OcNOS における RPKI ルートオリジン検証：ピアリングエッジでの ROV 設定

ルートオリジン検証は、事業者がインターネットエッジに追加できる最も低コストな対策であり、任意から必須へと位置づけが変わりました。本ガイドでは、OcNOS での動作と、ピアリングルーターでの設定方法を、OcNOS-SP で検証済みのコマンドとともに説明します。

RPKI ルートオリジン検証とは何か

Resource Public Key Infrastructure（RPKI）は、Route Origin Authorization（ROA）と呼ばれる暗号署名されたレコードによって、IP プレフィックスをそれを広告する権限を持つネットワークに結び付けます。Route Origin Validation（ROV）は、着信した BGP 経路をこれらの ROA と照合し、valid、invalid、not-found のいずれかに分類するルーターの動作です。経路は、オリジン AS とプレフィックス長が ROA と一致すれば valid、ROA は存在するがオリジンまたは長さが誤っていれば invalid、その経路を含む ROA が存在しなければ not-found となります。ROV は、最も一般的なルーティングの事故と攻撃、すなわち自身が保有しないプレフィックスを広告して他の事業者のトラフィックを誤った方向へ送り込む行為を、一手で防ぎます。

いま RPKI が重要な理由

ルートオリジン検証は、もはやあれば便利という機能ではありません。大手トランジット事業者は RPKI-invalid な経路を既定で拒否し、各国の規制当局はガイダンスの中でルーティングセキュリティに言及し、MANRS のアクションはオリジン検証とプレフィックスフィルタリングを、まともなネットワークにとっての必須要件として扱っています。ピアリングエッジでインターネットの完全な BGP テーブルを保持する事業者にとって、ROV はごくわずかな労力で誤ったオリジンの問題群をまとめて取り除きます。しかも保護は直ちに得られます。すでに存在するすべての ROA の恩恵を、インターネットの他の部分を待たずに受けられるからです。

OcNOS が経路を検証する仕組み

OcNOS は RPKI データベースをルーター上に保持しません。外部の RPKI バリデーター（RPKI-to-Router（RTR）キャッシュとも呼ばれます）に接続し、トラストアンカーから ROA を取得して暗号的に検証し、検証済みのプレフィックスとオリジンの対応レコードをまとめてルーターに渡します。OcNOS はその検証済みテーブルをメモリ上に保持し、タイマーで更新し、経路を受信するたびに分類します。冗長化のために、ルーターを複数のバリデーターに向けることもできます。RTR プロトコルに対応するバリデーターであれば、Routinator、StayRTR と組み合わせた rpki-client、NLnet Labs の Krill 構成など、いずれも利用できます。

OcNOS で RPKI ルートオリジン検証を設定する方法

設定は 3 つの部分から成ります。ルーターをバリデーターに接続し、検証済みテーブルを充填させ、その結果に基づいて動作するポリシーを適用します。OcNOS はトランザクション方式のため、各段階は次のコマンドで適用します commit.

1. ルーターを RPKI バリデーターに接続する

BGP インスタンス内で、ルーターを 1 台または 2 台の RTR キャッシュに向けます。アドレスだけで完結したコマンドになり、 port は任意で、TCP では既定値が 3323 です。

configure terminal
router bgp 64500
 bgp rpki server 10.0.0.10 port 3323
 bgp rpki server 10.0.0.11 port 3323
 commit

2. 検証状態をマッチさせ、invalid な経路を破棄する

route-map を使って RPKI の状態に応じた処理を行います。この route-map は invalid な経路を拒否し、それ以外をすべて許可するため、valid と not-found の経路は受け入れられ、invalid な経路は破棄されます。

route-map RPKI-EDGE-IN deny 10
 match rpki invalid
!
route-map RPKI-EDGE-IN permit 20
 commit

3. ピアリングセッションのインバウンドにポリシーを適用する

保護対象のアドレスファミリーで、route-map を eBGP ピアに適用します。次の下でも同様に繰り返します。 address-family ipv6 unicast （IPv6 の場合）

router bgp 64500
 address-family ipv4 unicast
  neighbor 203.0.113.1 route-map RPKI-EDGE-IN in
  exit
 commit

RPKI 検証が機能していることを確認するには

バリデーターセッションが確立していること、検証済みテーブルにエントリーがあること、経路が分類されていることを確認します。OcNOS はこのための 3 つのコマンドを提供します。

OcNOS# show bgp rpki server
OcNOS# show bgp rpki table ipv4
OcNOS# show bgp rpki table ipv6

show bgp rpki server は各バリデーターとそのセッションが確立しているかを報告し、 show bgp rpki table ipv4 lists the validated prefix-to-origin records the router downloaded for IPv4, and show bgp rpki table ipv6 does the same for IPv6. Once the session is established and the table has entries, routes that fail validation carry the invalid state and are dropped by the route-map at the edge.

ピアリングエッジにおける RPKI

Origin validation is one layer of a secure peering edge, not the whole of it. On a complete open peering router, RPKI invalid-route rejection sits alongside prefix filtering aligned with MANRS, BGP FlowSpec for DDoS mitigation, and remote-triggered black-holing, so the router enforces routing hygiene and attack response from the same place it carries the full table. See how the roles fit together on the オープンな IP コア／ピアリングルーター.