Original text:
handshake.  An endpoint which has sent this transport parameter, but detects that a peer has nonetheless migrated to a different network MAY treat this as a connection error of type INVALID_MIGRATION.  Not all changes of peer address are intentional migrations.  The peer could experience NAT rebinding: a change of address due to a need to ensure that connections IDs they provide cannot be linked by any other entity. <del> This eliminates the use of the connection ID for linking activity from the same connection on different networks.  Header protection ensures that packet numbers cannot be used to correlate activity. This does not prevent other properties of packets, such as timing and size, from being used to correlate activity. </del>  <del> Clients MAY move to a new connection ID at any time based on implementation-specific concerns.  For example, after a period of network inactivity NAT rebinding might occur when the client begins sending data again. </del>  A client might wish to reduce linkability by employing a new connection ID and source UDP port when sending traffic after a period reset its congestion state (see migration-cc), so the port SHOULD only be changed infrequently. <del> 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. 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. </del>  9.6.

Reviewer comments:
Based on , which should merge soon.
I think this strikes a good balance. It isn't practical to forbid migration without CID when NAT's do it behind your back, but allowing it for intentional migration would work against networks attempting to move towards safer modes of operation in the future, some which might only make sense if QUIC does indeed require new CID's on migration. At some point with IPv6, NAT rebinding might be seen the same way as older insecure WLAN standards.
This seems to have consensus, tagging as such and reassigning.
Removing tag as it needs to be canvassed on-list (and attached to an issue, not a PR).
I'm sorry if I misunderstood the new process, but I don't think your PR says that an issue must be discussed on the mailing list? Doesn't it say that the discussion can happen on the list or on the issue?
NAME discussion can happen in either place, but we've always checked with the list before declaring consensus (which is what records). In the currently operative process, that's happening (admittedly sporadically) after the drafts are published.
NAME NAME : The associated issue is and there's been a . There seems to be some disagreement on what needs to happen next. Specifically, some folks think this PR is an editorial one, and some want to open up the issue as a design issue for discussion.
is a design issue. If this is just editorial and no one disputes that, you can apply it as that, but it can't
is only marked design because there is debate, therefore, I conclude that we need chairs to help us. I requested that close to 2 weeks ago.
The requirement previously existed, but was accidentally dropped during one of the CID rewrites. The underlying question is whether we had consensus to remove the requirement previously -- if so, then reversing ourselves requires consensus. If not, then it's just fixing an accidental deletion.
If the PR that removed it doesn't have a note about removing it, I'd consider it an accidental deletion(which is what I suspect).
I thought the overall requirement for changing CIDs was , so it doesn't seem like the issue is around adding/removing a requirement, but rather the rest of the accompanying text here? Otherwise, not sure how this isn't entirely editorial, since the main requirement is already in place.
Currently the section 5.1(URL) says: "An endpoint whose peer has selected a zero-length connection ID MUST continue to use a zero-length connection ID for the lifetime of the connection and MUST NOT send packets from any other local address." In practice, 0 length connection IDs are only expected to be used when the receiver's IP/port identifies the connection, because otherwise QUIC connections cannot survive NAT rebinding. Given 0 byte connection IDs are not a privacy concern, the only reason I've heard to prohibit this is that we want to ensure servers never use trial decryption to deal with explicit migration. I don't believe that's a compelling reason, given there are existing use cases such as Peer-to-peer(ie: WebRTC) where we might want to use 0-byte connection IDs, but supporting migration may also be valuable. And I don't think any even small-scale server is going to use trial decryption to handle migration due to the excessive CPU cost. There is already a transport parameter to indicate connection migration is not supported, so the peer should have a clear signal about whether they can migrate with a 0-byte CID.
I think I agree that we can remove MUST NOT, assuming that we would recommend (i.e. SHOULD) servers using 0-byte CID to set the disable migration flag.
The problem here is that any system that uses this capability (migrating while sending no connection ID), would be unreliable. To make it reliable, we would need to add signaling. Is this a feature you really need for QUICv1?
Oh, I see, the idea is to rely on DISABLE_MIGRATION. That is probably OK.
As a general piece of advice, I would not advise any endpoint(ie: server) receiving multiple connections on a given IP/port use 0 byte CIDs. And if a 'server' did want to do that, it should disable migration explicitly.
NAME Um, isn't it normal for servers (QUIC or otherwise) to listen on IP/port. Do you mean multiple connections from same client IP/port?
If servers want to terminate multiple connections on an IP/port(as is typical), they either should use CID lengths > 0 OR disable connection migration. If they use a CID length of 0, they need to expect that NAT rebinding is going to terminate the connection, but they may be ok with that.
... or these servers may be ok with sending PINGs as necessary.
If a connection receives a garbage packet, it can be easily rejected based on the (lack of / unknown) CID. Only someone on-path will be able to observe the CID in use, so only on-path attackers can make you attempt to decrypt garbage. If you use a zero-length CID, your CID is very easy to guess. The restriction on migrating means that an attacker must spoof the remote port and IP in order to perform this attack, which means being on-path, which brings zero-length connection IDs up to equivalent security. If we make this change, anyone can make you attempt to decrypt garbage packets. Are we sure we want that?
On that account, it should be a requirement that CID's are compared constant time, otherwise they are easy to guess anyway.
Discussed in Prague; flag for v2.
In fixing , I discovered that we don't actually mandate this. It's a privacy requirement that I thought we had previously agreed to, but it appears as though we missed capturing it properly.
I do not think it is wise to prohibit connection migration, when there are no available connection IDs. This is something that the client is fully capable of deciding for itself -- to migrate using an old connection ID or to reconnect instead. I would go with MUST use, if there is one available. Otherwise, privacy-conscious clients SHOULD reconnect.
It looks like it’s been moved around a lot, but 5.1.2 says Historically, that’s been under the CID sections, not the migration sections, which made it kind of hard for me to dig up. Re the proposed diff: >An endpoint that exhausts available connection IDs can only migrate if the peer chooses to use receive packets with zero-length connection IDs. Does that conflict at all with the below text in 5.1?
Thanks for finding that NAME That supports the change being editorial-only. As for the perceived conflict, yeah, the text is not ideal. I'll find some way to reword it. Perhaps by observing that you can never run out of zero-length connection IDs. NAME allowing a peer to exhaust connection IDs to maintain linkability across migrations is an attack that I'd rather we not have.
I'd not worry about the peer. But I would, indeed, worry about a man-on-a-side exhausting your reserve of connection IDs by pretending to initiate peer migration events. So this is a valid concern. Of course, a violation of this MUST is indistinguishable from NAT rebinding/tethering migration and thus is not detectable by the peer. So this MUST is really just a recommendation. It is a fine recommendation.
I agree with NAME here. In Tokyo we decided we want to avoid MUSTs that can't be enforced, and in this case it's reasonable for some clients to value migration over non-linkability when they run out of CIDs.
The intent is clearly to disallow avoidable migration on empty CIDs. Not running out would suggest keep using it, which is wrong. Otoh: if it is not required to use a new CID, it makes no sense to forbid empty CID, on migration.
The problem with migrating with an empty CID is that the recipient can't identify which connection it should be considered for. It's going to have to do trial decryption with the keys for all current 0LCID connections on that destination port if it wants to permit that. (In fact, I'm fairly sure we previously had text that said if you couldn't match a packet to exactly one connection upon receipt, you had to drop it; that seems to have been removed.) On a NAT rebinding, a server could say that if the IP matches and only the port has changed, it might still match a singular existing connection. That's only safe if the server is using a unique port for each connection, which seems unlikely.
NAME Good point.
Yes, I think that this was a mistake on my part. Clearly, if there is no connection ID on outward-bound packets, migration is generally inadvisable. I'll update the PR.
Superseded by , which does more, but does it better.
We ought to leave this issue open, and let it be closed by PR or by the chairs.
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.
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, NAME 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.
The recommendation exists to avoid linkability across a non-migrating change in connection ID.
I don't think that that's particularly useful, and it seems to create a bunch of new problems.
My recollection is what NAME 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
Looks like good clarification, just one minor wording comment I thought that we had agreed that an endpoint that intentionally migrates has to use a new connection ID on the new path. But I couldn't find any "MUST" in the spec that said that. On the off chance that this wasn't just a mistake and there was some good reason not to mandate this, I'm bringing the discussion here. I've opened a design issue: URL The change I'm proposing is here: URL

