CID change still required in response to migration?

[tatsuhiro-t]

There are bunch of changes in migration recently, and they suggests that new CID is required only when endpoint sends a packet from new local address and an endpoint of migrating peer is no longer required to change its CID when sending a packet using new path as long as its local address does not change.

But there are several lines of text left to suggest that an endpoint changes CID:

   An endpoint that initiates migration and requires non-zero-length
   connection IDs SHOULD ensure that the pool of connection IDs
   available to its peer allows the peer to use a new connection ID on
   migration, as the peer will close the connection if the pool is
   exhausted.

   An endpoint can change the connection ID it uses for a peer to
   another available one at any time during the connection.  An endpoint
   consumes connection IDs in response to a migrating peer, see
   Section 9.5 for more.

Are they just remnants of old text and should be removed? or does changing CID in response to migration still a requirement?

[mikkelfj]

Changing CID in response to migration is a soft requirement since it cannot always be enforced since NAT rebinding might happen without endpoint interference. It can hurt privacy though.

CID changes can also happen without migration. One reason is for the peer to do so after an idle period because the risk of NAT rebinding is high. Another reason is to ensure CIDs do not get stale on long living connections since the peers routing infrastructure might regroup or move valid CID patterns to a new epoch. The last reason could perhaps be replaced by the proposed explicit retire prior to facility.

[tatsuhiro-t]

So what does implementation actually need to do in response to migrating peer?
Just keep using same CID or not? Use same CID to do path validation?
I know that peer can change CID at anytime it likes.

[mikkelfj]

The key principle is to not reuse a CID on a new path if it can be avoided. I'm not sure about the CID terminating if the pool is exhausted - in your quoted text. I think it may choose to do so (and is encouraged to do so) but I'm not sure it is required to.

Changing CID in response to a peers migration is therefore relevant but changing CID just because the peer changes CID is problematic because it might never end.

[tatsuhiro-t]

Thank you. I thought that new CID should be used on new path, but I couldn't find normative text for it now.
Other than quoted text, draft says new CID is required if endpoint migrates to new local address.

I remember the discussion of changing CID in response to CID change which is not required and sorted out with the recent PRs.

[erickinnear]

I think at one point we said "SHOULD change if the peer changes, but be careful not to loop". Otherwise it's pretty trivial to establish linkability, so everything is structured about trying to make sure you can do it, but not falling over too hard in the edge cases where you may not be able to.

[martinthomson]

We agreed that changing CID wouldn't trigger a change in response, but the only hard rule was "if you use a new path, use a new connection ID".

[erickinnear]

Ah, interesting. I thought you were still expected to attempt to change if you could.

[mikkelfj]

... if you know that you change path - but you don’t always know.

[mnot]

Is there an underling issue here, or has the question been answered?

[tatsuhiro-t]

I couldn't find the hard rule "if you use a new path, use a new connection ID" in the draft in clear manner.
What I found is endpoint MUST change CID when using new local address. It does not mention about change on remote address.

[tatsuhiro-t]

Background context for this issue:
In NAT rebinding test, quic tracker does not send any NEW_CONNECTION_ID.
My server implementation refuses to use new path because there is no new CID left and cannot verify new path assuming that new CID is required for new path.
But they say that using NEW_CONNECTION_ID for new path is not written in draft as requirement, so server should follow the new path.
If using new CID for new path is a requirement, quic tracker should send NEW_CONNECTION_ID.
If it is just a recommendation, server probably should use new path with same CID.

[larseggert]

I think the issue is that there are two types of migration: "Direct" migration, where an endpoint changes to a new path and it is in their interest to also change the CID (to reduce trackability), and "indirect" migration, i.e., NAT rebinding, where a middlebox changes the path for an endpoint in a way that they are unaware of and therefore cannot initiate a CID migration for. Both of there are valid, but they are slightly different.

Is it sufficient to clarify that for a direct migration, a CID change SHOULD happen, and for an indirect migration, it (generally) cannot, and that the peer must handle both?

