要約

  • IESGは2026年6月22日、RPKIから得た検証状態を、管理境界をまたぐEBGPの経路属性で通知してはならないとするBest Current Practice文書を承認した。現行の第12版はRFC Editorの工程にある。
  • 問題は信頼性だけではない。状態は各ネットワークのキャッシュと時点に依存する一方、その属性が変わるたびに到達性の変わっていない多数の経路まで再広告され、検証系の障害がBGP制御面へ波及する。

一つの停止が二つの波になる

承認された文書は、AS65536がAS65537の顧客で、両者が同じ中央RTRサービスを利用する例を置く。これは実障害の報告ではなく、時刻差が何を起こすかを示す思考実験である。両ASは300秒周期で検証済みペイロードを更新し、検証状態に応じたCommunityを経路へ付けている。

AS65536はサービス停止の一秒前に更新を終えた。AS65537は停止の一秒後に更新時刻を迎える。先に情報を失うのはAS65537であり、多数の経路がValidからNotFoundへ変わる。Communityも変わるため、顧客側へUPDATEが流れ、AS65536もそれを受けて下流へ送る。

約300秒後、今度はAS65536の状態が失効し、同じ経路群の属性が再び変わる。一つのRTR停止が、異なるローカル時計を通じて二度のBGP作業を発生させた。キャッシュTTLを延ばせば時刻は後ろへ動くが、停止がTTLを超えれば二段階性は残る。

ここで分けるべきなのは障害の所在だ。変化したのは検証材料へのアクセスであって、プレフィックスの到達性でもOrigin ASNでもない。ローカルな判断を外部経路の一部にしたことで、検証系の変化が経路系のイベントへ変換された。

結論を運んでも証拠は運ばれない

RFC 6811のNotFound、Valid、Invalidは、ルータがローカルに保存したVRPと受信経路を照合した結果である。同RFCは検証状態を経路のローカルな性質として扱うよう求める。

判定には時点がある。Relying Partyがどの署名オブジェクトを取得できたか、検証に成功したか、キャッシュをいつ更新したか、RTRセッションが継続しているかによって結果は変わり得る。短い時間であれば、二つの管理ドメインが異なる状態を持つこと自体は異常ではない。

ところがCommunityに入るのは三つの状態のどれかだけだ。VRP集合、取得時刻、信頼アンカー、キャッシュの健全性、適用したローカルポリシーは付いてこない。受信者は結論を得るが、その結論を再現する材料を得ない。

さらに、通常のEBGP経路属性は署名されていない。承認文書が述べるとおり、第三者が状態を加えた可能性を排除できず、古いNLRIに古い判定が残る場合もある。受信したValidは証明書ではなく、送信側の内部状態を示したかもしれない未認証の注記にすぎない。

RFC 8097の適用範囲は最初から内向きだった

2017年のRFC 8097は、Origin Validation State Extended CommunityをAS内部で共有するために定義した。すべてのIBGP speakerが個別に検証しなくても、信頼関係のある内部ルータ間で結果を利用できる。属性はnon-transitiveであり、既定ではEBGPから受信したときに破棄し、EBGPへ送信しない。

例外として、隣接する二つのASが同一の管理主体に属する場合などは設定で許容できる。重要なのはプロトコル種別ではなく、誰が証拠と失敗責任を持つかという管理境界である。

新文書はこの考え方を特定のExtended Communityに限らない。通常のCommunity、Large Community、事業者独自の値、さらに将来の経路属性まで、状態変更が外部EBGPのUPDATEを生む仕組みを対象とする。ROAに基づくOrigin Validationだけでなく、ASPAやBGPsecのローカルな検証結果にも同じ原則を当てる。

実装上、内部speaker間で属性を使う必要が残ることは認めている。その場合でも、外部管理ドメインへNLRIを送る前に属性を除去しなければならない。内部の最適化を、暗黙の外部委任へ変えてはならない。

付加情報が経路表規模の負荷になる

文書が示す数値には日付が付いている。2024年2月にRISで観測したBGP UPDATEの8%から10%には、NotFoundまたはValidを示す既知のCommunityが含まれていた。ROAオブジェクトの作成や削除後、およそ一時間にわたる更新連鎖も観測された。

2026年半ばの例では、IPv4とIPv6を合わせた世界の経路表を約130万プレフィックス、その約65%をROAで覆われていると置く。状態を外部属性へ反映するネットワークでRPKIキャッシュが停止すれば、85万を超える経路を再送する可能性がある。

比率は将来も固定される統計ではない。示しているのは、付加情報の変化が本体と同じ配布費用を要求する構造だ。一つのROA変更なら関係するローカル経路を再評価すればよい。キャッシュ障害なら検証サービスを復旧すればよい。外部属性に状態を載せると、その再計算を隣接ネットワークのCPU、メモリ、キューへ請求することになる。

悪意ある操作にも余地ができる。自分のプレフィックスについて署名オブジェクトを発行・撤回できる者は状態を反転させられる。経路を再広告する者は未署名属性を書き換えられる。外部経路の識別に状態を組み込めば、検証イベントがBGP churnを起こす入力になる。

外部のラベルより自分の現行ビュー

送信側がRPKIを検証し、Invalidを拒否するなら、その経路はそもそも顧客へ届かない。隣接ネットワークが受け取る経路集合には、すでに送信側ポリシーの結果が反映されている。

受信側がOrigin Validationを必要とするなら、自分の現行RPKIビューで検証するべきだ。外部のValidは署名も再現可能な根拠も持たず、代替にはならない。内部機構を見せることと、外部で行使できる証拠を渡すことは別である。

最小共通層は、各参加者がローカルに確かめられる相互運用上の事実に絞るほど強い。あるルータの結論を境界の外へ出しても、時間、証拠、決定権までは移転しない。

出典