Subject: [quicwg/base-drafts] New connection IDs are mandatory for intentional migration (#2414)

From: Martin Thomson <[email-masked]>
Date: Mon, 04 Feb 2019 23:12:42 +0000 (UTC)

Based on #2386, which should merge soon.

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

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

-- Commit Summary --

  * Remove requirement for reciprocal connection ID change
  * remove redundant word
  * Editorial changes
  * New connection IDs are mandatory for intentional migration

-- File Changes --

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

-- Patch Links --

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 04 Feb 2019 15:51:17 -0800

@martinthomson pushed 1 commit.

d6fe1014583969a45f91f9e44022f61b87a8a200  Reword zero-length caveat

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2414/files/13698cbe311922a3995236dda960b4cdff49e36f..d6fe1014583969a45f91f9e44022f61b87a8a200

---

From: ianswett <[email-masked]>
Date: Tue, 05 Feb 2019 07:46:45 +0000 (UTC)

ianswett commented on this pull request.

 Clients MAY move to a new connection ID at any time based on
 implementation-specific concerns.  For example, after a period of network
-inactivity NAT rebinding might occur when the client begins sending data again.
+inactivity, where NAT rebinding might occur when the client begins sending data

```suggestion
inactivity, NAT rebinding may cause an unintentional change in path when the client begins sending data
```

-- 
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/2414#pullrequestreview-199943052

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 05 Feb 2019 01:21:49 -0800

janaiyengar commented on this pull request.

> @@ -2089,15 +2089,17 @@ different local addresses, as discussed in {{connection-id}}.  For this to be
 effective endpoints need to ensure that connections IDs they provide cannot be
 linked by any other entity.
 
-This 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
-correlate activity.
+An endpoint MUST use a new connection ID if it initiates connection migration,

I would move the conditional clause to the beginning, otherwise it's not clear what the "This" in the next sentence refers to.

"Unless the peer has selected a zero-length connection ID, an endpoint MUST use ..."

Also, how about adding something about what the endpoint needs to do if it has nothing from the peer? Something like: "If no new connection IDs are available, the endpoint MUST NOT migrate. The endpoint MAY close the connection, but MUST NOT send any packets on a new path with the same connection ID as that used on an earlier path."  I can't find any text that says as much. I wonder if this is a new non-editorial issue, since we currently do not have normative text about this (maybe I just can't find it yet).

-- 
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/2414#pullrequestreview-199973660

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 05 Feb 2019 01:22:52 -0800

> -that packets sent on different paths cannot be correlated. To fulfill this
-privacy requirement, endpoints that initiate migration and use connection IDs
-with length greater than zero SHOULD provide their peers with new connection IDs
-before migration.
-
-Caution:
-
-: If both endpoints change connection ID in response to seeing a change in
-  connection ID from their peer, then this can trigger an infinite sequence of
-  changes.
+An endpoint cannot migrate to a new path if it does not have a connection ID to
+use on that path.  An endpoint that exhausts available connection IDs cannot
+migrate.  If a peer chooses to receive packets with zero-length connection IDs,
+an endpoint can always 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.

This text is good, but still doesn't have normatives, and I think we should have MUST NOT. 

-- 
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/2414#pullrequestreview-199974090

---

From: Martin Thomson <[email-masked]>
Date: Tue, 05 Feb 2019 03:19:35 -0800

491d871829800a78661202e642839ab1e97100d8  Explain more

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2414/files/d6fe1014583969a45f91f9e44022f61b87a8a200..491d871829800a78661202e642839ab1e97100d8

---

From: ianswett <[email-masked]>
Date: Tue, 05 Feb 2019 13:03:36 -0800

> -after migration. Endpoints that receive packets with a previously unused
-Destination Connection ID SHOULD change to sending packets with a connection ID
-that has not been used on any other network path.  The goal here is to ensure

I think it makes sense to put this 3rd sentence first, and then say, "Otherwise, an endpoint cannot migrate..."

The current text reads in a somewhat self-contradictory way.

-- 
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/2414#pullrequestreview-200301616

---

From: Martin Thomson <[email-masked]>
Date: Tue, 05 Feb 2019 15:05:12 -0800

