要約
- ASPAは顧客ASが署名した提供者集合からAS_PATHの形を検証するが、その集合はIPv4/IPv6ユニキャストで共通であり、個別契約や稼働中セッションの証明ではない。
- 第28版はUnknownをValidと同じ優先度で扱い、Invalidを選択不能にしつつAdj-RIB-Inへ保持する。いずれも経路選択、FIB投入、配送結果とは別の証拠である。
一つの集合に二つの家族
U-SPASは、顧客ASについて取得できた有効なASPAの提供者集合をまとめたものだ。検証手順はこの集合をIPv4とIPv6の双方で用いる。提供関係が一方のアドレスファミリーにしか存在しなくても、もう一方の判定も同じだけ寛容になる。
草案は、登録を単純にし、意図しないInvalidを生まないための合理的な選択だと説明する。重要なのは、仕様が差異を証明したのではなく、差異を署名データの外に置いたことである。Validから「このIPv6セッションにも契約がある」と逆算してはならない。
第28版は2026年8月24日公開、2027年2月25日失効予定のSIDROPS作業部会Internet-Draftである。Datatracker上はWG Consensus: Waiting for Write-Up、IESGはI-D Existsであり、RFCや最終承認、導入効果の証明ではない。
署名されるのは顧客側の主張
ASPA Profileでは、顧客AS番号の保有者が提供者AS番号を列挙する。非透過型ルートサーバがAS_PATHに自身を入れる場合は、そのASNも含める。RPKIは、顧客ASNに対する資源権限を持つ主体が内容に署名したことを検証可能にする。
そこには価格、SLA、アドレスファミリー別条件、現在のBGPセッション状態は入らない。複数の有効なASPAがある場合、集合は和集合になる。移行中の欠落を避ける一方、古い提供者が残れば許容範囲も広がる。
AS0 ASPAは「トランジット提供者がなく、非透過型RSの顧客でもない」という限定的な主張である。到達性、広告の有無、実際の転送を示すものではない。
三値が欠落と否定を分ける
順序付きペア (x, y) に対し、Provider+はyが顧客xの集合にあること、Not Provider+は有効集合があるのに含まれないこと、No Attestationは使えるASPAがないことを表す。
欠落と否定を区別することで、部分導入を障害に変えずに済む。連続する同一ASNを圧縮したAS_PATHについて、各結果から上り坂と下り坂の最小・最大長を求める。
最大でも経路を覆えなければInvalid、最大なら可能だが欠落で最小を確定できなければUnknown、最小が覆えばValidとなる。これは取得済みオブジェクトの下での構造判定であって、UPDATEが実際に同じ順序で流れた証明ではない。
方向も署名オブジェクトの外にある
顧客またはピアから受けた経路には上流用アルゴリズムを使い、提供者から受けた経路には下流用を使う。どちらを選ぶかは検証側のローカル関係設定に依存する。
RFC 9234のBGP RoleはOPENで役割を照合し、選択を自動化できる。それでも、複合関係ではプレフィクスごとに役割が異なり得る。第28版は別セッションまたはプレフィクス別選択を勧め、難しい場合は誤検知を避けるため下流用アルゴリズムを許す。
同じAS_PATHでも入力役割が違えば状態は変わる。したがって監査記録には、隣接AS、Role、AFI/SAFI、対象プレフィクスと選択した手順が必要である。
UnknownとValidは処遇だけを共有する
推奨ポリシーではUnknownをValidと同じ優先度に置く。署名データが足りない経路を一律に不利にしないためである。Unknownの証拠がValidへ昇格したわけではない。
Invalidは経路選択の候補外にする一方、将来の再評価に備えてAdj-RIB-Inへ残す。ASPAの公開、Relying Partyの取得、検証済みデータの転送、ルータ取込みはBGP UPDATEと別の時計で進む。新オブジェクトだけで状態が変わり得る。
その後もBGPの選択、Loc-RIB、FIB、パケット転送がある。同じ優先度は同じ勝者を意味せず、Validも配送完了を意味しない。
誤りは左右対称ではない
誤って提供者を追加すると検出力が弱まる。実在する提供者を削ると正当な経路が将来Invalidになり得る。DDoS対策などの待機提供者は、使用前に登録することが推奨される。CA移行中は両方の登録を同一に保つ必要がある。
ここで必要なのは「現在のオブジェクトは有効」という一点ではない。変更前後の内容、ハッシュ、公開時刻、検証時刻、ルータ反映時刻をつなぐことで、どの判断がどの証拠に基づいたかを復元できる。
Invalid時にはNot Provider+となったホップを記録すべきだが、記録したルータが漏洩を起こしたASを特定できるとは限らない。矛盾の場所は責任帰属ではない。
他の保護を吸収しない
ROAはプレフィクス起源を許可する。ASPAは顧客—提供者関係から経路形状を検査する。BGPsecは署名された伝播履歴を与えるが、valley-free違反そのものを検出しない。OTCはASPAが捉えられないローカルな誤配布を抑える。
提供者による一部の経路操作はASPAで検出できず、AS prependの重複追加・削除も判別できない。Validは「全ASが正直」「実パケットも同じ道を通った」という証明ではない。
証拠連鎖には、草案版、ASPA内容と証明書、配布スナップショット、ローカルRole、元のAS_PATHと再構成・圧縮結果、各ペアの三値、坂の境界、最終状態、適用ポリシー、Loc-RIB/FIB、トラフィック観測が必要である。
Lu HengのRunning-Code Primacyに従えば、公開された署名記録は限定された主張にのみ権威を持つ。実行コードとローカル判断、観測された結果は別の主体が生む。強い仕組みとは、その境界を隠さない仕組みである。
情報源が証明しないこと
凍結資料は仕様案と明記された制約を示す。特定実装の適合性、世界的導入率、実際の漏洩阻止、IPv4/IPv6契約の同一性は示さない。本稿はその不足を推測で埋めない。
情報源
- Datatracker — ASPA検証 第28版
- Datatracker — ASPA検証の履歴
- Datatracker — ASPA Profile 第29版
- RFC 9234 — BGP RoleとOnly to Customer
- RFC 4271 — Border Gateway Protocol 4
- RFC 9324 — Route Refreshを要しないRPKIポリシー
- RFC 9582 — ROA Profile
- RFC 9774 — AS_SETとAS_CONFED_SETの廃止
- RFC 7606 — BGP UPDATEエラー処理
- RFC 6793 — 4オクテットASN対応
- RFC 6480 — RPKIアーキテクチャ
- Lu Heng — Running-Code Primacy
- Lu Heng — On Authority, Belief, and the Internet’s Addressing System
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
