要約

  • IKE SAは制御交換を保護し、Child SAはAHまたはESPのトラフィックを保護する。IKE SAのrekeyでは制御用SPI、鍵、メッセージ状態が新しくなるが、勝ち残った後継は既存のChild SAをそのまま引き継ぐ。
  • Child SAのrekeyは別の系譜を持つ。同時rekeyで二つの候補が生まれた場合、最小のnonceを含む交換が作ったSAが冗長側として閉じられる。最小nonceが勝者なのではない。
  • 監査可能な結果には、IKE制御の系譜、各Childの引き継ぎまたは交換、保護された制御メッセージとパケットの稼働結果という三つの帳簿が必要になる。

移行直後の通信は、何も起きなかったように見える。ESPパケットは流れ続け、相手の認証済みIDも変わらない。それでも裏側では、制御を担う親だけが交代し、複数のChildが古い鍵のまま新しい親の管理下へ移っているかもしれない。

ここで「VPNをrekeyした」とだけ記録すると、二つの事実を区別できない。制御鍵を更新したのか、トラフィック鍵を更新したのか。RFC 7296は両者に異なる識別子、寿命、交換手順を与えている。

Tero KivinenはCharlie Kaufman、Paul Hoffman、Yoav Nir、Pasi EronenとともにRFC 7296の著者として記載される。人物への帰属は設計上の貢献を追跡可能にするためのものであり、IETFの集合的成果を単独の所有物にしたり、現在の製品動作を保証したりするものではない。

制御するSAと、パケットを運ぶSA

IKE SAは、Child SAの作成、rekey、削除を指示する要求と応答を保護する。Child SAは一方向のAHまたはESP保護であり、通常は往復に対応する二つが組になる。親子という表現は、暗号素材を共有するという意味ではなく、保守メッセージの保護関係を示す。

初期のIKE_AUTHは、認証済みIKE SAと最初のChild SAを近い時点で成立させる。そのため実装画面では一個のトンネルにまとめられやすい。しかしChild作成に失敗しても、完成済みIKE SAまで必ず破棄するわけではない。後続Childの作成失敗も、制御全体の解体理由にはならない。

RFC 6023はChildを持たない認証済みIKE SAを定義する。生存確認、NAT検出、保護された通知、後日のChild作成に利用できる。この実験的RFCの著者はYoav Nir、Hannes Tschofenig、Hui Deng、Raj Singhであり、Kivinenではない。ここで重要なのは著者を広げることではなく、制御の存在とデータ経路の存在が独立した状態だと確認できる点である。

したがって、運用イベントは最初にSA種別を示さなければならない。主語のない「rekey」は、どの鍵、どのSPI、どの寿命が変わったかを説明できない。

CREATE_CHILD_SAという名前より広い機能

初期交換後、どちらの端点もCREATE_CHILD_SAを開始できる。この交換は新しいChildの作成だけでなく、既存Childのrekey、さらにIKE SA自身のrekeyにも使われる。共通の封筒の中に、三つの異なる操作が入る。

新規ChildではSA提案、nonce、必要に応じた鍵交換素材、TSiとTSrが提示される。応答側はトラフィックセレクタを狭められる。Child rekeyではREKEY_SAが、プロトコルと受信SPIによって交換対象を特定する。新しいChildが旧Childと異なるセレクタやアルゴリズムへ黙って変わるべきではない。

IKE rekeyでは新しい送受側IKE SPIと制御鍵が作られる。後継IKE SAではMessage IDとウィンドウ状態が新しく始まり、旧IKE SAは残務のため自分のカウンターを保つ。同じ交換形式でも、更新される履歴は別である。

実装は後続のCREATE_CHILD_SAを拒否できる。容量やローカルポリシーは共有交換によって奪われない。IANAのレジストリは交換、ペイロード、変換、通知のコードを一意にするが、相手が実装したことや交換が完了したことまでは証明しない。

rekeyは上書きではなく継承である

RFC 7296のrekeyは、既存SAの行を編集する操作ではない。新しいSAを作り、準備が整ってから旧SAを削除する。make-before-breakで二つのIDが一時的に並ぶことは、異常ではなく安全な移行に必要な状態である。

