要約

  • 2012年11月6日02:24 UTCごろ、Cloudflareは一部のインターネット経路からGoogleサービスに到達できないことを確認した。同社が公表した経路はAS4436、PCCW/AS3491、Moratel/AS23947を通り、正当なGoogleの起点AS15169へ至っていた [1]。
  • Cloudflareは障害を約27分間の限定的なものと説明し、インターネット利用者の3-5%に影響した可能性があり、香港周辺で影響が大きかったと推定した。この数値はCloudflareの推定であり、独立した全体調査ではない [1]。
  • RFC 7908はMoratel-PCCW事例をType 4の経路リークとして挙げた。これは、ピアから学習したプレフィックスをトランジット・プロバイダーへ広告し、本来の範囲を越えて伝搬させる類型である [2]。
  • Cloudflareは当初、誤った広告が行われた可能性を示した。後の更新では、Moratelが「予期しないハードウェア障害が異常状態を生み、悪意ある行為ではなかった」と説明したことを記録している [1]。公開情報だけでは内部の故障順序を確定できない。
  • 説明責任は輸出側と受入側の両方にある。Moratelは許可されていない経路の外部広告を防ぎ、PCCWは別の関係から学習された経路を顧客経路として受け入れない必要があった。

公開記録が示す事実

Cloudflareによると、同社の担当者は02:24 UTCごろにGoogleサービスへの到達不能に気づいた。8.8.8.8にも届かなかったため、当初はDNSの問題に見えた。しかしトレースにはインドネシアのMoratelのアドレスが現れた。カリフォルニアからGoogleへ向かう通信としては不自然な迂回であり、調査対象はBGP制御プレーンへ移った [1]。

公表されたGoogleプレフィックスの経路にはAS4436、AS3491、AS23947、AS15169が含まれていた。末尾のAS15169はGoogleの正当な起点のままだった。未知のネットワークがGoogleを単純に詐称したのではない。中間の関係が崩れ、到達先の身元は正しくても、許可も収容能力も想定されていないネットワークへトラフィックが引き込まれた。

CloudflareはMoratelの技術者に連絡したと述べる。異常広告は02:50 UTCごろに修正され、その約3分後に経路は正常へ戻った [1]。短時間でも、影響を受けた利用者にとってサービスは利用不能だった。宛先サーバーが正常でも、ドメイン間の経路が壊れれば、アプリケーションやDNSの障害と似た症状が遠隔地に現れる。

影響の境界は慎重に扱う必要がある。Cloudflareは有力な運用上の観測点だったが、すべての利用者、ネットワーク、Google製品を観測していたわけではない。3-5%という値には必ず出典を付けるべきである。原因についても、最初の人的ミスの推測と、後に報告されたMoratelのハードウェア障害説明を区別しなければならない。ルーターログ、ハードウェア警報、設定履歴、内部時刻表がなければ、ハードウェア、ソフトウェア、設定、フェイルオーバーのどこで最初の制御が破られたかは判断できない。

Type 4という関係上の境界

BGPは自律システム間で到達性を交換する。各自律システムはASNで識別され、独自のポリシーを実行する。広告にはIPプレフィックス、AS_PATH、その他の属性が含まれる。ルーターは何を受け入れ、優先し、次の隣接へ再広告するかを決める。

この判断は商業・運用関係を表す。顧客は通常、プロバイダーからインターネット・トランジットを購入する。ピア同士は通常、自らと顧客の経路を交換するが、互いに完全なトランジットを提供するわけではない。したがって、あるピア・セッションで正しく受信した経路でも、プロバイダーへ輸出することは許されない場合がある。

RFC 7908は経路リークを、意図した範囲を越える広告の伝搬と定義する。Type 4は、横のピアから学習した経路を自らのトランジット・プロバイダーへ広告するケースである。同RFCはMoratel-PCCWによるGoogleプレフィックスのリークを具体例として記載している [2]。

そのため起点検証だけでは不十分である。AS15169が末尾に残るなら、起点は正しい可能性がある。検証すべきなのは、AS23947がその経路をAS3491へ輸出してよかったのか、AS3491が顧客経路として受け入れてよかったのかという伝搬関係である。正しい起点は正しい経路を保証しない。

輸出側の証拠責任

経路を輸出した運用者は、対象セッション、その役割、受信経路、選択経路、隣接へ実際に広告した経路を再構成できなければならない。自組織のプレフィックス、許可された顧客経路、ピアから学習した経路、プロバイダーから学習した経路を区別する必要がある。

ハードウェア障害が引き金だったなら、報告はその障害がポリシーへ与えた効果を説明すべきである。再起動が不完全な設定を読み込んだのか、待機系が広すぎるポリシーを使ったのか、収束中に一時的なテーブルが外部へ出たのか、フィルターが迂回されたのか。「ハードウェア障害」は引き金の種類であって、輸出がオープンに失敗できた理由ではない。

