BGP セキュリティ：RPKI と経路の発信元検証

なぜ BGP は騙されるのか

BGP には致命的な前提があります。ある AS が「このプレフィックスは私が発信元だ」と広告したとき、その主張が正しいかを誰も検証しないのです。BGP の経路選択 は届いた複数経路から1本を機械的に選びますが、選ぶ材料（AS_PATH 長や LOCAL_PREF）はどれも「広告内容が真実である」ことを暗黙に信じています。つまり BGP は信頼ベースのプロトコルで、認証は標準では存在しません。

この穴を突くのが経路ハイジャックです。攻撃者（または設定ミスをした AS）が、自分のものでないプレフィックスを自 AS 発信として広告すると、その経路が周囲に伝播し、トラフィックが本来の所有者でなく攻撃者へ吸い込まれます。さらに該当プレフィックスよりより長いプレフィックス（more-specific）を広告すれば、最長一致 の原理で必ず勝つため、被害は局所的どころか世界規模に広がりえます。歴史的には誤設定による事故が大半ですが、結果は盗聴・遮断・なりすましと同じです。

RPKI が証明したいもの

RPKI（Resource Public Key Infrastructure）は、この「広告主張の真偽」のうち最も基本的な一点＝発信元 AS が正当かを暗号的に検証可能にする公開鍵基盤です。守るのは経路情報の機密性ではなく、IP アドレス資源の所有という事実の真正性です。発想は DNSSEC の信頼チェーン と同型で、上位機関が下位に「この資源を割り当てた」と署名付きで保証し、それを起点まで遡って検証します。

信頼の階層は資源の割り当て構造そのものに乗ります。

IANA（ルートに相当）
  └ RIR（APNIC / ARIN / RIPE NCC など 地域レジストリ）
      └ LIR / ISP（実際にアドレスを使う組織）
          └ ROA（プレフィックス↔発信元AS の署名済み宣言）

各段は リソース証明書（RFC 3779 拡張付き X.509 証明書） を持ち、自分が保有する IP プレフィックスと AS 番号の範囲が証明書に記載されます。親はその範囲内でしか子に証明書を発行できないため、所有関係が証明書チェーンとして暗号的に裏打ちされます。証明書の扱いは TLS と同じ X.509 ですが、ここで束ねるのは「身元」ではなく「IP/AS 資源の保有」です。

ROA：正当な発信元の暗号証明

検証の核になるのが **ROA（Route Origin Authorization）**です。ROA は「このプレフィックスを、この AS が、この最大長まで発信してよい」という宣言を、保有者のリソース証明書の秘密鍵で署名したオブジェクトです。論理的な中身は次の三つ組です。

maxLength が要点です。203.0.113.0/22 に対し maxLength を 22 のままにすれば、/23 や /24 への分割広告は許されません。逆に maxLength を不用意に大きく（例 24）すると、攻撃者が許容範囲内の more-specific を出して正当な ROA を盾に取った乗っ取りを許す隙になります。原則は「実際に広告する最小限の長さに maxLength を絞る」ことです。

検証フロー：RP から ルータまで

ROA は署名オブジェクトであって、ルータが直接 BGP 中で受け取るものではありません。検証は二段に分かれます。

第一段は RP（Relying Party／Validator） が担います。RP は各 RIR が公開する RPKI リポジトリ（rsync / RRDP で配布）から証明書と ROA を集め、チェーンと署名・有効期限・失効を検証し、妥当な ROA だけを抽出します。検証済みの結果は VRP（Validated ROA Payload）、すなわち (Prefix, maxLength, Origin AS) の一覧へと正規化されます。

第二段で、ルータが RPKI-to-Router（RTR）プロトコル を通じて RP から VRP の集合を受け取り、受信した各 BGP 経路を突き合わせて判定します。判定は三値です。

classify(route): route = (prefix P, origin AS A)
  該当VRPなし（Pを覆う Prefix を持つ VRP が一つも無い）:
      return NotFound        # 未署名。ROA 未登録の領域
  覆う VRP が存在する:
      if ∃ VRP s.t. P が VRP.Prefix に含まれ
                    Pの長さ ≤ VRP.maxLength かつ A == VRP.Origin AS:
          return Valid       # 正当な発信元の経路
      else:
          return Invalid     # 覆う VRP はあるが AS か長さが不一致

肝は Invalid と NotFound の違いです。NotFound は「まだ ROA が無い」だけで悪性とは限りません。一方 Invalid は「ROA が存在し、その内容と矛盾する」状態で、発信元なりすましの強いシグナルです。世界の経路の多くは依然 NotFound なので、NotFound を落とすと通信が壊れます。だから運用は Invalid だけを落とす（drop-invalid） のが定石です。

実装上は判定結果を 経路伝播ポリシー に組み込みます。多くは route-map で「Invalid を reject、Valid に高い LOCAL_PREF」を与え、ROA で守られた経路を選択順位でも優先させます。判定は経路選択の前段フィルタとして効くのが特徴です。

ここまでが限界：RPKI が守れないもの

RPKI 発信元検証は強力ですが、守備範囲は狭く深い点を正確に押さえる必要があります。検証しているのは AS_PATH の最初の1ホップ（発信元 AS）だけで、パス全体の真偽ではありません。

具体的に、RPKI が無力な代表例は次のとおりです。

• AS_PATH 偽装型ハイジャック：正規の発信元 AS を末尾に偽造して付与すると、発信元としては Valid。長さや経由は嘘でも origin 検証は通る。
• 経路リーク：本来流すべきでない経路を誤って隣接へ広告する事故（Gao-Rexford ルール 違反）。発信元 AS は正しいので RPKI では一切検知できない。
• データ面の改ざん：RPKI は制御面（広告）の検証であり、転送中のパケットそのものは守らない。

これらを埋めるために登場するのが、AS 間の「この AS はあの AS を上流として持ってよい」という関係を署名する ASPA（Autonomous System Provider Authorization）（リークやパス偽装の一部を検知）と、AS_PATH の各ホップを署名で連鎖検証する BGPsec です。BGPsec はパス全体を守れますが、各ルータが経路ごとに署名・検証する負荷が重く、普及は限定的です。現実の防御は「RPKI/ROV で発信元を固め、ASPA でパスを補い、ピアリングのフィルタや IRR で多層化する」という積み重ねになります。

一段で言うと

RPKI 発信元検証は「プレフィックスと正当な発信元 AS の対応を、資源保有を裏打ちする証明書チェーンで署名（ROA）し、ルータが受信経路と突き合わせて Invalid を落とす」仕組みです。これで「他人の IP を勝手に名乗る」最も古典的なハイジャックは塞げますが、検証対象は発信元 AS の1点に限られ、AS_PATH 全体や経路リークは守れません。実機では RP（routinator など）が出す VRP と、ルータの show ip bgp 上の RPKI 状態（valid/invalid/not-found）を突き合わせ、どの経路がどの判定で落ちたかを必ず裏取りしてください。発信元を固めたうえで、パスの防御は別レイヤで重ねるのが正しい設計です。