要約

  • 2017年8月25日の事象は、Googleがピアから学習した経路をVerizonへ広告し、Verizonがそれを受理して外部へ伝搬したことで、日本の到達性に実害が見えたBGP経路ポリシーの失敗として読むべきである。
  • Googleが設定ミスを8分以内に修正したという時刻、Internet Societyが示した10分未満のリーク継続、NTT Communicationsの12時22分から12時45分の不安定化、KDDIの一部利用者で16時47分まで続いた復旧窓は、同じ時計ではない。

何が起きたのか

2017年8月25日の事象を、Googleのサービス障害としてだけ扱うと、ネットワーク上の責任境界が見えなくなる。公開された技術分析と日本の通信事業者の告知を合わせると、中心にあるのはBGPの輸出入ポリシーである。Googleは、ピアリング関係から学習した経路をVerizonへ広告した。Verizon側ではその経路が受理され、さらに外部へ伝搬した。そこには、あるネットワークが本来トランジットとして扱うべきでない経路を外へ出し、別のネットワークがそれを顧客経路または到達可能な経路として扱う境界問題があった。

Internet Societyの事象説明は、Googleがピアから受け取ったプレフィックスを漏らし、結果としてGoogleが単なるピア交換ではなくトランジットのように振る舞ったと整理している。Doug MadoryによるCircleIDの分析は、GoogleとVerizonを経由した経路の可視化、プレフィックス数、経路パス、トレースルート、日本側で見えた影響を結び付けている。日本国内では、NTT Communicationsが大規模な経路変動によりOCNの通信が不安定になったと告知し、OCN設備自体には異常がなかったと説明した。KDDIも一部のインターネット接続利用者に影響があったことと、より長い復旧時刻を公表した。

この因果鎖では、悪意や意図的なハイジャックを仮定する必要はない。むしろ重要なのは、BGPにおいて関係性が自動的には強制されないことである。ピア、顧客、トランジットという関係は運用上の意味を持つが、経路を実際に受け入れ、選択し、再広告するのはルータと設定である。番号資源の登録情報やRPKIのROAは、誰がどの番号資源を正当に保有・運用しているかを示す重要な証拠であり、監査の起点になる。しかし、それだけで「このピアから学んだ経路を別の上流へ流してはならない」という関係ポリシーをルータが自動実行するわけではない。

事象範囲を絞る理由

本稿が扱うのは、2017年8月25日のGoogleからVerizonへのBGP経路リークと、その日本における到達性への影響に限る。Googleの別のクラウド制御プレーン障害、2018年のMainOneを含む別件の経路リーク、Metaの2021年BGP障害、日本国内のGoogle関連サービス障害一般は、ここでは同一視しない。対象を広げると、BGPの輸出入ポリシー、より具体的なプレフィックス、AS関係、経路収束、事業者別の復旧時計という、この事象固有の説明がぼやける。

この限定は、責任を狭めるためではない。逆である。ネットワーク・インフラの責任は、事実の粒度を上げなければ評価できない。どのASが何を広告したのか、どの境界で受理されたのか、どの経路がより具体的だったのか、どの観測点で見えたのか、どの顧客窓口で不安定化が確認されたのか。これらを分けなければ、単に「インターネットは壊れやすい」と言うだけで終わってしまう。

プレフィックス数が一致しない理由

この事象では、公開分析ごとにプレフィックス数の表現が異なる。Internet Societyの説明、CircleIDの分析、日本語の技術解説、報道は、それぞれ受信された経路、漏れた経路、伝搬した経路、影響した可能性のある経路を別の切り口で数えている。したがって、13万5,000、16万、あるいはそれ以外の数を、単一の確定総数として扱うべきではない。

BGPの事故では、数の違い自体が重要な証拠になる。ある観測者は、RouteViewsや他のコレクタから見えた経路だけを数える。別の観測者は、特定のASパスに現れた経路だけを数える。さらに別の説明は、受け取った経路、実際に再広告された経路、到達性に影響した経路を混ぜて見出しにすることがある。経路が見えたことは、その経路が全世界のすべてのルータにインストールされたことを意味しない。逆に、あるコレクタで見えなかったことは、その経路がどのネットワークにも届かなかったことを意味しない。

