要約

  • 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、アラート、顧客影響、トラフィック量を突き合わせるべきである。公開分析だけで内部設定や全世界の受理状況を断定するのではなく、公開経路証拠を監査の入口として使う必要がある。