要約
- 経路オリジン認証(ROA)は単独の宣言ではない。ROA は、RIR のトラストアンカーを起点とする有効な証明書パスを通じてのみ受け入れられる。親 CA は、オペレーターの ROA が署名される下位の証明書を発行、置換、縮小、失効させることができる。
- 登録と認証は意図的に連携されている。これにより暗号学的表明が現在のリソースレコードを反映するが、移行判断、契約ステータスエラー、裁判所命令、アカウント操作が、依存パーティから見える経路認証の集合を変化させうることも意味する。
- 失効はグローバルルーティングテーブルへの指令ではない。失われた ROA はアナウンスを NotFound にし、変更されたり競合する認証は Invalid にする可能性がある。そして各ネットワークが独自のルーティングポリシーを適用する。影響は分散的で可変的、かつ深刻になりうる。
- RIPE NCC による2020年12月のレガシーリソースインシデントは伝播メカニズムを示した。契約ステータスのエラーが証明書を縮小し、ホスト型 ROA を削除し、委任型 ROA の消失や過大請求を引き起こした。これは実際の制御経路の証拠であり、普遍的な故障率の証拠ではない。
- 委任型 RPKI は、オペレーターに自身の署名鍵と子 CA の運用制御を与える。しかし RIR の親 CA を除去するものではない。親 CA は依然として認証リソースセットを決定し、規定の条件下で子証明書を失効させることができる。
- より強固なガバナンスには、将来的な失効根拠、リスクベースの通知、機械可読な変更プレビュー、メイクビフォアブレイクの移行計画、緊急復旧、書面による理由、独立した審査、公開インシデント会計が含まれるべきである。免責条項が予防と救済の代わりになるべきではない。
- Number Resource Society は、親 CA のルールを比較し、継続性チェックリストを公開し、技術政策議論において小規模ホルダーを代表することで建設的に貢献できる。ただし、そのアドボカシー自体が証明書権限を与えたり、代替のトラスト構造を証明するものではない。
決定的なパケットはレジストリから遠く離れて評価される
オペレーターの自律システムからの通常のプレフィックスアナウンスを考えてみよう。オペレーターは BGP を正しく設定している。そのトランジットプロバイダーは経路を受信する。しかし別の場所で、依存パーティのバリデーターが RPKI 資料を取得し、検証済み経路オリジン認証のセットを構築し、結果のペイロードをルーターに渡している。それらのルーターはプレフィックスとオリジン AS をペイロードセットと比較する。アナウンスは Valid、Invalid、NotFound のいずれかになる。その後、各ネットワークが独自のポリシーを適用する。
レジストリはパケット経路に存在しない。すべてのルーターから経路を引き抜くボタンを押すわけでもない。しかし、その分散的な決定に使用される暗号学的証拠の上位に位置する。オペレーターの ROA への証明書パスが検証されなくなると、その ROA は有効なペイロードを提供しなくなる。他のカバーする認証が残っていれば、経路は Invalid になる可能性がある。何も残らなければ、通常は NotFound になる。Invalid 経路を拒否するネットワークはアナウンスを拒絶し、NotFound 経路を受け入れるネットワークはそれを運び続けるかもしれない。
この一連の流れが重要なメカニズムである。管理イベントは親 CA で発生する。リポジトリが変更されたオブジェクトを配布する。バリデーターがローカルビューを更新する。ルーターが新しい検証データを受信する。独立したネットワークポリシーがそのデータを到達性の結果に変換する。
このチェーンにおけるギャップとキャッシュは重要である。異なるバリデーターが異なるタイミングでリフレッシュする。オペレーターはリポジトリに問題がある間データを保持できる。ルーターポリシーは均一ではない。一つの証明書イベントがプレフィックスをあらゆる場所で瞬時に切断すると主張する正直な根拠はない。同様に、失効を無害な事務的編集として扱う根拠もほとんどない。このアーキテクチャは、暗号学的ステータスがルーティングに影響を与えるように設計された。ガバナンスはその影響を真剣に受け止めつつ、その均一性を誇張すべきではない。
オペレーターの署名は条件的である
RPKI の魅力的なストーリーはホルダー制御である。アドレス保持者は ROA を作成することでオリジン AS を認可する。暗号によって他者は、その表明が認証されたリソースに関連付けられた鍵から来たことを検証できる。これは、BGP アナウンスがオリジンが認可されていることの証明を内蔵していないルーティングシステムへの貴重な修正である。
しかし、ホルダーの鍵は主権的ではない。RFC 6480は、インターネット番号資源の割り振りに合わせた階層を記述している。リソース証明書は公開鍵を IP アドレスブロックと AS 番号に結び付ける。署名されたオブジェクトの有効性は、選択されたトラストアンカーへの証明書パス、証明書の有効性、失効情報、各レベルで許可されたリソースに依存する。
委任型 CA を使用するオペレーターは、その子の秘密鍵を制御する。親はその鍵を使って子の署名を偽造することはできない。この区別は重要である。これはオペレーター自身の署名行為の完全性を保護し、ローカルな自動化、サブ委任、鍵管理の選択を可能にする。
親は異なる力を保持する。子証明書を発行し、置換証明書の対象リソースを変更し、または証明書を失効リストに載せることができる。有効な親パスによって裏付けられなくなったリソースに対する子の署名は、数学的主張によって自らを有効にすることはできない。親は、子の表明を無効にするために子鍵を所有する必要はない。
ホスト型 RPKI はこの区別をさらに圧縮する。RIR はホルダーの CA を運用し、秘密鍵を自らのインフラに保存する。ホルダーはポータルやインターフェースを通じてルーティングの意図を選択し、サービスが署名、更新、公開を実行する。結果として得られる ROA は正確にホルダーの指示を表すかもしれないが、暗号管理権限と親権限は同一機関内に存在する。したがって、利便性は技術的作業量だけでなく、制御の配分も変化させる。
登録の真実が暗号学的範囲になる
RPKI は偶然に RIR レコードに結び付けられたわけではない。その中心的な約束は、証明書が番号資源の現在の委任を反映することである。APNIC の認証実践声明は、この取り決めを明確に説明する。証明書を発行する組織は、同時に委任を行う組織でもあり、したがってその結合について権威を持つ。RIPE NCC の文書は、その資源証明書が登録組織にリンクされ、資源が追加、返却、移動、移転されると自動的に変更されると述べている。
この連携により、正当な移行後に旧ホルダーが古い証明書に無期限に依存することが防止される。受領者は新たな認証を確立でき、依存パーティは古い要求を拒否できる。範囲を更新できる親がなければ、RPKI は現在の登録を犠牲にして古いルーティング意図を保護することになる。
同じ連携が管理レコードに第二の人生を与える。レジストリシステムにおける名前、ステータス、契約関係は、単に誰がサービスを受けるか、RDAP に何が表示されるかを答えるために使われるだけではない。それはどのプレフィックスがリソース証明書に入るかを決定しうる。その証明書がどの署名オブジェクトを検証できるかを決定する。登録からルーティング証拠への経路は意図的なものである。
ガバナンスの問いは、その経路を切断すべきか否かではない。そうすることは資源認証の目的を無にする。経路が始まる場所で誤りと裁量行動をいかに抑制するかである。完了した移行後にリソースが削除された場合、旧ホルダーの認証は停止すべきである。一時的なアカウント不一致、争われている請求書、誤った法的分類が適切な保護策なしに同じ結果を生む場合、セキュリティメカニズムは管理上の欠陥をより重大な層に持ち込んでいる。
正確な修正と性急な執行の区別は、失効の前になされるべきである。暗号は、親が新しい証明書に署名したか、古い証明書を CRL に載せたかを示せる。スタッフが合併を正しく解釈したか、通知が適切な役員に届いたか、制裁マッチが健全か、争われている移行が即時の効果に値したかどうかは示せない。これらは署名行為を取り巻く制度的な問いである。
失効は一つの結果ではない
失効という言葉は単一のスイッチを連想させる。ルーティング結果はより条件的である。RFC 6811は三つの経路オリジン検証状態を定義する。カバーする有効なペイロードがない場合、経路は NotFound である。少なくとも一つのペイロードが経路をカバーし一致する場合、Valid である。少なくとも一つのペイロードがカバーするが、どれも一致しない場合、Invalid である。
仮にホルダーがプレフィックスに対して一つの正確な ROA を持っており、証明書パスが消失したとする。バリデーターがその ROA の受け入れを停止すると、カバーするペイロードが残らないかもしれない。すると経路は Valid から NotFound に移行する。多くのネットワークは NotFound を受け入れる。なぜなら RPKI の展開は不完全で、未認証の経路すべてを拒否することは依然として破壊的だからである。直ちに影響するのは、したがって到達性の喪失ではなく、検証保護の喪失かもしれない。
今度は、より広範な有効な ROA が別の CA の下に残っているか、または異なるオリジンや最大長でプレフィックスをカバーする置換認証が存在すると仮定する。経路は Invalid になりうる。Invalid 経路を拒否するネットワークはそれをドロップするかもしれない。他は優先度を下げ、監視用にタグ付けするか、受け入れるかもしれない。RFC 7115は最終的なポリシーをローカルにする。検証ステータスはルーティングに情報を与えるが、一つの普遍的な応答を指示するものではない。
この変動性は安心の理由にはならない。経路は、害が重大であるために至る所で消える必要はない。大規模トランジットプロバイダー、クラウドネットワーク、公共セクターピア、コンテンツプラットフォームによる選択的拒否は、アクセスを断片化しうる。NotFound になったプレフィックスは、顧客が依存する保証を失う。オペレーターは、キャッシュが異なる速度で収束する中で、新しい証明書の下で ROA を緊急に再作成する必要性にも直面しうる。
したがってガバナンスの言葉は二つの誤りを避けるべきである。RIR がすべての経路を直接制御していると言うべきではない。また、証明書の変更はオプションのセキュリティラベルにのみ影響すると主張すべきでもない。親は多くの自律ネットワークにわたって行われる意思決定への入力を制御する。最終的な行動の分散性は、親の注意義務も事業者の継続性計画の必要性も減じるものではない。
設計選択は大量の運用利用の前に現れた
現代の取り決めは数年にわたり形作られた。RIR と IETF による作業は、主要な RPKI アーキテクチャ文書の2012年公開に先立つ。2008-08という番号の RIPE 政策提案は、証明書が登録された資源をいかに反映すべきか議論し、証明書は常に登録ステータスを反映すると述べたが、その提案は後に撤回された。APNIC は2009年にすでにリソース認証の作業を報告していた。これらは単に優れた暗号についての議論ではなかった。どの機関がリソース制御を証明するかに関するものだった。
商用サービスは2011年頃に登場した。RIPE NCC は同年初めにホスト型リソース認証サービスを開始した。当初は限定的な機能セットで、その発表はこのサービスをレジストリをより堅牢にし、ルーティングをより安全にする方法と位置付けた。2011年後半には、事業者が RIPE NCC を親として独自の CA を運用できるローカル認証の概念実証を提供した。LACNIC は2011年1月からのホスト型サービスと、2019年12月からの委任型サービスを記録している。地域ごとにタイミングと能力は異なった。
2012年に公開されたコア IETF 文書は、機能を紙の上で明確に分離した。RFC 6480はアーキテクチャを記述し、RFC 6482は ROA を規定し、RFC 6483は経路オリジン検証を説明し、RFC 6492は子 CA が証明書を要求し親が発行・失効するための交換を規定した。その後の作業は公開プロトコルを追加し、CA の有害行動を分析した。
制度的な決着は実利的だった。RIR はすでにリソースレコードを維持し、ホルダーを認証し、一意性を調整していた。それらをリソース証明書の上位に置くことで、無関係なグローバルな権原機関の創設を回避した。ホスト型サービスは、CA やリポジトリを運用したくない事業者の参入コストを引き下げた。委任は、より強力な鍵制御を必要とする組織のための経路を温存した。
この決着は賞賛に値する。同時に定期的な憲法的レビューにも値する。オプションのセキュリティサービスとして始まった機能が、今やより多くのネットワークと自動化されたシステムによって消費される証拠を供給している。依存が高まるにつれ、実験のために書かれたサービス条件は、誤りが到達性を変えうるインフラストラクチャには不十分になりうる。関連するテストは、元の設計が悪意を持っていたかどうかではない。運用上の結果とともにガバナンスが成熟したかどうかである。
親 CA は単なる技術的中継ではない
RFC 6492は、リソースの一覧表示、発行要求、失効要求のための標準言語を親子システムに与える。それは、親がなぜあるリソースを含めるべきと考えるか、移行が完了したか、または非自発的変更の前にどのようなプロセスがあるべきかを決定しない。プロトコルは、他の場所で下された決定を忠実に伝達する。
これはインフラストラクチャでは一般的である。技術標準は、コマンドがどのように認証され表現されるかを定義する。それらはそのコマンドを送信することが許可された機関の全公法を提供するわけではない。有効に署名された失効は依然として性急、誤り、または手続き的に不公平でありうる。逆に、確認された侵害や完了した移行の後など、オペレーターが遅延を望む場合でも、親は失効を義務付けられることがある。
したがって RIR は少なくとも三つの関連する役割を果たす。登録情報を維持する。認証サービスが証明するリソース範囲を決定する。その範囲を暗号オブジェクトに変換する CA を運用または親として管理する。ホスト型サービスでは、ユーザーの秘密鍵を保持しユーザーの署名オブジェクトを公開することもある。
役割の集中は一貫性を向上させうる。移行が完了すると、一つの機関がレコードを更新し、証明書を置換し、当事者が新たな認証を構築するのを支援できる。また、誤りを増幅させることもある。誤ったステータス変更は、別の組織が行動するのを待つ必要がない。自動化が直接それを証明書発行とリポジトリ状態に持ち込むかもしれない。
ガバナンスは集中した役割に合わせるべきである。親は、登録イベントと証明書イベントの間のマッピングを文書化すべきである。自動的に発生しうる変更と人間の確認を必要とする変更を区別すべきである。誰が緊急失効を承認できるか、二重制御がどのように機能するか、どの証拠が保持されるか、オペレーターがどのように誤りに異議を唱えられるかを特定すべきである。認証実践声明は技術的実践を記述できるが、サービス条件とコミュニティポリシーも決定の正当性を定義しなければならない。
2020年のインシデントは伝播経路を明らかにした
2020年12月17日、RIPE NCC はレガシーリソースに関わるエラーを報告した。無関係なレジストリアイテムの実装におけるプログラミングミスが、影響を受けたレガシーリソースの契約ステータスを「なし」に設定した。それらのリソースは認証不適格となった。
結果は階層に従って生じた。36の CA のリソース証明書が、より少ない認証可能リソースを含むように更新された。41のホスト型 ROA(202の検証済みペイロードを生成)が、24の CA から削除された。影響を受けた委任型 CA に発行された証明書は縮小し、それらのソフトウェアによっては、それらの ROA は消失するか過大請求として拒否された。RIPE NCC は、影響を受けた105のリソースの契約ステータスを復旧し、ホスト型 ROA を再作成した。委任型事業者には、自身の ROA を再作成する必要があるか確認するよう助言された。
数値は事象の内部に留めるべきである。それらは年次エラー率、全体の分母、RIR の比較故障尺度を確立するものではない。事後分析も、影響を受けたすべての経路が到達不能になったことを証明しない。検証状態とネットワークポリシーがその結果を決定する。
このインシデントが証明するのはメカニズムである。登録環境における契約ステータスエラーが、証明書範囲と経路認証素材に伝播した。ホスト型ユーザーと委任型ユーザーは異なる復旧義務を経験した。RIR は自身が運用するホスト型 ROA を再作成できたが、委任ホルダーは自身の CA 内で行動する必要があったかもしれない。
RIPE NCC は、品質保証、受け入れテスト、リスクベースの影響分析を改善すると述べた。これらは賢明な措置である。より広い教訓は、登録と証明書の境界付近の変更は、ルータープラットフォームへの変更と同様の注意に値するということである。テストには、予想される証明書の差分、ROA と検証済みペイロードへの影響、移行効果、委任クライアントの動作、復旧経路を含めるべきである。管理的に見えるレジストリ変更が、暗号学的な影響範囲を持ちうる。
移行が最も困難な通常ケースである
緊急時の侵害は劇的だが、移行は経常的なガバナンスの試金石である。レジストリは旧ホルダーの証明を停止し、受領者の証明を開始しなければならない。ルーティングは全体を通じて継続する必要があるかもしれない。オリジン AS は同じままであるか、一度に変更されるか、段階的に変更されるかもしれない。売り手、買い手、ブローカー、トランジットプロバイダー、RIR のそれぞれが、シーケンスの異なる部分を制御するかもしれない。
RIPE NCC のガイダンスによれば、リソースが移動または移転されると、登録組織と証明書が変更され、基礎となる ROA は削除されて再作成されなければならない。そのホスト型文書はまた、登録保有の変更に応じてリソースが証明書に自動的に追加または削除されると述べている。この動作は、旧ホルダーによる古い請求から受領者を保護する。それは、決済の一部として扱われるべき切り替え依存性を生み出す。
高品質の移行計画はレジストリ更新の前に始まる。当事者は、より詳細な経路、複数オリジン、一時的な緩和プロバイダーを含め、すべての ROA と実際のアナウンスを棚卸しすべきである。クロージング後にどの認証が存在しなければならないか、誰がそれらを作成するか、受領者の CA へのアクセスがどのように確認されるか、バリデーターがどのように観測されるかについて合意すべきである。RIR は、何が削除され、受領者が何を作成できるかの機械可読なプレビューを提供すべきである。
原則は、アーキテクチャが許す限りメイク・ビフォア・ブレイクである。出力側の認証は、入力側の認証が公開され取得可能になるまで有効のままであるべきである。ただし、セキュリティや法律が即時削除を要求する場合を除く。地域システムが重複認証をサポートできない場合、その制限は明示されるべきであり、切り替えにはテスト済みのロールバックまたは加速復旧経路がなければならない。
すべての重複が安全であるわけではない。同一リソースについて二者を証明することは、競合する請求を生み出したり、旧ホルダーの権限を延長する可能性がある。制限付きの移行は、それでも予告なしのギャップよりも安全でありうる。政策設計は、期間、許可されるオブジェクト、承認、監視、自動有効期限を指定しなければならない。移行の継続性は、旧来の権利を無期限に温存する要求ではない。回避可能なルーティング損傷なしに有効な権利を連続させる要求である。
可能な場合、通知は暗号イベントの前に届かなければならない
伝統的な通知は、しばしばアカウントステータスが変更されたという電子メールである。イベントが証明書範囲を変更しうる場合、これは弱すぎる。メッセージはルーティングセキュリティチームではなく請求担当者に届くかもしれない。リスクにさらされているプレフィックス、証明書、ROA を列挙せずに契約問題を説明するかもしれない。自動化されたシステムがすでに行動した後に届くかもしれない。
通知はリスクベースであるべきである。確認された秘密鍵侵害は、即時失効と、その後の迅速な通知と置換を正当化しうる。完了した自発的移行は合意されたスケジュールに従う。争われている支払い、制裁マッチ、疑わしいポリシー違反、不確かな企業承継は、具体的な脅威が緊急性を要求しない限り、通常は警告期間を許容する。
非緊急行動について、オペレーターは精密なプレビューを受け取るべきである。影響を受けるリソース、現在の証明書識別子、検証が停止すると予想される署名オブジェクト、発効時期、理由、権限者、可能な改善策、審査経路。プレビューはポータルおよび大規模事業者がルーティング意図と比較できるよう署名付き機械可読形式で利用可能であるべきである。
配信は、争われているか侵害されている可能性のあるアカウント資格情報だけでなく、独立して維持されている運用連絡先と法務連絡先を使用すべきである。受領確認は記録されるべきだが、受領確認の欠如が無限の拒否権を生むべきではない。エスカレーションは反復的なチャネルと公開されたタイムテーブルを通じて進められる。
通知期間は修正を支援すべきである。レジストリが誤った組織を結び付け、合併文書を誤読し、または誤った制裁対象者を一致させた場合、スタッフは証拠が審査されている間、非緊急行動を一時停止できなければならない。行動が正しい場合、オペレーターは新しい ROA や顧客を検証状態の変化に備える時間を得る。
良好な通知は、すべての経路が Valid であり続けるという約束ではない。それは管理権限とネットワーク運用の間の規律ある引き継ぎである。それは驚きを減らし、証拠記録を作成し、後の説明責任を可能にする。
理由と審査はセキュリティ統制である
機関は往々にして、デュープロセスを技術的セキュリティに課される遅延として扱う。ここではそれはセキュリティの一部である。迅速に失効できる親は、アカウント乗っ取り、内部者エラー、虚偽の法的請求、誤解された登録変更に対する統制を必要とする。書面による理由と独立した審査は、決定を証拠と権限に結びつけることを強制する。
失効理由は将来的かつ限定的であるべきである。例としては、確認された鍵侵害、ホルダー要求、完了した登録変更との証明書不一致、関連するサービス関係の期限切れ、拘束力のある法的命令、証明された詐欺、公表された方針の下での委任 CA の持続的な機能不全が含まれる。「運用上の理由」のような曖昧な表現は、閾値、承認役割、復旧義務を伴うべきである。
審査は時間スケールに適合しなければならない。数ヶ月後に決定される定常的な異議申し立ては、今日の午後に発生する経路切り替えを保護できない。第一層は、初期行動の責任者ではないスタッフによる迅速な技術的および登録上の確認であるべきだ。第二層は契約上または政策上の紛争を検討できる。緊急行動は、認証の継続が深刻なリスクを生み出す場合、審査中も効力を維持しうるが、機関はその理由を説明すべきである。
審査者は現在のレコード以上のものを必要とする。イベント履歴を見るべきである。誰が登録ステータスを変更したか、どのルールが適用されたか、結果として生じた証明書差分は何か、どの通知が送信されたか、どの承認が得られたか、どの復旧オプションが存在するか。セキュリティとプライバシーが許す限り、オペレーターはその推論の多くを受け取るべきである。
匿名化された決定クラスの公開は一貫性を改善できる。メンバーは、緊急および非緊急の根拠がどのくらいの頻度で使用されるか、誤りがどれだけ迅速に復旧されるか、地域政策が経常的な移行ギャップを生み出すかどうかを見ることができる。集計報告は、事象が稀な場合に精度を捏造してはならないが、沈黙はコミュニティが集中した力を評価不能にする。
委任は一つの依存関係を狭めるが、階層を無くさない
委任型 RPKI は、時に RIR 制御への答えとして提示される。それは部分的な答えである。オペレーターは秘密鍵を生成・保護し、自らの CA ソフトウェアを実行し、どのオブジェクトに署名するかを決定する。認証変更をネットワーク運用と統合し、一つのシステムで複数の親からのリソースを管理し、潜在的には子証明書を発行できる。
これらは重要な統制である。ホスト型サービスポータルの停止は、委任ホルダーが新しい ROA を作成するのを妨げる必要はない。RIR のスタッフは子の秘密鍵を使って異なる声明に署名することはできない。ホルダーは自身の署名済みイベント履歴を保持し、別の公開サービスを選択できる。
親は依然として、子をあるリソースセットに対して権威あるものにする証明書を制御する。RFC 6492は親が証明書を発行し失効させることを許容する。登録が変更されれば、親はより少ないリソースを持つ証明書を提供できる。子が古い範囲に署名し続ければ、バリデーターは過大請求を拒否する。したがって委任は、署名管理権限を登録権限から分離する。それは登録権限を廃止しない。
RIPE-847 は別の文脈でこのことを明示する。2025年10月以降、RIPE NCC が委任型 CA の現在のマニフェストと CRL を三ヶ月以上にわたって発見・検証できない場合、現在の資料を発見しオペレーターに通知する合理的な努力の後、リソース証明書は失効される。方針は、短期的な不完全性ではなく、持続的に機能不全の CA とそれが依存パーティに課す負荷に対処する。
それはガバナンス上の結果を伴う正当な親機能である。委任オペレーターは制御を得て、義務を負う。親は失効の根拠を得て、それを予測可能に適用しなければならない。監視は、親自身の到達性問題によって引き起こされる誤検出を避けなければならない。通知は失敗したチェックを特定し、ホルダーが有効な公開を実証できるようにすべきである。復旧は文書化されるべきである。
委任は、階層内の憲法的分離として最もよく理解される。それは親がすべてを行うことを防ぐが、何もできないようにするわけではない。
リポジトリは第二の制御面を形成する
証明書と ROA は依存パーティに届かなければならない。RPKI リポジトリは証明書、失効リスト、マニフェスト、署名オブジェクトを公開する。RFC 8181は、CA が公開サーバーにオブジェクトの公開または撤回を依頼するためのプロトコルを定義する。ホスト型サービスは通常、CA とリポジトリの運用を統合する。委任ホルダーは自ら公開するか、RIR の公開サービスを使用するかもしれない。
この区別は重要である。なぜなら署名鍵の所持と署名オブジェクトを配布する能力は異なる権限だからである。親の公開サービスを使用する委任ホルダーは鍵を保持するが、親が運用するリポジトリがそのオブジェクトを受け入れ配信することに依存する。自己公開するホルダーはより多くの配布制御を得るが、グローバルに利用可能なサービス、最新のマニフェスト、最新の失効リスト、運用障害に対する回復力についても責任を負う。
リポジトリの利用不能は、機械的に即時の経路拒否に変換されない。バリデーターは資料をキャッシュし、失効または利用不能なリポジトリのルールを適用する。異なる実装とローカル設定が異なるタイミングを生み出しうる。しかし、失効した公開は意図された変更が世界に届くのを妨げ、無効なマニフェストや失効情報はブランチ全体の拒否を引き起こしうる。
したがって、制度的な地図は四つの統制を別個に記述すべきである。登録範囲、親証明書、子署名、公開である。ある組織は、四つすべてを制御せずに一つ、二つ、三つを制御するかもしれない。オペレーターが自らの鍵を持っているとのみ述べる契約書や継続性計画は不完全である。
同じ分離はインシデント分析を改善する。新しい ROA が現れない場合、原因は子の署名操作の失敗、拒否されたプロビジョニング要求、失敗した公開要求、リポジトリ同期問題、依存パーティキャッシュかもしれない。抽象的な RPKI を非難することは、権限と責任が実際にどこにあったかを不明瞭にする。
裁判所命令と制裁には狭い橋が必要である
RIR は法の下で運営される。裁判所が企業紛争を決定し、資産の保全もしくは移転を命じ、口座を制限し、または詐欺の疑いに対処するかもしれない。制裁ルールはリストされた人物へのサービス提供を禁じるかもしれない。レジストリは、ルーティング継続性が価値あるからといって、拘束力のある法的義務を無視すると約束することはできない。
危険は、広範な法的圧力を定義された橋なしに証明書行動に変換することにある。企業の株式に関する命令は、RIR にリソース証明書を失効するよう指示しないかもしれない。制裁マッチは曖昧かもしれない。債権者の請求は、現在の経路認証の有効性ではなく支払いに関するものかもしれない。機関は、法的行為、リソース関係、最も混乱の少ない遵守対応を特定すべきである。
即時失効が要求される場合、記録は誰がそれを承認したか、なぜ通知が限定されたかを特定すべきである。保全が許される場合、RIR は裁判所が支配権を明確にするまで、既存の認証を維持しつつ移行を凍結するかもしれない。その選択は、技術スタッフによって即興されるのではなく、法律と政策に基づかなければならない。
国境を越える運用は状況を複雑にする。リソースホルダー、親会社、ネットワーク、RIR、裁判所は異なる法域に存在しうる。RPKI は法律の抵触を解決しない。その暗号学的確実性は、法的な不確実性を偽装することさえある。バリデーターはどの証明書パスが受け入れられるかは知っているが、親の行動の背後にある紛争が正しく解決されたかどうかは知らない。
これは経路検証を所有権の証明として提示することを避けるもう一つの理由である。RIPE NCC の条件は、その証明書が所有権の主張を裏付けることを明示的に否定している。リソース証明書は調整システム内で証明する。裁判所はその証拠を使用または審査するかもしれないが、証明書は普遍的な権原証書ではない。
責任は予防可能な制御に従うべきである
現在のサービス条件はしばしば多くのリスクをユーザーに配分する。ARIN の公開された契約は、契約上、政府、技術、セキュリティを含むいくつかの理由による即時終了を含む広範な終了権を記述し、いかなる理由でも、あるいは理由なしでも14日のルートによる終了を記述する。また広範な免責条項、権利放棄、免責文言を含む。RIPE NCC 条件は利用をホルダーのリスクとし、故意の不正行為または重大な過失を含む場合を除き、責任を制限する。
これらの条項の法的効果は準拠法と事実に依存する。比較記事が執行可能性を判断できるものではない。しかし、その制度的メッセージは明らかである。RIR は、他で行われたすべてのルーティング決定の保険者になることなく、進化するセキュリティサービスを運営する柔軟性を求めている。
その懸念は正当である。親は遠隔のネットワークが Invalid 経路を拒否するかどうかを制御しない。すべての委任リポジトリの可用性やホルダーの ROA の正確性を保証できない。無制限の結果的責任は公益サービスの提供を妨げる可能性がある。
しかし、完全な免責は調整された責任の貧弱な代用品である。リスクは予防可能な制御に従うべきである。ホルダーは、提出する誤ったルーティング意図、安全でない資格情報、および自身が運用する CA の障害について責任を負うべきである。公開プロバイダーは、合理的なサービス制限の下で明示的に引き受けた義務について責任を負うべきである。親は、著しく不十分な認証、公表された失効ルールからの説明不能な逸脱、約束された移行の不履行、または自身の誤りの復旧における回避可能な遅延について責任を負うべきである。
救済は多額の損害賠償から始める必要はない。緊急復旧、料金クレジット、資金提供された技術支援、証拠の保全、独立調査、調査結果の公表を含みうる。重大な証明された損失については、上限付き補償の取り決めや保険メカニズムが各地域コミュニティによって検討されうる。中心的な論点は、決定的な統制を持つ機関が理論上のみ説明責任を負うべきではないということである。
親アクション憲章は権力を読解可能にする
各 RIR は、登録と認証の境界における行動のためのコンパクトな憲章を公表すべきである。それは技術的な証明書方針や一般的なサービス契約を置き換えるものではない。それはオペレーターに、その認証状態に何が起こりうるか、誰の権限の下でかを伝えるだろう。
憲章はイベントを分類すべきである。自発的イベントには、ホルダーが要求する失効、キーロールオーバー、移行が含まれる。セキュリティイベントには、侵害および認証された緊急要求が含まれる。登録イベントには、返却、移行、修正された委任が含まれる。コンプライアンスイベントには、制裁、裁判所命令、契約終了が含まれる。運用イベントには、永続的に無効な委任公開が含まれる。
各クラスについて、憲章は証拠の閾値、通知期間、承認者、メイクビフォアブレイクが利用可能かどうか、予想されるルーティングセキュリティ上の影響、審査経路、復旧目標、保持される記録を明記すべきである。ホスト型ユーザーと委任型ユーザーの違いを説明すべきである。オペレーターが現在のオブジェクト目録を取得し、提案された証明書変更をプレビューできるインターフェースを列挙すべきである。
憲章はまた、否定的権限を定義すべきである。RIR が RPKI を通じて決定しないこと。親 CA は、合法的な政策批判を罰するため、サービスに関係のない私的負債を解決するため、競合するネットワークアーキテクチャの選択のため、または財産権を付与するために失効を使用すべきではない。地域政策がより広範な行動を認可する場合、その権限は明示的かつ審査可能であるべきである。
独立監査は、実際のイベントが憲章に従っているかどうかをテストできる。サンプリングは、暗号鍵保護だけでなく、登録システムからのトリガーが正しいかに焦点を当てるべきである。監査人は、認可、タイミング、通知、復旧を調査すべきである。公開サマリーは、ホルダーの秘密を暴露することなく、クラスと統制調査結果を開示できる。
これはセキュリティに追加された官僚主義ではない。それは外部効果を持つセキュリティサービスの運用憲法である。
Number Resource Society が鍵を主張せずにできること
Number Resource Society は、正確な登録、ホルダー制御、参加、恣意的な干渉の削減を公に主張している。これらの原則は親 CA に関連する。なぜなら、行き過ぎに対する最強の保護は階層の否定ではなく、階層の透明で制限された使用だからである。
NRS は、比較親アクション指標を維持することで具体的な貢献ができる。各 RIR について、証明書置換と失効の公表された根拠、通知ルール、移行手段、異議申し立てチャネル、責任文言、委任公開オプションを記録できる。小規模事業者にとってページが理解可能かどうかをテストし、ルーティングの結果が説明されないままの条件を特定できる。
また、オブジェクト目録、受領者の準備、複数オリジン、顧客委任、バリデーター観測、ロールバック連絡先に基づいて構築された移行継続性チェックリストも公開できる。小規模なメンバーは専任の公開鍵チームを欠くことが多い。中立的なチェックリストと机上訓練は、NRS が CA を運用することを求めずに、制度的リスクを実践的な準備に変換するだろう。
最後に NRS は、厳格な証拠ルールの下で文書化された会員の経験を収集できる。すなわち、日付、地域サービス、イベントタイプ、通知、検証状態への影響、復旧、未解決の不確実性である。集計は、既知の分母なしに率を主張することを避けるべきである。価値は、繰り返し発生する故障モードと政策のギャップを明らかにすることにある。
これらの役割は積極的だが制限されている。NRS の憲章と説明ページは当事者によるアドボカシーである。それらは NRS が認知されたトラストアンカー、認可されたレジストラ、中立の裁定者、または技術的に優れた証明書オペレーターであることを証明しない。その最も強い立場は、階層の周囲の市民的制度としてである。すなわち、ルールを比較可能にし、ホルダーの準備を助け、暗号学的権力を手続き上の義務と結びつけるよう地域コミュニティに圧力をかけることである。
反論は深刻だが管理可能である
一つの反論は、事前通知が侵害された鍵を持つ攻撃者を助けるというものである。だからこそ、提案された規律は緊急セキュリティ行動と通常の管理変更を区別する。即時失効は、遅延が具体的な脅威を拡大する場合に利用可能なままでありうる。二重認可、迅速な置換、事後審査は緊急権力を遅くすることなく安全にする。
第二の反論は、メイクビフォアブレイクが二つの請求者を証明しうるというものである。時にはそうであり、不注意な重複はシステムを弱める。答えは普遍的な重複ではない。それは、登録権限、当事者の同意、技術的制約がそれを支持する場合にのみ使用される狭い移行ツールであり、短期の有効期限と可視的な監視を伴う。重複が受け入れられない場合、事前検証と合意された切り替えが依然としてギャップを縮小できる。
第三の反論は、オペレーターはすでにサービス条件を受け入れているというものである。条件への同意は制度依存を排除しない。多くのオペレーターは、正当に保持するリソースについて一つの地域の親しか持たない。顧客やピアがますます検証を重視するようになれば、RPKI を断ることが完全な答えではない。会員ガバナンスは、関係を通常の競争的購入と偽るのではなく、条件を改善すべきである。
第四の反論は、分散ルーティングシステムがユーザーを保護するというものである。なぜならネットワークが独自のポリシーを選択するからである。それは確かに CA による直接制御を減らす。また、害が不均一で測定しにくいことも意味する。断片化された結果は精密なインシデントテレメトリの必要性を強化する。それは回避可能な親エラーを許すものではない。
最後の反論はコストである。プレビューツール、迅速な審査、監査にはスタッフが必要である。しかし RIR はすでに認証、登録、移行、証明システムを運用している。それらの間のインターフェースに保護策を追加することは、各エラーを予見不能な事故として扱うよりも安価である。認証サービスの料金は、それらを信頼に値するものにする統制を支援すべきである。
境界を測定せよ、神話的なグローバルスイッチではなく
説明責任には測定が必要だが、でっち上げられたグローバルパーセンテージではない。RIR は原因別の親証明書置換、緊急失効、非緊急失効、移行切り替え、復旧イベント、委任 CA アクションの件数を公表できる。サンプルサイズが許す限り、通知と復旧の中央値と範囲を報告できるが、ホルダーを特定する詳細は抑制する。
技術的測定は、アクションがそのプレビューと一致したか、影響を受けたオブジェクトが再作成されたか、委任クライアントが手動復旧を必要としたか、リポジトリ配布が宣言された目標を達成したかを追跡すべきである。登録測定は、計画されたホルダーアクションではなく修正されたデータから生じた証明書影響イベントの数を記録すべきである。
独立したオブザーバーは可視的な RPKI 変更を測定できるが、公開オブジェクトから原因を確実に推測することはできない。存在しない ROA は意図的かもしれない。証明書の縮小は有効な移行に従うかもしれない。したがって公開テレメトリは、外部の推測によって置き換えられるのではなく、監査された制度的記録と組み合わされるべきである。
オペレーターも独自の測定が必要である。親関係、証明されたリソース、ROA、委任子、公開ポイント、ルーティング依存関係の現在の目録を維持すべきである。予期せぬ証明書範囲変更を警告し、複数の実装または観測点からの検証済みペイロードを比較すべきである。どの顧客やサービスが Valid ステータスを必要とするかを知るべきであり、すべてのネットワークが NotFound を同様に扱うと仮定するべきではない。
最も有用な測定は、誤った親アクションから復旧された有効認証までの時間である。それは検出、連絡、権限、署名、公開を一緒にテストする。無秩序な復旧経路を伴う低いインシデント数は、成熟したガバナンスではない。
現在のところ、公正なクロス RIR の不当失効または経路喪失の確率を裏付ける公開データセットは存在しない。その不確実性は可視的のままであるべきである。それはより良い証拠を公開する理由であり、安心感を捏造するライセンスではない。
セキュリティ権限には手続きの背骨が必要である
RPKI は実在する問題を解決する。それはオペレーターのルーティング意図を暗号的に検証可能にし、偶発的または悪意のあるオリジンを拒否するためのより強力な基盤をネットワークに与える。階層は、その成果の中に隠された恥ずべき欠陥ではない。それはシステムが認証を現在のリソース委任に結びつける方法である。
しかし、階層は権力を下方に運ぶ。RIR の親は、子証明書がカバーできるリソースを決定する。ホスト型サービスは、ホルダーの署名鍵を保有し、すべてのオブジェクトを公開することもある。したがって登録更新は経路検証証拠の変更になりうる。2020年の RIPE NCC インシデントは、この経路が運用可能であることを示し、現在の地域条件と方針は失効理由と救済が依然として異なることを示している。
正しい応答は、RPKI を放棄することでも、暗号が制度的判断を取り除くと偽ることでもない。親 CA は将来的なルール、狭く調整された緊急権限、意味のある通知、移行エンジニアリング、迅速な審査、透明なインシデント会計、管理に比例した責任を必要とする。委任 CA は、その利益が義務を正当化する場合には奨励されるべきだが、親関係からの逃避として販売されるべきではない。
「オペレーターの上の証明書権限」というフレーズは、設計上のリマインダーになるべきである。オペレーターは経路を発信し認証に署名しうる。別の機関が、その署名が有効なリソースチェーン内に位置するかどうかを決定する。その機関が正確に、予測可能に、説明責任を持って行動するとき、RPKI はより強固である。その管理エラーや制限のない裁量が目に見えず伝播するとき、ルーティングセキュリティはレジストリリスクの経路になりうる。
したがって、RPKI ガバナンスの次の段階は暗号的ではなく手続き的である。標準はすでに証明書、失効リスト、マニフェスト、ROA がどのように機能するかを説明している。地域コミュニティは今や、親がいつ行動できるか、継続性がどのように保護されるか、オペレーターの上の権限が誤った場合に何が起こるかを同様に明確にしなければならない。
出典
- IETF, RFC 6480,An Infrastructure to Support Secure Internet Routing:https://www.rfc-editor.org/rfc/rfc6480
- IETF, RFC 6483,Validation of Route Origination Using the Resource Certificate Public Key Infrastructure and Route Origin Authorizations:https://www.rfc-editor.org/rfc/rfc6483
- IETF, RFC 6492,A Protocol for Provisioning Resource Certificates:https://www.rfc-editor.org/rfc/rfc6492
- IETF, RFC 6811,BGP Prefix Origin Validation:https://www.rfc-editor.org/rfc/rfc6811
- IETF, RFC 7115,Origin Validation Operation Based on the Resource Public Key Infrastructure:https://www.rfc-editor.org/rfc/rfc7115
- IETF, RFC 8181,A Publication Protocol for the Resource Public Key Infrastructure:https://www.rfc-editor.org/rfc/rfc8181
- IETF, RFC 8211,Adverse Actions by a Certification Authority or Repository Manager in the Resource Public Key Infrastructure:https://www.rfc-editor.org/rfc/rfc8211
- RIPE NCC,Initial Certification Policy in the RIPE NCC Service Region:https://www.ripe.net/community/policies/proposals/2008-08/
- RIPE NCC,Resource Certification Service Launch:https://www.ripe.net/about-us/news/RIPE NCC-resource-certification-service-launch/
- RIPE NCC,Using the RPKI System:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/using-the-rpki-system/
- RIPE NCC,Using the Hosted Certification Authority:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/resource-certification-roa-management/
- RIPE NCC,Using a Delegated Certification Authority:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/using-a-delegated-certification-authority/
- RIPE NCC,Certification Service Terms and Conditions:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/legal/RIPE NCC-certification-service-terms-and-conditions/
- RIPE NCC, RIPE-847,Revocation of Persistently Non-functional Delegated RPKI CAs:https://www.ripe.net/publications/docs/ripe-847/
- RIPE NCC,Error in Contractual Status of Legacy Resources Impacted RPKI:https://www.ripe.net/ripe/mail/archives/routing-wg/2020-December/004210.html
- ARIN,RPKI Deployment Options:https://www.arin.net/resources/manage/rpki/options/
- ARIN,RPKI Terms of Service Agreement:https://www.arin.net/resources/manage/rpki/tos/
- APNIC,Certification Practice Statement:https://www.APNIC.net/community/security/resource-certification/certification-practice-statement/
- APNIC,Resource Public Key Infrastructure:https://www.APNIC.net/community/security/resource-certification/
- LACNIC,Resource Certification:https://www.LACNIC.net/640/1/LACNIC/resource-certification-rpki
- Number Resource Society,Our Charter:https://nrs.help/our-charter/
- Number Resource Society,Frequently Asked Questions:https://nrs.help/faq/

