Subject: [quicwg/base-drafts] Invariants and Stateless Reset (#930)

From: Mike Bishop <[email-masked]>
Date: Tue, 14 Nov 2017 23:28:36 +0000 (UTC)

These three things are currently specified by the transport spec:

1. The meaning of packet type values and the presence/meaning of fields beyond the Connection ID in a Short Header packet is version-dependent
2. Stateless Reset messages are structured to look like a Short Header packet, including choosing a short-packet-number type value
3. Stateless Reset messages can be sent without knowing the version of the unknown connection

These can't all be true -- pick any two.

My inclination is that we'll want to compromise on the second point.  We may wind up accepting that Stateless Resets might become detectable if the arrangement of Short Header packet type values differs between versions.  If we implement some form of #311, that will make it more difficult for an intermediary to identify when a server has used the "wrong" packet type and might mitigate that somewhat.  Alternately, we retain the "SHOULD use packet type 0x01" and recommend that future versions make sure that codepoint is a reasonable one for Stateless Reset.

Odds are good, but not certain, that if a future version adds new unencrypted fields to the Short Header, random bytes will be at least a plausible value for those.

-- 
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/930

---

From: ianswett <[email-masked]>
Date: Tue, 14 Nov 2017 23:36:36 +0000 (UTC)

Agreed, this is definitely an problem with the current draft.

I previously assumed stateless reset would end up being largely version independent, or if we wanted to change it slightly, we'd package it in the same short header packet.  ie: I'm going to send you a 16 byte token at the end and then a 32 byte token before that and you can accept whichever works for you depending upon your version.  That would imply that the 16 bytes at the end becomes part of the invariants, but nothing else?  Does that seem acceptable?

-- 
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/930#issuecomment-344436540

---

From: ianswett <[email-masked]>
Date: Tue, 14 Nov 2017 23:47:06 +0000 (UTC)

After chatting with @RyanAtGoogle, the 16 bytes would not be a true invariant, but something that could not change while the server still spoke QUIC v1.  If the server stopped supporting v1 and v2 had a new reset, then it'd only have to worry about v2.

-- 
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/930#issuecomment-344438566

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 14 Nov 2017 23:53:28 +0000 (UTC)

Right. As long as a server (and all servers in the same ... cluster/farm/region) speaks only a single version, then there is no ambiguity since the Stateless Reset will be sent on a connection that this server (or one of it's friends) created. However, if the server does support two different version that have different packet types/public header fields then there is ambiguity. I suspect there are heuristics that the server can use to help here, and perhaps a bit of though when creating the format of the new QUIC version will also help.

For example if the new QUIC version adds new packet types, then the the presence of one of these new values indicates to the server that this must be the new version. If the new QUIC version is designed so that when any new fields are added for an existing packet type a Stateless Reset from the old QUIC version would still work, then the server can just sent an old version.

So I think that as long as we're careful, we should be OK here?

-- 
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/930#issuecomment-344439804

---

From: Mike Bishop <[email-masked]>
Date: Wed, 15 Nov 2017 01:38:12 +0000 (UTC)

As long as an endpoint only speaks a single version, many of the invariants don't really matter. But I'm assuming for the discussion that a server speaks multiple versions and doesn't know which version was used for an incoming short packet without connection state.

In order to support that scenario, at least part of Reset needs to be invariant, I think.  However, you're right that careful design in future versions will aid the ability of a Reset to "blend in."

-- 
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/930#issuecomment-344458066

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Nov 2017 03:17:31 +0000 (UTC)

The discussion today concluded that version-specific stateless reset is possible.  The cost here is that servers that speak multiple versions will have to generate a stateless reset that would be accepted in any version.  That's possible if we ensure that concurrently deployed versions only need to write to non-overlapping parts of the packet.

-- 
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/930#issuecomment-347740371