Pakistan Telecom と国内フィルターを逸脱した YouTube 経路ハイジャック

概要

• 2008年2月24日、Pakistan Telecom（AS17557）は、YouTube のアドレスブロック 208.65.152.0/22 のより詳細な部分である 208.65.153.0/24 の不正な経路をオリジネートしました。RIPE NCC の Routing Information Service のケーススタディによると、PCCW Global（AS3491）がこの経路をインターネット全体へ転送したことで、YouTube のトラフィックが世界的にパキスタンへリダイレクトされました。
• この障害は国内向けのポリシー目標を世界的な可用性インシデントに変えました。当時の報道では、このブロックはパキスタンの ISP に対して YouTube をブロックするよう命じた Pakistan Telecommunication Authority の命令に関連付けられています。ルーティングの証拠は、Pakistan Telecom によるこのブロックの BGP 実装が、上流のトランジットプロバイダがこの経路広告を受け入れて伝搬させたために国内の境界を越えたことを示しています。
• YouTube の復旧は、コンテンツプラットフォームの修復ではなく、BGP の対策に依存していました。YouTube は UTC 20:07 に同一の /24 をアナウンスし始め、その後 UTC 20:18 に 2 つの /25 のより詳細な経路をアナウンスしました。RIPE NCC は、UTC 21:01 に PCCW が AS17557 によりオリジネートされた全プレフィックスを引き下げたことを記録しており、これにより 208.65.153.0/24 のハイジャックが終了しました。
• このインシデントは単なる有名なミスではなく、経路セキュリティのアカウンタビリティ（責任）に関する事例です。Pakistan Telecom は偽のオリジンを管理していました。PCCW は最初の主要な伝搬ゲートを管理していました。YouTube は自らのアドレス空間に対する緊急時の詳細化と監視を管理していました。他のネットワークは経路の受け入れを管理していました。政府はブロック要求を管理していました。その後登場した RPKI、経路起点検証、プレフィックスフィルタリング、MANRS といった業界メカニズムは、この教訓が無視できなくなった後の実際的な責任の在り方を示しています。

国内フィルターが世界の経路に

YouTube ハイジャックが記憶に残るのは、説明が十分にシンプルでありながら、インターネットの信頼モデルを困惑させるほどの深刻さを持つからです。ある政府が国内向けのプラットフォームブロックを望みました。国内通信事業者が、トラフィックをローカルで消滅させるための BGP 経路を生成しました。上流プロバイダがその経路をエクスポートしました。他のルーターはそのアナウンスを信じました。結果はパキスタンだけのブロックではなく、YouTube トラフィックの世界的な誤誘導でした。

RIPE NCC のRouting Information Service のケーススタディが最も明快な技術的記録です。これによると、2008年2月24日日曜日に、Pakistan Telecom（AS17557）が 208.65.153.0/24 の不正なアナウンスを開始しました。YouTube（AS36561）は、インシデントの前、最中、後を通じて 208.65.152.0/22 をアナウンスしていました。208.65.153.0/24 はこの /22 内のより詳細なプレフィックスであるため、両方の経路を受け取ったルーターは、/24 内のアドレスに対して、より詳細な経路を優先します。RIPE によれば、PCCW Global（AS3491）が Pakistan Telecom のアナウンスをインターネットの他の部分に転送したため、YouTube のトラフィックが世界的にパキスタンへリダイレクトされました。

Renesys の当時のPakistan hijacks YouTube 分析も本質的に同じメカニズムを説明しています。それによると、UTC の 2 月 24 日遅くに、Pakistan Telecom が YouTube に割り当てられたネットワークのごく一部を広告し始め、このより詳細な経路がそのプロバイダによって受け入れられ伝搬されました。後に公開されたGoogle Research の出版物ページではルーティングダイナミクス分析について同様の事実を要約し、このイベントを世界規模のハイジャックに結びつけています。詳細な分析 PDFは RIPE NCC の参加を得て作成され、約 300 の観測点から観測されたこと、およびハイジャック中の経路の変化を再構築したことを記しています。

このイベントは、YouTube への侵入、YouTube サーバーの障害、あるいは各国におけるパケットフィルターを必要としませんでした。制御プレーンがインターネットに対して、Pakistan Telecom 経由の経路の方が YouTube ネットワークの一部にとってより良いパスであると伝えたのです。トラフィックは制御プレーンに従いました。ここに、このインシデントの冷酷なまでの明快さがあります。すなわち、国内向けのブロック命令が国境を越えたのは、BGP アナウンスが本来、その発生原因となったポリシー目的によって自然に制約されるものではないからです。

時系列が重要である理由は、各時点が異なる制御主体を示しているからです

