< 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/