]> Protocol Labs

martenseemann@gmail.com

Transport QUIC QUIC ICE NAT traversal hole punching QUIC () is well-suited to various NAT traversal techniques. As it operates over UDP, and because the QUIC header was designed to be demultipexed from other protocols, STUN () can be used on the same UDP socket. This allows for using ICE () with QUIC. Furthermore, QUIC’s path validation mechanism can be used to test the viability of an address candidate pair, allowing the immediate use of a new path. 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 defines three distinct modes for traversing NATs using QUIC:

1. Using ICE with an external signaling channel to select a pair of UDP addresses. Once candidate nomination is completed, a new QUIC connection between the two endpoints can be established.
2. Using a (proxied) QUIC connection as the signaling channel for ICE. Once ICE has nominated a candidate pair (i.e., selected a usable path), the proxied connection is migrated using QUIC's connection migration.
3. Using a (proxied) QUIC connection as the signaling channel for ICE. Instead of using ICE's connectivity checks, QUIC's path validation logic is used to determine possible paths.

The first mode doesn't require any changes to existing QUIC and ICE stacks. The only requirement is the ability to send non-QUIC (STUN) packets on the UDP socket that a QUIC server is listening on. However, it necessitates running a separate signaling channel for the communication between the two ICE agents. The second mode requires a minor modification of the QUIC stacks involved, as they now need to be capable of exchanging ICE messages on top of the proxied QUIC connection. This is achieved by defining an ICE frame to carry these messages. This mode makes it possible to start exchanging application data (via QUIC streams) on the proxied connection. The migration event is transparent to the application. The third mode necessitates changes to both the QUIC and ICE stacks. The ICE delegates responsibility for performing connectivity checks to the QUIC stack. The QUIC stack utilizes QUIC's path validation logic to perform the connectivity check. In addition to the path validation mechanism described in , the QUIC server needs the capability to initiate path validation, which, as per , is solely executed by the client. Compared to the second mode, this mode elimitates the need to effectively probe a path twice (once at the ICE and once at the QUIC layer), leading to a faster connection migration.

Modes

Using an External Signaling Channel 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, particularly, it does not necessitate the negotiation of the ICE extension defined in this document. 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.

Using a QUIC Connection as a Signaling Channel, using ICE for Connectivity Checks A (proxied) QUIC connection (e.g. using CONNECT-UDP ()) can be used as the signaling channel required by the ICE protocol (see section 1 of ). ICE messages are sent on this QUIC connection using the ICE frame defined in this document. This mode requires the ICE extension defined in this document to be negotiated (). Implementions MAY use Trickle ICE () to speed up the exchange of address candidates. Once ICE has successfully nominated a candidate pair, this path can be used as a direct connection between the two endpoints. The client SHOULD initiate a QUIC connection migration (section 9 of ) in a timely manner. The ICE connectivity check should have created all the NAT bindings needed for the QUIC path validation to complete successfully, however, these NAT bindings are usually only valid for a limited amount of time.

Using a QUIC Connection as a Signaling Channel, using QUIC for Connectivity Checks Similar to mode 2, in this mode a (proxied) QUIC connection is used as the ICE signaling channel. Instead of performing the connectivy checks (section 7 of ) themselves, the ICE stacks delegates them to the QUIC stack. The QUIC client MUST ensure that it ends up as the controlling agent (see section 2.3 of ). This can be achieved by sending the maximum allowed value for the tiebreaker value (see section 7.3.1. of ). When the ICE stack requests to perform a connectivity check for an address candidate pair, each QUIC endpoint probes the path by sending a probing packet containing a PATH_CHALLENGE frames, as described in section 8.2 of . Note that this differs slightly from , where only the client sends a probing packet. To create the required NAT bindings, it's necessary for both endpoints to send packets. Upon the completion of path validation, the QUIC stack passes the result (successful or failed) back to the ICE stack. The ICE stack then nominates an address pair. The client SHOULD then migrate the QUIC connection to this path in a timely manner.

Negotiating Extension Use Endpoints advertise their support of the extension needed for mode 2 and 3 by sending the ice (0x3d7e9f0bca12fea6) transport parameter (section 7.4 of ) with an empty value. An implementation that understands this transport parameter MUST treat the receipt of a non-empty value as a connection error of type TRANSPORT_PARAMETER_ERROR. In order to the use of this extension in 0-RTT packets, the client MUST remember the value of this transport parameter. If 0-RTT data is accepted by the server, the server MUST not disable this extension on the resumed connection.

ICE Frame The ICE frame contains the following fields: Length: A variable-length integer encoding the length of the following Data field. Data: The ICE message. If the Length is larger than the remaining payload of the QUIC packet, the receiver MUST close the connection with a connection error of type FRAME_ENCODING_ERROR. ICE frames are ack-eliciting. When lost, they MUST NOT be retransmitted, as the ICE layer is handling retransmission of messages.

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.

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

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. Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution. This document obsoletes RFC 3489. [STANDARDS-TRACK] 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. This document describes how to proxy UDP in HTTP, similar to how the HTTP CONNECT method allows proxying TCP in HTTP. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel for UDP communications through an HTTP server that acts as a proxy. 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. 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.