Revised text:
handshake.  An endpoint which has sent this transport parameter, but detects that a peer has nonetheless migrated to a different network MAY treat this as a connection error of type INVALID_MIGRATION. <ins> Similarly, an endpoint MUST NOT initiate migration if its peer supplies a zero-length connection ID as packets without a Destination Connection ID cannot be attributed to a connection based on address tuple. </ins> Not all changes of peer address are intentional migrations.  The peer could experience NAT rebinding: a change of address due to a need to ensure that connections IDs they provide cannot be linked by any other entity.  <ins> At any time, endpoints MAY change the Destination Connection ID they send to a value that has not been used on another path. </ins>  <ins> 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.  Header protection ensures that packet numbers cannot be used to correlate activity.  This does not prevent other properties of packets, such as timing and size, from being used to correlate activity. Unintentional changes in path without a change in connection ID are possible.  For example, after a period of network inactivity, NAT rebinding might cause packets to be sent on a new path when the client resumes sending. </ins> A client might wish to reduce linkability by employing a new connection ID and source UDP port when sending traffic after a period reset its congestion state (see migration-cc), so the port SHOULD only be changed infrequently.  <ins> An endpoint that exhausts available connection IDs cannot migrate. To ensure that migration is possible and packets sent on different paths cannot be correlated, endpoints SHOULD provide new connection IDs before peers migrate. </ins> 9.6.