96b9fe88ce116bba073406d2f0ac65e02e37254f  Editorial changes, stronger MUST

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2414/files/491d871829800a78661202e642839ab1e97100d8..96b9fe88ce116bba073406d2f0ac65e02e37254f

---

From: Martin Thomson <[email-masked]>
Date: Tue, 05 Feb 2019 15:12:03 -0800

martinthomson commented on this pull request.

I've just updated the text below to cover the MUST NOT migrate case (I used "cannot" before).

-- 
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/2414#discussion_r254081076

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 05 Feb 2019 21:29:47 -0800

-before migration.
-
-Caution:
-
-: If both endpoints change connection ID in response to seeing a change in
-  connection ID from their peer, then this can trigger an infinite sequence of
-  changes.
+An endpoint MUST NOT intentionally migrate to a new path if it does not have a
+connection ID to use on that path.  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.
+
+If a peer chooses to receive packets with zero-length connection IDs, an
+endpoint can always migrate - zero-length connection IDs provide no significant

```suggestion
endpoint can always migrate, since zero-length connection IDs provide no significant
```

-- 
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/2414#pullrequestreview-200417758

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 05 Feb 2019 21:29:59 -0800

janaiyengar 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/2414#pullrequestreview-200417781

---

From: Martin Thomson <[email-masked]>
Date: Tue, 05 Feb 2019 22:03:40 -0800

7c2660ecf7a11f42f7950615b9ad80ecdec8d280  Editorial fix

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2414/files/96b9fe88ce116bba073406d2f0ac65e02e37254f..7c2660ecf7a11f42f7950615b9ad80ecdec8d280

---

From: Mike Bishop <[email-masked]>
Date: Wed, 06 Feb 2019 11:58:20 -0800

MikeBishop requested changes on this pull request.

As noted in #2413, this PR permits something that's currently prohibited intentionally -- migrating with a zero-length CID. Do we have consensus to make that change?

If there's no CID and the packet is coming from an unknown remote address, how does the server know what keys to use to remove packet protection in that case?  We've previously said we need to avoid trial decryption, and that seems like the only option if migration is permitted.

-- 
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/2414#pullrequestreview-200775836

---

From: Martin Thomson <[email-masked]>
Date: Thu, 07 Feb 2019 18:38:25 -0800

fb9f6904c61e83188813376f8b6be1c09b622b82  No connection ID = no migration

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2414/files/7c2660ecf7a11f42f7950615b9ad80ecdec8d280..fb9f6904c61e83188813376f8b6be1c09b622b82

---

From: MikkelFJ <[email-masked]>
Date: Fri, 08 Feb 2019 01:09:32 -0800

I think this strikes a good balance. It isn't practical to forbid migration without CID when NAT's do it behind your back, but allowing it for intentional migration would work against networks attempting to move towards safer modes of operation in the future, some which might only make sense if QUIC does indeed require new CID's on migration.

At some point with IPv6, NAT rebinding might be seen the same way as older insecure WLAN standards.

-- 
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/2414#issuecomment-461736782

---

From: ianswett <[email-masked]>
Date: Fri, 08 Feb 2019 16:23:22 +0000 (UTC)

> @@ -1853,7 +1853,9 @@ An endpoint also MUST NOT initiate connection migration if the peer sent the
 `disable_migration` transport parameter during the handshake.  An endpoint which
 has sent this transport parameter, but detects that a peer has nonetheless
 migrated to a different network MAY treat this as a connection error of type
-INVALID_MIGRATION.
+INVALID_MIGRATION.  Similarly, an endpoint MUST NOT migrate if its peer supplies

As I said on the list, I'm not a big fan of adding this 0-len CID restriction.

-- 
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/2414#pullrequestreview-201664446

---

From: Mike Bishop <[email-masked]>
Date: Fri, 08 Feb 2019 12:49:43 -0800

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/2414#pullrequestreview-201779299

---

From: Mike Bishop <[email-masked]>
Date: Fri, 08 Feb 2019 12:50:26 -0800

MikeBishop commented on this pull request.

Not adding; linking to #2441 where this separate issue will be discussed.

-- 
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/2414#discussion_r255230974

