idnits 2.17.1 draft-ietf-quic-version-negotiation-03.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 (5 February 2021) is 1168 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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 Working Group D. Schinazi 3 Internet-Draft Google LLC 4 Intended status: Informational E. Rescorla 5 Expires: 9 August 2021 Mozilla 6 5 February 2021 8 Compatible Version Negotiation for QUIC 9 draft-ietf-quic-version-negotiation-03 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 of this work is encouraged to happen on the QUIC IETF 22 mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub 23 repository which contains the draft: https://github.com/quicwg/ 24 version-negotiation/ (https://github.com/quicwg/version- 25 negotiation/). 27 Discussion Venues 29 This note is to be removed before publishing as an RFC. 31 Source for this draft and an issue tracker can be found at 32 https://github.com/quicwg/version-negotiation. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 9 August 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 68 2. Compatible Versions . . . . . . . . . . . . . . . . . . . . . 3 69 3. Version Negotiation Mechanism . . . . . . . . . . . . . . . . 4 70 3.1. Connections and Version Negotiation . . . . . . . . . . . 5 71 3.2. Incompatible Version Negotiation . . . . . . . . . . . . 5 72 3.3. Compatible Version Negotiation . . . . . . . . . . . . . 5 73 4. Handshake Version Information . . . . . . . . . . . . . . . . 6 74 5. Version Downgrade Prevention . . . . . . . . . . . . . . . . 8 75 6. Supported Versions . . . . . . . . . . . . . . . . . . . . . 9 76 7. Client Choice of Original Version . . . . . . . . . . . . . . 9 77 8. Interaction with Retry . . . . . . . . . . . . . . . . . . . 9 78 9. Interaction with 0-RTT . . . . . . . . . . . . . . . . . . . 10 79 10. Considerations for Future Versions . . . . . . . . . . . . . 10 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 12.1. QUIC Transport Parameter . . . . . . . . . . . . . . . . 10 83 12.2. QUIC Transport Error Code . . . . . . . . . . . . . . . 11 84 13. Normative References . . . . . . . . . . . . . . . . . . . . 11 85 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 The version-invariant properties of QUIC [INV] define a version 91 negotiation (VN) packet but do not specify how an endpoint reacts 92 when it receives one. QUIC version 1 [QUIC] allows the server to use 93 a VN packet to indicate that the version the client offered is 94 unacceptable, but doesn't allow the client to safely make use of that 95 information to create a new connection with a mutually supported 96 version. With proper safety mechanisms in place, the VN packet can 97 be part of a mechanism to allow two QUIC implementations to negotiate 98 between two totally disjoint versions of QUIC, at the cost of an 99 extra round trip. However, it is beneficial to avoid that cost 100 whenever possible, especially given that most incremental versions 101 are broadly similar to the the previous version. 103 This specification describes a simple version negotiation mechanism 104 which optionally leverages similarities between versions and can 105 negotiate between the set of "compatible" versions in a single round 106 trip. 108 Discussion of this work is encouraged to happen on the QUIC IETF 109 mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub 110 repository which contains the draft: https://github.com/quicwg/ 111 version-negotiation/ (https://github.com/quicwg/version- 112 negotiation/). 114 1.1. Conventions and Definitions 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 2. Compatible Versions 124 If A and B are two distinct versions of QUIC, A is said to be 125 "compatible" with B if it is possible to take a first flight of 126 packets from version A and convert it into a first flight of packets 127 from version B. As an example, if versions A and B are absolutely 128 equal in their wire image and behavior during the handshake but 129 differ after the handshake, then A is compatible with B and B is 130 compatible with A. 132 Version compatibility is not bijective: it is possible for version A 133 to be compatible with version B and for B not to be compatible with 134 A. This could happen for example if version B is a strict superset 135 of version A. 137 Note that version compatibility does not mean that every single 138 possible instance of a first flight will succeed in conversion to the 139 other version. A first flight using version A is said to be 140 "compatible" with version B if two conditions are met: first that 141 version A is compatible with version B, and second that the 142 conversion of this first flight to version B is well-defined. For 143 example, if version B is equal to A in all aspects except it 144 introduced a new frame in its first flight that version A cannot 145 parse or even ignore, then B could still be compatible with A as 146 conversions would succeed for connections where that frame is not 147 used. In this example, first flights using version B that carry this 148 new frame would not be compatible with version A. 150 When a new version of QUIC is defined, it is assumed to not be 151 compatible with any other version unless otherwise specified. 152 Similarly, no other version is compatible with the new version unless 153 otherwise specified. Implementations MUST NOT assume compatibility 154 between versions unless explicitly specified. 156 Note that both endpoints might disagree on whether two versions are 157 compatible or not. For example, two versions could have been defined 158 concurrently and then specified as compatible in a third document 159 much later - in that scenario one endpoint might be aware of the 160 compatibility document while the other may not. 162 3. Version Negotiation Mechanism 164 This document specifies two means of performing version negotiation: 165 one "incompatible" which requires a round trip and is applicable to 166 all versions, and one "compatible" that allows saving the round trip 167 but only applies when the versions are compatible. 169 The client initiates a QUIC connection by sending a first flight of 170 QUIC packets with a long header to the server [INV]. We'll refer to 171 the version of those packets as the "original version". The client's 172 first flight includes handshake version information (see Section 4) 173 which will be used to optionally enable compatible version negotation 174 (see Section 3.3), and to prevent version downgrade attacks (see 175 Section 5). 177 Upon receiving this first flight, the server verifies whether it 178 knows how to parse first flights from the original version. If it 179 does not, then it starts incompatible version negotiation, see 180 Section 3.2. If the server can parse the first flight, it can either 181 establish the connection using the original version, or it MAY 182 attempt compatible version negotiation, see Section 3.3. 184 Note that it is possible for a server to have the ability to parse 185 the first flight of a given version without fully supporting it, in 186 the sense that it implements enough of the version's specification to 187 parse first flight packets but not enough to fully establish a 188 connection using that version. 190 3.1. Connections and Version Negotiation 192 QUIC connections are shared state between a client and a server 193 [INV]. The compatible version negotiation mechanism defined in this 194 document (see Section 3.3) operates inside of a QUIC connection; 195 i.e., the packets with the original version are part of the same 196 connection as the packets with the negotiated version. On the other 197 hand, the incompatible version negotiation mechanism, which leverages 198 QUIC Version Negotiation packets (see Section 3.2) conceptually 199 operates across two QUIC connections: one before the Version 200 Negotiation packet, and a distinct connection after. 202 3.2. Incompatible Version Negotiation 204 The server starts incompatible version negotiation by sending a VN 205 packet, listing all the versions that it does support. 207 Upon receiving the VN packet, the client will search for a version it 208 supports in the list provided by the server. If it doesn't find one, 209 it aborts the connection attempt. Otherwise, it selects a mutually 210 supported version and sends a new first flight with that version - we 211 refer to this version as the "negotiated version". 213 The new first flight will allow the endpoints to establish a 214 connection using the negotiated version. The handshake of the 215 negotiated version will exchange handshake version information (see 216 Section 4) required to ensure that VN was genuine, i.e. that no 217 attacker injected packets in order to influence the VN process, see 218 Section 5. 220 3.3. Compatible Version Negotiation 222 When the server can parse the client's first flight using the 223 original version, it can extract the client's handshake version 224 information (see Section 4). This contains the list of versions that 225 the client thinks its first flight is compatible with. 227 If the server supports one of the client's compatible versions, and 228 the server also believes that the original version is compatible with 229 this version, then the server converts the client's first flight to 230 that version and replies to the client as if it had received the 231 converted first flight. The version used by the server in its reply 232 is refered to as the "negotiated version". The server MUST NOT reply 233 with a version that is not present in the client's compatible 234 versions, unless it is the original version. 236 If the server does not find a compatible version, it will use the 237 original version if it supports it, and if it doesn't then the server 238 will perform incompatible version negotiation instead, see 239 Section 3.2. 241 For the duration of the compatible version negotiation process, 242 clients MUST use the same 5-tuple (source and destination IP 243 addresses and UDP port numbers). During that time, clients MUST also 244 use the same Destination Connection ID, except if the server 245 explicitly instructs the client to use a different Destination 246 Connection ID (for example, a QUIC version 1 server can accomplish 247 this by sending an INITIAL packet with a Source Connection ID that 248 differed from the client's Destination Connection ID). This allows 249 load balancers to ensure that packets for a given connection are 250 routed to the same server. 252 4. Handshake Version Information 254 During the handshake, endpoints will exchange handshake version 255 information, which is a blob of data that is defined below. In QUIC 256 version 1, the handshake version information is transmitted using a 257 new transport parameter, "version_negotiation". The contents of 258 handshake version information depend on whether the client or server 259 is sending it, and are shown below (using the notation from the 260 "Notational Conventions" section of [QUIC]): 262 Client Handshake Version Information { 263 Currently Attempted Version (32), 264 Previously Attempted Version (32), 265 Received Negotiation Version Count (i), 266 Received Negotiation Version (32) ..., 267 Compatible Version Count (i), 268 Compatible Version (32) ..., 269 } 271 Figure 1: Client Handshake Version Information 273 The content of each field is described below: 275 Currently Attempted Version: The version that the client is 276 attempting to use. This field MUST be equal to the value of the 277 Version field in the long header that carries this data. 279 Previously Attempted Version: If the client is sending this first 280 flight in response to a Version Negotiation packet, this field 281 contains the version that the client used in the previous first 282 flight that triggered the version negotiation packet. If the 283 client did not receive a Version Negotiation packet, this field 284 SHALL be all-zeroes. 286 Received Negotiation Version Count: A variable-length integer 287 specifying the number of Received Negotiation Version fields 288 following it. If the client is sending this first flight in 289 response to a Version Negotiation packet, the subsequent versions 290 SHALL include all the versions from that Version Negotiation 291 packet in order, even if they are not supported by the client 292 (even if the versions are reserved). If the client has not 293 received a Version Negotiation packet on this connection, this 294 field SHALL be 0. 296 Compatible Version Count: A variable-length integer specifying the 297 number of Compatible Version fields following it. The client 298 lists all versions that this first flight is compatible with in 299 the subsequent Compatible Version fields, ordered by descending 300 preference. Note that the version in the Currently Attempted 301 Version field MUST be included in the Compatible Version list to 302 allow the client to communicate the currently attempted version's 303 preference. Note that this preference is only advisory, servers 304 MAY choose to use their own preference instead. 306 Server Handshake Version Information { 307 Negotiated Version (32), 308 Supported Version Count (i), 309 Supported Version (32) ..., 310 } 312 Figure 2: Server Handshake Version Information 314 The content of each field is described below: 316 Negotiated Version: The version that the server chose to use for the 317 connection. This field MUST be equal to the value of the Version 318 field in the long header that carries this data. 320 Supported Version Count: A variable-length integer specifying the 321 number of Supported Version fields following it. The server 322 encodes all versions it supports in the subsequent list, ordered 323 by descending preference. Note that the version in the Negotiated 324 Version field MUST be included in the Supported Version list to 325 allow the server to communicate the negotiated version's 326 preference. Note that this preference is only advisory, clients 327 MAY choose to use their own preference instead. 329 Clients MAY include versions following the pattern "0x?a?a?a?a" in 330 their "Compatible Version" list, and the server in their "Supported 331 Version" list. Those versions are reserved to exercise version 332 negotiation (see the Versions section of [QUIC]), and MUST be ignored 333 when parsing these fields. On the other hand, the "Received 334 Negotiation Version" list MUST be identical to the received Version 335 Negotiation packet, so clients MUST NOT add or remove reserved 336 version from that list. 338 5. Version Downgrade Prevention 340 Clients MUST ignore any received Version Negotiation packets that 341 contain the version that they initially attempted. Once a client has 342 reacted to a Version Negotiation packet, it MUST drop all subsequent 343 Version Negotiation packets on that connection. 345 Servers MUST validate that the client's "Currently Attempted Version" 346 matches the version in the long header that carried the handshake 347 version information. Similarly, clients MUST validate that the 348 server's "Negotiated Version" matches the long header version. If an 349 endpoint's validation fails, it MUST close the connection. If the 350 connection was using QUIC version 1, it MUST be closed with a 351 transport error of type "VERSION_NEGOTIATION_ERROR". 353 When a server parses the client's handshake version information, if 354 the "Received Negotiation Version Count" is not zero, the server MUST 355 validate that it could have sent the Version Negotation packet 356 described by the client in response to a first flight of version 357 "Previously Attempted Version". In particular, the server MUST 358 ensure that there are no versions that it supports that are absent 359 from the Received Negotiation Versions, and that the ordering matches 360 the server's preference. If this validation fails, the server MUST 361 close the connection. If the connection was using QUIC version 1, it 362 MUST be closed with a transport error of type 363 "VERSION_NEGOTIATION_ERROR". This mitigates an attacker's ability to 364 forge Version Negotiation packets to force a version downgrade. 366 If a server operator is progressively deploying a new QUIC version 367 throughout its fleet, it MAY perform a two-step process where it 368 first progressively adds support for the new version, but without 369 enforcing its presence in "Received Negotiation Versions". Once all 370 servers have been upgraded, the second step is to start enforcing 371 that the new version is present in "Received Negotiation Versions". 372 This opens connections to version downgrades during the upgrade 373 window, since those could be due to clients communicating with both 374 upgraded and non-upgraded servers. 376 If an endpoint receives its peer's Handshake Version Information and 377 fails to parse it (for example, if it is too short), then the 378 endpoint MUST close the connection. If the connection was using QUIC 379 version 1, it MUST be closed with a transport error of type 380 "TRANSPORT_PARAMETER_ERROR". 382 6. Supported Versions 384 The server's "Supported Version" list allows it to communicate the 385 full list of versions it supports to the client. In the case where 386 clients initially attempt connections with the oldest version they 387 support, this allows them to be notified of more recent versions the 388 server supports. If the client notices that the server supports a 389 version that is more preferable that the one initially attempted by 390 default, the client SHOULD cache that information and attempt the 391 preferred version in subsequent connections. 393 7. Client Choice of Original Version 395 The client's first flight SHOULD be sent using the version that the 396 server is most likely to support (in the absence of other 397 information, this will often be the oldest version the client 398 supports). 400 8. Interaction with Retry 402 QUIC version 1 features retry packets, which the server can send to 403 validate the client's IP address before parsing the client's first 404 flight. This impacts compatible version negotiation because a server 405 who wishes to send a retry packet before parsing the client's first 406 flight won't have parsed the client's handshake version information 407 yet. If a future document wishes to define compatibility between two 408 versions that support retry, that document MUST specify how version 409 negotiation (both compatible and incompatible) interacts with retry 410 during a handshake that requires both. For example, that could be 411 accomplished by having the server send a retry packet first and 412 validating the client's IP address before starting version 413 negotiation and deciding whether to use compatible version 414 negotiation on that connection (in that scenario the retry packet 415 would be sent using the original version). 417 9. Interaction with 0-RTT 419 QUIC version 1 allows sending data from the client to the server 420 during the handshake, by using 0-RTT packets. If a future document 421 wishes to define compatibility between two versions that support 422 0-RTT, that document MUST address the scenario where there are 0-RTT 423 packets in the client's first flight. For example, this could be 424 accomplished by defining which transformations are applied to 0-RTT 425 packets. Alternatively, that document could specify that compatible 426 version negotiation causes 0-RTT data to be rejected by the server. 428 10. Considerations for Future Versions 430 In order to facilitate the deployment of future versions of QUIC, 431 designers of future versions SHOULD attempt to design their new 432 version such that commonly deployed versions are compatible with it. 433 For example, a successor to QUIC version 1 may wish to design its 434 transport parameters in a way that does not preclude compatibility. 435 Additionally, frames in QUIC version 1 do not use a self-describing 436 encoding, so unrecognized frame types cannot be parsed or ignored 437 (see the Extension Frames section of [QUIC]); this means that new 438 versions that wish to be very similar to QUIC version 1 and 439 compatible with it should avoid introducing new frames in initial 440 packets. 442 11. Security Considerations 444 The security of this version negotiation mechanism relies on the 445 authenticity of the handshake version information exchanged during 446 the handshake. In QUIC version 1, transport parameters are 447 authenticated ensuring the security of this mechanism. Negotiation 448 between compatible versions will have the security of the weakest 449 common version. 451 The requirement that versions not be assumed compatible mitigates the 452 possibility of cross-protocol attacks, but more analysis is still 453 needed here. 455 The presence of the "Attempted Version" and "Negotiated Version" 456 fields mitigates an attacker's ability to forge packets by altering 457 the version. 459 12. IANA Considerations 461 12.1. QUIC Transport Parameter 463 If this document is approved, IANA shall assign the following entry 464 in the QUIC Transport Parameter Registry: 466 +--------+---------------------+---------------+ 467 | Value | Parameter Name | Reference | 468 +--------+---------------------+---------------+ 469 | 0x73DB | version_negotiation | This document | 470 +--------+---------------------+---------------+ 472 12.2. QUIC Transport Error Code 474 If this document is approved, IANA shall assign the following entry 475 in the QUIC Transport Error Codes Registry: 477 +--------+---------------------------+---------------+ 478 | Value | Parameter Name | Reference | 479 +--------+---------------------------+---------------+ 480 | 0x53F8 | VERSION_NEGOTIATION_ERROR | This document | 481 +--------+---------------------------+---------------+ 483 13. Normative References 485 [INV] Thomson, M., "Version-Independent Properties of QUIC", 486 Work in Progress, Internet-Draft, draft-ietf-quic- 487 invariants-13, 14 January 2021, . 490 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 491 and Secure Transport", Work in Progress, Internet-Draft, 492 draft-ietf-quic-transport-34, 14 January 2021, 493 . 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, 498 DOI 10.17487/RFC2119, March 1997, 499 . 501 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 502 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 503 May 2017, . 505 Acknowledgments 507 The authors would like to thank Martin Thomson, Mike Bishop, Nick 508 Banks, Ryan Hamilton, and Roberto Peon for their input and 509 contributions. 511 Authors' Addresses 512 David Schinazi 513 Google LLC 514 1600 Amphitheatre Parkway 515 Mountain View, California 94043, 516 United States of America 518 Email: dschinazi.ietf@gmail.com 520 Eric Rescorla 521 Mozilla 523 Email: ekr@rtfm.com