要約

  • グローバル RPKI は、文字どおり単一のユニバーサルなトラストアンカー上に構築されているわけではない。リライングパーティソフトウェアは通常、AFRINIC、APNIC、ARIN、LACNIC、RIPE NCC の TAL を使用する。しかし、あるリソースに対する有効な証明書パスは通常、一度に一つの受け入れられた認証局で終了するため、複数のバリデータを実行しても、そのリソースに対して複数の独立した発行者が生じるわけではない。
  • バリデータの多様性は価値がある。独立したコードベースは、異なるパーサの欠陥、メモリ安全性の障害、トランスポートの動作、キャッシュ戦略、リリースサイクルを含みうる。別個のインスタンスは、一つのプロセス障害やメンテナンスイベントがネットワークで利用可能なすべての検証済みフィードを削除する可能性を減らす。
  • すべての準拠するバリデータは、設定されたトラストアンカーによって提供される権限の範囲内で署名付きオブジェクトを評価する。受け入れられた親 CA が子証明書を失効させたり、そこからリソースを削除したり、競合するチェーンを発行したりした場合、バリデータは、親が賢明に行動したかどうかを投票するのではなく、結果として生じる暗号状態を認識することが期待される。
  • リポジトリとトランスポートの多様性は可用性を向上させうるが、ミラーは権限を作り出すことはできない。完全に複製された不利な証明書や失効は依然として不利であり、一方、独立したミラーからの未署名の修正は有効な代替とはならない。
  • バリデータ出力間の多数決は、制度的な上訴ではない。二つの古いキャッシュが一つの最新のキャッシュを上回ることができ、二つの実装がライブラリや解釈を共有することができ、実際の権限変更が最初に不一致として現れることがある。オペレータは、単純な数ではなく、各相違を説明する証拠を必要とする。
  • トラストアンカーの回復力は権限層に属する。保護されたキーの保管、分割承認、公開ロールオーバ計画、後継キーの準備、独立した監視、範囲を限定した証明書変更、理由のある決定、上訴、および継続性の手配である。RFC 9691 は計画されたトラストアンカーキーの移行をより安全にするが、現在のトラストアンカー秘密鍵の侵害に対する保護は明示的に行わない。
  • SLURM のようなローカル例外は、不利なアクションの間、オペレータの自律性を維持できるが、それはローカルであり、検証ビューを断片化しうる。それらは緊急時の制御であり、代替となるグローバルな権限や、紛争中のレジストリ決定に対する自動的な解決策ではない。
  • 番号資源社会は、トラストアンカーの受領書、キーセレモニーの証拠、変更通知、異議申立手続き、バリデータ比較レポートを標準化することで、権限の集中をより説明可能にできる。それは独立したソフトウェアを補完すべきであり、レジストリ権限が分散化された証拠としてソフトウェアの多様性を販売するべきではない。

多様性は最初の決定がすでに行われた後に始まる

RPKI バリデータは、BGP を検査して説得力があると感じた機関を選ぶことによって権限を発見するのではない。オペレータが設定したトラストアンカー素材から開始する。トラストアンカーロケータは、自己署名の認証局証明書を取得して認証するために使用される場所と公開鍵を提供する。その受け入れられた出発点から、バリデータは証明書パスをたどり、リソース拡張、マニフェスト、失効リスト、署名付きオブジェクトをチェックし、検証済みペイロードを導出する。

異なる言語で書かれた二つのバリデータは、その作業を独立して実行できる。一方が不正なエンコーディングを拒否するかもしれず、他方はそれを誤って処理するかもしれない。一方がリポジトリの中断から回復する一方で、他方がクラッシュするかもしれない。一方が古いマニフェストを明確に示す一方で、他方はあまり有用でないエラーを出すかもしれない。こうした違いは重要である。なぜなら、リポジトリの内容は信頼できない入力であり、検証面は複雑だからである。

しかし、バリデータは最終的な発行者を独立して決定するわけではない。両方が同じ TAL 公開鍵で設定されている場合、両者はその証明書に記述されたリソースに対する開始権限として同じトラストアンカーを受け入れる。子孫オブジェクトが構文的または暗号的に有効かどうかについては意見が分かれるかもしれない。入力と標準について合意しているならば、一方がホルダーを好み、他方が親 CA を好むという理由だけで意見が分かれるべきではない。

制度的な集中は、したがって実装の上流にある。バリデータは、オブジェクトが定められたルールのもとで受け入れられたルートから導かれることを証明できる。ルートのガバナンスが公正であること、強制された失効が比例的であること、レジストリのホルダー記録がすべての私的な法的利益を反映していることを証明することはできない。暗号検証はより狭い質問に答える。

これが、三つのバリデータ製品を購入する調達計画が分散化を誇張しうる理由である。それは一つの設定された権限に対して三つの計算上の証人を作り出す。それは有用な回復力であるが、三つの独立した認証権限の源ではない。

五つの地域アンカーがすべてのプレフィックスに五つの独立した票を与えるわけではない

本番環境のリライングパーティソフトウェアは通常、五つの地域インターネットレジストリ（AFRINIC、APNIC、ARIN、LACNIC、RIPE NCC）のトラストアンカーロケータを含んでいる。RFC 8897 は、各リライングパーティが自らのトラストアンカーを選択し、IANA と五つの RIR を、番号リソース割り振り階層と整合する明白なデフォルト候補として特定すると述べている。Routinator と FORT のドキュメントは、通常の設定で五つの RIR TAL を示している。

