| < draft-ietf-quic-version-negotiation-06.txt | draft-ietf-quic-version-negotiation-07.txt > | |||
|---|---|---|---|---|
| QUIC D. Schinazi | QUIC D. Schinazi | |||
| Internet-Draft Google LLC | Internet-Draft Google LLC | |||
| Intended status: Standards Track E. Rescorla | Intended status: Standards Track E. Rescorla | |||
| Expires: 8 September 2022 Mozilla | Expires: 8 October 2022 Mozilla | |||
| 7 March 2022 | 6 April 2022 | |||
| Compatible Version Negotiation for QUIC | Compatible Version Negotiation for QUIC | |||
| draft-ietf-quic-version-negotiation-06 | draft-ietf-quic-version-negotiation-07 | |||
| Abstract | Abstract | |||
| QUIC does not provide a complete version negotiation mechanism but | QUIC does not provide a complete version negotiation mechanism but | |||
| instead only provides a way for the server to indicate that the | instead only provides a way for the server to indicate that the | |||
| version the client offered is unacceptable. This document describes | version the client chose is unacceptable. This document describes a | |||
| a version negotiation mechanism that allows a client and server to | version negotiation mechanism that allows a client and server to | |||
| select a mutually supported version. Optionally, if the original and | select a mutually supported version. Optionally, if the client's | |||
| negotiated version share a compatible first flight format, the | chosen version and the negotiated version share a compatible first | |||
| negotiation can take place without incurring an extra round trip. | flight format, the negotiation can take place without incurring an | |||
| extra round trip. | ||||
| Discussion Venues | About This Document | |||
| This note is to be removed before publishing as an RFC. | This note is to be removed before publishing as an RFC. | |||
| The latest revision of this draft can be found at | ||||
| https://quicwg.github.io/version-negotiation/draft-ietf-quic-version- | ||||
| negotiation.html. Status information for this document may be found | ||||
| at https://datatracker.ietf.org/doc/draft-ietf-quic-version- | ||||
| negotiation/. | ||||
| Discussion of this document takes place on the QUIC Working Group | Discussion of this document takes place on the QUIC Working Group | |||
| mailing list (quic@ietf.org), which is archived at | mailing list (mailto:quic@ietf.org), which is archived at | |||
| https://mailarchive.ietf.org/arch/browse/quic/. | https://mailarchive.ietf.org/arch/browse/quic/. | |||
| Source for this draft and an issue tracker can be found at | Source for this draft and an issue tracker can be found at | |||
| https://github.com/quicwg/version-negotiation. | https://github.com/quicwg/version-negotiation. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 8 September 2022. | This Internet-Draft will expire on 8 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 | 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 | |||
| 2. Version Negotiation Mechanism . . . . . . . . . . . . . . . . 3 | 2. Version Negotiation Mechanism . . . . . . . . . . . . . . . . 3 | |||
| 2.1. Incompatible Version Negotiation . . . . . . . . . . . . 4 | 2.1. Incompatible Version Negotiation . . . . . . . . . . . . 4 | |||
| 2.2. Compatible Versions . . . . . . . . . . . . . . . . . . . 4 | 2.2. Compatible Versions . . . . . . . . . . . . . . . . . . . 5 | |||
| 2.3. Compatible Version Negotiation . . . . . . . . . . . . . 5 | 2.3. Compatible Version Negotiation . . . . . . . . . . . . . 6 | |||
| 2.4. Connections and Version Negotiation . . . . . . . . . . . 6 | 2.4. Connections and Version Negotiation . . . . . . . . . . . 7 | |||
| 2.5. Client Choice of Original Version . . . . . . . . . . . . 7 | 2.5. Client Choice of Original Version . . . . . . . . . . . . 8 | |||
| 3. Version Information . . . . . . . . . . . . . . . . . . . . . 7 | 3. Version Information . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 4. Version Downgrade Prevention . . . . . . . . . . . . . . . . 8 | 4. Version Downgrade Prevention . . . . . . . . . . . . . . . . 9 | |||
| 5. Server Deployments of QUIC . . . . . . . . . . . . . . . . . 9 | 5. Server Deployments of QUIC . . . . . . . . . . . . . . . . . 10 | |||
| 6. Considerations for Future Versions . . . . . . . . . . . . . 11 | 6. Application Layer Protocol Considerations . . . . . . . . . . 12 | |||
| 6.1. Interaction with Retry . . . . . . . . . . . . . . . . . 11 | 7. Considerations for Future Versions . . . . . . . . . . . . . 12 | |||
| 6.2. Interaction with TLS resumption . . . . . . . . . . . . . 12 | 7.1. Interaction with Retry . . . . . . . . . . . . . . . . . 13 | |||
| 6.3. Interaction with 0-RTT . . . . . . . . . . . . . . . . . 12 | 7.2. Interaction with TLS resumption . . . . . . . . . . . . . 13 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 7.3. Interaction with 0-RTT . . . . . . . . . . . . . . . . . 13 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 8. Special Handling for QUIC Version 1 . . . . . . . . . . . . . 14 | |||
| 8.1. QUIC Transport Parameter . . . . . . . . . . . . . . . . 13 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
| 8.2. QUIC Transport Error Code . . . . . . . . . . . . . . . . 13 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 9. Normative References . . . . . . . . . . . . . . . . . . . . 13 | 10.1. QUIC Transport Parameter . . . . . . . . . . . . . . . . 14 | |||
| Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 10.2. QUIC Transport Error Code . . . . . . . . . . . . . . . 15 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 | |||
| Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | ||||
| 1. Introduction | 1. Introduction | |||
| The version-invariant properties of QUIC [INV] define a Version | The version-invariant properties of QUIC [INV] define a Version | |||
| Negotiation packet but do not specify how an endpoint reacts when it | Negotiation packet but do not specify how an endpoint reacts when it | |||
| receives one. QUIC version 1 [QUIC] allows the server to use a | receives one. QUIC version 1 [QUIC] allows the server to use a | |||
| Version Negotiation packet to indicate that the version the client | Version Negotiation packet to indicate that the version the client | |||
| offered is unacceptable, but doesn't allow the client to safely make | chose is unacceptable, but doesn't allow the client to safely make | |||
| use of that information to create a new connection with a mutually | use of that information to create a new connection with a mutually | |||
| supported version. | supported version. | |||
| With proper safety mechanisms in place, the Version Negotiation | With proper safety mechanisms in place, the Version Negotiation | |||
| packet can be part of a mechanism to allow two QUIC implementations | packet can be part of a mechanism to allow two QUIC implementations | |||
| to negotiate between two totally disjoint versions of QUIC. This | to negotiate between two totally disjoint versions of QUIC. This | |||
| document specifies version negotiation using Version Negotiation | document specifies version negotiation using Version Negotiation | |||
| packets, which adds an extra round trip to connection establishment | packets, which adds an extra round trip to connection establishment | |||
| if needed. | if needed. | |||
| skipping to change at page 3, line 23 ¶ | skipping to change at page 3, line 33 ¶ | |||
| especially given that most incremental versions are broadly similar | especially given that most incremental versions are broadly similar | |||
| to the the previous version. This specification also defines a | to the the previous version. This specification also defines a | |||
| simple version negotiation mechanism which leverages similarities | simple version negotiation mechanism which leverages similarities | |||
| between versions and can negotiate between the set of "compatible" | between versions and can negotiate between the set of "compatible" | |||
| versions without additional round trips. | versions without additional round trips. | |||
| 1.1. Conventions and Definitions | 1.1. Conventions and Definitions | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| In this document, the Maximum Segment Lifetime (MSL) represents the | In this document, the Maximum Segment Lifetime (MSL) represents the | |||
| time a QUIC packet can exist in the network. Implementations can | time a QUIC packet can exist in the network. Implementations can | |||
| make this configurable, and a RECOMMENDED value is one minute. | make this configurable, and a RECOMMENDED value is one minute. | |||
| 2. Version Negotiation Mechanism | 2. Version Negotiation Mechanism | |||
| This document specifies two means of performing version negotiation: | This document specifies two means of performing version negotiation: | |||
| one "incompatible" which requires a round trip and is applicable to | one "incompatible" which requires a round trip and is applicable to | |||
| all versions, and one "compatible" that allows saving the round trip | all versions, and one "compatible" that allows saving the round trip | |||
| but only applies when the versions are compatible. | but only applies when the versions are compatible. | |||
| The client initiates a QUIC connection by sending a first flight of | The client initiates a QUIC connection by choosing an initial version | |||
| QUIC packets with a long header to the server [INV]. We'll refer to | and sending a first flight of QUIC packets with a long header to the | |||
| the version of those packets as the "original version". The client's | server [INV]. The client's first flight includes Version Information | |||
| first flight includes Version Information (see Section 3) which will | (see Section 3) which will be used to optionally enable compatible | |||
| be used to optionally enable compatible version negotation (see | version negotation (see Section 2.3), and to prevent version | |||
| Section 2.3), and to prevent version downgrade attacks (see | downgrade attacks (see Section 4). We'll refer to the version of the | |||
| Section 4). | very first packets the client sends as the "original version" and the | |||
| version of the first packets the client sends in a given QUIC | ||||
| connection as the "client's chosen version". | ||||
| Upon receiving this first flight, the server verifies whether it | Upon receiving this first flight, the server verifies whether it | |||
| knows how to parse first flights from the original version. If it | knows how to parse first flights from the original version. If it | |||
| does not, then it starts incompatible version negotiation, see | does not, then it starts incompatible version negotiation, see | |||
| Section 2.1. If the server can parse the first flight, it can either | Section 2.1, which causes the client to initiate a new connection | |||
| establish the connection using the original version, or it MAY | with a different version. For instance, if the client initiates a | |||
| attempt compatible version negotiation, see Section 2.3. | connection with version A and the server starts incompatible version | |||
| negotiation and the client then initiates a new connection with | ||||
| version B, we say that the first connection's client chosen version | ||||
| is A, the second connection's client chosen version is B, and the | ||||
| original version for the entire sequence is A. | ||||
| If the server can parse the first flight, it can either establish the | ||||
| connection using the client's chosen version, or it MAY select any | ||||
| other compatible version, as described in Section 2.3. | ||||
| Note that it is possible for a server to have the ability to parse | Note that it is possible for a server to have the ability to parse | |||
| the first flight of a given version without fully supporting it, in | the first flight of a given version without fully supporting it, in | |||
| the sense that it implements enough of the version's specification to | the sense that it implements enough of the version's specification to | |||
| parse first flight packets but not enough to fully establish a | parse first flight packets but not enough to fully establish a | |||
| connection using that version. | connection using that version. | |||
| 2.1. Incompatible Version Negotiation | 2.1. Incompatible Version Negotiation | |||
| The server starts incompatible version negotiation by sending a | The server starts incompatible version negotiation by sending a | |||
| skipping to change at page 5, line 8 ¶ | skipping to change at page 5, line 27 ¶ | |||
| from version B. As an example, if versions A and B are absolutely | from version B. As an example, if versions A and B are absolutely | |||
| equal in their wire image and behavior during the handshake but | equal in their wire image and behavior during the handshake but | |||
| differ after the handshake, then A is compatible with B and B is | differ after the handshake, then A is compatible with B and B is | |||
| compatible with A. Note that the conversion of the first flight can | compatible with A. Note that the conversion of the first flight can | |||
| be lossy: some data such as QUIC version 1 0-RTT packets could be | be lossy: some data such as QUIC version 1 0-RTT packets could be | |||
| ignored during conversion and retransmitted later. | ignored during conversion and retransmitted later. | |||
| Version compatibility is not symmetric: it is possible for version A | Version compatibility is not symmetric: it is possible for version A | |||
| to be compatible with version B and for B not to be compatible with | to be compatible with version B and for B not to be compatible with | |||
| A. This could happen for example if version B is a strict superset | A. This could happen for example if version B is a strict superset | |||
| of version A. | of version A: if version A includes the concept of streams and STREAM | |||
| frames, and version B includes the concepts of streams and tubes | ||||
| along with STREAM and TUBE frames, then A would be compatible with B | ||||
| but B would not be compatible with A. | ||||
| Note that version compatibility does not mean that every single | Note that version compatibility does not mean that every single | |||
| possible instance of a first flight will succeed in conversion to the | possible instance of a first flight will succeed in conversion to the | |||
| other version. A first flight using version A is said to be | other version. A first flight using version A is said to be | |||
| "compatible" with version B if two conditions are met: first that | "compatible" with version B if two conditions are met: first that | |||
| version A is compatible with version B, and second that the | version A is compatible with version B, and second that the | |||
| conversion of this first flight to version B is well-defined. For | conversion of this first flight to version B is well-defined. For | |||
| example, if version B is equal to A in all aspects except it | example, if version B is equal to A in all aspects except it | |||
| introduced a new frame in its first flight that version A cannot | introduced a new frame in its first flight that version A cannot | |||
| parse or even ignore, then B could still be compatible with A as | parse or even ignore, then B could still be compatible with A as | |||
| skipping to change at page 5, line 35 ¶ | skipping to change at page 6, line 11 ¶ | |||
| Similarly, no other version is compatible with the new version unless | Similarly, no other version is compatible with the new version unless | |||
| otherwise specified. Implementations MUST NOT assume compatibility | otherwise specified. Implementations MUST NOT assume compatibility | |||
| between versions unless explicitly specified. | between versions unless explicitly specified. | |||
| Note that both endpoints might disagree on whether two versions are | Note that both endpoints might disagree on whether two versions are | |||
| compatible or not. For example, two versions could have been defined | compatible or not. For example, two versions could have been defined | |||
| concurrently and then specified as compatible in a third document | concurrently and then specified as compatible in a third document | |||
| much later - in that scenario one endpoint might be aware of the | much later - in that scenario one endpoint might be aware of the | |||
| compatibility document while the other may not. | compatibility document while the other may not. | |||
| When a client creates a QUIC connection, its goal is to use an | ||||
| application layer protocol. Therefore, when considering which | ||||
| versions are compatible, clients will only consider versions that | ||||
| support one of the intended application layer protocols. For | ||||
| example, if the client's first flight advertises multiple Application | ||||
| Layer Protocol Negotiation (ALPN) [ALPN] tokens and multiple | ||||
| compatible versions, the server needs to ensure that the ALPN token | ||||
| that it selects can run over the QUIC version that it selects. | ||||
| 2.3. Compatible Version Negotiation | 2.3. Compatible Version Negotiation | |||
| When the server can parse the client's first flight using the | When the server can parse the client's first flight using the | |||
| original version, it can extract the client's Version Information | client's chosen version, it can extract the client's Version | |||
| structure (see Section 3). This contains the list of versions that | Information structure (see Section 3). This contains the list of | |||
| the client knows its first flight is compatible with. | versions that the client knows its first flight is compatible with. | |||
| If the server supports one of the client's compatible versions, and | In order to perform compatible version negotiation, the server MUST | |||
| the server also knows that the original version is compatible with | select one of these versions that (1) it supports and (2) it knows | |||
| this version, and the client's first flight is compatible with this | the client's chosen version to be compatible with. Once the server | |||
| version, then the server converts the client's first flight to that | has selected a version, termed the "negotiated version", it then | |||
| version and replies to the client as if it had received the converted | attempts to convert the client's first flight into that version, and | |||
| first flight. Note that this conversion process cannot fail by | replies to the client as if it had received the converted first | |||
| definition of the first flight being compatible. The version used by | flight. | |||
| the server in its reply is refered to as the "negotiated version". | ||||
| The server MUST NOT reply with a version that is not present in the | ||||
| client's compatible versions, unless it is the original version. | ||||
| Clients will be made aware of compatible version negotiation by | If those formats are identical, as in cases where the negotiated | |||
| seeing a change in the QUIC long header Version field. It is | version is the same as the client's chosen version, then this will be | |||
| possible for the server to initially send packets with the original | the identity transform. If the first flight is correctly formatted, | |||
| version before switching to the negotiated version (for example, this | then this conversion process cannot fail by definition of the first | |||
| can happen when the client's Version Information structured spans | flight being compatible; if the server is unable to convert the first | |||
| multiple packets; in that case the server might acknowledge the first | flight, it MUST abort the handshake. | |||
| packet in the original version and later switch to a different | ||||
| Clients can determine the server's negotiated version by examining | ||||
| the QUIC long header Version field. It is possible for the server to | ||||
| initially send packets with the client's chosen version before | ||||
| switching to the negotiated version (for example, this can happen | ||||
| when the client's Version Information structure spans multiple | ||||
| packets; in that case the server might acknowledge the first packet | ||||
| in the client's chosen version and later switch to a different | ||||
| negotiated version). | negotiated version). | |||
| Note that, after the first flight is converted to the negotiated | Note that, after the first flight is converted to the negotiated | |||
| version, the handshake completes in the negotiated version. The | version, the handshake completes in the negotiated version. The | |||
| entire handshake (including the converted first flight) needs to | entire handshake (including the converted first flight) needs to | |||
| conform to the rules of the negotiated version. For instance, if the | conform to the rules of the negotiated version. For instance, if the | |||
| negotiated version requires that the 5-tuple remain stable for the | negotiated version requires that the 5-tuple remain stable for the | |||
| entire handshake (as QUIC version 1 does), then this applies to the | entire handshake (as QUIC version 1 does), then this applies to the | |||
| entire handshake, including the first flight. | entire handshake, including the first flight. | |||
| Note also that the client can disable compatible version negotiation | Note also that the client can disable compatible version negotiation | |||
| by only including the Chosen Version in the Other Versions field of | by only including the Chosen Version in the Other Versions field of | |||
| the Version Information Transport Parameter. | the Version Information transport parameter. | |||
| If the server does not find a compatible version, it will use the | If the server does not find a compatible version (including the | |||
| original version if it supports it, and if it doesn't then the server | client's chosen version), it will perform incompatible version | |||
| will perform incompatible version negotiation instead, see | negotiation instead, see Section 2.1. | |||
| Section 2.1. | ||||
| Note that it is possible to have incompatible version negotation | ||||
| followed by compatible version negotiation. For instance, if version | ||||
| A is compatible with B and C is compatible with D, the following | ||||
| scenario could occur: | ||||
| Client Server | ||||
| Chosen = A, Other Versions = (A, B) -----------------> | ||||
| <------------------------ Version Negotiation = (D, C) | ||||
| Chosen = C, Other Versions = (C, D) -----------------> | ||||
| <-------------------------------------- Negotiated = D | ||||
| Figure 1: Combined Negotiation Example | ||||
| In this example, the client selected C from the server's Version | ||||
| Negotiation packet, but the server preferred D and then selected it | ||||
| from the client's offer. | ||||
| 2.4. Connections and Version Negotiation | 2.4. Connections and Version Negotiation | |||
| QUIC connections are shared state between a client and a server | QUIC connections are shared state between a client and a server | |||
| [INV]. The compatible version negotiation mechanism defined in this | [INV]. The compatible version negotiation mechanism defined in this | |||
| document (see Section 2.3) is performed as part of a single QUIC | document (see Section 2.3) is performed as part of a single QUIC | |||
| connection; that is, the packets with the original version are part | connection; that is, the packets with the client's chosen version are | |||
| of the same connection as the packets with the negotiated version. | part of the same connection as the packets with the negotiated | |||
| version. | ||||
| In comparison, the incompatible version negotiation mechanism, which | In comparison, the incompatible version negotiation mechanism, which | |||
| leverages QUIC Version Negotiation packets (see Section 2.1) | leverages QUIC Version Negotiation packets (see Section 2.1) | |||
| conceptually operates across two QUIC connections: the connection | conceptually operates across two QUIC connections: the connection | |||
| attempt prior to receiving the Version Negotiation packet is distinct | attempt prior to receiving the Version Negotiation packet is distinct | |||
| from the connection with the incompatible version that follows. | from the connection with the incompatible version that follows. | |||
| Note that this separation across two connections is conceptual: it | ||||
| applies to normative requirements on QUIC connections, but does not | ||||
| require implementations to internally use two distinct connection | ||||
| objects. | ||||
| 2.5. Client Choice of Original Version | 2.5. Client Choice of Original Version | |||
| The client's first connection attempt SHOULD be made using the | When the client picks its original version, it will try to avoid | |||
| version that the server is most likely to support. The client | incompatible version negotiation to save a round trip. Therefore, | |||
| selects the version most likely to be supported from the versions | the client SHOULD pick an original version to maximize the combined | |||
| that are compatible with the client's most preferred version. | probability that both: | |||
| Without additional information this could mean selecting the oldest | ||||
| * The server knows how to parse first flights from the original | ||||
| version. | ||||
| * The original version is compatible with the client's preferred | ||||
| version. | ||||
| Without additional information, this could mean selecting the oldest | ||||
| version that the client supports. | version that the client supports. | |||
| 3. Version Information | 3. Version Information | |||
| During the handshake, endpoints will exchange Version Information, | During the handshake, endpoints will exchange Version Information, | |||
| which consists of a chosen version and a list of other versions. Any | which consists of a chosen version and a list of other versions. Any | |||
| version of QUIC that supports this mechanism MUST provide a mechanism | version of QUIC that supports this mechanism MUST provide a mechanism | |||
| to exchange Version Information in both directions during the | to exchange Version Information in both directions during the | |||
| handshake, such that this data is authenticated. | handshake, such that this data is authenticated. | |||
| In QUIC version 1, the Version Information is transmitted using a new | In QUIC version 1, the Version Information is transmitted using a new | |||
| transport parameter, version_information. The contents of Version | transport parameter, version_information. The contents of Version | |||
| Information are shown below (using the notation from the "Notational | Information are shown below (using the notation from the "Notational | |||
| Conventions" section of [QUIC]): | Conventions" section of [QUIC]): | |||
| Version Information { | Version Information { | |||
| Chosen Version (32), | Chosen Version (32), | |||
| Other Versions (32) ..., | Other Versions (32) ..., | |||
| } | } | |||
| Figure 1: Version Information Format | Figure 2: Version Information Format | |||
| The content of each field is described below: | The content of each field is described below: | |||
| Chosen Version: The version that the sender has chosen to use for | Chosen Version: The version that the sender has chosen to use for | |||
| this connection. In most cases, this field will be equal to the | this connection. In most cases, this field will be equal to the | |||
| value of the Version field in the long header that carries this | value of the Version field in the long header that carries this | |||
| data. | data. | |||
| The contents of the Other Versions field depends on whether it is | The contents of the Other Versions field depends on whether it is | |||
| sent by the client or by the server. | sent by the client or by the server. | |||
| skipping to change at page 8, line 44 ¶ | skipping to change at page 9, line 43 ¶ | |||
| if it is too short or if its length is not divisible by four), then | if it is too short or if its length is not divisible by four), then | |||
| the endpoint MUST close the connection; if the connection was using | the endpoint MUST close the connection; if the connection was using | |||
| QUIC version 1, that connection closure MUST use a transport error of | QUIC version 1, that connection closure MUST use a transport error of | |||
| type TRANSPORT_PARAMETER_ERROR. If an endpoint receives a Chosen | type TRANSPORT_PARAMETER_ERROR. If an endpoint receives a Chosen | |||
| Version equal to zero, or any Other Version equal to zero, it MUST | Version equal to zero, or any Other Version equal to zero, it MUST | |||
| treat it as a parsing failure. | treat it as a parsing failure. | |||
| Every QUIC version that supports version negotiation MUST define a | Every QUIC version that supports version negotiation MUST define a | |||
| method for closing the connection with a version negotiation error. | method for closing the connection with a version negotiation error. | |||
| For QUIC version 1, version negotiation errors are signaled using a | For QUIC version 1, version negotiation errors are signaled using a | |||
| transport error of type VERSION_NEGOTIATION_ERROR; see Section 8.2. | transport error of type VERSION_NEGOTIATION_ERROR; see Section 10.2. | |||
| If the Version Information was missing, the endpoints MAY complete | If the Version Information was missing, the endpoints MAY complete | |||
| the handshake. However, if a client has reacted to a Version | the handshake. However, if a client has reacted to a Version | |||
| Negotiation packet and the Version Information was missing, the | Negotiation packet and the Version Information was missing, the | |||
| client MUST close the connection with a version negotiation error. | client MUST close the connection with a version negotiation error. | |||
| If the client received and acted on a Version Negotiation packet, the | If the client received and acted on a Version Negotiation packet, the | |||
| client MUST validate the server's Other Versions field. The Other | client MUST validate the server's Other Versions field. The Other | |||
| Versions field is validated by confirming that the client would have | Versions field is validated by confirming that the client would have | |||
| attempted the same version with knowledge of the versions the server | attempted the same version with knowledge of the versions the server | |||
| skipping to change at page 11, line 23 ¶ | skipping to change at page 12, line 18 ¶ | |||
| * Finally, the third step is to progressively remove support for the | * Finally, the third step is to progressively remove support for the | |||
| version from all server instances. That step updates the | version from all server instances. That step updates the | |||
| Acceptable Versions. | Acceptable Versions. | |||
| Note that this opens connections to version downgrades (but only for | Note that this opens connections to version downgrades (but only for | |||
| partially-deployed versions) during the update window, since those | partially-deployed versions) during the update window, since those | |||
| could be due to clients communicating with both updated and non- | could be due to clients communicating with both updated and non- | |||
| updated server instances. | updated server instances. | |||
| 6. Considerations for Future Versions | 6. Application Layer Protocol Considerations | |||
| When a client creates a QUIC connection, its goal is to use an | ||||
| application layer protocol. Therefore, when considering which | ||||
| versions are compatible, clients will only consider versions that | ||||
| support one of the intended application layer protocols. If the | ||||
| client's first flight advertises multiple Application Layer Protocol | ||||
| Negotiation (ALPN) [ALPN] tokens and multiple compatible versions, it | ||||
| is possible for some application layer protocols to not be able to | ||||
| run over some of the offered compatible versions. It is the server's | ||||
| responsibility to only select an ALPN token that can run over the | ||||
| compatible QUIC version that it selects. | ||||
| A given ALPN token MUST NOT be used with a new QUIC version different | ||||
| from the version for which the ALPN token was originally defined, | ||||
| unless all the following requirements are met: | ||||
| * The new QUIC version supports the transport features required by | ||||
| the application protocol. | ||||
| * The new QUIC version supports ALPN. | ||||
| * The version of QUIC for which the ALPN token was originally | ||||
| defined is compatible with the new QUIC version. | ||||
| When incompatible version negotiation is in use, the second | ||||
| connection which is created in response to the received version | ||||
| negotiation packet MUST restart its application layer protocol | ||||
| negotiation process without taking into account the original version. | ||||
| 7. Considerations for Future Versions | ||||
| In order to facilitate the deployment of future versions of QUIC, | In order to facilitate the deployment of future versions of QUIC, | |||
| designers of future versions SHOULD attempt to design their new | designers of future versions SHOULD attempt to design their new | |||
| version such that commonly deployed versions are compatible with it. | version such that commonly deployed versions are compatible with it. | |||
| QUIC version 1 defines multiple features which are not documented in | QUIC version 1 defines multiple features which are not documented in | |||
| the QUIC invariants. Since at the time of writing QUIC version 1 is | the QUIC invariants. Since at the time of writing QUIC version 1 is | |||
| widely deployed, this section discusses considerations for future | widely deployed, this section discusses considerations for future | |||
| versions to help with compatibility with QUIC version 1. | versions to help with compatibility with QUIC version 1. | |||
| 6.1. Interaction with Retry | 7.1. Interaction with Retry | |||
| QUIC version 1 features Retry packets, which the server can send to | QUIC version 1 features Retry packets, which the server can send to | |||
| validate the client's IP address before parsing the client's first | validate the client's IP address before parsing the client's first | |||
| flight. A server that sends a Retry packet can do so before parsing | flight. A server that sends a Retry packet can do so before parsing | |||
| the client's first flight. A server that sends a Retry packet | the client's first flight. A server that sends a Retry packet | |||
| therefore might not have processed the client's Version Information | therefore might not have processed the client's Version Information | |||
| before doing so. | before doing so. | |||
| If a future document wishes to define compatibility between two | If a future document wishes to define compatibility between two | |||
| versions that support retry, that document MUST specify how version | versions that support retry, that document MUST specify how version | |||
| negotiation (both compatible and incompatible) interacts with retry | negotiation (both compatible and incompatible) interacts with retry | |||
| during a handshake that requires both. For example, that could be | during a handshake that requires both. For example, that could be | |||
| accomplished by having the server send a Retry packet in the original | accomplished by having the server send a Retry packet in the original | |||
| version first and therefore validating the client's IP address before | version first thereby validating the client's IP address before | |||
| attempting compatible version negotiation. If both versions support | attempting compatible version negotiation. If both versions support | |||
| authenticating Retry packets, the compatibility defition needs to | authenticating Retry packets, the compatibility defition needs to | |||
| define how to authenticate the Retry in the negotiated version | define how to authenticate the Retry in the negotiated version | |||
| handshake even though the Retry itself was sent using the original | handshake even though the Retry itself was sent using the client's | |||
| version. | chosen version. | |||
| 6.2. Interaction with TLS resumption | 7.2. Interaction with TLS resumption | |||
| QUIC version 1 uses TLS 1.3, which supports session resumption by | QUIC version 1 uses TLS 1.3, which supports session resumption by | |||
| sending session tickets in one connection that can be used in a later | sending session tickets in one connection that can be used in a later | |||
| connection; see Section 2.2 of [TLS]. New versions that also use TLS | connection; see Section 2.2 of [TLS]. New versions that also use TLS | |||
| 1.3 SHOULD mandate that their session tickets are rightly scoped to | 1.3 SHOULD mandate that their session tickets are tightly scoped to | |||
| one version of QUIC; i.e., require that clients not use them across | one version of QUIC; i.e., require that clients not use them across | |||
| version and that servers validate this client requirement. | multiple version and that servers validate this client requirement. | |||
| 6.3. Interaction with 0-RTT | 7.3. Interaction with 0-RTT | |||
| QUIC version 1 allows sending data from the client to the server | QUIC version 1 allows sending data from the client to the server | |||
| during the handshake, by using 0-RTT packets. If a future document | during the handshake, by using 0-RTT packets. If a future document | |||
| wishes to define compatibility between two versions that support | wishes to define compatibility between two versions that support | |||
| 0-RTT, that document MUST address the scenario where there are 0-RTT | 0-RTT, that document MUST address the scenario where there are 0-RTT | |||
| packets in the client's first flight. For example, this could be | packets in the client's first flight. For example, this could be | |||
| accomplished by defining which transformations are applied to 0-RTT | accomplished by defining which transformations are applied to 0-RTT | |||
| packets. Alternatively, that document could specify that compatible | packets. That document could specify that compatible version | |||
| version negotiation causes 0-RTT data to be rejected by the server. | negotiation causes 0-RTT data to be rejected by the server. | |||
| 7. Security Considerations | 8. Special Handling for QUIC Version 1 | |||
| Because QUIC version 1 was the only IETF Standards Track version of | ||||
| QUIC published before this document, it is handled specially as | ||||
| follows: if a client is starting a QUIC version 1 connection in | ||||
| response to a received Version Negotiation packet, and the | ||||
| version_information transport parameter is missing from the server's | ||||
| transport parameters, then the client SHALL proceed as if the | ||||
| server's transport parameters contained a version_information | ||||
| transport parameter with a Chosen Version set to 0x00000001 and an | ||||
| Other Version list containing exactly one version set to 0x00000001. | ||||
| This allows version negotiation to work with servers that only | ||||
| support QUIC version 1. Note that implementations which wish to use | ||||
| version negotiation to negotiate versions other than QUIC version 1 | ||||
| will need to implement the version negotiation mechanism defined in | ||||
| this document. | ||||
| 9. Security Considerations | ||||
| The security of this version negotiation mechanism relies on the | The security of this version negotiation mechanism relies on the | |||
| authenticity of the Version Information exchanged during the | authenticity of the Version Information exchanged during the | |||
| handshake. In QUIC version 1, transport parameters are authenticated | handshake. In QUIC version 1, transport parameters are authenticated | |||
| ensuring the security of this mechanism. Negotiation between | ensuring the security of this mechanism. Negotiation between | |||
| compatible versions will have the security of the weakest common | compatible versions will have the security of the weakest common | |||
| version. | version. | |||
| The requirement that versions not be assumed compatible mitigates the | The requirement that versions not be assumed compatible mitigates the | |||
| possibility of cross-protocol attacks, but more analysis is still | possibility of cross-protocol attacks, but more analysis is still | |||
| needed here. | needed here. | |||
| 8. IANA Considerations | 10. IANA Considerations | |||
| 8.1. QUIC Transport Parameter | 10.1. QUIC Transport Parameter | |||
| This document registers a new value in the QUIC Transport Parameter | This document registers a new value in the "QUIC Transport | |||
| Registry maintained at https://www.iana.org/assignments/quic/ | Parameters" registry maintained at <https://www.iana.org/assignments/ | |||
| quic.xhtml#quic-transport. | quic>. | |||
| Value: 0xFF73DB | Value: 0xFF73DB | |||
| Parameter Name: version_information | Parameter Name: version_information | |||
| Status: provisional | Status: provisional | |||
| Specification: This document | Specification: This document | |||
| When this document is approved, it will request permanent allocation | When this document is approved, it will request permanent allocation | |||
| of a codepoint in the 0-63 range to replace the provisional codepoint | of a codepoint in the 0-63 range to replace the provisional codepoint | |||
| described above. | described above. | |||
| 8.2. QUIC Transport Error Code | 10.2. QUIC Transport Error Code | |||
| This document registers a new value in the QUIC Transport Error Codes | This document registers a new value in the "QUIC Transport Error | |||
| Registry maintained at https://www.iana.org/assignments/quic/ | Codes" registry maintained at <https://www.iana.org/assignments/ | |||
| quic.xhtml#quic-transport-error-codes. | quic>. | |||
| Value: 0x53F8 | Value: 0x53F8 | |||
| Code: VERSION_NEGOTIATION_ERROR | Code: VERSION_NEGOTIATION_ERROR | |||
| Description: Error negotiating version | Description: Error negotiating version | |||
| Status: provisional | Status: provisional | |||
| Specification: This document | Specification: This document | |||
| When this document is approved, it will request permanent allocation | When this document is approved, it will request permanent allocation | |||
| of a codepoint in the 0-63 range to replace the provisional codepoint | of a codepoint in the 0-63 range to replace the provisional codepoint | |||
| described above. | described above. | |||
| 9. Normative References | 11. Normative References | |||
| [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, | [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, | |||
| "Transport Layer Security (TLS) Application-Layer Protocol | "Transport Layer Security (TLS) Application-Layer Protocol | |||
| Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, | Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, | |||
| July 2014, <https://www.rfc-editor.org/rfc/rfc7301>. | July 2014, <https://www.rfc-editor.org/rfc/rfc7301>. | |||
| [INV] Thomson, M., "Version-Independent Properties of QUIC", | [INV] Thomson, M., "Version-Independent Properties of QUIC", | |||
| RFC 8999, DOI 10.17487/RFC8999, May 2021, | RFC 8999, DOI 10.17487/RFC8999, May 2021, | |||
| <https://www.rfc-editor.org/rfc/rfc8999>. | <https://www.rfc-editor.org/rfc/rfc8999>. | |||
| skipping to change at page 14, line 38 ¶ | skipping to change at page 16, line 16 ¶ | |||
| The authors would like to thank Nick Banks, Mike Bishop, Ryan | The authors would like to thank Nick Banks, Mike Bishop, Ryan | |||
| Hamilton, Roberto Peon, Anthony Rossi, and Martin Thomson for their | Hamilton, Roberto Peon, Anthony Rossi, and Martin Thomson for their | |||
| input and contributions. | input and contributions. | |||
| Authors' Addresses | Authors' Addresses | |||
| David Schinazi | David Schinazi | |||
| Google LLC | Google LLC | |||
| 1600 Amphitheatre Parkway | 1600 Amphitheatre Parkway | |||
| Mountain View, California 94043, | Mountain View, CA 94043 | |||
| United States of America | United States of America | |||
| Email: dschinazi.ietf@gmail.com | Email: dschinazi.ietf@gmail.com | |||
| Eric Rescorla | Eric Rescorla | |||
| Mozilla | Mozilla | |||
| Email: ekr@rtfm.com | Email: ekr@rtfm.com | |||
| End of changes. 49 change blocks. | ||||
| 117 lines changed or deleted | 205 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||