draft-ietf-quic-applicability-06.txt   draft-ietf-quic-applicability-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
Applicability of the QUIC Transport Protocol Applicability of the QUIC Transport Protocol
draft-ietf-quic-applicability-06 draft-ietf-quic-applicability-07
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 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 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . 7
4.2. Prioritization . . . . . . . . . . . . . . . . . . . . . 7 4.2. Prioritization . . . . . . . . . . . . . . . . . . . . . 7
4.3. Flow Control Deadlocks . . . . . . . . . . . . . . . . . 7 4.3. Flow Control Deadlocks . . . . . . . . . . . . . . . . . 7
5. Packetization and Latency . . . . . . . . . . . . . . . . . . 9 5. Packetization and Latency . . . . . . . . . . . . . . . . . . 9
6. Port Selection . . . . . . . . . . . . . . . . . . . . . . . 9 6. Port Selection and Application Endpoint Discovery . . . . . . 9
7. Connection Migration . . . . . . . . . . . . . . . . . . . . 10 7. Connection Migration . . . . . . . . . . . . . . . . . . . . 10
8. Connection closure . . . . . . . . . . . . . . . . . . . . . 10 8. Connection closure . . . . . . . . . . . . . . . . . . . . . 10
9. Information exposure and the Connection ID . . . . . . . . . 11 9. Information exposure and the Connection ID . . . . . . . . . 11
9.1. Server-Generated Connection ID . . . . . . . . . . . . . 11 9.1. Server-Generated Connection ID . . . . . . . . . . . . . 12
9.2. Mitigating Timing Linkability with Connection ID 9.2. Mitigating Timing Linkability with Connection ID
Migration . . . . . . . . . . . . . . . . . . . . . . . . 12 Migration . . . . . . . . . . . . . . . . . . . . . . . . 12
9.3. Using Server Retry for Redirection . . . . . . . . . . . 12 9.3. Using Server Retry for Redirection . . . . . . . . . . . 12
10. Use of Versions and Cryptographic Handshake . . . . . . . . . 12 10. Use of Versions and Cryptographic Handshake . . . . . . . . . 13
11. Enabling New Versions . . . . . . . . . . . . . . . . . . . . 13 11. Enabling New Versions . . . . . . . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
16.1. Normative References . . . . . . . . . . . . . . . . . . 14 16.1. Normative References . . . . . . . . . . . . . . . . . . 15
16.2. Informative References . . . . . . . . . . . . . . . . . 15 16.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
QUIC [QUIC] is a new transport protocol currently under development QUIC [QUIC] is a new transport protocol currently under development
in the IETF quic working group, focusing on support of semantics as in the IETF quic working group, focusing on support of semantics as
needed for HTTP/2 [QUIC-HTTP] such as stream-multiplexing to avoid needed for HTTP/2 [QUIC-HTTP] such as stream-multiplexing to avoid
head-of-line blocking. Based on current deployment practices, QUIC head-of-line blocking. Based on current deployment practices, QUIC
is encapsulated in UDP. The version of QUIC that is currently under is encapsulated in UDP. The version of QUIC that is currently under
development will integrate TLS 1.3 [TLS13] to encrypt all payload development will integrate TLS 1.3 [TLS13] to encrypt all payload
data and most control information. data and most control information.
skipping to change at page 9, line 39 skipping to change at page 9, line 39
Additionally, a QUIC implementation can expose an application layer Additionally, a QUIC implementation can expose an application layer
interface to specify a certain packet size. This can either be used interface to specify a certain packet size. This can either be used
by the application to force certian packet sizes in specific use by the application to force certian packet sizes in specific use
cases/networks, or ensure that all packets are equally sized to cases/networks, or ensure that all packets are equally sized to
conceal potential leakage of application layer information when the conceal potential leakage of application layer information when the
data sent by the application are not greedy. Note the initial packet data sent by the application are not greedy. Note the initial packet
must have a minimum size of 1200 bytes according to the QUIC must have a minimum size of 1200 bytes according to the QUIC
specification. A receiver of a smaller initial packet may reject specification. A receiver of a smaller initial packet may reject
this packet in order to avoid amplification attacks. this packet in order to avoid amplification attacks.
6. Port Selection 6. Port Selection and Application Endpoint Discovery
As QUIC is a general purpose transport protocol, there are no
requirements that servers use a particular UDP port for QUIC in
general. Instead, the same port number is used as would be used for
the same application over TCP. In the case of HTTP the expectation
is that port 443 is used, which has already been registered for "http
protocol over TLS/SSL". However, [QUIC-HTTP] also specifies the use
of Alt-Svc for HTTP/QUIC discovery which allows the server to use and
announce a different port number.
In general, port numbers serves two purposes: "first, they provide a In general, port numbers serves two purposes: "first, they provide a
demultiplexing identifier to differentiate transport sessions between demultiplexing identifier to differentiate transport sessions between
the same pair of endpoints, and second, they may also identify the the same pair of endpoints, and second, they may also identify the
application protocol and associated service to which processes application protocol and associated service to which processes
connect" [RFC6335]. Note that the assumption that an application can connect" [RFC6335]. Note that the assumption that an application can
be identified in the network based on the port number is less true be identified in the network based on the port number is less true
today, due to encapsulation, mechanisms for dynamic port assignments today, due to encapsulation, mechanisms for dynamic port assignments
as well as NATs. as well as NATs.
However, whenever a non-standard port is used which does not enable As QUIC is a general purpose transport protocol, there are no
easy mapping to a registered service name, this can lead to blocking requirements that servers use a particular UDP port for QUIC in
by network elements such as firewalls that rely on the port number as general. For applications with a fallback to TCP which do not
a first order of filtering. already have an alternate mapping to UDP, the registration (if
necessary) and use of the UDP port number corresponding to the TCP
port already registered for the application is RECOMMENDED. For
example, the default port for HTTP/3 [QUIC-HTTP] is UDP port 443,
analogous to HTTP/1.1 or HTTP/2 over TLS over TCP.
Applications SHOULD define an alternate endpoint discovery mechanism
to allow the usage of ports other than the default. For example,
HTTP/3 ([QUIC-HTTP] sections 3.2 and 3.3) specifies the use of ALPN
[RFC7301] for service discovery which allows the server to use and
announce a different port number. Note that HTTP/3's ALPN token
("h3") identifies not only the version of the application protocol,
but also the binding to QUIC as well as the version of QUIC itself;
this approach allows unambiguous agreement between the endpoints on
the protocol stack in use.
Note that given the prevalence of the assumption in network
management practice that a port number maps unambiguously to an
application, the use of ports that cannot easily be mapped to a
registered service name may lead to blocking or other interference by
network elements such as firewalls that rely on the port number for
application identification.
7. Connection Migration 7. Connection Migration
QUIC supports connection migration. Even if lower-layer addresses QUIC supports connection migration. Even if lower-layer addresses
(usually the 4-tuple of IP addresses and ports) changes, QUIC packets (usually the 4-tuple of IP addresses and ports) changes, QUIC packets
can still be associated with an existing connection based on the can still be associated with an existing connection based on the
Connection ID (see also section Section 9) in the QUIC header, if Connection ID (see also section Section 9) in the QUIC header, if
present. This supports cases where address information changes due present. This supports cases where address information changes due
to e.g. NAT rebinding or change of the local interface. Currently to e.g. NAT rebinding or change of the local interface. Currently
QUIC only supports failover cases. Only one "path" can be used at a QUIC only supports failover cases. Only one "path" can be used at a
skipping to change at page 14, line 13 skipping to change at page 14, line 34
negotiation version as though the new version were disabled. negotiation version as though the new version were disabled.
The process for disabling an old version or rolling back the The process for disabling an old version or rolling back the
introduction of a new version uses the same process in reverse. introduction of a new version uses the same process in reverse.
Servers disable validation of the old version, stop sending the old Servers disable validation of the old version, stop sending the old
version in Version Negotiation packets, then the old version is no version in Version Negotiation packets, then the old version is no
longer accepted. longer accepted.
12. IANA Considerations 12. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA; however, note that Section 6
recommends that application bindings to QUIC for applications using
TCP register UDP ports analogous to their existing TCP registrations.
13. Security Considerations 13. Security Considerations
See the security considerations in [QUIC] and [QUIC-TLS]; the See the security considerations in [QUIC] and [QUIC-TLS]; the
security considerations for the underlying transport protocol are security considerations for the underlying transport protocol are
relevant for applications using QUIC, as well. relevant for applications using QUIC, as well.
Application developers should note that any fallback they use when Application developers should note that any fallback they use when
QUIC cannot be used due to network blocking of UDP SHOULD guarantee QUIC cannot be used due to network blocking of UDP SHOULD guarantee
the same security properties as QUIC; if this is not possible, the the same security properties as QUIC; if this is not possible, the
skipping to change at page 14, line 46 skipping to change at page 15, line 24
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-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>.
[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>.
[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-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>.
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 16 skipping to change at page 16, line 45
[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-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>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[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-
 End of changes. 16 change blocks. 
40 lines changed or deleted 59 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/