Re: Tacking stuff on to VN packets

[Martin Duke <[e-mail]>]

> What problem are you trying to solve with this trailer?

For the purposes of this discussion, I'm wondering about this idle
speculation in the invariants draft. Having this field would simplify some
problems in an individual draft I'm working on, but there are other ways to
fix it.

If no one is going to say "Yes we should have this capability" then we can
either excise the text from invariants or, at this late stage, at least
have an understanding that this text doesn't mean anything.

Martin

On Tue, May 11, 2021 at 10:18 AM David Schinazi <[e-mail]>
wrote:

> Unfortunately that won't work. Supporting multiple versions of QUIC does
> not require supporting any document, apart from the QUIC invariants. And
> the invariants don't reserve space for a trailer after the Supported
> Versions field. What problem are you trying to solve with this trailer? I
> suspect there are easier ways of solving it.
>
> David
>
> On Tue, May 11, 2021 at 10:11 AM Martin Duke <[e-mail]>
> wrote:
>
>> Section 6 of invariants
>> <https://quicwg.org/base-drafts/rfc8999.html#name-version-negotiation>
>> sayeth:
>>
>> "Version Negotiation packets do not use integrity or confidentiality
>> protection. Specific QUIC versions might include protocol elements that
>> allow endpoints to detect modification or corruption in the set of
>> supported versions."
>>
>> I also vaguely remember ekr batting around the idea of tacking some data
>> onto the packet  to solve a problem we were discussing.
>>
>> *Maybe we just don't want to do this at all and we can safely ignore this
>> text in invariants.*
>>
>> If we *do* want to do it, the design is a little problematic. There is no
>> length field in VN packets to signal that the supported version list is
>> ending and other stuff is beginning.
>>
>> The only way I can think of to make this work is to use the VN draft to
>> reserve a magic version number to mean "this is the end of the supported
>> version list". That version is not a real version, MUST be the last one
>> listed, and perhaps can be followed by another magic number to indicate the
>> content that follows.
>>
>> Leaving aside legacy stuff negotiating pre-standard versions, which will
>> hopefully go away someday, someone supporting multiple versions would be
>> REQUIRED to support the VN draft and therefore incorporate this change.
>>
>> Thoughts?
>> Martin
>>
>>
>>