draft-ietf-quic-manageability-07.txt   draft-ietf-quic-manageability-08.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: 9 January 2021 Google Expires: 6 May 2021 Google
8 July 2020 2 November 2020
Manageability of the QUIC Transport Protocol Manageability of the QUIC Transport Protocol
draft-ietf-quic-manageability-07 draft-ietf-quic-manageability-08
Abstract Abstract
This document discusses manageability of the QUIC transport protocol, This document discusses manageability of the QUIC transport protocol,
focusing on caveats impacting network operations involving QUIC focusing on caveats impacting network operations involving QUIC
traffic. Its intended audience is network operators, as well as traffic. Its intended audience is network operators, as well as
content providers that rely on the use of QUIC-aware middleboxes, content providers that rely on the use of QUIC-aware middleboxes,
e.g. for load balancing. e.g. for load balancing.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 9 January 2021. This Internet-Draft will expire on 6 May 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 13 skipping to change at page 2, line 13
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . 6
2.4. The QUIC handshake . . . . . . . . . . . . . . . . . . . 6 2.4. The QUIC handshake . . . . . . . . . . . . . . . . . . . 7
2.5. Integrity Protection of the Wire Image . . . . . . . . . 11 2.5. Integrity Protection of the Wire Image . . . . . . . . . 11
2.6. Connection ID and Rebinding . . . . . . . . . . . . . . . 11 2.6. Connection ID and Rebinding . . . . . . . . . . . . . . . 11
2.7. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 11 2.7. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 12
2.8. Version Negotiation and Greasing . . . . . . . . . . . . 11 2.8. Version Negotiation and Greasing . . . . . . . . . . . . 12
3. Network-visible information about QUIC flows . . . . . . . . 12 3. Network-visible information about QUIC flows . . . . . . . . 12
3.1. Identifying QUIC traffic . . . . . . . . . . . . . . . . 12 3.1. Identifying QUIC traffic . . . . . . . . . . . . . . . . 13
3.1.1. Identifying Negotiated Version . . . . . . . . . . . 13 3.1.1. Identifying Negotiated Version . . . . . . . . . . . 13
3.1.2. Rejection of Garbage Traffic . . . . . . . . . . . . 13 3.1.2. Rejection of Garbage Traffic . . . . . . . . . . . . 14
3.2. Connection confirmation . . . . . . . . . . . . . . . . . 13 3.2. Connection confirmation . . . . . . . . . . . . . . . . . 14
3.3. Application Identification . . . . . . . . . . . . . . . 14 3.3. Application Identification . . . . . . . . . . . . . . . 14
3.4. Flow association . . . . . . . . . . . . . . . . . . . . 14 3.3.1. Extracting Server Name Indication (SNI)
3.5. Flow teardown . . . . . . . . . . . . . . . . . . . . . . 14 Information . . . . . . . . . . . . . . . . . . . . . 15
3.6. Flow symmetry measurement . . . . . . . . . . . . . . . . 15 3.4. Flow association . . . . . . . . . . . . . . . . . . . . 16
3.7. Round-Trip Time (RTT) Measurement . . . . . . . . . . . . 15 3.5. Flow teardown . . . . . . . . . . . . . . . . . . . . . . 16
3.7.1. Measuring initial RTT . . . . . . . . . . . . . . . . 15 3.6. Flow symmetry measurement . . . . . . . . . . . . . . . . 16
3.7.2. Using the Spin Bit for Passive RTT Measurement . . . 15 3.7. Round-Trip Time (RTT) Measurement . . . . . . . . . . . . 17
4. Specific Network Management Tasks . . . . . . . . . . . . . . 17 3.7.1. Measuring initial RTT . . . . . . . . . . . . . . . . 17
4.1. Stateful treatment of QUIC traffic . . . . . . . . . . . 17 3.7.2. Using the Spin Bit for Passive RTT Measurement . . . 17
4. Specific Network Management Tasks . . . . . . . . . . . . . . 19
4.1. Stateful treatment of QUIC traffic . . . . . . . . . . . 19
4.2. Passive network performance measurement and 4.2. Passive network performance measurement and
troubleshooting . . . . . . . . . . . . . . . . . . . . . 18 troubleshooting . . . . . . . . . . . . . . . . . . . . . 19
4.3. Server cooperation with load balancers . . . . . . . . . 18 4.3. Server cooperation with load balancers . . . . . . . . . 20
4.4. DDoS Detection and Mitigation . . . . . . . . . . . . . . 18 4.4. DDoS Detection and Mitigation . . . . . . . . . . . . . . 20
4.5. UDP Policing . . . . . . . . . . . . . . . . . . . . . . 19 4.5. UDP Policing . . . . . . . . . . . . . . . . . . . . . . 21
4.6. Distinguishing acknowledgment traffic . . . . . . . . . . 19 4.6. Distinguishing acknowledgment traffic . . . . . . . . . . 21
4.7. QoS support and ECMP . . . . . . . . . . . . . . . . . . 19 4.7. QoS support and ECMP . . . . . . . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 21 9.1. Distinguishing IETF QUIC and Google QUIC Versions . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 21 9.2. Extracting the CRYPTO frame . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
QUIC [QUIC-TRANSPORT] is a new transport protocol currently under QUIC [QUIC-TRANSPORT] is a new transport protocol currently under
development in the IETF QUIC working group, focusing on support of development in the IETF QUIC working group, focusing on support of
semantics as needed for HTTP/2 [QUIC-HTTP]. Based on current semantics as needed for HTTP/2 [QUIC-HTTP]. Based on current
deployment practices, QUIC is encapsulated in UDP and encrypted by deployment practices, QUIC is encapsulated in UDP and encrypted by
default. The current version of QUIC integrates TLS [QUIC-TLS] to default. The current version of QUIC integrates TLS [QUIC-TLS] to
encrypt all payload data and most control information. encrypt all payload data and most control information.
skipping to change at page 4, line 27 skipping to change at page 4, line 27
that forward QUIC packets. Here, we are concerned primarily with the that forward QUIC packets. Here, we are concerned primarily with the
unencrypted part of QUIC's wire image [WIRE-IMAGE], which we define unencrypted part of QUIC's wire image [WIRE-IMAGE], which we define
as the information available in the packet header in each QUIC as the information available in the packet header in each QUIC
packet, and the dynamics of that information. Since QUIC is a packet, and the dynamics of that information. Since QUIC is a
versioned protocol, the wire image of the header format can also versioned protocol, the wire image of the header format can also
change from version to version. However, at least the mechanism by change from version to version. However, at least the mechanism by
which a receiver can determine which version is used and the meaning which a receiver can determine which version is used and the meaning
and location of fields used in the version negotiation process is and location of fields used in the version negotiation process is
invariant [QUIC-INVARIANTS]. invariant [QUIC-INVARIANTS].
This document is focused on the protocol as presently defined in This document describes only version 1 the QUIC protocol, whose wire
[QUIC-TRANSPORT] and [QUIC-TLS]. Non-invariant parts of the wire image is fully defined in [QUIC-TRANSPORT] and [QUIC-TLS]. Note that
image as described herein and in those documents cannot be used to features of the wire image described herein and in those documents
identify QUIC as a protocol, and cannot be relied upon to infer may change in future versions of the protocol, and cannot be used to
behavior of future versions of QUIC. identify QUIC as a protocol or to infer the behavior of future
versions of QUIC. Section 9.1 provides non-normative guidance on the
identification of QUIC version 1 packets compared to other deployed
versions at the date if publication.
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 us the Header Form bit, and indicates first bit of the QUIC header us the Header Form bit, and indicates
which type of header is present. which type of header is present.
The long header exposes more information. It is used during The long header exposes more information. It is used during
connection establishment, including version negotiation, retry, and connection establishment, including version negotiation, retry, and
0-RTT data. It contains a version number, as well as source and 0-RTT data. It contains a version number, as well as source and
skipping to change at page 5, line 24 skipping to change at page 5, line 30
* 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.
* version number: the version number present in the long header, and * version number: the version number present in the long header, and
identifies the version used for that packet. Note that during identifies the version used for that packet. Note that during
Version Negotiation (see Section 2.8, and Section 17.2.1 of Version Negotiation (see Section 2.8, and Section 17.2.1 of
[QUIC-TRANSPORT], the version number field has a special value [QUIC-TRANSPORT], 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. packet. QUIC versions that start with 0xff are IETF drafts. QUIC
versions that start with 0x0000 are reserved for IETF consensus
documents, for example the QUIC version 1 is expected to use
version 0x00000001.
* source and destination connection ID: short and long packet * source and destination connection ID: short and long packet
headers carry a destination connection ID, a variable-length field headers carry a destination connection ID, a variable-length field
that can be used to identify the connection associated with a QUIC that can be used to identify the connection associated with a QUIC
packet, for load-balancing and NAT rebinding purposes; see packet, for load-balancing and NAT rebinding purposes; see
Section 4.3 and Section 2.6. Long packet headers additionally Section 4.3 and Section 2.6. Long packet headers additionally
carry a source connection ID. The source connection ID carry a source connection ID. The source connection ID
corresponds to the destination connection ID the source would like corresponds to the destination connection ID the source would like
to have on packets sent to it, and is only present on long packet to have on packets sent to it, and is only present on long packet
headers. On long header packets, the length of the connection IDs headers. On long header packets, the length of the connection IDs
skipping to change at page 8, line 29 skipping to change at page 8, line 40
| QUIC CRYPTO frame header | | | QUIC CRYPTO frame header | |
+----------------------------------------------------------+ | +----------------------------------------------------------+ |
| TLS Client Hello (incl. TLS SNI) | | | TLS Client Hello (incl. TLS SNI) | |
+----------------------------------------------------------+ | +----------------------------------------------------------+ |
| QUIC PADDING frame | | | QUIC PADDING frame | |
+----------------------------------------------------------+<-+ +----------------------------------------------------------+<-+
Figure 2: Typical 1-RTT QUIC Client Hello datagram pattern Figure 2: Typical 1-RTT QUIC Client Hello datagram pattern
The Client Hello datagram exposes version number, source and The Client Hello datagram exposes version number, source and
destination connection IDs, and information in the TLS Client Hello destination connection IDs in the clear. Information in the TLS
message, including any TLS Server Name Indication (SNI) present, in Client Hello frame, including any TLS Server Name Indication (SNI)
the clear. The QUIC PADDING frame shown here may be present to present, is obfuscated using the Initial secret. The QUIC PADDING
ensure the Client Hello datagram has a minimum size of 1200 octets, frame shown here may be present to ensure the Client Hello datagram
to mitigate the possibility of handshake amplification. Note that has a minimum size of 1200 octets, to mitigate the possibility of
the location of PADDING is implementation-dependent, and PADDING handshake amplification. Note that the location of PADDING is
frames may not appear in the Initial packet in a coalesced packet. implementation-dependent, and PADDING frames may not appear in the
Initial packet in a coalesced packet.
+------------------------------------------------------------+ +------------------------------------------------------------+
| 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 | |
+------------------------------------------------------------+ | +------------------------------------------------------------+ |
| TLS Server Hello | | | TLS Server Hello | |
+------------------------------------------------------------+ | +------------------------------------------------------------+ |
skipping to change at page 9, line 27 skipping to change at page 9, line 27
+------------------------------------------------------------+ | +------------------------------------------------------------+ |
| encrypted payload (presumably CRYPTO frames) | | | encrypted payload (presumably CRYPTO frames) | |
+------------------------------------------------------------+<-+ +------------------------------------------------------------+<-+
| QUIC short header | | QUIC short header |
+------------------------------------------------------------+ +------------------------------------------------------------+
| 1-RTT encrypted payload | | 1-RTT encrypted payload |
+------------------------------------------------------------+ +------------------------------------------------------------+
Figure 3: Typical QUIC Server Hello datagram pattern Figure 3: Typical QUIC Server Hello datagram pattern
The Server Hello datagram exposes version number, source and The Server Hello datagram also exposes version number, source and
destination connection IDs, and information in the TLS Server Hello destination connection IDs and information in the TLS Server Hello
message. message which is obfuscated 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 Hello Initial) | | | QUIC ACK frame (acknowledging Server Hello Initial) | |
+------------------------------------------------------------+<-+ +------------------------------------------------------------+<-+
| QUIC long header (type = Handshake, Version, DCID, SCID) (Length) | QUIC long header (type = Handshake, Version, DCID, SCID) (Length)
+------------------------------------------------------------+ | +------------------------------------------------------------+ |
skipping to change at page 11, line 31 skipping to change at page 11, line 31
ensuring that related flows are appropriately balanced together; and ensuring that related flows are appropriately balanced together; and
to allow rebinding of a connection after one of the endpoint's to allow rebinding of a connection after one of the endpoint's
addresses changes - usually the client's, in the case of the HTTP addresses changes - usually the client's, in the case of the HTTP
binding. Client and server negotiate connection IDs during the binding. Client and server negotiate connection IDs during the
handshake; typically, however, only the server will request a handshake; typically, however, only the server will request a
connection ID for the lifetime of the connection. Connection IDs for connection ID for the lifetime of the connection. Connection IDs for
either endpoint may change during the lifetime of a connection, with either endpoint may change during the lifetime of a connection, with
the new connection ID being negotiated via encrypted frames. See the new connection ID being negotiated via encrypted frames. See
Section 5.1 of [QUIC-TRANSPORT]. Section 5.1 of [QUIC-TRANSPORT].
Server-generated connection IDs should seek to obscure any encoding,
of routing identities or any other information. Exposing the server
mapping would allow linkage of multiple IP addresses to the same host
if the server also supports migration. Furthermore, this opens an
attack vector on specific servers or pools.
The best way to obscure an encoding is to appear random to observers,
which is most rigorously achieved with encryption. Even when
encrypted, a scheme could embed the unencrypted length of the
Connection ID in the Connection ID itself, instead of remembering it,
e.g. by using the first few bits to indicate a certain size of a
well-known set of possible sizes with multiple values that indicate
the same size but are selected randomly.
[QUIC_LB] further specified possible algorithms to generate
Connection IDs at load balancers.
2.7. Packet Numbers 2.7. Packet Numbers
The packet number field is always present in the QUIC packet header; The packet number field is always present in the QUIC packet header;
however, it is always encrypted. The encryption key for packet however, it is always encrypted. The encryption key for packet
number protection on handshake packets sent before cryptographic number protection on handshake packets sent before cryptographic
context establishment is specific to the QUIC version, while packet context establishment is specific to the QUIC version, while packet
number protection on subsequent packets uses secrets derived from the number protection on subsequent packets uses secrets derived from the
end-to-end cryptographic context. Packet numbers are therefore not end-to-end cryptographic context. Packet numbers are therefore not
part of the wire image that is visible to on-path observers. part of the wire image that is visible to on-path observers.
skipping to change at page 14, line 21 skipping to change at page 15, line 5
Application-Layer Protocol Negotiation (ALPN) [RFC7301], by which the Application-Layer Protocol Negotiation (ALPN) [RFC7301], by which the
client exposes the names of application-layer protocols it supports; client exposes the names of application-layer protocols it supports;
an observer can deduce that one of those protocols will be used if an observer can deduce that one of those protocols will be used if
the connection continues. the connection continues.
Work is currently underway in the TLS working group to encrypt the Work is currently underway in the TLS working group to encrypt the
SNI in TLS 1.3 [TLS-ESNI]. If used with QUIC, this would make SNI- SNI in TLS 1.3 [TLS-ESNI]. If used with QUIC, this would make SNI-
based application identification impossible through passive based application identification impossible through passive
measurement. measurement.
3.3.1. Extracting Server Name Indication (SNI) Information
If the SNI is not encrypted it can be derived from the QUIC Initial
packet by calculating the Initial Secret to decrypt the packet
payload and parse the QUIC CRYPTO Frame containing the TLS
ClientHello.
As both the initial salt for the Initial Secret as well as CRYPTO
frame itself are version-specific, the first step is always to parse
the version number (second to sixth byte of the long header). Note
that only long header packets carry the version number, so it is
necessary to also check the if first bit of the QUIC packet is set to
1, indicating a long header.
Note, that proprietary QUIC versions, that have been deployed before
standardization, might not set the first bit in a QUIC long header
packets to 1. To parse these versions example code is provided in
the appendix (see Section 9.1), however, it is expected that these
versions will gradually disappear over time.
When the version has been identified as QUIC version 1, the packet
type needs to be verified as an Initial packet by checking that the
third and fourth bit of the header are both set to 0. Then the
Client Destination Connection ID needs to be extracted to calculate
the Initial Secret together with the version specific initial salt,
as described in [QUIC-TLS]. The length of the connection ID is
indicated in the 6th byte of the header followed by the connection ID
itself.
To determine the end of the header and find the start of the payload
further the packet number length, the source connection ID length, as
well as the token length need to be extracted. The packet number
length is defined by the seventh and eight bits of the header as
described in section 17.2. of [QUIC-TRANSPORT]. The source
connection ID length is specified in the byte after the destination
connection ID. And the token length, which follows the source
connection ID, is a variable length integer as specified in section
16 of [QUIC-TRANSPORT].
Finally after decryption, the Initial Client packet can be parsed to
detect the CRYPTO frame that contains the TLS Client Hello, which
then can be respectively parsed similar as for all other TLS
connections. The Initial client packet may contain other frames, so
the first byte of each frame need to be checked to identify the frame
type and the skip over the frame. Note that the length of the frames
is dependent on the frame type. Usually for QUIC version 1, the
packet is expected to only carry the CRYPTO frame and optionally
padding frames. However, padding which is one byte of zeros, may
also occur before or after the CRYPTO frame.
3.4. Flow association 3.4. Flow association
The QUIC Connection ID (see Section 2.6) is designed to allow an on- The QUIC Connection ID (see Section 2.6) is designed to allow an on-
path device such as a load-balancer to associate two flows as path device such as a load-balancer to associate two flows as
identified by five-tuple when the address and port of one of the identified by five-tuple when the address and port of one of the
endpoints changes; e.g. due to NAT rebinding or server IP address endpoints changes; e.g. due to NAT rebinding or server IP address
migration. An observer keeping flow state can associate a connection migration. An observer keeping flow state can associate a connection
ID with a given flow, and can associate a known flow with a new flow ID with a given flow, and can associate a known flow with a new flow
when when observing a packet sharing a connection ID and one endpoint when when observing a packet sharing a connection ID and one endpoint
address (IP address and port) with the known flow. address (IP address and port) with the known flow.
skipping to change at page 20, line 41 skipping to change at page 22, line 31
Supporting manageability of QUIC traffic inherently involves Supporting manageability of QUIC traffic inherently involves
tradeoffs with the confidentiality of QUIC's control information; tradeoffs with the confidentiality of QUIC's control information;
this entire document is therefore security-relevant. this entire document is therefore security-relevant.
7. Contributors 7. Contributors
Dan Druta contributed text to Section 4.4. Igor Lubashev contributed Dan Druta contributed text to Section 4.4. Igor Lubashev contributed
text to Section 4.3 on the use of the connection ID for load text to Section 4.3 on the use of the connection ID for load
balancing. Marcus Ilhar contributed text to Section 3.7 on the use balancing. Marcus Ilhar contributed text to Section 3.7 on the use
of the spin bit. of the spin bit. The pseudo provided in the appendix is based on
input provided by David Schinazi.
8. Acknowledgments 8. Acknowledgments
Thanks to Martin Thomson and Martin Duke for contributing by
reviewing and providing text proposals.
This work is partially supported by the European Commission under This work is 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. Appendix
9.1. Normative References
This appendix uses the following conventions: array[i] - one byte at
index i of array array[i:j] - subset of array starting with index i
(inclusive) up to j-1 (inclusive) array[i:] - subset of array
starting with index i (inclusive) up to the end of the array
9.1. Distinguishing IETF QUIC and Google QUIC Versions
This section contains algorithms that allows parsing versions from
both Google QUIC and IETF QUIC. These mechanisms will become
irrelevant when IETF QUIC is fully deployed and Google QUIC is
deprecated.
Note that other than this appendix, nothing in this document applies
to Google QUIC. And the purpose of this appendix is merely to
distinguish IETF QUIC from any versions of Google QUIC.
Conceptually, a Google QUIC version is an opaque 32bit field. When
we refer to a version with four printable characters, we use its
ASCII representation: for example, Q050 refers to {'Q', '0', '5',
'0'} which is equal to {0x51, 0x30, 0x35, 0x30}. Otherwise, we use
its hexadecimal representation: for example, 0xff00001d refers to
{0xff, 0x00, 0x00, 0x1d}.
QUIC versions that start with 'Q' or 'T' followed by three digits are
Google QUIC versions. Versions up to and including 43 are documented
by <https://docs.google.com/document/d/
1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/preview>. Versions
Q046, Q050, T050, and T051 are not fully documented, but this
appendix should contain enough information to allow parsing Client
Hellos for those versions.
To extract the version number itself, one needs to look at the first
byte of the QUIC packet, in other words the first byte of the UDP
payload.
first_byte = packet[0]
first_byte_bit1 = ((first_byte & 0x80) != 0)
first_byte_bit2 = ((first_byte & 0x40) != 0)
first_byte_bit3 = ((first_byte & 0x20) != 0)
first_byte_bit4 = ((first_byte & 0x10) != 0)
first_byte_bit5 = ((first_byte & 0x08) != 0)
first_byte_bit6 = ((first_byte & 0x04) != 0)
first_byte_bit7 = ((first_byte & 0x02) != 0)
first_byte_bit8 = ((first_byte & 0x01) != 0)
if (first_byte_bit1) {
version = packet[1:5]
} else if (first_byte_bit5 && !first_byte_bit2) {
if (!first_byte_bit8) {
abort("Packet without version")
}
if (first_byte_bit5) {
version = packet[9:13]
} else {
version = packet[5:9]
}
} else {
abort("Packet without version")
}
9.2. Extracting the CRYPTO frame
counter = 0
while (payload[counter] == 0) {
counter += 1
}
first_nonzero_payload_byte = payload[counter]
fnz_payload_byte_bit3 = ((first_nonzero_payload_byte & 0x20) != 0)
if (first_nonzero_payload_byte != 0x06) {
abort("Unexpected frame")
}
if (payload[counter+1] != 0x00) {
abort("Unexpected crypto stream offset")
}
counter += 2
if ((payload[counter] & 0xc0) == 0) {
crypto_data_length = payload[counter]
counter += 1
} else {
crypto_data_length = payload[counter:counter+2]
counter += 2
}
crypto_data = payload[counter:counter+crypto_data_length]
ParseTLS(crypto_data)
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 10.2. Informative References
[Ding2015] Ding, H. and M. Rabinovich, "TCP Stretch Acknowledgments [Ding2015] Ding, H. and M. Rabinovich, "TCP Stretch Acknowledgments
and Timestamps - Findings and Impliciations for Passive and Timestamps - Findings and Impliciations for Passive
RTT Measurement (ACM Computer Communication Review)", July RTT Measurement (ACM Computer Communication Review)", July
2015, <http://www.sigcomm.org/sites/default/files/ccr/ 2015, <http://www.sigcomm.org/sites/default/files/ccr/
papers/2015/July/0000000-0000002.pdf>. papers/2015/July/0000000-0000002.pdf>.
[DOTS-ARCH] [DOTS-ARCH]
Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and
R. Compton, "Distributed-Denial-of-Service Open Threat R. Compton, "Distributed-Denial-of-Service Open Threat
Signaling (DOTS) Architecture", Work in Progress, Signaling (DOTS) Architecture", Work in Progress,
Internet-Draft, draft-ietf-dots-architecture-18, 6 March Internet-Draft, draft-ietf-dots-architecture-18, 6 March
2020, <http://www.ietf.org/internet-drafts/draft-ietf- 2020, <http://www.ietf.org/internet-drafts/draft-ietf-
dots-architecture-18.txt>. dots-architecture-18.txt>.
[I-D.ietf-quic-load-balancers] [I-D.ietf-quic-load-balancers]
Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC
Connection IDs", Work in Progress, Internet-Draft, draft- Connection IDs", Work in Progress, Internet-Draft, draft-
ietf-quic-load-balancers-02, 9 March 2020, ietf-quic-load-balancers-05, 30 October 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic-load- <http://www.ietf.org/internet-drafts/draft-ietf-quic-load-
balancers-02.txt>. balancers-05.txt>.
[IPIM] Allman, M., Beverly, R., and B. Trammell, "In-Protocol [IPIM] Allman, M., Beverly, R., and B. Trammell, "In-Protocol
Internet Measurement (arXiv preprint 1612.02902)", 9 Internet Measurement (arXiv preprint 1612.02902)", 9
December 2016, <https://arxiv.org/abs/1612.02902>. December 2016, <https://arxiv.org/abs/1612.02902>.
[QUIC-APPLICABILITY] [QUIC-APPLICABILITY]
Kuehlewind, M. and B. Trammell, "Applicability of the QUIC Kuehlewind, M. and B. Trammell, "Applicability of the QUIC
Transport Protocol", Work in Progress, Internet-Draft, Transport Protocol", Work in Progress, Internet-Draft,
draft-ietf-quic-applicability-06, 6 January 2020, draft-ietf-quic-applicability-07, 8 July 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic- <http://www.ietf.org/internet-drafts/draft-ietf-quic-
applicability-06.txt>. applicability-07.txt>.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., "Hypertext Transfer Protocol Version 3 Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-29, 9 June 2020, <http://www.ietf.org/internet- quic-http-32, 20 October 2020, <http://www.ietf.org/
drafts/draft-ietf-quic-http-29.txt>. internet-drafts/draft-ietf-quic-http-32.txt>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
Work in Progress, Internet-Draft, draft-ietf-quic- Work in Progress, Internet-Draft, draft-ietf-quic-
invariants-09, 9 June 2020, <http://www.ietf.org/internet- invariants-11, 24 September 2020, <http://www.ietf.org/
drafts/draft-ietf-quic-invariants-09.txt>. internet-drafts/draft-ietf-quic-invariants-11.txt>.
[QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
Work in Progress, Internet-Draft, draft-ietf-quic-tls-29, Work in Progress, Internet-Draft, draft-ietf-quic-tls-32,
9 June 2020, <http://www.ietf.org/internet-drafts/draft- 20 October 2020, <http://www.ietf.org/internet-drafts/
ietf-quic-tls-29.txt>. draft-ietf-quic-tls-32.txt>.
[QUIC-TRANSPORT] [QUIC-TRANSPORT]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft, and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-29, 9 June 2020, draft-ietf-quic-transport-32, 20 October 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic- <http://www.ietf.org/internet-drafts/draft-ietf-quic-
transport-29.txt>. transport-32.txt>.
[QUIC_LB] Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC
Connection IDs", Work in Progress, Internet-Draft, draft-
ietf-quic-load-balancers-05, 30 October 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic-load-
balancers-05.txt>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>. 2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, DOI 10.17487/RFC5382, October 2008, RFC 5382, DOI 10.17487/RFC5382, October 2008,
<https://www.rfc-editor.org/info/rfc5382>. <https://www.rfc-editor.org/info/rfc5382>.
skipping to change at page 23, line 11 skipping to change at page 27, line 42
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7605] Touch, J., "Recommendations on Using Assigned Transport [RFC7605] Touch, J., "Recommendations on Using Assigned Transport
Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605,
August 2015, <https://www.rfc-editor.org/info/rfc7605>. August 2015, <https://www.rfc-editor.org/info/rfc7605>.
[TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS [TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft, Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-07, 1 June 2020, <http://www.ietf.org/ draft-ietf-tls-esni-08, 16 October 2020,
internet-drafts/draft-ietf-tls-esni-07.txt>. <http://www.ietf.org/internet-drafts/draft-ietf-tls-esni-
08.txt>.
[TMA-QOF] Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data [TMA-QOF] Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data
Integrity Signals for Passive Measurement (in Proc. TMA Integrity Signals for Passive Measurement (in Proc. TMA
2014)", April 2014. 2014)", April 2014.
[WIRE-IMAGE] [WIRE-IMAGE]
Trammell, B. and M. Kuehlewind, "The Wire Image of a Trammell, B. and M. Kuehlewind, "The Wire Image of a
Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April
2019, <https://www.rfc-editor.org/info/rfc8546>. 2019, <https://www.rfc-editor.org/info/rfc8546>.
 End of changes. 29 change blocks. 
67 lines changed or deleted 244 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/