要約

  • ASPA は顧客 AS がプロバイダー AS の集合を認可する署名付き RPKI オブジェクトであり、検証アルゴリズム向けの関係表明であって経路全体の逐次署名ではない。
  • 検証結果は利用可能なオブジェクトと伝播文脈に応じて Valid、Invalid、Unknown となる。起点検証、実在身元、事業者のローカル方針を置き換えない。
  • 運用ではオブジェクトの妥当性、集合の完全性、キャッシュ時刻、セッション役割、結果、ローカル措置、不確実性を分けた台帳が必要になる。

「Valid」は完全な保証のように見える。しかし ASPA で意味するのは、観測したパスが、関連方向で評価可能な顧客・プロバイダー認可と整合するという限定的な結論だ。経路の全ホップが署名したという意味ではない。

現在の ASPA profile はまだ Internet-Draft である。顧客 AS 番号の保有者が認可済みプロバイダーを列挙する RPKI 署名オブジェクトを定義し、全プロバイダーを一つの ASPA に含めることを想定する。Relying Party は内容を使う前にオブジェクトを検証する。

したがって答える問いは「この顧客 AS は公開データ上でこのプロバイダー AS を認可したか」である。広告プレフィックスは含まれない。ROA に基づく経路起点検証とは対象が異なり、両者は補完関係にある。

署名は現実世界の身元も認証しない。RFC 9255 は RPKI の I が Identity を意味しないと明記する。有効な認可から、現在の商取引契約、登録内容の正確性、特定リンクでのトラフィック交換まで推定することはできない。

完全性も重要な境界である。検証草案は顧客 AS に全プロバイダーと関係する非透過ルートサーバーの登録を求める。正当なプロバイダーを漏らせば、普及後に正しい経路が Invalid と判定され得る。暗号学的に正しくても、維持された宣言が不完全な場合がある。

関係判定には Provider+、Not Provider+、No Attestation があり、パス判定には Valid、Invalid、Unknown がある。Unknown は弱い Invalid ではなく、結論に必要な表明が不足している状態だ。一方 Valid も、起点認可、全 AS の署名、すべての輸出方針の順守を証明しない。

ASPA と BGPsec の証拠意味は異なる。ASPA は別々に公開されたプロバイダー認可とパスを照合し、ホップごとにパスを署名する仕組みではない。順序も不可欠である。RFC 9774 が廃止方向を示す AS_SET と AS_CONFED_SET は順序を持たず、顧客・プロバイダー方向を復元できない。

RFC 9234 の BGP Roles はセッション関係と経路漏えい判断の文脈を与えるが、ネゴシエートされた能力は普遍的な商取引台帳ではない。受信事業者が到達性、普及率、例外と組み合わせて運用判断を行う。

監査可能な台帳は、検証済み ASPA、プロバイダー棚卸しの完全性証拠、キャッシュ観測と時刻、順序付きパスと役割、理由付き結果、ローカル措置と期限を別レコードとして保持する。金曜のプロバイダー追加、土曜の ASPA 更新、日曜のキャッシュ更新は異なる状態である。

引用した草案は RFC 化までに変わり得る。また本稿は特定の事業者や事故を主張しない。長く通用する原則は、ASPA を限定されたプロバイダー認可として扱い、妥当性、完全性、利用を別々の証拠として残すことである。

出典