Cloudflare、2019 年 6 月のルート漏洩とネットワーク境界を超えた説明責任

概要

• 2019 年 6 月 24 日、DQE Communications のネットワーク内部で生成された最適化されたより具体的な経路が、顧客である AS396531 を経由して Verizon の AS701 に受け入れられた。Verizon はその後、数千のネットワークをカバーする経路を伝播させた。ルーターはより具体的な宛先プレフィックスを優先するため、大量のトラフィックが漏洩経路を辿り、それを処理する能力のないリンクに流れ込んだ。Cloudflare はインシデントの最悪の時点でグローバルトラフィックの約 15%を失ったと報告している。
• 公開された経路記録は、単一原因のスローガンではなく、一連の制御の失敗を裏付けている。経路生成装置は最適化経路をローカルに留めず、マルチホーム接続の顧客がプロバイダーから学習した経路を別のプロバイダーにエクスポートし、大規模なトランジットネットワークがその顧客に期待される経路権限に適合しない経路を受け入れて拡散させた。Cloudflare は検知、連絡、経路の撤回支援を行うことはできたが、他のネットワークのインポートポリシーを一方的に変更することはできなかった。
• RPKI 経路起点検証は、このイベントの Cloudflare 部分に非常に適合していた。Cloudflare の Route Origin Authorization（ROA）は集約プレフィックスを指定された最大長のみ許可しており、漏洩したより具体的な経路はその長さを超えていたため無効だったからである。しかし、これによって RPKI が完全な経路漏洩対策になるわけではない。起点が有効な経路でも商業的関係を侵害する可能性があり、そのため顧客フィルタリング、プレフィックス制限、BGP Roles、経路制御、モニタリング、連絡可能なオペレータの連絡先が依然として必要である。
• 説明責任は制御能力に従う。例外的な経路を生成またはエクスポートする事業者はそれを封じ込めテストしなければならない。プロバイダーは顧客が何をアナウンスできるかを検証しなければならない。クラウドプラットフォームは経路権限を公開し、外部経路を観測し、迅速に連携し、顧客への影響を開示しなければならない。顧客は依存関係の障害に備えた計画を立てなければならない。取締役会や規制当局は、業界のベストプラクティスに従っているという一般的な声明ではなく、測定可能な経路セキュリティの保証を要求すべきである。

ルーティング障害であり、Cloudflare のサーバー障害ではない

2019 年 6 月 24 日 10:34:25（UTC）、公開 BGP コレクターが Cloudflare のアドレス空間に対する異常な、より具体的な経路の記録を開始した。調査対象となった Cloudflare の経路の最後のものは 12:38:54（UTC）に消失した。Cloudflare のアーカイブ経路の詳細調査は、RIPE NCC のデータからその期間を再構成し、驚くほど一貫した経路を示している：Cloudflare の AS13335、そのトランジットプロバイダーの 1 つ、DQE Communications の AS33154、Allegheny Technologies の AS396531、そして Verizon の AS701 である。その後、他のネットワークは Verizon を通じてこの経路を学習した。

この経路が重要なのは、障害が Cloudflare のデータセンター障害やアプリケーションの展開から始まったわけではないからだ。Cloudflare のマシンは通常の集約経路を継続してアナウンスしていた。グローバルルーティングシステムが単に同じアドレス空間のより小さな部分について競合する経路を学習したのである。それらのより小さな部分が多くのネットワークで転送判断に勝ち、パケットを意図しない経路に誘導した。リクエストが Cloudflare のエッジに到達する前に輻輳とパケットロスが発生した。

Cloudflare の当時のインシデント説明では、最悪の時点でグローバルトラフィックの約 15%が失われたと報告された。これは企業による測定値であり、独立して監査された普遍的な停止率ではない。Cloudflare のトラフィックを説明するものであり、インターネット全体の 15%ではない。しかし独立した観測は、大まかなメカニズムとサービス横断的な影響を裏付けている。ThousandEyes はネットワーク経路分析で、ユーザーが約 2 時間にわたり Cloudflare がフロントエンドを務めるサービスや一部の AWS サービスに到達するのに困難をきたしたと報告し、Catchpoint のインシデントレビューでは、10:30 UTC 頃に特定のオンラインサービス全体でパフォーマンス問題が記録された。

経路の可用性とサーバーの可用性の区別は説明責任にとって重要である。プラットフォームは多くの国で健全なサーバーを運用していても、ルーティング制御プレーンがトラフィックを別の場所に誘導すれば到達不能になる可能性がある。顧客が経験するのは一つの結果である：タイムアウト、エラー、アプリケーションの利用不可。しかしながら、技術的な原因によって、どの制御がその損失を防げたか、またどの事業者がそれを操作できたかが決まる。

Cloudflare のイベントのステータス記録では、最初にネットワークパフォーマンスの問題が説明され、次に経路漏洩の可能性が特定され、後に責任のあるネットワークが修正したと述べられた。ステータス更新の公開コピーによると、調査通知は 11:02 UTC、特定は 11:36 UTC、修正後の監視は 12:42 UTC となっている。BGP アーカイブは最初のステータス通知より前に異常な経路を示している。その差は、Cloudflare が既知のイベントを 28 分間無視していた証拠ではない。これは有用な説明責任の問いである：自動システムはいつ異常トラフィックを検出したか、エンジニアはいつ外部ルーティングが原因であると特定したか、そして同社はいつ顧客に通知できるだけの確信を持ったか。

