要約

  • RPKI の可用性はエンドツーエンドの特性であり、サーバーのヘルスチェックがグリーンでも、外部のバリデータが古い、不完全、矛盾した、または暗号的に使用不可能な資料を受け取る可能性がある。
  • 短時間の中断は、依拠当事者が以前に検証したオブジェクトをキャッシュしているため、経路検証に影響を与えないとは限らない。しかし、マニフェストや証明書失効リスト（CRL）の nextUpdate 時刻を超過した場合や、証明書の有効期限が切れた場合、または必要な変更が外部から見えなくなった場合、その中断は重大になる。
  • 公表されているインシデントは、異なる障害クラスを示している。2019年には APNIC が rsync の不整合を報告しつつ RRDP は有効であり、2020年には RIPE NCC がサイレント公表障害の後に失効した CRL を報告し、2021年には親子証明書の不整合な公表を報告した。2022年には JPNIC が公表が停止しフレッシュネスフィールドが経過した後に ROA が NotFound になったと報告した。
  • 信頼できるサービスコミットメントは、独立したネットワークからの成功したフェッチ、プロトコル固有の完全性、暗号的な有効性、フレッシュネスヘッドルーム、検証されたペイロードの変更、リカバリーコンバージェンス、および関連する経路検証の変更を測定すべきである。
  • アトリビューション（原因帰属）は、認可された変更から証明書の生成、公表、外部取得、検証、ルーターへの配信、経路ポリシーに至るまでの時刻順の記録を必要とする。このチェーンがなければ、レジストリ、リポジトリ、ソフトウェアベンダー、ネットワーク事業者が互いに責任をなすりつける可能性がある。
  • 経路への影響は、リポジトリの障害だけから推測できない。事業者はローカルポリシーを選択し、異なるソフトウェアやリフレッシュ間隔を使用し、異なる BGP パスを観測する。報告は観測対象集団を明記し、不明点は不明のまま残すべきであり、普遍的な停止率を主張すべきではない。
  • NRS（Number Resource Society）は、中立的なプローブ、共通のインシデントフィールド、外部から再現可能な保証基準を主催することで、レジストリの正当性を強化できる。NRS の積極的な貢献は、限定的な組織的主張をテスト可能にすることであり、すべてのリポジトリ中断が顧客損失を引き起こしたと宣言することではない。

停止はサーバールームではなく、依拠当事者から始まる

RPKI の決定的なイベントは、リポジトリオペレーターのコンソール上の赤いランプではない。それは、ネットワークが経路起点の決定を下す際に基礎とする資料を、外部の依拠当事者が取得・検証できないことである。二つの事象は同時に起こりうるが、同一ではない。

リポジトリオペレーターは、健全なプロセス、開いているソケット、ローカルでの成功したリクエストを観測しながら、他のユーザーが DNS 障害、壊れたコンテンツ配信ノード、TLS の不一致、不完全な rsync ツリー、RRDP セッションの不整合、または有効なパスを形成しない署名付きオブジェクトセットに遭遇することがある。逆に、キャッシュされた資料が使用可能で緊急の更新がなければ、リポジトリが数時間到達不能でも、事業者が保持する検証済みビューは変わらないこともある。

この区別は単なる技術的な句読点ではない。ポリシー文書では、可用性を機械の特性として、稼働時間を月間の分数で割ったものとして扱うことが多い。RPKI は分散型のセキュリティ判断に組み込まれた公表サービスである。その有用な出力は、検証されたアサーションの集合であり、応答するウェブページではない。したがって、リポジトリのエッジで止まる測定は、事業者が自分自身にサービスを提供している能力を測るのであって、依拠当事者の依拠能力を測っているわけではない。

適切な問いは外部から観測可能なものである。すなわち、指定された時刻に、指定されたネットワークから、指定されたプロトコルとバリデータバージョンを用いて、指定された証明書パスに必要な完全な資料を取得し、適用可能な標準の下で検証し、フレッシュネス余裕が尽きる前に期待される検証済みペイロードを生成できたか？という問いである。

この問いは「サーバーは稼働していたか？」よりも長い。なぜなら、サービスがより長いからである。また、これは責任もより公平に配分する。リポジトリ側の障害、パス固有の到達可能性問題、バリデータの欠陥、古いローカルキャッシュ、またはルーターへの配信遅延を、すべて一つの事象と偽ることなく示すことができる。

RPKI の公表は時間依存の連鎖である

RPKI は、自律システムがプレフィックスを起点する権限があるかどうかを事業者が評価する手段を提供する。リソース保有者は経路起点承認（ROA）を作成する。証明書は関連する番号リソースを証明書パスに結びつける。リポジトリは証明書、ROA、マニフェスト、証明書失効リストを公表する。依拠当事者ソフトウェアはそれらのオブジェクトをフェッチして検証し、検証済みペイロードを生成し、通常 RPKI-to-Router プロトコルを介してルーティングシステムに供給する。ルーターは、Valid、Invalid、NotFound に分類された BGP アナウンスメントにローカルポリシーを適用する。

この連鎖における各動詞には、それぞれ独自の障害境界がある。保有者が誤った起点や最大長を提出するかもしれない。認証サービスが不整合な証明書を発行するかもしれない。公表サービスが完了した変更を露出できないかもしれない。一つのアクセスプロトコルが機能している間に別のプロトコルが失敗するかもしれない。依拠当事者が過剰に拒否したり、過少に保持したり、リフレッシュが遅すぎたりするかもしれない。RTR セッションが最新のセットの伝達を停止するかもしれない。ルーターがセットを受け取って予期しないポリシーを適用するかもしれない。ある経路があるネットワークではフィルタされ、別のネットワークでは受け入れられるかもしれない。

リポジトリは中心である。なぜなら、すべての依拠当事者が取得可能な公表ビューを必要とするからである。しかし、リポジトリはルーターではなく、普遍的な反応を指示するわけでもない。RFC 7115は経路ポリシーをローカルなものとしている。これにより、リポジトリ報告が正直に主張できる範囲が制限される。報告は、オブジェクトが利用不可能または無効であったこと、定義されたソフトウェアの下で特定の検証済みペイロードが消失したこと、選択された観測地点で観測された経路が状態を変えたことを確立できる。しかし、これらの事実だけからすべての事業者のポリシーやすべての顧客の到達可能性を推測することはできない。