その構造は、単一の組織によって運用される一つのグローバルルートよりも分散している。一つの地域ツリーに限定された障害は、排他的に他の地域ツリーで認証されたリソースを無効化する必要はない。地域コミュニティ、契約、ガバナンスも異なる。RPKI 全体が文字通りただ一つのトラストアンカーしか持たないと述べるいかなる分析も誤りだろう。

分析の単位がリソースになると、集中が再び現れる。プレフィックスは通常、その割り振りをカバーするトラストアンカーから派生する証明書パスの中に位置する。そのホルダーは、オペレータが三つのバリデータを実行しているからといって、三つの無関係な RIR ルートに三つの同等に権限のある証明書を発行するよう求めることはできない。正当な地域間移行の間、パスが一時的に変更されたり重複したりすることがあるが、それは日常的なマルチルート投票ではなく、管理された例外である。

したがって、ソフトウェアの多重性はリライングパーティ層で水平的に作用する一方、認証権限は垂直的に組織化されている。例えば、複数のバリデータが APNIC ツリーをたどることができるが、それらは APNIC のルート決定を五つの地域決定に変換するわけではない。リソースが別の地域に移動する場合、権限パスは移転の取り決めに従って変化し、バリデータの数がその移動を引き起こすわけではない。

この区別により、より正確なリスク表明が可能になる。グローバルシステムには地域的な分離がある。しかし、あるリソースのアクティブなパスの中では、親の権限がそれに依存するすべての子孫オブジェクトに影響を及ぼしうる。CA 証明書の失効は、リライングパーティに従属する署名付きオブジェクトを無効化させうる。独立したバリデータが、その結果を見事な一貫性をもって確認するかもしれない。その場合、それらの一致は、設計どおりに機能する集中権限を示すのであり、分散した権限を示すのではない。

ソフトウェアの多様性は実際の制御であり、軽視されるべきではない

誇張に反対する論は、モノカルチャーを支持する論ではない。RPKI リライングパーティは、多くの公開ポイントから取得された証明書、失効リスト、マニフェスト、ROA、その他の署名付きオブジェクトを処理する。それらは ASN.1、暗号署名、URI ディスカバリ、RRDP、rsync、キャッシュ状態、オブジェクトの有効期限、例外的な公開状況を扱う。欠陥は、出力を破損させたり、リソースを消費したり、検証済みデータをルータが利用できなくしたりする可能性がある。

独立した実装は、その独立性が本物である場合、共通のソフトウェア障害を減らす。rpki-client は OpenBSD エコシステムで開発されており、小さなコードベース、特権分離、制約されたプロセスアクセスを強調している。Routinator は Rust による実装であり、独自の取得、保存、検証設計を持つ。FORT は別のオープンソースのリライングパーティであり、個別の運用制御を持つ。これらのコード、リリースパス、セキュリティ前提は同一ではない。

エコシステムはすでに、ソフトウェアの管理が変わることを示している。2021年、RIPE NCC は自社のバリデータのサポートを終了し、オペレータに対し、メンテナンスされていないコードを使い続けるのではなく、代替手段に移行するよう助言した。この決定は RPKI の権限を弱めるものではなかった。リライングパーティソフトウェアが独立したエコシステムによって提供されることが可能であり、そうされるべきであると認めたのだ。

ネットワークは、一つ以上のメンテナンスされた実装を使用することで、いくつかの保護を得る。重大なパーサの欠陥がすべてのフィードを削除する必要はない。リポジトリの境界ケースを比較できる。新しい標準機能が唯一の本番ソースになる前にテストできる。盲目的に運用することなくメンテナンスが可能である。異なるテレメトリが、一つのインターフェースが隠すエラーを明らかにするかもしれない。

これらの利点は、エンジニアリングの努力を正当化する。間違いは、それらを別の命題の証拠として使うことだ。すなわち、証明書とレジストリの権限が分散化されたという命題である。防火扉は建物の所有者を多様化しない。それは、ある種の障害に対して建物をより安全にする。バリデータの多様性は、それと同様に正確な条件で擁護されるべきである。

共通のトラスト入力が独立した判断の境界を定義する

RFC 8630 は、トラストの決定を通常よりも可視化する。TAL は一つ以上の場所と公開鍵情報を含む。リライングパーティは自己署名の CA 証明書を取得し、その公開鍵が一致することを確認し、証明書に記述されたリソースに対するトラストアンカーとしてそのエンティティを受け入れる意思があるかどうかを決定する。受け入れられると、アンカーは単なる別のデータソースではない。それは、子孫の証明が有効となる基礎である。

RFC はまた、侵害の深刻さも述べている。トラストアンカーの秘密鍵を持つ攻撃者は、その権限になりすますことができる。不適切または誤ったトラストアンカーへの依存は、同様に深刻な結果をもたらしうる。発行者は、TAL 鍵を再配布することなく、その証明書内のリソースセットを変更できる。これは、地域のリソース保有状況が変化するために必要な柔軟性である。その同じ設計は、リライングパーティが発行者の自制に相当な信頼を置くことを意味する。

同じ TAL を使用する複数のバリデータは、オペレータが意図的に異なる設定をしない限り、別々のトラスト選択をするわけではない。バンドルされた TAL は、選択をほとんど不可視にしうる。インストールは有用なデフォルトを生成し、すべての実装が同じ地域鍵から開始する。利便性は採用のために望ましいが、それは独立して交渉されたトラスト関係と混同されるべきではない。