このイベントにおいて、悪意のある意図、トラフィック検査、または Cloudflare システムの侵害を示す公開証拠はない。経路漏洩は傍受の機会を生み出す可能性があるが、ここで観測されたサービス被害は、意図しない経路に沿った輻輳と損失であった。したがって、本稿はこのインシデントを可用性とルーティング整合性の障害として扱う。経路漏洩の潜在的なセキュリティ特性を、トラフィックが読み取られたという主張に変換するものではない。

ローカルな最適化がグローバルな経路になった経緯

インターネットは、中央制御のネットワークではなく、自律システム間の合意である。各自律システムは Border Gateway Protocol（BGP）を使用して、どの IP プレフィックスに到達可能か、どの AS パスを経由するかを隣接システムに伝える。RFC 4271のコアプロトコルは、オペレータにかなりのポリシー自由度を与えている。この柔軟性は、商用ピアリング、有償トランジット、マルチホーミング、トラフィックエンジニアリング、ローカルな優先設定を支えている。また、隣接から受信した経路には、その経路内のすべての AS がそのアナウンスがそこまで伝わることを意図していたという普遍的な証明が付随しないことも意味する。

インシデントの前、DQE は Noction の BGP 最適化製品を使用していた。そのような製品は経路のパフォーマンスを測定し、より具体的な経路を注入して、選択されたトラフィックがどのリンクを通過するかに影響を与えることができる。Cloudflare が公開した例では、通常の104.20.0.0/20のアナウンスが104.20.0.0/21と104.20.8.0/21に分割された。2 つの/21 は/20 と同じアドレス範囲をカバーするが、それぞれがより小さな宛先ブロックを名指している。

管理されたネットワーク内では、より具体的な経路は合法的なトラフィックエンジニアリングの手段となり得る。危険なのはその範囲である。この経路は DQE の内部判断に影響を与えることを意図していた。DQE はそれを AS396531 にアナウンスした。AS396531 は DQE と Verizon の両方に接続されており、学習した経路を Verizon に向けてエクスポートした。Verizon はそれを顧客から受け入れ、さらに伝播させた。ローカルな命令がグローバルな主張になってしまったのである。

Noction 自身の6 月 26 日のインシデント対応では、自社プラットフォームがより具体的な経路を生成したことを認め、3 つの重複する条件を説明した：顧客ネットワーク内での生成、下流の ASN を通じて大規模プロバイダーへの漏洩、そして 3 つの自律システムすべてでの不十分なフィルタリングである。Noction は、より具体的な経路の生成は固有の欠陥ではなく一般的な慣行であると主張し、プロバイダーのフィルタリングを強調した。この回答は、単一事業者の説明に異議を唱えつつ、オプティマイザーの役割を確認している点で関連性がある。これは独立した事後分析ではなく、DQE の展開に関する正確な設定、変更記録、テスト証拠を公開していない。

Qrator Labs の別のルーティング分析では、開始を 10:35 UTC 直後の AS396531 と Verizon 間の BGP セッション再確立と関連付けた。その説明によると、AS396531 がフィルターを失い、DQE から学習した経路をエクスポートしたという。これは、なぜその条件がその時に始まったのかについてもっともらしいトリガーを提供するが、利用可能な公開記録には AS396531、DQE、または Verizon のルーター設定やログは含まれていない。より安全な結論は限定的である：観測可能なパスは経路がそれらの AS 境界を越えたことを証明しており、事業者の説明はフィルタの欠如または不備を特定しているが、正確な内部変更シーケンスは非公開のままである。

この区別は 3 つのよくある誤りを防ぐ。第一に、DQE は BGP の意味で Cloudflare のアドレス空間の起点と記述されるべきではない。観測された AS パスは依然として Cloudflare の AS13335 で終端している。DQE のオプティマイザーは正当な起点を保持したまま、より具体的な経路を作成し伝播させた。第二に、Verizon が経路を発明したわけではないが、その受け入れとグローバルな伝播が到達範囲を大幅に拡大した。第三に、Cloudflare のネットワークは AS396531 を優先経路として選択したわけではない。遠隔ネットワークが受信した広告に基づいて転送判断を行ったのである。

より具体的な経路が距離とエニーキャストを無効にした理由

非専門家にとっては、このイベントはルーターがより短い AS パスを選択したかのように聞こえるかもしれない。決定的な優先選択はもっと前の段階で行われた。インターネットの転送では最長プレフィックス一致が使用され、最も具体的な宛先ブロックをカバーする経路が、より広いブロックをカバーする経路上で選択される。クラスレスドメイン間ルーティングの仕様であるRFC 4632は、この最長一致動作と、集約経路およびより具体的な経路との関係を説明している。

あるルーターが、Cloudflare の104.20.0.0/20が通常のプロバイダー経由で到達可能であると認識しており、さらに Verizon、AS396531、DQE 経由で104.20.0.0/21を学習したとする。最初の/21 内の宛先は両方のアナウンスに一致する。/21 はより具体的であるため、AS パスが長かろうと運用上不合理であろうと勝つ。通常のパス属性は同じプレフィックスへの経路間で決定するものであり、健全な/20 が受け入れられた/21 に勝つわけではない。

