要約

  • 2025年の事例で、SEACOMのlooking glassはSingNetを正当な起点とする203.127.0.0/16を示し、Innoveが起点の203.127.225.0/24は示さなかった。しかし同じ網からのtracerouteはInnoveのAS内とみられるホップに達した。
  • ROVによるInvalid判定と破棄は、自網の受信経路に対する判断である。隣接ASがより具体的な経路を受け入れるかどうかは決められない。
  • BMPは監視対象ルーターのBGP情報を運ぶ。対象外の隣接網の選択や、実際のパケット転送をそのまま映す装置ではない。

空の検索結果は、何を証明したか

SEACOM（AS37100）のlooking glassで203.127.225.0/24を照会すると、結果は「Network not in table」だった。一方、広い203.127.0.0/16にはSingNet（AS3758）を起点とする有効な経路がある。李琦らのInternet-Draftは両方の出力を付録に載せる。狭い経路の起点はInnove Communications（AS17894）で、研究者はROVを使うSEACOMがこれを除外したと説明する。

ところが同じSEACOM側から203.127.225.1に向けたtracerouteでは、TISparkle（AS6762）、FLAG Telecom（AS15412）、Globe Telecom（AS4775）を経て、AS17894に属するホップが現れた。局所的な経路表に/24がないという事実と、その先の網が/24を使うという事実は両立する。前者だけで「この宛先への通信は安全」と結論すれば、観測対象を取り違える。

草案の著者は2025年2月10日にGlobeへ報告し、4月24日を最後の観測日とする。関係企業の接点から、悪意より設定ミスの可能性を挙げている。個人提出の草案であり、IETFが承認した標準ではない。提示されたtracerouteは一時点・一宛先の経路証拠として重要だが、全利用者の通信量やアプリケーション到達性までは測っていない。

APNIC 62のセッション記事によると、NokiaのRitesh Mukherjeeはこれを「良い隣人」の問題として取り上げた。発表資料が示す防御策は複数あるが、各策が答える問いを切り離すことこそ、現場で使える教訓になる。

次のASで最長一致が働く

SingNetの/16は正当な起点を持つ。Innoveが広告した/24は、その範囲の起点認可に合わない。RFC 6811は検証済みROAに照らしたValid、Invalid、NotFoundを定義するが、Invalidをどう扱うかは受信ASのポリシーだ。SEACOMは/24を除外し、/16に基づく次ホップとしてAS6762へパケットを送れる。AS6762が/24を受け入れていれば、その地点ではより長いプレフィックスが優先され、転送先が変わる。SEACOMのROVが誤動作したという話ではない。

同じ発表のTelegram事例は、別の証拠を持つ。2026年6月16日、TelegramのアドレスにAS18101を起点とする広告が現れた。BGPHorizonの記録は91.108.4.0/22について07:17:27 UTCの検出、通常の起点AS62041、4つのピア網と5つの収集点による観測を示し、後のより具体的な広告も列挙する。ROAと異なる起点は検証できる。だが公的な収集点は経路の一部しか見ず、被害者数や広告した側の意図を確定しない。Vodafone Ideaの2021年の大量広告は、単一の偽/24とは異なり、ピア当たりの受信プレフィックス上限という量の制御も問う。

BMPが見られないもの

MukherjeeはAdj-RIB-InのBMP収集とNokiaのRAVENを提案した。RFC 7854では、設定したピアについてポリシー適用前後の受信経路をスナップショットと更新として送れる。前段の記録があれば、後段で拒否した広告を確認できる場合がある。ただし監視対象のピアは限定でき、途中の変化は圧縮され得る。時刻情報が得られない場合もある。SEACOMに届かなかった経路がAS6762にだけ届いたなら、SEACOMのBMPを増強しても隣の受信表は現れない。

また、BMPはパケットの通過証明ではない。隣の選択経路、FIB、能動的な経路追跡を別々に確かめる必要がある。RAVENの公開リポジトリは機能を説明するが、当該網への導入や防御効果の実測ではない。スライド中の出力も実演ではなく例示と明記されている。収集器の「異常検出」を転送結果と同一視してはならない。

RFC 7454の最大プレフィックス数は、想定量と増加余地に合わせて設定する大量広告対策であり、一つの不正/24の正当性を判定しない。ASPAによる経路検証は提供者関係を扱う進行中の草案で、2025年の事例が既にそれで防がれた証拠ではない。起点判断、量の抑制、隣接網の選択、実際の転送は、それぞれ別の記録を要する。

根拠の範囲

中心となるlooking glassとtracerouteは李らの草案第4節と付録Aにある。APNICの記事とスライドは発表の位置付けを、BGPHorizonはTelegramの別個の経路観測を示す。技術上の境界はRFC 6811、7854、7454による。全通信の損失、意図、現在の普及率、製品の実効性はこれらからは確定できない。