Subject: [quicwg/base-drafts] Prevent linkability from responding to migration (#2969)

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Aug 2019 19:45:38 -0700

This closes the rather serious hole we left when we attempted to limit
the effect of perpetual changing of connection IDs.  This uses a
narrower formulation, that I believe will avoid perpetual changes.  But
it does require reciprocal connection ID changes where endpoints
genuinely do migrate.

It's a design change unfortunately, but I hope non-controversial.

Closes #2778.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Prevent linkability from responding to migration

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2969.patch
https://github.com/quicwg/base-drafts/pull/2969.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/2969

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 14 Aug 2019 21:38:45 -0700

kazuho commented on this pull request.

> @@ -2057,11 +2057,17 @@ linked by any other entity.
 At any time, endpoints MAY change the Destination Connection ID they send to a
 value that has not been used on another path.
 
-An endpoint MUST use a new connection ID if it initiates connection migration.
-Using a new connection ID eliminates the use of the connection ID for linking
-activity from the same connection on different networks.  Header protection
-ensures that packet numbers cannot be used to correlate activity.  This does not
-prevent other properties of packets, such as timing and size, from being used to
+An endpoint MUST use a new connection ID if it initiates connection migration as
+described in {{initiating-migration}}.  An endpoint MUST use a new
+connection ID in response to a connection migration if the packet that initiates
+migration uses a different connection ID to packets received on any previous
+path.

I wonder if using the term "initiate a connection migration" is correct, as to me it seems to imply what [section 9.2](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.9.2) talks, but not [path probing (section 9.1)](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.9.1).

Shouldn't we better state that, an endpoint MUST use a new connection ID when responding to a packet on a new path, using a new connection ID?

-- 
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/2969#pullrequestreview-275257914

---

From: MikkelFJ <[email-masked]>
Date: Wed, 14 Aug 2019 22:52:45 -0700

mikkelfj commented on this pull request.

Is it feasible to remember all past CID's?

-- 
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/2969#discussion_r314181948

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Aug 2019 23:02:52 -0700

martinthomson commented on this pull request.

Maybe, but you are right, this could be better.  I just don't know how to word that without turning the sentence into an essay.  Suggestions sought.

-- 
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/2969#discussion_r314183537

---

From: MikkelFJ <[email-masked]>
Date: Thu, 15 Aug 2019 05:46:42 -0700

The server must have a short list if issued CID's. It suffice that the CID is in that list, and that the client does not reuse old CID's - as is already the case. So something like 

```
An endpoint MUST use a new
connection ID in response to a connection migration that uses a new connection ID from the list of issued connection ID's.```

-- 
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/2969#discussion_r314291610

---

From: ianswett <[email-masked]>
Date: Thu, 15 Aug 2019 06:53:34 -0700

ianswett commented on this pull request.

```suggestion
connection ID in response to a change in peer IP or port if the first packet arriving from the new IP and port
```

(and delete the word migration on the next line)

-- 
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/2969#pullrequestreview-275440190

---

From: Martin Thomson <[email-masked]>
Date: Thu, 15 Aug 2019 16:38:23 -0700

@martinthomson pushed 2 commits.

b7e3fecba2e8c2f72f7376a648db487dc6aec9bb  Use address change and previously unused CID
ac1c0083c50c831ad32b7a16ca4b0386b94ee055  Define active connection ID

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2969/files/d365a605731be5a2fce35bb8f545d51f96d241cd..ac1c0083c50c831ad32b7a16ca4b0386b94ee055

---

From: Martin Thomson <[email-masked]>
Date: Thu, 15 Aug 2019 18:17:12 -0700

@martinthomson pushed 1 commit.

96e46271ed3f1649e3c300b920b3d20b22c45a1d  Missed a 'migration'

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2969/files/ac1c0083c50c831ad32b7a16ca4b0386b94ee055..96e46271ed3f1649e3c300b920b3d20b22c45a1d

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 18 Aug 2019 17:15:16 -0700

Thank you for the changes. I think it's much better, the discussion of "active" connection ID looks good.

> @@ -2057,11 +2058,17 @@ linked by any other entity.
 
+described in {{initiating-migration}}.  An endpoint MUST use a new connection ID

Maybe add something like: "or when probing a new path ({{#probing}})"?

> @@ -2057,11 +2058,17 @@ linked by any other entity.
 
-An endpoint MUST use a new connection ID if it initiates connection migration.
-Using a new connection ID eliminates the use of the connection ID for linking
-activity from the same connection on different networks.  Header protection
-ensures that packet numbers cannot be used to correlate activity.  This does not
-prevent other properties of packets, such as timing and size, from being used to
+An endpoint MUST use a new connection ID if it initiates connection migration as
+described in {{initiating-migration}}.  An endpoint MUST use a new connection ID
+in response to a change in the address of a peer if the packet with the new peer
+address uses an active connection ID that has not been previously used by the
+peer.

What should the responding endpoint do, when it does not have any unused Connection IDs?

I think we have at least four options, but neither of them seem to be very good: a) respond using a Connection ID already in use, b) error-close the connection (on the active path), c) respond with a stateless reset, d) drop the packet.

