Subject: [quicwg/base-drafts] Detectable Stateless Resets (#3032)

From: martinduke <[email-masked]>
Date: Fri, 13 Sep 2019 14:26:56 -0700

What are the implications of some stateless resets being detectable? The new language explicitly allows a situation where a host chooses not to pad out all its packets to include the length of its own connection ID. In this situation, a small packet could trigger a stateless reset from the peer that is too small to be anything other than a stateless reset.

I don't believe this will happen "all the time", as in general Server CIDL > Client CIDL and in general servers are the ones sending resets. Those are somewhat weak assumptions for reasons we can bracket for now, but I feel confident that the detectable reset will happen in the internet, at least occasionally. What is the threat model we feared when we put in the original rules to block reset detection, and do the concerns apply 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/3032

---

From: David Schinazi <[email-masked]>
Date: Fri, 13 Sep 2019 15:51:13 -0700

My understanding is that we want stateless resets to be hard to detect to avoid someone implementing a NAT that detects stateless resets and upon seeing them removes the NAT port mapping. As long as stateless resets are almost-always undetectable, we've removed the incentive for anyone to write that bad NAT code.

-- 
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/3032#issuecomment-531414605

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 16 Sep 2019 17:13:12 -0700

What @DavidSchinazi said. The goal here was to avoid trivial signatures that get used by middleboxes so that connections are resilient to a third party that injects a StatelessReset-like 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/3032#issuecomment-532005595

---

From: martinduke <[email-masked]>
Date: Thu, 19 Sep 2019 10:02:09 -0700

I guess the embedded assumption is that the following scenario does not become prevalent in the internet:
- Server infrastructures generally do not support migration, meaning a 4-tuple based architecture is satisfactory;
- As CIDs are irrelevant to switching, servers choose short CIDs, specifically to enable stateless reset; and
- Clients generally do not take care to pad their small packets

It's hard to predict the future, but if the internet evolves this way we'll have enabled some bad outcomes. I'm disinclined to change the spec at this time, but we should aware of the implications of this evolution if it occurs.

Unless I've gotten someone more concerned than I am, I believe it's OK to close this issue. I'll do so in a couple of days if no one pipes up.

-- 
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/3032#issuecomment-533221421

---

From: MikkelFJ <[email-masked]>
Date: Thu, 19 Sep 2019 10:33:13 -0700

That is not a good assumption.

I have redundant servers that respawn should one go down either due to an error, or more likely, a software upgrade. While these are behind load balancers that hide their address, this is not always the case.

Therefore, server migration could be a very real thing. Now, it is not necessarily trivial to pass state to fail-over servers, but it does happen.

-- 
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/3032#issuecomment-533232513

---

From: martinduke <[email-masked]>
Date: Thu, 19 Sep 2019 15:24:54 -0700

I'm not talking about server migration, I"m talking about server support for client migration.

-- 
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/3032#issuecomment-533331525

---

From: David Schinazi <[email-masked]>
Date: Thu, 19 Sep 2019 22:58:50 -0700

@martinduke I think your nightmare scenario is very unlikely, as it requires the three bullets you mentioned, but also depends on the size of client connection IDs. I think we can assume that:

- most browsers will use zero-length client connection IDs
- most servers will use non-zero-length server connection IDs

At that point it's extremely unlikely that NAT/firewall manufacturers will build the "remove port mapping when you observe a 20-byte packet" feature for a minority of traffic, it's not like there's an overwhelming amount of innovation in this space...

-- 
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/3032#issuecomment-533418428

---

From: martinduke <[email-masked]>
Date: Fri, 20 Sep 2019 18:06:01 -0700

Why would a server use a connection ID if stuck with a 4-tuple based infrastructure? The only reason is to allow stateless resets, which only requires a byte.

-- 
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/3032#issuecomment-533754949

---

From: martinduke <[email-masked]>
Date: Mon, 23 Sep 2019 12:19:30 -0700

Closed #3032.

-- 
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/3032#event-2655603510