Subject: [quicwg/base-drafts] Don't change CID on peer CID change (#2145)

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 10:57:00 -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
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
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.
```

I don't remember this being what we agreed, and it's not necessary. You only need to change when you see a new path, not after a new CID. That's how we got rid of counting to infinity.

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 13 Dec 2018 11:50:35 -0800

I'm not sure it is always well-defined when you are on a new path and you risk accidental linkage. I believe this was the thinking behind this.

-- 
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/2145#issuecomment-447097901

---

From: Mike Bishop <[email-masked]>
Date: Thu, 13 Dec 2018 12:21:59 -0800

IIRC, @ekr is correct; we agreed to do this on peer address change.

- If you don't know you've been rebound and you reuse a CID, you've already linked yourself; the peer changing CID in response is pointless.
- If you either anticipate a rebinding or proactively change ports, and change both CID and address simultaneously, then it doesn't matter which of those triggers the peer to switch.
- If you switch CID without changing address, the address links you with fairly high probability anyway, so it doesn't really matter if the peer switches.

-- 
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/2145#issuecomment-447107827

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Dec 2018 16:06:24 -0800

The recommendation exists to avoid linkability across a non-migrating change in 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/issues/2145#issuecomment-447166423

---

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 16:31:49 -0800

I don't think that that's particularly useful, and it seems to create a bunch of new 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/issues/2145#issuecomment-447171240

---

From: janaiyengar <[email-masked]>
Date: Fri, 14 Dec 2018 17:57:38 -0800

My recollection is what @MikeBishop says.  I remember discussing that changing CID on both sides allows a flow to be broken up into flowlets, but if the address is the same on both sides, that's a pretty clear signal anyways. I am fine with requiring a change only if the peer's CID and address change.

-- 
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/2145#issuecomment-447527813

---

From: MikkelFJ <[email-masked]>
Date: Sat, 15 Dec 2018 03:07:54 -0800

>  but if the address is the same on both sides, that's a pretty clear signal anyways. I am fine with requiring a change only if the peer's CID and address change.

That is not sufficient because the client could be migrating from domestic wifi to mobile, to train wifi, while the server always sees the IP address of the load balancer.

-- 
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/2145#issuecomment-447560444

---

From: ekr <[email-masked]>
Date: Sat, 15 Dec 2018 05:17:19 -0800

In this case the LB and the server should be regarded as the same thing,
and it's the LB's job to convey that somehow.

On Sat, Dec 15, 2018 at 3:07 AM MikkelFJ <[email-masked]> wrote:

> but if the address is the same on both sides, that's a pretty clear signal
> anyways. I am fine with requiring a change only if the peer's CID and
> address change.
>
> That is not sufficient because the client could be migrating from domestic
> wifi to mobile, to train wifi, while the server always sees the IP address
> of the load balancer.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/2145#issuecomment-447560444>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1oQwz-CDVeYLTwd9HSiiPFxjWl1fjks5u5NgHgaJpZM4ZSOPm>
> .
>

-- 
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/2145#issuecomment-447567768

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 16 Dec 2018 21:10:39 -0800

FWIW, it helps when you have multiple connections coalesced onto a 5-tuple.

An endpoints rotates the sending CIDs of all the connections at once, and that triggers the peer to rotate all of it's sending CIDs at once. Then, it becomes very hard for an observer to track the individual connections.

-- 
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/2145#issuecomment-447724546