---

From: Mike Bishop <[email-masked]>
Date: Fri, 08 Feb 2019 12:51:08 -0800

-- 
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/2414#discussion_r255231176

---

From: ianswett <[email-masked]>
Date: Fri, 08 Feb 2019 12:58:44 -0800

> @@ -2089,15 +2091,19 @@ different local addresses, as discussed in {{connection-id}}.  For this to be
 
-This 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
+Endpoints MAY move to a new connection ID at any time.
+
+An endpoint MUST use a new connection ID if it initiates connection migration,
+unless the peer has selected a zero-length connection ID.  Using a new

Above we say you can't migrate if you use a zero-length connection ID, so I don't understand the purpose of "unless the peer has selected a zero-length 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/2414#pullrequestreview-201782539

---

From: ianswett <[email-masked]>
Date: Fri, 08 Feb 2019 13:00:03 -0800

> -Endpoints that use connection IDs with length greater than zero could have their
-activity correlated if their peers keep using the same destination connection ID

This sentence seems duplicative of the paragraph above starting with "An endpoint MUST use 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/2414#pullrequestreview-201783064

---

From: Martin Thomson <[email-masked]>
Date: Sun, 10 Feb 2019 15:56:09 -0800

ac7f3818c75c1abac0c5f0068532cfd5dc636b3a  Remove text, thanks Ian

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 10 Feb 2019 17:18:46 -0800

Yep, trimmed it down.

-- 
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/2414#discussion_r255363486

---

From: ianswett <[email-masked]>
Date: Mon, 11 Feb 2019 13:18:18 -0800

ianswett approved this pull request.

One small suggestion, but I think this LG.

> @@ -2089,15 +2091,18 @@ different local addresses, as discussed in {{connection-id}}.  For this to be

Nit: move to may not be clear.  How about "Endpoints MAY change the Destination Connection ID they send in short header packets at any time." assuming that statement is correct.

-- 
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/2414#pullrequestreview-202342025

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Feb 2019 14:00:58 -0800

c95b96835c50b65abcf913744bd187ebbd92523e  Ian's suggestion, tweaked

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

---

From: ianswett <[email-masked]>
Date: Mon, 11 Feb 2019 22:25:55 +0000 (UTC)

> @@ -2091,7 +2091,8 @@ different local addresses, as discussed in {{connection-id}}.  For this to be
 
-Endpoints MAY move to a new connection ID at any time.
+At any time, endpoints MAY change the Destination Connection ID they send to a
+value that has not been used on another path.

Much better.  Can this be "has not been used previously on this path or another path."?

-- 
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/2414#pullrequestreview-202371425

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Feb 2019 14:34:29 -0800

It's OK to reuse a connection ID that has been used on the same path.  Unless the goal is to avoid temporal linkability, but that's far less of a pressing issue, I think.

One thing I want to allow is alternating connection IDs, which your suggestion would prevent.

-- 
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/2414#discussion_r255722497

---

From: ianswett <[email-masked]>
Date: Mon, 11 Feb 2019 14:36:12 -0800

I'm happy with this PR, but can you explain why you'd want that?

-- 
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/2414#discussion_r255723013

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Feb 2019 14:39:56 -0800

I don't necessarily, but other have mentioned a desire to put multiple connection IDs on the same path.  This makes one connection look like multiple.

-- 
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/2414#discussion_r255724161

---

From: Mike Bishop <[email-masked]>
Date: Mon, 11 Feb 2019 16:53:55 -0800

Of course, you'd need your peer to do the same; otherwise, it's kind of pointless.

-- 
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/2414#discussion_r255759521

---

From: ianswett <[email-masked]>
Date: Mon, 11 Feb 2019 17:02:50 -0800

I'd rather just have multiple connections or in v2, one could use multipath to do this.  Alternating between CIDs on a single path seems like a recipe for problems because few will exercise this option and it has dubious value in my opinion.

-- 
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/2414#discussion_r255761246

---

From: MikkelFJ <[email-masked]>
Date: Mon, 11 Feb 2019 22:46:58 -0800

mikkelfj commented on this pull request.

