Cloudflare のルートリーク対応は、安心感よりも検証可能な修復を重要視した

概要

• 2019年6月、小規模ネットワーク、ルートオプティマイザー、Verizon が関与する BGP ルートリークにより、Cloudflare およびその他のサービスの到達可能性が妨害されました。Cloudflare の公式対応は、自社の直接ネットワーク外でのルーティングセキュリティの障害を正しく強調していました。
• 新たな視点は、安心感と検証可能な修復の比較です。ルートリーク後、プロバイダーの顧客は自信に満ちた説明以上のものを必要とします。経路発信元の権限、上流フィルタリング、検証、監視が改善されたという証拠が必要です。
• Cloudflare は公的記録上、元のリーク元ではありませんでしたが、自社の経路権限、RPKI の推進、顧客とのコミュニケーション、監視、トランジット圧力、残留リスクの公開説明に対して実質的な管理権を持っていました。
• Verizon とリーク元のネットワークは、波及力の高い伝播ポイントを管理していました。したがって、説明責任のマップは、インターネットを匿名の事故として扱うのではなく、発信元、増幅器、影響を受けたプロバイダー、検証ネットワーク、顧客を分離します。
• 持続可能な教訓は、ルーティングインシデントは測定可能な成果物を残すべきであるということです。ROA、無効経路の拒否、フィルター変更、ピア要件、公開経路データ、インシデントタイムライン、およびプロバイダーの行動のみで安全にできることとできないことに関する顧客へのガイダンスです。

証拠記録とその使用方法

この記事では、Cloudflare の公開インシデント分析を第一当事者の影響を受けたプロバイダーの説明として、外部のルーティングおよび業界ソースをルーティングセキュリティの文脈として、RFC または政府ガイダンスを現在の BGP、RPKI、ルートリーク制御のために使用しています。新しい標準は、2019年のすべての参加者に対する遡及的な法的義務としてではなく、検証可能な修復を枠組み化するために使用されます。

安心感は修復ではない

ルートリークは予測可能な広報上の問題を引き起こします。影響を受けたプロバイダーは、障害が自社の直接管理外で発生したことを顧客に安心させたいと考えます。それは真実かもしれません。2019年6月、Cloudflare の公開分析は、Verizon と小規模ネットワークが使用するルートオプティマイザーを含む経路伝播行動を特定しました。Cloudflare は影響を受けたプロバイダーであり、悪いルーティング情報の元のソースではありませんでした。しかし、顧客は責任の割り当てだけを購入するわけではありません。彼らは到達可能なサービスを購入します。ルーティングインシデント後、安心感は修復の証拠になる必要があります。

修復の証拠は、安心感では答えられない質問に答えます。影響を受けたプロバイダーはそのプレフィックスに対して正確な経路発信元認証を公開しましたか？そのトランジットプロバイダーは無効または不正な経路を拒否していますか？プロバイダー自身は他からの無効経路を拒否していますか？ルーティング衛生に基づいてピアを選択または圧力をかけましたか？顧客は公開ルーティングデータが事後分析をサポートしているかどうかを確認できますか？プロバイダーは自社の管理外に残る残留リスクを開示していますか？イベント後にどのような制御が変更されましたか？

Cloudflare の対応は、同社がすでにルーティングセキュリティの擁護者としての立場を確立していたため興味深いものです。同社は RPKI の説明を公開し、ルートフィルタリングと検証の必要性に注意を喚起しました。その擁護は価値があります。説明責任の課題は、それを検証可能にする方法です。プロバイダーはルーティングシステムの改善が必要だと言うことができます。顧客はプロバイダー自身が何をしたかを知る必要があります：ROA、検証ポリシー、トランジット要件、監視、顧客コミュニケーション、インシデント訓練。

この区別は細かいことではありません。インターネットルーティングは多くのプライベートな関係を持つ信頼システムです。顧客はすべてのトランジットフィルターやピアポリシーを検査できません。したがって、公開証拠が不可欠です。ルートコレクター、RPKI リポジトリ、MANRS 参加、インシデントタイムライン、プロバイダーの声明はすべて直接検査の代わりになります。公開証拠が強力であればあるほど、顧客はブランドの信頼に頼らなければならない度合いが減ります。

安心感には賞味期限もあります。インシデント直後は顧客を落ち着かせるかもしれません。数か月後には、相互接続の脆弱性が減少したかどうかが重要な問題です。ブログ投稿だけを残すルートリークは、測定可能な検証、より優れたフィルター、説明責任の圧力を残すものよりもインターネットに教えることが少ないのです。タイトルの教訓は、修復は検査可能でなければならないということです。

リークには発信元、増幅器、被害者の役割があった