このため、本稿ではプレフィックス数を責任判断の単独根拠にしない。数は、どれほど大きな経路集合が異常な経路関係を通って見えたかを示す指標である。責任の中心は、数そのものではなく、なぜそのような経路集合がGoogleからVerizonへ出て、Verizonからさらに外へ流れ、より具体的な経路としてトラフィックを吸引し得たのかという運用統制にある。

Google側の輸出制御と8分の修正

Internet Watchの記事は、Googleが設定ミスを8分以内に修正したという同社の説明を伝えている。この8分は重要である。発端となった設定またはソフトウェア上の誤りが短時間で修正された可能性を示すからだ。しかし、この時計は利用者側の完全復旧を意味しない。設定が戻されても、BGP経路の撤回、隣接ASへの伝搬、各ネットワークの経路選択、FIBへの反映、セッションやアプリケーションの回復には別の時間がかかる。

Google側の責任境界は、経路を生成・広告する仕組み、ピアごとの輸出ポリシー、変更レビュー、異常時のロールバック、監視アラート、公開説明にある。公開情報だけでは、どのコマンド、どの自動化、どの承認手順、どのルータ群が直接の発火点だったかは分からない。したがって、特定の内部手順違反や過失を断定することはできない。それでも、ピアから学んだ経路が別のASへ流れたという公開経路証拠は、輸出フィルタが期待どおりに働かなかったか、少なくとも期待される関係ポリシーが実際の広告に反映されなかったことを示す。

この点で、8分以内の修正は評価されるべき要素である一方、統制の十分性を証明するものではない。事故後の説明で必要なのは、修正に要した時間だけではなく、異常経路がどの範囲まで出たのか、どのフィルタが失敗したのか、どの監視が検知したのか、誰がロールバック権限を持っていたのか、同種の経路広告を再発させないための検証がどのように行われたのかである。

Verizon側の受理と再広告

この事象が日本の到達性問題になったのは、Googleが経路を出しただけではなく、Verizonがそれを受理し、さらに外へ伝搬したと公開分析が示しているからである。BGPでは、あるASが誤って経路を広告しても、隣接ASのインポートフィルタ、関係ポリシー、max-prefix制御、経路監視が機能すれば、被害の広がりを抑えられる可能性がある。つまり、輸出側の誤りと輸入側の受理は、別々の統制点である。

ここでも、公開情報からVerizonの私的なピアリング契約、ローカルプリファレンス、実際のルータ設定を推測してはいけない。分かるのは、公開観測上、GoogleからVerizonを含むASパスを通った経路が見え、そこからさらに到達性問題につながったということだ。したがって、Verizon側の責任分析は、契約違反の断定ではなく、受理・再広告境界の統制検証でなければならない。

実務上の問いは明確である。Googleのような大規模ネットワークから突然大量のピア学習経路が来たとき、Verizonの境界はそれを期待された経路集合として扱うべきだったのか。顧客から来るべき経路、ピアから来るべき経路、トランジットとして再広告してよい経路の区別は、どの機械可読なポリシーに落とされていたのか。異常なプレフィックス数やASパスの組み合わせに対して、max-prefixや異常アラートはどの段階で働いたのか。これらは、2017年時点の実装状況を問う運用上の責任であり、後年の標準をさかのぼって法的義務として押し付けるものではない。

より具体的なプレフィックスがトラフィックを引き寄せた

この事象の到達性への影響を理解するには、BGPの最長一致を避けて通れない。一般にIP転送では、より具体的なプレフィックスがより広いプレフィックスより優先される。例えば、正当な経路として広い範囲が広告されていても、別経路からより細かいプレフィックスが広告されれば、トラフィックはそのより具体的な経路へ引き寄せられる可能性がある。

公開分析は、このリークによりデアグリゲートされた、つまりより具体的な経路が含まれていたと説明している。これが単なる経路表のノイズではなく、日本の到達性問題につながった理由である。Googleがその宛先に対して通常のトランジットとして機能していなければ、引き寄せられたトラフィックは正しく届けられず、破棄、迂回、遅延、セッション失敗として利用者に見える。問題は「Googleが宛先を所有していたか」だけではない。「その瞬間に、ルータがどの経路を最も具体的で好ましいものとして選んだか」である。

