TTNet の2004年ルートリークは顧客プレフィックス管理の責任を示す

概況

事件範囲の固定:この記事は、2004年12月24日に観測された AS9121/TTNet のルーティングテーブル流出に限定して扱います。後のトルコ国内の接続障害、無関係な経路ハイジャック、または異なる自律システムを含む他の経路流出事象と統合して扱いません。
規模は文脈を示して扱う:NANOG 再構成と後続研究は、10万以上のプレフィックスに及ぶ流出を記述しています。これは当時の一部観測点で見えるグローバルルーティングテーブルの大半に相当します。件数は、収集点、観測間隔、重複処理、イベント定義によって変動します。これは普遍的な運用ログではなく、証拠としての観測です。
境界を越えた失敗:一方のコンテキストで受信した経路が、想定外の宛先へ広告されました。接続先ネットワークは各自のローカル方針に従って受け入れや再配布を行いました。結果は TTNet 単独の障害ではなく、グローバルな経路状態の分散的な変化でした。
責任は制御権に従う:AS9121 はインポート、エクスポート、経路生成、デプロイ、監視、撤回を制御しました。直接接続先は顧客プレフィックスフィルタ、AS-path 制約、最大プレフィックス上限、アラート、先行再配布制御を制御しました。さらにインポータは各自の受入と封じ込めを制御しました。
レジストリは証拠であり、執行ではない:ASN、アドレス、IRR、後の RPKI 記録は想定起点やリソース保有者を示すことができますが、ルーターポリシーを自律的に設定しません。実際に受理・転送されるかは実行中の設定とローディングされたポリシー次第です。
現代の制御は相補的:明示的 eBGP ポリシー、許可プレフィックスフィルタ、最大プレフィックス上限、経路起点検証、BGP Roles と OTC、顧客コーン検証、異常検知、事前テスト済みロールバックは、異なる失敗モードを扱います。単独の後追い対策はありません。
復旧には外部証拠が必要:ルータ設定変更やセッションリセットだけでは十分な根拠になりません。責任ある復旧は、撤回、代替経路、残存する古い経路、ピアとの調整、収束、独立観測点からの到達可能性回復を示す記録で示されます。

事件の境界は2004年12月24日

インフラ障害レビューではまず、事件を固定することが基本です。2004年12月24日、運用者は TTNet（AS9121）に関連する異常経路セットを観測しました。事件は当時 NANOG で議論され、のちに NANOG プレゼンテーションで RouteViews および RIPE コレクタの公開 BGP データを用いて再構成されました。[1][2] 後年の学術研究も、ルートリークおよびルーティング異常分析の代表例または典型ケースとしてこの事件を扱っています。[3][4][5]

公開記録は一貫して、AS9121 が本来の想定範囲を超えて非常に大きなルーティングテーブルの一部を伝播させ、他のネットワークがその告知の十分な部分を受け入れまたは再配布したため、到達可能性問題が広範囲化したという命題を支持しています。この記事はこの事実構造を分析します。

この命題を過大評価しないことが重要です。公開情報だけでは、TTNet の完全なルータ設定、すべてのルートマップ、すべての双方向合意、全ての運用メッセージ、または一つの普遍的権威タイムラインは得られません。悪意の意図も示されていません。全世界のインターネットで全ルートが受理されたわけでも、全ユーザーが同様の影響を受けたわけでもありません。

数値には特別な注意が必要です。NANOG の再構成および後続文献は、10万以上の影響プレフィックス、当時見えるテーブルの大部分に相当すると記述しています。[1][3][4] これは意味のある記述ですが、測定上の記述です。収集点は受けるセッション経路に沿ってのみ観測し、異なる収集点は異なる経路を受け取り、更新時刻の差、重複抑制、公開前にフィルタされた経路の見え方などが異なります。

したがって、妥当な編集方針は誤差を隠すことではなく、帰属の明示です。事件は2004年当時のルーティングテーブル規模としては非常に大きいものでした。正確なプレフィックス件数や継続時間は観測点と分析手法によって変動します。その変動は事件を過小評価する理由にはなりません。観測証拠と推計プロセスの透明化が必要だからです。

時系列を確認することも重要です。2004年後年に標準化された制御を、遡って適合有無の基準に使うのは、比較に留めるべきです。RFC 7908のルートリーク分類は2016年に公開されました。[12] RFC 8212の明示ポリシー既定動作は2017年に公開されました。[13] RFC 9234の BGP Roles および Only-to-Customer メカニズムは2022年に登場しました。[14] これらは制御課題の抽象化に有用ですが、2004年時点で AS9121 や隣接体が何を実装していたかを直接証明しません。

防御的な問いは「なぜ2004年のネットワークが2022年標準に従わなかったか」ではありません。より妥当なのは「顧客またはピアがどの経路を広告できるべきか、どの組織がその境界を制御し、ルート状態がいつ正常化したことをどの証拠で示せるか」です。

