不適切な ROA がルーティングセキュリティを共通モード障害に変える

要約

• 2025年3月18日、公開ネットワーク分析情報源は、北朝鮮に関連する BGP 経路が誤った Route Origin Authorization（ROA）の発行により RPKI 無効になったと報告した。この ROA は/22を承認したが、ネットワークは4つの/24を通知していた。
• このインシデントは、検証者側の設計通りに経路セキュリティメカニズムが機能したという点で、説明責任の事例として有用である。無効な経路を拒否するネットワークは、運用上は正当でありながら新しい ROA と矛盾する経路の到達性を低下させた。
• したがって、この障害は RPKI に対する反論ではない。RPKI データが共有インフラとなり、変更レビュー、ステージング、maxLength の規律、監視、ロールバック、アラートによって管理されなければならないことを示す証拠である。
• 共通モード依存が主要なリスクである。より多くのネットワークが経路起点検証を採用し、無効を拒否するにつれて、単一のリソース保持者や RIR 側の発行ミスが広範な運用上の影響を与える可能性がある。なぜなら、多くのネットワークが同じ暗号文書を消費するからである。
• 修復の基準は検証可能であるべきである。無効なプレフィックスを特定し、ROA を修正し、経路伝搬の回復を測定し、タイムラインを保存し、他の事業者が自身の maxLength およびアラート制御を監査できる十分な証拠を公開する。

証拠記録とその使用方法

この記事では、公開記録を層状の証拠として扱う。インシデントレポート、標準、ブラウザまたはルーティングの測定、規制当局または政策資料、および現在の事業者ガイダンスを異なる主張に使用する。企業作成の情報源は企業の立場として帰属させる。標準および後のガイダンスは、管理策を説明し説明責任の期待を示すために使用し、公開記録がその主張を裏付けていない場合に私的事実を発明したり、遡及的に後の義務を課したりしない。

RPKI がミスを可視化し重大なものにした

RPKI が存在する理由は、通常の BGP ではネットワークに誤った到達可能性の主張を信じる余地が大きすぎるからである。Route Origin Authorization により、リソース保持者はどの自律システムがどのプレフィックスを発信できるか、また maxLength を通じて通知の具体性をどの程度にするかを指定できる。経路起点検証を実施するネットワークは、経路を有効、無効、または未検出として扱い、ポリシーを適用できる。これは主要なセキュリティ改善である。北朝鮮の誤った ROA インシデントは、この改善が公開された承認データの正確性に対する新たな運用上の依存関係を生み出すことを示している。

Kentik は、2025年3月18日に北朝鮮の BGP 経路が誤った ROA の発行により RPKI 無効になったと報告した。他の公開レポートは、/22の承認と maxLength /22を記述している一方で、ネットワークは4つの/24プレフィックスを通知していたと説明している。ROV のロジックでは、通知されたプレフィックスが ROA で許可されているよりも具体的である場合、発信 AS が一致しても経路は無効になり得る。事業者が無効を拒否すれば、到達性は低下する。言い換えれば、システムは ROA を無視したのではなく、ROA が実際のルーティングを誤って記述したために失敗したのである。

これが共通モードのポイントである。RPKI 以前は、各ネットワークの経路フィルターと判断は異なる方法で失敗する可能性があった。RPKI により、多くのネットワークが同じ署名オブジェクトを消費できる。これはオブジェクトが正しい場合には良い。誤った発信元のハイジャックを広く拒否できる。オブジェクトが間違っている場合には危険である。正当な経路が広く拒否され得る。共有された信頼の源泉が共有された障害モードになる。

答えは RPKI を避けることではない。承認が間違っている可能性があるために検証を拒否することは、古い BGP 信頼問題を残す。答えは、ROA データをプロダクション変更管理として扱うことである。リソース保持者の最初の ROA を作成する、maxLength を変更する、発信元を移動する、プレフィックスを分割するといった作業は、影響の大きいルーティング変更として扱うべきである。レビュー、シミュレーション、監視、ロールバック、アラートが必要である。