時間がこれらの層を結びつける。十分なフレッシュネスヘッドルームがある場合の10分の中断と、マニフェストの nextUpdate を越える10分の中断は異なる。新しい ROA の遅延と、以前有効だった ROA の消失は異なる。あるバリデータにとって継続性を保護するキャッシュが、別のバリデータでは存在しないか、既に期限切れに近いかもしれない。したがって、サービス品質は時刻付きの証拠の列として表現されなければならず、単一の期間としてではない。

内部的な稼働時間は必要だが、根本的に不十分である

従来の可用性監視は、ホストまたはアプリケーションが応答するかどうかを問う。これは依然として有用である。事業者は、起点サーバー、ストレージ、署名サービス、公表ワーカー、DNS、TLS 終端、配信ノードが健全かどうかを知るべきである。しかし、内部チェックには三つの構造的な死角がある。

第一に、それは通常プロバイダー自身のネットワークの内部または近傍から開始される。外部のバリデータが遭遇する DNS リゾルバ、ピアリングパス、アドレスファミリー、コンテンツ配信ノード、またはアクセス制御をバイパスするかもしれない。同一施設からの成功したリクエストは、アフリカ、アジア、ヨーロッパ、南北アメリカからの到達可能性についてほとんど証明しない。

第二に、それは意味よりもトランスポートをテストする傾向がある。HTTP ステータス200は古い RRDP 通知ファイルを配信しうる。rsync デーモンは部分的に更新されたツリーを露出しながら応答できる。ファイルは存在しても現在のマニフェストに含まれておらず、誤ったハッシュでリストされ、無効なチェーンの下で署名され、または古い CRL と対になっているかもしれない。サーバーは生きているが、アサーションは使用不可能である。

第三に、内部監視は公表アクションが試みられたことを知っていても、独立したユーザーがそれを受け取ったかどうかを知らないことが多い。キューは、データが起点ディレクトリに到達したときにタスクの完了をマークできるが、たとえ配信層が前のビューを保持していてもである。試みられた公表と外部から見える公表の差こそが、保証サービスが注視すべき場所である。

外部から再現可能な基準は、プロバイダーのテレメトリを捨てるのではない。それを適切な場所に置く。内部の証拠は原因を説明し、修復を加速する。外部の証拠はユーザーに見える状態を確立する。サービスコミットメントは両方を要求し、不一致が生じた場合の解決方法を明記すべきである。内部チェックが健全である一方で、多様な外部バリデータが意味的に失敗する場合、サービスはその不一致が説明されるまで劣化している。

キャッシュは単純な停止を暗号的な時間との競争に変える

RPKI は、リポジトリやネットワークパスが常に到達可能であると想定できないため、ローカルキャッシュを備えて設計された。RFC 8182は依拠当事者に古いオブジェクトを保持するよう助言し、RFC 9286は、失敗したフェッチに関連するキャッシュされたオブジェクトを、それらが古くなるか正常に置換されるまで継続使用することを推奨する。これは重要な継続性機能である。これこそが、生のダウンタイムがリスクの不十分な記述である理由でもある。

中断の開始時点では、二つの依拠当事者が異なるが有効なキャッシュ状態を保持しうる。一方は直前に更新し、他方は次に予定された取得に近づいている。それらの残りフレッシュネス余裕は異なる。リポジトリが迅速に回復すれば、両方が同じ検証済みペイロードを生成し続けるかもしれない。回復が関連する時間境界の後に来れば、一方が他方より早くオブジェクトを失うかもしれない。三つ目の実装は古くなった資料に対して異なるローカルポリシーに従うかもしれない。

したがって、インシデントには最低三つの時計がある。第一は外部フェッチの失敗を測る。第二は影響を受ける各認証ブランチのフレッシュネスヘッドルームを測る。第三は検証済み出力が実際に変わる時点を測る。ポリシー報告は通常、第一のものだけを公表するとしてもである。しかし、第二は緊急性を、第三はセキュリティサービス上の帰結を特定する。

キャッシュはまた、失敗した更新を隠蔽することがある。既存のオブジェクトは有効なままなので、全体的な検証は安定して見えるが、保有者が新たに作成した修正は存在しない。もしその欠けている変更が、移行を認可するか偶発的な Invalid 状態を修正するためのものであった場合、古い資料の継続性は、影響を受けた保有者にとってサービスが利用可能であったことを意味しない。読み取り可用性と変更公表可用性は別個の尺度を必要とする。

賢明な報告はこれらの時計を一緒にプロットする。独立フェッチが最初に失敗した時期、関連する有効期限または staleness までの最小観測時間、期待される変更が現れなくなった時期、バリデータが出力を変えた時期、プローブの定義された割合が回復に収束した時期を記述する。こうした説明は、キャッシュの回復力が機能したか、システムがより深刻な帰結にどれだけ近かったかを示す。

マニフェストと失効リストが意味的な可用性をテスト可能にする

RPKI リポジトリは単なる署名付きファイルのディレクトリではない。マニフェストは認証局に関連する署名付きオブジェクトを列挙し、ハッシュを含む。それらは依拠当事者が削除、置換、不完全なビューを検出するのを助ける。証明書失効リストは失効した証明書を識別する。これらのタイミングフィールドは、フレッシュネスについて外部から観測可能な期待を作り出す。

RFC 9286は、サービス測定のための非常に有用な基礎を提供する。依拠当事者は証明書で特定されたマニフェストをフェッチし、現在時刻がマニフェストの区間内にあることを確認し、リストされたすべてのファイルを取得し、各ハッシュを検証しなければならない。無効または古くなったマニフェスト、リストされたファイルの欠落、またはハッシュの不一致は、フェッチの失敗である。依拠当事者は、適切なキャッシュされたバージョンが古くなるか、成功したフェッチがそれらを置換するまで、その使用を継続すべきである。

このことは、外部の観測者が公表が完了したという事業者の声明を信頼する必要がないことを意味する。観測者は、署名付きのインベントリを取得したファイルに対してテストできる。検証が停止した正確な認証局、その理由、プロトコル、残りキャッシュマージンを記録できる。このテストを独立したネットワークから繰り返すことで、検証可能な可用性履歴を作成できる。

同じ方法で誇張を避けられる。失敗したブランチが自動的に無関係なブランチを無効にするわけではない。利用不能な委任公表ポイントは、地域的なトラストアンカーの下のすべてのオブジェクトが消えた証拠として報告されるべきではない。結果は、影響を受けた認証局、オブジェクト、バリデータにスコープされるべきである。過度に広範なラベルはエンジニアリングと説明責任の両方を曖昧にする。

