Subject: [quicwg/base-drafts] 0-RTT DCID Routing (#1513)

From: MikkelFJ <[email-masked]>
Date: Mon, 02 Jul 2018 21:25:29 -0700

Transport doc says

> Packets protected with 0-RTT keys use a type value of 0x7C. The connection ID fields for a 0-RTT packet MUST match the values used in the Initial packet (Section 4.4.1).

But the original DCID is random and the server with the 0-RTT keys is at the DCID replied to the original handshake packet.

See also
https://github.com/quicwg/base-drafts/issues/1507#issuecomment-401808742

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 02 Jul 2018 23:03:10 -0700

The operating assumption here is that the server doesn't get a chance to set a connection ID because that takes a round trip.  That text exists because the client can still be sending 0-RTT after getting a connection ID from the server.  It's a little rare though, and the consequences of an occasional inconsistency were considered worse than just having all 0-RTT go to the same place, even if that place was a black hole.

-- 
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/1513#issuecomment-402022769

---

From: MikkelFJ <[email-masked]>
Date: Mon, 02 Jul 2018 23:18:38 -0700

You could require the 0-RTT uses not the original DCID, but the DCID it was given by the server after the earlier successfull 1-RTT handshake.

-- 
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/1513#issuecomment-402025481

---

From: Martin Thomson <[email-masked]>
Date: Mon, 02 Jul 2018 23:21:33 -0700

Yes.  That is an option, it wouldn't change the recommendation of the quoted text though.  There's a tension there that makes ticket reuse (a common practice still) harder.

-- 
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/1513#issuecomment-402025967

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Jul 2018 23:34:02 -0700

So a design that might be valid here is to include a connection ID in the NEW_TOKEN frame.  It would be mandatory to use both the token and connection ID if you wanted to use 0-RTT.  I made a similar suggestion early on.

The feedback I got from server implementers is that the value of such a connection ID approaches zero too quickly.  There are so many topology changes in a cluster that a connection ID can be useless even on relatively short timescales.  0-RTT tickets might be valid for hours, but providing a connection ID isn't useful after minutes.

That might have changed, so feel free to poll the list if you think that this is important, or you disagree with that assessment.

-- 
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/1513#issuecomment-402377851

---

From: MikkelFJ <[email-masked]>
Date: Tue, 03 Jul 2018 23:42:48 -0700

It does make sense - in my response to the linked comment above I claim that 0-RTT cannot be routed in the general case. But in specific cases where a DC can distribute 0-RTT trust better than LB routing it makes sense.

I don't know enough about 0-RTT trust formation to have a strong opinion. There are downsides to both cases.

The risk is the 0-RTT mostly become useless and provides more RTT's rather than fewer.

Idea:
0-RTT token is delivered with a DCID token to use in new connections. This DCID is (typically) neither random, not as specific as a proper server generated DCID. This makes it possible to route 0-RTT to any compatible end-point. Perhaps this is what you mean by an ID in the NEW_TOKEN frame? It starts to get complicated, but I think it would work better.

-- 
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/1513#issuecomment-402379540

---

From: Igor Lubashev <[email-masked]>
Date: Sun, 08 Jul 2018 12:26:03 -0700

As a load balancer implementor, my primary consideration is knowing whether a particular bunch of octets is supposed to be server-generated or a random DCID.  If I cannot tell the difference from the packet header (w/o performing crypto), I would prefer t stick with the assumption of "random" and then not have DCID change from the initial.

(CID internal consistency validation would be performed on the DCID that claims to be server-generated, but it should not be the primary method of deciding whether a CID is be considered to be server-generated.)

-- 
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/1513#issuecomment-403310526

---

From: MikkelFJ <[email-masked]>
Date: Sun, 08 Jul 2018 14:11:06 -0700

Currently it would be random. If there were a server negotiated DCID for 0-RTT then I'd assume it could be generally assumed that all 0-RTT initials are server generated DCID's. If it is not consitent, it would be useless as @igorlord suggests.

-- 
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/1513#issuecomment-403317493