BGP処理バグによりインターネットのルーティング不安定性が発生
(blog.benjojo.co.uk)- 2025年5月20日 07:00 UTCに伝播した破損したBGPメッセージが、主要実装2種で予期しない動作を引き起こし、多数のインターネット接続BGPセッションがリセットされ、一部ネットワークでルーティング不安定化や短時間の接続断が発生
- 問題のアップデートには、インターネットBGPアップデートでは通常想定されないBGP Prefix-SID Attributeが付与されており、内部データがすべて
0x00の破損状態だった - RFC7606ベースのエラー耐性を適用したIOS-XR/Nokia SR-OSはこれを適切に破棄したが、JunOSは転送し、Arista EOSはセッションをリセットしたため、JunOSベースのtransit carrierに接続されたArista利用者に影響した可能性がある
- bgp.toolsの観測では、AS9304、AS135338、AS151326、AS138077が繰り返し登場しており、不正な属性を追加した主体はStarcloud AS135338またはHutchison AS9304である可能性が高い
- 事故中、bgp.tools route collectorの10秒平均メッセージ率は通常時の毎秒20,000〜30,000件から150,000/s超へ急増し、BGPエラー処理の違いが実際のインターネット経路安定性を揺るがしうることを示した
2025年5月20日のBGPアップデート事故
- 2025年5月20日火曜日 07:00 UTCに伝播したBGPメッセージが、インターネットトラフィック転送でよく使われる主要なBGP実装2種で予期しない動作を誘発
- 多くのインターネット接続BGPセッションが自動終了し、影響が拡大
- 一部ネットワークでルーティング不安定化が確認された
- 最悪の場合、短時間の接続断が発生した可能性がある
問題となったBGPメッセージ
- bgp.toolsに供給されるセッションで確認されたアップデートは、/16に対する比較的ありふれたBGP Updateだったが、問題のBGP Prefix-SID Attributeを含んでいた
- この属性は2つの理由で危険だった
- インターネットテーブルのBGPアップデートで見られることが想定されない属性である
- 内部データがすべて
0x00の破損した属性である
- IOS-XR/Nokia SR-OSのような大半の実装では、RFC7606ベースの「BGP error tolerance」が設定されている場合、これを正しく破棄するため問題は起きない
- JunOSとArista EOSの組み合わせでは異なる結果が見られた
- JunOSは破損したメッセージを転送する
- Arista EOS機器は、JunOS機器から来たと見られるこのメッセージを受信するとセッションをリセットする
- 多くのインターネットtransit carrierがJunOSを実行するJuniper製ハードウェアを使っているため、Arista EOSを運用しつつJunOSベースの上位transit carrierルーターに接続されたネットワークでは、一定時間インターネット接続が途切れた可能性がある
- 継続時間は最大約10分と推定される
不正属性を追加した候補AS
- 当該期間のbgp.toolsアーカイブをフィルタリングした結果、複数のorigin ASが事故に関与したように見える
- これは、属性がprefixをoriginしたネットワークではなく、より広いインターネットへ向かう途中の中間carrierで追加された可能性を示唆する
- 問題メッセージ全体で繰り返し登場した候補は次の4つ
- bgp.toolsは
[…] 151326 138077 […]経路で、不正なBGP属性なしにimpacted prefixを観測している- したがって、不正属性を追加した主体はStarcloud AS135338またはHutchison AS9304である可能性が高い
- 属性を含むアップデートで観測された一部prefixは次のとおり
156.230.0.0/16138.113.116.0/24163.171.102.0/24163.171.103.0/24163.171.104.0/24
インターネットエクスチェンジへ広がった経路
- 事故は、Hutchison/AS9304が多くのインターネットエクスチェンジに接続していたため拡大した
- 問題メッセージはIX route serverへ送られ、これらのroute serverは通常birdを実行している
- BirdはBGP SIDをサポートしていないためメッセージをフィルタできず、そのまま複数のmulti-terabitインターネットエクスチェンジへ配布した
- その結果、混乱はインターネットtransitセッションを超えてより広い範囲へ拡散した
BGP Prefix-SIDの性質
- BGP Prefix-SID Attributeは通常、内部BGPセッションでのみ見られるべきもの
- RFC8669で定義された目的は、単一ネットワーク内で宛先までトラフィックがどの経路を取るかを決める助けとなること
- この属性がグローバルルーティングテーブルへ漏れ出た理由は、外部BGPセッションが内部セッションのように設定されていたためかもしれない
影響を受けたネットワークと観測指標
- 正確に誰が影響を受けたかを断定するのは難しいが、最初の問題BGPメッセージ直後にネットワーク規模に対してchurnが非常に大きかった場所を基準に、約100ネットワークが問題を経験したと集計されている
- 高い確度で挙げられる例は次のとおり
- 平常時、bgp.tools route collectorは毎秒約20,000〜30,000件のメッセージを収集する
- 今回の事故中、10秒平均メッセージ率は150,000/sを大きく上回った
- 多くのインターネット経路で相当な障害があったことを示している
ベンダーごとのエラー処理の違い
- 根本原因や実際の発生主体は完全には明らかでないものの、欠陥メッセージがインターネット規模で伝播した事実は、BGPエラー処理のリスクを示している
- 他ベンダーは不正属性を検知してルート広告を抑止したが、Juniperはこれをpeerへ伝播した
- このメッセージがArista機器に到達した後は、BGP error toleranceコードが存在しなかったか欠陥があり、セッションリセットにつながった
- JuniperのJunOS BGP error tolerance文書は、JunOSがメッセージのすべての部分を確認するわけではないと明記している
- この動作により、JunOS自身はリモート誘発のセッションリセットを回避しつつ、同じメッセージを別のpeerや顧客側へ転送する結果になった
運用上の含意
- 今回のoutageは短時間だったが、さらに大きな影響を及ぼしえた
- より多くのサービスがIPベースへ移行するにつれ、インターネット障害の影響範囲はメールアクセス不能を超える可能性がある
- テレビ放送の停止
- 緊急サービスへの通話障害
- この種のバグは、現実世界での人命被害を引き起こしたり悪化させたりする可能性を高める
- フルルーティングテーブルを持つネットワーク運用者は、bgp.toolsへデータフィードを提供することで、将来の事故のデバッグに役立てられる
- すでに2570個の稼働セッションがbgp.toolsへデータを提供している
- 設定方法はbgp.toolsデータフィード設定文書で案内されている
1件のコメント
Hacker News のコメント
標準的な考え方は、受け入れるときは寛容に、送り出すときは厳格に、というもの
選択肢は、壊れたメッセージをフィルタする、破棄する、壊れた属性は無視しつつ転送する、壊れた属性のせいで壊れる、のいずれかだが、本当に受け入れがたいのは4番のArista式の挙動だけだと思う。3番のJuniper式の挙動は望ましくはないが致命的ではない
読み直してみると、Aristaは4番ではなく2番に近く、完全にクラッシュしたのではなく、不正な接続と見なして閉じたようだ。ユーザーの立場ではよくないが、議論の余地はあるものの許容可能な部類ではある
最も一般的な方式は treat-as-withdraw で、経路広告のアップデートを既存の広告経路の撤回として扱うもの。壊れたメッセージを単に捨てると、もはや有効でない古い状態を維持し続けることになるため、そうしてはいけない
1980年代や90年代のインターネット古代史に由来する発想だが、今日ではプロトコルの硬直化と数多くのセキュリティ問題を生んだ誤ったアイデアとして広く理解されている
いまや多くのシステムがその挙動に依存しており、その「機能」の欠点に苦しんでいる
一見すると、この「機能」は、転送される情報の影響を理解していないシステムを通じて未知の情報が盲目的に広がるため、非常に悪いアイデアのように見える。しかしこの機能のおかげで Large Communities のようなものがより早く広く展開でき、新しいBGP機能の展開そのものが可能になったとも言える
ネットワーク全体で CVE-2023-4481 を修正しようと必死に走り回ったことを今でも覚えている
この種のバグは対処するのが本当に悪夢のようなもので、BGPが設計・実装された方法のせいで、この挙動を修正するには非常に長い時間がかかるはず
何十年も前のことだが、通信機器メーカーで BGP機能 を開発していた
今でもBGPは複雑すぎると思うし、人々は新機能を追加し続け、メーカーはRFC標準やドラフトを基準に実装し続けている
BGPが廃止されるとも思えないので、こうしたバグは今後も繰り返し見つかり続けるだろう
個人的には恐ろしいほど複雑だったが、誰かにとっては収益性が高かった
HGC Global Communications Limitedは、以前はHutchison Global Communications Limitedとして知られていた企業で、香港のインターネットサービスプロバイダー
https://en.wikipedia.org/wiki/HGC_Global_Communications
うちの IOS XRシャーシ もこうしたパケットを一部受け取っており、高いBGP経路広告の発生時期と一致していた。上流がどんな機器を使っているのかは正直わからない
BGPプロトコルがきちんとファジングされているのか気になってきた。重要すぎて、みんな壊して試すのを恐れている分野なのかもしれない
BGPファザーを書くのは簡単かもしれないが、クラッシュ原因を診断するのは非常に難しそうだ
BGPは、問題を起こすという話を聞くまで学んだことがなかった気がする。TCP/IPと同じくインターネットに不可欠なのに、TCP/IPは大学でも学び、キャリアの中でも触れ、本もたくさん読んだが、BGPは大学・職場・本のどこでもほとんど触れる機会がなかった
TCP/IPは家でおもちゃのプロジェクトとして「遊び」ながら学べるが、BGPはどう試せばいいのか分からない。家でBGPを学ぶにはどうすればいいのか？
記事にはbirdが出てくるし、また非常に人気のある実装としてFRR（free range routing）もある。Dockerコンテナを2つ立ち上げ、その間にBGPセッションを作り、たとえば内部で設定した静的経路を伝播させるのはとても簡単
ガイド付きチュートリアルが好きなら、https://blog.ipspace.net/2023/08/bgp-labs-basic-setup/がかなりよく、少し高度なトピックまで広がっている。手順を追うのに必要なものはすべて自由ソフトウェア
どんなネットワーキング技術でも、実際に体験してみる最も簡単な方法はおそらくGNS3だろう
[1]: https://wiki.dn42.us/home
試してみる方法の一つはこれ: https://www.eve-ng.net/
もう一つの方法は、ネットワークインターフェースをいくつか持つ仮想マシンを数台作り、その間にネットワークを構成してからBGPルーティングデーモンを使うこと
https://bird.network.cz/
https://www.nongnu.org/quagga/
といったものがある
複数のASをシミュレーションするPythonパッケージを使ったが、どのパッケージだったかは覚えていない
BGPを実験するには、この記事の著者のようにネットワークシミュレーターを使える。授業では教授の大学院生が作ったらしいgini[1]を使い、著者はCisco特化のns3版のように見えるgns3を使ったようだ。ns3は一度使ったことがあるが、学習曲線が急だった。giniシミュレーターはユーザーインターフェースがより素朴だが、おそらく機能はそれほど強力ではないだろう
[1] https://citelab.github.io/gini5/
[2] https://docs.gns3.com/docs/
複数のハードウェアベンダーが、この種の処理の標準的な方法について合意していれば、BGPはずっと安定していたように見える
本当の問題は、各ベンダーがロックイン効果を望むために標準化しないことにあるのだろうか？
ただし、BGPについての理解は浅く乏しく、専門家ではない
こうしたバグの影響を考えると、相互運用性テストスイートを持つコンソーシアムがないのは驚きだ
もしかすると存在はするが、この特定の問題がテストスイートに入っていなかったのかもしれない。だとすると、ファザーや機械生成方式で可能なパケットエラーをすべて探索し、テストケースを作っていないのが驚きだ。スイートの実行に数時間や数日かかっても構わないはずなのに
この記事の著者はある程度のカバレッジを持つファザーを作っており、以前にも似た問題に遭遇したようだ。ベンダー各社がこの作業を積極的に取り入れないのは驚きだ
複数のベンダーが過去にこのバグを経験していた: https://www.kb.cert.org/vuls/id/347067
CVE-2023-4481（Juniper）、CVE-2023-38802（FRR）、CVE-2023-38283（OpenBGPd）、CVE-2023-40457（EXOS）があった
当時Aristaは影響を受けなかった
インターネットの配管ほど規模が大きく、偶発的複雑性もビザンチン的に入り組んだものがほかにあっただろうかと思う