QUIC Over Reliable Transport

QUIC Over Reliable Transport Unaffiliated

Ottawa Canada billgage.ietf@gmail.com

Internet QUIC Working Group Internet-Draft This document defines QUIC operations when using an underlying reliable transport that, in contrast to UDP, can provide lossless in-order delivery of QUIC packets. The reliable transport may, for example, be TCP or SCTP or a reliable link such as that provided by the 5G radio link protocol.

Introduction The initial design for QUIC, as defined in , provides for the carriage of QUIC packets over UDP. Since UDP is an unreliable transport, includes mechanisms for recovering lost packets and for ensuring in-order delivery of byte streams to upper-layer applications. And since UDP is a raw datagram transport, also includes mechanisms for congestion control, flow control, integrity protection and privacy protection. In some deployments, an upper-layer application may wish to exploit QUIC capabilities such as light-weight stream management or connection migration in an environment that includes a reliable underlying transport. When QUIC packets are conveyed over a reliable transport such as or or over a reliable link such as that provided by the 5G radio link protocol , some aspects of may be redundant or undesirable due to added overhead, to added latencies or to negative interactions with mechanisms of the underlying reliable transport. This document defines QUIC over a reliable transport (QORT), a set of procedures for conveying QUIC packets over a reliable transport where one or more of the reliability and protection mechanisms of are replaced by those of the reliable transport.

Conventions 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.

Terminology This document uses the following terminology:

QUIC:: the protocol defined by the streams, connections, packets and frames specified in . Within the context of this document, the term "QUIC" does not include the cryptographic protection described in nor the loss detection and congestion control procedures of .
QORT:: QUIC over a reliable transport (as defined in this document).
RPT:: reliable and protected transport offering both cryptographic protection and error-free, in-order application data delivery (e.g. TLS/TCP, TLS/SCTP).
RT:: reliable transport offering error-free, in-order application data delivery but not offering cryptographic protection (e.g. SCTP).
session:: a collection of QUIC connections and paths used to exchange QUIC packets between two endpoints.

Notation This document uses the field notation defined in and quoted below:

Individual fields use the following notational conventions, with all lengths in bits: x (A): Indicates that x is A bits long x (i): Indicates that x holds an integer value using the variable length encoding described in x (A..B): Indicates that x can be any length from A to B; A can be omitted to indicate a minimum of zero bits, and B can be omitted to indicate no set upper limit; values in this format always end on a byte boundary x (L) = C: Indicates that x has a fixed value of C; the length of x is described by L, which can use any of the length forms above x (L) = C..D: Indicates that x has a value in the range from C to D, inclusive, with the length described by L, as above x (L)...: Indicates that x is repeated zero or more times and that each instance has a length of L

Overview The differences between the protocol stack of QORT and the protocol stack of are illustrated in :

RFC9000 and QORT Protocol Stacks uses UDP/IP to convey QUIC packets between the endpoints of a QUIC session while QORT is designed to use a reliable transport between the endpoints. The reliable transport may include IP and may even include UDP (or it may not) so long as the requirements of are met. Depending on the characteristics of the reliable transport, one of two modes of QORT may be used by the upper-layer application:

CRYPTO-QORT includes the cryptographic mechanisms described in and is designed to operate over a reliable transport that does not provide integrity and privacy protection (i.e. an RT). For example, this mode may be used when operating QORT over SCTP .
BASIC-QORT is designed to operate over a reliable transport that also provides integrity and privacy protection (i.e. an RPT). For example, this mode may be used when operating QORT over TLS (over TCP or SCTP) or over a 5G radio link .

The mode selected by the client is indicated by the Version field in the long packet header of the QUIC INITIAL packet sent from the client to a server. Different QORT modes are distinguished by different version values (). If CRYPTO-QORT mode is selected by the client, the QUIC INITIAL packet transmitted by an endpoint includes a QUIC CRYPTO frame for the initial cryptographic handshake and the transport parameters selected by the endpoint (). If BASIC-QORT mode is selected by the client, the QUIC INITIAL packet transmitted by an endpoint includes a new QORT_CONFIGURATION frame that contains the transport parameters selected by the endpoint (). Once the initial handshake has been completed, the client and server may exchange QUIC packets containing any of the QUIC frames that are not subject to restrictions imposed by the selected QORT mode ().

