Summary

  • A matching PATH_RESPONSE shows that the peer receiving a particular unpredictable PATH_CHALLENGE could return its eight-byte value for the challenged address or path.
  • That result is narrower than cryptographic peer authentication, application identity, authorization, path-MTU validation, future reachability, or transaction success.
  • Operators should preserve the distinction in their evidence ledger instead of converting one path event into a durable trust or identity verdict.

An operator sees a matching PATH_RESPONSE and promotes it into a durable identity record. That is the error this briefing is designed to prevent. RFC 9000 defines path validation as a reachability check over a network path. It is useful during connection migration and may probe a new local address before migration, but its success condition is deliberately modest.

The endpoint sends PATH_CHALLENGE on the path it wants to test. Its data must contain at least 64 bits of entropy, represented by an unpredictable eight-byte value. The value matters because merely receiving a challenge should be easier than guessing its contents. A receiving endpoint returns a PATH_RESPONSE containing the same data. The response is sent on the path where the challenge arrived, and the initiator accepts a matching response arriving on any network path.

This is carefully bidirectional evidence, not an identity ceremony: the responder demonstrates return of the value over the receiving path, while the initiator does not impose a response arrival path that could enable a migration attack.

Validation succeeds when the received response contains data from a previous challenge. An ACK for the packet carrying PATH_CHALLENGE is not enough. A malicious peer could spoof that ACK, whereas the matching unpredictable value supplies the specific returnability evidence being tested. Multiple challenges may be sent to tolerate loss, but several should not be placed in one packet. Other packets or frames on the candidate path do not substitute for the required matching response.

The tested object is an address/path condition at a point in time. It is not a person, device, account, application principal, authorization grant, or cryptographic peer identity. Those distinctions are operational conclusions from the narrow protocol condition, not additional claims made by path validation. A system may separately establish cryptographic authentication, application identity and authorization; those fields must not be overwritten by a path-validation result. Likewise, a successful response says nothing about a later business outcome or a retention decision.

Path validation is also not path-MTU validation. A successful challenge in a datagram smaller than 1200 bytes can validate the peer address or path without proving support for the required path MTU. A further expanded challenge is needed for that separate question. PATH_RESPONSE datagrams are normally expanded to at least 1200 bytes, but expansion cannot exceed the anti-amplification limit. The ledger therefore needs distinct address-validation and path-MTU results, alongside datagram size and anti-amplification state.

Failure is not declared merely because one response is missing. RFC 9000 recommends a timer based on three times the larger of the current-path or new-path PTO, with multiple PTOs allowed so a single lost challenge or response does not decide the result. The endpoint fails validation only when it abandons the attempt. If one candidate path is abandoned, the connection need not end when another valid path remains usable. A failed probe means that candidate path is not usable for that connection.

Address changes, including NAT rebinding, trigger validation unless the address was previously validated. This does not make QUIC path validation a NAT-traversal mechanism; RFC 9000 does not provide the synchronization mechanisms needed for effective NAT traversal. During migration, a new path can have different capacity and timing. QUIC resets congestion-control and RTT state rather than treating measurements from the previous path as guarantees.

A practical evidence ledger should record a connection-scoped path identifier and privacy-safe challenge digest; challenge and response times; the tested local and remote address tuple; datagram size; matching result; and response arrival path. It should separately record peer-address validation, path-MTU validation, anti-amplification state before and after validation, current and candidate path PTO inputs, abandonment reason and timer outcome. The trigger should identify NAT rebinding or migration, prior validated-address evidence and alternative usable paths.

Cryptographic authentication, application identity, authorization, outcome and retention policy belong in separate fields. Privacy-safe digests and retention controls are operational recommendations, not QUIC requirements.

The five-dimensional boundary with earlier work is important. TR-039 concerns the amplification budget before address validation, not the meaning of a completed path exchange. TR-033 concerns DNS Cookie return-path evidence. TR-043 concerns Retry integrity. TR-040 separates connection IDs from identity. TR-061 concerns server-issued NEW_TOKEN evidence across future connections. None of those dimensions should be collapsed into this one.