ルートリークは関係性ポリシーの失敗

BGP は自律システム間で到達情報を配布します。各ネットワークはローカルポリシーで経路を選択し、各隣接先へどの経路を広告するかを決定します。RFC 4271はベースプロトコル、メッセージ種別、経路属性、選択処理、撤回の挙動を定義します。[11] ただし、全セッションに対する普遍的な商業・運用関係を符号化するものではありません。

この関係情報は重要です。なぜなら、インターネット経路は自動的にすべての隣接先へ広告されるわけではないからです。顧客は通常、自身の経路と、提供トランジットとして認可された経路を広告します。事業者（provider）は、トランジット対価を受けるため顧客に対して広い到達性を広告できる場合があります。無償ピアは通常、互いの顧客経路を交換し、無関係事業者間で自由なトランジットは行いません。

「顧客」「事業者」「ピア」という用語は実態を単純化しますが、ポリシー境界を示します。あるプロバイダから学習した経路を、別のプロバイダへそのまま広告してこれをトランジット提供と錯覚するのは通常誤りです。ピアで学習した経路を別のピアや事業者へ再広告してはいけません。顧客のフルテーブルを顧客起点の許可起点として扱うのも誤りです。

RFC 7908は、後に「本来の意図を超えて目的外に伝播する経路」をルートリークとして定義し、通常は対関係ポリシー違反を伴うとしています。[12] この定義は意図推定より観測される伝播を重視する点で有用です。問題の本質は誤った経路が誤った境界を越えたことです。

TTNet 事件は、当時のコンテキストでは AS9121 が本来の意図ではない大量経路を広告したという意味で、ルーティングテーブル流出として語られます。必要なのは単一の内部トポロジを特定することではありません。トリガーが経路マップ、再配布、ポリシー生成、セッション分類、あるいは他の仕組みに起因したかを問わず、外部公開の観測では、送出セットが限定された顧客/ピア役割と整合しないことが明確です。

次に、受信側は自律的な判断を行います。直接隣接は経路を受理しました。一部ではパス属性や商用優先、経路長によりそれが選好されました。別の一部は最大プレフィックス上限で拒否した、あるいは別経路を選択しました。したがって到達影響は、複数ポリシーの連鎖で生じた結果です。

分散的因果は、責任の所在が消えることを意味しません。流出元は広告内容を統制し、直接隣接はその関係下で受入を統制し、先行再配布者は再転送を統制します。各責務は異なるものの、いずれも具体的です。

BGP 更新証拠は普遍的な転送ログではない

公開ルート収集基盤があってこそ、履歴的な説明可能性が成立します。RouteViews は参加ピアから BGP 更新と RIB を保存します。2004年12月の更新アーカイブは、研究者が TTNet 事件周辺の変化を再構成するためのデータを保持しています。[9] RIPE の Routing Information Service は別の分散測定面を提供し、収集器が観測可能な範囲を明示しています。[10]

更新レコードは、あるセッションである告知あるいは撤回が収集器に到達したことを示します。プレフィックス、AS path、起点、属性、時刻を保持できます。観測を比較することで、異常経路がいつ現れたか、どの程度広がったか、撤回や置換がいつ入ったかを推定できます。

この証拠は強力ですが、限界があります。

第一に、観測は部分的です。経路は収集器に供給しないネットワークへ到達している可能性があります。別の経路は、公開観測点に到る前にフィルタされる可能性があります。ある収集ピアは学習した全経路ではなく最良経路のみをエクスポートすることがあります。したがって公的記録は不完全になります。

第二に、制御面の可視化は転送面そのものと一致しません。ルータは更新を受けてもインストールしない場合があります。ルーティングテーブルに入っても転送テーブルに反映しない場合があります。トラフィックが経路を通っても、経路途中で輻輳やブラックホールに遭遇することもあります。逆に、セッションキャッシュと経路多様性があれば、制御面が不安定な間でも一部サービスは到達可能なままです。

第三に、タイムスタンプは観測時刻です。あるアーカイブの最初の更新が世界初の不正通知を意味しません。ある収集点の最後の撤回が全域での古い状態解消時点を意味しません。収束は分散的です。

第四に、件数は定義に依存します。解析ではユニークリスト、更新メッセージ数、経路数、起点数、経路変更数のどれを数えるかを決める必要があります。インシデント区間の設定と重複排除の方針が異なれば、結果も異なります。

よって、信頼できる記事は「インターネット全体が正確に X 分間停止した」と断定しません。より正確な主張は、AS9121 が異常事態を生成し、異常が広域に伝播し、公開測定で制御面が変化し、到達可能性が実害として損なわれたというものです。

