Telekom Malaysia 2015年ルートリークと上流フィルタリングの説明責任

要約

独立した監視により、Telekom Malaysia の AS4788 からの大規模な BGP 経路広告バーストが2015年6月12日08:43 UTC 頃に始まったとされています。BGPMon は約179,000のプレフィックスが広告されたと報告し、RFC 7908は後にこのイベントを Level 3が約179,000のプレフィックスを受け入れ伝搬した主要なルートリーク事例として引用しています。[2][10]
異なる分析でルート数が異なるのは、使用するコレクター、時間枠、定義が異なるためです。Geoff Huston の分析は約2,500の新たに可視化されたルートについて議論し、22,577の影響を受けたルートのセットを調査しました。これらの数値を誤った精度で統合することはできません。[1][2]
Level 3の AS3549 は AS4788 の広告を観測しただけでなく、それを受け入れ伝搬し、主要なグローバルトランジットネットワークを通じて爆発範囲を拡大しました。ThousandEyes は Level 3の複数の拠点で深刻なパケット損失と終端経路を測定しました。[2][3]
証拠はリレーションシップポリシーリークを支持しています。ピアから学習したルートが上流のトランジットプロバイダーに向けて再広告された可能性があります。正確な Telekom Malaysia のルーター設定、ルートマップ、コマンド、ソフトウェア、承認チェーンはこのパケットでは公開されていません。[1]
説明責任は制御によって分割されています。AS4788 はそのエクスポートポリシーとルートマップライフサイクルを制御していました。AS3549 は顧客から何を受け入れるか、適用されるボリュームとパスチェック、受け入れられたルートが伝搬されるかどうかを制御していました。下流ネットワークは独自のインポートポリシーと監視を制御していました。
通常の RPKI 経路起点検証はこのイベントに対する完全な解決策ではありません。漏洩したパスのほとんどは正当な起点を保持していました。起点の認証が有効であっても、パスが顧客、ピア、またはプロバイダーのエクスポート意図に違反する可能性があります。[1][15][16]
後の標準規格は可能な制御を明確にしています。RFC 8212は eBGP のデフォルト要件として明示的なインポートおよびエクスポートポリシーを規定し、RFC 9234は関係を認識した BGP ロールと Only to Customer 属性を追加しています。これらはレトロスペクティブな制御ガイダンスであり、2015年のコンプライアンス違反の証明ではありません。[11][12]
信頼できる修復の主張には、復旧だけでは不十分です。広告セットの凍結された再構築、意図されたセッションポリシー、設定変更前後の証拠、同じリーククラスに対するテスト、独立した経路観測、およびエクスポート側と受入側の両方が再発を封じ込められることの証明が必要です。

経路広告が他者のトラフィックに対する権限となった

BGP はしばしばインターネットにネットワークがどこにあるかを伝えるプロトコルとして紹介されます。その説明は正確ですが不完全です。BGP 広告は運用上の権限の主張でもあります。

ある自律システムが別のシステムにプレフィックスが自分を通じて到達可能であると伝えると、受信側はそのパスを優先し、さらに広告することができます。他のネットワークは広告されたパスに向けてトラフィックを誘導できます。その経路には、広告元のネットワークに十分な容量があること、パスが商業関係に準拠していること、すべての中間オペレーターがトランジットを提供する意図があることの保証はありません。BGP は到達可能性情報と AS パスデータを配布し、ポリシーがネットワークがどの主張を受け入れ繰り返すかを決定します。[8]

そのポリシーレイヤーこそ、2015年の Telekom Malaysia イベントが世界的に重大なものとなった理由です。

独立した情報源によると、6月12日08:43 UTC 頃に大規模な広告バーストが始まりました。Telekom Malaysia の AS4788 は膨大なルートセットを Level 3の AS3549 に広告しました。Level 3はそれらのルートを受け入れ、ピアや顧客に伝搬しました。トラフィックは変更されたパスに従いました。AS3549 と AS4788 を経由するパスはルーティングポリシー上魅力的に見える可能性がありましたが、相互接続は結果として生じるトラフィック量を安全に運ぶことができませんでした。パケット損失と遅延が増加し、Telekom Malaysia の自社顧客ベースをはるかに超えたサービスへの到達が困難または不可能になりました。[2][3]

このイベントは、偽造証明書、ドメイン名の侵害、または最も単純な意味での虚偽の経路起点ではありませんでした。影響を受けた多くのプレフィックスは依然として正当な起点自律システムに終端していました。有害な変化は、AS4788 が予期されていなかった方向にルートをエクスポートするために自身をトランジットとして挿入したことでした。パスは構文的に有効で、ループフリーで、起点が有効であっても、学習された経済的・運用上の関係に違反する可能性があります。

この区別は説明責任にとって重要です。問題が「Telekom Malaysia がルートをリークした」とのみ説明されると、責任はエクスポートネットワークで終わるように見えます。しかし、BGP 伝搬はすべてのセッションで双方向です。一方が広告し、他方が何を受け入れ、優先し、さらに広告するかを決定します。大規模なトランジットネットワークは孤立した顧客よりも大きな伝搬力を持ちます。その力は対応するフィルタリングと証拠の義務を生み出します。

中心的な問いは、どのオペレーターが最初に間違いを犯したかではありません。他のネットワークの障害となる前に、その間違いを止める実用的な能力を独立したコントロールがいくつ持っていたかです。

時系列は端では明確だが、ネットワーク内部では不完全

BGPMon は AS4788 が08:43 UTC に大規模なルートセットの広告を開始したと報告しました。その監視では、パケット損失が始まると同時に BGP 更新メッセージが急増しました。分析では約179,000のプレフィックスが広告され、影響を受けた Facebook のプレフィックスが AS3549 と AS4788 を経由して正当な起点に至るパスの例として挙げられました。[2]

ThousandEyes も独立して同じ大まかなシーケンスを説明しました。Telekom Malaysia と Level 3を経由する新しいパス、深刻なパケット損失、アムステルダム、シカゴ、フランクフルト、ロンドン、ロサンゼルス、シアトル、ワシントンなどの場所での終端経路を観測しました。Level 3が約10:45 UTC にルートの受け入れを停止し、サービスが正常に戻り始めたと述べています。[3]