ルーティングインシデントは、あたかもインターネットが全般的に失敗したかのように説明されることがよくあります。その表現は説明責任には曖昧すぎます。有用なルートリークマップは役割を分離します。あるネットワークが問題のあるルート情報をリークまたは発信しました。より広いリーチを持つ別のネットワークがそれを受け入れ、伝播しました。Cloudflare などの影響を受けたプロバイダーは、トラフィックが迂回されるか、到達可能性が損なわれるのを目の当たりにしました。他のネットワークはそのルートを受け入れるか、拒否するか、観察しました。顧客はこれらのルーティング決定のいずれも制御せずにサービス障害を経験しました。

この役割マップは2つの誤りを防ぎます。1つ目の誤りは、影響を受けたプロバイダーにすべての到達可能性障害の責任を負わせることです。Cloudflare は Verizon の経路受け入れや小規模ネットワークのルートオプティマイザーを制御していませんでした。2つ目の誤りは、リークが他の場所で発生したために影響を受けたプロバイダーを完全に免責することです。Cloudflare は依然として自社の経路権限、検証体制、監視、顧客とのコミュニケーション、ネットワークパートナーへの商業的圧力を管理していました。説明責任は分散されており、解消されていません。

Verizon の役割は重要でした。増幅によって爆発範囲が決まるからです。小規模ネットワークの悪い経路は、上流でフィルタリングされれば小さく留まります。主要なトランジットプロバイダーの伝播により、それがグローバルになる可能性があります。そのため、上流フィルタリングはオプションの礼儀ではありません。これはリーチを販売するネットワークにとっての安全義務です。プロバイダーのリーチが大きければ大きいほど、伝播するものをより注意深く検証する必要があります。

ルートオプティマイザーの角度は、自動化に関する警告でもあります。BGP の決定を最適化するツールは、影響力の高いルーティング変更を生み出す可能性があります。そのようなツールがプロバイダー関係を越えてルートをリークすることを許可されると、商業的なトラフィックエンジニアリングが公共の障害に変わる可能性があります。自動化は説明責任を減らさず、制約、ルートポリシーテスト、監視の必要性を高めます。

Cloudflare の影響を受けたプロバイダーとしての役割には異なる義務があります：外部の制御障害を可視化し、正確に説明し、そのイベントをより強力なルーティングセキュリティの要求に変換することです。これは正当な説明責任の形態です。プロバイダーは元のリークを引き起こさなかった場合でも、エコシステムの修復に貢献できます。重要なのは修復を測定可能にすることです。

RPKI は証拠基準を変える

RPKI が重要なのは、経路権限の一部の質問を暗号的に検証可能なデータに変えるからです。リソース保有者は、どの自律システムがプレフィックスを発信することを許可され、どの最大長で許可されるかを示す経路発信元認証を公開できます。経路発信元検証を実行するネットワークは、受信した経路を分類し、ポリシーで要求される場合に無効な発信元を拒否できます。これはすべてのルートリークを解決するわけではありませんが、何が証明できるかを変えます。

Cloudflare にとって、RPKI は単なる技術的な修正ではありませんでした。それは説明責任の手段でした。同社が自社のプレフィックスに対して正確な ROA を公開すれば、顧客や他のネットワークは権限記録の一部を検査できます。ネットワークが無効な経路を拒否すれば、一部の誤った発信元のアナウンスは危険性が低くなります。Cloudflare が測定と採用を推進すれば、依然として無効な権限を受け入れているネットワークに圧力がかかります。修復はプライベートな保証への依存度が低くなります。

RPKI は魔法の盾ではありません。ルートリークには、元の発信元 AS がまだ許可されているため経路が発信元として有効でありながら、パス関係が間違っている場合が含まれます。そのため、RFC 7908 ルートリーク分類法や BGP ロールなどの後のメカニズムが重要です。経路発信元検証は誰が発信できるかに答え、ルートリーク防止はまた、そのルートが特定の関係を越えて伝播されるべきかどうかを尋ねます。検証可能な修復には、発信元検証と関係認識型フィルタリングの両方が含まれなければなりません。

このニュアンスは、誠実な顧客コミュニケーションにとって重要です。プロバイダーは RPKI がすべてのルーティングインシデントを不可能にすることを示唆すべきではありません。RPKI が何を防止でき、何を防止できず、どのような補完的制御が必要かを説明すべきです。顧客は残留リスクを理解できます。制御を誇張することは、修復を伴わない別の形の安心感です。

RPKI の公共的価値は、成果物を作り出すことです。ROA はチェックできます。無効経路の拒否は測定できます。採用は追跡できます。ネットワークオペレーターはなぜ検証するのか、しないのかを尋ねられます。これらの成果物は、インシデント後の謝罪よりも確かなものを顧客に提供します。Cloudflare のルーティングセキュリティ擁護は、そのような検査可能な証拠と結びついているときに最も強力です。

MANRS スタイルの規範はプライベートルーティングを公共の期待に変える

