摘要

  • RFC 5201 及其后继 RFC 7401 都允许响应方在收到 I1 后选择预计算 R1，并继续保持无状态；R1 签名证明某些内容曾由该密钥生成，不证明此刻在线或已为本次请求留存资源。
  • I2 被接受、R2 被验证、负载关联安装、受保护数据往返，是四种不同的运行事实；前一步不能代替后一步。

把四个报文拆成四层事实

HIP 的基础交换由 I1、R1、I2、R2 组成。I1 是触发。R1 带来 puzzle、Diffie–Hellman 材料、算法选择和响应方签名。I2 交回 puzzle 解答与发起方的认证材料。R2 完成基础交换。

如果只看报文顺序，很容易想象响应方从 I1 开始逐步建立会话。规范给出的真实实现空间不同：响应方可以预先生成若干 R1，收到 I1 后选出一份，填入允许动态变化的字段并发送，然后仍然保持无状态。RFC 7401 的交换图继续明确标出“选择预计算 R1”和“保持无状态”。

这不是缺陷，而是拒绝服务防御的经济结构。若每个伪造源地址的 I1 都迫使响应方分配内存、验证公钥签名或计算共享秘密，攻击者只需付出廉价触发成本。预计算 R1 让响应方把昂贵承诺推迟到有效 I2 到来之后。

因此，R1 快速返回只能说明某条响应路径工作了。它甚至可能说明无状态路径按设计工作得很好，却不能说明会话已经存在。

签名证明来源，不自带“现在”

R1 的签名覆盖响应方 Host Identity 密钥生成的部分内容。RFC 5201 对其效果表述得很窄：发起方可以确认这份 R1 曾由响应方生成。由于 R1 可被预计算，而且没有覆盖 I1 的全部会话特定信息，签名本身不能阻止重放。

“曾经”是关键。探针可以可靠记录自己在某个单调时刻收到字节，并在某组算法下通过了签名校验。但它不能据此写成：响应方在同一时刻处理了本次 I1、为该发起方分配了状态、保留了容量或允许了服务。

R1 generation counter 用于在多个候选 R1 中偏好较新的 puzzle 代际。它不是 UTC 时间。HIPv2 讨论了计数器保存、复位和回绕，并继续选择不在 R1 中加入时间戳，以免依赖全球时钟同步。把计数器换算成“远端存活秒数”是在协议之外创造事实。

合格的收据应分别保存响应方 HIT、签名验证结果、算法标识、generation counter、puzzle 难度与寿命、opaque 值，以及本地接收时间。时间字段必须写明是谁的钟、记录了哪个事件。

Puzzle 证明做过功，不证明有资格

发起方要不断尝试 J，使挑战 I、双方 HIT 与 J 的哈希满足低位零的数量要求。响应方只需一次哈希就能验证。这种不对称让它在执行公钥验证、Diffie–Hellman 与状态创建之前，低成本丢弃许多伪造 I2。

RFC 5201 用“sincere”形容愿意消耗 CPU 的发起方，但这个词只限于计算意义。有效解答不证明操作者善意，不证明账户有权，不证明商业策略通过，不证明容量被预留，更不证明后端应用存在。

防护范围也有限。把计算绑定到发起方 HIT，可以阻止攻击者从一次 I1/R1 交换批量伪造许多不同 HIT 的 I2；规范同时承认，固定 HIT 的攻击者仍是另一种情形。实现可以记录失败历史，用内存换计算。运维收据必须说明具体采用了哪种权衡，而不是给出“可信发起方”这种模糊标签。

I2 才可能触发响应方的状态

I2 带回 puzzle 解、发起方 Diffie–Hellman 值和签名材料。响应方可以先做廉价的 puzzle 校验，再决定是否承担签名验证与密钥计算。如果全部通过，它计算共享材料并创建相应 HIP association。

响应方侧的“I2 accepted”日志因此比发起方看到 R1 更强：它证明某条本地策略实际执行并跨过了状态创建边界。但它仍不证明 R2 已到达发起方。发起方验证 R2，才获得响应方掌握共享结果并完成基础交换的证据。两端收据应通过 HIT、代际、参数与哈希关联，而不是靠墙上时钟硬拼。

这也解释一种看似矛盾的调查结果：抓包里有一份完全有效的 R1，响应方数据库却没有会话。I2 可能从未到达、已经过期、puzzle 错误或签名失败。此时“没有状态”正是规范期待的结果。

基础交换完成，不等于数据通路可用

HIP 基础交换建立 HIP 状态与密钥材料，却没有在 RFC 7401 中定义实际用户数据格式。该文档把任务交给独立传输规范，并要求至少支持 RFC 7402 的 ESP 传输。它在重启流程中还明确区分：基础交换完成后，主机可以创建新的 payload association，随后才开始发送数据。

所以 R2 验证成功不能证明两端都装好了 ESP Security Association。本地 SA 存在不能证明对端一致。发出受保护报文不能证明它到达。网络层回包也不能证明应用接受了请求。

若要声称“通路就绪”，应保存协商的传输格式、算法组、定位地址、密钥代际、受保护的 SPI 或等价标识、两端安装结果，以及双向首个认证报文。若要声称“服务可用”，还需一项安全、可重复、针对目标应用的响应。

运维应展示证据梯子

观测 可以证明 仍不能证明
本地发送 I1 发起方发出了触发 响应方收到
R1 签名有效 响应方密钥曾生成被覆盖内容 当前在线、会话或资源预留
本地解出 puzzle 发起方完成所需计算 响应方接受
响应方接受 I2 本地验证与状态创建成功 发起方收到 R2
发起方验证 R2 该端视角下基础交换完成 ESP 关联和数据送达
负载关联已安装 指定传输状态存在 双向应用成功
受保护请求与响应 一个有边界的业务效果发生 未来持续可用

每一层都应带实现版本、策略版本、协议坐标、本地单调时间与失败原因。一个绿色图标不能保存这些因果关系。

历史身份必须写准确

RFC 5201 于 2008 年 4 月发布，类别为 Experimental，并明确声明它不规定任何 Internet Standard。IESG Note 提醒了 SHA-1、MAC 算法敏捷性、RSA 选择和基于 IP 地址的本地策略等问题。RFC 6253 后来补充证书能力。

RFC 7401 在 2015 年废止 RFC 5201，把 HIPv2 作为 Proposed Standard 发布，并加入密码敏捷性和实现经验。RFC 8002 与 RFC 9374 后续又更新相关部分。本文不把 2008 年算法组推荐为当前部署方案。

真正延续至 HIPv2 的，是预计算 R1 与无状态响应方所揭示的证据边界。按照现实层次与运行代码优先原则，控制台必须说出实际执行到哪一步，而不能让一个符号替代尚未发生的效果。

来源

  1. RFC 5201 HTML
  2. RFC 5201 文本
  3. RFC 5201 信息页
  4. IETF Datatracker：RFC 5201
  5. RFC 5201 历史
  6. RFC 5201 引用
  7. RFC 5201 勘误
  8. RFC 7401 — HIPv2
  9. RFC 7401 文本
  10. RFC 7401 信息页
  11. RFC 7401 勘误
  12. RFC 7402 — HIP 的 ESP 传输
  13. RFC 4423 — HIP 架构
  14. RFC 4987 — TCP SYN Flood 防护
  15. RFC 6253 — HIP 证书
  16. RFC 8002 — HIPv2 证书
  17. RFC 9374 — DRIP Entity Tag
  18. Heng Lu：现实层次与符号权力
  19. Heng Lu：最小初始规范
  20. Heng Lu：运行代码优先