要約

  • BGPMon は、2015 年 3 月 12 日の Google サービス到達性問題を、Google 起源のプレフィックスが Hathway AS17488 に学習され、Airtel AS9498 に漏れた経路リークと結び付けた [1]。
  • 観測された時間は 08:58 UTC から 09:14 UTC までと短かったが、BGPMon は 336 個の Google IPv4 プレフィックスが影響を受けたとした [1]。
  • RFC 7908 は後に、Hathway-Airtel のリークを、ピアのプレフィックスがトランジット事業者へ伝播した経路リーク例として挙げた [2]。
  • 本稿は悪意、全利用者数、内部損害を推定しない。問うべき範囲は、顧客フィルタ、関係検証、エクスポート、アラート、保持された証拠である。

何が起きたのか

BGPMon は、この事象を Google サービスの中断として説明し、ユーザー報告と経路データから分析した。多数の Google プレフィックスへのパスが 08:58 UTC から 09:14 UTC の間に変化し、インドの Airtel AS9498 を含むようになった [1]。

重要なのは、プレフィックスの origin は Google AS15169 のままだったことである。つまり、別のネットワークが Google を装う単純な origin hijack ではない。問題はパスの途中にある関係の扱いだった。BGPMon は、Google が Hathway AS17488 とピアリングしており、Hathway がその経路をトランジット事業者である Airtel AS9498 に漏らし、Airtel がインターネット交換点のピアへ広告を伝播したと説明した [1]。

この違いは修復方法を変える。正しい origin は、正しい関係パスを意味しない。ある関係で学習した経路は、その関係の範囲で利用されるべきであり、別のピアやプロバイダーにトランジット経路として自動的に広げてよいわけではない。

なぜ重要か

この事象は、Google のような大規模プラットフォームでも、自社外部の経路判断に影響されることを示す。Google はプレフィックスを保有し起源 AS として広告していた。しかし限定的な関係で学んだ経路がトランジットに渡され、他のネットワークがそのパスを好むと、ユーザーには Google 側の問題のように見える到達性障害が起きる。

これはコスト移転でもある。緩い顧客フィルタは運用上便利かもしれない。手動例外を減らせるからである。しかし大手トランジットがその経路を増幅すると、デバッグ、サポート、可用性のコストは関係外のネットワークと利用者へ移る。

RPKI origin validation だけでは足りない点も明確である。origin が Google AS15169 のままなら、origin だけを見る検証は通る可能性がある。説明責任はパスと関係にある。誰が経路を学習し、誰がエクスポートでき、誰が優先し、どの証拠が同じ種類の経路を次回は止めるのかが問われる。

技術層

単純化すれば、これは経路ポリシーの台帳である。事業者は、各顧客、ピア、プロバイダーが送ってよいプレフィックスと、それらをどの隣接先にエクスポートしてよいかを知っていなければならない。ピアから学んだ経路は通常、別のピアやプロバイダー向けのトランジットに変換すべきではない。顧客から学んだ経路も、プレフィックス承認、IRR/RPKI、過去の経路、明示的な許可と照合する必要がある。

BGPMon は、Google AS15169、Hathway AS17488、Airtel AS9498 を含むパスを示した。また Airtel がインターネット交換点のピアへ広告を伝播し、一部ネットワークが顧客経路をピアリング経路より優先した可能性にも触れた [1]。つまり制御面は、ローカルプリファレンス、顧客/プロバイダー関係、エクスポート衛生の交点にある。

信頼できる事後証拠には、許可プレフィックス、route map、max-prefix、関係タグ、IRR/RPKI オブジェクト、リーク検知、first seen と last seen、withdrawal、修復後の collector 確認が含まれる。

誰が影響を受けたのか

BGPMon は欧州とインドの利用者報告が中心だったとし、RFC 7908 は欧州とアジアの Google サービス中断という表現を使った [1][2]。Vice はこの事例を、グローバルな経路制御がユーザー可視の障害へ変わる仕組みの説明として扱った [3]。

これらは到達性影響を述べる根拠になるが、利用者数、補償額、全 Google サービスの世界的停止を示す根拠ではない。強い公開証拠は AS path、プレフィックス数、時間窓に限られる。

次に見るべきこと

第一に、事業者が失敗した経路クラスを名指しできるかである。顧客プレフィックスフィルタ、ピア経路のエクスポート、ローカルプリファレンス、route object、一時例外、アラート失敗のどれだったのか。「ルーティング問題を解消した」だけでは制御変更の証拠にならない。

第二に、関係を意識した制御である。RFC 7908 は問題を定義した。BGP Roles、Only-to-Customer、ASPA 型のパス承認は、provider/customer/peer の範囲を運用記憶ではなく検証可能な経路証拠に近づける。

第三に、公共 collector と内部テレメトリの照合である。16 分間見えた事象なら、BGP ログ、フローカウンタ、アラート、顧客報告、withdrawal と突き合わせられるべきである。

Sources

[1] BGPMon, "What caused the Google service interruption?", https://www.bgpmon.net/what-caused-the-google-service-interruption/

[2] RFC 7908, "Problem Definition and Classification of BGP Route Leaks," https://www.rfc-editor.org/rfc/rfc7908.txt

[3] Vice, "Anatomy of a Globe-Spanning Google Outage," https://www.vice.com/en/article/anatomy-of-a-globe-spanning-google-outage/