]> n0 Inc.

flub@n0.computer

Transport QUIC QUIC NAT Traversal hole punching A description of how noq performs NAT traversal for iroh, including all current bugs. This is not yet a specification, though further revisions migth be.

Introduction This document describes how noq currently performs NAT traversal using a QUIC extension. It is based on , but with heavy modifications. This is not expected to be the final shape of the protocol, and does not aim to be a specification. The NAT traversal described here functions as a QUIC extension which needs to be negotiated in the transport parameters. Once negotiated the server can share NAT traversal address candidates using ADD_ADDRESS frames. NAT traversal is initiated by the client using REACH_OUT frames, and performed using PATH_CHALLEGE and PATH_RESPONSE frames in probing packets to achieve NAT traversal. The current implementation is combined with for gathering address candidates and for opening multiple paths concurrently, however these mechanisms are somewhat orthogonal and not not require tight integration.

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.

NAT Traversal

Establishing a connection Both endpoints are expected to be able to establish a QUIC connection already. This is done via a "relay" path, the transport of this is out of scope. However in iroh this looks like a normal IP path that uses IPv6 Unique Local Addresses as far as the QUIC stack is concerned. Once the connection is established with the extension negotiated the endpoints can perform NAT traversal.

Gathering address candidates Both endpoints need to gather address candidates to participate in the holepunching from the same UDP socket that takes part in the holepunching. This is done using using a sparate connection to a cooperating server. The discovered addresses are propagated up to the application, which has full control over which ones it decides to use for NAT traversal by passing any desired address candidates into the QUIC stack as NAT traversal address candidates.

Negotiating Extension use Endpoints advertise their support of the extension by sending the max_remote_nat_traversal_addresses (0x3d7f91120401) set to a non-zero variable-length integer. The value advertised by the server is not used by the client. It is only used by the server itself to limit the number of address candidates the application is allowed to use. The value sent by the client limits the number of address candidates the server can advertise to the client at any given time.

Exchanging address candidates The server advertises address candidates using ADD_ADDRESS frames. Any address candidates advertised by the server that exceed the allowed number the client advertised in the transport parameter, are ignored by the client. Each ADD_ADDRESS frame uses a unique and monotonically incrementing sequence ID. If the server wants to remove an address candidate from the set of address candidates the client can use, it uses the REMOVE_ADDRESS frame using a sequence ID of a previously sent ADD_ADDRESS frame. The client ignores an unknown sequence ID in any REMOVE_ADDRESS frames. If the server receives an ADD_ADDRESS or REMOVE_ADDRESS frame it closes the connection with the PROTOCOL_VIOLATION transport error.

Initiating NAT traversal The client initiates NAT traversal by sending one or more REACH_OUT frames, each containing one of the client's address candidates. At the same time the client sends out probes to all the address candidates the server advertised. Upon receipt of a REACH_OUT frame the server also sends out a probe to the client's address candidate advertised in the frame. NAT traversal happens in rounds, each round has a sequence ID. The receipt of a higher sequence ID than the current round implies the termination of the previous round. This means that any probes which have not yet had a response will no longer be retried. If the server sends a REACH_OUT frame the client closes the connection with the PROTOCOL_VIOLATION transport error.

NAT probes NAT probes are valid QUIC packets containing a PATH_CHALLENGE frame, sent off-path to the address candidate provided by the remote endpoint. They are treated as in , except they are not padded to 1200 bytes. As a result any valid PATH_RESPONSE received for such a challenge does not validate the path. Such NAT probes are treated as probing frames as defined in . Since this extension is used together with this re-introduces the concept of probing frames even when is negotiated. Currently these NAT probes are sent using the active CID of the PathId they are sent on, in clear violation of . Since PATH_CHALLENGE frames are not retransmittable the sending endpoint has to re-send NAT probes if it does not receive a timely response. For this the normal PTO duration calculation is used, using the initial RTT for new paths and using no ack-delay since PATH_RESPONSES must be sent immediately. The exponent of the exponential backoff is the retry count of the probe. Finally NAT probes are abandoned once a new round is started, or a fixed timeout of 30s elapsed. Once a successful response is received from a remote address probing of that remote address stops, even if there are still other un-responded challenges to the same remote address. In combination with an acknowledgement for the NAT probe migth be received over another path, even if no matching PATH_RESPONSE is received. These acknowledgements do not influence the sending of new challenges when no timely response is received.