これが、Cloudflare のエニーキャストフットプリントが自動的に問題を迂回しなかった理由である。エニーキャストでは、多数の Cloudflare ロケーションが同じプレフィックスをアナウンスでき、BGP が適切なインスタンスを選択する。地理的分散を提供し、個別のサイトやリンクの障害を吸収できる。しかし、漏洩した/21 は Cloudflare の通常の/20 の広告よりも具体的だった。グローバルルーティングシステムは、どの Cloudflare エニーキャストロケーションが最も近いかを比較する前に/21 を優先する可能性があった。敗れた経路の背後にある冗長性はトラフィックを復旧しなかった。

また、この望ましくない経路は負荷を集中させた。AS396531 とその接続は、Cloudflare、Amazon、Linode、その他影響を受けた多数のネットワークのグローバルトランジットとしての設備はなかった。より具体的な広告に引き寄せられたトラフィックは、それを運ぶ容量もポリシーもない回廊に流入した。パケットは遅延または破棄された。経路漏洩は時に非効率な経路でトラフィックを運ぶことがあるが、今回の規模では経路がボトルネックと化した。

Internet Engineering Task Force のRFC 7908 経路漏洩分類では、経路漏洩をアナウンスの意図された範囲を超える伝播と定義している。2019 年 6 月のイベントは、分類が分析目的で分離している特徴を組み合わせている。それには、マルチホーム接続されたネットワークがプロバイダーから学習した経路を別のプロバイダーにエクスポートするという古典的なヘアピンターンパターンに似た要素と、グローバルな伝播を意図されていなかった内部的に有用なより具体的な経路が関与している。ラベルよりも、破られた不変条件が重要である：Verizon の顧客が、その正当な顧客コーンの外側にあるプレフィックスに対してトランジットを提供するかのように見え、Verizon がその外見を受け入れたことである。

時系列と拡大する説明責任の窓

インシデントが予防から検知、復旧へと移行するにつれて、説明責任は変化する。以下のタイムラインは公開経路データと帰属が明らかな事業者の声明に基づいており、仮定された内部アクションで空白を埋めるものではない。

最も重要な期間は最初のタイムスタンプよりも前に始まっている。取締役会が 10:34 にレビューを開始すれば、アラートと通話に焦点を当てるだろう。オプティマイザー経路が本番環境で認可された時点から始めれば、設計の安全性、経路の範囲、フェイルクローズドのデフォルト、ピアポリシー、変更レビュー、独立した伝播テストを検討できる。インシデント対応は期間を短縮したが、予防的制御が対応すべきインシデントの有無を決定したのである。

4 つのフィルタリング機会が同じ方向で失敗した

この経路はいくつかの境界を越え、それぞれに停止の機会があった。これらの機会を層として扱うことで、すべての関係者が同等の制御力を有していたと偽ることなく、責任が明確になる。

オプティマイザーと生成元ネットワークの封じ込め。DQE は、Noction 製品がより具体的な経路を生成する環境を制御していた。ローカルな判断にのみ使用される経路は、すべての下流が正しく動作することに依存しないエクスポート障壁を必要とした。選択肢には、厳密に範囲を限定したエクスポートポリシー、専用のルーティングコンテキスト、すべての出口で解釈される明示的なコミュニティ、外部コレクターからの自動チェック、予期しない伝播に連動するキルスイッチが含まれる。Noction は展開テストを実施し、NO_EXPORTの使用について議論しているが、NO_EXPORTがすべてのマルチ AS 設計で適切ではないとも主張している。この既知のコミュニティはRFC 1997で定義されており、それを付与された経路はコンフェデレーション境界の外では広告されるべきではない。今回のイベントでそれが使用されたか、保持されたか、削除されたか、または一度も付与されなかったかは、公に確立されていない。

マルチホーム接続された顧客のエクスポート制御。AS396531 は、意図的にトランジットとして運用しない限り、あるプロバイダーの完全または最適化された経路を別のプロバイダーに提供すべきではなかった。リーフネットワークやエンタープライズネットワークは、単純なアウトバウンドルールを適用できる：自身の認可されたプレフィックスと明示的に承認された顧客プレフィックスのみを広告する。デフォルト拒否は、出てはいけないすべての経路を特定しようとするよりも信頼性が高い。2017 年に公開されたRFC 8212は、明示的なインポートまたはエクスポートポリシーが設定されていない場合のデフォルトの外部 BGP 拒否を成文化した。これにより、事業者が誤った許容ポリシーを付与することを防ぐことはできないが、ポリシー不在による偶発的な伝播の一形態を取り除く。

プロバイダーの顧客受信制御。Verizon には最も強力な停止ポイントがあった。トランジットプロバイダーは、どのセッションが顧客セッションであるかを知っており、その顧客が何を発信またはトランジットする権限があるかを知っているべきである。Cloudflare の詳細調査では、その顧客に関連付けられた経路登録情報に Cloudflare の ASN や他の漏洩ネットワークが含まれていなかったことが判明した。したがって、顧客固有のプレフィックスおよび AS パスフィルタによって、これらのアナウンスを拒否できたはずである。2015 年に公開されたRFC 7454 の BGP 運用およびセキュリティガイダンスでは、すべての境界での経路受信・広告ポリシー、顧客プレフィックス制御、AS パスフィルタリング、最大プレフィックス制限を推奨している。