証拠のギャップは、完全な事故記録に必要な要素を明示します。公開 BGP データは、発生ネットワークの設定差分、ポリシー生成ログ、導入記録、警告タイムライン、セッション状態、撤回コマンド、NOC チケット、ピア間コミュニケーションと組み合わせて用いるべきです。直接の隣接は、受理した経路、適用フィルタ、最大プレフィックスイベント、セッションを維持したか再起動したかの理由を保持する必要があります。

これらの非公開記録がない場合、外部調査では影響再現は可能でも、内部操作のすべてを帰属できません。これは事実上の根拠欠落であり、推測で埋めるべきではありません。

ハイジャックよりリークの方が精度が高い

公開討論では「ハイジャック」と呼ばれることが多いですが、これは通常、トラフィックが誤ったネットワークへ向けられた状況を表します。この語は意図が明確な事件で有用な場合もありますが、証拠が示さない意図まで含意する危険があります。

TTNet 記録は、一次的に「ルートリーク」が妥当です。経路は想定される関係境界を越えており、重大なポリシーまたは設定失敗に整合します。TTNet があらゆる影響先を意図的に偽装し、盗聴目的でトラフィックを誘導したとは断定しません。

ここは技術上の区別です。起点起源ハイジャックは、あるプレフィックスをその AS が起点とする権限がない場合に起きます。一方、関係ポリシー起因リークでは、起点は正当でも、許容されない関係経路で経路が流通します。両者が併存する事件や、公開記録が曖昧な事件も存在します。

経路起点検証は第一段階です。あるプレフィックスの起点 ASN が ROA で認可されているかを判定します。RFC 6811は、ルータが RPKI データでルートを分類する方法を定義します。[15] ただしすべての顧客・事業者関係は符号化できず、正当な起点でも不適切な谷（valley）を通過した経路を排除できません。

関係認識メカニズムは別の問いに答えます。経路がどこで学習されたかを踏まえ、このセッションで再広告すべきか受け入れるべきかを判断します。RFC 9234は、BGP Roles と Only-to-Customer 属性を経路流出防止・検知のためのクラスに体系化しました。[14] 顧客コーンや ASPA 的アプローチは、別軸からパス権限を扱います。

全てを「ハイジャック」と呼ぶと対策が不完全になります。運用者は ROA を設定し、リーク経路が起点的には有効であることを確認して「解決」と結論づけがちです。これは誤りです。起点認可、関係認可、量の封じ込め、変更安全性は独立した制御群です。

意図は法的・懲戒的な判断に重要ですが、意図がなくても運用上の封じ込めは成立します。設定ミス、制御破損、悪意ある行為、契約理解不足のいずれであっても、顧客がグローバルテーブルの大半を出す場合は早期警戒すべきです。

この証拠優先の用語は、ネットワークが何を主張・受領・伝播したかを記述します。推論した意図を事実化しません。

顧客プレフィックス認可は実行可能であるべき

最も直接的な制御教訓は、顧客の想定通知セットを実行可能なポリシーとして定義することです。

顧客が通知を許可されたプレフィックス群を持つ場合、提供者はそれを許可するインポートフィルタを作成し、他は拒否できます。真実源は契約記録、ルーティングレジストリ、RPKI 起点認証、顧客からの直接宣言、観測履歴、手動例外などを含む場合があります。いずれにも限界はありますが、最終結果は明示的なルータ判断でなければなりません。

許可リスト（allowlist）は禁止リスト（denylist）よりも安全です。禁止リストはデフォルト空間や予約空間など明らかに不可能な経路を列挙しますが、列挙外の広大な領域を許可してしまいがちです。許可リストは、顧客が起点または経由可能な経路のみを基準化し、拡張は制御された変更として扱います。

生成されたフィルタはテストが必須です。正しい見た目のレジストリでも、生成設定は不正確になり得ます。自動化では誤った顧客を取り込む、プレフィックスを取りこぼす、過度に広い集約を受け入れる、またはデータ未取得時に fail-open することがあります。テストでは意図資源、生成ポリシー、代表的な許可・拒否告知を比較します。

例外には所有者と有効期限が必要です。顧客が移行時に新規プレフィックスを公告する、関連会社の転送を一時提供する、あるいは事故時に集約を使う場合があります。例外には承認者、証拠、影響セッション、対象プレフィックス/パス範囲、開始時刻、レビュー時刻、ロールバック条件を明示し、期限付きとする必要があります。永続化した「一時例外」はリスク移転を隠します。

TTNet 事件は、規模そのものが認可シグナルであることを示します。境界付きの経路を広告するはずのネットワークが、いきなりグローバルテーブルの大半を広告して複数の制御を同時に越えれば異常です。プレフィックス一覧が古く不完全でも、配信量の変化自体が異例でなければなりません。