最も重要なタイムラインはウェブサイトの停止時間ではありません。経路制御のタイムラインです。

RIPE NCC のケーススタディはこれらのタイムマークを提供し、UTC 21:23 までに同機関のスナップショットが不正な AS17557 のアナウンスの引き下げと、YouTube の AS36561 への経路を記録したことも記しています。MENOG のプレゼンテーションPakistan Telecom vs. YouTubeは、ネットワーク事業者向けに同じ運用上のストーリーを提示しています。すなわち、Pakistan Telecom が /24 をアナウンスし、PCCW がそれを転送し、YouTube がオフエア状態となり、YouTube がより詳細な経路をアナウンスすることで事態を修復した、というものです。

このタイムラインにはガバナンスの教訓があります。18:47 時点では、実務的な制御は Pakistan Telecom にありました。つまり、自らが保持していないアドレスブロックをオリジネートせず、国内向けのブラックホールをトランジットにエクスポートしない、ということです。そのすぐ後、実務的な制御は PCCW にありました。すなわち、顧客がオリジネートを許可されていない顧客経路を受け入れて伝搬しない、ということです。20:07 と 20:18 では、制御の一部は YouTube に移りました。すなわち、経路起点を監視し、緊急のより詳細な経路をアナウンスし、上流と調整することで、自らの到達性を守る、ということです。21:01 には、上流による引き下げが中心的な経路漏洩を終了させました。

このような責任の割り当ては、「BGP が失敗した」と言うよりも有益です。BGP は、その当時展開されていた信頼モデルが許容する通りに動作しました。事業者は、ローカルなブロックをローカルにとどめておくために必要な検証を実施するか、あるいは実施しなかったのです。

政府の命令はグローバルな伝搬を説明しない

政治的背景は必要ですが、それだけで十分ではありません。当時の報道は、経路ハイジャックを Pakistan Telecommunication Authority のブロック命令と結びつけました。CBS Newsは、同局が反イスラム的な動画を理由にインターネットサービスプロバイダに対し YouTube へのアクセスをブロックするよう命令し、Pakistan Telecom がその経路を PCCW に公開する前に、リクエストをローカルのブラックホールに向ける経路を確立したと報じました。Computerworldは、パキスタンのネットワークが一連の事象の発生源であるとする YouTube の声明を報じ、パキスタンの ISP に対する PTA の命令について説明しました。ABC News Australiaはその後、パキスタンが YouTube の禁止を解除し、自らの行動によって引き起こされた世界的な停止は意図的なものではなかったと述べたと報じました。

これらの説明は、政策から運用への連鎖を示しています。国家の規制当局または政府機関が、国内ユーザー向けにサイトをブロックしようとしました。ネットワーク事業者はそのブロックを実装しなければなりませんでした。事業者は技術的メカニズムを選択しました。そのメカニズムが漏洩したのです。この区別は重要です。国家は検閲を命じることができ、その命令は人権および公共政策上の結果を伴います。しかし、世界的な停止は、ネットワークエンジニアと上流プロバイダが制約できたはずのルーティング上の選択を必要としたのです。

したがって、実務上の制御に関する問いは、パキスタンが国内で YouTube をブロックする権限を持っていたかどうかよりも、さらに明確なものとなります。それは以下の通りです。

• ブロック命令は手法を指定していたのか、それとも実装を事業者に委ねていたのか？
• Pakistan Telecom は、上流のトランジットにエクスポートされない、ローカルのみの経路ブラックホールを持っていたか？
• Pakistan Telecom の境界における経路フィルターは、許可されていないプレフィックスがネットワークから出ていくのを防いでいたか？
• PCCW は、顧客発のアナウンスに対してプレフィックスフィルターを維持していたか？
• YouTube は、迅速な経路起点アラートとトランジットプロバイダへのエスカレーションパスを受け取っていたか？
• 他のグローバルネットワークは、経路起点を検証していたのか、それともトランジットパスが供給するものを単純に受け入れていたのか？

本稿でレビューした公開記録には、内部の PTCL 変更チケット、PTA の指示文書、PCCW の 2008 年当時の顧客フィルター設定、あるいは YouTube のインシデントルームログは含まれていません。しかし、経路の証拠は含まれています。経路の証拠は、ブロックを国内にとどめるためにどこで責任が行使されるべきだったかを示しています。

検閲の制御には技術的な封じ込めが必要

