要約

  • Cloudflareによれば、2026年1月22日の設定整理で、ボゴタ拠点向けの不要なプレフィックスリスト参照が削除された一方、生成されたIPv6エクスポート項には route-type internal と accept が残った。
  • 最後の限定条件が消えたことで、構文上は使用可能な設定のまま、その項が受理する経路集合が拡大した。小さなソース差分や構文検査だけでは、この意味上の拡張を検出できない。
  • Cloudflareの説明では、マイアミの1台のルーターから、ピアであるMetaのAS32934から学習したIPv6経路が、CloudflareのAS13335を経由してトランジット事業者AS3356側へ広告された。
  • Cloudflareは公開影響をIPv6に限定された25分間とし、マイアミ―アトランタ間の輻輳、一部顧客トラフィックの損失増加、遅延上昇、非ダウンストリーム宛てトラフィックの破棄、ピーク時約12 Gbpsの破棄を報告した。
  • 限定したRIPEstat BGPlay照会は1,548件のイベントを返し、そのうち1,440件のASパスにAS13335とAS32934の双方が含まれていた。この結果が裏づけるのは異常なパスの外部可視性であり、内部設定、全影響範囲、顧客被害、商業関係そのものではない。
  • RPKIによるオリジン検証は、正当なオリジンASを保持した関係性リークを単独では阻止しない。オリジン認可と、ピア・プロバイダー・顧客間で許される伝播経路は別の検証対象である。
  • 有効な変更管理には、生成元だけでなく、レンダリングされた候補ポリシー、実行中ポリシー、Loc-RIB、隣接相手ごとのAdj-RIB-Out、実際のBGP更新、RIB/FIB、トラフィック観測、外部コレクターを一続きの証拠として扱う仕組みが必要だ。
  • 1台のルーターを使うカナリア展開は、単に「設定を投入できた」ことを確認する段階ではない。送信前に経路集合とAdj-RIB-Outの差分を比較し、関係性ルールへの違反があれば自動停止しなければならない。

25分間の事象と、その後まで続いた復旧

Cloudflareのインシデント報告によれば、発端はインフラ更新後に不要となったボゴタ拠点固有のプレフィックスリスト参照を整理する変更だった。変更の目的自体は、古い参照を削除して設定を現状に合わせることにあった。しかし、生成されるエクスポートポリシーの意味は、削除前後で同じではなかった。

Cloudflareは、リポジトリ上の変更が2026年1月22日19時52分（UTC）にマージされたとしている。20時25分、オートメーションがマイアミの1台のルーターで動作し、同時点から影響が始まった。Cloudflareによる調査開始は20時40分、インシデントとしての提起は20時44分だった。

20時50分、オペレーターが当該ルーターのポリシーを手動で元に戻し、オートメーションを停止した。したがって、Cloudflareが示す公開上の影響時間は20時25分から20時50分までの25分間となる。ただし、外部影響が止まった時点と、変更系全体が健全な状態に戻ったと判断された時点は同じではない。

リポジトリ上の変更が取り消されたのは21時47分だった。22時07分にオートメーションが健全であると判断され、実際に停止状態が解除されたのは22時40分である。この時間差は重要だ。ルーター上の誤った実行状態を戻すこと、生成元を訂正すること、オートメーションを検証すること、再開を承認することは、それぞれ別の復旧作業だからである。

Cloudflareは、影響がIPv6だけに限定されたと報告している。この限定は、今回公表された影響範囲を理解するうえで有用だが、IPv4とIPv6の変更経路、生成ロジック、承認手続き、監視系統が完全に分離されていたことまで証明するものではない。公開情報から確認できるのは、観測され報告された影響がIPv6に限られたという境界までである。

Cloudflareが報告したネットワーク影響

Cloudflareによると、この事象ではマイアミからアトランタへ向かうリンクに輻輳が発生し、一部のCloudflare顧客トラフィックで損失が増加した。影響を受けたリンクでは遅延も上昇したと同社は説明している。

また、ルーターのファイアウォールフィルターは、ダウンストリームに属さない宛先へ向かうトラフィックを破棄したとCloudflareは報告した。その破棄量はピーク時に約12 Gbpsへ達したという。これらの数値と影響記述は、Cloudflare自身が公表した測定および評価である。公開コレクターのASパスだけから、トラフィック量、遅延、パケット損失、破棄量を独立に導くことはできない。