顧客プレフィックス認可には相互の逆方向もあります。顧客は自分の広告内容を検証し、変更前に意図セットを固定し、生成出力を点検し、実際の送信広告がそのセットと整合するか比較すべきです。提供者も受信内容を独立して検証します。これらは冗長ではなく、共通故障を減らします。

帳票や契約、チケット、IRR は責任記録に過ぎず、境界を実装するのはルータです。実務的な検証は、未承認経路が安全な検証手順で拒否され、拒否結果が運用者双方に見えるかです。

AS-path 確認と関係性ポリシーは異なる証拠対象

プレフィックス認可は、経路が想定到達先を含むかを確認します。AS-path 確認は経路が関係上妥当かを確認します。

顧客は下位ネットワークに対し合法的にトランジットを提供する場合があります。その場合、顧客の ASN 起点だけで検証するプレフィックス限定フィルタは、顧客の正当なサービスを誤って拒否しうるため不十分です。提供者は顧客コーンなど、どの起点とパスを顧客が持てるかの表現を持つ必要があります。

経路の表現は難しいです。AS 関係は変化します。合併、再販、地域別契約、ルートサーバ、コンフェデレーション、複雑なセッションは単純分類に耐えません。公開の関係推定は有用ですが完全ではありません。非公開の商用記録は精密でも運用に即時反映しにくい場合があります。

この困難を理由に「全て許容」することはできません。信頼度を区分し、未確定は制御し、偏差を監視すべきです。提供者は顧客宣言、レジストリ証拠、観測された安定経路、RPKI 起点データ、手動レビューを組み合わせることができます。自 AS が想定外の位置にある場合、予約 AS、異常に短い/長いパス、認可されない起点を拒否できます。

RFC 9234の BGP Roles は二者間 BGP スピーカでのセッション関係を明示し、provider/customer/peer/route server/route-server client の役割に応じた伝播規則を定義します。[14] OTC 属性は、経路が原則として顧客方向のみへ送信されることを示せます。この仕組みは対象関係ルール違反の流出の検知・防止に寄与します。

ただし BGP Roles はすべての商用関係を完全表現するモデルではありません。RFC 自体も複雑関係を認め、役割設定誤りが伝播に影響することを警告します。ここで求めるのは「機能を一つ有効化すること」ではなく、「関係を機械可読化し、可能なら隣接と整合確認し、生成結果をテストし、運用中経路を継続監視すること」です。

2004年の事案では、これらはあくまで後追い比較です。より根源的な責任判断は、関係ポリシーが重要だった一方、実装制御の多くが異常な送出・受入連鎖を止めるまで十分に機能していなかったという点です。

最大プレフィックス上限は量的サーキットブレーカー

最大プレフィックス上限は、1セッションあたりの受信経路数に上限を設けます。上限を超えるとルータは警告、追加拒否、セッション停止などを実装に応じて行えます。

10万を超える想定外プレフィックスの流出に対して、適切な上限は明確な抑制層になります。平常時は小規模な顧客が上限近くまで拡張することは想定されないためです。

この制御は概念は単純ですが運用は精密です。

上限が低すぎると、正規の拡張や経路集約分割でもセッションがリセットされ、停止を招きます。高すぎると装飾化します。設定ミスを修正せず自動再起動すれば振動が発生し得ます。警告のみでは責任者が未設定だとノイズ化します。

閾値は想定経路量、増加率、運用変動、障害コストを基に設計します。警告レベルと強制レベルを分けることが必要です。例外は文書化し期間を限定します。対応では、セッションを継続するか、許可サブセットのみ受け付けるか、顧客と協調して修正するかを即時判断します。

ただし最大プレフィックスは認可を証明しません。顧客は閾値下で有害な少数経路を流出できるためです。1つの重要な more-specific 経路や1本のデフォルト、または別組織の妥当サイズ群を告知するだけでも影響は大きい。したがって上限はブレーカーであり、プレフィックス/パス検証代替ではありません。

事件は独立制御の価値を示しました。許可リストが失敗した場合でも、量的上限が大規模流出を抑える可能性があります。両方失敗した場合でも、監視差分で顧客ベースラインと比較し、さらに外部ルートアラートとピア報告で対応を起動できます。

責任ある運用者は、どの外部セッションが警告/強制上限を持つか、上限見直しの頻度、例外セッション、発動頻度、そして回復時の可用性とセキュリティを両立するテスト有効性を報告できることが求められます。

明示的な受信・送信ポリシーで曖昧な既定を減らす

RFC 8212は、明示的ポリシーがない場合の eBGP 挙動を「受信・送信しない」を既定としました。[13] これは、ポリシー欠落で広域伝播が起きる再発事案に対する一例です。

この原則はベンダ既定を越えます。すべての外部セッションは明示的な受信・送信意図を持つべきです。運用者は、ルートマップ欠落、生成失敗、空オブジェクト参照、保守中の設定分離時に何が起きるかを事前に知る必要があります。

