| < draft-ietf-quic-manageability-15.txt | draft-ietf-quic-manageability-16.txt > | |||
|---|---|---|---|---|
| Network Working Group M. Kuehlewind | Network Working Group M. Kuehlewind | |||
| Internet-Draft Ericsson | Internet-Draft Ericsson | |||
| Intended status: Informational B. Trammell | Intended status: Informational B. Trammell | |||
| Expires: 8 September 2022 Google Switzerland GmbH | Expires: 8 October 2022 Google Switzerland GmbH | |||
| 7 March 2022 | 6 April 2022 | |||
| Manageability of the QUIC Transport Protocol | Manageability of the QUIC Transport Protocol | |||
| draft-ietf-quic-manageability-15 | draft-ietf-quic-manageability-16 | |||
| Abstract | Abstract | |||
| This document discusses manageability of the QUIC transport protocol, | This document discusses manageability of the QUIC transport protocol, | |||
| focusing on the implications of QUIC's design and wire image on | focusing on the implications of QUIC's design and wire image on | |||
| network operations involving QUIC traffic. It is intended as a | network operations involving QUIC traffic. It is intended as a | |||
| "user's manual" for the wire image, providing guidance for network | "user's manual" for the wire image, providing guidance for network | |||
| operators and equipment vendors who rely on the use of transport- | operators and equipment vendors who rely on the use of transport- | |||
| aware network functions. | aware network functions. | |||
| skipping to change at page 1, line 36 ¶ | skipping to change at page 1, line 36 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 8 September 2022. | This Internet-Draft will expire on 8 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 20 ¶ | skipping to change at page 2, line 20 ¶ | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Features of the QUIC Wire Image . . . . . . . . . . . . . . . 4 | 2. Features of the QUIC Wire Image . . . . . . . . . . . . . . . 4 | |||
| 2.1. QUIC Packet Header Structure . . . . . . . . . . . . . . 4 | 2.1. QUIC Packet Header Structure . . . . . . . . . . . . . . 4 | |||
| 2.2. Coalesced Packets . . . . . . . . . . . . . . . . . . . . 6 | 2.2. Coalesced Packets . . . . . . . . . . . . . . . . . . . . 6 | |||
| 2.3. Use of Port Numbers . . . . . . . . . . . . . . . . . . . 6 | 2.3. Use of Port Numbers . . . . . . . . . . . . . . . . . . . 7 | |||
| 2.4. The QUIC Handshake . . . . . . . . . . . . . . . . . . . 7 | 2.4. The QUIC Handshake . . . . . . . . . . . . . . . . . . . 7 | |||
| 2.5. Integrity Protection of the Wire Image . . . . . . . . . 11 | 2.5. Integrity Protection of the Wire Image . . . . . . . . . 12 | |||
| 2.6. Connection ID and Rebinding . . . . . . . . . . . . . . . 11 | 2.6. Connection ID and Rebinding . . . . . . . . . . . . . . . 12 | |||
| 2.7. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 12 | 2.7. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 2.8. Version Negotiation and Greasing . . . . . . . . . . . . 12 | 2.8. Version Negotiation and Greasing . . . . . . . . . . . . 13 | |||
| 3. Network-Visible Information about QUIC Flows . . . . . . . . 13 | 3. Network-Visible Information about QUIC Flows . . . . . . . . 14 | |||
| 3.1. Identifying QUIC Traffic . . . . . . . . . . . . . . . . 13 | 3.1. Identifying QUIC Traffic . . . . . . . . . . . . . . . . 14 | |||
| 3.1.1. Identifying Negotiated Version . . . . . . . . . . . 14 | 3.1.1. Identifying Negotiated Version . . . . . . . . . . . 15 | |||
| 3.1.2. First Packet Identification for Garbage Rejection . . 14 | 3.1.2. First Packet Identification for Garbage Rejection . . 15 | |||
| 3.2. Connection Confirmation . . . . . . . . . . . . . . . . . 14 | 3.2. Connection Confirmation . . . . . . . . . . . . . . . . . 15 | |||
| 3.3. Distinguishing Acknowledgment Traffic . . . . . . . . . . 15 | 3.3. Distinguishing Acknowledgment Traffic . . . . . . . . . . 16 | |||
| 3.4. Server Name Indication (SNI) . . . . . . . . . . . . . . 15 | 3.4. Server Name Indication (SNI) . . . . . . . . . . . . . . 16 | |||
| 3.4.1. Extracting Server Name Indication (SNI) | 3.4.1. Extracting Server Name Indication (SNI) | |||
| Information . . . . . . . . . . . . . . . . . . . . . 15 | Information . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 3.5. Flow Association . . . . . . . . . . . . . . . . . . . . 17 | 3.5. Flow Association . . . . . . . . . . . . . . . . . . . . 18 | |||
| 3.6. Flow Teardown . . . . . . . . . . . . . . . . . . . . . . 17 | 3.6. Flow Teardown . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 3.7. Flow Symmetry Measurement . . . . . . . . . . . . . . . . 18 | 3.7. Flow Symmetry Measurement . . . . . . . . . . . . . . . . 19 | |||
| 3.8. Round-Trip Time (RTT) Measurement . . . . . . . . . . . . 18 | 3.8. Round-Trip Time (RTT) Measurement . . . . . . . . . . . . 19 | |||
| 3.8.1. Measuring Initial RTT . . . . . . . . . . . . . . . . 18 | 3.8.1. Measuring Initial RTT . . . . . . . . . . . . . . . . 19 | |||
| 3.8.2. Using the Spin Bit for Passive RTT Measurement . . . 18 | 3.8.2. Using the Spin Bit for Passive RTT Measurement . . . 19 | |||
| 4. Specific Network Management Tasks . . . . . . . . . . . . . . 20 | 4. Specific Network Management Tasks . . . . . . . . . . . . . . 21 | |||
| 4.1. Passive Network Performance Measurement and | 4.1. Passive Network Performance Measurement and | |||
| Troubleshooting . . . . . . . . . . . . . . . . . . . . 20 | Troubleshooting . . . . . . . . . . . . . . . . . . . . 21 | |||
| 4.2. Stateful Treatment of QUIC Traffic . . . . . . . . . . . 21 | 4.2. Stateful Treatment of QUIC Traffic . . . . . . . . . . . 22 | |||
| 4.3. Address Rewriting to Ensure Routing Stability . . . . . . 22 | 4.3. Address Rewriting to Ensure Routing Stability . . . . . . 23 | |||
| 4.4. Server Cooperation with Load Balancers . . . . . . . . . 23 | 4.4. Server Cooperation with Load Balancers . . . . . . . . . 24 | |||
| 4.5. Filtering Behavior . . . . . . . . . . . . . . . . . . . 23 | 4.5. Filtering Behavior . . . . . . . . . . . . . . . . . . . 24 | |||
| 4.6. UDP Blocking, Throttling, and NAT Binding . . . . . . . . 23 | 4.6. UDP Blocking, Throttling, and NAT Binding . . . . . . . . 24 | |||
| 4.7. DDoS Detection and Mitigation . . . . . . . . . . . . . . 24 | 4.7. DDoS Detection and Mitigation . . . . . . . . . . . . . . 25 | |||
| 4.8. Quality of Service Handling and ECMP Routing . . . . . . 26 | 4.8. Quality of Service Handling and ECMP Routing . . . . . . 27 | |||
| 4.9. Handling ICMP Messages . . . . . . . . . . . . . . . . . 26 | 4.9. Handling ICMP Messages . . . . . . . . . . . . . . . . . 27 | |||
| 4.10. Guiding Path MTU . . . . . . . . . . . . . . . . . . . . 26 | 4.10. Guiding Path MTU . . . . . . . . . . . . . . . . . . . . 27 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 | |||
| 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 | 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 29 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 30 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 30 | 9.2. Informative References . . . . . . . . . . . . . . . . . 31 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
| 1. Introduction | 1. Introduction | |||
| QUIC [QUIC-TRANSPORT] is a new transport protocol that is | QUIC [QUIC-TRANSPORT] is a new transport protocol that is | |||
| encapsulated in UDP. QUIC integrates TLS [QUIC-TLS] to encrypt all | encapsulated in UDP. QUIC integrates TLS [QUIC-TLS] to encrypt all | |||
| payload data and most control information. QUIC version 1 was | payload data and most control information. QUIC version 1 was | |||
| designed primarily as a transport for HTTP, with the resulting | designed primarily as a transport for HTTP, with the resulting | |||
| protocol being known as HTTP/3 [QUIC-HTTP]. | protocol being known as HTTP/3 [QUIC-HTTP]. | |||
| This document provides guidance for network operations that manage | This document provides guidance for network operations that manage | |||
| skipping to change at page 3, line 48 ¶ | skipping to change at page 3, line 48 ¶ | |||
| layer information. However, it means in-network operations that | layer information. However, it means in-network operations that | |||
| depend on modification of data (for examples, see [RFC9065]) are not | depend on modification of data (for examples, see [RFC9065]) are not | |||
| possible without the cooperation of a QUIC endpoint. Such | possible without the cooperation of a QUIC endpoint. Such | |||
| cooperation might be possible with the introduction of a proxy which | cooperation might be possible with the introduction of a proxy which | |||
| authenticates as an endpoint. Proxy operations are not in scope for | authenticates as an endpoint. Proxy operations are not in scope for | |||
| this document. | this document. | |||
| Network management is not a one-size-fits-all endeavour: practices | Network management is not a one-size-fits-all endeavour: practices | |||
| considered necessary or even mandatory within enterprise networks | considered necessary or even mandatory within enterprise networks | |||
| with certain compliance requirements, for example, would be | with certain compliance requirements, for example, would be | |||
| impermissible on other networks without those requirements. This | impermissible on other networks without those requirements. The | |||
| document therefore does not make any specific recommendations as to | presence of a particular practice in this document should therefore | |||
| which practices should or should not be applied; for each practice, | not be construed as a recommendation to apply it. For each practice, | |||
| it describes what is and is not possible with the QUIC transport | this document describes what is and is not possible with the QUIC | |||
| protocol as defined. | transport protocol as defined. | |||
| This document focuses solely on network management practices that | ||||
| observe traffic on the wire. Replacement of troubleshooting based on | ||||
| observation with active measurement techniques, for example, 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-specific terminology used in this document is defined in | |||
| [QUIC-TRANSPORT]. | [QUIC-TRANSPORT]. | |||
| 2. Features of the QUIC Wire Image | 2. Features of the QUIC Wire Image | |||
| This section discusses those aspects of the QUIC transport protocol | This section discusses those aspects of the QUIC transport protocol | |||
| that have an impact on the design and operation of devices that | that have an impact on the design and operation of devices that | |||
| forward QUIC packets. This section is therefore primarily | forward QUIC packets. This section is therefore primarily | |||
| considering the unencrypted part of QUIC's wire image [WIRE-IMAGE], | considering the unencrypted part of QUIC's wire image [WIRE-IMAGE], | |||
| which is defined as the information available in the packet header in | which is defined as the information available in the packet header in | |||
| each QUIC packet, and the dynamics of that information. Since QUIC | each QUIC packet, and the dynamics of that information. Since QUIC | |||
| is a versioned protocol, the wire image of the header format can also | is a versioned protocol, the wire image of the header format can also | |||
| change from version to version. However, the field that identifies | change from version to version. However, the field that identifies | |||
| the QUIC version in some packets, and the format of the Version | the QUIC version in some packets, and the format of the Version | |||
| Negotiation Packet, are both inspectable and invariant | Negotiation Packet, are both inspectable and invariant | |||
| [QUIC-INVARIANTS]. | [QUIC-INVARIANTS]. | |||
| This document describes version 1 of the QUIC protocol, whose wire | This document addresses version 1 of the QUIC protocol, whose wire | |||
| image is fully defined in [QUIC-TRANSPORT] and [QUIC-TLS]. Features | image is fully defined in [QUIC-TRANSPORT] and [QUIC-TLS]. Features | |||
| of the wire image described herein may change in future versions of | of the wire image described herein may change in future versions of | |||
| the protocol, except when specified as an invariant | the protocol, except when specified as an invariant | |||
| [QUIC-INVARIANTS], and cannot be used to identify QUIC as a protocol | [QUIC-INVARIANTS], and cannot be used to identify QUIC as a protocol | |||
| or to infer the behavior of future versions of QUIC. | or to infer the behavior of future versions of QUIC. | |||
| 2.1. QUIC Packet Header Structure | 2.1. QUIC Packet Header Structure | |||
| QUIC packets may have either a long header or a short header. The | 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 | first bit of the QUIC header is the Header Form bit, and indicates | |||
| skipping to change at page 5, line 16 ¶ | skipping to change at page 5, line 23 ¶ | |||
| and identifies the version used for that packet. During Version | and identifies the version used for that packet. During Version | |||
| Negotiation (see Section 17.2.1 of [QUIC-TRANSPORT] and | Negotiation (see Section 17.2.1 of [QUIC-TRANSPORT] and | |||
| Section 2.8), the version number field has a special value | Section 2.8), the version number field has a special value | |||
| (0x00000000) that identifies the packet as a Version Negotiation | (0x00000000) that identifies the packet as a Version Negotiation | |||
| packet. QUIC version 1 uses version 0x00000001. Operators should | packet. QUIC version 1 uses version 0x00000001. Operators should | |||
| expect to observe packets with other version numbers as a result | expect to observe packets with other version numbers as a result | |||
| of various Internet experiments, future standards, and greasing | of various Internet experiments, future standards, and greasing | |||
| ([RFC7801]). All deployed versions are maintained in an IANA | ([RFC7801]). All deployed versions are maintained in an IANA | |||
| registry (see Section 22.2 of [QUIC-TRANSPORT]). | registry (see Section 22.2 of [QUIC-TRANSPORT]). | |||
| * source and destination connection ID: short and long packet | * source and destination connection ID: short and long headers carry | |||
| headers carry a destination connection ID, a variable-length field | a destination connection ID, a variable-length field that can be | |||
| that can be used to identify the connection associated with a QUIC | used to identify the connection associated with a QUIC packet, for | |||
| packet, for load-balancing and NAT rebinding purposes; see | load-balancing and NAT rebinding purposes; see Section 4.4 and | |||
| Section 4.4 and Section 2.6. Long packet headers additionally | Section 2.6. Long packet headers additionally carry a source | |||
| carry a source connection ID. The source connection ID | connection ID. The source connection ID corresponds to the | |||
| corresponds to the destination connection ID the source would like | destination connection ID the source would like to have on packets | |||
| to have on packets sent to it, and is only present on long packet | sent to it, and is only present on long headers. On long header | |||
| headers. On long header packets, the length of the connection IDs | packets, the length of the connection IDs is also present; on | |||
| is also present; on short header packets, the length of the | short header packets, the length of the destination connection ID | |||
| destination connection ID is implicit. | is implicit. | |||
| In version 1 of QUIC, the following additional information is | In version 1 of QUIC, the following additional information is | |||
| exposed: | exposed: | |||
| * "fixed bit": The second-most-significant bit of the first octet of | * "fixed bit": The second-most-significant bit of the first octet of | |||
| most QUIC packets of the current version is set to 1, enabling | most QUIC packets of the current version is set to 1, enabling | |||
| endpoints to demultiplex with other UDP-encapsulated protocols. | endpoints to demultiplex with other UDP-encapsulated protocols. | |||
| Even though this bit is fixed in the version 1 specification, | Even though this bit is fixed in the version 1 specification, | |||
| endpoints might use an extension that varies the bit. Therefore, | endpoints might use an extension that varies the bit. Therefore, | |||
| observers cannot reliably use it as an identifier for QUIC. | observers cannot reliably use it as an identifier for QUIC. | |||
| * latency spin bit: The third-most-significant bit of the first | * latency spin bit: The third-most-significant bit of the first | |||
| octet in the short packet header for version 1. The spin bit is | octet in the short header for version 1. The spin bit is set by | |||
| set by endpoints such that tracking edge transitions can be used | endpoints such that tracking edge transitions can be used to | |||
| to passively observe end-to-end RTT. See Section 3.8.2 for | passively observe end-to-end RTT. See Section 3.8.2 for further | |||
| further details. | details. | |||
| * header type: The long header has a 2 bit packet type field | * header type: The long header has a 2 bit packet type field | |||
| following the Header Form and fixed bits. Header types correspond | following the Header Form and fixed bits. Header types correspond | |||
| to stages of the handshake; see Section 17.2 of [QUIC-TRANSPORT] | to stages of the handshake; see Section 17.2 of [QUIC-TRANSPORT] | |||
| for details. | for details. | |||
| * length: The length of the remaining QUIC packet after the length | * length: The length of the remaining QUIC packet after the length | |||
| field, present on long headers. This field is used to implement | field, present on long headers. This field is used to implement | |||
| coalesced packets during the handshake (see Section 2.2). | coalesced packets during the handshake (see Section 2.2). | |||
| * token: Initial packets may contain a token, a variable-length | * token: Initial packets may contain a token, a variable-length | |||
| opaque value optionally sent from client to server, used for | opaque value optionally sent from client to server, used for | |||
| validating the client's address. Retry packets also contain a | validating the client's address. Retry packets also contain a | |||
| token, which can be used by the client in an Initial packet on a | token, which can be used by the client in an Initial packet on a | |||
| subsequent connection attempt. The length of the token is | subsequent connection attempt. The length of the token is | |||
| explicit in both cases. | explicit in both cases. | |||
| Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation | Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation | |||
| (Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or | (Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or | |||
| obfuscated in any way. For other kinds of packets, version 1 of QUIC | protected in any way. For other kinds of packets, version 1 of QUIC | |||
| cryptographically obfuscates other information in the packet headers: | cryptographically obfuscates other information in the packet headers: | |||
| * packet number: All packets except Version Negotiation and Retry | * packet number: All packets except Version Negotiation and Retry | |||
| packets have an associated packet number; however, this packet | packets have an associated packet number; however, this packet | |||
| number is encrypted, and therefore not of use to on-path | number is encrypted, and therefore not of use to on-path | |||
| observers. The offset of the packet number can be decoded in long | observers. The offset of the packet number can be decoded in long | |||
| headers, while it is implicit (depending on destination connection | headers, while it is implicit (depending on destination connection | |||
| ID length) in short headers. The length of the packet number is | ID length) in short headers. The length of the packet number is | |||
| cryptographically obfuscated. | cryptographically protected. | |||
| * key phase: The Key Phase bit, present in short headers, specifies | * key phase: The Key Phase bit, present in short headers, specifies | |||
| the keys used to encrypt the packet to support key rotation. The | the keys used to encrypt the packet to support key rotation. The | |||
| Key Phase bit is cryptographically obfuscated. | Key Phase bit is cryptographically protected. | |||
| 2.2. Coalesced Packets | 2.2. Coalesced Packets | |||
| Multiple QUIC packets may be coalesced into a single UDP datagram, | Multiple QUIC packets may be coalesced into a single UDP datagram, | |||
| with a datagram carrying one or more long header packets followed by | with a datagram carrying one or more long header packets followed by | |||
| zero or one short header packets. When packets are coalesced, the | zero or one short header packets. When packets are coalesced, the | |||
| Length fields in the long headers are used to separate QUIC packets; | Length fields in the long headers are used to separate QUIC packets; | |||
| see Section 12.2 of [QUIC-TRANSPORT]. The Length field is variable | see Section 12.2 of [QUIC-TRANSPORT]. The Length field is variable | |||
| length, and its position in the header is also variable depending on | length, and its position in the header is also variable depending on | |||
| the length of the source and destination connection ID; see | the length of the source and destination connection ID; see | |||
| skipping to change at page 9, line 21 ¶ | skipping to change at page 9, line 35 ¶ | |||
| +----------------------------------------------------------+ | | +----------------------------------------------------------+ | | |||
| | | TLS Client Hello (incl. TLS SNI) | | | | | | TLS Client Hello (incl. TLS SNI) | | | | |||
| +----------------------------------------------------------+ | | +----------------------------------------------------------+ | | |||
| | QUIC PADDING frames | | | | QUIC PADDING frames | | | |||
| +----------------------------------------------------------+<-+ | +----------------------------------------------------------+<-+ | |||
| Figure 2: Example Client Initial datagram without 0-RTT | Figure 2: Example Client Initial datagram without 0-RTT | |||
| A Client Initial packet exposes the version, source and destination | A Client Initial packet exposes the version, source and destination | |||
| connection IDs without encryption. The payload of the Initial packet | connection IDs without encryption. The payload of the Initial packet | |||
| is obfuscated using the Initial secret. The complete TLS Client | is protected using the Initial secret. The complete TLS Client | |||
| Hello, including any TLS Server Name Indication (SNI) present, is | Hello, including any TLS Server Name Indication (SNI) present, is | |||
| sent in one or more CRYPTO frames across one or more QUIC Initial | sent in one or more CRYPTO frames across one or more QUIC Initial | |||
| packets. | packets. | |||
| +------------------------------------------------------------+ | +------------------------------------------------------------+ | |||
| | UDP header (source and destination UDP ports) | | | UDP header (source and destination UDP ports) | | |||
| +------------------------------------------------------------+ | +------------------------------------------------------------+ | |||
| | QUIC long header (type = Initial, Version, DCID, SCID) (Length) | | QUIC long header (type = Initial, Version, DCID, SCID) (Length) | |||
| +------------------------------------------------------------+ | | +------------------------------------------------------------+ | | |||
| | QUIC CRYPTO frame header | | | | QUIC CRYPTO frame header | | | |||
| skipping to change at page 9, line 50 ¶ | skipping to change at page 10, line 29 ¶ | |||
| +------------------------------------------------------------+<-+ | +------------------------------------------------------------+<-+ | |||
| | QUIC short header | | | QUIC short header | | |||
| +------------------------------------------------------------+ | +------------------------------------------------------------+ | |||
| | 1-RTT encrypted payload | | | 1-RTT encrypted payload | | |||
| +------------------------------------------------------------+ | +------------------------------------------------------------+ | |||
| Figure 3: Coalesced Server Initial datagram pattern | Figure 3: Coalesced Server Initial datagram pattern | |||
| The Server Initial datagram also exposes version number, source and | The Server Initial datagram also exposes version number, source and | |||
| destination connection IDs in the clear; the payload of the Initial | destination connection IDs in the clear; the payload of the Initial | |||
| packet(s) is obfuscated using the Initial secret. | packet(s) is protected using the Initial secret. | |||
| +------------------------------------------------------------+ | +------------------------------------------------------------+ | |||
| | UDP header (source and destination UDP ports) | | | UDP header (source and destination UDP ports) | | |||
| +------------------------------------------------------------+ | +------------------------------------------------------------+ | |||
| | QUIC long header (type = Initial, Version, DCID, SCID) (Length) | | QUIC long header (type = Initial, Version, DCID, SCID) (Length) | |||
| +------------------------------------------------------------+ | | +------------------------------------------------------------+ | | |||
| | QUIC ACK frame (acknowledging Server Initial) | | | | QUIC ACK frame (acknowledging Server Initial) | | | |||
| +------------------------------------------------------------+<-+ | +------------------------------------------------------------+<-+ | |||
| | QUIC long header (type = Handshake, Version, DCID, SCID) (Length) | | QUIC long header (type = Handshake, Version, DCID, SCID) (Length) | |||
| +------------------------------------------------------------+ | | +------------------------------------------------------------+ | | |||
| skipping to change at page 13, line 7 ¶ | skipping to change at page 13, line 37 ¶ | |||
| may contain reserved versions. This mechanism is used to avoid | may contain reserved versions. This mechanism is used to avoid | |||
| ossification in the implementation on the selection mechanism. | ossification in the implementation on the selection mechanism. | |||
| Further, a client may send an Initial packet with a reserved version | Further, a client may send an Initial packet with a reserved version | |||
| number to trigger version negotiation. In the Version Negotiation | number to trigger version negotiation. In the Version Negotiation | |||
| packet, the connection IDs of the client's Initial packet are | packet, the connection IDs of the client's Initial packet are | |||
| reflected to provide a proof of return-routability. Therefore, | reflected to provide a proof of return-routability. Therefore, | |||
| changing this information will also cause the connection to fail. | changing this information will also cause the connection to fail. | |||
| QUIC is expected to evolve rapidly, so new versions, both | QUIC is expected to evolve rapidly, so new versions, both | |||
| experimental and IETF standard versions, will be deployed on the | experimental and IETF standard versions, will be deployed on the | |||
| Internet more often than with traditional Internet- and transport- | Internet more often than with other commonly deployed Internet- and | |||
| layer protocols. Using a particular version number to recognize | transport-layer protocols. Use of the version number field for | |||
| valid QUIC traffic is likely to persistently miss a fraction of QUIC | traffic recognition will therefore behave differently than with these | |||
| flows and completely fail in the near future, and is therefore not | protocols. Using a particular version number to recognize valid QUIC | |||
| recommended. In addition, due to the speed of evolution of the | traffic is likely to persistently miss a fraction of QUIC flows, and | |||
| protocol, devices that attempt to distinguish QUIC traffic from non- | completely fail in the near future. Reliance on the version number | |||
| QUIC traffic for purposes of network admission control should not | field for the purposes of admission control is similarly likely to | |||
| rely on the version number field. Instead it is recommended to admit | rapidly lead to unintended failure modes. Admission of QUIC traffic | |||
| all QUIC traffic regardless of version in order to support continious | regardless of version avoids these failure modes, avoids unnecessary | |||
| version-based evolution and avoid unnecessary deployment delays. | deployment delays, and supports continuous version-based evolution. | |||
| 3. Network-Visible Information about QUIC Flows | 3. Network-Visible Information about QUIC Flows | |||
| This section addresses the different kinds of observations and | This section addresses the different kinds of observations and | |||
| inferences that can be made about QUIC flows by a passive observer in | inferences that can be made about QUIC flows by a passive observer in | |||
| the network based on the wire image in Section 2. Here we assume a | the network based on the wire image in Section 2. Here we assume a | |||
| bidirectional observer (one that can see packets in both directions | bidirectional observer (one that can see packets in both directions | |||
| in the sequence in which they are carried on the wire) unless noted, | in the sequence in which they are carried on the wire) unless noted, | |||
| but typically without access to any keying information. | but typically without access to any keying information. | |||
| 3.1. Identifying QUIC Traffic | 3.1. Identifying QUIC Traffic | |||
| The QUIC wire image is not specifically designed to be | The QUIC wire image is not specifically designed to be | |||
| distinguishable from other UDP traffic by a passive observer in the | distinguishable from other UDP traffic by a passive observer in the | |||
| network. | network. While certain QUIC applications may be heuristically | |||
| identifiable on a per-application basis, there is no general method | ||||
| for distinguishing QUIC traffic from otherwise-unclassifiable UDP | ||||
| traffic on a given link. Any unrecognized UDP traffic may therefore | ||||
| be QUIC traffic. | ||||
| At the time of writing, two application bindings for QUIC have been | At the time of writing, two application bindings for QUIC have been | |||
| published or adopted by the IETF: HTTP/3 [QUIC-HTTP] and DNS over | published or adopted by the IETF: HTTP/3 [QUIC-HTTP] and DNS over | |||
| Dedicated QUIC Connections [I-D.ietf-dprive-dnsoquic]. These are | Dedicated QUIC Connections [I-D.ietf-dprive-dnsoquic]. These are | |||
| both known at the time of writing to have active Internet | both known at the time of writing to have active Internet | |||
| deployments, so an assumption that all QUIC traffic is HTTP/3 is not | deployments, so an assumption that all QUIC traffic is HTTP/3 is not | |||
| valid. HTTP/3 uses UDP port 443 by convention but various methods | valid. HTTP/3 uses UDP port 443 by convention but various methods | |||
| can be used to specify alternate port numbers. Simple assumptions | can be used to specify alternate port numbers. Simple assumptions | |||
| about whether a given flow is using QUIC based upon a UDP port number | about whether a given flow is using QUIC based upon a UDP port number | |||
| may therefore not hold; see also Section 5 of [RFC7605]. | may therefore not hold; see also Section 5 of [RFC7605]. | |||
| skipping to change at page 16, line 37 ¶ | skipping to change at page 17, line 37 ¶ | |||
| Note that subsequent Initial packets might contain a Destination | Note that subsequent Initial packets might contain a Destination | |||
| Connection ID other than the one used to generate the Initial secret. | Connection ID other than the one used to generate the Initial secret. | |||
| Therefore, attempts to decrypt these packets using the procedure | Therefore, attempts to decrypt these packets using the procedure | |||
| above might fail unless the Initial secret is retained by the | above might fail unless the Initial secret is retained by the | |||
| observer. | observer. | |||
| To determine the end of the packet header and find the start of the | To determine the end of the packet header and find the start of the | |||
| payload, the packet number length, the source connection ID length, | payload, the packet number length, the source connection ID length, | |||
| and the token length need to be extracted. The packet number length | and the token length need to be extracted. The packet number length | |||
| is defined by the seventh and eight bits of the header as described | is defined by the seventh and eight bits of the header as described | |||
| in Section 17.2 of [QUIC-TRANSPORT], but is obfuscated as described | in Section 17.2 of [QUIC-TRANSPORT], but is protected as described in | |||
| in Section 5.4 of [QUIC-TLS]. The source connection ID length is | Section 5.4 of [QUIC-TLS]. The source connection ID length is | |||
| specified in the byte after the destination connection ID. The token | specified in the byte after the destination connection ID. The token | |||
| length, which follows the source connection ID, is a variable-length | length, which follows the source connection ID, is a variable-length | |||
| integer as specified in Section 16 of [QUIC-TRANSPORT]. | integer as specified in Section 16 of [QUIC-TRANSPORT]. | |||
| After decryption, the client's Initial packet(s) can be parsed to | After decryption, the client's Initial packet(s) can be parsed to | |||
| detect the CRYPTO frame(s) that contains the TLS ClientHello, which | detect the CRYPTO frame(s) that contains the TLS ClientHello, which | |||
| then can be parsed similarly to TLS over TCP connections. Note that | then can be parsed similarly to TLS over TCP connections. Note that | |||
| there can be multiple CRYPTO frames spread out over one or more | there can be multiple CRYPTO frames spread out over one or more | |||
| Initial packets, and they might not be in order, so reassembling the | Initial packets, and they might not be in order, so reassembling the | |||
| CRYPTO stream by parsing offsets and lengths is required. Further, | CRYPTO stream by parsing offsets and lengths is required. Further, | |||
| skipping to change at page 29, line 36 ¶ | skipping to change at page 30, line 36 ¶ | |||
| * Mike Bishop | * Mike Bishop | |||
| * Nick Banks | * Nick Banks | |||
| * Thomas Fossati | * Thomas Fossati | |||
| * Sean Turner | * Sean Turner | |||
| 8. Acknowledgments | 8. Acknowledgments | |||
| Special thanks to last call reviewers Elwyn Davies, Barry Lieba, Al | ||||
| Morton, and Peter Saint-Andre. | ||||
| This work was partially supported by the European Commission under | This work was partially supported by the European Commission under | |||
| Horizon 2020 grant agreement no. 688421 Measurement and Architecture | Horizon 2020 grant agreement no. 688421 Measurement and Architecture | |||
| for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat | for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat | |||
| for Education, Research, and Innovation under contract no. 15.0268. | for Education, Research, and Innovation under contract no. 15.0268. | |||
| This support does not imply endorsement. | This support does not imply endorsement. | |||
| 9. References | 9. References | |||
| 9.1. Normative References | 9.1. Normative References | |||
| skipping to change at page 30, line 27 ¶ | skipping to change at page 31, line 27 ¶ | |||
| August 2020, <https://www.rfc-editor.org/rfc/rfc8811>. | August 2020, <https://www.rfc-editor.org/rfc/rfc8811>. | |||
| [DPLPMTUD] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. | [DPLPMTUD] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. | |||
| Völker, "Packetization Layer Path MTU Discovery for | Völker, "Packetization Layer Path MTU Discovery for | |||
| Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, | Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, | |||
| September 2020, <https://www.rfc-editor.org/rfc/rfc8899>. | September 2020, <https://www.rfc-editor.org/rfc/rfc8899>. | |||
| [I-D.ietf-dprive-dnsoquic] | [I-D.ietf-dprive-dnsoquic] | |||
| Huitema, C., Dickinson, S., and A. Mankin, "DNS over | Huitema, C., Dickinson, S., and A. Mankin, "DNS over | |||
| Dedicated QUIC Connections", Work in Progress, Internet- | Dedicated QUIC Connections", Work in Progress, Internet- | |||
| Draft, draft-ietf-dprive-dnsoquic-10, 28 February 2022, | Draft, draft-ietf-dprive-dnsoquic-11, 21 March 2022, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-dprive- | <https://datatracker.ietf.org/doc/html/draft-ietf-dprive- | |||
| dnsoquic-10>. | dnsoquic-11>. | |||
| [I-D.ietf-tsvwg-transport-encrypt] | [I-D.ietf-tsvwg-transport-encrypt] | |||
| Fairhurst, G. and C. Perkins, "Considerations around | Fairhurst, G. and C. Perkins, "Considerations around | |||
| Transport Header Confidentiality, Network Operations, and | Transport Header Confidentiality, Network Operations, and | |||
| the Evolution of Internet Transport Protocols", Work in | the Evolution of Internet Transport Protocols", Work in | |||
| Progress, Internet-Draft, draft-ietf-tsvwg-transport- | Progress, Internet-Draft, draft-ietf-tsvwg-transport- | |||
| encrypt-21, 20 April 2021, | encrypt-21, 20 April 2021, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg- | <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg- | |||
| transport-encrypt-21>. | transport-encrypt-21>. | |||
| skipping to change at page 31, line 36 ¶ | skipping to change at page 32, line 36 ¶ | |||
| May 2021, <https://www.rfc-editor.org/rfc/rfc9002>. | May 2021, <https://www.rfc-editor.org/rfc/rfc9002>. | |||
| [QUIC-TIMEOUT] | [QUIC-TIMEOUT] | |||
| Roskind, J., "QUIC (IETF-88 TSV Area Presentation)", 7 | Roskind, J., "QUIC (IETF-88 TSV Area Presentation)", 7 | |||
| November 2013, | November 2013, | |||
| <https://www.ietf.org/proceedings/88/slides/slides-88- | <https://www.ietf.org/proceedings/88/slides/slides-88- | |||
| tsvarea-10.pdf>. | tsvarea-10.pdf>. | |||
| [QUIC_LB] Duke, M., Banks, N., and C. Huitema, "QUIC-LB: Generating | [QUIC_LB] Duke, M., Banks, N., and C. Huitema, "QUIC-LB: Generating | |||
| Routable QUIC Connection IDs", Work in Progress, Internet- | Routable QUIC Connection IDs", Work in Progress, Internet- | |||
| Draft, draft-ietf-quic-load-balancers-12, 11 February | Draft, draft-ietf-quic-load-balancers-13, 28 March 2022, | |||
| 2022, <https://datatracker.ietf.org/doc/html/draft-ietf- | <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | |||
| quic-load-balancers-12>. | load-balancers-13>. | |||
| [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, | [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, | |||
| DOI 10.17487/RFC1191, November 1990, | DOI 10.17487/RFC1191, November 1990, | |||
| <https://www.rfc-editor.org/rfc/rfc1191>. | <https://www.rfc-editor.org/rfc/rfc1191>. | |||
| [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", | [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", | |||
| RFC 1812, DOI 10.17487/RFC1812, June 1995, | RFC 1812, DOI 10.17487/RFC1812, June 1995, | |||
| <https://www.rfc-editor.org/rfc/rfc1812>. | <https://www.rfc-editor.org/rfc/rfc1812>. | |||
| [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., | [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., | |||
| End of changes. 24 change blocks. | ||||
| 86 lines changed or deleted | 99 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||