公表資料は、影響を受けた全プレフィックスの完全な一覧、顧客の氏名や社名、影響顧客数、財務損失を示していない。したがって、それらを推定値で補うべきではない。ルーターベンダー、非公開トポロジー、内部に存在した可能性のある未公表の防御策についても、公開記録から断定することはできない。

この事象は、悪意あるオリジン詐称を示すものではない。Cloudflareの説明に基づけば、焦点は、正規に学習された経路が許可されていない関係へ輸出された点にある。問題の核心はオリジンの偽装ではなく、経路伝播の関係性とエクスポート権限の逸脱である。

最後の限定条件が消えたエクスポート項

Cloudflareの説明では、設定生成処理はボゴタ向けの旧いプレフィックスリスト参照を削除したが、生成されたIPv6エクスポート項には route-type internal と accept が残った。ここで重要なのは、「限定条件が削除された」というテキスト上の変化と、「残った項が何を受理するか」という実行上の意味が一致しないことである。

route-type internal は、単に当該ルーター自身が生成した経路だけを意味する狭い条件ではなかった。Cloudflareによれば、この条件は外部経路ではない経路を照合し、iBGPで学習した経路も対象に含めた。その後ろに accept が残っていたため、本来はプレフィックスリストによって狭く限定されていた項が、より広い内部経路集合を受理できる状態になった。

生成された設定は構文的に壊れていなかった。ルーターが読み込めず失敗する種類の障害ではなく、意味上広すぎるが実行可能なポリシーだった。この違いが、ルーティングオートメーションにおける難しい責任問題を生む。構文検査が成功し、設定投入も成功し、BGPセッションが維持されていても、輸出される経路集合は誤っている可能性がある。

「削除した行が少ない」「古い参照を消しただけ」「候補設定が正常にレンダリングされた」という確認は、必要条件にはなり得ても十分条件ではない。最後のプレフィックス、コミュニティー、隣接関係などの限定条件が消えた時点で、残存する受理アクションの権限を再評価する必要がある。

安全側の生成器は、限定条件がゼロになった項を暗黙に有効化してはならない。少なくとも、項そのものを削除する、明示的に拒否へ変える、生成を失敗させる、あるいは人間の再承認を要求するなど、閉じる方向に動作すべきである。どの方式を選ぶとしても、最終的に受理される経路集合を計算せず、ソース差分だけで安全性を判断することはできない。

ソースの意図から外部観測までを分離する

今回のような事象を検証する際、異なる証拠層を混同すると、原因と影響の双方を誤って評価する。最低限、次の状態は個別に保存されなければならない。

第一は、ソース上の意図である。これは、なぜボゴタ向け参照を削除したのか、どのプレフィックスまたは拠点を変更対象としたのか、変更者が期待した範囲は何かを表す。ただし、意図は実行結果ではない。

第二は、レンダリングされた候補ポリシーである。テンプレート、データ、生成器の分岐を通過した後、ルーターへ送られる具体的な設定がここに当たる。ソースでは小さな削除でも、候補ポリシーでは受理集合が大幅に広がっている可能性がある。

第三は、ルーター上の実行中ポリシーである。候補が投入されたか、別の設定と合成されたか、投入の一部だけが成功したかを示す。候補ファイルと実行状態は同一とは限らないため、両者のハッシュや構造差分だけでなく、意味上の差分も必要になる。

第四は、Loc-RIBである。RFC 4271が示すBGPの情報モデルでは、経路は受信、選択、ローカル利用、隣接相手への広告という段階を持つ。Loc-RIBはローカルに選択された経路を示すが、そこに存在するだけで外部へ広告されたとは限らない。

第五は、隣接相手ごとのAdj-RIB-Outである。実際に各ピア、プロバイダー、顧客へ送信するために選ばれた経路集合を確認する層であり、エクスポートポリシーの結果を最も直接的に表す。全隣接相手を合算した件数だけでは、誤った相手への少数の輸出を見逃し得る。

第六は、ルーターが実際に送出したBGP更新である。Adj-RIB-Outの候補状態と、外部へ発せられた更新は、観測時点や実装上の処理によって区別して記録する必要がある。

第七は、RIB/FIBと転送状態である。BGP上の広告が存在しても、実際にトラフィックがどのインターフェースへ転送され、どこで破棄されたかは別の証拠である。制御プレーンの異常と、データプレーンの損失、遅延、輻輳を一つの数値にまとめるべきではない。

