Subject: [quicwg/base-drafts] Bundle new client connection ID and path challenge in migration probes (#1730)

From: Christian Huitema <[email-masked]>
Date: Sun, 09 Sep 2018 11:43:58 -0700

During migration, the server will respond to the client's probe. If the client does not use a null length connection ID, the server needs to chose one of the destination connection ID specified by the client in "new connection ID" frames. There is however a synchronization issue. The client may have sent a new connection ID frame on another path, but that frame may not have yet been received when the probe arrives. The server is in a bind. It does not know whether the client sent a new connection ID or not. It does not know whether it should reuse an old ID and compromise privacy, or delay processing of the probe.

The synchronization issue is solved if the probe bundles NEW_CONNECTION_ID and PATH_CHALLENGE frames.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Merge pull request #5 from quicwg/master
  * Specifying use of new connection ID to avoid correlation

-- File Changes --

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

-- Patch Links --

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 09 Sep 2018 17:47:30 -0700

martinthomson requested changes on this pull request.

I think that the idea is good, but the first addition needs some tweaking.

> @@ -2074,6 +2074,9 @@ 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.
 
+When probing a new path, an endpoint may want to ensure that the response, if
+any, is sent to a specific connection ID. The endpoint achieves that by bundling
+NEW_CONNECTION_ID and PATH_CHALLENGE frames, in that order.

This implies that order is significant.  It also implies that bundling the two means that this specific connection ID will be used.  We've tried really hard to avoid special inter-frame dependencies like this.  PATH_CHALLENGE is special in the sense that the path it follows is relevant to its processing (which is a necessary evil), but this implies much more than that.  I think that rewording this to suggest that providing NEW_CONNECTION_ID ahead of PATH_CHALLENGE is useful (even necessary if the peer has run out, as they might have) and that having them in the same packet means that the NEW_CONNECTION_ID is guaranteed to be available.  Anything more than might give the wrong impression.

> @@ -2187,7 +2190,10 @@ usable for this connection.  Failure to validate a path does not cause the
 connection to end unless there are no valid alternative paths available.
 
 An endpoint uses a new connection ID for probes sent from a new local address,
-see {{migration-linkability}} for further discussion.
+see {{migration-linkability}} for further discussion. An endpoint that uses
+a new local address should include a NEW_CONNECTION_ID frame in the probe,

"SHOULD"? I don't think that we need to be this suggestive here, other than to note that lack of connection IDs will make probing - and responding to probes - impossible.

> @@ -2359,6 +2365,11 @@ 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.
 
+Endpoints could also have their activity correlated if their peers keep using
+the same destination connection id after migration. Nodes that initiate a

s/id/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/1730#pullrequestreview-153601031

---

From: Christian Huitema <[email-masked]>
Date: Sun, 09 Sep 2018 21:46:37 -0700

huitema commented on this pull request.

Agreed. I was being terse. That said, migration results in a new pair of <local cid>, <remote cid>. It would be really nice if the nodes could chose the ID by which they accept packets on the new 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/1730#discussion_r216196989

---

From: Christian Huitema <[email-masked]>
Date: Sun, 09 Sep 2018 21:56:52 -0700

Note that there is another issue in the same section. The text says that a packet containing PATH_CHALLENGE, PATH_RESPONSE, and PADDING frames is a "probing frame". Adding the NEW_CONNECTION_ID makes that a "non probing packet". I am not sure I fully get the consequences.

-- 
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/1730#discussion_r216197925

---

From: Christian Huitema <[email-masked]>
Date: Sun, 09 Sep 2018 22:02:23 -0700

@huitema pushed 1 commit.

efeb5fc  Attempt to incorporate Martin's suggestions

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

---

From: MikkelFJ <[email-masked]>
Date: Sun, 09 Sep 2018 22:20:00 -0700

mikkelfj commented on this pull request.

OTOH, if this PR is have any effect, it means that an endpoint must be prepared to process later frames in order to proceed. This is still an inter-frame dependency although ordering is relaxed. I think it needs to be made clear that this can happen (perhaps generally, not specifically here), otherwise an implementation may send frames in one order and a receiver fail to make use of that order.

-- 
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/1730#discussion_r216200004

---

From: Christian Huitema <[email-masked]>
Date: Sun, 09 Sep 2018 22:51:39 -0700

This is fixed. Please look at the new text.

-- 
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/1730#discussion_r216204122

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Sep 2018 04:31:02 -0700

@martinthomson pushed 1 commit.

34f056e  ensures

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1730/files/efeb5fc69e6f663e2f15ec1c133628b8171cfca4..34f056e23fb5fce59146fb065cfc05bb31958e89

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Sep 2018 11:31:41 +0000 (UTC)

martinthomson approved this pull request.

WFM

-- 
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/1730#pullrequestreview-153731335

---

From: ianswett <[email-masked]>
Date: Mon, 10 Sep 2018 14:01:00 +0000 (UTC)

ianswett commented on this pull request.

> @@ -2359,6 +2366,11 @@ genuine migrations.  Changing port number can cause a peer to reset its
 
+Endpoints could also have their activity correlated if their peers keep using
+the same destination connection ID after migration. Nodes that initiate a
+migration need to provide their peers with new connection IDs. The goal is

need is non-normative, which feels odd to me, and there's no mention of zero-length connection IDs.

-- 
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/1730#pullrequestreview-153787210

---

From: Christian Huitema <[email-masked]>
Date: Mon, 10 Sep 2018 09:30:30 -0700

@huitema pushed 2 commits.

a1ecc65  Adding more specific requirements per Ian's review
cac497f  Merge branch 'probe-cid' of https://github.com/huitema/base-drafts into probe-cid

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1730/files/34f056e23fb5fce59146fb065cfc05bb31958e89..cac497fcba75aed6ad72d155641201cd1e2acccf

---

From: Christian Huitema <[email-masked]>
Date: Mon, 10 Sep 2018 09:31:31 -0700

Yes. I rewrote that paragraph. Tell me what you think of the new version.

-- 
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/1730#discussion_r216388735

---

From: Christian Huitema <[email-masked]>
Date: Mon, 10 Sep 2018 09:34:04 -0700

6c018a6  Remove trailing white space.

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

---

From: ianswett <[email-masked]>
Date: Mon, 10 Sep 2018 09:35:45 -0700

LG in general, I wonder if this should be a bit stronger, particularly in cases the peer changes connection ID?

> @@ -2366,11 +2366,16 @@ genuine migrations.  Changing port number can cause a peer to reset its
 
-Endpoints could also have their activity correlated if their peers keep using
-the same destination connection ID after migration. Nodes that initiate a
-migration need to provide their peers with new connection IDs. The goal is
+Endpoints that use connection IDs with length greater than zero
+could also have their activity correlated if their peers keep using

nit: I think the "also" is unnecessary.

> @@ -2366,11 +2366,16 @@ genuine migrations.  Changing port number can cause a peer to reset its
 
-Endpoints could also have their activity correlated if their peers keep using
-the same destination connection ID after migration. Nodes that initiate a
-migration need to provide their peers with new connection IDs. The goal is
+Endpoints that use connection IDs with length greater than zero
+could also have their activity correlated if their peers keep using
+the same destination connection ID after migration. If a node receives
+packets through a newly used connection ID, it SHOULD select an

I'm wondering whether this should be a MUST in this case.  Not only are you migrating, but the peer has changed CIDs, which seems like strong evidence it's trying to limit linkability?

-- 
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/1730#pullrequestreview-153859041

---

From: MikkelFJ <[email-masked]>
Date: Mon, 10 Sep 2018 10:26:37 -0700

Yes, it would seem rather pointerless to change CID otherwise. Responding with an old CID is the same as the peer never changing CID. The only reason is running out of CID's and not being that sensitive to linkability. As we now, opting out voluntarily does not work well in crypto.

-- 
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/1730#discussion_r216406711

---

From: Christian Huitema <[email-masked]>
Date: Mon, 10 Sep 2018 10:53:15 -0700

5dacf5f  Remove extraneous "also".

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1730/files/6c018a60848ecdd33c4005eb77d1e33824edee9e..5dacf5f5c675268a6e0d02c1c35837423d539f71

---

From: Christian Huitema <[email-masked]>
Date: Mon, 10 Sep 2018 17:56:39 +0000 (UTC)

I understand that this could be stronger, but I am hesitant to put stronger words there without consensus. There is an obvious trade-off between privacy and performance. For example, should a server wait to answer a probe until a new connection ID is available? Maybe we could discuss this in NYC.

-- 
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/1730#issuecomment-420003425

---

From: Christian Huitema <[email-masked]>
Date: Mon, 10 Sep 2018 19:59:27 +0000 (UTC)

@mikkelfj the whole point of this PR is to say that and ensure that it works. Do you want to specify what the server should do if the client's probe arrives before a new connection ID is available? By your logic, we want to say that the server should wait before responding to the probe.

Then, do you want to enforce that? For example, suppose that a client sent a probe with a new CID, and receives a response with an already-in-use CID. Should it just shrug and continue, or signal a protocol violation? 

-- 
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/1730#discussion_r216453075

---

From: MikkelFJ <[email-masked]>
Date: Mon, 10 Sep 2018 13:21:21 -0700

Well, I hope that this PR fixes that so that the one case I outlined - running out of CID's become impossible, leaving only the don't care case which is not a strong enough of case for a SHOULD. If there are edge cases I think packets should be dropped or parked, otherwise the large volume of work on linkability is void. It could be that some adversary could delay packets to force linkability to happen.

-- 
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/1730#discussion_r216459197

---

From: MikkelFJ <[email-masked]>
Date: Mon, 10 Sep 2018 13:25:43 -0700

Or, you could just reply on the old path until you have a new CID. It might work, or it might trigger retransmission.

-- 
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/1730#discussion_r216460456

---

From: Christian Huitema <[email-masked]>
Date: Tue, 11 Sep 2018 20:34:10 -0700

Note that if endpoints really want to avoid correlation, they don't want a pattern in which the client sends packets from new address to new CID, but each packet triggers a response to old address and old CID. That too would be reasonably easy to observe. Yet that's probably what you get if the server does not want to use the new path yet and keeps sending data on the old path. I think that bundling the New CID with the client's probe solves that, or at least removes one of the reasons for the server to wait.

-- 
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/1730#issuecomment-420500873

---

From: Christian Huitema <[email-masked]>
Date: Tue, 11 Sep 2018 20:35:49 -0700

Responding on the old path is problematic too, because it causes correlation between new and old 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/1730#discussion_r216887849

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Sep 2018 23:30:09 -0700

86ecbec  Tweak probing text

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1730/files/5dacf5f5c675268a6e0d02c1c35837423d539f71..86ecbecca3eadb9eea70458b0f9794348161d7c8

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Sep 2018 23:40:23 -0700

17ccc69  reword, note the possibility of infinite regress

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1730/files/86ecbecca3eadb9eea70458b0f9794348161d7c8..17ccc69ecd0c652bc8f35c5db5fb3a37b0f7c67c

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Sep 2018 23:41:44 -0700

Merged #1730 into master.

-- 
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/1730#event-1840274580

---

From: Mike Bishop <[email-masked]>
Date: Fri, 14 Sep 2018 12:13:50 -0700

MikeBishop commented on this pull request.

The consequence is that you'd be initiating a change to the new path, and not just a probe.  I think we want to expand the definition of probing packets to include NEW_CONNECTION_ID as well.

-- 
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/1730#discussion_r217815549