MANRS が重要なのは、ルーティングセキュリティは単一のプロバイダーだけでは解決できないからです。発信元のネットワーク、受け入れる上流、伝播するピア、検証する下流がすべて結果を形成します。フィルタリング、アンチスプーフィング、調整、グローバル検証などの自主的な規範は、プライベートな相互接続行動を公共の期待として可視化します。それらはコンプライアンスを保証しませんが、責任あるオペレーターが示すべきものを定義します。

2019年6月のインシデントにとって、MANRS のレンズは直接的です。不正なルーティング情報が関係境界を逃れ、広く伝播されたためにリークは有害になりました。顧客のアナウンスをフィルタリングし、正確なルーティング情報を維持することは、中心的な防止義務です。リークが進行中の場合、調整と連絡の準備が重要です。経路を受信するネットワークでは検証が重要です。単一の層がすべての障害を捕捉できないため、システムはこれらの制御をすべて必要とします。

したがって、Cloudflare の対応は、その市場での立場を利用してこれらの規範を押し進めた方法によって部分的に判断されるべきです。トランジットプロバイダーにより良いルーティング衛生を要求しましたか？フィルタリングの役割を公表しましたか？ルーティングセキュリティの採用を容易にしたり、可視化したりしましたか？顧客が自社のプロバイダーの上流の選択がなぜ重要かを理解できるよう、公開教育を支援しましたか？これらの行動は、障害をエコシステムへの圧力に変えることができます。

顧客はまた、調達において MANRS スタイルの質問を使用できます。プロバイダーは顧客経路をフィルタリングしますか？RPKI を検証しますか？正確な経路オブジェクトを維持していますか？24時間のルーティングセキュリティ連絡先がありますか？認知されたルーティングセキュリティイニシアチブに参加していますか？ルーティングに問題が発生したときにインシデントレポートを公開していますか？エッジセキュリティを購入する顧客は、ルーティングセキュリティについて尋ねるべきです。なぜなら、エッジはルーティングシステムを通じてのみ到達可能だからです。

重要なのは、自主的な規範が規制や契約に取って代わるということではありません。重要なのは、ルーティング行動がしばしばプライベート契約と公共の害の間に存在するということです。MANRS スタイルの期待は、顧客とピアにその行動について尋ねるための語彙を提供します。検証可能な修復は、テスト可能な語彙に依存しています。

公開 BGP 証拠はインシデント記録の一部である

ルートリークは、部外者が重要な部分を観察できるという点で、インフラインシデントの中でも異例です。RouteViews、RIPE RIS、その他のコレクターはプライベートルーターの意図を明らかにしませんが、多くの視点からのアナウンス、撤回、AS パス、タイミングを示すことができます。この公開証拠は、インシデントのナラティブを検証または異議申し立てするのに役立ちます。また、影響を受けたプロバイダーが顧客にすべての主張を盲目的に受け入れるよう求めずに何が起こったかを説明するのにも役立ちます。

Cloudflare の公開分析は、ルーティング証拠を使用して障害がどのように発生したかを示しました。それは良い慣行です。ルートリークの事後分析には、メカニズムを読み解くのに十分な公開ルートデータを含めるべきです：どのプレフィックスが影響を受けたか、どの AS パスが関与したか、時間の経過とともに何が変わったか、伝播がいつ停止したか、どの緩和策が重要だったか。目的は読者を BGP テーブルで圧倒することではなく、因果関係のストーリーを監査可能にすることです。

公開証拠はまた、曖昧な非難から守ります。プロバイダーが上流がルートをリークしたと言う場合、経路記録はその主張を支持すべきです。上流がフィルタリングを修正したと言う場合、その後の経路行動は修正と一致すべきです。ネットワークが無効な RPKI 経路を拒否すると言う場合、公開測定はそれを大まかにテストできるべきです。ルーティングセキュリティの主張が測定可能になればなるほど、評判だけの修復の余地は少なくなります。

顧客は、インシデント後の経路証拠を利用可能な形で要求すべきです。短いナラティブは経営陣に役立ちます。技術的な付録はネットワークチームに役立ちます。タイムラインはインシデントマネージャーに役立ちます。変更された制御のリストはリスクオーナーに役立ちます。顧客は、プロバイダーが説明から修復に移行したかどうかを理解するために BGP の専門家である必要はありません。

公開経路証拠には限界があります。すべてのプライベートピア、ポリシー決定、内部アラームを捕捉できない場合があります。ノイズが多い場合があります。専門家の解釈が必要な場合があります。しかし、その限界はそれを省略する理由にはなりません。ルーティングの説明責任において、不完全な公開証拠は、プライベートな安心感だけよりも優れています。

トランジットプロバイダーの説明責任は影響力の高いポイントである

