Subject: [quicwg/base-drafts] Can Initial/0-RTT CIDs safely be used for routing? (#2026)

From: Mike Bishop <[email-masked]>
Date: Tue, 20 Nov 2018 11:01:50 -0800

In Section 7.2, the spec makes an implicit assumption that the CID of the Initial packet is used for routing:
> A client SHOULD select a Destination Connection ID length long enough to fulfill the minimum for every QUIC version it supports. **This increases the chance subsequent Initial packets are routed to the same server.**

 #2008 makes this even more explicit:
> To enable consistent routing through the subsequent Initial packets are routed to the same server.	handshake, a client SHOULD select an initial Destination Connection ID length long enough to fulfill the minimum size for every QUIC version it supports.

However, in the discussion of #1486, part of the conclusion was that, to protect from malicious clients, load balancers cannot safely permit client-chosen fields to influence the routing of their packets to a particular server.  IIRC, this was also discussed in New York as part of the #1486 discussion.

Did we mean that?  If so, we have conflicting text.

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

---

From: ianswett <[email-masked]>
Date: Tue, 20 Nov 2018 12:30:43 -0800

I'd say sometimes it's safe and sometimes it's not and there are pros and cons of different approaches.  You mention conflicting text, can you point out the text that conflicts with the sections you quoted above in this issue?

-- 
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/2026#issuecomment-440419026

---

From: MikkelFJ <[email-masked]>
Date: Tue, 20 Nov 2018 12:35:46 -0800

I tend to agree with Ian, but an Initial that follows a stateless reset would have to be routed consistently. I assume this reset driven routing cannot (trivially) be abused due to integrity checks in the reset, but I don't recall the details.

-- 
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/2026#issuecomment-440420476

---

From: Mike Bishop <[email-masked]>
Date: Tue, 20 Nov 2018 12:56:35 -0800

Conflicting as in, we have text (quoted) which contradicts my understanding of our decision. I think if we decide to go with what we'd discussed before (don't trust the CID of Initial/0-RTT), we should add some Security Considerations text about that.

-- 
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/2026#issuecomment-440426509

---

From: Mike Bishop <[email-masked]>
Date: Tue, 20 Nov 2018 20:58:17 +0000 (UTC)

@mikkelfj, I presume you mean Retry.  The server can specify any CID in the Retry, but I'd expect the routing to be achieved by IP:port consistency throughout the 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/2026#issuecomment-440427008

---

From: MikkelFJ <[email-masked]>
Date: Tue, 20 Nov 2018 13:10:49 -0800

I mean Retry, of course.

You cannot assume IP/port consistency because the routing will in some cases happen behind an external load balancer that exposes a single public IP and routes to a specific internal IP based on CID.

-- 
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/2026#issuecomment-440430673

---

From: MikkelFJ <[email-masked]>
Date: Tue, 20 Nov 2018 13:15:53 -0800

If a middlebox can tell the difference between and original and a Retry driven Initial packet, it would be possible configure the middlebox to a) route randomly on first initial, or b) route consistently on first initial, and for both a) and b) route consistently after a retry.

In the case b) the middlebox could force a retry when it thinks there is overload either accidentally, or through an attack.

If the Retry is verified properly, it is not possible to forge a successful CID in this case.

All of this should be possible, and trivial to do, but need some reading up to see what is the current state of affairs. I think middleboxes might not be able to detect a Retry driven initial but endpoints are since a Retry can only happen once.

-- 
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/2026#issuecomment-440432094

---

From: MikkelFJ <[email-masked]>
Date: Tue, 20 Nov 2018 13:29:22 -0800

Nah, I think a retry would not make sense in the above, or least not where you end up with the same external loadbalancer and public IP. In that case the load balancer could just internally swap endpoint.

So @MikeBishop is probably right about IP/port stability.

-- 
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/2026#issuecomment-440436042

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Nov 2018 20:13:23 -0800

My answer is that both are true and that they can co-exist.  While the server can't rely on the randomized connection ID being good, it might choose to allow routing based on that value under normal circumstances.

The recommendation that a client not tamper with fields that might alter routing is a sensible one.  As is the recommendation that a server not attach too much significance to values chosen by clients.

-- 
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/2026#issuecomment-440523611

---

From: janaiyengar <[email-masked]>
Date: Wed, 21 Nov 2018 15:33:28 -0800

@martinthomson : I don't think there is any text that suggests a server "not attach too much significance to values chosen by clients".

Do folks think it might be useful to add to Security Considerations?

-- 
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/2026#issuecomment-440850092

---

From: Mike Bishop <[email-masked]>
Date: Mon, 26 Nov 2018 11:50:08 -0800

Obviously I think we should.  :-)  If we think there's a place for both, then let's give both some airtime in the spec.

-- 
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/2026#issuecomment-441774129