RPKI-to-Router デプロイメントと失われたガバナンス層

概要

RPKI-to-router チェーンは権限とアクションを分離する。リソース保持者と認証局は署名オブジェクトを公開し、検証者ソフトウェアはそれらを検証して検証済みペイロードをエクスポートし、ルーターは経路を分類し、オペレーターはローカルのインポート、ベストパス、エクスポートポリシーにおいて Valid、Invalid、NotFound が何を意味するかを決定する。
RFC 8481は2018年に境界を明確にした。実装は検証状態を設定すべきだが、オペレーターの具体的な設定なしにポリシーを適用すべきではない。最終的な処理決定は、レジストリやバリデータではなく、オペレーターが行う。
ローカル制御があっても、上流のアクターが無関係になるわけではない。証明書の誤り、失効、ROA、リポジトリの状態は、それに正しく従う下流の分類をすべて変える可能性がある。したがって、責任は制御される行為によって分割されるべきであり、レジストリか経路を運ぶネットワークのいずれかに全面的に割り当てられるべきではない。
「Invalid」は、ある時点で利用可能な検証済みデータに対する暗号的および構文的な結果である。それはルーティングポリシーにとって強力な証拠だが、根本的な原因がハイジャック、保持者のミス、移転遅延、誤った maxLength、不利な証明書アクション、または古い検証データであるかを特定するものではない。
ルーターポリシーは単一のバイナリスイッチではない。ネットワークは Invalid 経路を拒否したり、保持しつつもベストパス選択の対象外としたり、優先度を下げたり、ピアクラスごとに扱いを制限したり、最初にアラートを出したり、狭いローカル例外を維持したりできる。それぞれの選択には異なるセキュリティ、到達性、回復の効果がある。
運用チェーンにはタイミングと状態がある。RPKI-Router Protocol セッションはキャッシュからのアナウンスと撤回を運び、シリアル番号とセッション識別子を使用し、リフレッシュ、リトライ、期限切れの動作を指定する。レジストリでの修正は、公開、検証、キャッシュ転送、ルーターの再評価がすべて収束するまで、修復された転送決定とはならない。
ガバナンスはすべての境界で決定レシートを要求すべきである。署名オブジェクトと変更理由、バリデータのバージョンとトラスト入力、キャッシュのシリアル番号と経過時間、ルーターポリシーのバージョン、影響を受けるピアクラス、観測された経路の結果、例外権限、回復時間などだ。この証拠のないラベルでは、異議申し立てや責任追及には薄すぎる。
番号資源社会はこれらの境界を比較し、修正経路をテストし、自らがグローバルなルーティングコントローラーになることなく、小規模オペレーターを代表することができる。その有用な役割は、オペレーターがローカルルーティングポリシーを決定する権利と義務を保持しつつ、権限と救済を可読化することにある。

最終決定は設計上ローカルである

現代の起点検証において最も重要な一文は、レジストリ契約やルーターのコマンドガイドにはない。それは2018年9月に発行された RFC 8481に現れる。「経路が評価され、その検証状態が設定されたならば、オペレーターはその状態から適用されるポリシーを完全に制御すべきである。オペレーターの具体的な設定なしには、ポリシーを適用してはならない。」この標準の指示は「状態を設定せよ、行動するな」である。

この区別は、Invalid 経路の最終処理を誰が決定するかという狭い疑問に答える。それはネットワークオペレーターである。RIR はトラストアンカーを運用し、証明書を発行し、認証サービスをホストし、オブジェクトを公開できる。リソース保持者は ROA で起点 AS を認可できる。バリデータはリポジトリを取得し、証明書パスを認証し、検証済み ROA ペイロードを生成できる。ルーターは BGP アナウンスをそれらのペイロードと比較し、状態を付加できる。これらのどのステップも、それだけでは、特定のネットワークが顧客から経路を受け入れるか、ピアからそれを優先するか、トランジットにエクスポートするか、転送テーブルにインストールするかを決定しない。

この答えが単純なのは、「決定する」が最後に設定されたアクションを意味する場合だけである。決定が原因と混同されると、より困難になる。レジストリの誤りは、正しいバリデータに認可を削除させる可能性がある。正しいキャッシュは、ルーターに長年の経路を再分類させる可能性がある。ベンダーのデフォルトは、オペレーターが理解しているよりもアグレッシブなポリシーにしうる。トランジットプロバイダの拒否は、保持者自身のネットワークが経路を受け入れ続けていても、保持者を到達不能にする可能性がある。複数の機関が因果的に重要でありうるが、各ローカルルーティング決定を制御するのはただ一つのネットワーク管理者だけである。

この分散はドメイン間ルーティングの基本的な特徴である。自律システムが自律的であるのは、どの相手と接続し、どの経路を使用するかを選択するからだ。レジストリの署名オブジェクトを普遍的な遠隔制御命令に変えることは、ルーティング権力を認証階層に集中させ、リスク、顧客義務、ローカル知識の違いを消し去るだろう。逆に、レジストリが無害な情報を公開しているだけだとするのは、その認証済みオブジェクトが自動化されたポリシーをどれほど強く形成しうるかを過小評価している。

良いガバナンスはこの両方の命題を同時に保持しなければならない。認証局は、自らが制御する表明とステータス変更について説明責任を負う。オペレーターは、自らが選択するルーティングポリシーと、それを適用する回復力について説明責任を負う。欠けている層は、両者の間の新たな中央決定者ではない。それは、境界を越えた義務、証拠、救済の可視的な割り当てである。

4つの動詞が、一機関があらゆる義務を継承するのを防ぐ

公開の議論はしばしば起点検証を一つの動詞「RPKI がハイジャックをブロックする」に圧縮する。このフレーズはアドボカシーとしては有用だが、制度分析としては貧弱である。実際には、認可、検証、分類、行動という4つの異なる動詞が関与している。それぞれが異なる主体、証拠基盤、救済を持つ。

