RFC 9312: Manageability of the QUIC Transport Protocol | RFC Editor

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.¶
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9312.¶
Copyright (c) 2022 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.¶
QUIC [QUIC-TRANSPORT] is a new transport protocol that is encapsulated in UDP. QUIC integrates TLS [QUIC-TLS] to encrypt all payload data and most control information. QUIC version 1 was designed primarily as a transport for HTTP with the resulting protocol being known as HTTP/3 [QUIC-HTTP].¶
This document provides guidance for network operations that manage QUIC traffic. This includes guidance on how to interpret and utilize information that is exposed by QUIC to the network, requirements and assumptions of the QUIC design with respect to network treatment, and a description of how common network management practices will be impacted by QUIC.¶
QUIC is an end-to-end transport protocol; therefore, no information in the protocol header is intended to be mutable by the network. This property is enforced through integrity protection of the wire image [WIRE-IMAGE]. Encryption of most transport-layer control signaling means that less information is visible to the network in comparison to TCP.¶
Integrity protection can also simplify troubleshooting at the end points as none of the nodes on the network path can modify transport layer information. However, it means in-network operations that depend on modification of data (for examples, see [RFC9065]) are not possible without the cooperation of a QUIC endpoint. Such cooperation might be possible with the introduction of a proxy that authenticates as an endpoint. Proxy operations are not in scope for this document.¶
Network management is not a one-size-fits-all endeavor; for example, practices considered necessary or even mandatory within enterprise networks with certain compliance requirements would be impermissible on other networks without those requirements. Therefore, presence of a particular practice in this document should not be construed as a recommendation to apply it. For each practice, this document describes what is and is not possible with the QUIC transport protocol as defined.¶
This document focuses solely on network management practices that observe traffic on the wire. For example, replacement of troubleshooting based on observation with active measurement techniques is therefore out of scope. A more generalized treatment of network management operations on encrypted transports is given in [RFC9065].¶
QUIC-specific terminology used in this document is defined in [QUIC-TRANSPORT].¶
This section discusses aspects of the QUIC transport protocol that have an impact on the design and operation of devices that forward QUIC packets. Therefore, this section is primarily considering the unencrypted part of QUIC's wire image [WIRE-IMAGE], which is defined as the information available in the packet header in each QUIC packet, and the dynamics of that information. Since QUIC is a versioned protocol, the wire image of the header format can also change from version to version. However, the field that identifies the QUIC version in some packets and the format of the Version Negotiation packet are both inspectable and invariant [QUIC-INVARIANTS].¶
This document addresses version 1 of the QUIC protocol, whose wire image is fully defined in [QUIC-TRANSPORT] and [QUIC-TLS]. Features of the wire image described herein may change in future versions of the protocol except when specified as an invariant [QUIC-INVARIANTS] and cannot be used to identify QUIC as a protocol or to infer the behavior of future versions of QUIC.¶
QUIC packets may have either a long header or a short header. The first bit of the QUIC header is the Header Form bit and indicates which type of header is present. The purpose of this bit is invariant across QUIC versions.¶
The long header exposes more information. It contains a version number, as well as Source and Destination Connection IDs for associating packets with a QUIC connection. The definition and location of these fields in the QUIC long header are invariant for future versions of QUIC, although future versions of QUIC may provide additional fields in the long header [QUIC-INVARIANTS].¶
In version 1 of QUIC, the long header is used during connection establishment to transmit CRYPTO handshake data, perform version negotiation, retry, and send 0-RTT data.¶
Short headers are used after a connection establishment in version 1 of QUIC and expose only an optional Destination Connection ID and the initial flags byte with the spin bit f