これは特に小規模または集中型のネットワークにとって重要である。北朝鮮の公開インターネットフットプリントはハイパースケールプロバイダーと比較して限られており、インシデントの分析が容易だった。しかし、同じパターンは大学、政府、銀行、CDN、地域通信事業者、緊急サービスネットワークにも影響を与える可能性がある。少数のプレフィックスでも重要なサービスを運ぶことができる。誤った ROA はセキュリティ管理を可用性インシデントに変える可能性がある。

maxLength はポリシー上の決定であり、フォームフィールドではない

オプションの maxLength フィールドは、多くの ROA ミスが障害になる場所である。カバーするプレフィックスの ROA は、そのプレフィックス長のみを承認することも、指定された最大値までより具体的な通知を許可することもできる。ネットワークが通常/22の下で/24を通知する場合でも、ROA が/22のみを承認する場合、検証者は/24を無効と見なす。これが北朝鮮インシデントの公開説明と思われる。このフィールドは些細な詳細ではなく、プロダクション経路の存在を許可するかどうかをエンコードしていた。

事業者は時折、狭い maxLength 値を好む。なぜなら、過度に広い承認は保護を弱める可能性があるからだ。/22 ROA が/24を許可する場合、同じ発信元を使用する許可されていないより具体的な経路が有効として扱われやすくなる。逆に許可しない場合、正当なトラフィックエンジニアリングや分割が失敗する可能性がある。正しい値は実際のルーティング意図、緊急時計画、監視に依存する。普遍的に安全な自動操縦設定は存在しない。

これにより、maxLength はガバナンスの問題となる。誰がプロダクション経路セットを把握しているか？誰が分割を承認するか？プレフィックスが移動したり、通知が変更されたり、プロバイダーが追加されたりした場合、誰が ROA を維持するか？経路が無効になった場合、誰がアラートを受信するか？営業時間外に誰がオブジェクトを修正できるか？依存ネットワークが無効を拒否し始める前に、新しく公開された ROA が BGP と一致することを誰が確認するか？これらの質問は手続き的に聞こえるが、セキュリティ展開が到達性を保護するか破壊するかを決定する。

APNIC の無効な経路のクリーンアップに関するガイダンスや、不適切な ROA に関する RIR 資料は、実践的な修復経路を示している。無効な経路を見つけ、ROA を検査し、maxLength または発信元を修正し、依拠当事者キャッシュと BGP 伝搬の収束を待つ。この手順はリハーサルされるべきである。国、機関、企業にとって初めての ROA は、リスクの低い書類更新として公開されるべきではない。

問題は契約言語にも含まれるべきである。管理されたネットワークプロバイダー、RIR アカウント保持者、外部委託されたルーティングチームが ROA 作成の責任を共有する可能性がある。顧客は、プロバイダーが ROA を変更したことを、検証ネットワークからの障害をユーザーが報告するまで知らないかもしれない。契約は、ROA データの所有者、maxLength の承認者、存在する監視、有効性状態変更後に提供される証拠を指定すべきである。

フェイルオープンとフェイルクローズドのインセンティブは不安定である

RPKI はインセンティブの緊張を生み出す。ネットワークが無効な経路を拒否すれば、ハイジャックや誤った発信を阻止するのに役立つ。無効な経路を受け入れれば、正当なネットワークが誤った ROA を公開した場合に到達性を損なわない。北朝鮮インシデントはその緊張の中にある。経路は無効になった。拒否を実施したネットワークは到達性を低下させた。寛容なネットワークは経路を利用可能に保つかもしれないが、同時に経路セキュリティの弱点を残す。

この緊張は、厳格な検証に対する議論として使われることがある。それは単純すぎる。何もブロックしないセキュリティ制御は、それが阻止するために作られた攻撃から保護できない。しかし、古いまたは間違ったデータのためにプロダクショントラフィックをブロックするセキュリティ制御は、それを無効にする圧力を生み出す。持続可能な答えは、データ衛生とアラートを改善して、無効な正当経路を稀にし、迅速に検出し、迅速に修正することである。

