https://github.com/quicwg/base-drafts/issues/4257 is the one issue raised during last call that seems to be headed toward normative changes that will affect implementations. I wanted to bring that here to ensure that people are aware of the problem, the proposal, and the discussion.
The problem is that in the latest draft (-32) a spoofed migration by an attacker can be used for an amplification attack. It's not a huge amplification factor (~20x is estimated), but it seems like the general view is that it is worth preventing. This was highlighted when we required that path validation uses packets padded to at least 1200 bytes to validate the path MTU. That change made the amplification factor more reliably large, but the potential for amplification was already a problem. The proposed solution to this is to ensure that endpoints (servers specifically) respect a 3x amplification limit in response to migrations. This is the same basic mitigation we already have for other cases where more data might be sent than received (handshake and connection close). This proposal is written up here: https://github.com/quicwg/base-drafts/pull/4264 There has been some debate about the performance implications of this mitigation. If an endpoint is unaware of a migration and sends a small packet, the amount of data they can receive in return is limited until path validation completes. Some people would like to have us recommend padding for packets that are sent in two cases as a defensive measure. The first is after migration; the second is after a period of idleness, where a NAT rebinding might occur. I'm not currently reading sufficient support for documenting performance optimizations along these lines.
