- ベネズエラの CANTV(AS8048) ネットワークで複数回にわたり BGPルートリーク(route leak) が発生し、一部のネットワーク経路が異常に伝播した
- Cloudflare Radarのデータによると、12月以降 11件のリークイベント が確認されており、これは ルーティングポリシーの不備 に起因する技術的な誤りである可能性が高い
- 今回の事案は、AS8048が上位プロバイダ AS6762(Sparkle) から受け取った経路を 別のプロバイダ AS52320(V.tal GlobeNet) に再送した形で、典型的な Type 1 ヘアピンリーク の構造
- RPKIベースの経路起点検証(ROV) は今回のケースでは有効ではなく、ASPA(Autonomous System Provider Authorization) や RFC9234 のような新しい標準がこの種のリーク防止に必要
- BGPの信頼ベースの構造により、このような事故は珍しくなく、ASPA・Peerlock・RFC9234 といった技術の導入が安全なインターネット運用の鍵となる
BGPルートリークの概念
- BGP(Route Gateway Protocol) は、インターネット上の自律システム(AS)間で経路を交換するためのプロトコル
- ネットワーク間の関係は 顧客-プロバイダ(customer-provider) または ピア(peer-peer) の形で構成される
- ルートリーク(route leak) は RFC7908 で「意図した範囲を超えたルーティング情報の伝播」と定義される
- 例: 顧客がプロバイダから受け取った経路を別のプロバイダへ再び伝播する場合
- このようなリークは valley-free routing ルール への違反であり、トラフィックが異常な経路をたどって移動することになる
- 結果として、ネットワーク混雑、遅延、トラフィック損失などの問題が発生する
AS8048(CANTV)のルートリーク事例
- Cloudflare Radarは、AS8048(CANTV) が AS6762(Sparkle) から受け取った経路を AS52320(V.tal GlobeNet) に再送した事実を確認
- リークした経路の起点は AS21980(Dayco Telecom) で、AS8048の 顧客ネットワーク
- 両AS間の関係は Cloudflare Radar と bgp.tools のデータで プロバイダ-顧客関係 と確認されている
- 経路には AS8048が複数回 prepend されていた
- prepend は経路の魅力度を下げてトラフィックを別経路へ誘導するための手法
- したがって、意図的な MITM(中間者攻撃) の可能性は低い
- リークは2026年1月2日 15:30〜17:45 UTCの間に複数回発生しており、ネットワークポリシーの誤りや収束の問題 による現象である可能性が高い
- Cloudflare Radarの記録によれば、12月以降11件の類似リーク が繰り返されており、継続的なポリシー不備 と判断される
技術的原因とポリシー上の問題
- AS8048が プロバイダ AS52320 に対する ルーティング export ポリシーを緩く設定 していた可能性
- 顧客BGPコミュニティタグの代わりに IRRベースのプレフィックスリスト のみを使用していた場合、誤った経路再送が発生しうる
- こうしたポリシー誤りは RFC9234の Only-to-Customer(OTC) 属性 によって防止可能
- OTCはBGPロール(顧客・プロバイダ・ピア)を明示的に定義し、誤った経路伝播を遮断する
RPKIとASPAの役割
- Sparkle(AS6762) は RPKI Route Origin Validation(ROV) を完全には実装していなかったが、
- 今回の事案は 経路(path)の異常 であるため、ROVでは防止できない
- ASPA(Autonomous System Provider Authorization) は経路ベースの検証を提供する
- 各ASが承認された上位プロバイダの一覧を明示することで、異常な経路を自動的に遮断する
- 例: AS6762が「上位プロバイダなし」を宣言すれば、他のネットワークはAS6762を含む誤った経路を拒否できる
- ASPAはRPKIベースで動作し、ルートリーク防止に直接的な効果 を持つ
安全なBGP構築のための提案
- BGPは本質的に 信頼ベースのプロトコル であるため、ポリシー誤りやミスによるリークが頻繁に起こる
- ASPA、RFC9234、Peerlock/Peerlock-lite のような技術を併用すれば
- 経路検証の強化
- 誤った経路伝播の遮断
- ネットワーク安定性の向上
- RIPE はすでにASPAオブジェクトの作成をサポートしており、
- 運用者は RFC9234実装の要請 をネットワーク機器ベンダーに伝える必要がある
- このような協調的な標準導入こそが、ベネズエラの事例のようなBGP事故を防ぐ中核的手段 である
1件のコメント
Hacker Newsの意見
ここのコメントの流れはちょっと意外だった。みんな米国企業への恐れを語っているけれど、記事の内容とはあまり関係がないように見える
Cloudflareの投稿は単にBGPの動作原理を説明し、ベネズエラのISPで経路リークが頻発していた点を指摘しただけだった
もちろんCloudflareが間違っていたり、何かを隠している可能性はあるが、記事のどこにも彼らが直接関与したという話はない。みんな何を見てそこまで確信しているのか気になる
ただ、StuxnetやDual EC DRBGの件を見ると、政府の0-day活用能力を過小評価すべきではない
私の友人はFANG企業で働いていたが、政府にデータストリームを直接提供しているのを見たと言っていた。ISPのバックドアも現実だ（Room 641A）
もしCloudflareが令状に従って協力していたなら、それを否定する文章を法的に書けただろうか？
だから人々に基本的な懐疑心が生まれるのだと思う。「これは昔からある問題で大したことではない」というCloudflareの結論は少し弱い
BGPの構造上、米国が他国よりこうしたことをやりやすい理由があるのかも気になる
最近は米国政府への世論がかなり冷笑的なので、小さな出来事でも疑われやすい空気がある
あるいは単にロシアや中国のソーシャルアカウントかもしれないが、誰にもわからない
それに、CNNの記事ではトランプが同盟国に対しても軍事行動の可能性に言及していた
今の政権なら、むしろこういう攻撃を公然と自慢していたようにも思う。だから私はひとまず「単なる設定ミス」のほうを信じる
とはいえ、最近の米国がニュースになるたびに脅し、撤退、制裁の話ばかりなので、人々の不信が強まるのは自然だ
眠かったが、記事は興味深かった。AS path prependingの分析は「事故説」をよく裏づけている
国家がトラフィックを横取りしようとしていたなら、わざわざ経路を長くする理由はない
おそらく単純なルーティング設定ミスだった可能性が高い。BGPはいまだに信頼ベースのシステムなので、小さなタイプミスひとつで世界中に影響が及ぶ
悪意より欠落したexportフィルタのほうがもっともらしい説明だ
実際、広告トラフィックを操作しようとする非国家アクターも存在する
それでもネットワーク運用者の立場からすると、こうしたミスは珍しくなく、自動化されたトラフィック調整スクリプトが問題を悪化させることもある
結局のところ問題はBGPの構造的脆弱性だ。セキュリティとBGPは今もなお相性の悪い言葉だ
Snowden文書のひとつであるNSA Network Shaping 101は参考になる
2007年に作成された文書で、ASINとレイヤー3のトラフィック制御について説明している
単に特定IP宛てのトラフィックがそのリンクを通る構造を説明している程度だ
記事を読んで、米国企業と政府の結びつきがどれほど深いかを改めて思い知らされてぞっとした
以前から知っていたことではあるが、今回は信頼が完全に崩れたように感じる。時代の転換点のようだ
こうした監視インフラはずっと前から存在しており、日本でも2003年にリアルタイムのトラフィック監視が行われていた
今ではDPI技術の実装はあまりにも容易だ
新しく業界に入った人たちは無邪気に始めるが、やがて政府と企業の密着構造に気づいて信頼を失う
時間がたつとまた新しい世代が同じ過程を繰り返す
記事の要点はHanlon's razor、つまり悪意より先にミスを疑おうということだ
もちろんCloudflareが事実を歪めていたなら批判されるべきだが、その証拠はまだない
ベネズエラの老朽化したインフラを考えると、わざわざ高度なサイバー攻撃が必要だったのかと思う
腐敗した請負業者がいい加減なシステムを納入してきたのが現実だ
サイバー攻撃より腐敗した構造のほうがはるかに大きな問題だ
結局、路上で働いていた技術者に金を払って解決したのだが、その番号はタクシー会社の番号だった
こういう環境でBGP攻撃を論じるのは少し虚しい
今回の記事は良いBGPの復習だった
以前ネットワークエンジニアとして働いていたとき、BGP community magicをよく使っていたが、
もしBGPがprovider、customer、peerの3種類しか表現しないものだったら、ずっと単純だったかもしれない
Google Mapsで交通情報や信号データをなくせば計算は楽になるが、結果はめちゃくちゃになるのと同じだ
以前、Google Mapsが私を高速道路からWalmartの駐車場を経由して別の高速道路へ案内したことがあった
そのときは単なるアルゴリズムのバグだと思ったが、もしMcDonald’sのドライブスルー経由で案内されていたら陰謀を疑っていただろう
今回の件も同じで、単純なミスと見るほうが説得力がある
インターネットの中核インフラが米国企業中心で運営されているのは少し怖く感じる
もう他国も独立した仕組みを作るべきだ
では誰が代わりに管理すべきだというのか気になる
私は長年BGP事故を観察してきたが、意図された変更とミス、構造的障害を見分けるのはいつも難しいと感じる
だからまず3つの質問をする。影響範囲は徐々に広がったか、経路は対称的に変化したか、復旧はきれいに行われたか
そしてAS-path prependingの変化を先に見て、地域ごとの可視性を比較する
最後に「誰が得をしたのか」を追う。他の人たちはどんな指標で問題を検知しているのか気になる
Cloudflareの世界的なカバレッジには本当に驚かされる
ただ、彼らはエンジニアリング中心の組織なので、こうした分析を公開するのがうまい