摘要

  • draft-smyslov-ipsecme-ikev2-psp-02 要求先建立不带 Child SA 的 IKEv2 SA并完成对端认证，再通过修改后的 CREATE_CHILD_SA 双向传递 PSP Key Download；每一端交付的是对方发往自己时应使用的密钥。
  • 成功响应可以绑定对端、流量选择器、SPI、PSP 参数和封装密钥，却看不到发送端是否把密钥装进正确网卡，也看不到接收端是否成功派生、校验 ICV 与接收上层数据。
  • PSP 本身不提供派生密钥的单独撤销，也不承担重放保护。换 SA、主密钥双重轮换、旧状态清退、重放判决和应用交付必须分别留痕。

最清晰的一盏绿灯停在执行门外

在一个自动化平台里，IKE 服务往往最容易观测。请求、响应、身份、算法、SPI 与选择器都有结构化字段，成功或失败也有明确边界。网卡内部的表项、DMA、队列和每包判决却更分散。于是组织很容易让控制服务替整个系统发言。

当前 draft-smyslov-ipsecme-ikev2-psp-02 解决的是一个真实但有限的问题：如何用 IKEv2 给 PSP 提供密钥。它的 HTML 和 XML 描述相同消息流程，没有定义硬件安装回执。Security Considerations 仍只有 “To be added”。因此，任何端到端安全结论都不能从这七页文本里自动长出来。

这不是否定控制面。恰恰相反，只有承认它证明到哪里，成功响应才有操作价值。它证明密钥材料在经过认证的 IKE 会话里抵达；之后的问题必须交给之后的证据回答。

PSP 的密钥由接收端决定

PSP Architecture Specification 希望减少接收网卡保存的逐 SA 密钥。接收端保有两把 256 位主密钥。数据包 SPI 的最高位选择其中一把，其余位与主密钥一起派生该 SA 的接收密钥。

只有接收端知道当前活动主密钥和 SPI 分配状态，所以 SPI 必须由接收端选。随后，它把对应派生密钥安全交给发送端。发送端存储或提交这把密钥，用它保护发向该接收端的包。反向流量需要另一条单向 SA 和另一把由另一接收端选出的密钥。

这使“谁发送密钥”与“谁使用密钥”呈反向关系。KD payload 的发送者是在提供自己的接收材料；远端才是用它发包的一方。如果日志只写“双方交换密钥”，它会抹掉方向，也会掩盖一边安装成功、另一边失败的状态。

RFC 7296 的普通 Child SA 从 IKE 交换中的秘密与随机数派生材料。PSP 需要接收端可控的材料，因此草案复用 RFC 9838 的 Key Download 能力，把原本用于组密钥管理的封装材料机制用于单播。传输问题因此得到回答，执行问题仍留在本地。

先认证再送密钥，是边界而不是终点

双方在 IKE_SA_INIT 协商 Key Wrap Algorithm。支持这一流程的响应端还发送 CHILDLESS_IKEV2_SUPPORTED。RFC 6023 允许先建立没有 Child SA 的 IKE SA。

草案不允许在 IKE_AUTH 中创建 PSP Child SA。原因很直接：此时发起方若先交付自己的接收密钥，响应方尚未完成认证。正确顺序是先完成身份认证，再在后续 CREATE_CHILD_SA 中双向传递 PSP 材料。

这个顺序能防止敏感材料过早暴露，但它不认证网卡状态。IKE 身份可能属于一个控制服务，背后管理多台主机、虚拟功能、物理 NIC 或加速器。对端认证说明控制关系中的主体是谁，不说明哪一个执行对象已经接收命令。

能力协商也应单独记录。Key Wrap Algorithm 谈妥，不代表该 IKE SA 只能创建 PSP；草案明确允许它同时用于 ESP。CHILDLESS_IKEV2_SUPPORTED 说明可以先完成空子关联启动，不说明后来已经存在 PSP 数据路径。

CREATE_CHILD_SA 把语义绑在一起，却没有触碰表项

修改后的消息包含仍标作 <TBA> 的 PSP Protocol ID、PSP Parameters transform、Traffic Selectors、SPI 以及每个方向恰好一个 KD payload。Key Bag 的 SPI 必须对应某个提案，SA_KEY 以默认 SK_w 封装；SK_w 来自 SK_d 与 “Key Wrap for PSP”。

这些字段足以回答控制面审计问题：哪个已认证对端、哪段流量、哪个 SPI、哪个 PSP 参数、哪一份封装材料属于同一次决定。但草案没有规定 IKE 进程如何把返回密钥交给主机或 NIC。

已经归档的 Google PSP 仓库 提供参考实现与测试材料。架构附件列出多种发送密钥管理方式：片上流表、RAM 中的 SA 数据库、随发送描述符提供密钥或引用。每种方式都有不同容量和失败面。公开代码证明这些设计被写过，不证明任何命名设备、产品或生产网络采用其中某种方式。