下流およびピアによる拒否。Verizon から経路を受信したネットワークにも、それらを拒否する機会があった。Verizon は大規模なトランジットネットワークであるため、多くの受信者はそのアナウンスにかなりの信頼を置いていた。Route Origin Validation を使用している一部のネットワークは、影響を受けた Cloudflare のより具体的な経路を RPKI 無効として拒否したであろう。他のネットワークは経路漏洩ヒューリスティックやピアポリシーを使用できた。しかし、大規模プロバイダーがエラーを配信した後に、すべてのリモートネットワークにそれを捕捉させることは、元の顧客セッションで拒否するよりも効率が悪い。ポリシー違反に最も近い場所での予防が、グローバルな収束が設定エラーを分散型障害に変える前に伝播を制限する。

これらの層は十分に独立していなかった。DQE の最適化、AS396531 のエクスポート、Verizon のインポートはすべて、正しい経路ポリシー設定に依存していた。各層が手動で許容的であるか、不完全な顧客記録から構築されている場合、3 つの制御が同時に失敗し得る。したがって、成熟した保証プログラムは、管理ドメインの外部から結果をテストする。設定レビューだけでは経路がローカルに留まっている証拠として受け入れない。

RPKI はこれらの経路をブロックできたが、完全な答えではない

Cloudflare は、RPKI 導入の説明で述べられているように、2018 年に経路の署名と検証の導入を開始していた。Route Origin Authorization（ROA）は、どの自律システムがプレフィックスを発信してよいか、そしてオプションで、それがアナウンスしてよい最も具体的なプレフィックス長を規定する。Cloudflare によれば、その関連経路は AS13335 を最大長/20 で認可していた。漏洩した/21 は AS13335 を起点として保持していたが、認可された最大長を超えていた。したがって、それらは Route Origin Validation では無効であった。

この論理はRFC 6811で形式化されている。受信経路は、検証された ROA ペイロードがプレフィックスをカバーし、起点 ASN が一致し、経路のプレフィックス長が ROA の最大値を超えない場合に有効となる。カバーする認可が存在するが、いずれもすべての必要プロパティに一致しない場合、無効となる。RIPE NCC の起点検証の説明は、有効、無効、不明の状態を有用に分離し、ネットワークオペレータがそれらの状態にどのポリシーを適用するかを依然として決定することを強調している。

Cloudflare が ROA を作成した行為は必要だが十分ではなかった。ROA は公開された証拠であり、遠隔執行命令ではない。Verizon または他の受信ネットワークが、検証済み RPKI データを取得し、顧客経路に検証を適用し、無効なものを拒否しなければならなかった。Cloudflare は自社ネットワークに入る無効な経路を拒否できたが、それはサードパーティネットワークが別の場所で選択された経路に沿って Cloudflare 宛てトラフィックを送信することを止めはしなかった。ルーティングセキュリティは相互的な構造を持つ：アドレス保持者が認可を公開し、他の事業者がそれを有効にする。

このインシデントでは、オプティマイザーがプレフィックス長を変更したため、RPKI は特に強力な予防制御となった。この成功条件をすべての経路漏洩に一般化するのは誤りだろう。AS396531 が Cloudflare の通常の/20 を漏洩し、AS13335 をパスの最後に保持した場合、起点検証はその経路を有効と見なす可能性がある。その経路は依然として期待されるプロバイダー・顧客トポロジーに違反する。RPKI 起点検証は、誰がどの長さでプレフィックスを発信できるかには答える。AS パス内のすべてのトランジット関係が認可されていることを証明するものではない。

この境界は RPKI への批判ではない。他の制御と共に展開する理由である。NIST のSP 800-189 ガイダンスは、RPKI と BGP 起点検証をプレフィックスフィルタリングやより広範なドメイン間レジリエンスプラクティスと組み合わせている。経路漏洩、ハイジャック、トラフィック迂回、サービス拒否、パフォーマンス低下を、層を必要とする関連運用リスクとして扱っている。2019 年 6 月のイベントは、異例なほど具体的な実証である：ある層は正確に不正なプレフィックスを拒否でき、一方で基本的な顧客フィルタリングは、暗号がなくても、もっともらしくない権限パスを拒否できただろう。

maxLengthにもガバナンスの教訓がある。過度に許容的な ROA は、認可されていないより具体的な経路を有効に見せることがあり、過度に制限的または古い ROA は、正当な経路の拒否を引き起こす可能性がある。ROA のカバレッジ、最大長、有効期限、鍵とリポジトリの健全性、計画されたルーティング変更は変更管理を必要とする。ROA が存在することを示すダッシュボードは、それらが本番環境の意図を正確に記述している証拠にはならない。

2019 年以降の経路ポリシー制御

標準とポリシーの状況は、障害後も発展を続けた。後の制御を、事業者が 2019 年 6 月に完成版を展開できたかのように説明するべきではないが、それらは業界が以前は暗黙的だった前提をどのようにコード化しようとしたかを示している。

2022 年に公開されたRFC 9234は、BGP Roles と Only-to-Customer（OTC）属性を導入した。隣接ネットワークは、関係がプロバイダー、顧客、ピア、ルートサーバー、またはルートサーバークライアントのいずれであるかを宣言できる。ロールの合意と OTC 処理により、ルーターは許可されない方向で関係境界を越える一部のアナウンスを検出できる。2019 年のパスを単純化した場合、プロバイダーから学習され、その後別のプロバイダーに送られた経路は、顧客のみのエクスポートと矛盾する証拠を持つはずである。BGP Roles は、一部の商業トポロジー知識を事業者の慣習からプロトコル可視状態に変換する。