BGPMon は約10:40に改善、約11:15に広範な解消を報告しました。これらの時間は属性を保持すべきです。ルートコレクター、アクティブ測定プラットフォーム、トランジットオペレーター、エンドユーザーは同じイベントを同じ瞬間に観測するわけではありません。フィルターが新しい広告を停止しても、古いパスが他の場所で選択され続けることがあります。撤回は不均一に伝搬する可能性があります。輻輳はコントロールプレーンのトリガーが除去された後も持続する可能性があります。したがって、復旧は普遍的なタイムスタンプではなく、一連のプロセスです。

RIPE Atlas の分析は後にこのイベントを使用して、コアインフラストラクチャの大規模な障害がエンドツーエンドの接続性にどのように影響するかを調査しました。ストレス下にあるインフラストラクチャの周りをトラフィックが迂回する証拠と、エンドツーエンドの障害の両方を見つけました。著者らは代表性について明確に述べています。多様なグローバル測定システムでも、有限のパスと宛先のセットしか観測できません。[4]

公開された時系列は強力な外部記録と弱い内部記録を持っています。

外部の観測者はおおよその開始点、変更されたパス、ルート更新量、パケット損失、遅延、大まかな復旧を特定できます。彼らはプライベートなルートマップ、オペレーター端末、承認された変更、設定されたプレフィックス制限、アラートキュー、または Telekom Malaysia と Level 3間の意思決定の会話を見ることはできません。

そのギャップは記事の言葉遣いを形成するべきです。

AS4788 がルートを発信し、AS3549 がそれを受け入れ伝搬し、グローバルな到達可能性が損なわれたと言うことは防御可能です。そのパターンがピア学習ルートが上流プロバイダーにエクスポートされたことと一致すると言うことは防御可能です。しかし、認証されたオペレーター記録なしに、正確なコマンド、ルーター、従業員、変更チケット、またはソフトウェア欠陥を特定することは防御できません。

Geoff Huston の分析はルートポリシーの障害について確率的な表現を使用しており、一部の箇所で AS 番号の明らかなタイプミス異体を含んでいます。Telekom Malaysia のネットワークは AS4788 です。記事は明らかな AS4877 や AS4778 の参照を追加のアクターに変えたり、それらを使用して内部デバイスについての確実性を作り出したりすべきではありません。[1]

完全な説明責任記録は外部のタイムラインを内部の証拠に結びつけるでしょう：

最後の既知の正常なエクスポートポリシー。
提案され正規化された変更。
各ルーターまたはセッションがそれを受信した時間。
エクスポート用に選択されたプレフィックスの数とタイプ。
ルート量と関係違反のアラート。
AS3549 での受け入れと最大プレフィックス状態。
エスカレーションの連絡先とメッセージ。
伝搬を停止したコマンドまたは自動アクション。
撤回と収束を示すコレクター証拠。
修復されたポリシーが同じルートクラスを拒否することを証明するテスト。

その連鎖がなければ、復旧は可視ですが、組織的な学習は検証が困難なままです。

プレフィックス数は異なるビューを説明しており、1つの争われた事実ではない

大規模なインターネットインシデントは単一の記憶に残る数字を引き寄せます。ここでは、その本能が記録の正確性を低下させる可能性があります。

BGPMon は AS4788 が約179,000のプレフィックスの広告を開始し、後に約176,000のリークされたプレフィックスに言及しました。RFC 7908は「大規模な Telekom Malaysia ルートリーク」を約179,000のプレフィックスとして引用しています。ThousandEyes はグローバルルーティングテーブルの大部分を説明しました。[2][3][10]

Huston の分析はイベントの異なるビューを使用しました。何千もの新たに可視化され撤回されたルートを含むネットのルーティングテーブル変更を示し、その後特定の影響を受けたセット内の22,577ルートを調査しました。[1]

これらの数字は共存可能です。なぜなら、BGP イベントには1つの自然な単位しかないわけではないからです。

観測者はすべての UPDATE メッセージ、予期しないパスを通じて広告されたすべてのユニークなプレフィックス、コレクターで新たに可視化されたすべてのプレフィックス、変更されたすべてのベストパス、すべてのより具体的なルート、選択された時間にまだ存在するすべてのルート、または影響を受けたすべての起点をカウントできます。コレクターは異なるフィードを受け取ります。ルートは広告され、撤回され、再広告されることがあります。一部のパスはあるコレクターでは可視でも別のコレクターではそうではありません。完全なテーブルとフィルタリングされた影響セットは異なる質問に答えます。

説明責任のある編集上の選択は、測定の定義を保持することです。

記事は、BGPMon と RFC 7908がその再構築で約179,000のリークされた広告またはプレフィックスを説明したと言うことができます。Huston の別個の分析が22,577ルートのセットを調査し、何千ものテーブル追加と撤回を観測したと言うことができます。値を平均化したり、ドラマのために最大値を選んだり、ユーザー影響の完全な国勢調査として一つを提示したりすべきではありません。

同じ規律が影響を受けたサービスにも適用されます。BGPMon と ThousandEyes は主要なプラットフォームと金融サービスを含む例を特定しました。これらの例は範囲と副次的影響を示しています。すべてのプレフィックスが同じパケット損失を経験した、すべてのサービスが利用不能になった、またはすべてのユーザーが AS4788 を経由したことを確立するものではありません。

カウントは、その定義が保持されるときに説明責任の証拠となります：

広告数はエクスポート量が異常だったかどうかをテストします。
ユニークプレフィックス数は主張されたルーティング権限の広がりをテストします。
変更されたベストパス数はいくつのネットワークがリークを選択したかをテストします。
コレクター可視性は伝搬をテストします。
トラフィック量とパケット損失は運用上の害をテストします。
影響を受けた顧客とアプリケーション数はビジネス影響をテストします。
撤回期間は封じ込めをテストします。

各測定には責任者、しきい値、保持された記録が必要です。トランジットプロバイダーは顧客の通常の数千のプレフィックスを受け入れるかもしれませんが、突然の桁違いの変化を隔離するかもしれません。ルート監視システムは、生のプレフィックス量が静的な制限を下回っていても、顧客コーン期待に違反するパスを検出するかもしれません。公開されたポストモーテムは1つの見出しの総数を提供するのではなく、両方の尺度を説明するかもしれません。

誤った精度は書き方の問題だけではありません。どの制御が失敗したかを隠す可能性があります。