トラストアンカー証明書を複数の URL から取得することも、複数の権限を作り出すわけではない。RFC 8630 は、取得を改善するために複数の場所を許可している。各場所は同じ公開鍵に対してチェックされる。ミラーは証明書を利用可能に保つことができるが、信頼された秘密鍵なしに異なる権限状態に署名することはできない。

この境界は、オペレータに実用的な棚卸の質問を投げかける。あらゆるバリデータインスタンスについて、どの TAL キーが設定されているか、それらがどのように取得されたか、誰がそれらを更新できるか、アップグレード中にどのソフトウェアパッケージがそれらを変更できるか。三つのインスタンスが一つの自動パッケージチャネルを通じて TAL の変更を受け取る場合、それらの見かけ上の独立性には共有されたブートストラップ依存性が含まれる。コードベースは異なるかもしれないが、ルートの設定は運用上集中されたままである。

バリデータは、単に不利益だからといって有効な不利な行為を覆すことはできない

RFC 8211 は、リソースホルダーに損害を与えうる認証局およびリポジトリマネージャによる行為を分析している。原因は、攻撃、誤り、ポリシーアクション、または法的強制である可能性がある。親は CA 証明書を失効させることができ、その結果、リライングパーティは従属する署名付きオブジェクトを無効として扱う。競合する ROA や変更されたリソースセットもルーティング結果を変えうる。

ホルダーの観点からは、影響は深刻かもしれない。バリデータの観点からは、タスクは依然として、受け入れられた認証状態を正しく処理することである。適切に署名された最新の失効が設定されたチェーンの下で現れ、検証ルールを満たすなら、公の声明が不公平を主張しているからといって、バリデータがそれを無視する権限はない。そうすることは、各ソフトウェアメンテナを上訴審のレジストリに変えてしまうだろう。

別の実装を実行しても、この分担は変わらない。正しい実装は、有効な親の行為の効果に収束するはずである。多様性は、一つのバリデータが新しい失効の取得に失敗したこと、またはマニフェストを誤って処理したことを明らかにできる。それが、親が契約上または法律上の権限を欠いていたことを立証することはできない。その判断には証拠とパーサのロジックの外側のフォーラムが必要である。

これが、タイトルの主張の最も鮮明な形である。単一のトラストアンカーは、必ずしもインターネット全体に対する単一の組織ではない。それは、関連するパスの最上部にある単一の受け入れられた権限である。その権限または強力な親が不利益な行為をした場合、バリデータの複数性は、その結果をより確実に可視化できる。それを生み出した権限関係を治すことはできない。

救済策は権限層で機能しなければならない。例外的な証明書変更に対する分割承認、可能な場合の通知、正確な理由、独立したレビュー、上訴、継続性の手段、そして履歴を消去せずに誤りを修正する方法である。技術的な検出はそれらの制御を支援するが、それらを置き換えるものではない。

バリデータ間の一致は計算の証拠であり、制度的同意ではない

オペレータはしばしば、複数のバリデータからの出力を比較する。この慣行は実装の欠陥や古いキャッシュを特定できるが、比較には合意が何を意味するかについての理論が必要である。三つの同一の検証済みペイロードリストは、インスタンスが現在のビューから同じ結果を生成したことを示す。それらは、三つのレジストリが基礎となる証明書を承認したことや、影響を受けたホルダーが同意したことを示さない。

この区別は、複製された算術に似ている。独立した計算機は、合計が正しく計算されたという信頼を高める。それらは、請求書が合法的に発行されたという独立した証拠を提供しない。RPKI バリデータは、パスとオブジェクトの有効性を確認できる。認証局と登録プロセスが、どのステートメントがそのパスに入るかを決定する。

計算上の合意にも限界がある。インスタンスは、暗号ライブラリ、オペレーティングシステムコンポーネント、リポジトリキャッシュ、TAL パッケージ、ネットワークパス、更新スケジュールを共有しているかもしれない。二つのブランド製品が同じ解析依存性を継承することがある。三つのサーバが一つのローカルミラーにクエリできる。多様性は、製品の数ではなく故障ドメインによって評価されるべきである。

不一致もまた曖昧である。一つのインスタンスが古く、一つがより新しい RFC を実装しており、一つが不正なコンテンツを拒否し、一つが最新の失効を最初に取得しているかもしれない。少数派が正しいこともある。新たに有効になった権限の変更は、キャッシュが更新されるにつれて、しばしば一時的な不一致を生むだろう。最も一般的な出力を選ぶ多数決ルールは、失効の迅速な認識が必要なときにまさに古い権限を保持しうる。

これらの理由から、比較は説明を保持すべきである。レポートは、ソフトウェアとバージョン、TAL 鍵識別子、リポジトリのシリアルまたは取得時刻、マニフェスト状態、検証エラー、出力の相違を示すべきである。そうすれば、オペレータは原因がコード、取得、設定、上流の権限のいずれにあるかを判断できる。出所のないコンセンサスは弱い安全シグナルである。

多数決は、正当な変更の瞬間に特に危険である

一つのネットワークにサービスを提供する三つのバリデータを想像してほしい。二つは証明書失効の前から成功した取得を完了していない。一つは最新のリポジトリ状態を持ち、影響を受けるペイロードを削除する。単純な三分の二ポリシーは、古いビューがより多くの票を持つために、失効された権限を維持するだろう。安全性を向上させるために設計された冗長性が、正当なセキュリティアクションを遅延させるだろう。

