Subject: [quicwg/base-drafts] Mandate using a new connection ID on migration (#2413)

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

In fixing #2145, I discovered that we don't actually mandate this.  It's a privacy requirement that I thought we had previously agreed to, but it appears as though we missed capturing it properly.

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 04 Feb 2019 15:37:09 -0800

I do not think it is wise to prohibit connection migration, when there are no available connection IDs.  This is something that the client is fully capable of deciding for itself -- to migrate using an old connection ID or to reconnect instead.  I would go with MUST use, if there is one available.  Otherwise, privacy-conscious clients SHOULD reconnect.

-- 
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/2413#issuecomment-460457005

---

From: erickinnear <[email-masked]>
Date: Mon, 04 Feb 2019 15:39:45 -0800

It looks like it’s been moved around a lot, but 5.1.2 says

> As discussed in Section 9.5, each connection ID MUST be used on packets sent from only one local address. An endpoint that migrates away from a local address SHOULD retire all connection IDs used on that address once it no longer plans to use that address.

Historically, that’s been under the CID sections, not the migration sections, which made it kind of hard for me to dig up. 

Re the proposed diff: 
>An endpoint that exhausts available connection IDs can only
migrate if the peer chooses to use receive packets with zero-length connection
IDs.

Does that conflict at all with the below text in 5.1?

> An endpoint whose peer has selected a zero-length connection ID MUST continue to use a zero-length connection ID for the lifetime of the connection and MUST NOT send packets from any other local address.

-- 
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/2413#issuecomment-460457572

---

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

Thanks for finding that @erickinnear.  That supports the change being editorial-only.

As for the perceived conflict, yeah, the text is not ideal.  I'll find some way to reword it.  Perhaps by observing that you can never run out of zero-length connection IDs.

@igorlord, allowing a peer to exhaust connection IDs to maintain linkability across migrations is an attack that I'd rather we not have.

-- 
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/2413#issuecomment-460459352

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 04 Feb 2019 16:38:32 -0800

> allowing a peer to exhaust connection IDs to maintain linkability across migrations is an attack that I'd rather we not have.

I'd not worry about the peer. But I would, indeed, worry about a man-on-a-side exhausting your reserve of connection IDs by pretending to initiate peer migration events.  So this is a valid concern.

Of course, a violation of this MUST is indistinguishable from NAT rebinding/tethering migration and thus is not detectable by the peer.  So this MUST is really just a recommendation.  It is a fine recommendation.

-- 
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/2413#issuecomment-460469971

---

From: David Schinazi <[email-masked]>
Date: Mon, 04 Feb 2019 16:51:39 -0800

I agree with @igorlord here. In Tokyo we decided we want to avoid MUSTs that can't be enforced, and in this case it's reasonable for some clients to value migration over non-linkability when they run out of CIDs.

-- 
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/2413#issuecomment-460472796

---

From: MikkelFJ <[email-masked]>
Date: Mon, 04 Feb 2019 20:59:24 -0800

> As for the perceived conflict, yeah, the text is not ideal. I'll find some way to reword it. Perhaps by observing that you can never run out of zero-length connection IDs.

The intent is clearly to disallow avoidable migration on empty CIDs. Not running out would suggest keep using it, which is wrong.

Otoh: if it is not required to use a new CID, it makes no sense to forbid empty CID, on 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/issues/2413#issuecomment-460513453

---

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

The problem with migrating with an empty CID is that the recipient can't identify which connection it should be considered for.  It's going to have to do trial decryption with the keys for all current 0LCID connections on that destination port if it wants to permit that.  (In fact, I'm fairly sure we previously had text that said if you couldn't match a packet to exactly one connection upon receipt, you had to drop it; that seems to have been removed.)  On a NAT rebinding, a server could say that if the IP matches and only the port has changed, it might still match a singular existing connection.

That's only safe if the server is using a unique port for each connection, which seems unlikely.

-- 
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/2413#issuecomment-461162070

---

From: MikkelFJ <[email-masked]>
Date: Wed, 06 Feb 2019 21:39:44 +0000 (UTC)

@MikeBishop Good point.

-- 
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/2413#issuecomment-461198242

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Feb 2019 21:48:53 +0000 (UTC)

Yes, I think that this was a mistake on my part.  Clearly, if there is no connection ID on outward-bound packets, migration is generally inadvisable.  I'll update the 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/issues/2413#issuecomment-461201267

---

From: Martin Thomson <[email-masked]>
Date: Thu, 07 Feb 2019 23:17:39 -0800

Closed #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/issues/2413#event-2126363507

---

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

Superseded by #2414, which does more, but does it better.

-- 
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/2413#issuecomment-461712859

---

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

Reopened #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/issues/2413#event-2147642733

---

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

We ought to leave this issue open, and let it be closed by PR #2414.

-- 
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/2413#issuecomment-464956077