良性の RPKI 競合と事業者インセンティブに関する研究は、この点を大規模に示している。設定ミスは続き、無効を拒否するネットワークは、無効状態が良性である場合にトラフィックを失う可能性がある。これは導入に対する経済的圧力を生み出す。修正は悪いデータを正常化することではない。悪いデータを可視化し、公開前チェックを提供し、経路状態変更前にリソース保持者に警告し、緊急修正経路を作成することである。

経路起点検証はまた、誰がミスの代償を払うかを変える。リソース保持者またはアカウント管理者が誤った ROA を公開する可能性がある。即時の接続損失はユーザーと下流サービスが経験する。ROV を実施するトランジットプロバイダーは、そのポリシーがセキュリティモデルの意図通りであるにもかかわらず、トラフィックを落としたことで非難されるかもしれない。悪いオブジェクトを作成した当事者がすべてのサポートコールを受け取るとは限らない。このコスト分割は、証拠が無効性の真の原因を特定しない限り、信頼を損なう可能性がある。

したがって、成熟した説明責任記録は「RPKI が障害を引き起こした」という怠惰なフレーズを避けるべきである。より正確には、不正確な承認が正当なプロダクション経路を無効にし、無効を拒否する検証ネットワークがその声明を実施したのである。根本的な問題は、共有セキュリティシステムにおけるデータガバナンスの失敗であった。

監視は制御プレーンと承認プレーンの両方を監視しなければならない

従来のルーティング監視は BGP アナウンスを監視する。発信元、経路、プレフィックス長、撤回、伝搬である。RPKI は第二の監視層を必要とする。承認プレーンである。BGP スピーカーがそのアナウンスを変更しなくても、経路の有効性は変わり得る。新しく公開された ROA、期限切れの証明書、リポジトリ障害、maxLength の変更により、昨日の有効な経路が今日の無効な経路に変わる可能性がある。BGP のみの監視はもはや十分ではない。

これが、bgp.tools の無効経路アラートのようなサービスが重要である理由である。プレフィックスが RPKI 無効になることは緊急のプロダクションシグナルである。ハイジャック、誤った発信元、maxLength の不一致、古い ROA、リポジトリ問題、または計画された変更の失敗を示す可能性がある。事業者はどのケースが該当するかを迅速に知る必要がある。重要なネットワークの場合、そのアラートは ROA またはルーティングアナウンスを変更する権限を持つ人物を呼び出すべきである。

RIPE Labs によるその後のリアルタイムルーティング分析とインシデント可視化に関する議論は、有用な未来を示している。BGP ビュー、RPKI 有効性、経路伝搬、到達可能性の証拠を1つのワークフローで組み合わせる。北朝鮮インシデント中、外部の観察者は有効性の変更と伝搬の低下を見ることができた。リソース保持者は、公衆が気付く前に、自社のプレフィックスに対して少なくとも同じレベルの可視性を持つべきである。

監視は変更前にも行われるべきである。ROA を公開する前に、ツールは意図した ROA を現在の BGP アナウンスと比較し、無効になるすべての経路をフラグするべきである。その結果が意図的であれば、事業者はルーティング変更と ROA 変更を一緒にスケジュールすべきである。意図的でなければ、ツールは公開を停止すべきである。これは暗号化経路データに適用される通常の変更管理ロジックである。

公共部門のネットワークは特別な注意を必要とする。機関はしばしば契約業者、共有サービス、または上流プロバイダーにルーティングを依存している。ROA 管理が一方のチームにあり、サービス継続性が別のチームにある場合、maxLength のミスが所有権の境界に落ちる可能性がある。継続性計画は、RPKI アカウント保持者、経路セット所有者、緊急連絡先、回復を証明するために必要な証拠を指定すべきである。

検証可能な修復は安心よりも優れている