この経路ハイジャックは、法的・人権的な問題に踏み込む以前に、検閲とブロックの工学的な側面についても警告を発しています。規制当局は国内的な視点でコンテンツの目標を述べることができますが、ネットワークはその目標を、自動的に地理的境界を理解するわけではない技術システムを通じて実装します。DNS フィルタリング、HTTP プロキシフィルタリング、IP アクセス制御リスト、ディープパケットインスペクション、BGP ブラックホーリングには、それぞれ異なる障害モードがあります。あるものはローカルで失敗し、あるものはプロバイダ内部で巻き添え被害を生み、あるものは隣接ネットワークに漏洩する可能性があります。他者のプレフィックスに対する BGP ブラックホーリングは、最も危険な選択肢の一つです。なぜなら、経路アナウンス自体が到達可能性の権限に関する主張だからです。

Wired の当時の分析Pakistan's accidental YouTube re-routing exposes trust flaw in netは、このインシデントをインターネットの信頼性の欠陥として位置づけました。あるネットワークからの経路アナウンスが、たとえそれが主要サイトのトラフィックをリダイレクトするものであっても、他のネットワークによって受け入れられ、拡散され得るというものです。これは、ルーティングの教訓であると同時に、公共政策の教訓でもあります。グローバルに意味のある制御を用いて実装された国内ブロックは、国内ブロックであることをやめる可能性があるのです。それは、他のネットワークに対するエクスポートされた命令となるのです。

したがって、封じ込めは、ネットワークレベルのブロック命令にとって前提条件であるべきです。政府が国内のネットワークに対して宛先のブロックを要求する場合、事業者は、ブロック経路、フィルター、またはポリシーが上流トランジットやピアにエクスポートされ得ないことを示せるべきです。経路ベースのブラックホールであれば、それはローカルのみのルーティングポリシー、関連するすべての境界で尊重される非エクスポートコミュニティ、明示的な出力フィルター、経路ポリシーテスト、および経路が意図された境界を越えて見えないことを確認する監視を意味します。DNS ブロッキングであれば、再帰的リゾルバが国内の顧客だけに使用されているかどうか、代替リゾルバが異なる効果を生み出すかどうかを把握することを意味します。HTTP またはアプリケーションレイヤーの制御であれば、その手法が共有ホスティング、CDN アドレス、または無関係なサービスを破壊するかどうかを理解することを意味します。

これは検閲の擁護ではありません。より限定的な運用上のポイントです。すなわち、国家が課す言論に対する制御が、偶然にも国家の命令を執行するためにグローバルなインターネットを徴用できるようであってはならない、ということです。YouTube ハイジャックが示したのは、インターネットのルーティング制御プレーンが、「パキスタンがローカルブロックを望んでいる」ことと、「Pakistan Telecom が今や YouTube アドレスへの最適パスである」ことを区別しなかったということです。事業者は、フィルタリングと検証を通じてその区別を提供しなければなりませんでした。彼らはそれを十分な速さで行わなかったのです。

同じ封じ込めの原則は、他のポリシー主導のネットワーク制御にも当てはまります。裁判所命令、制裁措置、マルウェアのシンクホール、DDoS ブラックホール、緊急テイクダウン、そして不正利用への対応はすべて、意図したよりも広範な影響を持つ経路、フィルター、または DNS 変更を生み出す可能性があります。制御が強力であればあるほど、その境界の証明はより強固であるべきです。あるプロバイダ内での /32 のリモートトリガードブラックホールは注意深くスコープを定めることができますが、プレフィックスを保持していない当事者の代理としてグローバル BGP にオリジネートされる /24 は、グローバルな到達可能性の主張となります。その違いは管理上の言葉遣いではなく、他のルーターが何をするかです。

公的な説明責任の観点から、2008 年以降に欠落している文書は、ルーティングの事後分析だけではありません。それは制御選択の根拠です。なぜ BGP が使用されたのか？どのような代替案が検討されたのか？どのようなエクスポート防止テストが実行されたのか？誰が変更を承認したのか？誰がグローバルな可視性を監視したのか？誰が経路が漏洩したときにそれを引き下げる権限を持っていたのか？公開された証拠は経路パスを示していますが、その機関が将来のポリシー制御を制約する方法を学んだことを示してはいません。

最長一致プレフィックス優先が小さな経路を大きな障害に変えた

技術的な根本原因は通常の BGP の動作にあります。BGP は自律システム間で到達可能性情報を配布します。RFC 4271は BGP-4 を自律システム間ルーティングプロトコルとして説明し、経路を宛先プレフィックスとパス属性の単位として定義しています。BGP 自体は道徳的なシステムではありません。それは、あるプレフィックスが国家の命令に従うため、トラフィックを盗むため、障害を修復するため、または誤りによってアナウンスされているのかどうかを知りません。それはポリシーによって経路を選択し、フォワーディングは選択された経路に従います。