第八は、外部コレクターや遠隔観測点である。これは、経路が自律システムの境界を越え、インターネット上の観測点へ到達したことを示す。しかし、内部のどの設定行が原因だったか、どの商業契約に反したか、どれほどのトラフィック障害を起こしたかまでは示さない。

この八つの層を時刻付きで結ぶことにより、「何を変更するつもりだったか」「何が生成されたか」「何がルーター上で動いたか」「どの経路が誰に輸出されたか」「外部から何が見えたか」「実トラフィックに何が起きたか」を分けて説明できる。

ピア、プロバイダー、顧客を別々の関係として検証する

Cloudflareは、ピアであるMetaのAS32934から学習したIPv6経路を、CloudflareのAS13335からトランジットプロバイダーAS3356側へ広告したと説明している。公表例のプレフィックスは 2a03:2880:f077::/48、観測されたASパスは 64112 22850 174 3356 13335 32934 だった。

このASパスは、AS13335とAS32934を含む経路がAS3356を越えて外部から観測されたことを示す材料になる。一方、ASパスだけを商業契約の完全な台帳として扱うことはできない。ピアリング、トランジット、顧客関係の具体的条件には公開されない要素があり、ASパスの並びだけでは契約上の全権利義務を確定できないからである。ここでの関係性の説明は、Cloudflareが公表したピアおよびプロバイダーの位置づけに基づく。

エクスポート制御は、プレフィックスやオリジンが妥当かどうかだけでなく、「どの関係から学んだ経路を、どの関係へ再広告できるか」を判定しなければならない。ピアから学んだ経路、プロバイダーから学んだ経路、顧客から学んだ経路、運用者自身が生成した経路は、それぞれ独立した来歴を持つ。

一般的な運用設計では、顧客から正当に受けた経路を他の接続先へ提供する場合と、ピアまたは上流から学んだ経路を別のピアや上流へ流す場合を同じ規則で扱わない。後者を許せば、自らが意図しない中継経路となり、Type 3またはType 4に該当し得るルートリークを形成する。

Cloudflareは今回の事象を、RFC 7908におけるType 3とType 4が混在するルートリークと説明した。分類は伝播関係の異常を記述するものであり、悪意や法的責任を自動的に意味するものではない。また、単一の観測パスから全経路が同じ分類だったと拡張してはならない。

関係性制御を堅牢にするには、経路が有効なプレフィックスを持つこと、オリジンASが認可されていること、隣接相手からの受信が許されること、さらに別の隣接相手への輸出が許されることを独立に評価する必要がある。どれか一つが通ったからといって、残りを省略できない。

1台のカナリアで確認すべきもの

今回、オートメーションはマイアミの1台のルーターで動いた。限定した展開は、障害範囲を抑える有力な設計になり得る。しかし、1台に限定したという事実だけで、カナリアが安全制御として十分だったとは言えない。カナリアの価値は、異常を送信前またはごく初期に検出し、自動的に停止できるかで決まる。

カナリア適用前には、候補ポリシーが照合する経路集合を実行中ポリシーの集合と比較する必要がある。増減したプレフィックス数だけでなく、オリジンAS、学習元、経路タイプ、コミュニティー、ASパス、アドレスファミリーを含む差分が必要だ。今回のように最後の狭い条件が消えた場合、IPv6の受理集合が突然広がる兆候を投入前に捉えられる可能性がある。

次に、隣接相手ごとのAdj-RIB-Out差分を計算する。ある顧客向けに予定された経路増加と、ピアまたはプロバイダー向けに現れる同じ増加は、意味が異なる。許容上限は全体件数だけでなく、隣接相手の関係、アドレスファミリー、オリジン、パス、コミュニティーごとに設定すべきである。

さらに重要なのは送信前の停止条件である。ピア学習経路がプロバイダー向けAdj-RIB-Outへ追加される、プロバイダー学習経路が別の上流へ追加される、許可されていないオリジンまたは関係タグが現れる、といった違反は、件数が1件でも自動停止の対象になり得る。単なる「増加率が閾値以下」という検査では、小規模だが重大な関係性違反を通してしまう。

送信後の短い観測窓では、実際のBGP更新、外部コレクター、経路監視、リンク利用率、損失、遅延、破棄カウンターを照合する。ただし、外部コレクターで異常が見えるまで待つ方式は、すでに経路が外へ出た後の検知である。外部観測は重要な独立証拠だが、送信前検査の代替にはならない。