可用性の圧力下では、fail-open は魅力的に見えます。レジストリ取得不可時に全受入を維持するとセッション維持できる可能性があるからです。生成エンジンエラー時に前状態を保存すると、過去設定維持の事故は避けられるように見えます。逆に全拒否はサービス停止を招きます。普遍的な正解はありません。

責任ある運用は、意図的かつテストされた失敗モード選択です。前回正常設定を維持する、急増のみを遮断する、手動承認を必須にする、別経路へフェイルオーバーする等の選択肢があります。事故時に「条件がないこと」が静かに「permit all」へ変わる状態を放置してはなりません。

送信ポリシーも同等の注意が必要です。あるネットワークは顧客入力の検証ができても、提供者/ピア経路を別関係で誤広告する可能性があります。誤ったコミュニティ付与、no-export を欠く、逆方向適用などの誤設定があります。生成後の送信経路は、関係意図と比較してから投入すべきです。

TTNet 事件はポリシー設計の実用試験として有効です。代表的なフルテーブル、あるいは異常な顧客通知をラボセッションへ注入し、顧客側送信制御、提供者側受信制御、最大プレフィックス抑制、監視が異常経路残存を検知するか確認します。

この検証は挙動そのものです。「顧客経路をフィルタする」との文書だけでは、実際の生成設定が該当障害を拒否したことの証拠になりません。

RPKI は起点証拠を改善するが全リークを符号化しない

RPKI はリソース保有者が暗号的検証可能な Route Origin Authorization を作成する仕組みです。ルータは、BGP 経路のプレフィックスと起点 ASN を検証済み ROA と照合し、Valid/Invalid/NotFound を分類します。RFC 6811が起点検証の前提を定義しています。[15]

これは認証されていない起点主張よりは有意な改善です。流出した経路の起点 ASN が保有者の認可外なら、ローカルポリシーで拒否できます。

ただし、関係ポリシー起因のリークでは起点は正当なことがあります。顧客がプロバイダ A から有効なルートを受け取り、別のプロバイダ B へ同じ起点のまま流すと、RPKI は有効と判定する可能性がありますが、関係境界は破られています。RPKI 起点検証単体では経路の谷問題を表現しません。

TTNet の文脈でこの点は重要です。公開要約は、影響ルートの起点とパス構造のすべてが同じではないと指摘します。全告知を RPKI で遮断できたと断言しないでください。2004年時点では現代的な認可も存在しないため、実データとの照合テストが必要です。

NIST SP 800-189はレイヤードな境界保護として RPKI 起点検証とプレフィックスフィルタを含めることを推奨します。[18] さらに広い意味で、起点セキュリティ、経路ポリシー、偽装、DDoS 対応、運用監視は異なる問題であり、複数機構が必要であると示します。

RPKI は運用上の責任も生みます。検証済みキャッシュの冗長化、鮮度監視、リポジトリ障害時の安全動作、Invalid/NotFound の運用方針、例外ガバナンス、実際の適用メトリクスが必要です。ROA を作成しただけでは、到達性に影響する運用ルールに反映されません。

ここにも Lu Heng の原則が見えます。リソースレコードは台帳であり、権限の証拠と説明可能性を提供します。だがルータを直接命じる命令ではありません。実行されるポリシーが到達性へ影響します。

監視は運用経路を意図経路と比較するべき

TTNet 流出は経路状態が劇的に変化したため可視化できました。成熟した監視はその変化を複数次元で検知します。

量監視は、セッションごとの広告、撤回、維持経路数を追跡します。境界付きベースラインからグローバル規模に跳ねる兆候は重大イベントです。

起点監視は、想定プレフィックスが起点 ASN を変更したか、または顧客が権限外アドレス空間を起点送出したかを検知します。RPKI やレジストリで比較可能です。

経路監視は、顧客・事業者・ピアの関係が想定外の順序になっていないかを確認します。谷的な経路伝播、ループ、急なパス短縮、事業者 ASN の異常位置を検知します。

詳細度監視は、意図外の more-specific ルート出現を確認します。少数でも全体件数の閾値以下なら影響が小さいとは限らず、トラフィック吸収が増える場合があります。

地理・位相監視は複数収集点を比較します。一地域のみの経路はローカル運用上の可能性があり、複数独立上流へ広がれば広域伝播を示します。

変更連関では、経路異常をデプロイ、保守ウィンドウ、設定コミット、ロジックジョブと接続します。グローバルなスパイクが政策変更直後数秒後なら、無関係なシステムを探索する前に原因候補を即時識別すべきです。

監視は実行可能な証拠を出す必要があります。アラートには責任者、重要度、影響セッション、観測差分、想定ベースライン、推奨封じ込め、エスカレーション経路を含めます。発生経路サンプルも保存しなければなりません。

