RE: QUIC Version Negotiation Extension

[Mike Bishop <[e-mail]>]

Some notes:

  *   Section 3:  “Version negotiation takes place after the retry cycle is over.”  This is only possible for compatible versions; if the server does not support the version the client attempted, it obviously cannot send a Retry packet in that version, because Retry packets are version-specific.
  *   Section 3:  “Servers must retain the ability to process the Initial packet from older versions….”  No, it means that if the server wants to avoid a VN packet, it needs to be able to process the Initial packet from the version the client tried.
  *   Section 4:  Rather than putting a count-prefixed list of versions, perhaps consider just embedding the VN packet payload?  It’s equivalent, but easier to explain.
  *   Section 7:  Clearly it is possible to possible to add new frame types to Initial packets in a future version, I think what you mean to say is that this is a change that would break compatibility between versions.

As a general statement on the document, you assume throughout that all versions have packet types, contain packet types called Initial and Retry, and that Initial packets contain frames.  The odds of those things being true across QUIC versions is likely high, but they’re not invariants, so you can’t assume them here.  You need to state general principles, and then use concepts from QUICv1 as examples of the principle.

For example, rather than discussing version compatibility in terms of Initial packets, you might want to say that versions A and B are “compatible” if the first flight of packets sent by the client in version A carries enough information for the server to generate the corresponding flight in version B, the server speaks version B, and is able to parse at least the first flight of version A.

Also not discussed is the case where the server speaks version(s) which are compatible with what the client offered, but doesn’t speak the version the client offered, even enough to generate the response.  With the right definition of “compatible,” this just falls into the “incompatible” path and works for the server, but you need to call out the fact that the client shouldn’t consider it an error if the server uses the incompatible path between versions that the client thinks are compatible.

From: QUIC <[e-mail]> On Behalf Of David Schinazi
Sent: Monday, November 4, 2019 3:30 PM
To: QUIC <[e-mail]>
Subject: QUIC Version Negotiation Extension

Hi everyone,

From the recent discussion on multiple PRs, it appears that there might be a need for downgrade-safe QUIC version negotiation, earlier than we expected.

EKR and I updated our extension to hopefully suit these needs:
https://tools.ietf.org/html/draft-schinazi-quic-version-negotiation-02

Comments welcome here or on the GitHub (link in draft).

Thanks,
David