Change:
connection migration before the handshake is confirmed, as defined in section 4.1.2 of QUIC-TLS. <del> An endpoint also MUST NOT initiate connection migration if the peer sent the "disable_migration" transport parameter during the 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. 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. Not all changes of peer address are intentional migrations.  The peer could experience NAT rebinding: a change of address due to a middlebox, usually a NAT, allocating a new outgoing port or even a new outgoing IP address for a flow.  An endpoint MUST perform path validation (migrate-validate) if it detects any change to a peer's address, unless it has previously validated that address. </del> <ins> An endpoint also MUST NOT send packets from a different local address, actively initiating migration, if the peer sent the "disable_active_migration" transport parameter during the handshake. An endpoint which has sent this transport parameter, but detects that a peer has nonetheless migrated to a different network MUST either drop the incoming packets on that path without generating a stateless reset or proceed with path validation and allow the peer to migrate. Generating a stateless reset or closing the connection would allow third parties in the network to cause connections to close by spoofing or otherwise manipulating observed traffic. Not all changes of peer address are intentional, or active, migrations.  The peer could experience NAT rebinding: a change of address due to a middlebox, usually a NAT, allocating a new outgoing port or even a new outgoing IP address for a flow.  An endpoint MUST perform path validation (migrate-validate) if it detects any change to a peer's address, unless it has previously validated that address. </ins> When an endpoint has no validated path on which to send packets, it MAY discard connection state.  An endpoint capable of connection

Discussion:
Remove connection error response to a packets from a different source address when an endpoint has sent , clarify an endpoints options when prohibited packets are received, rename to , and remove error code.
Re: The value of this TP, I tend to agree with NAME pretty much all of the machinery must be implemented whether or not the TP is sent. But agreed - let's discuss elsewhere, since I think this particular change is in pretty good shape now.
I think PR is fine, though I would had added an explicit explanation of when a server may consider sending thing TP (other paths are likely to either not work or be very inefficient) and what a client that needs to migrate to a new path should do (recheck DNS from the new path and reconnect).
The primary use case for disableactivemigration is that load balancing infrastructure cannot support any changes to the 4-tuple, intentional or otherwise. So in this case if a peer still changes its tuples, the packets may hit a a new server endpoint that doesn't have any existing state, and will generate a stateless reset? I'd like to hold consensus on this issue until this is clarified in the text.
NAME I think we got to the point where either (a) the packets miraculously get to the right place and then the endpoint can choose to either honor them or drop them or (b) they don't, in which case that's sad, but that's what happens when your infrastructure doesn't handle NAT rebinding or any other changes to the 4-tuple. In neither case do you want to close the connection with an error, in case someone else has injected a packet with a different source address. Note URL >21.8. Stateless Reset Oracle >Stateless resets create a possible denial of service attack analogous to a TCP reset injection. This attack is possible if an attacker is able to cause a stateless reset token to be generated for a connection with a selected connection ID. An attacker that can cause this token to be generated can reset an active connection with the same connection ID. Should you be in a situation where the client will accept your stateless reset for a connection that's active if someone spoofs a source address and the packet ends up on a server that has no state?

If that can happen, that seems like we should open a new issue, since that's something that can happen at any time (although seems to me to be pretty much covered by the text in 21.8). The point of this change is to be clear that the purpose of the TP is to instruct the endpoint sending the packets to not intentionally change its address or port, but that the server receiving the packets (if for whatever reason they still get there) needs to not close the connection if it sees that happening. It can drop the offending packets, or process them, but it's a problem if it does the previous behavior which was to close the connection.
NAME thanks for the detailed explanation. This looks good to me and I have no objections to consensus.
The mechanism for disabling migration might be clear, but it isn't clear what problems it addresses. Some more clarity on that would be useful. What I understand this to be intended for is server deployments that can't guarantee that packets from a new source address will be routed to the same server instance.
Having re-read the minutes from Tokyo, I would re-articulate the problem statement a bit. As you said, disable_migration is an indication from a server that the serving infrastructure cannot handle client address changes. I don't think there's any confusion on this purpose. The pending question IMO is what a server should do if it disables migration and then receives packets on the connection from a different address. NAME : Do you agree?
That sounds about right, but I draw two conclusions: There are some editorial improvements we might consider in light of this analysis. The pending question about what to do in those scenarios is complex, but the conclusion might just be a better explanation of the sorts of trade-offs that servers work on. As you imply, that might be editorial as well, but I suspect that we'll uncover ways in which conflicting interpretations of working group participants come to light.
Yes, that is what I had in mind as well. We may want to add some text around what a client might expect when it continues sending packets after switching networks to a server that has disable_migration set.
It is my understanding that "disablemigration set" means that packets sourced from a different IP or port are likely to be blackholed. Hence, the client SHOULD reconnect instead of attempting a connection migration.

As for the servers that specified "disablemigration", they are free to blockhole packets for migrating connections or to honor connection migration (after an ordinary path validation).
NAME yes that sounds about right, but we probably want to specify that a server that cannot validate a new source MUST blackhole packets from that source.
NAME sure, though this is what naturally falls out from the text. There is already explicit text that source address validation is a MUST before a server can use a new path.
It may also be due to implementations not implementing path migration logic or maintain the necessary state, or servers that wish to use 0-length CIDs.
Discussed in London: to be resolved together with
NAME are you working on a PR here?
NAME I am happy to give it a read, if you have a PR ready. Or I could propose my own if that would not duplicate your work. Let me know.
Section 9 "Connection Migration" has this text: How can an endpoint distinguish "a peer has nonetheless migrated to a different network" vs "a man-on-a-side attacker has resent/raced a packet from a different IP"? If this hinges on path validation, an insidious attacker can actually own the new IP and proxy packets with PATHCHALLENGE back to the client and resend packets with PATHCHALLENGE_RESPONSE from its IP.
Yeah, that seems like too simple a DoS. It sort of highlights the need to implement much of the migration machinery if you consider the risk of NAT rebinding. Unless you plan to only permit remote address changes based on a "same network" heuristic.
Tokyo conclusion: Remove the text... But then, with our answer to , the endpoint that disables migration and then subsequently receives a packet from a new source address has two choices: it can do the full path validation and proceed to use the same path it can drop the packet The consequence of the latter is that the connection will time out, which is awful, but if the endpoint architecture is such that routing to the same instance is not possible, then packets will be dropped anyway. We already require, for the purposes of stateless reset oracle defense, that where routing is not consistent, that stateless resets not be generated for these cases. An endpoint can't send a stateless reset here, because that would produce the attack in a different form - our existing text on defense against stateless reset oracles would prohibit that anyway.

We should perhaps rename the transport parameter to "disableexplicitmigration" or "disableactivemigration". Opened for clarifying this point.
Discussed in London: NAME to incorporate a resolution in or a separate PR
London: Also remove the error code, since it's no longer a protocol violation.
One editorial suggestion