通知だけでは封じ込めになりません。リークを検知しても、セッション再設定の権限、復旧ルートマップ、障害拡大回避やロールバック判断に時間を費やせば、致命的遅延が起こります。演習で実行チェーンを検証すべきです。

外部監視は独立層です。顧客や重要サービス運用者は自社プレフィックスと起点を外部観測点で観察できます。提供者は RouteViews、RIPE RIS、商用フィードと比較することで、内部テレメトリの欠陥検知と撤回の到達反映を検証できます。

AS9121、提供者、ピア、インポータをまたがる責任

責任は制御権、証拠、義務で割り当てるべきです。

AS9121 は送出する経路セットの第一制御主体です。運用レビューではトリガー、想定ポリシー、生成設定、承認、導入経路、検知時間、収束封じ込め、撤回処理、修復テストを明示する必要があります。顧客や下流起点がテーブルを流した場合、その起点と AS9121 が受入・再送に対して持つ責任を区別すべきです。

直接の上流事業者とピアは、最初の外部封じ込め境界を統制します。AS9121 セッションへの関係付け、期待起点集合、パス集合、最大プレフィックス方針、例外、アラート、再送方針を示す必要があります。異常量を受け入れたのであれば、どの制御が欠落・無効・上書きされたかを説明すべきです。

更なる中継ネットワークとピアはその後の境界を統制します。責任は、何を誰から学習し、その関係に対しどのポリシーが妥当だったかで決まります。小規模顧客から大規模テーブルを受け取るプロバイダと、プロバイダから全量を受け取る顧客では責任の構図が異なります。

収集器運用者は、測定とルート伝播を制御しません。観測点、時刻、保持期間、方法論的限界を明示する義務があります。研究者はライセンスとプライバシーの範囲で再現可能な変換を提示すべきです。

重要サービス運用者は、復元力の境界を担います。複線接続、事業者多様性、外部経路監視、補助通信、フェイルオーバー設計で影響を減らせます。だがこれらの運用者は流出ソースを制御していないため、責任を中継ポリシー境界に転嫁すべきではありません。

エンドユーザーは BGP 制御にほぼ関与できません。速度劣化、ブラックホール、サービス停止を経験するのが主です。報告は影響検知に役立つ一方、AS path の正当性評価や撤回操作は行えません。

この階層モデルは二つの誤りを避けます。第一に、起点に全責任を負わせ、提供者を受動経路とみなすこと。第二に、責任を拡散させすぎて実制御者が不在になること。各ネットワークは自身が運用した境界を説明すべきです。

復旧は経路状態遷移であり、宣言ではない

トリガー停止は必要だが、十分ではありません。BGP は分散プロトコルであり経路状態は時間をかけて収束します。

起点ネットワークはポリシー修正、経路撤回、セッションリセット、発信源切断を行えます。直接隣接は撤回またはセッション喪失を処理し、代替を選択し、変化を再配信します。その隣接も同様に繰り返します。フラップ抑制、古い経路処理、セッション状態、タイマー、ローカルポリシーは時系列を左右します。

「設定を修正した」という宣言は内部処置の事実です。それだけで経路全体が健全化したことを示しません。

責任ある復旧記録は、少なくとも以下に答える必要があります。

AS9121 が異常経路セットの送出をいつ停止したか
どのセッションがリセット・フィルタ・抑止され、保持されたか
直接隣接が撤回または代替受理をいつ観測したか
各独立収集点で異常プレフィックスが時間経過とともにいくつ残存したか
正規経路が復帰し、データプレーンで実利用可能だったか
主経路収束後も古い経路や二次リークが残存したか
重要サービスが複数地域と複数アクセス網でいつ回復したか
どのピアが自動収束ではなく手動調整を必要としたか

ルートアーカイブはこれらの一部に回答できます。非公開のセッションログと経路スナップショットはより多くを明らかにできます。データプレーン計測は、経路正規化と実ユーザー到達性の乖離を分離します。

復旧時の不確実性も記録に残す必要があります。10:00で収束した収集点と10:07で収束した収集点がある場合、単一の世界同時復旧時刻を創作してはいけません。収束区間と観測点を明示します。

最終ステップは安全な再現です。実験環境で失敗クラスを再現し、代表顧客が異常に大きい未承認経路セットを送出します。テストは、どの層が拒否したか、どのアラートが出たか、誰が対応したか、証拠がどのように保持されたかを確認すべきです。

この再現がなければ、ポリシー変更は約束のままに留まります。

近代的な制御は層状である

単一制御で全ルートリークを解決することはありません。各層は独立して失敗し得る設計が必要です。

明示的セッションポリシー:受信・送信方針を明示化し、ポリシー欠落・失敗時の安全挙動を設計します。RFC 8212は有効な既定方向性を示します。[13]

