摘要

  • 10 月 27 日的一份 IETF 个人草案要求 BPSec 接收方为每项必需的安全服务、每个目标块预先指定有权提供证明的安全来源及其密钥。另一个合法节点的有效安全块不能顶替它。
  • 载荷自己的完整性块还必须把主块纳入保护范围；分别验证两个真实的块，无法证明它们原本属于同一个 Bundle。

合法节点干了不属于它的活

延迟容忍网络的消息要经过多站转发。中继节点可以持有真密钥，也可以按规则为自己的工作添加安全保护。麻烦恰恰从这里开始：某个中继拿到原始 Bundle，换掉受保护的载荷，再用自己的密钥做出新的完整性块。接收方如果只问“是不是合法用户做的”，答案可能完全正确。原始发送者的内容却已被另一位合法参与者替换。

RFC 9172 第 8.2.2 节写出了这种内部替换路径。规范允许多个安全来源参与 Bundle 的保护，并将安全策略留给部署方。由来源先加完整性块、再用保密块包住它，可以保护内层结构；但接收方若接受任何授权来源制作的外层块，合法中继仍能重新包装自己的内容。签名算法没有出错。接收方问错了问题。

N. D. S. Gupthaa 的新草案把判断放回接收端：对某项安全服务和某个目标块，先记录应由谁提供证明，以及与该来源绑定的密钥材料。收到 Block Integrity Block（BIB）或 Block Confidentiality Block（BCB）后，只接受能在预期密钥下通过验证的块。另一个中继纵使在网络里有合法身份、在别处也有充分权限，它的块仍不能完成原始来源的这项任务。

IETF Datatracker将它列为第 00 版个人 Internet-Draft，没有 RFC 通道，也没有 IETF 正式背书。它提出接收方规则；现有公开记录没有显示哪一个具体网络已经采用。

授权名单不是权力地图

草案用 R1 到 R4 划出四道边界。R1 把每项必需服务、每个目标块对应到预期安全来源及密钥。R2 不许其他来源的有效块代劳。R3 要求缺少匹配块时判定该服务失败。R4 管住权限外溢：网关获准为一种用途重新保护数据，不等于它自动成为另一来源数据的权威签名者。

这是一条很具体的治理问题。运营者常把一个中继称为“可信”，仿佛可信是一张覆盖全公司的任命书。转发、为某段路径加密、替某个来源作证，是三个不同职位。只有“好密钥清单”而没有“哪把密钥能为哪件事作证”的表格，接收方会把出入证当成董事会决议。

收到的安全块里自带 Security Source 字段。草案把它视为不可信的查找线索：字段可以告诉系统声称是谁做的，却不能让声称者自己决定谁有权做。接收方必须拿本地预设的来源和密钥来比对。若让入站数据挑选审查它的规则，验签只剩下仪式。

前提是不同来源确实有不同密钥。RFC 9172指出，如果所有节点共用一把密钥，任何持钥合法节点都能以这把密钥行使特权。接收方无法凭一张更漂亮的策略表重新分辨已经混在一起的签名者。密钥托管、网关授权和接收策略必须讲同一套边界。

两份真件，也能拼出一份假档案

草案的 R5 处理另一种拼接。一个 BIB 保护载荷，另一个 BIB 单独保护主块。两块都可能出自同一个真实来源，却分别属于两个不同的 Bundle。分别验出“真”，不能验出“这一页原本就和那一页装订在一起”。

因此载荷自己的 BIB 必须把主块放进同一次完整性计算。RFC 9173 第 3.3.3 节规定了相关范围标志：bit 0 涵盖主块；省略参数时的默认值 7 也包含它。再给主块单独加一个 BIB，补不出载荷与主块之间缺失的共同证明。RFC 9171定义了 Bundle 结构：主块承载消息级身份与处理信息，载荷块承载应用数据。接收方要核对的是它们作为一件东西被保护，而不是两件东西分别受到保护。

接收的一刻，证据要说清楚

草案称其 Tamarin 形式化模型和配置检查器可应要求提供，公开工件尚待发表。现有文本不能让读者复核模型，也不能证明任何部署已经抵挡一次真实替换。若有公开的接收配置与可重放的替换轨迹，运营层面的判断才会更扎实。

眼下的工程问题已足够锋利：系统记录的是哪项服务、哪个块、预期哪个来源、哪把密钥，以及载荷 BIB 实际覆盖了什么？只留下一个绿色“验证通过”，等于在包裹已被调包时夸奖印章做工精良。

来源