draft-ietf-quic-manageability-06.txt   draft-ietf-quic-manageability-07.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 July 2020 Google Expires: 9 January 2021 Google
6 January 2020 8 July 2020
Manageability of the QUIC Transport Protocol Manageability of the QUIC Transport Protocol
draft-ietf-quic-manageability-06 draft-ietf-quic-manageability-07
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 July 2020. This Internet-Draft will expire on 9 January 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 33 skipping to change at page 2, line 33
3.3. Application Identification . . . . . . . . . . . . . . . 14 3.3. Application Identification . . . . . . . . . . . . . . . 14
3.4. Flow association . . . . . . . . . . . . . . . . . . . . 14 3.4. Flow association . . . . . . . . . . . . . . . . . . . . 14
3.5. Flow teardown . . . . . . . . . . . . . . . . . . . . . . 14 3.5. Flow teardown . . . . . . . . . . . . . . . . . . . . . . 14
3.6. Flow symmetry measurement . . . . . . . . . . . . . . . . 15 3.6. Flow symmetry measurement . . . . . . . . . . . . . . . . 15
3.7. Round-Trip Time (RTT) Measurement . . . . . . . . . . . . 15 3.7. Round-Trip Time (RTT) Measurement . . . . . . . . . . . . 15
3.7.1. Measuring initial RTT . . . . . . . . . . . . . . . . 15 3.7.1. Measuring initial RTT . . . . . . . . . . . . . . . . 15
3.7.2. Using the Spin Bit for Passive RTT Measurement . . . 15 3.7.2. Using the Spin Bit for Passive RTT Measurement . . . 15
4. Specific Network Management Tasks . . . . . . . . . . . . . . 17 4. Specific Network Management Tasks . . . . . . . . . . . . . . 17
4.1. Stateful treatment of QUIC traffic . . . . . . . . . . . 17 4.1. Stateful treatment of QUIC traffic . . . . . . . . . . . 17
4.2. Passive network performance measurement and 4.2. Passive network performance measurement and
troubleshooting . . . . . . . . . . . . . . . . . . . . . 17 troubleshooting . . . . . . . . . . . . . . . . . . . . . 18
4.3. Server cooperation with load balancers . . . . . . . . . 18 4.3. Server cooperation with load balancers . . . . . . . . . 18
4.4. DDoS Detection and Mitigation . . . . . . . . . . . . . . 18 4.4. DDoS Detection and Mitigation . . . . . . . . . . . . . . 18
4.5. Distinguishing acknowledgment traffic . . . . . . . . . . 18 4.5. UDP Policing . . . . . . . . . . . . . . . . . . . . . . 19
4.6. QoS support and ECMP . . . . . . . . . . . . . . . . . . 19 4.6. Distinguishing acknowledgment traffic . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 4.7. QoS support and ECMP . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 28 skipping to change at page 4, line 28
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 is focused on the protocol as presently defined in
[QUIC-TRANSPORT] and [QUIC-TLS], and will change to track those [QUIC-TRANSPORT] and [QUIC-TLS]. Non-invariant parts of the wire
documents. image as described herein and in those documents cannot be used to
identify QUIC as a protocol, and cannot be relied upon to infer
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 indicates which type of header is first bit of the QUIC header us the Header Form bit, and indicates
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
destination connection IDs for grouping packets belonging to the same destination connection IDs for grouping packets belonging to the same
flow. The definition and location of these fields in the QUIC long flow. The definition and location of these fields in the QUIC long
header are invariant for future versions of QUIC, although future header are invariant for future versions of QUIC, although future
versions of QUIC may provide additional fields in the long header versions of QUIC may provide additional fields in the long header
[QUIC-INVARIANTS]. [QUIC-INVARIANTS].
Short headers are used after connection establishment, and contain Short headers are used after connection establishment, and contain
only an optional destination connection ID and the spin bit for RTT only an optional destination connection ID and the spin bit for RTT
measurement. measurement.
The following information is exposed in QUIC packet headers: The following information is exposed in QUIC packet headers:
* demux bit: the second most significant bit of the first octet * "fixed bit": the second most significant bit of the first octet
every QUIC packet of the current version is set to 1, for most QUIC packets of the current version is currently set to 1,
demultiplexing with other UDP-encapsulated protocols. for demultiplexing with other UDP-encapsulated protocols.
* latency spin bit: the third most significant bit of first octet in * latency spin bit: the third most significant bit of first octet in
the short packet header. The spin bit is set by endpoints such the short packet header. The spin bit is set by endpoints such
that tracking edge transitions can be used to passively observe that tracking edge transitions can be used to passively observe
end-to-end RTT. See Section 3.7.2 for further details. end-to-end RTT. See Section 3.7.2 for further 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 bit. Header types correspond to stages following the Header Form and fixed bits. Header types correspond
of the handshake; see Section 17.2 of [QUIC-TRANSPORT]. to stages of the handshake; see Section 17.2 of [QUIC-TRANSPORT]
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.
* 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
skipping to change at page 5, line 48 skipping to change at page 5, line 49
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 and Version Negotiation packets are not encrypted or obfuscated Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation
in any way. For other kinds of packets, other information in the (Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or
packet headers is cryptographically obfuscated: obfuscated in any way. For other kinds of packets, other information
in the packet headers is cryptographically obfuscated:
* packet number: Most packets (with the exception of Version * packet number: All packets except Version Negotiation and Retry
Negotiation and Retry packets) have an associated packet number; packets have an associated packet number; however, this packet
however, this packet number is encrypted, and therefore not of use number is encrypted, and therefore not of use to on-path
to on-path observers. The offset of the packet number is encoded observers. The offset of the packet number is encoded in the
in the header for packets with long headers, while it is implicit header for packets with long headers, while it is implicit
(depending on Destination Connection ID length) in short header (depending on Destination Connection ID length) in short header
packets. The length of the packet number is cryptographically packets. The length of the packet number is cryptographically
obfuscated. obfuscated.
* 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, supporting key rotation. The the keys used to encrypt the packet, supporting key rotation. The
Key Phase bit is cryptographically obfuscated. Key Phase bit is cryptographically obfuscated.
2.2. Coalesced Packets 2.2. Coalesced Packets
skipping to change at page 12, line 33 skipping to change at page 12, line 33
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.
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. distinguishable from other UDP traffic.
The only application binding currently defined for QUIC is HTTP The only application binding defined by the IETF QUIC WG is HTTP/3
[QUIC-HTTP]. HTTP over QUIC uses UDP port 443 by default, although [QUIC-HTTP] at the time of this writing; however, many other
URLs referring to resources available over HTTP over QUIC may specify applications are currently being defined and deployed over QUIC, so
alternate port numbers. Simple assumptions about whether a given an assumption that all QUIC traffic is HTTP/3 is not valid. HTTP
flow is using QUIC based upon a UDP port number may therefore not over QUIC uses UDP port 443 by default, although URLs referring to
hold; see also [RFC7605] section 5. resources available over HTTP over QUIC may specify alternate port
numbers. Simple assumptions about whether a given flow is using QUIC
based upon a UDP port number may therefore not hold; see also
[RFC7605] section 5.
While the second most significant bit (0x40) of the first octet is While the second most significant bit (0x40) of the first octet is
always set to 1 in QUIC packets of the current version, this is not a set to 1 in most QUIC packets of the current version (see
recommended method of recognizing QUIC traffic, as it only provides Section 2.1), this method of recognizing QUIC traffic is NOT
one bit of information and is quite prone to collide with UDP-based RECOMMENDED. First, it only provides one bit of information and is
protocols other than those that this static bit is meant to allow quite prone to collide with UDP-based protocols other than those that
multiplexing with. this static bit is meant to allow multiplexing with. Second, this
feature of the wire image is not invariant [QUIC-INVARIANTS] and may
change in future versions of the protocol, or even be negotiated
after handshake via future transport parameters.
3.1.1. Identifying Negotiated Version 3.1.1. Identifying Negotiated Version
An in-network observer assuming that a set of packets belongs to a An in-network observer assuming that a set of packets belongs to a
QUIC flow can infer the version number in use by observing the QUIC flow can infer the version number in use by observing the
handshake: an Initial packet with a given version from a client to handshake: an Initial packet with a given version from a client to
which a server responds with an Initial packet with the same version which a server responds with an Initial packet with the same version
implies acceptance of that version. implies acceptance of that version.
Negotiated version cannot be identified for flows for which a Negotiated version cannot be identified for flows for which a
handshake is not observed, such as in the case of connection handshake is not observed, such as in the case of connection
migration; however, these flows can be associated with flows for migration; however, these flows can be associated with flows for
which a version has been identified; see Section 3.4. which a version has been identified; see Section 3.4.
In the rest of this section, we discuss only packets belonging to This document focuses on QUIC Version 1, and this section applies
Version 1 QUIC flows, and assume that these packets have been only to packets belonging to Version 1 QUIC flows; for purposes of
on-path observation, it assumes that these packets have been
identified as such through the observation of a version negotiation. identified as such through the observation of a version negotiation.
3.1.2. Rejection of Garbage Traffic 3.1.2. Rejection of Garbage Traffic
A related question is whether a first packet of a given flow on known A related question is whether a first packet of a given flow on known
QUIC-associated port is a valid QUIC packet, in order to support in- QUIC-associated port is a valid QUIC packet, in order to support in-
network filtering of garbage UDP packets (reflection attacks, random network filtering of garbage UDP packets (reflection attacks, random
backscatter). While heuristics based on the first byte of the packet backscatter). While heuristics based on the first byte of the packet
(packet type) could be used to separate valid from invalid first (packet type) could be used to separate valid from invalid first
packet types, the deployment of such heuristics is not recommended, packet types, the deployment of such heuristics is not recommended,
skipping to change at page 14, line 46 skipping to change at page 14, line 46
The connection ID value should be treated as opaque; see Section 4.3 The connection ID value should be treated as opaque; see Section 4.3
for caveats regarding connection ID selection at servers. for caveats regarding connection ID selection at servers.
3.5. Flow teardown 3.5. Flow teardown
QUIC does not expose the end of a connection; the only indication to QUIC does not expose the end of a connection; the only indication to
on-path devices that a flow has ended is that packets are no longer on-path devices that a flow has ended is that packets are no longer
observed. Stateful devices on path such as NATs and firewalls must observed. Stateful devices on path such as NATs and firewalls must
therefore use idle timeouts to determine when to drop state for QUIC therefore use idle timeouts to determine when to drop state for QUIC
flows. flows, see further section Section 4.1.
Changes to this behavior have been discussed in the working group,
but there is no current proposal to implement these changes: see
https://github.com/quicwg/base-drafts/issues/602.
3.6. Flow symmetry measurement 3.6. Flow symmetry measurement
QUIC explicitly exposes which side of a connection is a client and QUIC explicitly exposes which side of a connection is a client and
which side is a server during the handshake. In addition, the which side is a server during the handshake. In addition, the
symmetry of a flow (whether primarily client-to-server, primarily symmetry of a flow (whether primarily client-to-server, primarily
server-to-client, or roughly bidirectional, as input to basic traffic server-to-client, or roughly bidirectional, as input to basic traffic
classification techniques) can be inferred through the measurement of classification techniques) can be inferred through the measurement of
data rate in each direction. While QUIC traffic is protected and data rate in each direction. While QUIC traffic is protected and
ACKs may be padded, padding is not required. ACKs may be padded, padding is not required.
skipping to change at page 17, line 29 skipping to change at page 17, line 29
4.1. Stateful treatment of QUIC traffic 4.1. Stateful treatment of QUIC traffic
Stateful treatment of QUIC traffic (e.g., at a firewall or NAT Stateful treatment of QUIC traffic (e.g., at a firewall or NAT
middlebox) is possible through QUIC traffic and version middlebox) is possible through QUIC traffic and version
identification (Section 3.1) and observation of the handshake for identification (Section 3.1) and observation of the handshake for
connection confirmation (Section 3.2). The lack of any visible end- connection confirmation (Section 3.2). The lack of any visible end-
of-flow signal (Section 3.5) means that this state must be purged of-flow signal (Section 3.5) means that this state must be purged
either through timers or through least-recently-used eviction, either through timers or through least-recently-used eviction,
depending on application requirements. depending on application requirements.
[RFC4787] recommends a 2 minute timeout interval for UDP, however,
often timer are lower in the range of 15 to 30 second. In constrast
[RFC5382] recommends a timeout of more than 2 hours for TCP, given
TCP is a connection-oriented protocol with well defined closure
semantics. For network devices that are QUIC-aware, it is
recommended to also use longer timeouts for QUIC traffic, as QUIC is
connection-oriented and as such a handshake packet from the server
indicates the willingness of the server to communicate with the
client.
The QUIC header optionally contains a Connection ID which can be used The QUIC header optionally contains a Connection ID which can be used
as additional entropy beyond the 5-tuple, if needed. The QUIC as additional entropy beyond the 5-tuple, if needed. The QUIC
handshake needs to be observed in order to understand whether the handshake needs to be observed in order to understand whether the
Connection ID is present and what length it has. However, Connection Connection ID is present and what length it has. However, Connection
IDs may be renegotiated during a connection, and this renegotiation IDs may be renegotiated during a connection, and this renegotiation
is not visible to the path. Keying state off the Connection ID may is not visible to the path. Keying state off the Connection ID may
therefore cause undetectable and unrecoverable loss of state in the therefore cause undetectable and unrecoverable loss of state in the
middle of a connection. Use of Connection ID specifically middle of a connection. Use of Connection ID specifically
discouraged for NAT applications. discouraged for NAT applications.
skipping to change at page 18, line 16 skipping to change at page 18, line 24
In the case of content distribution networking architectures In the case of content distribution networking architectures
including load balancers, the connection ID provides a way for the including load balancers, the connection ID provides a way for the
server to signal information about the desired treatment of a flow to server to signal information about the desired treatment of a flow to
the load balancers. Guidance on assigning connection IDs is given in the load balancers. Guidance on assigning connection IDs is given in
[QUIC-APPLICABILITY]. [QUIC-APPLICABILITY].
4.4. DDoS Detection and Mitigation 4.4. DDoS Detection and Mitigation
Current practices in detection and mitigation of Distributed Denial Current practices in detection and mitigation of Distributed Denial
of Service (DDoS) attacks generally involve passive measurement using of Service (DDoS) attacks generally involves classification of
network flow data [RFC7011], classification of traffic into "good" incoming traffic (as packets, flows, or some other aggregate) into
(productive) and "bad" (DoS) flows, and filtering of these bad flows "good" (productive) and "bad" (DDoS) traffic, then differential
in a "scrubbing" environment. Key to successful DDoS mitigation is treatment of this traffic to forward only good traffic, to the extent
efficient classification of this traffic. possible. This operation is often done in a separate specialized
mitigation environment through which all traffic is filtered; a
generalized architecture for separation of concerns in mitigation is
given in [DOTS-ARCH].
Limited first-packet garbage detection as in Section 3.1.2 and Key to successful DDoS mitigation is efficient classification of this
stateful tracking of QUIC traffic as in Section 4.1 above can be used traffic in the mitigation environment. Limited first-packet garbage
in this classification step. detection as in Section 3.1.2 and stateful tracking of QUIC traffic
as in Section 4.1 above may be useful during classification.
Note that the use of a connection ID to support connection migration Note that the use of a connection ID to support connection migration
renders 5-tuple based filtering insufficient, and requires more state renders 5-tuple based filtering insufficient and requires more state
to be maintained by DDoS defense systems, and linkability resistance to be maintained by DDoS defense systems. For the common case of NAT
in connection ID update mechanisms means that a connection ID aware rebinding, DDoS defense systems can detect a change in client's
DDoS defense system must have the same information about flows as the endpoint address by linking flows based on the first 8 bytes of the
load balancer. server's connection IDs, provided the server is using at least 8-
bytes-long connection IDs. QUIC's linkability resistance ensures
that a deliberate connection migration is accompanied by a change in
the connection ID and necessitate that connection ID aware DDoS
defense system must have the same information about connection IDs as
the load balancer [I-D.ietf-quic-load-balancers]. This may be
complicated where mitigation and load balancing environments are
logically separate.
However, it is questionable if connection migrations needs to be It is questionable whether connection migrations must be supported
supported in a DDOS attack. If the connection migration is not during a DDoS attack. If the connection migration is not visible to
visible to the network that performs the DDoS detection, an active, the network that performs the DDoS detection, an active, migrated
migrated QUIC connection may be blocked by such a system under QUIC connection may be blocked by such a system under attack. As
attack. However, a defense system might simply rely on the fast soon as the connection blocking is detected by the client, the client
resumption mechanism provided by QUIC. may rely on the fast resumption mechanism provided by QUIC. When
clients migrate to a new path, they should be prepared for the
migration to fail and attempt to reconnect quickly.
4.5. Distinguishing acknowledgment traffic 4.5. UDP Policing
Today, UDP is the most prevalent DDoS vector, since it is easy for
compromised non-admin applications to send a flood of large UDP
packets (while with TCP the attacker gets throttled by the congestion
controller) or to craft reflection and amplification attacks.
Networks should therefore be prepared for UDP flood attacks on ports
used for QUIC traffic. One possible response to this threat is to
police UDP traffic on the network, allocating a fixed portion of the
network capacity to UDP and blocking UDP datagram over that cap.
The recommended way to police QUIC packets is to either drop them all
or to throttle them based on the hash of the UDP datagram's source
and destination addresses, blocking a portion of the hash space that
corresponds to the fraction of UDP traffic one wishes to drop. When
the handshake is blocked, QUIC-capable applications may failover to
TCP (at least applications using well-known UDP ports). However,
blindly blocking a significant fraction of QUIC packets will allow
many QUIC handshakes to complete, preventing a TCP failover, but the
connections will suffer from severe packet loss.
4.6. Distinguishing acknowledgment traffic
Some deployed in-network functions distinguish pure-acknowledgment Some deployed in-network functions distinguish pure-acknowledgment
(ACK) packets from packets carrying upper-layer data in order to (ACK) packets from packets carrying upper-layer data in order to
attempt to enhance performance, for example by queueing ACKs attempt to enhance performance, for example by queueing ACKs
differently or manipulating ACK signaling. Distinguishing ACK differently or manipulating ACK signaling. Distinguishing ACK
packets is trivial in TCP, but not supported by QUIC, since packets is trivial in TCP, but not supported by QUIC, since
acknowledgment signaling is carried inside QUIC's encrypted payload, acknowledgment signaling is carried inside QUIC's encrypted payload,
and ACK manipulation is impossible. Specifically, heuristics and ACK manipulation is impossible. Specifically, heuristics
attempting to distinguish ACK-only packets from payload-carrying attempting to distinguish ACK-only packets from payload-carrying
packets based on packet size are likely to fail, and are emphatically packets based on packet size are likely to fail, and are emphatically
NOT RECOMMENDED. NOT RECOMMENDED.
4.6. QoS support and ECMP 4.7. QoS support and ECMP
[EDITOR'S NOTE: this is a bit speculative; keep?] [EDITOR'S NOTE: this is a bit speculative; keep?]
QUIC does not provide any additional information on requirements on QUIC does not provide any additional information on requirements on
Quality of Service (QoS) provided from the network. QUIC assumes Quality of Service (QoS) provided from the network. QUIC assumes
that all packets with the same 5-tuple {dest addr, source addr, that all packets with the same 5-tuple {dest addr, source addr,
protocol, dest port, source port} will receive similar network protocol, dest port, source port} will receive similar network
treatment. That means all stream that are multiplexed over the same treatment. That means all stream that are multiplexed over the same
QUIC connection require the same network treatment and are handled by QUIC connection require the same network treatment and are handled by
the same congestion controller. If differential network treatment is the same congestion controller. If differential network treatment is
desired, multiple QUIC connections to the same server might be used, desired, multiple QUIC connections to the same server might be used,
given that establishing a new connection using 0-RTT support is cheap given that establishing a new connection using 0-RTT support is cheap
and fast. and fast.
skipping to change at page 20, line 34 skipping to change at page 21, line 23
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.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]
Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and
R. Compton, "Distributed-Denial-of-Service Open Threat
Signaling (DOTS) Architecture", Work in Progress,
Internet-Draft, draft-ietf-dots-architecture-18, 6 March
2020, <http://www.ietf.org/internet-drafts/draft-ietf-
dots-architecture-18.txt>.
[I-D.ietf-quic-load-balancers]
Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC
Connection IDs", Work in Progress, Internet-Draft, draft-
ietf-quic-load-balancers-02, 9 March 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic-load-
balancers-02.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-05, 5 July 2019, draft-ietf-quic-applicability-06, 6 January 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic- <http://www.ietf.org/internet-drafts/draft-ietf-quic-
applicability-05.txt>. applicability-06.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-24, 4 November 2019, <http://www.ietf.org/ quic-http-29, 9 June 2020, <http://www.ietf.org/internet-
internet-drafts/draft-ietf-quic-http-24.txt>. drafts/draft-ietf-quic-http-29.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-07, 11 September 2019, <http://www.ietf.org/ invariants-09, 9 June 2020, <http://www.ietf.org/internet-
internet-drafts/draft-ietf-quic-invariants-07.txt>. drafts/draft-ietf-quic-invariants-09.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-24, Work in Progress, Internet-Draft, draft-ietf-quic-tls-29,
3 November 2019, <http://www.ietf.org/internet-drafts/ 9 June 2020, <http://www.ietf.org/internet-drafts/draft-
draft-ietf-quic-tls-24.txt>. ietf-quic-tls-29.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-24, 3 November 2019, draft-ietf-quic-transport-29, 9 June 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic- <http://www.ietf.org/internet-drafts/draft-ietf-quic-
transport-24.txt>. transport-29.txt>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, DOI 10.17487/RFC5382, October 2008,
<https://www.rfc-editor.org/info/rfc5382>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928, "Increasing TCP's Initial Window", RFC 6928,
DOI 10.17487/RFC6928, April 2013, DOI 10.17487/RFC6928, April 2013,
<https://www.rfc-editor.org/info/rfc6928>. <https://www.rfc-editor.org/info/rfc6928>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"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-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS
"Encrypted Server Name Indication for TLS 1.3", Work in Encrypted Client Hello", Work in Progress, Internet-Draft,
Progress, Internet-Draft, draft-ietf-tls-esni-05, 4 draft-ietf-tls-esni-07, 1 June 2020, <http://www.ietf.org/
November 2019, <http://www.ietf.org/internet-drafts/draft- internet-drafts/draft-ietf-tls-esni-07.txt>.
ietf-tls-esni-05.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. 34 change blocks. 
92 lines changed or deleted 161 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/