2019年6月のインシデントは、トランジットプロバイダーが高い影響力を持つことを再び示しました。小規模ネットワークがリークする可能性があります。ルートオプティマイザーが誤動作する可能性があります。しかし、主要なトランジットプロバイダーは、そのルートが広く信じられるかどうかを決定できます。プロバイダーの顧客フィルター、プレフィックス制限、経路検証、関係ポリシーは、悪い情報がどこまで伝わるかを決定するため、公共の安全制御です。

ここで商業的インセンティブが失敗する可能性があります。トランジットプロバイダーはリーチ、パフォーマンス、価格で競争します。フィルタリングと検証には運用努力が必要であり、顧客の摩擦を生み出す可能性があります。市場がルーティング衛生に報いなければ、プロバイダーはインシデントが評判のコストを生み出すまで過小投資する可能性があります。したがって、顧客と影響を受けたネットワークは、ルーティング衛生をベンダー選定とピアリング圧力の一部にすべきです。

Cloudflare の増幅ポイントに対する公開批判は、有用な市場機能を果たしました。影響力の高い失敗を名指ししました。しかし、名前を挙げることは始まりに過ぎません。検証可能な修復には、トランジットポリシーが変更されたこと、無効または不正な経路が拒否されていること、顧客経路セットが維持されていること、ルートリークが迅速な封じ込めを引き起こすことの証拠が必要です。その証拠の一部は公的コミットメントから、一部は測定から、一部は契約要件から、一部は将来のインシデントの不在と監査から得られるかもしれません。

影響を受けたプロバイダーにも影響力があります。大規模なエッジネットワークは、トランジット関係を選択し、ピアリングの好みを設定し、ルーティングセキュリティ要件を公開し、プロバイダー衛生について顧客を教育できます。インターネット上のすべてのネットワークに検証を強制することはできませんが、自社の相互接続に関するインセンティブをシフトできます。プロバイダーがセキュリティと信頼性を販売する場合、ルーティングセキュリティの調達は製品の一部であり、ネットワークチームのバックグラウンドワークだけではありません。

より広範な政策の教訓は、上流フィルタリングはリーチに付随する義務として扱われるべきであるということです。ネットワークが販売するグローバルリーチが大きければ大きいほど、悪い経路を受け入れることで生み出す公共の害も大きくなります。その義務は、規範、契約、監査、インシデント後のレポートにおいて可視化されるべきです。

ルーティング障害下での顧客の継続性には限界がある

顧客は、プロバイダーの障害後に自分たちが何を異なる方法でできたのかとよく尋ねます。主要なエッジプロバイダーに影響を与えるルートリークの場合、答えは心地よくないかもしれません：顧客が事前に独立した配信パスを構築していない限り、リアルタイムでできることは多くありません。公共インターネットがプロバイダーの正当なパスからトラフィックを迂回させる場合、顧客のオリジンは正常でも、期待されるエッジを介して到達可能でない可能性があります。DNS フェイルオーバーは一部のアーキテクチャで役立つかもしれませんが、キャッシュ、証明書設定、オリジン容量、代替プロバイダーの準備によって制約される可能性があります。

それは顧客が無力であることを意味しません。顧客は重要なサービスを分類し、代替ステータスページを維持し、選択されたワークロードにマルチ CDN またはダイレクトオリジンフォールバックを使用し、多様なネットワークから監視し、同じプロバイダーの背後にすべての公開通信チャネルを配置しないようにすることができます。しかし、これらの対策には計画が必要です。ルートリーク中、即興はほとんど十分ではありません。

したがって、Cloudflare の顧客に対する説明責任は部分的に説明責任です。Cloudflare は、RPKI、ルート監視、トランジット選択を通じてどのリスクを低減できるか、そしてどのリスクが顧客のアーキテクチャを必要とするかを顧客に伝えるべきです。すべてのインターネットルーティング障害を吸収できると示唆するプロバイダーは、誤った信頼を招きます。残留リスクを説明するプロバイダーは、顧客がより良い継続性の決定を行うのに役立ちます。

顧客契約とリスク評価はこれを反映すべきです。サービスレベルコミットメントは、ルートリークの完全な運用上の影響をカバーしない場合があります。クレジットはサービスを到達可能に保ちません。顧客は、重要なワークロードに配信の多様性が必要かどうか、その多様性が真に独立しているかどうか、緊急通信チャネルが同じルーティング障害を生き延びるかどうかを尋ねるべきです。答えはワークロードによって異なるかもしれませんが、影響の大きいサービスには質問が必須です。

ルートリークインシデントはまた、依存関係リスクが障害まで不可視である可能性があることを示しています。顧客は、どのトランジット関係またはルートポリシーがプロバイダーを介した到達可能性を形成しているかを知らないかもしれません。そのため、プロバイダーの透明性が重要です。顧客は、プロバイダーが読み取り可能にしようとしないものを管理できません。