保持者は、証明書パスの下で ROA を発行または要求することにより起点を認可する。ホスト型サービスでは、RIR が鍵と公開操作の多くを制御する場合がある。委任された形態では、保持者がより直接的に制御できる。認証階層は、署名者が関連する番号資源の権限を持つかどうかを確立する。結果として得られるオブジェクトは、指定された長さ制限内でプレフィックスを起点とすることを AS が認可されていると示す。それは BGP でプレフィックスをアナウンスするものではなく、経路が商業的に受け入れ可能であると約束するものでもない。

検証当事者は検証する。署名オブジェクトを取得し、証明書、失効リスト、マニフェスト、オブジェクトプロファイルをチェックし、標準とローカルトラスト設定に従って使用可能なペイロードの現在のセットを構築する。これは認証済みデータに関する計算上の判断である。異なるバリデータ実装やリポジトリビューは一時的に不一致を起こしうる。ローカルフィルタとアサーションは、グローバルデータから意図的に異なるビューを生成することもできる。

ルーターは、起点とプレフィックスを検証済みペイロードと比較することにより経路を分類する。よく知られた状態は Valid、Invalid、NotFound である。Valid は少なくとも一つの関連する認可が一致することを意味する。Invalid はカバーする認可データが存在するが、観測された起点とプレフィックス長の組み合わせを認可するものがないことを意味する。NotFound は関連する検証済みペイロードが経路をカバーしていないことを意味する。この状態はその比較を説明するものであり、経路の歴史や正当性の完全な説明ではない。

最後に、オペレーターが行動する。そのポリシーは経路を拒否、優先、低優先、隔離、タグ付け、ログ記録、または一時的に例外とすることができる。それらは顧客、ピア、トランジット、ルートサーバー、アドレスファミリ、地域、クリティカルサービスによって異なりうる。それらはプレフィックスフィルタ、IRR データ、最大プレフィックス制限、コミュニティ、商業的優先度、最長プレフィックス転送と相互作用する。低優先度で保持された経路は、競合する集約よりも具体的である場合にトラフィックを引き寄せる可能性があり、これは RFC 7115がオペレーターに見落とさないよう警告している点である。

この用語が重要であるのは、責任が制御に従うべきだからだ。署名者は誤った認可について答えるべきである。バリデータのメンテナは、提供する保証の範囲内で再現可能な検証欠陥について答えるべきである。キャッシュオペレーターは、運用を約束した安全性や鮮度の低い配信サービスについて答えるべきである。ネットワークは自らのポリシーとテストについて答えるべきである。いかなる層も、その出力の力を主張しつつ、すべての結果を他者の問題であると述べることを許されるべきではない。

Invalid は状態であり、動機に対する評決ではない

Invalid 分類は噂よりも正確であり、司法上の認定よりも狭い。起点検証の下では、少なくとも一つの検証済みペイロードが経路のプレフィックスをカバーしているが、アナウンスされた長さをカバーし、かつ観測された起点 AS を名前として挙げるペイロードがないことを意味する。数学はその不一致がなぜ存在するかを語らない。

この不一致は、起点ハイジャックの試みかもしれない。また、ROA を変更する前にトランジットプロバイダを変更したリソース保持者、maxLength を超えるより具体的なプレフィックスをアナウンスした運用チーム、ルーティング調整が完了する前に証明書状態が変わった移転、あるいは権限を予期せず削除したレジストリアクションかもしれない。バリデータはオペレーターの変更チケットが予想したよりも新しいリポジトリビューを持っているかもしれない。ルーターは一つのキャッシュを使用している一方で、エンジニアの診断ツールは別のものを参照しているかもしれない。ローカルアサーションが差異を修復または作成するかもしれない。これらすべてが、コマンドラインで同じ3文字の状態を生み出しうる。

このことは Invalid が弱い証拠であることを意味しない。起点検証の目的は認証された認可を使用可能なルーティングシグナルに変換することであり、Invalid 経路の拒否は偶発的および悪意のある誤起点のコストを実質的に引き上げる。この分類はアクションをサポートするように設計されている。しかし、セキュリティコントロールは、即時の封じ込めと最終的な原因帰属を区別できるときに初めて統治可能になる。

オペレーターは、特に認証された顧客例外が存在しないピアまたはトランジット境界では、最初に Invalid 経路を拒否し、その後調査するというのが合理的でありうる。その即時アクションはローカルのセキュリティ判断である。影響を受けた保持者が誤りを主張するならば、問題は変わる。当事者はそのとき、正確なプレフィックス、起点 AS、カバーペイロード、maxLength、バリデータ時刻、キャッシュシリアル、ルーターポリシー、および最初に観測された遷移を必要とする。彼らは、一致する認可が他に存在したかどうか、撤回が公開されたかどうか、異なるビューがどれだけ早く収束したかを知る必要がある。

すべての Invalid を敵対的行為の証明として扱うことは、意味のある修正権を否定する。すべての Invalid を無害な設定ノイズとして扱うことは、保護を無効にする。実行可能な中間は手続き的である。宣言されたポリシーに従って封じ込め、証拠を保存し、認証されたエスカレーションパスを提供し、原因を分類し、それを導入した層で修正し、復旧を測定する。このような手続きは、自動化された拒否の価値と、認証データが誤りうる可能性の両方を尊重する。

したがってガバナンスの問題は、ラベルを信頼すべきかどうかではない。そのラベルがどのような主張を支持し、どれだけの期間、どの入力の下で、そして正当な利害を持つ人がそれに異議を唱えたときに何が起こるかである。

レジストリの権限は実質的だが、転送テーブルには及ばない

RIR は、RPKI 証明書階層が番号資源管理に従っているため、強力な地位を占める。彼らは地域トラストアンカーとサービスを運用し、登録関係を維持し、検証当事者が依存する証明書材料を公開する。ホスト型の取り決めでは、保持者の認証された指示に基づいて ROA を生成し公開することがある。失効、リソースセット変更、公開障害は、バリデータが生成するペイロードを変えうる。

それは本物の権限である。RPKI を単にオプションのデータベースと呼ぶことは、暗号の優先度と自動消費の効果を曖昧にする。多くのネットワークが Invalid 経路を拒否するようになれば、上流の誤った変更が独立したネットワーク間で到達性の喪失に変換されうる。各オペレーターが自由に拒否を設定したという事実は、誤った証明書状態を無関連にしない。橋の管理者は、各ドライバーが信号に従うことを選んだからといって、自らの故障した信号について免責を主張できない。

