QUIC M. Seemann Internet-Draft Intended status: Standards Track E. Kinnear Expires: 11 April 2027 Apple Inc. 8 October 2026 Using QUIC to traverse NATs draft-seemann-quic-nat-traversal-03 Abstract 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 This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/marten-seemann/draft-seemann-quic-nat-traversal. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 11 April 2027. Seemann & Kinnear Expires 11 April 2027 [Page 1] Internet-Draft QUIC NAT Traversal October 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Background: NAT Traversal with ICE . . . . . . . . . . . . . 3 4. NAT Traversal Extension Overview . . . . . . . . . . . . . . 4 5. Candidate Discovery and Exchange . . . . . . . . . . . . . . 4 5.1. Gathering Address Candidates . . . . . . . . . . . . . . 4 5.2. Advertising Server Address Candidates . . . . . . . . . . 4 5.3. Forming Candidate Pairs . . . . . . . . . . . . . . . . . 5 6. Coordinated Path Probing . . . . . . . . . . . . . . . . . . 5 6.1. Grant Limits . . . . . . . . . . . . . . . . . . . . . . 6 6.2. Punching Connection IDs . . . . . . . . . . . . . . . . . 6 6.2.1. Use with Multipath . . . . . . . . . . . . . . . . . 7 6.3. Probes Received on a Different Base . . . . . . . . . . . 7 6.4. Amplification Attack Mitigation . . . . . . . . . . . . . 7 7. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 7 8. Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. PUNCH_GRANT Frame . . . . . . . . . . . . . . . . . . . . 8 8.2. MAX_PUNCH_GRANTS Frame . . . . . . . . . . . . . . . . . 8 8.3. PUNCH_REQUEST Frame . . . . . . . . . . . . . . . . . . . 9 8.4. PUNCH_DONE Frame . . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Seemann & Kinnear Expires 11 April 2027 [Page 2] Internet-Draft QUIC NAT Traversal October 2026 1. Introduction This document specifies an extension to QUIC ([RFC9000]) 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; [RFC8445]), but does not use the ICE protocol. 2. 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 [RFC2119] [RFC8174] 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. 3. 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 [RFC9287]. Seemann & Kinnear Expires 11 April 2027 [Page 3] Internet-Draft QUIC NAT Traversal October 2026 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. 4. NAT Traversal Extension Overview QUIC's path validation mechanism can be used to establish the required NAT mappings that allow for a direct connection. Once the NAT mappings are established, QUIC's connection migration can be used to migrate the connection to a direct path. During the path validation phase, multiple different paths might be established in parallel. When using QUIC Multipath [MULTIPATH], these paths may be used at the same time; however, the mechanism described in this document does not require the use of QUIC multipath. Although ICE is not directly used, the logic run on the client makes use of ICE's candidate pairing logic (see especially Section 6.1.2.2 of [RFC8445]). Implementations are free to implement different algorithms as they see fit. This mode needs to be negotiated during the handshake; see Section 7. 5. Candidate Discovery and Exchange 5.1. Gathering Address Candidates The gathering of address candidates is out of scope for this document. Endpoints MAY use the logic described in Sections 5.1.1 and 5.2 of [RFC8445], or they MAY use address candidates provided by the application. 5.2. Advertising Server Address Candidates The server advertises its address candidates using ALTERNATIVE_ADDRESS frames, as defined in [ALTERNATIVE-ADDRESS]. 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 ([RFC8838]). 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. Seemann & Kinnear Expires 11 April 2027 [Page 4] Internet-Draft QUIC NAT Traversal October 2026 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. Since address matching is run on the client side, only the server advertises address candidates. The client communicates selected address pairs to the server using PUNCH_REQUEST frames. 5.3. Forming Candidate Pairs The client matches the address candidates sent by the server with its own address candidates, forming candidate pairs. Section 5.1 of [RFC8445] describes an algorithm for pairing address candidates. Since the pairing algorithm is only run on the client side, the endpoints do not need to agree on the algorithm used, and 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. 6. Coordinated Path Probing The server authorizes attempts using PUNCH_GRANT (Section 8.1). 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 Section 8.2 of [RFC9000], with additional rate limits (Section 6.4). Each endpoint MUST set its own timeout following Section 8.2.4 of [RFC9000]. 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. Seemann & Kinnear Expires 11 April 2027 [Page 5] Internet-Draft QUIC NAT Traversal October 2026 Each endpoint MUST report success or timeout using PUNCH_DONE (Section 8.4); 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. 6.1. Grant Limits The client's nat_traversal transport parameter (Section 7) sets the initial cumulative grant limit. MAX_PUNCH_GRANTS (Section 8.2) 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. 6.2. 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 Section 5.1 of [RFC9000]. Each endpoint issues two punching connection IDs per grant, using PUNCH_GRANT or 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 (Section 6.3). The NEW_CONNECTION_ID and RETIRE_CONNECTION_ID mechanisms of [RFC9000] 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. Seemann & Kinnear Expires 11 April 2027 [Page 6] Internet-Draft QUIC NAT Traversal October 2026 An endpoint retires a grant's punching connection IDs after both sending and receiving PUNCH_DONE (Section 8.4) for that attempt. 6.2.1. Use with Multipath When QUIC multipath [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. 6.3. 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 (Appendix B.2 of [RFC8445]). Both endpoints follow the path validation rules of [RFC9000] 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. 6.4. Amplification Attack Mitigation TODO describe exactly how to mitigate amplification attacks 7. Extension Negotiation Endpoints advertise their support of the extension by sending the nat_traversal (0x3d7e9f0bca12fea6) transport parameter (Section 7.4 of [RFC9000]). The client's value is a single variable-length integer specifying the initial cumulative grant limit (Section 6.1). 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. Seemann & Kinnear Expires 11 April 2027 [Page 7] Internet-Draft QUIC NAT Traversal October 2026 The client MUST also send the alternative_address transport parameter defined in [ALTERNATIVE-ADDRESS]. 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. 8. Frames This extension defines the PUNCH_GRANT, MAX_PUNCH_GRANTS, PUNCH_REQUEST, and PUNCH_DONE frames. 8.1. PUNCH_GRANT Frame PUNCH_GRANT Frame { Type (i) = 0x3d7e96, Grant ID (i), Connection ID 1 Length (8), Connection ID 1 (8..160), Connection ID 2 Length (8), Connection ID 2 (8..160), } PUNCH_GRANT authorizes one attempt and supplies the two server-issued punching connection IDs (Section 6.2). The server MUST number new grants consecutively from 0 within each connection, subject to the client's grant limit (Section 6.1). 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. 8.2. MAX_PUNCH_GRANTS Frame MAX_PUNCH_GRANTS Frame { Type (i) = 0x3d7e97, Maximum Grants (i), } Seemann & Kinnear Expires 11 April 2027 [Page 8] Internet-Draft QUIC NAT Traversal October 2026 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. 8.3. PUNCH_REQUEST Frame PUNCH_REQUEST Frame { Type (i) = 0x3d7e92, Grant ID (i), Connection ID Length (8), Connection ID (8..160), Client Address Type (8), Client IP Address (32..128), Client Port (16), Advertisement Sequence Number (i), Entry Index (i), } The PUNCH_REQUEST frame contains the following fields: Grant ID: The grant used for this attempt (Section 8.1). Connection ID Length and Connection ID: The length in bytes and value of a client-issued punching connection ID (Section 6.2). 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 [ALTERNATIVE-ADDRESS]. 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. Seemann & Kinnear Expires 11 April 2027 [Page 9] Internet-Draft QUIC NAT Traversal October 2026 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 (Section 9.1 of [RFC9000]) 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. 8.4. PUNCH_DONE Frame Seemann & Kinnear Expires 11 April 2027 [Page 10] Internet-Draft QUIC NAT Traversal October 2026 PUNCH_DONE Frame { Type (i) = 0x3d7e95, Grant ID (i), Status (i), } 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. Seemann & Kinnear Expires 11 April 2027 [Page 11] Internet-Draft QUIC NAT Traversal October 2026 9. 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 Section 8.1 of [RFC9000]) 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. 10. IANA Considerations TODO: fill out registration request for the transport parameter and frame types 11. References 11.1. Normative References [ALTERNATIVE-ADDRESS] Munizaga, M. and M. Seemann, "QUIC Alternative Server Address Frames", Work in Progress, Internet-Draft, draft- munizaga-quic-alternative-server-address-02, 25 September 2026, . [MULTIPATH] Liu, Y., Ma, Y., De Coninck, Q., Bonaventure, O., Huitema, C., and M. Kühlewind, "Managing multiple paths for a QUIC connection", Work in Progress, Internet-Draft, draft-ietf- quic-multipath-21, 17 March 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Seemann & Kinnear Expires 11 April 2027 [Page 12] Internet-Draft QUIC NAT Traversal October 2026 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9287] Thomson, M., "Greasing the QUIC Bit", RFC 9287, DOI 10.17487/RFC9287, August 2022, . 11.2. Informative References [RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", RFC 8838, DOI 10.17487/RFC8838, January 2021, . Acknowledgments TODO acknowledge. Authors' Addresses Marten Seemann Email: martenseemann@gmail.com Eric Kinnear Apple Inc. One Apple Park Way Cupertino, California 95014, United States of America Email: ekinnear@apple.com Seemann & Kinnear Expires 11 April 2027 [Page 13]