2010年 RIPE-Duke BGP 実験：標準準拠と経路説明責任

概要

有効な任意推移 BGP 属性が、影響を受けた IOS XR システムでの伝播中に破損し、下流のセッションリセットと広範な経路不安定化を引き起こした。
説明責任は、実験の範囲と監視、製品の挙動と修正、運用者の継続性管理、プロトコルのエラー処理という別々の管理点に従う。

2010年8月27日、Routing Information Service（RIS）を運用する RIPE NCC のスタッフは、デューク大学の研究グループと共に、稼働中の Border Gateway Protocol（BGP）実験を行った。研究者らは、認証情報を任意推移経路属性に載せて運ぶセキュア経路設計を研究していた。UTC 08:41、RIPE NCC は AMS-IX と GN-IX の接続を通じて、RIS AS12654 から93.175.144.0/24を生成した。この経路は予定どおり UTC 09:08に撤回された。[1]

このアナウンスが異例だったのは、この属性が公開インターネット上で新しいものだったからである。しかし、異例であることは、不正な形式であることを意味しない。RIPE NCC と Cisco は、最初の属性を有効または標準準拠と説明した。[1][2] この区別が、この事象の分析方法を決める。この実験は、単にルーターが無効な入力を拒否することを示したのではない。標準に準拠した入力が形式的な検査を通過し、配備済みソフトウェアの欠陥に遭遇し、伝播中に破損し、その後に他方で深刻なエラー処理を引き起こしたことを示したのである。

Cisco は、影響を受けた IOS XR システムが、有効だが未認識の推移属性を先へ送信する際に誤って処理したと報告した。隣接ルーターは、その結果生じた破損した UPDATE を受信し、BGP ピアリングセッションをリセットする可能性があった。BGP セッションは多数の経路を運ぶため、1つの欠陥のある UPDATE への応答が、無関係な有効な到達可能性情報を一時的に削除することがあった。出力側の破損を引き起こしたルーターが自らのエラーを検知しなければ、セッション復旧後に再び問題のある情報を広告し、不安定化を繰り返す可能性があった。[2][3]

RIPE NCC の測定は、影響が限定的ながらも重大であるという見方を裏付けている。この事象では、更新レートが周辺の基準値の最大20倍に達した。RIPE は、通常より長く完全に到達不能になったプレフィックスがさらに0.5％増加したと推定した。不安定なプレフィックスの割合はピーク時で1.4％、約4,500件に達し、この事象の前後に観測された通常レベルの約9倍だった。結果はコレクタと場所によって異なり、ウィーンのコレクタでは特に激しい更新活動が観測された。[1]

これらの数値は重要だが、既知の割合のユーザー、ルーター、ネットワーク、トラフィックが消滅したと主張する根拠にはならない。制御プレーンの観測は経路の挙動を数えるもので、人を数えるものではない。RIPE の DNSMON 分析ではルートサーバーの障害は見つからなかった。監視対象ドメインの一部で限定的なクエリ損失が確認され、.si と.fr の権威サーバー基盤の一部でより目立つ問題が見られた一方、冗長サーバーは応答を続けた。[1] 当時の運用者のコメントにはアクセス障害や交換トラフィックの変化への言及があったが、そうした報告は完全な定量的記録にはならない。[4][6]

したがって、説明責任の教訓は、単一の主体が「インターネットを壊した」という話よりも狭く、より有用である。RIPE NCC は、自らの測定基盤がインターネット上で見える実験経路を生成するかどうか、その時期、通知、監視、撤回を管理した。デューク大学の研究者は研究設計と研究側の実装を管理した。Cisco は IOS XR の未認識の有効な属性の処理、製品テスト、情報開示、保守修正を管理した。ネットワーク運用者は、自社ネットワーク内の導入済みソフトウェア、経路ポリシー、ピア保護、監視、復旧を管理した。当時のプロトコル規則は、1つの不正な UPDATE がセッションレベルの障害を引き起こすことで増幅メカニズムを提供した。

修復もまた別々の層に属していた。Cisco は事象当日にアドバイザリを発行し、メンテナンスアップグレードを準備した。[2] RIPE NCC は証拠を保存し、ベンダーに情報を提供し、分析を公開し、将来の共同実験に対してより厳格な管理を約束した。[1] その執行理事会は後に、適切なコミュニケーションを重視しつつ研究の継続を支持した。[5] 製品の修正は実装リスクを低減し、実験統制の強化は、不必要に広い公開障害領域を通じて未知の相互作用を発見するリスクを低減した。

後の標準は、業界がこの種の障害から何を学んだかを説明するのに役立つが、2010年8月に何が配備され、何が要求されていたかの証明には使えない。RFC 7606は後に、セッション全体のリセットが多数の有効な経路を破棄しうるため、不正な BGP UPDATE のより狭い処理を推奨した。[13] 明示的な対外ポリシー、経路リーク防止、起点検証、RPKI、BGPsec に関する運用上の推奨事項は隣接する管理策を明らかにするが、いずれも遡及的に過失を立証するものではなく、また、この事象で露呈した正確な出力側破損欠陥を単独で是正するものでもない。[14][15][16][17][18][19][20]

中心的な結論は抑制されたものである。有効な実験的アナウンスが、実装欠陥が情報を破損し、セッションレベルのエラー処理がその破損を増幅し、十分に制限されていない稼働実験の管理が公開インターネット上でその相互作用を露出させるという連鎖を引き起こした。説明責任は、最初に見える引き金の単純さではなく、管理の配分に従う。

1. この事象が狭い分析に値する理由

BGP インシデントは、リーク、ハイジャック、停止、設定ミスといったラベルに圧縮されがちである。これらのラベルは、証拠が当てはまる場合には有用だが、実際に重要なメカニズムを消し去ることもある。この事象には、より正確な境界が必要である。

対象は、2010年8月27日の RIPE NCC–デューク大学の実験のみである。その後の経路リークやハイジャック、あるいはその後のすべての BGP 障害の記録ではない。RFC 7908の後の経路リーク分類はカテゴリーを区別するのに有用だが、指定されたリーク条件が発生した証拠なしに、この実験を通常の経路リークと再分類することを正当化しない。[16]

この実験は、新しい任意推移属性を運ぶ意図的に構築された経路を生成した。その公開可視性は意図的だった。結果として生じた不安定化は意図的ではなかった。この組み合わせは、1つにまとめるべきではない3つの問いを生む：

最初の BGP UPDATE は有効だったのか？
どの構成要素が有効な情報を破損した情報に変えたのか？
どの管理策が、結果として生じた障害を狭く制限されたテストの範囲を超えて拡散させたのか？

入手可能な記録は最初の2つの問いに比較的高い確度で答える。RIPE NCC と Cisco はともに最初の属性を有効または標準準拠と特徴付けた一方、Cisco は伝播中の破損を伴う IOS XR の脆弱性を特定した。[1][2] NVD はこの製品問題を CVE-2010-3035 として記録している。[3]

