Re: QUIC Version Negotiation Extension

["Martin Thomson" <[e-mail]>]

Hi David,

I think that this is broadly the right mechanism.  It would be good to validate it more thoroughly.  

The model and framing could use a little work.

I struggled a little with the framing here because the split between incompatible and compatible versions is very important, but also unclear.  The definition of "compatible" is left for Section 7, but it seems like it should be right up front.

The framing I would choose puts the model up front.  The model that you have have two layers that are applied progressively:

1. incompatible version negotiation, where the server sends a Version Negotiation packet in response to a version it does not understand.

2. compatible version negotiation, where the server can generate interpret a version X Initial packet and continue with version Y.

Regarding the model, the definition of "compatible" needs work.

I observe that you only need a mapping from "Initial"-equivalent packets in X to the same in Y - and maybe the ability to generate a Retry in version X (more below) - in order for this to work.  That's where there is a clear functional mapping from a version X packets that initiate the connection to something that fills the same purpose in version Y.  

But the definition you have for "compatible" implies that the mapping is bijective, which I don't think is necessary.  As the draft says, version Y might define (and allow) new frame types in its Initial-equivalent packet(s), but as long as those are either optional or can be synthesized from X, that's OK.  It isn't necessary that every Y have a functional representation in X.  We might not want to define a way to negotiate an older version from a newer one (or at least not for every case).

The ability to generate a Retry stretches this definition a little.  Can you explain why you can't generate a version Y Retry?  I have an inkling, but it's not fully formed.  It complicates the model more than I'd like to have it this way around.

On Tue, Nov 5, 2019, at 07:29, David Schinazi wrote:
> Hi everyone,
> 
> From the recent discussion on multiple PRs, it appears that there might 
> be a need for downgrade-safe QUIC version negotiation, earlier than we 
> expected.
> 
> EKR and I updated our extension to hopefully suit these needs:
> https://tools.ietf.org/html/draft-schinazi-quic-version-negotiation-02
> 
> Comments welcome here or on the GitHub (link in draft).
> 
> Thanks,
> David