摘要

  • RFC 5386 中的 BTNS 可以证明对端控制着其提交公钥对应的私钥，却不能据此证明某个人、机构、域名或地址就是该密钥的外部身份。
  • 普通 PAD 规则必须先行；对端一旦匹配已知身份却认证失败，就必须被拒绝，不能再由匿名通配项“兜底”。
  • 匿名流量只能匹配显式设置 BTNS_OK 的 SPD 规则，而且 Child SA 选择器不得侵入其他 PAD 关系保留的身份范围。

BTNS_OK 不是能力标志，而是授权标志

系统支持 BTNS，只说明它具备处理这种交换的能力。RFC 5386 没有让这一能力自动覆盖所有 IPsec 流量，而是在 Security Policy Database 中增加 BTNS_OK。来自 BTNS 对端的流量只能命中带有该标志的规则。

这个设计把决策留在本地。运营者可以允许一个公开服务在没有网络层身份的情况下获得完整性和机密性，同时要求管理接口、合作伙伴网段和关键存储必须使用常规认证。匿名不是主机的永久属性，而是某条流量政策接受的一种证明级别。

如果监控页面只显示“IPsec 已连接”，这项授权就会消失。相同的绿色状态可能对应证书验证、预共享密钥、对端自带公钥，甚至后来标准中的 NULL Authentication。它们都能产生 IKE SA，却不是同一种信任关系。

因此，运行记录至少要同时保存 PAD 匹配路径、认证方式、SPD 规则、BTNS_OK 状态和 Child SA 选择器。缺少其中任何一个字段，都无法回答这条加密通道为什么被允许进入某个业务面。

已知身份失败后不能改名为匿名

RFC 5386 把 Peer Authorization Database 当作有顺序的控制表。系统先按对端声称的身份查找非 BTNS 项。若命中，就由那条关系决定认证要求。对端未能完成要求时，提案必须被拒绝。

只有完全没有普通项匹配时，系统才可以在本地把对端身份转换成 PUBLICKEY，以对端公钥本身作为值，再查找 BTNS 项。PUBLICKEY 并不是新增的线上 ID；它是实现内部保存较窄事实的办法。

“没有已知关系”与“声称已知关系但证明失败”是两种状态。前者可以进入受控的公开入口，后者已经触发强关系的否决。如果继续向下搜索匿名项，攻击者只需故意选择一个已知名字、失败一次，再借最低门槛进入。通配项就从补充政策变成了降级器。

所以 RFC 规定所有 BTNS 项在逻辑上必须位于普通项之后，最多只能有一个通配 BTNS 项，而且它必须是最后一项。这里的“最后”不是性能建议，而是权力顺序：它只处理强关系没有认领的剩余空间。

有效签名只把交换绑定到一把钥匙

BTNS 对端在 CERT payload 中发送裸公钥，并用相应私钥生成 IKEv2 AUTH 签名。验证成功是一项真实结果：本次交换的参与者掌握了对应私钥，交换内容也受到 IKE 的密码学绑定。

然而，公钥是谁提供的，不能回答公钥属于谁。没有受信 CA、预配置登记或其他外部机制时，签名并没有把钥匙连接到公司、设备资产、域名或地址所有权。RFC 5387 因而把弱保证称为“关联连续性”：在一条 SA 生命周期内，通信对象保持为同一个未认证来源。

这项保证有用。初始建立未被中间人劫持时，ESP 或 AH 可以提供完整性、抗重放和机密性，长连接也能抵御部分离路径攻击。但关联连续性不是跨 SA 的身份，也不能自动穿过 rekey。

RFC 7670 后来以 SubjectPublicKeyInfo 形式为 IKEv2 提供通用裸公钥编码，并明确指出：若要相信钥匙的真实性，需要带外验证或配置。RFC 7619 则定义 NULL Authentication 和 ID_NULL，保留交换绑定，却明确不信任对端身份。后来的机制不能证明今天有谁部署了 RFC 5386，但它们共同表明“通道成立”与“外部身份成立”必须分栏记录。