誤った ROA インシデントは「修正しました」で終わるべきではない。証拠で終わるべきである。どの ROA が間違っていたか？どのプレフィックスが無効になったか？どの発信元が承認されたか？どの maxLength が設定されたか？オブジェクトはいつ公開されたか？どの経路コレクターが伝搬低下を見たか？ROA はいつ修正されたか？依拠当事者キャッシュの収束にどのくらい時間がかかったか？修正後もどのネットワークが経路を拒否し続けたか？これらの詳細により、他の事業者は学び、影響を受けたユーザーは修復を信頼できる。

北朝鮮インシデントは外部から文書化されているが、大企業や公共機関が同等の障害の後に提供すべき完全な事業者ポストモーテムは伴っていない。外部分析はイベントの多くを再構築できるが、内部証拠がなければ、なぜその ROA がそのように作成されたのか、チェックが存在したのか、誰が承認したのか、その後何が変わったのかを答えることはできない。これらの事実は重要である。なぜなら、同じ種類のミスはどこでも再発する可能性があるからである。

RIR とツールプロバイダーにとっての教訓は、危険な ROA 変更を静かに実行することを困難にすることである。インターフェースは現在の BGP アナウンスを表示し、有効性の結果をシミュレーションし、maxLength の競合について警告し、ロールバックのガイダンスを提供し、アラートを促進すべきである。目的は事業者の裁量を奪うことではない。署名オブジェクトの結果を、グローバルな到達性に影響を与える前に可視化することである。

RPKI を検証するネットワークにとっての教訓は、実施を続けながら例外処理を改善することである。事業者は、拒否する無効経路、リソース保持者の連絡先、緊急評価のポリシーを可視化する必要がある。無効を拒否することは、顧客の苦痛を無視することを意味するべきではない。証拠を使用して、経路が悪意があるのか、誤りなのか、古いのかを特定し、修正を適切な所有者に促すことを意味するべきである。

結論は、RPKI がルーティング信頼をデータに変えたということである。それは進歩である。しかし、十分なネットワークがそれに依存するとき、データはインフラになる。したがって、誤った ROA は事務的なミスではなく、インフラインシデントになり得る。ガバナンスは署名オブジェクトの力に追いつかなければならない。

セキュリティ管理が可用性依存関係になった

経路起点検証は、署名された承認と矛盾する経路を拒否することでネットワークをより安全にするように設計されている。その設計こそが、誤った ROA が障害を引き起こす理由である。管理は装飾的ではない。検証ネットワークは実際にそれを使用する。正当な経路が悪い maxLength や発信元の記述のために無効になるとき、無効を拒否するネットワークはリソース保持者の公開データを実施している。したがって、障害は RPKI が運用上意味を持つようになった兆候であり、役に立たないという兆候ではない。

これは、組織がリスクを説明する方法に影響する。リーダーが「RPKI が私たちを壊した」と言うと、バリデーターを無効にして、古くて弱い信頼モデルに戻るかもしれない。もし「経路承認データがルーティングと一致しなかった」と言えば、真の問題を修正できる。北朝鮮インシデントは、承認プレーンとルーティングプレーンの間の不一致として理解するのが最善である。BGP アナウンスは存在し続けた。署名された承認がそれらのグローバルな有効性状態を変えた。

セキュリティ管理によって作成された可用性依存関係は、他のプロダクション依存関係と同じ真剣さで管理されるべきである。DNSSEC トラストアンカー、証明書透過性ログ、OCSP レスポンダー、RPKI リポジトリ、バリデーターフィードはすべてこのカテゴリに含まれる。それらはセキュリティシステムであるが、プロダクショントラフィックの流れに影響を与える。それらをコンプライアンス成果物として扱い、生きたインフラとして扱わないことは、運用上の驚きを招く。

共通モードリスクは導入とともに成長する。RPKI 無効経路を拒否するネットワークが少数しかない場合、誤った ROA の影響は限定的である。多くの主要ネットワークが無効を拒否する場合、同じ誤った ROA が広範な影響を与える可能性がある。それは導入に対する議論ではない。厳格な公開管理の議論である。共有セキュリティメカニズムは、より成功するにつれて、より規律正しくなければならない。

