要約

  • LACNICが7月28日に公開した記事は、2025年5月20日に観測された属性コード40の壊れたBGP Prefix-SIDと、10秒間に15万件を超えた更新の急増から始まる。
  • 記事によれば、IOS-XRとSR OSは属性を破棄し、Junosは転送し、EOSはセッションをリセットし、複数IXPのroute serverも属性を中継した。
  • RFC 8669は不正なPrefix-SIDを破棄して記録するよう求めるが、その規定だけでは、実機の版、エラー耐性設定、継承後の隣接ポリシーまでは分からない。
  • 公開マトリクスは、同じサニタイズ済みUPDATEを、正確な版、実効設定、接続境界、処理、転送後バイト列、RIBへの結果と結び付けるべきだ。

製品名より先に、三つの動詞を見る

LACNICが7月28日に公開したルーティングセキュリティの記事は、RPKIの適用範囲外に残る危険を整理している。導入例は抽象論ではない。2025年5月20日、壊れたPrefix-SID属性を含むBGP UPDATEが観測された。Prefix-SIDはoptional transitive属性で、コード40が割り当てられている。

記事が描く経路では、同じメッセージが一様には扱われなかった。Cisco IOS-XRとNokia SR OSは不正な属性を捨て、処理を続けた。Junosはそのまま先へ送った。受信したAristaルータはBGPセッションをリセットした。複数のIXPでroute serverもフィルタせずに中継したとされる。10秒間に15万件（150,000件）を超えるUPDATEが生じ、Starlink、Disney、Zscaler、ByteDanceなどに関連する経路が変動した。AristaはEOS 4.28.11以降で挙動を変更した、と記事は記す。

この整理が重要なのは、起点認証と属性処理を分けたからだ。正当なorigin ASから来た経路でも、別の属性の壊れた内部構造が下流のパーサを刺激し得る。ROAが答えるのはprefix–originの許可であって、すべてのoptional transitive属性の安全性ではない。

ただし、ベンダー名をそのまま実行状態と読むと、比較は粗くなる。CiscoやNokiaという名だけでは、どのパーサ、どのパッチレベル、どのfault-tolerance機能が使われたか分からない。peer groupやtemplateから継承した設定がneighbor単位でどう確定したかも見えない。iBGP、顧客、transit、peer、route serverのどの境界だったかによっても扱いは変わり得る。

RFCは規範を示すが、配備台帳ではない

RFC 8669のエラー処理は明確である。Prefix-SID属性はTLVの集合であり、属性が短すぎる、TLV長が条件に合わない、またはTLVが宣言境界を越える場合、受信側は属性を破棄し、エラーを記録しなければならない。その処理はRFC 7606のAttribute discardに対応する。

これは実装を検査する基準である。しかし、全世界の実機がその時点で何をしたかを証明するものではない。

事件直後にBen Coxが公表した分析には、運用上大切な条件が残っている。IOS-XRとSR OSは、RFC 7606のエラー耐性を使うようシステムが設定されていれば問題の属性を除去した、という書き方である。LACNICの記事は「両者がRFC 7606どおりに破棄した」と簡潔にまとめた。結果を指す限り両文は両立し得るが、前者には設定という検証可能な変数がある。

これは記事の揚げ足取りではない。ニュースは短く書く必要があり、研究サーベイは用語を統一する必要がある。実インターネットで生じた事故に、最初から完全なラボ記録が付くこともまれだ。結論を無意味な「可能性」に薄めるのではなく、条件を表の列として保存すればよい。

当日のNANOGスレッドは、その必要性を示す。議論ではAristaのbug 899981と、EOS 4.28.11、4.29.8、4.30.6、4.31.2の各修正版が挙げられた。一方で、修正済み版が当日の正確なメッセージにどのような結果を出したかについて質問も残った。後のJANOG 57でAristaが示した資料も、IOS XR、SR OS、Junos、EOSの違いと修正版を説明している。これは有力な裏付けだが、四製品を同じ試験ベクトルと公開設定で比較した一枚の実験記録ではない。

15万という数字の単位

15万超という値は制御プレーンの増幅を印象的に示す。ただし単位を変えてはならない。元のグラフは、一つのcollectorが観測したメッセージ率を10秒平均で表したものだ。15万の一意prefix、session、router、network、outageを数えたものではない。

列挙された組織名も機器一覧ではない。Starlink、Disney、Zscaler、ByteDanceに関係する経路がflapしたとしても、各組織が同じEOS版を使ったこと、同じneighborから同じbytesを受け取ったこと、同一の利用者影響があったことまでは示さない。分散したBGP観測は手掛かりであり、全経路の因果台帳ではない。

発信元ASの意図も未確定である。論文と記事は、誤ったredistribution、二重実行されたscript、vendor bugといった無害な説明があり得ると認める。脅威分類にATRという名前を与えても、この一件の悪意が証明されるわけではない。

再現できる行を作る

LACNICがベンダーコードや各社の運用を支配する必要はない。必要なのは、同じサニタイズ済みUPDATEを使う、日付と版を持ったconformance matrixである。

各行の先頭に入力bytesの不変hashとtest-vector版を置く。code 40、flags、宣言長、具体的なTLVエラーを続ける。その後にplatform、正確なsoftware release、fix identifier、group・template・neighborの継承を解決した後のerror-handling設定を書く。

接続の種類も一列にする。内部、顧客、transit、settlement-free peer、IXP route serverでは、同じ属性にも異なる方針を適用できる。route serverは単一製品名でも共通設定でもない。

出力は、session reset、AFI/SAFI disable、treat-as-withdraw、attribute discard、acceptなどを区別する。メッセージを転送したなら、機密部分を除いたforwarded bytesのhashを示す。転送しなかったなら、その事実を明記する。さらにsession状態と、制御試験内でAdj-RIB-In、Loc-RIB、FIBがどう変わったかを結ぶ。

peer IP、顧客名、認証情報、私設topology、production config全文を公開する必要はない。raw captureは限定保管し、test vector、method version、capture loss、集計結果、訂正履歴、再試験日だけを公開できる。

この形なら責任境界も崩れない。RFCは要求を定め、vendorはparserを実装・修正し、operatorは版とpolicyを選ぶ。route server operatorはサービスを通過する属性を決める。LACNICは地域向けの明確な技術記録と再現方法を提供するが、ルータの決定権を持つわけではない。

言えないことを残す

公開資料は、LACNICがUPDATEを発信した、影響を受けたroute serverを運用した、あるいは事故を直接止められたとは示さない。全session数、利用者数、全ネットワーク共通の障害時間も分からない。ベンダーごとの永続的なdefaultを証明したものでもない。

RPKIの役割も否定されない。ROVはprefixとoriginの許可関係を検証する。optional transitive属性の構文やparserの耐性は別の制御である。両者を一つにすれば、暗号基盤に過大な権限を求め、現場のsoftwareとpolicyの責任が見えなくなる。

今回のニュースは「暗号が失敗した」ことではない。LACNICが、局所的で版依存の挙動が運用結果を変える場面を、比較可能な形で示したことにある。三つの動詞はそろった。次に必要なのは、それぞれが成立した版と設定である。

情報源