Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Compatible version upgrade #1901

Closed
wants to merge 30 commits into from
Closed

Compatible version upgrade #1901

Changes from 1 commit
Commits
Show all changes
30 commits
Select commit Hold shift + click to select a range
4dc5e0d
Compatible version upgrade
martinthomson Oct 24, 2018
7483395
There are only two things, which means no list
martinthomson Oct 24, 2018
f997b10
Marten's editorial suggestions
martinthomson Oct 24, 2018
f12becd
Thwart downgrade attacks between incompatible versions
martinthomson Oct 25, 2018
4235f75
unplural
nibanks Oct 25, 2018
0e0df73
article
nibanks Oct 25, 2018
48ae25f
joiner
nibanks Oct 25, 2018
87bcb71
Nick's suggestions
martinthomson Oct 25, 2018
847445b
No common versions means fail
martinthomson Oct 25, 2018
7533873
Move some text up to get the flow right
martinthomson Oct 25, 2018
2b02ccd
Split into supported and unsupported
martinthomson Oct 26, 2018
34b19da
The packet definitely always changes
martinthomson Oct 26, 2018
a2c5c6a
Moar words about what it means for a version to be supported by a client
martinthomson Oct 26, 2018
0de8a0c
Cleanup, don't create conflicting requirements
martinthomson Oct 26, 2018
8ffb306
discard, not ignore
igorlord Oct 29, 2018
67a815e
Fix the RETIRE_CONNECTION_ID frame type again
martinthomson Oct 24, 2018
4edf5b3
Don't recommend stateless reset
martinthomson Oct 25, 2018
4417e03
Add missing sections to document structure
martinthomson Oct 25, 2018
8f69ad1
Forward reference ECN verification
martinthomson Oct 25, 2018
7c4b04d
Take suggestion
martinthomson Oct 25, 2018
270243e
Use octets rather than bytes throughout
martinthomson Oct 25, 2018
0143d41
Use octets for units; size for packet sizes
martinthomson Oct 25, 2018
bbf55a5
Use bytes instead of octets throughout
martinthomson Oct 25, 2018
a4f4c9f
Reflow
martinthomson Oct 25, 2018
9d50417
Update draft-ietf-quic-recovery.md
ianswett Oct 28, 2018
3f330f6
clarify
ianswett Oct 28, 2018
f0b5080
unhypenate - the name of my new startup
martinthomson Oct 28, 2018
4578287
rewrap
martinthomson Oct 28, 2018
aa3ddc1
Reflow
martinthomson Oct 29, 2018
d59f429
Merge branch 'master' into vn-mkII
martinthomson Oct 29, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
23 changes: 12 additions & 11 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -1221,24 +1221,25 @@ transport parameters include the version the client first attempts to use, plus
a list of QUIC versions the client supports.

A server that understands the version selected by the client can extract the
list of QUIC versions and select an alternative version from the list of
versions provided by the client. A server MAY choose a version from that list
if that version is compatible with the version selected by the client. A server
MAY choose a version that the client believes to be unsupported. The server
sends its first packet as though it was continuing with the selected version.
list of QUIC versions in the `supported_versions` field included in the client
transport parameters. A server MAY choose a version from that list if that
version is compatible with the version selected by the client. The server sends
its first packet as though it was continuing with the selected version.

A QUIC version is compatible with another version if the cryptographic handshake
message sent in the first packet can be used in both versions. A compatible
message carried in the first packet can be used in both versions. A compatible
version is also able to identify and acknowledge the first packet sent by the
client in some fashion. Other QUIC versions might have different constraints in
determining what is compatible. In order to facilitate this process, new QUIC
versions could define a process for transforming the first packet from other
compatible versions into the equivalent packet in the new version.
client in some fashion.

Other QUIC versions might have different constraints in determining what is
compatible. In order to facilitate this process, new QUIC versions could define
a process for transforming the first packet from other compatible versions into
the equivalent packet in the new version.

Upgrading in this manner allows a server to upgrade without incurring the round
trip imposed by sending a Version Negotiation packet. It also allows clients to
send their first packet using a widely deployed version, without the risk of
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There’s no incentive to use a widely deployed version any more. A client can use the highest (compatible) version, and the server would just downgrade it to the highest version it supports.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The server might not know that there is a newer compatible version - compatible is both a spec thing and an implementation thing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the incentive remains the same - the client offers what it believes to be most widely deployed. This design only allows for a seamless upgrade to a compatible version. If the client were to advertise the new, less-widely-deployed version, it risks getting a Version Negotiation packet.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A client can use the highest (compatible) version, and the server would just downgrade it to the highest version it supports.

It needs to be the lowest version for maximum flexibility.

Consider the case where we would be using 0x81 as the first octet for the Initial packet in QUIC v2, and that we have a client that wants to connect to a server using either v1 or v2. The way to provide room for such possibility is to let the client send a v1 Initial packet with an indication that the server can respond using a v2 Initial packet.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking of versions as being ordered is helpful, but might be constraining. The point is that the client will use the most widely deployed to start with and accept that the server is able to choose a compatible version. The client hopes that the server will choose a version that it prefers more, but leaves that to the server to decide.

In the case of monotonically increasing versions where A >> B >> C, this might seem obvious, but it's still possible that the client will advertise B and get an apparent downgrade to C. That's a property of the design that I don't think we'll see that often, but it's nonetheless theoretically possible.

But as @kazuho says, the expected case is a client advertising vN, then being opportunistically upgraded to vN+1. Like today, you can rely on TLS 1.0 being available widely, but you might prefer TLS 1.3.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The TLS comparison is somewhat inapt, since in TLS you actually do offer your highest (most preferred) version and let the server select a compatible, less-preferred version if it doesn't support that one. QUIC can't do that because the contents of the Initial aren't invariant.

having to use that version with servers that supports a more-preferred version.
having to use that version with a server that supports a more-preferred version.

A server MUST NOT send a Version Negotiation packet if it prefers a version that
is not compatible with the version the client initially chose; a server has to
Expand Down