しかし、RIR は世界の BGP スピーカーを運用しているわけではない。すべての二国間ピアリング条件、緊急サービス依存関係、プライベート経路、顧客メンテナンスウィンドウ、ローカル例外を知ることはできない。ネットワークに Invalid アナウンスの拒否を強制することはできず、また文書化されていないデフォルトによってそうできるようにもすべきではない。RFC 8481のオペレーター制御ルールは、検証ソフトウェアが黙ってレジストリ状態をルーティングポリシーに変換することを防ぐ。

境界はサービスコミットメントとして表現されるべきである。レジストリは、定義された制限内で、認証された制御、保持者指示の正確な処理、保護された鍵操作、一貫した公開、通知、修正、保存された記録を保証すべきである。証明書と ROA の変更がどのように認可されるか、どのような緊急チャネルが存在するか、どのタイムスタンプが記録されるか、不利または誤ったアクションにどのように異議を唱えうるかを公開すべきである。すべてのネットワークが修正されたすべての経路を運ぶこと、またはすべての結果的なビジネス損失を補償することを保証する必要はない。

オペレーターもまた、レジストリが行わなかった選択についてレジストリを非難すべきではない。キャッシュの経過時間を監視せず、再評価をテストせず、顧客エスカレーション経路を提供せずに拒否を適用するネットワークは、それらの設計決定の持ち主である。ルーターがパスを破棄し、それを回復しなかったために修正されたペイロードを無視するプロバイダは、別の故障の持ち主である。商業的な都合で既知の誤起点を受け入れ続けるネットワークは、その受け入れを RIR によって強制されたと説明できない。

可視的な境界は責任を弱めるどころか強くする。それらは修理可能な機関を特定する。レジストリは認可状態を修正できる。バリデータオペレーターは取得や検証を修正できる。ルーターベンダーは実装を修正できる。ネットワークはポリシーを変更し経路を復旧できる。曖昧な共有責任の主張は、しばしば誰も時計を動かしていないことを意味する。

バリデータは独立した解釈者であり、控訴裁判所ではない

検証当事者ソフトウェアは、署名された公開とルーター消費の間に位置する。分散リポジトリからオブジェクトを収集し、設定されたトラストアンカーに対してそれらを認証し、検証ルールを適用し、ペイロードのセットを生成する。RFC 8897はこの役割の多くの要件を統合し、独立した実装は解析、取得、キャッシュ処理、リリース実務において有用な多様性を提供する。

バリデータの裁量は制限されている。不正な形式のオブジェクトを拒否し、古いか失効したチェーンを使用不能と見なし、標準の範囲内でリポジトリ転送動作を選択し、診断情報を公開することができる。適切に認証された ROA を不当と宣言し、オペレーターがレジストリに異議を唱えたからといって異なるグローバル認可を代用することはできない。もしそうすれば、ソフトウェアメンテナが番号資源権限に関する任命されていない控訴機関になってしまうだろう。

それでもローカルの自律性は存在する。RFC 8416は SLURM を定義し、オペレーターが検証済みペイロードをフィルタしたり、ローカルアサーションを追加したりすることを可能にする。これは、不利なアクションの間に経路を保護したり、グローバル RPKI が表現できないプライベートな使用を許可したりすることができる。重要な形容詞は「ローカル」である。例外は、そのオペレーターと、そのオペレーターが修正されたビューを意図的に提供する任意の顧客が使用するビューを変更する。それは他のネットワークのために署名された状態を書き換えることはない。

したがって、バリデータの運用は宣言されるべきガバナンスの選択を含んでいる。どのトラストアンカーロケーターが受け入れられるか？ローカルフィルタやアサーションはロードされているか？どのリポジトリ転送が有効か？古いデータはどのように扱われるか？どのバリデータバージョンと暗号ライブラリが実行されているか？ルーターは一つのキャッシュビューを受け取るのか、複数から選択するのか？誰が例外を承認でき、それはどれほど狭くありうるか、いつ期限切れになり、どのような証拠がそれを閉じるか？

複数のバリデータを動かすことは価値があるが、それだけでこれらの質問に答えるわけではない。二つのインスタンスがリポジトリパス、トラスト設定、またはパッケージチャネルを共有するかもしれない。出力が異なる場合、多数決は欠陥を特定するのと同じくらい容易に古い状態を保持しうる。有用な比較は、オブジェクトと入力レベルでの違いを説明する。どのバイトが取得されたか、どの証明書パスが受け入れられたか、どのシリアルがエクスポートされたか、どのペイロードが追加または撤回されたか。

これがまた、バリデータがルーティングポリシーを吸収すべきでない理由である。それらは高品質の状態、来歴、経過時間、エラー情報を提供すべきである。ルーターとネットワークポリシー層が運用上の扱いを決定すべきである。検証と拒否を一つの不透明な管理サービスの背後で組み合わせることは便利かもしれないが、最も重要な引き継ぎ、すなわち認証された表明が接続性の決定になる瞬間を隠してしまう。

RPKI-Router Protocol は状態を運び、制度的同意を運ばない

RFC 8210は、検証済みキャッシュからルーターへの実用的な橋渡しを記述する。ルーターは一つ以上のキャッシュとの関係を確立し、設定された優先度に従って選択し、完全または増分のデータセットを要求する。セッション識別子はキャッシュインスタンスを区別し、シリアル番号はセッション内の論理バージョンを識別する。プレフィックスアナウンスと撤回は、正確な検証済みレコードを追加または削除する。End of Data メッセージは一貫した更新を完了し、タイミングパラメーターを運ぶ。

これらの詳細は、時間とともに変化する状態にポリシーが適用されるため、運用上重要である。キャッシュは新しいデータが利用可能であることをルーターに通知できるが、その通知はヒントであり、ルーターは依然としてクエリを行う。増分履歴が利用できない場合、ルーターはリセットして完全なセットを要求するか、別のキャッシュに移動することができる。セッション識別が予期せず変わった場合、古くなったレコードをフラッシュする必要があるかもしれない。キャッシュ対ルータープロトコルでの撤回は、同じプレフィックス、最大長、ASN を持つ以前にアナウンスされた権利を削除する。