If there is point to changing CID's on same path, then reordering can send packets with the old CID. I'm not sure there is, but it might have relevance to keep up with changes to router state. But I suppose a router will need to be able to track a CID forever if it keeps seeing it periodically.

-- 
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/2414#discussion_r255820990

---

From: erickinnear <[email-masked]>
Date: Tue, 12 Feb 2019 17:33:46 -0800

erickinnear approved this pull request.

Looks like good clarification, just one minor wording comment

It would probably be worth indicating that this is intentional migration, just to keep everything clear. Elsewhere I think we've said an endpoint must not "initiate" migration, since of course its peer may think it migrated due to a NAT. 

-- 
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/2414#pullrequestreview-202969444

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Feb 2019 17:50:11 -0800

c13a9f565df1fee1cbfe12cf17e2923fc5affeea  Initiate migration

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

---

From: Lars Eggert <[email-masked]>
Date: Tue, 12 Feb 2019 23:18:56 -0800

This seems to have consensus, tagging as such and reassigning.

-- 
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/2414#issuecomment-463086996

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 17 Feb 2019 21:30:13 -0800

Removing `has-consensus` tag as it needs to be canvassed on-list (and attached to an issue, not a PR).

-- 
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/2414#issuecomment-464590609

---

From: Lars Eggert <[email-masked]>
Date: Mon, 18 Feb 2019 01:41:00 -0800

I'm sorry if I misunderstood the new process, but I don't think your PR says that an issue **must** be discussed on the mailing list? Doesn't it say that the discussion can happen on the list **or** on the issue?

-- 
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/2414#issuecomment-464658938

---

From: Lars Eggert <[email-masked]>
Date: Mon, 18 Feb 2019 09:41:38 +0000 (UTC)

-- 
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/2414#issuecomment-464659165

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Feb 2019 17:35:52 -0800

@larseggert discussion can happen in either place, but we've always checked with the list before declaring consensus (which is what `has-consensus` records). In the currently operative process, that's happening (admittedly sporadically) after the drafts are published.

-- 
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/2414#issuecomment-464943648

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 18 Feb 2019 18:49:20 -0800

@mnot @larseggert : The associated issue is #2413 and there's been a [mailing list discussion](https://mailarchive.ietf.org/arch/msg/quic/goCZG8crQZ8bM_G1-OGm130kbpM).  There seems to be some disagreement on what needs to happen next.

Specifically, some folks think this PR is an editorial one, and some want to open up the issue as a design issue for discussion.

-- 
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/2414#issuecomment-464958522

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Feb 2019 22:08:26 -0800

#2413 is a design issue. If this is just editorial and no one disputes that, you can apply it as that, but it can't close #2413.

-- 
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/2414#issuecomment-464997880

---

From: Martin Thomson <[email-masked]>
Date: Mon, 18 Feb 2019 22:47:56 -0800

#2413 is only marked design because there is debate, therefore, I conclude that we need chairs to help us.  I requested that close to 2 weeks ago.

-- 
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/2414#issuecomment-465007227

---

From: Mike Bishop <[email-masked]>
Date: Mon, 25 Feb 2019 19:14:29 +0000 (UTC)

The requirement previously existed, but was accidentally dropped during one of the CID rewrites.  The underlying question is whether we had consensus to remove the requirement previously -- if so, then reversing ourselves requires consensus.  If not, then it's just fixing an accidental deletion.

-- 
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/2414#issuecomment-467142396

---

From: ianswett <[email-masked]>
Date: Mon, 25 Feb 2019 12:26:15 -0800

If the PR that removed it doesn't have a note about removing it, I'd consider it an accidental deletion(which is what I suspect).

-- 
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/2414#issuecomment-467169693

---

From: erickinnear <[email-masked]>
Date: Mon, 25 Feb 2019 21:49:18 +0000 (UTC)

I thought the overall requirement for changing CIDs was [still in the text](https://github.com/quicwg/base-drafts/issues/2413#issuecomment-460457572), so it doesn't seem like the issue is around adding/removing a requirement, but rather the rest of the accompanying text here? 
Otherwise, not sure how this isn't entirely editorial, since the main requirement is already in place. 

-- 
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/2414#issuecomment-467197215