Reliable Transport Services QORT replaces the UDP/IP transport of with a reliable transport that ensures the in-order exchange of error-free messages and may provide cryptographic protection.

Delimiting Messages Some reliable transports provide message delimitation (aka. "framing"), allowing a sequence of bytes conveyed by the reliable transport to be identified and treated as a self-contained message. For example, in message delimitation is provided by the SCTP packet protocol and in message delimitation is provided by the packet data convergence protocol (PDCP). When message delimitation is provided by the reliable transport, each transmitted QUIC packet MUST be treated as a separate message. Some reliable transports (e.g. TCP) only convey byte streams and do not (natively) provide message delimitation. When message delimitation is not provided by the reliable transport, each transmitted QUIC packet MUST be terminated by a QORT end-of-packet frame ().

In-Order Delivery A reliable transport MUST provide in-order delivery of messages, ensuring that messages are presented to a receiving QORT entity in the same order that they sent by a transmitting QORT entity.

Guaranteed Delivery A reliable transport MUST provide guaranteed delivery, ensuring that any bytes of a message lost in transmission between two endpoints are recovered, normally through retransmission. The reliable transport MUST buffer any bytes received out-of-order and MUST reorder any recovered bytes to ensure in-order delivery of the messages.

Congestion Control A reliable transport MUST provide congestion control that is applied to the aggregate of packets transmitted by an endpoint.

Cryptographic Protection A reliable transport MAY also provide integrity protection (e.g. a cryptographic hash of packet contents) and privacy protection (i.e. encryption). The ability of a reliable transport to provide cryptographic protection may influence the QORT mode of operation selected by a client ().

Modes of Operation A client may choose one of two modes of operations for QUIC over a reliable transport -- CRYPTO-QORT mode or BASIC-QORT mode. If a reliable transport provides integrity and privacy protection, a client SHOULD select BASIC-QORT mode, otherwise the client SHOULD select CRYPTO-QORT mode. The choice of QORT mode is, however, ultimately based on the requirements of the upper-layer application (see ).

Mode Selection The QORT mode of operation selected by the client is indicated by the Version field in the long packet header of the QUIC INITIAL packet sent from the client to a server. If the server is able to support the QORT mode selected by the client, the server MUST respond with a QUIC INITIAL packet where the Version field in the long packet header is the same as the version indicated by the client. If the server is not able to support the QORT mode selected by the client, the server MUST close the connection with an Error_qortNotSupported (). Because the reliable transport has been established between the client and server before the start of QORT operations, there is no mode of operation negotiation -- the server either accepts the mode selected by the client or it closes the connection. Similarly, QORT does not support negotiation of the QUIC protocol version using a VERSION NEGOTIATION packet. In this document, the mode of operation Version dictates compatibility with Version 0x00000001 of QUIC; compatibility with other versions of QUIC are beyond the scope of this document.

CRYPTO-QORT mode of operation The CRYPTO-QORT mode of operation is initiated using a cryptographic handshake sequence similar to that described in . The CRYPTO-QORT mode of operation differs from in the following ways:

the Version field in a QUIC long header packet MUST be set to Version01_qortCrypto ().
deprecated QUIC frames listed in and in MUST NOT be included in any QUIC packets.

In the CRYPTO-QORT mode of operation, a receiving endpoint must be able to detect the end of a QUIC packet before attempting to decrypt the packet. Therefore CRYPTO-QORT mode of operation can only be used with a reliable transport that provides message delimitation (). An exemplary CRYPTO-QORT handshake sequence is illustrated in .

BASIC-QORT mode of operation The BASIC-QORT mode of operation assumes that cryptographic protection (if needed) has been established by the reliable transport before the QORT handshake between client and server begins. As a consequence, the BASIC-QORT mode of operation involves an initial exchange of transport parameters between the endpoints but does not include a cryptographic handshake. The BASIC-QORT mode of operation differs from in the following ways:

the Version field in a QUIC long header packet MUST be set to Version01_qortBasic ().
the QUIC INITIAL packets exchanged between endpoints MUST include a QORT_CONFIGURATION frame ().
QUIC HANDSHAKE packets MUST NOT be exchanged between endpoints.
deprecated QUIC frames listed in and in MUST NOT be included in any QUIC packets.

