Re: [quicwg/base-drafts] QUIC Ossification (#2496)

[Kazuho Oku <[e-mail]>]

> Are there any changes to VN we can make to reduce the chance of ossification happening?

We only have obfuscation to protect the payload format of Initial packets from ossification. Therefore, IMO the question is if we can have something similar for the version number field, without making the protocol complex.

As some have pointed out, using multiple version numbers on wire to designate "version 1" is one way to go. That would be sufficient as a protection against middlebox vendors who try to use the version number field in some ways in negligence. I also think that that might be the only thing that we can do without making the "version number obfuscation scheme" an invariant.

We could do various things if we think that it is a good idea to make the obfuscation scheme an invariant. For example, we could set the version number field to a XOR value of the version number and four octets that follow the DCIL/SCIL fields (i.e. `version_number_field = version_number XOR packet[6..9]`). Such scheme would IMO require the middlebox vendors to actually consult the specification when they try to detect the QUIC protocol version. In other words, it would be as reliable as the AES-based ossification scheme we use for Initial packet payload.

-- 
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/2496#issuecomment-469563881