因此，本地安装回执应至少绑定 SPI、算法、方向、网卡或虚拟功能、队列或 SA 索引、驱动命令结果与时代标识。无需记录明文密钥，但必须证明正确引用落在正确执行对象上。

“无状态”没有消除主密钥、时代与容量

PSP 所谓 stateless，主要是接收端不逐 SA 存储派生密钥。接收端仍管理两把主密钥、活动位、SPI 空间、SA 生命周期与轮换；发送端仍管理逐 SA 发送密钥；上层还可能维护允许的 SPI 列表。

RFC 4301 把 IPsec 的 SA 管理、策略与包处理分开，RFC 4303 也不把 ESP SA 建立等同于每包成功。PSP 改变部分状态的存放方式，没有取消管理面与数据面之间的交接。

容量同样不能由“无状态”三个字证明。架构讨论数百万 SA 与高频密钥更新，是设计规模，不是某块 NIC 的实测。控制服务可以继续快速响应，而网卡表项已满、命令队列积压或发送分类器仍选择明文路径。

第一只 PSP 包需要自己的证据链

PSP 架构要求提供 TX/RX 成功包与字节计数、认证或加密失败、格式错误及主密钥选择错误等计数。它还建议把成功解密/认证标志与 SPI 元数据交给上层。

一个受控 canary 可以连接这些表面。先保存 IKE 事务和安装回执，再发一只可识别 PSP 包。发送端记录 SPI、IV 与 TX 增量；接收端记录所用主密钥时代、派生结果、ICV 判决与 RX 增量；上层确认收到预期内容。

这条链只能证明那一只包或受控流在那个时点通过，不能自动证明所有后续包。但它至少把“收到密钥”推进到了“数据路径确实执行”。若 TX 增加而 RX 认证不增加，问题可在路由、封装、版本、主密钥时代或 ICV 中定位；若 RX 成功而应用无回执，调查再向 SPI 白名单、传输或应用推进。

Rekey 的成功响应只完成替换的第一步

草案允许 REKEY_SA 指向要被替换的 PSP SA。IKEv2 的通用模式是创建新 SA、切换流量、删除旧 SA。成功响应只证明创建协商完成，不证明后两步。

运维记录应包含：新 SPI 安装时间、新 SA 首个认证成功包、旧 SA 最后一个包、发送分类切换、双方删除确认，以及期间的丢包与乱序。若新密钥已安装但分类器仍指向旧 SA，控制面和执行面会同时各自“正确”，系统却没有完成迁移。

主密钥轮换还需要更长视角。一把主密钥停止活动后，旧 SA 仍可用它派生。PSP 架构说，只有下一次轮换才能真正驱逐这把旧主密钥；在那之前，相关连接必须 rekey。它还明确不提供单个派生密钥撤销，轮换才是失效方法。

所以管理系统中的 “revoked” 只是一项行政决定。只有迁移、旧包停止、旧 SA 删除以及第二次轮换完成，才构成密码学退场证据。

重放保护被移交，不等于已经完成

PSP 自身没有 replay protection，假定 TCP 等第四层机制提供。IKEv2 交付一把新密钥，也不会产生这项后续判决。一个 ICV 有效的包仍可能需要被另一层识别为重复。

这不能被写成“PSP 部署必然没有重放保护”。正确结论是：若运营者声称重放被拒绝，就必须说明哪一层负责、使用什么状态、观察了什么序号或事件、最终怎样判决。SPI、IV 和认证成功标志都不能偷偷代替这份记录。

认证、重放判决与应用去重是三件事。把它们分开，才能解释一个密码学上真实的包为什么仍应被丢弃。

02 版更新时间没有带来新的安全结论

Datatracker API 显示 02 版于 2026 年 9 月 30 日上传，2027 年 4 月 3 日到期。文档页 将其列为活跃的个人 Internet-Draft，历史页 记录三个版本。

01 到 02 的差异只有日期、版号、到期日与页眉，协议正文没有变化。文件头称目标状态为 Experimental，但 Datatracker 没有 RFC、stream、负责 AD 或标准级别。它不是 IETF 背书，也不是部署里程碑。

草案申请的 PSP 标识与 transform 仍是 <TBA>。IANA IKEv2 参数注册表 才是已分配值的权威记录。申请不能被写成分配，文本发布也不能被写成互操作成功。

来源与限制

本文使用 02 版 text、HTML、XML 与 Datatracker 记录，并以 RFC 7296、RFC 6023、RFC 9838、RFC 4301、RFC 4303、IANA、PSP 仓库及架构规范限定语义。它们不证明生产采用、性能、实现符合性、漏洞、事故或业务结果。