意味的な測定は逆誤りも防ぐ。つまり、到達可能なエンドポイントを健全なリポジトリと扱うが、時間フィールドやオブジェクトの一貫性が既に失敗している場合である。RPKI では、完全性管理が可用性の一部である。なぜならば、安全に依拠できないファイルは、約束されたサービスではないからである。

2020年の JPNIC の中断が示すこと：経過ダウンタイムはインパクトではない

JPNIC は、2020年5月15日23:29から5月16日10:01（日本時間）まで、ハードウェア関連の停電後、ROAWeb と RPKI リポジトリが利用不可だったと報告した。ユーザーは ROA を作成・削除できず、外部当事者は証明書、ROA 等のファイルをダウンロードできなかった。これは明らかにサービス中断であった。

しかし、JPNIC はまた、以前にダウンロードされた ROA に基づく検証結果は、証明書の有効期限や CRL とマニフェストの nextUpdate 値が超過されなかったため、変わらなかったと報告している。これこそ、外部サービスコミットメントが保持すべき区別である。公表エンドポイントは約10時間半にわたって故障したが、通知に記述されたキャッシュされた検証機能は、述べられた条件下のオブジェクトとユーザーに対して継続された。

この事象は依然として重要である。保有者は一時的に変更を行う能力を失った。新たに必要な認可や失効は完了できなかった。関連する事前キャッシュを持たない、または異なるローカル条件にあるバリデータは、同じ継続性を享受しなかったかもしれない。公開通知は、すべての依拠当事者の状態やすべての経路の到達可能性を確定するものではなかった。それは、変更されなかった公表コンテンツと尽きなかったフレッシュネス時間について、境界のある技術的に意味のある主張を確立したのである。

これは事象を無害か破局的かのいずれかとするより優れている。よく設計された指標は、管理アクションのための不稼働と公表フェッチのための不稼働を分けて報告し、テストされたキャッシュ状態での検証済み出力の変化はゼロだったことを報告するだろう。それは、その結論に達するために使用されたプローブ、オブジェクトブランチ、バリデータを開示する。

教訓は肯定的である。暗号的な時間とキャッシュは、意図された通りリポジトリ障害を吸収できる。ポリシーは、その回復力を評価しつつ、拒否された変更サービスを依然として記録すべきである。プロバイダーは、経路継続性のための可用性クレジットを失うべきではなく、また保有者が必要な更新を発行できなかった場合に完全なクレジットを受け取るべきではない。

APNIC の2019年の事象が示すこと：各アクセスプロトコルが独自の結果を必要とする理由

APNIC の2019年12月13日のサービス告知は、20分間の部分的な RPKI 停止を記述している。rsync リポジトリ状態は不完全であり、古く失効したマニフェストが公表されたため、多数の証明書と ROA が無効になった。RRDP を使用しているバリデータは影響を受けず、引き続き完全な有効性を認識した。

したがって、一つのインシデントが二つの物質的に異なる外部現実を生み出した。RRDP のみテストするモニターは成功を宣言しただろう。rsync のみテストするモニターは意味的な失敗を見つけただろう。サーバーレベルの集計は、二つを安心させるような百分率に平均化しつつ、標準でサポートされる一つの方法のユーザーが使えないビューを受け取ったことを隠蔽したかもしれない。

プロトコルの多様性は、測定がその区別を保持する場合にのみ回復力を提供できる。関連する指標には、RRDP 通知の取得、スナップショットとデルタの完全性、セッションとシリアルの進行、rsync の到達可能性、ツリーの完全性、および優先する方法が失敗した場合にフォールバックが発生したかどうかが含まれる。プロバイダーはまた、二つの方法が同一の起点、ストレージシステム、ネットワークパス、または更新プロセスを共有しているかどうかを開示すべきである。なぜなら、表面上別個のアクセス方法が共通の故障モードを持つ可能性があるからである。

依拠当事者の振る舞いは説明に含められるべきである。RFC 8182は RRDP に問題がある場合の代替アクセスメカニズムを許可しているが、設定または実装されたフォールバックがすべてのデプロイメントで機能することが保証されているわけではない。2020年の依拠当事者に関する研究では、その実験的条件下で一貫性のないフェッチ動作が観察された。これらの結果は、観測された認証局とテストの限定された集合から得られたものであり、現在のすべてのバリデータの分母ではない。それらは、公表事業者がプロトコル設計から推測するのではなく実際のクライアント動作をテストすべき理由を示している。

外部コミットメントは、プロトコル別の内訳なしに単一の RPKI 可用性数値を決して公表すべきではない。一つの方法が完全な有効ビューを供給し、別の方法がそうでない場合、サービスは一部のユーザーにとっては回復力があり、他のユーザーにとっては劣化している。両方の事実がヘッドラインに属する。

RIPE NCC の2020年の障害：サイレントな公表ギャップの危険性を示す

2020年2月、RIPE NCC は、ディスクの問題により新たに作成、変更、削除された ROA が公表サーバーに到達できなかったと報告した。通知は、そのような変更が176件あったと特定した。影響を受けた情報は別の場所に保持されていたが、公表は発生せず、ディスクはエンジニアに警告する問題を報告しなかった。

これは、あらゆる暗号オブジェクトが期限切れになる前から既に停止であった。保有者向けのアクションと外部から見える状態は分岐していた。ユーザーは変更が受け入れられたと合理的に信じられた一方、依拠当事者は古い状態を取得し続けていた。サービスは、ファイルが依然として提供されているにもかかわらず、公表確認の時点で失敗していた。

その後、事象は第二の境界を越えた。RIPE NCC は、CRL が失効し、その後に背後にあるオブジェクトも失効したと報告した。異常な状態は、依拠当事者ソフトウェアに応じて異なって現れた。修復にはディスクの問題を解消する以上のことが必要であり、組織は最終的に解決の前に完全な認証局鍵ロールオーバーを実行した。

従来の稼働時間は、サイレントフェーズと意味的な断崖の両方を見逃す。外部から再現可能なテストは、署名されたまたは他の方法で検証可能な受入済み変更リファレンスと観測された公表を比較し、CRL フレッシュネスヘッドルームを追跡し、リポジトリビューが進歩しなかったときに警報を上げただろう。独立したバリデータは、期限切れのブランチが指定されたバージョンの下で出力にどう影響したかを示しただろう。

このインシデントはまた、状態発見がサービス品質の一部である理由を示している。故障は土曜日に始まり、CRL は日曜日に古くなり、組織は月曜日に通知を受けたと述べた。リポジトリは継続的に監視されていても、そのチェックが新しい権威的な状態が外部に存在することを検証しない場合、運用上盲目でありうる。