許可プレフィックスフィルタ:直接顧客は、起点発信または中継を許可されたプレフィックスに限定し、維持される証拠にもとづき例外を管理します。

AS-path および顧客コーン制約:起点の正しさだけでなく、経路が関係制約に整合するかを評価します。

最大プレフィックス上限:異常な経路量が広域流出する前に、セッション単位で警告・封じ込めを実行します。

RPKI 経路起点検証:Invalid、NotFound、キャッシュ障害、例外運用を扱う運用方針の下で、検証済み起点情報を適用します。[15]

BGP Roles と OTC:適用可能かつ事前合意が成立した場合、相互確認の関係と Only-to-Customer 遷移で関係期待を符号化・執行します。[14]

生成ポリシーテスト:意図資源、生成設定、シミュレーション経路のデプロイ前比較を実施します。

変更安全性:高リスクのルーティング変更では段階展開、レビュー、カナリア、停止条件、テスト済みロールバックが必要です。

独立監視:内外部経路可視化で量・起点・経路長・詳細度の異常を検出し、直近変更へ連携します。

インシデント連携:最新連絡先、アウトオブバンドチャネル、事前承認された封じ込め手順、影響プレフィックスと撤回証拠の共有テンプレートを保持します。

復旧検証:制御面とデータ面の複数観測点で復旧を確認します。

これらの制御は測定可能でなければなりません。有用な指標には、許可リストを持つ顧客セッション率、ハード上限導入率、起点検証有効率、外部監視の採用率、最新関係分類、リーク再現テストの更新実施頻度があります。例外経過日数と古い証拠の状態も重要です。

MANRS は、フィルタリング、連携、なりすまし防止、全域検証を運用責務として定義します。[17] NIST SP 800-189も同様に、単一製品でなく複数対策の集合としてルーティング安全を扱うと示します。[18] 価値は採用と検証にあり、導入だけではありません。

レジストリ証拠とランニングコードの優先性

TTNet 事件は Lu Heng の責任モデルと直結します。BGP ルーティング、ASN/IP レジストリ、ピア/トランジット関係の三位一体です。

AS レコードは AS9121 を特定します。アドレスレジストリは割当と権利者を示します。ルーティングレジストリは route オブジェクトやポリシーを公開します。RPKI は署名付きの起点認証を提供します。これらは不確実性を減らし、説明可能な証跡を作ります。

ただし、これらはパケットを転送しません。

実際に経路を受理・転送したのは、実行中のルータ設定とライブセッション状態です。運用方針がレジストリ証拠を無視、誤解、未取得した場合、記録はネットワーク制御に反映されません。

このためレジストリは台帳または記録管理システムとして理解されるべきです。正当性は記録の正確性、唯一性、セキュリティ、移転容易性、実運用可能性に依存します。実際の抑止は引き続き運用者責任です。

ランニングコード優先はガバナンス否定ではなく、ガバナンスを検証可能にします。取締役会が認可資源を要求しても、ルータでのフィルタと検証決定に反映されることが必要です。監査では IRR を確認するだけでなく、そのオブジェクトが生成ポリシーを経由してルータ設定になっているか、対立告知で拒否できるかを検証します。

現実層は二つの誤った訴えを退けます。ひとつは「分散運用だから誰も責任を持てない」という主張です。もうひとつは「中央レジストリがインターネットを正しく制御できる」という主張です。どちらも誤りです。

インターネットは、契約とセッションにより接続された独立運用システム群です。責任は正確な証拠、明確な境界、実行可能なポリシー、独立検証、検証可能な復旧で成立します。

BGP エクスポート、AS9121、プレフィックス認可、関係ポリシー、収集器、撤回をこの記事から外せば命題は破綻します。ネットワーク制御面は装飾ではなく対象そのものです。

再現可能な修復記録が備えるべき内容

現実に信頼できる TTNet 級の修復パッケージは、他の運用者や監査人が主張を再現できる具体性を持ちます。

まず最初はインシデント・タイムラインです。内部トリガー、外部初期異常、初回アラート、診断、封じ込め、撤回、部分収束、最終回復を分離し、各時刻ソースと時間基準を明示します。

次に該当セッションの想定受信/送信ポリシー、事故前設定、流出を生んだ変更または障害、修正後設定を示します。機微情報は論理を保つ範囲でマスキング可能です。

顧客の想定プレフィックスとパスのセットを固定し、参照ソース、例外一覧、生成済みフィルタを明示します。最大プレフィックスの警告閾値と強制閾値を記載します。

内部監視、直接ピア、RouteViews、RIPE RIS の代表的な BGP 更新を含めます。収集器の限界、件数算出方法も説明します。

最初の制御がなぜ失敗したかを明示します。フィルタ欠如、データ老朽、セッション役割不一致、生成失敗、ポリシー順序誤り、fail-open、未所有アラート、または他の証拠に基づく要因を示します。

