https://www.rfc-editor.org/rfc/rfc9312.txt

 Internet Engineering Task Force (IETF) M. Kühlewind Request for Comments: 9312 Ericsson Category: Informational B. Trammell ISSN: 2070-1721 Google Switzerland GmbH September 2022 Manageability of the QUIC Transport Protocol Abstract 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. Status of This Memo 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 Notice 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. Table of Contents 1. Introduction 2. Features of the QUIC Wire Image 2.1. QUIC Packet Header Structure 2.2. Coalesced Packets 2.3. Use of Port Numbers 2.4. The QUIC Handshake 2.5. Integrity Protection of the Wire Image 2.6. Connection ID and Rebinding 2.7. Packet Numbers 2.8. Version Negotiation and Greasing 3. Network-Visible Information about QUIC Flows 3.1. Identifying QUIC Traffic 3.1.1. Identifying Negotiated Version 3.1.2. First Packet Identification for Garbage Rejection 3.2. Connection Confirmation 3.3. Distinguishing Acknowledgment Traffic 3.4. Server Name Indication (SNI) 3.4.1. Extracting Server Name Indication (SNI) Information 3.5. Flow Association 3.6. Flow Teardown 3.7. Flow Symmetry Measurement 3.8. Round-Trip Time (RTT) Measurement 3.8.1. Measuring Initial RTT 3.8.2. Using the Spin Bit for Passive RTT Measurement 4. Specific Network Management Tasks 4.1. Passive Network Performance Measurement and Troubleshooting 4.2. Stateful Treatment of QUIC Traffic 4.3. Address Rewriting to Ensure Routing Stability 4.4. Server Cooperation with Load Balancers 4.5. Filtering Behavior 4.6. UDP Blocking, Throttling, and NAT Binding 4.7. DDoS Detection and Mitigation 4.8. Quality of Service Handling and ECMP Routing 4.9. Handling ICMP Messages 4.10. Guiding Path MTU 5. IANA Considerations 6. Security Considerations 7. References 7.1. Normative References 7.2. Informative References Acknowledgments Contributors Authors' Addresses 1. Introduction 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]. 2. Features of the QUIC Wire Image 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