]>

martenseemann@gmail.com

Apple Inc.

One Apple Park Way Cupertino, California 95014 United States of America ekinnear@apple.com

Transport QUIC QUIC ICE NAT traversal hole punching This document specifies a QUIC extension for traversing Network Address Translators (NATs). Endpoints use an existing proxied QUIC connection to coordinate path validation attempts that create the NAT bindings needed for a direct path and test its connectivity. Application data can be exchanged over the proxied path while NAT traversal is in progress. Once a suitable direct path has been validated, the connection can migrate to it. Discussion Venues Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction This document specifies an extension to QUIC () that enables endpoints behind NATs to establish a direct path for an existing connection. The extension uses QUIC's path validation mechanism to create NAT bindings and test connectivity, and connection migration to move the connection to a suitable direct path. The endpoints first establish a QUIC connection over a proxied path (). This connection carries both application data and the signaling needed to coordinate NAT traversal. The server advertises its address candidates, and the client pairs them with its own candidates and requests coordinated path validation attempts. Both endpoints send path validation packets toward the selected peer addresses to create the necessary NAT bindings. Application data can be exchanged over the proxied path while these attempts are in progress. If a suitable direct path is validated, the connection can migrate to it. Otherwise, the endpoints can continue using the proxied path. The extension borrows address candidate pairing concepts from Interactive Connectivity Establishment (ICE; ), but does not use the ICE protocol.

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.

Sending base:

The local sending context used for an address candidate, such as a UDP socket on a particular network interface or a tunnel.

Background: NAT Traversal with ICE When an external signaling channel is used, the QUIC connection is established after the two ICE agents have agreed on a candidate pair. This mode doesn't require any modification to existing QUIC stacks. In particular, it does not necessitate the negotiation of the extension defined in this document. For address discovery to work, QUIC and ICE need to use the same UDP socket. Since this requires demultiplexing of QUIC and STUN packets, the QUIC bit cannot be greased as described in . Once ICE has completed, the client immediately initiates a normal QUIC handshake using the server's address from the nominated address pair. The ICE connectivity checks should have created the necessary NAT bindings for the client's first flight to reach the server and for the server's first flight to reach the client.

NAT Traversal Extension Overview The extension described in this document assumes that the endpoints first establish a QUIC connection over a proxied path. One or both endpoints can be behind a NAT. The terms client and server refer to their roles in this QUIC connection: the client initiates the handshake, and the server responds. The proxied path runs through a relay, which forwards UDP payloads between the endpoints without terminating the QUIC connection. Each endpoint's connection to the relay (for example, an HTTP connection to a proxy) is separate from the end-to-end QUIC connection. shows a setup with both endpoints behind NATs. The dotted line shows the direct path that the endpoints attempt to establish.

Proxied and direct paths between QUIC endpoints

Establishing the proxied path is out of scope for this document. This can be done in multiple ways, for example using Traversal Using Relays around NAT (TURN; ), CONNECT-UDP Bind (), or UDP Rendezvous over HTTP (). Peer discovery and address candidate gathering () are also out of scope. The protocol is asymmetric by design. Only the server advertises its address candidates over the connection. The client pairs them with its own candidates and decides which pairs to try and when. The server authorizes attempts and probes the requested pairs. This allows the client to change its pairing and scheduling algorithms without updating the server. Both endpoints send QUIC path validation packets to create the NAT bindings needed for a direct path and test its connectivity. Once a suitable direct path has been validated, the connection can migrate to it. Multiple paths can be validated in parallel. When using QUIC Multipath , these paths may be used at the same time; however, this extension does not require multipath.

Candidate Discovery and Exchange

Gathering Address Candidates The gathering of address candidates is out of scope for this document. Endpoints MAY use the logic described in Sections and of , or they MAY use address candidates provided by the application.