The BASIC-QORT handshake sequence is illustrated in .

Deprecated QUIC Frames When either QORT mode is enabled, the following QUIC frame types defined by MUST NOT be transmitted by either endpoint in a session:

ACK_ECN frames

are not needed because handling of ECN signals is a function of the reliable transport.
MAX_DATA frames

are not needed because restrictions (if any) on the amount of data to be exchanged must be negotiated and enforced by the reliable transport.
NEW_TOKEN frames

are not needed because à priori validation of the client address (if supported) is a function of the reliable transport.

If an endpoint receives one of these frame types, it MUST close the connection with an error of type Error_qortInvalidFrame ().

Deprecated QUIC Frames in CRYPTO-QORT Mode When CRYPTO-QORT mode is selected, the following additional QUIC frame types defined by MUST NOT be transmitted by either endpoint in a connection:

(TBD)

If an endpoint receives one of these frame types when operating in CRYPTO-QORT mode, it MUST close the connection with an error of type Error_qortInvalidFrame ().

Deprecated QUIC Frames in BASIC-QORT Mode When BASIC-QORT mode is selected, the following additional QUIC frame types defined by MUST NOT be transmitted by either endpoint in a connection:

CRYPTO frames

are not needed because cryptographic protection is provided by the reliable transport.

If an endpoint receives one of these frame types when operating in BASIC-QORT mode, it MUST close the connection with an error of type Error_qortInvalidFrame ().

Use of QUIC ACK Frames QUIC ACK frames are not needed for error recovery nor are they needed for congestion control because the reliable transport provides both of these services (). However, in some instances, an ACK frame may be used as an indication that information previously transmitted in a packet by one QUIC endpoint has been processed by the peer endpoint in a QUIC connection. For this reason, QORT retains the use and processing of ACK frames (but not of ACK_ECN frames, ).

Delimiting QUIC Packets When a reliable transport does not provide message delimitation (), a transmitting QORT endpoint MUST identify the end of a QUIC packet by including a QORT_ENDOFPACKET frame () as the last QUIC frame in the packet. See example in . When a reliable transport does provide message delimitation, QORT_ENDOFPACKET frames MAY be used to identify the end of a QUIC packet even though this adds unnecessary overhead. It is RECOMMENDED that QORT_ENDOFPACKET frames not be used when the reliable transport provides message delimitation. When a receiving endpoint detects a QORT_ENDOFPACKET frame, it MUST stop processing the current QUIC packet. Any bytes remaining in the receive buffer of the endpoint MUST be treated as the start of a new QUIC packet.

New QORT Frame Types QORT procedures utilise one new QUIC frame type -- QORT_ENDOFPACKET -- when operating over a reliable transport that does not provide message delimitation (). In addition, QORT procedures utilise one additional new QUIC frame type -- QORT_CONFIGURATION -- when operating in BASIC-QORT mode. The QORT_CONFIGURATION frame type MUST NOT be used when operating in CRYPTO-QORT mode. The QORT_CONFIGURATION frame type is ack-eliciting; the QORT_ENDOFPACKET frame type is not ack-eliciting. Both QORT_CONFIGURATION and QORT_ENDOFPACKET are non-probing frames.

QORT_CONFIGURATION frame A QORT_CONFIGURATION frame contains transport parameters defined by the sending endpoint. As such, a QORT_CONFIGURATION frame is a direct replacement for the TLS quic_transport_parameters extension described in . When a client initiates the BASIC-QORT mode of operation, the client MUST include a QORT_CONFIGURATION frame in its QUIC INITIAL packet. See example in . When a server agrees to use the BASIC-QORT mode of operation, the server MUST include a QORT_CONFIGURATION frame in its responding QUIC INITIAL packet. A QORT_CONFIGURATION frame () includes the following fields:

QORT_CONFIGURATION Frame Fields

Type

is set to Type_qortConfiguration ().
Transport_Parameter_List_Length

is set to the length of the Transport_Parameter_List, in number of octets.
Transport_Parameter_List

is a list of transport parameters.

As defined in , each transport parameter in the list of transport parameters is encoded as an (identifier, length, value) tuple -- i.e.

RFC9000 Transport Parameter Fields The set of valid QORC transport parameters is described in .

