要約

  • 2020年8月30日10時前後（UTC）から約5時間、CenturyLink/Level 3を中心に大規模な到達性障害が続いた。独立した観測者は、経路のフラッピング、異常なBGP更新、古い経路広告、トラフィックの終端、数千のネットワークに及ぶ到達不能をそれぞれ異なる観測範囲で記録した。
  • CenturyLinkは、1個のIPアドレスを遮断する意図の要求がワイルドカード付きで届き、二次フィルターを通過して広く伝播したため、問題のあるFlowSpec広告がネットワーク機器間のBGP確立を妨げたと説明した。この内部メカニズムは事業者による説明であり、外部測定が完全な内部因果関係を再現したわけではない。
  • 説明責任の中心は、ルールの受理ではなく、意図と実効範囲の一致、段階的な伝播、撤回の完全性、停止権限、安定した経路と到達性による回復証明にある。公開記録だけでは、完全な内部ログ、個人やベンダーの責任、損失や法的責任、現在の予防策の全社的な有効性までは確定できない。

約5時間、経路が存在しても通信できない状態が広がった

障害は2020年8月30日の10時前後（UTC）に表面化した。USC Information Sciences InstituteのTrinocular観測は開始を09時55分ごろに置き、Cloudflareは10時03分にエラーの増加を記録している。観測地点や指標が違えば開始時刻に数分の差が生じるのは不自然ではない。重要なのは、複数の独立した測定が同じ時間帯にCenturyLink/Level 3を中心とする広範なIPv4到達性の悪化を捉え、その状態が回復までおよそ5時間続いたことである。

これは単に一部のウェブサイトが遅くなった出来事ではない。大手バックボーンは、直接の顧客だけでなく、他の通信事業者、クラウド、コンテンツ配信、企業ネットワークの経路にも組み込まれている。制御プレーンが不安定になると、パケットを運ぶ物理回線が残っていても、どの経路を使うべきかという情報が信頼できなくなる。到達先への広告が残ったまま実際には転送できない場合、トラフィックは故障した経路へ引き込まれ、代替経路があっても利用されない。

Cloudflareは48都市でCenturyLink/Level 3を経路から外し、別の接続へ切り替えた。それでも、古い経路が残った場所や単一の上流事業者に依存するネットワークでは、障害を回避できなかったと報告した。同社が観測した世界のトラフィック低下は3.5％だったが、この割合は世界中の被害者数を示すものではない。Cloudflareの測定対象と基準におけるトラフィック変化であり、別の観測値と足して一つの被害総数にすることはできない。

CatchpointはRouteViewsのデータを使い、AS3356に結び付く異常な広告と、LINXの収集点で増大したBGP更新を分析した。実際に迂回できたネットワークと、経路がCenturyLinkを通り続けたネットワークの差も示した。USC/ISIは米国内外の複数地点から数千のネットワークが到達不能になる様子を捉えた。これらの数字は測定方法も分母も違う。共通して証明するのは広い継続性障害であって、固有の利用者数、収益損失、死傷者数、法的損害額ではない。

ThousandEyesの分析は、通信がCenturyLink網内で終端する状況、経路のフラッピング、古い広告、ピアによる経路変更を記録するとともに、CenturyLinkが顧客に提供した拡張説明を保存している。外から見える現象と事業者が説明した内部の出来事を同じものとして扱わないことが重要である。外部観測は「何がインターネットに起きたか」を強く裏付けるが、「内部で誰がどの入力をどの順序で扱ったか」までは示さない。

防御用のFlowSpec入力が制御プレーンを揺らした

FlowSpecは、BGPを使ってトラフィックの一致条件と処理を配布する仕組みである。たとえば、攻撃を受けている特定の宛先への通信を遮断したり、速度を制限したりするルールを多数のネットワーク機器へ素早く届けられる。大規模なネットワークでは、個々の装置を手作業で設定するよりも迅速で一貫した防御が可能になる。その強みは、誤った範囲も同じ速度と一貫性で広げられるという危険と表裏一体である。

CenturyLinkの顧客向け説明によれば、発端は1個のIPアドレスを遮断するための要求だった。しかし、その要求はワイルドカードを含む形で受け取られ、二次フィルターを通過し、複数のネットワーク機器へ広く伝播したという。問題のあるFlowSpec広告は、それらの機器でBGPを正常に確立できない状態を引き起こしたとCenturyLinkは説明した。この一連の内部事情は必ず事業者への帰属を保つ必要がある。公開された独立測定は広範な外部影響と時間的な整合性を示すが、非公開のコマンド履歴や検証処理そのものを再現してはいない。

「ワイルドカードがあった」という記述だけで、具体的な構文、入力者、変換処理、装置実装の欠陥を推定してはならない。どの段階で意図と実効範囲が食い違ったのか、二次フィルターが何を比較したのか、同じ解釈を共有していたのかは公開記録から分からない。悪意ある行為も示されていない。1個のアドレスを遮断する目的は通常の防御作業と整合し、結果が広範だったことだけで攻撃意図を認定することはできない。