Advertising Server Address Candidates The server advertises its address candidates using ALTERNATIVE_ADDRESS frames, as defined in . Each frame advertises the complete set of alternative addresses and replaces the previously advertised set. The server SHOULD NOT wait until address candidate discovery has finished; instead, it SHOULD update the advertised set as soon as new candidates become available. This speeds up NAT traversal and is similar to Trickle ICE (). The server stores the sending bases associated with each advertised address. Candidates with different sending bases MUST be advertised as separate entries, even if their advertised addresses are identical. Each advertisement of an address MUST retain one entry per base ever advertised for it on this connection. Without an increase in the entry count, the client cannot distinguish a replaced base from an unchanged one and might not schedule another attempt. Across advertisements, entries for the same address MUST retain their relative order and associated sending bases. Entries for new bases MUST follow the existing entries for that address. The server MAY withdraw an address by omitting all its entries from a subsequent address-set update.

Forming Candidate Pairs The client matches the address candidates sent by the server with its own address candidates, forming candidate pairs. describes an algorithm for pairing address candidates. The client is free to use a different algorithm. The client MUST treat local candidates with different sending bases and distinct server entries as separate candidates, even if their addresses are identical. It SHOULD request one attempt per compatible pair. Across advertisements, the client identifies a server candidate by its address and position among entries for that address.

Coordinated Path Probing The server authorizes attempts using PUNCH_GRANT (). Each grant permits one independent path validation attempt for an address pair. The client uses a grant by sending PUNCH_REQUEST with its Grant ID and the selected address pair on an established path. It SHOULD start validation immediately after sending this request; the server SHOULD start immediately upon accepting it. Validation follows , with additional rate limits (). Each endpoint MUST set its own timeout following . Each endpoint MUST send probe packets containing PATH_CHALLENGE frames for an attempt from a single sending base to the peer address specified in the PUNCH_REQUEST. Each endpoint MUST report success or timeout using PUNCH_DONE (); the server MUST also report rejection. Before sending it, the endpoint MUST permanently stop sending probe packets containing PATH_CHALLENGE frames for that attempt. PUNCH_DONE does not stop the peer's probing or change its validation result. The client SHOULD request attempts as candidate pairs and unused grants become available, but MAY delay requests to prioritize pairs.

Grant Limits The client's nat_traversal transport parameter () sets the initial cumulative grant limit. MAX_PUNCH_GRANTS () can increase it. The server MUST NOT issue a grant whose Grant ID is greater than or equal to the largest limit received. The client MUST treat receipt of a grant at or above its largest advertised limit as a connection error of type PROTOCOL_VIOLATION. The server decides when to issue grants within the limit; the client decides when to increase it.

Punching Connection IDs This document introduces punching connection IDs, a new type of connection ID for coordinated path probing. They have the same wire format in packet headers as ordinary connection IDs and MUST satisfy the unlinkability requirements in . The server and client each issue two punching connection IDs per grant, using PUNCH_GRANT and PUNCH_REQUEST, respectively. The IDs MUST be distinct from all others issued by that endpoint on the connection. In most circumstances, only one of the two connection IDs is needed, but there are certain network setups where both need to be used (). The NEW_CONNECTION_ID and RETIRE_CONNECTION_ID mechanisms of and the active_connection_id_limit transport parameter do not apply to punching connection IDs. Packets containing PATH_CHALLENGE or PATH_RESPONSE frames for an attempt MUST use one of the peer's punching connection IDs for that grant. Non-probing packets MUST NOT use these IDs. If a peer receives a non-probing packet that used a punching connection ID, it MUST close the connection with an error of type PROTOCOL_VIOLATION. An endpoint retires a grant's punching connection IDs after both sending and receiving PUNCH_DONE () for that attempt.

Use with Multipath When QUIC multipath is negotiated, packets using punching connection IDs MUST use the reserved Path ID 0xffffffff for nonce calculation and acknowledgments. All grants share its packet number space, which MUST persist for the connection's lifetime without resetting packet numbers. This ID is excluded from ordinary path allocation, path limits, and path management. PATH_ACK frames for this ID MUST be sent on a validated path using an ordinary destination connection ID.

Probes Received on a Different Base Under certain network configurations, a probe packet can arrive at a different base than the one the receiving endpoint selected for its attempt. This can happen when overlapping address spaces give candidates with different bases the same address (). Both endpoints follow the path validation rules of in addition to the coordinated probing rules above. An endpoint sends a packet containing the PATH_RESPONSE from the receiving base to the probe's source address. A matching PATH_RESPONSE validates the path on which the corresponding probe was sent, regardless of where the response arrives.

