Subject: [quicwg/base-drafts] Don't Stateless Reset probes from IPs you wouldn't talk to (#3832)

From: Mike Bishop <[email-masked]>
Date: Tue, 07 Jul 2020 16:07:08 -0700

@ianswett points out that the obvious solution to #3765 is for the node to respond to the attempted probe with a stateless reset.  Clients would see a Stateless Reset while attempting to probe and not use the new path.  That was, in fact, part of the original design IIRC.

However, the reason we removed that was that doing so opens up an attack.  An attacker can take a packet, rewrite the source address to an IP range the server always rejects, and get back a valid SRT for that CID.  It can then inject the SRT toward the client to destroy the connection at any time, albeit only until the CID is rotated out.

As far as I can tell, this attack isn't documented anywhere.  The right fix is to note that if servers receive packets that would be associated with an existing connection but would not permit migration, they SHOULD drop the packet and MUST NOT generate a stateless reset.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Jul 2020 17:40:43 -0700

I think that we do have this text.  A [whole section](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-stateless-reset-oracle) in fact:

> If a packet can be routed to different instances that share a static key, for example by changing an IP address or port, then an attacker can cause the server to send a stateless reset.

The subtle distinction here is not that you are unable to respond, but instead unwilling.  Why would you send a stateless reset when you are pretending that the route doesn't work?  (Sorry, this just seems like self-inflicted harm.)

-- 
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/3832#issuecomment-655212549

---

From: Mike Bishop <[email-masked]>
Date: Wed, 08 Jul 2020 11:32:35 -0700

Yeah, but this is specifically not a different instance.  The defense in that case is to use different keys, so the generated stateless reset isn't valid for the original connection.

The section in question could perhaps be augmented to talk about behavior when an instance receives a packet associated with an active connection, but from a source that it considers unacceptable for that connection.

-- 
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/3832#issuecomment-655685196

---

From: ianswett <[email-masked]>
Date: Wed, 08 Jul 2020 12:59:06 -0700

> The subtle distinction here is not that you are unable to respond, but instead unwilling. Why would you send a stateless reset when you are pretending that the route doesn't work? (Sorry, this just…

In the case of unsupported migration, the thinking is that a stateless reset would cause the path validation to fail in one round trip(opposed to a timeout), which is very useful if it's the only path the client can use.

I think it's worth saying something about this case, but I'd I'm not sure we need normative language.  If a server thinks the best course of action is to terminate the connection in this case, then sending a stateless reset is still the right thing to do.

-- 
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/3832#issuecomment-655725193

---

From: Igor Lubashev <[email-masked]>
Date: Thu, 09 Jul 2020 08:45:45 -0700

@martinthomson 

> Why would you send a stateless reset when you are pretending that the route doesn't work? (Sorry, this just seems like self-inflicted harm.)

So stateless reset is a wrong mechanism, but you seem to be asking why refuse to serve traffic to a set of CIDRs if they seem to be reachable.  The answer could be (a) contractual/legal reasons, (b) performance reasons (you know it will be poor).

-- 
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/3832#issuecomment-656203693

---

From: Igor Lubashev <[email-masked]>
Date: Thu, 09 Jul 2020 08:52:27 -0700

I think the normative language is that _a valid Stateless Reset MUST NOT be sent, while a connection with that CID could still be active_.  This covers both far-away-server Stateless Reset Oracle text quoted by @martinthomson and the same-server Stateless Reset Oracle mentioned by @MikeBishop here.  I am happy to provide a PR for this.

-- 
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/3832#issuecomment-656207028

---

From: Martin Thomson <[email-masked]>
Date: Thu, 09 Jul 2020 17:29:53 -0700

That's a good addition.

-- 
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/3832#issuecomment-656416360

---

From: ianswett <[email-masked]>
Date: Fri, 10 Jul 2020 07:01:19 -0700

If the packet arrives at the right connection, there's no need to send a stateless reset at all.  If a server wants to close the connection, it should just send a connection close, which is likely to be smaller and doesn't have any Stateless Reset Oracle issues.

-- 
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/3832#issuecomment-656692261

---

From: Igor Lubashev <[email-masked]>
Date: Fri, 10 Jul 2020 07:07:53 -0700

The client could still have its original network attachment intact and could be just probing of it can migrate to the second attachment. Sending a PATH_RESPONCE with CONNECTION_CLOSE will kill the connection instead of telling the client "don't migrate".

-- 
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/3832#issuecomment-656695408

---

From: ianswett <[email-masked]>
Date: Fri, 10 Jul 2020 08:15:13 -0700

Agreed, I had in mind the case when disable migration was also sent.

I think there are a number of use cases and options here, and the key thing is to ensure servers understand the implications of their choices.

-- 
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/3832#issuecomment-656728425

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 12 Jul 2020 19:18:51 -0700

I'm a bit confused in this discussion. Stateless Resets have had connection-level scope so far, and using that signal for invalid paths would be an overload. Not that I'm opposed to this on the face of it, I am just noting that as a significant departure.

FWIW, I'm on board with the change to saying "a valid Stateless Reset MUST NOT be sent, while a connection with that CID could still be active". That is the right response I think.

-- 
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/3832#issuecomment-657323432

---

From: Martin Thomson <[email-masked]>
Date: Sun, 12 Jul 2020 20:51:19 -0700

I took a swing at this.

-- 
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/3832#issuecomment-657343990

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Jul 2020 01:50:39 +0000 (UTC)

Closed #3832 via #3894.

-- 
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/3832#event-3542080543