3つ目の問いは分散している。研究者は配備済みの各ルーターを管理していなかった。Cisco は RIS が実験経路を生成すると決めたわけではない。個々の運用者は実験や影響を受けた実装を設計したわけではない。インターネット交換接続は、単に存在するだけでは、そこを通過するすべての属性の承認を証明しない。したがって、帰属は実際の管理点に従わなければならない。

この事象が重要なのは、危険な仮定を打ち破るからである。起点での標準準拠が、異種混在の経路制御システム全体で運用上の安全性を確立するのに十分である、という仮定である。準拠は必要だが、パケットや UPDATE が稼働中のコードに触れたときに生き残るかどうかは、配備された挙動が決める。この実験は、ある種の妥当性境界を通過したが、別の境界では失敗した。

RIS 自体は、複数の観測点から経路情報を収集し公開するために存在する。[7][8] RIPEstat と RIPE データベースの記録は AS12654 の識別上の文脈を提供するが、自律システムの記録は、伝播経路上で遭遇するすべてのソフトウェア挙動を明らかにすることはできない。[9][10] RIS や Route Views のような経路コレクタシステムが価値を持つのは、単一のレジストリ記録、ピアの声明、ローカルログではドメイン間経路制御システム全体を記述できないからにほかならない。[11]

教訓は、標準が無関係だということではない。標準は要求される挙動を記述するが、説明責任には、実装、配備、運用上の管理が実条件下でその挙動を生み出すという証拠が必要である、ということである。

2. 経緯：予定されたアナウンスから意図しない混乱へ

UTC 08:41以前：設計とアナウンス前の確認

デューク大学の研究グループは、認証情報が任意推移 BGP 経路属性に載って運ばれるセキュア経路設計を研究していた。デューク大学は研究の一環として修正版 Quagga 実装を提供した。アナウンス前の確認では、その属性が許容可能なプロトコル形式を持つことが確立され、2つ目の Quagga インスタンスでは、後に影響を受けた配備機器で見られた挙動は再現されなかった。[1]

その結果は有益だが不完全だった。それは、最初の実装と類似の受信環境がその属性を処理できることを示した。しかし、公開インターネット上のすべてのルーターファミリ、ソフトウェアリリース、転送経路がその属性を正しく保存することを示したわけではない。

これが重大な検出ギャップだった。テスト経路は形式的構造と限られた実装挙動を評価した。推移属性が通過しうる異種混在のインストールベースを再現しなかった。最も重要なことに、有効な未知の属性を受け入れながら、それを先へ送信する際に破損させる欠陥を露呈しなかった。

公開記録は、完全な承認記録、検討されたすべてのリスク、事象前に議論されたすべての管理策を確立していない。したがって、文書化されていない意思決定プロセスを捏造するのは不適切である。言えるのは、アナウンス前に使用された管理策が、公開混乱を生み出した相互作用を検出しなかったということである。

UTC 08:41：経路が可視化される

2010年8月27日 UTC 08:41、RIS AS12654 は実験的な任意推移属性を付けて93.175.144.0/24をアナウンスし始めた。このアナウンスは、RIPE NCC の AMS-IX および GN-IX での接続を通じて伝播した。[1]

この瞬間が引き金となった。しかし、「引き金」は「根本原因」と同義ではない。引き金とは、潜在状態を活性化する事象である。有効な入力が欠陥のある実装に遭遇した場合、有効な入力が観測されたシーケンスを開始するが、そのシーケンスが規定された挙動から逸脱する理由を説明するのは欠陥である。

経路の公開可視性は、実験統制上の露出も生み出した。閉じた、または厳密に制限されたシステムでのテストは、広範な自律ネットワークを横断させることなく欠陥を明らかにできる。経路が通常のドメイン間伝播に入った時点で、結果は開始当事者の直接の管理外にあるソフトウェアとポリシーに依存することになった。

伝播中：有効な情報が破損する

影響を受けた IOS XR システムは、認識できない属性を受信した。BGP の任意推移設計の下では、未認識であること自体はその属性を拒否する根拠にならない。関連する挙動は、それを保存して伝播することである。

Cisco の説明は、その伝播経路における障害を特定した。影響を受けたシステムは、それ以外は有効な属性を隣接機器へ送信する際に破損させた。[2] 入手可能な証拠は、影響を受けたすべての経路について正確なバイトレベルの変異を捏造することを正当化しない。信頼できる発見は機能的である。有効な未知の情報が影響を受けた実装に入り、伝播時に破損した情報が出てきた。

この区別は、ルーターが実験機能を単に「サポートしていなかった」と言うよりも正確に製品欠陥を位置付ける。任意推移性は、ルーターが属性の完全な意味を理解せずにその属性を運べるようにするために存在する。準拠した実装は、認証情報に基づいて動作する必要はない。伝播する場合は、その属性を正しく保存する必要がある。

破損はその後、実装境界を越えた。下流の隣接機器は、実験が生成した有効なものとはもはや同等ではない UPDATE を受信した。

下流での受信：1つの UPDATE がセッション全体を脅かす

当時の標準ベースラインに関連するエラー処理規則の下では、不正な形式の経路属性は UPDATE メッセージエラーと BGP セッションの切断を引き起こし得た。[12] この応答は設計上厳しいものだった。経路情報を安全に解釈できないルーターは、セッションを終了することで自らを保護した。

運用上の副作用は広範だった。BGP セッションは通常、実験用プレフィックスだけでなく多数の経路を運ぶ。したがって、セッションの切断は、そのピアから学習した無関係な有効な経路を撤回し得た。その後、ネットワークは代替経路を探し、新しい UPDATE を交換し、再収束する。

さらなる反復メカニズムもあり得た。出力側属性を破損させたルーターは、必ずしも自らを破損の発生源と特定しなかった。隣接セッションが回復した後、同じ経路が再び広告され得た。同じ破損が再発し、下流システムが再びリセットし、経路不安定化が再燃し得た。[2]

したがって、障害連鎖は実験用プレフィックスよりも大きかった：

有効だが未知の属性が影響を受けたルーターに入った。
ルーターはそれを転送中に破損させた。
隣接機器は不正な UPDATE を受信した。
隣接機器は BGP セッションを終了し得た。
実験とは無関係の経路がその隣接関係から消え得た。
再収束により大量の更新が発生した。
再広告がシーケンスを繰り返し得た。

これが、この事象が単なる相互運用性の興味ではなく、説明責任の試金石となった理由である。各段階は異なる構成要素または組織によって管理されていた。

UTC 09:08：予定された撤回

RIPE NCC は、予定どおり UTC 09:08に実験的アナウンスを撤回した。[1] したがって、経路は約27分間生成されていたことになる。