事実を逆転させてみよう。二つのバリデータが、共通の欠陥があるために不正形または再送された状態を受け入れ、より厳格な実装がそれを拒否する。多数決は再び誤った結果を選ぶ。インスタンスが統計的に独立しておらず、システムがビザンチン合意プロトコルとして設計されていない場合、数は因果関係の診断を代替できない。

より良い本番設計は、アラート、フェイルオーバー、および範囲を限定した比較に多様性を利用する。ルータは、ベンダーの能力とローカルアーキテクチャに従って、独立して運用されるキャッシュからフィードを受信できる。ネットワークは、通常のサービスでどのインスタンスが権威を持つか、プロセス障害後に別のインスタンスが引き継ぐタイミング、不一致が自動化された変更を凍結するかレビューをトリガーするかを定義できる。安全ポリシーは、新鮮なデータの欠如を検証済みの削除と区別すべきである。

応答は範囲にも依存しうる。一つのプレフィックスに影響する不一致は、すべての検証済みペイロードを放棄することを要求すべきではない。完全なバリデータ停止は、紛争中のオブジェクトとは異なる。トラストアンカーの取得障害は、そのアンカー下での認証された変更とは異なる。きめ細かなテレメトリは、冗長層があらゆる例外を投票に平準化することを防ぐ。

これらの決定をすべてのネットワークにとって正しいものにする普遍的な定足数は存在しない。ルータの統合、リスク許容度、更新間隔は異なる。オペレータは内部的に使用するロジックを公開し、最新状態の変更、古いキャッシュの多数派、不正なオブジェクトの不一致、完全なフィード喪失に対してテストすべきである。バリデータの多様性は、選択動作がインスタンスと同じくらい慎重に設計されて初めて制御となる。

リポジトリの多様性は可用性を保護し、認証する権限を保護しない

RPKI リポジトリシステムは分散している。子 CA は異なるポイントで公開でき、RRDP や rsync が署名付きプロダクトをリライングパーティが利用できるようにする。複数の場所、コンテンツ配信、キャッシュされた有効な状態は、一つのサーバ障害がすべてのデータを直ちに削除する可能性を減らす。それらは本質的な可用性制御である。

署名付きオブジェクトはまた、バリデータがリポジトリの転送を信頼できないものとして扱うことを可能にする。ミラーは黙って ROA を変更し、有効な署名を保持することはできない。マニフェストと失効情報は、リライングパーティが欠落、古い、または置き換えられたコンテンツを検出するのに役立つ。これはアーキテクチャの強みである。分散は、すべての配信サーバが権限であることを要求しない。

同じ特性が限界を定義する。ミラーは、ホルダーの欠落した ROA を発行したり、親が有効に失効させた証明書を復元したり、誤ったリソースセットを訂正したりすることは、認可された署名なしにはできない。十のリポジトリが同じ不利な現在状態を複製できる。それらの独立性は、その状態を抑圧しにくくするが、権限を弱めるわけではない。

リポジトリマネージャ自身が不利な行動をとったり、故障したりすることもある。RFC 8211 はそれらのケースを考慮している。なぜなら、抑圧や置換がリライングパーティが検証する内容に影響を与えうるからである。バリデータの多様性は異なる取得結果の特定に役立ち、リポジトリの多様性は代替アクセスを提供できる。しかし、関連する CA が権威あるマニフェストと失効状態を制御しているなら、分散はその署名された決定に対する独立した制度的チェックを作り出さない。

ガバナンスの対応は、可用性と説明責任を組み合わせることである。公開サービスは有用な場合に運用上分離され、変更は検証可能な受領書を生成し、独立したモニターはハッシュと時刻をアーカイブすべきである。欠落したオブジェクト、古い状態、認証された失効は、異なるイベントとして報告されるべきである。アーカイブは、何がいつ変更されたかを示すことができるが、一方的に代替の権限を作り出すことはできない。

したがって、回復力の主張は層を名指しすべきである。複数サイト公開は配信の回復力を向上させる。独立したバリデータは処理の回復力を向上させる。保護され分割された CA 運用は発行の回復力を向上させる。レビューと上訴はガバナンスの回復力を向上させる。これら四つすべてを分散化と呼ぶことは、それぞれが実際にどの障害を制御するのかを不明瞭にする。

トラストアンカーのロールオーバは、権限が信頼に値するままであって初めて継続性を解決する

長寿命のトラストアンカーキーは、最終的には変更されなければならない。ハードウェアは老朽化し、アルゴリズムは進化し、運用慣行は改善し、侵害の疑いが交換を必要とすることがある。ロールオーバは危険である。なぜなら、リライングパーティはすでに帯域外で設定された鍵素材からブートストラップするからである。急すぎる変更は、検証エコシステムの一部がツリーを見失う可能性がある。

RFC 9691 は、現在と後継の公開鍵およびそれらの証明書の場所を通知できるトラストアンカーキーオブジェクトを導入する。それは受け入れ期間と繰り返しの観測を使用し、リライングパーティが切り替え前に後継を準備できるようにする。この手順は計画されたロールオーバをより秩序的でないものとし、オペレータに後継素材が安定して維持された証拠を提供する。

これは物質的な権限層の改善である。これは、ルートキーの移行は安全策なしに通常のオブジェクト取得に委任できないことを認識している。また、異なるリライングパーティが同じ段階的変更を実装または監視できるため、独立したソフトウェアを支援する。