IKE rekeyで勝ち残った新しいIKE SAは、元のIKE SAに属していたすべてのChild SAを引き継ぐ。その後のChild管理メッセージは後継の保護下に置かれる。旧IKE SAが自分を削除する要求は、その旧SAにとって最後の要求になる。

証跡には、後継作成、相手による受理、Child一覧の付け替え、後継で保護された最初の有効な交換、旧親の削除を別時刻で残したい。「rekey時刻」一個では、保管の空白や早すぎる削除を検出できない。

IKEv2は双方に共通の寿命を一つ交渉しない。各端点がローカルの寿命を適用し、短い側が通常rekeyを起動する。時間、バイト量、活動状況などのトリガーは、その決定をした端点の記録に属する。

親が変わってもChildの暗号史は変わらない

引き継がれたChild SAは、送受のSPI、セレクタ、モード、アルゴリズム、鍵の世代、シーケンスとアンチリプレイ状態、カウンター、寿命を保持する。それらを更新するにはChild自身のrekeyが必要である。

新しいIKE SPIだけを示す証跡は、制御面の鍵更新を証明する。全トラフィック鍵の更新を主張するなら、旧・新Child SPIの組、提案と選択アルゴリズム、新しい鍵世代、有効化、旧Child削除まで示さなければならない。

標準文書の範囲もこの分離を支える。RFC 8247はIKEv2のアルゴリズム指針であり、ESP暗号化アルゴリズムを更新しないと明記する。RFC 8221はESPとAHを別に扱う。Kivinenはいずれの著者群にも含まれるが、制御面とデータ面の暗号姿勢は一つの「VPN暗号」欄には収まらない。

IKE側だけを新しい方式へ移行し、既存Childが自分の期限まで旧方式を続ける場合もある。逆にChildだけを更新する場合もある。ライフサイクル管理では二つの時計を同時に表示する必要がある。

認証された相手にも、全セレクタは許されない

IKE SAは相手の認証証拠を持ち、交渉を保護する。しかし認証済みの相手が任意の送信元・宛先範囲を主張できるわけではない。RFC 4301はPeer Authorization Databaseに、相手が提示できるトラフィックセレクタを制約する役割を与える。

応答側はTSiとTSrをローカルに許された範囲へ狭められる。Childが新しい親に引き継がれるときも、認証相手、許可済みセレクタ、ポリシー版を一緒に保持すべきである。親の交代を使って範囲を広げてはならない。

「相手を認証した」「Childを設置した」「この範囲を許可した」は別の判断である。一つ目を残しただけでは、ID証明が無制限の経路権限に見えてしまう。

Heng LuのMinimum Initial Specificationに照らすと、標準は独立運用者が協調するための最小のメッセージと識別子を共有する。その先の容量、許可範囲、寿命は、結果を引き受ける各参加者のローカル判断である。

新しいChildを両端が同時に知るわけではない

応答側は成功応答を送る前に、新しいSAでパケットを受信できなければならない。開始側は応答を処理した後に送信できる。しかし応答側には、その応答が届いたか、開始側の送信半分が使えるかを直ちに知る方法がない。

そのためChild rekey中、応答側は新しい組の反対半分で有効なパケットを受けるか、旧SAを閉じるIKE要求を受けるまで、旧SAから送信を続ける。アプリケーションパケットがなければ、開始側はdummy ESPパケットを準備完了の合図にできる。

dummyは移行の証拠であって、有用な処理の完了ではない。成功応答も、戻り経路、アンチリプレイ、MTU、アプリケーション継続を保証しない。稼働結果は交渉結果とは別に観測する。

相手とセレクタだけではChildを一意に特定できない。IKEv2は同じ端点・同じセレクタの並列SAを許す。SPIと系譜を欠く集計は、旧SA、勝者、冗長候補を一つの行へ潰してしまう。

同時Child rekeyでは最小nonce側を閉じる

双方の寿命方針が近いと、両端がほぼ同時にChild rekeyを始める。ジッターは確率を下げるだけで、競合を消さない。旧Childの組に加え、二つの新しい組が一時的に存在する。

複数の受信SAが有効な間は、どの候補からのパケットも受け入れる必要がある。その後、二つの交換に含まれる四つのnonceをオクテット単位で比較する。含まれる最小nonceを持つ交換が作ったSAは冗長として閉じられる。最小値は勝ち条件ではない。

