8. Address Validation

Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own.

The primary defense against amplification attacks is verifying that an endpoint is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address.

8.1 Address Validation during Connection Establishment

Connection establishment implicitly provides address validation for both endpoints. In particular, receipt of a packet protected with Handshake keys confirms that the peer successfully processed an Initial packet. Once an endpoint has successfully processed a Handshake packet from the peer, it can consider the peer address to have been validated.

8.1.1 Token Construction

A token sent in a Retry packet or NEW_TOKEN frame MUST be constructed in a way that allows the server to identify how it was provided to the client.

8.1.2 Address Validation Using Retry Packets

Upon receiving the client's Initial packet, the server can request address validation by sending a Retry packet (Section 17.2.5) containing a token.

8.1.3 Address Validation for Future Connections

A server MAY provide clients with an address validation token during one connection that can be used on a subsequent connection.

8.1.4 Address Validation Token Integrity

An address validation token MUST be difficult to guess. Including a large enough random value with at least 128 bits of entropy in the token would be sufficient.

8.2 Path Validation

Path validation is used during connection migration (see Section 9) to verify reachability after a change of address. In path validation, endpoints test reachability between a specific local address and a specific peer address, where an address is the two-tuple of IP address and port.

8.2.1 Initiating Path Validation

To initiate path validation, an endpoint sends a PATH_CHALLENGE frame (Section 19.17) containing an unpredictable payload on the path to be validated.

8.2.2 Path Validation Responses

On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame (Section 19.18).

8.2.3 Successful Path Validation

Path validation succeeds when a PATH_RESPONSE frame is received that contains the data that was sent in a previous PATH_CHALLENGE frame.

8.2.4 Failed Path Validation

Path validation fails when a PATH_RESPONSE frame is not received within the expected time.