| Internet-Draft | QUIC Address Discovery | October 2023 |
| Seemann | Expires 21 April 2024 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://marten-seemann.github.io/draft-seemann-quic-address-discovery/draft-seemann-quic-address-discovery.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-seemann-quic-address-discovery/.¶
Discussion of this document takes place on the QUIC Working Group mailing list (mailto:quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Subscribe at https://www.ietf.org/mailman/listinfo/quic/.¶
Source for this draft and an issue tracker can be found at https://github.com/marten-seemann/draft-seemann-quic-address-discovery.¶
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 21 April 2024.¶
Copyright (c) 2023 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.¶
STUN ([RFC8489]) allows nodes to discover their reflexive transport address by asking a remote server to report the observed source address. While the QUIC ([RFC9000]) packet header was designed to allow demultiplexing from STUN packets, moving address discovery into the QUIC layer has a number of advantages:¶
STUN traffic is unencrypted, and can be observed and modified by on-path observers. By moving address discovery into QUIC's encrypted envelope it becomes invisible to observers.¶
When located behind a load balancer, QUIC packets may be routed based on the QUIC connection ID. Depending on the architecture, not using STUN might simplify the routing logic.¶
If QUIC traffic doesn't need to be demultiplexed from STUN traffic, implementations can enable QUIC bit greasing ([RFC9287]).¶
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.¶
Endpoints advertise their support of the extension by sending the address_discovery (0x9f81a173) transport parameter (Section 7.4 of [RFC9000]) with an empty value. Implementations that understand this transport parameter MUST treat the receipt of a non-empty value as a connection error of type TRANSPORT_PARAMETER_ERROR.¶
When using 0-RTT, both endpoints MUST remember the value of this transport parameter. This allows sending the frames defined by this extension in 0-RTT packets. If 0-RTT data is accepted by the server, the server MUST NOT disable this extension on the resumed connection.¶
This extension defines three frames. These frames MUST only appear in the application data packet number space. These frames are "probing frames" as defined in Section 9.1 of [RFC9000].¶
REQUEST_ADDRESS Frame {
Type (i) = 0x9f81a0,
Sequence Number (i),
}
¶
The REQUEST_ADDRESS frame contains the following fields:¶
The sequence number of the request.¶
REQUEST_ADDRESS frames are ack-eliciting. If lost, it's the sender's decision if it wants to retransmit the frame. A sender MAY send a new REQUEST_ADDRESS frame with an incremented sequence number instead.¶
REQUEST_DECLINED Frame {
Type (i) = 0x9f81a1,
Sequence Number (i),
}
¶
The REQUEST_DECLINED frame contains the following fields:¶
The sequence number of the request that is being declined.¶
REQUEST_DECLINED frames are ack-eliciting, and SHOULD be retransmitted if lost.¶
OBSERVED_ADDRESS Frame {
Type (i) = 0x9f81a2..0x9f81a3,
Sequence Number (i),
[ IPv4 (32) ],
[ IPv6 (128) ],
Port (16),
}
¶
The OBSERVED_ADDRESS frame contains the following fields:¶
The sequence number of the request for which this response is intended.¶
The IPv4 address. Only present if the least significant bit of the frame type is 0.¶
The IPv6 address. Only present if the least significant bit of the frame type is 1.¶
The port number, in network byte order.¶
OBSERVED_ADDRESS frames are ack-eliciting, and SHOULD be retransmitted if lost.¶
An endpoint that wishes to determine the remote address of a path sends a REQUEST_ADDRESS frame on that path. The sequence number starts at 0 and is incremented for any subsequent request. Since the REQUEST_ADDRESS frame is a probing frame, the endpoint MAY bundle it with other probing frames during path validation (Section 8.2 of [RFC9000]).¶
The receiver of the REQUEST_ADDRESS frame SHOULD report the observed address using an OBSERVED_ADDRESS frame. The OBSERVED_ADDRESS frame does not need to be sent on the same path, since the requester can associate the response with the corresponding request using the sequence number.¶
The receiver of a REQUEST_ADDRESS frame MAY decline to report the observed address by sending a REQUEST_DECLINED frame. The REQUEST_DECLINED frame also contains a sequence number, and therefore may be sent on any path.¶
The sender MAY send a REQUEST_ADDRESS frame for the same path after a some time has elapsed. This allows it to detect when a NAT rebinding has happened. To speed up the discovery, it MAY also send another REQUEST_ADDRESS frame when the peer changes the connection ID used on the path.¶
When receiving an OBSERVED_ADDRESS or a REQUEST_DECLINED frame with a sequence number value that was not previously sent in a REQUEST_ADDRESS frame, the receiver MUST close the connection with a PROTOCOL_VIOLATION error code if it can detect this condition.¶
In general, nodes cannot be trusted to report the correct address in OBSERVED_ADDRESS frames. If possible, endpoints might decide to only use this extension when connecting to trusted peers, or if that is not possible, define some validation logic (e.g. by asking multiple untrusted peers and observing if the responses are consistent). This logic is out of scope for this document.¶
Depending on the routing setup, a node might not be able to observe the peer's reflexive transport address, and attempts to do so might reveal details about the internal network. In these cases, the node SHOULD NOT enable support the extension, or decline reporting the address using REQUEST_DECLINED frames.¶
TODO: fill out registration request for the transport parameter and frame types¶
TODO acknowledge.¶