この点は、番号資源台帳と実際の到達性の差をよく示している。レジストリ上の保有者情報が正しくても、ルータが誤った関係から来たより具体的な経路を選べば、パケットの現実は台帳とずれる。台帳は責任追跡の土台であり、監査対象を特定する証拠である。しかし、到達性を決めるのは、受理され、選択され、転送面へ反映された経路である。

日本側で見えた影響

日本国内の影響については、事業者ごとの公開告知を分けて扱う必要がある。NTT Communicationsは、2017年8月25日12時22分から12時45分にかけてOCNの通信が不安定になったと告知し、原因としてインターネット上の大規模な経路変動を挙げた。また、OCN設備自体には異常がなかったと説明している。これは、問題がアクセス網内部の単純な設備故障ではなく、外部の経路状態と連動した到達性の不安定化だったことを示す直接の事業者証拠である。

KDDIの告知は、影響範囲を一部のインターネット接続利用者に限定しつつ、復旧時刻として16時47分を示している。これは、Google側の8分修正やInternet Societyが示した10分未満のリーク時間よりも長い。ここで重要なのは、矛盾ではなく時計の種類である。経路リークの発生・修正、BGP撤回、経路収束、事業者側の安定化、顧客が正常化を確認するまでの時間は、同一ではない。

報道や二次的な技術分析は、複数の日本企業やサービスに影響があった可能性を伝えている。ただし、それをもって「日本のインターネット全体が停止した」または「すべての利用者が影響を受けた」とは言えない。観測できるのは、少なくとも一部の日本のアクセス利用者やサービスで顕著な不安定化があり、通信事業者がそれを外部経路変動と結び付けて告知した、という範囲である。

復旧時計を混ぜてはいけない

この事象の説明で最も危険なのは、「8分で終わった」と「数時間影響した」を同じ意味に扱うことである。Googleの8分以内の修正は、発端となった設定誤りを直した時間である。Internet Societyの10分未満という説明は、リークが観測された制御プレーン上の継続時間を示す。NTT Communicationsの12時22分から12時45分は、OCN利用者に見えた不安定化の窓である。KDDIの16時47分は、一部利用者についてのより長い復旧告知である。

経路制御では、原因が取り除かれても影響が即時に消えるとは限らない。撤回された経路は隣接ASを通じて伝搬し、各ネットワークが新しいベストパスを選び直し、転送表が更新され、既存セッションや上位アプリケーションが再試行する。さらに、事業者の障害告知は技術的な経路収束そのものではなく、利用者影響の観察、社内確認、復旧判断、告知更新を含む。

したがって、責任分析では少なくとも五つの時計を分ける必要がある。第一に、誤った広告が始まった時刻。第二に、発端ネットワークが設定またはソフトウェア状態を修正した時刻。第三に、異常経路が撤回され、外部ASで収束した時刻。第四に、日本の事業者が自網内の不安定化を収めた時刻。第五に、顧客がサービス回復を実感し、事業者が復旧を告知した時刻である。これらを分けることで、各主体が何を制御し、何を観測し、どの時点で説明責任を負うべきだったかが見える。

経路コレクタの証拠価値と限界

RouteViewsやBGPStreamのような公開経路データは、この種の事象を後から検証するうえで不可欠である。参加ピアから見えた経路広告、ASパス、時刻変化を使えば、異常経路がどの方向へ伝搬したかを再構成できる。CircleIDの分析や他の技術解説も、こうした可視経路に基づいて、GoogleからVerizonを通る伝搬や日本側での影響を説明している。

しかし、コレクタは全知ではない。公開観測点は、すべての私的ピアリング、すべてのルータ、すべてのローカルプリファレンス、すべての拒否された経路、すべてのパケットフローを見ているわけではない。ある経路がコレクタに見えたことは、その経路が全ネットワークで採用されたことを意味しない。ある経路がコレクタに見えなかったことは、その経路がどこにも届かなかったことを意味しない。

この限界は、コレクタ証拠の価値を下げるものではない。むしろ、公開証拠から言えることと言えないことを区別するために必要である。責任ある事故報告では、コレクタで見えた経路、事業者ログで見えた受信経路、ローカルRIB、FIB、アラート、顧客影響、トラフィック量を突き合わせるべきである。公開分析だけで内部設定や全世界の受理状況を断定するのではなく、公開経路証拠を監査の入口として使う必要がある。