インシデントはまた、RPKI プログラムのより注意深い指標を示唆している。カバレッジ率だけでは十分ではない。ネットワークは高い ROA カバレッジを持ちながら、maxLength 値が間違っていたり、古かったり、広すぎたりするとリスクを生み出す可能性がある。より良い指標は、カバレッジ、有効性の整合性、古いオブジェクトのレビュー、maxLength ポリシー、アラート、リポジトリ健全性、修正時間を組み合わせる。目標は単に「ROA がある」ことではない。目標は「ROA が、インターネットに受け入れさせる意図のある経路を正確に記述している」ことである。

RIR とアカウントのワークフローは制御面の一部である

ROA は多くの場合、RIR ポータルまたは委任ツールを通じて作成される。つまり、ユーザーインターフェース、アカウント権限、承認ワークフロー、警告システムはセキュリティ管理の一部である。適切に設計されたバリデーターは、影響の大きい maxLength のミスを警告なしに通過させる公開ワークフローを補償できない。北朝鮮インシデントは、ROA 作成に、公開前に現在の BGP アナウンスに対するシミュレーションを含めるべき理由を示している。

ポータルは事業者に伝えることができる。この ROA を公開すると、現在表示されているこれらの経路が無効になります。その警告は推測ではない。経路起点検証ロジックから直接導かれる。事業者がそれらの経路を撤回する意図がある場合、警告はタイミングの調整に役立つ。事業者が無効化を意図していなかった場合、警告は障害を防ぐ。RIR とツールベンダーは、そのシミュレーションをオプションの便利機能ではなく、安全ガードとして扱うべきである。

アカウントの所有権も重要である。多くの組織では、ROA を公開できる人物は、ルーターやサービス継続性を管理する人物と同じではない。レジストリ管理者はアドレス管理の観点から行動している一方、NOC は BGP アナウンスを、アプリケーションチームは障害を監視している。それらのチームが接続されていない場合、承認プレーンはルーティングプレーンが適応することなく変更される可能性がある。修正は所有権マッピングである。すべての ROA には、ルーティング所有者、サービス所有者、緊急連絡先、レビュー頻度が必要である。

権限はスコープされるべきである。すべてのレジストリアカウントユーザーが、レビューなしに影響の大きい ROA 変更を行えるべきではない。現在観測されている経路を無効にする変更は、確認を必要とし、重要なリソースには第二の承認者が必要かもしれない。緊急修正経路は存在すべきだが、危険なオブジェクトの緊急作成は可視化され、ログに記録されるべきである。繰り返すが、目的は官僚主義ではない。署名された経路承認の運用力を尊重することである。

不適切な ROA とクリーンアップに関する RIR ガイダンスは、無効状態がしばしば通常のミスから生じるという考えを正常化するため貴重である。それは建設的である。恥は経路セキュリティデータを改善しない。明確な警告、より良いツール、共有例、迅速な修正経路が改善する。インシデントは、RIR、管理サービスプロバイダー、リソース保持者が ROA データに関するワークフローを改善する動機となるべきであり、公開を後退させるべきではない。

バリデーターは例外処理のための証拠を必要とする

無効な経路を拒否するネットワークは、例外処理の規律も必要とする。顧客や公共サービスが経路が RPKI 無効のために到達不能であると苦情を申し立てた場合、検証事業者は一時的なオーバーライドを正当化する証拠を知る必要がある。無効な経路を盲目的に受け入れることはセキュリティを損なう。良性の無効経路の診断を拒否することは、展開への信頼を損なう。中間の道は証拠に基づくトリアージである。

最初の質問は、無効性が発信元の不一致、プレフィックス長の不一致、期限切れまたは欠落した公開、リポジトリ障害、バリデーター状態のいずれによって引き起こされるかである。それぞれの原因は異なる所有者を指す。発信元の不一致はハイジャックか古い移行である可能性がある。プレフィックス長の不一致は maxLength のミスである可能性がある。リポジトリ障害は多くのプレフィックスに影響する可能性がある。バリデーターキャッシュの問題は局所的である可能性がある。優れたツールは無効性を迅速に分類すべきである。

