Draft: draft-ietf-quic-transport

Commentary: As discussed in Tokyo , forcing your peer to change a connection ID is still possible , but we would require a change in port in order to effect that . . 
 I do n'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 . 
 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 . 
 IIRC , is correct ; we agreed to do this on peer address change . If you do n'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 does n'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 does n't really matter if the peer switches . 
 The recommendation exists to avoid linkability across a non - migrating change in connection ID . 
 I do n't think that that 's particularly useful , and it seems to create a bunch of new problems . 
 My recollection is what 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 . 
 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 . 
 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 . 
 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 . 
 Tokyo : 
 That being ( I 'm closing ) . 
 This was
Paragraph (version A):
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.  The goal 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.
Paragraph (version B):
Endpoints that supply connection IDs with length greater than zero
could have their activity correlated if their peers keep using the
same destination connection ID after migration.  To ensure that
packets sent on different paths cannot be correlated, endpoints
SHOULD provide with new connection IDs before peers migrate.  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.