idnits 2.17.1 draft-ietf-quic-applicability-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Any fallback mechanism is likely to impose a degradation of performance; however, fallback MUST not silently violate the application's expectation of confidentiality or integrity of its payload data. -- The document date (8 July 2020) is 1387 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.nottingham-httpbis-retry' is defined on line 724, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-29 == Outdated reference: A later version (-13) exists of draft-ietf-quic-invariants-09 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-29 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-29 -- Duplicate reference: draft-ietf-quic-tls, mentioned in 'TLS13', was also mentioned in 'QUIC-TLS'. -- Duplicate reference: draft-nottingham-httpbis-retry, mentioned in 'I-D.nottingham-httpbis-retry', was also mentioned in 'HTTP-RETRY'. == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-29 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Kuehlewind 3 Internet-Draft Ericsson 4 Intended status: Informational B. Trammell 5 Expires: 9 January 2021 Google 6 8 July 2020 8 Applicability of the QUIC Transport Protocol 9 draft-ietf-quic-applicability-07 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 9 January 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 54 2. The Necessity of Fallback . . . . . . . . . . . . . . . . . . 3 55 3. Zero RTT . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Thinking in Zero RTT . . . . . . . . . . . . . . . . . . 4 57 3.2. Here There Be Dragons . . . . . . . . . . . . . . . . . . 4 58 3.3. Session resumption versus Keep-alive . . . . . . . . . . 5 59 4. Use of Streams . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Stream versus Flow Multiplexing . . . . . . . . . . . . . 7 61 4.2. Prioritization . . . . . . . . . . . . . . . . . . . . . 7 62 4.3. Flow Control Deadlocks . . . . . . . . . . . . . . . . . 7 63 5. Packetization and Latency . . . . . . . . . . . . . . . . . . 9 64 6. Port Selection and Application Endpoint Discovery . . . . . . 9 65 7. Connection Migration . . . . . . . . . . . . . . . . . . . . 10 66 8. Connection closure . . . . . . . . . . . . . . . . . . . . . 10 67 9. Information exposure and the Connection ID . . . . . . . . . 11 68 9.1. Server-Generated Connection ID . . . . . . . . . . . . . 12 69 9.2. Mitigating Timing Linkability with Connection ID 70 Migration . . . . . . . . . . . . . . . . . . . . . . . . 12 71 9.3. Using Server Retry for Redirection . . . . . . . . . . . 12 72 10. Use of Versions and Cryptographic Handshake . . . . . . . . . 13 73 11. Enabling New Versions . . . . . . . . . . . . . . . . . . . . 13 74 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 77 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 78 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 16.1. Normative References . . . . . . . . . . . . . . . . . . 15 80 16.2. Informative References . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 83 1. Introduction 85 QUIC [QUIC] is a new transport protocol currently under development 86 in the IETF quic working group, focusing on support of semantics as 87 needed for HTTP/2 [QUIC-HTTP] such as stream-multiplexing to avoid 88 head-of-line blocking. Based on current deployment practices, QUIC 89 is encapsulated in UDP. The version of QUIC that is currently under 90 development will integrate TLS 1.3 [TLS13] to encrypt all payload 91 data and most control information. 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 application use of HTTP/2 over QUIC as 96 well as the use of other application layer protocols over QUIC. For 97 specific guidance on how to integrate HTTP/2 with QUIC, see 98 [QUIC-HTTP]. 100 In the following sections we discuss specific caveats to QUIC's 101 applicability, and issues that application developers must consider 102 when using QUIC as a transport for their application. 104 1.1. Notational Conventions 106 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 107 document. It's not shouting; when these words are capitalized, they 108 have a special meaning as defined in [RFC2119]. 110 2. The Necessity of Fallback 112 QUIC uses UDP as a substrate for userspace implementation and port 113 numbers for NAT and middlebox traversal. While there is no evidence 114 of widespread, systematic disadvantage of UDP traffic compared to TCP 115 in the Internet [Edeline16], somewhere between three [Trammell16] and 116 five [Swett16] percent of networks simply block UDP traffic. All 117 applications running on top of QUIC must therefore either be prepared 118 to accept connectivity failure on such networks, or be engineered to 119 fall back to some other transport protocol. This fallback SHOULD 120 provide TLS 1.3 or equivalent cryptographic protection, if available, 121 in order to keep fallback from being exploited as a downgrade attack. 122 In the case of HTTP, this fallback is TLS 1.3 over TCP. 124 These applications must operate, perhaps with impaired functionality, 125 in the absence of features provided by QUIC not present in the 126 fallback protocol. For fallback to TLS over TCP, the most obvious 127 difference is that TCP does not provide stream multiplexing and 128 therefore stream multiplexing would need to be implemented in the 129 application layer if needed. Further, TCP without the TCP Fast Open 130 extension does not support 0-RTT session resumption. TCP Fast Open 131 can be requested by the connection initiator but might no be 132 supported by the far end or could be blocked on the network path. 133 Note that there is some evidence of middleboxes blocking SYN data 134 even if TFO was successfully negotiated (see [PaaschNanog]). 136 Any fallback mechanism is likely to impose a degradation of 137 performance; however, fallback MUST not silently violate the 138 application's expectation of confidentiality or integrity of its 139 payload data. 141 Moreover, while encryption (in this case TLS) is inseparably 142 integrated with QUIC, TLS negotiation over TCP can be blocked. In 143 case it is RECOMMENDED to abort the connection, allowing the 144 application to present a suitable prompt to the user that secure 145 communication is unavailable. 147 3. Zero RTT 149 QUIC provides for 0-RTT connection establishment. This presents 150 opportunities and challenges for applications using QUIC. 152 3.1. Thinking in Zero RTT 154 A transport protocol that provides 0-RTT connection establishment to 155 recently contacted servers is qualitatively different than one that 156 does not from the point of view of the application using it. 157 Relative trade-offs between the cost of closing and reopening a 158 connection and trying to keep it open are different; see Section 3.3. 160 Applications must be slightly rethought in order to make best use of 161 0-RTT resumption. Most importantly, application operations must be 162 divided into idempotent and non-idempotent operations, as only 163 idempotent operations may appear in 0-RTT packets. This implies that 164 the interface between the application and transport layer exposes 165 idempotence either explicitly or implicitly. 167 3.2. Here There Be Dragons 169 Retransmission or (malicious) replay of data contained in 0-RTT 170 resumption packets could cause the server side to receive two copies 171 of the same data. This is further described in [HTTP-RETRY]. Data 172 sent during 0-RTT resumption also cannot benefit from perfect forward 173 secrecy (PFS). 175 Data in the first flight sent by the client in a connection 176 established with 0-RTT MUST be idempotent (as specified in section 177 2.1 in [QUIC-TLS]). Applications MUST be designed, and their data 178 MUST be framed, such that multiple reception of idempotent data is 179 recognized as such by the receiverApplications that cannot treat data 180 that may appear in a 0-RTT connection establishment as idempotent 181 MUST NOT use 0-RTT establishment. For this reason the QUIC transport 182 SHOULD provide an interface for the application to indicate if 0-RTT 183 support is in general desired or a way to indicate whether data is 184 idempotent, whether PFS is a hard requirement for the application, 185 and/or whether rejected 0-RTT dgitata should be retransmitted or 186 withdrawn. 188 3.3. Session resumption versus Keep-alive 190 Because QUIC is encapsulated in UDP, applications using QUIC must 191 deal with short idle timeouts. Deployed stateful middleboxes will 192 generally establish state for UDP flows on the first packet state, 193 and keep state for much shorter idle periods than for TCP. According 194 to a 2010 study ([Hatonen10]), UDP applications can assume that any 195 NAT binding or other state entry will be expired after just thirty 196 seconds of inactivity. 198 A QUIC application has three strategies to deal with this issue: 200 * Ignore it, if the application-layer protocol consists only of 201 interactions with no or very short idle periods. 203 * Ensure there are no long idle periods. 205 * Resume the session after a long idle period, using 0-RTT 206 resumption when appropriate. 208 The first strategy is the easiest, but it only applies to certain 209 applications. 211 Either the server or the client in a QUIC application can send PING 212 frames as keep-alives, to prevent the connection and any on-path 213 state from timing out. Recommendations for the use of keep-alives 214 are application specific, mainly depending on the latency 215 requirements and message frequency of the application. In this case, 216 the application mapping must specify whether the client or server is 217 responsible for keeping the application alive. Note that sending 218 PING frames more frequently than every 30 seconds over long idle 219 periods may result in a too much unproductive traffic and power usage 220 for some situations. 222 Alternatively, the client (but not the server) can use session 223 resumption instead of sending keepalive traffic. In this case, a 224 client that wants to send data to a server over a connection idle 225 longer than the server's idle timeout (available from the 226 idle_timeout transport parameter) can simply reconnect. When 227 possible, this reconnection can use 0-RTT session resumption, 228 reducing the latency involved with restarting the connection. This 229 of course only applies in cases in which 0-RTT data is safe, when the 230 client is the restarting peer, and when the data to be sent is 231 idempotent. 233 The tradeoffs between resumption and keepalive need to be evaluated 234 on a per-application basis. However, in general applications should 235 use keepalives only in circumstances where continued communication is 236 highly likely; [QUIC-HTTP], for instance, recommends using PING 237 frames for keepalive only when a request is outstanding. 239 4. Use of Streams 241 QUIC's stream multiplexing feature allows applications to run 242 multiple streams over a single connection, without head-of-line 243 blocking between streams, associated at a point in time with a single 244 five-tuple. Stream data is carried within Frames, where one (UDP) 245 packet on the wire can carry one of multiple stream frames. 247 Stream can be independently open and closed, gracefully or by error. 248 If a critical stream for the application is closed, the application 249 can generate respective error messages on the application layer to 250 inform the other end or the higher layer and eventually indicate QUIC 251 to reset the connection. QUIC, however, does not need to know which 252 streams are critical, and does not provide an interface to 253 exceptional handling of any stream. There are special streams in 254 QUIC that are used for control on the QUIC connection, however, these 255 streams are not exposed to the application. 257 Mapping of application data to streams is application-specific and 258 described for HTTP/s in [QUIC-HTTP]. In general data that can be 259 processed independently, and therefore would suffer from head of line 260 blocking if forced to be received in order, should be transmitted 261 over different streams. If the application requires certain data to 262 be received in order, the same stream should be used for that data. 263 If there is a logical grouping of data chunks or messages, streams 264 can be reused, or a new stream can be opened for each chunk/message. 265 If one message is mapped to a single stream, resetting the stream to 266 expire an unacknowledged message can be used to emulate partial 267 reliability on a message basis. If a QUIC receiver has maximum 268 allowed concurrent streams open and the sender on the other end 269 indicates that more streams are needed, it doesn't automatically lead 270 to an increase of the maximum number of streams by the receiver. 271 Therefore it can be valuable to expose maximum number of allowed, 272 currently open and currently used streams to the application to make 273 the mapping of data to streams dependent on this information. 275 Further, streams have a maximum number of bytes that can be sent on 276 one stream. This number is high enough (2^64) that this will usually 277 not be reached with current applications. Applications that send 278 chunks of data over a very long period of time (such as days, months, 279 or years), should rather utilize the 0-RTT session resumption ability 280 provided by QUIC, than trying to maintain one connection open. 282 4.1. Stream versus Flow Multiplexing 284 Streams are meaningful only to the application; since stream 285 information is carried inside QUIC's encryption boundary, no 286 information about the stream(s) whose frames are carried by a given 287 packet is visible to the network. Therefore stream multiplexing is 288 not intended to be used for differentiating streams in terms of 289 network treatment. Application traffic requiring different network 290 treatment SHOULD therefore be carried over different five-tuples 291 (i.e. multiple QUIC connections). Given QUIC's ability to send 292 application data in the first RTT of a connection (if a previous 293 connection to the same host has been successfully established to 294 provide the respective credentials), the cost of establishing another 295 connection is extremely low. 297 4.2. Prioritization 299 Stream prioritization is not exposed to either the network or the 300 receiver. Prioritization is managed by the sender, and the QUIC 301 transport should provide an interface for applications to prioritize 302 streams [QUIC]. Further applications can implement their own 303 prioritization scheme on top of QUIC: an application protocol that 304 runs on top of QUIC can define explicit messages for signaling 305 priority, such as those defined for HTTP/2; it can define rules that 306 allow an endpoint to determine priority based on context; or it can 307 provide a higher level interface and leave the determination to the 308 application on top. 310 Priority handling of retransmissions can be implemented by the sender 311 in the transport layer. [QUIC] recommends to retransmit lost data 312 before new data, unless indicated differently by the application. 313 Currently, QUIC only provides fully reliable stream transmission, 314 which means that prioritization of retransmissions will be beneficial 315 in most cases, by filling in gaps and freeing up the flow control 316 window. For partially reliable or unreliable streams, priority 317 scheduling of retransmissions over data of higher-priority streams 318 might not be desirable. For such streams, QUIC could either provide 319 an explicit interface to control prioritization, or derive the 320 prioritization decision from the reliability level of the stream. 322 4.3. Flow Control Deadlocks 324 Flow control provides a means of managing access to the limited 325 buffers endpoints have for incoming data. This mechanism limits the 326 amount of data that can be in buffers in endpoints or in transit on 327 the network. However, there are several ways in which limits can 328 produce conditions that can cause a connection to either perform 329 suboptimally or deadlock. 331 Deadlocks in flow control are possible for any protocol that uses 332 QUIC, though whether they become a problem depends on how 333 implementations consume data and provide flow control credit. 334 Understanding what causes deadlocking might help implementations 335 avoid deadlocks. 337 Large messages can produce deadlocking if the recipient does not 338 process the message incrementally. If the message is larger than 339 flow control credit available and the recipient does not release 340 additional flow control credit until the entire message is received 341 and delivered, a deadlock can occur. This is possible even where 342 stream flow control limits are not reached because connection flow 343 control limits can be consumed by other streams. 345 A common flow control implementation technique is for a receiver to 346 extend credit to the sender as a the data consumer reads data. In 347 this setting, a length-prefixed message format makes it easier for 348 the data consumer to leave data unread in the receiver's buffers and 349 thereby withhold flow control credit. If flow control limits prevent 350 the remainder of a message from being sent, a deadlock will result. 351 A length prefix might also enable the detection of this sort of 352 deadlock. Where protocols have messages that might be processed as a 353 single unit, reserving flow control credit for the entire message 354 atomically ensures that this style of deadlock is less likely. 356 A data consumer can read all data as it becomes available to cause 357 the receiver to extend flow control credit to the sender and reduce 358 the chances of a deadlock. However, releasing flow control credit 359 might mean that the data consumer might need other means for holding 360 a peer accountable for the state it keeps for partially processed 361 messages. 363 Deadlocking can also occur if data on different streams is 364 interdependent. Suppose that data on one stream arrives before the 365 data on a second stream on which it depends. A deadlock can occur if 366 the first stream is left unread, preventing the receiver from 367 extending flow control credit for the second stream. To reduce the 368 likelihood of deadlock for interdependent data, the sender should 369 ensure that dependent data is not sent until the data it depends on 370 has been accounted for in both stream- and connection- level flow 371 control credit. 373 Some deadlocking scenarios might be resolved by cancelling affected 374 streams with STOP_SENDING or RST_STREAM. Cancelling some streams 375 results in the connection being terminated in some protocols. 377 5. Packetization and Latency 379 QUIC provides an interface that provides multiple streams to the 380 application; however, the application usually cannot control how data 381 transmitted over one stream is mapped into frames or how those frames 382 are bundled into packets. By default, QUIC will try to maximally 383 pack packets with one or more stream data frames to minimize 384 bandwidth consumption and computational costs (see section 8 of 385 [QUIC]). If there is not enough data available to fill a packet, 386 QUIC may even wait for a short time, to optimize bandwidth efficiency 387 instead of latency. This delay can either be pre-configured or 388 dynamically adjusted based on the observed sending pattern of the 389 application. If the application requires low latency, with only 390 small chunks of data to send, it may be valuable to indicate to QUIC 391 that all data should be send out immediately. Alternatively, if the 392 application expects to use a specific sending pattern, it can also 393 provide a suggested delay to QUIC for how long to wait before bundle 394 frames into a packet. 396 Similarly, an appliaction has usually no control about the length of 397 a QUIC packet on the wire. However, QUIC provides the ability to add 398 a padding frame to impact the packet size. This is mainly used by 399 QUIC itself in the first packet in order to ensure that the path is 400 capable of transferring packets of at least a certain size. 401 Additionally, a QUIC implementation can expose an application layer 402 interface to specify a certain packet size. This can either be used 403 by the application to force certian packet sizes in specific use 404 cases/networks, or ensure that all packets are equally sized to 405 conceal potential leakage of application layer information when the 406 data sent by the application are not greedy. Note the initial packet 407 must have a minimum size of 1200 bytes according to the QUIC 408 specification. A receiver of a smaller initial packet may reject 409 this packet in order to avoid amplification attacks. 411 6. Port Selection and Application Endpoint Discovery 413 In general, port numbers serves two purposes: "first, they provide a 414 demultiplexing identifier to differentiate transport sessions between 415 the same pair of endpoints, and second, they may also identify the 416 application protocol and associated service to which processes 417 connect" [RFC6335]. Note that the assumption that an application can 418 be identified in the network based on the port number is less true 419 today, due to encapsulation, mechanisms for dynamic port assignments 420 as well as NATs. 422 As QUIC is a general purpose transport protocol, there are no 423 requirements that servers use a particular UDP port for QUIC in 424 general. For applications with a fallback to TCP which do not 425 already have an alternate mapping to UDP, the registration (if 426 necessary) and use of the UDP port number corresponding to the TCP 427 port already registered for the application is RECOMMENDED. For 428 example, the default port for HTTP/3 [QUIC-HTTP] is UDP port 443, 429 analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. 431 Applications SHOULD define an alternate endpoint discovery mechanism 432 to allow the usage of ports other than the default. For example, 433 HTTP/3 ([QUIC-HTTP] sections 3.2 and 3.3) specifies the use of ALPN 434 [RFC7301] for service discovery which allows the server to use and 435 announce a different port number. Note that HTTP/3's ALPN token 436 ("h3") identifies not only the version of the application protocol, 437 but also the binding to QUIC as well as the version of QUIC itself; 438 this approach allows unambiguous agreement between the endpoints on 439 the protocol stack in use. 441 Note that given the prevalence of the assumption in network 442 management practice that a port number maps unambiguously to an 443 application, the use of ports that cannot easily be mapped to a 444 registered service name may lead to blocking or other interference by 445 network elements such as firewalls that rely on the port number for 446 application identification. 448 7. Connection Migration 450 QUIC supports connection migration. Even if lower-layer addresses 451 (usually the 4-tuple of IP addresses and ports) changes, QUIC packets 452 can still be associated with an existing connection based on the 453 Connection ID (see also section Section 9) in the QUIC header, if 454 present. This supports cases where address information changes due 455 to e.g. NAT rebinding or change of the local interface. Currently 456 QUIC only supports failover cases. Only one "path" can be used at a 457 time, and as soon as the new path is validated all traffic will be 458 switched over to the next path. Of course if an endpoint decided to 459 not use the Connection ID in short packets (Zero-length Conn ID) for 460 a certain connection, migration is not supported for that direction 461 of the connection. 463 8. Connection closure 465 QUIC connections are closed either by expiration of an idle timeout 466 or by an explicit indication of the application that a connection 467 should be closed (immediate close). While data could still be 468 received after the immediate close has been initiated by one endpoint 469 (for a limited time period), the expectation is that an immediate 470 close was negotiated at the application layer and therefore no 471 additional data is expected from both sides. 473 An immidate close will emit an CONNECTION_CLOSE frame. This frames 474 has two sets of types: one for QUIC internal problems that might lead 475 to connection closure, and one for closures initiated by the 476 application. An application using QUIC can define application- 477 specific error codes, e.g. see [QUIC-HTTP] section 8.1. In the case 478 of a grateful shut-down initiated by the application after 479 application layer negotiation, a NO_ERROR code is expected. Further, 480 the CONNECTION_CLOSE frame provides an optional reason field, that 481 can be used to append human-readable information to an error code. 482 Note that QUIC RESET_STREAM and STOP_SENDING frames provide similar 483 capablities. Usually application error codes are defined to be 484 applicabile to all three frames. 486 Alternatively, a QUIC connection will be silently closed by each 487 endpoint separately after an idle timeout. The idle timeout is 488 announce for each endpoint during connection established and should 489 be accessible by the application. If an application desires to keep 490 the connection open for longer than the announced timeout, it can 491 send keep-alives messages. See {#resumption-v-keepalive} for further 492 guidance. 494 9. Information exposure and the Connection ID 496 QUIC exposes some information to the network in the unencrypted part 497 of the header, either before the encryption context is established, 498 because the information is intended to be used by the network. QUIC 499 has a long header that is used during connection establishment and 500 for other control processes, and a short header that may be used for 501 data transmission in an established connection. While the long 502 header always exposes some information (such as the version and 503 Connection IDs), the short header exposes at most only a single 504 Connection ID. 506 Note that the Connection ID in the short header may be omitted. This 507 is a per-connection configuration option; if the Connection ID is not 508 present, then the peer omitting the connection ID will use the same 509 local address for the lifetime of the connection. 511 9.1. Server-Generated Connection ID 513 QUIC supports a server-generated Connection ID, transmitted to the 514 client during connection establishment (see Section 6.1 of [QUIC]). 515 Servers behind load balancers may need to change the Connection ID 516 during the handshake, encoding the identity of the server or 517 information about its load balancing pool, in order to support 518 stateless load balancing. Once the server generates a Connection ID 519 that encodes its identity, every CDN load balancer would be able to 520 forward the packets to that server without retaining connection 521 state. 523 Server-generated connection IDs should seek to obscure any encoding, 524 of routing identities or any other information. Exposing the server 525 mapping would allow linkage of multiple IP addresses to the same host 526 if the server also supports migration. Furthermore, this opens an 527 attack vector on specific servers or pools. 529 The best way to obscure an encoding is to appear random to observers, 530 which is most rigorously achieved with encryption. 532 9.2. Mitigating Timing Linkability with Connection ID Migration 534 While sufficiently robust connection ID generation schemes will 535 mitigate linkability issues, they do not provide full protection. 536 Analysis of the lifetimes of six-tuples (source and destination 537 addresses as well as the migrated CID) may expose these links anyway. 539 In the limit where connection migration in a server pool is rare, it 540 is trivial for an observer to associate two connection IDs. 541 Conversely, in the opposite limit where every server handles multiple 542 simultaneous migrations, even an exposed server mapping may be 543 insufficient information. 545 The most efficient mitigation for these attacks is operational, 546 either by using a load balancing architecture that loads more flows 547 onto a single server-side address, by coordinating the timing of 548 migrations to attempt to increase the number of simultaneous 549 migrations at a given time, or through other means. 551 9.3. Using Server Retry for Redirection 553 QUIC provides a Server Retry packet that can be sent by a server in 554 response to the Client Initial packet. The server may choose a new 555 Connection ID in that packet and the client will retry by sending 556 another Client Initial packet with the server-selected Connection ID. 557 This mechanism can be used to redirect a connection to a different 558 server, e.g. due to performance reasons or when servers in a server 559 pool are upgraded gradually, and therefore may support different 560 versions of QUIC. In this case, it is assumed that all servers 561 belonging to a certain pool are served in cooperation with load 562 balancers that forward the traffic based on the Connection ID. A 563 server can choose the Connection ID in the Server Retry packet such 564 that the load balancer will redirect the next Client Initial packet 565 to a different server in that pool. 567 10. Use of Versions and Cryptographic Handshake 569 Versioning in QUIC may change the protocol's behavior completely, 570 except for the meaning of a few header fields that have been declared 571 to be invariant [QUIC-INVARIANTS]. A version of QUIC with a higher 572 version number will not necessarily provide a better service, but 573 might simply provide a different feature set. As such, an 574 application needs to be able to select which versions of QUIC it 575 wants to use. 577 A new version could use an encryption scheme other than TLS 1.3 or 578 higher. [QUIC] specifies requirements for the cryptographic 579 handshake as currently realized by TLS 1.3 and described in a 580 separate specification [QUIC-TLS]. This split is performed to enable 581 light-weight versioning with different cryptographic handshakes. 583 11. Enabling New Versions 585 QUIC provides integrity protection for its version negotiation 586 process. This process assumes that the set of versions that a server 587 supports is fixed. This complicates the process for deploying new 588 QUIC versions or disabling old versions when servers operate in 589 clusters. 591 A server that rolls out a new version of QUIC can do so in three 592 stages. Each stage is completed across all server instances before 593 moving to the next stage. 595 In the first stage of deployment, all server instances start 596 accepting new connections with the new version. The new version can 597 be enabled progressively across a deployment, which allows for 598 selective testing. This is especially useful when the new version is 599 compatible with an old version, because the new version is more 600 likely to be used. 602 While enabling the new version, servers do not advertise the new 603 version in any Version Negotiation packets they send. This prevents 604 clients that receive a Version Negotiation packet from attempting to 605 connect to server instances that might not have the new version 606 enabled. 608 During the initial deployment, some clients will have received 609 Version Negotiation packets that indicate that the server does not 610 support the new version. Other clients might have successfully 611 connected with the new version and so will believe that the server 612 supports the new version. Therefore, servers need to allow for this 613 ambiguity when validating the negotiated version. 615 The second stage of deployment commences once all server instances 616 are able accept new connections with the new version. At this point, 617 all servers can start sending the new version in Version Negotiation 618 packets. 620 During the second stage, the server still allows for the possibility 621 that some clients believe the new version to be available and some do 622 not. This state will persist only for as long as any Version 623 Negotiation packets take to be transmitted and responded to. So the 624 third stage can follow after a relatively short delay. 626 The third stage completes the process by enabling validation of the 627 negotiation version as though the new version were disabled. 629 The process for disabling an old version or rolling back the 630 introduction of a new version uses the same process in reverse. 631 Servers disable validation of the old version, stop sending the old 632 version in Version Negotiation packets, then the old version is no 633 longer accepted. 635 12. IANA Considerations 637 This document has no actions for IANA; however, note that Section 6 638 recommends that application bindings to QUIC for applications using 639 TCP register UDP ports analogous to their existing TCP registrations. 641 13. Security Considerations 643 See the security considerations in [QUIC] and [QUIC-TLS]; the 644 security considerations for the underlying transport protocol are 645 relevant for applications using QUIC, as well. 647 Application developers should note that any fallback they use when 648 QUIC cannot be used due to network blocking of UDP SHOULD guarantee 649 the same security properties as QUIC; if this is not possible, the 650 connection SHOULD fail to allow the application to explicitly handle 651 fallback to a less-secure alternative. See Section 2. 653 14. Contributors 655 Igor Lubashev contributed text to Section 9 on server-selected 656 Connection IDs. 658 15. Acknowledgments 660 This work is partially supported by the European Commission under 661 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 662 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 663 for Education, Research, and Innovation under contract no. 15.0268. 664 This support does not imply endorsement. 666 16. References 668 16.1. Normative References 670 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 671 and Secure Transport", Work in Progress, Internet-Draft, 672 draft-ietf-quic-transport-29, 9 June 2020, 673 . 676 [QUIC-INVARIANTS] 677 Thomson, M., "Version-Independent Properties of QUIC", 678 Work in Progress, Internet-Draft, draft-ietf-quic- 679 invariants-09, 9 June 2020, . 682 [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 683 Work in Progress, Internet-Draft, draft-ietf-quic-tls-29, 684 9 June 2020, . 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, 689 DOI 10.17487/RFC2119, March 1997, 690 . 692 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 693 Cheshire, "Internet Assigned Numbers Authority (IANA) 694 Procedures for the Management of the Service Name and 695 Transport Protocol Port Number Registry", BCP 165, 696 RFC 6335, DOI 10.17487/RFC6335, August 2011, 697 . 699 [TLS13] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 700 Work in Progress, Internet-Draft, draft-ietf-quic-tls-29, 701 9 June 2020, . 704 16.2. Informative References 706 [Edeline16] 707 Edeline, K., Kuehlewind, M., Trammell, B., Aben, E., and 708 B. Donnet, "Using UDP for Internet Transport Evolution 709 (arXiv preprint 1612.07816)", 22 December 2016, 710 . 712 [Hatonen10] 713 Hatonen, S., Nyrhinen, A., Eggert, L., Strowes, S., 714 Sarolahti, P., and M. Kojo, "An experimental study of home 715 gateway characteristics (Proc. ACM IMC 2010)", October 716 2010. 718 [HTTP-RETRY] 719 Nottingham, M., "Retrying HTTP Requests", Work in 720 Progress, Internet-Draft, draft-nottingham-httpbis-retry- 721 01, 1 February 2017, . 724 [I-D.nottingham-httpbis-retry] 725 Nottingham, M., "Retrying HTTP Requests", Work in 726 Progress, Internet-Draft, draft-nottingham-httpbis-retry- 727 01, 1 February 2017, . 730 [PaaschNanog] 731 Paasch, C., "Network Support for TCP Fast Open (NANOG 67 732 presentation)", 13 June 2016, 733 . 736 [QUIC-HTTP] 737 Bishop, M., "Hypertext Transfer Protocol Version 3 738 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 739 quic-http-29, 9 June 2020, . 742 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 743 "Transport Layer Security (TLS) Application-Layer Protocol 744 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 745 July 2014, . 747 [Swett16] Swett, I., "QUIC Deployment Experience at Google (IETF96 748 QUIC BoF presentation)", 20 July 2016, 749 . 752 [Trammell16] 753 Trammell, B. and M. Kuehlewind, "Internet Path 754 Transparency Measurements using RIPE Atlas (RIPE72 MAT 755 presentation)", 25 May 2016, . 758 Authors' Addresses 760 Mirja Kuehlewind 761 Ericsson 763 Email: mirja.kuehlewind@ericsson.com 765 Brian Trammell 766 Google 767 Gustav-Gull-Platz 1 768 CH- 8004 Zurich 769 Switzerland 771 Email: ietf@trammell.ch