Probe responses Upon receiving an off-path probing packet containing a PATH_CHALLENGE, the receiving endpoint handles this as any other path validation or liveness probe response as specified in . Since the receiving endpoint does not know the reason for this path challenge it always expands the packet to the 1200 byte limit required for path validation. When the client receives an off-path PATH_CHALLENGE it always includes a new PATH_CHALLENGE together with the PATH_RESPONSE it must send, turning the response into a new NAT probe. This has two benefits:

• It speeds up opening of new paths, since as per only the client can open a new path a successful NAT traversal can only be acted upon by the client. Sending a new challenge before the next challenge retry would occur is faster.
• It enables NAT traversal even for challenges received from addresses not advertised as address candidates by the server. This can occur when the server is behind an Endpoint Dependent Mapping NAT, while the client is behind an Endpoint Independent Mapping NAT.

Successful NAT traversal Once the client receives a PATH_RESPONSE for a NAT probe it sent, NAT traversal is successful. The client now opens a new path using over the path. It does however stil have to validate the path before it can use it, since only the address is validated as part of the NAT traversal.

Frames Receipt of any frame while the extension is not negotiated results in closing the connection with a PROTOCOL_VIOLATION transport error.

ADD_ADDRESS As per , but with different codepoints: The ADD_ADDRESS frame contains the following fields:

Sequence Number:

A variable-length integer encoding the sequence number of this address advertisement.

IPv4:

The IPv4 address. Only present if the least significant bit of the frame type is 0.

IPv6:

The IPv6 address. Only present if the least significant bit of the frame type is 1.

Port:

The port number.

ADD_ADDRESS frames are ack-eliciting. When lost, they SHOULD be retransmitted, unless the address is not active anymore. This frame is only sent from the server to the client. Servers MUST treat receipt of an ADD_ADDRESS frame as a connection error of type PROTOCOL_VIOLATION.

REMOVE_ADDRESS As per , but with different codepoints: The REMOVE_ADDRESS frame contains the following fields:

Sequence Number:

A variable-length integer encoding the sequence number of the address advertisement to be removed.

REMOVE_ADDRESS frames are ack-eliciting. When lost, they SHOULD be retransmitted. This frame is only sent from the server to the client. Servers MUST treat receipt of an REMOVE_ADDRESS frame as a connection error of type PROTOCOL_VIOLATION.

REACH_OUT The REACH_OUT frame contains the following fields:

Round:

The sequence number of the NAT Traversal attempt.

IPv4:

The IPv4 address. Only present if the least significant bit of the frame type is 0.

IPv6:

The IPv6 address. Only present if the least significant bit of the frame type is 1.

Port:

The port number.

REACH_OUT frames are ack-eliciting. This frame is only sent from the client to the server. Clients MUST treat receipt of a REACH_OUT frame as a connection error of type PROTOCOL_VIOLATION.

Security Considerations TODO Security

• Both client and server send data to un-validated addresses provided by the peer, this should be subject to ani-amplification limits.

IANA Considerations TODO codepoints need registering

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. Apple Inc. 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, enabling ICE to be used with QUIC. Furthermore, QUIC’s path validation mechanism can be used to test the viability of an address candidate pair while at the same time creating the NAT bindings required for a direction connection, after which QUIC connection migration can be used to migrate the connection to a direct path. Private Octopus Inc. Unless they have out-of-band knowledge, QUIC endpoints have no information about their network situation. They neither know their external IP address and port, nor do they know if they are directly connected to the internet or if they are behind a NAT. This QUIC extension allows nodes to determine their public IP address and port for any QUIC path. 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.