I've already said my bit in github, but I think there are non-obvious performance optimizations: that clients should send some full-size datagrams after a migration or after a long idle period (i.e. a possible NAT rebinding) to avoid getting limited by anti-amplification measures.
I originally proposed normative text, but given the objections, a non-normative sentence would be fine. For example "After an address migration, or long idle period (which may have triggered a NAT rebinding), a client might send more full-size datagrams than strictly necessary to avoid being limited by server anti-amplification measures" or something to that effect. On Tue, Nov 3, 2020 at 6:45 PM Martin Thomson <[email protected]> wrote: > 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. > >
