要約
draft-sriram-savnet-intrasav-solution-00は、経路広告するプレフィックスと送信元にだけ使うプレフィックスを顧客が明示し、CE の各インターフェースへ許可リストを作る方法を提案する。- 誤遮断・誤許可がゼロという記述は、設定情報が完全であることを条件にする。Revision 00 は正しい世代が正しい実行点へ届いたことを証明する仕組みまでは定義していない。
顧客 2 は r を広告し、s は広告せず送信元だけに使う。Configuration Manager が作る集合は {r, s}。モデル上は完全で、正当なパケットを落とさず、偽装された送信元を通さない。
しかし、その集合が配布される途中で顧客が別ポートへ移ったらどうなるか。一台は新世代をコミットし、もう一台は旧世代で再起動する。中央の答えは正しいまま、パケットを扱う現場の答えだけが分かれる。
この実行境界を可視化するのが IntraSAV - A Solution for Intra-Domain Source Address Validation の運用上の意味である。00 版は 2026 年 10 月 1 日に提出された。想定ステータス Best Current Practice、状態 I-D Exists の個人 Internet-Draft であり、SAVNET 採択、RFC、IANA 処理、実装報告、導入測定ではない。承認された場合に BCP 38 と BCP 84 を更新するのであって、現時点では更新していない。
FIB に送信元の権限は書かれていない
Strict uRPF は、送信元へ戻る経路が受信インターフェースと一致するかを見る。非対称経路やマルチホームでは、正当なトラフィックまで落とし得る。Loose uRPF は経路の存在だけを見るため誤遮断を減らす一方、方向性を失って偽装を許しやすい。ACL は精密でも、許可プレフィックスが変わるたびに保守しなければ古くなる。
根本には質問の違いがある。FIB は宛先へどう到達するかを表す。ある主体がそのアドレスを送信元に使ってよいかは表さない。Direct Server Return では、エッジが広告していない anycast サービスアドレスを送信元にして応答することがある。経路が見えないことは、不正の証拠ではない。
IntraSAV はその権限をローカル設定へ移す。BYOIP 顧客が、各インターフェースで経路広告するプレフィックス、送信元に使うプレフィックス、その両方を申告する。ローカル AS も自分のプレフィックスについて同様に記録する。Configuration Manager と任意の SAV Agent が情報を統合し、CE インターフェースごとの allowlist を作る。
草案の顧客 1 は {p, q} を両方広告する。顧客 2 は {r, s} を登録し、r だけを広告する。だからインターフェース 1 は {p, q}、2 は {r, s} を受け取る。経路表が隠していた正当な s の利用を、初めて直接表現できる。
ROA の一致はローカルな実行を証明しない
草案は、プレフィックス所有者がローカル AS を origin とする ROA を作るよう勧める。ただしローカルな経路起点と SAV では、ローカル設定を ROA より優先する。遠隔 AS が ROA を使って inter-domain SAV を計算するため、不一致は顧客に通知する。
ここには二つの依存面がある。ローカル設定は顧客、プレフィックス、インターフェース、用途を結ぶ。ROA は外部に origin authorization を示す。一致は整合性を高めるが、申請者の権限、現在のポート所有、ルール配布、ハードウェア実行を証明しない。
Configuration Manager は顧客を認証すると書かれているものの、登録プロトコル、資格情報の範囲、変更承認、失効、リプレイ防止、トランザクション ID は未定義だ。実装選択をローカルに残すことと、監査可能な受領記録を残さないことは別である。
ゼロを支えるのは「完全」という条件
文書は、Manager の設定情報が完全なら、IntraSAV は improper block と improper admit をゼロにできると述べる。集合モデルでは明快だ。そのポートで正当な送信元をすべて含み、それ以外を含まなければ分類は正しい。
問題は、完全性をどう確かめるかである。Revision 00 は設定世代、発効時刻、対象装置一覧、アトミックな置換、配布確認、ロールバックを定義しない。追加、削除、ポート移動、再起動、コントローラー分断の途中状態も定めない。
その結果、正しい計算と不整合なネットワークが同時に存在できる。ソフトウェア RIB にはルールがあり ASIC にはない。旧ポートに許可が残る。新しい送信元専用プレフィックスが一部 CE だけで遮断される。計算が誤っていなくても、パケットの結果は誤り得る。
運用上の「ゼロ」には分母が要る。権限あるプレフィックス・インターフェース組の総数、全実行点の期待世代とコミット世代、正当・偽装のラベル付きパケット、proper/improper の permit/block 四分類を記録して初めて観測になる。
ASBR の和集合は細かな帰属を消す
草案は “To be Discussed” として、ASBR の Interface 3 に {p, q, r, s} の和集合を置く案も示す。CE をすべて更新するより ASBR 一台を更新しやすく、ローカル AS 由来の既知プレフィックスしか届かないとトポロジーから確信できる場合を想定している。
本文自身が、ASBR がホストや非 AS 顧客を直接収容する場合を除き、問題定義の範囲を越える可能性を認める。和集合は s が AS 内のどこかで許可されていることを示せても、顧客 2 の Interface 2 から来るべきことを示さない。集約防御と顧客別の拘束は同じ保証ではない。
段階導入の評価も、設定済みポート率だけでは足りない。閉じた攻撃経路、影響を受けた正当フロー、例外、未導入ポートからの迂回を測って初めて、部分導入の利益が分かる。
パケットを裁いた世代を記録する
堅牢な運用では、顧客認証、プレフィックス・ポート・用途の権限、版付き設定の受理、ROA 照合、リスト計算、対象装置への配布、コミットまたは拒否、パケットカウンター、ラベル付き誤差試験、サービス結果を別々の証跡にする。
Heng Lu の最小初期仕様は、各運用者に同一コントローラーを強いない。稼働コード優先の原則は、実行面だけを観測可能にする。設定ダイジェスト、インターフェース別世代、コミット確認があれば、ローカルな判断を世界共通の権威にせず検証できる。
IntraSAV の価値は、経路だけから送信元権限を推測するのをやめたことにある。その明示的な真実をパケット処理まで保つことが次の仕事だ。コントローラー内の完全なリストは、証明の終点ではない。
出典
- SAVNET ドメイン内問題定義
- IntraSAV 現行 Datatracker
- IntraSAV Datatracker 履歴
- Minimum Initial Specification and Voluntary Adoption
- Running-Code Primacy
- SAVNET ドメイン間問題定義 21 版
- SAVNET ドメイン内問題定義 26 版
- BAR-SAV 10 版
- IntraSAV 00 版テキスト
- IntraSAV 00 版 XML
- RFC 2119
- RFC 2827:Network Ingress Filtering
- RFC 3704:マルチホーム向け Ingress Filtering
- RFC 8174
- RFC 8704:Enhanced Feasible-Path uRPF
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加