第二の質問は、到達性の損失が広範囲かどうかである。経路コレクター、ルッキンググラス、RIS/RouteViews、商用監視、顧客レポートは、多くのネットワークが経路を落としたか少数だけかを示すことができる。その証拠は緊急度とコミュニケーションの決定に役立つ。影響が限定的な単一の無効経路は通常のチケッティングで処理できる。多くの検証ネットワークで無効化された重要な公共サービスプレフィックスは即時エスカレーションを必要とする。

第三の質問は、誰が信頼の源泉を修復できるかである。リソース保持者が誤った ROA を公開した場合、クリーンな修正は ROA を更新することであり、すべての検証ネットワークにポリシーを無効にするよう求めることではない。BGP アナウンスが間違っている場合、クリーンな修正は経路を変更することである。両方が移行の一部として変更される場合、修正は調整されたシーケンシングである。例外処理は、局所的なバイパスを正常化するのではなく、修正を正しい所有者に促すべきである。

ここで公開インシデント記録が役立つ。北朝鮮の誤った ROA のような既知のインシデントが文書化されると、事業者はそれをトレーニング資料として使用できる。自社の NOC が無効性を認識し、アラートが発動し、レジストリの連絡先が最新であり、営業時間外にロールバックが可能かどうかを問いかけることができる。良いインシデントは次のインシデントのリハーサルになる。

共通モード依存には独立したチェックが必要である

共通モード障害とは、多くの当事者が同じコンポーネントまたは前提に依存するために同じ方法で失敗することを意味する。RPKI では、署名された承認オブジェクトがその共有コンポーネントになる可能性がある。正しければ、多くのネットワークが一緒に改善する。間違っていれば、多くのネットワークが一緒に拒否する可能性がある。したがって、公開前と変更後に独立したチェックが不可欠である。

一つの独立したチェックは BGP 比較である。意図した ROA を現在のグローバルアナウンスと比較する。別の方法は段階的監視である。有効性の変更とロールバックの迅速な観察を可能にする方法で公開する。別の方法は、リソース保持者が運用しないサービスからの外部アラートである。ローカルダッシュボードはオブジェクトが存在すると言うが、外部モニターは経路が現在公開インターネット全体で無効であることを示す。両方とも有用であり、どちらも唯一のシグナルであるべきではない。

第二の独立したチェックは、ポリシー意図の人間によるレビューである。ネットワークはこの/22の下で/24を通知することがあるか？DDoS 緩和のために分割するか？フェイルオーバー時に複数の発信 ASN を使用するか？プロバイダーが代わりに通知するか？移行に一時的な二重発信元を必要とするか？ROA は構文的に正しくても、運用上の現実を無視すると間違っている可能性がある。レビュー担当者は、レジストリ構文だけでなく、ルーティング意図を理解する必要がある。

第三のチェックは、期限切れとリポジトリ健全性である。ROA は、maxLength のミスだけでなく、証明書やリポジトリの問題により無効または利用不能になる可能性がある。バリデーターはキャッシュ動作と障害モードを持つ。リソース保持者は、RPKI リポジトリが到達可能であり、依拠当事者のビューが期待されるオブジェクトと一致するかどうかを監視すべきである。誰も取得できない署名オブジェクトは信頼できる管理ではない。

共通モード思考はコミュニケーションにも影響する。誤った ROA が重要な経路を無効にした場合、多くの検証ネットワークが独立してそれを拒否する可能性がある。リソース保持者は、修正を説明する公開ステータスチャネルまたは連絡先を必要とする。そうでなければ、各プロバイダーが個別のチケットを開き、同じ原因の診断に時間を費やす可能性がある。簡潔な公開メモは重複作業を減らし、収束を加速できる。

インセンティブの問題は証拠が改善すれば解決可能である

RPKI 導入はインセンティブ問題に直面している。なぜなら、無効経路を拒否する利益は分散している一方、良性の無効経路による痛みは即時的かつ局所的である可能性があるからだ。無効を拒否するプロバイダーは、他の誰かが悪い ROA を公開したときに顧客から非難されるかもしれない。無効を受け入れるプロバイダーはサポートコールを避けられるかもしれないが、安全でないグローバルルーティングシステムに貢献する。より良い証拠はその緊張を減らすことができる。