YouTube のケースはまた、どの単一のポリシーノブよりも深いフォワーディングルール、すなわち最長一致プレフィックスに依存しています。YouTube のより広範なアナウンス 208.65.152.0/22 はアドレス範囲をカバーしていました。Pakistan Telecom の 208.65.153.0/24 はより詳細でした。ルーターが、より大きなブロックへの経路と、その内部のより狭いブロックへの経路の両方を持っている場合、狭いブロック内のアドレスに対するトラフィックは、より狭い経路に従います。これが、YouTube の /22 が存在し続けていたにもかかわらず、単一の /24 が YouTube の IP アドレスへのトラフィックを引き寄せることができた理由です。

RIPE のケーススタディは、208.65.153.0/24 内のアドレスを含む、関係する YouTube の DNS IP 番号を列挙しています。また、YouTube が最初に同じ /24 を、次に 2 つの /25 プレフィックスをアナウンスした理由についても説明しています。同じ /24 は YouTube に同等の詳細度の経路を与えましたが、ルーターは依然として等しい長さの経路間で BGP パス選択を使用しました。2 つの /25 経路はさらに詳細であったため、それらを受け入れたルーターは、ハイジャックされた /24 の両方の半分に対して、YouTube へとトラフィックを向けることになります。これは緊急の詳細化戦略でした。

この戦略は効果的でしたが、クリーンではありませんでした。緊急のより詳細なアナウンスは到達可能性を回復させることができますが、一方でグローバルテーブルを拡大し、ネットワークがその長さのプレフィックスを受け入れることに依存します。RIPE のケーススタディは、2 つの /25 プレフィックスがインターネット上で /24 よりもはるかに可視性が低かったことを指摘しています。したがって、防御は部分的かつ運用上のものであり、YouTube だけがあらゆる場所のすべての悪質な経路を無効にできるという証明ではありませんでした。

このイベントは、コンテンツプラットフォームと重要なサービスにとって厳格な教訓を教えています。アドレスを所有しているだけでは十分ではありません。もしインターネットの他の部分が、他者のより詳細なアナウンスを好むように説得され得るのであれば。事業者は、経路起点監視、上流との事前調整されたエスカレーション、登録された経路オブジェクト、可能な場合は ROA、そして副作用が理解されているリハーサル済みの緊急詳細化手順を必要とします。

PCCW が伝搬ゲートだった

Pakistan Telecom が不正な経路をオリジネートしましたが、インシデントがグローバル化したのは、上流がそれを伝搬したからです。RIPE のケーススタディは、PCCW Global（AS3491）を、インターネットの残りの部分にアナウンスを転送した上流プロバイダとして名指ししています。Renesys と当時の報道も同じ点を指摘しました。これが、上流フィルタリングが説明責任の記録の中心に位置する理由です。

上流は、すべての顧客経路の背後にある政治的理由を知る必要はありません。しかし、どのプレフィックスを顧客がオリジネートすることを許可されているかを知る必要はあります。カスタマーコーンとアドレスレジストリは変更される可能性がありますが、中核となる制御は特殊なものではありません。既知の顧客権限に一致する顧客経路のみを受け入れ、他のネットワークに属するプレフィックスに対する経路アナウンスを拒否し、緊急例外のための連絡手順を維持することです。国内通信事業者は多くの顧客とプレフィックスを伝送するかもしれませんが、それこそがフィルタリングと経路オブジェクトの衛生が重要である理由です。

MANRS のネットワーク事業者向けアクションページは現在、これを業界規範として表現しています。MANRS は、グローバルルーティングシステムのセキュリティとレジリエンスを向上させることを目的としており、フィルタリング、アンチスプーフィング、調整、そしてグローバルな検証を、不正なルーティング情報を含む一般的な脅威に対する対策として位置づけています。MANRS 実装ガイドは、事業者に対して、フィルタリング、調整、グローバル検証、および関連する実践に関するチェックリストを提供しています。MANRS は 2008 年当時、現在の形では存在しておらず、メンバーシップが自動的に完璧な運用を証明するわけでもありません。これが有用なのは、YouTube の教訓を現在の期待事項に変換しているからです。すなわち、経路の受け入れはセキュリティとレジリエンスの義務である、ということです。

PCCW の役割は慎重に述べられるべきです。本稿でレビューした公開記録は、PCCW が不正な経路を伝搬し、後に AS17557 発のプレフィックスを引き下げ、RIPE のデータにおける /24 のハイジャックを停止したことを支持しています。PCCW の完全な内部説明、契約文言、フィルターインベントリは提供されていません。また、PCCW が世界的な停止を意図していたことを証明するものでもありません。説明責任は意図を必要としません。トランジットプロバイダの価値の一部は、顧客ネットワークを世界に接続することです。その価値は、プロバイダが顧客の偽の権限を世界にエクスポートするとき、リスクとなります。

