Linkability across new points of network attachment

[martinthomson]

A client that migrates to a new point of network attachment probably wants to use a new connection ID. But that attempt will result in linkability if the server doesn't also change. How do we manage that? One approach is to use the cid_immediate instruction. But clients need to be careful to include that instruction in every packet they send lest the server miss it.

QUIC takes a different approach, which is to number all connection IDs combined with a ratchet. If connection ID N is used by one endpoint, its peer has to use connection ID N or greater on that same network path.

[martinthomson]

The QUIC DT on this subject has come up with a different design:

1. you use a new connection ID when you observe a path change
2. endpoints need to provide their peers enough connection IDs that they shouldn't run out
3. when an endpoint stops using a connection ID, there is a new "retire connection ID" message that is used to signal that it is no longer needed
4. endpoints that receive this "retire connection ID" are expected to replenish the supply of connection IDs at their peer

[ekr]

Point (1) is sort of implicit in the text, and I agree we should add it.

Points (2)-(4) are about ensuring that the other side has enough CIDs. In QUIC, this is the server's job and there's no real way for the client to say that it doesn't have enough CIDs or tell the server how many. It can just say that it is done using some set of CIDs and this tells the server to send more, but the server has no idea how many. By contrast, the DTLS design is for the client to tell the server when it wants more CIDs and the server gets to retire them. ISTM that this is a more flexible design in that the server can change CIDs whenever it wants (e.g., for rekeying of the CID encryption key).

IIRC much of the motivation for the design with QUIC was not to have to interlock with the ACK, and in this respect the situation here is the same as with the KeyUpdate, which is that the QUIC design has the advantage that it doesn't need to interlock with the ACK to know when things have change. But that doesn't apply here for the same reason as with #63.

So I think my proposed resolution is just to add that you should change CIDs whenever you change paths and should request enough CIDs that you have a hot spare. I could imagine a way for the server to say what specific keys it wants to invalidate, but I'm not sure that's necessary. I do think we should enhance RequestConnectionId to have a count.

[ekr]

@ekinnear

[ekr]

@erickinnear

[erickinnear]

(Just noting my earlier thoughts here so they're saved somewhere)

Overall, only concern is around the rate at which you can send additional connection IDs to the peer vs. the rate at which you retire them. My understanding is that they are all retired at once, but need to be provided independently.
It seems like there could be situations, especially for a sender that needs to migrate rapidly (say away from and then back to some specific interface), where this leaves the sender without a CID to switch to.
Allowing multiple CIDs in the messages as in #65 looks like it generally resolves this.

Also noting that infinite looping in response to peer changes is covered by the sequence number.