同様に、ルーター、オペレーティングシステム、FlowSpec制御製品のメーカーも確定していない。名前のないベンダー欠陥を想定することさえ、証拠のない責任移転になる。分析すべき対象は、事業者が運用する入力、検証、伝播、撤回、復旧の連鎖である。製品名を補わなくても、稼働中のネットワークが防御ルールを安全な範囲に保てなかったという説明責任の問いは成立する。

入力検証は構文ではなく実効範囲を確かめる境界である

入力検証には少なくとも三つの層がある。第一は構文上の妥当性で、機器や制御システムがオブジェクトを解釈できるかを確認する。第二は組織の方針で、その一致条件、処理、対象範囲が許可された種類かを判断する。第三は意図との一致で、配布される実効ルールが承認された要求を本当に表しているかを確かめる。構文が正しく、方針表の範囲内でも、1個のアドレスを対象としたはずの入力が広い集合に作用するなら検証は目的を果たしていない。

実効範囲は人が理解できる形で表示されるべきである。正規化後のアドレス集合、フロー条件、適用アクション、配布予定の地域や装置、影響が予想される経路を、元の変更要求と並べて比較する。1個のアドレスという承認内容に対し、予期しないワイルドカードや大幅に広い一致集合が現れれば、自動的に停止する必要がある。単に「検証済み」と記録するのではなく、何と何を比較し、どの差を検出したかが証拠になる。

二次フィルターが存在するだけでは独立性を証明しない。最初の処理と同じパーサー、同じ正規化表現、同じ既定値、同じ方針仮定を使えば、同じ誤解を二回受理する可能性がある。独立性は必ずしも別ベンダーを意味しない。別実装による実効範囲の計算、安全な環境でのシミュレーション、限定されたカナリア領域への投入、外部からの到達性試験など、共通の解釈誤りを同じまま通過させない仕組みを意味する。

人による承認も、表示される情報が不十分なら安全境界にはならない。担当者が曖昧な要求文だけを見て承認し、機器が実際に評価する一致集合を見られなければ、入力者と同じ誤解を追認するだけである。逆に、自動化された検査でも、承認された対象と正規化後の効果を別々に算出して差分を強制的に止めるなら、実用的な独立性を持ち得る。重要なのは人か機械かではなく、異なる失敗経路と観測可能な判定根拠があるかである。

検証システム自身が失敗したときの挙動も決めておく必要がある。検査サービスが応答しない、二つの計算が一致しない、結果が曖昧であるという状況で、バックボーン全体への配布を黙って許可すべきではない。不確実性が高いほど伝播権限を小さくする。広範な防御ルールを出したい側に、範囲が理解され限定されていることを示す責任を置くべきである。

伝播の封じ込めは検証失敗を全網障害にしない

どれほど慎重な検証でも、実際の装置と経路が示す挙動を完全には予測できない。そこで、ルールを一度に全ネットワークへ広げず、少数の装置、地域、トラフィック範囲に段階投入する。各段階でBGPセッション、更新量、ルート安定性、ルールに一致したトラフィック、意図していない宛先への到達性を基準値と比較し、次の段階へ進む条件を明確にする。

カナリアと呼ぶだけでは封じ込めにならない。全体と同じ重要な実装経路を通り、危険な挙動を検出できる規模でありながら、失敗時の影響を限定できなければならない。また、停止条件が数値化されている必要がある。相関するBGPセッション切断、更新量の急増、経路フラッピング、意図外トラフィックの終端、外部プローブの到達性喪失が見えたら、原因の完全な説明を待たずに拡大を凍結する。

停止権限は技術設計の一部である。異常を見た運用者が、長い承認経路や最終的な責任認定を待たず、配布を止め、ルールを撤回し、影響を受けていない領域を保護できなければ、停止手順は紙の上にしか存在しない。原因がまだ分からない段階でも、観測可能な閾値に基づいて可逆的な保護行動を取れるようにする。後で検証するため、誰がどの信号に基づき、どの範囲を止めたかを記録する。

伝播速度と人間の判断速度の非対称性も考慮すべきである。自動配布は数秒から数分で多数の装置へ届く一方、担当者が要求の意図を再構成し、複数チームの承認を得るには時間がかかる。最終段階まで人の介入が不要な設計なら、異常時には自動的に影響範囲を固定する仕組みが必要になる。安全な自動化とは速く配布することではなく、証拠が不足したときに速く止まれることである。

経路撤回が機能しなければ冗長性は利用できない

今回の障害で重要なのは、別の接続を持つことと、その接続へ実際に切り替えられることの差である。BGPでは、利用できない経路が撤回されたり優先度を失ったりすれば、他の経路が選ばれる。しかし、故障したネットワークが古い広告を残し、周囲がその経路を有効と見なし続ければ、トラフィックは到達不能な方向へ送られる。構成上の二重化は、制御プレーンの状態が正確でなければ運用上の多様性にならない。