Pakistan Telecom の役割は単なるタイプミスではなかった

Pakistan Telecom は、ラボに向けて迷走経路を送信する小さなホビーネットワークではありませんでした。それは、このインシデントにおいて起点 AS に関連付けられた国内通信会社でした。現在のPTCL 年次報告書は、Pakistan Telecommunication Company Limited を、パキスタンで電気通信サービスを提供するグループの持株会社として記述しています。また、AS17557 の CAIDA AS RankやAS17557 の BGP.toolsのような現在の公的なルーティング記録は、その自律システムを Pakistan Telecommunication Company Limited または Pakistan Telecom Company Limited として識別しています。これらの現在の記録は、2008 年の内部設定の証拠ではありません。それらは、関与したネットワークアイデンティティの継続的な重要性を示しています。

2008 年において、Pakistan Telecom の責任には少なくとも 4 つの層がありました。

第一に、ポリシー要求を技術的制御に変換する必要がありました。規制当局が国内ブロックを命令した場合、事業者は DNS フィルタリング、HTTP プロキシ制御、IP フィルタリング、BGP ブラックホーリング、または他の方法のいずれを使用するかを依然として選択します。一部の方法は粗雑でリスクが高いものです。ブラックホールへの経路は、それがエクスポートされ得ない場合、管理されたネットワーク内部では適切であり得ます。エクスポートされると危険になります。

第二に、エクスポートを制約する必要がありました。国内ブロッキングに使用される経路は、タグ付け、フィルタリング、スコープ設定、またはその他の方法で、ローカルネットワークから離脱したり、トランジットによって受け入れられたりすることを防ぐべきでした。内部ブラックホール経路は、広告を停止するコミュニティやルーティングポリシーをしばしば使用します。公開された経路の証拠は、必要とされたどのような制御も、そのアナウンスが PCCW およびインターネットの残りの部分に到達するのを防げなかったことを示しています。

第三に、影響を監視する必要がありました。経路が漏洩したならば、国内通信事業者は異常なインバウンドトラフィック、上流のアナウンス、経路コレクタからのアラーム、そして国際的なピアからの苦情を認識できるべきです。公開記録は、Pakistan Telecom がグローバルな結果をどれほど迅速に検知したか、またはどのような内部エスカレーションが発生したかを示していません。

第四に、修復を調整する必要がありました。RIPE のタイムラインは、YouTube における経路変更と PCCW による引き下げを示しています。記録は、実装の選択、正確なミス、封じ込め、またはその後の制御を説明する公的な PTCL のインシデント後報告書を示していません。その欠如は重要です。なぜなら、インシデント後の説明責任は、経路が消えること以上のものを必要とするからです。同じ運用パターンが再発しないという証拠を必要とするのです。

YouTube にもレジリエンスの義務があった

YouTube は不正な経路アナウンスの被害者でした。それは偽の経路のオリジネーターではありませんでした。しかし、大規模なコンテンツプラットフォームは依然として、自らのアドレス空間に対する経路セキュリティの義務を負っています。このイベントは、それらの義務の限界と必要性の両方を示しました。

YouTube の緊急対応は技術的に適切でした。すなわち、同一の /24 をアナウンスし、次に 2 つの /25 をアナウンスし、可能な場所ではグローバルネットワークが YouTube に戻る経路を好むように調整することです。RIPE のケーススタディは、これらの対抗アナウンスを記録しています。Google Research のルーティングダイナミクスページと関連する PDF は、分析記録を保存しています。YouTube は、すべてのネットワークが即座に正しい経路を好むように強制することはできず、/25 は /24 よりも可視性が低いものでした。それでも、経路起点監視と緊急ルーティング権限がなければ、復旧はおそらくより遅かったでしょう。

YouTube のようなプラットフォームに対する現代的な基準はより広範です。正確なルーティングレジストリオブジェクトを維持し、RPKI の下で自らのプレフィックスに対して ROA に署名し、グローバルな経路コレクタを監視し、不正な起点やより詳細なアナウンスについてアラートを発し、24 時間体制のネットワークエスカレーション連絡先を維持し、どの緊急詳細化が許容可能かを把握し、危機の前に主要なトランジットと調整するべきです。また、リハーサルされた例外パスがない限り、正当な緊急詳細化を不可能にする ROA の maxLength 設定を作成することも避けるべきです。