RPKIが守る境界と、守らない境界

RPKIとROAは、IPプレフィックスのオリジンASが認可されているかを検証する仕組みである。RFC 6480はRPKIの基盤を、RFC 6811はBGPオリジン検証を、RFC 8210はルーターと検証キャッシュの連携を、RFC 7115はオリジン検証を利用した運用上の考え方を示している。

今回公表された例では、リークした経路のオリジンはMetaのAS32934のままだった。したがって、ROAがそのオリジンを正当に認可していた場合、RPKIオリジン検証はその事実を正常と判断し得る。しかし、それはAS13335からAS3356側へその経路を輸出してよいことを意味しない。

オリジン認可は「誰がこのプレフィックスを起点として広告できるか」を扱う。関係性リークは「その正当な起点から来た経路を、途中のASがどの隣接関係へ伝播してよいか」を扱う。同じ経路について両者の判定は併存できる。オリジンが正当でも、途中の伝播がポリシー違反である場合がある。

このため、RPKIが有効なら今回の事象を必ず阻止できた、と述べることはできない。RPKIは重要な防御層だが、エクスポートポリシーの関係性を全面的に代替する仕組みではない。

RFC 9234、コミュニティー、外部フィルタリング、ASPA

RFC 9234は、BGP RolesとOnly-to-Customer属性、すなわちOTCを定義し、隣接関係に基づくルートリークの防止と検出を支援する。役割が適切に交渉され、OTCが期待どおり設定・検査される環境では、ピアまたはプロバイダーから受けた経路が不適切な方向へ伝播することを、ローカルな生成ポリシーとは別の層で拒否できる可能性がある。

信頼されたBGPコミュニティーも、経路の来歴や輸出可能範囲を示す補助的な制御になり得る。ただし、コミュニティーが正しく付与され、経路伝播中に保持され、すべてのエクスポート境界で一貫して評価されることが前提となる。生成器自身がタグ付けと検査の双方を誤る場合に備え、別系統の検証が必要である。

外部フィルタリングは、隣接する他のネットワークが異常な経路を受け入れないための防御層になる。MANRSの資料は、プレフィックスやASパスを含む運用上のフィルタリング慣行を示す。しかし、一般的な運用指針は特定事業者の私設ネットワークにおける実装監査ではない。Cloudflareまたは隣接事業者が特定の制御を当時どのように展開していたかを証明するものでもない。

ASPA検証に関するIETFの作業は、AS間のプロバイダー関係を利用してパスの妥当性を検証する方向を扱う。これは単純なオリジン検証よりもパスと関係性に近い問題へ対応するが、発展中の作業を、今回の時点ですでに広く展開され有効性が証明された仕組みとして扱ってはならない。

BGP RolesとOTC、信頼されたコミュニティー、外部フィルタリング、ASPAは同じものではない。役割の明示、経路への属性付与、ローカルポリシーの補強、隣接ネットワークでの拒否、パス検証という異なる制御面を担う。複数を重ねる理由は、一つの生成器、一つのタグ、一つの事業者の意図に安全性を依存させないためである。

Cloudflareは、ベンダーによる関連機能の対応状況を検証すること、BGPコミュニティーによる防護を追加すること、CI/CDで空または誤ったポリシー項を評価すること、早期検知を改善することを方向性として挙げた。これらは妥当性を検討できる改善方針だが、後日の実装完了や有効性を示す証拠ではない。約束と実装、実装と検証済みの効果は分けて扱う必要がある。

公開コレクターが示した異常パス

対象プレフィックス 2a03:2880:f077::/48 について、2026年1月22日20時24分から20時52分（UTC）までに限定したRIPEstat BGPlay照会は、ステータス ok とともに1,548件の更新イベントを返した。そのうち1,440件は、ASパスにAS13335とAS32934の双方を含んでいた。

この件数は、指定したプレフィックス、時間窓、BGPlayデータに対する限定的な観測結果である。Cloudflareが例示したASの組み合わせを含む経路が、多数の更新イベントとして公開観測系に現れたことを裏づける。したがって、「異常なパスがCloudflare内部だけの候補状態にとどまらず、外部から可視だった」という点については独立した補強材料になる。