匿名对端不能借走已知网段

通过 IKE SA 准入后，对端还会协商 Child SA 的流量选择器。若匿名对端能声明已知合作伙伴的地址或整个受保护网段，前面的身份隔离就会被流量授权绕过。

RFC 5386 因此要求通配 BTNS 项的 Child SA 身份约束不能与其他 PAD 项逻辑重叠。规范建议在协商阶段再次搜索 PAD，检查匿名对端提出的选择器是否冲突。

安全网关示例说明了双重否决。冒充已知主机的攻击者可能先匹配该主机的普通 PAD 项，然后因认证失败被拒绝。即使它以未知公钥身份进入 BTNS，仍不能建立覆盖已知主机地址的 Child SA。匿名服务可以接受它，但不能把别人受保护的标识空间一起交给它。

RFC 7619 对 NULL Authentication 提出类似警告。NAT 后的匿名对端如果可以任意缩窄选择器，可能把原本发往 DNS 服务器的流量导向自己。规范建议隔离匿名对端，并把可用范围限制到明确分配的地址。加密不会把越权选择器变成合法选择器。

首次建立仍可能遭遇主动中间人

RFC 5387 区分 Stand-Alone BTNS 与 Channel-Bound BTNS。前者不依赖上层认证。只要首次 SA 没被劫持，建立后的包保护可以发挥作用；但主动中间人仍可在初始密钥交换时分别与两端建 SA。

Channel-Bound BTNS 让上层协议认证其主体，再把该认证绑定到 IPsec 通道。强 channel binding 能发现中间人拼接了两条 SA。connection latching 则把上层流与一系列相似 SA 关联，在 rekey 时维持可核验的连续性。

时间顺序决定风险。BTNS 的 IKE 可以先成功，SA 已经创建、资源已经消耗，之后上层认证才识别中间人。若上层机制在失败前泄露可离线攻击的口令派生材料，迟到的检测无法撤回泄露。RFC 5387 明确要求避免这种组合。

因此，channel binding 的成功不应回写成“最初 IKE 身份已认证”。正确的链条是：未认证 IKE 交换、SA 对、通道绑定值、上层主体认证、应用授权、最终操作结果。每个环节只为下一环节提供输入。

Better Than Nothing 不是降级阶梯

RFC 5386 明确没有定义：当对端不支持 IKEv2 时自动退回未保护 IP。它也没有完整定义 leap of faith 或 connection latching。规范的边界是，在明确政策下建立无网络层身份的 IPsec SA。

RFC 5387 把适用原则说得很窄：BTNS 应替代“没有保护”，而不是替代“更强保护”。如果实现依次尝试证书、匿名公钥、明文，直到通信成功，它创造了另一个降级系统。

真正需要保留的不是“最终连通”，而是每条分支的结论。已知身份认证失败，是强规则成功执行否决的证据；匿名准入，是另一条显式政策的结果；未保护传输，是第三个决定。把三者压成一个 availability 指标，会让安全边界从历史中消失。

证据边界

官方资料能够证明标准文本、历史状态和设计威胁，不能证明某个现有产品实现了 BTNS、某个网络正在使用它或某次攻击已经发生。RFC 4306 时代的裸 RSA 形式后来被 RFC 7296 移除，又由 RFC 7670 以通用形式恢复。任何生产断言都需要版本、构建、配置、跟踪和包级观察。

按照 Lu Heng 的现实层次，声称身份、钥匙持有、PAD 权限、SPD 权限、SA 状态、受保护数据包、上层主体和业务结果不应互相代言。RFC 5386 最值得保留的不是“弱安全也不错”这句口号，而是更严格的制度：弱通道只能占据强关系没有认领的空间，不能吞掉强关系已经作出的拒绝。