摘要

  • IKE SA 负责保护控制交换，Child SA 负责保护 AH 或 ESP 数据包。IKE SA 换钥会生成新的控制 SPI、密钥与消息计数状态；胜出的新 IKE SA 继承已有 Child SA，并不会自动更新每一条 Child 的流量密钥。
  • Child SA 换钥有自己的 SPI 谱系、选择器、算法和碰撞处理。双方同时发起时，含有最低 nonce 的交换所创建的 SA 是应被关闭的冗余项；最低 nonce 不是赢家。
  • 可核验的交接至少需要三本账：控制谱系、每条 Child 的归属与换钥状态、实际控制消息和数据包的运行结果。一个 rekey 指标无法证明流量密钥轮换，也无法证明服务连续。

先看一个最容易误判的画面：新 IKE SPI 已经出现，旧 IKE SA 正在删除，业务包仍沿原路径传输。运维界面把这三件事压成一个绿色事件，审计报告随后写下“隧道密钥已轮换”。

问题在于，“隧道”不是 IKEv2 的唯一状态对象。IKE SA 是受保护的控制上下文；Child SA 才承载两个方向上的 AH 或 ESP 保护。控制上下文换代以后，原有 Child 可以只换父关联，不换自己的密钥、SPI、选择器和生命周期。

Tero Kivinen 与 Charlie Kaufman、Paul Hoffman、Yoav Nir、Pasi Eronen 共同署名 RFC 7296。以他为人物线索，可以看清标准如何描述这种接班；但署名只证明可追溯的贡献，不等于他单独拥有协议，也不等于任何厂商产品已经正确实现。

IKE_AUTH 同时出生，不代表终身绑定

通常，IKE_AUTH 在建立认证后的 IKE SA 时也创建第一条 Child SA。两个对象几乎同时出现，很多界面于是把它们画成一个 VPN 会话。RFC 7296 保留了两者的独立性：第一条 Child 创建失败，已经完成的 IKE SA 不一定随之失败；后续 Child 创建失败也不应当然拆除控制关联。

RFC 6023 进一步定义了没有任何 Child SA 的已认证 IKE SA。它仍可用于存活性、NAT 检测、受保护通知以及稍后创建 Child。该实验性 RFC 的作者是 Yoav Nir、Hannes Tschofenig、Hui Deng 与 Raj Singh，不是 Kivinen；这里引用它，是为了证明“有控制”与“有数据通道”本来就是两个状态。

因此，事件表的第一列应是关联类型。若没有 IKE 或 Child，后面的“创建”“换钥”“删除”都缺少主语。

同样，活跃流量只能证明某条 Child 仍能收发。它不能证明旧 IKE SA 已可安全删除，也不能证明下一次删除、存活检测或换钥消息会由正确的新父关联保护。

一个 CREATE_CHILD_SA 包住三种意图

初始交换之后，任一端都能发起 CREATE_CHILD_SA。名称看似只指新建 Child，实际可表达三种操作：创建一条新 Child、为已有 Child 换钥、为 IKE SA 自身换钥。

新建 Child 时，请求携带 SA 提案、nonce、可选的密钥交换材料，以及发起方和响应方流量选择器 TSi、TSr。响应方可以缩小选择器。为 Child 换钥时，REKEY_SA 通过协议和入站 SPI 指定被替换者；新 Child 不应悄悄换成与旧 Child 不同的选择器或算法。

为 IKE SA 换钥时，双方获得新的 IKE SPI 与控制密钥，新关联的 Message ID 与窗口状态重新开始；旧关联在完成遗留请求期间仍保留自己的计数器。交换外壳相同，不等于三个对象共享一段历史。

实现也可以拒绝后续 CREATE_CHILD_SA。本地容量和策略仍由本地决定。IANA 登记让交换类型、载荷、转换与通知代码不冲突，却不证明某个对端支持、接受或完成了相应操作。

换钥是先造继任者，再拆前任

RFC 7296 所说的 rekey 不是在原记录上覆盖密钥，而是创建新的 SA，再删除旧的 SA。这个 make-before-break 顺序保留了过渡期，也让旧、新两个身份都应进入审计记录。

