draft-ietf-quic-version-negotiation-00.txt   draft-ietf-quic-version-negotiation-01.txt 
QUIC Working Group D. Schinazi QUIC Working Group D. Schinazi
Internet-Draft Google LLC Internet-Draft Google LLC
Intended status: Informational E. Rescorla Intended status: Informational E. Rescorla
Expires: 29 August 2020 Mozilla Expires: 4 March 2021 Mozilla
26 February 2020 31 August 2020
Compatible Version Negotiation for QUIC Compatible Version Negotiation for QUIC
draft-ietf-quic-version-negotiation-00 draft-ietf-quic-version-negotiation-01
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 offered is unacceptable. This document describes
a version negotiation mechanism that allows a client and server to a 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 original and
negotiated version share a compatible Initial format, the negotiation negotiated version share a compatible Initial format, the negotiation
can take place without incurring an extra round trip. can take place without incurring an extra round trip.
Discussion of this work is encouraged to happen on the QUIC IETF Discussion of this work is encouraged to happen on the QUIC IETF
mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub
repository which contains the draft: https://github.com/quicwg/ repository which contains the draft: https://github.com/quicwg/
version-negotiation/ (https://github.com/quicwg/version- version-negotiation/ (https://github.com/quicwg/version-
negotiation/). negotiation/).
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
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 4 March 2021.
This Internet-Draft will expire on 29 August 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 3, line 50 skipping to change at page 4, line 10
If the server sends a Retry, it MUST use the same version that the If the server sends a Retry, it MUST use the same version that the
client provided in its Initial. Version negotiation takes place client provided in its Initial. Version negotiation takes place
after the retry cycle is over. after the retry cycle is over.
In order for negotiation to complete successfully, the client's In order for negotiation to complete successfully, the client's
Initial packet (and initial CRYPTO frames) MUST be interpretable by Initial packet (and initial CRYPTO frames) MUST be interpretable by
the server. This implies that servers must retain the ability to the server. This implies that servers must retain the ability to
process the Initial packet from older versions as long as they are process the Initial packet from older versions as long as they are
reasonably popular. This is not generally an issue in practice as reasonably popular. This is not generally an issue in practice as
long as the the overall structure of the protocol remains similar. long as the overall structure of the protocol remains similar.
4. Version Negotiation Transport Parameter 4. Version Negotiation Transport Parameter
This document registers a new transport parameter, This document registers a new transport parameter,
"version_negotiation". The contents of this transport parameter "version_negotiation". The contents of this transport parameter
depend on whether the client or server is sending it, and are shown depend on whether the client or server is sending it, and are shown
below: below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 6, line 19 skipping to change at page 6, line 27
Version list. Those versions are reserved to exercise version Version list. Those versions are reserved to exercise version
negotiation (see the Versions section of [QUIC]), and MUST be ignored negotiation (see the Versions section of [QUIC]), and MUST be ignored
when parsing these fields. On the other hand, the Received when parsing these fields. On the other hand, the Received
Negotiation Version list MUST be identical to the received Version Negotiation Version list MUST be identical to the received Version
Negotiation packet, so clients MUST NOT add or remove reserved Negotiation packet, so clients MUST NOT add or remove reserved
version from that list. version from that list.
5. Version Downgrade Prevention 5. Version Downgrade Prevention
Clients MUST ignore any received Version Negotiation packets that Clients MUST ignore any received Version Negotiation packets that
contain the version that they initially attempted. contain the version that they initially attempted. Once a client has
reacted to a Version Negotiation packet, it MUST drop all subsequent
Version Negotiation packets.
Servers MUST validate that the client's "Currently Attempted Version" Servers MUST validate that the client's "Currently Attempted Version"
matches the version in the long header that carried the transport matches the version in the long header that carried the transport
parameter. Similarly, clients MUST validate that the server's parameter. Similarly, clients MUST validate that the server's
"Negotiated Version" matches the long header version. If an "Negotiated Version" matches the long header version. If an
endpoint's validation fails, it MUST close the connection with an endpoint's validation fails, it MUST close the connection with an
error of type VERSION_NEGOTIATION_ERROR. error of type VERSION_NEGOTIATION_ERROR.
When a server parses the client's "version_negotiation" transport When a server parses the client's "version_negotiation" transport
parameter, if the "Received Negotiation Version Count" is not zero, parameter, if the "Received Negotiation Version Count" is not zero,
skipping to change at page 8, line 17 skipping to change at page 8, line 21
If this document is approved, IANA shall assign the identifier 0x73DB If this document is approved, IANA shall assign the identifier 0x73DB
for the "version_negotiation" transport parameter from the QUIC for the "version_negotiation" transport parameter from the QUIC
Transport Parameter Registry and the identifier 0x53F8 for Transport Parameter Registry and the identifier 0x53F8 for
"VERSION_NEGOTIATION_ERROR" from the QUIC Transport Error Codes "VERSION_NEGOTIATION_ERROR" from the QUIC Transport Error Codes
registry. registry.
10. Normative References 10. Normative References
[QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft, and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-27, 21 February 2020, draft-ietf-quic-transport-29, 9 June 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic- <http://www.ietf.org/internet-drafts/draft-ietf-quic-
transport-27.txt>. transport-29.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
 End of changes. 8 change blocks. 
9 lines changed or deleted 17 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/