QORT_ENDOFPACKET frame A QORT_ENDOFPACKET frame is used to identify the end of a QUIC packet (). A QORT_ENDOFPACKET frame () includes the following fields:

QORT_ENDOFPACKET Frame Fields

Type

is set to Type_qortEndOfPacket ().

Transport Parameters The different modes of QORT operation use different mechanisms for the exchange of transport parameters by the endpoints:

in CRYPTO-QORT mode of operation, transport parameters are exchanged as a TLS extension in a CRYPTO frame conveyed in an INITIAL packet ();
in BASIC-QORT mode of operation, transport parameters are exchanged as in a QORT_CONFIGRATION frame conveyed in an INITIAL packet ().

RFC9000 Transport Parameters Not all transport parameters defined in are valid for use with QUIC over a reliable transport. When either QORT mode is enabled, a QUIC transport parameter with an 'x' in the "not allowed?" column of MUST NOT be transmitted by either endpoint. Allowed/Not-allowed QUIC Transport Parameters

transport parameter	allowed?	not allowed?
original_destination_connection_id	x
max_idle_timeout	x
stateless_reset_token	x
max_udp_payload_size	x
initial_max_data		x
initial_max_stream_data_bidi_local	x
initial_max_stream_data_bidi_remote	x
initial_max_stream_data_uni	x
initial_max_streams_bidi	x
initial_max_streams_uni	x
ack_delay_exponent	x
max_ack_delay	x
disable_active_migration	x
preferred_address		x
active_connection_id_limit	x
initial_source_connection_id	x
retry_source_connection_id		x

If an endpoint receives one of the "not allowed?" transport parameters, it MUST close the connection with an error of type Error_qortInvalidParameter ().

QORT Connection Errors This document extends the QUIC Transport Error Codes of with the following values ():

Error_qortInvalidFrame

indicates that an unknown frame type was received or that the QUIC frame type is not allowed in the QORT mode of operation ().
Error_qortInvalidParameter

indicates that a received transport parameter was invalid (e.g. was badly formatted) or is not allowed in a QORT mode of operation () .
Error_qortNotSupported

indicates that the QORT mode of operation selected by a client is not supported by the server.
Error_qortProtocolViolation

indicates an error with protocol compliance that is not covered by a more specific error code -- e.g. an endpoint received a QORT_CONFIGURATION frame when BASIC-QORT mode is not selected.

QORT connection errors MUST be processed according to .

QUIC extensions In general, any extension to Version 0x00000001 of QUIC that does not rely on the deprecated QUIC frames of may be used with QORT (e.g. , ). However this must be be verified by the extension designers and is beyond the scope of this document.

Security Considerations QORT does not change the operating principles of and, as such, is subject to the same security considerations as . Specific security considerations associated with the use of QORT procedures include:

packet protection. When using BASIC-QORT mode. the reliable transport is also expected to provide cryptographic protection of its payload (i.e. QUIC packets). As a consequence, all bits of a QUIC packet are cryptographically protected. Therefore, in BASIC-QORT mode, it should not be possible to mount an attack that relies on unfettered visibility of bits in a QUIC packet header ().

IANA Considerations If approved, the following provisional entries will be added to the IANA QUIC Protocol Registry .

QUIC version numbers This document defines two new (preliminary) QUIC version numbers that are bound to Version 0x00000001 of QUIC ():

Version01_qortBasic (0x54e51e9e)
Version01_qortCrypto (0x147214bd)

QORT transport error codes This document extends the QUIC Transport Error Codes of with the following (preliminary) values:

Error_qortInvalidFrame (0x2fc2ed12e1295ab1)
Error_qortInvalidParameter (0x0b244a578d7dc6c4)
Error_qortNotSupported (0x341b50c67a845ff4)
Error_qortProtocolViolation (0x0ed79e3b4c52d445)

New QUIC frame types This document defines two new (preliminary) QUIC frame types:

Type_qortConfiguration (0x27f72376051c5308) --
Type_qortEndOfPacket (0x3b5690c1243618cd) --

