idnits 2.17.1 draft-ietf-quic-applicability-10.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 (22 February 2021) is 1153 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.nottingham-httpbis-retry' is defined on line 909, but no explicit reference was found in the text == 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 (~~), 4 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: 26 August 2021 Google 6 22 February 2021 8 Applicability of the QUIC Transport Protocol 9 draft-ietf-quic-applicability-10 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 26 August 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 5. Packetization and Latency . . . . . . . . . . . . . . . . . . 11 63 6. Port Selection and Application Endpoint Discovery . . . . . . 12 64 7. Connection Migration . . . . . . . . . . . . . . . . . . . . 12 65 8. Connection Closure . . . . . . . . . . . . . . . . . . . . . 13 66 9. Information Exposure and the Connection ID . . . . . . . . . 14 67 9.1. Server-Generated Connection ID . . . . . . . . . . . . . 15 68 9.2. Mitigating Timing Linkability with Connection ID 69 Migration . . . . . . . . . . . . . . . . . . . . . . . . 15 70 9.3. Using Server Retry for Redirection . . . . . . . . . . . 16 71 10. Quality of Service (QoS) and DSCP . . . . . . . . . . . . . . 16 72 11. Use of Versions and Cryptographic Handshake . . . . . . . . . 16 73 12. Enabling New Versions . . . . . . . . . . . . . . . . . . . . 17 74 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 75 14. Security Considerations . . . . . . . . . . . . . . . . . . . 18 76 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 77 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 78 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 17.1. Normative References . . . . . . . . . . . . . . . . . . 19 80 17.2. Informative References . . . . . . . . . . . . . . . . . 19 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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 it provides capabilities that can be used with a much wider variety 88 of applications. QUIC is encapsulated in UDP. QUIC version 1 89 integrates TLS 1.3 [TLS13] to encrypt all payload data and most 90 control information. The version of HTTP that uses QUIC is known as 91 HTTP/3 [QUIC-HTTP]. 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. 98 In the following sections we discuss specific caveats to QUIC's 99 applicability, and issues that application developers must consider 100 when using QUIC as a transport for their application. 102 2. The Necessity of Fallback 104 QUIC uses UDP as a substrate. This enables userspace implementation 105 and permits traversal of network middleboxes (including NAT) without 106 requiring updates to existing network infrastructure. 108 While recent measurements have shown no evidence of a widespread, 109 systematic disadvantage of UDP traffic compared to TCP in the 110 Internet [Edeline16], somewhere between three [Trammell16] and five 111 [Swett16] percent of networks block all UDP traffic. All 112 applications running on top of QUIC must therefore either be prepared 113 to accept connectivity failure on such networks or be engineered to 114 fall back to some other transport protocol. In the case of HTTP, 115 this fallback is TLS over TCP. 117 The IETF TAPS specifications [I-D.ietf-taps-arch] describe a system 118 with a common API for multiple protocols and some of the implications 119 of fallback between these different protocols, specifically 120 precluding fallback to insecure protocols or to weaker versions of 121 secure protocols. 123 An application that implements fallback needs to consider the 124 security consequences. A fallback to TCP and TLS exposes control 125 information to modification and manipulation in the network. Further 126 downgrades to older TLS versions than used in QUIC, which is 1.3, 127 might result in significantly weaker cryptographic protection. For 128 example, the results of protocol negotiation [RFC7301] only have 129 confidentiality protection if TLS 1.3 is used. 131 These applications must operate, perhaps with impaired functionality, 132 in the absence of features provided by QUIC not present in the 133 fallback protocol. For fallback to TLS over TCP, the most obvious 134 difference is that TCP does not provide stream multiplexing and 135 therefore stream multiplexing would need to be implemented in the 136 application layer if needed. Further, TCP implementations and 137 network paths often do not support the Fast Open option, which is 138 analogous to 0-RTT session resumption. Note that there is some 139 evidence of middleboxes blocking SYN data even if TFO was 140 successfully negotiated (see [PaaschNanog]). And even if Fast Open 141 successfully operates end-to-end, it is limited to a single packet of 142 payload, unlike QUIC 0-RTT. 144 Moreover, while encryption (in this case TLS) is inseparably 145 integrated with QUIC, TLS negotiation over TCP can be blocked. If 146 TLS over TCP cannot be supported, the connection should be aborted 147 instead, in order to enable the application to present a suitable 148 prompt to the user that secure communication is unavailable. 150 In summary, any fallback mechanism is likely to impose a degradation 151 of performance and can degrade security; however, fallback must not 152 silently violate the application's expectation of confidentiality or 153 integrity of its payload data. 155 3. Zero RTT 157 QUIC provides for 0-RTT connection establishment. Though the same 158 facility exists in TLS 1.3 with TCP, 0-RTT presents opportunities and 159 challenges for applications using QUIC. 161 A transport protocol that provides 0-RTT connection establishment is 162 qualitatively different than one that does not from the point of view 163 of the application using it. Relative trade-offs between the cost of 164 closing and reopening a connection and trying to keep it open are 165 different; see Section 3.2. 167 An application needs to deliberately choose to use 0-RTT, as 0-RTT 168 carries a risk of replay attack. Application protocols that use 169 0-RTT require a profile that describes the types of information that 170 can be safely sent. For HTTP, this profile is described in 171 [HTTP-REPLAY]. 173 3.1. Replay Attacks 175 Retransmission or (malicious) replay of data contained in 0-RTT 176 packets could cause the server side to receive two copies of the same 177 data. 179 Application data sent by the client in 0-RTT packets could be 180 processed more than once if it is replayed. Applications need to be 181 aware of what is safe to send in 0-RTT. Application protocols that 182 seek to enable the use of 0-RTT need a careful analysis and a 183 description of what can be sent in 0-RTT; see Section 5.6 of 184 [QUIC-TLS]. 186 In some cases, it might be sufficient to limit application data sent 187 in 0-RTT to that which only causes actions at a server that are known 188 to be free of lasting effect. Initiating data retrieval or 189 establishing configuration are examples of actions that could be 190 safe. Idempotent operations - those for which repetition has the 191 same net effect as a single operation - might be safe. However, it 192 is also possible to combine individually idempotent operations into a 193 non-idempotent sequence of operations. 195 Once a server accepts 0-RTT data there is no means of selectively 196 discarding data that is received. However, protocols can define ways 197 to reject individual actions that might be unsafe if replayed. 199 Some TLS implementations and deployments might be able to provide 200 partial or even complete replay protection, which could be used to 201 manage replay risk. 203 3.2. Session resumption versus Keep-alive 205 Because QUIC is encapsulated in UDP, applications using QUIC must 206 deal with short network idle timeouts. Deployed stateful middleboxes 207 will generally establish state for UDP flows on the first packet 208 sent, and keep state for much shorter idle periods than for TCP. 209 [RFC5382] suggests a TCP idle period of at least 124 minutes, though 210 there is not evidence of widespread implementation of this guideline 211 in the literature. Short network timeout for UDP, however, is well- 212 documented. According to a 2010 study ([Hatonen10]), UDP 213 applications can assume that any NAT binding or other state entry can 214 expire after just thirty seconds of inactivity. Section 3.5 of 215 [RFC8085] further discusses keep-alive intervals for UDP: it requires 216 a minimum value of 15 seconds, but recommends larger values, or 217 omitting keep-alive entirely. 219 By using a connection ID, QUIC is designed to be robust to NAT 220 address rebinding after a timeout. However, this only helps if one 221 endpoint maintains availability at the address its peer uses, and the 222 peer is the one to send after the timeout occurs. 224 Some QUIC connections might not be robust to NAT rebinding because 225 the routing infrastructure (in particular, load balancers) uses the 226 address/port four-tuple to direct traffic. Furthermore, middleboxes 227 with functions other than address translation could still affect the 228 path. In particular, some firewalls do not admit server traffic for 229 which the firewall has no recent state for a corresponding packet 230 sent from the client. 232 QUIC applications can adjust idle periods to manage the risk of 233 timeout. Idle periods and the network idle timeout are distinct from 234 the connection idle timeout, which is defined as the minimum of 235 either endpoint's idle timeout parameter; see Section 10.1 of 236 [QUIC]). There are three options: 238 * Ignore the issue, if the application-layer protocol consists only 239 of interactions with no or very short idle periods, or the 240 protocol's resistance to NAT rebinding is sufficient. 242 * Ensure there are no long idle periods. 244 * Resume the session after a long idle period, using 0-RTT 245 resumption when appropriate. 247 The first strategy is the easiest, but it only applies to certain 248 applications. 250 Either the server or the client in a QUIC application can send PING 251 frames as keep-alives, to prevent the connection and any on-path 252 state from timing out. Recommendations for the use of keep-alives 253 are application-specific, mainly depending on the latency 254 requirements and message frequency of the application. In this case, 255 the application mapping must specify whether the client or server is 256 responsible for keeping the application alive. While [Hatonen10] 257 suggests that 30 seconds might be a suitable value for the public 258 Internet when a NAT is on path, larger values are preferable if the 259 deployment can consistently survive NAT rebinding or is known to be 260 in a controlled environment (e.g. data centres) in order to lower 261 network and computational load. 263 Sending PING frames more frequently than every 30 seconds over long 264 idle periods may result in excessive unproductive traffic in some 265 situations, and to unacceptable power usage for power-constrained 266 (mobile) devices. Additionally, timeouts shorter than 30 seconds can 267 make it harder to handle transient network interruptions, such as VM 268 migration or coverage loss during mobilty. See [RFC8085], especially 269 Section 3.5. 271 Alternatively, the client (but not the server) can use session 272 resumption instead of sending keepalive traffic. In this case, a 273 client that wants to send data to a server over a connection idle 274 longer than the server's idle timeout (available from the 275 idle_timeout transport parameter) can simply reconnect. When 276 possible, this reconnection can use 0-RTT session resumption, 277 reducing the latency involved with restarting the connection. Of 278 course, this approach is only valid in cases in which 0-RTT data is 279 safe, when the client is the restarting peer, and when the data to be 280 sent is idempotent. It is also not applicable when the application 281 binds external state to the connection, as this state cannot reliably 282 be transferred to a resumed connection. 284 The tradeoffs between resumption and keep-alives need to be evaluated 285 on a per-application basis. In general, applications should use 286 keep-alives only in circumstances where continued communication is 287 highly likely; [QUIC-HTTP], for instance, recommends using keep- 288 alives only when a request is outstanding. 290 4. Use of Streams 292 QUIC's stream multiplexing feature allows applications to run 293 multiple streams over a single connection, without head-of-line 294 blocking between streams, associated at a point in time with a single 295 five-tuple. Stream data is carried within frames, where one QUIC 296 packet on the wire can carry one or multiple stream frames. 298 Streams can be unidirectional or bidirectional, and a stream may be 299 initiated either by client or server. Only the initiator of a 300 unidirectional stream can send data on it. 302 Streams and connections can each carry a maximum of 2^(62)-1 bytes in 303 each direction, due to encoding limitations on stream offsets and 304 connection flow control limits. In the presently unlikely event that 305 this limit is reached by an application, a new connection would need 306 to be established. 308 Streams can be independently opened and closed, gracefully or 309 abruptly. An application can gracefully close the egress direction 310 of a stream by instructing QUIC to send a FIN bit in a STREAM frame. 311 It cannot gracefully close the ingress direction without a peer- 312 generated FIN, much like in TCP. However, an endpoint can abruptly 313 close the egress direction or request that its peer abruptly close 314 the ingress direction; these actions are fully independent of each 315 other. 317 QUIC does not provide an interface for exceptional handling of any 318 stream. If a stream that is critical for an application is closed, 319 the application can generate error messages on the application layer 320 to inform the other end and/or the higher layer, which can eventually 321 reset the QUIC connection. 323 Mapping of application data to streams is application-specific and 324 described for HTTP/3 in [QUIC-HTTP]. There are a few general 325 principles to apply when designing an application's use of streams: 327 * A single stream provides ordering. If the application requires 328 certain data to be received in order, that data should be sent on 329 the same stream. 331 * Multiple streams provide concurrency. Data that can be processed 332 independently, and therefore would suffer from head of line 333 blocking if forced to be received in order, should be transmitted 334 over separate streams. 336 * Streams can provide message orientation, and allow messages to be 337 cancelled. If one message is mapped to a single stream, resetting 338 the stream to expire an unacknowledged message can be used to 339 emulate partial reliability for that message. 341 If a QUIC receiver has opened the maximum allowed concurrent streams, 342 and the sender indicates that more streams are needed, it does not 343 automatically lead to an increase of the maximum number of streams by 344 the receiver. Therefore it can be valuable to expose the maximum 345 number of allowed, currently open, and currently used streams to the 346 application to make the mapping of data to streams dependent on this 347 information. 349 QUIC assigns a numerical identifier to each stream, called the Stream 350 ID. While the relationship between these identifiers and stream 351 types is clearly defined in version 1 of QUIC, future versions might 352 change this relationship for various reasons. QUIC implementations 353 should expose the properties of each stream (which endpoint initiated 354 the stream, whether the stream is unidirectional or bidirectional, 355 the Stream ID used for the stream); applications should query for 356 these properties rather than attempting to infer them from the Stream 357 ID. 359 The method of allocating stream identifiers to streams opened by the 360 application might vary between transport implementations. Therefore, 361 an application should not assume a particular stream ID will be 362 assigned to a stream that has not yet been allocated. For example, 363 HTTP/3 uses Stream IDs to refer to streams that have already been 364 opened, but makes no assumptions about future Stream IDs or the way 365 in which they are assigned Section 6 of [QUIC-HTTP]). 367 4.1. Stream versus Flow Multiplexing 369 Streams are meaningful only to the application; since stream 370 information is carried inside QUIC's encryption boundary, no 371 information about the stream(s) whose frames are carried by a given 372 packet is visible to the network. Therefore stream multiplexing is 373 not intended to be used for differentiating streams in terms of 374 network treatment. Application traffic requiring different network 375 treatment should therefore be carried over different five-tuples 376 (i.e. multiple QUIC connections). Given QUIC's ability to send 377 application data in the first RTT of a connection (if a previous 378 connection to the same host has been successfully established to 379 provide the necessary credentials), the cost of establishing another 380 connection is extremely low. 382 4.2. Prioritization 384 Stream prioritization is not exposed to either the network or the 385 receiver. Prioritization is managed by the sender, and the QUIC 386 transport should provide an interface for applications to prioritize 387 streams [QUIC]. Applications can implement their own prioritization 388 scheme on top of QUIC: an application protocol that runs on top of 389 QUIC can define explicit messages for signaling priority, such as 390 those defined for HTTP/2; it can define rules that allow an endpoint 391 to determine priority based on context; or it can provide a higher 392 level interface and leave the determination to the application on 393 top. 395 Priority handling of retransmissions can be implemented by the sender 396 in the transport layer. [QUIC] recommends retransmitting lost data 397 before new data, unless indicated differently by the application. 398 Currently, QUIC only provides fully reliable stream transmission, 399 which means that prioritization of retransmissions will be beneficial 400 in most cases, by filling in gaps and freeing up the flow control 401 window. For partially reliable or unreliable streams, priority 402 scheduling of retransmissions over data of higher-priority streams 403 might not be desirable. For such streams, QUIC could either provide 404 an explicit interface to control prioritization, or derive the 405 prioritization decision from the reliability level of the stream. 407 4.3. Ordered and Reliable Delivery 409 QUIC streams enable ordered and reliable delivery. Though it is 410 possible for an implementation to provide options that use streams 411 for partial reliability or out-of-order delivery, most 412 implementations will assume that data is reliably delivered in order. 414 Under this assumption, an endpoint that receives stream data might 415 not make forward progress until data that is contiguous with the 416 start of a stream is available. In particular, a receiver might 417 withhold flow control credit until contiguous data is delivered to 418 the application; see Section 2.2 of [QUIC]. To support this receive 419 logic, an endpoint will send stream data until it is acknowledged, 420 ensuring that data at the start of the stream is sent and 421 acknowledged first. 423 An endpoint that uses a different sending behavior and does not 424 negotiate that change with its peer might encounter performance 425 issues or deadlocks. 427 4.4. Flow Control Deadlocks 429 Flow control provides a means of managing access to the limited 430 buffers endpoints have for incoming data. This mechanism limits the 431 amount of data that can be in buffers in endpoints or in transit on 432 the network. However, there are several ways in which limits can 433 produce conditions that can cause a connection to either perform 434 suboptimally or deadlock. 436 Deadlocks in flow control are possible for any protocol that uses 437 QUIC, though whether they become a problem depends on how 438 implementations consume data and provide flow control credit. 439 Understanding what causes deadlocking might help implementations 440 avoid deadlocks. 442 Large messages can produce deadlocking if the recipient does not 443 process the message incrementally. If the message is larger than the 444 flow control credit available and the recipient does not release 445 additional flow control credit until the entire message is received 446 and delivered, a deadlock can occur. This is possible even where 447 stream flow control limits are not reached because connection flow 448 control limits can be consumed by other streams. 450 A common flow control implementation technique is for a receiver to 451 extend credit to the sender as a the data consumer reads data. In 452 this setting, a length-prefixed message format makes it easier for 453 the data consumer to leave data unread in the receiver's buffers and 454 thereby withhold flow control credit. If flow control limits prevent 455 the remainder of a message from being sent, a deadlock will result. 456 A length prefix might also enable the detection of this sort of 457 deadlock. Where protocols have messages that might be processed as a 458 single unit, reserving flow control credit for the entire message 459 atomically makes this style of deadlock less likely. 461 A data consumer can read all data as it becomes available to cause 462 the receiver to extend flow control credit to the sender and reduce 463 the chances of a deadlock. However, releasing flow control credit 464 might mean that the data consumer might need other means for holding 465 a peer accountable for the state it keeps for partially processed 466 messages. 468 Deadlocking can also occur if data on different streams is 469 interdependent. Suppose that data on one stream arrives before the 470 data on a second stream on which it depends. A deadlock can occur if 471 the first stream is left unread, preventing the receiver from 472 extending flow control credit for the second stream. To reduce the 473 likelihood of deadlock for interdependent data, the sender should 474 ensure that dependent data is not sent until the data it depends on 475 has been accounted for in both stream- and connection- level flow 476 control credit. 478 Some deadlocking scenarios might be resolved by cancelling affected 479 streams with STOP_SENDING or RESET_STREAM. Cancelling some streams 480 results in the connection being terminated in some protocols. 482 5. Packetization and Latency 484 QUIC exposes an interface that provides multiple streams to the 485 application; however, the application usually cannot control how data 486 transmitted over those streams is mapped into frames or how those 487 frames are bundled into packets. 489 By default, many implementations will try to maximally pack QUIC 490 packets DATA frames from one or more streams to minimize bandwidth 491 consumption and computational costs (see Section 13 of [QUIC]). If 492 there is not enough data available to fill a packet, an 493 implementation might wait for a short time, to optimize bandwidth 494 efficiency instead of latency. This delay can either be pre- 495 configured or dynamically adjusted based on the observed sending 496 pattern of the application. 498 If the application requires low latency, with only small chunks of 499 data to send, it may be valuable to indicate to QUIC that all data 500 should be send out immediately. Alternatively, if the application 501 expects to use a specific sending pattern, it can also provide a 502 suggested delay to QUIC for how long to wait before bundle frames 503 into a packet. 505 Similarly, an application has usually no control about the length of 506 a QUIC packet on the wire. QUIC provides the ability to add a 507 PADDING frame to arbitrarily increase the size of packets. Padding 508 is used by QUIC to ensure that the path is capable of transferring 509 datagrams of at least a certain size, during the handshake (see 510 Sections 8.1 and 14.1 of [QUIC]) and for path validation after 511 connection migration (see Section 8.2 of [QUIC]) as well as for 512 Datagram Packetization Layer PMTU Discovery (DPLMTUD) (see 513 Section 14.3 of [QUIC]). 515 Padding can also be used by an application to reduce leakage of 516 information about the data that is sent. A QUIC implementation can 517 expose an interface that allows an application layer to specify how 518 to apply padding. 520 6. Port Selection and Application Endpoint Discovery 522 In general, port numbers serve two purposes: "first, they provide a 523 demultiplexing identifier to differentiate transport sessions between 524 the same pair of endpoints, and second, they may also identify the 525 application protocol and associated service to which processes 526 connect" [RFC6335]. The assumption that an application can be 527 identified in the network based on the port number is less true today 528 due to encapsulation, mechanisms for dynamic port assignments, and 529 NATs. 531 As QUIC is a general-purpose transport protocol, there are no 532 requirements that servers use a particular UDP port for QUIC. For 533 applications with a fallback to TCP that do not already have an 534 alternate mapping to UDP, usually the registration (if necessary) and 535 use of the UDP port number corresponding to the TCP port already 536 registered for the application is appropriate. For example, the 537 default port for HTTP/3 [QUIC-HTTP] is UDP port 443, analogous to 538 HTTP/1.1 or HTTP/2 over TLS over TCP. 540 Applications could define an alternate endpoint discovery mechanism 541 to allow the usage of ports other than the default. For example, 542 HTTP/3 (Sections 3.2 and 3.3 of [QUIC-HTTP]) specifies the use of 543 HTTP Alternative Services for an HTTP origin to advertise the 544 availability of an equivalent HTTP/3 endpoint on a certain UDP port 545 by using the "h3" ALPN token [RFC7301]. Note that HTTP/3's ALPN 546 token ("h3") identifies not only the version of the application 547 protocol, but also the version of QUIC itself; this approach allows 548 unambiguous agreement between the endpoints on the protocol stack in 549 use. 551 Given the prevalence of the assumption in network management practice 552 that a port number maps unambiguously to an application, the use of 553 ports that cannot easily be mapped to a registered service name might 554 lead to blocking or other changes to the forwarding behavior by 555 network elements such as firewalls that use the port number for 556 application identification. 558 7. Connection Migration 560 QUIC supports connection migration by the client. If an IP address 561 changes, a QUIC endpoint can still associate packets with an existing 562 transport connection using the destination connection ID field (see 563 also Section 9) in the QUIC header, unless a zero-length value is 564 used. This supports cases where address information changes, such as 565 NAT rebinding, intentional change of the local interface, or based on 566 an indication in the handshake of the server for a preferred address 567 to be used. 569 Use of a non-zero-length connection ID for the server is strongly 570 recommended if any clients are behind a NAT or could be. A non-zero- 571 length connection ID is also strongly recommended when migration is 572 supported. 574 Currently QUIC only supports failover cases. Only one "path" can be 575 used at a time, and only when the new path is validated all traffic 576 can be switched over to that new path. Path validation means that 577 the remote endpoint is required to validate the new path before use 578 in order to avoid address spoofing attacks. Path validation takes at 579 least one RTT and congestion control will also be reset after path 580 migration. Therefore migration usually has a performance impact. 582 QUIC probing packets, which cannot carry application data, can be 583 sent on multiple paths at once. Probing packets can be used to 584 perform address validation, measure path characteristics as input for 585 the switching decision, or prime the congestion controller in 586 preparation for switching to the new path. 588 Only the client can actively migrate in version 1 of QUIC. However, 589 servers can indicate during the handshake that they prefer to 590 transfer the connection to a different address after the handshake. 591 For instance, this could be used to move from an address that is 592 shared by multiple servers to an address that is unique to the server 593 instance. The server can provide an IPv4 and an IPv6 address in a 594 transport parameter during the TLS handshake and the client can 595 select between the two if both are provided. See also Section 9.6 of 596 [QUIC]. 598 8. Connection Closure 600 QUIC connections are closed either by expiration of an idle timeout, 601 as determined by transport parameters, or by an explicit indication 602 of the application that a connection should be closed (immediate 603 close). While data could still be received after the immediate close 604 has been initiated by one endpoint (for a limited time period), the 605 expectation is that an immediate close was negotiated at the 606 application layer and therefore no additional data is expected from 607 both sides. 609 An immediate close will emit an CONNECTION_CLOSE frame. This frame 610 has two sets of types: one for QUIC internal problems that might lead 611 to connection closure, and one for closures initiated by the 612 application. An application using QUIC can define application- 613 specific error codes (see, for example, Section 8.1 of [QUIC-HTTP]). 615 The CONNECTION_CLOSE frame provides an optional reason field, that 616 can be used to append human-readable information to an error code. 617 RESET_STREAM and STOP_SENDING frames also include an error code, but 618 no reason string. 620 Alternatively, a QUIC connection can be silently closed by each 621 endpoint separately after an idle timeout. If enabled as indicated 622 by a transport parameter in the handshake, the idle timeout is 623 announced for each endpoint during connection establishment and the 624 effective value for this connection is the minimum of the two values 625 advertised by client and server. An application therefore should be 626 able to configure its own maximum value as well as have access to the 627 computed minimum value for this connection. An application may 628 adjust the maximum idle timeout for new connections based on the 629 number of open or expected connections, since shorter timeout values 630 may free-up memory more quickly. 632 If an application desires to keep the connection open for longer than 633 the announced timeout, it can send keep-alive messages; a QUIC 634 implementation may provide an option to defer the time-out by sending 635 keep-alive messages at the transport layer to avoid unnecessary load, 636 as specified in Section 10.1.2 of [QUIC]. See Section 3.2 for 637 further guidance on keep-alives. 639 9. Information Exposure and the Connection ID 641 QUIC exposes some information to the network in the unencrypted part 642 of the header, either before the encryption context is established or 643 because the information is intended to be used by the network. QUIC 644 has a long header that exposes some additional information (the 645 version and the source connection ID), while the short header exposes 646 only the destination connection ID. In QUIC version 1, the long 647 header is used during connection establishment, while the short 648 header is used for data transmission in an established connection. 650 The connection ID can be zero length. Zero length connection IDs can 651 be chosen on each endpoint individually, on any packet except the 652 first packets sent by clients during connection establishment. 654 An endpoint that selects a zero-length connection ID will receive 655 packets with a zero-length destination connection ID. The endpoint 656 needs to use other information, such as the source and destination IP 657 address and port number to identify which connection is referred to. 658 This could mean that the endpoint is unable to match datagrams to 659 connections successfully if these values change, making the 660 connection effectively unable to survive NAT rebinding or migrate to 661 a new path. 663 9.1. Server-Generated Connection ID 665 QUIC supports a server-generated connection ID, transmitted to the 666 client during connection establishment (see Section 7.2 of [QUIC]). 667 Servers behind load balancers may need to change the connection ID 668 during the handshake, encoding the identity of the server or 669 information about its load balancing pool, in order to support 670 stateless load balancing. 672 Server deployments with load balancers and other routing 673 infrastructure need to ensure that this infrastructure consistently 674 routes packets to the correct server instance. This might require 675 coordination between servers and infrastructure. One method of 676 achieving this involves encoding routing information into the 677 connection ID. This ensures that there is no need to for servers and 678 infrastructure to coordinate routing information for each connection. 679 See [QUIC-LB] for more information. 681 9.2. Mitigating Timing Linkability with Connection ID Migration 683 QUIC requires that endpoints generate fresh connection IDs for use on 684 new network paths. Choosing values that are unlinkable to an outside 685 observer ensures that activity on different paths cannot be trivially 686 correlated using the connection ID. 688 While sufficiently robust connection ID generation schemes will 689 mitigate linkability issues, they do not provide full protection. 690 Analysis of the lifetimes of six-tuples (source and destination 691 addresses as well as the migrated CID) may expose these links anyway. 693 In the limit where connection migration in a server pool is rare, it 694 is trivial for an observer to associate two connection IDs. 695 Conversely, in the opposite limit where every server handles multiple 696 simultaneous migrations, even an exposed server mapping may be 697 insufficient information. 699 The most efficient mitigations for these attacks are through network 700 design and/or operational practice, by using a load balancing 701 architecture that loads more flows onto a single server-side address, 702 by coordinating the timing of migrations in an attempt to increase 703 the number of simultaneous migrations at a given time, or through 704 other means. 706 9.3. Using Server Retry for Redirection 708 QUIC provides a Server Retry packet that can be sent by a server in 709 response to the Client Initial packet. The server may choose a new 710 connection ID in that packet and the client will retry by sending 711 another Client Initial packet with the server-selected connection ID. 712 This mechanism can be used to redirect a connection to a different 713 server, e.g. due to performance reasons or when servers in a server 714 pool are upgraded gradually, and therefore may support different 715 versions of QUIC. In this case, it is assumed that all servers 716 belonging to a certain pool are served in cooperation with load 717 balancers that forward the traffic based on the connection ID. A 718 server can choose the connection ID in the Server Retry packet such 719 that the load balancer will redirect the next Client Initial packet 720 to a different server in that pool. Alternatively the load balancer 721 can directly offer a Retry service as further described in [QUIC-LB]. 723 Section 4 of [RFC5077] describes an example approach for constructing 724 TLS resumption tickets that can be also applied for validation 725 tokens, however, the use of more modern cryptographic algorithms is 726 highly recommended. 728 10. Quality of Service (QoS) and DSCP 730 QUIC assumes that all packets of a QUIC connection, or at least with 731 the same 5-tuple {dest addr, source addr, protocol, dest port, source 732 port}, will receive similar network treatment since feedback about 733 loss or delay of each packet is used as input to the congestion 734 controller. Therefore it is not recommended to use different 735 DiffServ Code Points (DSCPs) [RFC2475] for packets belonging to the 736 same connection. If differential network treatment, e.g. by the use 737 of different DSCPs, is desired, multiple QUIC connections to the same 738 server may be used. However, in general it is recommended to 739 minimize the number of QUIC connections to the same server, to avoid 740 increased overheads and, more importantly, competing congestion 741 control. 743 11. Use of Versions and Cryptographic Handshake 745 Versioning in QUIC may change the protocol's behavior completely, 746 except for the meaning of a few header fields that have been declared 747 to be invariant [QUIC-INVARIANTS]. A version of QUIC with a higher 748 version number will not necessarily provide a better service, but 749 might simply provide a different feature set. As such, an 750 application needs to be able to select which versions of QUIC it 751 wants to use. 753 A new version could use an encryption scheme other than TLS 1.3 or 754 higher. [QUIC] specifies requirements for the cryptographic 755 handshake as currently realized by TLS 1.3 and described in a 756 separate specification [QUIC-TLS]. This split is performed to enable 757 light-weight versioning with different cryptographic handshakes. 759 12. Enabling New Versions 761 QUIC provides integrity protection for its version negotiation 762 process. This process assumes that the set of versions that a server 763 supports is fixed. This complicates the process for deploying new 764 QUIC versions or disabling old versions when servers operate in 765 clusters. 767 A server that rolls out a new version of QUIC can do so in three 768 stages. Each stage is completed across all server instances before 769 moving to the next stage. 771 In the first stage of deployment, all server instances start 772 accepting new connections with the new version. The new version can 773 be enabled progressively across a deployment, which allows for 774 selective testing. This is especially useful when the new version is 775 compatible with an old version, because the new version is more 776 likely to be used. 778 While enabling the new version, servers do not advertise the new 779 version in any Version Negotiation packets they send. This prevents 780 clients that receive a Version Negotiation packet from attempting to 781 connect to server instances that might not have the new version 782 enabled. 784 During the initial deployment, some clients will have received 785 Version Negotiation packets that indicate that the server does not 786 support the new version. Other clients might have successfully 787 connected with the new version and so will believe that the server 788 supports the new version. Therefore, servers need to allow for this 789 ambiguity when validating the negotiated version. 791 The second stage of deployment commences once all server instances 792 are able accept new connections with the new version. At this point, 793 all servers can start sending the new version in Version Negotiation 794 packets. 796 During the second stage, the server still allows for the possibility 797 that some clients believe the new version to be available and some do 798 not. This state will persist only for as long as any Version 799 Negotiation packets take to be transmitted and responded to. So the 800 third stage can follow after a relatively short delay. 802 The third stage completes the process by enabling authentication of 803 the negotiated version with the assumption that the new version is 804 fully available. 806 The process for disabling an old version or rolling back the 807 introduction of a new version uses the same process in reverse. 808 Servers disable validation of the old version, stop sending the old 809 version in Version Negotiation packets, then the old version is no 810 longer accepted. 812 13. IANA Considerations 814 This document has no actions for IANA; however, note that Section 6 815 recommends that application bindings to QUIC for applications using 816 TCP register UDP ports analogous to their existing TCP registrations. 818 14. Security Considerations 820 See the security considerations in [QUIC] and [QUIC-TLS]; the 821 security considerations for the underlying transport protocol are 822 relevant for applications using QUIC, as well. Considerations on 823 linkability, replay attacks, and randomness discussed in [QUIC-TLS] 824 should be taken into account when deploying and using QUIC. 826 Application developers should note that any fallback they use when 827 QUIC cannot be used due to network blocking of UDP should guarantee 828 the same security properties as QUIC; if this is not possible, the 829 connection should fail to allow the application to explicitly handle 830 fallback to a less-secure alternative. See Section 2. 832 Further, [QUIC-HTTP] provides security considerations specific to 833 HTTP. However, discussions such as on cross-protocol attacks, 834 traffic analysis and padding, or migration might be relevant for 835 other applications using QUIC as well. 837 15. Contributors 839 Igor Lubashev contributed text to Section 9 on server-selected 840 connection IDs. 842 16. Acknowledgments 844 This work is partially supported by the European Commission under 845 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 846 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 847 for Education, Research, and Innovation under contract no. 15.0268. 848 This support does not imply endorsement. 850 17. References 852 17.1. Normative References 854 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 855 and Secure Transport", Work in Progress, Internet-Draft, 856 draft-ietf-quic-transport-34, 14 January 2021, 857 . 860 [QUIC-INVARIANTS] 861 Thomson, M., "Version-Independent Properties of QUIC", 862 Work in Progress, Internet-Draft, draft-ietf-quic- 863 invariants-13, 14 January 2021, 864 . 867 [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 868 Work in Progress, Internet-Draft, draft-ietf-quic-tls-34, 869 14 January 2021, 870 . 872 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 873 Cheshire, "Internet Assigned Numbers Authority (IANA) 874 Procedures for the Management of the Service Name and 875 Transport Protocol Port Number Registry", BCP 165, 876 RFC 6335, DOI 10.17487/RFC6335, August 2011, 877 . 879 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 880 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 881 . 883 17.2. Informative References 885 [Edeline16] 886 Edeline, K., Kuehlewind, M., Trammell, B., Aben, E., and 887 B. Donnet, "Using UDP for Internet Transport Evolution 888 (arXiv preprint 1612.07816)", 22 December 2016, 889 . 891 [Hatonen10] 892 Hatonen, S., Nyrhinen, A., Eggert, L., Strowes, S., 893 Sarolahti, P., and M. Kojo, "An experimental study of home 894 gateway characteristics (Proc. ACM IMC 2010)", October 895 2010. 897 [HTTP-REPLAY] 898 Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 899 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 900 2018, . 902 [I-D.ietf-taps-arch] 903 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 904 Perkins, C., Tiesel, P. S., and C. A. Wood, "An 905 Architecture for Transport Services", Work in Progress, 906 Internet-Draft, draft-ietf-taps-arch-09, 2 November 2020, 907 . 909 [I-D.nottingham-httpbis-retry] 910 Nottingham, M., "Retrying HTTP Requests", Work in 911 Progress, Internet-Draft, draft-nottingham-httpbis-retry- 912 01, 1 February 2017, . 915 [PaaschNanog] 916 Paasch, C., "Network Support for TCP Fast Open (NANOG 67 917 presentation)", 13 June 2016, 918 . 921 [QUIC-HTTP] 922 Bishop, M., "Hypertext Transfer Protocol Version 3 923 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 924 quic-http-34, 2 February 2021, 925 . 927 [QUIC-LB] Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC 928 Connection IDs", Work in Progress, Internet-Draft, draft- 929 ietf-quic-load-balancers-06, 4 February 2021, 930 . 933 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 934 and W. Weiss, "An Architecture for Differentiated 935 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 936 . 938 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 939 "Transport Layer Security (TLS) Session Resumption without 940 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 941 January 2008, . 943 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 944 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 945 RFC 5382, DOI 10.17487/RFC5382, October 2008, 946 . 948 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 949 "Transport Layer Security (TLS) Application-Layer Protocol 950 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 951 July 2014, . 953 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 954 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 955 March 2017, . 957 [Swett16] Swett, I., "QUIC Deployment Experience at Google (IETF96 958 QUIC BoF presentation)", 20 July 2016, 959 . 962 [Trammell16] 963 Trammell, B. and M. Kuehlewind, "Internet Path 964 Transparency Measurements using RIPE Atlas (RIPE72 MAT 965 presentation)", 25 May 2016, . 968 Authors' Addresses 970 Mirja Kuehlewind 971 Ericsson 973 Email: mirja.kuehlewind@ericsson.com 975 Brian Trammell 976 Google 977 Gustav-Gull-Platz 1 978 CH- 8004 Zurich 979 Switzerland 981 Email: ietf@trammell.ch