Martin,
For V1, we had a rule that the version "0x00000001" would only be used
after we had finalized the RFC. Before that, drafts would define
versions such as "0xFF00001D" for draft 29. Should you not follow a
similar mechansim, and define something like version "0xFF0100nn" for
the draft-nn of the V2 spec?
-- Christian Huitema
On 4/23/2021 8:44 AM, Martin Duke wrote:
Hi Marten,
I believe everything you say is true, but to me the main intent of the v2
draft is in fact to exercise VN.
On Fri, Apr 23, 2021 at 5:29 AM Marten Seemann <[email protected]>
wrote:
Hi Martin,
Thanks for writing this up. If there's interest in deploying v1 and v2 at
the same time, we could scratch the requirement to implement the version
negotiation draft. This would open us up to version "downgrade" attacks,
but given that the two versions have identical security properties (by
design), do we actually care?
On the other hand, I'm not sure if deploying v2 right now would actually
help prevent ossification. Middleboxes are already used to seeing multiple
QUIC versions on the wire, since we have quite broad deployment of draft
versions, and some people controlling both endpoints are even using private
version numbers. One might argue that the one thing that will actually
prevent ossification won't be shipping one v2, but only proper greasing of
the field, e.g. by implementing some variant of your version alias draft.
Regards,
Marten
On Fri, Apr 23, 2021 at 1:22 AM Martin Duke <[email protected]>
wrote:
Hi Lucas,
That's a great question that I hadn't considered.
The answer depends on what the WG does with the scope of this, and how VN
evolves.
1. If it turns out there are some useful v1 patches we want to land here,
then there will be some churn.
2. The VN design is baked into v2, and that is not stable yet. While "v2"
might never change, an implementation that advertises v2 may in fact
instantiate non-interoperable VN designs that should not be aggregated into
a single version codepoint (though I'd have to think through how to
negotiate through mutating VN designs; I have probably made a conceptual
error here). In fact this draft is probably a necessary component to doing
proper implementation and testing of compatible VN (unless people keep the
draft versions around).
IMO if this gets to the point of implementation, it would be wise to use
experimental versions until it progresses to RFC. I filed an issue to fix
this: https://github.com/martinduke/draft-duke-quic-v2/issues/1
Thanks,
Martin
On Thu, Apr 22, 2021 at 11:07 AM Lucas Pardue <[email protected]>
wrote:
Hi Martin,
Thanks for writing this up.
Speaking as an individual, I have some naive questions. Is this document
so trivial that it would never change between revisions? Or is there a risk
that something like initial salt in there might need to rev? To rephrase,
would the document be better off starting with a different QUIC version
value before interoperability discovers a problem and we've blown that code
point? We can always develop such a document with a target code point in
mind for use if the doc were to get adopted and run through all due process.
Cheers
Lucas
On Thu, Apr 22, 2021 at 6:52 PM Martin Duke <[email protected]>
wrote:
Hello QUIC,
I believe it was MT that threatened to do this a long time ago, but to
work through compatible version negotiation I wrote up a trivial QUICv2
(below) that just changes the initial salts. This caused me to figure out a
couple of things about VN that may have been obvious to others but not to
me.
TL;DR we made the right decision to keep both in the draft.
1. One very possible world is one where firewalls ossify on expecting
v1 in the first packet, but don't care about subsequent packets. Compatible
VN is well-designed for this world, as Client Initials (and 0RTT, sadly)
can be v1 essentially forever and subsequent packets can be whatever we
want.
2. If all versions are compatible, choice of VN method is essentially
up to the client, but not quite deterministically: it can pick either a
likely supported version or an unlikely one. If unlikely, the server will
either accept it or send a VN. If likely, the server MUST use compatible VN
to change the version, since it can't send a VN packet that contains the
initial version unless it doesn't have full support for it.
Anyway, this v2 draft is available for your consideration if people
want to quickly iterate a new version, and/or we need a vehicle for fixes
to v1.
Thanks
Martin
---------- Forwarded message ---------
From: <[email protected]>
Date: Thu, Apr 22, 2021 at 10:22 AM
Subject: New Version Notification for draft-duke-quic-v2-00.txt
To: Martin Duke <[email protected]>
A new version of I-D, draft-duke-quic-v2-00.txt
has been successfully submitted by Martin Duke and posted to the
IETF repository.
Name: draft-duke-quic-v2
Revision: 00
Title: QUIC Version 2
Document date: 2021-04-22
Group: Individual Submission
Pages: 5
URL:
https://www.ietf.org/archive/id/draft-duke-quic-v2-00.txt
Status: https://datatracker.ietf.org/doc/draft-duke-quic-v2/
Html:
https://www.ietf.org/archive/id/draft-duke-quic-v2-00.html
Htmlized: https://tools.ietf.org/html/draft-duke-quic-v2-00
Abstract:
This document specifies QUIC version 2, which is identical to QUIC
version 1 except for some trivial details. Its purpose is to combat
various ossification vectors and exercise the version negotiation
framework. Over time, it may also serve as a vehicle for needed
protocol design changes.
Discussion of this work is encouraged to happen on the QUIC IETF
mailing list [email protected] or on the GitHub repository which
contains
the draft: https://github.com/martinduke/draft-duke-quic-v2.
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
