Subject: [quicwg/base-drafts] Stateless Reset during Path Migration (#1259)

From: Mike Bishop <[email-masked]>
Date: Mon, 02 Apr 2018 10:21:11 -0700

Extracted from #1251 at @martinthomson's request.  Fixes #1258.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1259

-- Commit Summary --

  * Stateless Reset during Path Migration

-- File Changes --

    M draft-ietf-quic-transport.md (5)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1259.patch
https://github.com/quicwg/base-drafts/pull/1259.diff

-- 
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/pull/1259

---

From: ianswett <[email-masked]>
Date: Mon, 02 Apr 2018 17:27:05 +0000 (UTC)

ianswett approved this pull request.

-- 
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/pull/1259#pullrequestreview-108677641

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Apr 2018 00:35:13 +0000 (UTC)

martinthomson approved this pull request.

Please add a note to the effect that a Stateless Reset causes the connection ID to be unusable thereafter.

-- 
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/pull/1259#pullrequestreview-108784881

---

From: Mike Bishop <[email-masked]>
Date: Tue, 03 Apr 2018 10:42:54 -0700

@MikeBishop pushed 1 commit.

2a7ea4d  Connection ID invalidation

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1259/files/9ecbdf63b775a0f286f009a24941d1551865ccab..2a7ea4daf95281d425d687a193142c85f76189cb

---

From: MikkelFJ <[email-masked]>
Date: Wed, 04 Apr 2018 08:13:49 -0700

mikkelfj commented on this pull request.

> @@ -1489,7 +1489,9 @@ Differences in routing on the Internet might cause the same destination address
 and connection ID to reach a different server instance which does not posses the
 necessary connection state. Receiving a Stateless Reset in response to a probing
 packet SHOULD NOT terminate the connection, but MUST cause the endpoint to
-consider path validation to have failed.
+consider path validation to have failed.  After receiving a Stateless Reset, the
+client MUST NOT send additional packets with the Connection ID used on the
+probing packet.

with high probability.

-- 
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/pull/1259#pullrequestreview-109372636

---

From: Mike Bishop <[email-masked]>
Date: Wed, 04 Apr 2018 08:45:53 -0700

MikeBishop commented on this pull request.

With high probability what?  This isn't a statement that you probably reached the wrong server, it's a normative requirement that the client abandon the path if a certain response occurs.

-- 
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/pull/1259#discussion_r179190052

---

From: MikkelFJ <[email-masked]>
Date: Wed, 04 Apr 2018 15:51:20 +0000 (UTC)

When you create new connections, you use a random connection ID. If "high probability" is not there, it means that you have to log all previous connections and test against those, otherwise you can just assume the random ID is unlikely to collide, but if it does, the world will continue to exist as best as it can.

-- 
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/pull/1259#discussion_r179191962

---

From: Mike Bishop <[email-masked]>
Date: Wed, 04 Apr 2018 17:43:41 +0000 (UTC)

I'm not following.  This text isn't about new connections, and the CID isn't random -- it's supplied by the server.

-- 
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/pull/1259#discussion_r179226189

---

From: MikkelFJ <[email-masked]>
Date: Wed, 04 Apr 2018 17:49:07 +0000 (UTC)

If you create a new Initial packet for a new connection, you use a random CID before using the server provided CID. If you consider this a separate namespace, then your are right. And if you are only referring to the current connection you are also right. But otherwise you risk accidentially creating an already used ID in a new connection, and with, say, 32 bit CID's it is non-neglectible.

-- 
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/pull/1259#discussion_r179227833

---

From: Mike Bishop <[email-masked]>
Date: Wed, 04 Apr 2018 20:59:02 +0000 (UTC)

Given that this text is about path validation using probing packets, yes, I'm assuming we're only talking about the current 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/pull/1259#discussion_r179281130

---

From: Mike Bishop <[email-masked]>
Date: Wed, 04 Apr 2018 14:03:10 -0700

Ah, I think I see what you're saying now.  If the prohibition is read as "you must never use this CID again for anything ever," then the client would be obligated to keep such CIDs persisted and make sure that it never has a randomly-chosen initial CID on a future connection which happens to collide with a CID that got a stateless reset at some point on a past connection.  Yeah, this prohibition is connection-scoped, because now the Stateless Reset token has been leaked and it's vulnerable to packet injection attacks.

-- 
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/pull/1259#discussion_r179282306

---

From: Mike Bishop <[email-masked]>
Date: Wed, 04 Apr 2018 21:05:46 +0000 (UTC)

7b5c347  Connection-scoped

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1259/files/2a7ea4daf95281d425d687a193142c85f76189cb..7b5c34777bbaf2f8d7983b66207de0bb68ae0934

---

From: MikkelFJ <[email-masked]>
Date: Wed, 04 Apr 2018 21:07:37 +0000 (UTC)

thanks

-- 
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/pull/1259#discussion_r179283473

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Apr 2018 02:55:12 +0000 (UTC)

martinthomson commented on this pull request.

> @@ -1490,8 +1490,8 @@ and connection ID to reach a different server instance which does not posses the
 necessary connection state. Receiving a Stateless Reset in response to a probing
 packet SHOULD NOT terminate the connection, but MUST cause the endpoint to
 consider path validation to have failed.  After receiving a Stateless Reset, the
-client MUST NOT send additional packets with the Connection ID used on the
-probing packet.
+client MUST NOT send additional packets on the same connection the Connection ID

missing a word here somewhere

-- 
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/pull/1259#pullrequestreview-109564764

---

From: Mike Bishop <[email-masked]>
Date: Thu, 05 Apr 2018 09:51:33 -0700

61f2e5b  Always proofread carefully to be sure you didn't any words out

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1259/files/7b5c34777bbaf2f8d7983b66207de0bb68ae0934..61f2e5be6f63fb0db7a181c1e2d90e9631a6cc7b

---

From: Mike Bishop <[email-masked]>
Date: Fri, 06 Apr 2018 13:00:36 -0700

2bf9a02  ...or leters, either.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1259/files/61f2e5be6f63fb0db7a181c1e2d90e9631a6cc7b..2bf9a02a7eec83fb0c8e2dc5bb36970c7c2f3792

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 07 Apr 2018 01:06:46 +0000 (UTC)

kazuho commented on this pull request.

> @@ -1485,6 +1485,13 @@ path validation with other frames.  For instance, an endpoint may pad a packet
 carrying a PATH_CHALLENGE for PMTU discovery, or an endpoint may bundle a
 PATH_RESPONSE with its own PATH_CHALLENGE.
 
+Differences in routing on the Internet might cause the same destination address
+and connection ID to reach a different server instance which does not possess
+the necessary connection state. Receiving a Stateless Reset in response to a

May I question if it is a good idea to let a different server (that does not know the connection state) send a Stateless Reset?

My understanding is that the static key that is used to generate stateless reset tokens cannot be shared between endpoints that do not share the connection states. The attack (credit goes to @siyengar) is as follows.

Consider the case where we have two different servers A and B that do not share the connection state but shares the static key that is being used to generate the stateless reset tokens.

An on-path attacker wants to kill a connection that goes to A. The attacker creates a packet that carries the same CID as the connection he/she wants to kill, and send it to server B. Server B returns a stateless reset. The attacker then forwards the stateless reset to the client and the connection gets reset.

To summarize, I believe that you can send a stateless reset only from a server that knows (or should have known) the connection 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/pull/1259#pullrequestreview-110241523

---

From: Mike Bishop <[email-masked]>
Date: Mon, 09 Apr 2018 17:52:27 +0000 (UTC)

Yes, that's the attack in #1230.  The scope of that key is a deployment issue, and we don't currently have good guidance around that problem.  I think limiting the scope of the key is probably the right choice, but unfortunately that's not something the protocol (or even the implementations) control -- it's a deployment decision.

Probably the right choice is some text in 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/pull/1259#discussion_r180177406

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 10 Apr 2018 02:04:52 +0000 (UTC)

@MikeBishop Thank you for the answer and pointing to your comment on #1230, I missed that. I will make my future comments there.

-- 
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/pull/1259#discussion_r180279237

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Apr 2018 02:27:14 +0000 (UTC)

Based on the discussion thus far, I don't think that we should take this.  Instead, we should make it clear that whatever instances share a key for stateless reset MUST use the same connection ID space.  Otherwise we'll end up deep in all sorts of nasty DoS problems.

-- 
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/pull/1259#issuecomment-381002031

---

From: Mike Bishop <[email-masked]>
Date: Fri, 13 Apr 2018 14:22:15 -0700

I'm amenable to that.  It has the interesting result that, during path validation, we'll be provoking Stateless Resets that parse as invalid.  Some implementations might still want to use that as a hint that the path isn't likely to work, but we don't need that to be normative.

-- 
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/pull/1259#issuecomment-381263818