]> Fastly

kazuhooku@gmail.com

Google

stefanoduo@google.com

Meta

jbeshay@meta.com

Meta

mjoras@meta.com

quic internet-draft This document specifies how a QUIC endpoint can delegate sending Stateless Resets to a component that outlives its connection state. It also defines a frame for clients using zero-length Connection IDs to advertise a Stateless Reset Token and a transport parameter for servers to indicate support for receiving the frame. 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 Stateless reset () allows an endpoint that has lost connection state to signal to its peer that a connection can no longer be continued. Nothing a Stateless Reset carries is protected by the connection's keys or tied to its packet number spaces: the signal is authenticated solely by the 128-bit Stateless Reset Token it ends with, which the receiver matches against the tokens it retains. QUIC uses that property to avoid retaining state. An endpoint associates a Stateless Reset Token with each Connection ID it issues, delivering the token to the peer either in the stateless_reset_token transport parameter or in a NEW_CONNECTION_ID frame. When such an endpoint later receives a packet that it cannot associate with any active connection, it recomputes the token from the Destination Connection ID carried in that packet -- typically by applying a static key to the Connection ID () -- and emits a Stateless Reset carrying that token. Because the token is derived from the Connection ID, the resetting endpoint need not retain any per-connection state. The same property permits a different arrangement, and it is the subject of this document: the entity that sends a Stateless Reset need not be the endpoint that ran the connection. The ability to send a Stateless Reset is valuable precisely when connection state has been lost involuntarily -- for example, when an application exits or is terminated by the operating system. After the application is gone, the peer may buffer data that will never be delivered and continue to send packets on the connection until its idle timeout expires. It can also delay fallback delivery, such as a push notification or a secondary connection. At scale, abandoned connections consume memory and connection-table capacity. To cover these scenarios, an endpoint can delegate the termination of the connection to a component that outlives its own connection state, and that component can reset the peer long after the endpoint is gone (). A mobile operating system can withdraw an application's network access before the application can send a CONNECTION_CLOSE frame. Once the connection has been abandoned, a delegate that retains network access can reset the peer (). Delegation is optional. A delegate, such as an operating system, system service, or application helper, needs to survive the loss of connection state and retain access to the connection's network path. If a reset cannot be delivered, the peer relies on the usual QUIC termination and timeout mechanisms. A CONNECTION_CLOSE packet could be recorded for a delegate to send, but such a packet is difficult to manage. It is protected under the connection's packet-protection keys that endpoints periodically rotate, and it carries a packet number that must fall within a dynamic range the peer will accept; thus, the recorded packet would need constant refreshing to remain usable. In contrast, a Stateless Reset does not depend on packet-protection keys or packet numbers. The delegate retains the token and the information needed to match and route packets (). A delegated Stateless Reset can also be better formed than one sent by an endpoint that has lost its state: the delegate can remember a Connection ID that the peer has issued and place it where a 1-RTT packet carries the Destination Connection ID, so that the Stateless Reset reaches the intended peer in a load-balanced deployment (). In , Stateless Reset Tokens are issued alongside Connection IDs. An endpoint that uses zero-length Connection IDs cannot issue one in a NEW_CONNECTION_ID frame (). Only a server can provide a token for its handshake Connection ID in the stateless_reset_token transport parameter; clients cannot because client transport parameters are not confidential. Zero-length Connection IDs are common for clients. A client that identifies connections solely by the 5-tuple has no need to issue Connection IDs and can reduce per-packet overhead by using zero-length Connection IDs. To allow such clients to issue Stateless Reset Tokens and delegate them, this document defines a frame for advertising a token and a transport parameter through which servers indicate support for receiving that frame (). Servers can advertise a token in the existing stateless_reset_token transport parameter; the new frame is limited to clients that use zero-length Connection IDs. The mechanisms in this document apply to QUIC versions 1 and 2 (), which use the same Stateless Reset format and short-header fields.

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.

Delegating a Stateless Reset An endpoint can delegate the sending of a Stateless Reset to a component that outlives its connection state. The delegate retains a registration containing:

• Information the endpoint uses to match incoming datagrams to the connection, such as endpoint-issued Connection IDs or addressing information ().
• A return path and a peer-issued Connection ID that the peer currently accepts ().
• A Stateless Reset Token that the endpoint has advertised, or will advertise, to the peer.