検証可能な修復にはチェックリストが必要

信頼できるルートリーク修復記録には、観察可能な要素が必要です。第一に、ルート伝播、検出、緩和、復旧の正確なタイムライン。第二に、発信元、増幅器、影響を受けたプレフィックス、既知の検証ネットワークを特定する役割マップ。第三に、経路発信元の証拠：ROA、maxLength の選択、検証体制。第四に、フィルタリングの証拠：顧客経路セット制御、無効経路拒否、ルートリーク防止方法。第五に、調整の証拠：連絡先、エスカレーション、責任ネットワークとの通信。第六に、残留リスクと可能な継続性設計に関する顧客ガイダンス。

そのようなチェックリストがあれば、2019年6月のイベントは単なるナラティブ以上のものになっていたでしょう。Cloudflare はかなりの公開説明と擁護を提供しました。次の説明責任のステップは、すべての主張を耐久性のある成果物に結び付けることです。RPKI が答えの一部であれば、採用を示してください。上流フィルタリングが答えの一部であれば、上流への期待を述べてください。公開ルートコレクターがタイムラインをサポートする場合、検査するのに十分なデータを含めてください。顧客がアーキテクチャの変更を必要とする場合、直接そう述べてください。

このチェックリストはまた、影響を受けたプロバイダーを保護します。プロバイダーが ROA を公開し、経路を検証し、公開 BGP を監視し、責任あるトランジットを選択し、迅速にエスカレーションしたことを示せるとき、顧客は残留リスクがより広範なルーティングエコシステムから来たことを理解できます。その証拠がなければ、顧客は安心感だけを聞くかもしれません。証拠は、プロバイダーが実際に障害の発信元でなかった場合の最も強力な防御です。

検証可能な修復は、インシデント全体で繰り返し可能であるべきです。同じ構造は、CDN、クラウドプロバイダー、銀行、政府ポータル、ソフトウェアリポジトリに影響を与えるリークに適用できます。詳細は異なりますが、説明責任の要素は同じままです：経路権限、伝播制御、検証、監視、調整、顧客の継続性。

チェックリストはまた、技術の進化に応じて更新されるべきです。RFC 9234 の BGP ロールと Only-to-Customer メカニズムは、RPKI 発信元検証だけでは解決できない関係認識型のリーク防止に対処します。プロバイダーは修復モデルを2019年に利用可能だった制御で固定化すべきではありません。真の修復プログラムは、より良いメカニズムが展開可能になるにつれて採用します。

擁護は調達と組み合わせることでより強力になる

Cloudflare はその公開プラットフォームを利用して、より良いルーティングセキュリティを推進してきました。ルーティングセキュリティは集団行動の作業であるため、擁護は重要です。しかし、擁護は調達と運用のコミットメントと組み合わせることでより強力になります。プロバイダーは RPKI について書く一方で、同じ価値観を反映するパートナー、ピア、トランジットの取り決めを選択できます。自社のネットワーク購入において気にかけていることを示しながら、顧客にも気にかけるよう求めることができます。

この組み合わせが重要なのは、ルーティングセキュリティの採用がフリーライダーのダイナミクスに苦しむ可能性があるからです。責任あるネットワークが検証しても、無責任なネットワークが悪い経路を伝播し続ければ、誰もがさらされたままです。大規模プロバイダーは、ルーティング衛生を商業関係の一部にすることでインセンティブを変えることができます。弱いフィルタリングのために重要な顧客を失うリスクがあるトランジットプロバイダーは、改善するより強力な理由があります。経路オブジェクトを維持できないピアは、より厳しい監視に直面します。無効を拒否するネットワークは、その成熟度を宣伝できます。

顧客は同じインセンティブを強化できます。彼らはエッジプロバイダーに、どのトランジットプロバイダーを使用しているか、RPKI を検証しているか、MANRS のような制御を維持しているか、リークにどのように対応しているかを尋ねることができます。すべての詳細が公開されるわけではありませんが、繰り返される買い手の圧力は会話を変えます。ルーティングセキュリティは、ニッチなネットワークエンジニアリングのトピックではなく、信頼性調達の一部になるべきです。

Cloudflare の影響を受けたプロバイダーとしての立場は、このアジェンダを推進する信頼性を与えます。同社は害を経験し、幅広い聴衆に説明することができました。説明責任の基準は、その信頼性を測定可能なエコシステムへの圧力に変換し続けることです。説得力のあるブログ投稿は有用ですが、変化したルーティング市場はより良いものです。

同じ原則は、安全な到達可能性を販売するすべてのプロバイダーに適用されます。製品の約束が顧客をオンラインで保護し続けることを含む場合、ルーティングセキュリティの調達は製品の作業です。ネットワーク運用と顧客信頼の間の境界は、障害時には人為的です。

ルートリークはエッジ冗長性の限界を明らかにする