一方、この照会から、ルーター内部に route-type internal と accept が存在したことを確認することはできない。変更を生成したソース、候補設定、実行中設定も見えない。1,548件というイベント数を、影響プレフィックス数、影響顧客数、パケット数、セッション数として読み替えることもできない。

また、AS13335とAS32934が同じパスに現れることは、その経路の可視性を示すが、非公開の商業契約全文や関係条件を独立に証明するものではない。Cloudflareが説明したピアとプロバイダーの関係を補強する文脈にはなるものの、コレクターデータだけから契約違反や法的評価を導くことはできない。

RIPE RISのコレクターやMRT形式の記録は、時系列で経路変化を追うための重要な外部証拠である。ただし、観測点がインターネット上のすべての経路を網羅するわけではない。観測されなかった経路が存在しなかったとは限らず、観測された経路が同じ規模で全ネットワークへ広がったとも限らない。

復旧はルーターと生成元の双方を直す

20時50分の手動復旧は、実行中ルーターの誤ったポリシーを戻し、同時にオートメーションを停止する対応だった。これは進行中の影響を止めるための即時措置として理解できる。しかし、ルーターだけを戻して生成元を残せば、次回の自動実行で同じ状態が再現される危険がある。

そのため、21時47分のリポジトリ変更の取り消しは、異なる復旧層として意味を持つ。実行環境と生成元の双方が訂正された後、22時07分にオートメーションの健全性が判断され、22時40分に再開された。この順序は、緊急停止、永続的な訂正、健全性確認、再開承認を分ける必要性を示している。

ただし、公開された時刻だけから、誰が最終的な意思決定責任を持っていたか、内部でどの承認が必要だったかを推測することはできない。今後の説明責任として必要なのは、個人を推定することではなく、各段階に役割名と明示的な所有者を割り当て、記録を保存することである。

復旧確認には、ルーター上の実行中ポリシーが期待状態へ戻ったこと、誤ったAdj-RIB-Outが消えたこと、撤回更新が送出されたこと、外部コレクターや遠隔観測点から異常パスが消えたこと、トラフィックと破棄カウンターが通常範囲へ戻ったことを含めるべきである。

自動化の再開条件も、単なるプロセスの稼働確認では足りない。修正済みのソースから候補設定を再生成し、以前の異常を再現しないこと、関係性制約が機能すること、カナリアの自動停止条件が有効であることを確認する必要がある。

ルーティングオートメーションの説明責任

ルーティング変更の説明責任は、「オートメーションを使っていたか」という二者択一では測れない。重要なのは、オートメーションが自らの出力をどの証拠によって限定し、逸脱時にどの段階で止まるかである。

変更記録には、変更目的、対象拠点、対象アドレスファミリー、削除される最後の限定条件、生成前後の受理集合、隣接関係ごとの輸出集合、予想されるAdj-RIB-Out差分を含める必要がある。構文が正しいという結果とは別に、意味上の差分を示さなければならない。

承認時には、変更者が書いたソースだけでなく、実際に投入される候補ポリシーを確認対象とする。とりわけ accept を持つ項からプレフィックス、コミュニティー、隣接関係などの条件が削除される場合、通常の差分承認から切り離して強い検査を要求するのが合理的である。

展開時には、1台のカナリアについて、許容する経路数、ASパス、オリジン、学習元、輸出先を明示する。差分が想定範囲を越えた場合だけでなく、件数にかかわらず禁止関係が一つでも現れた場合に自動停止する。

運用中には、Loc-RIBとAdj-RIB-Outを混同せず、送信された更新と外部観測を時間で結ぶ。データプレーンについても、RIB/FIB、リンク利用率、遅延、損失、破棄を別々に記録する。こうすることで、経路が外へ出たことと、顧客トラフィックへ測定可能な影響が出たことを区別できる。

ロールバックでは、実行中ルーターと生成元の双方を修正し、オートメーションを停止したまま撤回を確認する。再開には、名前の付いた運用上の所有者、検証結果、外部観測、再発防止条件が必要である。事故後に新しい制御を約束した場合は、その実装日、適用範囲、例外、試験結果を後から確認できる形で残すべきだ。

この証拠連鎖があれば、「意図は安全だった」という説明から一歩進み、「生成された実行状態が許容範囲内だったか」「何が外へ出たか」「どの制御が止められなかったか」「復旧後に何を検証したか」を具体的に答えられる。