要約
- RPKI は、単に5つのメンバーポータルにおけるセキュリティ機能ではない。それはトラストシステムであり、認証局、リポジトリ公開、ROA 管理、バリデータ構成、TAL 配布、ホスト型サービス依存、委任型サービス可用性、レジストリガバナンスのすべてがルーティング依存要因となり得る。
- NRO RPKI プログラムは、5つの RIR すべてでより一貫性があり、統一的に安全で信頼性の高い RPKI サービスを目指すことを公然と表明しており、2025年の目標には透明性、堅牢性、セキュリティ、現在のトラストアンカー構成に関する懸念が含まれている。調整は有用だが、同時にレジリエンスは RIR ブランドの数ではなく、共有される障害ドメインによって測られなければならないことも意味する。
- 本格的な RPKI レジリエンス基準は、どの障害が独立しており、どれが共通であり、どれがレジストリから委任して回避でき、どれが緊急オペレーターサポートを必要とし、どれが証明書状態の変更がルーティング受容に影響を与える前に公開レビューを必要とするかを問うべきである。
ロゴの数はレジリエンス指標ではない
RPKI の公開マップは一見安心感を与える。5つの地域インターネットレジストリが存在する。各々が独自の地域、公開サイト、メンバーポータル、リソース認証ページ、トラストアンカー素材を持っている。NRO の RPKI コンテンツリポジトリは、AFRINIC、APNIC、ARIN、LACNIC、RIPE NCC の各々について、個別の RPKI ポータル、リソース認証ページ、トラストアンカーロケータ情報、認証業務規定へのリンクを掲載している。表面は、目に見えて複数存在するため分散しているように見える。
複数に見えることが独立したレジリエンスと等しいわけではない。5つの公開ブランドが、一つのガバナンス前提を共有することはありうる。5つのトラストアンカーが、共通のプログラム方向性を通じて収束することはありうる。5つのポータルが、類似のアカウント管理慣行、類似のホスト型サービスへの誘因、保持者権限に関する類似の法的解釈、類似の緊急時継続性への期待に依存することはありうる。5つのリポジトリが、同一のバリデータエコシステムによって消費され、同一の下流フィルタリング判断に流れ込むことはありうる。署名地点では地域的に見える障害も、オペレータが共通のツールと共通のルーティングポリシーを通じてその結果を取り込めば、依拠者地点ではグローバルなものになりうる。
これが、共同 RPKI トラストの根底にある中心的な問題である。RPKI は、経路起点の認可をより検証可能にするために設計された。番号資源を暗号証明書素材に結び付け、正当な保持者が自律システムにプレフィックスを生成することを認可できるようにする。これは、経路広報への緩い信頼や古い経路オブジェクトに対する大きな改善である。しかし、いったん経路受容が証明書状態に依存し始めると、その証明書状態のガバナンスがインターネットの制御表面の一部となる。問題はもはや、各 RIR にロゴとポータルがあるかどうかではない。問題は、どの障害がルータや経路フィルタが消費する証拠を削除し、陳腐化させ、誤表記し、あるいは遅延させうるかである。
NRO RPKI プログラムは、調整レイヤーを明示的にしている。それによれば、NRO は、堅牢で調整され安全な RPKI サービスに向けて取り組むことで合意しており、その目的は、より一貫性があり統一的に安全でレジリエントかつ信頼性の高いサービスを提供し、複数の RIR を通じて RPKI オブジェクトを作成するオペレータが経験する障壁を取り除くことである。これは理にかなった目標である。地域をまたがる資源を持つオペレータは、互換性のない5つのセキュリティ文化を学ぶ必要はないはずである。グローバルなルーティングセキュリティ層は、一貫性から恩恵を受ける。
しかし、一貫性はレジリエンスの問いも変える。サービスが意図的に均一化されるとき、観察者は、その均一性が誤りを減らすのか、それとも集中させるのかを問わねばならない。共通のベースラインは、脆弱なローカル慣行を排除できる。しかし、誤った前提を全地域に拡散させることもありうる。共通の文書セットは採用を容易にする。しかし、委任型サービス、緊急アクセス、アカウント復旧、ROA 失効、法的権限にとって重要な地域差を不明瞭にすることもありうる。共同プログラムはセキュリティを強化できる。また、運用言語で届くために、政策選択を技術的に見せかけることもできる。
したがって、正しい指標は障害ドメインであり、ロゴの数ではない。障害ドメインとは、共に障害を起こしうる構成要素、権限、前提、人、法的ルール、ソフトウェア依存関係、公開ポイント、レビュー経路の集合である。特定のリスクについて5つの機関が同じドメインを共有しているならば、それらを5つのレジリエンス単位と数えるのは誤解を招く。特定のリスクについて1つの機関が真に分離された2つのドメインを有するならば、それを1つと数えるのもまた誤解を招く。監査は、ページ上の紋章ではなく、決定と依存関係に従わなければならない。
RPKI はレジストリ権限をルーティング証拠に変える
RPKI は技術アーキテクチャとして始まるが、ガバナンスの外側に留まるわけではない。RFC 6480は、改善されたルーティングセキュリティを支援するインフラストラクチャを記述している。その基礎は、IP アドレスと AS 番号の割り当て階層を表現するリソース公開鍵基盤と、ルーティングセキュリティで使用される署名付きオブジェクトのための分散リポジトリである。これは、正当な保持者が、アドレス空間に対して経路を生成するために1つ以上の AS を認可する方法、およびそうした検証可能な認可が経路フィルタを支援する方法を記述している。
そのアーキテクチャはリソース割り当てに従う。IANA は割り当て階層の頂点に位置する。RIR は、定義された地域内でアドレスと AS 番号の割り当てを管理する。リソース証明書は保有を証明し、ROA は起点認可を提供する。証明書は装飾的な工芸品ではない。それは、RPKI 起点検証を使用するオペレータによって、ある経路が Valid、Invalid、NotFound のいずれと見なされるかに影響を与えうる表明である。かくして、レジストリ記録はルーティング証拠となる。
ガバナンス上の帰結は直接的である。レジストリが保有者のためにホスト型 RPKI サービスを管理するとき、それは単にウェブサイトの機能を維持しているのではない。保有者の経路起点証拠の一部を運用しているのである。レジストリが、移転、アカウント侵害、裁判所命令、支払不履行、制裁審査、保有者の死亡、企業合併、紛争、詐欺の疑いの後に証明書状態を変更するとき、その変更はレジストリのデスクからバリデータキャッシュ、経路フィルタへと移動しうる。ガバナンスとルーティングの間の距離は縮まる。
これは、RIR が RPKI 権限を避けるべきだという意味ではない。既存の割り当て構造が、RIR の関与を自然なものにしている。RFC 6480は、PKI 構造が既存のリソース割り当てに対応しており、管理はすでにリソース割り当てに責任を負う組織の自然な拡張であると述べている。また、リソース証明書は通常の公開 PKI の意味での個人や組織の身元を確認するものではなく、リソース保有を証明するものであるとも述べている。その境界は、いくらかの責任を軽減する一方で、別の問いを先鋭化させる。すなわち、証明書が表明する権限のあるレジストリ上の事実とは何か、である。
その答えは狭くあるべきである。リソース証明書は、リソース保有権限と関連する委任状態を表明すべきであり、保有者を取り巻くあらゆる商業的、政治的、道徳的問題に関するレジストリの見解を表明すべきではない。ROA は、認識されたリソース状態の範囲内で経路起点認可を表明すべきであり、根底にあるあらゆる紛争を解決すべきではない。RPKI リポジトリは、現在の暗号証拠を公開すべきであり、不透明な懲戒ツールになるべきではない。オペレータが出力に依存すればするほど、入力の権限を正確に保つことが重要になる。
障害ドメイン分析はここから始まる。レジストリガバナンスの障害は、レジストリが誤って失効させたり、公開に失敗したり、更新を拒否したり、移転引継ぎを遅延させたり、委任公開を誤って処理したり、アカウント管理を失ったり、保持者権限を読み誤ったり、共通のポリシー前提をあまりに広く適用したりする場合、RPKI 障害になりうる。バリデータの障害は、たとえレジストリが正しくてもルーティング障害になりうる。リポジトリ停止は、データ陳腐化障害になりうる。トラストアンカーの鍵更新は、グローバルな設定障害になりうる。法的紛争は、証明書状態の遅延になりうる。
これらのリスクは、RIR が5つあると言うだけでは解決されない。同じオペレータが5つすべてに依存しうる。同じバリデータが5つすべてを取得しうる。同じ主要ネットワークが5つすべてに基づいて経路フィルタを適用しうる。同じ NRO プログラムが5つすべてを共通の文書と機能へと推進しうる。システムは、ある面では分散しており、別の面では集中している。レジリエンスマップは、その両方を示さなければならない。
TAL は小さなファイルだが大きな制度的意味を持つ
トラストアンカーロケータは、隠れた集中の最も明らかな例の一つである。RFC 6490は、RPKI におけるトラストアンカーが自己署名の X.509 認証局証明書で表現されること、そして TAL がトラストアンカーの信頼性を取得し検証するために使用されるデータを指定することを説明している。TAL は、依拠者側ソフトウェアが使用する URI と公開鍵素材を含む。そのポイントは、公開鍵と場所が安定している限り、トラストアンカーに関連付けられたインターネット番号資源のセットが変化するたびにトラストアンカー自体を再配布することを避けることである。
その説明は技術的に聞こえるが、TAL は制度的な依存オブジェクトでもある。ある依拠者が TAL を設定することは、ある地域のリソース証明書についてどの権限を信頼するかを決定することである。TAL の場所が変わった場合、鍵が変わった場合、リポジトリが利用できない場合、CA 証明書が不適切に取り扱われた場合、鍵更新の伝達が不十分だった場合、あるいは危機が誰が変更を認可できるかについて疑問を提起した場合、問題は暗号技術だけではない。それはトラストガバナンスである。
NRO の RPKI コンテンツリポジトリは、各 RIR の TAL 情報を列挙することで、この依存性を可視化している。また、CPS 素材やサポート資源にもリンクしている。これは有用な透明性である。オペレータが必要な断片を見つけることを可能にする。しかし、より深いレジリエンスの問いには答えていない。誰が TAL をいつ変更すべきかを決めるのか？どれだけの予告が必要か？緊急オペレータがサービスを維持しなければならない場合はどうなるのか？現地の裁判所命令がトラストアンカー素材に影響を与えうるのか？競合する主張はどのように処理されるのか？レジストリが運用上は存続しているがガバナンスが機能不全の場合はどうなるのか？移行中、バリデータは古い素材と新しい素材をどのように扱うのか？
短命のトラストアンカー証明書、リポジトリ公開方式、委任型サービスのサポート、ホスト型サービスの設計は、すべてその全体像に影響を与える。NRO のコア RPKI サービスロードマップは、ホスト型サービスを5つの RIR すべてから利用可能とし、委任型サービスを APNIC、ARIN、LACNIC、RIPE NCC から提供し、2026年第1四半期末までに全 RIR を対象とすることを挙げている。また、API 管理目標、インタフェースと API を通じた ROA オブジェクト、そして APNIC、ARIN、LACNIC が提供し、2025年末までに全 RIR を目標とする短命 TA 証明書も挙げている。これらの機能格差と目標は、単なる製品ノートではなく、ガバナンス上の事実である。
すべての RIR が最終的に同じコア機能セットを提供すれば、いくつかの採用障壁は取り除かれる。複数地域の保持者はより良い内部統制を設計できる。依拠者の期待はより予測可能になる。文書は改善されうる。しかし、共通の目標日程が自動的に独立した障害ドメインを生み出すわけではない。トラストアンカーの鍵更新に関する同じ前提が至る所に埋め込まれれば、誤りが伝播しうる。すべての地域が類似したホスト型サービスのデフォルトを採用すれば、委任による自己依存は十分に活用されないかもしれない。すべての地域が用語を整合させても救済権を整合させなければ、オペレータは拒否をより良く理解できても、それに異議を唱えることができないかもしれない。
したがって、TAL は良いレジリエンステストである。設定された TAL の数を数え、次に、それらを保護する独立したガバナンス経路がいくつあるかを問う。リポジトリの数を数え、次に、依拠者が障害を異なって扱うかを問う。RIR ブランドの数を数え、次に、共通の NRO プログラムや共通の実装決定が、すべてのオペレータの期待を一度に変えうるかを問う。証明書の数を数え、次に、どの法的行為者が緊急時の継続性を認可できるかを問う。
答えはリスクによって異なる。リポジトリの可用性は、法的解釈よりも分散しているかもしれない。ポータルの多要素認証制御は地域固有かもしれない。バリデータの実装挙動はグローバルかもしれない。トラストアンカーの周知は部分的に調整されているかもしれない。緊急時継続性は十分に定義されていないかもしれない。重要なのは、それらのドメインを明示的にマップすることであり、複数のロゴが複数のレジリエンスと等しいと仮定しないことである。
ホスト型の利便性はオペレータ制御と同じではない
NRO の RPKI サービスに関するベースラインページは、ホスト型サービスが5つすべての RIR で利用可能であると報告している。ホスト型サービスは価値がある。なぜなら、多くのリソース保持者は委任型 RPKI を運用するためのスタッフ、時間、セキュリティエンジニアリングを欠いているからだ。小規模ネットワークは、使い慣れたレジストリポータルを通じて ROA を作成できる。より大規模なオペレータは、自身の CA を運用することなく経路起点証拠を管理できる。ホスト型サービスは採用を加速させ、採用が重要であるのは、十分な保持者が正しいオブジェクトを公開し、十分な数のネットワークがそれらを検証して初めて RPKI がルーティングセキュリティを改善するからである。
ガバナンス上の代償は依存である。ホスト型モードでは、レジストリのポータル、アカウント認証、認可モデル、変更ログ記録、サポートデスク、スタッフプロセス、停止対応、法的解釈が、保持者とその経路起点証拠の間に介在する。保持者のアカウントが侵害されれば、レジストリのプロセスが重要になる。移転が完了すれば、引継ぎプロセスが重要になる。緊急の maxLength 修正が必要になれば、サービスデスクが重要になる。制裁審査や法的検討がアカウントを凍結すれば、証明書状態は巻き添え被害になりうる。レジストリの危機がスタッフのアクセスや支払システムを混乱させれば、ホスト型 RPKI サービスはサービス継続性問題の一部となる。
委任型 RPKI はバランスを変える。保持者が、レジストリ発行の証明書の下で自身の CA または公開アレンジメントを運用することを可能にする。それはポータル依存を減らし、高度なオペレータにより直接的な制御を与えうる。しかし、委任型サービスはレジストリからの逃避ではない。親証明書、トラストアンカー、リソース認識、移転更新、ポリシー境界は依然として重要である。委任は、一部の運用障害ドメインをレジストリから遠ざける一方で、他のものはレジストリに留める。
NRO の RPKI サービス概要は、委任型サービスの可用性とハイブリッド公開の機能が均一ではないことを示している。ホスト型サービスは普遍的である。委任型サービスは、2025年12月時点の概要では4つの RIR に挙げられており、AFRINIC はそれを提供していないとマークされている。ハイブリッド公開サービスも様々である。API サポート、トランザクション履歴、経路コレクタ推奨、RPKI と IRR ソース間の整合性は様々である。これらの違いは重要である。なぜなら、どの障害が局所的で、どれが回避可能で、どれが親トラスト構造に内在するかをオペレータに伝えるからである。
したがって、レジリエンス監査は、すべてのリソース保持者に対して3つの問いを立てるべきである。第一に、今日何かが壊れた場合、保持者はレジストリスタッフなしで何ができるか？第二に、認証情報、支払状況、制裁審査、現地裁判所手続き、サポート待ち行列が問題となった場合、保持者はレジストリポータルなしで何ができるか？第三に、保持者がどれほど有能であろうとも、親レジストリのアクションなしでは何ができないか？
小規模なホスト型ユーザにとって、その答えは「ほぼすべてがレジストリインタフェースとサポートモデルに依存する」かもしれない。委任型オペレータにとっては、「日常的な ROA 公開は独立しているが、親証明書状態、リソース変更、移転引継ぎ、トラストアンカーイベントはレジストリ依存のままである」かもしれない。複数地域の保持者にとっては、RIR によって答えが異なりうる。下流のクラウドやトランジットプロバイダにとっては、保持者が文書化しない限り、答えは見えないかもしれない。
これが「5つの RIR が RPKI を提供している」では不十分な理由である。システムは広く利用可能でありながら、決定権においては集中していることがありうる。問うべきは、ある機能が存在するかどうかだけではない。ストレス時に誰がその機能を行使できるか、誰がそれを上書きできるか、誰がそれを復旧できるか、誰がそれを監査できるか、そしてレジストリとオペレータが対立するとき誰がコストを負うか、である。
調整は一貫性を向上させ、前提を集中させる
NRO RPKI プログラムは、その目標について率直である。2025年について、同プログラムは RPKI システムの透明性、堅牢性、セキュリティに焦点を当てたとしており、現在のトラストアンカー構成に関する懸念に対処する技術コミュニティとの協議のためのソリューションを含んでいる。また、統合された文書、標準化された用語、推奨されるベストプラクティス、RIR 間の RPKI インタフェースのギャップ分析、合意されたコア機能セットのロードマップを通じて、ユーザエクスペリエンスの一貫性を高めることを目指している。
これはまさに成熟した調整機関が行うべきことである。RPKI は、無関係な5つの製品文化に委ねるにはあまりに重要である。オペレータには明確さが必要である。バリデータには予測可能な挙動が必要である。複数地域の保持者には類似した概念が必要である。セキュリティ研究者には比較可能な成果物が必要である。混乱は設定ミスを増やし、設定ミスは正規の経路を無効にしうる。調整はそのリスクを低減できる。
集中リスクは「合意された」という言葉の中にある。合意されたコア機能セットは、最も弱い地域を強化できる。しかしまた、すべての地域に同じ盲点を継承させることもできる。合意されたベースラインが証明書停止後の不服申立権についてほとんど述べていなければ、すべての地域がその沈黙を通常のことと見なすかもしれない。合意されたベースラインが委任型の自律性よりもホスト型の利便性を優先すれば、採用は増加してもオペレータの制御は弱いままかもしれない。合意されたベースラインが透明性は向上させるが緊急時の権限は向上させなければ、危機は十分に文書化されても未解決のままかもしれない。合意されたベースラインが公開インシデント報告を標準化せずに用語のみ標準化すれば、オペレータは停止についてより一貫して語ることができても、より良い証拠は欠いたままかもしれない。
RPKI は、依拠者が自動化する傾向にあるため、共通の前提に特に敏感である。法的またはガバナンス上の誤りは、いったん証明書状態として表現されバリデータによって消費されると、すべての人間オペレータを個別に説得する必要はない。経路起点の結果はキャッシュ、ルータ、フィルタを通じて伝播しうる。この自動化こそが RPKI の目的であり、またガバナンスが正確でなければならない理由でもある。
正しい対応は、すべての RIR を異なるままに保つことではない。恣意的な差異もまた障害である。ある地域が委任型サービス、API アクセス、トランザクション履歴、信頼できるサポートを欠いているならば、オペレータは苦しむ。ある地域が混乱を招く用語を使っているならば、採用は苦しむ。ある地域が脆弱なセキュリティ管理をしているならば、システム全体の信頼性が低下する。正しい対応は、どの差異が有害で、どの差異がレジリエンスをもたらすかを分類することである。
有害な差異には、不明瞭な ROA 管理、脆弱な認証、欠落したトランザクション履歴、貧弱なリポジトリ可用性、不安定なサポート、maxLength に関する一貫性のないガイダンス、不明瞭な TAL 指示、ホスト型と委任型モードの可視性の低さが含まれる。レジリエンスの差異には、独立したインシデントレビュー、地域固有の法的保護措置、代替公開アレンジメント、委任型サービスを実行する能力、分離された運用チーム、多様なソフトウェアスタック、現地の不服申立経路、公開サービス指標、公開された引継ぎ計画が含まれる。
NRO は、第二のカテゴリーを消去することなく第一のカテゴリーを調整できる。すべての RIR に安全なベースラインを支持するよう要求しながら、異なる説明責任設計を許容できる。用語を整合させながら、現地の法的開示を保持できる。インシデント重大度ラベルを標準化しながら、各 RIR に独自の根本原因声明を公表するよう要求できる。すべてのオペレータを同一アーキテクチャに強制することなく、委任型サービスを推奨できる。トラストアンカー構成について協議しながら、各選択肢の障害ドメイン分析を公開できる。
「単一のグローバルな RPKI システム」という表現は、したがって慎重に扱われるべきである。ルーティングセキュリティ層は、効果においてはグローバルである。割り当て階層は、構造においてはグローバルである。依拠者エコシステムは、消費においてはグローバルである。しかし、システムが制御された多様性——独立した公開経路、独立したレビュー、独立した地域的理由、そして不必要なホスト型依存から離脱するオペレータの能力——を含むときに、レジリエンスは向上する。単一のグローバルシステムが、単一の疑いのないガバナンス前提を意味すべきではない。
測定されるべき障害ドメイン
第一の障害ドメインは権限である。誰が RPKI オブジェクトを作成し、失効させ、変更し、あるいは拒否する権利を持つのか？その答えには、リソース保持者、ポータルユーザ、法的代表者、レジストリスタッフ、スポンサー組織、NIR、移転相手方、裁判所任命の役員、緊急オペレータが含まれうる。これらの役割が混乱していれば、リスクは技術的なものではない。それは、技術的状態を通じて表現された権限の曖昧さである。
第二のドメインはアカウント制御である。ホスト型 RPKI はポータルに依存する。ポータルは認証情報、多要素認証、役割割当、スタッフサポート、復旧に依存する。NRO サービス概要は、RIR ポータル全体にわたる多要素認証機能を様々な方式と必須閾値とともに報告している。セキュリティ監査は、単に多要素認証が存在するかどうかを問うべきではない。誰がユーザを追加できるか、誰がある要素をリセットできるか、誰が役割を承認できるか、誰が侵害から復旧できるか、誰がトランザクションの証跡を見ることができるかを問うべきである。
第三のドメインは公開である。RPKI は証明書、ROA、マニフェスト、関連オブジェクトのためにリポジトリを使用する。リポジトリ障害、コンテンツの陳腐化、マニフェスト問題、RRDP や rsync の問題、バリデータの取得挙動はすべて、経路起点情報に影響を与えうる。このドメインは、単に RIR のデータセンターだけではない。コンテンツ配信、プロトコルサポート、監視、インシデント通知、依拠者キャッシュ挙動を含む。
第四のドメインはトラストアンカー構成である。TAL は安全に配布され、依拠者によって設定され、鍵や場所の変更を通じて維持されなければならない。あるトラストアンカーに関する懸念は、その TAL に依存するすべてのオペレータに影響を与えうる。複数の RIR が同じプログラムとスケジュールを通じてトラストアンカー変更を調整すれば、コミュニケーションは改善されるが、共通のタイミングリスクが現れる。まったく調整しなければ、依拠者は混乱に直面する。レジリエンス設計はそれらのリスクのバランスを取らなければならない。
第五のドメインはサービスモードである。ホスト型と委任型のアレンジメントは、レジストリと保持者に異なる責任を課す。成熟した監査は、単にオプションが存在するかどうかではなく、ホスト型サービス、委任型サービス、利用可能ならハイブリッド公開の下にある資源の割合を報告すべきである。大多数の保持者によって使われない機能は、効果的なレジリエンス層ではない。
第六のドメインは法的介入である。裁判所命令、制裁リスト、倒産、管財、合併、債権者請求、詐欺調査、政府の要求はすべて、証明書状態に圧力をかけうる。レジストリは、自ら検証できる事実と外部の裁定を必要とする事実を知らなければならない。また、可逆的な救済策も必要である：一時的保留、注記、狭い凍結、独立監査、緊急停止、証拠が不完全な場合の不可逆的な失効ではなく段階的な更新である。
第七のドメインは共通のプログラム方向性である。NRO プログラムが機能ロードマップ、用語、ベストプラクティス、対応姿勢を設定するならば、そのプログラムは前提に関する障害ドメインとなる。したがって、出力だけでなく、検討された代替案、却下された選択肢、リスクのトレードオフ、そして存在するならば異論のある技術的見解も公開すべきである。
第八のドメインはバリデータの挙動である。RIR は署名付き素材を公開するが、依拠者側ソフトウェアとオペレータのフィルタが、その素材がルーティングにどう影響するかを決定する。主要なバリデータがエッジケースを異なって解釈すれば、同じリポジトリ状態が異なる運用結果を生みうる。主要ネットワークが一つの実装に収束すれば、ソフトウェア多様性は縮小する。ルートサーバが局所的な方法で RPKI フィルタリングを適用すれば、その効果は Tier-1 フィルタリングとは異なる。これらの下流ドメインは RIR のロゴの外側にあるが、現実のレジリエンスを形作る。
第九のドメインは緊急時継続性である。2025年の RIR ガバナンス文書草案は、緊急時継続性と緊急オペレータの概念を定義しており、NRO 安定化基金は深刻な混乱に対する相互支援を記述している。RPKI 継続性は、あらゆる緊急時計画の一部であるべきである。何が継続され、何が凍結され、誰が署名でき、誰が公開でき、古いオブジェクトがどのように扱われ、権限がどのように通常に戻るのかが公に知られるべきである。
最後のドメインは公開証拠である。オペレータが必要とするのは安心感ではなく、証拠である。サービス可用性指標、リポジトリ健全性、インシデント報告、TAL 変更通知、トランザクション履歴、サポート応答時間、委任型サービス採用状況、不服申立結果、緊急時訓練は、市場がレジリエンスを価格付けできる程度に十分に可視化されるべきである。証拠がなければ、5つのロゴは芝居になる。
ガバナンスが証明書状態になるとき何が起こるか
移転を考えてみよう。売り手は ROA を持っている。買い手は経路起点認可を必要とする。レジストリは移転を認識し、資源レコードを更新し、継続性を保ち、古い ROA が長く残り過ぎるのを避けなければならない。移転が通常のものであれば、プロセスは管理上のものである。しかし、移転が争われている、融資を受けている、国境を越えている、裁判所の影響下にある、制裁審査を受ける、あるいは文書によって遅延している場合、RPKI 状態はリスク表面となる。古い認可が長く生き残りすぎることがある。新しい認可が遅れすぎることがある。maxLength の誤りが、正規のより詳細な経路を無効にすることがある。サポート遅延が顧客停止を生むことがある。
次に、企業承継を考えてみよう。旧来の保持者が名称を変更する、合併する、あるいは関連会社に解散する。レジストリは誰が行動できるかを特定しなければならない。ポータルユーザは依然として認証情報を持っているが権限を持たないかもしれない。取締役は権限を持っているがポータルアクセスを持たないかもしれない。銀行は証拠を要求するかもしれない。裁判所が命令を出すかもしれない。ホスト型 RPKI サービスは、これらの役割が衝突する場になりうる。証明書状態は、権限が明確になるまで動くべきではないが、無期限の遅延はルーティングを害しうる。救済策は、広範な裁量ではない。それは、一時的な継続性を備えた証拠の階梯である。
レジストリの危機を考えてみよう。レジストリが正常に運用できなければ、RPKI の問いが直ちに生じる。既存の証明書は有効であり続けられるか？誰がリポジトリの鮮度を監視するのか？誰が緊急の ROA 修正要求に応答するのか？誰が通常サービスを凍結することなく危険な変更を停止できるのか？誰が依拠者とコミュニケーションを行うのか？緊急オペレータは署名権限、公開権限、あるいはサポート権限のみを持つのか？鍵はどのように保護されるのか？返還はどのように監査されるのか？
NRO のライフサイクルガバナンス草案は、RIR の運用と潜在的な認定取消には参入基準以上のものが必要であることを認識しているという点で、妥当性がある。しかし、RPKI にはさらに詳細な継続性付属書が必要である。レジストリは、一般に承認されていながら、一時的な RPKI 署名問題を抱えることがある。レジストリは、RPKI を稼働させていながら、メンバーの信頼を欠くことがある。認定取消の提案には時間がかかる一方、ルーティング証拠は日々維持されなければならない。証明書層は、制度論が決着するのを待ってはくれない。
制裁と法的制約についても同じことが言える。レジストリは適用法を遵守する必要があるかもしれない。制裁対象者へのサービス提供を阻止する必要があるかもしれない。詐欺を助長することを避ける必要があるかもしれない。しかし、法的保留は正確であるべきである。既存の ROA が維持されるのか、新たな ROA がブロックされるのか、失効が必要か、委任公開が継続されるのか、裁判所または規制当局が判断を下しているのか、影響を受けないプレフィックスは継続するのか、保持者にレビュー経路があるのかを明示すべきである。さもなければ、証明書状態は隠れた執行になる。
ガバナンス基準は、最も破壊的でないルーティング証拠であるべきである。事実が不確かなときは、可能ならば最後に知られた安全な状態を保持する。経路認可が明らかに無許可のときは、それを修正する。権限が争われているときは、影響を受けないサービスを壊すのではなく、争点となっているアクションに印を付け、一時停止する。法的強制が存在するときは、機密性が許す限り狭く、そのサービス上の帰結を記述する。レジストリの誤りが発生したときは、訂正とタイムラインを公開する。緊急アクションが取られたときは、即時のセキュリティが別段の要求をするのでない限り、それを可逆的にする。
この基準は RPKI を弱めない。証明書状態を信用できるものにすることで、依拠を強化するだろう。オペレータは完全な安心を必要としているのではない。彼らは、ある有効性変更がルーティング認可、データ陳腐化、法的制約、アカウント侵害、移転タイミング、レジストリ停止、ガバナンス危機のいずれを反映しているのかを知る必要がある。それらは異なる事実であり、異なる救済策を伴う。
共同トラストには独立した証明が必要である
NRO の調整の役割は、共通基準の中で独立した証明を要求するならば、より強力な RPKI システムを生み出しうる。共有ベースラインは、すべての RIR がホスト型サービスを提供していると言うだけでは足りない。比較可能なサービス指標を公開すべきである：リポジトリ可用性、更新レイテンシ、インシデント件数、サポート応答時間、TAL 変更の告知期間、トランザクション履歴可用性、委任型サービス採用状況、緊急時訓練、根本原因の公開である。比較可能な証拠があれば、オペレータはレジリエンスがどこで現実で、どこで願望的かを知ることができる。
ベースラインはまた、障害ドメインマップを公開すべきである。各 RIR について、マップは、ホスト型ポータル、委任経路、リポジトリ公開、TAL 管理、CPS、アカウント復旧、移転引継ぎ、法的保留、緊急オペレータ、サポートエスカレーション、公開インシデントチャネルを示すべきである。NRO プログラム全体としては、マップは、どの決定が共同的で、どれが地域的で、どれが ICANN を必要とし、どれが IANA に関わり、どれが RFC 定義の挙動に依存し、どれが民間オペレータの展開に依存するかを示すべきである。
独立レビューがマップの一部であるべきである。リソース保持者が、ROA 変更が誤って拒否されたと言うならば、誰がレビューするのか？委任公開ポイントが誤分類されたならば、誰がレビューするのか？移転引継ぎが古い認可を残したならば、誰がレビューするのか？レジストリが法的制約を発動したならば、影響を受けた保持者は、サービスの帰結に異議を唱えるのに十分な情報を見ることができるのか？共通の NRO RPKI 慣行が害を及ぼしたならば、その共通慣行に異議を唱える経路があるのか、それとも5つのローカルサポートチケットしかないのか？
レビュー機関は裁判所である必要はない。多くの問題は技術的であり、時間的制約がある。第一のレビュー者は内部のエスカレーションチームでありうる。第二は独立した技術パネルでありうる。第三は、問題が権限や公正さに関わる場合の制度的な不服申立でありうる。裁判所は、法的権利、詐欺、企業権限または法的強制に関しては依然として関わりがある。ポイントは、自動化されたルーティング証拠が、紛争が暗号構文ではなくレジストリ権限に関するときに、人間による異議申立可能性を奪うべきではないということである。
異論も可視化されるべきである。ある RIR が、提案された共通 RPKI ベースラインが自地域で法的リスクを生じさせると考えるならば、その異論は理由とともに公表されるべきである。ある RIR が現地法のために機能を実装できないならば、そのギャップは明示されるべきである。ある RIR が、より強力な委任型サービス自律性や不服申立権でベースラインを上回っているならば、その改善は地域文書の中に隠されるべきではない。共同トラストは、オペレータがバリエーションを見て判断できるとき、より強くなる。
セキュリティエンジニアは時として、過度のガバナンス議論が展開を遅らせることを懸念する。そのリスクは現実である。RPKI の採用にはすでに数年を要しており、経路漏洩やハイジャックは依然として運用上の脅威である。しかし、隠れたガバナンスリスクもまた採用を遅らせる。オペレータは、一方的な証明書の誤り、不明瞭な失効、ホスト型保管、脆弱な復旧、法的テイクダウンを恐れるときに、躊躇する。より明確な障害ドメインモデルは、何が制御され、何がリスクとして残るのかを示すので、採用を増加させうる。
したがって、NRO プログラムにとって最善の主張は「我々を信頼せよ、5つの RIR はすべて合意している」ではない。「これが共通ベースラインであり、これが独立ドメインであり、これが既知のギャップであり、これが不服申立経路であり、これが緊急時計画であり、これが証拠である」である。これは、トラストを検証可能なものとして扱うため、より強力なセキュリティメッセージとなる。
レジリエンスは表明ではなく訓練でテストされるべきである
RPKI 継続性には訓練が必要である。訓練は、信頼を向上させるのに十分なほど公開され、鍵と攻撃面を保護するのに十分なほど非公開であるべきである。トラストアンカー周知訓練は、依拠者が通知を受け取り、タイミングを理解し、バリデータを安全に更新するかどうかをテストできる。リポジトリ停止訓練は、陳腐化キャッシュの挙動とオペレータへのメッセージングをテストできる。ホスト型ポータル侵害訓練は、アカウント凍結、トランザクションレビュー、保持者通知をテストできる。移転引継ぎ訓練は、古い ROA のクリーンアップと新しい ROA のタイミングをテストできる。委任型サービス障害訓練は、不必要な制御を奪うことなく親の調整をテストできる。
緊急レジストリ訓練は特に重要である。レジストリが重要なスタッフを失った場合、支払不能に直面した場合、理事会権限を失った場合、裁判所が任命した管理人のシナリオに陥った場合、あるいはそのポータルを運用できなくなった場合、何が起こるかを問うべきである。共同 RIR 安定化基金は、財政的苦境、重要スタッフの喪失、自然災害、政治的不安定、犯罪行為、構造的インフラ問題といったシナリオを認識している。RPKI は、そのようないかなる事象においても、指定されたサービスであるべきである。訓練は、誰が既存素材を有効に保つことができるか、誰が緊急告知を公開できるか、誰が緊急のセキュリティ修正を処理できるか、そして、権限が回復されるまでどのアクションが凍結されるかを特定すべきである。
成果物は、機密性の高い鍵取扱詳細を明らかにすべきではない。サービスクラスを明らかにすべきである。例えば：既存のリポジトリ公開は継続される；認証された保持者は新規 ROA を作成できる；高リスクのアカウント復旧には二重承認が必要である；移転関連の証明書変更は緊急レビューの下で処理される；争われている法的変更は一時停止される；影響を受けないリソースは継続する；公開更新は定められた周期で現れる。こうした表明は、レジリエンスを保証から運用上の約束へと変える。
訓練には複数 RIR の保持者も含めるべきである。複数地域にリソースを持つ企業は、異なるポータル制御、委任オプション、サポート時間、法的要件に直面しうる。グローバルインシデントは、複数地域での変更を必要としうる。NRO プログラムが、複数の RIR を通じて RPKI オブジェクトを作成するオペレータの障壁を取り除きたいならば、複数地域緊急ユーザジャーニーをテストすべきである。
依拠者も訓練の一部であるべきである。RPKI は、バリデータとネットワークがデータを消費するまでは完結しない。レジストリが正しく公開していても、バリデータのキャッシュが不適切である、エッジケースを誤解する、あるいはオペレータへの警告に失敗する場合がある。訓練には、主要なバリデータ実装、ルートサーバ、トランジットプロバイダ、交換ポイント、大規模クラウドネットワークを適宜関与させるべきである。NRO はそれらを統制しないが、コミュニケーションを調整し、教訓を公開することはできる。
監査は虚栄の指標を退けるべきである。ROA の数は有用だが不完全である。カバーされる経路プレフィックスの割合は有用だが不完全である。ある機能を提供する RIR の数は有用だが不完全である。レジリエンスには、検出時間、修正時間、データ陳腐化挙動、サポート経路、保持者の異議申立可能性、委任フォールバック、インシデント透明性、緊急権限が必要である。
最も深刻な指標は爆発半径である。一つのレジストリが誤った RPKI 決定を下した場合、その影響はどこまで及ぶのか？一つの NRO ベースラインに欠陥のある前提が含まれていた場合、いくつの地域がそれを継承するのか？一つのバリデータの挙動が誤っている場合、いくつのネットワークがそれを適用するのか？一つのトラストアンカー周知が失敗した場合、いくつの依拠者が影響を受けるのか？一つの法理論が証明書変更を凍結した場合、いくつのプレフィックスが運用上の柔軟性を失うのか？爆発半径の問いに答えられないシステムは、十分にレジリエントではない。
公共はトラストモデルを推測する必要があってはならない
RPKI トラストは公共の言語で説明されるべきである。すべてのオペレータが PKI 専門家ではない。すべての弁護士が ROA を理解しているわけではない。すべての裁判所がバリデータを理解しているわけではない。すべてのメンバー理事会がホスト型サービスと委任型サービスの違いを知っているわけではない。成熟したレジストリシステムは、過度に単純化することなくトラストモデルを読みやすくすべきである。
NRO のベースライン文書は良い出発点である。それらはサービスモード、オブジェクトサポート、API、認証、および関連機能を比較している。コンテンツリポジトリはポータル、TAL 情報、CPS 文書にリンクしている。プログラムページは一貫性が目的である理由を説明している。ロードマップは目標日程を挙げている。これらの資料はシステムを調査しやすくしている。
欠けている層はガバナンスの翻訳である。各 RIR は、以下の問いに答える短い公開文書を公表すべきである：当社の RPKI 証明書は何を証明するのか；何を証明しないのか；誰が変更を要求できるのか；役割はどのように検証されるのか；移転をどのように扱うのか；紛争をどのように扱うのか；アカウント侵害をどのように扱うのか；法的制約の間に何が起こるのか；レジストリ緊急時に何が起こるのか；保持者はどのように緊急レビューを得られるのか；依拠者はどのようにリポジトリや TAL の問題を報告できるのか；ホスト型サービスと委任型サービスは制御においてどう異なるのか。
この翻訳は法的な過大主張を避けるべきである。証明書は、認識されたリソース保有状態と認可関係の証明であり、万能の身分証明書ではない。ROA は経路起点認可であり、完全なセキュリティ保証ではない。Valid な経路起点結果は、その経路が安全であることを意味しない。Invalid な結果は、攻撃だけでなく設定ミスからも生じうる。RPKI はルーティング証拠を改善するが、運用の判断を廃止するものではない。
公の説明は制度的な過小主張も避けるべきである。レジストリの行為が経路起点の有効性に影響を与えうるならば、レジストリはそう述べるべきである。サポート遅延がルーティングに影響を与えうるならば、そう述べるべきである。委任型サービスがいくつかの依存を減らすが親トラスト依存は減らさないならば、そう述べるべきである。TAL の変更が依拠者の注意を必要とするならば、そう述べるべきである。限界が見えるとき、ユーザは機関をより信頼する。
言葉は一貫しているが空疎であってはならない。「堅牢で、調整され、安全な」はミッションステートメントである。オペレータが必要とするのは、その背後にある名詞である：鍵、TAL、リポジトリ、ROA、マニフェスト、アカウント、役割、ログ、インシデント、不服申立、緊急連絡先、返還、監査。これらの名詞が決定に結びつくとき、ガバナンスは信頼できるものになる。
NRO プログラムのためのより良い基準
NRO は RPKI の調整を続けるべきである。代替案はより悪い：不均一な5つのサービス、回避可能な混乱、より弱いセキュリティ管理、より困難な複数地域採用。しかし、調整は機能の整合性よりも高い基準で判断されるべきである。プログラムは障害ドメイン登録簿を公開すべきである。
登録簿は、コアとなる各 RPKI 機能を列挙し、その独立性を分類する。ホスト型 ROA 作成：地域ポータル＋共通ベースライン。委任型サービス：親トラスト付きの地域可用性。トラストアンカー構成：共同協議リスク付きの地域 TAL。リポジトリ公開：依拠者のグローバル消費を伴う地域インフラ。API 管理：共通機能目標付きの地域実装。インシデント報告：共通重大度用語付きの地域的義務。緊急時継続性：地域権限付きの共同支援。法的制約：グローバルなルーティング帰結付きの地域法。バリデータコミュニケーション：RIR の制御外の共有エコシステム。
各機能について、登録簿は、主要な障害、二次的依存関係、保持者による緩和、依拠者による緩和、公開指標、レビュー経路を明示すべきである。これにより、レジリエンスはテスト可能になる。また、共通基準がどこでリスクを低減し、どこでリスクを集中させるかを示すだろう。
プログラムは共通のインシデント分類学も公開すべきである。リポジトリ停止はポータル停止と同じではない。TAL 通知の失敗は誤った ROA と同じではない。陳腐化した移転 ROA はアカウント侵害と同じではない。法的保留は技術的障害と同じではない。オペレータはこれらの区別を必要とする。なぜなら、修復方法が異なるからである。
最後に、プログラムは独立した地域証明を保護すべきである。各 RIR は、独自の CPS、インシデント履歴、サービス指標、委任型採用状況、サポートコミットメント、現地法的制約を公開すべきである。NRO は、消去することなく集約すべきである。5つの RIR の目的は、5つの紋章を見せることではない。それは、障害、学習、改革がすべて一つの閉ざされた部屋で起こらないよう、十分な地域的独立性を保持することである。
情報源と限界
本分析は、RPKI アーキテクチャについては RFC 6480、トラストアンカーロケータ構造については RFC 6490、共同プログラムの目的については NRO RPKI プログラムページ、RIR 横断機能については NRO 共同 RPKI ベースライン文書およびサービス概要、TAL および CPS の参照については NRO RPKI コンテンツリポジトリ、目標機能の整合については NRO ロードマップに依拠している。また、緊急時継続性と承認の文脈を枠づけるためにのみ、NRO ガバナンス資料を使用している。これらの情報源は、RPKI が5つの RIR にわたって調整されており、サービス機能にばらつきがあるという主張を支持する。これらは、実際の共通停止、隠されたトラストアンカー決定、または違法な集中を証明するものではない。この議論はレジリエンス基準である。すなわち、ロゴではなく障害ドメインを数えることである。