IKE 换钥成功后，胜出的新 IKE SA 继承原 IKE SA 名下全部 Child。以后针对这些 Child 的受保护控制消息，应走继任者。旧 IKE SA 发出的最后一个请求，是删除它自己。

交接至少包含四个时点：继任者创建、对端接受、Child 清单挂接、前任删除。还应记录继任者保护的第一个有效控制交换。“创建成功”与“可以拆旧”之间可能存在重要间隔。

IKEv2 不协商唯一的共同寿命。两端各自执行本地生命周期策略，较短的一方通常先触发换钥。定时、流量阈值、活跃度和实现策略属于本地决策凭证；标准负责让交接可互操作，不替远端统一排期。

继承 Child，不等于更新 Child 密钥

被继承的 Child SA 保留自己的入站与出站 SPI、流量选择器、模式、算法、密钥代际、序列与抗重放状态、计数器和寿命。只有单独的 Child 操作才会改变这些字段。

所以，“VPN 已换钥”必须被拆问。若证据只有新旧 IKE SPI 和控制算法，它只能证明控制面轮换。若声称全部流量密钥更新，则必须给出新旧 Child SPI 对、Child 提案与选中算法、新密钥代际、启用证据和旧 Child 删除。

RFC 8247 的范围是 IKEv2 算法要求，并明确不更新 ESP 分组加密算法；RFC 8221 另行处理 ESP 与 AH。Kivinen 都参与了这两份 RFC，但它们各有不同合著者。范围分离本身说明，控制面和数据面的密码态势不能填在同一个字段里。

升级控制算法时，在用 Child 可能继续停留在旧的、仍被允许的套件，直到它自己的计时器触发。反过来，也可以只为 Child 换钥而保持 IKE SA 不变。合规报告需要两只时钟。

认证了对端，不等于授权所有选择器

IKE SA 提供对端身份的认证证据，并保护后续协商。它不会赋予对端声明任意地址范围的权力。RFC 4301 要求 Peer Authorization Database 在对端认证之后，继续约束其可提出的流量选择器。

响应方可以把 TSi、TSr 缩小到本地允许的范围。Child 被新 IKE SA 继承时，应同时保留已认证对端、获准选择器和策略版本。父关联换代不能让 Child 的覆盖范围悄悄扩大。

“对端已认证”“Child 已安装”“这些前缀已获授权”是三个不同判断。把第一项当作后两项，会把身份凭证错误地升级为全网段通行证。

Heng Lu 的 Minimum Initial Specification 在这里提供了合适尺度：共同规范只固定独立参与者互操作所需的最小消息和标识；是否接受、允许哪些范围、何时换钥，仍由承担本地后果的一方决定。

新 Child 的可用性从来不是同时被看见

响应方必须先准备好接收新 SA 上的包，才能发出创建成功响应。发起方处理响应后即可发送。此时响应方无法立即知道响应是否抵达，也不知道发起方的出站半边是否安装完成。

因此 Child 换钥期间，响应方继续从旧 SA 发送，直到从新配对的另一半收到有效包，或收到关闭旧 SA 的 IKE 请求。如果发起方没有业务包可发，可以送一个 dummy ESP 包表示已经就绪。

dummy 包只是过渡证据，不是有效业务交付证明。创建响应也只证明协商完成，不证明回程路由、抗重放状态、MTU 或应用事务都成功。运行结果需要另一本账。

对端与选择器也不能唯一识别 Child。IKEv2 有意允许相同端点和选择器之间存在并行 SA，例如用于差异化服务。若不保留 SPI 与谱系，仪表盘会把旧关联、胜出者和碰撞冗余项合并成一行。

Child 同时换钥时，最低 nonce 的候选者要退出

两端采用接近的寿命策略时，可能近乎同时发起 Child 换钥。加入抖动只能降低概率，不能消除竞态。短时间内会同时存在旧 Child 对和两个新 Child 对。

只要多个入站 SA 仍有效，接收方就必须接受其上的包。随后按字节比较两次交换中的四个 nonce。RFC 7296 的规则常被口头倒置：包含最低 nonce 的那次交换所创建的 SA 是冗余项，应被关闭。最低 nonce 输，不是赢。

