Don't change CID on peer CID change

[ekr]

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.

[mikkelfj]

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.

[MikeBishop]

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.

[martinthomson]

The recommendation exists to avoid linkability across a non-migrating change in connection ID.

[ekr]

I don't think that that's particularly useful, and it seems to create a bunch of new problems.

[janaiyengar]

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.

[mikkelfj]

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.

[ekr]

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 ***@***.***> 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 <#2145 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABD1oQwz-CDVeYLTwd9HSiiPFxjWl1fjks5u5NgHgaJpZM4ZSOPm> .

[kazuho]

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.

[mnot]

Tokyo:

MT has a PR that does just this.

[martinthomson]

That being #2414 (I'm closing #2413).

[ianswett]

This was closed by #2386