Cloudflare は大規模なグローバルエッジネットワークを運用していますが、ルートリークインシデントは、物理的およびソフトウェアの冗長性がドメイン間ルーティングへの依存を排除しないことを示しました。プロバイダーは多くのデータセンター、多くのサーバー、洗練されたトラフィック管理を持つことができますが、それでもインターネットが悪いパスを信じる場合には影響を受ける可能性があります。プロバイダーの資産内での冗長性は必要ですが、それはルーティングの独立性と同じではありません。エッジへの公開パスはサービスの一部です。

これは顧客の期待にとって重要です。顧客は、規模が免疫を生み出すと想定してエッジサービスを購入することがよくあります。規模は容量と多くの復旧オプションを生み出しますが、より多くの相互接続関係と他者のルーティング決定へのより多くの露出も生み出します。主要なトランジットプロバイダーが悪い経路を伝播する場合、グローバルエッジは特定の方法でグローバルに誤った到達可能性になる可能性があります。顧客は、プロバイダーの内部復元力とインターネットの外部ルーティング衛生が異なる層であることを理解する必要があります。

Cloudflare の公開コミュニケーションは、サービス復元力とルーティングエコシステムリスクを区別することで、この期待ギャップを減らすことができます。事後分析は、どの部分が Cloudflare の管理下にあり、どの部分が外部にあり、どの緩和策が境界を橋渡しするかを述べるべきです。RPKI 公開は1つの橋です。無効経路拒否は別のものです。トランジット選択とピアリングポリシーは別のものです。公開 BGP 監視は別のものです。顧客側のマルチプロバイダー配信は、重要度の高いワークロードには別のものかもしれません。この層状の説明がなければ、顧客はプロバイダーを過信するか、すべての外部ルート障害について誤って非難する可能性があります。

エッジ冗長性の教訓は、インシデント訓練にも影響します。プロバイダーは、データセンターの喪失やソフトウェアの回帰だけでなく、ルートハイジャック、ルートリーク、無効発信元の受け入れ、トランジットプロバイダーの誤動作シナリオもテストすべきです。これらの訓練には顧客コミュニケーションを含めるべきです。なぜなら、ルーティングインシデントはネットワーク以外のチームにとって混乱を招くからです。一部の地域から断続的なエラーを見る顧客は、問題がオリジンの健全性、DNS、CDN ソフトウェア、ISP フィルタリング、ルート伝播のいずれにあるのかを知らないかもしれません。層を迅速に説明するプロバイダーの能力は、復元力の一部です。

したがって、最良の修復証拠にはシナリオカバレッジが含まれます。プロバイダーはルートリーク検出をテストしましたか？トランジットエスカレーションをリハーサルしましたか？ROA の正確性を検証しましたか？疑わしい AS パスを監視しましたか？ルーティングインシデント用の顧客向け言語を準備しましたか？これらの質問は、ルーティングを専門家だけのドメインから説明責任のあるサービス義務に変えます。

偽の経路は信頼債務を生み出す

ルートリークは信頼債務イベントです。それは、ネットワークが受け入れるべきではなかったパスを受け入れたか、移動すべきではなかった関係を越えてルートを伝播したことを明らかにします。債務は、障害中に影響を受けたプロバイダーとユーザーによって支払われますが、基盤となる信頼の前提が修正されなければ、その後も残ります。安心感はその瞬間を静めることができます。修復は債務を返済します。

信頼債務は累積的です。公共のルートリークのたびに、顧客はインターネットの到達可能性が見えない制御に依存していることを学びます。対応がナラティブだけなら、次のインシデントが避けられないと感じられるため、信頼は弱まります。対応が測定可能な改善を生み出すなら、システムがより検査可能になるため、信頼は回復できます。RPKI の採用、ルートフィルタリングのコミットメント、公開ルート監視は単なる技術的な衛生ではなく、信頼再構築のツールです。

Cloudflare の役割は複雑です。同社はルーティング信頼失敗の犠牲者であると同時に、インターネット信頼サービスの販売者でもあります。その二重の役割は基準を引き上げます。顧客は、同社が回復するだけでなく、インターネットの脆弱性を説明し、信頼できる修正を推進することを期待します。Cloudflare がルーティングセキュリティの解説を公開するとき、それは自社のインシデントを公開教育に変換しています。次のステップは、その教育のどの部分が自社のネットワークと商業関係で運用化されているかを示すことです。

信頼債務はまた、増幅ネットワークに属します。悪い経路を受け入れて伝播するトランジットプロバイダーは、直接の顧客を超えて信頼を損なう。その債務は、将来の調達とピアリングの会話に従うべきです。フィルターを変更しましたか？より多くの経路を検証しましたか？ルーティングセキュリティ規範に参加または準拠しましたか？透明性をもって報告しましたか？そうでなければ、市場が同じ行動が再発しないと信じる理由はほとんどありません。

