BGPsec とパス検証：経路全体の真正性

RPKI が残した穴：パスは誰も保証しない

RPKI の発信元検証 は「このプレフィックスを発信してよい AS はどれか」を ROA で暗号的に固めます。しかし守るのは AS_PATH の 先頭1ホップ（発信元 AS）だけで、そこから先のパスがどう構成されたかは一切検証しません。

ここに致命的な隙が残ります。攻撃者が正規の発信元 AS 番号を AS_PATH の末尾に偽装して付ければ、発信元としては ROA と矛盾せず Valid のまま経路を乗っ取れます（path manipulation）。あるいは存在しない隣接関係をでっち上げて、実際には通っていない AS を経由したと偽る短経路を広告すれば、BGP の経路選択 は AS_PATH 長を信じて攻撃者の経路を選んでしまいます。発信元が正しくても、経路そのものが嘘ならハイジャックは成立するのです。

BGPsec（RFC 8205）はこの穴を埋めます。狙いは一点、「広告された AS_PATH が、本当にその AS の列を順番どおりに通って伝播したものか」を暗号的に証明可能にすることです。

着想：転送のたびに署名を1段積む

BGPsec の核心は、各 AS が経路を隣接へ転送するとき 自分の署名を1つ追加する ことです。通常の AS_PATH が AS 番号を継ぎ足していくのと並行して、BGPsec は署名のリスト（BGPsec_PATH 属性内の Signature_Block）を継ぎ足します。結果として、経路が originAS → AS1 → AS2 → 受信者 と流れれば、署名も同じ順に3段積まれます。

通常のAS_PATH:   [ AS2, AS1, originAS ]   ← 番号だけ。誰でも捏造可能

BGPsec_PATH:
  Secure_Path:    AS2 → AS1 → originAS    ← 各ASの pCount 等
  Signature_Block:
    sig(originAS, 宛先=AS1, originの鍵で署名)
    sig(AS1,      宛先=AS2, AS1の鍵で署名)
    sig(AS2,      宛先=受信者, AS2の鍵で署名)

各署名に使う鍵は、RPKI が発行する ルータ証明書の秘密鍵です。RPKI は ROA で「IP/AS 資源の保有」を裏打ちしますが、BGPsec ではこれを拡張し「この AS 番号を名乗るルータの公開鍵」を証明書チェーンで保証します。検証側は受信した署名を、各 AS のルータ証明書（公開鍵）で1段ずつ確かめます。署名に使う鍵が資源証明書チェーンに根を持つ点は TLS と同じ X.509 ですが、束ねるのは「身元」ではなく「AS 資源の保有」です。

署名が守るもの：宛先 AS を巻き込む鎖

ただ AS 番号に署名するだけでは不十分です。攻撃者が正規経路から有効な署名を1つ抜き取り、別の偽経路に貼り付ける 再利用攻撃 が成立してしまうからです。BGPsec はこれを「署名対象に 次に渡す相手の AS 番号 を含める」ことで封じます。

この設計から二つの保証が生まれます。ひとつは 順序の保全で、各署名が前段までを覆うため、途中の AS を抜いたり順番を入れ替えたりすると鎖が壊れます。もうひとつは 隣接関係の真正性で、宛先 AS を署名に含めるため「AS1 が確かに AS2 へ渡した」という事実が暗号的に記録されます。攻撃者は自分の秘密鍵を持たない AS の署名を作れないため、存在しない経由を捏造できません。

検証手順：末尾から起点へ鎖をほどく

受信側ルータは BGPsec_PATH を受け取ると、署名を 新しい方（直前のホップ）から発信元へ向かって 1段ずつ検証します。

verify(bgpsec_path, 自AS):
  segs = Secure_Path の AS 列            # 末尾=自分の隣, 先頭=originAS
  sigs = Signature_Block の署名列         # segs と一対一
  target = 自AS                          # 最初の宛先は受信者である自分
  for i in (隣のAS から originAS の順):
    cert = RPKIから segs[i] のルータ証明書(公開鍵)を取得・チェーン検証
    if cert 無効:           return Invalid   # 鍵が資源証明書チェーンに根を持たない
    msg = (前段までの BGPsec_PATH 内容) ++ target  # 署名が覆った対象を再構築
    if not verify_sig(sigs[i], msg, cert.公開鍵):
        return Invalid       # 署名が壊れている/順序が違う/宛先が合わない
    target = segs[i]         # 次段の宛先は、いま検証したAS
  return Valid               # 全ホップの署名が起点まで連鎖した

全段の署名が起点まで途切れず検証できて初めて Valid です。一段でも壊れていれば Invalid。発信元検証が三値（Valid / Invalid / NotFound）だったのに対し、BGPsec のパス検証は本質的に二値で、「鎖が完全に繋がったか否か」を問います。

なお BGPsec が守るのはあくまで 制御面（広告された経路情報）の真正性です。実際に転送されるパケットが本当にその経路を通る保証ではありません。発信元検証と同様に、データ面の保証は別問題です。

なぜ展開が進まないのか

原理は明快ですが、BGPsec の実運用はほとんど進んでいません。理由は性能と展開の両面にあります。

第一に 計算コスト です。署名生成・検証は経路1本ごと、ホップ1段ごとに発生します。フルルートは数十万経路規模で、しかも経路が更新されるたびに署名し直しが要ります。ROV が静的な VRP との突き合わせで済むのと比べ、桁違いに重い処理です。

第二に 経路集約との非互換 です。BGPsec の署名は具体的な AS_PATH を1本ずつ覆うため、複数経路を1つに束ねる CIDR の経路集約 や、AS_PATH を畳む最適化と本質的に両立しません。署名された経路はそのままの形で運ぶしかなく、テーブル肥大やメモリ消費を悪化させます。

第三に 増分配備の弱さ です。これが最大の障壁です。

そのため現実の防御は、まず RPKI/ROV で発信元を固め、隣接関係の正しさは ASPA（Autonomous System Provider Authorization） で軽量に補い、ピアリングの 経路伝播ポリシー によるフィルタや IRR で多層化する、という積み重ねが主流です。ASPA は「この AS はあの AS を上流に持ってよい」という関係だけを署名する設計で、経路ごとの動的署名が不要なため、BGPsec より遥かに軽く展開しやすい。パス全体の完全な暗号保証は BGPsec の理想ですが、当面はこの軽量な近似が現実解になっています。

一段で言うと

BGPsec は「各 AS が経路を転送するたびに、前段までの内容と次の宛先 AS をまとめて自分の鍵で署名し、受信側が末尾から起点まで署名連鎖を検証する」ことで、RPKI が守れなかった AS_PATH 全体の真正性を保証します。宛先 AS を署名に巻き込むことで署名の流用を封じ、順序と隣接関係を暗号的に固定するのが要諦です。一方で経路ごと・ホップごとの署名は計算コストが重く、経路集約と両立せず、しかも全 AS が対応しないと鎖が途切れます。この「全員揃わないと効かない」性質ゆえ実運用はほぼ進まず、現実には ROV で発信元を固め、ASPA とフィルタでパスを軽く補う多層防御が選ばれています。