Subject: [quicwg/base-drafts] Stateless Reset Concerns (#1177)

From: MikkelFJ <[email-masked]>
Date: Fri, 09 Mar 2018 00:15:11 -0800

Stateless Reset (SR) has some positives and negatives.
Based on feedback on-list this issue is created to highlight these, asking for more input.

https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.section.7.9.4

With the likely introduction of asymmetric Connection ID's a reset can no longer be routed to the client which reduces effectiveness. But it also prevents a connection specific reset meaning that an off-path attacker has better chances of spoofing a reset. A token could be tied the connection tuple, but this isn't stable through NAT, although it can be hashed to the IP iff migration is not in use.

Positives:

- Google reports that SR measurably reduces overall latency, presumably because some connections eventually fail to route and a timeout would delay reconnection attempts.
- SR is currently only used on clients which are more difficult to target maliciously than a publicly known server.

Negatives:

- SR has the potential to be abused by forcing established connections to close via off-path packet injection.
- SR shadows alternative solutions to the problem such as more aggresive probes with short timeouts.
- SR is currently asymmetric which is odd given that P2P server use is also relevant, but apparently it is difficult to make symmetric in handshake. But OTOH if SR were symmetric, the server (or client) with a publicly known address, would be vulnerable to reset attacks to the extend such are effective.
- With asymmetric Connection IDs the reset cannot always route, which at least conceptually is clumsy and may or may not reduce effectiveness in the primary use case (that likely doens't have client routers).
- Asymmetric Connection ID's makes SR more vulnerable because the receiver cannot verify the connection ID.  A client will also have to do more work to realise that a packet is a reset and not random data.

It is unclear to what extend the positives are important without further input and possibly evalulation of alternative strategies. For example, it might be that SR reduces latency because no alternative counter measure has been implemented. For example a PATH_CHALLENGE might be used as soon as ACK's don't arrive timely rather than waiting for a connection timeout that might have much longer duration because it deals with periods of inactivity as well. That said, a reset will clearly be more effecive when it works as intended.

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

---

From: MikkelFJ <[email-masked]>
Date: Fri, 09 Mar 2018 00:22:04 -0800

I forgot that including the packet number in the SR offers a good counter measure to an off-path attack.

-- 
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/1177#issuecomment-371745028

---

From: Martin Thomson <[email-masked]>
Date: Fri, 09 Mar 2018 01:12:21 -0800

Not sure what can be done here:

The first of these negatives is addressed in the draft.

The second doesn't seem actionable if I understand your intent - if stateless reset works, it's better than aggressive timers, but that's not a problem, especially since aggressive timers have pretty bad side-effects, like premature closure.

The third is addressed in the draft to the extent possible.

The fourth seems to be a duplicate of the third.

-- 
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/1177#issuecomment-371756249

---

From: MikkelFJ <[email-masked]>
Date: Fri, 09 Mar 2018 09:52:28 +0000 (UTC)

The the third negative is about asymmetri in design - a change would likely inherit the fourth neative about routability, but they are not quite the same.

An agressive timer is indeed suitable for self-inflicted wounds, but also offers more control such is being aggressive during connection setup and less so as the connection proves viable.

I'm not sure anything can/should be done, but there better be good reasons to have it since it is an attack vector.

-- 
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/1177#issuecomment-371766103

---

From: MikkelFJ <[email-masked]>
Date: Fri, 09 Mar 2018 02:00:18 -0800

There is also the option to issue a Path Challenge upon receiving a Reset and die if the response does not appear within 1.2 RTT or so. An implementation could choose to a) ignore Resets, b) issue a challenge, or c) always react to Resets.

-- 
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/1177#issuecomment-371767968

---

From: MikkelFJ <[email-masked]>
Date: Fri, 09 Mar 2018 14:00:56 +0000 (UTC)

Added negative 6 on rate limiting state.

-- 
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/1177#issuecomment-371819765

---

From: Mike Bishop <[email-masked]>
Date: Thu, 15 Mar 2018 04:58:41 -0700

Closed #1177.

-- 
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/1177#event-1523098668

---

From: Mike Bishop <[email-masked]>
Date: Thu, 15 Mar 2018 04:58:41 -0700

Discussed at editors' meeting.  The current design is imperfect.  We understand these concerns, and discussed them in the process of coming up with the current design, and decided to accept them (modulo the one which is already separately tracked as #466).  However, if there's an alternative design that you'd like the working group to consider, feel free to e-mail it to the mailing list.

-- 
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/1177#issuecomment-373352328