セキュリティ境界は明示的なままである。RFC 9691 は、そのメカニズムが現在または後継のトラストアンカー秘密鍵の侵害に対して保護しないと述べている。現在の鍵を制御する攻撃者は、悪意のある移行を指示するために必要な権限をすでに持っている。署名された移行を忠実に処理する複数のバリデータは、その制御を無効化しない。

したがって、キーロールオーバは技術メカニズムの周りに制度的制御を必要とする。後継の生成は保護された設備と分割承認を使用すべきである。一般市民は、独立したチャネルを通じて、事前通知、現在と後継のフィンガープリント、予定日、復旧連絡先を受け取るべきである。リライングパーティの開発者はサポートをテストすべきである。同等性が期待される間、モニターは両方の鍵での検証結果を比較すべきである。移行後、古い秘密鍵の破壊または廃止は証拠付けされるべきである。

教訓はロールオーバよりも広範である。暗号手続きは、権限の集中をそのままにしながら、偶発的な不連続に対して権限変更を安全にすることができる。良いガバナンスは、移行が検証されるかどうかと、それを制御する人々、ルール、証拠が十分に制約されているかどうかの両方を問う。

キー保管は所有、承認、監視を分離すべきである

トラストアンカーの秘密鍵は、通常の管理者が単独で不可視的に使用できるべきではないほど強力である。技術的保管は鍵を保護されたハードウェアに置き、エクスポートを制限し、センシティブな操作に複数の認可された参加者を要求できる。組織的保管は、変更を提案する人、それを承認する人、セレモニーを実施する人、結果をレビューする人を分離できる。

これらの制御は別のルートを作り出すわけではないが、一つの侵害されたアカウントや内部者がルート権限を行使するリスクを低減する。また、それらは後のレビューのための証拠を作り出す。証明書発行、リソースセットの変更、またはロールオーバは、承認されたイベント、正確な入力、参加者、生成された出力、独立した公開観測にリンクされるべきである。

しきい値承認は実質的でなければならない。一つの侵害されたアイデンティティサービスを使用した一つの報告ラインからの三つの承認は、故障ドメインを共有しながら分散しているように見えるかもしれない。参加者は異なる責任を代表すべきであり、緊急アクセスは通常のアクセスよりも狭く、より可視的であるべきである。復旧素材は、アクティブキーに課せられた同じ制御を黙ってバイパスすべきではない。

一般市民は秘密鍵素材を検査できないし、すべきでもない。それはガバナンスの証拠を検査できる。現在の認証実践ステートメント、鍵識別子、セレモニーのスケジュール、監査範囲、例外アクションの数、重大な所見、および改善措置である。リソースホルダーは、自分の証明書が変更されたときにより詳細な証拠を受け取ることができる。裁判所と権限ある当局は、適用可能な手続きの下で保護された記録にアクセスできる。

バリデータの多様性はこの構造を補完する。独立した実装とモニターは、公開された効果がセレモニー出力と一致し、予期しない子孫状態が現れなかったことを確認できる。それらは権限の観察者であり続け、分割保管の代替ではない。最も強力な設計は両者を結びつける。制約された発行は監査可能な変更を生み出し、多様なリライングパーティがそれらの変更が意図どおりに伝播することを検証する。

認証は登録に従うため、レジストリ権限はレビュー可能でなければならない

RPKI リソース証明書は、番号リソース割り振り階層と発行機関の権限認識を反映する。基礎となる登録が変更されれば、証明書パスも変わりうる。完全に保護された鍵でも、誤った、過剰に広範な、または争われているレジストリ決定を実行することができる。鍵の保護は不正使用に対処するが、健全なポリシーや裁定を保証しない。

したがって、制度的制御は署名の前に始まるべきである。証明書からリソースを削除する権限は明示的であるべきである。通常の返却、承認された移転、契約終了、不正の是正、裁判所命令、緊急セキュリティ対応は異なる根拠である。それぞれは証拠、決定権、合法的な場合の通知ルール、範囲、発効時刻、レビューを持つべきである。

決定に異議を唱えるホルダーは、単に CA 署名が有効であることを確認するだけでなく、登録基盤を審査できるフォーラムを必要とする。レビューは、初期決定を行った従業員や組織から独立しているべきである。緊急の継続性手段は、紛争が検討されている間ルーティングを維持するかもしれないが、最終的なホルダー状態を黙って書き換えるべきではない。

公開は、保護された証拠を開示することなく説明責任を支援するレベルで、理由コードまたはリンクされた公開通知を伴うべきである。バリデータは失効を処理するために非公開のケースファイルを必要としない。オペレータと影響を受けるホルダーは、変更が予定されていたのか、是正措置なのか、セキュリティ関連なのか、法的に制限されているのかを知り、適切な救済を求めることができる必要がある。

ここで、制度的正当性がルートセキュリティに入り込む。より多くのネットワークが起点検証に依存するほど、上流の登録および認証の決定はより重大な結果をもつ。強化された技術的執行は、より強力な適正手続きによって対応されるべきであり、独立したバリデータコードがすでに権限を分散させたという主張によってではない。

ローカル例外は自律性を維持するが、共有シグナルを断片化しうる

RFC 8416 は、RPKI を使用した簡略化されたローカルインターネット番号リソース管理を定義している。これにより、オペレータは、対処されている間の不利なアクションからの保護を含め、自らのローカルビューでアサーションをフィルタリングまたは追加できる。これは、リライングパーティがグローバルな公開状態から制限された自律性を必要とする可能性があることを明示的に認識したものである。

