Re: [quicwg/base-drafts] GREASE the flags byte (#311)

[Martin Thomson <[e-mail]>]

This requires positive identification of short vs. long form.  I think that it also fixes the size of the space in which long form packets can be sent.  If the next version of the protocol needs an additional long-form packet, then n_long increases and greased packets suddenly fall into different slots.

That's not workable if you ever want to change this protocol.  I believe that long form packets are most in need of this sort of protection - experience with TLS shows that issues are most likely to occur on the very first packet.  That doesn't mean that greasing the short form isn't valuable, it's just that greasing the initial packets is more important.  We need to balance that with having an escape valve - a way to deploy a new version of the protocol.

We could say that version has to be understood before identifying type (else, send a version negotiation packet and don't grease type there).  That requires that only long form packets either be distinct from short form or that only long form packets arrive prior to establishing state. The latter of these doesn't work in light of NAT rebinding, since short form packets will arrive with no context.  That leads me to conclude the distinguishing long and short is still useful.

So we say that long form packets are identified by some clearly defined operation.  Pick a permutation operation. &0x08 or &0x80 could work, or even something like n%3!=1 so that there can be twice as many long form layouts as short form.  After that you know that version is present and can use version to determine if you even have a hope of recovering the type.

Here is where I think @marten-seemann is right about packing the space of valid codepoints.  A sparsely populated space makes this easier to build.  A complicated PRP hurts, especially since this octet is likely to to need hardware implementation.  That accepts that greasing the type loses any hope of preserving bitwise compatibility with Google-QUIC (why didn't anyone pick up on that in Jana's proposal, or am I just being dense through severe lack of sleep?).

That means that adding a new long form packet layout and type requires a new version.  I think that's a perfectly reasonable compromise.

Short form packets are easier in a way: since those are only exchanged after version negotiation, the only wrinkle is how they are managed after NAT rebinding.  For that, the connection ID remains our best way to ensure that they can be correctly recovered.  Once the server can correlate the packet with a connection, then it's easy to recover type.

@martinduke, @RyanAtGoogle, see #302.

-- 
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/issues/311#issuecomment-280216811