摘要

  • RFC 9868 利用 UDP Length 之后、IP 数据报结束之前的 surplus area 承载传输层选项；它与 UDP 用户数据是不同的区域。
  • DTLS 保护的是用户数据而非 UDP 传输层选项。校验成功、选项被发出或负载被保护，都不能代替对选项保护、接收端处理和后续结果的独立证据。

协议字段最容易被放大的并不是长度，而是人们附会给它的保证。RFC 9868 利用 UDP Length 与 IP 传输负载长度不完全相同的空间，在 UDP 用户数据之后定义了 surplus area。这个设计让 UDP 可以承载传输选项，却没有把该区域变成应用负载的隐藏部分，更没有让一个格式存在就等于另一端支持、路径保留或应用采用。

边界是可观察的。UDP Length 之前是用户数据；其后、仍处在 IP 数据报中的字节由支持该扩展的实现解释为选项。RFC 9868 仍把 UDP 保持为无状态、单向的最小传输。选项是框架，而不是独立完成的协议。发送端能构造某个选项，不代表接收端必须理解或使用它；除规定的必须支持集合外，接收端可按本地设置忽略选项。

DTLS 的范围尤其不能被扩大。RFC 9868 明说 TLS 和 DTLS 不保护传输层，它们保护的是 UDP 用户数据。RFC 9868 的机制也没有为 UDP 头、负载或 surplus area 自动提供防篡改能力，除非另选 OCS、AUTH、UENC 等选项，或由 IPsec 等其他层覆盖。若没有合适加密，选项在路径上仍可见。因此，“DTLS 已启用”只能说明与用户数据有关的保护范围，不能证明相邻的 UDP 选项已保密、已认证或未被改变。

OCS 也应被准确命名。它检测 surplus area 的错误；它不是授权判断、路径认证或业务批准。为保留传统 UDP 行为，UDP 校验通过但适用 OCS 失败时，实现可以仍把用户数据交给上层，同时忽略其他选项。应记录的是具体实现以何种本地策略处理了一个选项，而不是把一次校验或转发写成“选项成功”或“服务安全”。

发送与接收是另一条不可压缩的证据链。除必须支持选项外，发出选项并不会强制远端做事。RFC 9869 的 UDP-options DPLPMTUD 也要求两端启用，并要求探测获得明确确认。选项语法的存在不是路径测量，不证明中间设备保留了区域、对端处理了值，或更大的应用消息已经送达。

RFC 9868 还记录某些路径可能截去 surplus area，或直接丢弃含选项的数据报。一次发送日志、DTLS 记录、OCS 结果、接收端确认和应用结果因而是不同的事实。它们可以被关联，却不能互相替代。Heng Lu 所强调的共同工件与本地决定的区分在这里很直接：RFC 提供一个可验证的有限格式；是否启用、要求何种保护、如何在失败后转发，以及什么证据足以触发后续行动，仍由本地承担责任。

Sources