SLURM は、明白なエラーの際に価値を持つことがある。信頼できる直接的な証拠を持つネットワークは、CA が偶発的な失効を修正する間、自らとその顧客の到達可能性を維持できる。ローカルアサーションは、グローバル RPKI がすでに修正を含んでいるふりをすることなく、レビューされ、期限切れになり、削除されうる。

この制御はグローバルな治療法ではない。ローカル例外は他のオペレータが検証する内容を変えない。多くのネットワークが異なる上書きを作成すれば、RPKI 結果の共有された意味は断片化する。悪意のあるまたは不注意なオペレータはまた、グローバル階層が承認しないルートを承認するためにローカル追加を使用できる。例外メカニズムは責任をローカルネットワークに移す。

バリデータの多様性はそのポリシー問題を解決しない。異なる実装は、すべて同じローカルファイルを正しく適用しながら、グローバルリポジトリとは異なる出力を生成するかもしれない。比較レポートはローカルアサーションを特定しなければならない。さもなければ、オペレータは意図的な上書きを実装の欠陥や独立した権限と誤解するおそれがある。

健全な例外ポリシーは、証拠、狭いプレフィックスと ASN の範囲、指名された承認、開始と期限切れ、影響を受ける顧客、レビューと削除基準を必要とする。緊急使用は、恒常的なシャドウ認証になるのではなく、権威ある修正の追求をトリガーすべきである。オペレータは、センシティブな詳細を不必要に暴露することなく、ピアや監査人に違いを説明できるべきである。

ローカル自律性はこのように安全弁である。それは一つのネットワークにとって即時の上流の救済への依存を減らすが、修正された権威あるチェーンだけが回復できる一貫したグローバルな認可を提供することはできない。

制約されたトラスト選択は可能だが、調整コストを伴う

RFC 8630 は、トラストアンカー発行者に幅広い信頼を置くことを望まないリライングパーティは、独自の自己署名証明書をトラストアンカーとして発行し、下位の証明書に制約を課すことができると述べている。原則として、ローカルトラスト設定は、外部アンカーが受け入れられる対象範囲を狭めることができる。

このオプションは、リライングパーティが形而上学的にベンダーデフォルトに拘束されていないことを示す。彼らは自分が検証する起点となるアンカーを選択する。大規模なオペレータやコンソーシアムは、追加の制約、独立した配布、レビューを維持できる。そのような措置は、アンカーが期待されるセットを超えるリソースを主張することの影響を制限しうる。

代償は調整である。ローカルに制約されたアンカーは、地域のリソース保有と移転の正当な変更を追跡しなければならない。古い制約は、リソースが移動した後に有効な認証を拒否しうる。異なる制約セットは、ネットワークが異なるペイロードを導出する原因となりうる。それらを維持する機関は、自身の権限と運用負担を取得する。

同じリソースに対して複数の競合するトラストルートを作成すると、さらに難しい問題が生じる。それらが一致しない場合、どのルートが優先するのか？廃れたまたは乗っ取られたルートが権限を保持するのを許容し、一つの有効なパスで十分なのか？多数決が必要であり、古い多数派の失敗のリスクを負うのか？誰がルートを参加させ、削除するのか？暗号技術はそれらの憲法的選択に単独で答えることはできない。

短期的な目標は、それ自体のための増殖であるべきではない。それは、一貫した検証シグナルを維持しながら、現在の階層内でレビュー不能な権限を最小化することであるべきである。強力なトラストアンカー運用、範囲を限定したリソース主張、透明な変更、独立した監視、ローカルな緊急制御、信頼できる上訴は、未解決のマルチルート競争を発明することなく、集中リスクを低減できる。

代替権限モデルの研究は依然として価値がある。いかなる提案も、競合解決、移転、緊急アクション、鍵侵害、法的強制、離脱を明示すべきである。それらのケースに答える前に設計が分散化されていると呼ぶことは、バリデータの数が権限の数として扱われるときになされたのと同じ過ちを繰り返すだろう。

オペレータは冗長性を購入する前に層のマップを必要とする

回復力のあるデプロイメントは、六つの層にわたって評価できる。第一はブートストラップである。TAL キー、それらの取得、パッケージソース、更新権限。第二は発行である。トラストアンカーと下位 CA キー、承認、登録決定。第三は公開である。マニフェスト、失効リスト、署名付きオブジェクト、RRDP、rsync、リポジトリ可用性。第四は検証である。コードベース、ライブラリ、キャッシュ、バージョン、例外条件の動作。第五はルータへの配信である。RPKI-to-Router セッション、フェイルオーバー、古さのルール。第六はルーティングポリシーである。Valid、Invalid、NotFound 状態がルート選択にどのように影響するか。

二つのバリデータを購入することは、主に第四層とおそらく第五層を変える。それらを別々の場所で実行することは、可用性の分離を追加する。階層が許すところで独立したリポジトリを使用することは第三層を改善する。いずれも自動的にブートストラップや発行を変更しない。共通の TAL 更新チャネル、一つの RIR CA、一つの登録決定は共有されたままでありうる。

棚卸は、共通の依存関係を明示的に特定すべきである。両方のバリデータは一つのホスト上の仮想マシンか？それらは DNS、電源、ネットワークトランジットを共有しているか？一つのキャッシュを読み取っているか？ルータセッションは自動的にフェイルオーバーするか？両方のパッケージは同じバンドルされた TAL 更新を受け取るか？同じ暗号ライブラリを使用しているか？どのチームがローカル例外を変更できるか？