撤回は必要だったが、撤回は即時の消しゴムではない。BGP は分散している。すでに受け入れられ、または伝播された更新は他のセッションを通過しなければならず、ルーターは経路を再計算し、隣接関係を回復する。計画的な撤回は、開始点での継続的な生成を止めることができても、すでに進行中のすべてのコピー、キューにある更新、リセット、再収束プロセスを即座に取り消すことはできない。

RIPE は、意図しない運用上の影響が約30分続いたと述べた。ほとんどの不安定化は、実験の約20分後に通常へ戻り、撤回の正確な瞬間に終わったわけではない。[1] これらの記述は、測定された運用間隔として扱うべきであり、影響を受けたすべての経路が同時に回復したという主張に変換すべきではない。

撤回後：運用者の対応と証拠収集

運用者は自社ネットワークから観測し対応した。当時のメーリングリストの議論には、アクセス問題、経路変更、交換トラフィックへの影響の報告が含まれた。[4][6] このようなコメントは、混乱が運用上可視化されたことの有用な証拠であるが、厳格な限界がある。影響を受けたすべての自律システムを列挙するものでも、場所をまたいで観測を正規化するものでも、失われたトラフィックの完全な数を提供するものでもない。

RIPE NCC は実験データを保持し、収集した証拠を Cisco に提供した。この保存が重要だったのは、事象が組織の境界を越えたからである。起点側のログだけでは RIS が何を送信したかは示せても、中間実装が何を出力したかは必ずしも示せない。ベンダーの報告だけでは欠陥を説明できても、インターネット全体の観測を定量化できない。信頼できる再構築には、複数の管理領域からの証拠が必要だった。

UTC 22:00：Cisco のアドバイザリ

Cisco は2010年8月27日 UTC 22:00に IOS XR アドバイザリを公開した。[2] この問題は CVE-2010-3035 として記録され、Cisco はソフトウェアメンテナンスアップグレードを準備した。[3]

当日のアドバイザリは、公開された製品レベルの対応を確立した。それ自体では、影響を受けた各運用者にどのリリースがインストールされていたか、何台のデバイスがその経路に遭遇したか、すべての運用者が直ちに使用可能な緩和策を持っていたかを証明するものではない。これらは限られた記録の中では依然として不明である。

8月31日以降：公開分析と統制上の対応

RIPE NCC は2010年8月31日にインシデントと測定分析を公開した。[1] その記述は、実験、実装の相互作用、観測された経路への影響、DNSMON の所見、将来の共同実験への変更見込みを説明した。

RIPE NCC は、将来の実験は包括的な影響評価、運用者への十分な事前通知、脆弱性の責任ある取り扱いを含む、より厳格な扱いを受けると述べた。[1] 執行理事会は後に、適切なコミュニケーションを重視しつつ実験の継続を支持した。[5]

この対応は研究の価値を否定したわけではない。有用な研究目的があっても、運用上の露出を制限する必要性がなくなるわけではないことを認識した。したがって、統制上の是正は「実験をやめる」ことではなかった。公開実験を開始する権限を、より明確なリスク、通知、封じ込め、対応の管理に条件付けることだった。

3. 任意推移属性とは何か——そして「未知」が「無効」を意味しなかった理由

BGP 経路属性は、経路に関連する情報を運ぶ。一部は広く知られており、BGP 実装が理解することが期待される。他は任意である。別の区別は推移性に関するもので、中間実装がその意味を認識しない場合でも、属性が BGP スピーカー間を継続すべきかどうかである。

RFC 4271は関連する挙動を定義している。認識されない任意非推移属性は転送する必要がない。認識されない任意推移属性は異なる。それは受け入れられ、他の BGP ピアへ渡され、Partial ビットが中間システムが属性を完全に認識しなかったことを示すために使用される。[12]

このメカニズムは拡張を支える。これがなければ、新しい推移機能がインターネットを横断できる前に、経路上のすべての自律システムが同時にソフトウェアサポートを必要とすることになる。任意推移性は漸進的な配備を可能にする。ルーターは情報を解釈せずに運ぶことができる。

この設計は厳格な実装責任を生む。任意推移属性を理解しないルーターも、その表現を安全に処理しなければならない。実際には、有効な不透明情報を不正な情報に変えてはならない。

4つの概念は分離しておかなければならない。

認識。ルーターは属性の意味を理解するか？

受容。属性は、ルーターがプロトコル規則の下で安全に受信できる形式を持つか？

伝播。ルーターは属性を先へ渡さなければならないか、または渡してもよいか？

変異。ルーターは属性を変更するか、変更する場合、その変更は許可され、正しく符号化されているか？

2010年の事象は、影響を受けた IOS XR システムに研究用認証方式の理解を要求したわけではない。欠陥は伝播に関するものだった。Cisco の説明は、影響を受けたシステムが有効な未認識の推移属性を先へ送信する際に破損させたというものだった。[2]

これが、2つ目の Quagga インスタンスだけではインシデントを予測するのに十分でなかった理由を説明する。2つの実装は属性の形式について合意できる一方で、3つ目は異なるコード経路に欠陥を含み得る。未知の属性の受信、保存、直列化は別々の操作を含み得る。入口での適合性チェックの通過は、出口での正しい挙動を証明しない。

この事象は、構文上の妥当性とエンドツーエンドの運用上の安全性の違いも示している。最初の UPDATE は起点で有効であり得る。中間システムはその後、無効な表現を生成し得る。下流システムは、利用可能な規則に従って正しく応答しながら、セッション全体を閉じることで有害な運用上の結果を生み出し得る。

単一の層だけでは影響を説明できない：

実験が未知の入力を提供した。
影響を受けた製品が破損を提供した。
下流のエラー応答がセッション喪失を提供した。
BGP 再収束が更新の増幅を提供した。
公開伝播が障害領域を提供した。

元の属性が不正だったと呼ぶことは、パケット証拠が反対を示さない限り、製品欠陥を消し去る。事象全体を製品バグだけと呼ぶことは、不確実な相互作用を稼働中のインターネットで露出させる決定を消し去る。厳しいプロトコル応答だけと呼ぶことは、不正な下流 UPDATE を生成した実装を消し去る。

正確な記述は、別個の管理所有者を持つ連鎖障害である。

4. 1つの破損 UPDATE から広範な経路不安定化へ

BGP は自律システム間で到達可能性を配布する。ピアリングセッションが閉じると、そのセッションを通じて排他的または優先的に学習した経路は、ローカル経路表から撤回され得る。ルーターは代替経路を選択し、それらの変更を他のピアへアナウンスする。それらのピアはその後、自身の選択プロセスを繰り返す。

つまり、1つの経路に付随するエラーは、応答が隣接関係全体を削除する場合、多数の経路に関わる変更を生み出し得る。実験用プレフィックスが、影響を受けたユーザーが求める宛先である必要はなかった。リセットは、同じセッションで学習した他の到達可能性を乱し得た。