リレーションシップポリシーは BGP 到達可能性の背後にある不可視の構造

インターネットはすべての自律システムが他のすべてのシステムに無料のトランジットを提供するフラットなメッシュではありません。ネットワークはトランジットを購入し、販売し、ピアリングを行い、これらがルートポリシーを形成します。

簡略化された運用ルールは次のように機能します：

顧客から学習したルートは顧客、ピア、プロバイダーに広告されることがあります。
ピアから学習したルートは顧客に広告されることがありますが、通常は別のピアやプロバイダーには広告されません。
プロバイダーから学習したルートは顧客に広告されることがありますが、通常は別のプロバイダーやピアには広告されません。

これらのルールはおなじみの「バレーフリー」モデルを生み出します。パスは顧客からプロバイダーへ上昇し、最大で1つのピア関係を横断し、顧客へ下降します。下降してから再び上昇するパスは、ネットワークが意図しないトランジットを提供していることを示す可能性があります。[1][10]

実際の商業関係はより複雑です。2つのネットワークは異なる場所、アドレスファミリ、またはサービスで異なる役割を持つことができます。部分的なトランジット、有料ピアリング、ルートサーバー、地域的取り決めは常に単一のラベルに適合するとは限りません。その複雑さはポリシーを文書化しテストする理由であり、省略する理由ではありません。

Huston の再構築によると、AS4788 は交換ポイントのピアからルートを収集し、上流のトランジットネットワークに再広告したように見えます。そのモデルでは、横方向に学習されたルートが「上り坂」にエクスポートされました。Level 3はその後パスを受け入れ伝搬しました。[1]

プロトコル自体は AS パスからすべてのプライベートなビジネス関係を推測できません。正当な AS 番号のシーケンスは、ルートが契約上および運用上それらを通過することが許可されていたかどうかを示しません。その知識はローカルポリシー、公開されたルーティングオブジェクト、交渉されたロール、コミュニティ、顧客コーンデータ、または別の検証システムにエンコードされなければなりません。

これがルートリークが困難な理由です。ルーターは認証されたネイバーから有効な BGP UPDATE を受信し、正当な起点を見て、ループフリーの AS パスを構築し、それでも意図された関係に違反するルートを受け入れる可能性があります。

したがって、運用上の説明責任には、ネットワークが可能な限り期待を機械的にチェック可能にすることが必要です：

各 eBGP セッションと例外的なポリシーを分類する。
ネイバーから期待されるプレフィックスと顧客パスを定義する。
ルートが学習された方法に従ってエクスポートを制約する。
提案されたポリシーを意図された関係と比較する。
説明できない拡張を拒否または隔離する。
例外に対する人間が読める説明を保持する。
代表的なフルテーブル条件に対してポリシーをテストする。

公開されたイベントは、関係の意図が暗黙のままであるか、執行が効果的でないときに何が起こるかを示しています。ルートは1つのセッションを越え、誰かがチケットを読む前にグローバルな主張になる可能性があります。

AS4788 はエクスポートを制御し、AS3549 は受け入れと伝搬を制御した

Telekom Malaysia は AS4788 を離れる広告セットに対して最も直接的な制御を持っていました。エクスポートネットワークは、どのルートを自ら発信したか、顧客から学習したか、ピアまたはプロバイダーから学習したか、およびどのクラスが各ネイバーに送信されるかを知っているべきです。

その制御は設定の有効化より前に始まります。

変更はルーターが施行する実際のプレフィックスおよび AS パスポリシーにコンパイルされるべきです。レビューは結果を期待される顧客コーン、ルート数、および関係ルールと比較するべきです。テスト環境またはオフライン評価器は代表的なルートをポリシーに通し、何がエクスポートされるかを示すべきです。独立したチェックは、別の非顧客セッションのために選択されたピアまたはプロバイダー学習ルートにフラグを立てるべきです。

公開記録は、そのような制御が AS4788 に存在したか、ルーチン設定が変更されたか、潜在的な状態がトリガーされたかを確立しません。それは出力を確立します：大規模で安全でないルートセットがエクスポートされました。

Level 3の制御境界は別個であり、グローバルな伝搬にとって同様に重要です。

AS3549 は、AS4788 から受信したルートが適格かどうか、どのように優先されるか、どこに広告されるかを選択しました。大手トランジットプロバイダーは、任意の第三者が持たない顧客固有の知識を持っています。期待されるプレフィックス数、登録された顧客ルート、観測された履歴、顧客コーン関係、セッションの目的を知ることができます。以下を適用できます：

明示的なインポートポリシー。
認証されたルーティングデータから導出されたプレフィックスリスト。
AS パスおよび顧客コーン制約。
最大プレフィックスしきい値。
ルート長およびボゴンチェック。
関係を認識したリーク検出。
異常のための隔離または低優先ポリシー。
例外的な拡張に対する人間の承認。

BGPMon の説明によると、Level 3は広告を受け入れ、ピアや顧客に広告しました。ルートはその後トラフィックを引き寄せ、Level 3および主要なピアリングロケーションでの輻輳に寄与しました。[2]

これは、上流がすべての顧客ルートが正しいことを保証できるという意味ではありません。静的なフィルターは陳腐化する可能性があります。マルチホームの顧客は正当に広告を変更できます。緊急ルーティングはセットを拡大する可能性があります。複雑なポリシーは顧客コーンの計算を困難にする可能性があります。厳しすぎるフィルターはそれ自体で障害を引き起こす可能性があります。

しかし、これらのコストはプロバイダーの主体性を消し去るものではありません。それらはエンジニアリングの問題を定義します。

グローバルな伝搬力を持つトランジットプロバイダーは以下に答えられるべきです：

この顧客にとって正常なルート数とパス形状の範囲は何か？
どの変更に事前調整が必要か？
受け入れられたセットには、顧客の背後にある他の主要なピアやプロバイダーからのルートが含まれていたか？
最大プレフィックスしきい値は存在したか、現実的なベースラインに対して設定されていたか？
チェックを無効化または弱化する例外がセッションにあったか？
最初にどのアラートが発報したか？
顧客を待たずにルートを抑制できるのは誰か？
調査中の collateral トラフィックはどのように保護されたか？

