Summary

  • DTLS Connection ID 让接收方定位既有安全上下文，并不自动验证承载 UDP 数据报的新源地址。
  • basic RRC 直接检查新地址；enhanced RRC 先询问旧路径是否仍为首选，再决定是否检查新路径。
  • 受保护的 Cookie 往返只支持当次绑定判断；变化原因、路径对称与持久性、后续数据包和应用结果必须分别取证。

连接是熟悉的，地址却不是

一个受保护的数据报从未绑定的新地址抵达。Connection ID 能把它带回既有 DTLS 安全上下文，记录也能在该上下文下通过认证。此时系统只回答了“这条记录属于哪个连接”，还没有回答“对端能否在这个地址接收并返回数据”。

RFC 9853 正是填补这道缝隙。它更新 RFC 9146 的 DTLS 1.2 CID 和 RFC 9147 的 DTLS 1.3，引入 Return Routability Check。CID 负责找回安全上下文；RRC 则在接收方修改 CID 与地址的绑定之前，验证特定地址上的对端能否完成受保护的挑战往返。

规范并不知道地址为什么改变。原因可能是 NAT 映射改变、对端主动迁移，也可能是攻击者把真实记录复制到更快路径上竞速。单凭“源地址不同”不能给原因贴标签。

三种消息不是同一个“已验证”

RRC 通过扩展号 61 协商，只能在双方都交换该扩展后使用。ContentType 为 27。每条消息携带一个八字节、64 位熵的 Cookie，并由当前 DTLS 安全上下文认证和加密。IANA TLS 参数表登记了 path_challenge、path_response 与 path_drop。

path_challenge 发起检查；path_response 回显 Cookie；path_drop 表示旧路径仍能用但已不再是首选，于是发起方必须转而对新地址执行 basic 检查。尤其在 enhanced 模式中，旧路径返回 path_response 的结果是继续使用旧绑定，而不是迁移成功。把所有匹配响应都统计为“新路径验证通过”，会把协议决策倒置。

Cookie 还必须保持新鲜。规范警告，如果缺少防重放而重复使用旧 Cookie，攻击者可能重放过去的响应。因此有效收据不是永久的 RRC passed 布尔值，而是连接代次、挑战代次、Cookie 标识、地址、模式、计时器和响应类型的组合。

basic 检查只授权一次绑定更新

basic 流程中，发现地址变化的一方把 path_challenge(cookie) 发往观察到的新地址并启动计时器 T。对端验证消息后，把 path_response(cookie) 发回挑战来源地址。发起方确认 Cookie 匹配后更新对端地址绑定；超时则不更新。

RFC 说这种返回方式保证该挑战路径双向可用。这个保证应严格限定在当次交换：一个受保护的挑战出去，一个受保护的回答回来。它不证明两个方向经过同一组链路，不证明未来仍然稳定，也不覆盖反向 PMTU，更不证明后续应用数据完成交付。

验证完成前，接收方必须停止发送缓存的应用数据，或把发往未验证地址的量限制在从该地址收到有效数据的三倍以内。这是反放大约束，不是连续性承诺。恰恰相反，暂停发送说明“找回连接”与“恢复业务”是两个阶段。

enhanced 检查先向旧路径提问

basic 主要缓解伪造受害者地址带来的放大。enhanced 处理更强的离路径攻击者：攻击者能观察真实记录，并持续把副本通过更快路径抢先送达，使复制流量看起来像合法重绑定。

enhanced 首先把挑战发往先前有效地址。若旧路径仍是首选，对端返回 path_response，发起方保留旧绑定；若旧路径仍活着但已非首选，对端返回 path_drop，发起方才对新地址执行 basic 检查；旧路径超时也会触发 basic，但超时本身不会更新绑定。

NAT 重绑定揭示了视角差异：发起验证的接收方看到新路径，响应方仍把旧路径看作当前首选。path_drop 需要响应方知道自己曾主动迁移，不能把它当作所有地址变化的通用答案。

规范也承认 enhanced 防御并不完美。如果转发路径长期更快，协议可能无法区分攻击与真正的路由改善。更快不是善意的证明。

计时器和嵌套重绑定定义了失败语义

RRC 允许为容忍丢包而发送多个、经过节奏控制的挑战。若已知旧路径 RTT，T 应为三倍 RTT；未知时建议一秒，具体部署配置可另定。超时只说明在该计时与重试策略下没有及时收到合格响应，不能直接证明对端消失、地址伪造或服务中断。

验证期间再次发生地址变化时，规范的语义更明确：算法不处理嵌套重绑定；响应被丢弃，验证超时，绑定不更新，等新数据到来再开始新的验证。若实现直接用最新地址覆盖正在等待的挑战，便抹掉了协议需要的代次边界。

连续性需要五张收据

第一张收据属于连接定位：DTLS 版本、CID、RRC 是否协商、安全上下文代次、记录 epoch、观察时间与新源地址。

第二张属于验证：basic 或 enhanced、检查的是旧地址还是新地址、挑战代次、受保护 Cookie 引用、计时器依据、重传、响应类型和结果。它必须保留“更新绑定”“维持旧绑定”与“启动下一次检查”的区别。

第三张属于绑定行为本身：旧地址、新地址、选择结果、时间和作出决定的端点。否则，成功交换和状态写入只是被假定为同一件事。

第四张属于恢复后的数据包：验证后每个相关方向首个被接收的受保护包、epoch、计数器重置和丢失信息。发送调用返回不等于远端收到了包。

第五张属于应用：同一证据窗口内，一条唯一请求被接受、处理并在期限内得到响应。这才是服务连续事实，Cookie 无法代替。

规范建议不是事故证据

RFC 9853 强烈建议为 SIEM 与排障统计失败检查，建议记录同一挑战收到多个响应的情形，也指出频繁探测可能表示路径不稳定。这些是合理的日志建议与待调查信号，不是已经发生攻击或中断的事实。

版本也影响解释。DTLS 1.2 中，未包在 tls12_cid 内的 RRC 消息会暴露内容类型，可能被中间盒干扰；DTLS 1.3 则向路径观察者隐藏记录类型。因此，一条失败日志在归因前必须带上版本与记录格式。

RFC Editor 页面、Datatracker 记录与勘误查询能证明规范状态和出版来源，不能证明部署与服务结果。

Lu Heng 的运行代码优先给出正确顺序：文档定义可验证的兼容边界，运行系统提供现实证据。最小初始规范要求共同规则保持狭窄且可在本地验证；现实层与象征层则提醒我们，象征性的“已验证”标签不能替代可执行的数据包和应用结果。

Sources