要約

  • RFC 9827 は Transform Type 5 と既存 ID 0、1 の名称を改めるが、AH/ESP の処理も wire 上の bit も変更しない。交渉対象を一般的なシーケンス性質として定義し直す。
  • ID 0 と 1 は、SA 全体で単調増加し、wrap せず、ネットワーク入口で一意な番号を約束する。anti-replay に利用できるが、実際に window を有効にするかは受信側のローカル判断である。
  • 交渉、送信側の割り当て、入口の集約ストリーム、受信観測、認証、window、replay 拒否、IIV/AGGFRAG の安全性は別々の証拠を要する。

名前の変更が仕様の射程を正した

2025 年 11 月に Standards Track として公開された RFC 9827 は、パケット形式を増やす文書ではない。Transform Type 5 の名称を Extended Sequence Numbers から Sequence Numbers へ変更する。ID 0 は No Extended Sequence Numbers から 32-bit Sequential Numbers へ、ID 1 は Extended Sequence Numbers から Partially Transmitted 64-bit Sequential Numbers へ変わった。

既存の意味は維持され、AH と ESP の処理にも変更はない。にもかかわらず、この改名は重要である。旧名称は、交渉を 32 bit と ESN の二択のように見せていた。実際には、Type 5 は番号の論理的な幅、送信される部分、増加、wrap、SA 全体での一意性をまとめた性質を運ぶ場所だった。

IANA の現在の registry は、この広がりを具体化している。RFC 9838 による ID 2 は 32-bit Unspecified Numbers であり、32 bit の field は残るが一意性を保証しない。3–1023 は未割当、1024–65535 は private use である。同じ Type 5 に存在するからといって、各 ID が replay protection に同じ入力を提供するわけではない。

したがって運用確認は「ESN 対応」の表示から始めてはならない。選択された ID、その定義 RFC、保証される性質、保証が終わる地点を保存する必要がある。

保証地点はネットワークへ入る瞬間

RFC 9827 の中核定義は慎重である。Type 5 は、ある IPsec SA のパケットがネットワークに入る時点におけるシーケンス番号の性質を定める。

ここでいう番号は wire 上の 32 bit field だけではない。ID 1 では下位 32 bit のみが送信され、上位 32 bit は受信側が過去の認証済みパケットから再構成する。番号は論理的状態でもある。

また、各 sender の動作ではなく SA のパケット集合に対する性質である。複数 sender、CPU core、NIC queue がそれぞれ正しくローカル counter を増やしても、同じ SA で同じ値を割り当てれば集約結果は一意ではない。局所的な成功ログを足しても、SA-wide の証明にはならない。

入口を過ぎればネットワークが状態を変える。複製は一つの番号を受信側で二回見せる。reordering は増加順を到着順で崩す。loss は gap を作る。二つの capture point は同じ packet を別々に記録できる。受信 capture の重複だけで sender の再利用を断定できない。

この境界は、Heng Lu の running-code primacy と整合する。registry の記述は、検証可能な最小の現実を述べるべきであり、その後の動作や結果を宣言によって作ってはならない。交渉は入口性質を約束し、実装、ネットワーク、受信者はそれぞれの現実を残す。

replay protection に「使える」と「使った」は違う

ID 0 は 32 bit の単調増加 counter で、field に送信され、wrap せず SA 内で一意である。ID 1 は 64 bit の論理 counter で、下位だけを送信し、上位を推定する。同じく単調、一意、非 wrap である。両方とも replay protection に適する。

しかし RFC 4301、4302、4303 は、anti-replay を受信側の SA ごとの任意機能としている。実装は対応しなければならないが、特定 SA で有効にする義務はない。無効なら inbound Sequence Number の replay check は行われない。

有効な場合、receiver は sliding window を持つ。左端より古い値を拒否し、window 内ですでに見た値を duplicate とし、より新しい認証済み値で右端を進める。window size はローカル設定で sender には通知されない。同じ multicast SA の receiver が異なる reordering 許容量を持つことも可能である。

処理順も証拠の一部だ。暗号処理前の preliminary check は安価な拒否に使えるが、integrity が成功する前に window state を確定してはならない。未認証の大きな番号で window を前へ押し、正当な packet を古く見せられるからだ。

