摘要

  • 修订 07 允许 IKEv2 控制交换使用 TCP、ESP 使用原生 IP 或 UDP 封装；完成 IKE 认证并创建 Child SA，只能证明协商与密码学状态，不能证明 ESP 的实际道路畅通。
  • 运营记录必须拆成控制通道、ESP 路径、独立 NAT 状态、加密探测、业务流量与回退决策；认证可以成立，可用性却仍然为零。

想象一个很容易误判的夜班现场：网关通过 TCP 4500 完成了一次体量很大的 IKE 交换，双方身份验证正常，密钥派生完成，Child SA 已写入状态表。值班人员看见所有控制面指标都为绿色，于是宣布隧道已恢复。

几秒后，业务仍然没有流量。

原因并不神秘。允许 TCP 会话通过的中间设备，未必允许原生 ESP；维持 TCP 状态的 NAT，也不会顺手替 UDP 4500 建立并续租映射。密码学对象已经存在，但承载业务的路径还没有得到任何事实证明。

IETF IPsecME 工作组的活跃草案 Separate Transports for IKE and ESP 正在处理的就是这个缝隙。修订 07 属于 IETF stream，目标为 Standards Track，Datatracker 冻结状态为“WG Consensus: Waiting for Write-Up”。它仍是工作中的 Internet-Draft，不是 RFC，也不是部署或互通报告。

背景是两个不同的工程压力。第一，IKEv2 原本使用 UDP，RFC 9329 又为 UDP 受阻的网络定义了 IKE 与 ESP 一起封装进 TCP 的方式。第二，后量子密钥交换会显著放大 IKE 消息，可靠字节流更适合承载大块控制数据。然而，让 ESP 也长期套在 TCP 中会引入额外的性能与拥塞耦合问题。

修订 07 提议把两者拆开。双方通过空载荷状态通知 SEPARATE_TRANSPORTS 表明能力：IKE 后续交换继续走 TCP；ESP 则尽可能走原生 IP，发现 NAT 时走 UDP 4500 封装。如果响应方不返回该通知，就回到 RFC 9329 的耦合方式，让 IKE 与 ESP 都走 TCP。

这里最容易犯的错误，是把“双方同意分离”读成“分离路径已经可用”。通知只说明能力和偏好。它不是 ESP 的送达回执。

草案对两种起步方式作了关键区分。若 IKE_SA_INIT 从 UDP 开始，请求和响应本身已经提供了 UDP 可达证据。若它从 TCP 开始，控制交换再完整也不包含 ESP 可达证据。因此，Child SA 建立后，发起方应验证 ESP，除非已经收到受保护流量等价证明。

这也说明“安全”不能只用一个布尔值表达。草案明确指出，ESP 可达性无法确认，并不自动削弱 IKEv2 身份验证，也不自动破坏已协商 Child SA 的密码学保护。身份可能是真的，密钥可能是对的，道路却可能不存在。把这种故障称为认证失败，会把维修人员引向错误位置；把它称为已上线，又会把愿望伪装成事实。

NAT 进一步迫使我们承认两条路径。中间设备按传输协议维护状态。IKE 的 TCP 连接保持活跃，不会替 ESP 的 UDP 映射续命。ESP 必须发送自己的 NAT keepalive。来自新地址或端口、且完整性验证通过的 ESP 包，可以更新相关 ESP SA 的对端信息，却不能因此改写 IKE SA 的端点；反过来，受保护 IKE 消息更新控制端点，也不能当作 ESP 端点证据。

同一个对端身份，并不意味着同一份路径状态。

当 IKE 从 TCP 起步，修订 07 给出了有限但清楚的验证程序。检测到 NAT，就探测 UDP 4500 上的 ESP。未检测到 NAT，则先尝试原生 ESP；短暂等待仍无响应时，再尝试 UDP 封装，因为有些中间设备只接受带 UDP 或 TCP 头的流量。哪个有效响应先到，就使用哪条路径。这与 Happy Eyeballs 的精神相近：保留偏好，但不让偏好制造漫长不可用。

加密 ESP Echo 是草案列出的一个工具。它能够回答一个明确问题：在这组 SA、这个方向和这条候选路径上，受保护请求是否得到受保护响应。但它不是全部业务结果。Echo 成功不证明所有 Traffic Selector 正确，不证明大包一定通过，不证明隧道后的服务健康，也不证明真实应用完成交易。

因此，证据链至少包含四级：控制交换完成、ESP 探测响应、代表性受保护业务通过、最终服务结果成立。任何一级都不能替下一级签字。

若 ESP 无法确认可达，草案没有让系统保留一个含糊的 Child SA 等待奇迹。发起方必须用 DELETE payload 删除当前 IKE SA，再次通过 TCP 建立，并且不再提出 ESP 分离传输，也就是回退到 RFC 9329 的耦合承载。部署方还需要预先决定：ESP-over-TCP 的性能代价是否可以接受，还是应直接终止建立。

这是一项业务政策，而不仅是网络参数。穿越严格网络的连续性服务可能接受 TCP 回退；高吞吐或低时延业务可能拒绝；受监管环境可能要求在放行业务前保存路径证明。协议提供选择，风险所有者必须为选择负责。

移动会让旧结论失效。MOBIKE 可以把 IKE SA 及其 Child SA 移到新地址，但旧路径上的 ESP 证据不会随状态对象自动搬家。新地址可能拥有不同的过滤规则和 NAT 映射。草案要求在相应条件下重新验证，而不是因为 IKE 仍在 TCP 上就沿用过去的绿色状态。

会话恢复也一样。修订 07 禁止把分离传输选择写进 resumption ticket，理由很现实：客户端离线期间，网络条件可能已改变。票据可以加速安全关系恢复，却不能冻结物理网络。传输选择必须重新协商。

这与 Heng Lu 的三个设计判断相合。最小初始规范只共享互操作所需的能力，不替未来环境作过度决定；后续路径选择留给掌握当下事实的端点。Reality Layers 要求把状态对象与物理运行分开；“IKE established”是控制事实，不是数据事实。Running-Code Primacy 则要求最终相信实际穿越路径的受保护交换，而不是配置页面里的绿色标签。

运营系统不应只写“VPN up”，而应保存以下独立回执：

  1. IKE_SA_INIT 与后续 IKE 分别使用什么传输；
  2. SEPARATE_TRANSPORTS 是否提出并被接受；
  3. NAT 检测结果与候选 ESP 方式；
  4. ESP 自己的映射和 keepalive 是否存在；
  5. 哪个受保护探测从哪个端点首先返回；
  6. 代表性应用流量是否真正通过；
  7. 谁批准回退、终止或继续；
  8. MOBIKE 或恢复之后是否重新判定。

把八条记录压成一个绿色灯，正是下一次争议的起点。

资料来源