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