顧客にとって、信頼債務はリスクレジスターに現れるべきです。重要なサービスがグローバルなルーティングインシデントにさらされたプロバイダーに依存している場合、リスクは障害モードと制御を明記すべきです。それは、一般的なインターネット障害の言葉の下に隠されるべきではありません。具体性こそが修復を測定可能にするものです。

最大長はガバナンスの決定である

RPKI の修復は、ROA を作成するだけでなく、注意深く作成することに依存します。ROA は発信元 AS を許可し、最大プレフィックス長を設定できます。その最大長は重要です。広すぎると、保護を弱めるより具体的なアナウンスを許可する可能性があります。狭すぎると、正当なトラフィックエンジニアリングや緊急時の非集約が無効になる可能性があります。したがって、経路発信元の証拠には、チェックボックス公開だけでなくガバナンスが必要です。

グローバルエッジプロバイダーにとって、maxLength の決定は文書化されたルーティングプラクティスに結び付けられるべきです。どのプレフィックスが通常アナウンスされますか？どのより具体的なものがトラフィックエンジニアリングに使用されますか？緊急時に使用される可能性があるものはどれですか？決して現れるべきでないものはどれですか？変更を承認するのは誰ですか？ROA は公開前にどのようにテストされますか？エラーはどのくらい早く修正できますか？これらは顧客に影響を与える運用上の質問です。

2019年6月のルートリーク議論はこれを具体的にします。なぜなら、ルートリークとハイジャックはしばしば、より具体的な経路の優先度や伝播の誤りを悪用するからです。RPKI は一部の誤った発信元を無効にできますが、ROA が過度に寛容な場合、誤った安全感を生み出すこともあります。したがって、検証可能な修復には、経路権限が正確で維持されているという証拠を含める必要があります。古くなったまたはずさんな ROA 記録は修復ではなく、新たなリスクの源です。

顧客はすべての ROA を一行ごとに検査する必要はありませんが、洗練された顧客や公的観察者は、プロバイダーが規律ある RPKI 体制を持っていることを確認できるべきです。公開ツールは存在と有効性をチェックできます。プロバイダーの声明はポリシーを説明できます。インシデントレポートは、経路発信元検証が役立ったか、または役立ったであろうかを説明できます。ここで技術的成果物がガバナンス成果物になります。

経路権限はまた、顧客のオンボーディングと交差します。CDN またはエッジプロバイダーが顧客所有のプレフィックスをアナウンスしたり、持込 IP の取り決めをサポートする場合、ROA の調整は顧客リスクの一部になります。プロバイダーと顧客は、発信元の許可、maxLength、緊急手順を調整する必要があります。不一致は無効な経路を作成したり、保護を弱めたりする可能性があります。検証可能な修復は、プロバイダー所有のプレフィックスだけでなく、これらの顧客エッジケースもカバーすべきです。

関係リークには関係証拠が必要

RPKI 発信元検証は特定の質問に答える：この発信元 AS はこのプレフィックスに対して許可されていますか？ルートリークはしばしば別の質問を問う：このルートはある関係から別の関係に渡されるべきでしたか？ルートは発信元としては有効でありながら、リークされる可能性があります。そのため、ルートフィルタリング、BGP ロール、Only-to-Customer メカニズムなどの関係認識型制御が重要です。検証可能な修復は関係層に対処しなければなりません。

2019年6月のイベントでは、有害なパターンは、ルートがその規模で広がるべきではなかったネットワーク間での伝播を伴いました。正確なプライベートポリシーは顧客には完全には見えないため、公開修復証拠は制御のクラスを説明しなければなりません。プロバイダーは顧客固有のプレフィックスフィルターを要求しましたか？ネイバーロールを分類しましたか？ビジネス関係に基づいてルート伝播を制限しましたか？正確な IRR および RPKI データを維持しましたか？通常の関係と矛盾するパス異常を監視しましたか？

RFC 9234 は重要なのは、それが BGP リーク防止に関係ロールをエンコードする標準化トラックの試みを表すからです。これはインシデントを後日にするため、将来のメカニズムで2019年の行動を判断するために使用すべきではありません。現在の修復基準を引き上げるために使用すべきです。プロバイダーはインシデント発生時に一般的だった制御で停止すべきではありません。同じクラスのリスクを現在どの新しいメカニズムが低減できるかを問うべきです。

関係証拠は発信元証拠よりも公開が難しいのは、商業関係が機密になる可能性があるからです。それでも、プロバイダーはすべてのプライベート条件を公開せずにポリシーコミットメントを開示できます。顧客経路は期待されるプレフィックスに対してフィルタリングされ、無効な RPKI 経路は拒否され、ピアと顧客の関係は分類され、ルートリークはアラームをトリガーし、トランジットプロバイダーはルート衛生について評価されることを述べることができます。また、そのようなステートメントを比較可能にする業界規範をサポートすることもできます。