胜出新 Child 的创建者负责删除被替换的旧 Child；冗余新 Child 的创建者负责删除冗余项。审计记录必须保留三个候选及各自删除责任，不能只留下最终一条。

丢包还可能让迟到的换钥请求指向已经被替换的 SA，此时 CHILD_SA_NOT_FOUND 可以是非致命的碰撞结果。没有目标 SPI、到达顺序和谱系，就不能把该通知解释成“从未发生换钥”。

IKE 同时换钥时，胜者还要接走所有 Child

两端也可能同时为 IKE SA 换钥，于是旧 IKE SA 与两个新候选短暂并存。与 Child 碰撞相同，关联最低 nonce 的新 IKE SA 被关闭。

但这里多了一层后果：只有胜出的新 IKE SA 应继承全部 Child。两端不仅要同意哪个候选退出，还要在删除旧控制状态前，对胜出者名下的完整 Child 清单达成一致。

若一端已经开始关闭旧 IKE SA，另一端的换钥请求才到达，RFC 7296 使用 TEMPORARY_FAILURE 表示该状态。收到旧 SA 删除后，遇到竞态的一端可放弃自己的尝试。临时失败可能是有序收敛的一部分，而非中断证明。

凭证应保留两次交换、nonce 集、冗余候选、最终继任者、旧 SA 删除以及双方看到的继承清单。若清单不一致，即使控制密钥派生正确，也属于归属失败。

多重密钥交换没有取消这条边界

RFC 9370 在 IKE 或 Child 的创建与换钥中加入多重密钥交换和 IKE_FOLLOWUP_KE。它仍要求先解决同时换钥碰撞，再继续后续交换。

RFC 9370 属于另一个七人作者组，不能归给 Kivinen。它对本文的意义在于：链条越长，“成功”二字包含的信息越少。记录必须说明协商了什么扩展、哪些交换完成、哪个候选胜出、所得密钥属于哪种关联。

IANA 代码点能让扩展名称公开且不冲突，却不能说明部署普及度、厂商符合性或有用流量是否通过。那些都是运行证据的问题。

同理，RFC 6023 与 RFC 9370 只是邻近证据。清楚标注作者边界，可以避免把人物叙事变成对整个技术谱系的占有宣称。

Kivinen 的署名是贡献线索，不是控制权

截至 2026 年 8 月 31 日，IETF Datatracker 显示 Tero Kivinen 担任 IPsecme chair、Tools Team 成员、Security Area Directorate 评审者与秘书；列有 16 份 RFC，没有活跃 Internet-Draft。这些是有日期的职业事实，不是对任何产品的认证。

RFC 7296 有五名作者，RFC 8247 与 RFC 8221 各有自己的合著组，RFC 6023 和 RFC 9370 则由别人署名。保留这些边界，才能让贡献可追溯而不制造协议主权。

用 Heng Lu 的 agency 问题来理解，标准组织与作者提供的是范围有限的协调工具；运行两端的人仍须为自己的寿命策略、授权、算法部署和事故判断负责。

这也划定本文结论：引用文本说明协议设计，不证明市场部署比例，不审计任何具名厂商或网络，也不声称每个实现都正确处理了继承与碰撞。

三本账，回答三种成功

控制谱系账记录对端身份、新旧 IKE SPI、算法、nonce、Message ID、本地触发原因、碰撞候选、继任决策、继任者首个受保护交换和旧 SA 删除。它回答谁接掌控制。

Child 归属账逐条记录入站与出站 SPI、选择器、PAD/SPD 授权、模式、算法、密钥代际、本地寿命、旧父关联、新父关联、继承或替换状态与删除。它回答哪些对象搬家，哪些对象真正换钥。

运行结果账记录新旧 Child 上的包接收、序列与抗重放、丢弃原因、可能的 dummy 包、首个双向有效流量、切换时间与应用连续性。它回答路径是否实际工作，而不是只看协商返回码。

三本账通过 SPI 谱系和时间相连，却不能合并。成功的 IKE 换钥不证明 Child 密钥更新；活跃的 Child 流量不证明未来维护已归正确父关联。Running-Code Primacy 的意义正在于此：规范给出可检验规则，运行状态给出实际答案。

来源