ポリシーは、エンジニアが既知の事象をどれだけ早く修復したかだけでなく、誰かが知る前にサービスがどれだけ間違っていたかを問うべきである。外部検出までの平均時間は第一級の RPKI 指標である。

RIPE NCC の2021年のインシデント：一部のバリデータでのみ完全性が失敗しうることを示す

2021年1月7日、外向けのリソース移転が原因で、RIPE NCC のシステムは関連する子証明書よりも先に更新された親証明書を公表した。不整合な区間の間、子はもはや親に存在しないリソースを過剰に請求した。組織は、厳格なマニフェスト解釈を使用する古い依拠当事者実装が、一つのエントリが無効な場合にマニフェストにリストされたすべての証明書を拒否したと報告した。

したがって、同じ公表状態がソフトウェアバージョンによって異なる結果を生み出した。RIPE NCC はアクセスログから327の依拠当事者インスタンスが影響を受けたと推定し、インシデントが停止を引き起こした可能性があると警告した。この組織は、327のネットワークが到達可能性を失ったとは主張しなかったし、ましてやトラストアンカーの下のすべての経路が失敗したとは主張しなかった。この抑制は重要である。インスタンス数はネットワーク数ではなく、拒否された証明書は普遍的な顧客影響の分母ではない。

この事象は、単一のリファレンスバリデータを使用するポリシー報告の弱点を暴露する。適合性は進化する。実装は困難なケースを異なって解釈し、バグは修正され、事業者は異なる速度で更新する。リポジトリは最新の実装をパスする一方で、デプロイされた古い集団にとって深刻な結果を生み出すことがある。

外部保証は、サポートされ物質的にデプロイされたバリデータの開示された互換性パネルを維持すべきである。認証ブランチおよび検証済みペイロードレベルでの出力差異を記録すべきである。パネルは標準適合性に対する投票ではない。不適合実装はそのように特定されるべきである。それは、更新が伝播する間の予見可能な運用上の露出の尺度である。

RIPE NCC が提案した改善策もまた、正しい指標を指し示している。アトミックな公表とより短い不整合ウィンドウを追求した。サービス目標は、外部から観測される原子性を測定すべきである。つまり、いかなるプローブも、一緒に検証できない親状態と子状態を取得すべきではない。これは、二つの内部更新ジョブがどれだけ早く終了したかを測定するよりも有意義である。

JPNIC の2022年の事象：Valid から NotFound への遅延変換を示す

JPNIC の2022年2月の通知は、成長するアクセスログが1月26日から2月2日までの間にリポジトリサーバーのディスクを満杯にしたと報告した。公表プロセスは CRL やマニフェストの nextUpdate フィールドを更新できなくなった。これらのフィールドが経過すると、関連する ROA はクライアントによって検証できなくなり、それらがカバーしていた経路は NotFound として検出された。

この順序が重要である。サービスは必ずしも経路を Valid から Invalid に直接移動させたわけではない。それは使用可能な認可証拠を除去し、影響を受けた検証ビューにとって NotFound を生成した。多くの運用ポリシーは NotFound を受け入れるが、しばしば Valid とは異なる選好でである。セキュリティ上の帰結は、即時の到達可能性の喪失ではなく、保護の喪失かもしれない。すべての消失した ROA を経路停止と呼ぶ報告は、これらの結果を混同する。

この事象は、キャッシュされた継続性が尽きるのに十分な長さ続いた。サーバーがまだ応答している間に公表のフレッシュネスが停止した場合、成功した TCP 接続のみに基づく可用性指標は特に誤解を招くものだっただろう。有用な警報は、新しいマニフェストと CRL の観測失敗と組み合わされた nextUpdate までの時間の減少であった。

JPNIC はまた、知識のあるユーザーが問題を報告したと述べた。この事実は制度上の改革を支持する。すなわち、独立したモニターは、リポジトリ運用への定義され認証され継続的に人員が配置された経路を持つべきである。外部発見は、専門家がたまたま異常に気づき、適切な連絡先を見つけることができるかどうかに依存すべきではない。

このクラスの事象に関する報告は、測定された集合内で、影響を受けた各 ROA がいつ検証済みペイロードの生成を停止したか、どの経路が選択された BGP 観測地点で Valid から NotFound に変わったか、いずれかの事業者がポリシーまたは顧客への影響を報告したかどうかを定量化すべきである。顧客データが利用不可能であるならば、ROA の数から推測されるのではなく、利用不可能のままでいるべきである。

ARIN の2022年の劣化：トランスポート冗長性の価値と限界を示す

ARIN は、2022年8月11日に、構成変更により一部のサービングノードに不一致な証明書材料がインストールされた後、90分間の RRDP サービス劣化を報告した。組織は影響を受けたノードを DNS ローテーションから削除し、一致する材料を復元し、リポジトリ生成を再開した。その rsync サービスは全体を通じて機能を維持し、一方で6件の ROA の公表が遅延した。

これは部分的な回復力の有用な事例である。代替公表方法は利用可能であり続け、プロバイダーは遅延した変更の数を境界付きで示した。しかし、すべての依拠当事者がフォールバックを通じてこれらの変更を取得したことにはならない。事業者は RRDP を好むかもしれず、リトライスケジュールを適用し、機能するフォールバックを欠くか、一方のサービスと異なるネットワークパスを持つかもしれない。

正しいスコアカードは、プロトコルと観測地点ごとの成功した取得、フォールバック試行と結果、影響を受けた6件の ROA の公表遅延、および修復後の検証済み出力の収束を示すだろう。また、公開リポジトリの既存状態と、新しい状態の生成の一時的な停止とを区別するだろう。現在のキャッシュを持つ事業者にとっての可用性は、遅延した ROA の一つを待つ保有者にとっての可用性と同一ではなかった。

冗長性は、独立して行使される場合にのみクレジットに値する。同一の誤設定ノードプールによってサーブされる二つの URL は、二つの制御ではない。個別の故障モードを持つ RRDP と rsync は継続性を改善しうるが、プロバイダーはバリデータがフレッシュネスが切れる前に生き残っているパスを使用できることを証明すべきである。一つの方法の制御された撤回のような定期的な訓練は、緊急事態を待たずにフォールバックが機能するかどうかを明らかにできる。

これが、外部テストがアーキテクチャ図よりも優れる点である。それらはクライアントが実際に通ったパス、実際に検証したビュー、遅延アサーションが有用になった時刻を示す。