これは被害者非難ではありません。レジリエンスの会計です。プラットフォームは、他者があらゆる場所で発表するすべての悪質な経路を防ぐことはできませんが、検出時間を短縮し、検証を行うネットワークが不正な起点を拒否する可能性を高め、復旧手順をより即興的でないものにすることはできます。

RPKI は説明責任のテストを変えていただろう

最もよくある現代的な質問は、RPKI が YouTube ハイジャックを阻止できたかどうかです。注意深い答えは次の通りです。経路起点検証は、正当な保持者が正しい ROA を作成しており、ネットワークが検証を行い、不正な経路を拒否していた場合、誤った起点の /24 の伝搬を停止または低減できた可能性があります。それはすべてのルーティング問題を不可能にはしなかったでしょうし、2008 年には広く展開されていませんでした。

RFC 6480は、Resource Public Key Infrastructure を、インターネット番号資源を証明し、アドレス保持者と経路起点認可を結びつける署名付きオブジェクトを可能にするシステムとして説明しています。RFC 6811は、RPKI を使用した BGP プレフィックス起点検証を規定しています。実用的な観点では、アドレス保持者は、どの自律システムがプレフィックスをオリジネートすることを許可されているか、および、設定されている場合、許可されたアナウンスがどの程度詳細であり得るかを示す Route Origin Authorization を公開できます。検証を行うネットワークは、受信した経路を valid、invalid、または not found に分類し、ポリシーを適用できます（一般的には invalid の経路を拒否します）。

Cloudflare のRPKI の説明は、同じ概念を事業者向けの言葉で要約しています。RPKI は、BGP 経路アナウンスを正しい起点 AS と関連付けるレコードに署名します。Cloudflare のその後のRPKI 測定アップデートは、経路起点検証を用いると、経路が利用可能な RPKI レコードと照合され、不正な経路は通常拒否されることを説明しています。公的な教育サイトIs BGP Safe Yet?は、より端的に述べています。デフォルトでは BGP はセキュリティプロトコルを組み込んでいないため、各自律システムが誤った経路をフィルタリングしなければならない、と。

YouTube のケースに当てはめると、AS36561 を認可された起点とし、適切な maxLength を設定した、YouTube の 208.65.153.0/24 またはそれをカバーするブロックに対する有効な ROA があれば、Pakistan Telecom の AS17557 起点は検証を行うネットワークにとって invalid となった可能性があります。経路起点検証を実施し、invalid を拒否していた PCCW や他のトランジットプロバイダは、その経路を伝搬または選択しなかったでしょう。注意点は maxLength です。もし YouTube が /22 のみを認可し、/24 や /25 のアナウンスを許可していなかった場合、YouTube 自身の緊急時のより詳細なアナウンスが、厳格な検証の下では invalid となった可能性があります。RPKI は、認可を機械的にチェック可能にすることで説明責任を改善しますが、事業者は依然として注意深い ROA 設計と緊急時計画を必要とします。

RPKI はまた、すべての BGP 問題を解決するわけではありません。それは起点を検証するものであり、AS パス全体を検証するものではありません。それ自体では、すべての経路漏洩、トラフィックエンジニアリングのミス、または悪意のあるパス操作を防ぐことはできません。RFC 7908は、BGP 経路漏洩を別個の問題クラスとして定義し分類しています。RFC 9234は、BGP Roles と Only-to-Customer メカニズムを規定しており、ピアリング関係をより明確にすることで経路漏洩を防ぐのに役立ちます。これらのメカニズムは関連する障害に対処しますが、誤った起点のハイジャックに対する起点検証を置き換えるものではありません。

説明責任のシフトは重要です。広範な RPKI 展開以前は、上流はプレフィックスフィルタリングが困難であり、レジストリデータが不完全であると主張できました。RPKI とより優れたツールの登場後は、問いはより具体的になります。すなわち、アドレス保持者は正確な ROA を公開したか、上流は検証したか、invalid を拒否したか、ネットワークは例外を測定したか、ということです。「BGP は信頼ベースである」は、実用的な検証が存在する場合には、もはや完全な防御とはなりません。

現在のルーティングセキュリティガイダンスは教訓を運用可能にしている

NIST のSP 800-189は、回復力のあるドメイン間トラフィック交換について説明し、BGP 制御トラフィックの保護、IP アドレススプーフィングの防止、および DDoS 検出と緩和の側面に関するガイダンスを提供しています。NIST のページは、BGP が、インターネットを構成する何万もの自律ネットワーク間のパスを配布し計算するために使用される制御プロトコルであると指摘しています。RPKI、BGP 起点検証、プレフィックスフィルタリングなどの技術を推奨しています。

