Subject: Re: [quicwg/base-drafts] Specify DCID of 0-RTT packets (#2398)

From: MikkelFJ <[email-masked]>
Date: Fri, 08 Feb 2019 00:39:34 -0800

Based on proposed 0-RTT routing to single instance for replay protection, discussed on the mailing list, it would be helpful if the server can assign a DCID for use in 0-RTT that is potentially longer than normal CID's. This is because CID routing lifetime may shorter than 0-RTT session tickets, and a longer DCID could make it easier for a server farm to route 0-RTT packets correctly.

-- 
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/2398#issuecomment-461729490

---

From: Mike Bishop <[email-masked]>
Date: Fri, 08 Feb 2019 13:10:38 -0800

Are you proposing that the client should get a CID along with the NewSessionTicket (or the NEW_TOKEN)?  That's been discussed before, and while it makes sense to me, it means that load balancers need to be able to differentiate the two types (and potentially sizes) of CID.

On the whole, I think this is a promising direction, but perhaps not needed for v1.

-- 
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/2398#issuecomment-461947986

---

From: MikkelFJ <[email-masked]>
Date: Fri, 08 Feb 2019 13:25:35 -0800

Yes, along with the session ticket. The ticket transfer is a bit of a black box so I can only propose the high level concept. (I'm wondering if Retry and 0-RTT could be made more similar, but whatever).

> That's been discussed before, and while it makes sense to me, it means that load balancers need to be able to differentiate the two types (and potentially sizes) of CID.

At least such that they have an option to do so if they are so inclined. I.e. there is no immediate downside since you can also just provide a standard CID if that is better for a particular infrastructure.

As to sizes, that was a bigger problem a while ago when the CID size was implicit. Also, since the CID is only used for 0-RTT, it can be large without significant cost - it should/could be changed immediately upon 0-RTT server acceptance.

As to v1, I agree that might be stretching it a bit.

-- 
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/2398#issuecomment-461952123

---

From: Martin Thomson <[email-masked]>
Date: Sun, 10 Feb 2019 16:01:24 -0800

The point that keeps coming up in this context (I'm sure I've typed the same response elsewhere...) is that the timescales over which connection IDs are stable is likely far less than the timescale over which attempting 0-RTT is possible.  That is, you might attempt 0-RTT up to a week later, but the server cluster you hit might be in a configuration so different that the connection ID you got 5 or 6 days ago doesn't route to the same node.

That said, for those server configurations that are more stable, this isn't a terrible idea.  If this were discretionary, say as an extension, then it might be useful for ensuring that 0-RTT attempts are routed to the right destination.

But anything that does this sort of targeting could also create a nice targeted DoS vector.  Connect to the same server multiple times over the course of a week.  Then, when it's go time, send that server 0-RTT using all the collected connection IDs that route directly to it.

Marking v2, not editorial.

-- 
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/2398#issuecomment-462194127

---

From: MikkelFJ <[email-masked]>
Date: Sun, 10 Feb 2019 22:46:57 -0800

It's fine to move to v2 on the larger issue, but the text is still unclear in transport v1.

-- 
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/2398#issuecomment-462231593