リポジトリサービスコミットメントは四つの別個のサービス目標を必要とする

第一の目標は検索可用性である。独立した観測地点から、依拠当事者はリポジトリ名前を解決し、サポートされるアドレスファミリー上で接続し、必要なトランスポートをネゴシエートし、RRDP または rsync マテリアルを取得できるか？結果はプロトコル、IP バージョン、地域、ネットワークプロバイダーごとに分けるべきである。月間平均は、ある組合せに対する完全な故障を隠蔽すべきではない。

第二は意味的可用性である。取得されたビューには、最新の有効なマニフェスト、一致するハッシュを持つリストされたオブジェクト、使用可能な CRL、および有効な証明書パスが含まれているか？バリデータは、無関係なブランチを破棄することなく、期待されるペイロードセットを生成できるか？この目標は、暗号的な正しさをサービス指標に変換する。

第三は公表適時性である。認可されたアクションが受け入れられた後、独立したプローブが新しいオブジェクトを観測し、対応するペイロード変更を生成するまでの時間はどのくらいか？この目標は、作成、変更、失効、移転、緊急修正をカバーする。監査人がアカウントの秘密を露出することなくアクションを公表に一致させることを可能にする、プライバシーを保護するリファレンスが必要である。

第四は回復収束である。修復後、定義された独立したバリデータのパネルが同じ最新ビューに到達し、ルーティングシステムがそれを受け取るまでの時間はどのくらいか？起点では修復されたが配信ノードでは依然として古いままのリポジトリは、完全には回復していない。また、ファイルが最新である一方で RTR セッションが未だに古いペイロードセットを供給しているものも同様である。

各目標は明示的な分母を必要とする。検索可用性はスケジュールされたプローブ試行を使用しうる。意味的可用性は最新であることが期待される認証ブランチを使用しうる。公表適時性は即時公表の資格がある受入済みアクションを使用しうる。回復はインシデント前の既知の状態を持つアクティブプローブを使用しうる。これらの集団を混ぜると、魅力的だが無意味な百分率が生まれる。

四つの目標モデルはまた、公正な責任帰属を支援する。リポジトリは意味的完全性を満たさずに検索可用性を満たすこともあり、または両方を満たしていても保有者の要求した変更が依然として誤っていることもある。事業者と監督機関は、どの約束が失敗したかを正確に見ることができる。

独立プローブはプロバイダーの前提に挑戦するために十分に多様でなければならない

中立的な測定ネットワークは、複数の地域および自律システムにプローブを含み、提供されている場合には IPv4 と IPv6 の両方を使用すべきである。パスやリゾルバが一体として故障しうる単一のクラウドに全プローブを集中させることを避けるべきである。数と配置は、すべてのインターネットユーザーを代表すると偽る必要はない。読者が観測集団を理解できるよう開示されねばならない。

各プローブは、制御されたクロックを使用し、DNS 応答、宛先アドレス、トランスポートタイミング、プロトコル応答、オブジェクトハッシュ、バリデータ名とバージョン、トラストアンカー資料、キャッシュ状態、最終的な検証済みペイロードダイジェストを記録すべきである。機微な運用詳細は保護されうるが、別の資格ある当事者がテストを再現できる十分な証拠が公表されるべきである。

フレッシュモードとウォームキャッシュモードの両方が必要である。フレッシュなバリデータは、新しい依拠当事者がビューを構築できるかを示す。ウォームなバリデータは、確立された事業者が障害を通じて継続できるかを示す。フレッシュインスタンスのみをテストすると即時の損失を誇張し、ウォームのもののみをテストするとオンボーディングとキャッシュ枯渇のリスクを隠す。

プローブは、リポジトリの容量を尊重しつつ現実的な間隔で取得すべきである。サービスを圧倒する測定システムは、観測すると主張する条件を自ら作り出す。プロバイダーと研究者は、プロバイダーに通常の配信をバイパスするパスを与えることなく、レート制限と専用の識別に合意できる。

誤警報は規律ある取り扱いを必要とする。単一のプローブ障害は、そのリゾルバ、ローカルクロック、ディスク、バリデータ、または上流パスから生じうる。インシデント宣言は、最小数の独立したネットワークにわたる意味的失敗やプロバイダーの確認など、予め告知されたルールを使用すべきである。局所的な障害は依然としてデータに属するが、すべてがグローバルな通知になるわけではない。

基準は、プローブコード、テストベクター、結果定義を公表すべきである。再現性は共有されたメソッドと署名された観測から生まれ、組織的な名声からではない。

フレッシュネスヘッドルームは、グリーンなダッシュボードが提供できないリスク指標である

任意の時点で、リポジトリブランチには、関連するマニフェストまたは CRL が古くなるか証明書が失効するまでの残り区間がある。この区間がそのフレッシュネスヘッドルームである。それは、通常のフェッチ問題を運用上のリスク指標に変換する。

外部プローブがあるブランチのフェッチに失敗するが、その現在のマニフェストに18時間残っているとする。この事象は注意に値するが、キャッシュされたバリデータには継続する余地がある。回復なしにヘッドルームが1時間に落ち込めば、同じトランスポート条件が緊急になる。もし新たに必要な失効も待っているならば、古いオブジェクトが未期限切れであるにもかかわらず、セキュリティリスクは既に高いかもしれない。

プロバイダーは、リポジトリ全体の最小値だけでなく、影響を受けたブランチにわたるヘッドルームの最小値、中央値、分布を報告すべきである。異常に短い区間を持つ一つの委任認証局が、すべてのブランチが故障に近いことを暗示するために使用されるべきではない。同様に、長命な親証明書が、staleness に近い子マニフェストを覆い隠すべきではない。

ヘッドルームは燃焼レートアラートを支援する。もし事象が、修復の信頼度が上がるよりも早くフレッシュネスマージンを消費するならば、期限切れ前にエスカレーションが起こるべきである。これは準備金の管理に類似している。サービスはまだ意味的に失敗していないが、遅延を吸収する能力は縮小しつつある。

オブジェクトのタイミングがリスクのすべてではない。新しい認可を待つ保有者は、ネットワーク移行が進行中であるために、実質的なヘッドルームがゼロかもしれない。インシデント記録は、影響を受けた保有者が、証拠とレビューを伴って緊急の期待される変更をマークすることを許可すべきであり、機密の商業計画を公に露出すべきではない。