無効アラートが責任のある ROA、影響を受けるプレフィックス、発信元、maxLength、推定所有者を明確に特定すれば、検証プロバイダーは問題を説明し、修正を指摘できる。RIR ツールが公開前に警告すれば、良性の無効が少なくなる。リソース保持者が即座にアラートを受け取れば、多くのユーザーが気付く前に修正できる。公開インシデントレポートがクリーンアップを正常化すれば、組織はミスを隠そうとする誘惑が減る。それぞれの証拠改善は、厳格な検証のコストを下げる。

調達は役立つことができる。大口購入者は、トランジットおよびクラウドプロバイダーに、無効経路を拒否するかどうか、良性の無効イベントをどのように処理するかを尋ねるべきである。また、購入者がアドレススペースを持っている場合、購入者自身の ROA を誰が管理するか尋ねるべきである。あらゆるミスのたびにプロバイダーに無効経路を受け入れるよう圧力をかける購入者は、ルーティングセキュリティを損なう。クリーンな ROA を維持し、厳格な検証を期待する購入者はエコシステムを改善する。

規制当局と政府ネットワークは同じ姿勢を取るべきである。公共部門のアドレスリソースには、ROA の所有権、maxLength ポリシー、経路監視、緊急修正が必要である。政府調達は、プロバイダーに RPKI 検証を求めると同時に、無効経路診断のためのサポートワークフローを要求できる。セキュリティと可用性は、ストレス下でトレードオフされるのではなく、一緒に管理されるべきである。

北朝鮮の誤った ROA インシデントは、経路セキュリティがもはや攻撃者の排除だけではないことをコンパクトに思い出させる。それはまた、権威データの正確性を維持することでもある。署名された声明には力がある。その力には変更管理、監視、説明責任が必要である。

ROA ガバナンスに関する読者の判断

読者は、誤った ROA のケースを RPKI を信頼しない理由として扱うべきではない。より良い判断は、ROA ガバナンスをプロダクションガバナンスとして扱うことである。組織がアドレススペースを持っている場合、ROA データの所有者、通常および緊急通知のマップ、maxLength ポリシー、公開前シミュレーション、無効性のアラート、ロールバックパス、オブジェクトを迅速に修正できる連絡先が必要である。これらの管理がなければ、組織は署名された経路ポリシーを持っているが、管理された経路ポリシーは持っていない。

リソース保持者にとっての当面の質問は、すべての可視経路が意図的かつ正確な ROA でカバーされているかどうかである。これには発信 AS、プレフィックス長、maxLength が含まれる。また、例外的なケースも含まれる。DDoS プロバイダー、バックアップトランジット、エニーキャスト、トラフィックエンジニアリング、移行ウィンドウ、緊急分割である。経路計画と ROA 計画が異なるツールと異なる所有者にある場合、リスクはすでに存在する。

検証ネットワークにとっての判断は、無効を拒否しながら人間的な診断を構築することである。厳格な検証はインターネットを改善するが、顧客は無効経路が良性である場合の明確な証拠を必要とする。事業者は無効性を説明し、責任のあるオブジェクトを指摘し、リソース保持者が信頼の源泉を修正するのを助けるべきである。これにより、あらゆるミスを検証を無効にする圧力に変えることなく、セキュリティを保護できる。

RIR とツールプロバイダーにとっての判断は、危険な ROA 変更を静かに公開することを困難にすることである。現在のアナウンスを表示する。有効性をシミュレーションする。ライブ経路を無効にする前に警告する。監査証跡を保持する。アラートを促進する。緊急修正ガイダンスを提供する。良いインターフェースは、暗号オブジェクトがポータルを離れる前にルーティング障害を防ぐことができる。

