idnits 2.17.1 draft-ietf-quic-applicability-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Any fallback mechanism is likely to impose a degradation of performance; however, fallback MUST not silently violate the application's expectation of confidentiality or integrity of its payload data. -- The document date (July 02, 2018) is 2124 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.nottingham-httpbis-retry' is defined on line 429, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-13 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-13 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-13 -- Duplicate reference: draft-ietf-quic-tls, mentioned in 'TLS13', was also mentioned in 'QUIC-TLS'. -- Duplicate reference: draft-nottingham-httpbis-retry, mentioned in 'I-D.nottingham-httpbis-retry', was also mentioned in 'HTTP-RETRY'. == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-13 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Kuehlewind 3 Internet-Draft B. Trammell 4 Intended status: Informational ETH Zurich 5 Expires: January 3, 2019 July 02, 2018 7 Applicability of the QUIC Transport Protocol 8 draft-ietf-quic-applicability-02 10 Abstract 12 This document discusses the applicability of the QUIC transport 13 protocol, focusing on caveats impacting application protocol 14 development and deployment over QUIC. Its intended audience is 15 designers of application protocol mappings to QUIC, and implementors 16 of these application protocols. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 3, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 54 2. The Necessity of Fallback . . . . . . . . . . . . . . . . . . 3 55 3. Zero RTT . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Thinking in Zero RTT . . . . . . . . . . . . . . . . . . 4 57 3.2. Here There Be Dragons . . . . . . . . . . . . . . . . . . 4 58 3.3. Session resumption versus Keep-alive . . . . . . . . . . 4 59 4. Use of Streams . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. Stream versus Flow Multiplexing . . . . . . . . . . . . . 5 61 4.2. Packetization and latency . . . . . . . . . . . . . . . . 6 62 4.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 6 63 5. Graceful connection closure . . . . . . . . . . . . . . . . . 6 64 6. Information exposure and the Connection ID . . . . . . . . . 7 65 6.1. Server-Generated Connection ID . . . . . . . . . . . . . 7 66 6.2. Using Server Retry for Redirection . . . . . . . . . . . 8 67 7. Use of Versions and Cryptographic Handshake . . . . . . . . . 8 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 71 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 12.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 QUIC [QUIC] is a new transport protocol currently under development 80 in the IETF quic working group, focusing on support of semantics as 81 needed for HTTP/2 [QUIC-HTTP] such as stream-multiplexing to avoid 82 head-of-line blocking. Based on current deployment practices, QUIC 83 is encapsulated in UDP. The version of QUIC that is currently under 84 development will integrate TLS 1.3 [TLS13] to encrypt all payload 85 data and most control information. 87 This document provides guidance for application developers that want 88 to use the QUIC protocol without implementing it on their own. This 89 includes general guidance for application use of HTTP/2 over QUIC as 90 well as the use of other application layer protocols over QUIC. For 91 specific guidance on how to integrate HTTP/2 with QUIC, see 92 [QUIC-HTTP]. 94 In the following sections we discuss specific caveats to QUIC's 95 applicability, and issues that application developers must consider 96 when using QUIC as a transport for their application. 98 1.1. Notational Conventions 100 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 101 document. It's not shouting; when these words are capitalized, they 102 have a special meaning as defined in [RFC2119]. 104 2. The Necessity of Fallback 106 QUIC uses UDP as a substrate for userspace implementation and port 107 numbers for NAT and middlebox traversal. While there is no evidence 108 of widespread, systematic disadvantage of UDP traffic compared to TCP 109 in the Internet [Edeline16], somewhere between three [Trammell16] and 110 five [Swett16] percent of networks simply block UDP traffic. All 111 applications running on top of QUIC must therefore either be prepared 112 to accept connectivity failure on such networks, or be engineered to 113 fall back to some other transport protocol. This fallback SHOULD 114 provide TLS 1.3 or equivalent cryptographic protection, if available, 115 in order to keep fallback from being exploited as a downgrade attack. 116 In the case of HTTP, this fallback is TLS 1.3 over TCP. 118 These applications must operate, perhaps with impaired functionality, 119 in the absence of features provided by QUIC not present in the 120 fallback protocol. For fallback to TLS over TCP, the most obvious 121 difference is that TCP does not provide stream multiplexing and 122 therefore stream multiplexing would need to be implemented in the 123 application layer if needed. Further, TCP without the TCP Fast Open 124 extension does not support 0-RTT session resumption. TCP Fast Open 125 can be requested by the connection initiator but might no be 126 supported by the far end or could be blocked on the network path. 127 Note that there is some evidence of middleboxes blocking SYN data 128 even if TFO was successfully negotiated (see [PaaschNanog]). 130 Any fallback mechanism is likely to impose a degradation of 131 performance; however, fallback MUST not silently violate the 132 application's expectation of confidentiality or integrity of its 133 payload data. 135 Moreover, while encryption (in this case TLS) is inseparably 136 integrated with QUIC, TLS negotiation over TCP can be blocked. In 137 case it is RECOMMENDED to abort the connection, allowing the 138 application to present a suitable prompt to the user that secure 139 communication is unavailable. 141 3. Zero RTT 143 QUIC provides for 0-RTT connection establishment (see section 3.2 of 144 [QUIC]). This presents opportunities and challenges for applications 145 using QUIC. 147 3.1. Thinking in Zero RTT 149 A transport protocol that provides 0-RTT connection establishment to 150 recently contacted servers is qualitatively different than one that 151 does not from the point of view of the application using it. 152 Relative trade-offs between the cost of closing and reopening a 153 connection and trying to keep it open are different; see Section 3.3. 155 Applications must be slightly rethought in order to make best use of 156 0-RTT resumption. Most importantly, application operations must be 157 divided into idempotent and non-idempotent operations, as only 158 idempotent operations may appear in 0-RTT packets. This implies that 159 the interface between the application and transport layer exposes 160 idempotence either explicitly or implicitly. 162 3.2. Here There Be Dragons 164 Retransmission or (malicious) replay of data contained in 0-RTT 165 resumption packets could cause the server side to receive two copies 166 of the same data. This is further described in [HTTP-RETRY]. Data 167 sent during 0-RTT resumption also cannot benefit from perfect forward 168 secrecy (PFS). 170 Data in the first flight sent by the client in a connection 171 established with 0-RTT MUST be idempotent (as specified in section 172 3.2 in [QUIC-TLS]). Applications MUST be designed, and their data 173 MUST be framed, such that multiple reception of idempotent data is 174 recognized as such by the receiverApplications that cannot treat data 175 that may appear in a 0-RTT connection establishment as idempotent 176 MUST NOT use 0-RTT establishment. For this reason the QUIC transport 177 SHOULD provide an interface for the application to indicate if 0-RTT 178 support is in general desired or a way to indicate whether data is 179 idempotent, and/or whether PFS is a hard requirement for the 180 application. 182 3.3. Session resumption versus Keep-alive 184 [EDITOR'S NOTE: see https://github.com/quicwg/ops-drafts/issues/6] 186 4. Use of Streams 188 QUIC's stream multiplexing feature allows applications to run 189 multiple streams over a single connection, without head-of-line 190 blocking between streams, associated at a point in time with a single 191 five-tuple. Stream data is carried within Frames, where one (UDP) 192 packet on the wire can carry one of multiple stream frames. 194 Stream can be independently open and closed, gracefully or by error. 195 If a critical stream for the application is closed, the application 196 can generate respective error messages on the application layer to 197 inform the other end or the higher layer and eventually indicate quic 198 to reset the connection. QUIC, however, does not need to know which 199 streams are critical, and does not provide an interface to 200 exceptional handling of any stream. There are special streams in 201 QUIC that are used for control on the QUIC connection, however, these 202 streams are not exposed to the application. 204 Mapping of application data to streams is application-specific and 205 described for HTTP/s in [QUIC-HTTP]. In general data that can be 206 processed independently, and therefore would suffer from head of line 207 blocking, if forced to be received in order, should be transmitted 208 over different streams. If there is a logical grouping of those data 209 chunks or messages, stream can be reused, or a new stream can be 210 opened for each chunk/message. If a QUIC receiver has maximum 211 allowed concurrent streams open and the sender on the other end 212 indicates that more streams are needed, it doesn't automatically lead 213 to an increase of the maximum number of streams by the receiver. 214 Therefore it can be valuable to expose maximum number of allowed, 215 currently open and currently used streams to the application to make 216 the mapping of data to streams dependent on this information. 218 Further, streams have a maximum number of bytes that can be sent on 219 one stream. This number is high enough (2^64) that this will usually 220 not be reached with current applications. Applications that send 221 chunks of data over a very long period of time (such as days, months, 222 or years), should rather utilize the 0-RTT session resumption ability 223 provided by QUIC, than trying to maintain one connection open. 225 4.1. Stream versus Flow Multiplexing 227 Streams are meaningful only to the application; since stream 228 information is carried inside QUIC's encryption boundary, no 229 information about the stream(s) whose frames are carried by a given 230 packet is visible to the network. Therefore stream multiplexing is 231 not intended to be used for differentiating streams in terms of 232 network treatment. Application traffic requiring different network 233 treatment SHOULD therefore be carried over different five-tuples 234 (i.e. multiple QUIC connections). Given QUIC's ability to send 235 application data in the first RTT of a connection (if a previous 236 connection to the same host has been successfully established to 237 provide the respective credentials), the cost for establishing 238 another connection are extremely low. 240 4.2. Packetization and latency 242 Quic provides an interface that provides multiple streams to the 243 application, however, the application usually doesn't have control 244 how the data transmitted over one stream is mapped into frame and how 245 frames are bundled into packets. By default QUIC will try to 246 maximally pack packets to minimize bandwidth consumption and 247 computational costs with one or multiple same data frames. If not 248 enough data available to send QUIC may even wait for a short time, 249 trading of latency and bandwidth efficiency. This time might either 250 be pre-configured or can the dynamically adjusted based on the 251 observed sending pattern of the application. If the application 252 requires low latency, with only small chunks of data to send, it may 253 be valuable to indicate to QUIC that all data should be send out 254 immediately. Or if a certain sending pattern is know by the 255 application, it might also provide valuable guidance to QUIC how long 256 it should wait to bundle frame into a packet. 258 4.3. Prioritization 260 Stream prioritization is not exposed to the network, nor to the 261 receiver. Prioritization can be realized by the sender and the QUIC 262 transport should provide an interface for applications to prioritize 263 streams [QUIC]. Further applications can implement their own 264 prioritization scheme on top of QUIC: (an application) protocol that 265 runs on top of QUIC can define explicit messages for signaling 266 priority, such as those defined for HTTP/2; it can define rules that 267 allow an endpoint to determine priority based on context; or it can 268 provide a higher level interface and leave the determination to the 269 application on top. 271 Priority handling of retransmissions can be implemented by the sender 272 in the transport layer. [QUIC] recommends to retransmit lost data 273 before new data, unless indicated differently by the application. 274 Currently QUIC only provides fully reliable stream transmission, and 275 as such prioritization of retransmissions likely beneficial in most 276 cases, as gaps that get filled up and thereby free up flow control. 277 For not fully reliable streams priority scheduling of retransmissions 278 over data of higher-priority streams might not be desired. In this 279 case QUIC could also provide an interface or derive the 280 prioritization decision from the reliability level of the stream. 282 5. Graceful connection closure 284 [EDITOR'S NOTE: give some guidance here about the steps an 285 application should take; however this is still work in progress] 287 6. Information exposure and the Connection ID 289 QUIC exposes some information to the network in the unencrypted part 290 of the header, either before the encryption context is established, 291 because the information is intended to be used by the network. QUIC 292 has a long header that is used during connection establishment and 293 for other control processes, and a short header that may be used for 294 data transmission in an established connection. While the long 295 header is fixed and exposes some information, the short header only 296 exposes the packet number by default and may optionally expose a 297 connection ID. 299 Given that exposing this information may make it possible to 300 associate multiple addresses with a single client during rebinding, 301 which has privacy implications, an application may indicate to not 302 support exposure of certain information after the handshake. 303 Specifically, an application that has additional information that the 304 client is not behind a NAT and the server is not behind a load 305 balancer, and therefore it is unlikely that the addresses will be re- 306 bound, may indicate to the transport that is wishes to not expose a 307 connection ID. 309 6.1. Server-Generated Connection ID 311 QUIC supports a server-generated Connection ID, transmitted to the 312 client during connection establishment: see Section 5.7 of [QUIC]. 313 Servers behind load balancers should propose a Connection ID during 314 the handshake, encoding the identity of the server or information 315 about its load balancing pool, in order to support stateless load 316 balancing. Once the server generates a Connection ID that encodes 317 its identity, every CDN load balancer would be able to forward the 318 packets to that server without needing information about every 319 specific flow it is forwarding. 321 Server-generated Connection IDs must not encode any information other 322 that that needed to route packets to the appropriate backend 323 server(s): typically the identity of the backend server or pool of 324 servers, if the data-center's load balancing system keeps "local" 325 state of all flows itself. Care must be exercised to ensure that the 326 information encoded in the Connection ID is not sufficient to 327 identify unique end users. Note that by encoding routing information 328 in the Connection ID, load balancers open up a new attack vector that 329 allows bad actors to direct traffic at a specific backend server or 330 pool. It is therefore recommended that Server-Generated Connection 331 ID includes a cryptographic MAC that the load balancer pool server is 332 able to identify and discard packets featuring an invalid MAC. 334 6.2. Using Server Retry for Redirection 336 QUIC provides a Server Retry packet that can be sent by a server in 337 response to the Client Initial packet. The server may choose a new 338 connection ID in that packet and the client will retry by sending 339 another Client Initial packet with the server-selected connection ID. 340 This mechanism can be used to redirect a connection to a different 341 server, e.g. due to performance reasons or when servers in a server 342 pool are upgraded gradually, and therefore may support different 343 versions of QUIC. In this case, it is assumed that all servers 344 belonging to a certain pool are served in cooperation with load 345 balancers that forward the traffic based on the connection ID. A 346 server can chose the connection ID in the Server Retry packet such 347 that the load balancer will redirect the next Client Initial packet 348 to a different server in that pool. 350 7. Use of Versions and Cryptographic Handshake 352 Versioning in QUIC may change the protocol's behavior completely, 353 except for the meaning of a few header fields that have been declared 354 to be fixed. As such version of QUIC with a higher version number 355 does not necessarily provide a better service, but might simply 356 provide a very different service, so an application needs to be able 357 to select which versions of QUIC it wants to use. 359 A new version could use an encryption scheme other than TLS 1.3 or 360 higher. [QUIC] specifies requirements for the cryptographic 361 handshake as currently realized by TLS 1.3 and described in a 362 separate specification [QUIC-TLS]. This split is performed to enable 363 light-weight versioning with different cryptographic handshakes. 365 8. IANA Considerations 367 This document has no actions for IANA. 369 9. Security Considerations 371 See the security considerations in [QUIC] and [QUIC-TLS]; the 372 security considerations for the underlying transport protocol are 373 relevant for applications using QUIC, as well. 375 Application developers should note that any fallback they use when 376 QUIC cannot be used due to network blocking of UDP SHOULD guarantee 377 the same security properties as QUIC; if this is not possible, the 378 connection SHOULD fail to allow the application to explicitly handle 379 fallback to a less-secure alternative. See Section 2. 381 10. Contributors 383 Igor Lubashev contributed text to Section 6 on server-selected 384 connection IDs. 386 11. Acknowledgments 388 This work is partially supported by the European Commission under 389 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 390 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 391 for Education, Research, and Innovation under contract no. 15.0268. 392 This support does not imply endorsement. 394 12. References 396 12.1. Normative References 398 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 399 and Secure Transport", draft-ietf-quic-transport-13 (work 400 in progress), June 2018. 402 [QUIC-TLS] 403 Thomson, M. and S. Turner, "Using Transport Layer Security 404 (TLS) to Secure QUIC", draft-ietf-quic-tls-13 (work in 405 progress), June 2018. 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 409 RFC2119, March 1997, . 412 [TLS13] Thomson, M. and S. Turner, "Using Transport Layer Security 413 (TLS) to Secure QUIC", draft-ietf-quic-tls-13 (work in 414 progress), June 2018. 416 12.2. Informative References 418 [Edeline16] 419 Edeline, K., Kuehlewind, M., Trammell, B., Aben, E., and 420 B. Donnet, "Using UDP for Internet Transport Evolution 421 (arXiv preprint 1612.07816)", December 2016, 422 . 424 [HTTP-RETRY] 425 Nottingham, M., "Retrying HTTP Requests", draft- 426 nottingham-httpbis-retry-01 (work in progress), February 427 2017. 429 [I-D.nottingham-httpbis-retry] 430 Nottingham, M., "Retrying HTTP Requests", draft- 431 nottingham-httpbis-retry-01 (work in progress), February 432 2017. 434 [PaaschNanog] 435 Paasch, C., "Network Support for TCP Fast Open (NANOG 67 436 presentation)", June 2016, 437 . 440 [QUIC-HTTP] 441 Bishop, M., "Hypertext Transfer Protocol (HTTP) over 442 QUIC", draft-ietf-quic-http-13 (work in progress), June 443 2018. 445 [Swett16] Swett, I., "QUIC Deployment Experience at Google (IETF96 446 QUIC BoF presentation)", July 2016, 447 . 450 [Trammell16] 451 Trammell, B. and M. Kuehlewind, "Internet Path 452 Transparency Measurements using RIPE Atlas (RIPE72 MAT 453 presentation)", May 2016, . 456 Authors' Addresses 458 Mirja Kuehlewind 459 ETH Zurich 460 Gloriastrasse 35 461 8092 Zurich 462 Switzerland 464 Email: mirja.kuehlewind@tik.ee.ethz.ch 466 Brian Trammell 467 ETH Zurich 468 Gloriastrasse 35 469 8092 Zurich 470 Switzerland 472 Email: ietf@trammell.ch