Amplification Attack Mitigation TODO describe exactly how to mitigate amplification attacks

Extension Negotiation Endpoints advertise their support of the extension by sending the nat_traversal (0x3d7e9f0bca12fea6) transport parameter (). The client's value is a single variable-length integer specifying the initial cumulative grant limit (). The server MUST send an empty value. An endpoint that understands this transport parameter MUST treat receipt of an invalid value as a connection error of type TRANSPORT_PARAMETER_ERROR. The client MUST also send the alternative_address transport parameter defined in . A server that understands nat_traversal MUST treat receipt of nat_traversal without alternative_address as a connection error of type TRANSPORT_PARAMETER_ERROR. This transport parameter MUST NOT be remembered for use in 0-RTT. The frames defined in this document MUST only be sent in 1-RTT packets.

Frames This extension defines the PUNCH_GRANT, MAX_PUNCH_GRANTS, PUNCH_REQUEST, and PUNCH_DONE frames.

PUNCH_GRANT Frame PUNCH_GRANT authorizes one attempt and supplies the two server-issued punching connection IDs (). The server MUST number new grants consecutively from 0 within each connection, subject to the client's grant limit (). Both Connection ID Length fields specify a length in bytes from 1 to 20; other values MUST be treated as FRAME_ENCODING_ERROR. PUNCH_GRANT is ack-eliciting and sent on a validated path. The Grant ID SHOULD be retransmitted on loss until acknowledged. This frame is only sent from the server to the client. Servers MUST treat receipt of a PUNCH_GRANT frame as a connection error of type PROTOCOL_VIOLATION.

MAX_PUNCH_GRANTS Frame Maximum Grants is the cumulative number of grants the server may issue, including grants already used. Servers MUST ignore values that do not increase the limit. MAX_PUNCH_GRANTS is ack-eliciting and sent on a validated path. On loss, the client MUST retransmit its current limit unless it has already been acknowledged. This frame is only sent from the client to the server. Clients MUST treat receipt of a MAX_PUNCH_GRANTS frame as a connection error of type PROTOCOL_VIOLATION.

PUNCH_REQUEST Frame The PUNCH_REQUEST frame contains the following fields:

Grant ID:

The grant used for this attempt ().

Connection ID Length and Connection ID:

The length in bytes and value of a client-issued punching connection ID (). Lengths outside 1 to 20 MUST be treated as FRAME_ENCODING_ERROR.

Client Address Type:

The address family of the Client IP Address field. The values 0x01 and 0x02 indicate IPv4 and IPv6, respectively, as in . Receipt of any other value MUST be treated as a connection error of type FRAME_ENCODING_ERROR.

Client IP Address:

The client's address candidate. This field is 32 bits long for IPv4 and 128 bits long for IPv6, as indicated by Client Address Type.

Client Port:

The port number of the client's address candidate.

Advertisement Sequence Number:

The Sequence Number of the referenced ALTERNATIVE_ADDRESS frame.

Entry Index:

The zero-based index of the selected IPv4 or IPv6 entry in that frame, counting all entries, including CURRENT_PATH.

The client MUST use a received, unused grant for each new attempt. Sending PUNCH_REQUEST permanently binds that grant to the client address and server entry reference, even if rejected. The client MUST send PUNCH_REQUEST:

• On an established path, using an ordinary destination connection ID and carrying one of its punching connection IDs. Only this copy starts the server's validation.
• In every probe packet containing PATH_CHALLENGE for the attempt, carrying its other punching connection ID.

