]> Ethereum Foundation

marco@marcopolo.io

martenseemann@gmail.com

Transport QUIC Internet-Draft This document specifies an extension to QUIC that allows a server to advertise a prioritized set of alternative addresses. This allows a client to migrate the connection as the availability or preference of server addresses changes. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction QUIC supports client-initiated connection migration, allowing a connection to survive changes to the client's address and enabling the client to select among available paths (). A server can advertise a preferred address during the handshake (), but cannot update that address or advertise additional addresses during the connection. Some deployments have multiple server addresses whose availability or preference can change over the lifetime of a connection. These include multihomed endpoints, relays, proxies, and peer-to-peer systems. This document defines an extension that allows a server to advertise a prioritized and replaceable set of alternative addresses. The client remains responsible for validating these addresses and initiating any connection migration. Address discovery and NAT traversal mechanisms, including hole punching, are out of scope of this document.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Negotiating Extension Use alternative_address (0xff0969d85c): Clients advertise their support of this extension by sending the alternative_address (0xff0969d85c) transport parameter () with an empty value. Sending this transport parameter signals to the server that the client understands the ALTERNATIVE_ADDRESS frame. Servers MUST NOT send this transport parameter. A client that supports this extension and receives this transport parameter MUST abort the connection with a TRANSPORT_PARAMETER_ERROR. Endpoints MUST NOT remember the value of this extension for 0-RTT.

Path Validation Advertising an alternative address does not create a new path or initiate connection migration. As in , clients remain responsible for initiating all connection migrations. A client initiates path validation by sending probing packets to an advertised address and only migrates after validation succeeds. Packets from unadvertised server addresses are handled as specified by RFC 9000, except while validating an advertised address as described below. Such packets do not create new paths. The response to a client-initiated PATH_CHALLENGE can arrive from a server address other than the address being validated. requires the server to send the PATH_RESPONSE on the path where it received the PATH_CHALLENGE, but prohibits the client from enforcing this requirement. A matching PATH_RESPONSE received on any path validates the path on which the PATH_CHALLENGE was sent (). The server might also send a PATH_CHALLENGE to validate the path in its sending direction. Consequently, while validating an advertised address, a client MUST NOT discard a successfully authenticated probing packet solely because it was received from an unadvertised server address. Processing the packet does not validate its source address or make that address eligible for migration.

Alternative Address Frame A server uses an ALTERNATIVE_ADDRESS frame to advertise its complete set of alternative addresses and their priority relative to the current path. Each frame replaces the state established by any previously processed ALTERNATIVE_ADDRESS frame. The frame uses the following format, following the conventions described in : The Entry Count field contains the number of Address Entry fields in the frame. An Address Entry starts with an 8-bit Address Type and has one of the following formats: The Priority Hint field is a QUIC variable-length integer. On each side of the CURRENT_PATH entry, lower values indicate higher priority and entries with the same value form a priority group in which the server expresses no preference. Entries on each side MUST appear in ascending Priority Hint order. Priority Hint values have meaning only relative to other values on the same side of the CURRENT_PATH entry; values on opposite sides are unrelated. A server can assign the same value to every entry. The CURRENT_PATH entry is a sentinel representing the server address of the current path and carries no priority hint, address, or port. A frame MUST contain exactly one CURRENT_PATH entry and MUST contain each IP address and port tuple at most once. Receipt of a frame that violates these requirements, does not order entries as required, or contains an unknown Address Type MUST be treated as a connection error of type FRAME_ENCODING_ERROR. IPV4 and IPV6 entries before CURRENT_PATH have higher priority than the current path. The client SHOULD promptly validate these addresses and migrate to a validated address. Entries after CURRENT_PATH are backup addresses. The client MAY validate paths to these addresses, but SHOULD NOT migrate to one solely because it was advertised. Priority hints are advisory. A client MAY use them to decide which addresses to validate, which validations to perform in parallel, and which validated address to use. A client MAY disregard priority hints based on local policy. A server MUST use a larger Sequence Number for each address-set update. A client MUST ignore an ALTERNATIVE_ADDRESS frame whose Sequence Number is not greater than that of the most recently processed ALTERNATIVE_ADDRESS frame. Therefore, a newer frame atomically replaces an older address set even if the frames are received out of order. An address omitted from the newer frame is no longer advertised by this extension. The client SHOULD stop probing or using a non-current path associated with an address that is no longer advertised. ALTERNATIVE_ADDRESS frames are ack-eliciting and MUST only be sent in the application data packet number space.

Address Selection and Reachability The mechanism by which a server discovers and selects addresses to advertise is outside the scope of this document. An advertised address is a candidate and does not imply reachability from the client. A server SHOULD limit the advertised set to addresses that it has reason to believe might be reachable, and SHOULD update the set when it learns that an address is no longer usable. Advertised addresses can include private-use, unique-local, or other limited-scope addresses. A client MAY decline to probe an address according to local policy. A client MUST successfully validate a path before sending non-probing frames on it. The request forgery considerations in Sections 21.5.3 and 21.5.6 of apply.

Connection ID Management Each endpoint SHOULD advertise an active_connection_id_limit that allows its peer to supply enough connection IDs for all paths that the endpoint might probe concurrently. This applies in both directions. The server SHOULD ensure that the client has a sufficient number of available and unused connection IDs, as the client will be unable to probe paths without an unused connection ID. The server MAY bundle one or more NEW_CONNECTION_ID frames with an ALTERNATIVE_ADDRESS frame. Likewise, the client SHOULD ensure that the server has enough connection IDs to probe new paths.

Interaction with the Multipath Extension for QUIC This extension complements the Multipath extension for QUIC by allowing the server to contribute more information to the client for alternative paths.

Security Considerations

Request Forgery Attacks The same considerations from apply here as well.

DDoS - Thundering herd A malicious server could wait until it has received a large number of clients, and request a migration from all of them at the same time to a victim endpoint. If the clients all migrate at the same time, they may overload or otherwise negatively impact the victim endpoint. Clients may mitigate this by randomly delaying the migration.

IANA Considerations

QUIC Transport Parameter This document registers the alternative_address transport parameter in the "QUIC Transport Parameters" registry established in . The following fields are registered:

Value:

0xff0969d85c

Parameter Name:

alternative_address

Status:

Provisional

Specification:

This document

Change Controller:

IETF (iesg@ietf.org)

Contact:

Marco Munizaga (marco@marcopolo.io)

QUIC Frame Types This document registers the ALTERNATIVE_ADDRESS frame in the "QUIC Frame Types" registry established in . The following fields are registered:

Value:

0x1d5845e2

Frame Type Name:

ALTERNATIVE_ADDRESS

Status:

Provisional

Specification:

This document

Change Controller:

IETF (iesg@ietf.org)

Contact:

Marco Munizaga (marco@marcopolo.io)

Normative References This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments TODO acknowledge.

Questions

• Any new security considerations from allowing a dynamically chosen preferred address?