ヘッドルームを公表するポリシー報告は、なぜある10時間の停止が検証変化をもたらさなかった一方、別の数日間の公表故障がもたらしたかを説明する。それは、生の稼働時間が提供できない緊急性に関する共通言語を理事会とオペレーターに与える。

帰属は、認可されたアクションから経路効果までの共有されたシーケンスを必要とする

RPKI インシデントが論争になるとき、各参加者はシーケンスの一部しか見ていない。保有者は自分が要求したことを知っている。認証サービスは受け入れて署名したことを知っている。リポジトリはサーブしたことを知っている。依拠当事者はフェッチし拒否したことを知っている。ルーターはどのペイロードセットとポリシーを使用したかを知っている。顧客はサービスが到達不能になったことを知っている。相関する時刻がなければ、責任は主張になる。

共通のインシデント記録は、各材料アクションに安定したリファレンスを割り当て、六つのマイルストーンを記録すべきである。すなわち、認可受入、オブジェクト生成、オブジェクト外部公表、オブジェクトのフェッチと検証、ルーターへのペイロード配信、関連する経路決定の観測である。各マイルストーンは責任組織とクロックソースを特定すべきである。公開報告は、独立したレビューのためにシーケンスを保持しながら、機微なリファレンスをハッシュまたは集計することができる。

この方法は、誤ったオブジェクトと利用不可能なオブジェクトを区別する。保有者が誤った最大長を要求し、サービスがそれを忠実に公表した場合、責任はコード欠陥とは異なる。リポジトリは正しいオブジェクトを公表したが、旧式のバリデータがより広いブランチを拒否した場合、プロバイダーには依然として互換性とコミュニケーションの義務があるが、直接の技術的原因は異なる。

帰属にはまた、反実仮想テストが必要である。調査者は、観測されたオブジェクトセットを指定されたバリデータを通じて再実行し、結果のペイロードを比較し、次いで捕捉された BGP アナウンスメントに事業者の述べられた経路ポリシーを適用できる。これはすべてのパケットや失われたトランザクションを再構築するものではない。主張された連鎖が技術的に可能かどうか、状態が最初にどこで分岐したかをテストする。

いずれの組織もこの証拠の唯一のコピーを管理すべきではない。プロバイダーはマイルストーン記録に署名でき、中立的なモニターは外部観測に署名でき、事業者は RTR と経路ポリシー履歴を保持できる。共有された証拠は狭い責任を可能にし、それは包括的な非難や包括的な免責よりも公平である。

経路影響は、オブジェクト数から推定されるのではなく測定されねばならない

リポジトリインシデントは、到達可能性を変えずに経路セキュリティを変えることができる。有効な ROA が使用可能なビューから消えたとき、アナウンスメントは NotFound となり、受け入れられ続けるかもしれない。不正な起点に対する保護は弱まるが、正当な経路は依然として機能するかもしれない。不整合な証明書がある有効な認可を消失させるが別のカバーする ROA が残っている場合、経路の状態はまったく変わらないかもしれない。誤った ROA が正当なアナウンスメントを Invalid にするとき、Invalid 経路を拒否する事業者は到達可能性を失う一方、他の事業者は受け入れ続けるかもしれない。

したがって、影響調査は検証済みペイロードの差分から始まる。どのプレフィックス、最大長、起点タプルが各バリデータの下で追加または削除されたか。次のステップは、これらの差分を、指定されたコレクターまたは事業者フィードで観測された BGP アナウンスメントに結合する。最後の技術的ステップは、開示されたポリシー仮定を、または利用可能であれば実際の事業者ポリシーを適用する。

顧客影響には別個の証拠が必要である。すなわち、アラーム、トラフィック損失、失敗したセッション、サポート報告、またはサービスレベル違反である。経路コレクターはすべてのプライベートピアリングパスを見るわけではなく、変更された検証状態はどれだけのトラフィックがそれを使用していたかを明らかにしない。報告は、影響を受けたネットワークから提供されたデータなしにプレフィックスをユーザーや収益に変換することを避けるべきである。

同様の規律がプロバイダーを誇張された主張から保護する。あるブランチを一時的に NotFound にしたインシデントが、地域的なインターネットが停止した証拠として記述されるべきではない。また、事業者を過小評価からも保護する。もし複数の独立したネットワークが拒否された Invalid 経路を記録し、同時にトラフィックが低下したならば、リポジトリホストが到達可能であったという声明は無関係である。

適切な出力は階層化された影響テーブルである。影響を受けた公表オブジェクト、影響を受けた検証済みペイロード、影響を受けた観測されたアナウンスメント、ポリシー応答が証拠づけられたネットワーク、文書化された帰結を持つ顧客またはサービス。未知のセルは未知のままである。

分母は、ローカルで、開示され、プロモーション的な再利用に耐性があるべきである

RPKI 測定は、システムが目的においてグローバルであるために印象的な数字を引きつける。しかし、いかなる公的な観測者も、依拠当事者インスタンス、ソフトウェアバージョン、キャッシュ履歴、経路ポリシー、プライベート BGP パス、エンド顧客影響の完全なセンサスを持っていない。信頼できるサービスコミットメントはその分母をでっちあげない。

すべてのレートはその観測された集団を伴うべきである。プローブ可用性は、指定されたプローブセットからのスケジュールされたチェックのうち成功したチェックである。バリデータ互換性は、パネル内のバージョンとテストケースのうち成功した出力である。公表適時性は、報告期間内の資格ある受入済みアクションのうち目標内に観測されたアクションである。経路効果は、指定されたコレクターで可視なアナウンスメントのうち変更されたアナウンスメントである。いずれも「影響を受けたインターネットの割合」ではない。

IMC 2020の依拠当事者研究は、まさに境界が定められているときに価値がある。それは三つの認証局に到達するクライアントを観測し、制御された条件を使用して一貫しないフェッチを暴露した。報告された割合はその実験を記述するものであり、現在のすべての事業者やすべての将来のバージョンではない。ポリシー報告は研究を引用する際にこのような境界を保持すべきである。

インシデント固有のカウントにも同様の抑制が必要である。2021年1月の RIPE NCC の影響を受けた327の依拠当事者インスタンスの推定は、アクセスログと定義されたソフトウェアの振る舞いから来ている。インスタンスはネットワークを共有することも、複数のネットワークにサービスすることも、テストシステムであることもある。その数は運用上の露出の証拠であり、切断された組織の数ではない。