意図と実行を結ぶ証拠が必要である。設定差分に加え、Adj-RIB-Outまたは同等の広告済み経路、関連コミュニティ、機器イベント、正確な時刻、変更責任者、撤回順序を保存すべきだ。これらがあって初めて、修正がリークの経路を閉じたのか、見えていた広告だけを消したのかを判定できる。

上流側の受入責任

CloudflareはPCCWをMoratelの上流プロバイダーとし、Moratelから受け取った経路を信頼して伝搬したと説明した [1]。現在のRDAPはAS3491をPCCWG-APAC-HKとし、PCCW Global (HK) Limitedを関連組織として記録している [6]。これは現在の識別を支えるが、2012年の契約やセッション役割を完全に復元するものではない。

トランジット・プロバイダーは受動的な回線ではない。どの顧客広告を受け入れ、どのように分類し、どこへ伝搬するかを決める。許可プレフィックスと起点、想定顧客コーン、許容パス、最大経路数、警報、例外承認を記録する必要がある。

顧客が正当に第三者経路を運ぶ場合、単純な許可リストは難しくなる。しかし難しさはフィルターを不要にしない。関係データを正確にし、頻繁に照合し、異常な経路数や関係遷移を検出する必要性を高める。

大規模な上流は局所的な誤りを拡大する。「顧客が送った」という説明で責任は終わらない。上流が提供するのは制御された伝搬である。受信時刻、受入理由、選好、再広告先を証明できなければならない。

登録情報と稼働状態

APNICの現在のRDAPはAS23947をMORATELINDONAP-AS-IDとし、PT. Mora Telematika Indonesiaに関連付けている [5]。AS3491の記録はPCCWG-APAC-HKとPCCW Global (HK) Limitedを示す [6]。番号資源の身元、連絡先、継続性を支える重要な記録である。

しかし02:24 UTCにルーターが何を実行していたかは示さない。登録簿はASNの運用者を記録するが、セッション上の実ポリシーや広告済み経路を記録しない。これが本稿のHeng.luの接点である。登録簿は台帳・記録者であり、稼働するネットワークそのものではない。資源の身元、意図した関係、実際の稼働状態を突き合わせて初めて説明責任が成立する。

RIPEstatの8.8.8.0/24に対する履歴応答は、照会日にAS15169が起点として見えていたことを示す [4]。ただし粒度は8時間であり、数十分の異常パスを証明できない。本稿はこれをリーク経路の証拠として使わず、経路はCloudflareの同時期観測、分類はRFC 7908に基づける。

フェイルクローズすべき制御

すべての外部BGPセッションに明示的なインポート・エクスポートポリシーが必要である。ポリシー欠落時にフルテーブルを許可してはならない。ピアから学習した経路を、デフォルトでプロバイダーへ輸出できる状態にしない。

プロビジョニング台帳には隣接ASN、役割、許可プレフィックスまたは起点、上限、変更責任者、承認、例外期限を記録する。自動化はポリシーを生成するだけでなく、実機に配備された状態が承認記録と一致するかを照合する。

実際に広告している経路集合も監視する。第三者起点の突然の出現、経路数の急増、役割と矛盾するAS_PATHやコミュニティは封じ込めを起動すべきである。

RFC 9234は事件後にBGP RolesとOnly-to-Customer属性を定義した。関係を機械可読にし、役割と矛盾する伝搬の検出に役立つ [3]。これは現在の制御設計の文脈であり、2012年にMoratelまたはPCCWが導入していた証拠ではない。

外部観測も必要である。コレクターや遠隔ネットワークは、両社のローカル表示が正常に見える段階でも越境した経路を確認できる。その情報は内部のAdj-RIB-In、ローカル決定、Adj-RIB-Outと照合すべきであり、内部証拠の代替ではない。

検証可能な公開クローズアウト

有用な報告はUTCの時系列から始める。最初の症状、内部警報、異常経路の確認、運用者間の連絡、広告停止、外部から見た撤回、安定復旧を分ける。観測時刻と診断時刻を混同してはならない。

次に、秘密の設定を公開せず、失敗したポリシーの種類を示す。ピア経路がトランジットへ輸出されたのか、ポリシーが欠落・古い・迂回されたのか、上流の顧客フィルターが広すぎたのかを説明できる。

最後に持続的な変更を試験する。承認済みの関係、生成ポリシー、配備ハッシュ、同等経路を使った拒否試験、警報しきい値、ロールバック責任者、外部の撤回確認をそろえる。「サービス復旧」は緊急対応の終了であり、「同じ経路が拒否される」という証拠がリスクの終了である。

出典

  1. https://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about/
  2. https://www.rfc-editor.org/rfc/rfc7908.txt
  3. https://www.rfc-editor.org/rfc/rfc9234.txt
  4. https://stat.ripe.net/data/routing-history/data.json?resource=8.8.8.0/24&starttime=2012-11-06T00:00:00&endtime=2012-11-07T00:00:00
  5. https://rdap.apnic.net/autnum/23947
  6. https://rdap.arin.net/registry/autnum/3491