タイミングモデルは限られた継続性ウィンドウを作り出す。リフレッシュ間隔はルーターが再ポーリングすべき時を示す。再試行間隔は失敗後の試行を管理する。期限切れ間隔は、現在のキャッシュデータが正常な更新なしに使用され続けうる時間を制限する。RFC 8210の推奨デフォルトは工学的パラメーターであり、普遍的なサービス公約ではない。導入者は指定された範囲内で値を設定できる。制度的に重要なのは、キャッシュ接続が失敗したからといって、古い認可が無期限の寿命を持たないことである。

同時に、期限切れは到達性リスクを変えうる。検証済みデータが消失すると、経路は NotFound 扱いまたは実装固有の別の状態に移行しうるが、これはアーキテクチャとポリシーに依存する。Invalid 経路のみを拒否する設計は、期限切れ後にオープンに失敗するかもしれない。検証の喪失を広範な拒否の根拠とする設計は、クローズドに失敗し、有効なネットワークを切断するかもしれない。標準の転送動作は、オペレーターがどちらの継続性リスクを優先すべきかを選択できない。

プロトコルの存在は、機関にメッセージを過大解釈させる誘惑となりうる。Prefix PDU は RIR からルーターへの指令ではない。それは、ルーターオペレーターによって信頼されたキャッシュが、自らの検証済みビューから導出して発するデータである。そのシリアル番号は、そのキャッシュセッション内での順序を証明するものであり、レジストリ間の合意やピアリング契約に基づく許可を証明するものではない。ルーターのそれの使用は、設定されたローカルな行為であり続ける。

統治可能な展開は引き継ぎを記録する。争点となった決定に使用されたペイロードを供給したキャッシュセッションとシリアル、ルーターがそれを受け入れた時、後の撤回が到着した時、影響を受けたパスが再評価された時を示すことができる。その記録がなければ、運用上最も決定的なステップが、上流の証明書セレモニーよりも少ない証拠しか残さない。

ルーターはいくつかの扱いを提供し、それぞれが異なる救済を持つ

ベンダーおよびオープンソースのルーター文書は、起点検証が一つの普遍的なアクションを強制しないことを確認している。Cisco の例は、Valid、NotFound、Invalid 経路に異なるローカルプリファレンスを割り当てるポリシーと、Invalid パスを保持しつつベストになるのを防ぐ代替案を示す。Juniper のガイダンスは、検証状態をマークするポリシーと Invalid 経路を拒否する後の項を分離する。FRRouting は同じ状態に対するルートマップマッチを公開し、パスを破棄する代わりにプリファレンスを下げることができる。

第一の扱いはインポート時のハード拒否である。これは経路がその境界で使用可能な BGP 決定セットに入るのを防ぐ。これは明確な保護を提供するが、実装が拒否されたパスを保持していなかった場合、回復を複雑にする可能性がある。修正された ROA が到着したとき、ルーターは保存されたポリシー前経路、ソフト再設定、またはネイバーからの経路リフレッシュを必要とするかもしれない。RFC 9324は、新しい RPKI データが負荷の高いリフレッシュを引き起こす害に対処し、RPKI ポリシーによって影響を受けたパスを保持して、ローカルで再評価できるよう推奨している。

第二の扱いはパスを保持するが、ベストパス選択の対象外とする。検証が変わったとき、経路は再評価に利用可能なままなので、迅速に回復できる。これはメモリを消費し、パスが誤って転送やエクスポートに漏れ出さない保証を必要とする。証拠は「回復のために保持されている」ことと「使用可能として受け入れられている」ことを区別すべきである。

第三の扱いはプリファレンスを下げる。これは段階的展開や顧客固有の移行を支援できるが、安全性と同等ではない。Invalid 経路が唯一のパスである場合、依然として勝つかもしれない。Valid な集約よりも具体的である場合、最長プレフィックス転送はより低い BGP プリファレンスにかかわらずトラフィックを引き寄せる可能性がある。例外は、経路テーブルの見た目だけでなく、実際の転送結果を中心に設計されなければならない。

第四の扱いは実施前の監視とタグ付けである。これはオペレーターに顧客のエラーを特定し、エスカレーションサービスを構築し、機器をテストする時間を与える。その弱点は明らかである。観測だけではハイジャックを止められない。したがって、段階的計画には、無期限のパイロットではなく、日付、閾値、説明責任のある承認が必要である。

最後に、オペレーターは狭いローカル例外を適用できる。例外は修正中の検証済み保持者に対して正当化されうるが、プレフィックス、起点、影響を受けるセッション、承認者、証拠、期限、レビューを指定すべきである。広範で恒久的なバイパスは、黙って第二の認可体制を作り出す。誤った拒否への救済と安全でない例外に対する制御は同じものである。保存された決定記録を伴う、正確で時間限定の状態だ。

ピアリングとトランジットは一つの状態を異なる義務に変える

ネットワークは法的な真空の中で経路を受け取るのではない。顧客セッション、セトルメントフリーのピアリングセッション、トランジットフィード、ルートサーバーセッションは異なる期待を抱く。起点検証は、プレフィックス認可、エクスポート範囲、トラフィックエンジニアリング、最大プレフィックス保護、商業的優先度の中の一つの入力としてこれらの関係に入る。

トランジットプロバイダは通常、利用規定とルーティングセキュリティ条件に従うことを条件に到達性を約束する。顧客の Invalid 経路を拒否する場合、顧客は明確な通知と修正された認可を証明する認証された方法を必要とする。プロバイダは拒否する強力な根拠を持つかもしれないが、それでもプレフィックス、観測された起点、検証証拠を特定すべきである。「インターネットが Invalid と言っている」は、単一のインターネットルーターが決定を下しているわけではないため、適切なサービス応答ではない。