ESN では、認証済み履歴が wire にない上位 bit の選択にも必要になる。RFC 9827 は、anti-replay を使わない場合でも ID 1 の受信 packet を正しく処理するには認証が必要だと明記する。認証は SA への帰属を示し、window は新しさを判定する。真正な replay はあり得るため、一つの判定ではない。

IKEv2 の選択は runtime counter を生成しない

IKEv2 は SA payload の proposal と transform を通じて Child SA を作る。RFC 7296 の旧語彙では、通常値と ESN の双方を受け入れる initiator は ID 0 と 1 を提示し、1 だけを提示すれば 32 bit を拒否した。responder の選択が SA の契約となる。

監査では両側の offer、選択値、Child SA、方向、SPI、peer、build、policy version を保持すべきだ。設定上の希望は実際の negotiation result ではない。

さらに選択結果は、複数 core や offload queue の番号配分を実施しない。active/standby の切替で key だけが移り、最新 checkpoint が欠けることもある。再起動で古い epoch に戻ることもある。Transform ID は正しいままでも、入口ストリームは衝突し得る。

必要なのは SA 全体の counter custody である。range reservation、queue ごとの epoch、永続化、failover transfer、overflow 前の rekey を誰が保証するかを記録する。RFC 4303 は multi-sender SA の counter 同期を ESP が提供しないと明記している。

同じ値を二度見ても原因は一つではない

同じ SPI と番号を持つ認証済み packet が二つ見つかったとする。sender reuse、network duplication、二地点 capture、攻撃者による replay の少なくとも四つが考えられる。bytes だけでは選べない。

入口の packet fingerprint、capture location、受信時刻、authentication result、window verdict を結合する必要がある。ID 1 なら推定上位 bit とその根拠となる履歴も要る。replay rejection の receipt は、判定前後の window bounds、old/duplicate/new、最終 disposition を含む。

application effect が一度しかないことも証明ではない。複製がなかった、上流で落ちた、capture が欠けた、window は無効だったが application が一度しか処理しなかった、という可能性が残る。安全動作を主張するには明示的な verdict が必要だ。

implicit IV は番号を暗号資産として使う

RFC 8750 は特定 AEAD の 8-byte IV を packet に載せず、ESP sequence から生成する。IV は同じ key のもとで繰り返してはならない。したがって番号の衝突は、replay window の設定とは独立した暗号上の事故になる。

multi-sender が同じ値を使った後で anti-replay を無効にしても nonce reuse は消えない。RFC 8750 は overlap の可能性がある環境で implicit IV を禁じ、multicast では重複を防ぐ仕組みを要求する。Type 5 の選択、実際の配分方式、key と rekey の境界が一組の safety case になる。

RFC 9347 の AGGFRAG/IP-TFS は別の性質を消費する。inner packet を outer ESP stream の論理順で再構成するため、番号は単に増えるだけでなく後続 packet ごとに厳密に +1 でなければならない。通常 ESP では偶数だけを使うことも許される。all-pad packet や reorder window にも固有ルールがある。

よって ID 0/1 の選択だけでは AGGFRAG を証明できない。連続割当、fragment continuity、rekey で一つの inner packet を二つの SA に分けないことが追加条件である。

ID 2 が古い理解を壊す

RFC 9838 の 32-bit Unspecified Numbers は、multi-sender multicast SA で一意性が期待できないことを member へ伝える。receiver の local choice は残るが、従来型 anti-replay を成立させる入力がない。

結果として、一意性のない SA で implicit-IV cipher は使えず、単一の増加ストリームがない multi-sender SA で AGGFRAG も使えない。field の存在、property contract、local window の enable は別々の事実である。

一つの badge を八つの receipt に分ける

検証可能な主張は、IANA semantics、IKEv2 negotiation、generator ownership、入口の集約性質、receiver policy、認証済み observed packets、replay verdict、dependent-mode compatibility の八段で構成される。

前段の成功は次段の記入ではない。RFC 9827 自身が wire security を変えたとは言わず、名称と意味の範囲を正したにすぎない。その慎重さを運用まで保てば、「適切な番号形式を合意した」と「replay を拒否した」を混同せずに済む。

情報源