Subject: [quicwg/base-drafts] Two CHs handling the same SH (#4090)

From: ekr <[email-masked]>
Date: Thu, 10 Sep 2020 15:14:23 -0700

Over in TLS, Mike Bishop posits the following scenario:

> The client sends an Initial packet (randomly selected Destination CID), PTOs, then sends another Initial packet to the same Destination CID.  On the server side, the infrastructure assumes that Initial packets whose CIDs aren’t issued by them can be routed to a random back-end, and that back-end will set a new DCID that routes to it in the future.

> The client will receive either of the Server Initial packets, switch to the new DCID, and will reject the other because attempts to change the server’s CID a second time.  The connection succeeds because whichever server’s ServerHello is used also has its DCID used, so all subsequent packets go to that back-end.

https://mailarchive.ietf.org/arch/msg/tls/O5jDgpPyQ_BSIz8_LXmD5rbOHnw/

My response:

> While it's not clear to me that QUIC explicitly prohibits this (it would be prohibited if CRYPTO frames were STREAM frames because of draft-ietf-tls-quic-transport S 2.2, it seems like it's  quite bad practice because the result will be that the losing server has a pending handshake which it continues to retransmit on until the client times out.

Is this in fact possible? Should we forbid it?

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

---

From: David Schinazi <[email-masked]>
Date: Thu, 10 Sep 2020 15:48:40 -0700

If I understand this issue correctly, we have an edge case that we hadn't thought of where things are odd but functional. Since this doesn't cause any failures or security issues, do we need to do anything about it? The only negative outcome seems to be that the server wastes a small amount of resources, and the server can unilaterally fix this themself by using deterministic CID routing. I'm inclined to put this in the "Doctor, it hurts when I poke myself in the eye" bucket and not worry about it. I think banning this server behavior isn't helpful because it might be reasonable for a server deployment to do this intentionally if it's cheaper for them to use randomized client-selected-CID routing even with the wasted resources cost. 

-- 
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/4090#issuecomment-690771839

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Sep 2020 18:25:52 -0700

Given that we already discussed this (if you want me to dig up the discussion, I'll have to ask for a small fee), the relevant question is whether the spec covers this.  We have lost things from time-to-time, so it is worth checking. 

And we're OK:

> Once a client has received a valid Initial packet from the server, it MUST discard any subsequent packet it receives with a different Source Connection ID.
That is in [Section 7.2](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-7.2-7).

The assumption here is that the server instances that answer different Initial packets will generate different connection IDs.  I think that's a good assumption.

So I'm not seeing an action 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/4090#issuecomment-690817919

---

From: ianswett <[email-masked]>
Date: Fri, 11 Sep 2020 13:25:11 -0700

Additionally, we also say you can't migrate during the connection, so I expect many deployments will use 5-tuple for long-header packets and CID for short-header packets.

-- 
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/4090#issuecomment-691295994

---

From: ekr <[email-masked]>
Date: Fri, 11 Sep 2020 15:07:16 -0700

On Fri, Sep 11, 2020 at 1:25 PM ianswett <[email-masked]> wrote:

> Additionally, we also say you can't migrate during the connection, so I
> expect many deployments will use 5-tuple for long-header packets and CID
> for short-header packets.
>
OK, so now I'm confused. Do you think that this forbids this server
behavior?

-- 
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/4090#issuecomment-691332476

---

From: ianswett <[email-masked]>
Date: Fri, 11 Sep 2020 16:05:11 -0700

I don't believe it forbids it, but it allows servers to avoid this edge case if they choose.

-- 
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/4090#issuecomment-691347552

---

From: Igor Lubashev <[email-masked]>
Date: Sun, 13 Sep 2020 07:18:47 -0700

I am not seeing a problem either. FWIW, our infrastructure has been doing precisely this for TCP in some cases for over 15 years, and it works fine.

-- 
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/4090#issuecomment-691677318

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Sep 2020 15:33:17 -0700

Based on discussion, it looks like we're OK.

-- 
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/4090#issuecomment-693014439

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Sep 2020 15:33:19 -0700

Closed #4090.

-- 
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/4090#event-3770571481