説明責任は害を制限するこの実用的な能力に従います。AS4788 のエクスポートエラーと AS3549 の受け入れは相互に排他的な説明ではありません。それらは同じ伝搬チェーンにおける連続した制御障害です。

トランジット集中がポリシーエラーを共有された害に変えた

すべてのルートリークがグローバルなインシデントを引き起こすわけではありません。爆発範囲は、リークがどこで受け入れられるか、パスがどれほど魅力的になるか、どれほど広く伝搬されるか、そして受信ネットワークがリダイレクトされたトラフィックを運ぶ容量があるかどうかに依存します。

Level 3は主要なグローバルトランジットプロバイダーでした。AS3549 がパスを伝搬すると、マレーシアから遠く離れたネットワークや顧客がそれらを選択する可能性がありました。通常は直接、地域的、またはより適切にプロビジョニングされた経路をたどるトラフィックが、Level 3と AS4788 を通るパスに引き寄せられました。[2][3]

2つの害のメカニズムが続きました。

1つ目は直接的なパス転換です。宛先プレフィックスが AS3549 と AS4788 を通る選択されたパスを取得する可能性がありました。パケットはその宛先に対してグローバルトランジットを提供する意図がなかったにもかかわらず、Telekom Malaysia に向かって移動しました。相互接続が飽和し、パケットがドロップされ、遅延が増加する可能性がありました。

2つ目は collateral 輻輳です。サービスはリークされたパス自体を選択しなくても影響を受ける可能性がありました。Level 3の容量または輻輳した拠点に依存している場合、異常なトラフィック負荷が通常のルートを損なう可能性がありました。ThousandEyes は、サービスの独自のルートは変更されていないが、Level 3内の輻輳が可用性を低下させた例を説明しました。[3]

この2つ目のメカニズムは重要です。なぜなら、漏洩したプレフィックスのリストを超えて説明責任のレンズを広げるからです。共有されたトランジットインフラストラクチャは、ルーティングポリシーが直接間違っていない顧客にも害を伝える可能性があります。容量、分離、トラフィックエンジニアリングは封じ込め問題の一部になります。

ネットワークは、グローバルテーブルの任意の部分が突然それを選択するためにすべてのリンクをプロビジョニングすることはできません。経済的制限は現実的です。しかし、トランジットプロバイダーは、異常なルートセットがそもそもそのトラフィック権限を取得しないように制御を設計できます。

したがって、このイベントはルーティングセキュリティと集中リスクを結びつけます。高度に接続されたトランジットネットワークは通常の条件下で到達可能性を向上させます。同じ接続性は、安全でないルートが受け入れられ伝搬されるときにポリシー障害を増幅します。規模は回復力の資産であると同時に爆発範囲の乗数でもあります。

責任ある運用は伝搬到達性をリスク変数として扱うべきです：

小さなローカル顧客の広告は通常の自動処理を使用できます。
多くの無関係な大規模ネットワークからのルートの突然の顧客広告は、隔離または検証を必要とするべきです。
多くのリージョンにわたってパスを変更する変更は、外部からの測定をトリガーするべきです。
プロバイダーは、リダイレクトされたトラフィックを受信する拠点と相互接続を知っているべきです。
封じ込めは、健全な顧客ルートを不必要に無効にせずに可能であるべきです。

目標は自動化を排除することではありません。それは自動化をそれが付与する権限に比例させることです。

最大プレフィックス制御は役立つが、完全なポリシーではない

最大プレフィックス制限は、大規模なリークに対する直感的な防御です。顧客が通常は制限されたセットを広告し、突然巨大なテーブルを送信する場合、プロバイダーは警告し、新しいルートを拒否するか、セッションをシャットダウンできます。

BGPMon は、異常なルート量が Level 3の他の大規模ネットワークとのセッションでも最大プレフィックス制限をトリガーし、さらなるチャーンとパス変更を引き起こす可能性があることを示唆しました。[2]

その観察は、単純なしきい値の価値と危険性の両方を明らかにしています。

カスタマーエッジでは、適切に調整された最大プレフィックス制御が、広範な伝搬の前に非現実的な拡張を止めることができます。下流セッションでは、同じメカニズムが悪いルートがすでに主要プロバイダーに入った後に反応し、セッション全体をドロップしてトラフィックを別の場所に移す可能性があります。制限は1つのパスを封じ込める一方で、別のパスを不安定にする可能性があります。

効果的な制限にはコンテキストが必要です：

顧客の通常の集約およびより具体的なプレフィックス。
期待される成長。
メンテナンスおよび緊急シナリオ。
IPv4 と IPv6 の別々の動作。
拒否されたルートがフェイルクローズするか、最後の既知の正常セットを保持するか。
ハードストップ前のアラートエスカレーション。
有効期限付きの安全なオーバーライドプロセス。
現実的なトラフィック下での応答のテスト。

ルート数はすべてのリークを検出できるわけでもありません。顧客は少数の非常に魅力的なより具体的なルートをリークするかもしれません。総量をあまり増やさずに強力なピアからのルートをエクスポートするかもしれません。正当な顧客ルートを同じサイズの不正なセットに置き換えるかもしれません。

したがって、最大プレフィックスは1つのレイヤーです。プレフィックス所有権、顧客コーン検証、AS パス関係、ルートソースタグ、異常検出は異なる障害形状に対処します。

インシデント後の記録は、どのレイヤーが存在したかを述べるべきであり、「フィルターが改善された」とだけ述べるべきではありません。イベント後に追加された最大プレフィックスしきい値は、オペレーターがベースライン、しきい値ロジック、応答モード、および再構築された広告セットを使用したテストを公開した場合に意味のある証拠となります。

RPKI 起点検証はパスポリシーの障害を解決しなかっただろう

ルーティングセキュリティの議論では、RPKI が BGP インシデントへの一般的な回答として使われることがよくあります。ここではその省略表現は危険です。

リソース公開鍵基盤（Resource Public Key Infrastructure）により、インターネット番号リソースの保持者は暗号的に検証可能なステートメントを作成できます。ルート起点認証（Route Origin Authorization）は、許可のプレフィックス長ルールに従って、どの自律システムがプレフィックスを発信することを許可されているかを識別します。ルート起点検証（Route Origin Validation）は、受信した広告のプレフィックスと起点 AS をそれらの認証と比較して分類できます。[15][16]