ピアリング境界では、ネットワークはすべての経路を運ぶ義務を負わないかもしれない。交換条件として厳格なポリシーを採用できる。しかし、誤った分類がピアとその顧客の双方に影響を与えうるため、透明性は依然として重要である。ピアリングコーディネーターは、拒否がローカルネットワーク、ルートサーバー、検証サービス、伝播された状態コミュニティのいずれから来たのかを知る必要がある。iBGP またはルートサーバーの枠組みでの起点検証拡張コミュニティの使用は状態を配布できるが、RFC 8481はオペレーターが設定しない限り自動アクションに対して警告している。

ルートサーバーは境界を特に可視的にする。多くのメンバーに代わって検証とフィルタリングを行うか、単に情報を付加して各メンバーに決定を委ねるかもしれない。共有サービスは一貫性を改善し、導入コストを削減できる。また、一つの設定エラーを交換全体に増幅させうる。そのポリシー、例外権限、キャッシュ入力、変更通知は、したがってサービス条件と技術文書で明示的であるべきである。

下流の顧客は原因帰属を複雑にする。小規模ネットワークはバリデータを運用せず、上流の有効なポリシーのみを受け取るかもしれない。その経路は、データを公開した RIR から遠く離れた場所で拒否される可能性があり、その離れたオペレーターへの契約上の経路がない。ここで集合的な機関が役立つ。標準化された通知と相互運用可能な証拠は、小規模な保持者がすべてのフィルタリングネットワークと個別に交渉する必要性を減らす。

商業的自律性は情報上の免責になってはならない。ネットワークはいかなる経路も拒否する権利を保持しうるが、その拒否を RPKI の執行として提示するならば、どの状態とポリシーがそれを生み出したかを示すことができるべきである。その最小限の開示は、運搬を強制することなく正確な責任を保持する。

修正は ROA が変わった時点では完了しない

運用チェーンは非同期である。保持者はポータルで ROA を修正しても、依然として到達不能でありうる。新しいオブジェクトは生成され公開されなければならない。リポジトリクライアントはそれを取得しなければならない。バリデータは一貫した現在のビューを認証し、ペイロードセットを変更しなければならない。キャッシュはルーターのポーリングを通知または待機しなければならない。ルーターは追加または撤回を受け取り、検証状態を再計算し、ポリシーを再適用しなければならない。パスが破棄された場合、ネイバーは再評価を必要とするかもしれない。トラフィックはその後再収束しなければならない。

各段階は成功しつつも、最終結果は壊れたままでありうる。RIR は修正されたオブジェクトを自らのリポジトリで示せるが、あるバリデータは公開ポイントを取得できないかもしれない。バリデータは正しいペイロードを示せるが、ルーターは障害が発生した優先キャッシュに固定されているかもしれない。ルーターは状態を更新できるが、変更前に計算されたポリシー結果を保持するかもしれない。ある境界クラスターは回復する一方で、別のクラスターは期限切れデータを持っているかもしれない。プロバイダはインポートを回復しても、ピアへのエクスポートを抑制し続けるかもしれない。

そのため、意味のあるサービス指標は「ポータル確認までの時間」ではない。それは、認証された修正リクエストから、宣言されたチェックポイントを横断して観測された復旧までの時間である。チェックポイントは地球上のすべてのネットワークを含む必要はない。それらは発行者の公開、少なくとも二つの利用可能な独立した検証ビュー、影響を受けたプロバイダのキャッシュとルーター状態、代表的な外部 BGP コレクターまたは顧客プローブを含むべきである。

RFC 9324は重要な回復の教訓を加える。ルーターが Invalid パスを破棄し、十分なポリシー前状態を保持しなかった場合、新しい RPKI データはネイバーへの経路リフレッシュ要求を引き起こすかもしれない。大規模では、これは深刻な負荷やピアリング解除さえ引き起こした。影響を受けたパスをローカル再評価のために保持することは、したがって単なるパフォーマンス改善ではない。それは修正権の一部である。ネットワークが経路を忘れ、それを回復する安全な方法がない場合、保持者の認可は迅速に修復できない。

このチェーンは、固定されたグローバルな期限がなぜ誤解を招きうるかも説明する。公開頻度、リポジトリの健全性、バリデータのポーリング、キャッシュタイマー、ルーターアーキテクチャ、BGP コンバージェンスは異なる。ガバナンスは、不可能な普遍的な瞬間を約束するのではなく、制御された段階で測定可能な目標を指定し、観測されたエンドツーエンドの復旧を報告すべきである。

修正レシートには、新旧のオブジェクト識別子、公開時刻、バリデータの初回確認時刻、ペイロード変更、ルーターの初回適用時刻、経路再評価方法、外部観測を含めるべきである。これは、インシデント後の改善と、どの機関が回復を遅らせたかに関するあらゆる紛争のための記録を作成する。

5つの障害ケースが5つの異なる説明責任主体を明らかにする

まず、保持者の認証された指示から作成された誤った ROA を考えよう。保持者が間違った起点または最大長を入力し、レジストリがそれを正確に処理した場合、主要な修正義務は保持者にあり、レジストリは依然として使用可能な変更管理と警告ツールを負う。ポータルが正しい指示を誤って変換した場合、責任はサービスオペレーターに移る。結果として生じた Invalid 経路を拒否するルーターは、宣言されたポリシーを適用したのであり、悪い認可を作り出したわけではない。

第二に、有効なペイロードを削除するレジストリの証明書または公開エラーを考えよう。バリデータは、同じ上流状態を忠実に処理しているため、合意するかもしれない。彼らの合意は発行者を免罪するものではなく、原因を特定するものである。オペレーターは依然として緊急例外が適切かどうかを決定するが、レジストリは迅速な復旧、理由、保存された証拠を負う。

第三に、一方が古いリポジトリデータやソフトウェア欠陥のために、二つのバリデータが一致しないとしよう。キャッシュオペレーターは入力の差異を分離し、ソフトウェアメンテナは再現可能な欠陥を修正すべきである。ネットワークは不一致の間、どのビューを使用するかを決定しなければならない。単純な多数決では不十分である。二つの古いインスタンスが一つの最新のインスタンスに勝つ可能性がある。決定は、鮮度、トラスト入力、オブジェクト証拠、障害の独立性を考慮すべきである。