The delegate retains the token rather than recomputing it from a Connection ID. It needs no packet-protection keys or packet numbers. Both clients and servers can delegate resets, regardless of the length of their Connection IDs. Tokens are advertised in the server-only stateless_reset_token transport parameter or in NEW_CONNECTION_ID frames. A client using zero-length Connection IDs can advertise a token for the whole connection in RESET_TOKEN frames (). Registration can precede token advertisement, but the peer recognizes a reset only after learning the token and associating it with the reset's source address (). For tokens associated with Connection IDs, the peer also needs to have used and not retired the ID. A reset carrying any other token is indistinguishable from a packet that cannot be decrypted and is discarded. A delegate MAY track when the peer starts using a Connection ID, and send a Stateless Reset carrying its token only once that happens. The endpoint updates a registration when its matching information, peer-issued Connection ID, or path changes. A reset sent with stale routing information might be dropped. Tokens associated with endpoint-issued Connection IDs remain bound to those IDs when the path or peer-issued Connection ID changes. A token advertised using RESET_TOKEN remains fixed for the connection's lifetime (). A connection can have registrations for multiple paths. Closing a socket or losing a path does not authorize resetting a connection that remains active on another path (). A delegate MUST NOT use a canceled or expired registration to send resets. This document does not define an interface between an endpoint and a delegate. Except as described in and , the requirements of and governing the construction and sending of a Stateless Reset apply unchanged.

Delegating a Stateless Reset to the Operating System In some environments, the operating system sends a Stateless Reset on behalf of an application that has exited or has been terminated. The application and the operating system can divide the work as follows (). The operating system exposes an interface through which an application registers, for one of its connections, a Connection ID that the peer has issued and currently accepts, together with what identifies that connection in the datagrams the peer sends -- the socket, and the Connection ID that the application is issuing, if any. For a new connection or a new Connection ID issued by the application, the operating system generates a Stateless Reset Token, forms and retains a Stateless Reset datagram (), and returns the token to the application. The application makes the token known to its peer, either as the token associated with the issued Connection ID or, if it is a client that uses zero-length Connection IDs, in a RESET_TOKEN frame (). The application updates or cancels registrations as described in . Updating the registered path or peer-issued Connection ID can require rebuilding the retained datagram, but does not require generating a new token. Once the application has lost or abandoned the connection state, the operating system sends the retained datagram once (), and thereafter responds to datagrams matching that registration by sending it again, but does so only if the retained datagram is smaller than the one that triggered it, as required by . The operating system limits how long it retains the reset and registration after the application loses or abandons connection state. A retained registration applies only to the old connection. It MUST NOT prevent delivery to a new connection that reuses the socket or 5-tuple.

Delegating a Stateless Reset to the Operating System | | | | | (Peer CID, | | | | | Socket, etc.) | | | | | | (Generates Token | | | | | & Reset Packet) | | | |<--- Reset Token -----| | | | | | | | | |--------------- Advertise Token --------------->| | | | (RESET_TOKEN or NEW_CONNECTION_ID) | | | | | | | | [App Exits] |---- Proactive Reset --->| | | | (Usually sufficient) | | | | | | | +--------------------------------------+ | | | Optional (if more packets arrive): | | | | | | | | | | |<-- Incoming Datagram ---| | | | | | | | | | | |---- Stateless Reset --->| | | | | | (If smaller than Rx) | | | | | | | | | | +--------------------------------------+ | | | | | | | (Discards Reset | | | | & Registration) | | | | +-----------------------------------------------------------------+ ]]>

In this division of labor (), it is possible to deny an application the use of the Stateless Reset as a means of conveying information of its own. The Stateless Reset Token and the other bytes that the operating system generates are outside the application's control, and the peer's Connection ID, which the application supplies, is also the value that it places in the Destination Connection ID field of the packets it sends. An operating system can therefore monitor the packets that the application sends after the registration, and send the Stateless Reset only if those packets carried that Connection ID. The Stateless Reset then carries no Connection ID other than the one that the application's own packets were already carrying to the peer.

Division of labor between application and operating system

Constructing a Routable Stateless Reset When constructing a Stateless Reset, the endpoint or its delegate SHOULD place a Connection ID that the peer currently accepts in the position in which a 1-RTT packet carries the Destination Connection ID field. If the peer uses a zero-length Connection ID, the Destination Connection ID field is empty. calls for unpredictable bits, rather than the Destination Connection ID, because an endpoint that has lost its state cannot recover a Connection ID that its peer accepts, observing that the resulting packet "could be incorrectly routed" where the Connection ID is critical for routing toward the peer, as in load-balanced deployments. Because a delegate retains state, it can send a Stateless Reset that reaches the peer and is less distinguishable from a valid packet. To maintain indistinguishability from a valid 1-RTT packet, the endpoint or delegate MUST include at least 4 unpredictable bytes following the Destination Connection ID. Doing so satisfies both the 21-byte minimum size requirement of , when zero-length Connection IDs are used, and provides the 4-byte offset required by .

Routable Stateless Reset Format

