バリデータ多様性は単一の RPKI トラストアンカーを救えない

要約

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

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

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

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

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

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

これが、3つのバリデータ製品を購入する調達計画が分散化を過大評価できる理由である。それは1つの設定された権限に対する3つの計算上の証人を作成する。それは有用な回復力であるが、証明力の3つの独立した情報源ではない。

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

本番の依拠者ソフトウェアには通常、5つの地域インターネットレジストリ（AFRINIC、APNIC、ARIN、LACNIC、RIPE NCC）のトラストアンカーロケーターが含まれている。RFC 8897は、各依拠者がトラストアンカーを選択し、IANA と5つの RIR を番号リソース割り当て階層と一致する明白なデフォルト候補として識別すると述べている。Routinator と FORT のドキュメントは、通常の設定で5つの RIR TAL を示している。

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

集中は、分析の単位がリソースになると再び現れる。プレフィックスは通常、その割り当てをカバーするトラストアンカーから降りる証明書パス内にある。そのホルダーは、オペレーターが3つのバリデータを実行しているという理由だけで、3つの無関係な RIR ルートに3つの同等に権威のある証明書を発行するように依頼することはできない。正当な地域間移行中、パスは一時的に変更または重複する可能性があるが、それは日常的なマルチルート投票ではなく、制御された例外である。

したがって、ソフトウェアの多重性は依拠者層で水平に動作し、認証権限は垂直に組織される。たとえば、複数のバリデータが APNIC ツリーをトラバースできるが、APNIC のルート決定を5つの地域決定に変換するわけではない。リソースが別の地域に移動すると、権限パスは転送取り決めを通じて変更される。バリデータ数は移動を引き起こさない。

この区別により、より正確なリスクステートメントが可能になる。グローバルシステムには地域分離がある。リソースのアクティブパス内では、親権限はそれに依存するすべての子孫オブジェクトに影響を与える可能性がある。CA 証明書の失効により、依拠者が下位の署名オブジェクトを無効にする可能性がある。独立したバリデータは、その結果を見事な一貫性で確認できる。それらの同意は、設計どおりに機能する集中権限を示しており、分散権限ではない。

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

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

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

エコシステムは、ソフトウェアの管理が変わることをすでに示している。2021年に RIPE NCC はバリデータのサポートを終了し、未保守のコードを使い続けるのではなく、代替手段に移行するようオペレーターにアドバイスした。この決定は RPKI 権限を弱めるものではなく、依拠者ソフトウェアは独立したエコシステムによって供給されるべきであることを認めたものである。

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

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

共通の信頼入力は独立した判断の境界を定義する

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

RFC はまた、侵害の重大性を述べている。トラストアンカー秘密鍵を持つ攻撃者は権限になりすますことができる。不適切または不正確なトラストアンカーへの依存は、同様に深刻な結果をもたらす可能性がある。発行者は TAL キーを再配布することなく証明書のリソースセットを変更できる。これは地域リソースの保有が変化するために必要な柔軟性である。同じ設計は、依拠者が発行者の抑制にかなりの信頼を置くことを意味する。

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

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

この境界は、オペレーターに実用的な在庫質問を提供する。各バリデータインスタンスについて、どの TAL 鍵が設定されているか、どのように取得されたか、誰がそれらを更新できるか、どのソフトウェアパッケージがアップグレード中にそれらを変更できるか。3つのインスタンスが1つの無人パッケージチャネルを通じて TAL 変更を受け取る場合、それらの見かけの独立性には共有されたブートストラップ依存関係が含まれる。コードベースは異なる可能性があるが、ルート設定は運用上集中したままである。

バリデータは有害であるという理由だけで有効な有害行為を無効にすることはできない

RFC 8211は、リソースホルダーに害を及ぼす可能性のある認証局とリポジトリマネージャーによる行動を分析している。原因は攻撃、ミス、ポリシー行動、法的強制である可能性がある。親は CA 証明書を失効させることができ、その結果、依拠者は下位の署名オブジェクトを無効として扱う。競合する ROA や変更されたリソースセットもルーティング結果を変更する可能性がある。

ホルダーの観点からは、影響は深刻である可能性がある。バリデータの観点からは、タスクは依然として受け入れられた証明書状態を正しく処理することである。適切に署名された現在の失効が設定されたチェーンの下に表示され、検証規則を満たす場合、バリデータは公開声明が不公平を主張しているという理由だけでそれを無視する権限はない。そうすることは、各ソフトウェア保守者を上訴レジストリに変えることになる。

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

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

