Re: QUIC ossification

[Christian Huitema <[e-mail]>]

How about an IANA registry of version numbers, tied to the extension process?

-- Christian Huitema 

> On Feb 13, 2019, at 7:17 AM, Ted Hardie <[e-mail]> wrote:
> 
>> On Wed, Feb 13, 2019 at 9:14 AM Mikkel Fahnøe Jørgensen <[e-mail]> wrote:
> 
>> There is the risk that middle boxes learn that versions mean nothing, and that they are all the same, akin to crying wolf.
>> 
> I tend to agree with this. Version numbers should shift when the interoperability among parties to the protocol shifts.  While you can artificially create that shift in closed system, teaching the ecosystem that the shifts are meaningless doesn't seem to advance the general goal.
> 
> Ted
> 
>  
>> If it also mutated transport parameters and other observables, it would start being a defence.
>> 
>> Alas, once 1.0 hits, things are back to normal.
>> So I doubt this exercise would be worthwhile.
>> 
>> But, I don’t have any strong opinion.
>> 
>>> On 13 February 2019 at 17.56.47, Ian Swett (ianswett=[e-mail]) wrote:
>>> 
>>> Previously David Benjamin suggested spinning a new version of QUIC in Chrome for every Chrome milestone with the only change being the version number and the Initial keys.  I'd be curious how the WG feels about that idea?
>>> 
>>>> On Wed, Feb 13, 2019 at 11:17 AM Martin Duke <[e-mail]> wrote:
>>>> I agree that a fast v2 would help here. However, it's hard to count on a fast IETF process, and even then the middlebox can be pretty dumb and still drop version > 2.
>>>> 
>>>> I agree that David's scheme, by having the Initial be a v1 packet, may get that one through. But then you have subsequent long headers with the new version, which may still end badly.
>>>> 
>>>> I don't see a good solution here, right now. Although it shouldn't be written in the spec, the working group should have some sort of contingency plan for how to proceed if the version field ossifies.
>>>> 
>>>>> On Tue, Feb 12, 2019 at 4:21 PM Roberto Peon <fenix@fb...com> wrote:
>>>>> I don’t have an opinion on how version is negotiated yet.
>>>>> I’m not convinced it is easy to get right. It may be more correct for me to say that I’m convinced it is reasonable difficult to get right because it is the most important of the various invariants.
>>>>> 
>>>>> I also suspect that you need more than one way to do it, e.g. in-band and out-of-band (which could be in-band in a V2 to allow for upgrade to something else). Then does a client cache the version? For how long/where? Per IP? Hostname? (blah blah.. etc. etc.)
>>>>> 
>>>>> I can say that the ALPN and NPN approaches each had their positives and negatives, and in the end, having something like either is probably good enough.
>>>>> 
>>>>> Rather than an opinion on how it should be done, I have an opinion that we need to add this soon, as a V2.
>>>>> 
>>>>> -=R
>>>>> 
>>>>>  
>>>>> 
>>>>> From: David Schinazi <[e-mail]>
>>>>> Date: Tuesday, February 12, 2019 at 4:13 PM
>>>>> To: Roberto Peon <[e-mail]>
>>>>> Cc: Martin Thomson <[e-mail]>, "[e-mail]" <[e-mail]>
>>>>> Subject: Re: QUIC ossification
>>>>> 
>>>>>  
>>>>> 
>>>>> I think we may be able to limit ossification of version numbers by adding some GREASE to the (upcoming) in-band compatible version upgrade extension (what used to be EKR's PR). The idea of that extension is that the client sends a QUICv1 initial containing a transport parameter indicating it supports this extension and what versions of QUIC it supports. The server can then send its replies with a new QUIC version number. Back to GREASE: one option here would be for us to burn some versions for "v1 compatible version negotiation greasing" (similar but different to 0x?a?a?a?a) and servers can in-band upgrade to those versions. But we could also do that in the reverse direction: the servers advertise support for one of these in Alt-Svc and clients send their Initial to that version, and the server can then perform in-band version change to v1, to another of these versions, or just keep the client's version for the life of this connection. This will cause ossifying middleboxes to break these connections.
>>>>> 
>>>>>  
>>>>> 
>>>>> Thoughts?
>>>>> 
>>>>>  
>>>>> 
>>>>> David
>>>>> 
>>>>>  
>>>>> 
>>>>> On Tue, Feb 12, 2019 at 2:15 PM Roberto Peon <[e-mail]> wrote:
>>>>> 
>>>>> My fear/experience around this is why I'd strongly recommend doing a QUIC V2 as soon as possible where the delta from V1 -> V2 is limited to *solely* what is necessary for version negotiation.
>>>>> 
>>>>> We can simultaneously have a V3 conversation which would  include whatever else we decide we need to change/add as a separate conversation which depends on V2.
>>>>> 
>>>>> -=R
>>>>> 
>>>>> On 2/12/19, 1:36 PM, "QUIC on behalf of Martin Thomson" <[e-mail] on behalf of [e-mail]> wrote:
>>>>> 
>>>>>     On Wed, Feb 13, 2019, at 08:18, Martin Duke wrote:
>>>>>     > 1) Version. I can't think of any immediate negative consequences for a
>>>>>     > middlebox that drops any long header with a version > 1. TLS 1.3 had to
>>>>>     > surrender to this problem by hiding the version elsewhere.
>>>>>     >
>>>>>     > We might avoid this by routinely coalescing long headers with random
>>>>>     > version fields to connection-critical packets. Beyond that, I'm out of
>>>>>     > great ideas. If we don't have a robust defense against this, we ought to
>>>>>     > put some thought into how to deploy a v2 if the version fields is
>>>>>     > inoperable.
>>>>> 
>>>>>     As Mike points out, the Length field is version-specific, so there is no real defense here other than - as many have suggested - using the version field actively.  That means shipping another version.  In a sense, the fact that Google are still not on the same version gives us some time, but it could mean that we might want to look toward having the "add version negotiation and fallback protection" draft define a version rather than an extension.
>>>>> 
>>>>>     > 2) Client Transport Parameters. Initial Keys will help a little bit, but in
>>>>>     > TLS1.3 CCS still sorta exists because middleboxes are inspecting packets so
>>>>>     > deeply. It's not viable for v2 to have the same transport parameters; it's
>>>>>     > only slightly less gross to send v2 client TPs in some later message and
>>>>>     > have to send a fairly bulky "fake" set of v1 TPs in the client hello to get
>>>>>     > through the network.
>>>>> 
>>>>>     I'm not concerned about transport parameters if the above issue is fixed.  TLS had no real issues with extensions, and it looks like we already have the start of a pipeline of extensions coming.  v2 can share the transport parameter extension, unless we decide to change the format in a non-compatible way.
>>>>> 
>>>>>     (Note: CCS in TLS 1.3 only exists because middleboxes were inspecting a lot, yes, but it also indicates that they weren't inspecting enough, because the compatibility hack we have wouldn't work if they did a proper job.)
>>>>> 
>>>>>