この事象の更新量はこの増幅メカニズムと整合的である。RIPE は、周辺の基準値の最大20倍の更新レートを観測した。[1] これは制御プレーンの測定である。ルーターが大幅に多くの経路変更を交換していた。どれだけのアプリケーショントラフィックが失われたかを直接述べるものではないが、混乱が1つのプレフィックスの静かな拒否を超えて広がったことを示している。

セッション回復も再発を生み出し得た。上流の影響を受けたルーターが経路を保持し、セッション復帰時に欠陥のある伝播を繰り返した場合、隣接機器は再び不正な UPDATE に遭遇し得た。結果として生じるサイクルは以下を組み合わせる：

セッション確立；
経路広告；
伝播中の破損；
不正な UPDATE 受信；
セッション切断；
経路撤回と再収束；および
再確立。

すべてのピアや経路が必ずしも全段階を経験したわけではない。証拠は、繰り返し得るメカニズムと不安定化の増大の観測を支持するが、すべての自律システムについて完全なパケット単位の記録を提供するものではない。

この区別は影響を割り当てる際に重要である。経路コレクタは、その観測点で広告と撤回を見る。すべての転送決定、すべてのユーザーセッション、すべての破棄されたパケットを見るわけではない。異なるコレクタは経路制御システムの異なる断面を見る。ウィーンコレクタでの特に激しい活動は、影響が不均一だったことを示している。[1]

不均一性は測定の欠陥ではない。インターネットのトポロジーとポリシーの特性である。自律システムはローカルに経路を選択する。異なるピア、ソフトウェア、フィルタ、代替経路を持つ。欠陥のある広告は、ある経路を通過し、別の経路ではブロックされ、第3の経路では選択されないことがある。

したがって、正しい分析上の動きは、1つのコレクタのピークをインターネット全体へ外挿することではない。コレクタを組み合わせ、分布を記述し、推論の限界を保持することである。

5. 限定的な影響：証拠が裏付けるもの

RIPE の測定は3つの主要な指標を提供する。

第1に、経路更新レートは周辺の基準値の最大20倍に達した。[1] これは事象ウィンドウ中の例外的な制御プレーン活動を示している。「最大」という表現は重要である。すべてのコレクタで、または全期間にわたり、均一なレートではなく、ピークを表す。

第2に、RIPE は、通常より長く完全に到達不能になったプレフィックスがさらに0.5％増加したと推定した。[1] これはプレフィックスレベルの可視性指標である。ユーザー、トラフィック、ルーター、経済活動の0.5％に変換すべきではない。プレフィックスは規模、用途、トラフィックが大きく異なり、経路コレクタはすべての転送経路を観測するわけではない。

第3に、不安定なプレフィックスの割合はピーク時で1.4％だった。RIPE はこのピークを約4,500件、通常レベルの約9倍と関連付けた。[1] 「不安定」は「普遍的に到達不能」と同一ではない。プレフィックスは、一部の場所から到達可能なままでありながら、繰り返し経路変更を経験し得る。

これらの所見は、この事象が重大で、測定可能で、分散した経路不安定化を引き起こしたという結論を裏付ける。インターネットの1.4％が完全にオフラインになったという主張は裏付けない。

この事象がインターネットの約1％に影響したという当時の略式表現は、一部の測定の桁数を捉えているかもしれないが、RIPE の個別の指標ほど正確ではない。それらに取って代わるべきではない。証拠は、追加的な完全到達不能、観測された不安定化、更新量を区別している。

地理的およびコレクタによる変動

影響は場所とコレクタによって異なった。ウィーンコレクタは特に高い更新活動を示した。[1] 変動は、トポロジー、ピア選択、影響を受けた実装への露出、代替経路の可用性を反映し得る。

コレクタの場所は、その都市や国でのユーザー影響の直接的な地図ではない。BGP 観測点は参加ピアから経路を受信する。その視野は遠隔ネットワークにサービスする経路を含むことがあり、ローカルユーザーはコレクタから見えない経路をたどり得る。コレクタの証拠は経路挙動については強いが、影響を受けた人数の地理的集計を割り当てるには弱い。

DNS の観測

RIPE は DNSMON を使用して、経路の混乱が可視的な DNS 影響を生み出したかを調べた。ルートサーバーシステムの障害は見つからなかった。[1] この否定的所見は重要である。広範な経路不安定化が、すべての重要サービスの障害を自動的に意味するわけではないからである。

分析では、監視対象ドメインの一部で限定的なクエリ損失、.si および.fr の権威基盤の一部でより顕著な困難が観測された。冗長サーバーは応答を続けた。[1] したがって、証拠は、普遍的な DNS 障害ではなく、部分的かつ不均一な DNS 影響を裏付ける。

冗長サーバーの継続的な可用性は、経路の説明責任にサービスアーキテクチャが含まれることの想起でもある。経路の混乱は、ある権威サーバー経路に到達し得る一方で、別の権威サーバーは到達可能なままである。冗長性は経路欠陥を排除しないが、構成要素の障害が完全なサービス障害になるのを防ぐことができる。

運用者の報告

当時の運用フォーラムには、アクセス中断、経路反応、トラフィック変化の報告が記録された。[4][6] これらの報告は、インシデントが開始機関の外で可視化されたことを確立するのに役立つ。さらなる調査のための問いも特定できる。

これらは正規化された測定の代替ではない。ある交換地点や運用者でのトラフィック低下は、再経路化、損失、予防的ポリシー変更、その他のローカルな対応を反映し得る。一致した基準値、トポロジー、トラフィック記録なしには、インターネット全体の影響数値に変換できない。

証拠が裏付けない主張

限られた記録は以下を確立しない：

当時配備されていた影響を受けた IOS XR リリースの完全なリスト；
影響を受けたルーターまたはデバイスの正確な数；
セッションをリセットしたすべての自律システム；
影響を受けたユーザーの正確な数；
失われたアプリケーショントラフィックの合計；
実験用プレフィックスの普遍的な障害；
DNS ルートの障害；
RIPE NCC、デューク大学、Cisco、運用者による悪意；
事象前のすべての承認の完全な記録；
事象前にすべての運用者が利用可能な緩和策を持っていたこと；または
法的責任。

これらは些細な免責事項ではない。証拠に基づく基盤報道と、裏付けのない掛け算から構築された停止ストーリーの違いを定義する。

6. 管理配分による説明責任

説明責任は、各結果的な決定、実装、回復行動を誰が管理したかを問うときに最も強くなる。最初に見える事象への近さを単独責任の証明として扱うと弱くなる。