第四に、キャッシュ対ルーター接続がデータ期限切れまで障害を起こすとしよう。RFC 8210は無期限の保持を防ぐが、ネットワークのその後のルーティングポリシーを選択するわけではない。キャッシュサービスは、そのコミットメントの範囲内で可用性について説明責任を負う。オペレーターは冗長性、期限切れ処理、検証の喪失がオープンに失敗するかクローズドに失敗するかについて説明責任を負う。ベンダーは、実装が設定または標準化された動作と矛盾する場合に説明責任を負う。

第五に、正しいペイロードがルーターに到達するが、ポリシー項が誤って順序付けられたり、一部のセッションにのみ適用されたり、ベンダーデフォルトから継承されたりするとしよう。これはオペレーターの設定障害であり、おそらく不十分なベンダー診断によって助長されている。レジストリはそれを修復できない。証拠には、ポリシーバージョン、セッション範囲、経路テーブルの結果を含めるべきであり、Valid ペイロードのスクリーンショットだけでは不十分である。

これらの例は、一つの広範な「RPKI インシデント」カテゴリーがなぜ不十分であるかを示す。同じ可視的症状—到達不能なプレフィックス—は、認可、検証、配布、分類、またはポリシーから生じうる。インシデントレビューは、最初の誤った状態遷移と、すべての失敗した封じ込めまたは回復義務を割り当てるべきである。複数のアクターが異なる部分について説明責任を負いうるが、責任が無意味になるわけではない。

権利と救済は害が発生する境界で執行可能でなければならない

ガバナンス憲章は、影響を受けた当事者がそれを行使できる場合にのみ有用である。保持者は認証サービスへの認証された緊急チャネル、保留中および公開された変更を見る方法、耐久性のあるレシートを必要とする。権限が削除された場合の理由と、誤りや不利なアクションに異議を唱える経路を必要とする。日常的な保持者の誤りについては、セルフサービス修正で十分かもしれない。争われている失効や法的強制については、独立したレビューと継続性の取り決めがより重要になる。

オペレーターの顧客は異なる救済を必要とする。経路が拒否された理由を尋ね、プロバイダ自身の観測に結びついた回答を受け取ることができるべきである。プロバイダは、無関係なネットワークセキュリティ詳細を暴露することなく、検証状態、キャッシュ時刻、カバーペイロード、関連するポリシークラスを開示すべきである。商業的およびセキュリティリスクが許す場合には、狭く制御された一時的な例外手続きを提供すべきであるが、いかなる顧客も伝播を強制する無条件の権利を前提とすべきではない。

オペレーターはまた、キャッシュまたは管理された検証サプライヤーに対する権利を必要とする。サービス条件は、トラストアンカー、ソフトウェア、更新目標、古いデータの動作、通知、ログ保持、分岐時のサポートを特定すべきである。サプライヤーが検証とルーティング推奨を組み合わせる場合、事実に基づくペイロード変更とそのポリシーアドバイスを分離すべきである。顧客は最終的なルーティング選択を理解し、上書きできるままでなければならない。

ルーターベンダーは実装可能な制御を負う。オペレーターは、検証とアクションを区別し、キャッシュセッションと経過時間を表示し、影響を受けたパスを安全に保持または回復し、ポリシー項が一致した理由を公開するコマンドとテレメトリーを必要とする。デフォルトは文書化されるべきであり、アップグレードが Invalid や NotFound 経路の扱いを黙って変えるべきではない。再現可能な欠陥には、セキュリティレスポンスとリリース記録が必要である。

救済は比例的であるべきである。通常、即時の技術的修正が投機的な損害賠償よりも価値がある。通知、保存された状態、迅速な撤回または置換、再評価、外部検証が最初に来る。制御された障害と文書化された損失が残る場合に金銭的または契約上の救済が続くかもしれないが、無制限の責任は共有インフラを阻害し、証明書とパケットの間の多くの独立した決定を反映できないだろう。

したがって、執行可能な最小限は普遍的な到達性の保証ではない。それは、争点となっているステップを制御する機関からの証拠とタイムリーなアクションへの権利である。その権利は、拡散した技術的依存を、回答可能な一連のサービスに変換する。

決定レシートは分散された権限を監査可能にする

RPKI はすでに署名オブジェクトと注意深く規定された検証ルールを含んでいる。オペレーター境界でしばしば欠けているのは、それらのオブジェクトをルーティング結果に結びつけるコンパクトな記録である。決定レシートは新たなグローバル認可ではない。それは各アクターが自身のアクションのために作成する証拠フォーマットである。

認証層では、レシートはリソース、新旧の認可、リクエスト識別子、承認方法、有効公開時刻、理由カテゴリー、およびあらゆる異議申し立てや緊急リファレンスを特定すべきである。センシティブな個人詳細は保護されたままで、オブジェクトレベルの変更と権限基盤が見えるようにできる。

バリデータ層では、ソフトウェアとバージョン、アクティブなトラストアンカー、ローカル修正、リポジトリスナップショットまたは観測時刻、検証結果、ペイロードの追加または撤回、関連する警告を記録すべきである。キャッシュ対ルーター層では、キャッシュ識別子、プロトコルバージョン、セッション識別子、シリアル、転送完了、データ経過時間を追加すべきである。これらの詳細は「私のバリデータは別のことを言っている」を再現可能な比較に変える。

ルーター層では、レシートは経路、ピアクラス、検証状態、一致したポリシー項、結果としてのアクション、ポリシーバージョン、時刻を指定すべきである。経路が保持されていたが不適格であった場合、記録はその旨を示すべきである。例外が適用された場合、範囲、承認者、期限を含めるべきである。大規模プロバイダにとって、記録は自動的に生成され、正当なクエリに応じて選択的に開示されうる。

外部観測がチェーンを完成させる。RIPE RIS、RouteViews、オペレーターのルッキンググラスは、アナウンスが選択された視点から現れたかどうかを示すことができる。それらはすべてのネットワークが何を受け入れたかを証明できず、あるコレクターでの不在はグローバルな抑制の証明ではない。その価値は独立した時間的証拠である。経路は変更前にここで可視であり、変更後にここで不在となり、記録された時刻にここで復旧した。