顧客にとっての価値は明確さです。プロバイダーが RPKI を持っていると言っても、ルートリークについて何も言わなければ、顧客は保護を過大評価するかもしれません。発信元検証と関係フィルタリングを区別すれば、顧客はより正直なリスク像を得ます。正直なリスク像は修復の一部です。

インシデントの言葉は因果関係を平坦化すべきではない

ルーティングインシデントは技術的に dense であり、dense なインシデントは平坦化されやすい。企業はルートリークが発生し、上流が原因で、サービスに影響があり、是正が進行中であると言うかもしれません。その言葉は真実かもしれませんが、不十分です。平坦化された言葉は、誰がどの制御を持っていたか、どの制御が失敗したか、どの制御が変更されたかを隠します。検証可能な修復文化は正確な因果関係を使用します。

正確な因果関係は、リークソース、オプティマイザーまたは自動化メカニズム、増幅ネットワーク、影響を受けたプレフィックス、検証または非検証の受信者、検出パス、顧客に可視の症状を分離します。また、公開証拠が不完全な場合には不確実性を述べます。これは、すべてのプライベート詳細が既知であるふりをしないため、顧客がレポートを信頼するのに役立ちます。また、影響を受けたプロバイダーが上流の失敗をすべての顧客影響の包括的な説明として使用することを防ぎます。

Cloudflare のインシデント分析は、ルーティング行動を名指しし、上流フィルタリングがなぜ重要かを説明したため、一般的な声明よりも強力でした。より広範な基準は、すべての主要なルーティングインシデントには、顧客が制御を更新するのに十分な因果構造が含まれるべきであるということです。セキュリティチームは、RPKI は役立ったか？ルートリーク防止は役立ったか？マルチプロバイダー配信は役立ったか？プロバイダーは迅速に監視したか？自社のステータスコミュニケーションは生き残ったか？と尋ねることができるべきです。

言語はまた、公共のインセンティブに影響します。レポートがルーティングインシデントを避けられないインターネットの奇妙さとして説明するなら、オペレーターは改善への圧力が少なくなります。レポートが正確に欠落したフィルターや検証失敗を説明するなら、責任ネットワークは監視に直面します。目的はそれ自体のための公開羞辱ではありません。失敗モードを十分に具体化して、市場が修復に報いることができるようにすることです。

精度は復旧の主張にも及ぶべきです。プロバイダーは、経路撤回、経路伝播収束、サービス復旧、顧客可視の復旧、インシデント後の監視を区別すべきです。これらのマイルストーンは異なる可能性があります。経路は、キャッシュ、セッション、または顧客モニターが正常に戻る前に修正される可能性があります。顧客は自社のレポートのためにそのニュアンスを必要とします。

修復基準は公開証明である

Cloudflare の2019年6月のルートリーク対応は、不可視のルーティング障害を幅広い聴衆に理解可能にしたため価値があります。しかし、記事の説明責任基準は説明よりも高いです。影響を受けたプロバイダー、増幅トランジットプロバイダー、より広範なルーティングコミュニティは、脆弱性が低減されたという公開証明を残すべきです。証明は部分的であり得ます。技術的であり得ます。RPKI リポジトリ、ルートコレクター、MANRS コミットメント、プロバイダーポリシー、インシデントレポートに分散され得ます。しかし、それは自信以上のものでなければなりません。

Cloudflare はその証明の重要な部分を管理していました：自社の経路権限、監視、公開教育、検証体制、顧客ガイダンス、商業的圧力。Verizon とリーク元のネットワークは他の部分を管理していました：フィルタリング、経路ポリシーの規律、伝播。顧客は事前に構築された継続性オプションと調達圧力のみを管理していました。その制御マップは、安心感だけが不十分である理由を説明します。各主体は、自らが管理するポイントで修復を示さなければなりません。

永続的な教訓は、インターネットの到達可能性は自己実行型の信頼ではないということです。それは、BGP、DNS、レジストリ、契約、ピアリング関係を通じて交換される一連の運用上の約束です。それらの約束が失敗したとき、対応は検査可能でなければなりません。グローバルエッジプロバイダーを混乱させるルートリークは、誰が発信でき、誰が伝播でき、誰が検証し、誰が監視し、誰が復旧できるかについて、より良い公開記録を生み出すべきです。

リーク後の Cloudflare の最大の貢献は、単に別のネットワークが問題を引き起こしたと言うことではありませんでした。ルーティングセキュリティ問題を可視化したことでした。すべてのプロバイダーにとっての次のステップは、修復も可視化することです。顧客は、ブランドを信じることとルートを理解することの間で選択する必要があるべきではありません。彼らは、安心感がより安全なルーティングになったという証拠を見ることができるべきです。