管理領域	当事者が管理したもの	当事者が管理しなかったもの	より強い評価に必要な証拠
RIPE NCC	RIS 基盤の使用、インターネット可視の生成、時期、コミュニケーション、監視、撤回、証拠保持、将来の実験ポリシー	すべての外部ルーター上のソフトウェア挙動とすべての運用者の復旧	承認記録、リスク評価、通知計画、監視閾値、撤回基準、保持された観測
デューク大学の研究者	研究設計、実験属性の構築、研究側の Quagga 変更、研究側のテスト	配備済み IOS XR コード、下流セッションポリシー、運用者のソフトウェア配備	テストベクタ、生成された UPDATE バイト、研究実装記録、相互運用性テストの範囲
Cisco	IOS XR の解析、保存、伝播挙動；製品テスト範囲；開示；保守修正	実験を生成する決定と運用者のインストールスケジュール	欠陥分析、影響リリース一覧、回帰結果、修正コードの証拠、配備ガイダンス
ネットワーク運用者	インストール済みソフトウェア、保守、受信・送出ポリシー、ピア管理、フィルタリング、監視、ネットワーク内の復旧	実験設計、上流ベンダーコード、完全なグローバル伝播経路	デバイスログ、パケットキャプチャ、設定、ソフトウェアバージョン、セッション履歴、復旧記録
下流 BGP 実装	実装した規則の下での不正な UPDATE のローカル処理	元の有効な属性または上流の破損の生成	UPDATE エラーログ、セッション通知、サポートされている場合のより狭い処理の証明
インターネット交換	参加ネットワークが経路を交換した接続性	デフォルトでは、各参加者の BGP アナウンスの内容と正確性	より多くの管理を割り当てる前の、特定のルートサーバー、フィルタリング、運用上の役割の証拠

RIPE NCC の管理

RIPE NCC は、実験経路を公開伝播に導入した行為を管理した。RIS AS12654 はテストに使用された起点であり、アナウンスは AMS-IX と GN-IX の RIPE NCC 接続を通過した。[1] RIPE NCC は計画された撤回、証拠の収集、類似の共同研究に関する将来の規則も管理した。

その管理は実験統制上の説明責任を確立する。RIPE NCC が製品欠陥を作り出したことを確立しない。最初の属性は有効と説明された。RIPE NCC にとっての関連する問いは、正確な文書化されていない障害を確実に予測すべきだったかではなく、実験の不確実性が、可能な公開到達範囲に比例して評価され、伝達され、監視され、封じ込められたかである。

より包括的な影響評価、運用者への事前通知、責任ある脆弱性取り扱いへの後のコミットメントは、RIPE NCC 自身が統制上の改善を特定したことを示す。[1] 適切なコミュニケーションを伴う実験継続への執行理事会の支持は、研究の正当性と運用管理の十分性の区別を補強する。[5]

デューク大学の管理

デューク大学の研究者はセキュア経路研究設計を管理し、自らの範囲内で使用された Quagga 修正を提供した。彼らの作業は有効な実験的入力の作成に貢献した。入手可能な記録は、彼らが IOS XR の内部処理や下流ルーターのエラー応答を管理したことを示していない。

研究側の説明責任は、設計上の前提と相互運用性テストの広さに関するものである。2つ目の Quagga インスタンスは、類似のソフトウェア環境での挙動を示し得た。関連するすべての配備済み実装にわたる安全性を確立できなかった。

公開証拠は、デューク大学と RIPE NCC の間の事象前の決定の完全な分担を明らかにしていない。それを捏造するのは不適切である。より細かい割り当てには、公開伝播条件を誰が承認したかを特定する実験計画、テスト記録、コミュニケーションが必要である。

Cisco の管理

Cisco は影響を受けた IOS XR 実装を管理した。そのアドバイザリは、伝播中の有効な未認識推移属性の破損を特定した。[2] その挙動は製品管理領域に属する。解析、保持、直列化、属性フラグ処理、回帰テストである。

Cisco は開示と保守対応も管理した。アドバイザリはインシデント当日に公開され、ソフトウェアメンテナンスアップグレードが準備された。[2] CVE-2010-3035 は公開脆弱性識別子を提供する。[3]

製品の説明責任は依然として証拠に基づくべきである。記録は、配備されたすべてのリリース、影響を受けたデバイス数、欠陥が以前に発見されていたかどうかを確立しない。より強い評価には、リリース固有のテスト、欠陥履歴、インストール証拠が必要である。

運用者の管理

各ネットワーク運用者は、システムのローカルな部分を管理した。ソフトウェアの選択とインストール、保守時期、ピアリングポリシー、フィルタ、監視、セッション保護、復旧である。これらの管理は露出と復旧に影響し得た。

そのことは、運用者が未知のベンダー破損欠陥を予測する責任を負うということではない。また、実験前にすべての運用者が利用可能なパッチや設定緩和策を持っていたことも示さない。運用者の説明責任は、関連する時点で知り得たこと、管理できたことに条件付けられる。

開示後は、継続的保証に必要な証拠が変わる。運用者は、影響を受けたリリースの特定、修正の適用、挙動のテスト、証明の保持を求められ得る。開示前に、不合理な不作為に関する主張には、リスクと実行可能な緩和策がすでに知られていたという証拠が必要である。

交換に捏造された役割を割り当てるべきでない理由

実験は AMS-IX と GN-IX での接続を使用した。[1] その事実は伝播経路を確立する。追加の証拠なしに、いずれかの交換が実験を設計し、属性を承認し、影響を受けたルーターを運用し、参加者の送出ポリシーを管理したことを確立しない。

基盤報道はしばしば、物理的または論理的な通過を決定権限と混同する。名前の付いた交換は、UPDATE を生成、破損、受容した主体でなくても、経路の一部であり得る。説明責任はトポロジーだけから推論すべきではない。

7. 製品修復と実験統制の是正は異なる

完全な対応には2つの修復トラックが必要だった。

製品修復

製品欠陥は、影響を受けた IOS XR システムによる伝播中の有効な未認識推移属性の破損だった。直接の修復はソフトウェアとそのテストに属する。

信頼できる製品修復は以下を実証する：

有効な未知の任意推移属性を受信できる；
破壊的な変異なしに保存される；
プロトコルで要求される形式で伝播される；
関連する属性フラグと長さフィールドが一貫している；
繰り返しのセッション確立が破損を再現しない；
不正な変種がサポートされるエラー処理挙動に従って封じ込められる；
回帰テストが認識経路と不透明伝播経路の両方をカバーする；および
修正リリースが運用者に識別可能である。

Cisco のアドバイザリとメンテナンスアップグレードは、この層に対処する直後の公開行動だった。[2] アドバイザリは欠陥を伝え、アップグレードは実装を変える。この2つは関連するが、互換ではない。

検証には配備の証拠も必要である。ベンダーは修正ビルドが回帰テストに合格することを証明でき、運用者は特定のルーターでどのビルドが稼働しているかを証明できる。どちらか一方の記録だけでは、製品修正と現場導入の両方を確立しない。

実験統制の是正

