Re: QUIC ossification

[Jana Iyengar <[e-mail]>]

Brian,

I agree that there are potentially other models as well, but the one we
know from experience is the naive one.  We should at least protect against
the one model we know, naive or not. I'll note that it quickly gets
difficult to come up with measures if we assume a smarter ossifier.

- jana

On Tue, Feb 19, 2019 at 11:03 PM Brian Trammell (IETF) <[e-mail]>
wrote:

> (oops, hit send too soon...)
>
> > On 20 Feb 2019, at 07:58, Brian Trammell (IETF) <[e-mail]>
> wrote:
> >
> > hi Jana,
> >
> > The middlebox adaptation model that this proposal addresses seems
> limited to middleboxes built based on naive traffic analysis and pre-QUIC
> assumptions about wire images. This is admittedly the model behind one of
> Google's experiences with QUIC middlebox breakage, and the one we seem most
> concerned with because by definition we cannot fix it by writing things in
> documents.
>
> I don't think these are the only things we're concerned about though.
> Concerns about partitioning VN space have a less naive model in mind: here
> we think more about default-deny firewalls that have been told that some
> versions of QUIC are okay but all others are not. As noted before I
> personally cannot think of a reason an operator would want to do this -- if
> you've already decided to allow a protocol with low observability and
> built-in extensibility as a design goal on your network, does the exact
> flavor really matter all that much? -- but it's a checkbox on the firewall
> feature list so yeah, I suppose someone will ship it.
>
> Are there other middlebox adaptation models we are concerned about here?
>
> Cheers,
>
> Brian
>
>
> >> On 20 Feb 2019, at 00:17, Jana Iyengar <[e-mail]> wrote:
> >>
> >> Roberto -- yes, that's basically what I'm proposing too, just one
> variant of how to go about doing it dynamically over time.
> >>
> >> On Tue, Feb 19, 2019 at 3:14 PM Roberto Peon <[e-mail]> wrote:
> >> As others have intimated in some form or another, you can also use
> multiple numbers to express “version 1”.
> >>
> >>
> >> For instance, pick 64 (or some similar constant) random numbers, and
> call them all version 1.
> >> -=R
> >>
> >>
> >>
> >> From: QUIC <[e-mail]> on behalf of Jana Iyengar <
> [e-mail]>
> >> Date: Tuesday, February 19, 2019 at 3:10 PM
> >> To: Martin Thomson <[e-mail]>
> >> Cc: QUIC WG <[e-mail]>
> >> Subject: Re: QUIC ossification
> >>
> >>
> >>
> >> On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson <[e-mail]>
> wrote:
> >>
> >> I don't think that there is much value in using two version numbers to
> refer to the same protocol.  But even if we did, as long as we didn't
> establish any pattern in doing so, that couldn't be used against us.  So I
> might tentatively agree that 0x1 == 0x2 would be inadvisable, there is no
> strong need to do anything special with the first version.  Any attempt to
> profile QUIC will be done with full knowledge of the version number we
> pick, so randomness doesn't serve any real purpose.  Subsequent versions
> might need to use a randomized value, but we can make that decision then.
> >>
> >>
> >>
> >> I figured that making all version assignments random instead of
> special-casing 0x1 made it simpler to reason about and uniform to code for,
> but I actually don't care about the IANA assignment for v1 for the reason
> you note. v1 will be one specific bit-pattern on the wire to start of with,
> and that can just as well be 0x1. It still does segregate the space, but we
> can't do anything about it anyways - it'll be 0x1 or some other random
> number getting special treatment.
> >>
> >>
> >>
> >> The problem of course being that as long as v1 remains, we might find
> places that no other version does.  The QUIC "magic number" will be
> whatever we pick, and we can't prevent someone from fixating on that..
> We'll convince those people in the same way they will be convinced to open
> up UDP for QUIC version 1: by making a QUIC version 2 worth enabling.
> >>
> >>
> >>
> >> That was the entire point of having alternate and preferred versions to
> 0x1. If we have downgrade protection in place, and if there are those who
> try alternate version numbers for v1, that gives us what we need at the
> endpoints. I believe that there would be interest at some major vendors to
> do this at some endpoints. Presumably, we can convince Google to do
> something, since it has been bit by mbox ossification in the past. I am
> operating on the premise that we have buy in from a few major providers.
> >>
> >>
> >>
> >> IANA is for me a publication venue where these alternate versions are
> published and other clients/servers interested in keeping the ecosystem
> from ossifying can use these alternate versions as well.
> >>
> >>
> >>
> >> I completely get the don't segregate thing.  But to - I think -
> Mikkel's point about experimentation without permission, I do think that
> squatting is a perfectly sound approach in a space this big.  TLS people do
> it in a much smaller space.  As long squatters pick random values, they do
> so infrequently, and they get IANA registrations for codepoints relatively
> soon afterwards, the risk of collision is low.  Randomness here is useful -
> but primarily as a collision-avoidance technique.  The TLS extension
> codepoint 26 is a great example of why.  Keeping the bar on registrations
> low (FCFS is a reasonable policy) would also have the effect of making the
> pool of apparent versions larger, which might be more effective than any
> other strategy we might employ.
> >>
> >>
> >>
> >> I'm totally fine with experimentation without permission, and using
> random to avoid collision. My point was entirely about using alternate
> on-wire version numbers for v1. Nothing here about new or experimental
> versions.
> >>
> >>
> >>
> >
>
>