救済策は権限層で機能しなければならない：例外的な証明書変更に対する分割承認、可能な場合は通知、正確な理由、独立したレビュー、上訴、継続措置、および履歴を消去せずに間違いを修正する方法。技術的検出はそれらの制御をサポートする。それらを置き換えるわけではない。

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

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

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

計算上の一致でさえ限界がある。インスタンスは暗号ライブラリ、オペレーティングシステムコンポーネント、リポジトリキャッシュ、TAL パッケージ、ネットワークパス、更新スケジュールを共有する可能性がある。2つのブランド製品が同じパーシング依存関係を継承する可能性がある。3台のサーバーが1つのローカルミラーにクエリを実行する可能性がある。多様性は製品数ではなく障害ドメインで評価されるべきである。

不一致も曖昧である。1つのインスタンスは古く、1つは新しい RFC を実装し、1つは不正なコンテンツを拒否し、1つは現在の失効を最初に取得した可能性がある。少数派が正しい可能性がある。新しく有効な権限変更は、キャッシュが更新されるにつれて一時的な不一致を生じることが多い。最も一般的な出力を選択する多数決ルールは、失効の迅速な認識が要求されるまさにその時に古い権限を維持する可能性がある。

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

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

3つのバリデータが1つのネットワークにサービスを提供していると想像してほしい。2つは証明書の失効以来、正常な取得を完了していない。1つは現在のリポジトリ状態を持ち、影響を受けるペイロードを削除する。単純な2対1のポリシーは、古いビューがより多くの票を持つため、失効した権限を維持する。安全性を改善するために設計された冗長性は、正当なセキュリティ行動を遅らせることになる。

事実を逆にする。2つのバリデータは欠陥を共有するため、不正な形式または再生された状態を受け入れるが、より厳格な実装はそれを拒否する。多数決は再び間違った結果を選択する。インスタンスが統計的に独立しておらず、システムがビザンチン合意プロトコルとして設計されていない場合、数は因果診断の代わりにはならない。

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

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

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

リポジトリの多様性は可用性を保護し、証明する力ではない

RPKI リポジトリシステムは分散されている。子 CA は異なるポイントで公開でき、RRDP や rsync は署名された製品を依拠者が利用できるようにする。複数の場所、コンテンツ配信、キャッシュされた有効状態は、1つのサーバー中断がすぐにすべてのデータを削除する可能性を低減する。それらは不可欠な可用性制御である。

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

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

リポジトリマネージャー自身が有害に行動するか、失敗する可能性がある。RFC 8211は、抑制や置換が依拠者の検証に影響を与える可能性があるため、それらのケースを考慮している。バリデータの多様性は異なる取得結果を識別するのに役立ち、リポジトリの多様性は代替アクセスを提供できる。しかし、関連 CA が権威あるマニフェストと失効状態を制御している場合、配布はその署名決定に対する別個の制度的チェックを生み出さない。

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

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

トラストアンカーロールオーバーは、権限が信頼できるままである場合にのみ継続性を解決する

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

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

これは重要な権限層の改善である。ルート鍵の移行を安全策なしに通常のオブジェクト取得に委任できないことを認識している。また、異なる依拠者が同じステージングされた変更を実装または監視できるため、独立したソフトウェアをサポートする。

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

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

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

鍵管理は所持、承認、観察を分離すべきである

トラストアンカー秘密鍵は、日常の管理者がそれを単独で目に見えない形で使用できるべきではないほど強力である。技術的管理は、鍵を保護ハードウェアに配置し、エクスポートを制限し、機密操作に複数の認可参加者を要求することができる。組織的管理は、変更を提案する人、承認する人、式典を実施する人、結果をレビューする人を分離することができる。

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

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

一般は秘密鍵素材を検査できないし、すべきでもない。しかし、ガバナンス証拠（現在の証明書実践声明、鍵識別子、式典スケジュール、監査範囲、例外的アクション数、重要な調査結果、是正措置）を検査できる。リソースホルダーは、証明書が変更された際により詳細な証拠を受け取ることができる。裁判所と権限のある当局は、適用手続きの下で保護された記録にアクセスできる。