統制上の欠陥は、研究が行われたことではない。観測された影響範囲を防止または迅速に制限するのに十分な管理なしに、不確実な相互作用が公開経路基盤を通じてテストされたことである。

RIPE NCC の対応は、より厳格な将来の要件を特定した。包括的な影響評価、運用者への十分な事前通知、脆弱性の責任ある取り扱いである。[1] これらは実験前および実験中に行われた決定に対処する。

信頼できる統制上の是正は以下を含む：

明確に制限された技術目的；
生成されるすべての属性と経路の特定；
文書化された伝播境界、またはより広い伝播が必要な理由の説明；
リスクに応じた異種実装テスト；
実行可能な場合の影響を受ける運用者への事前連絡；
定義されたテストウィンドウ；
リアルタイムの経路コレクタ観測；
関連する場合のデータプレーンまたはサービスプローブ；
定量的な停止基準；
直ちに撤回できる権限者；
リハーサルされた撤回手順；
ベンダー連絡基準；
事象前後のデータの保存；および
意図しない外部影響が発生した場合の公開インシデント記録。

統制管理は、未知の欠陥が決して現れないことを保証できない。その目的は、発見が制御不能な外部結果を生み出す確率を下げ、検出から封じ込めまでの時間を短縮することである。

一方の修復が他方の代わりにならない理由

Cisco が IOS XR を修正しても実験管理が変わらなければ、後の実験は別の実装の別の未知の欠陥を露出させ得る。特定の製品リスクは低下するが、発見リスクは残る。

RIPE NCC が実験管理を強化しても、影響を受けたソフトウェアが未修正のままなら、別の有効な未知の推移属性を運ぶ通常のインターネットトラフィックが依然として潜在欠陥に遭遇し得る。公開テストのリスクは低下するが、製品リスクは残る。

したがって、この事象には2つの独立したクロージャーの問いが必要である：

実装欠陥は修正され、関連する場所に配備されたか？
将来の稼働実験は、その不確実性に一致するように制限され、観測可能で、統制されているか？

片方だけに答える報告は、完全な修復を実証していない。

8. 後の標準は分析上の文脈——遡及的判断ではない

2010年8月以降に公開された標準は、より良い封じ込めとポリシー実践の説明に役立つ。それらは、事象中にそれらの実践が配備されていたことを証明せず、また、後の推奨を遡及的に過失の認定に変換することもできない。

RFC 4271：歴史的ベースライン

RFC 4271は、任意推移属性とエラー処理を含む BGP-4 を記述する。[12] その伝播規則は、認識されない推移属性が先へ運ばれるべき理由を説明する。その UPDATE エラー処理は、不正な属性がセッション終了につながり得る理由の説明にも役立つ。

その組み合わせは危険な相互作用を生んだ。拡張性は安全な不透明伝播に依存する一方、不正な入力は広範な応答を活性化し得た。中間実装が不透明情報を破損させたとき、下流システムは、1つの経路よりも大きな結果を持つエラー状態に直面した。

RFC 7606：障害領域の縮小

RFC 7606は後に、セッションリセットが多数の有効な経路を破棄し、大きな経路混乱を引き起こし得るため、BGP UPDATE エラー処理を改訂した。[13] それは一般に、セッション全体を自動的に破壊するのではなく、定義されたケースで影響を受けた経路を撤回済みとして扱うことを含む、より狭い応答を促進する。

分析上の文脈として適用すると、これは障害領域をどのように縮小できるかを示す。不正な広告を影響を受けた経路に封じ込め、セッションと無関係な経路を維持できれば、1つの破損属性が隣接関係を不安定化する力は小さくなる。

RFC 7606が2010年の事象を支配する規則だったと言うのは不正確である。それは後に公開された。また、現在のすべての実装がすべての推奨を均一に適用していると想定するのも不正確である。RFC はアーキテクチャ上の修復方向を説明するが、配備の証拠は依然として必要である。

RFC 7454と RFC 8212：明示的な対外ポリシー

RFC 7454は BGP の運用セキュリティ推奨をまとめ、RFC 8212は外部 BGP アナウンスと受信に対する明示的ポリシーの期待を確立する。[14][15] これらは共に基本的な管理原則を補強する。外部経路は、セッションが存在するというだけで交換されるべきではない。

明示的な受信・送出ポリシーは、偶発的な伝播を減らし、意図された関係を監査可能にする。制限された実験では、慎重に範囲を定めたポリシーが、どのピアがテスト経路を受信するかを制限するのに役立つ。

これらの手段は、伝播が義務付けられている属性を破損させるルーターを直接修正しない。それらはポリシー境界で動作し、欠陥のある直列化経路の内部ではない。経路またはセッションが、実験の正当な目的を損なわずに区別・制約できる場合にのみ、露出を減らす可能性がある。

RFC 7908：経路リーク分類

RFC 7908は経路リークの種類を記述する。[16] ここでは主に、緩い用語への境界として有用である。2010年の事象は、意図的に生成された実験経路と、任意推移属性に影響する実装欠陥を含んでいた。入手可能な証拠は、カテゴリーの条件に一致させずに、それを後のリークカテゴリーに当てはめるために引き伸ばすべきではない。

分類は、無関係なメカニズムが融合するのを防ぐときに説明責任を支える。馴染みのあるラベルが因果分析を置き換えると、説明責任を損なう。

RPKI 起点検証

RFC 6480は Resource Public Key Infrastructure アーキテクチャを記述し、RFC 6811は BGP プレフィックス起点検証を定義する。[17][18] 起点検証は、起点自律システムがプレフィックスについて関連する Route Origin Authorization によって認可されているかを問う。

その管理は、ここで露呈したものとは異なる問いに対処する。経路は、中間製品が後に破損させる属性を運びながら、許容可能な起点関係を持ち得る。起点検証は、すべての経路属性が正しく符号化され保存されていることを証明しない。

実験の実際の RPKI 状態について結論は必要ない。分析上のポイントは限定的である。起点検証だけでは、影響を受けた出力側処理経路をテストしない。

BGPsec

RFC 8205は BGPsec 経路検証を規定する。[19] BGPsec は、定義されたアーキテクチャにおける経路情報の暗号的保護に対処する。デューク大学のグループが研究したセキュア経路のより広い目標に関連するが、この2010年の実験中に何が配備されていたかの証拠ではない。

また、すべての実装欠陥の自動修正として提示すべきでもない。セキュリティメカニズム自体がソフトウェアに実装されている。安全な解析、直列化、障害封じ込め、相互運用性テストは依然として必要である。

NIST の経路セキュリティガイダンス

NIST SP 800-189は、経路保護と運用実践を含む、ドメイン間トラフィック交換のセキュリティ確保に関する後のガイダンスを提供する。[20] フィルタリング、監視、検証、対応に関する現在の期待を構成するのに有用である。

