]> 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 of, or preference among, 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 relative 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 Clients advertise support for ALTERNATIVE_ADDRESS frames by sending the alternative_address (0xff0969d85c) transport parameter (). CURRENT_PATH, IPv4, and IPv6 are implicitly supported. The value is a possibly empty sequence of QUIC variable-length integers () listing additional supported Address Types, read to the end of the parameter value. Values MUST be in strictly increasing order and MUST NOT contain duplicates. Servers MUST ignore unknown Address Types in the list and MUST treat a truncated integer as a connection error of type TRANSPORT_PARAMETER_ERROR. Servers MUST NOT send ALTERNATIVE_ADDRESS frames without this transport parameter or include Address Types not supported by the client. 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. A server MUST NOT remember this transport parameter for 0-RTT in a subsequent connection.

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 MUST also validate the path in its sending direction before sending non-probing packets on that path, following . 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 hints. Frames with higher Sequence Numbers supersede those with lower Sequence Numbers. The frame uses the following format, following the conventions described in : The Entry Count field contains the number of Address Entries in the frame. An Address Entry starts with a variable-length integer Address Type (). Except for CURRENT_PATH, each entry MUST include a Priority Hint immediately after the Address Type. This document defines the following entry types: The CURRENT_PATH entry is a sentinel that separates the address entries into two sets. When multipath has not been negotiated, 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. The corresponding behavior when multipath has been negotiated is described in . 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 nondecreasing 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. A frame MUST contain exactly one CURRENT_PATH entry. Receipt of a frame that fails this requirement, does not order entries as required, or contains an unknown or unnegotiated Address Type () MUST be treated as a connection error of type FRAME_ENCODING_ERROR. 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 increment the Sequence Number on each ALTERNATIVE_ADDRESS frame it sends. 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 be sent only in the application data packet number space. Clients MUST NOT send ALTERNATIVE_ADDRESS frames. A server MUST treat receipt of an ALTERNATIVE_ADDRESS frame as a connection error of type PROTOCOL_VIOLATION.

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 IPv4 addresses, unique local IPv6 unicast addresses, and other addresses with limited scope. 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 and 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 Managing Multiple Paths for a QUIC Connection The mechanism described in enables a QUIC connection to use multiple paths simultaneously. This extension complements that mechanism by allowing the server to advertise addresses for alternative paths. When multipath has been negotiated, the client SHOULD promptly establish paths to addresses in IPv4 and IPv6 entries before CURRENT_PATH, as described in . The endpoints' multipath scheduling and path management determine how these paths are used and whether they supplement or replace existing paths. Entries after CURRENT_PATH remain backup addresses. The client MAY validate paths to these addresses, but SHOULD NOT start using them for application data solely because they were advertised.

Security Considerations

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

DDoS - Thundering herd A malicious server could establish connections with a large number of clients and advertise a victim endpoint as a higher-priority alternative to all of them at the same time. 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 (note that, prior to publication, the value will be replaced by a new value that encodes in two bytes)

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 (note that, prior to publication, the value will be replaced by a new value that encodes in two bytes)

Specification:

This document

Change Controller:

IETF (iesg@ietf.org)

Contact:

Marco Munizaga (marco@marcopolo.io)

QUIC Alternative Address Types This document creates the "QUIC Alternative Address Types" registry under the "QUIC" registry group, following . It covers 62-bit values, recorded in hexadecimal. Permanent registrations also include an Address Type Name field containing a short mnemonic. The initial entries are:

Value	Address Type Name	Specification
0x00	CURRENT_PATH
0x01	IPv4
0x02	IPv6

These entries are permanent, with IETF as Change Controller and quic@ietf.org as Contact. All other values are unassigned.

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. Alibaba Inc. Uber Technologies Inc. University of Mons (UMONS) UCLouvain and WELRI Private Octopus Inc. Ericsson This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. It introduces explicit path identifiers to create, delete, and manage multiple paths. This document does not specify address discovery or management, nor how applications using QUIC schedule traffic over multiple paths. 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.