摘要

  • 匹配的 PATH_RESPONSE 表明，接收特定不可预测 PATH_CHALLENGE 的对端能够返回其中的八字节数据。
  • 这不是人的身份、设备或账户身份、应用授权、密码学对端身份、路径 MTU 或未来可达性的证明。
  • 运营记录应把路径返回性与认证、授权、业务结果和保留策略放在不同字段中。

最危险的误读，往往发生在一次 PATH_RESPONSE 匹配之后：运营人员把它写入长期身份或信任记录。RFC 9000 给出的含义更窄。路径验证检查对端能否通过某条网络路径到达。它可用于连接迁移，也可在迁移前探测新的本地地址，但它并不负责回答“谁在对面”这个问题。

端点在希望验证的路径上发送 PATH_CHALLENGE。挑战数据至少需要 64 位熵，也就是一个不可预测的八字节值。接收端以 PATH_RESPONSE 原样回显该数据。响应必须在挑战到达的路径上发送；而发起验证的一方接受从任意网络路径到达的匹配响应。这两个规则必须一起理解：响应方证明了自己能沿接收路径返回挑战值，发起方则不能强行要求响应从某条固定路径抵达，否则可能形成迁移攻击条件。

当收到的 PATH_RESPONSE 包含此前 PATH_CHALLENGE 的数据时，验证成功。承载挑战的报文收到 ACK 并不足够，因为恶意对端可以伪造 ACK。为容忍丢失，可以发送多个挑战，但不应把多个挑战放进同一个报文。新路径上到达的其他报文或帧，也不能替代所需的匹配响应。

这里被验证的是某个时刻的地址和路径条件，而不是人、设备、账户或应用主体。它也不证明密码学对端身份、应用授权、交易结果或未来路径可用性。这些边界是根据 RFC 9000 狭窄的成功条件作出的运营解释，不是协议凭空提供的身份声明。因此，密码学认证、应用身份、授权、业务结果和证据保留策略都应保持独立。

路径验证与路径 MTU 验证不能混为一谈。在小于 1200 字节的数据报中成功完成挑战，可以验证对端地址或路径，却不能证明路径支持所需 MTU。要检查 MTU，必须进行进一步的扩展挑战。PATH_RESPONSE 数据报通常扩展到至少 1200 字节，但不得超过反放大限制。因此，记录中必须分别保存地址验证结果与路径 MTU 结果，并记录数据报大小及验证前后的反放大状态。

缺少一次响应并不立即等于失败。RFC 9000 建议使用当前路径 PTO 与新路径 PTO 中较大者的三倍作为基础计时，并允许经历多个 PTO，以免单个丢失的挑战或响应决定结果。只有验证端放弃尝试时，路径验证才算失败。放弃一条候选路径也不必然结束连接，只要还有另一条有效路径可用。新路径探测失败的含义是：该路径对这条连接不可用。

检测到对端地址变化时，包括 NAT 重绑定，端点必须重新验证路径，除非该地址此前已经验证过。这并不意味着 QUIC 路径验证能够穿越 NAT；RFC 9000 没有提供有效 NAT 穿越所需的同步机制。迁移后路径可能具有不同的容量和时延，因此 QUIC 会重置拥塞控制与 RTT 状态，而不会把旧路径测量当成新路径的保证。

一个可审计的运营账本，应保存连接范围内的路径标识和保护隐私的挑战摘要、挑战与响应时间、受测本地和远端地址元组、数据报大小、匹配结果以及响应到达路径。它还应分别记录对端地址验证、路径 MTU 验证、反放大状态、当前与候选路径的 PTO 输入、放弃原因和计时结果。NAT 重绑定或迁移触发原因、此前的地址验证证据、其他可用路径也要单独记录。密码学认证、应用身份、授权、业务结果和保留策略不能共享一个“可信”字段。隐私安全的摘要与保留控制是运营建议，不是 QUIC 要求。

五个维度的边界同样不能丢失。TR-039 讨论地址验证前的反放大预算；TR-033 讨论 DNS Cookie 的返回路径证据；TR-043 讨论 Retry 完整性；TR-040 将连接 ID 与身份分开；TR-061 讨论未来连接中复用 NEW_TOKEN 的地址验证证据。PATH_RESPONSE 不应被写成这些主题的替代物。