APNIC のルーティングの安全性の測定に関する記事は、ルーティングセキュリティを運用者の実践と、フィルタリング、アンチスプーフィング、調整、グローバル検証を含む MANRS アクションに結びつけています。これらは抽象的な理想ではありません。それらは 2008 年の失敗に直接マッピングされます。

• フィルタリングは、PCCW に対し、AS17557 が 208.65.153.0/24 をアナウンスすることを許可されているかどうかを問うものであったでしょう。
• グローバル検証は、経路起点データを可視化し、機械的にチェック可能にしたでしょう。
• 調整は、検出から引き下げまでの時間を短縮し、YouTube が正しい事業者に連絡するのを助けたでしょう。
• アドレス保持者による良好な経路オブジェクトと ROA の衛生管理は、正しい起点の検証を容易にしたでしょう。
• 内部ブラックホール制御は、国内ブロックがエクスポートされる経路になるのを防いだでしょう。

このインシデントはまた、ルーティングセキュリティが単なるネットワークエンジニアリングの問題ではない理由を示しています。国家の検閲命令が運用上のプレッシャーを生み出しました。通信事業者がそのプレッシャーを経路に変換しました。トランジットプロバイダがそれを伝搬しました。グローバルプラットフォームが復旧しなければなりませんでした。数百万人のユーザー、広告主、クリエイター、依存サイトが到達可能性の障害を経験しました。したがって、ルーティングセキュリティは公共の利益に関わる分野なのです。

測定は信頼を監査に変える

このインシデントは、今日の経路セキュリティ測定エコシステムが成熟する前に発生しましたが、説明責任の機能は同じです。すなわち、偽の権限を、拒否または引き下げが可能なほど迅速に可視化することです。経路コレクタ、経路監視サービス、RIR データ、ROA、IRR オブジェクト、ルッキンググラス、検証テレメトリはすべて、他の方法では見えない制御プレーンの主張を、事業者が監査できるものに変えます。

RIPE RIS は、YouTube のイベントを再構築する上で中心的な役割を果たしました。なぜなら、複数の観測点からの経路アナウンスをキャプチャしていたからです。Google/Roma Tre の分析は、経路がどのように進展したかを調査するために数百の観測点を使用しました。この種の証拠は、インシデント中に重要であり、事後だけでなく重要です。もしプラットフォームが、自らの空間に対するより詳細なプレフィックスが予期しない AS によってオリジネートされているというアラートを受け取ったならば、顧客がウェブサイトに到達できないことを証明し終える前に、トランジットプロバイダにエスカレーションすることができます。もし上流が、RPKI の下で顧客経路が invalid になったのを確認したならば、それがグローバルパスになる前に、その経路を拒否するか、少なくともアラームを発することができます。

監査はまた、インセンティブを変えます。フィルタリングなしで顧客の経路を受け入れるプロバイダは、特にその経路が他者にトラフィックを引き寄せる場合、即座にローカルな痛みを経験しないかもしれません。公的な経路データはその振る舞いを可視化します。アドレス保持者は、どのネットワークが不正な起点を受け入れたかを確認できます。ピアは、なぜトランジットプロバイダがそれを伝搬したのかを問うことができます。顧客は、自らの上流が検証しているかどうかを問うことができます。規制当局や調達チームは、通信事業者が MANRS スタイルのフィルタリングと調整の規範に従っているかどうかを問うことができます。これらの問いは抽象的なコンプライアンスではありません。それらは、BGP の古い信頼モデルを、測定された信頼モデルに変える社会的メカニズムです。

国内通信事業者にとって、監査レイヤーは内部と外部の両方に存在すべきです。内部的には、事業者またはそのカスタマーコーンが所有していないすべての経路アナウンスは、経路ポリシーレビューをトリガーするべきであり、特にブロッキング、ブラックホーリング、または緊急対応のために生成された場合はそうです。外部的には、事業者は正確な IRR オブジェクトを公開し、自らの空間に対して ROA を維持し、顧客およびピアの経路を検証し、他のネットワークが実際に到達できる緊急連絡先を維持するべきです。経路ハイジャックは時間的制約があります。翌営業日にチェックされるメールの受信箱は、運用上の調整ではありません。

上流トランジットプロバイダにとって、監査の負担はさらに厳しいものです。各顧客に対して、期待されるプレフィックスセット、それを構築するために使用されたデータソース、RPKI の状態、例外、最終レビュー日、および変更管理パスを提示できるべきです。顧客が突然、有名なプラットフォームのプレフィックスをアナウンスした場合、デフォルトの姿勢は拒否または隔離であるべきであり、謝罪を伴うグローバルな伝搬ではありません。

説明責任マップ

このインシデントは、単一の悪質な行為者としてではなく、層状の責任として理解するのが最善です。