Sending a Stateless Reset Proactively An endpoint that retains the state necessary to send a CONNECTION_CLOSE frame MUST use CONNECTION_CLOSE instead of a Stateless Reset, as required by . Once the endpoint that delegated the Stateless Reset has lost or abandoned its connection state, a delegate MAY send a single Stateless Reset proactively, without waiting to receive a datagram from the peer. describes a Stateless Reset only as a response to a received packet because an endpoint that has lost its state learns of the connection's existence only from one; an endpoint or delegate that retains the token knows which connections it may need to reset before any packet arrives. A delegate MUST NOT send a Stateless Reset unless the endpoint has lost or abandoned its connection state. Loss of one path or temporary suspension of the application does not by itself imply abandonment. Once delegated teardown begins, the application MUST NOT resume that connection.

Advertising a Token with Zero-Length Connection IDs The RESET_TOKEN frame lets a client using zero-length Connection IDs advertise a Stateless Reset Token. Servers indicate support with the reset_token transport parameter. The token is bound to the connection and can be delegated as described in .

The reset_token Transport Parameter A server that is willing to accept RESET_TOKEN frames () from its client advertises the reset_token transport parameter (0x-TBD). The reset_token transport parameter has a zero-length value; its presence alone conveys that willingness. A client MUST NOT send this transport parameter. Receipt of this parameter from a client, or receipt of a non-zero value, MUST be treated as a connection error of type TRANSPORT_PARAMETER_ERROR.

The RESET_TOKEN Frame The RESET_TOKEN frame (type 0x-TBD) carries a Stateless Reset Token that a client associates with the connection rather than with any Connection ID.

RESET_TOKEN Frame Format

The frame contains the following field:

Stateless Reset Token:

A 128-bit value that the sender will use to construct a Stateless Reset () for this connection. The token MUST be generated so that it is hard to guess, as required by .

RESET_TOKEN frames are ack-eliciting; a sender that detects the loss of a RESET_TOKEN frame retransmits the token it carried. A RESET_TOKEN frame MUST only be sent in a 1-RTT packet. A client MUST NOT send a RESET_TOKEN frame unless the server advertised the reset_token transport parameter. Only a client that uses a zero-length Connection ID may send a RESET_TOKEN frame; the mechanism substitutes for the tokens that a Connection ID-issuing client sends in NEW_CONNECTION_ID frames. A client that uses a non-zero-length Connection ID MUST NOT send a RESET_TOKEN frame. A server that receives a RESET_TOKEN frame from such a client MUST treat this as a connection error of type PROTOCOL_VIOLATION. An endpoint that has not advertised the reset_token transport parameter treats a received RESET_TOKEN frame as a frame of unknown type, which is a connection error of type FRAME_ENCODING_ERROR (). A server MUST NOT send a RESET_TOKEN frame. Because a client cannot advertise the transport parameter, it treats a RESET_TOKEN frame from a server as a frame of unknown type. A server that receives a RESET_TOKEN frame recognizes the contained value as a Stateless Reset Token for this connection and thereafter processes it exactly as a token received in a NEW_CONNECTION_ID frame, following the requirements of for retaining the token and for detecting a Stateless Reset that carries it, except that this token is immediately usable and is not subject to the rule that excludes tokens for unused Connection IDs. A client uses a single Stateless Reset Token for the lifetime of a connection. It MAY send more than one RESET_TOKEN frame -- for example, to retransmit a frame that was lost -- but every RESET_TOKEN frame it sends on a connection MUST carry the same token value. A server that receives a RESET_TOKEN frame carrying a token value different from one it received earlier on the same connection MUST treat this as a connection error of type PROTOCOL_VIOLATION. Receipt of the same value more than once is idempotent. The token MUST NOT be used for another connection or for a Connection ID.

Security Considerations Knowledge of a Stateless Reset Token allows an entity to terminate the connection. A token MUST be difficult to guess and MUST NOT be reused. A sender can generate a token using a cryptographically secure random number generator. Giving a delegate access to the token creates another opportunity for disclosure, even if it can already terminate the connection. The endpoint needs to consider this exposure when selecting a delegate. The token and routing information MUST have confidentiality and integrity in transit and at rest. The delegate MUST restrict registration creation, update, cancellation, and access to the endpoint and entities authorized to act for it. Removing a registration does not revoke a token retained by the delegate. A token associated with a Connection ID is invalidated when the peer retires that ID (). A token advertised using RESET_TOKEN remains valid for the connection's lifetime (). A delegate can retain multiple registrations for a connection, such as one for each path. Implementations SHOULD limit the number of registrations to avoid resource exhaustion. A RESET_TOKEN frame is protected by 1-RTT packet protection. A Stateless Reset reveals its token to an on-path observer. This does not create a new termination capability because the peer enters the draining state after accepting the reset. The token cannot be used for another connection. A delegate sends using the source and destination addresses of a path on which the endpoint recently received packets from the peer. This allows the peer to apply the remote-address check in .

IANA Considerations TBD

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. This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC. Note that "version 2" is an informal name for this proposal that indicates it is the second version of QUIC to be published as a Standards Track document. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risks. 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 how Transport Layer Security (TLS) is used to secure QUIC.

Acknowledgments TODO acknowledge.