バリデータの多様性はこの構造を補完する。独立した実装とモニターは、公開された効果が式典の出力と一致し、予期しない子孫状態が出現しなかったことを確認できる。それらは権限の観察者であり続け、分割管理の代わりではない。最も強い設計は両方を接続する：制約された発行は監査可能な変更を生成し、多様な依拠者はそれらの変更が意図したとおりに伝播することを検証する。

レジストリの権限は登録が認証に先行するため、レビュー可能でなければならない

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

したがって、制度的制御は署名の前に始めるべきである。証明書からリソースを削除する権限は明示的であるべきである。日常的な返却、承認された転送、契約終了、詐欺訂正、裁判所命令、緊急セキュリティ対応は異なる根拠である。それぞれに証拠、決定権、可能な場合は通知規則、範囲、有効時間、レビューが必要である。

決定に異議を唱えるホルダーは、登録根拠を審査できるフォーラムを必要とし、単に CA 署名が有効であることを確認するのではない。レビューは、最初の決定を下した従業員または機関から独立しているべきである。緊急継続措置は紛争が検討されている間、ルーティングを維持するかもしれないが、最終的なホルダー状態を静かに書き換えるべきではない。

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

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

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

RFC 8416は、RPKI による簡略化されたローカルインターネット番号リソース管理（SLURM）を定義している。これにより、オペレーターはローカルビューでアサーションをフィルタリングまたは追加できる。これは、対応中に有害な行動からの保護として含まれる。これは、依拠者がグローバル公開状態から制限された自律性を必要とする可能性があるという明示的な認識である。

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

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

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

健全な例外ポリシーには、証拠、狭いプレフィックスと ASN 範囲、名前のある承認、開始と期限、影響を受ける顧客、レビューと削除基準が必要である。緊急使用は、恒久的な影の認証になるのではなく、権威ある訂正の追求をトリガーするべきである。オペレーターは、不必要に機密詳細を公開することなく、ピアや監査人に違いを説明できるべきである。

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

制約された信頼選択は可能であるが、調整コストがかかる

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

このオプションは、依拠者がベンダーのデフォルトに形而上学的に拘束されないことを示している。彼らは検証するアンカーを選択する。大規模オペレーターやコンソーシアムは、追加の制約、独立した配布、レビューを維持できる。そのような措置は、アンカーが予想されるセットを超えてリソースを主張する効果を制限する可能性がある。

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

同じリソースに対して複数の競合する信頼ルートを作成することは、さらに難しい問題を提起する。それらが一致しない場合、どのルートが優先されるか？1つの有効なパスで十分であり、廃止されたまたは捕獲されたルートが権限を維持できるようにするか？クォーラムが合意する必要があり、古い多数決の失敗のリスクがあるか？誰がルートを追加し削除するか？暗号はそれらの憲法上の選択を単独で答えることはできない。

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

代替権限モデルの研究は依然として価値がある。どの提案も、紛争解決、転送、緊急行動、鍵侵害、法的強制、終了を指定すべきである。それらのケースに答える前に設計を分散型と呼ぶことは、バリデータ数が権限数として扱われるときと同じ間違いを繰り返すことになる。

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

回復力のある展開は、6つの層にわたって評価できる。1つ目はブートストラップ：TAL 鍵、その取得、パッケージソース、更新権限。2つ目は発行：トラストアンカーと下位 CA 鍵、承認、登録決定。3つ目は公開：マニフェスト、失効リスト、署名オブジェクト、RRDP、rsync、リポジトリ可用性。4つ目は検証：コードベース、ライブラリ、キャッシュ、バージョン、例外条件動作。5つ目はルーターへの配布：RPKI-to-Router セッション、フェイルオーバー、陳腐化ルール。6つ目はルーティングポリシー：有効、無効、NotFound 状態がルート選択にどのように影響するか。

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

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

テストはマップに従うべきである。1つの実装をクラッシュさせる。実験室環境で不正なオブジェクトを供給する。1つのリポジトリビューを遅延させる。制御された環境で TAL を回転させる。ペイロードを正当に削除し、古い多数決論理がそれを復元しないことを確認する。完全なフィード損失と回復を実行する。各障害を検出し封じ込めた層を記録する。

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

独立した比較はブランドをスコアリングするのではなく、相違を説明すべきである

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

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