[kazuho]

@larseggert I like the way you categorize migration.

Is it sufficient to clarify that for a direct migration, a CID change SHOULD happen, and for an indirect migration, it (generally) cannot, and that the peer must handle both?

Does that mean in practical sense that clients SHOULD change CID on direct migration, and that servers SHOULD respond to a CID change with a CID change?

Assuming that is what we are seeking, I think it might be a good idea to clarify using a non-RFC2199 term that is effectively what we recommend (I understand that we prefer talking about "endpoints").

[tatsuhiro-t]

Client doesn't change CID in indirect migration because it does not aware of it.
Regardless of direct or indirect migration, server knows the packet is coming from new path (new remote address and/or port).
So the question is server MAY/SHOULD/MUST change CID when sending a packet to new path.

Current draft says that it is MUST to change CID on direct migration:

An endpoint MUST use a new connection ID if it initiates connection migration.

[mikkelfj]

An option would also to keep MUST change CID on direct migration and add that a en endpoint SHOULD not reject a migration that doesn't change CID because it might be a valid indirect migration. An endpoint MAY, however, reject indirect migrations that do not change CID if this is privacy is considered more important than broad interop (this is controversial).

[mikkelfj]

Either way, I think it would be beneficial if the text has a section with clear definition of the terms "direction migration" and "indirect migration".

[larseggert]

@tatsuhiro-t bit when a server sees the client using a new path (because of a NAT rebind) the server is not the one initiating the migration

[martinthomson]

In reviewing this, I think we've messed up badly. We currently only mandate the use of a new connection ID for the initiator of a migration. A peer that responds to a connection migration has to change a connection ID if the initiator changed their connection ID.

An endpoint MUST use a new connection ID if it initiates connection migration. Using a new connection ID eliminates the use of the connection ID for linking activity from the same connection on different networks.

That needs to be fixed promptly. Then the concerns that @tatsuhiro-t raises here might seem less surprising.

@mnot, @larseggert, can we recategorize this as design? Thanks.

[mikkelfj]

In reviewing this, I think we've messed up badly. We currently only mandate the use of a new connection ID for the initiator of a migration. A peer that responds to a connection migration has to change a connection ID if the initiator changed their connection ID.

This has been discussed at length and while I tend to agree that this is not a good design, I believe things ended up as they are due to concerns about endless CID change loops. I think that can be prevented without too much complexity, but that argument was one of the drivers, as I recall.

[martinthomson]

The problem was that we over-rotated. Now we don't require any change on the responding endpoint's part, which means we have near-perfect linkability across migrations. I think that the proposed change is the minimal one we can mandate.

I might prefer to have something slightly better, but doing that without also flirting with the infinite loop was too hard.

[kazuho]

Agreed. IIUC, the only endpoint that "initiates" a CID change is the client, because only the client side that migrates (or probes) a new path. This is the case for SPA too.

Therefore, I believe that stating something along the lines of the following is sufficient: a server MUST respond with a new CID to a packet that has been received on a new path with a new CID.

[erickinnear]

I definitely agree that we should change this to require a change in response, it would be worth wordsmithing something that achieves this -- the PR is a good start. Differentiating by client/server might be interesting, although there appear to be two cases:

1. A CID change on a link without any address change.
2. A change in any part of address (IP/port)

We can talk about initiator/responder to migration rather than client/server and that might be a good approach (which is pretty close to what the PR does right now).

[MikeBishop]

I thought where we landed (in concept, not necessarily text) was that you MUST change CID any time you're using a different local or remote IP:port. That means the client MUST change if it knows it's migrating (new source address); the server will change in response because it's going to a new destination. The client SHOULD change if it has been quiescent and anticipates a NAT-rebind (i.e. uncertain about source address); if it actually got rebound, the server would change as well (new destination address). If it turns out the client didn't get rebound, then IP:port already correlate it; perhaps slightly better if the server rotates, but it's not required to.