テストはそのマップに従うべきである。一つの実装をクラッシュさせる。実験室設定で不正なオブジェクトを与える。一つのリポジトリビューを遅延させる。制御された環境で TAL をローテートする。ペイロードを正当に削除し、古い多数派ロジックがそれを復元しないことを検証する。完全なフィード喪失と復旧を実行する。どの層が各障害を検出して封じ込めたかを記録する。

結果は防御可能な回復力の主張である。オペレータは、地域認証局が共通のままであることを認めつつ、単一のバリデータプロセス、ホスト、メンテナンスイベントがその検証済みフィードを削除しないと言うことができる。正確な主張は正確な改善を招くが、分散化の広範な主張は調査をあまりに早く終わらせる傾向がある。

独立した比較はブランドを採点するのではなく、乖離を説明すべきである

公開比較サービスは、バリデータ出力をリーグテーブルに変えることを避ければ、エコシステムを強化できる。そのタスクは、特定されたリポジトリのスナップショットとライブ取得に対してメンテナンスされた実装を実行し、設定を保持し、開発者とオペレータが再現するのに十分な証拠とともに相違を報告することである。

有用な単位は検証イベントである。どのトラストアンカーがアクティブだったか？どのオブジェクトまたは公開ポイントが不一致を生み出したか？実装は同じバイトを取得したか？一つがキャッシュされた以前の状態を使用したか？どの RFC ルールまたはローカルポリシーが適用されたか？どのペイロードの違いがルータに到達したか？問題は修正されたか、どのバージョンでか？

集計された数はメンテナンスを支援できるが、分母と重大度が必要である。一つの不正形のテストオブジェクトに影響するパーサ拒否は、地域ツリーの欠落とは異なる。トランスポートタイムアウトは、失効された証明書の受け入れとは異なる。サービスは、参加者からグローバルなデプロイメントシェアを推測したり、一ヶ月の選択されたテストをあらゆる本番環境の状態として記述すべきではない。

開発者は証拠をもって応答する権利を持つべきである。オペレータは、RIPE NCC が引退したバリデータに対して行ったように、実装がもはやメンテナンスされていないときに警告されるべきである。セキュリティ上センシティブな詳細は、完全な公開の前に調整された開示を必要とするかもしれない。独立性は、比較サービスが一つのバリデータベンダーまたは一つの発行機関だけによって資金提供または統治されることができないことを意味する。

そのようなサービスはソフトウェアの多様性をより良くする。共有ライブラリ、相関する障害、標準の曖昧さを特定できる。また、権限の境界を可視化する。すべての実装が一つの認証された親のアクションから同じ不利な結果を生成する場合、レポートは全会一致を称賛するのではなく、発行者とレビュープロセスに注意を向けるべきである。

番号資源社会はコードと権限の間の境界を監査できる

将来の番号資源社会は、各層を名指しし、ある層が別の層の代わりをすることを許さない保証基準を定義することによって貢献できる。バリデータの多様性を主張するプロバイダーは、コードベース、バージョン、ホスティングの分離、TAL 取得、共有依存関係、比較方法、ルータフィードロジック、例外ポリシーを開示するだろう。これらの制御が独立した認証ルートを作り出すことを暗示することは許されないだろう。

トラストアンカーと RIR CA について、NRS は異なる証拠セットを定義できる。現在の鍵識別子、リソース主張の範囲、保管モデル、承認分離、ロールオーバ計画、例外的な変更手続き、リポジトリの継続性、公開通知、独立した観察、上訴経路、是正履歴である。目的は NRS にすべての秘密鍵を渡すことではない。それは上流の権限の行使を評価可能にすることである。

NRS はまた、変更レシートを標準化できる。レシートは、理由区分、影響を受けるリソースセット、以前と新しい証明書識別子、認可機関、発効時刻、公開証拠、レビュー状況を結びつけるだろう。バリデータまたはモニターは、変更が可視化されたときを示す観測を添付できる。影響を受けたホルダーは、全員が署名された内容に同意している間に、指定されたフォーラムを通じて登録基盤に異議を唱えることができる。

この役割は、テストされていないスーパールートを作り出すことなく説明責任を拡大するため、肯定的である。NRS は独立した比較プロバイダーを認定し、適合事例を公開し、重要な所見の後で是正措置を要求できる。会員代表は、ホルダーとオペレータを標準レビューに参加させることができる。資金と利害相反は開示されなければならず、大手レジストリ、ベンダー、ネットワークが保証を推奨に変えることができないようにする。

このモデルは依然として予測的である。公開された NRS の資料は、分散参加と制限された制度的権限を目標として支持するが、このトラストアンカー保証システムがすべての地域でデプロイされているか、認識されているかを確立するものではない。信頼性は、パイロット、外部監査、公開された例外、ソフトウェアプロバイダーと発行機関の両方を批判する意欲に依存するだろう。

測定はソフトウェアの普及率を権限への露出と分離しなければならない

本番バリデータデプロイメントの完全な公開分母は存在しない。オペレータはプライベートインスタンスを実行したり、ベンダー統合サービスを使用したり、検証をアウトソースしたり、上流から検証済みルートを受信することができる。ダウンロード数はアクティブなネットワーク数と等しくない。公開ルータ観測は、どのリライングパーティ実装がポリシー決定を生成したかを確実に明らかにしない。

したがって、レポートは、測定がその分母を裏付けない限り、一つの実装がインターネットの一定の割合にサービスしているといった主張に抵抗すべきである。調査は、何件の応答ネットワークが Routinator、rpki-client、FORT、または別のサービスを使用しているかを述べることができる。それを黙ってすべての自律システムに一般化することはできない。テストプラットフォームは、どのバージョンを比較したかを述べることができる。そこから、デプロイされたすべてのバージョンが同じように振る舞うと推測することはできない。