2015年の AS4788 イベントは大部分がパスポリシーリークであり、単純な不正な起点ではありませんでした。

漏洩したルートの多くでは、正当な起点が AS パスの終端に残っていました。AS4788 は自身をトランジットとして挿入し、ルートを予期されていなかった関係に広告しました。起点検証ツールは許可された起点を見て、ルートがピア/プロバイダーエクスポート意図に違反していても有効と分類する可能性があります。

Huston の分析はこの点を直接指摘しています。彼が調査したルートセットでは、AS4788 が起点として現れ、通常の ROA フィルタリングが対処できるようなものはごく少数でした。問題のほとんどはトランジット情報に関するものでした。[1]

これは RPKI が重要でないという意味ではありません。起点検証は不正な起点、偶発的な誤発信、および多くのハイジャックを阻止できます。それは偽の到達可能性の1つのクラスを減らすことができます。また、より広範な制御をサポートできる認証されたリソース情報を提供します。

しかし、それは制御の主張が正確でなければならないことを意味します。

「ROV を展開した」というだけでは、有効な起点を持つが無効な関係パスを持つルートに対する保護を証明できません。ネットワークは、誰が誰にトランジットを提供できるか、どのパスがポリシーと一致するかに関する追加情報を必要とします。RPSL、顧客コーンデータ、コミュニティ、BGP ロール、Only to Customer 属性、ASPA 関連作業、およびオペレーター固有のフィルターは、この問題の一部を異なる成熟度レベルで扱います。

説明責任のあるメッセージは階層化されています：

RPKI は起点権限を検証します。
明示的なインポートおよびエクスポートポリシーがセッションを制約します。
関係を認識した制御がパス伝搬を制約します。
監視は静的なデータが見逃す異常を検出します。
運用上の調整は予防が止められないものを封じ込めます。

これらのレイヤーを混同すると、誤った保証と弱いインシデント後の学習を生み出します。

ルートレジストリは意図を公開できるが、古い意図は制御ではない

ルーティングポリシー仕様言語（Routing Policy Specification Language）は、インターネットルーティングレジストリでルーティングポリシーを記述するために設計されました。RPSL と RPSLng は、インポートおよびエクスポートポリシー、自律システムセット、ルートセット、および関連する意図を表現できます。[13][14]

原則として、プロバイダーは認証され維持されたポリシーデータを使用して顧客のフィルターを生成できます。顧客は広告を予定するプレフィックスと AS 関係を公開できます。ピアは観測されたルートを宣言された意図と比較できます。

Huston の分析は魅力と限界を説明しています。レジストリデータは不完全、古い、データベース間で重複、またはセッション固有の関係に対して粗すぎる可能性があります。複雑なポリシーは表現と維持が困難な場合があります。いくつかのレジストリは歴史的に弱い権限で第三者エントリを許可していました。[1]

間違った教訓はルートレジストリが役に立たないということです。正しい教訓は、レジストリオブジェクトはその所有権、鮮度、範囲、使用が検証可能である場合にのみ証拠となるということです。

成熟したフィルタリングパイプラインは以下を記録するべきです：

使用されたレジストリとオブジェクト。
認証とメンテナンス権限。
最後の成功したリフレッシュ。
AS セットの具体的なプレフィックスとパスへの展開。
レジストリ間の競合。
ローカルな例外。
生成されたフィルター差分。
ルーター展開結果。
公開されたポリシーと観測されたポリシーの乖離の監視。

MANRS はルーティングセキュリティを集団的な運用責任として位置づけています。そのオペレーター行動は、広告のフィルタリング、調整連絡先の維持、および他者が検証できる情報の公開を強調しています。現在の実装ガイドはプレフィックスおよび AS パスの粒度について議論し、顧客学習または中間ルートが不適切な非顧客ピアにエクスポートされるのを防ぐ制御を推奨しています。[17][18]

これらの現在の文書は現在の形で2015年イベントよりも後です。それらは制御フレームワークとして使用されるべきであり、遡及的な法的証拠としてではありません。

このイベントは、フレームワークがなぜ重要かを示しています。1つのルーター設定だけに知られているポリシーは、別のネットワークが検証するのが困難です。公開されたがフィルターにコンパイルされていないポリシーは単なる文書です。古いデータからコンパイルされたフィルターは有効なルートを拒否したり、無効なルートを受け入れたりする可能性があります。説明責任には、宣言された意図から展開された動作、観測されたルートへの連鎖が必要です。

デフォルト拒否が障害モードを変える

2017年に公開された RFC 8212は、eBGP セッション上のルートが明示的なポリシーが設定されていない限りインポートもエクスポートもされないように BGP 動作を更新します。[11]

これは非常に重要な設計選択です。

寛容なデフォルトは初期設定中の到達可能性を容易にします。また、ポリシーの欠落が黙って「すべてを受け入れる」または「すべてを広告する」になる可能性があることも意味します。オペレーターはセッションがルートを運ぶ前にすべての保護ルールを追加することを覚えておかなければなりません。

デフォルト拒否の姿勢は障害モードを変えます。ポリシーの欠落はルート交換を生じさせず、これは可視的でローカルであり、意図しないグローバル伝搬ではありません。オペレーターは依然として誤った明示的なポリシーを書く可能性があります。RFC 8212はそのように述べています。この制御は意味的な間違い、陳腐化したフィルター、または意図的な例外を解決しません。

しかし、それは健全な説明責任の原則をエンコードしています：グローバルな到達可能性は積極的なポリシー決定を必要とするべきです。

顧客-トランジットセッションの場合、その決定はレビュー可能であるべきです：

どのプレフィックスが受け入れられるか。
どの起点と顧客パスが期待されるか。
どのルートがエクスポートされて戻されるか。
例外がどのように承認されるか。
ポリシーデータが利用できない場合に何が起こるか。
ロールバックを所有するシステムはどれか。
展開を証明する証拠は何か。

すべての関連する eBGP エッジが厳格なデフォルトと正しい明示的なポリシーを使用していたなら、欠落したフィルターはフェイルクローズしていたでしょう。公開された証拠は、RFC 8212のような動作がこの特定のインシデントを防いだかどうかを示すことができません。なぜなら、実際の2015年の設定を公開していないからです。RFC は依然として有用なレトロスペクティブテストです：ルート交換は両側で明示的で境界のある権限を必要としましたか？

