Re: Potential design changes from IETF last call

[Martin Duke <[e-mail]>]

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 <[e-mail]> 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.
>
>