Peerlock は別の経路重視のアプローチを提供する。2020 年の論文「Flexsealing BGP Against Route Leaks」は、事業者が展開したメカニズムを研究し、保護された大規模ネットワークが本来現れるべきでない場所に現れるパスを停止する能力などを調査した。Peerlock は論文以前に、また 2019 年 6 月のイベント以前に存在したが、展開は双方向の知識と設定に依存していた。これは実用的なパスフィルターが可能だった証拠であり、普遍的な既製の制御が利用可能だった証拠ではない。

Autonomous System Provider Authorization（ASPA）は、AS が検証可能なプロバイダー関係を RPKI システムを通じて公開できるようにすることを目的としている。多くの経路漏洩は起点の失敗ではなくパスの妥当性の失敗であるため、有望である。また、慎重な表現が求められる：ASPA の標準と展開状況は進化しており、部分的なカバレッジは不明なパスを生み出す。これは追加の検証シグナルとして扱われるべきであり、2019 年の参加者が当時必須だった暗号化パス標準に違反したという遡及的な証拠としてではない。

検出も成熟した。Cloudflare は後に、ルーティング関係と観測経路を使用して可能性のある漏洩にフラグを立てるRadar 経路漏洩検出サービスについて説明した。監視により、知るまでの時間と調整までの時間が短縮されるが、ルーターが経路を受け入れることを防ぐわけではない。改善経路が人間の電話連鎖である場合、2 時間のインシデントでもグローバルな損害を与え得る。検出はリハーサルされたアクションに接続する必要がある：影響を受けたプレフィックスを特定し、安全な場所で防御ポリシーを適用し、権限のある事業者に連絡し、顧客ステータスを公開し、独立したコレクター間で撤回を検証し、トラフィックの復旧を見守る。

したがって、有用な制御モデルは累積的である：

1. IRR オブジェクトと ROA を通じて正確な経路権限を公開する。
2. 信頼できるデータから顧客インポートフィルタを生成し、安全に更新する。
3. 明示的なポリシーのない経路をデフォルトで拒否する。
4. 顧客コーン、AS パス、プレフィックス長、最大プレフィックス数の期待を実施する。
5. すべての関連する外部入口で RPKI 無効アナウンスを拒否する。
6. BGP Roles、OTC、Peerlock、そして成熟次第で ASPA 検証など、関係を認識する制御を追加する。
7. 独立した外部の視点から伝播を観測する。
8. 継続的にテストされたオペレーション連絡先と経路撤回権限を維持する。

どの単一項目も他に代用できない。それらの価値は異なる故障モードから生じる。

責任判定を創作せずに説明責任を割り当てる

公開された技術記録は責任分析を裏付けるが、DQE、AS396531、Verizon、Noction、Cloudflare、影響を受けた顧客の間で法的責任を割り当てる裁判所の判決、規制命令、または完全な契約書を含まない。この記事で使用された記録には、Verizon の根本原因に関する公開報告書は見つからなかった。したがって、以下の割り当ては運用上のものである：誰がどの安全策を制御し、誰がどのリスクを低減できたか。それは損害のパーセンテージ割り当てではない。

DQE Communications.DQE は最適化経路が生成されたネットワークと、それらが AS396531 に到達する関係を制御していた。最も価値の高い義務は、経路の範囲を制限し、外部可視性をテストし、正しいエクスポートポリシーを維持し、連絡を受けたらアナウンスを停止することだった。Cloudflare は DQE 担当者が経路撤回を支援したと評価した。迅速な協力は期間を短縮したが、予防制御の失敗を消し去るものではない。

AS396531.マルチホーム接続されたこのネットワークはプロバイダー間の橋渡しだった。Verizon に向けた観測可能な広告により、DQE を通じて学習した経路の到達可能性を提供するように見えた。非トランジットの企業は、学習したフルテーブルではなく、狭い許可リストをエクスポートすべきである。公開記録はフィルタリングを削除または回避したエンジニア、ベンダー、変更を特定していないため、個人の非難は推測になる。組織的な説明責任は、セッション復旧によって企業の権限外の経路が露出することを許した設計に付随する。

Verizon.Verizon の顧客向けインポートポリシーは、最も重大な未使用の制御だった。大規模なトランジットネットワークが顧客から数千の経路を受け入れる場合、認可されたプレフィックス、期待される起点とパス、プレフィックス量を検証すべきである。経路アーカイブは Verizon がそのパスを伝播させたことを示している。Cloudflare は、関連する IRR データと RPKI 検証があれば拒否できたはずであり、イベント中に Verizon への連絡が困難だったと報告している。Verizon の内部記録がなければ、フィルタが不在だったか、古くなっていたか、誤適用されたか、回避されたか、別の方法で失敗したかは言えない。これらの可能性のいずれも、事業者の規模に比例した保証とインシデント調整の義務を示している。