BGP ロールと Only to Customer が関係情報に対処する

2022年に公開された RFC 9234は、BGP ロールと Only to Customer 属性を標準化します。ネイバーはプロバイダー、カスタマー、ピア、ルートサーバー、ルートサーバークライアントなどのロールをネゴシエートできます。伝搬されたルートは、期待される関係方向を強制し、リークを検出するのに役立つ情報を運ぶことができます。[12]

このメカニズムは AS4788 イベントで可視化されたギャップをターゲットにしています。正当な起点とループフリーパスは、ピアから学習したルートがプロバイダーに送信される可能性があるかどうかを明らかにしません。関係情報はプロトコル交換でそのポリシーをより明示的にします。

標準は依然として正しい設定と展開に依存します。ネットワークはロールを正確に割り当てる必要があります。複雑な関係は注意を必要とします。部分的な採用は保護を制限します。レガシールートと機器は残ります。プロトコル機能だけでは監視と運用調整の必要性を排除できません。

価値は、両側が期待を比較できることです。一方的なローカルラベルは即時のフィードバックなしで誤っている可能性があります。ネゴシエートされたロールは、両端が不一致の場合にセッション確立を失敗させるか、パスにマークを付けることができます。Only to Customer 属性は、別のプロバイダーやピアに渡るべきでないルートを特定するのに役立ちます。

繰り返しますが、これは後のガイダンスです。AS4788 や AS3549 が2015年に2022年の標準を使用しなかったと言うのは歴史的に不正確です。

代わりに、インシデントはテストケースを提供します：

ピアから学習したルートは、検出可能なポリシー違反なしに上流にエクスポートできますか？
上流は、顧客のパスに期待される顧客関係外のルートが含まれていることを特定できますか？
どちらかの側がグローバル伝搬の前にルートを停止できますか？
証拠はポリシー例外と偶発的なリークを区別しますか？

現代のロール認識メカニズムは、クリーンなトポロジに一致する合成例だけでなく、再構築された AS4788 のようなルートセットに対して評価されるべきです。

監視はルートを意図と比較する必要があり、可用性だけでなく

可用性監視は、ユーザーが到達可能性を失い始めた後に害を検出します。ルート監視はコントロールプレーンの異常をより早期に特定できます。

2015年の公開記録はいくつかの形態の観測によって保存されました：

BGPMon は更新ストリームを処理し、広告バーストを特定しました。
RouteViews と RIPE RIS は生の BGP アーカイブを保持しました。
ThousandEyes はルートとネットワーク測定を組み合わせました。
RIPE Atlas はアクティブなエンドツーエンド測定を提供しました。
独立したアナリストはパス、プレフィックス数、タイミングを比較しました。[2][3][4][5][6]

これらのシステムは異なるスライスを見ました。その多様性は強みです。単一のプロバイダーの内部ビューは、ルートが他の場所でどのように見えるかを見逃す可能性があります。アクティブプローブはパケット損失を見ることができますが、それを引き起こしたポリシーは見えません。ルートコレクターは AS パスを見ることができますが、すべてのトラフィックパスやプライベートセッションを見ることはできません。

現代の検出システムは、トポロジ、AS 関係、ルート履歴、異常な伝搬を使用してルートリークを探すことができます。Cloudflare はパブリックルートリーク検出を異常なパスを表面化する方法として説明しており、RIPE Atlas のドキュメントは分散プローブからの再現可能な測定をサポートしています。[19][20]

検出はアクションに結び付けられるべきです。

「ルート数が増加した」と言うアラートは、誰もしきい値を所有しておらず、ルートを抑制できない場合に弱いです。有用なインシデントパスは以下を定義します：

期待される関係とルートセット。
異常条件。
信頼度と偽陽性処理。
隔離を許可されたオペレーター。
安全な封じ込めアクション。
外部確認。
証拠保持。
イベント後レビュー。

最初の対応は必ずしもセッション全体をドロップする必要はありません。プロバイダーは優先度を下げ、予期しないルートを隔離し、最後の既知の正常な受け入れセットを保持し、または顧客コーン外のパスのみを拒否できます。適切なアクションはルーターの能力と顧客の設計に依存します。

監視はまた、予防と検出を区別するべきです。グローバル伝搬後にルートリークアラートを公開することは貴重な公的証拠です。それはプロバイダーが伝搬前の制御を持っていたことを証明するものではありません。説明責任レポートは、どの段階がイベントを検出し、どの段階がそれを停止したかを述べるべきです。

安全なルートポリシー変更には現在のバイト証拠が必要

ルーティング設定は、ルーターに到達する前に、テンプレート、データベース、自動化、ポリシーコンパイラ、ベンダー固有の構文を通過することがよくあります。人間のレビューアはある表現を承認しても、デバイスは別の表現を受け取る可能性があります。

証拠連鎖は各段階で現在のバイトを結びつけるべきです：

ソースポリシーまたは変更要求。
正規化された関係とプレフィックスデータ。
生成されたルートマップまたはポリシー言語。
デバイス固有の設定。
候補設定の差分。
コミットされた設定のハッシュ。
結果として広告され受け入れられたルートセット。
外部コレクターの観測。

これは「ポリシーはレビューされた」があいまいだから重要です。どのバージョンがレビューされたのか？承認後に自動化ジョブが AS セットを展開したのか？古いレジストリスナップショットがフィルターを生成したのか？手動の緊急コマンドが通常のパイプラインをバイパスしたのか？すべてのルーターが同じ出力を受信したのか？

説明責任のある変更システムは、これらのバインディングが乖離した場合に失敗するべきです。

展開前に、コンパイルされたポリシーに代表的なルートをリプレイするべきです。AS4788 のような条件では、テストには以下を含めるべきです：

顧客発信のルート。
顧客コーンルート。
ピア学習ルート。
プロバイダー学習ルート。
大規模トランジットネットワークを含むルート。
予期しないより具体的なルート。
突然のフルテーブル規模の入力。
有効と無効の広告の混合。

テストは肯定的および否定的な動作の両方をアサートするべきです。有効な顧客ルートは通過し続ける必要があります。ピアおよびプロバイダー学習ルートは上流に向かってエスケープしてはなりません。受け入れ側のプロバイダーは、顧客の期待されるロールと矛盾するパスを独立して拒否するべきです。