良い測定は依然として力強いものでありうる。五つの独立したネットワークの全プローブが同じブランチを拒否した、テストされた三つの最新バリデータすべてが同じペイロードを失った、または特定の経路が二つのコレクターで消えたと言える。精密さは、主張が再現可能で挑戦可能であるため、説明責任を強化する。

インシデント報告は、原因、状態、帰結、信頼性を分離すべきである

原因は初期の故障である。ディスク満杯、順不同の公表、不一致な証明書材料、停電、またはソフトウェア欠陥。状態は外部ユーザーが遭遇したものである。フェッチ失敗、古いマニフェスト、不完全な rsync ツリー、不整合な証明書パス、または遅延した変更。帰結は観測された出力である。ペイロード除去、状態変更、拒否された経路、または顧客中断。信頼性は証拠がそれらをどれだけ強力に結びつけるかを述べる。

多くの通知はこれらの層を単一の文に収縮させる。それは、後の証拠が変わる場合に混乱を作り出す。プロバイダーは原因を知る前に状態を知っているかもしれない。事業者はプロバイダーが外部パスを再現する前に経路帰結を証明するかもしれない。層を分けて報告することで、公的説明は元の観測を消去することなく改善できる。

通知は、正確な開始と終了の定義を含むべきである。開始は、最初の失敗した外部意味チェックの時刻であり、エンジニアがインシデントを開いた時刻ではない。終了は、プローブの定足数からの成功した検証と遅延した変更の公表を必要としうる。単にプロセスの再起動ではない。検出、アクノレッジメント、緩和、完全収束の時刻がすべて可視であるべきである。

信頼性は証拠によって等級付けできる。署名されたオブジェクトのリプレイによって確認されたか、複数の独立したバリデータによって観測されたか、影響を受けた事業者によって報告されたか、またはタイミングから推測されたか。これは事実の代替ではない。それは読者に更なる調査が必要な場所を伝える。

プロバイダーはまた、測定されなかったことを公表すべきである。顧客損失データが収集されなかったならば、そう述べよ。rsync はテストされたが RRDP ログが利用不可能だったならば、そのギャップを述べよ。BGP コレクターが影響を受けた経路を見なかったならば、不在を無効果の証明として扱ってはならない。

正直な報告は簡潔でありながらこれらのフィールドを含みうる。目的は官僚的な長さではない。狭い稼働時間の主張が、事業者が必要とする証拠を押しのけるのを防ぐことである。

サービス与信だけでは経路セキュリティ中断の不十分な救済策である

RPKI 公表は、しばしば個別に価格付けされたユーティリティとして販売されるのではなく、メンバーシップまたは登録サービスの中に含められる。したがって、従来の料金控除は些細であるか、計算が困難であるか、依拠当事者や下流顧客には利用不可能かもしれない。最も価値ある救済は運用上のものである。

第一に迅速な修正である。プロバイダーは、誤った、欠落した、または古くなったオブジェクトを報告するための継続的に人員が配置された経路を必要とし、それは潜在的に影響を受けるポータルに完全に依存しない認証を伴う。応答目標はフレッシュネスヘッドルームと実証された経路リスクによって変動すべきである。

第二に証拠保全である。オブジェクトバージョン、公表時刻、アクセスメソッド状態、検証結果、変更認可は、調査と正当な請求のために十分長く保持されるべきである。証拠を上書きする修復は、組織を記憶に頼って議論するままにする。

第三にポータブルなコミュニケーションである。署名されたインシデント通知は、影響を受けた認証ブランチとオブジェクトダイジェストを特定すべきであり、それによりバリデータと事業者はスクリーンショットや噂を信頼することなく露出を決定できる。更新は、既存のキャッシュが依然として使用可能かどうか、要求された変更が遅延しているかどうかを述べるべきである。

第四に、重大または反復的な事象のための独立レビューである。レビューアは外部目標をテストし、プロバイダー管理を調査し、セキュリティ制限内で発見を公表すべきである。プロバイダーが著述した説明は必要であるが、プロバイダー自身の監視が故障を見逃した場合の唯一の保証ではありえない。

実際の損失と法的責任が確立された場合には、金銭的な救済が依然として重要かもしれない。その設計は、責任、因果関係、適用法に属する。サービスコミットメントは不可能な補償を約束すべきではないが、低いまたはゼロの料金が正確に公表し迅速に修復する義務を否定するために使用されるべきでもない。

事業者にも測定可能な継続性義務がある

外部説明責任は、あらゆる RPKI リスクをリポジトリに移転するための装置ではない。ネットワーク事業者は、バリデータ、リフレッシュ間隔、冗長性、監視、経路ポリシーを選択する。リソース保有者は ROA の内容とタイミングを選択する。これらの決定は帰結に物質的に影響を与える。

事業者は、サポートされた依拠当事者ソフトウェアを実行し、成功したリポジトリ同期を監視し、少なくとも適用可能な標準が推奨するキャッシュ動作を保持し、RTR 冗長性をテストすべきである。ペイロードが消えたりバリデータが利用不能になったときにルーターがどう振る舞うかを知っているべきである。同じリゾルバ、電源、ソフトウェア欠陥を共有する第二のバリデータは、堅牢な冗長性ではない。

リソース保有者は、ネットワーク変更前に意図したアナウンスメントと ROA を比較し、不必要に寛容な最大長を避け、作成または移転後に外部公表を検証すべきである。彼らは緊急連絡先を維持し、ホスト型および委任アレンジメントにおいてどの当事者が鍵を制御するかを理解すべきである。

これらの義務は、リポジトリ障害の包括的な言い訳にならずにインシデント分析に現れるべきである。もし事業者が標準が要求する以上に拒否する旧式のソフトウェアを実行していたならば、それは関連する。もしリポジトリが不整合な状態を公表したならば、それもまた関連する。複数の原因が一つの損失に寄与しうる。

共有された訓練は両サイドを改善できる。プロバイダーは、事業者がフォールバックを検証する間、一つのアクセスメソッドが撤回されるテストウィンドウを告知できる。合成認証ブランチは、本番経路をリスクにさらすことなく期限切れアラームやアトミック更新をテストできる。事業者は匿名化された収束結果を報告できる。

目的は相互的な証拠である。プロバイダーは外部公表品質を実証し、事業者は慎重な依拠を実証する。両方が測定されるとき、残余の不確実性は契約またはレトリックのみによって割り当てられる代わりに可視になる。

NRS は外部保証を正当性サービスにできる