権限への露出には異なる尺度が必要である。バリデータは各ペイロードを生成したトラストアンカーをリストアップでき、オペレータは設定されたアンカーごとに自らのローカル検証セットのシェアを報告できる。それでもガバナンスの質や不利なアクションの確率を測定するわけではない。リソース数、ルート数、トラフィック依存度は異なる分母である。

運用指標は障害に結びつけられるべきである。インスタンスごとの検証サイクルの成否、リポジトリの新鮮さ、出力の乖離、TAL 変更、ルータフィードの可用性、古い状態の持続時間、ローカル例外、修正までの時間。権限指標は、例外的な証明書変更、ロールオーバのパフォーマンス、監査所見、上訴、改善措置を含むべきである。両者を一つの多様性スコアに統合することは因果関係を消去するだろう。

最も有用なレポートは、ソフトウェアの回復力は強いが権限レビューは弱いままであると結論づけるかもしれない。別のレポートは、健全な CA ガバナンスだが危険なバリデータのモノカルチャーを見つけるかもしれない。層状の測定は、機関が実際の欠陥を修正することを可能にする。単一の分散化バッジは、エンジニアリングではなくプレゼンテーションに報いる。

次のアーキテクチャは、主権ルートを増やす前にチェックを多様化すべきである

RPKI 権限階層が進化すべきかどうかについて、真の憲法的な疑問がある。地域トラストアンカーは割り振り構造を反映し、検証のための一貫した基盤を提供するが、Invalid ルートがより広く拒否されるにつれて、その権限はより重大な結果をもつ。ソフトウェアの多様性だけでは答えにならない。不一致に対するルールなしに安易にルートを追加することも同様である。

短期的な改革は、現在の権限を巡るチェックを多様化できる。独立したモニターは変更をアーカイブできる。ホルダーは署名された通知を受け取ることができる。例外的なアクションは分割承認を要求できる。上訴は制度的に分離されうる。鍵セレモニーとロールオーバの証拠は公開されうる。ローカルな緊急例外は管理され、期限付きにできる。地域間移転は共通のレシートを使用できる。バリデータ実装は独立したままであり、継続的に比較されうる。

より長期的な提案は、制約付きルート、クロス署名、しきい値権限、その他のモデルを使用するかもしれない。それぞれは、正当なリソース移転がどのように権限を変えるか、侵害された参加者がどのように除去されるか、競合する認証がどのように解決されるか、法的命令がどのように範囲を定められるか、リライングパーティがどのように収束するかを説明しなければならない。廃れた権限を終了できない冗長性は、階層よりも危険になりうる。

設計目標はルート数の最大化ではない。ルート起点検証が有用であり続けるのに十分な一貫性を備えつつ、説明責任のない制御を最小化することである。システムはいくつかのルートを持ちながら、各リソースに対する権限を依然として集中させうる。一つのリソースに一つのパスを持ちながら、そのパスを強力な手続きチェックで取り囲むこともできる。ラベルは実際の障害分析に従うべきである。

NRS は、制度的勝利を宣言するのではなく、前提、競合する設計、テスト結果を公開することで、この議論を建設的に主催できる。RIR、オペレータ、ホルダー、バリデータ開発者、ルーティングベンダーは、それぞれ必要な証拠の一部を持っている。どの単一グループのソフトウェアや証明書も、憲法的な答えを単独で定義すべきではない。

正しい主張はより狭く、より強い

複数のメンテナンスされたバリデータを実行するオペレータは、放置された一つのインスタンスに依存するオペレータよりも、ある種の障害に対して安全である。独立したコードと運用は、欠陥を検出し、メンテナンス中もサービスを維持し、曖昧なリポジトリ状態を露呈できる。それらは重要な利得であり、測定されるべきである。

オペレータは、設定されたトラストアンカーとそれらの認証階層に依存し続ける。与えられたリソースについて、複数のバリデータは通常、同じアクティブなルートパスから導出された権限を検証する。親チェーンが有効に変更されれば、正しいバリデータはそれに従う。ルートキーが侵害されれば、ソフトウェアの多様性は信頼できる発行を復元しない。レジストリ決定が争われれば、パーサの合意は適正手続きを提供しない。

応答は RPKI に対するシニシズムではない。起点検証は、BGP 単独では欠けている有用な暗号ステートメントを提供する。その増大する運用上の重みこそが、権限層が明示的なガバナンスに値する理由である。技術的成功は、上流の権限を隠蔽するのではなく、その精査を強化すべきである。

最も強力なデプロイメントは、両方の種類の制御を組み合わせる。多様なリライングパーティソフトウェアが、信頼できないコンテンツを独立してチェックする。トラストアンカーと CA 運用は、保護された鍵、分割された権限、安全なロールオーバを使用する。登録変更は理由付けられ、レビュー可能である。公開は回復力があり、観察可能である。ルータフィードポリシーは、古い状態や分岐した状態を意図的に処理する。ローカル例外は制限されたままである。外部保証レポートは、ある層を別の層で代替することなく、各層について報告する。

バリデータの多様性は、一つのトラスト階層が正しく解釈されていることを確認できる。それはその階層を複数にすることはできない。制度的正当性は、システムがそれを率直に述べ、権限が実際に存在する場所に欠けているチェックを構築するときに始まる。

出典