2010年の法的義務を確立するものでも、当時いずれかの当事者が何を知っていたかを証明するものでもない。その適切な使用は将来を見据えたものである。ネットワークが今どのような証拠を保持すべきか、どの管理策が類似の障害連鎖を減らせるかを問うことである。

9. 反実仮想：どの事実が変わっていれば影響を減らせたか

反実仮想分析は、各シナリオが定義された条件を変え、残りの証拠を保持する場合にのみ有用である。確実に何が起きたかを証明できないが、価値の高い管理策を特定できる。

反実仮想1：IOS XR が属性を正しく保存する

1つの事実を変える。影響を受けた IOS XR システムが有効な未認識推移属性を受信し、破損なしに伝播する。

下流の不正な UPDATE はその製品経路から発生しない。破損した UPDATE に起因するセッションリセットメカニズムは、この欠陥によって活性化されない。アナウンスは異例で実験的なままであるが、文書化された障害連鎖は主要な実装点で遮断される。

これは、特定された破損メカニズムを取り除くため、最も強力な製品反実仮想である。他の実装が悪く反応しなかったことは証明しない。

反実仮想2：異種テストが配備挙動を再現する

1つの事実を変える。公開前テストに十分に代表的な影響実装が含まれ、出力側破損を引き起こす。

欠陥は経路が広範な公開伝播に入る前に調査できる。Cisco はテストケースを受信でき、RIPE NCC とデューク大学は実験を延期、制約、再設計するかを決定できる。

限界は代表性である。どの実験室もすべてのインターネット経路を再現できない。価値は、2つの類似の Quagga エンドポイントを超えて拡張し、異なる実装にわたって不透明な受信・伝播挙動を具体的にテストすることにある。

反実仮想3：実験が制限された経路環境で実施される

1つの事実を変える。同じ属性と影響を受けたソフトウェアが、通常の公開伝播ではなく、閉じた、または厳密に管理されたテスト環境で相互作用する。

欠陥は依然としてセッションをリセットし得るが、露出する無関係な経路と外部ネットワークの数を制限できる。証拠を各ホップで取得できる。

限界はリアリズムである。制限された環境は、公開インターネットに見られるトポロジー、ポリシー、ソフトウェアの組み合わせを再現できないことがある。だからこそ段階的拡大が望ましい。制限された多様性から始め、リスクと証拠が正当化する場合にのみ広げる。

反実仮想4：下流ルーターがより狭い UPDATE エラー処理を使用する

1つの事実を変える。後続スタイルの狭い応答が適用可能な場合、下流ルーターが BGP セッション全体を閉じずに不正な広告を封じ込める。

実験経路は破棄され得るが、セッションを介して学習した無関係な有効な経路は利用可能なままである。更新の増幅と再収束圧力は大幅に小さくなるはずである。

この反実仮想は、後に RFC 7606で形式化された方向を反映する。[13] その RFC は事象より後であり、正確な処理はエラークラスと実装に依存するため、分析的なままである。

反実仮想5：事前通知が影響を受ける運用者に届く

1つの事実を変える。運用者が、プレフィックス、属性、ウィンドウ、期待される挙動、停止条件の十分な技術的通知を受ける。

一部の運用者は関連セッションをより注意深く監視し、スタッフを準備し、露出を制限し、異常出現後に迅速に調整し得る。経路が説明のない事象ではなく実験として認識されるため、診断が加速し得る。

通知は IOS XR を修復しない。テストが安全でない挙動を露出させると予想される場合、慎重な脆弱性取り扱いも必要になり得る。したがって、コミュニケーションは緩和・調整策であり、完全な封じ込めメカニズムではない。

反実仮想6：定量的停止基準がより早い撤回を引き起こす

1つの事実を変える。監視が異常な更新レートまたはセッションリセットを、UTC 09:08より前に定義済みの停止閾値を越えるほど早く特定する。

RIPE NCC はより早く撤回する。継続的な生成がより早く終了し、反復と露出時間を減らし得る。

限界は BGP の分散状態である。すでに伝播された更新は依然として撤回と再収束を必要とする。早期の行動は持続時間を減らし得るが、影響を受けたすべての経路を即座に回復しない。

反実仮想7：ポリシーが伝播を選択されたピアに制限する

1つの事実を変える。受信・送出ポリシーが実験経路を明示的に参加するネットワークに制限する。

障害領域が小さくなり、参加運用者は証拠を取得できる。これは後の明示的対外ポリシーの強調と整合する。[14][15]

限界は研究上の問いである。目的が多様な公開実装の観測を必要とするなら、厳格な封じ込めは学べる内容を変える。そのトレードオフは、想定で消すのではなく明示的になされるべきである。

反実仮想8：経路コレクタとサービスプローブが即時に相関アラームを提供する

1つの事実を変える。制御プレーン観測、セッションテレメトリ、関連サービスプローブがリアルタイムで相関される。

調査者は、無害な新しいアナウンスを、更新増幅、プレフィックス不可視、サービス影響からより早く区別できる。撤回決定は証拠駆動になる。

これは最初の破損を防がない。検出を改善し、不確実性が続く間隔を短縮する。

反実仮想9：実験が行われない

1つの事実を変える。公開アナウンスが行われない。

8月27日の引き金が消え、この事象は欠陥を露出させない。製品の欠陥はそれでも潜在したままであり、後に別の有効な未知の属性によって活性化され得る。

この反実仮想は、「実験しない」ことが十分なセキュリティ戦略でない理由を明確にする。テストを避けることはこのインシデントを避けるが、稼働中のソフトウェアを修正しない。より良い目的は安全な発見である。製品修復と組み合わせた制限された実験である。

10. 検証可能な修復の姿

修復の主張は、安心ではなく成果物と観測に結びつくべきである。

製品の証拠

影響を受けた実装について、信頼できる証拠は以下を含む：

正確な修正済みソフトウェアリリース；
適切な詳細レベルでの欠陥のある処理経路のベンダー説明；
有効な未知の任意推移属性を使用する回帰テスト；
バイト保存またはその他の準拠伝播を示すテスト；
不正な、または意図的に破損した変種を使用するテスト；
サポートされる狭いエラー処理が、該当する場合に無関係な経路を保持する証拠；
再発を検出するための反復セッションサイクルテスト；
インストール済みリリースを特定する運用者記録；および
欠陥がもはや再現されないことを示すインストール後の観測。

公開 CVE とアドバイザリは問題と対応を特定する。[2][3] それらは検証可能性の始まりであり、現場クロージャーの完全な証明ではない。

実験の証拠

将来の稼働経路実験について、信頼できる証拠は以下を含む：