展開後、ルートコレクターまたはルッキンググラスは観測可能な結果を検証するべきです。設定ハッシュだけでは、ルーターが意図されたルートのみを広告したことを証明しません。コントロールプレーンの状態、デバイスのバグ、他のポリシーとの相互作用が実際の動作を変更する可能性があります。

この現在のバイト規律はそれ自体が目的の官僚主義ではありません。それは、組織が議論されているコード、ポリシー、ルートが害を生み出したか防いだ同じオブジェクトであることを証明する方法です。

復旧は検証された修復と同じではない

公的情報源は、ルートが撤回されるか受け入れが停止され、サービスが数時間後に回復したことを示しています。それは運用上の復旧です。

修復はより難しい質問をします：同じクラスのルートが再びエスケープできるでしょうか？

信頼できる修復プログラムは、RouteViews、RIPE RIS、内部ログから代表的なインシデントセットを凍結します。各ルートの意図された関係を特定し、テスト環境でエクスポートおよびインポートの決定を再現します。

AS4788 の場合、テストは、明示的でレビューされた例外が適用されない限り、ピアまたはプロバイダーから学習したルートが AS3549 へのエクスポート用に選択できないことを検証します。AS3549 の場合、テストは、顧客が期待される顧客コーン外のパスを広告できないこと、または正当化された量を超えることができないこと（隔離なし）を検証します。

プログラムはその後、証拠を生成します：

修正前の失敗テスト。
ポリシーまたはシステム変更。
修正後の合格テスト。
デバイスおよびソフトウェアバージョン。
展開カバレッジ。
アラートおよび封じ込め演習。
外部ルート観測。
例外インベントリと有効期限。
継続的な監視の所有権。

修復はまた、劣化した条件をテストするべきです。レジストリデータが利用できない場合はどうなりますか？システムはフェイルクローズしますか、最後の既知の正常セットを使用しますか、それともすべてを受け入れますか？異常検出器がダウンしている場合はどうなりますか？オペレーターは独立した管理パスを通じてセッションを分離できますか？最大プレフィックス停止は重要な顧客ルートを保持しますか、それともすべてをドロップしますか？

公開開示はプライベートな商業条件や悪用可能な設定を露出する必要はありません。それは障害クラス、影響を受けたポリシー境界、追加された制御、テスト方法、展開カバレッジ、検証日を述べることができます。

その証拠がなければ、「フィルターを修正しました」というのは意図に関する主張です。それがあれば、顧客とピアは、オペレーターがグローバル伝搬を許可したシステムを変更したかどうかを評価できます。

説明責任は個人の非難に崩壊すべきではない

インターネットのルートリークは、しばしば1人のエンジニアが悪いコマンドを入力した話になります。ここでの公開記録はその話を確立していません。単一のアクションがイベントを引き起こしたとしても、グローバルな影響には複数のシステムと組織的な決定が必要でした。

オペレーターは設定インターフェースを設計します。変更が生成されるか手書きされるかを選択します。ピアおよびプロバイダー関係を定義します。どのテストが必須か、2番目のレビューアが必要か、ポリシーがどれだけ速く伝搬するか、ロールバックが独立しているかを決定します。

トランジットプロバイダーは、顧客の広告にどれだけの信頼を置くか、どのフィルターが経済的かつ運用上実行可能か、どの異常が封じ込めをトリガーするかを決定します。リーダーシップは、ルーティングセキュリティ業務にスタッフ、メンテナンスウィンドウ、収益トラフィックを中断する権限があるかどうかを決定します。

個人の非難はこれらの制御を曖昧にする可能性があります。また、開示を阻害する可能性があります。より良い説明責任モデルは以下を尋ねます：

ルートが離れるのを防ぐ能力を持っていたのは誰か？
それを拒否する能力を持っていたのは誰か？
その伝搬を制限する能力を持っていたのは誰か？
独立して害を検出できたのは誰か？
撤回または隔離できたのは誰か？
証拠を保持したのは誰か？
修復に資金を提供し検証する権限を持っていたのは誰か？

これらの質問は、公的情報源が証明しない意図や過失を主張せずに責任を特定できます。

また、「インターネットは分散化されている」という中に責任が溶けてしまうのを防ぎます。分散化は、単一のオペレーターがすべてのパスを制御するわけではないことを意味します。それは各オペレーターが自身の広告、セッション、伝搬決定に対する制御を欠いていることを意味するわけではありません。

顧客とピアが合理的に要求できること

ほとんどの顧客はトランジットプロバイダーのルーターを監査できません。ピアはすべてのプライベートな変更プロセスを見ることはできません。それでも、依存関係に適した証拠を要求できます。

インシデント前に、オペレーターは以下を公開できます：

正確なルーティング連絡先。
登録されたプレフィックスと自律システム。
ルートおよび AS セット。
高レベルのピアリングおよびフィルタリングポリシー。
RPKI カバレッジ。
関連するロールおよび検証メカニズムのサポート。
ステータスおよびインシデントチャネル。

インシデント中に、以下を伝達できます：

影響を受けたルートまたはセッションクラス。
広告がまだ伝搬しているかどうか。
封じ込めアクション。
既知のリージョンとサービス。
測定の不確実性。
復旧の証拠。
次の更新時間。

インシデント後に、以下を提供できます：

ソースと受け入れの境界。
ルート数の定義。
出典付きのタイムライン。
失敗した制御。
害を封じ込めた制御。
テスト可能な修復。
残りの限界。

顧客はまた、自身のエクスポージャーをテストするべきです。マルチホームは、両方のプロバイダーが同じ上流に依存している場合、独立性を保証しません。バックアップルートは存在してもローカルプリファレンスで負ける可能性があります。より具体的な広告は意図された多様性を上書きする可能性があります。トラフィックはリークされたパスを回避しても、共有トランジットプロバイダー内の輻輳に苦しむ可能性があります。

独立したルート監視、RIPE Atlas 測定、ルッキンググラスチェックはそのエクスポージャーの一部を明らかにできます。[4][5][6][20]

義務は比例的です。重要な公共サービスや金融プラットフォームは、影響の少ない個人サイトよりも深く上流の集中を理解するべきです。しかし、トランジットプロバイダーが大規模で安全でないルートセットを受け入れ広めることを完全に補償できる顧客はいません。

