idnits 2.17.1 draft-ietf-quic-applicability-06.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 (6 January 2020) is 1571 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.nottingham-httpbis-retry' is defined on line 710, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-24 == Outdated reference: A later version (-13) exists of draft-ietf-quic-invariants-07 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-24 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-24 -- 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-24 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 July 2020 Google 6 6 January 2020 8 Applicability of the QUIC Transport Protocol 9 draft-ietf-quic-applicability-06 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 July 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 11 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 . . . . . . . . . 12 73 11. Enabling New Versions . . . . . . . . . . . . . . . . . . . . 13 74 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 77 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 78 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 16.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 16.2. Informative References . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 413 As QUIC is a general purpose transport protocol, there are no 414 requirements that servers use a particular UDP port for QUIC in 415 general. Instead, the same port number is used as would be used for 416 the same application over TCP. In the case of HTTP the expectation 417 is that port 443 is used, which has already been registered for "http 418 protocol over TLS/SSL". However, [QUIC-HTTP] also specifies the use 419 of Alt-Svc for HTTP/QUIC discovery which allows the server to use and 420 announce a different port number. 422 In general, port numbers serves two purposes: "first, they provide a 423 demultiplexing identifier to differentiate transport sessions between 424 the same pair of endpoints, and second, they may also identify the 425 application protocol and associated service to which processes 426 connect" [RFC6335]. Note that the assumption that an application can 427 be identified in the network based on the port number is less true 428 today, due to encapsulation, mechanisms for dynamic port assignments 429 as well as NATs. 431 However, whenever a non-standard port is used which does not enable 432 easy mapping to a registered service name, this can lead to blocking 433 by network elements such as firewalls that rely on the port number as 434 a first order of filtering. 436 7. Connection Migration 438 QUIC supports connection migration. Even if lower-layer addresses 439 (usually the 4-tuple of IP addresses and ports) changes, QUIC packets 440 can still be associated with an existing connection based on the 441 Connection ID (see also section Section 9) in the QUIC header, if 442 present. This supports cases where address information changes due 443 to e.g. NAT rebinding or change of the local interface. Currently 444 QUIC only supports failover cases. Only one "path" can be used at a 445 time, and as soon as the new path is validated all traffic will be 446 switched over to the next path. Of course if an endpoint decided to 447 not use the Connection ID in short packets (Zero-length Conn ID) for 448 a certain connection, migration is not supported for that direction 449 of the connection. 451 8. Connection closure 453 QUIC connections are closed either by expiration of an idle timeout 454 or by an explicit indication of the application that a connection 455 should be closed (immediate close). While data could still be 456 received after the immediate close has been initiated by one endpoint 457 (for a limited time period), the expectation is that an immediate 458 close was negotiated at the application layer and therefore no 459 additional data is expected from both sides. 461 An immidate close will emit an CONNECTION_CLOSE frame. This frames 462 has two sets of types: one for QUIC internal problems that might lead 463 to connection closure, and one for closures initiated by the 464 application. An application using QUIC can define application- 465 specific error codes, e.g. see [QUIC-HTTP] section 8.1. In the case 466 of a grateful shut-down initiated by the application after 467 application layer negotiation, a NO_ERROR code is expected. Further, 468 the CONNECTION_CLOSE frame provides an optional reason field, that 469 can be used to append human-readable information to an error code. 470 Note that QUIC RESET_STREAM and STOP_SENDING frames provide similar 471 capablities. Usually application error codes are defined to be 472 applicabile to all three frames. 474 Alternatively, a QUIC connection will be silently closed by each 475 endpoint separately after an idle timeout. The idle timeout is 476 announce for each endpoint during connection established and should 477 be accessible by the application. If an application desires to keep 478 the connection open for longer than the announced timeout, it can 479 send keep-alives messages. See {#resumption-v-keepalive} for further 480 guidance. 482 9. Information exposure and the Connection ID 484 QUIC exposes some information to the network in the unencrypted part 485 of the header, either before the encryption context is established, 486 because the information is intended to be used by the network. QUIC 487 has a long header that is used during connection establishment and 488 for other control processes, and a short header that may be used for 489 data transmission in an established connection. While the long 490 header always exposes some information (such as the version and 491 Connection IDs), the short header exposes at most only a single 492 Connection ID. 494 Note that the Connection ID in the short header may be omitted. This 495 is a per-connection configuration option; if the Connection ID is not 496 present, then the peer omitting the connection ID will use the same 497 local address for the lifetime of the connection. 499 9.1. Server-Generated Connection ID 501 QUIC supports a server-generated Connection ID, transmitted to the 502 client during connection establishment (see Section 6.1 of [QUIC]). 503 Servers behind load balancers may need to change the Connection ID 504 during the handshake, encoding the identity of the server or 505 information about its load balancing pool, in order to support 506 stateless load balancing. Once the server generates a Connection ID 507 that encodes its identity, every CDN load balancer would be able to 508 forward the packets to that server without retaining connection 509 state. 511 Server-generated connection IDs should seek to obscure any encoding, 512 of routing identities or any other information. Exposing the server 513 mapping would allow linkage of multiple IP addresses to the same host 514 if the server also supports migration. Furthermore, this opens an 515 attack vector on specific servers or pools. 517 The best way to obscure an encoding is to appear random to observers, 518 which is most rigorously achieved with encryption. 520 9.2. Mitigating Timing Linkability with Connection ID Migration 522 While sufficiently robust connection ID generation schemes will 523 mitigate linkability issues, they do not provide full protection. 524 Analysis of the lifetimes of six-tuples (source and destination 525 addresses as well as the migrated CID) may expose these links anyway. 527 In the limit where connection migration in a server pool is rare, it 528 is trivial for an observer to associate two connection IDs. 529 Conversely, in the opposite limit where every server handles multiple 530 simultaneous migrations, even an exposed server mapping may be 531 insufficient information. 533 The most efficient mitigation for these attacks is operational, 534 either by using a load balancing architecture that loads more flows 535 onto a single server-side address, by coordinating the timing of 536 migrations to attempt to increase the number of simultaneous 537 migrations at a given time, or through other means. 539 9.3. Using Server Retry for Redirection 541 QUIC provides a Server Retry packet that can be sent by a server in 542 response to the Client Initial packet. The server may choose a new 543 Connection ID in that packet and the client will retry by sending 544 another Client Initial packet with the server-selected Connection ID. 545 This mechanism can be used to redirect a connection to a different 546 server, e.g. due to performance reasons or when servers in a server 547 pool are upgraded gradually, and therefore may support different 548 versions of QUIC. In this case, it is assumed that all servers 549 belonging to a certain pool are served in cooperation with load 550 balancers that forward the traffic based on the Connection ID. A 551 server can choose the Connection ID in the Server Retry packet such 552 that the load balancer will redirect the next Client Initial packet 553 to a different server in that pool. 555 10. Use of Versions and Cryptographic Handshake 557 Versioning in QUIC may change the protocol's behavior completely, 558 except for the meaning of a few header fields that have been declared 559 to be invariant [QUIC-INVARIANTS]. A version of QUIC with a higher 560 version number will not necessarily provide a better service, but 561 might simply provide a different feature set. As such, an 562 application needs to be able to select which versions of QUIC it 563 wants to use. 565 A new version could use an encryption scheme other than TLS 1.3 or 566 higher. [QUIC] specifies requirements for the cryptographic 567 handshake as currently realized by TLS 1.3 and described in a 568 separate specification [QUIC-TLS]. This split is performed to enable 569 light-weight versioning with different cryptographic handshakes. 571 11. Enabling New Versions 573 QUIC provides integrity protection for its version negotiation 574 process. This process assumes that the set of versions that a server 575 supports is fixed. This complicates the process for deploying new 576 QUIC versions or disabling old versions when servers operate in 577 clusters. 579 A server that rolls out a new version of QUIC can do so in three 580 stages. Each stage is completed across all server instances before 581 moving to the next stage. 583 In the first stage of deployment, all server instances start 584 accepting new connections with the new version. The new version can 585 be enabled progressively across a deployment, which allows for 586 selective testing. This is especially useful when the new version is 587 compatible with an old version, because the new version is more 588 likely to be used. 590 While enabling the new version, servers do not advertise the new 591 version in any Version Negotiation packets they send. This prevents 592 clients that receive a Version Negotiation packet from attempting to 593 connect to server instances that might not have the new version 594 enabled. 596 During the initial deployment, some clients will have received 597 Version Negotiation packets that indicate that the server does not 598 support the new version. Other clients might have successfully 599 connected with the new version and so will believe that the server 600 supports the new version. Therefore, servers need to allow for this 601 ambiguity when validating the negotiated version. 603 The second stage of deployment commences once all server instances 604 are able accept new connections with the new version. At this point, 605 all servers can start sending the new version in Version Negotiation 606 packets. 608 During the second stage, the server still allows for the possibility 609 that some clients believe the new version to be available and some do 610 not. This state will persist only for as long as any Version 611 Negotiation packets take to be transmitted and responded to. So the 612 third stage can follow after a relatively short delay. 614 The third stage completes the process by enabling validation of the 615 negotiation version as though the new version were disabled. 617 The process for disabling an old version or rolling back the 618 introduction of a new version uses the same process in reverse. 619 Servers disable validation of the old version, stop sending the old 620 version in Version Negotiation packets, then the old version is no 621 longer accepted. 623 12. IANA Considerations 625 This document has no actions for IANA. 627 13. Security Considerations 629 See the security considerations in [QUIC] and [QUIC-TLS]; the 630 security considerations for the underlying transport protocol are 631 relevant for applications using QUIC, as well. 633 Application developers should note that any fallback they use when 634 QUIC cannot be used due to network blocking of UDP SHOULD guarantee 635 the same security properties as QUIC; if this is not possible, the 636 connection SHOULD fail to allow the application to explicitly handle 637 fallback to a less-secure alternative. See Section 2. 639 14. Contributors 641 Igor Lubashev contributed text to Section 9 on server-selected 642 Connection IDs. 644 15. Acknowledgments 646 This work is partially supported by the European Commission under 647 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 648 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 649 for Education, Research, and Innovation under contract no. 15.0268. 650 This support does not imply endorsement. 652 16. References 654 16.1. Normative References 656 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 657 and Secure Transport", Work in Progress, Internet-Draft, 658 draft-ietf-quic-transport-24, 3 November 2019, 659 . 662 [QUIC-INVARIANTS] 663 Thomson, M., "Version-Independent Properties of QUIC", 664 Work in Progress, Internet-Draft, draft-ietf-quic- 665 invariants-07, 11 September 2019, . 668 [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 669 Work in Progress, Internet-Draft, draft-ietf-quic-tls-24, 670 3 November 2019, . 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, 675 DOI 10.17487/RFC2119, March 1997, 676 . 678 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 679 Cheshire, "Internet Assigned Numbers Authority (IANA) 680 Procedures for the Management of the Service Name and 681 Transport Protocol Port Number Registry", BCP 165, 682 RFC 6335, DOI 10.17487/RFC6335, August 2011, 683 . 685 [TLS13] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 686 Work in Progress, Internet-Draft, draft-ietf-quic-tls-24, 687 3 November 2019, . 690 16.2. Informative References 692 [Edeline16] 693 Edeline, K., Kuehlewind, M., Trammell, B., Aben, E., and 694 B. Donnet, "Using UDP for Internet Transport Evolution 695 (arXiv preprint 1612.07816)", 22 December 2016, 696 . 698 [Hatonen10] 699 Hatonen, S., Nyrhinen, A., Eggert, L., Strowes, S., 700 Sarolahti, P., and M. Kojo, "An experimental study of home 701 gateway characteristics (Proc. ACM IMC 2010)", October 702 2010. 704 [HTTP-RETRY] 705 Nottingham, M., "Retrying HTTP Requests", Work in 706 Progress, Internet-Draft, draft-nottingham-httpbis-retry- 707 01, 1 February 2017, . 710 [I-D.nottingham-httpbis-retry] 711 Nottingham, M., "Retrying HTTP Requests", Work in 712 Progress, Internet-Draft, draft-nottingham-httpbis-retry- 713 01, 1 February 2017, . 716 [PaaschNanog] 717 Paasch, C., "Network Support for TCP Fast Open (NANOG 67 718 presentation)", 13 June 2016, 719 . 722 [QUIC-HTTP] 723 Bishop, M., "Hypertext Transfer Protocol Version 3 724 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 725 quic-http-24, 4 November 2019, . 728 [Swett16] Swett, I., "QUIC Deployment Experience at Google (IETF96 729 QUIC BoF presentation)", 20 July 2016, 730 . 733 [Trammell16] 734 Trammell, B. and M. Kuehlewind, "Internet Path 735 Transparency Measurements using RIPE Atlas (RIPE72 MAT 736 presentation)", 25 May 2016, . 739 Authors' Addresses 741 Mirja Kuehlewind 742 Ericsson 744 Email: mirja.kuehlewind@ericsson.com 746 Brian Trammell 747 Google 748 Gustav-Gull-Platz 1 749 CH- 8004 Zurich 750 Switzerland 752 Email: ietf@trammell.ch