テストプレフィックスと起点；
提案された属性符号化；
参加ピアと意図された伝播範囲；
実質的に異なる実装にわたる相互運用性結果；
制御プレーンとサービス影響をカバーする影響評価；
事前通知記録；
定量的停止閾値；
即時撤回権限；
撤回リハーサル；
ライブコレクタ監視；
関連するデータプレーンまたはサービスチェック；
異常と決定のタイムスタンプ；
保存された UPDATE データ；および
期待された挙動と観測された挙動を比較する事後記録。

RIS と Route Views は、複数の経路観測点の価値を示している。[7][11] デバイスログやパケットキャプチャの代わりにはならないが、アナウンスが伝播したか、撤回が増殖したか、影響が観測点によって異なったかを独立に示すことができる。

運用者の証拠

自社ネットワークが保護されていると主張する運用者は、以下を示せるべきである：

影響を受けた IOS XR ソフトウェアが存在するか、存在していたか；
どの修正リリースがインストールされているか；
外部経路ポリシーがどのように定義されているか；
現在のソフトウェアが不正な UPDATE をどのように処理するか；
セッションリセットがどのように検出されるか；
無関係な経路喪失がどのように測定されるか；
どのピア保護が有効か；
復旧決定がどのように記録されるか；および
管理された回帰テストが完了したか。

これが具体的な形での運用継続性である。稼働バージョンの証拠なしの設定文は不完全である。ポリシーと観測の証拠なしのソフトウェアバージョンも不完全である。

クロージャー基準

元のバイト、中間の変異、下流の応答が証拠によって結びつけられたとき、事象は技術的に理解されたとみなせる。修正ソフトウェアが関連する回帰テストに合格し、必要な場所での配備が実証されたとき、製品問題は修復されたとみなせる。将来の実験が、文書化された範囲、通知、監視、停止権限、保存なしに進められないとき、統制上の問題は是正されたとみなせる。

これらのクロージャー基準は意図的に分離されている。公開インシデント報告は、どれが満たされ、どれが未知のままかを述べるべきである。

11. 結論を変え得る証拠

現在の結論は証拠依存である。いくつかの発見は大幅な改訂を必要とする。

最初の属性が不正だったことを示すパケットキャプチャ

権威あるキャプチャが、RIS AS12654 が影響を受けた IOS XR システムに到達する前に不正な形式の属性を生成したことを示した場合、有効な入力が伝播中に最初に破損されたという所見は変わらなければならない。

責任は生成とアナウンス前検証へ移るが、追加の変異や増幅は依然として別途分析が必要である。重要な要件はエンドツーエンドのバイト比較である。起点が送信したもの、各中間システムが受信したもの、出力したものである。

異なる破損点を特定するデバイスログ

ログやキャプチャが、別の実装、ルートサーバー、中間装置が破損を作り出したことを示した場合、製品帰属は改訂が必要である。Cisco のアドバイザリは、同じ欠陥が観測されたすべての経路を説明することを証明せずに、実際の欠陥を特定できる。

この事象は複数の障害モードを含んでいたかもしれない。すべてのリセットが1つの破損点を共有したかは、経路固有の証拠のみが確立できる。

影響推定を大幅に改訂するコレクタデータ

保存されたコレクタデータが、基準値、影響を受けたプレフィックス数、持続時間が大幅に異なることを示した場合、限定的影響評価は更新されるべきである。修正は測定範囲を上げることも下げることもあり得る。

改訂は実装メカニズムを自動的に変えない。原因と規模は関連するが独立した証拠上の問いである。

追加の管理策を示す承認・リスク記録

完全な実験記録が、公開記述に見えない実質的な封じ込め、通知、停止管理を示した場合、統制評価はそれを認めるべきである。その場合、なぜそれらの管理策が観測された混乱を防止または短縮しなかったかを説明する必要がある。

逆に、特定された高影響リスクが緩和なしに受け入れられたことを示す記録は、統制批判を強める。公開記述だけではどちらのシナリオも確立しない。

事前の特定と効果的な管理を示す製品記録

製品テスト記録が、欠陥が実験前に特定され効果的に管理されていたことを示した場合、経緯と責任配分は変わる。調査者は、影響を受けた配備システムに利用可能な修正がなかったか、運用者が該当する通知を受けたか、観測された挙動が別のメカニズムから来たかを問う必要がある。

現在の記録はそのような事前特定を確立していない。

より広い、またはより狭いサービス影響の証拠

完全なトラフィック測定、運用者ログ、サービス遠隔測定は、ユーザーに見える結果の評価を改善し得る。制御プレーンの不安定化が現在文書化されているよりも多くのアプリケーション混乱を引き起こしたか、経路変動にもかかわらず冗長性がほとんどのサービスを利用可能に保ったかを示し得る。

そのような証拠は影響の節を変えるが、パケットレベルの証明なしに元の UPDATE の有効性を書き換えることを正当化しない。

12. 抑制された結論

2010年の RIPE-デューク大学実験は、通常の悪意ある経路ハイジャックではなく、入手可能な証拠はそれをそのように描写することを裏付けない。また、非合理なルーターに偶然遭遇した無害な標準テストでもなかった。

それは、有効で未知の任意推移属性が影響を受けた IOS XR 実装に遭遇した稼働中経路実験だった。その実装は伝播中に属性を破損させた。下流ルーターはその後、不正な UPDATE に応答して BGP セッションをリセットし、無関係な有効な経路を撤回し、繰り返される再収束に寄与し得た。RIPE の測定は、例外的な更新レート、追加的なプレフィックス不可視、約4,500件に達する不安定なプレフィックスのピークという、限定的だが重大な混乱を捉えた。[1][2]

この事象は、異なる管理領域の2つの欠陥を露出させた。1つは有効な不透明経路情報の処理における製品欠陥だった。もう1つは実験統制上の弱点だった。限られた公開前テストと不十分に制限された公開露出が、未知の相互作用をインターネット経路インシデントに変えることを許した。

Cisco のアドバイザリとメンテナンスアップグレードは製品欠陥に対処した。RIPE NCC の調査、証拠保存、より厳格な将来の実験コミットメントは統制上の欠陥に対処した。後の標準はより良いエラー封じ込めとポリシーガイダンスを提供したが、それらは文脈であり、遡及的証明ではない。

最も永続的な教訓は管理に関するものである。起点での標準準拠は、安全なエンドツーエンドの挙動を保証しない。レジストリや経路コレクタは、誰がプレフィックスをアナウンスしたかを特定し、可視性がどう変わったかを示せるが、すべての中間実装に属性を正しく保存させることはできない。ベンダーは安全な稼働コードを証明しなければならない。実験開始者は不確実な公開テストを制限しなければならない。運用者は自社のソフトウェア、ポリシー、復旧状態を知らなければならない。観測システムは、引き金、破損、増幅、影響を区別するのに十分な証拠を保存しなければならない。

説明責任は、経緯の中で最初の組織を名指しすることで達成されない。すべての結果的な管理を所有者に一致させ、対応する修復が機能するという証拠を要求することで達成される。

概要