The server MUST process both forms in either arrival order, ignoring duplicates of each form, and process the direct copy before answering its PATH_CHALLENGE. Both forms MUST use the same Grant ID, client address, Advertisement Sequence Number, and Entry Index; retransmissions MUST repeat each form's connection ID. Unissued Grant IDs, mismatched destination connection IDs, and detected conflicting values MUST be treated as PROTOCOL_VIOLATION. For the first established-path copy, the server MUST send PUNCH_DONE with Status STALE_ADVERTISEMENT if the referenced advertisement is older than its latest, without starting validation. Otherwise, an unsent advertisement or an index that does not select an IPv4 or IPv6 entry MUST be treated as PROTOCOL_VIOLATION. For accepted attempts, the server MUST use the selected entry's sending base. Later advertisements MUST NOT change the selected address or base. PUNCH_REQUEST is a probing frame () and is ack-eliciting. The established-path copy MUST be retransmitted on loss until it is acknowledged or the server's PUNCH_DONE is received, even after local probing ends. Direct copies MUST NOT be retransmitted independently. This frame is only sent from the client to the server. Clients MUST treat receipt of a PUNCH_REQUEST frame as a connection error of type PROTOCOL_VIOLATION.

PUNCH_DONE Frame The Grant ID identifies the attempt. Status reports the sender's result:

• SUCCEEDED (0x00): The sender's path validation succeeded.
• FAILED (0x01): The sender's path validation timed out.
• REJECTED (0x02): The server declined to start the attempt. The client SHOULD NOT retry the same candidate pair.
• STALE_ADVERTISEMENT (0x03): The referenced advertisement was superseded.

After STALE_ADVERTISEMENT, the client MUST use a newer advertisement for any retry. Each endpoint's Status MUST remain unchanged for a given Grant ID. Endpoints MUST treat detected conflicting statuses from the peer for a grant as a connection error of type PROTOCOL_VIOLATION. PUNCH_DONE can only be sent in response to a PUNCH_REQUEST. A client that receives a PUNCH_DONE frame with a Grant ID for which it didn't send a PUNCH_REQUEST frame MUST close the connection with an error of type PROTOCOL_VIOLATION. Due to packet reordering, a server might receive a PUNCH_DONE frame before receiving the corresponding PUNCH_REQUEST frame. Servers MUST treat an unissued Grant ID as a connection error of type PROTOCOL_VIOLATION. An unknown Status, or REJECTED or STALE_ADVERTISEMENT received by a server, MUST be treated as a connection error of type FRAME_ENCODING_ERROR. If PUNCH_DONE arrives before the request sent on the established path, the server MUST retain the Status and process that request normally when it arrives. PUNCH_DONE is a non-probing, ack-eliciting frame sent on a validated path. It MUST be retransmitted on loss until acknowledged.

Security Considerations This document expands QUIC's path validation logic to QUIC servers, allowing a QUIC client to request the sending of path validation packets on unverified paths. A malicious client can direct traffic to a target IP. This attack is similar to the IP address spoofing attack that address validation during connection establishment (see ) is designed to prevent. In practice, however, IP address spoofing is often additionally mitigated by ingress and egress filtering at the IP layer. This mitigation is not possible when using this extension. The server therefore needs to carefully limit the amount of data it sends on unverified paths.

IANA Considerations TODO: fill out registration request for the transport parameter and frame types

References Normative References Ethereum Foundation 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. 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. 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. This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). This document obsoletes RFC 5245. 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. This document describes a method for negotiating the ability to send an arbitrary value for the second-most significant bit in QUIC packets. Informative References Google LLC Google LLC The mechanism defined in "Proxying UDP in HTTP" (RFC 9298) only allows each UDP proxying request to transmit to a specific host and port. This is well suited for UDP client-server protocols such as HTTP/3, but is not sufficient for some UDP peer-to-peer protocols like WebRTC. This document defines an extension to that mechanism that enables such use cases. This document defines an Extended CONNECT protocol for relaying UDP between two clients authenticated by the same proxy. A Listener registers with the proxy, and a Client uses the resulting Rendezvous ID to connect to it. No public UDP address is allocated. If a host is located behind a NAT, it can be impossible for that host to communicate directly with other hosts (peers) in certain situations. In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called "Traversal Using Relays around NAT" (TURN), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the Interactive Connectivity Establishment (ICE) approach to NAT traversal, though it can also be used without ICE. This document obsoletes RFCs 5766 and 6156. This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to begin connectivity checks while they are still gathering candidates, by incrementally exchanging candidates over time instead of all at once. This method can considerably accelerate the process of establishing a communication session.

Acknowledgments TODO acknowledge.