Noction.封じ込めが失敗した場合、グローバルに優先されるより具体的な経路を生成できるルーティングオプティマイザーには、予見可能な高影響度の故障モードがある。製品責任には、安全なデフォルト、目立つリスク警告、展開検証、経路タグ付け、外部漏洩テスト、ロールバック、検証された境界なしに侵入モードを有効化しにくくする制御が含まれる。Noction の回答は、展開中に伝播をテストし、フィルタは必須のままだったと述べている。この主張は次の監査上の質問を提起する：製品はピアリングやセッション変更後も封じ込めを継続的に検証したのか、それとも導入時のみか？一時的なテストは動的ルーティング環境の安全性を永続的に証明できない。

Cloudflare.Cloudflare は望ましくないパスを生成も伝播もせず、Verizon の顧客セッションを設定することもできなかった。それにもかかわらず、グローバルルーティングに基づいて構築された可用性とセキュリティサービスを顧客に販売していた。したがって、その説明責任は残存する制御にある：正確な ROA、多様な相互接続、外部経路モニタリング、迅速な診断、連絡可能なピア連絡先、顧客コミュニケーション、軽減オプション、透明性のある開示。また、自社のアーキテクチャが何に耐えられるかを過大に主張しない義務もあった。エニーキャストと大規模なグローバルネットワークは多くの障害を低減するが、検証ネットワークの支援なしにはグローバルに受け入れられたより具体的な経路に打ち勝つことはできない。

他のネットワーク。Verizon から経路を受け入れたピアや下流のネットワークは、AS396531 の顧客認可を知る立場に平等にいたわけではないが、RPKI 検証とパス制御を導入できた。それらの決定は自社のユーザーに影響を与え、場合によってはさらなる伝播にも影響した。大規模なトランジットネットワークが正しく動作すればシステムはより安全になるが、受信ネットワークはそれが導入する経路に対して依然として責任を負う。

この割り当ては、BGP は信頼に基づいているため誰も説明責任を負わないという、都合は良いが役に立たない声明を避ける。信頼は設定、レジストリ、契約、運用慣行を通じて実装される。それらは制御可能である。プロトコルのオープン性は、なぜ障害が拡散し得るかを説明するが、プロバイダーが顧客経路をフィルタリングしないことの言い訳にはならない。

Cloudflare のビジネス上の説明責任は外部原因があっても存続した

外部トリガーはクラウドプロバイダーの顧客に対する義務を取り除かない。Cloudflare の 2019 年の修正Form S-1 登録申請書類は、6 月の経路漏洩が自社および他のプロバイダーのトラフィックに重大な混乱を引き起こしたと述べた。経路漏洩が評判と信頼に損害を与え得ると警告し、クレジットや返金につながる可能性のあるサービスレベルコミットメントについて説明し、6 月の経路漏洩と別件の 7 月の停止がそれらの義務の一部を引き起こしたと述べた。当時、Cloudflare はこれらのインシデントが経営成績や財政状態に重要な影響を与えるとは予想していなかった。

この開示は、サービスレベルコミットメントを踏まえて 6 月の経路漏洩の合理的に予想される財務上の影響に対処するよう企業に求めたSEC スタッフコメントに続くものだった。このやり取りは、説明責任がネットワークオペレーションセンターから企業報告へと移行するコンパクトな例である。インシデントは、外部原因で発生し、運用上は重要で、契約上は補償可能であり、同時にプロバイダーにとって財務上は重要でないということがあり得る。

この申請書類は、影響を受けた顧客数、クレジット総額、返金、失われたトランザクション、顧客レベルのダウンタイムを開示していない。また、6 月の経路漏洩を、Cloudflare 内部で引き起こされた 7 月 2 日のウェブアプリケーションファイアウォール停止と並べて論じている。これらのイベントは統合されるべきではない。6 月のインシデントは外部ルーティングへの依存性をテストする。7 月のインシデントは内部のソフトウェア変更管理をテストする。どちらも可用性に影響を与えたが、予防責任者と証拠は異なる。

顧客にとって、サービスクレジットはビジネスの回復と等価ではない。小規模なオンライン販売業者は注文を失い、通信サービスはセッションを失い、企業は月額サブスクリプションのクレジットが計算される前にスタッフ時間を消費する可能性がある。契約上の救済は、ダウンタイムの社会的または顧客コスト全体ではなく、直接的なプロバイダー料金の一部を割り当てるだけである。したがってクラウドプロバイダーは、契約上の稼働時間以上のものを報告すべきである：地域・ネットワーク別の到達可能性、トラフィックロス、検出時間、特定時間、連絡時間、安定復旧までの時間。

取締役会がピアリングとトランジットリスクについて問うべきこと

ルーティングはしばしば、取締役会の監視レベルを下回る専門家の関心事として扱われる。2019 年 6 月のイベントは、なぜその分割が安易すぎるかを示す。ある大手プロバイダーの BGP インポートポリシーが、多くのクラウドサービスへのアクセスを変更し、顧客義務を引き起こし、投資家開示を生み出し、正式なクラウドベンダー契約外の集中を露呈させた。取締役会はルーターの構文を選択する必要はないが、可用性が他の自律システムの動作に依存している場所を経営陣が理解しているという証拠は必要である。

すべての指標において分母が重要である。RPKI がコアルーターに展開されていると言っても、未検証のエッジセッションが同じネットワークに経路を注入できるかどうかはわからない。顧客フィルタが自動化されていると言っても、ソースレジストリが完全か、緊急例外が残存しているか、新しい BGP セッションがポリシーを継承したかどうかは示されない。連絡先がデータベースにあると言っても、現地時間の 06:30 に権限を持って誰かが応答する証明にはならない。