封じ込め判断とピア連携を文書化します。セッション再起動が行われたなら理由を示し、選択的拒否なら一致条件を示します。

観測点別の撤回と収束グラフ、および主要宛先のデータプレーン検証を添付します。

修復責任者、期限、完了証拠、残留リスクを報告します。「手順を更新した」は不十分です。

最後に、制御済み再現を含めます。フルテーブルまたは異常な顧客送信が複数独立層で拒否され、所有者主導のアラートが運用ピアへ自動拡散せず抑制可能であることを示します。

このパッケージはインターネットを無事故にするわけではありませんが、運用者の制御主張を反証可能な形にします。

ガバナンスの問いは経路から立てるべき

役員、規制当局、監査人、サービス購入者は、ルータ設定を直接構成しなくても有効な質問をできます。

経営陣は、公開 BGP 公告を変更できる構成がどこか、許可リストや硬い最大上限のない顧客セッションがいくつあるか、例外承認と最終レビュー時期、最後のリーク再現演習がいつかを確認すべきです。

トランジット事業者は、関係記録の更新状態、受信・送信ポリシーの明示性、生成フィルタが失敗時にも安全に振る舞うか、異常経路が先行再配信前に抑止されるかを検証すべきです。

エンタープライズ購入者は、事業者多様性がトポロジ上独立しているか、重要プレフィックスが外部監視されているか、事業者からの障害報告に経路状態証拠が含まれるかを確認すべきです。

監査人は、ライブ設定と生成設定をサンプリングし、リソース証拠が経路決定へ流れ込むことを追跡し、否定ケースをテストすべきです。ポータル画面のスクリーンショットは実装検証になりません。

規制当局は、制御導入と結果を混同させる単一義務は避けるべきです。ROA 導入は起点証拠を改善できますが、ルートリーク対策には関係ポリシー、フィルタ、監視、復旧検証の複合運用が必要です。

インシデントのレビューは「ヒューマンエラー」で終わるべきではありません。その語では、なぜ一つの誤りで異常量の経路を送れたのか、なぜ直接隣接が受け入れたのか、なぜ封じ込めが効かず復旧時間が要したのかを説明できません。

指標は平均値ではなく網羅と例外を示すべきです。99%のフィルタ導入率を報告していても、1つの高トラフィック顧客が未制御の場合があります。リスクは平均ではなく露出境界に従います。

ガバナンスは真実性を守るための不確実性開示も含みます。経路状態を再構成できない部分、保持されなかったデータ、検証されていない対照制御を明示することが求められます。

責任の試金石は境界付き伝播と検証済み撤回

2004年12月24日の TTNet 事件は、関係が曖昧、フィルタが過大、レコードが運用ポリシーと接続していないネットワークでも通底する制御課題を浮き彫りにしました。

AS9121 は異例の経路セットを送出しました。他の自律システムが十分量を受け入れ再配布したことで、局所的なポリシー失敗は分散的な到達障害へ拡大しました。公開ルート収集は一部の制御面記録を保存しました。後の分析は、この事件をリーク検知のベンチマークとして有用にしました。

公開証拠は悪意推定、単一の厳密なプレフィックス件数、全意思決定の完全再現を正当化しません。これらの限界は見える形で残すべきです。

責任は層的です。送出側はルート生成と公告を制御しました。直接の提供者・ピアは第一の受入境界を制御しました。後続ネットワークは先行再配布を制御しました。監視運用は証拠品質を制御しました。サービス運用者は回復力を制御しました。エンドユーザーは影響を負担し、ルート状態を制御しません。

現代の修復も層です。許可プレフィックスフィルタ、AS-path 制約、最大プレフィックス上限、明示ポリシー、RPKI 検証、BGP Roles、ポリシーテスト、独立監視、連携対応、収束検証は、失敗連鎖の異なる部分を担います。

Lu Heng の考え方は最終的な区別を示します。レジストリとルーティングポリシー記録は、誰がどの資源を起源とし、どの関係を想定するかを示す不可欠な証拠台帳です。だが実際の到達性は実行中ルータが決定します。

したがって信用できる運用者は、三点を示す必要があります。

第一に、顧客またはピアが何を広告してよいかを把握していること。

第二に、実行中システムが、その範囲を越える公告を、単一ソース障害や自動化障害が起きても拒否または封じ込めること。

第三に、誤状態が漏出した場合、迅速に撤回し、独立観測点でインターネットが認可済み経路状態へ戻ったことを示すこと。

これが、2004年 TTNet 流出が示した顧客プレフィックスフィルタリングにおける責任検証です。完璧な予防ではなく、境界固定、制御の帰属、証拠の保持、検証された復旧です。

TTNet の2004年ルートリークは顧客プレフィックスフィルタリングの責任検証を生んだ

なぜ重要か

概況