idnits 2.17.1 draft-ietf-quic-applicability-08.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 (2 November 2020) is 1261 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.nottingham-httpbis-retry' is defined on line 802, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-32 == Outdated reference: A later version (-13) exists of draft-ietf-quic-invariants-11 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-32 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-32 -- 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-32 == Outdated reference: A later version (-19) exists of draft-ietf-quic-load-balancers-05 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Kuehlewind 3 Internet-Draft Ericsson 4 Intended status: Informational B. Trammell 5 Expires: 6 May 2021 Google 6 2 November 2020 8 Applicability of the QUIC Transport Protocol 9 draft-ietf-quic-applicability-08 11 Abstract 13 This document discusses the applicability of the QUIC transport 14 protocol, focusing on caveats impacting application protocol 15 development and deployment over QUIC. Its intended audience is 16 designers of application protocol mappings to QUIC, and implementors 17 of these application protocols. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 6 May 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Thinking in Zero RTT . . . . . . . . . . . . . . . . . . 4 57 3.2. Here There Be Dragons . . . . . . . . . . . . . . . . . . 4 58 3.3. Session resumption versus Keep-alive . . . . . . . . . . 5 59 4. Use of Streams . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Stream versus Flow Multiplexing . . . . . . . . . . . . . 8 61 4.2. Prioritization . . . . . . . . . . . . . . . . . . . . . 8 62 4.3. Flow Control Deadlocks . . . . . . . . . . . . . . . . . 8 63 5. Packetization and Latency . . . . . . . . . . . . . . . . . . 10 64 6. Port Selection and Application Endpoint Discovery . . . . . . 10 65 7. Connection Migration . . . . . . . . . . . . . . . . . . . . 11 66 8. Connection closure . . . . . . . . . . . . . . . . . . . . . 12 67 9. Information exposure and the Connection ID . . . . . . . . . 13 68 9.1. Server-Generated Connection ID . . . . . . . . . . . . . 13 69 9.2. Mitigating Timing Linkability with Connection ID 70 Migration . . . . . . . . . . . . . . . . . . . . . . . . 13 71 9.3. Using Server Retry for Redirection . . . . . . . . . . . 14 72 10. Use of Versions and Cryptographic Handshake . . . . . . . . . 14 73 11. Enabling New Versions . . . . . . . . . . . . . . . . . . . . 14 74 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 75 13. Security Considerations . . . . . . . . . . . . . . . . . . . 16 76 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 77 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 78 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 16.1. Normative References . . . . . . . . . . . . . . . . . . 16 80 16.2. Informative References . . . . . . . . . . . . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 83 1. Introduction 85 QUIC [QUIC] is a new transport protocol providing a number of 86 advanced features. While initially designed for the HTTP use case, 87 like most transports it is intended for use with a much wider variety 88 of applications. QUIC is encapsulated in UDP. The version of QUIC 89 that is currently under development will integrate TLS 1.3 [TLS13] to 90 encrypt all payload data and most control information. HTTP 91 operating over QUIC is known as HTTP/3. 93 This document provides guidance for application developers that want 94 to use the QUIC protocol without implementing it on their own. This 95 includes general guidance for applications operating over HTTP/3 or 96 directly over QUIC. For specific guidance on how to integrate HTTP/3 97 with QUIC, see [QUIC-HTTP]. 99 In the following sections we discuss specific caveats to QUIC's 100 applicability, and issues that application developers must consider 101 when using QUIC as a transport for their application. 103 1.1. Notational Conventions 105 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 106 document. It's not shouting; when these words are capitalized, they 107 have a special meaning as defined in [RFC2119]. 109 2. The Necessity of Fallback 111 QUIC uses UDP as a substrate for userspace implementation and port 112 numbers for NAT and middlebox traversal. While there is no evidence 113 of widespread, systematic disadvantage of UDP traffic compared to TCP 114 in the Internet [Edeline16], somewhere between three [Trammell16] and 115 five [Swett16] percent of networks simply block UDP traffic. All 116 applications running on top of QUIC must therefore either be prepared 117 to accept connectivity failure on such networks, or be engineered to 118 fall back to some other transport protocol. This fallback SHOULD 119 provide TLS 1.3 or equivalent cryptographic protection, if available, 120 in order to keep fallback from being exploited as a downgrade attack. 121 In the case of HTTP, this fallback is TLS 1.3 over TCP. 123 These applications must operate, perhaps with impaired functionality, 124 in the absence of features provided by QUIC not present in the 125 fallback protocol. For fallback to TLS over TCP, the most obvious 126 difference is that TCP does not provide stream multiplexing and 127 therefore stream multiplexing would need to be implemented in the 128 application layer if needed. 130 Further, TCP implementations and network paths often do not support 131 the Fast Open option, which is analogous to 0-RTT session resumption. 132 Even if Fast Open successfully operates end-to-end, it is limited to 133 a single packet of payload, unlike QUIC 0-RTT. 135 Note that there is some evidence of middleboxes blocking SYN data 136 even if TFO was successfully negotiated (see [PaaschNanog]). 138 Any fallback mechanism is likely to impose a degradation of 139 performance; however, fallback MUST not silently violate the 140 application's expectation of confidentiality or integrity of its 141 payload data. 143 Moreover, while encryption (in this case TLS) is inseparably 144 integrated with QUIC, TLS negotiation over TCP can be blocked. In 145 case it is RECOMMENDED to abort the connection, allowing the 146 application to present a suitable prompt to the user that secure 147 communication is unavailable. 149 3. Zero RTT 151 QUIC provides for 0-RTT connection establishment. This presents 152 opportunities and challenges for applications using QUIC. 154 3.1. Thinking in Zero RTT 156 A transport protocol that provides 0-RTT connection establishment to 157 recently contacted servers is qualitatively different than one that 158 does not from the point of view of the application using it. 159 Relative trade-offs between the cost of closing and reopening a 160 connection and trying to keep it open are different; see Section 3.3. 162 Applications must be slightly rethought in order to make best use of 163 0-RTT resumption. Most importantly, application operations must be 164 divided into idempotent and non-idempotent operations, as only 165 idempotent operations may appear in 0-RTT packets. This implies that 166 the interface between the application and transport layer exposes 167 idempotence either explicitly or implicitly. 169 3.2. Here There Be Dragons 171 Retransmission or (malicious) replay of data contained in 0-RTT 172 resumption packets could cause the server side to receive two copies 173 of the same data. This is further described in [HTTP-RETRY]. Data 174 sent during 0-RTT resumption also cannot benefit from perfect forward 175 secrecy (PFS). 177 Data in the first flight sent by the client in a connection 178 established with 0-RTT MUST be idempotent (as specified in section 179 2.1 in [QUIC-TLS]). Applications MUST be designed, and their data 180 MUST be framed, such that multiple reception of idempotent data is 181 recognized as such by the receiver. Applications that cannot treat 182 data that may appear in a 0-RTT connection establishment as 183 idempotent MUST NOT use 0-RTT establishment. For these reason the 184 QUIC transport SHOULD provide some or all of the following interfaces 185 to applications: 187 * indicate if 0-RTT support is in general desired, which implies 188 that lack of PFS is acceptable for some data; 190 * an indication when 0RTT data for both egress and ingress, so that 191 both sender and receiver understand the properties of the 192 communication channel when the data is sent; and/or 194 * whether rejected 0-RTT data should be retransmitted or withdrawn. 196 Some TLS implementations may offer replay protection, which may 197 mitigate some of these issues. 199 3.3. Session resumption versus Keep-alive 201 Because QUIC is encapsulated in UDP, applications using QUIC must 202 deal with short network idle timeouts. Deployed stateful middleboxes 203 will generally establish state for UDP flows on the first packet 204 state, and keep state for much shorter idle periods than for TCP. 205 [RFC5382] suggests a TCP idle period of at least 124 minutes, though 206 there is not evidence of widespread implementation of this guideline 207 in the literature. Short network timeout for UDP, however, is well- 208 documented. According to a 2010 study ([Hatonen10]), UDP 209 applications can assume that any NAT binding or other state entry can 210 expire after just thirty seconds of inactivity. Section 3.5 of 211 [RFC8085] further discusses keep-alive intervals for UDP: it requires 212 a minimum value of 15 seconds, but recommends larger values, or 213 omitting keepalive entirely. 215 By using a Connection ID, QUIC is designed to be robust to NAT 216 address rebinding after a timeout. However, some QUIC connections 217 may not be robust to rebinding because the routing infrastructure (in 218 particular, load balancers) uses the address/port four-tuple to 219 direct traffic. Furthermore, middleboxes with functions other than 220 address translation may still affect the path. In particular, 221 firewalls will often not admit server traffic for which it has not 222 kept state for corresponding packets from the client. 224 A QUIC application has three strategies to deal with this issue by 225 adjusting idle periods (noting that idle periods and the network idle 226 timeout is distinct from the connection idle timeout, defined as the 227 minimum of the idle timeout parameter in Section 10.1 of [QUIC]): 229 * Ignore it, if the application-layer protocol consists only of 230 interactions with no or very short idle periods, or the protocol's 231 resistance to NAT rebinding is sufficient. 233 * Ensure there are no long idle periods. 235 * Resume the session after a long idle period, using 0-RTT 236 resumption when appropriate. 238 The first strategy is the easiest, but it only applies to certain 239 applications. 241 Either the server or the client in a QUIC application can send PING 242 frames as keep-alives, to prevent the connection and any on-path 243 state from timing out. Recommendations for the use of keep-alives 244 are application specific, mainly depending on the latency 245 requirements and message frequency of the application. In this case, 246 the application mapping must specify whether the client or server is 247 responsible for keeping the application alive. While [Hatonen10] 248 suggests that 30 seconds might be a suitable value for the public 249 Internet when a NAT is on path, larger values are preferable if the 250 deployment can consistently survive NAT rebinding, or is known to be 251 in a controlled environments like e.g. data centres in order to lower 252 network and computational load. Sending PING frames more frequently 253 than every 30 seconds over long idle periods may result in excessive 254 unproductive traffic in some situations, and to unacceptable power 255 usage for power-constrained (mobile) devices. Additionally, time- 256 outs shorter than 30 seconds can make it harder to handle trasient 257 network interruptions, such as VM migration or coverage loss during 258 mobilty. 260 Alternatively, the client (but not the server) can use session 261 resumption instead of sending keepalive traffic. In this case, a 262 client that wants to send data to a server over a connection idle 263 longer than the server's idle timeout (available from the 264 idle_timeout transport parameter) can simply reconnect. When 265 possible, this reconnection can use 0-RTT session resumption, 266 reducing the latency involved with restarting the connection. This 267 of course only applies in cases in which 0-RTT data is safe, when the 268 client is the restarting peer, and when the data to be sent is 269 idempotent. 271 The tradeoffs between resumption and keepalive need to be evaluated 272 on a per-application basis. However, in general applications should 273 use keepalives only in circumstances where continued communication is 274 highly likely; [QUIC-HTTP], for instance, recommends using PING 275 frames for keepalive only when a request is outstanding. 277 4. Use of Streams 279 QUIC's stream multiplexing feature allows applications to run 280 multiple streams over a single connection, without head-of-line 281 blocking between streams, associated at a point in time with a single 282 five-tuple. Stream data is carried within Frames, where one QUIC 283 packet on the wire can carry one or multiple stream frames. 285 Streams can be unidirectional or bidirectional, and a stream may be 286 initiated either by client or server. Only the initiator of a 287 unidirectional stream can send data on it. Due to offset encoding 288 limitations, a stream can carry a maximum of 2^62-1 bytes in each 289 direction. In the presently unlikely event that this limit is 290 reached by an application, the stream can simply be closed and 291 replaced with a new one. 293 Streams can be independently opened and closed, gracefully or by 294 error. An application can gracefully close the egress direction of a 295 stream by instructing QUIC to send a FIN bit in a STREAM frame. It 296 cannot gracefully close the ingress direction without a peer- 297 generated FIN, much like in TCP. However, an endpoint can abruptly 298 close either the ingress or egress direction; these actions are fully 299 independent of each other. 301 If a stream that is critical for an application is closed, the 302 application can generate respective error messages on the application 303 layer to inform the other end and/or the higher layer, and eventually 304 indicate QUIC to reset the connection. QUIC, however, does not need 305 to know which streams are critical, and does not provide an interface 306 for exceptional handling of any stream. 308 Mapping of application data to streams is application-specific and 309 described for HTTP/3 in [QUIC-HTTP]. In general, data that can be 310 processed independently, and therefore would suffer from head of line 311 blocking if forced to be received in order, should be transmitted 312 over separate streams. If the application requires certain data to 313 be received in order, that data should be sent on the same stream. 314 If there is a logical grouping of data chunks or messages, streams 315 can be reused, or a new stream can be opened for each chunk/message. 316 If one message is mapped to a single stream, resetting the stream to 317 expire an unacknowledged message can be used to emulate partial 318 reliability on a message basis. If a QUIC receiver has maximum 319 allowed concurrent streams open and the sender on the other end 320 indicates that more streams are needed, it doesn't automatically lead 321 to an increase of the maximum number of streams by the receiver. 322 Therefore it can be valuable to expose maximum number of allowed, 323 currently open and currently used streams to the application to make 324 the mapping of data to streams dependent on this information. 326 While a QUIC implementation must necessarily provide a way for an 327 application to send data on separate streams, it does not necessarily 328 expose stream identifiers to the application (see e.g. [QUIC-HTTP] 329 section 6) either at the sender or receiver end, so applications 330 should not assume access to these identifiers. 332 4.1. Stream versus Flow Multiplexing 334 Streams are meaningful only to the application; since stream 335 information is carried inside QUIC's encryption boundary, no 336 information about the stream(s) whose frames are carried by a given 337 packet is visible to the network. Therefore stream multiplexing is 338 not intended to be used for differentiating streams in terms of 339 network treatment. Application traffic requiring different network 340 treatment SHOULD therefore be carried over different five-tuples 341 (i.e. multiple QUIC connections). Given QUIC's ability to send 342 application data in the first RTT of a connection (if a previous 343 connection to the same host has been successfully established to 344 provide the respective credentials), the cost of establishing another 345 connection is extremely low. 347 4.2. Prioritization 349 Stream prioritization is not exposed to either the network or the 350 receiver. Prioritization is managed by the sender, and the QUIC 351 transport should provide an interface for applications to prioritize 352 streams [QUIC]. Further applications can implement their own 353 prioritization scheme on top of QUIC: an application protocol that 354 runs on top of QUIC can define explicit messages for signaling 355 priority, such as those defined for HTTP/2; it can define rules that 356 allow an endpoint to determine priority based on context; or it can 357 provide a higher level interface and leave the determination to the 358 application on top. 360 Priority handling of retransmissions can be implemented by the sender 361 in the transport layer. [QUIC] recommends to retransmit lost data 362 before new data, unless indicated differently by the application. 363 Currently, QUIC only provides fully reliable stream transmission, 364 which means that prioritization of retransmissions will be beneficial 365 in most cases, by filling in gaps and freeing up the flow control 366 window. For partially reliable or unreliable streams, priority 367 scheduling of retransmissions over data of higher-priority streams 368 might not be desirable. For such streams, QUIC could either provide 369 an explicit interface to control prioritization, or derive the 370 prioritization decision from the reliability level of the stream. 372 4.3. Flow Control Deadlocks 374 Flow control provides a means of managing access to the limited 375 buffers endpoints have for incoming data. This mechanism limits the 376 amount of data that can be in buffers in endpoints or in transit on 377 the network. However, there are several ways in which limits can 378 produce conditions that can cause a connection to either perform 379 suboptimally or deadlock. 381 Deadlocks in flow control are possible for any protocol that uses 382 QUIC, though whether they become a problem depends on how 383 implementations consume data and provide flow control credit. 384 Understanding what causes deadlocking might help implementations 385 avoid deadlocks. 387 Large messages can produce deadlocking if the recipient does not 388 process the message incrementally. If the message is larger than 389 flow control credit available and the recipient does not release 390 additional flow control credit until the entire message is received 391 and delivered, a deadlock can occur. This is possible even where 392 stream flow control limits are not reached because connection flow 393 control limits can be consumed by other streams. 395 A common flow control implementation technique is for a receiver to 396 extend credit to the sender as a the data consumer reads data. In 397 this setting, a length-prefixed message format makes it easier for 398 the data consumer to leave data unread in the receiver's buffers and 399 thereby withhold flow control credit. If flow control limits prevent 400 the remainder of a message from being sent, a deadlock will result. 401 A length prefix might also enable the detection of this sort of 402 deadlock. Where protocols have messages that might be processed as a 403 single unit, reserving flow control credit for the entire message 404 atomically ensures that this style of deadlock is less likely. 406 A data consumer can read all data as it becomes available to cause 407 the receiver to extend flow control credit to the sender and reduce 408 the chances of a deadlock. However, releasing flow control credit 409 might mean that the data consumer might need other means for holding 410 a peer accountable for the state it keeps for partially processed 411 messages. 413 Deadlocking can also occur if data on different streams is 414 interdependent. Suppose that data on one stream arrives before the 415 data on a second stream on which it depends. A deadlock can occur if 416 the first stream is left unread, preventing the receiver from 417 extending flow control credit for the second stream. To reduce the 418 likelihood of deadlock for interdependent data, the sender should 419 ensure that dependent data is not sent until the data it depends on 420 has been accounted for in both stream- and connection- level flow 421 control credit. 423 Some deadlocking scenarios might be resolved by cancelling affected 424 streams with STOP_SENDING or RST_STREAM. Cancelling some streams 425 results in the connection being terminated in some protocols. 427 5. Packetization and Latency 429 QUIC provides an interface that provides multiple streams to the 430 application; however, the application usually cannot control how data 431 transmitted over one stream is mapped into frames or how those frames 432 are bundled into packets. By default, QUIC will try to maximally 433 pack packets with one or more stream data frames to minimize 434 bandwidth consumption and computational costs (see section 13 of 435 [QUIC]). If there is not enough data available to fill a packet, 436 QUIC may even wait for a short time, to optimize bandwidth efficiency 437 instead of latency. This delay can either be pre-configured or 438 dynamically adjusted based on the observed sending pattern of the 439 application. If the application requires low latency, with only 440 small chunks of data to send, it may be valuable to indicate to QUIC 441 that all data should be send out immediately. Alternatively, if the 442 application expects to use a specific sending pattern, it can also 443 provide a suggested delay to QUIC for how long to wait before bundle 444 frames into a packet. 446 Similarly, an appliaction has usually no control about the length of 447 a QUIC packet on the wire. However, QUIC provides the ability to add 448 a padding frame to impact the packet size. This is mainly used by 449 QUIC itself in the first packet in order to ensure that the path is 450 capable of transferring packets of at least a certain size. 451 Additionally, a QUIC implementation can expose an application layer 452 interface to specify a certain packet size. This can either be used 453 by the application to force certian packet sizes in specific use 454 cases/networks, or ensure that all packets are equally sized to 455 conceal potential leakage of application layer information when the 456 data sent by the application are not greedy. Note the initial packet 457 must have a minimum size of 1200 bytes according to the QUIC 458 specification. A receiver of a smaller initial packet may reject 459 this packet in order to avoid amplification attacks. 461 6. Port Selection and Application Endpoint Discovery 463 In general, port numbers serves two purposes: "first, they provide a 464 demultiplexing identifier to differentiate transport sessions between 465 the same pair of endpoints, and second, they may also identify the 466 application protocol and associated service to which processes 467 connect" [RFC6335]. Note that the assumption that an application can 468 be identified in the network based on the port number is less true 469 today, due to encapsulation, mechanisms for dynamic port assignments 470 as well as NATs. 472 As QUIC is a general purpose transport protocol, there are no 473 requirements that servers use a particular UDP port for QUIC in 474 general. For applications with a fallback to TCP which do not 475 already have an alternate mapping to UDP, the registration (if 476 necessary) and use of the UDP port number corresponding to the TCP 477 port already registered for the application is RECOMMENDED. For 478 example, the default port for HTTP/3 [QUIC-HTTP] is UDP port 443, 479 analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. 481 Applications SHOULD define an alternate endpoint discovery mechanism 482 to allow the usage of ports other than the default. For example, 483 HTTP/3 ([QUIC-HTTP] sections 3.2 and 3.3) specifies the use of ALPN 484 [RFC7301] for service discovery which allows the server to use and 485 announce a different port number. Note that HTTP/3's ALPN token 486 ("h3") identifies not only the version of the application protocol, 487 but also the binding to QUIC as well as the version of QUIC itself; 488 this approach allows unambiguous agreement between the endpoints on 489 the protocol stack in use. 491 Note that given the prevalence of the assumption in network 492 management practice that a port number maps unambiguously to an 493 application, the use of ports that cannot easily be mapped to a 494 registered service name may lead to blocking or other interference by 495 network elements such as firewalls that rely on the port number for 496 application identification. 498 7. Connection Migration 500 QUIC supports connection migration by the client. If a lower-layer 501 address changes, a QUIC endpoint can still associate packets with an 502 existing connection based on the Connection ID (see also Section 9) 503 in the QUIC header, if present. This supports cases where address 504 information changes, such as NAT rebinding, intentional change of the 505 local interface, or based on an indication in the handshake of the 506 server for a preferred address to be used. As such if the client is 507 known or likely to sit behind a NAT, use of a connection ID for the 508 server is strongly recommended. A non-empty connection ID for the 509 server is also strongly recommended when migration is supported. 511 Currently QUIC only supports failover cases. Only one "path" can be 512 used at a time, and only when the new path is validated all traffic 513 can be switched over to that new path. Path validation means that 514 the other endpoint in required to validate the new path before use in 515 order to avoid address spoofing attacks. Path validation takes at 516 least one RTT and congestion control will also be reset on path 517 migration. Therefore migration usually has a performance impact. 519 As long as the new path is not validated only probing packets can be 520 sent. However, the probing packets can be used measure path 521 characteristics as input for the switching decision or the congestion 522 controller on the new path. 524 Only the client can actively migrate. However, servers can indicate 525 during the handshake that they prefer to transfer the connection to a 526 different address after the handshake, e.g. to move from an address 527 that is shared by multiple servers to an address that is unique to 528 the server instance. The server can provide an IPv4 and an IPv6 529 address in a transport parameter during the TLS handshake and the 530 client can select between the two if both are provided. See also 531 Section 9.6 of [QUIC]. 533 8. Connection closure 535 QUIC connections are closed either by expiration of an idle timeout, 536 as determined by transport parameters, or by an explicit indication 537 of the application that a connection should be closed (immediate 538 close). While data could still be received after the immediate close 539 has been initiated by one endpoint (for a limited time period), the 540 expectation is that an immediate close was negotiated at the 541 application layer and therefore no additional data is expected from 542 both sides. 544 An immidate close will emit an CONNECTION_CLOSE frame. This frames 545 has two sets of types: one for QUIC internal problems that might lead 546 to connection closure, and one for closures initiated by the 547 application. An application using QUIC can define application- 548 specific error codes, e.g. see [QUIC-HTTP] section 8.1. In the case 549 of a grateful shut-down initiated by the application after 550 application layer negotiation, a NO_ERROR code is expected. Further, 551 the CONNECTION_CLOSE frame provides an optional reason field, that 552 can be used to append human-readable information to an error code. 553 Note that QUIC RESET_STREAM and STOP_SENDING frames provide similar 554 capablities. Usually application error codes are defined to be 555 applicabile to all three frames. 557 Alternatively, a QUIC connection can be silently closed by each 558 endpoint separately after an idle timeout. If enabled as indicated 559 by a transport parameter in the handshake, the idle timeout is 560 announced for each endpoint during connection establishment and the 561 effective value for this connection is the minimum of the two 562 advertised values. An application therefore should be able to 563 configure its own maximum value as well as have access to the 564 computed minimum value for this connection. An application may 565 adjust the maximum idle timeout based on the number of open or 566 expected connections as shorter timeout values may free-up memory 567 more quickly. If an application desires to keep the connection open 568 for longer than the announced timeout, it can send keep-alives 569 messages, or a QUIC implementation may provide an option to defer the 570 time-out to avoid unnecessary load, as specified in Section 10.2.2 of 571 [QUIC]. See Section 3.3 for further guidance on keep-alives. 573 9. Information exposure and the Connection ID 575 QUIC exposes some information to the network in the unencrypted part 576 of the header, either before the encryption context is established, 577 because the information is intended to be used by the network. QUIC 578 has a long header that is used during connection establishment and 579 for other control processes, and a short header that may be used for 580 data transmission in an established connection. While the long 581 header always exposes some information (such as the version and 582 Connection IDs), the short header exposes at most only a single 583 Connection ID. 585 Note that the Connection ID in the short header may be omitted. This 586 is a per-connection configuration option; if the Connection ID is not 587 present, then the peer omitting the connection ID needs to use the 588 same local address for the lifetime of the connection and connection 589 migration is not supported for that direction of the connection. 591 9.1. Server-Generated Connection ID 593 QUIC supports a server-generated Connection ID, transmitted to the 594 client during connection establishment (see Section 6.1 of [QUIC]). 595 Servers behind load balancers may need to change the Connection ID 596 during the handshake, encoding the identity of the server or 597 information about its load balancing pool, in order to support 598 stateless load balancing. Once the server generates a Connection ID 599 that encodes its identity, every CDN load balancer would be able to 600 forward the packets to that server without retaining connection 601 state. 603 9.2. Mitigating Timing Linkability with Connection ID Migration 605 While sufficiently robust connection ID generation schemes will 606 mitigate linkability issues, they do not provide full protection. 607 Analysis of the lifetimes of six-tuples (source and destination 608 addresses as well as the migrated CID) may expose these links anyway. 610 In the limit where connection migration in a server pool is rare, it 611 is trivial for an observer to associate two connection IDs. 612 Conversely, in the opposite limit where every server handles multiple 613 simultaneous migrations, even an exposed server mapping may be 614 insufficient information. 616 The most efficient mitigation for these attacks is operational, 617 either by using a load balancing architecture that loads more flows 618 onto a single server-side address, by coordinating the timing of 619 migrations to attempt to increase the number of simultaneous 620 migrations at a given time, or through other means. 622 9.3. Using Server Retry for Redirection 624 QUIC provides a Server Retry packet that can be sent by a server in 625 response to the Client Initial packet. The server may choose a new 626 Connection ID in that packet and the client will retry by sending 627 another Client Initial packet with the server-selected Connection ID. 628 This mechanism can be used to redirect a connection to a different 629 server, e.g. due to performance reasons or when servers in a server 630 pool are upgraded gradually, and therefore may support different 631 versions of QUIC. In this case, it is assumed that all servers 632 belonging to a certain pool are served in cooperation with load 633 balancers that forward the traffic based on the Connection ID. A 634 server can choose the Connection ID in the Server Retry packet such 635 that the load balancer will redirect the next Client Initial packet 636 to a different server in that pool. Alternatively the load balancer 637 can directly offer a Retry services as further described in 638 [QUIC-LB]. 640 [RFC5077] Section 4 describes an example approach for constructing 641 TLS resumption tickets that can be also applied for validation 642 tokens, however, the use of more modern cryptographic algorithms is 643 highly recommended. 645 10. Use of Versions and Cryptographic Handshake 647 Versioning in QUIC may change the protocol's behavior completely, 648 except for the meaning of a few header fields that have been declared 649 to be invariant [QUIC-INVARIANTS]. A version of QUIC with a higher 650 version number will not necessarily provide a better service, but 651 might simply provide a different feature set. As such, an 652 application needs to be able to select which versions of QUIC it 653 wants to use. 655 A new version could use an encryption scheme other than TLS 1.3 or 656 higher. [QUIC] specifies requirements for the cryptographic 657 handshake as currently realized by TLS 1.3 and described in a 658 separate specification [QUIC-TLS]. This split is performed to enable 659 light-weight versioning with different cryptographic handshakes. 661 11. Enabling New Versions 663 QUIC provides integrity protection for its version negotiation 664 process. This process assumes that the set of versions that a server 665 supports is fixed. This complicates the process for deploying new 666 QUIC versions or disabling old versions when servers operate in 667 clusters. 669 A server that rolls out a new version of QUIC can do so in three 670 stages. Each stage is completed across all server instances before 671 moving to the next stage. 673 In the first stage of deployment, all server instances start 674 accepting new connections with the new version. The new version can 675 be enabled progressively across a deployment, which allows for 676 selective testing. This is especially useful when the new version is 677 compatible with an old version, because the new version is more 678 likely to be used. 680 While enabling the new version, servers do not advertise the new 681 version in any Version Negotiation packets they send. This prevents 682 clients that receive a Version Negotiation packet from attempting to 683 connect to server instances that might not have the new version 684 enabled. 686 During the initial deployment, some clients will have received 687 Version Negotiation packets that indicate that the server does not 688 support the new version. Other clients might have successfully 689 connected with the new version and so will believe that the server 690 supports the new version. Therefore, servers need to allow for this 691 ambiguity when validating the negotiated version. 693 The second stage of deployment commences once all server instances 694 are able accept new connections with the new version. At this point, 695 all servers can start sending the new version in Version Negotiation 696 packets. 698 During the second stage, the server still allows for the possibility 699 that some clients believe the new version to be available and some do 700 not. This state will persist only for as long as any Version 701 Negotiation packets take to be transmitted and responded to. So the 702 third stage can follow after a relatively short delay. 704 The third stage completes the process by enabling validation of the 705 negotiation version as though the new version were disabled. 707 The process for disabling an old version or rolling back the 708 introduction of a new version uses the same process in reverse. 709 Servers disable validation of the old version, stop sending the old 710 version in Version Negotiation packets, then the old version is no 711 longer accepted. 713 12. IANA Considerations 715 This document has no actions for IANA; however, note that Section 6 716 recommends that application bindings to QUIC for applications using 717 TCP register UDP ports analogous to their existing TCP registrations. 719 13. Security Considerations 721 See the security considerations in [QUIC] and [QUIC-TLS]; the 722 security considerations for the underlying transport protocol are 723 relevant for applications using QUIC, as well. 725 Application developers should note that any fallback they use when 726 QUIC cannot be used due to network blocking of UDP SHOULD guarantee 727 the same security properties as QUIC; if this is not possible, the 728 connection SHOULD fail to allow the application to explicitly handle 729 fallback to a less-secure alternative. See Section 2. 731 14. Contributors 733 Igor Lubashev contributed text to Section 9 on server-selected 734 Connection IDs. 736 15. Acknowledgments 738 This work is partially supported by the European Commission under 739 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 740 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 741 for Education, Research, and Innovation under contract no. 15.0268. 742 This support does not imply endorsement. 744 16. References 746 16.1. Normative References 748 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 749 and Secure Transport", Work in Progress, Internet-Draft, 750 draft-ietf-quic-transport-32, 20 October 2020, 751 . 754 [QUIC-INVARIANTS] 755 Thomson, M., "Version-Independent Properties of QUIC", 756 Work in Progress, Internet-Draft, draft-ietf-quic- 757 invariants-11, 24 September 2020, . 760 [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 761 Work in Progress, Internet-Draft, draft-ietf-quic-tls-32, 762 20 October 2020, . 765 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 766 Requirement Levels", BCP 14, RFC 2119, 767 DOI 10.17487/RFC2119, March 1997, 768 . 770 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 771 Cheshire, "Internet Assigned Numbers Authority (IANA) 772 Procedures for the Management of the Service Name and 773 Transport Protocol Port Number Registry", BCP 165, 774 RFC 6335, DOI 10.17487/RFC6335, August 2011, 775 . 777 [TLS13] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 778 Work in Progress, Internet-Draft, draft-ietf-quic-tls-32, 779 20 October 2020, . 782 16.2. Informative References 784 [Edeline16] 785 Edeline, K., Kuehlewind, M., Trammell, B., Aben, E., and 786 B. Donnet, "Using UDP for Internet Transport Evolution 787 (arXiv preprint 1612.07816)", 22 December 2016, 788 . 790 [Hatonen10] 791 Hatonen, S., Nyrhinen, A., Eggert, L., Strowes, S., 792 Sarolahti, P., and M. Kojo, "An experimental study of home 793 gateway characteristics (Proc. ACM IMC 2010)", October 794 2010. 796 [HTTP-RETRY] 797 Nottingham, M., "Retrying HTTP Requests", Work in 798 Progress, Internet-Draft, draft-nottingham-httpbis-retry- 799 01, 1 February 2017, . 802 [I-D.nottingham-httpbis-retry] 803 Nottingham, M., "Retrying HTTP Requests", Work in 804 Progress, Internet-Draft, draft-nottingham-httpbis-retry- 805 01, 1 February 2017, . 808 [PaaschNanog] 809 Paasch, C., "Network Support for TCP Fast Open (NANOG 67 810 presentation)", 13 June 2016, 811 . 814 [QUIC-HTTP] 815 Bishop, M., "Hypertext Transfer Protocol Version 3 816 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 817 quic-http-32, 20 October 2020, . 820 [QUIC-LB] Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC 821 Connection IDs", Work in Progress, Internet-Draft, draft- 822 ietf-quic-load-balancers-05, 30 October 2020, 823 . 826 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 827 "Transport Layer Security (TLS) Session Resumption without 828 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 829 January 2008, . 831 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 832 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 833 RFC 5382, DOI 10.17487/RFC5382, October 2008, 834 . 836 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 837 "Transport Layer Security (TLS) Application-Layer Protocol 838 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 839 July 2014, . 841 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 842 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 843 March 2017, . 845 [Swett16] Swett, I., "QUIC Deployment Experience at Google (IETF96 846 QUIC BoF presentation)", 20 July 2016, 847 . 850 [Trammell16] 851 Trammell, B. and M. Kuehlewind, "Internet Path 852 Transparency Measurements using RIPE Atlas (RIPE72 MAT 853 presentation)", 25 May 2016, . 856 Authors' Addresses 858 Mirja Kuehlewind 859 Ericsson 861 Email: mirja.kuehlewind@ericsson.com 863 Brian Trammell 864 Google 865 Gustav-Gull-Platz 1 866 CH- 8004 Zurich 867 Switzerland 869 Email: ietf@trammell.ch