Cloudflareが多数の都市でCenturyLink/Level 3を外して迂回できたことは、代替経路が機能した例である。同時に、古い経路や単一接続のために失敗が続いた地点は、迂回能力の限界を示す。Catchpointが確認したAS3356経由の継続も同じ問題を別のデータで捉えている。複数の上流を契約していても、一方の古い広告が優先され続ければ、実用上は独立した継続経路を持たない。

そのため、FlowSpecルールの撤回だけでは回復を証明できない。問題の入力を遮断した後、BGPセッションが安定し、悪い経路や古い広告が関係するピアから消え、代替経路が選択され、意図した宛先へエンドツーエンドで到達できる必要がある。内部ダッシュボードが正常でも、外部の経路収集点やプローブが到達不能を示すなら、サービス回復は完了していない。

回復時刻を一つに圧縮しないことも大切である。CenturyLinkは問題の広告を遮断し、BGPの安定性を回復したと報告した。しかし、トリガーの停止、内部セッションの確立、ピアへの撤回伝播、古い状態の消滅、利用者から見た到達性の回復は別の節目である。観測者ごとに回復時刻が違っても矛盾とは限らない。説明責任ある終了報告は、それぞれの節目と証拠を分けて示す。

外部測定が明らかにすること、しないこと

外部データを組み合わせる価値は、単一の組織の説明に依存しない点にある。経路収集点は広告と撤回の変化を示し、アクティブプローブは特定地点からの到達性を示し、トラフィックデータは実際の流量変化を示す。異なる種類の測定が同じ時間帯の異常を捉えれば、バックボーンの制御状態と利用者が経験した障害の関係をより確かにできる。

ただし、RouteViewsの収集点は選ばれた地点から見える経路を記録するもので、通信事業者内部の全ポリシー評価を監視しているわけではない。プローブはその観測地点から対象アドレスへ応答があるかを示すが、どの入力欄やコマンドがセッション確立を妨げたかは示さない。トラフィック比率も、固有の人や組織の被害台帳ではない。観測の限界を明示することで、再現できる事実と推測を分けられる。

Cloudflareが当日に示した内部原因の可能性は、CenturyLinkの拡張説明が得られる前の技術的仮説として扱うべきである。後の事業者説明と混ぜて、外部から完全な内部因果関係が証明されたように書いてはならない。時系列には初期仮説と後日の帰属説明を併記できるが、証拠の種類は異なる。後者はメカニズムを狭め、前者は当時インターネットが経験した挙動を保存する。

公開記録は、個人の行為や判断も確定しない。誰が要求を作り、誰がワイルドカードを追加または保持し、誰が二次フィルターを所有し、誰が広域配布や最初の対応を承認したかは分からない。その役割がCenturyLinkの従業員、顧客側の処理、自動システム、または複数の組み合わせだったかも確定していない。個人の物語を作ることは説明ではなく、空白の穴埋めになる。

法的結論にも同じ境界がある。大規模な停止と重大な制御失敗は、直ちに契約違反、過失、制裁、裁判上の責任を証明しない。ここで扱う4資料は、この出来事に関する判決や規制当局の決定ではない。技術的な説明責任はそれでも厳格に問える。なぜ広いルールが通り、伝播をどう限定し、どの証拠で回復を確認したかを事業者に求めることと、存在しない法的判断を宣言することは別である。

即時の復旧と現在の保証を区別する

CenturyLinkは、問題のある広告を遮断し、BGPの安定を取り戻したと報告した。これは当日の緩和措置を示す重要な記録である。しかし、後にどの入力検証が導入され、どの範囲で配備され、現在も独立した試験に合格しているかを公開資料は示していない。事後の対策が有効だとも無効だとも、ここから断定することはできない。

現在の保証に必要なのは、方針文書ではなく試験結果である。単一アドレスの要求に過剰な一致条件を加えた安全な演習で、検証が配布前に止めるか。カナリア領域でセッション異常が生じたとき、拡大が自動停止するか。ルールを撤回したとき、ピアが古い状態を保持せず代替経路を選べるか。内部の回復表示と外部の到達性が一致するか。これらを定期的に実証して初めて、予防策が稼働中のネットワークで機能していると言える。

機密性の高い設定をすべて公開する必要はない。事業者は、失敗した制御の種類、承認された対象と実効範囲の差、最初の封じ込め範囲、停止権限、回復の各節目、外部で用いた検証方法を説明できる。内部コマンドや顧客情報を伏せても、制御が存在し実行可能であることを示す集約的な証拠は提供できる。説明責任は秘密をなくすことではなく、観測可能な結果に所有者を置くことである。

この事件の教訓は、FlowSpecを避けるべきだということではない。強力な防御手段ほど、入力の意図と効果を別々に計算し、配布を限定し、撤回経路を保ち、外部から回復を確かめる必要がある。設計図に二次フィルターや冗長経路が描かれているだけでは足りない。稼働中の制御プレーンが過剰な入力を止め、失敗を局所化し、正確な経路情報を再び伝えられることが、バックボーン継続性の証拠になる。

出典