このマップは 2 つの誤りを避けます。第一は、イベントを Pakistan Telecom だけに帰することです。Pakistan Telecom は不正な経路をオリジネートしましたが、グローバルな障害は上流の伝搬と、他の場所における弱い検証を必要としました。第二は、責任を「インターネット」に溶解させることです。インターネットは単一の事業者ではありませんが、各自律システムは、どの経路をオリジネートし、受け入れ、検証し、エクスポートするかについて具体的な選択を持っています。

依然として不明なこと

公開記録には、完全な制度的監査に必要なすべての詳細が含まれているわけではありません。

そこには、当初の PTA ブロック命令、内部の PTCL 実装変更、経路をエクスポートしたルーターポリシー、正確な PCCW の顧客フィルター設定、あるいは Pakistan Telecom、PCCW、YouTube、および他のトランジット事業者間のすべての私的な通信は含まれていません。それは、グローバルな停止を引き起こす意図を証明するものではありません。当時の情報源と後の要約は、グローバルな結果は意図的ではなかったと説明しています。証拠は、故意のグローバル攻撃の主張ではなく、過失または制御不能なルーティング結果を支持しています。

また、影響を受けたすべてのユーザー、国、収益損失、クリエイター損失、または依存サービスについての正確な主張を支持するものでもありません。RIPE と Google の研究は、グローバルな経路伝搬と YouTube トラフィックのリダイレクトを示しています。当時の報道は大規模な停止を説明しました。正確なユーザーエクスペリエンスは、ネットワーク、キャッシュされたコンテンツ、DNS の状態、経路の受け入れ、YouTube の対抗アナウンスのタイミングによって異なりました。

PTCL または他のネットワークの現在の公開ルーティング姿勢を 2008 年に遡って読み込むべきではありません。BGP.tools と CAIDA は、現在のネットワークアイデンティティとルーティングコンテキストにとって有用です。それらは、インシデント時にどのようなフィルター、ROA、またはルーティングポリシーが存在していたかを証明するものではありません。

最後に、RPKI は魔法のような歴史的修正として扱われるべきではありません。今日重要であるメカニズムは、2008 年には成熟した運用形態で存在していなかったか、広く展開されていませんでした。有用な問いは、2008 年の事業者が 2026 年のあらゆるツールを使用すべきだったかどうかではありません。2008 年のインシデントが将来の義務を明確にしたかどうかです。すなわち、起点認可を公開し、顧客経路を検証し、不正なアナウンスを拒否し、インシデントを迅速に調整し、ポリシーフィルターが意図された境界から漏れ出ないようにすることです。

実際的な教訓

2008 年の YouTube ハイジャックは、単なるインターネット史の逸話ではありません。それは、グローバルにルーティングされるネットワークにおける国内通信事業者の力に関する、コンパクトな説明責任モデルです。

政府はプレッシャーを生み出すことができます。国内通信事業者は経路を生み出すことができます。上流トランジットプロバイダはグローバルな到達性を生み出すことができます。他のネットワークはその主張を受け入れるか拒否することができます。プラットフォームは検出し、対抗することができます。標準化団体は検証ツールを提供できます。ユーザーは結果を単純な停止として経験しますが、責任は制御プレーン全体に分散しています。

最も重要な設計ルールは封じ込めです。国家または事業者が国内でサービスをブロックすることを決定した場合、その手法は技術的にその国内ネットワークに封じ込められ、法的にその管轄内で説明責任を負わなければなりません。他者のプレフィックスに対する BGP アナウンスは、封じ込められたコンテンツフィルターではありません。それは到達可能性の権限の主張です。その主張をエクスポートすることは、インターネットの残りの部分にそれを信じるように誘うことです。

第二のルールは検証です。顧客経路は既知の権限に対してフィルタリングされるべきです。アドレス保持者は正確な ROA を公開すべきです。トランジットネットワークは検証し、invalid を拒否すべきです。事業者は最新の経路オブジェクトと連絡先を維持すべきです。経路コレクタは継続的に監視されるべきです。インシデントレスポンダーは、どの上流が悪質な経路を迅速に引き下げられるかを知っておくべきです。

第三のルールは謙虚さです。BGP の信頼モデルはインターネットをスケーラブルにしましたが、検証なき信頼は、ローカルな運用行為がグローバルなイベントになることを許します。YouTube ハイジャックが示したのは、国家の政策決定、単一のより詳細なプレフィックス、そして一つの寛容な上流が、世界最大級のプラットフォームのトラフィックをリダイレクトできるということです。業界には現在、より優れたツールがあります。説明責任の基準は、次のローカルな制御が漏洩する前に、事業者がそれらを使用するかどうかです。