References Normative References QUIC: A UDP-Based Multiplexed and Secure Transport 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. Using TLS to Secure QUIC This document describes how Transport Layer Security (TLS) is used to secure QUIC. QUIC Loss Detection and Congestion Control This document describes loss detection and congestion control mechanisms for QUIC. QUIC Protocol Registry Internet Assigned Numbers Authority Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. Informative References Manageability of the QUIC Transport Protocol This document discusses manageability of the QUIC transport protocol and focuses on the implications of QUIC's design and wire image on network operations involving QUIC traffic. It is intended as a "user's manual" for the wire image to provide guidance for network operators and equipment vendors who rely on the use of transport-aware network functions. An Unreliable Datagram Extension to QUIC This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. QUIC Path Management for Multi-Path Configurations Unaffiliated This document defines path management procedures for QUIC that operate independently of the connection management procedures defined in RFC9000. The path management procedures enable a multipath configuration between endpoints by allowing QUIC packets associated with any connection identifier to be transported over any of the paths established between the endpoints. As a consequence, the principles and operations of RFC9000 are retained regardless of the path used to a convey QUIC packet. QMux Fastly Cloudflare Netflix Apple This document specifies QMux version 1. QMux version 1 provides, over bi-directional streams such as TLS, the same set of stream and datagram operations that applications rely upon in QUIC version 1. 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/kazuho/draft-opik-quic-qmux. Stream Control Transmission Protocol This document describes the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document. In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document. SCTP was originally designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. It is also suited to be used for other applications, for example, WebRTC. SCTP is a reliable transport protocol operating on top of a connectionless packet network, such as IP. It offers the following services to its users: The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. Transmission Control Protocol (TCP) This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. The Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Technical Specification 38.300; NR and NG-RAN Overall Description; Stage 2 3rd Generation Partnership Project (3GPP)

QORT Packet Examples This section contains examples of QUIC packets when using QORT procedures.

QUIC Packet with QORT_ENDOFPACKET Frame When message delimitation is not provided by the reliable transport, each transmitted QUIC packet must be terminated by a QORT_ENDOFPACKET frame. This is illustrated in .

Packet with QORT_ENDOFPACKET Frame

QUIC Initial Packet with QORT_CONFIGURATION Frame In BASIC-QORT mode of operation, the INITIAL QUIC packet must include a QORT_CONFIGURATION frame. This is illustrated in .

INITIAL Packet with QORT_CONFIGURATION Frame

QORT use with reliable transports indicates how QORT is expected to be used with several reliable transports. The "Mode" indicates the QORT mode of operation and whether a QORT_ENDOFPACKET frame ("eop") is used for packet delimitation. QORT modes over various transports

Mode	TLS/TCP	TLS/SCTP	NR-RLP	TCP	SCTP
BASIC with eop	(1)	(2)	(2)	(3)	(3)
BASIC without eop	(x)	(1)	(1)	(x)	(3)
CRYPTO with eop	(x)	(2,4)	(2,4)	(x)	(2)
CRYPTO without eop	(x)	(4)	(4)	(x)	(1)

(1) recommended mode of operation
(2) possible, but not recommended - redundant end-of-packet frames
(3) possible, but not recommended - no cryptographic protection
(4) possible, but not recommended - redundant cryptographic protection
(x) not possible - message delimitation required

Comparison to proposes to convey QUIC frames over a reliable, bi-directional, byte-oriented stream. The following sections highlight key differences between and QORT.

Use of QUIC packets does not use QUIC packets for encapsulating QUIC frames. Instead, sends QUIC frames directly over the reliable transport. By contrast, QORT retains the use of QUIC packets to support QUIC operations that are dependent on information in the QUIC packet header as described in -- e.g. packet numbering, coalescence, cryptographic protection, connection identification and migration.

Connections and connection identifiers does not include mechanisms for identifying QUIC connections, for managing QUIC connection identifiers, or for path migration. Essentially, all QUIC frames are associated with a zero-length connection identifier. By contrast, QORT retains the concept of QUIC connections and associated connection identifiers to support connection management, path migration and multipath operations.

Cryptographic protection requires an underlying transport that provides cryptographic protection. As a consequence, offers no cryptographic capabilities. By contrast, QORT offers a CRYPTO-QORT mode of operation that reuses cryptographic protection mechanisms such as a cryptographic handshake using QUIC CRYPTO frames and key rotation using the key phase bit of a QUIC packet header.

Stream processing While reuses QUIC STREAM frames for exchanging application data, introduces some restrictions on STREAM frame use. By contrast, QORT does not change any procedures related to stream processing.