レシートは、異なるキャッシュからのシリアル番号が直接比較可能であるかのように偽ることなく、安定した識別子を使用すべきである。生のタイムスタンプを保存し、推論を明確にマークすべきである。中央ダッシュボードがそれらを集約するかもしれないが、基礎となる証拠はそれを生成したアクターに帰属し続けるべきである。

この実践はインセンティブを変える。レジストリは下流の影響が追跡可能になるため変更記録を改善する。バリデータは差異がレビュー可能になるため診断を改善する。オペレーターは拒否を説明する必要が生じうるためポリシーをテストする。保持者は自身の指示が可視のままであるため ROA を維持する。説明責任は、すべての参加者の上に新たな権限を設置することからではなく、リンクされた証拠から生じる。

測定は観測できるものとできないものを尊重しなければならない

展開に関する主張は、しばしば曖昧な分母によって弱められる。有効な ROA の数は認可の公開を測るものであり、Invalid 経路を拒否するネットワーク数を測るものではない。一つの実験的なアナウンスをフィルタするように見えるネットワークを数えることは、すべての顧客、ピア、地域に対するそれらのポリシーを確立するものではない。RPKI 機能を持つルーターベンダーを数えることは、オペレーターがそれを正しく有効にしたことを示さない。

有用な測定プログラムは少なくとも四つの量を分離する。第一は公開カバレッジである。検証済みペイロードによってカバーされるアドレス空間または経路プレフィックスで、重複する認可と最大長の明示的な扱いを伴う。第二はバリデータの可用性と一貫性である。選択された独立した検証当事者が、識別されたトラスト入力から同じペイロードセットを導出するかどうか。第三はルーターポリシーの展開である。観測されたネットワークが、制御された Valid、Invalid、NotFound アナウンスを拒否、低優先、または伝播するように見えるかどうか。第四は結果である。実際の認可イベント中にどのプレフィックスとパスが変更されたか。

RIPE RIS と RouteViews は、ボランティアのピアとコレクターを通じて広範だがサンプリングされた BGP 可視性を提供する。それらのアーカイブは前後分析をサポートできるが、すべての二国間パスや内部ポリシーを見るわけではない。アクティブな実験はテストされたパスに沿った扱いを明らかにできるが、経路伝播、商業的関係、パス変更が原因帰属を混乱させうる。オペレーターの証明は文脈を追加するが、実際のポリシーではなく意図されたポリシーを説明するかもしれない。

正しい対応は測定を放棄することではない。視点、時間枠、テストされた経路状態、確度、限界を公開することである。多様なコレクターからの反復観測は、正確なグローバルパーセンテージをでっち上げることなく、トレンドとインシデントを特定できる。証拠は「観測されず」と「拒否」を、「AS レベルの推論」と「ルーターレベルの設定」を区別すべきである。

修正監査にとって、測定はより狭く強力でありうる。関連するプロバイダはキャッシュとポリシー記録を公開でき、独立したバリデータはペイロード収束を示せ、経路コレクターは外部での再出現を示せ、エンドポイントプローブは到達性をテストできる。これは普遍的な修復を証明しないが、関係する当事者にとって運用チェーンを証明できる。

番号資源社会は共通の測定定義を維持し、再現可能なイベント研究を公開することができる。比較不可能な分母に基づくランキングに抵抗すべきである。目的は、権限と実装がどこで乖離するかを示すことであり、レジストリやオペレーターに単一の美点スコアを授与することではない。

限定された番号資源社会の役割が制度的ギャップを埋めうる

RIR の公開とルーターアクションの間のギャップは、諦念か中央集権化のいずれかを招く。諦念は、すべてのネットワークが自律的であるため、共通の説明責任は不可能だと言う。中央集権化は、一つの機関がすべての検証状態の扱いを指図すべきだと言う。どちらの答えも容易すぎる。

番号資源社会はより狭い位置を占めることができる。決定レシートフォーマットを定義し、レジストリの修正コミットメントを比較し、識別されたスナップショットに対してバリデータをテストし、キャッシュ対ルーターの回復演習を公開し、小規模オペレーターがベンダーの動作を解釈するのを支援できる。組織の境界を越える証拠をめぐって、保持者、RIR、トランジットプロバイダ、交換オペレーター、ベンダー、研究者を招集することができる。

エスカレーションディレクトリを運用することもできる。拒否に直面している保持者は、適切なレジストリ緊急連絡先、バリデータメンテナ、プロバイダのルーティングデスク、交換サービス所有者を見つけられるべきである。標準化されたケースフィールドは、プレフィックス、起点、ペイロード、タイミング証拠の繰り返しの翻訳を防ぐだろう。集約されたケースは、プライベートな顧客データを公開することなく、繰り返し発生する maxLength エラー、古いキャッシュのパターン、ポリシー順序の欠陥を明らかにできるかもしれない。

社会は、管理していないリソースについて代替 ROA に署名したり、運搬を強制したり、制度的好みで争われている権原を宣言したりすべきではない。自発的なベストプラクティスを隠れたグローバルルールに変えるべきではない。その正統性は、透明な方法、バランスの取れた代表、公表された限界、より迅速な修正の実用的価値から生じるだろう。

また、一回限りの質問票を通じてネットワークが「RPKI 準拠」であると認証すべきではない。保証はイベントベースであるべきだ。ネットワークはキャッシュの経過時間を示せるか？変更されたペイロードは安全な再評価をトリガーするか？顧客は理由付きの拒否通知を入手できるか？例外は期限切れになるか？二つのバリデータの不一致は説明可能か？レジストリの修正は報告された間隔内で外部から可視になるか？

これらのテストは自律性を保持しつつ、それを回答可能にする。RIR は認証責任を保持する。オペレーターはルーティング責任を保持する。ベンダーは実装責任を保持する。社会は、二国間関係が効率的に行うにはあまりに断片化されている場合に、共通の証拠とレビューを提供する。

