摘要

  • draft-ietf-ipsecme-encrypted-esp-ping-03 提议在已经建立的 ESP SA 内发送认证 Echo，并可请求一个明确的返回 SPI。
  • 成功响应只证明请求所走的出向 SA 与响应实际到达的入向 SA；它不能替普通流量证明 SPD 匹配、同路径转发或应用接收。
  • 协商响应能力后，超时更值得调查，但仍要结合资源压力、入向认证计数、请求与实际返回 SA 以及业务探测解释。

值班工程师看到 IKE_AUTH 成功，于是把 VPN 标成“已建立”。客户流量仍然超时。随后，一枚很小的 Encrypted ESP Echo 返回，第二盏绿灯亮起。故障却没有消失。

这不是协议自相矛盾，而是三种事实被一个“隧道正常”标签压扁了：控制面完成协商、某个 ESP 包往返、某个业务请求交付成功。

当前 Datatracker 页面与文档历史表明，正式公开文本仍是 2026 年 5 月 4 日发布的修订版 03。提交 API虽记录 9 月 28 日的修订版 04，但状态只是 uploaded，并未成为当前版本。03 是工作中的标准轨 Internet-Draft，不是 RFC、部署报告或采用率证明。

草案在现有 SA 上发送 ESP Echo Request。模式一复用 USE_AGGFRAG 的拥塞控制载荷；模式二在 IKE_AUTH 中协商 ENCRYPTED_PING_SUPPORTED，再使用新的请求/响应载荷。AGGFRAG 子类型注册表和IKEv2 状态通知注册表尚未出现草案中的新名称，草案编号仍为 TBD。

专用载荷包含 16 位请求标识、16 位 Echo 序号、可选数据和可选的 32 位返回 SPI。Echo 序号不是 ESP SA 包序号。请求返回 SPI 也不是执行证明：发起方先在本地 SADB 验证，响应方再按自己的 peer 与策略验证；不匹配时不得使用，可改从接收请求的 SA 返回。即使匹配，最终选择仍由响应方决定，发起方应报告实际 SPI 与请求值的差异。

RFC 4301把 SA 定义为单向连接，双向通信需要一对 SA；它还要求支持选择器相同的并行 SA，并把流量如何分配留给发送方本地决定。因此，一个逻辑 VPN 可能同时有光纤、卫星、主用、备用等不同 SPI 与路径。Echo 从 A 发出、请求 B 返回、最终从 C 收到时，只能证明 A 与 C。

RFC 4303规定接收方依据 SPI 及可选地址找到 SAD 项并验证 ESP。成功验证是一枚很强但很窄的包级回执。普通流量还要由 RFC 4301 的 SPD 按地址、协议与端口等选择 PROTECT、DISCARD 或 BYPASS。草案特意让 Echo 脱离普通安全策略匹配，以便网关即使没有对应本地 SPD 地址也能接收。正因为如此，Echo 成功不能证明客户包会匹配同一规则或同一 SA。

尺寸也可能不同。RFC 9347提供 AGGFRAG_PAYLOAD 和可复用的拥塞载荷，但不承诺内部 IP 包可靠交付，也没有逐包确认。小型探针通过，不能替大型业务包排除 MTU、分片与后续策略问题。

超时同样不能独立成为判决。协商 ENCRYPTED_PING_SUPPORTED 后，草案把它视为响应承诺，但同时保留本地资源约束，只说超时可以作为路径故障迹象。草案另一处明确要求：不要仅凭缺少响应拆除连接，应检查每 SA 入向包/字节计数。计数增长说明仍收到认证 ESP 流量，虽不能证明特定 Echo、反向健康或应用交付，却足以否定“整个加密路径都死了”。

RFC 7296建立 IKE 与 Child SA，却不保证 ESP 与 IKE 走同一路径。IKE 与 ESP 分离传输草案甚至允许 IKE 使用 TCP，而 ESP 继续独立运行。IKE 前 ESP Echo则是另一种未认证机制，不能混作本篇证据。

RFC 7110说明指定返回路径的动机：LSP 的正向路径可以正常，而回复在另一条路径丢失，形成假阴性。请求明确路径能减少歧义，但仍必须记录实际执行的路径。

因此，运行记录要依次保存：草案版本与 IANA 状态、能力协商、peer 身份、发送时间、请求 ID 与 Echo 序号、出向 SPI、请求返回 SPI、实际入向 SPI、认证/重放结果、计数器差值、响应方资源状态、普通包选择器与 SPD 决策、大小/MTU，以及应用确认。

现实分层要求把协商、配置、包与结果分别命名。最小初始规范支持共享可验证格式，但把重试和拆除阈值留给承担后果的运营者。运行代码优先则提醒：规范发布与能力声明是协调工件，活跃 SA、认证包与应用结果才是运行事实。

来源