Option _a_ has the privacy concern. I do not think that option _b_ or _c_ is viable, as it creates an attack vector (a middlebox might race the packet that initiates the migration from a different source address. If the spoofed packet reaches the server before the legitimate one, the connection might get dropped as the server might have used all the spare connection IDs for responding to the spoofed packets). Option _d_ seems a bit odd.

Relatedly, Section 9.1 (Probing a New Path) states quote: _An endpoint that uses a new local address needs to ensure that at least one new connection ID is available at the peer. That can be achieved by including a NEW_CONNECTION_ID frame in the probe._ I think that this is a good advice and that we might want to promote the sentences to here, so that it would cover both path probing and immediate connection 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/pull/2969#pullrequestreview-276302869

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Aug 2019 18:44:11 -0700

Yeah, option *d* is the only viable option I can see.  I will add text to that effect.

-- 
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/2969#discussion_r315015933

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Aug 2019 18:53:57 -0700

b678aa88082cb7092694100097d2d20ce190da5a  or probing
6a33e80754da87bd22364a3e8c82dc691e39e149  Recommend including NEW_CONNECTION_ID when migrating

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2969/files/96e46271ed3f1649e3c300b920b3d20b22c45a1d..6a33e80754da87bd22364a3e8c82dc691e39e149

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Aug 2019 18:55:45 -0700

I added a recommendation to send NEW_CONNECTION_ID when migrating.  It's a little janky, because you have to include the frame in every packet to be effective.  Unless you like the wonderful cascading loss that results from your peer being forced to drop all your packets because the golden one didn't get through.  Of course, then you need to worry about how to manage that retransmission logic...

-- 
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/2969#discussion_r315017061

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 18 Aug 2019 20:24:53 -0700

kazuho approved this pull request.

LGTM. Thank you for the changes.

-- 
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/2969#pullrequestreview-276327391

---

From: Mike Bishop <[email-masked]>
Date: Mon, 19 Aug 2019 08:46:28 -0700

MikeBishop 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/2969#pullrequestreview-276650015

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 19 Aug 2019 14:25:45 -0700

erickinnear approved this pull request.

Thanks for writing this up! Content looks great, just two minor wording questions and this looks ready to go.

> @@ -2077,9 +2084,13 @@ genuine migrations.  Changing port number can cause a peer to reset its
 congestion state (see {{migration-cc}}), so the port SHOULD only be changed
 infrequently.
 
-An endpoint that exhausts available connection IDs cannot migrate.  To ensure
-that migration is possible and packets sent on different paths cannot be
-correlated, endpoints SHOULD provide new connection IDs before peers migrate.
+An endpoint that exhausts available connection IDs cannot migrate.  Similarly,
+an endpoint is unable to respond to probes or an attempt by its peer to migrate

This sentence parses oddly for me, I assume it's in the context of the previous sentence, but maybe something like
```
An endpoint that exhausts available connection IDs cannot probe new paths or initiate 
migration, nor can it respond to probes or attempts by its peer to migrate.
```
and replace both sentences.
(Not providing that as a suggested change since it'll mess up the wrapping, sorry!)

> @@ -2077,9 +2084,13 @@ genuine migrations.  Changing port number can cause a peer to reset its
 congestion state (see {{migration-cc}}), so the port SHOULD only be changed
 infrequently.
 
-An endpoint that exhausts available connection IDs cannot migrate.  To ensure
-that migration is possible and packets sent on different paths cannot be
-correlated, endpoints SHOULD provide new connection IDs before peers migrate.
+An endpoint that exhausts available connection IDs cannot migrate.  Similarly,
+an endpoint is unable to respond to probes or an attempt by its peer to migrate
+or probe.  To ensure that migration is possible and packets sent on different
+paths cannot be correlated, endpoints SHOULD provide new connection IDs before
+peers migrate.  If a peer might have exhausted available connection IDs, a

Do we want to reference the other section that talks about SHOULD provide a new CID for every one that gets retired, etc.? I think that's `{{issue-cid}}`.

Specifically the below paragraph: 
```
An endpoint SHOULD supply a new connection ID when it receives a packet with a
previously unused connection ID or when the peer retires one, unless providing
the new connection ID would exceed the peer's limit.  An endpoint MAY limit the
frequency or the total number of connection IDs issued for each connection to
avoid the risk of running out of connection IDs; see {{reset-token}}.
```

```suggestion
peers migrate ({{issue-cid}}).  If a peer might have exhausted available connection IDs, a
```

If that doesn't mess up the spacing.

-- 
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/2969#pullrequestreview-276821582

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Aug 2019 17:08:55 -0700

f1e5f6909e2cdcb8c1c7017cd82b93832c48f8f4  @erickinnear's editorial tweaks

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2969/files/6a33e80754da87bd22364a3e8c82dc691e39e149..f1e5f6909e2cdcb8c1c7017cd82b93832c48f8f4

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 19 Aug 2019 17:29:53 -0700

Latest changes look great! 👍 

-- 
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/2969#issuecomment-522804296

---

From: ianswett <[email-masked]>
Date: Sat, 24 Aug 2019 18:41:53 -0700

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/2969#pullrequestreview-279316203