BGPルートリークとハイジャック

二つの事故は原因が違う

BGP の大規模障害は「経路ハイジャック」と「ルートリーク」という別々の名前で語られますが、この二つは原因も検知手段も異なります。ハイジャックは発信元 AS の詐称、リークは発信元は正しいのに伝播ポリシーを破って広く撒いてしまう事故です。RPKI 発信元検証 が前者にしか効かないのはこの違いに起因します。両者を区別せずに対策を語ると、片方しか守れていないのに安心してしまう典型的な穴になります。

ハイジャックのパターン分類

経路ハイジャックは「自分でないプレフィックスを自 AS 発信として広告する」点で共通しますが、実害の出方で型が分かれます。

• 完全奪取型：被害プレフィックスと同じ長さで広告する。BGP経路選択 の優先順位（AS_PATH長やLOCAL_PREF）で正規経路と競合し、勝った範囲だけ吸い込む。伝播が限定的なら被害も局所的。
• more-specific型：被害プレフィックスより長いプレフィックスを広告する。最長一致 の原理により、伝播が届いた場所では例外なく攻撃側が勝つ。2008年のYouTubeプレフィックスハイジャック事件はこの型で、本来一部地域向けの広告のはずが全世界に伝播し、YouTube自体が長時間到達不能になった。
• AS_PATHごく短縮型：中間のASを経由しているように装いつつAS_PATHを短く見せる、あるいは正規の発信元ASを末尾に付けて発信元検証だけは通す。ROVがValidと判定してしまう最も厄介な型。

ルートリークの分類（type 1〜4）

RFC 7908 はルートリークを、誰から学んだ経路をどの関係の相手へ渡したかという伝播ポリシー違反の形で分類します。BGP伝播ポリシー で述べたGao-Rexfordルールの違反パターンそのものです。

type 1: ピア/プロバイダから学んだ経路を別のピア/プロバイダへ広告
        （本来カスタマにしか流してはいけない経路を横に漏らす）
type 2: プロバイダA経由で学んだ経路をプロバイダBへ広告
        （複数上流を持つカスタマASが誤ってトランジットの真似をする）
type 3: 内部の機器設定ミスで、フィルタ対象外の全経路を隣接へ広告
type 4: 意図的なトラフィック誘導のためのリーク（悪用目的）

最も多いのが type 1 と type 3 で、いずれもマルチホームAS（複数のISPと契約するAS）が、片方から受け取った経路をもう片方へそのまま流してしまう設定ミスです。2019年のCloudflare関連障害（Verizon経由でDQEの経路が誤って世界に広がった事例）はtype 1の典型で、本来カスタマ向けのはずの経路がプロバイダ間トランジットのように大量に伝播し、広範な到達性障害を引き起こしました。

RPKI/ROVで防げる範囲と防げない範囲

RPKI発信元検証 はROAという署名済みの(Prefix, maxLength, Origin AS)を根拠に、受信経路をValid/Invalid/NotFoundへ分類します。これが有効なのは発信元詐称型ハイジャックだけです。

攻撃/事故のタイプ           ROVでの見え方
完全奪取型ハイジャック   →  Invalid（発信元AS不一致）で検知可能
more-specific型          →  maxLengthを絞っていればInvalidで検知可能
AS_PATH末尾偽装型        →  Valid（発信元だけは正しいので見抜けない）
ルートリーク（type1-3）  →  Valid（発信元は正しいので見抜けない）

ここが実務でよく誤解される点です。「ROVを入れたから経路事故は防げる」という理解は半分しか正しくありません。ROVは発信元という入口の1点しか検証しないため、BGPsec が対象とするAS_PATH全体の真正性や、伝播ポリシー違反であるルートリークには無力です。ASPA（Autonomous System Provider Authorization）はAS間の正当な上流関係を署名し、type 1/2 リークの一部（本来ありえない上流関係の経路）を検知できますが、普及はまだ限定的です。

フィルタリングのベストプラクティス

実運用でリークとハイジャックの双方を抑えるには、ROVだけに頼らず複数層のフィルタを重ねます。

実務上の基本形は、カスタマ収容セッションにはIRR由来のprefix-filterを自動生成して適用し、上流（プロバイダ・ピア）セッションにはmax-prefixとROV drop-invalidを両方かけるという組み合わせです。IXPの多くがルートサーバでこの種のフィルタを標準提供しているのも、type 1/3 のリークが「ピアの先のピア」という到達範囲を経由して急速に広がるためです。

検知の限界

ここまでの対策を重ねても、検知には構造的な限界が残ります。第一に、ROVもASPAも制御面（経路広告）の検証であり、転送面で実際にパケットがどこを通ったかは保証しません。経路上はValidでも、途中のASがトラフィックを盗聴・改ざんしていないかは別問題です。第二に、BGPの収束 には時間がかかるため、ハイジャックやリークが観測・是正されるまでに数分〜数十分の伝播が先行し、その間の実害は防げません。第三に、外部からの検知（RIPE RISやBGPStreamのような経路モニタリング）は「いつもと違うAS_PATHやOrigin ASが出現した」という異常検知に頼る部分が大きく、巧妙にAS_PATHを偽装されると異常として浮かび上がりにくくなります。

一段で言うと

経路ハイジャックとルートリークは、どちらも「BGPが広告内容の真偽を検証しない」という同じ根本原因から生まれますが、ハイジャックは発信元の嘘、リークは伝播範囲の誤りという別の症状です。RPKI/ROVは前者の入口だけを暗号的に塞ぎますが、AS_PATH偽装やリークには手が届かず、IRRベースのフィルタ・max-prefix・ASPAといった複数の層で補う必要があります。実機では経路モニタリング（RIPE RIS、BGPStream等）で自組織プレフィックスのOrigin ASとAS_PATHの異常を継続的に観測し、show ip bgpのRPKI状態と組み合わせて、どの層で何を検知できて何を検知できていないかを常に切り分けて運用してください。