集計数はメンテナンスをサポートできるが、分母と重大度が必要である。1つの不正なテストオブジェクトに影響するパーサー拒否は、欠落した地域ツリーとは異なる。トランスポートタイムアウトは、失効した証明書の受け入れとは異なる。サービスは参加者からグローバル展開シェアを推測したり、1か月の選択テストをすべての運用条件として説明すべきではない。

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

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

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

番号資源社会（NRS）は、各層に名前を付け、1つが別の層の代わりになることを拒否する提案された保証基準を公開することに貢献できる。バリデータの多様性を主張するプロバイダーは、コードベース、バージョン、ホスティング分離、TAL 取得、共有依存関係、比較方法、ルーターフィードロジック、例外ポリシーを開示する。これらの制御が独立した認証ルートを作成することを暗示することは許されない。

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

NRS はまた、発行機関と独立モニターが採用する標準変更領収書を提案できる。領収書は、理由クラス、影響を受けるリソースセット、以前および新しい証明書識別子、承認機関、有効時間、公開証拠、レビューステータスをバインドする。バリデータまたはモニターは、変更が可視になった時を示す観察を添付できる。影響を受けるホルダーは、署名されたものについて全員が同意しながら、指定されたフォーラムを通じて登録根拠に異議を唱えることができる。

この役割は、未テストのスーパールートを作成せずに説明責任を拡大するため、前向きである。NRS は、独立に資格のある比較プロバイダーを推進し、ソースに基づく比較を公開できる。認定と訂正命令は権限のある当局を必要とする。NRS はどちらも発行できない。メンバーシップ代表は、ホルダーとオペレーターを標準レビューに参加させることができる。資金と利益相反は開示されなければならず、主要なレジストリ、ベンダー、ネットワークが保証を推奨に変換できないようにする。

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

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

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

したがって、レポートは、測定がその分母をサポートしない限り、1つの実装がインターネットの固定シェアを提供するなどの主張に抵抗すべきである。調査は、応答ネットワークのうちいくつが Routinator、rpki-client、FORT、または別のサービスを使用しているかを述べることができる。すべての自律システムに暗黙的に一般化することはできない。テストプラットフォームは、どのバージョンを比較したかを述べることができる。展開されたすべてのバージョンが同じように動作すると推測することはできない。

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

運用指標は障害に結び付けられるべきである：インスタンスごとの検証サイクル成功率、リポジトリの鮮度、出力の相違、TAL 変更、ルーターフィード可用性、陳腐化期間、ローカル例外、修正時間。権限指標には、例外的証明書変更、ロールオーバー性能、監査結果、上訴、是正措置が含まれるべきである。2つを1つの多様性スコアに結合すると、因果関係が消去される。

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

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

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

短期的な改革は、現在の権限の周りでチェックを多様化できる。独立したモニターは変更をアーカイブできる。ホルダーは署名された通知を受け取ることができる。例外的な行動は分割承認を必要とすることができる。上訴は制度的に分離できる。鍵式典とロールオーバー証拠は公開できる。ローカル緊急例外は統治され、期限付きにできる。地域間転送は共通領収書を使用できる。バリデータ実装は独立して維持され、継続的に比較できる。

より長期的な提案は、制約されたルート、相互署名、閾値権限、または他のモデルを使用するかもしれない。それぞれは、正当なリソース転送がどのように権限を変更するか、侵害された参加者がどのように削除されるか、競合する認証がどのように解決されるか、法的命令がどのように範囲指定されるか、依拠者がどのように収束するかを説明しなければならない。廃止された権限を終了できない冗長性は、階層よりも危険である可能性がある。

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

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

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

複数の保守されたバリデータを実行するオペレーターは、1つの無視されたインスタンスに依存するオペレーターよりもあるクラスの障害から安全である。独立したコードと運用は欠陥を検出し、メンテナンス中にサービスを維持し、曖昧なリポジトリ条件を公開できる。これらは実質的な利益であり、測定されるべきである。

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

応答は RPKI に対する皮肉ではない。起点検証は、BGP 単独では欠如していた有用な暗号ステートメントを提供する。その運用上の重みが増大していることは、まさに権限層が明示的なガバナンスを必要とする理由である。技術的成功は、上流の権限を隠すのではなく、精査を増加させるべきである。

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

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