北朝鮮インシデントは、公共フットプリントが分析に十分小さかったためコンパクトである。教訓は大きく、依存関係はグローバルである。RPKI 導入が成長するにつれて、署名されたデータの品質は検証の決定と同じくらい重要になる。インターネットは無効経路の拒否に向けて進み続けるべきだが、その未来には経路を有効にする権威データに対するより良いケアが必要である。

障害クラスは一国よりも大きい

北朝鮮の例は可視性のために有用であるが、障害クラスは国固有ではない。カバーする割り当ての下でより具体的な経路を通知するリソース保持者は、狭い maxLength で同じ問題を作り出せる。発信 ASN 間でプレフィックスを移動する組織は、発信元不一致を作り出せる。NOC と調整せずに ROA を変更する管理ネットワークプロバイダーは、プロダクショントラフィックを無効にできる。共通パターンは、運用上の現実と一致しなくなった署名された文書である。

それは、すべての RPKI プログラムに定期的な調整ジョブを含めるべきであることを意味する。グローバル BGP で可視の経路を取得する。現在公開されている ROA を取得する。発信元と maxLength を比較する。カバーされるべきすべての無効および未検出の経路をフラグする。ネットワークが通知する意図のないより具体的な経路を許可する過度に広い承認をすべてレビューする。この調整は一度きりのオンボーディングタスクではない。ルーティングは変化する。プロバイダーは変化する。DDoS 緩和は変化する。合併、売却、クラウド移行は発信元計画を変える。承認プレーンはルーティングプレーンに従わなければならない。

最良の長期的成果は文化的なものである。事業者は、古い ROA に対して、重要なサービスの古い DNS レコードや公開エンドポイントの期限切れ証明書と同じくらい不快に感じるべきである。署名オブジェクトは小さいが、依存関係は大きくなり得る。それを生きたインフラとして扱うことが、信頼を得る経路セキュリティと、最初の痛みを伴うミスの後に無効にされる経路セキュリティの違いである。

その文化はまた、変更レビューの習慣を必要とする。ROA 編集は、厳格な検証の下で到達性を変える可能性がある場合、事務的なレジストリ更新として扱われるべきではない。レビュー担当者は、現在どの経路がライブか、プロバイダー変更後にどの経路がライブになるか、より具体的な経路が意図的に承認されているか、DDoS またはバックアップ発信元が一時的な権限を必要とするか、公開されたオブジェクトがトラフィックを無効にした場合に組織がどのように知るかを尋ねるべきである。ロールバック計画は変更計画と同じくらい明確であるべきである。答えが「誰かが苦情を言うのを待つ」である場合、署名されたデータはプロダクション管理下にない。クラウドプロバイダー、レジストリ、経路サーバー事業者、大企業はすべて、その習慣を正常化することに関与している。なぜなら、権威データが退屈なほど正確である場合に厳格な検証が最も効果的に機能するからである。

同じ習慣は所有権移転もカバーすべきである。アドレスリソースは、買収、レジストリ更新、プロバイダー変更、クラウド移行、災害復旧設計を通じて移動する。ある運用モデルの下で正しかった ROA が、次のモデルの下で有害になる可能性がある。したがって、ガバナンスは引継ぎチェックリストを必要とする。誰がオブジェクトを所有するか、誰がアラートを受信するか、誰が maxLength を承認するか、誰が古い承認を無効にできるか、誰が変更後のグローバル経路可視性を確認するか。北朝鮮の記録は、障害が理解するのに十分小さいため有用である。次の障害は、ストレス下でルーティング計画が変わる銀行、公共機関、CDN 顧客、または緊急サービスを含むかもしれない。署名された経路権限は、検証がそれを実施する前にそのストレスに備えるべきである。

結論

説明責任の基準は、公開証拠と結びついた実践的な管理である。最も強力な記録は、すべての関係者がすべての結果を管理したふりをしない。誰が障害を防げたか、誰がそれを検出できたか、誰が爆発半径を制限できたか、誰が影響を受ける当事者に通知できたか、誰が信頼関係を修復できたか、修復が依存していたシステムと人々に到達したことを証明する証拠を特定する。