idnits 2.17.1 draft-ietf-quic-version-negotiation-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 May 2021) is 1064 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC D. Schinazi 3 Internet-Draft Google LLC 4 Intended status: Standards Track E. Rescorla 5 Expires: 28 November 2021 Mozilla 6 27 May 2021 8 Compatible Version Negotiation for QUIC 9 draft-ietf-quic-version-negotiation-04 11 Abstract 13 QUIC does not provide a complete version negotiation mechanism but 14 instead only provides a way for the server to indicate that the 15 version the client offered is unacceptable. This document describes 16 a version negotiation mechanism that allows a client and server to 17 select a mutually supported version. Optionally, if the original and 18 negotiated version share a compatible first flight format, the 19 negotiation can take place without incurring an extra round trip. 21 Discussion Venues 23 This note is to be removed before publishing as an RFC. 25 Discussion of this document takes place on the QUIC Working Group 26 mailing list (quic@ietf.org), which is archived at 27 https://mailarchive.ietf.org/arch/browse/quic/. 29 Source for this draft and an issue tracker can be found at 30 https://github.com/quicwg/version-negotiation. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 28 November 2021. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 67 2. Server Deployments of QUIC . . . . . . . . . . . . . . . . . 3 68 3. Compatible Versions . . . . . . . . . . . . . . . . . . . . . 5 69 4. Version Negotiation Mechanism . . . . . . . . . . . . . . . . 6 70 4.1. Connections and Version Negotiation . . . . . . . . . . . 6 71 4.2. Incompatible Version Negotiation . . . . . . . . . . . . 7 72 4.3. Compatible Version Negotiation . . . . . . . . . . . . . 7 73 5. Version Information . . . . . . . . . . . . . . . . . . . . . 8 74 6. Version Downgrade Prevention . . . . . . . . . . . . . . . . 9 75 7. Client Choice of Original Version . . . . . . . . . . . . . . 10 76 8. Interaction with Retry . . . . . . . . . . . . . . . . . . . 10 77 9. Interaction with 0-RTT . . . . . . . . . . . . . . . . . . . 10 78 10. Considerations for Future Versions . . . . . . . . . . . . . 10 79 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 12.1. QUIC Transport Parameter . . . . . . . . . . . . . . . . 11 82 12.2. QUIC Transport Error Code . . . . . . . . . . . . . . . 11 83 13. Normative References . . . . . . . . . . . . . . . . . . . . 11 84 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 The version-invariant properties of QUIC [INV] define a version 90 negotiation (VN) packet but do not specify how an endpoint reacts 91 when it receives one. QUIC version 1 [QUIC] allows the server to use 92 a VN packet to indicate that the version the client offered is 93 unacceptable, but doesn't allow the client to safely make use of that 94 information to create a new connection with a mutually supported 95 version. With proper safety mechanisms in place, the VN packet can 96 be part of a mechanism to allow two QUIC implementations to negotiate 97 between two totally disjoint versions of QUIC, at the cost of an 98 extra round trip. However, it is beneficial to avoid that cost 99 whenever possible, especially given that most incremental versions 100 are broadly similar to the the previous version. 102 This specification describes a simple version negotiation mechanism 103 which optionally leverages similarities between versions and can 104 negotiate between the set of "compatible" versions in a single round 105 trip. 107 1.1. Conventions and Definitions 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 In this document, the Maximum Segment Lifetime (MSL) represents the 116 time a QUIC packet can exist in the network. Implementations can 117 make this configurable, and a RECOMMENDED value is one minute. 119 2. Server Deployments of QUIC 121 While this document mainly discusses a single QUIC server, it is 122 common for deployments of QUIC servers to include a fleet of multiple 123 server instances. We therefore define the following terms: 125 Acceptable Versions: This is the set of versions supported by a 126 given server instance. More specifically, these are the versions 127 that a given server instance will use if a client sends a first 128 flight using them. 130 Offered Versions: This is the set of versions that a given server 131 instance will send in a Version Negotiation packet if it receives 132 a first flight from an unknown version. This set will most often 133 be equal to the Acceptaple Versions set, except during short 134 transitions while versions are added or removed (see below). 136 Fully-Deployed Versions: This is the set of QUIC versions that is 137 supported and negotiated by every single QUIC server instance in 138 this deployment. If a deployment only contains a single server 139 instance, then this set is equal to the Offered Versions set, 140 except during short transitions while versions are added or 141 removed (see below). 143 If a deployment contains multiple server instances, software updates 144 may not happen at exactly the same time on all server instances. 145 Because of this, a client might receive a Version Negotiation packet 146 from a server instance that has already been updated and the client's 147 resulting connection attempt might reach a different server instance 148 which hasn't been updated yet. 150 However, even when there is only a single server instance, it is 151 still possible to receive a stale Version Negotiation packet if the 152 server performs its software update while the Version Negotiation 153 packet is in flight. 155 This could cause the version downgrade prevention mechanism described 156 in Section 6 to falsely detect a downgrade attack. To avoid that, 157 server operators SHOULD perform a three-step process when they wish 158 to add or remove support for a version: 160 When adding support for a new version: 162 * The first step is to progressively add support for the new version 163 to all server instances. This step updates the Acceptable 164 Versions but not the Offered Versions nor the Fully-Deployed 165 Versions. Once all server instances have been updated, operators 166 wait for at least one MSL to allow any in-flight Version 167 Negotiation packets to arrive. 169 * Then, the second step is to progressively add the new version to 170 Offered Versions on all server instances. Once complete, 171 operators wait for at least another MSL. 173 * Finally, the third step is to progressively add the new version to 174 Fully-Deployed Versions on all server instances. 176 When removing support for a version: 178 * The first step is to progressively remove the version from Fully- 179 Deployed Versions on all server instances. Once it has been 180 removed on all server instances, operators wait for at least one 181 MSL to allow any in-flight Version Negotiation packets to arrive. 183 * Then, the second step is to progressively remove the version from 184 Offered Versions on all server instances. Once complete, 185 operators wait for at least another MSL. 187 * Finally, the third step is to progressively remove support for the 188 version from all server instances. That step updates the 189 Acceptable Versions. 191 Note that this opens connections to version downgrades (but only for 192 partially-deployed versions) during the update window, since those 193 could be due to clients communicating with both updated and non- 194 updated server instances. 196 3. Compatible Versions 198 If A and B are two distinct versions of QUIC, A is said to be 199 "compatible" with B if it is possible to take a first flight of 200 packets from version A and convert it into a first flight of packets 201 from version B. As an example, if versions A and B are absolutely 202 equal in their wire image and behavior during the handshake but 203 differ after the handshake, then A is compatible with B and B is 204 compatible with A. 206 Version compatibility is not symmetric: it is possible for version A 207 to be compatible with version B and for B not to be compatible with 208 A. This could happen for example if version B is a strict superset 209 of version A. 211 Note that version compatibility does not mean that every single 212 possible instance of a first flight will succeed in conversion to the 213 other version. A first flight using version A is said to be 214 "compatible" with version B if two conditions are met: first that 215 version A is compatible with version B, and second that the 216 conversion of this first flight to version B is well-defined. For 217 example, if version B is equal to A in all aspects except it 218 introduced a new frame in its first flight that version A cannot 219 parse or even ignore, then B could still be compatible with A as 220 conversions would succeed for connections where that frame is not 221 used. In this example, first flights using version B that carry this 222 new frame would not be compatible with version A. 224 When a new version of QUIC is defined, it is assumed to not be 225 compatible with any other version unless otherwise specified. 226 Similarly, no other version is compatible with the new version unless 227 otherwise specified. Implementations MUST NOT assume compatibility 228 between versions unless explicitly specified. 230 Note that both endpoints might disagree on whether two versions are 231 compatible or not. For example, two versions could have been defined 232 concurrently and then specified as compatible in a third document 233 much later - in that scenario one endpoint might be aware of the 234 compatibility document while the other may not. 236 4. Version Negotiation Mechanism 238 This document specifies two means of performing version negotiation: 239 one "incompatible" which requires a round trip and is applicable to 240 all versions, and one "compatible" that allows saving the round trip 241 but only applies when the versions are compatible. 243 The client initiates a QUIC connection by sending a first flight of 244 QUIC packets with a long header to the server [INV]. We'll refer to 245 the version of those packets as the "original version". The client's 246 first flight includes Version Information (see Section 5) which will 247 be used to optionally enable compatible version negotation (see 248 Section 4.3), and to prevent version downgrade attacks (see 249 Section 6). 251 Upon receiving this first flight, the server verifies whether it 252 knows how to parse first flights from the original version. If it 253 does not, then it starts incompatible version negotiation, see 254 Section 4.2. If the server can parse the first flight, it can either 255 establish the connection using the original version, or it MAY 256 attempt compatible version negotiation, see Section 4.3. 258 Note that it is possible for a server to have the ability to parse 259 the first flight of a given version without fully supporting it, in 260 the sense that it implements enough of the version's specification to 261 parse first flight packets but not enough to fully establish a 262 connection using that version. 264 4.1. Connections and Version Negotiation 266 QUIC connections are shared state between a client and a server 267 [INV]. The compatible version negotiation mechanism defined in this 268 document (see Section 4.3) is performed as part of a single QUIC 269 connection; that is, the packets with the original version are part 270 of the same connection as the packets with the negotiated version. 272 In comparison, the incompatible version negotiation mechanism, which 273 leverages QUIC Version Negotiation packets (see Section 4.2) 274 conceptually operates across two QUIC connections: the connection 275 attempt prior to receiving the Version Negotiation packet is distinct 276 from the connection with the incompatible version that follows. 278 4.2. Incompatible Version Negotiation 280 The server starts incompatible version negotiation by sending a 281 Version Negotiation packet. This packet SHALL include each entry 282 from the server's set of Offered Versions (see Section 2) in a 283 Supported Version field. The server MAY add reserved versions (as 284 defined in the Versions section of [QUIC]) in Supported Version 285 fields. 287 Upon receiving the VN packet, the client will search for a version it 288 supports in the list provided by the server. If it doesn't find one, 289 it aborts the connection attempt. Otherwise, it selects a mutually 290 supported version and sends a new first flight with that version - we 291 refer to this version as the "negotiated version". 293 The new first flight will allow the endpoints to establish a 294 connection using the negotiated version. The handshake of the 295 negotiated version will exchange version information (see Section 5) 296 required to ensure that VN was genuine, i.e. that no attacker 297 injected packets in order to influence the VN process, see Section 6. 299 4.3. Compatible Version Negotiation 301 When the server can parse the client's first flight using the 302 original version, it can extract the client's Version Information 303 structure (see Section 5). This contains the list of versions that 304 the client thinks its first flight is compatible with. 306 If the server supports one of the client's compatible versions, and 307 the server also believes that the original version is compatible with 308 this version, then the server converts the client's first flight to 309 that version and replies to the client as if it had received the 310 converted first flight. The version used by the server in its reply 311 is refered to as the "negotiated version". The server MUST NOT reply 312 with a version that is not present in the client's compatible 313 versions, unless it is the original version. 315 If the server does not find a compatible version, it will use the 316 original version if it supports it, and if it doesn't then the server 317 will perform incompatible version negotiation instead, see 318 Section 4.2. 320 For the duration of the compatible version negotiation process, 321 clients MUST use the same 5-tuple (source and destination IP 322 addresses and UDP port numbers). During that time, clients MUST also 323 use the same Destination Connection ID, except if the server 324 explicitly instructs the client to use a different Destination 325 Connection ID (for example, a QUIC version 1 server can accomplish 326 this by sending an INITIAL packet with a Source Connection ID that 327 differed from the client's Destination Connection ID). This allows 328 load balancers to ensure that packets for a given connection are 329 routed to the same server. 331 5. Version Information 333 During the handshake, endpoints will exchange Version Information, 334 which is a blob of data that is defined below. In QUIC version 1, 335 the Version Information is transmitted using a new transport 336 parameter, "version_information". The contents of Version 337 Information are shown below (using the notation from the "Notational 338 Conventions" section of [QUIC]): 340 Version Information { 341 Chosen Version (32), 342 Other Versions (32) ..., 343 } 345 Figure 1: Version Information Format 347 The content of each field is described below: 349 Chosen Version: The version that the sender has chosen to use for 350 this connection. In most cases, this field will be equal to the 351 value of the Version field in the long header that carries this 352 data. 354 The contents of the "Other Versions" field depends on whether it is 355 sent by the client or by the server. 357 Client-Sent Other Versions: When sent by a client, the "Other 358 Versions" field lists all the versions that this first flight is 359 compatible with, ordered by descending preference. Note that the 360 version in the "Chosen Version" field MUST be included in this 361 list to allow the client to communicate the chosen version's 362 preference. Note that this preference is only advisory, servers 363 MAY choose to use their own preference instead. 365 Server-Sent Other Versions: When sent by a server, the "Other 366 Versions" field lists all the Fully-Deployed Versions of this 367 server deployment, see Section 2. 369 Clients and servers MAY both include versions following the pattern 370 "0x?a?a?a?a" in their "Other Versions" list. Those versions are 371 reserved to exercise version negotiation (see the Versions section of 372 [QUIC]), and will never be selected when choosing a version to use. 374 6. Version Downgrade Prevention 376 Clients MUST ignore any received Version Negotiation packets that 377 contain the version that they initially attempted. Once a client has 378 reacted to a Version Negotiation packet, it MUST drop all subsequent 379 Version Negotiation packets on that connection. 381 Both endpoints MUST parse their peer's Version Information during the 382 handshake. If parsing the Version Information failed (for example, 383 if it is too short or if its length is not divisible by four), then 384 the endpoint MUST close the connection; if the connection was using 385 QUIC version 1, that connection closure MUST use a transport error of 386 type "TRANSPORT_PARAMETER_ERROR". 388 If the Version Information was missing, the endpoints MAY complete 389 the handshake if they have reason to believe the peer might not 390 support this extension. However, if a client has reacted to a 391 Version Negotiation packet and the Version Information was missing, 392 the client MUST close the connection; if the connection was using 393 QUIC version 1, that connection closure MUST use a transport error of 394 type "VERSION_NEGOTIATION_ERROR". 396 If a client has reacted to a Version Negotiation packet, it MUST 397 validate that the server's "Other Versions" field does not contain 398 the client's original version, and that the client would have 399 selected the same negotiated version if it had received a Version 400 Negotiation packet whose Supported Versions field had the same 401 contents as the server's "Other Versions" field. If any of these 402 checks fail, the client MUST close the connection; if the connection 403 was using QUIC version 1, that connection closure MUST use a 404 transport error of type "VERSION_NEGOTIATION_ERROR". This connection 405 closure prevents an attacker from being able to use forged Version 406 Negotiation packets to force a version downgrade. 408 After the process of version negotiation in this document completes, 409 the version in use for the connection is the version that the server 410 sent in the "Chosen Version" field of its Version Information. That 411 remains true even if other versions were used in the Version field of 412 long headers at any point in the lifetime of the connection; 413 endpoints MUST NOT change the version that they consider to be in use 414 based on the Version field of long headers as that field could be 415 forged by attackers. 417 7. Client Choice of Original Version 419 The client's first flight SHOULD be sent using the version that the 420 server is most likely to support (in the absence of other 421 information, this will often be the oldest version the client 422 supports). 424 8. Interaction with Retry 426 QUIC version 1 features retry packets, which the server can send to 427 validate the client's IP address before parsing the client's first 428 flight. This impacts compatible version negotiation because a server 429 who wishes to send a retry packet before parsing the client's first 430 flight won't have parsed the client's Version Information yet. If a 431 future document wishes to define compatibility between two versions 432 that support retry, that document MUST specify how version 433 negotiation (both compatible and incompatible) interacts with retry 434 during a handshake that requires both. For example, that could be 435 accomplished by having the server send a retry packet first and 436 validating the client's IP address before starting version 437 negotiation and deciding whether to use compatible version 438 negotiation on that connection (in that scenario the retry packet 439 would be sent using the original version). 441 9. Interaction with 0-RTT 443 QUIC version 1 allows sending data from the client to the server 444 during the handshake, by using 0-RTT packets. If a future document 445 wishes to define compatibility between two versions that support 446 0-RTT, that document MUST address the scenario where there are 0-RTT 447 packets in the client's first flight. For example, this could be 448 accomplished by defining which transformations are applied to 0-RTT 449 packets. Alternatively, that document could specify that compatible 450 version negotiation causes 0-RTT data to be rejected by the server. 452 10. Considerations for Future Versions 454 In order to facilitate the deployment of future versions of QUIC, 455 designers of future versions SHOULD attempt to design their new 456 version such that commonly deployed versions are compatible with it. 457 For example, a successor to QUIC version 1 may wish to design its 458 transport parameters in a way that does not preclude compatibility. 459 Additionally, frames in QUIC version 1 do not use a self-describing 460 encoding, so unrecognized frame types cannot be parsed or ignored 461 (see the Extension Frames section of [QUIC]); this means that new 462 versions that wish to be very similar to QUIC version 1 and 463 compatible with it should avoid introducing new frames in initial 464 packets. 466 11. Security Considerations 468 The security of this version negotiation mechanism relies on the 469 authenticity of the Version Information exchanged during the 470 handshake. In QUIC version 1, transport parameters are authenticated 471 ensuring the security of this mechanism. Negotiation between 472 compatible versions will have the security of the weakest common 473 version. 475 The requirement that versions not be assumed compatible mitigates the 476 possibility of cross-protocol attacks, but more analysis is still 477 needed here. 479 12. IANA Considerations 481 12.1. QUIC Transport Parameter 483 If this document is approved, IANA shall assign the following entry 484 in the QUIC Transport Parameter Registry: 486 +----------+---------------------+---------------+ 487 | Value | Parameter Name | Reference | 488 +----------+---------------------+---------------+ 489 | 0xFF73DB | version_information | This document | 490 +----------+---------------------+---------------+ 492 12.2. QUIC Transport Error Code 494 If this document is approved, IANA shall assign the following entry 495 in the QUIC Transport Error Codes Registry: 497 +--------+---------------------------+---------------+ 498 | Value | Parameter Name | Reference | 499 +--------+---------------------------+---------------+ 500 | 0x53F8 | VERSION_NEGOTIATION_ERROR | This document | 501 +--------+---------------------------+---------------+ 503 13. Normative References 505 [INV] Thomson, M., "Version-Independent Properties of QUIC", 506 Work in Progress, Internet-Draft, draft-ietf-quic- 507 invariants-13, 14 January 2021, 508 . 511 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 512 and Secure Transport", Work in Progress, Internet-Draft, 513 draft-ietf-quic-transport-34, 14 January 2021, 514 . 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, 519 DOI 10.17487/RFC2119, March 1997, 520 . 522 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 523 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 524 May 2017, . 526 Acknowledgments 528 The authors would like to thank Martin Thomson, Mike Bishop, Nick 529 Banks, Ryan Hamilton, and Roberto Peon for their input and 530 contributions. 532 Authors' Addresses 534 David Schinazi 535 Google LLC 536 1600 Amphitheatre Parkway 537 Mountain View, California 94043, 538 United States of America 540 Email: dschinazi.ietf@gmail.com 542 Eric Rescorla 543 Mozilla 545 Email: ekr@rtfm.com