公開記録が証明できないこと

情報源セットは強力なネットワーク説明責任分析をサポートしますが、完全な内部ポストモーテムはサポートしません。

以下を証明できません：

正確な Telekom Malaysia のルーターまたは場所。
正確な設定コマンドまたはテンプレート。
トリガーが計画された変更、古い状態、自動化障害、または手動エラーであったかどうか。
ソフトウェアまたはハードウェアバージョン。
AS4788 と AS3549 間のプライベートな関係条件。
両側の正確なインポート、エクスポート、最大プレフィックス設定。
最初の内部アラートとオペレーター応答。
プライベートな調整メッセージ。
すべてのコレクターにわたって調整された1つのプレフィックス数。
影響を受けたユーザーまたは財務損失の完全な国勢調査。
法的責任または契約違反。
いずれかのオペレーターによって展開された耐久性のある修復。

パケットはまた、後の制御を歴史的要件に変えるべきではありません。RFC 8212は2017年、RFC 9234は2022年に公開され、現在の MANRS 実装ガイドは後の運用作業を反映しています。それらは有用な現在のテストを定義します。2015年に存在した設定や義務を証明するものではありません。[11][12][18]

同様に、現在の RIPEstat データは現在のネットワークリソースコンテキストであり、凍結された2015年のレジストリスナップショットではありません。[7]

これらの境界は結論をより信頼できるものにします。観測可能な障害は分割された制御を特定するのに十分です。欠落した内部記録はそれ自体が説明責任のギャップですが、それを発明する許可ではありません。

再利用可能な上流フィルタリング説明責任テスト

このイベントは、意味のある規模で BGP を運用するすべての顧客、トランジットプロバイダー、またはピアのための実用的なテストをサポートします。

1. 各セッションの関係を定義する。
ポリシーが異なる粒度でプロバイダー、カスタマー、ピア、ルートサーバー、例外的なロールを記録します。

2. 意図されたルートを認証された証拠に結びつける。
所有権、鮮度、出典を持つプレフィックス、起点、顧客コーン、AS セット、例外を維持します。

3. 展開前にポリシーをコンパイルする。
インポートおよびエクスポートポリシーが受け入れる具体的なルートとパスを示します。テンプレートテキストだけでなく、実際の動作をレビューします。

4. 明示的なポリシーがない場合はフェイルクローズする。
フィルターが欠落していたりデータ取得が失敗したために、eBGP ルートがグローバルな権限を獲得してはなりません。

5. 関係違反をテストする。
ピア学習およびプロバイダー学習ルートを顧客および上流セッションに対してリプレイします。無効な方向がエクスポーターとレシーバーの両方で拒否されることを検証します。

6. ボリューム制御を調整する。
通常の動作、正当な成長、緊急ケースに対して最大プレフィックスおよび異常しきい値を設定します。完全なセッションシャットダウンだけに依存するのではなく、安全な封じ込めを定義します。

7. 起点検証とパス検証を分離する。
起点権限には RPKI を使用しますが、ROV を関係有効な伝搬の証明として説明しないでください。パスおよび顧客コーン制御を追加します。

8. 外部から監視する。
独立したコレクターとアクティブ測定を使用して、観測されたルートと到達可能性を意図されたポリシーと比較します。

9. 封じ込めに所有者を割り当てる。
通常の変更ウィンドウ外でも、ルートを隔離したり、優先度を下げたり、最後の既知の正常セットを復元したり、セッションをリセットできる人を特定します。

10. 現在のバイト証拠を保持する。
承認されたポリシー、生成された設定、展開されたバイト、ルート状態、アラート、決定、外部観測を結びつけます。

11. 元のイベントクラスで修復を証明する。
再構築されたリークをセッションの両側でリプレイし、どこで停止するかを示します。1つの保存されたプレフィックスリストだけでなく、意味的なバリアントをテストします。

12. 依存ネットワークが検証できるのに十分な情報を公開する。
敏感なプライベート条件を露出せずに、制御境界、ルート数定義、修復、残りの不確実性を説明します。

このテストはルートリークが消えることを約束しません。それは予防、封じ込め、証拠の義務を、ルートにさらなる権限を与えることができるすべてのネットワークで明示的にします。

結論

2015年6月12日の Telekom Malaysia ルートリークは、ローカルルーティングポリシーがどれだけ迅速にグローバルなインフラストラクチャの害になり得るかを示しました。

AS4788 は非常に大規模なルートセットを発信しました。AS3549 はそれらを受け入れ伝搬しました。トラフィックは Level 3と Telekom Malaysia を通るパスにシフトしました。パケット損失、遅延、到達不能障害がリージョン全体に広がり、直接再ルーティングされたサービスと共有トランジットネットワーク内の輻輳にさらされたユーザーの両方に影響を与えました。独立したルートコレクターと測定プラットフォームが公開された概要を保存しました。[1][2][3][4]

このイベントは、1つのネットワークによる1つの悪い広告として責任を持って説明することはできません。エクスポートとインポートは別々の制御です。顧客は許可されたルートのみを広告する義務があります。トランジットプロバイダーは、それらのルートを受け入れ広める力に比例した義務を持ちます。ピアと下流ネットワークは追加の監視とインポート制御を持ちます。どのレイヤーも完全性を保証できませんが、各レイヤーは1つの間違いがより多くの到達範囲を獲得するのを防ぐことができます。

RPKI 起点検証は価値があり、このパスポリシー障害には不十分です。ルートレジストリは意図を公開できますが、古くなる可能性があります。最大プレフィックス制御は量を封じ込めることができますが、より小さなリークを見逃す可能性があります。後のデフォルト拒否標準と関係認識標準は制御モデルを改善しますが、2015年の違反を遡及的に証明するものではありません。耐久性のある答えは階層化されています：明示的なポリシー、認証されたルートデータ、関係チェック、調整された制限、独立した監視、迅速な封じ込め、再現可能な修復。

リスクは広告が獲得できる到達範囲に従います。説明責任は、その到達範囲を制約できた人、それを伝搬することを選択した人、そして同じ障害クラスが他の人々のトラフィックがテストになる前に停止することを証明できる人に帰属します。

Telekom Malaysia の2015年ルートリーク：上流フィルタリングとトランジット説明責任の教訓

要約