テストには制御されたネガティブケースを含めるべきである。プロバイダーは、許可されていないラボプレフィックス、ROA が許可するよりも長いプレフィックス、過剰な経路数、宣言された顧客関係に違反するパスをアナウンスすることを試みることができる。期待される結果は、受信ポリシーと独立したコレクターで観測されるべきである。テスト自体が漏洩にならないよう保護策が必要だが、すべての現実的なテストを避けると、最もリスクの高い動作が未証明のままになる。

単純なマルチプロバイダーアドバイスなしの顧客レジリエンス

顧客はしばしば、2 つ目の CDN、2 つ目の DNS プロバイダー、2 つ目のクラウドを購入することで依存を避けるべきだと聞く。多様性は役立つ可能性があるが、ルーティング障害は製品ラベルを尊重しない。2 つのプロバイダーがトランジット、交換ポイント、ファイバー、経路コレクター、または同じ検証を行わないアクセスネットワークを共有している可能性がある。漏洩したより具体的な経路は、顧客の DNS やアプリケーションのフェイルオーバーロジックが機能する前にトラフィックを引き寄せる可能性もある。

正しい設計はサービスのパスから始まる。どのプロバイダーが DNS に対して権威があるか？TLS キーとセキュリティポリシーはどこに保持されているか？オリジンは直接トラフィックを安全に受け入れられるか？セキュリティバイパスを作成せずにトラフィックを移動できるか？DNS キャッシュはどれくらい速く変化するか？クライアントは接続を保持するか？セカンダリプロバイダーは最新の設定と容量を持っているか？組織はトラフィックを移動する前に、上流ルーティング障害とオリジン障害を区別できるか？

一部のサービスでは、独立してルーティングされたプロバイダー間でのアクティブ・アクティブ配信が正当化される。他のサービスでは、複雑さ、一貫性のないセキュリティポリシー、キャッシュ動作、追加の攻撃対象領域が、2 時間の可用性向上を上回る。防御可能な決定は、重要度、テストされた復旧時間、共有依存関係、コスト、残存リスクを記録する。ベンダー名を数えて、その結果をレジリエントと呼ぶのではない。

顧客は調達のレバレッジも使用できる。クラウドやネットワークプロバイダーに、ROA のカバレッジ、ROV ポリシー、顧客フィルタ制御、MANRS 参加、インシデント連絡慣行、外部監視、匿名化されたテスト結果を尋ねることができる。MANRS ネットワークオペレーターアクションは、フィルタリング、アンチスプーフィング、連携調整、他者が検証できる情報の公開といった実用的な枠組みを提供する。メンバーシップや適合は、完璧な運用の証明ではなくシグナルであるが、このアクションはルーティングセキュリティを買い手が理解できる質問に変換する。

最も重要な契約上の質問は、しばしば稼働率のパーセンテージではない。それは、外部ルーティングのためにトラフィックが健全なサービスに到達できない場合に、プロバイダーがどのような証拠と支援を提供するかである。迅速で具体的なステータス連絡は、顧客が健全なオリジンに対する破壊的な変更を避けるのに役立つ。インシデント後の経路データは、彼ら自身の観測を突き合わせるのに役立つ。狭く書かれた不可抗力条項や第三者条項は補償を制限するかもしれないが、診断し連絡するというプロバイダーの運用上の義務を終わらせるべきではない。

自発的規範からリスク管理の証拠へ

2019 年 6 月のイベントは、ほぼ自発的なルーティングセキュリティ環境で発生した。ベストプラクティスは知られていなかったわけではない。プレフィックスと AS パスのフィルタリング、IRR データ、最大プレフィックス制御、RPKI、事業者連絡先レジストリは存在していた。導入と保証は不均一であり、特に 1 つのネットワークが導入コストを負担する一方で、利益がインターネット全体に広がる場合に顕著だった。

この集団行動の問題は、後に政府のより明確な注目を集めた。2024 年の米国国家サイバー局長官によるインターネットルーティングセキュリティ強化のためのロードマップは、一般的な運用における BGP が、起点の権限、メッセージの完全性、リモートパス情報、または隣接するビジネスポリシーに違反するアナウンスを検証できないことを説明している。特に大手プロバイダーと政府契約サービスにおいて、経路起点セキュリティのより強力な導入を求めている。このロードマップは政策指針であり、2019 年の参加者に関する認定ではない。

2024 年の連邦通信委員会のセキュアインターネットルーティング通知は、ブロードバンドプロバイダー向けの BGP リスク管理計画と報告を提案し、RPKI 起点検証を超える対策についてコメントを求めた。パスセキュリティにはさらなる作業が必要であることを明示的に認識した。繰り返すが、これは 2019 年 6 月について遡及的な責任を生み出すものではない。これは、プロバイダーが原則として RPKI をサポートしているかどうかを尋ねることから、維持された計画、カバレッジデータ、証明、進捗を求めることへのガバナンスシフトを示している。

規制にはそれ自体のリスクがある。ROA 登録のパーセント目標は、広範で緩い認可を報奨する可能性がある。提出要件はルーターポリシーから切り離された書類作業になり得る。詳細な防御設定の公開開示はセキュリティ上の懸念を生む可能性がある。したがって、効果的な監視は成果と管理された証拠に焦点を当てるべきである：正確な認可、拒否カバレッジ、テスト済みの顧客ポリシー、例外ガバナンス、検出速度、連絡体制の即応性、インシデント学習。機密性の高い詳細には秘密の監督アクセスが適切かもしれないが、集約的な導入状況とインシデントメトリクスは公開のままとする。

