BGP処理バグによりインターネットのルーティング不安定性が発生
(blog.benjojo.co.uk)- BGPメッセージ処理バグにより、2025年5月20日に大規模なルーティング不安定性と一部ネットワークでインターネット接続断が発生
- 問題の原因は不正なBGP Prefix-SID Attributeであり、主要なBGP実装（特に JunOS と Arista EOS）で例外的な反応を誘発
- Hutchison と Starcloudを含む一部のトランジットキャリアが原因メッセージを中継し、被害が拡大
- この事案により、約100以上のネットワークで大量のBGPセッションリセットと不安定性が発生
- ベンダーごとのBGPエラー耐性処理の欠陥と改善の必要性が今回の事態で強調された
May 27 2025
BGP処理バグによる世界的なインターネットルーティング不安定性
2025年5月20日火曜日の午前7時（UTC）にBGPメッセージが伝播し、インターネットトラフィック処理でよく使われる2つの主要BGP実装で予期しない動作が発生した。
これにより、多数の「インターネット接続BGPセッション」が自動的に終了し、最小限のルーティング不安定性から、最悪の場合には一部ネットワークの接続断まで、一時的に発生した。
問題のBGPメッセージ
- bgp.tools で収集されたセッションを分析した結果、この現象を引き起こしたBGP Updateメッセージは一見すると通常のものだが、内部データが 0x00 で埋められた破損したBGP Prefix-SID Attributeを含んでいた
- ほとんどのBGP実装（IOS-XR、Nokia SR-OS）は RFC7606(BGPエラー耐性) に従って正しくフィルタリングするが、JunOS と Arista EOS の相互作用で問題が発生
- JunOS は破損したメッセージを保持したまま転送し、Arista EOS はそのメッセージを受信すると BGP セッションをリセットする
- Juniper ハードウェア（JunOS）が多く使われる環境で、Arista EOS と接続されている場合、最長10分程度のインターネット接続断が発生する可能性がある
問題のメッセージ送信元
-
該当期間の bgp.tools アーカイブを分析すると、複数の AS オリジンが関連している
-
これは Prefix を生成したネットワークではなく、経路途中のトランジットキャリアが不正な Attribute を追加したことを示唆している
-
問題発生に関連した主要 AS は次のとおり
- AS9304 (Hutchison Global Communications Limited)
- AS135338 (Starcloud Information Limited)
- AS151326 (DCConnect Communication Pte. Ltd.)
- AS138077 (PT Abhinawa Sumberdaya Asia)
-
bgp.tools のデータから見ると、Attribute を実際に追加したのは Starcloud(AS135338) または Hutchison(AS9304) である可能性が高い
-
該当 Attribute が伝播した代表的な Prefix は 156.230.0.0/16、138.113.116.0/24 など
-
Hutchison/AS9304 は多数のインターネットエクスチェンジ（IX）に接続しており、bird が使われるルートサーバーにもメッセージが伝播した
-
Bird は BGP SID をサポートしていないため、フィルタリングなしで多数の IX にメッセージを送信し、ネットワーク規模の混乱が拡大した
BGP Prefix-SID とは？
- BGP Prefix-SID Attribute は通常、内部 BGP セッションでのみ使用されるべきもので、1つのネットワーク内で宛先へ移動する経路を定義するために使われる（RFC8669）
- この Attribute がグローバルルーティングテーブルへ漏えいした原因として、外部 BGP セッションが内部セッションのように構成されていた可能性がある
被害対象
- 正確な被害者の特定は難しいが、初期のBGPメッセージ後に激しい変動（churn）を示した約100前後のネットワークで問題が確認された
- 通常、bgp.tools のルートコレクターは毎秒2〜3万件のメッセージを収集するが、事案発生時には10秒平均で15万件以上を記録した
- この数値は、広範なインターネット経路で深刻な障害が発生していたことを示すシグナルである
ベンダーの責任と示唆
- 根本原因は確定していないが、エラーメッセージがインターネット規模で拡散したことから、既存のBGPエラー処理問題 が現実的なリスクであることを証明した
- 他ベンダーは問題の Attribute をフィルタリングしたが、Juniper はこれを迂回的に許容して Arista 機器へ転送し、BGP エラー耐性コードの不備によりセッションリセットを引き起こした
- JunOS の公式ドキュメントでも「メッセージ全体を検査するわけではない」ことが明記されている
- このような設計により、JunOS はリモートからのセッションリセットリスクは防ぐ一方で、他のピアや顧客に問題メッセージを転送する可能性がある
結論
-
今回の事案は障害期間こそ短かったが、規模が拡大した場合にはより深刻化する可能性を示している
-
サービスがますます IP 中心へ移行する中、インターネット障害の影響は単なる消費者向けメール接続不能を超え、TV放送の失敗、緊急サービスへの通話不通などへ広がるリスクがある
-
その結果、現実的に実際の人命被害にまでつながる可能性がある点から、ベンダーごとの確実な BGP エラー耐性実装の必要性が強調される
-
bgp.tools データ分析に協力できるネットワーク運用者の参加が案内されている（リンクあり）
1件のコメント
Hacker Newsのコメント
一般的に「受信時には寛容に、送信時には厳密に」という原則が標準的なアプローチとして知られている
壊れたメッセージを破棄する(drop, filter)、属性だけを無視して転送する(break)、接続自体を切断する(Aristaのように)といった選択肢がある
私は4つ目の方式(Arista方式)は本当に容認しがたい動作だと思う
3つ目(Juniper)も望ましくはないが、致命的な問題とまでは言えないと思う
編集: 内容を読み直したところ、Aristaは4つ目ではなく2つ目(接続終了)だった
接続を無効とみなして閉じただけで、ユーザー体験を考えるとあまり良い判断ではないが、受け入れ可能な範囲という印象だ
すでにRFC 7606(BGP UPDATEメッセージの改善されたエラー処理)があり、そこでは壊れたメッセージをどう扱うかが具体的に規定されている
treat-as-withdraw(経路をwithdrawしたものとして扱う)である「寛容に受け入れ、厳密に送り出す」という原則は、いわゆる「robustness principle」または「Postel's law」と呼ばれるものだ
BGPの動作特性を悪用し、ローカル機器が理解していない属性をそのまま転送できることを利用したさまざまな問題がネットワーク全体で起きていた
投稿者も関連記事でこの点を指摘している
私はこのアプローチには賛成しない
CVE-2023-4481のバグをネットワーク全体にパッチ適用するため、狂ったように忙しく動き回っていた記憶がまだ残っている
昔、通信機器ベンダーでBGP機能を開発していたことがある(かなり昔の話だ)
今でもBGPは複雑すぎると思っている
人々は新機能を追加し続け、ベンダーは標準やドラフトに合わせて実装を繰り返す
永遠に退場しそうにないBGPの性質上、この手のバグは絶えず再発する気がする
HGC Global Communications Limited(Hutchison Global Communications Limitedから改称、略称HGC)は香港のインターネットサービスプロバイダーである
BGPがこうした事柄について、複数のハードウェアベンダー間で標準化されれば、はるかに安定するように感じる
自分だけかもしれないが、BGPというものを、何か問題を起こしたという話を聞くまで一度も聞いたことがなかった
家でBGPを練習する方法があるなら知りたい
BGP実装を搭載した実機ルーター(安価なものならMikrotikのような機器)や、オープンソース実装を用意して試せる
DN42はルーティング技術を練習できる遊び場だ
私の学部のネットワーク科目ではBGPは扱われなかったが、大学院の授業ではBGPを学んだ
私が受けた学部のネットワーク授業では、BGPは黒板の上で簡単に触れられただけだった
実際のインターネットトラフィックにつながった大規模ネットワークを運用して初めて、BGPを本当に「練習」したことになるようにも思える
過去には複数ベンダーでも本文と似たバグがあった
私たちのIOS XRシャーシ機器でも似たようなパケットを受け取ったことがある
同時にBGP経路広告が多かった経験もある
upstream機器が何だったのかは正確には分からない
BGPプロトコルがきちんとファジングされてテストされているのか気になる
あまりにも重要なプロトコルなので、意図的に障害を起こしてみる度胸がないからなのかもしれないとも思う
BGP用fuzzerを書くのは簡単でも、クラッシュ診断は非常に難しいかもしれない
インターネットバックボーンほど巨大で、偶発的複雑性が積み重なったシステムが他にあっただろうかと考えさせられる
こうしたバグの影響力を考えると、相互運用性テストスイートのようなものを運営するコンソーシアムがあるはずだと思っていたので驚いた