摘要

  • RFC 5202 明确要求使用 SPI 的中间系统检查 HIP 重密钥报文；报文为它们签名，但因需要新 SPI 而不能加密。现行 Standards Track 的 RFC 7402 保留了这一设计。
  • 管理层必须分别验证载荷是否加密、控制报文是否真实、哪些元数据可见、映射是否生效，以及所有副本何时被删除。

从一张会过期的映射表开始

设想一台 HIP 感知防火墙。它的表中不是“这个人是谁”，而是某个时刻的目的地址、SPI 与 HIP 上下文。收到重密钥 UPDATE 后，它先并存旧表项和新表项，随后让旧状态超时。这张表说明了协议为何必须留下可见接缝。

ESP 依靠 SPI 找到接收方向的 Security Association。RFC 4303 把 32 位 SPI 和序列号放在加密载荷之前；二者受到完整性保护，却不被加密。没有这个选择器，接收方无法知道用哪组状态处理报文。

HIP 又赋予 SPI 一层含义：它压缩表示一对 HIT，中间系统可以借此做地址映射。但这个表示严格受时间和目的地址约束。相同数值可以出现在不同主机；同一目的地址与 SPI 的组合在另一个时刻也可能指向不同上下文。因此 SPI 不是永久身份，也不是无意义随机数。

规范为何让控制面透明

重密钥时，ESP_INFO 携带旧 SPI、新 SPI 与 KEYMAT 索引。发起 UPDATE 还包括序列坐标、可选 Diffie–Hellman、HMAC 和 HIP 签名；响应方返回自己的参数和确认信息。

RFC 5202 的文字十分直接：依赖 SPI 的中间系统必须检查携带重密钥信息的 HIP 报文；报文为了这些中间系统而签名；它们可能需要新的 SPI，因此内容不能加密。2015 年取代它的 RFC 7402 在 HIPv2 中重复了相同规则。

这里没有“加密忘了覆盖一个字段”的事故。可读性是功能条件。签名让被授权的中间系统能够相信自己读到的转换来自正确关联；加密反而会让这种功能失效。

所以，签名验证通过只支持来源与完整性判断。它不支持控制元数据不可见，也不支持新 SA 已安装、数据面已经切换或应用已经收到流量。

可观察不等于自动识别人

HIP UPDATE 头部提供发送方与接收方 HIT，ESP_INFO 提供旧选择器到新选择器的变更，网络头部提供位置与时序。具有关联上下文的设备可以按规范更新映射。RFC 9063 也指出，HIP 感知防火墙或 NAT 可能被动观察路径流量，并维护控制面与数据面之间的软状态。

RFC 6973 将流量分析定义为：即使流量已经加密，仍从出现、方向、时机、大小、构成或频率推断信息。一次结构化的 SPI 变化正是这种分析可以利用的事件。

但文章不能越过证据。单独一个 SPI 不会自动给出自然人、公司、业务内容或全球稳定身份。更强的归因需要目录、日志、历史表、其他传感器或外部知识。正确结论是存在一个可被关联的时间坐标，而不是所有观察者都知道通信主体。

轮换只能改变坐标，不能删除旧观察

RFC 5202 与 RFC 7402 建议随机选择 SPI、与同一对端的新交换使用不同 SPI，并要求重密钥时更换 SPI。这些规则降低重用和重放风险，也缩短某个数值的寿命。

然而，一旦抓包或表记录了旧 SPI → 新 SPI，下一次随机选择无法回到过去清除它。防火墙的软状态可能几分钟后消失，SIEM、流量平台、支持工单和备份却可能保存更久。

RFC 9063 另行建议轮换未公开的 Host Identity，以扰动可链接性与可追踪性。这个端点策略不会自动删除每个中间设备已有的副本。HIT 轮换、SPI 轮换和证据保留必须分别治理。

给元数据建立可执行账本

每个读取 ESP_INFO 的组件都应登记六项内容：业务目的、读取字段、安装规则、可访问角色、外发目的地、到期与删除证明。只有协议确实需要的字段才进入共享面，调试、分析和长期画像不能借用同一理由。

单次事件的最小回执应包含观察点、方向、定位地址、受保护的 HIT 引用、新旧 SPI、SEQ/ACK 坐标、HMAC 与签名结果、算法、规则版本、计划到期时间和外发记录。若政策允许保存原始 HIT，也要明确写出；若采用受保护引用，则要兼顾事件关联与最小化。

另一组回执负责数据面：端点是否安装新 SA、新 SPI 上第一个通过认证的报文、旧 SPI 最后一次出现、旧状态删除。中间设备读懂 UPDATE，绝不能替代这些证据。

删除也要有结果，而不是一句承诺。需要分别验证软状态表、原始抓包、派生流量记录、工单附件、外部处理者和备份策略。否则“表已过期”只是局部事实。

历史文档与当前规则

RFC 5202 于 2008 年作为 Experimental 文档发布，后来被废止。它的一项 Held for Document Update 勘误只把一处“transport parameters”改为“transform parameters”，与本文主题无关。RFC 7402 于 2015 年取代它，并进入 Standards Track。

可见 SPI 规则从实验版延续到现行规范，说明它不是遗留疏忽。RFC 6538 的实验报告与 RFC 9063 的架构还揭示了更广的张力：HIP 可以加强端点认证和身份隐私实践，中间系统也可能为了路径功能参与控制面。治理必须把这两面同时写进事实表。

领导层应批准什么

要求所有产品、合同和仪表盘拆开四种声明：载荷机密性、控制消息真实性、元数据可观察性、保留与删除。任何一个绿色状态都不得代替其他三项。

最小初始规范可以要求短暂公开互操作所需的映射，却没有授权无限期分析或二次使用。运行代码优先意味着先看真正发出的报文和真正生成的表，再看所有副本是否按期消失。只有这样，“加密”才不会成为掩盖元数据权力的符号。

来源

  1. RFC 5202 HTML
  2. RFC 5202 文本
  3. RFC 5202 信息页
  4. IETF Datatracker：RFC 5202
  5. RFC 5202 历史
  6. RFC 5202 引用
  7. RFC 5202 勘误
  8. RFC 7402 HTML
  9. RFC 7402 文本
  10. RFC 7402 信息页
  11. IETF Datatracker：RFC 7402
  12. RFC 7402 历史
  13. RFC 7402 引用
  14. RFC 7402 勘误
  15. RFC 4303 — ESP
  16. RFC 4301 — IPsec 架构
  17. RFC 9063 — HIP 架构
  18. RFC 6538 — HIP 实验报告
  19. RFC 6973 — 隐私考量
  20. Heng Lu — 现实层与符号权力
  21. Heng Lu — 最小初始规范
  22. Heng Lu — 运行代码优先