draft-ietf-quic-applicability-07.txt   draft-ietf-quic-applicability-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
Applicability of the QUIC Transport Protocol Applicability of the QUIC Transport Protocol
draft-ietf-quic-applicability-07 draft-ietf-quic-applicability-08
Abstract Abstract
This document discusses the applicability of the QUIC transport This document discusses the applicability of the QUIC transport
protocol, focusing on caveats impacting application protocol protocol, focusing on caveats impacting application protocol
development and deployment over QUIC. Its intended audience is development and deployment over QUIC. Its intended audience is
designers of application protocol mappings to QUIC, and implementors designers of application protocol mappings to QUIC, and implementors
of these application protocols. of these application protocols.
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 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. The Necessity of Fallback . . . . . . . . . . . . . . . . . . 3 2. The Necessity of Fallback . . . . . . . . . . . . . . . . . . 3
3. Zero RTT . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Zero RTT . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Thinking in Zero RTT . . . . . . . . . . . . . . . . . . 4 3.1. Thinking in Zero RTT . . . . . . . . . . . . . . . . . . 4
3.2. Here There Be Dragons . . . . . . . . . . . . . . . . . . 4 3.2. Here There Be Dragons . . . . . . . . . . . . . . . . . . 4
3.3. Session resumption versus Keep-alive . . . . . . . . . . 5 3.3. Session resumption versus Keep-alive . . . . . . . . . . 5
4. Use of Streams . . . . . . . . . . . . . . . . . . . . . . . 6 4. Use of Streams . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Stream versus Flow Multiplexing . . . . . . . . . . . . . 7 4.1. Stream versus Flow Multiplexing . . . . . . . . . . . . . 8
4.2. Prioritization . . . . . . . . . . . . . . . . . . . . . 7 4.2. Prioritization . . . . . . . . . . . . . . . . . . . . . 8
4.3. Flow Control Deadlocks . . . . . . . . . . . . . . . . . 7 4.3. Flow Control Deadlocks . . . . . . . . . . . . . . . . . 8
5. Packetization and Latency . . . . . . . . . . . . . . . . . . 9 5. Packetization and Latency . . . . . . . . . . . . . . . . . . 10
6. Port Selection and Application Endpoint Discovery . . . . . . 9 6. Port Selection and Application Endpoint Discovery . . . . . . 10
7. Connection Migration . . . . . . . . . . . . . . . . . . . . 10 7. Connection Migration . . . . . . . . . . . . . . . . . . . . 11
8. Connection closure . . . . . . . . . . . . . . . . . . . . . 10 8. Connection closure . . . . . . . . . . . . . . . . . . . . . 12
9. Information exposure and the Connection ID . . . . . . . . . 11 9. Information exposure and the Connection ID . . . . . . . . . 13
9.1. Server-Generated Connection ID . . . . . . . . . . . . . 12 9.1. Server-Generated Connection ID . . . . . . . . . . . . . 13
9.2. Mitigating Timing Linkability with Connection ID 9.2. Mitigating Timing Linkability with Connection ID
Migration . . . . . . . . . . . . . . . . . . . . . . . . 12 Migration . . . . . . . . . . . . . . . . . . . . . . . . 13
9.3. Using Server Retry for Redirection . . . . . . . . . . . 12 9.3. Using Server Retry for Redirection . . . . . . . . . . . 14
10. Use of Versions and Cryptographic Handshake . . . . . . . . . 13 10. Use of Versions and Cryptographic Handshake . . . . . . . . . 14
11. Enabling New Versions . . . . . . . . . . . . . . . . . . . . 13 11. Enabling New Versions . . . . . . . . . . . . . . . . . . . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 13. Security Considerations . . . . . . . . . . . . . . . . . . . 16
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
16.1. Normative References . . . . . . . . . . . . . . . . . . 15 16.1. Normative References . . . . . . . . . . . . . . . . . . 16
16.2. Informative References . . . . . . . . . . . . . . . . . 16 16.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
QUIC [QUIC] is a new transport protocol currently under development QUIC [QUIC] is a new transport protocol providing a number of
in the IETF quic working group, focusing on support of semantics as advanced features. While initially designed for the HTTP use case,
needed for HTTP/2 [QUIC-HTTP] such as stream-multiplexing to avoid like most transports it is intended for use with a much wider variety
head-of-line blocking. Based on current deployment practices, QUIC of applications. QUIC is encapsulated in UDP. The version of QUIC
is encapsulated in UDP. The version of QUIC that is currently under that is currently under development will integrate TLS 1.3 [TLS13] to
development will integrate TLS 1.3 [TLS13] to encrypt all payload encrypt all payload data and most control information. HTTP
data and most control information. operating over QUIC is known as HTTP/3.
This document provides guidance for application developers that want This document provides guidance for application developers that want
to use the QUIC protocol without implementing it on their own. This to use the QUIC protocol without implementing it on their own. This
includes general guidance for application use of HTTP/2 over QUIC as includes general guidance for applications operating over HTTP/3 or
well as the use of other application layer protocols over QUIC. For directly over QUIC. For specific guidance on how to integrate HTTP/3
specific guidance on how to integrate HTTP/2 with QUIC, see with QUIC, see [QUIC-HTTP].
[QUIC-HTTP].
In the following sections we discuss specific caveats to QUIC's In the following sections we discuss specific caveats to QUIC's
applicability, and issues that application developers must consider applicability, and issues that application developers must consider
when using QUIC as a transport for their application. when using QUIC as a transport for their application.
1.1. Notational Conventions 1.1. Notational Conventions
The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this
document. It's not shouting; when these words are capitalized, they document. It's not shouting; when these words are capitalized, they
have a special meaning as defined in [RFC2119]. have a special meaning as defined in [RFC2119].
skipping to change at page 3, line 41 skipping to change at page 3, line 34
fall back to some other transport protocol. This fallback SHOULD fall back to some other transport protocol. This fallback SHOULD
provide TLS 1.3 or equivalent cryptographic protection, if available, provide TLS 1.3 or equivalent cryptographic protection, if available,
in order to keep fallback from being exploited as a downgrade attack. in order to keep fallback from being exploited as a downgrade attack.
In the case of HTTP, this fallback is TLS 1.3 over TCP. In the case of HTTP, this fallback is TLS 1.3 over TCP.
These applications must operate, perhaps with impaired functionality, These applications must operate, perhaps with impaired functionality,
in the absence of features provided by QUIC not present in the in the absence of features provided by QUIC not present in the
fallback protocol. For fallback to TLS over TCP, the most obvious fallback protocol. For fallback to TLS over TCP, the most obvious
difference is that TCP does not provide stream multiplexing and difference is that TCP does not provide stream multiplexing and
therefore stream multiplexing would need to be implemented in the therefore stream multiplexing would need to be implemented in the
application layer if needed. Further, TCP without the TCP Fast Open application layer if needed.
extension does not support 0-RTT session resumption. TCP Fast Open
can be requested by the connection initiator but might no be Further, TCP implementations and network paths often do not support
supported by the far end or could be blocked on the network path. the Fast Open option, which is analogous to 0-RTT session resumption.
Even if Fast Open successfully operates end-to-end, it is limited to
a single packet of payload, unlike QUIC 0-RTT.
Note that there is some evidence of middleboxes blocking SYN data Note that there is some evidence of middleboxes blocking SYN data
even if TFO was successfully negotiated (see [PaaschNanog]). even if TFO was successfully negotiated (see [PaaschNanog]).
Any fallback mechanism is likely to impose a degradation of Any fallback mechanism is likely to impose a degradation of
performance; however, fallback MUST not silently violate the performance; however, fallback MUST not silently violate the
application's expectation of confidentiality or integrity of its application's expectation of confidentiality or integrity of its
payload data. payload data.
Moreover, while encryption (in this case TLS) is inseparably Moreover, while encryption (in this case TLS) is inseparably
integrated with QUIC, TLS negotiation over TCP can be blocked. In integrated with QUIC, TLS negotiation over TCP can be blocked. In
skipping to change at page 4, line 43 skipping to change at page 4, line 43
Retransmission or (malicious) replay of data contained in 0-RTT Retransmission or (malicious) replay of data contained in 0-RTT
resumption packets could cause the server side to receive two copies resumption packets could cause the server side to receive two copies
of the same data. This is further described in [HTTP-RETRY]. Data of the same data. This is further described in [HTTP-RETRY]. Data
sent during 0-RTT resumption also cannot benefit from perfect forward sent during 0-RTT resumption also cannot benefit from perfect forward
secrecy (PFS). secrecy (PFS).
Data in the first flight sent by the client in a connection Data in the first flight sent by the client in a connection
established with 0-RTT MUST be idempotent (as specified in section established with 0-RTT MUST be idempotent (as specified in section
2.1 in [QUIC-TLS]). Applications MUST be designed, and their data 2.1 in [QUIC-TLS]). Applications MUST be designed, and their data
MUST be framed, such that multiple reception of idempotent data is MUST be framed, such that multiple reception of idempotent data is
recognized as such by the receiverApplications that cannot treat data recognized as such by the receiver. Applications that cannot treat
that may appear in a 0-RTT connection establishment as idempotent data that may appear in a 0-RTT connection establishment as
MUST NOT use 0-RTT establishment. For this reason the QUIC transport idempotent MUST NOT use 0-RTT establishment. For these reason the
SHOULD provide an interface for the application to indicate if 0-RTT QUIC transport SHOULD provide some or all of the following interfaces
support is in general desired or a way to indicate whether data is to applications:
idempotent, whether PFS is a hard requirement for the application,
and/or whether rejected 0-RTT dgitata should be retransmitted or * indicate if 0-RTT support is in general desired, which implies
withdrawn. that lack of PFS is acceptable for some data;
* an indication when 0RTT data for both egress and ingress, so that
both sender and receiver understand the properties of the
communication channel when the data is sent; and/or
* whether rejected 0-RTT data should be retransmitted or withdrawn.
Some TLS implementations may offer replay protection, which may
mitigate some of these issues.
3.3. Session resumption versus Keep-alive 3.3. Session resumption versus Keep-alive
Because QUIC is encapsulated in UDP, applications using QUIC must Because QUIC is encapsulated in UDP, applications using QUIC must
deal with short idle timeouts. Deployed stateful middleboxes will deal with short network idle timeouts. Deployed stateful middleboxes
generally establish state for UDP flows on the first packet state, will generally establish state for UDP flows on the first packet
and keep state for much shorter idle periods than for TCP. According state, and keep state for much shorter idle periods than for TCP.
to a 2010 study ([Hatonen10]), UDP applications can assume that any [RFC5382] suggests a TCP idle period of at least 124 minutes, though
NAT binding or other state entry will be expired after just thirty there is not evidence of widespread implementation of this guideline
seconds of inactivity. in the literature. Short network timeout for UDP, however, is well-
documented. According to a 2010 study ([Hatonen10]), UDP
applications can assume that any NAT binding or other state entry can
expire after just thirty seconds of inactivity. Section 3.5 of
[RFC8085] further discusses keep-alive intervals for UDP: it requires
a minimum value of 15 seconds, but recommends larger values, or
omitting keepalive entirely.
A QUIC application has three strategies to deal with this issue: By using a Connection ID, QUIC is designed to be robust to NAT
address rebinding after a timeout. However, some QUIC connections
may not be robust to rebinding because the routing infrastructure (in
particular, load balancers) uses the address/port four-tuple to
direct traffic. Furthermore, middleboxes with functions other than
address translation may still affect the path. In particular,
firewalls will often not admit server traffic for which it has not
kept state for corresponding packets from the client.
A QUIC application has three strategies to deal with this issue by
adjusting idle periods (noting that idle periods and the network idle
timeout is distinct from the connection idle timeout, defined as the
minimum of the idle timeout parameter in Section 10.1 of [QUIC]):
* Ignore it, if the application-layer protocol consists only of * Ignore it, if the application-layer protocol consists only of
interactions with no or very short idle periods. interactions with no or very short idle periods, or the protocol's
resistance to NAT rebinding is sufficient.
* Ensure there are no long idle periods. * Ensure there are no long idle periods.
* Resume the session after a long idle period, using 0-RTT * Resume the session after a long idle period, using 0-RTT
resumption when appropriate. resumption when appropriate.
The first strategy is the easiest, but it only applies to certain The first strategy is the easiest, but it only applies to certain
applications. applications.
Either the server or the client in a QUIC application can send PING Either the server or the client in a QUIC application can send PING
frames as keep-alives, to prevent the connection and any on-path frames as keep-alives, to prevent the connection and any on-path
state from timing out. Recommendations for the use of keep-alives state from timing out. Recommendations for the use of keep-alives
are application specific, mainly depending on the latency are application specific, mainly depending on the latency
requirements and message frequency of the application. In this case, requirements and message frequency of the application. In this case,
the application mapping must specify whether the client or server is the application mapping must specify whether the client or server is
responsible for keeping the application alive. Note that sending responsible for keeping the application alive. While [Hatonen10]
PING frames more frequently than every 30 seconds over long idle suggests that 30 seconds might be a suitable value for the public
periods may result in a too much unproductive traffic and power usage Internet when a NAT is on path, larger values are preferable if the
for some situations. deployment can consistently survive NAT rebinding, or is known to be
in a controlled environments like e.g. data centres in order to lower
network and computational load. Sending PING frames more frequently
than every 30 seconds over long idle periods may result in excessive
unproductive traffic in some situations, and to unacceptable power
usage for power-constrained (mobile) devices. Additionally, time-
outs shorter than 30 seconds can make it harder to handle trasient
network interruptions, such as VM migration or coverage loss during
mobilty.
Alternatively, the client (but not the server) can use session Alternatively, the client (but not the server) can use session
resumption instead of sending keepalive traffic. In this case, a resumption instead of sending keepalive traffic. In this case, a
client that wants to send data to a server over a connection idle client that wants to send data to a server over a connection idle
longer than the server's idle timeout (available from the longer than the server's idle timeout (available from the
idle_timeout transport parameter) can simply reconnect. When idle_timeout transport parameter) can simply reconnect. When
possible, this reconnection can use 0-RTT session resumption, possible, this reconnection can use 0-RTT session resumption,
reducing the latency involved with restarting the connection. This reducing the latency involved with restarting the connection. This
of course only applies in cases in which 0-RTT data is safe, when the of course only applies in cases in which 0-RTT data is safe, when the
client is the restarting peer, and when the data to be sent is client is the restarting peer, and when the data to be sent is
skipping to change at page 6, line 16 skipping to change at page 6, line 49
on a per-application basis. However, in general applications should on a per-application basis. However, in general applications should
use keepalives only in circumstances where continued communication is use keepalives only in circumstances where continued communication is
highly likely; [QUIC-HTTP], for instance, recommends using PING highly likely; [QUIC-HTTP], for instance, recommends using PING
frames for keepalive only when a request is outstanding. frames for keepalive only when a request is outstanding.
4. Use of Streams 4. Use of Streams
QUIC's stream multiplexing feature allows applications to run QUIC's stream multiplexing feature allows applications to run
multiple streams over a single connection, without head-of-line multiple streams over a single connection, without head-of-line
blocking between streams, associated at a point in time with a single blocking between streams, associated at a point in time with a single
five-tuple. Stream data is carried within Frames, where one (UDP) five-tuple. Stream data is carried within Frames, where one QUIC
packet on the wire can carry one of multiple stream frames. packet on the wire can carry one or multiple stream frames.
Stream can be independently open and closed, gracefully or by error. Streams can be unidirectional or bidirectional, and a stream may be
If a critical stream for the application is closed, the application initiated either by client or server. Only the initiator of a
can generate respective error messages on the application layer to unidirectional stream can send data on it. Due to offset encoding
inform the other end or the higher layer and eventually indicate QUIC limitations, a stream can carry a maximum of 2^62-1 bytes in each
to reset the connection. QUIC, however, does not need to know which direction. In the presently unlikely event that this limit is
streams are critical, and does not provide an interface to reached by an application, the stream can simply be closed and
exceptional handling of any stream. There are special streams in replaced with a new one.
QUIC that are used for control on the QUIC connection, however, these
streams are not exposed to the application. Streams can be independently opened and closed, gracefully or by
error. An application can gracefully close the egress direction of a
stream by instructing QUIC to send a FIN bit in a STREAM frame. It
cannot gracefully close the ingress direction without a peer-
generated FIN, much like in TCP. However, an endpoint can abruptly
close either the ingress or egress direction; these actions are fully
independent of each other.
If a stream that is critical for an application is closed, the
application can generate respective error messages on the application
layer to inform the other end and/or the higher layer, and eventually
indicate QUIC to reset the connection. QUIC, however, does not need
to know which streams are critical, and does not provide an interface
for exceptional handling of any stream.
Mapping of application data to streams is application-specific and Mapping of application data to streams is application-specific and
described for HTTP/s in [QUIC-HTTP]. In general data that can be described for HTTP/3 in [QUIC-HTTP]. In general, data that can be
processed independently, and therefore would suffer from head of line processed independently, and therefore would suffer from head of line
blocking if forced to be received in order, should be transmitted blocking if forced to be received in order, should be transmitted
over different streams. If the application requires certain data to over separate streams. If the application requires certain data to
be received in order, the same stream should be used for that data. be received in order, that data should be sent on the same stream.
If there is a logical grouping of data chunks or messages, streams If there is a logical grouping of data chunks or messages, streams
can be reused, or a new stream can be opened for each chunk/message. can be reused, or a new stream can be opened for each chunk/message.
If one message is mapped to a single stream, resetting the stream to If one message is mapped to a single stream, resetting the stream to
expire an unacknowledged message can be used to emulate partial expire an unacknowledged message can be used to emulate partial
reliability on a message basis. If a QUIC receiver has maximum reliability on a message basis. If a QUIC receiver has maximum
allowed concurrent streams open and the sender on the other end allowed concurrent streams open and the sender on the other end
indicates that more streams are needed, it doesn't automatically lead indicates that more streams are needed, it doesn't automatically lead
to an increase of the maximum number of streams by the receiver. to an increase of the maximum number of streams by the receiver.
Therefore it can be valuable to expose maximum number of allowed, Therefore it can be valuable to expose maximum number of allowed,
currently open and currently used streams to the application to make currently open and currently used streams to the application to make
the mapping of data to streams dependent on this information. the mapping of data to streams dependent on this information.
Further, streams have a maximum number of bytes that can be sent on While a QUIC implementation must necessarily provide a way for an
one stream. This number is high enough (2^64) that this will usually application to send data on separate streams, it does not necessarily
not be reached with current applications. Applications that send expose stream identifiers to the application (see e.g. [QUIC-HTTP]
chunks of data over a very long period of time (such as days, months, section 6) either at the sender or receiver end, so applications
or years), should rather utilize the 0-RTT session resumption ability should not assume access to these identifiers.
provided by QUIC, than trying to maintain one connection open.
4.1. Stream versus Flow Multiplexing 4.1. Stream versus Flow Multiplexing
Streams are meaningful only to the application; since stream Streams are meaningful only to the application; since stream
information is carried inside QUIC's encryption boundary, no information is carried inside QUIC's encryption boundary, no
information about the stream(s) whose frames are carried by a given information about the stream(s) whose frames are carried by a given
packet is visible to the network. Therefore stream multiplexing is packet is visible to the network. Therefore stream multiplexing is
not intended to be used for differentiating streams in terms of not intended to be used for differentiating streams in terms of
network treatment. Application traffic requiring different network network treatment. Application traffic requiring different network
treatment SHOULD therefore be carried over different five-tuples treatment SHOULD therefore be carried over different five-tuples
skipping to change at page 9, line 12 skipping to change at page 10, line 12
streams with STOP_SENDING or RST_STREAM. Cancelling some streams streams with STOP_SENDING or RST_STREAM. Cancelling some streams
results in the connection being terminated in some protocols. results in the connection being terminated in some protocols.
5. Packetization and Latency 5. Packetization and Latency
QUIC provides an interface that provides multiple streams to the QUIC provides an interface that provides multiple streams to the
application; however, the application usually cannot control how data application; however, the application usually cannot control how data
transmitted over one stream is mapped into frames or how those frames transmitted over one stream is mapped into frames or how those frames
are bundled into packets. By default, QUIC will try to maximally are bundled into packets. By default, QUIC will try to maximally
pack packets with one or more stream data frames to minimize pack packets with one or more stream data frames to minimize
bandwidth consumption and computational costs (see section 8 of bandwidth consumption and computational costs (see section 13 of
[QUIC]). If there is not enough data available to fill a packet, [QUIC]). If there is not enough data available to fill a packet,
QUIC may even wait for a short time, to optimize bandwidth efficiency QUIC may even wait for a short time, to optimize bandwidth efficiency
instead of latency. This delay can either be pre-configured or instead of latency. This delay can either be pre-configured or
dynamically adjusted based on the observed sending pattern of the dynamically adjusted based on the observed sending pattern of the
application. If the application requires low latency, with only application. If the application requires low latency, with only
small chunks of data to send, it may be valuable to indicate to QUIC small chunks of data to send, it may be valuable to indicate to QUIC
that all data should be send out immediately. Alternatively, if the that all data should be send out immediately. Alternatively, if the
application expects to use a specific sending pattern, it can also application expects to use a specific sending pattern, it can also
provide a suggested delay to QUIC for how long to wait before bundle provide a suggested delay to QUIC for how long to wait before bundle
frames into a packet. frames into a packet.
skipping to change at page 10, line 29 skipping to change at page 11, line 29
Note that given the prevalence of the assumption in network Note that given the prevalence of the assumption in network
management practice that a port number maps unambiguously to an management practice that a port number maps unambiguously to an
application, the use of ports that cannot easily be mapped to a application, the use of ports that cannot easily be mapped to a
registered service name may lead to blocking or other interference by registered service name may lead to blocking or other interference by
network elements such as firewalls that rely on the port number for network elements such as firewalls that rely on the port number for
application identification. application identification.
7. Connection Migration 7. Connection Migration
QUIC supports connection migration. Even if lower-layer addresses QUIC supports connection migration by the client. If a lower-layer
(usually the 4-tuple of IP addresses and ports) changes, QUIC packets address changes, a QUIC endpoint can still associate packets with an
can still be associated with an existing connection based on the existing connection based on the Connection ID (see also Section 9)
Connection ID (see also section Section 9) in the QUIC header, if in the QUIC header, if present. This supports cases where address
present. This supports cases where address information changes due information changes, such as NAT rebinding, intentional change of the
to e.g. NAT rebinding or change of the local interface. Currently local interface, or based on an indication in the handshake of the
QUIC only supports failover cases. Only one "path" can be used at a server for a preferred address to be used. As such if the client is
time, and as soon as the new path is validated all traffic will be known or likely to sit behind a NAT, use of a connection ID for the
switched over to the next path. Of course if an endpoint decided to server is strongly recommended. A non-empty connection ID for the
not use the Connection ID in short packets (Zero-length Conn ID) for server is also strongly recommended when migration is supported.
a certain connection, migration is not supported for that direction
of the connection. Currently QUIC only supports failover cases. Only one "path" can be
used at a time, and only when the new path is validated all traffic
can be switched over to that new path. Path validation means that
the other endpoint in required to validate the new path before use in
order to avoid address spoofing attacks. Path validation takes at
least one RTT and congestion control will also be reset on path
migration. Therefore migration usually has a performance impact.
As long as the new path is not validated only probing packets can be
sent. However, the probing packets can be used measure path
characteristics as input for the switching decision or the congestion
controller on the new path.
Only the client can actively migrate. However, servers can indicate
during the handshake that they prefer to transfer the connection to a
different address after the handshake, e.g. to move from an address
that is shared by multiple servers to an address that is unique to
the server instance. The server can provide an IPv4 and an IPv6
address in a transport parameter during the TLS handshake and the
client can select between the two if both are provided. See also
Section 9.6 of [QUIC].
8. Connection closure 8. Connection closure
QUIC connections are closed either by expiration of an idle timeout QUIC connections are closed either by expiration of an idle timeout,
or by an explicit indication of the application that a connection as determined by transport parameters, or by an explicit indication
should be closed (immediate close). While data could still be of the application that a connection should be closed (immediate
received after the immediate close has been initiated by one endpoint close). While data could still be received after the immediate close
(for a limited time period), the expectation is that an immediate has been initiated by one endpoint (for a limited time period), the
close was negotiated at the application layer and therefore no expectation is that an immediate close was negotiated at the
additional data is expected from both sides. application layer and therefore no additional data is expected from
both sides.
An immidate close will emit an CONNECTION_CLOSE frame. This frames An immidate close will emit an CONNECTION_CLOSE frame. This frames
has two sets of types: one for QUIC internal problems that might lead has two sets of types: one for QUIC internal problems that might lead
to connection closure, and one for closures initiated by the to connection closure, and one for closures initiated by the
application. An application using QUIC can define application- application. An application using QUIC can define application-
specific error codes, e.g. see [QUIC-HTTP] section 8.1. In the case specific error codes, e.g. see [QUIC-HTTP] section 8.1. In the case
of a grateful shut-down initiated by the application after of a grateful shut-down initiated by the application after
application layer negotiation, a NO_ERROR code is expected. Further, application layer negotiation, a NO_ERROR code is expected. Further,
the CONNECTION_CLOSE frame provides an optional reason field, that the CONNECTION_CLOSE frame provides an optional reason field, that
can be used to append human-readable information to an error code. can be used to append human-readable information to an error code.
Note that QUIC RESET_STREAM and STOP_SENDING frames provide similar Note that QUIC RESET_STREAM and STOP_SENDING frames provide similar
capablities. Usually application error codes are defined to be capablities. Usually application error codes are defined to be
applicabile to all three frames. applicabile to all three frames.
Alternatively, a QUIC connection will be silently closed by each Alternatively, a QUIC connection can be silently closed by each
endpoint separately after an idle timeout. The idle timeout is endpoint separately after an idle timeout. If enabled as indicated
announce for each endpoint during connection established and should by a transport parameter in the handshake, the idle timeout is
be accessible by the application. If an application desires to keep announced for each endpoint during connection establishment and the
the connection open for longer than the announced timeout, it can effective value for this connection is the minimum of the two
send keep-alives messages. See {#resumption-v-keepalive} for further advertised values. An application therefore should be able to
guidance. configure its own maximum value as well as have access to the
computed minimum value for this connection. An application may
adjust the maximum idle timeout based on the number of open or
expected connections as shorter timeout values may free-up memory
more quickly. If an application desires to keep the connection open
for longer than the announced timeout, it can send keep-alives
messages, or a QUIC implementation may provide an option to defer the
time-out to avoid unnecessary load, as specified in Section 10.2.2 of
[QUIC]. See Section 3.3 for further guidance on keep-alives.
9. Information exposure and the Connection ID 9. Information exposure and the Connection ID
QUIC exposes some information to the network in the unencrypted part QUIC exposes some information to the network in the unencrypted part
of the header, either before the encryption context is established, of the header, either before the encryption context is established,
because the information is intended to be used by the network. QUIC because the information is intended to be used by the network. QUIC
has a long header that is used during connection establishment and has a long header that is used during connection establishment and
for other control processes, and a short header that may be used for for other control processes, and a short header that may be used for
data transmission in an established connection. While the long data transmission in an established connection. While the long
header always exposes some information (such as the version and header always exposes some information (such as the version and
Connection IDs), the short header exposes at most only a single Connection IDs), the short header exposes at most only a single
Connection ID. Connection ID.
Note that the Connection ID in the short header may be omitted. This Note that the Connection ID in the short header may be omitted. This
is a per-connection configuration option; if the Connection ID is not is a per-connection configuration option; if the Connection ID is not
present, then the peer omitting the connection ID will use the same present, then the peer omitting the connection ID needs to use the
local address for the lifetime of the connection. same local address for the lifetime of the connection and connection
migration is not supported for that direction of the connection.
9.1. Server-Generated Connection ID 9.1. Server-Generated Connection ID
QUIC supports a server-generated Connection ID, transmitted to the QUIC supports a server-generated Connection ID, transmitted to the
client during connection establishment (see Section 6.1 of [QUIC]). client during connection establishment (see Section 6.1 of [QUIC]).
Servers behind load balancers may need to change the Connection ID Servers behind load balancers may need to change the Connection ID
during the handshake, encoding the identity of the server or during the handshake, encoding the identity of the server or
information about its load balancing pool, in order to support information about its load balancing pool, in order to support
stateless load balancing. Once the server generates a Connection ID stateless load balancing. Once the server generates a Connection ID
that encodes its identity, every CDN load balancer would be able to that encodes its identity, every CDN load balancer would be able to
forward the packets to that server without retaining connection forward the packets to that server without retaining connection
state. state.
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.
9.2. Mitigating Timing Linkability with Connection ID Migration 9.2. Mitigating Timing Linkability with Connection ID Migration
While sufficiently robust connection ID generation schemes will While sufficiently robust connection ID generation schemes will
mitigate linkability issues, they do not provide full protection. mitigate linkability issues, they do not provide full protection.
Analysis of the lifetimes of six-tuples (source and destination Analysis of the lifetimes of six-tuples (source and destination
addresses as well as the migrated CID) may expose these links anyway. addresses as well as the migrated CID) may expose these links anyway.
In the limit where connection migration in a server pool is rare, it In the limit where connection migration in a server pool is rare, it
is trivial for an observer to associate two connection IDs. is trivial for an observer to associate two connection IDs.
Conversely, in the opposite limit where every server handles multiple Conversely, in the opposite limit where every server handles multiple
skipping to change at page 13, line 10 skipping to change at page 14, line 19
Connection ID in that packet and the client will retry by sending Connection ID in that packet and the client will retry by sending
another Client Initial packet with the server-selected Connection ID. another Client Initial packet with the server-selected Connection ID.
This mechanism can be used to redirect a connection to a different This mechanism can be used to redirect a connection to a different
server, e.g. due to performance reasons or when servers in a server server, e.g. due to performance reasons or when servers in a server
pool are upgraded gradually, and therefore may support different pool are upgraded gradually, and therefore may support different
versions of QUIC. In this case, it is assumed that all servers versions of QUIC. In this case, it is assumed that all servers
belonging to a certain pool are served in cooperation with load belonging to a certain pool are served in cooperation with load
balancers that forward the traffic based on the Connection ID. A balancers that forward the traffic based on the Connection ID. A
server can choose the Connection ID in the Server Retry packet such server can choose the Connection ID in the Server Retry packet such
that the load balancer will redirect the next Client Initial packet that the load balancer will redirect the next Client Initial packet
to a different server in that pool. to a different server in that pool. Alternatively the load balancer
can directly offer a Retry services as further described in
[QUIC-LB].
[RFC5077] Section 4 describes an example approach for constructing
TLS resumption tickets that can be also applied for validation
tokens, however, the use of more modern cryptographic algorithms is
highly recommended.
10. Use of Versions and Cryptographic Handshake 10. Use of Versions and Cryptographic Handshake
Versioning in QUIC may change the protocol's behavior completely, Versioning in QUIC may change the protocol's behavior completely,
except for the meaning of a few header fields that have been declared except for the meaning of a few header fields that have been declared
to be invariant [QUIC-INVARIANTS]. A version of QUIC with a higher to be invariant [QUIC-INVARIANTS]. A version of QUIC with a higher
version number will not necessarily provide a better service, but version number will not necessarily provide a better service, but
might simply provide a different feature set. As such, an might simply provide a different feature set. As such, an
application needs to be able to select which versions of QUIC it application needs to be able to select which versions of QUIC it
wants to use. wants to use.
skipping to change at page 15, line 24 skipping to change at page 16, line 42
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.
16. References 16. References
16.1. Normative References 16.1. Normative References
[QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed [QUIC] 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-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>.
[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>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>. <https://www.rfc-editor.org/info/rfc6335>.
[TLS13] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", [TLS13] 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>.
16.2. Informative References 16.2. Informative References
[Edeline16] [Edeline16]
Edeline, K., Kuehlewind, M., Trammell, B., Aben, E., and Edeline, K., Kuehlewind, M., Trammell, B., Aben, E., and
B. Donnet, "Using UDP for Internet Transport Evolution B. Donnet, "Using UDP for Internet Transport Evolution
(arXiv preprint 1612.07816)", 22 December 2016, (arXiv preprint 1612.07816)", 22 December 2016,
<https://arxiv.org/abs/1612.07816>. <https://arxiv.org/abs/1612.07816>.
[Hatonen10] [Hatonen10]
skipping to change at page 16, line 45 skipping to change at page 18, line 14
[PaaschNanog] [PaaschNanog]
Paasch, C., "Network Support for TCP Fast Open (NANOG 67 Paasch, C., "Network Support for TCP Fast Open (NANOG 67
presentation)", 13 June 2016, presentation)", 13 June 2016,
<https://www.nanog.org/sites/default/files/ <https://www.nanog.org/sites/default/files/
Paasch_Network_Support.pdf>. Paasch_Network_Support.pdf>.
[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-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>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[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>.
[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>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[Swett16] Swett, I., "QUIC Deployment Experience at Google (IETF96 [Swett16] Swett, I., "QUIC Deployment Experience at Google (IETF96
QUIC BoF presentation)", 20 July 2016, QUIC BoF presentation)", 20 July 2016,
<https://www.ietf.org/proceedings/96/slides/slides-96- <https://www.ietf.org/proceedings/96/slides/slides-96-
quic-3.pdf>. quic-3.pdf>.
[Trammell16] [Trammell16]
Trammell, B. and M. Kuehlewind, "Internet Path Trammell, B. and M. Kuehlewind, "Internet Path
Transparency Measurements using RIPE Atlas (RIPE72 MAT Transparency Measurements using RIPE Atlas (RIPE72 MAT
presentation)", 25 May 2016, <https://ripe72.ripe.net/wp- presentation)", 25 May 2016, <https://ripe72.ripe.net/wp-
content/uploads/presentations/86-atlas-udpdiff.pdf>. content/uploads/presentations/86-atlas-udpdiff.pdf>.
 End of changes. 32 change blocks. 
131 lines changed or deleted 229 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/