生き残る組を作った側が、交換対象だった旧組を削除する。冗長な新組を作った側が、その冗長組を削除する。最終状態だけでなく、全候補と二つの削除責任を履歴に残す必要がある。

パケット損失により、既に交換済みのSAを狙うrekey要求が遅れて届くこともある。CHILD_SA_NOT_FOUNDはこの競合では非致命の結果になり得る。対象SPIと到着順序なしには、失敗の意味を決められない。

同時IKE rekeyはChildの相続先も決める

IKE SAも双方から同時にrekeyできる。旧IKE SAと二つの新候補が並び、最小nonceに対応する新IKE SAが閉じられる。生き残った一つが全Childを引き継ぐ。

したがってnonce比較の合意だけでは不足する。旧親を削除する前に、両端が同じ後継と同じChild一覧を認識していなければならない。Childの欠落は、制御鍵の交換成功とは別の保管事故である。

片側が旧IKE SAの終了処理へ入った後に、相手のrekeyが届く競合もある。RFC 7296はその状態にTEMPORARY_FAILUREを用い、旧SA削除を受けた側が自分の試行を断念できるようにする。通知名だけで障害と決めてはいけない。

二つの要求・応答、nonce集合、冗長候補、勝者、旧SA削除、双方の継承一覧を一つの系譜に結ぶ。これがなければ、成功した交換と失われたChildを区別できない。

複数鍵交換でも成功の粒度は粗くできない

RFC 9370はIKE rekeyやChild作成・rekeyに複数の鍵交換とIKE_FOLLOWUP_KEを追加する。同時rekeyの競合は、追加交換を続ける前に解決しなければならない。

RFC 9370は別の7人の著者による文書で、Kivinenの著作ではない。ここでの意味は、交換鎖が長くなるほど一般的な「成功」が説明力を失うことにある。拡張の合意、完了した交換、勝った候補、鍵が属するSA種別を明記すべきである。

IANA登録は公開語彙を提供するが、採用率、製品適合、パケット到達を示さない。登録、実装、交渉、稼働は別の証拠段階である。

著者境界を守ることも同じ精度の一部だ。隣接RFCの内容を人物へまとめて帰属させれば、技術の系譜まで一つの所有関係に見えてしまう。

Kivinenの署名が示す範囲

2026年8月31日に確認したIETF Datatrackerは、Tero KivinenをIPsecme chair、Tools Team member、Security Area Directorate reviewerおよびsecretaryとして記載する。RFCは16件、active Internet-Draftは0件である。いずれも日付を伴う事実で、製品認証ではない。

RFC 7296は5人の共同著作である。RFC 8247とRFC 8221にはそれぞれ別の共同著者群があり、RFC 6023とRFC 9370は別人たちの成果だ。正しい帰属は貢献を可視化するが、プロトコルの主権者を作らない。

Heng Luのagency問題の観点では、標準化組織と著者が提供するのは限定された協調手段である。各端点を運用する主体は、寿命、認可、アルゴリズム、実装と証跡について責任を持ち続ける。

本稿もその限界を越えない。引用仕様の構造は説明できるが、市場での実装率、特定ベンダーの適合、特定ネットワークの鍵更新を証明するものではない。

一つのrekey表示を三つの台帳へ戻す

制御系譜台帳には、相手の認証証拠、旧・新IKE SPI、アルゴリズム、nonce、Message ID、ローカルトリガー、競合、後継選択、後継初回利用、旧SA削除を記録する。誰が制御の親になったかを答える台帳である。

Child保管台帳には、各送受SPI、セレクタ、PAD/SPD判断、モード、アルゴリズム、鍵世代、ローカル寿命、旧親、新親、引き継ぎか交換か、削除状態を記録する。何が移り、何が実際に更新されたかを答える。

稼働台帳には、新旧Childでの受信、シーケンスとアンチリプレイ、破棄理由、dummy、最初の有用な双方向通信、切替時間、アプリケーション継続を記録する。Running-Code Primacyが求めるのは、この観測可能な結果である。

三台帳はSPIと時刻で結合できるが、同じ意味にはできない。IKEの成功はChild鍵更新の証明ではなく、Childの生存は正しい親への制御移管の証明ではない。

出典