NRS は、番号レジストリが正確な記録を維持し、ネットワークの運用上の役割を尊重し、簿記機能に限定されるべきと論じる。RPKI は、証明書とリポジトリのアクションが事業者がどの経路アナウンスを受け入れるかに影響を与えうるため、その哲学を複雑にする。適切な応答は RPKI を拒否することではない。追加された力を観測可能かつ説明可能にすることである。

NRS は、保有者、事業者、レジストリエンジニア、依拠当事者メンテナ、研究者を共通のリポジトリ保証プロファイルの周りに招集できる。このプロファイルは、ここで説明した四つのサービス目標、最小インシデントフィールド、プロトコル固有テスト、フレッシュネス報告、帰属マイルストーンを定義するだろう。参加は自発的に開始でき、結果はサービスと地域ごとに公表される。

また、中立的なプローブを運用または委託できる。独立性は、開示された資金、オープンな測定コード、利益相反ルール、複数のホスティングネットワークを必要とする。NRS は自身の主張を主張によって認証すべきではない。いかなる事業者、レジストリ、研究者も再現できる証拠を公表すべきである。

有用な年次レビューは、各参加リポジトリを独自の公表目標と比較し、粗野な普遍スコアで地域をランク付けしない。それは、繰り返される部分的な失敗、未テストのフォールバック、遅い外部検出、弱い回復証拠を特定できる。プロバイダーは事実誤認を修正し説明を付す権利を有する一方、背後にある観測は利用可能なままである。

これは良いパフォーマンスに報いるため、肯定的な制度的役割である。例えば、JPNIC 2020事象は、管理とフェッチの不稼働を記録しながら、キャッシュされた検証継続性のクレジットを受け取ることができる。APNIC 2019事象は、RRDP の回復力と rsync の失敗を別個に示すことができる。ニュアンスが、警告主義と自己満足の両方を置き換えるだろう。

NRS はそれによって、レジストリ説明責任への広範な要求を、実用的な公共財へと変換するだろう。すなわち、重要な経路セキュリティアサーションが外部から使用可能であるかどうかに関する比較可能な証拠である。

調達と公共政策は、不一致に耐える証拠を求めるべきである

政府、重要インフラ事業者、大規模ネットワークは、必ずしも自分たちが信頼する認証と公表の層を運用することなく、RPKI にますます依存している。彼らの調達質問は、プロバイダーが高い可用性を主張するかどうかを超えて移行すべきである。

彼らは、RRDP と rsync がどこでホストされているか、その故障ドメインが異なるか、完全な外部検証がどのくらいの頻度で実行されるか、どのフレッシュネスヘッドルームがエスカレーションをトリガーするか、受け入れられた変更がどのように公表に一致されるか、どのバリデータバージョンがテストされるか、インシデントがどのように告知されるか、証拠がどのように保存されるかを問うべきである。彼らは、最近の訓練結果と回復収束の事例を要求すべきである。

公共政策は、リポジトリ事象に対する一つの普遍的な経路応答を義務付けることに抵抗すべきである。事業者には異なるリスクポジションがあり、フェールオープンな動作には継続性の利益とセキュリティコストの両方がある。より建設的な要件は透明性である。公共サービスに影響を及ぼすシステムの検証ビュー、ローカルポリシー、フォールバック計画を開示すること。

監督はまた、地域レジストリリポジトリとその下の委任公表ポイントを区別すべきである。委任された権限が故障している間、トラストアンカーは到達可能でありうる。すべての委任停止を親に帰属させるポリシーは、測定を改善することなく委任を阻害するだろう。証明書パスは障害がどこで発生したかを特定する。ガバナンスはその証拠に従うべきである。

保険や取締役会のリスクレビューも同じモデルを使用できる。彼らは、組織が自身のキャッシュマージンを知っているか、独立したバリデータを持っているか、経路ポリシー履歴を保持しているか、適切なリポジトリ連絡先に到達できるかを調査できる。これにより、RPKI は抽象的なサイバーセキュリティ制御から監査可能な継続性依存へと変わる。

基準は、中断のない経路を保証する必要はない。より狭い質問に対する規律ある回答を保証すべきである。すなわち、何が外部から利用可能だったか、いつそれが使用可能でなくなったか、誰が失敗したステップを制御していたか、そして実際にどのような経路帰結が観測されたかである。

ポリシーが見逃すリポジトリ停止は、公表と依拠の間に隠されている

RPKI リポジトリは既に、故障が単一の稼働時間カウンターに収まらないことを実証してきた。ハードウェアは、キャッシュされた有効性を使い果たすことなくアクセスを停止できる。古いマニフェストは、RRDP が整合的である間、rsync を損傷できる。ディスクは、CRL が失効するまでサイレントに変更をブロックできる。親証明書と子証明書は個別に本物でありながら一時的に不整合でありうる。配信ノードは、代替メソッドが利用可能な間、不一致なトランスポートクレデンシャルをサーブできる。

これらは経路起点検証に対する反対論ではない。それらは、経路セキュリティが成熟したサービス保証に値するインフラストラクチャへと成熟した証拠である。暗号は改ざんを検出可能にするが、公表を無謬にはしない。キャッシュは継続性を提供するが、新しい状態が到着したことを証明しない。ローカル経路ポリシーは事業者の自律性を保持するが、リポジトリの責任を排除しない。

したがって、最良の可用性主張は控えめで正確である。プロバイダーは、指定された独立プローブが指定されたメソッドを通じて完全な最新資料をフェッチしたこと、テストされたすべての認証ブランチが検証したこと、受け入れられたアクションが目標以内に可視になったこと、サポートされたバリデータが修復後に収束したこと、観測された経路影響が定義された集団内で発見されたか否かを述べることができる。別の当事者がテストを再現できる。

これより広いものはより多くの証拠を必要とする。内部ダッシュボードは外部フェッチ可能性を証明できない。欠落した ROA は顧客損失を証明できない。安定した BGP コレクターは、プライベートネットワークが影響を受けなかったことを証明できない。グローバルな百分率は非開示のサンプルから構築できない。

レジストリの正当性は、組織が公衆にその稼働時間を信仰で受け入れるよう求めないときに高まる。NRS とより広い事業者コミュニティはその規範の確立を助けることができる。リポジトリは、そのアサーションが使用可能になるポイント、時計が切れる前で、その帰結が見える後に、判断されるべきである。

それが、ポリシー報告が通常見逃す停止である。すなわち、マシンが止まった瞬間ではなく、インターネットの依拠当事者が、時宜を得た首尾一貫した説明責任のある経路権限の陳述を取得できなくなった区間である。

Sources