idnits 2.17.1 draft-ietf-quic-applicability-11.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 date (21 April 2021) is 1100 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-httpbis-priority-03 == Outdated reference: A later version (-14) exists of draft-ietf-quic-version-negotiation-03 == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-02 == Outdated reference: A later version (-19) exists of draft-ietf-taps-arch-09 == Outdated reference: A later version (-19) exists of draft-ietf-quic-load-balancers-06 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 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: 23 October 2021 Google 6 21 April 2021 8 Applicability of the QUIC Transport Protocol 9 draft-ietf-quic-applicability-11 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 23 October 2021. 36 Copyright Notice 38 Copyright (c) 2021 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 2. The Necessity of Fallback . . . . . . . . . . . . . . . . . . 3 54 3. Zero RTT . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 4 56 3.2. Session resumption versus Keep-alive . . . . . . . . . . 5 57 4. Use of Streams . . . . . . . . . . . . . . . . . . . . . . . 7 58 4.1. Stream versus Flow Multiplexing . . . . . . . . . . . . . 8 59 4.2. Prioritization . . . . . . . . . . . . . . . . . . . . . 9 60 4.3. Ordered and Reliable Delivery . . . . . . . . . . . . . . 9 61 4.4. Flow Control Deadlocks . . . . . . . . . . . . . . . . . 10 62 4.5. Stream Limit Commitments . . . . . . . . . . . . . . . . 11 63 5. Packetization and Latency . . . . . . . . . . . . . . . . . . 12 64 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 13 65 7. ACK-only packets on constrained links . . . . . . . . . . . . 14 66 8. Port Selection and Application Endpoint Discovery . . . . . . 14 67 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 15 68 10. Connection Termination . . . . . . . . . . . . . . . . . . . 16 69 11. Information Exposure and the Connection ID . . . . . . . . . 16 70 11.1. Server-Generated Connection ID . . . . . . . . . . . . . 17 71 11.2. Mitigating Timing Linkability with Connection ID 72 Migration . . . . . . . . . . . . . . . . . . . . . . . 17 73 11.3. Using Server Retry for Redirection . . . . . . . . . . . 18 74 12. Quality of Service (QoS) and DSCP . . . . . . . . . . . . . . 18 75 13. Use of Versions and Cryptographic Handshake . . . . . . . . . 19 76 14. Enabling New Versions . . . . . . . . . . . . . . . . . . . . 19 77 15. Unreliable Datagram Service over QUIC . . . . . . . . . . . . 20 78 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 79 17. Security Considerations . . . . . . . . . . . . . . . . . . . 21 80 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 81 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 82 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 20.1. Normative References . . . . . . . . . . . . . . . . . . 21 84 20.2. Informative References . . . . . . . . . . . . . . . . . 22 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 87 1. Introduction 89 QUIC [QUIC] is a new transport protocol providing a number of 90 advanced features. While initially designed for the HTTP use case, 91 it provides capabilities that can be used with a much wider variety 92 of applications. QUIC is encapsulated in UDP. QUIC version 1 93 integrates TLS 1.3 [TLS13] to encrypt all payload data and most 94 control information. The version of HTTP that uses QUIC is known as 95 HTTP/3 [QUIC-HTTP]. 97 This document provides guidance for application developers that want 98 to use the QUIC protocol without implementing it on their own. This 99 includes general guidance for applications operating over HTTP/3 or 100 directly over QUIC. 102 In the following sections we discuss specific caveats to QUIC's 103 applicability, and issues that application developers must consider 104 when using QUIC as a transport for their application. 106 2. The Necessity of Fallback 108 QUIC uses UDP as a substrate. This enables userspace implementation 109 and permits traversal of network middleboxes (including NAT) without 110 requiring updates to existing network infrastructure. 112 While recent measurements have shown no evidence of a widespread, 113 systematic disadvantage of UDP traffic compared to TCP in the 114 Internet [Edeline16], somewhere between three [Trammell16] and five 115 [Swett16] percent of networks block all 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. In the case of HTTP, 119 this fallback is TLS over TCP. 121 The IETF TAPS specifications [I-D.ietf-taps-arch] describe a system 122 with a common API for multiple protocols and some of the implications 123 of fallback between these different protocols, specifically 124 precluding fallback to insecure protocols or to weaker versions of 125 secure protocols. 127 An application that implements fallback needs to consider the 128 security consequences. A fallback to TCP and TLS exposes control 129 information to modification and manipulation in the network. Further 130 downgrades to older TLS versions than used in QUIC, which is 1.3, 131 might result in significantly weaker cryptographic protection. For 132 example, the results of protocol negotiation [RFC7301] only have 133 confidentiality protection if TLS 1.3 is used. 135 These applications must operate, perhaps with impaired functionality, 136 in the absence of features provided by QUIC not present in the 137 fallback protocol. For fallback to TLS over TCP, the most obvious 138 difference is that TCP does not provide stream multiplexing and 139 therefore stream multiplexing would need to be implemented in the 140 application layer if needed. Further, TCP implementations and 141 network paths often do not support the Fast Open option [RFC7413], 142 which enables sending of payload data together with the first control 143 packet of a new connection as also provided by 0-RTT session 144 resumption in QUIC. Note that there is some evidence of middleboxes 145 blocking SYN data even if TFO was successfully negotiated (see 146 [PaaschNanog]). And even if Fast Open successfully operates end-to- 147 end, it is limited to a single packet of TLS handshake and 148 application data, unlike QUIC 0-RTT. 150 Moreover, while encryption (in this case TLS) is inseparably 151 integrated with QUIC, TLS negotiation over TCP can be blocked. If 152 TLS over TCP cannot be supported, the connection should be aborted, 153 and the application then ought to present a suitable prompt to the 154 user that secure communication is unavailable. 156 In summary, any fallback mechanism is likely to impose a degradation 157 of performance and can degrade security; however, fallback must not 158 silently violate the application's expectation of confidentiality or 159 integrity of its payload data. 161 3. Zero RTT 163 QUIC provides for 0-RTT connection establishment. Though the same 164 facility exists in TLS 1.3 with TCP, 0-RTT presents opportunities and 165 challenges for applications using QUIC. 167 A transport protocol that provides 0-RTT connection establishment is 168 qualitatively different than one that does not from the point of view 169 of the application using it. Relative trade-offs between the cost of 170 closing and reopening a connection and trying to keep it open are 171 different; see Section 3.2. 173 An application needs to deliberately choose to use 0-RTT, as 0-RTT 174 carries a risk of replay attack. Application protocols that use 175 0-RTT require a profile that describes the types of information that 176 can be safely sent. For HTTP, this profile is described in 177 [HTTP-REPLAY]. 179 3.1. Replay Attacks 181 Retransmission or (malicious) replay of data contained in 0-RTT 182 packets could cause the server side to receive two copies of the same 183 data. 185 Application data sent by the client in 0-RTT packets could be 186 processed more than once if it is replayed. Applications need to be 187 aware of what is safe to send in 0-RTT. Application protocols that 188 seek to enable the use of 0-RTT need a careful analysis and a 189 description of what can be sent in 0-RTT; see Section 5.6 of 190 [QUIC-TLS]. 192 In some cases, it might be sufficient to limit application data sent 193 in 0-RTT to that which only causes actions at a server that are known 194 to be free of lasting effect. Initiating data retrieval or 195 establishing configuration are examples of actions that could be 196 safe. Idempotent operations - those for which repetition has the 197 same net effect as a single operation - might be safe. However, it 198 is also possible to combine individually idempotent operations into a 199 non-idempotent sequence of operations. 201 Once a server accepts 0-RTT data there is no means of selectively 202 discarding data that is received. However, protocols can define ways 203 to reject individual actions that might be unsafe if replayed. 205 Some TLS implementations and deployments might be able to provide 206 partial or even complete replay protection, which could be used to 207 manage replay risk. 209 3.2. Session resumption versus Keep-alive 211 Because QUIC is encapsulated in UDP, applications using QUIC must 212 deal with short network idle timeouts. Deployed stateful middleboxes 213 will generally establish state for UDP flows on the first packet 214 sent, and keep state for much shorter idle periods than for TCP. 215 [RFC5382] suggests a TCP idle period of at least 124 minutes, though 216 there is not evidence of widespread implementation of this guideline 217 in the literature. Short network timeout for UDP, however, is well- 218 documented. According to a 2010 study ([Hatonen10]), UDP 219 applications can assume that any NAT binding or other state entry can 220 expire after just thirty seconds of inactivity. Section 3.5 of 221 [RFC8085] further discusses keep-alive intervals for UDP: it requires 222 a minimum value of 15 seconds, but recommends larger values, or 223 omitting keep-alive entirely. 225 By using a connection ID, QUIC is designed to be robust to NAT 226 address rebinding after a timeout. However, this only helps if one 227 endpoint maintains availability at the address its peer uses, and the 228 peer is the one to send after the timeout occurs. 230 Some QUIC connections might not be robust to NAT rebinding because 231 the routing infrastructure (in particular, load balancers) uses the 232 address/port four-tuple to direct traffic. Furthermore, middleboxes 233 with functions other than address translation could still affect the 234 path. In particular, some firewalls do not admit server traffic for 235 which the firewall has no recent state for a corresponding packet 236 sent from the client. 238 QUIC applications can adjust idle periods to manage the risk of 239 timeout. Idle periods and the network idle timeout are distinct from 240 the connection idle timeout, which is defined as the minimum of 241 either endpoint's idle timeout parameter; see Section 10.1 of 242 [QUIC]). There are three options: 244 * Ignore the issue, if the application-layer protocol consists only 245 of interactions with no or very short idle periods, or the 246 protocol's resistance to NAT rebinding is sufficient. 248 * Ensure there are no long idle periods. 250 * Resume the session after a long idle period, using 0-RTT 251 resumption when appropriate. 253 The first strategy is the easiest, but it only applies to certain 254 applications. 256 Either the server or the client in a QUIC application can send PING 257 frames as keep-alives, to prevent the connection and any on-path 258 state from timing out. Recommendations for the use of keep-alives 259 are application-specific, mainly depending on the latency 260 requirements and message frequency of the application. In this case, 261 the application mapping must specify whether the client or server is 262 responsible for keeping the application alive. While [Hatonen10] 263 suggests that 30 seconds might be a suitable value for the public 264 Internet when a NAT is on path, larger values are preferable if the 265 deployment can consistently survive NAT rebinding or is known to be 266 in a controlled environment (e.g. data centres) in order to lower 267 network and computational load. 269 Sending PING frames more frequently than every 30 seconds over long 270 idle periods may result in excessive unproductive traffic in some 271 situations, and to unacceptable power usage for power-constrained 272 (mobile) devices. Additionally, timeouts shorter than 30 seconds can 273 make it harder to handle transient network interruptions, such as VM 274 migration or coverage loss during mobilty. See [RFC8085], especially 275 Section 3.5. 277 Alternatively, the client (but not the server) can use session 278 resumption instead of sending keepalive traffic. In this case, a 279 client that wants to send data to a server over a connection idle 280 longer than the server's idle timeout (available from the 281 idle_timeout transport parameter) can simply reconnect. When 282 possible, this reconnection can use 0-RTT session resumption, 283 reducing the latency involved with restarting the connection. Of 284 course, this approach is only valid in cases in which 0-RTT data is 285 safe, when the client is the restarting peer, and when the data to be 286 sent is idempotent. It is also not applicable when the application 287 binds external state to the connection, as this state cannot reliably 288 be transferred to a resumed connection. 290 The tradeoffs between resumption and keep-alives need to be evaluated 291 on a per-application basis. In general, applications should use 292 keep-alives only in circumstances where continued communication is 293 highly likely; [QUIC-HTTP], for instance, recommends using keep- 294 alives only when a request is outstanding. 296 4. Use of Streams 298 QUIC's stream multiplexing feature allows applications to run 299 multiple streams over a single connection, without head-of-line 300 blocking between streams, associated at a point in time with a single 301 five-tuple. Stream data is carried within frames, where one QUIC 302 packet on the wire can carry one or multiple stream frames. 304 Streams can be unidirectional or bidirectional, and a stream may be 305 initiated either by client or server. Only the initiator of a 306 unidirectional stream can send data on it. 308 Streams and connections can each carry a maximum of 2^62-1 bytes in 309 each direction, due to encoding limitations on stream offsets and 310 connection flow control limits. In the presently unlikely event that 311 this limit is reached by an application, a new connection would need 312 to be established. 314 Streams can be independently opened and closed, gracefully or 315 abruptly. An application can gracefully close the egress direction 316 of a stream by instructing QUIC to send a FIN bit in a STREAM frame. 317 It cannot gracefully close the ingress direction without a peer- 318 generated FIN, much like in TCP. However, an endpoint can abruptly 319 close the egress direction or request that its peer abruptly close 320 the ingress direction; these actions are fully independent of each 321 other. 323 QUIC does not provide an interface for exceptional handling of any 324 stream. If a stream that is critical for an application is closed, 325 the application can generate error messages on the application layer 326 to inform the other end and/or the higher layer, which can eventually 327 terminate the QUIC connection. 329 Mapping of application data to streams is application-specific and 330 described for HTTP/3 in [QUIC-HTTP]. There are a few general 331 principles to apply when designing an application's use of streams: 333 * A single stream provides ordering. If the application requires 334 certain data to be received in order, that data should be sent on 335 the same stream. There is no guarantee of transmission, 336 reception, or delivery order across streams. 338 * Multiple streams provide concurrency. Data that can be processed 339 independently, and therefore would suffer from head of line 340 blocking if forced to be received in order, should be transmitted 341 over separate streams. 343 * Streams can provide message orientation, and allow messages to be 344 cancelled. If one message is mapped to a single stream, resetting 345 the stream to expire an unacknowledged message can be used to 346 emulate partial reliability for that message. 348 If a QUIC receiver has opened the maximum allowed concurrent streams, 349 and the sender indicates that more streams are needed, it does not 350 automatically lead to an increase of the maximum number of streams by 351 the receiver. Therefore, an application can use the maximum number 352 of allowed, currently open, and currently used streams when 353 determining how to map data to streams. 355 QUIC assigns a numerical identifier to each stream, called the Stream 356 ID. While the relationship between these identifiers and stream 357 types is clearly defined in version 1 of QUIC, future versions might 358 change this relationship for various reasons. QUIC implementations 359 should expose the properties of each stream (which endpoint initiated 360 the stream, whether the stream is unidirectional or bidirectional, 361 the Stream ID used for the stream); applications should query for 362 these properties rather than attempting to infer them from the Stream 363 ID. 365 The method of allocating stream identifiers to streams opened by the 366 application might vary between transport implementations. Therefore, 367 an application should not assume a particular stream ID will be 368 assigned to a stream that has not yet been allocated. For example, 369 HTTP/3 uses Stream IDs to refer to streams that have already been 370 opened, but makes no assumptions about future Stream IDs or the way 371 in which they are assigned Section 6 of [QUIC-HTTP]). 373 4.1. Stream versus Flow Multiplexing 375 Streams are meaningful only to the application; since stream 376 information is carried inside QUIC's encryption boundary, no 377 information about the stream(s) whose frames are carried by a given 378 packet is visible to the network. Therefore stream multiplexing is 379 not intended to be used for differentiating streams in terms of 380 network treatment. Application traffic requiring different network 381 treatment should therefore be carried over different five-tuples 382 (i.e. multiple QUIC connections). Given QUIC's ability to send 383 application data in the first RTT of a connection (if a previous 384 connection to the same host has been successfully established to 385 provide the necessary credentials), the cost of establishing another 386 connection is extremely low. 388 4.2. Prioritization 390 Stream prioritization is not exposed to either the network or the 391 receiver. Prioritization is managed by the sender, and the QUIC 392 transport should provide an interface for applications to prioritize 393 streams [QUIC]. Applications can implement their own prioritization 394 scheme on top of QUIC: an application protocol that runs on top of 395 QUIC can define explicit messages for signaling priority, such as 396 those defined in [I-D.draft-ietf-httpbis-priority] for HTTP; it can 397 define rules that allow an endpoint to determine priority based on 398 context; or it can provide a higher level interface and leave the 399 determination to the application on top. 401 Priority handling of retransmissions can be implemented by the sender 402 in the transport layer. [QUIC] recommends retransmitting lost data 403 before new data, unless indicated differently by the application. 404 Currently, QUIC only provides fully reliable stream transmission, 405 which means that prioritization of retransmissions will be beneficial 406 in most cases, by filling in gaps and freeing up the flow control 407 window. For partially reliable or unreliable streams, priority 408 scheduling of retransmissions over data of higher-priority streams 409 might not be desirable. For such streams, QUIC could either provide 410 an explicit interface to control prioritization, or derive the 411 prioritization decision from the reliability level of the stream. 413 4.3. Ordered and Reliable Delivery 415 QUIC streams enable ordered and reliable delivery. Though it is 416 possible for an implementation to provide options that use streams 417 for partial reliability or out-of-order delivery, most 418 implementations will assume that data is reliably delivered in order. 420 Under this assumption, an endpoint that receives stream data might 421 not make forward progress until data that is contiguous with the 422 start of a stream is available. In particular, a receiver might 423 withhold flow control credit until contiguous data is delivered to 424 the application; see Section 2.2 of [QUIC]. To support this receive 425 logic, an endpoint will send stream data until it is acknowledged, 426 ensuring that data at the start of the stream is sent and 427 acknowledged first. 429 An endpoint that uses a different sending behavior and does not 430 negotiate that change with its peer might encounter performance 431 issues or deadlocks. 433 4.4. Flow Control Deadlocks 435 QUIC flow control provides a means of managing access to the limited 436 buffers endpoints have for incoming data. This mechanism limits the 437 amount of data that can be in buffers in endpoints or in transit on 438 the network. However, there are several ways in which limits can 439 produce conditions that can cause a connection to either perform 440 suboptimally or deadlock. 442 Deadlocks in flow control are possible for any protocol that uses 443 QUIC, though whether they become a problem depends on how 444 implementations consume data and provide flow control credit. 445 Understanding what causes deadlocking might help implementations 446 avoid deadlocks. 448 The size and rate of transport flow control credit updates can affect 449 performance. Applications that use QUIC often have a data consumer 450 that reads data from transport buffers. Some implementations might 451 have independent transport-layer and application-layer receive 452 buffers. Consuming data does not always imply it is immediately 453 processed. However, a common flow control implementation technique 454 is to extend credit to the sender, by emitting MAX_DATA and/or 455 MAX_STREAM_DATA frames, as data is consumed. Delivery of these 456 frames is affected by the latency of the back channel from the 457 receiver to the data sender. If credit is not extended in a timely 458 manner, the sending application can be blocked, effectively 459 throttling the sender. 461 Large application messages can produce deadlocking if the recipient 462 does not read data from the transport incrementally. If the message 463 is larger than the flow control credit available and the recipient 464 does not release additional flow control credit until the entire 465 message is received and delivered, a deadlock can occur. This is 466 possible even where stream flow control limits are not reached 467 because connection flow control limits can be consumed by other 468 streams. 470 A length-prefixed message format makes it easier for a data consumer 471 to leave data unread in the transport buffer and thereby withhold 472 flow control credit. If flow control limits prevent the remainder of 473 a message from being sent, a deadlock will result. A length prefix 474 might also enable the detection of this sort of deadlock. Where 475 application protocols have messages that might be processed as a 476 single unit, reserving flow control credit for the entire message 477 atomically makes this style of deadlock less likely. 479 A data consumer can eagerly read all data as it becomes available, in 480 order to make the receiver extend flow control credit and reduce the 481 chances of a deadlock. However, such a data consumer might need 482 other means for holding a peer accountable for the additional state 483 it keeps for partially processed messages. 485 Deadlocking can also occur if data on different streams is 486 interdependent. Suppose that data on one stream arrives before the 487 data on a second stream on which it depends. A deadlock can occur if 488 the first stream is left unread, preventing the receiver from 489 extending flow control credit for the second stream. To reduce the 490 likelihood of deadlock for interdependent data, the sender should 491 ensure that dependent data is not sent until the data it depends on 492 has been accounted for in both stream- and connection- level flow 493 control credit. 495 Some deadlocking scenarios might be resolved by cancelling affected 496 streams with STOP_SENDING or RESET_STREAM. Cancelling some streams 497 results in the connection being terminated in some protocols. 499 4.5. Stream Limit Commitments 501 QUIC endpoints are responsible for communicating the cumulative limit 502 of streams they would allow to be opened by their peer. Initial 503 limits are advertised using the initial_max_streams_bidi and 504 initial_max_streams_uni transport parameters. As streams are opened 505 and closed they are consumed and the cumulative total is incremented. 506 Limits can be increased using the MAX_STREAMS frame but there is no 507 mechanism to reduce limits. Once stream limits are reached, no more 508 streams can be opened, which prevents applications using QUIC from 509 making further progress. At this stage connections can be terminated 510 via idle timeout or explicit close; see Section 10). 512 An application that uses QUIC might communicate a cumulative stream 513 limit but require the connection to be closed before the limit is 514 reached. For example, to stop the server to perform scheduled 515 maintenance. Immediate connection close causes abrupt closure of 516 actively used streams. Depending on how an application uses QUIC 517 streams, this could be undesirable or detrimental to behavior or 518 performance. A more graceful closure technique is to stop sending 519 increases to stream limits and allow the connection to naturally 520 terminate once remaining streams are consumed. However, the period 521 of time it takes to do so is dependent on the client and an 522 unpredictable closing period might not fit application or operational 523 needs. Applications using QUIC can be conservative with open stream 524 limits in order to reduce the commitment and indeterminism. However, 525 being overly conservative with stream limits affects stream 526 concurrency. Balancing these aspects can be specific to applications 527 and their deployments. Instead of relying on stream limits to avoid 528 abrupt closure, an application-layer graceful close mechanism can be 529 used to communicate the intention to explicitly close the connection 530 at some future point. 532 HTTP/3 provides such a mechanism using the GOWAWAY frame. In HTTP/3, 533 when the GOAWAY frame is received by a client, it stops opening new 534 streams even if the cumulative stream limit would allow. Instead the 535 client would create a new connection on which to open further 536 streams. Once all streams are closed on the old connection, it can 537 be terminated safely by a connection close or after expiration of the 538 idle time out (see also Section 10). 540 5. Packetization and Latency 542 QUIC exposes an interface that provides multiple streams to the 543 application; however, the application usually cannot control how data 544 transmitted over those streams is mapped into frames or how those 545 frames are bundled into packets. 547 By default, many implementations will try to maximally pack QUIC 548 packets DATA frames from one or more streams to minimize bandwidth 549 consumption and computational costs (see Section 13 of [QUIC]). If 550 there is not enough data available to fill a packet, an 551 implementation might wait for a short time, to optimize bandwidth 552 efficiency instead of latency. This delay can either be pre- 553 configured or dynamically adjusted based on the observed sending 554 pattern of the application. 556 If the application requires low latency, with only small chunks of 557 data to send, it may be valuable to indicate to QUIC that all data 558 should be send out immediately. Alternatively, if the application 559 expects to use a specific sending pattern, it can also provide a 560 suggested delay to QUIC for how long to wait before bundle frames 561 into a packet. 563 Similarly, an application has usually no control about the length of 564 a QUIC packet on the wire. QUIC provides the ability to add a 565 PADDING frame to arbitrarily increase the size of packets. Padding 566 is used by QUIC to ensure that the path is capable of transferring 567 datagrams of at least a certain size, during the handshake (see 568 Sections 8.1 and 14.1 of [QUIC]) and for path validation after 569 connection migration (see Section 8.2 of [QUIC]) as well as for 570 Datagram Packetization Layer PMTU Discovery (DPLMTUD) (see 571 Section 14.3 of [QUIC]). 573 Padding can also be used by an application to reduce leakage of 574 information about the data that is sent. A QUIC implementation can 575 expose an interface that allows an application layer to specify how 576 to apply padding. 578 6. Error Handling 580 QUIC recommends that endpoints signal any detected errors to the 581 peer. Errors can occur at the transport level and the application 582 level. Transport errors, such as a protocol violation, affect the 583 entire connection. Applications that use QUIC can define their own 584 error detection and signaling (see, for example, Section 8 of 585 [QUIC-HTTP]). Application errors can affect an entire connection or 586 a single stream. 588 QUIC defines an error code space that is used for error handling at 589 the transport layer. QUIC encourages endpoints to use the most 590 specific code, although any applicable code is permitted, including 591 generic ones. 593 Applications using QUIC define an error code space that is 594 independent from QUIC or other applications (see, for example, 595 Section 8.1 of [QUIC-HTTP]). The values in an application error code 596 space can be reused across connection-level and stream-level errors. 598 Connection errors lead to connection termination. They are signaled 599 using a CONNECTION_CLOSE frame, which contains an error code and a 600 reason field that can be zero length. Different types of 601 CONNECTION_CLOSE frame are used to signal transport and application 602 errors. 604 Stream errors lead to stream termination. The are signaled using 605 STOP_SENDING or RESET_STREAM frames, which contain only an error 606 code. 608 7. ACK-only packets on constrained links 610 The cost of sending acknowledgments - in processing cost or link 611 utilization - could be a significant proportion of available 612 resources if these resources are constrained. Reducing the rate at 613 which acknowledgments are generated can preserve these resources and 614 improve overall performance, for both network processing as well as 615 application-relevant metrics. 617 8. Port Selection and Application Endpoint Discovery 619 In general, port numbers serve two purposes: "first, they provide a 620 demultiplexing identifier to differentiate transport sessions between 621 the same pair of endpoints, and second, they may also identify the 622 application protocol and associated service to which processes 623 connect" [RFC6335]. The assumption that an application can be 624 identified in the network based on the port number is less true today 625 due to encapsulation, mechanisms for dynamic port assignments, and 626 NATs. 628 As QUIC is a general-purpose transport protocol, there are no 629 requirements that servers use a particular UDP port for QUIC. For 630 applications with a fallback to TCP that do not already have an 631 alternate mapping to UDP, usually the registration (if necessary) and 632 use of the UDP port number corresponding to the TCP port already 633 registered for the application is appropriate. For example, the 634 default port for HTTP/3 [QUIC-HTTP] is UDP port 443, analogous to 635 HTTP/1.1 or HTTP/2 over TLS over TCP. 637 Additionally, Application-Layer Version Negotiation [RFC7301] permits 638 the client and server to negotiate which of several protocols will be 639 used on a given connection. Therefore, multiple applications might 640 be supported on a single UDP port based on the ALPN token offered. 641 Applications using QUIC should register an ALPN token for use in the 642 TLS handshake. 644 Applications could define an alternate endpoint discovery mechanism 645 to allow the usage of ports other than the default. For example, 646 HTTP/3 (Sections 3.2 and 3.3 of [QUIC-HTTP]) specifies the use of 647 HTTP Alternative Services for an HTTP origin to advertise the 648 availability of an equivalent HTTP/3 endpoint on a certain UDP port 649 by using the "h3" ALPN token. Note that HTTP/3's ALPN token ("h3") 650 identifies not only the version of the application protocol, but also 651 the version of QUIC itself; this approach allows unambiguous 652 agreement between the endpoints on the protocol stack in use. 654 Given the prevalence of the assumption in network management practice 655 that a port number maps unambiguously to an application, the use of 656 ports that cannot easily be mapped to a registered service name might 657 lead to blocking or other changes to the forwarding behavior by 658 network elements such as firewalls that use the port number for 659 application identification. 661 9. Connection Migration 663 QUIC supports connection migration by the client. If an IP address 664 changes, a QUIC endpoint can still associate packets with an existing 665 transport connection using the destination connection ID field (see 666 also Section 11) in the QUIC header, unless a zero-length value is 667 used. This supports cases where address information changes, such as 668 NAT rebinding, intentional change of the local interface, or based on 669 an indication in the handshake of the server for a preferred address 670 to be used. 672 Use of a non-zero-length connection ID for the server is strongly 673 recommended if any clients are behind a NAT or could be. A non-zero- 674 length connection ID is also strongly recommended when migration is 675 supported. 677 Currently QUIC only supports failover cases. Only one "path" can be 678 used at a time; and only when the new path is validated, all traffic 679 can be switched over to that new path. Path validation means that 680 the remote endpoint is required to validate the new path before use 681 in order to avoid address spoofing attacks. Path validation takes at 682 least one RTT and congestion control will also be reset after path 683 migration. Therefore migration usually has a performance impact. 685 QUIC probing packets, which can be sent on multiple paths at once, 686 are used to perform address validation as well as measure path 687 characteristics as input for the switching decision. Probing packets 688 cannot carry application data but may contain padding frames. 689 Endpoints can use information about their receipt as input to 690 congestion control for that path. Applications could use information 691 learned from probing to inform a decisions to switch paths. 693 Only the client can actively migrate in version 1 of QUIC. However, 694 servers can indicate during the handshake that they prefer to 695 transfer the connection to a different address after the handshake. 696 For instance, this could be used to move from an address that is 697 shared by multiple servers to an address that is unique to the server 698 instance. The server can provide an IPv4 and an IPv6 address in a 699 transport parameter during the TLS handshake and the client can 700 select between the two if both are provided. See also Section 9.6 of 701 [QUIC]. 703 10. Connection Termination 705 QUIC connections are terminated in one of three ways: implicit idle 706 timeout, explicit immediate close, or explicit stateless reset. 708 QUIC does not provide any mechanism for graceful connection 709 termination; applications using QUIC can define their own graceful 710 termination process (see, for example, Section 5.2 of [QUIC-HTTP]). 712 QUIC idle timeout is enabled via transport parameters. Client and 713 server announce a timeout period and the effective value for the 714 connection is the minimum of the two values. After the timeout 715 period elapses, the connection is silently closed. An application 716 therefore should be able to configure its own maximum value, as well 717 as have access to the computed minimum value for this connection. An 718 application may adjust the maximum idle timeout for new connections 719 based on the number of open or expected connections, since shorter 720 timeout values may free-up resources more quickly. 722 Application data exchanged on streams or in datagrams defers the QUIC 723 idle timeout. Applications that provide their own keep-alive 724 mechanisms will therefore keep a QUIC connection alive. Applications 725 that do not provide their own keep-alive can use transport-layer 726 mechanisms (see Section 10.1.2 of [QUIC], and Section 3.2). However, 727 QUIC implementation interfaces for controlling such transport 728 behavior can vary, affecting the robustness of such approaches. 730 An immediate close is signaled by a CONNECTION_CLOSE frame (see 731 Section 6). Immediate close causes all streams to become immediately 732 closed, which may affect applications; see Section 4.5. 734 A stateless reset is an option of last resort for an endpoint that 735 does not have access to connection state. Receiving a stateless 736 reset is an indication of an unrecoverable error distinct from 737 connection errors in that there is no application-layer information 738 provided. 740 11. Information Exposure and the Connection ID 742 QUIC exposes some information to the network in the unencrypted part 743 of the header, either before the encryption context is established or 744 because the information is intended to be used by the network. QUIC 745 has a long header that exposes some additional information (the 746 version and the source connection ID), while the short header exposes 747 only the destination connection ID. In QUIC version 1, the long 748 header is used during connection establishment, while the short 749 header is used for data transmission in an established connection. 751 The connection ID can be zero length. Zero length connection IDs can 752 be chosen on each endpoint individually, on any packet except the 753 first packets sent by clients during connection establishment. 755 An endpoint that selects a zero-length connection ID will receive 756 packets with a zero-length destination connection ID. The endpoint 757 needs to use other information, such as the source and destination IP 758 address and port number to identify which connection is referred to. 759 This could mean that the endpoint is unable to match datagrams to 760 connections successfully if these values change, making the 761 connection effectively unable to survive NAT rebinding or migrate to 762 a new path. 764 11.1. Server-Generated Connection ID 766 QUIC supports a server-generated connection ID, transmitted to the 767 client during connection establishment (see Section 7.2 of [QUIC]). 768 Servers behind load balancers may need to change the connection ID 769 during the handshake, encoding the identity of the server or 770 information about its load balancing pool, in order to support 771 stateless load balancing. 773 Server deployments with load balancers and other routing 774 infrastructure need to ensure that this infrastructure consistently 775 routes packets to the server instance that has the connection state, 776 even if addresses, ports, and/or connection IDs change. This might 777 require coordination between servers and infrastructure. One method 778 of achieving this involves encoding routing information into the 779 connection ID. For an example of this technique, see [QUIC-LB]. 781 11.2. Mitigating Timing Linkability with Connection ID Migration 783 QUIC requires that endpoints generate fresh connection IDs for use on 784 new network paths. Choosing values that are unlinkable to an outside 785 observer ensures that activity on different paths cannot be trivially 786 correlated using the connection ID. 788 While sufficiently robust connection ID generation schemes will 789 mitigate linkability issues, they do not provide full protection. 790 Analysis of the lifetimes of six-tuples (source and destination 791 addresses as well as the migrated CID) may expose these links anyway. 793 In the limit where connection migration in a server pool is rare, it 794 is trivial for an observer to associate two connection IDs. 795 Conversely, in the opposite limit where every server handles multiple 796 simultaneous migrations, even an exposed server mapping may be 797 insufficient information. 799 The most efficient mitigations for these attacks are through network 800 design and/or operational practice, by using a load balancing 801 architecture that loads more flows onto a single server-side address, 802 by coordinating the timing of migrations in an attempt to increase 803 the number of simultaneous migrations at a given time, or through 804 other means. 806 11.3. Using Server Retry for Redirection 808 QUIC provides a Server Retry packet that can be sent by a server in 809 response to the Client Initial packet. The server may choose a new 810 connection ID in that packet and the client will retry by sending 811 another Client Initial packet with the server-selected connection ID. 812 This mechanism can be used to redirect a connection to a different 813 server, e.g. due to performance reasons or when servers in a server 814 pool are upgraded gradually, and therefore may support different 815 versions of QUIC. In this case, it is assumed that all servers 816 belonging to a certain pool are served in cooperation with load 817 balancers that forward the traffic based on the connection ID. A 818 server can choose the connection ID in the Server Retry packet such 819 that the load balancer will redirect the next Client Initial packet 820 to a different server in that pool. Alternatively the load balancer 821 can directly offer a Retry service as further described in [QUIC-LB]. 823 Section 4 of [RFC5077] describes an example approach for constructing 824 TLS resumption tickets that can be also applied for validation 825 tokens, however, the use of more modern cryptographic algorithms is 826 highly recommended. 828 12. Quality of Service (QoS) and DSCP 830 QUIC assumes that all packets of a QUIC connection, or at least with 831 the same 5-tuple {dest addr, source addr, protocol, dest port, source 832 port}, will receive similar network treatment since feedback about 833 loss or delay of each packet is used as input to the congestion 834 controller. Therefore it is not recommended to use different 835 DiffServ Code Points (DSCPs) [RFC2475] for packets belonging to the 836 same connection. If differential network treatment, e.g. by the use 837 of different DSCPs, is desired, multiple QUIC connections to the same 838 server may be used. However, in general it is recommended to 839 minimize the number of QUIC connections to the same server, to avoid 840 increased overheads and, more importantly, competing congestion 841 control. 843 13. Use of Versions and Cryptographic Handshake 845 Versioning in QUIC may change the protocol's behavior completely, 846 except for the meaning of a few header fields that have been declared 847 to be invariant [QUIC-INVARIANTS]. A version of QUIC with a higher 848 version number will not necessarily provide a better service, but 849 might simply provide a different feature set. As such, an 850 application needs to be able to select which versions of QUIC it 851 wants to use. 853 A new version could use an encryption scheme other than TLS 1.3 or 854 higher. [QUIC] specifies requirements for the cryptographic 855 handshake as currently realized by TLS 1.3 and described in a 856 separate specification [QUIC-TLS]. This split is performed to enable 857 light-weight versioning with different cryptographic handshakes. 859 14. Enabling New Versions 861 QUIC version 1 does not specify a version negotation mechanism in the 862 base spec but [I-D.draft-ietf-quic-version-negotiation] proposes an 863 extension. This process assumes that the set of versions that a 864 server supports is fixed. This complicates the process for deploying 865 new QUIC versions or disabling old versions when servers operate in 866 clusters. 868 A server that rolls out a new version of QUIC can do so in three 869 stages. Each stage is completed across all server instances before 870 moving to the next stage. 872 In the first stage of deployment, all server instances start 873 accepting new connections with the new version. The new version can 874 be enabled progressively across a deployment, which allows for 875 selective testing. This is especially useful when the new version is 876 compatible with an old version, because the new version is more 877 likely to be used. 879 While enabling the new version, servers do not advertise the new 880 version in any Version Negotiation packets they send. This prevents 881 clients that receive a Version Negotiation packet from attempting to 882 connect to server instances that might not have the new version 883 enabled. 885 During the initial deployment, some clients will have received 886 Version Negotiation packets that indicate that the server does not 887 support the new version. Other clients might have successfully 888 connected with the new version and so will believe that the server 889 supports the new version. Therefore, servers need to allow for this 890 ambiguity when validating the negotiated version. 892 The second stage of deployment commences once all server instances 893 are able accept new connections with the new version. At this point, 894 all servers can start sending the new version in Version Negotiation 895 packets. 897 During the second stage, the server still allows for the possibility 898 that some clients believe the new version to be available and some do 899 not. This state will persist only for as long as any Version 900 Negotiation packets take to be transmitted and responded to. So the 901 third stage can follow after a relatively short delay. 903 The third stage completes the process by enabling authentication of 904 the negotiated version with the assumption that the new version is 905 fully available. 907 The process for disabling an old version or rolling back the 908 introduction of a new version uses the same process in reverse. 909 Servers disable validation of the old version, stop sending the old 910 version in Version Negotiation packets, then the old version is no 911 longer accepted. 913 15. Unreliable Datagram Service over QUIC 915 [I-D.ietf-quic-datagram] specifies a QUIC extension to enable sending 916 and receiving unreliable datagrams over QUIC. Unlike operating 917 directly over UDP, applications that use the QUIC datagram service do 918 not need to implement their own congestion control, per [RFC8085], as 919 QUIC datagrams are congestion controlled. 921 QUIC datagrams are not flow-controlled, and as such data chunks may 922 be dropped if the receiver is overloaded. While the reliable 923 transmission service of QUIC provides a stream-based interface to 924 send and receive data in order over multiple QUIC streams, the 925 datagram service has a unordered message-based interface. If needed, 926 an application layer framing can be used on top to allow separate 927 flows of unreliable datagrams to be multiplexed on one QUIC 928 connection. 930 16. IANA Considerations 932 This document has no actions for IANA; however, note that Section 8 933 recommends that application bindings to QUIC for applications using 934 TCP register UDP ports analogous to their existing TCP registrations. 936 17. Security Considerations 938 See the security considerations in [QUIC] and [QUIC-TLS]; the 939 security considerations for the underlying transport protocol are 940 relevant for applications using QUIC, as well. Considerations on 941 linkability, replay attacks, and randomness discussed in [QUIC-TLS] 942 should be taken into account when deploying and using QUIC. 944 Application developers should note that any fallback they use when 945 QUIC cannot be used due to network blocking of UDP should guarantee 946 the same security properties as QUIC; if this is not possible, the 947 connection should fail to allow the application to explicitly handle 948 fallback to a less-secure alternative. See Section 2. 950 Further, [QUIC-HTTP] provides security considerations specific to 951 HTTP. However, discussions such as on cross-protocol attacks, 952 traffic analysis and padding, or migration might be relevant for 953 other applications using QUIC as well. 955 18. Contributors 957 The following people have contributed text to this document: 959 * Igor Lubashev 961 * Mike Bishop 963 * Martin Thomson 965 * Lucas Pardue 967 * Gorry Fairhurst 969 19. Acknowledgments 971 Thanks also to Martin Duke, Sean Turner, and Ian Swett for their 972 reviews. 974 This work is partially supported by the European Commission under 975 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 976 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 977 for Education, Research, and Innovation under contract no. 15.0268. 978 This support does not imply endorsement. 980 20. References 982 20.1. Normative References 984 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 985 and Secure Transport", Work in Progress, Internet-Draft, 986 draft-ietf-quic-transport-34, 14 January 2021, 987 . 990 [QUIC-INVARIANTS] 991 Thomson, M., "Version-Independent Properties of QUIC", 992 Work in Progress, Internet-Draft, draft-ietf-quic- 993 invariants-13, 14 January 2021, 994 . 997 [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 998 Work in Progress, Internet-Draft, draft-ietf-quic-tls-34, 999 14 January 2021, 1000 . 1002 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1003 Cheshire, "Internet Assigned Numbers Authority (IANA) 1004 Procedures for the Management of the Service Name and 1005 Transport Protocol Port Number Registry", BCP 165, 1006 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1007 . 1009 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1010 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1011 . 1013 20.2. Informative References 1015 [Edeline16] 1016 Edeline, K., Kuehlewind, M., Trammell, B., Aben, E., and 1017 B. Donnet, "Using UDP for Internet Transport Evolution 1018 (arXiv preprint 1612.07816)", 22 December 2016, 1019 . 1021 [Hatonen10] 1022 Hatonen, S., Nyrhinen, A., Eggert, L., Strowes, S., 1023 Sarolahti, P., and M. Kojo, "An experimental study of home 1024 gateway characteristics (Proc. ACM IMC 2010)", October 1025 2010. 1027 [HTTP-REPLAY] 1028 Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 1029 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 1030 2018, . 1032 [I-D.draft-ietf-httpbis-priority] 1033 Oku, K. and L. Pardue, "Extensible Prioritization Scheme 1034 for HTTP", Work in Progress, Internet-Draft, draft-ietf- 1035 httpbis-priority-03, 11 January 2021, 1036 . 1039 [I-D.draft-ietf-quic-version-negotiation] 1040 Schinazi, D. and E. Rescorla, "Compatible Version 1041 Negotiation for QUIC", Work in Progress, Internet-Draft, 1042 draft-ietf-quic-version-negotiation-03, 4 February 2021, 1043 . 1046 [I-D.ietf-quic-datagram] 1047 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 1048 Datagram Extension to QUIC", Work in Progress, Internet- 1049 Draft, draft-ietf-quic-datagram-02, 16 February 2021, 1050 . 1052 [I-D.ietf-taps-arch] 1053 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 1054 Perkins, C., Tiesel, P. S., and C. A. Wood, "An 1055 Architecture for Transport Services", Work in Progress, 1056 Internet-Draft, draft-ietf-taps-arch-09, 2 November 2020, 1057 . 1059 [PaaschNanog] 1060 Paasch, C., "Network Support for TCP Fast Open (NANOG 67 1061 presentation)", 13 June 2016, 1062 . 1065 [QUIC-HTTP] 1066 Bishop, M., "Hypertext Transfer Protocol Version 3 1067 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 1068 quic-http-34, 2 February 2021, 1069 . 1071 [QUIC-LB] Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC 1072 Connection IDs", Work in Progress, Internet-Draft, draft- 1073 ietf-quic-load-balancers-06, 4 February 2021, 1074 . 1077 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1078 and W. Weiss, "An Architecture for Differentiated 1079 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1080 . 1082 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1083 "Transport Layer Security (TLS) Session Resumption without 1084 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1085 January 2008, . 1087 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 1088 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1089 RFC 5382, DOI 10.17487/RFC5382, October 2008, 1090 . 1092 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1093 "Transport Layer Security (TLS) Application-Layer Protocol 1094 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1095 July 2014, . 1097 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1098 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1099 . 1101 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1102 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1103 March 2017, . 1105 [Swett16] Swett, I., "QUIC Deployment Experience at Google (IETF96 1106 QUIC BoF presentation)", 20 July 2016, 1107 . 1110 [Trammell16] 1111 Trammell, B. and M. Kuehlewind, "Internet Path 1112 Transparency Measurements using RIPE Atlas (RIPE72 MAT 1113 presentation)", 25 May 2016, . 1116 Authors' Addresses 1118 Mirja Kuehlewind 1119 Ericsson 1121 Email: mirja.kuehlewind@ericsson.com 1122 Brian Trammell 1123 Google 1124 Gustav-Gull-Platz 1 1125 CH- 8004 Zurich 1126 Switzerland 1128 Email: ietf@trammell.ch