Subject: Potential design changes from IETF last call

From: "Martin Thomson" <[email-masked]>
Date: Wed, 04 Nov 2020 13:44:26 +1100

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.

---

From: Martin Duke <[email-masked]>
Date: Tue, 10 Nov 2020 12:10:24 -0800

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-masked]> 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.
>