このような機関にとっての積極的なケースは、交渉力が最も弱いネットワークにとって最も強い。大規模キャリアは自前のテレメトリーを構築し、レジストリエンジニアに直接電話できる。小規模な保持者や地域プロバイダは多くの場合できない。共有された手続きは、すべての遠隔ネットワークのポリシーを指図する権利があるかのように偽ることなく、彼らに信頼できる救済を与えることができる。

ガバナンス層は境界の地図であり、別のスイッチではない

RPKI 展開の成熟した見方は、プロモーション用の図がしばしば終わるところから始まる。署名オブジェクトがバリデータに到達し、ペイロードがルーターに到達し、状態がポリシーに到達し、ポリシーが商業関係とパケット経路に影響を与える。すべての矢印は技術的インタフェースであり、制度的な引き継ぎである。

中核となるルールは明確なままである。RIR とリソース保持者は認証された権限表明を公開する。バリデータは検証できる信頼データから何が導かれるかを決定する。ルーターは経路を分類し、設定された制御を実行する。ネットワークオペレーターは最終的な扱いを決定する。標準は、自動ポリシーが分類に密輸入されるのを意図的に防いでいる。

その分割は免責事項の連鎖になってはならない。発行者は発行と公開について答えなければならない。バリデータとキャッシュオペレーターは、忠実でタイムリーな計算と配布について答えなければならない。ベンダーは実装について答えなければならない。ネットワークはポリシー、例外、回復について答えなければならない。トランジットおよびピアリングサービスは、共有された制御が他者に影響を与える条件を説明しなければならない。

三つの改革がこの取り決めを統治可能にするだろう。第一に、オブジェクト変更をバリデータ、キャッシュ、ルーター状態に結びつける決定レシートを公開する。第二に、すべての制御された境界で執行可能な修正および異議申し立て手続きを提供する。第三に、展開数を運用上の証明の代用とするのではなく、宣言された視点でエンドツーエンドのイベントを測定する。

その結果はルーティングインシデントや権限をめぐる不一致を排除しないだろう。それはそれらを扱いやすくするだろう。影響を受けた保持者は、最初の誤った状態、それを修復できる機関、回復を検証するために必要な証拠を特定できるだろう。オペレーターは、Invalid ラベルが動機を証明すると偽ることなく、セキュリティ判断を擁護できるだろう。レジストリは、あらゆるルーティング選択の保険者になることなく、自らの行為に対する責任を受け入れることができるだろう。

したがって、欠けているガバナンス層は欠けているコードではない。それは欠けている可読性である。RPKI-to-router アーキテクチャはすでに最終的な選択を自律的なオペレーターに委ねている。2018年以降の制度的課題は、その自律性が緑、グレー、赤の検証状態の背後に隠れるのではなく、可視的で、理由付けられ、レビュー可能であり続けることを確実にすることである。

情報源

RFC 8481: Clarifications to BGP Origin Validation Based on RPKI— 2018年のルールを確立し、検証が状態を設定する一方でオペレーター設定がポリシーを制御することを定める。すべてのピアクラスやインシデントに対して一つの優先される扱いを規定するものではない。
RFC 8210: The RPKI to Router Protocol, Version 1— キャッシュ対ルーターセッション、シリアル更新、ペイロードアナウンスと撤回、転送オプション、リフレッシュ、再試行、期限切れパラメーターを定義する。商業的なルーティング義務ではなくデータ配信を規定する。
RFC 6811: BGP Prefix Origin Validation— Valid、Invalid、NotFound の比較を定義し、結果の使用をローカルポリシーとして扱う。不一致の背後にある動機を特定するものではない。
RFC 7115: Origin Validation Operation— 展開とルーティングポリシーガイダンスを提供し、トラフィックシフト、低優先度、より具体的な経路に関する警告を含む。運用上の前提の一部は以前の導入段階を反映しており、現在の展開数として読むべきではない。
RFC 9324: RPKI-Based Policy without Route Refresh— 展開で見られた有害なリフレッシュ動作を文書化し、影響を受けたパスを再評価のために保持することを推奨する。すべてのベンダーやネットワーク実装を測定するものではない。
RFC 8897: Requirements for RPKI Relying Parties— RPKI データの取得、検証、配布に関する要件を統合する。これは要件マップであり、現在のプライベートバリデータサービスの監査ではない。
RFC 8416: Simplified Local Internet Number Resource Management with the RPKI— 限定的な例外をサポートできるローカルフィルタとアサーションを定義する。そのようなローカル状態は他のオペレーターに対するグローバルな署名ビューを変更しない。
RFC 8211: Adverse Actions by a Certification Authority— 証明書とリポジトリアクションが保持者にどのように害を及ぼしうるか、ローカル制御がどのように影響を緩和しうるかを分析する。特定のレジストリアクションが法的に正当化されるかどうかを裁定するものではない。
Cisco: BGP RPKI with IOS XR 7 on Cisco 8000— 一つの製品ファミリーにおけるポリシーマッチ、低優先度、ベストパス処理、再評価の選択肢を示す。例はグローバルなオペレーター慣行を確立するものではない。
Cisco IOS XE: BGP Origin AS Validation— キャッシュ接続と検証状態に対する複数のポリシー結果を文書化する。製品コマンドは検証なしに他のリリースに一般化すべきではない。
Juniper Networks: Configuring RPKI— 状態マーキングと後の許可または拒否ポリシーを分離し、顧客、ピア、トランジットインポートへの配置を説明する。これは独立した測定研究ではなく運用ガイダンスである。
FRRouting BGP documentation— Valid、Invalid、NotFound 状態のオープンソースルートマップ処理とキャッシュテレメトリーを示す。動作はリリースとローカル設定に依存する。
RIPE RIS documentation— 分散 BGP 収集プラットフォームとその生データを説明する。コレクターの可視性はサンプリングであり、すべてのネットワークの処理を証明できない。
RouteViews API documentation— 参加コレクターからの現在およびアーカイブビューを説明する。コレクターでの不在は、それ自体が経路がグローバルに拒否されたことの証明ではない。
NRS Charter— 分散参加と集中した番号資源権力の制限に対する規範的サポートを提供する。ここで提案される保証、レシート、エスカレーション機能は推奨であり、普遍的な現在の展開の証拠ではない。