Re: QUIC ossification

[Mikkel Fahnøe Jørgensen <[e-mail]>]

I still think there is a need for private experimentation without going all
IANA.

If randomisation is a good idea, why not have 128-bit version identifiers -
each org with special needs can encrypt their own version numbers.
Now you have fully randomised keys and infinitely many spaces.
Since the VN’s are only used in a few header packets, 128-bits is a fine
length.

Mikkel


On 19 February 2019 at 04.36.21, Jana Iyengar ([e-mail]) wrote:

On Thu, Feb 14, 2019 at 6:43 PM Martin Thomson <[e-mail]> wrote:

> On Fri, Feb 15, 2019, at 12:22, Ian Swett wrote:
> > I believe the concern is that a middlebox/etc will conclude that a
> > certain range of versions are IETF standard versions and should be
> > allowed and others are fine to block because they're experimental,
> > thereby making the majority of versions largely undeployable.
>
> That only suggests to me that we not segregate the space.  The proposed
> variations won't all happen in that space.
>

The whole point of the proposal was to avoid segregating this space. Let me
articulate a bit better, and folks can poke holes.

Whatever we choose for the on-wire representation of version 1, that's
visible to mboxes and they can ossify around it. We want more versions on
the wire to avoid this from happening.  As long as a few major players use
a few more versions on the wire besides v1, that's all we need to keep the
ecosystem from ossifying.

Ideally, the additional versions keep changing over time to avoid those
getting ossified as well. So a server can simply choose a random version
periodically and use it. But we need clients to use the version as well,
and since not everyone is Google, we use IANA to publish this new version.
Basically, (i) org requests new version from IANA, (ii) IANA either assigns
a new version (randomly) or approves the requested version for use as
additional v1, and (iii) clients and servers roll out support for this new
version. Note again that all servers and clients continue supporting the
original v1 version; this is an additional preferred version when it is
available on both sides. This gets us greasing, and ensures that we have a
mechanism in play that protects against downgrade protection.

Let's say we use 0x00000001 as v1. Do we allow 0x00000002 as an additional
version for v1? If we do, then what is the on-wire representation for v2?
If we don't, then we have to segregate the space. To avoid this problem, I
suggested that we randomize everything. It's not that hard: IANA can easily
assign a version to us at RFC publication time much in the same way as they
would to anyone requesting an additional on-wire version for v1 in the
future.