Subject: [quicwg/base-drafts] Proposal to make Version Negotiation more like Retry to punt VN to QUICv2 (#2313)

From: David Schinazi <[email-masked]>
Date: Mon, 07 Jan 2019 13:36:38 -0800

We've been talking about Version Negotiation (VN) for a while, as the current design isn't perfect yet. In particular, it is vulnerable to subtle deadlocks and downgrades and requires a full RTT.

I have a proposal for the WG that would effectively punt this issue, allowing us to focus on other QUICv1 deliverables until we actually need VN and have deployment experience.

I'm working with the following assumptions:
- when we'll have clients and servers supporting both QUICv1 and QUICv2, we will not be willing to pay a full RTT to negotiate which version to use
- when we standardize QUICv1, we will not know what QUICv2 will look like, so cannot design compatible VN in v1 and be sure it will work with v2
- compatible VN can rely on transport parameters, so it will be possible to standardize it later as an extension to QUICv1

The proposal is to make VN packets a fatal error that effectively kills the first connection, and have them transmit a new connection ID to allow clients to create a new connection that will hit the same server (or not, based on server preference). In terms of wire format, this makes VN more like Retry by making the server send a new connection ID to the client.

(Note that this was mostly inspired by EKR's proposals.)
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2313

-- Commit Summary --

  * Proposal to make Version Negotiation more like Retry to punt VN to QUICv2

-- File Changes --

    M draft-ietf-quic-transport.md (231)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2313.patch
https://github.com/quicwg/base-drafts/pull/2313.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2313

---

From: David Schinazi <[email-masked]>
Date: Mon, 07 Jan 2019 21:50:53 +0000 (UTC)

@DavidSchinazi pushed 1 commit.

0551486736d4883882372488f30bf3e295542990  remove more text

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2313/files/e15da31e052ab9d8a48fb49feb20c0df61a97d61..0551486736d4883882372488f30bf3e295542990

---

From: ianswett <[email-masked]>
Date: Mon, 07 Jan 2019 19:51:43 -0800

ianswett commented on this pull request.

-The server MUST include the value from the Source Connection ID field of the
-packet it receives in the Destination Connection ID field.  The value for Source
-Connection ID MUST be copied from the Destination Connection ID of the received
-packet, which is initially randomly selected by a client.  Echoing both
-connection IDs gives clients some assurance that the server received the packet
-and that the Version Negotiation packet was not generated by an off-path
-attacker.
+Reserved Bits (R):

There is a lot of added text here.  Is that because the long header packets are currently not correctly documented?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2313#pullrequestreview-190084364

---

From: David Schinazi <[email-masked]>
Date: Tue, 08 Jan 2019 09:33:02 -0800

DavidSchinazi commented on this pull request.

The added text here is to add new fields to VN packets. This PR adds ODCIL and Original Destination Connection ID to allow the server to send a new source connection ID (similar to how Retry packets work today). The PR also adds a Number of Supported Versions field to allow future extensibility.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2313#discussion_r246086174

---

From: Mike Bishop <[email-masked]>
Date: Tue, 08 Jan 2019 16:18:47 -0800

My issue with this general approach is that VN is currently part of the invariants.  (Or otherwise framed, VN is the only packet defined by QUIC version zero.)  If we want to support versions which aren't mutually intelligible, it basically has to be version-independent.  If you're only writing in the Transport document, the PR probably doesn't have the necessary contents yet.

Further, I think we as a WG need to return to our basic principles in VN and agree on those first -- we have too many designs being tossed around fueled by different assumptions.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2313#issuecomment-452511356

---

From: David Schinazi <[email-masked]>
Date: Tue, 08 Jan 2019 17:23:40 -0800

@MikeBishop I agree. I wrote this up so people could reason about the proposal. Maybe it would be worth spending some time on VN in Tokyo?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2313#issuecomment-452524224

---

From: David Schinazi <[email-masked]>
Date: Tue, 15 Jan 2019 12:13:53 -0800

3a0b08c258651e6f9924108baa9b494dfe3774c1  Revert changes to the invariants

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2313/files/738fec2ec2fad1d8f26a5307ab426bb4910643eb..3a0b08c258651e6f9924108baa9b494dfe3774c1

---

From: David Schinazi <[email-masked]>
Date: Tue, 15 Jan 2019 12:15:09 -0800

I've now reverted the part of this proposal that changed the invariants. It now simply removes VN from v1.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2313#issuecomment-454535056