経路セキュリティのコモンズは国境も越える。Verizon の伝播はグローバルにユーザーとサービスに影響を与え、複数地域の Cloudflare エンジニアが対応に参加し、経路権限は地域レジストリを通じて分配され、受信者は独自のポリシーを適用する。国内ルールはその管轄下の事業者の行動を改善できるが、相互運用可能な標準と事業者規範こそが、その改善を広めるものである。

公開記録からまだ欠けている証拠

Cloudflare の詳細調査は異例なほど再現可能である：RIPE NCC データを特定し、コマンドを提供し、観測されたパスとタイムスタンプを示している。この透明性により、経路の時系列に対する高い信頼性が裏付けられる。しかし、すべての説明責任の問いに答えるわけではない。

以下の記録が、関係事業者によって公開されれば、分析を大幅に改善するだろう：

• DQE のオプティマイザー設定、生成プレフィックスポリシー、エクスポートマップ、コミュニティ処理、展開前後の外部伝播テスト。
• AS396531 の DQE および Verizon セッションに付随する BGP ポリシー、セッションダウンとセッションアップのタイムライン、設定変更、経路数、プロバイダー学習経路がエクスポート可能だった理由。
• Verizon の顧客オンボーディング記録、IRR またはプレフィックスリストのソース、AS パスポリシー、最大プレフィックス設定、RPKI 検証状態、アラート、オペレーター応答タイムライン、グローバル伝播の説明。
• Noction の展開チェックリスト、継続的封じ込めの保護策、アラート動作、インシデント後に行われた製品変更。
• Cloudflare の最初の内部検出タイムスタンプ、アラートソース、検討された軽減策、ピア連絡エスカレーションタイムライン、ネットワークおよび地域別の顧客影響、修正アクションの検証。
• 特に 6 月の経路漏洩に帰属する、数量化されたサービスクレジット、返金、サポート負荷、顧客離れ。別件の 7 月の停止ではないもの。

これらの不在がイベントを不可知にするわけではない。公開 BGP アナウンスはネットワークが互いに何を伝えたかの証拠である。トラフィック測定はサービス影響の証拠である。SEC 提出書類は企業開示と期待される重要度の証拠である。事業者ブログは帰属が明らかな説明の証拠である。原則は、これらの証拠クラスを分離しておくことである。

また、公開記録の不在と内部記録の不在を混同しないことも重要である。Verizon、DQE、AS396531、Noction は、公開されなかった広範なレビューを実施した可能性がある。Cloudflare は投稿に含まれていない詳細なテレメトリを保持している可能性がある。証拠が非公開のままである場合、公的説明責任は弱まるが、記事は学習がなかったと推論することはできない。

経路レジリエンスのための持続可能な説明責任基準

2019 年 6 月の停止が記憶されているのは、小規模なネットワークがインターネットの大部分への見かけ上の経路になったからである。より深い教訓は、規模がそれに見合った懐疑心を生まなかったことである。大手トランジットプロバイダーが顧客から異常な主張を受け入れ配信し、多くのネットワークがその結果を受け入れ、トラフィックがプロトコルルールに従ってもっともらしくないパスに流れ込み、復旧はアナウンスを撤回できる人々を見つけることに依存した。

このイベントは当時利用可能な制御で予防可能だった。DQE は最適化経路を封じ込めることができた。AS396531 は認可されたプレフィックスのみをエクスポートできた。Verizon はレジストリ、パス、プレフィックス数、RPKI の証拠で顧客アナウンスをフィルタリングできた。受信ネットワークは RPKI 無効の Cloudflare のより具体的な経路を拒否できた。より良い監視と連絡体制があれば、イベントを短縮できただろう。後の標準は一部の関係前提を合図しやすくするが、運用規律を任意の過去の懸念事に変えるわけではない。

Cloudflare の役割は被害者や所有者よりも複雑である。それは外部の決定によって到達可能性が損なわれた宛先であった。すでに漏洩したより具体的な経路を拒否するのに適した ROA を公開し、分散ネットワークを運用し、イベントを検出し、撤回を調整し、経路記録を説明し、契約上の結果を開示していた。それでもなお、顧客に対して明確なステータス、復旧努力、契約に基づく金銭的救済、残存ルーティングリスクの真実の説明を負っていた。プロバイダーは、インターネットの残りの部分が自社の経路を検証することを約束できないが、検証を可能にし、何が起こるかを監視し、証拠をもって対応することを約束できる。

したがって、最終的な説明責任基準はゼロ経路漏洩ではない。どのグローバルネットワークも、すべての自律システムがすべてのセッションを正しく設定することを保証できない。基準は、各当事者が自らの制御内でリスクを低減し、その低減を外部からテストし、不可避なミスの爆発半径を制限し、訓練された連携経路を通じて対応し、顧客と監督者が改善を検証するのに十分な証拠を生み出したかどうかである。

これがエッジを越えたネットワークレジリエンスの姿である：インターネットが不可能にする他のネットワークからの独立ではなく、一つの経路がどれだけの未検証の信頼を消費できるかについての規律ある制限である。