Re: [tcpm] mitigating TCP ACK loop ("ACK storm") DoS attacks

[Neal Cardwell <[e-mail]>]

On Wed, Feb 11, 2015 at 5:39 AM, Jeremy Harris <[e-mail]> wrote:
> On 10/02/15 02:11, Neal Cardwell wrote:
>> This patch series mitigates such ack loops by rate-limiting outgoing
>> duplicate ACKs sent in response to incoming TCP packets that are for
>> an existing connection but that are invalid due to any of the reasons
>> mentioned above: sequence number (1), ACK field (2), or timestamp
>> value (3). The rate limit for such duplicate ACKs is specified by a
>> new sysctl, tcp_invalid_ratelimit, which specifies the minimal space
>> between such outbound duplicate ACKs, in milliseconds. The default is
>> 500 (500ms), and 0 disables the mechanism.
>
> Would it not scale better over different link speeds to use a
> packet-counting approach rather than a rate limit?   For example,
> output a dupACK only for alternate triggers.

In our case the most common problem was with a middlebox that was not
only (a) desynchronizing the endpoints' notions of the window, but
also (b) duplicating packets to a high degree. So sending a dupack
once per 2 or even once per 32 packets was not enough to break the
loop. If we had responded to one in every 64 incoming out-of-window
packets, that probably would have broken the DoS loop.

However, if we respond to only one in every 64 incoming out-of-window
packets then responses to legitimate traffic become too infrequent.
For example, if the out-of-window packets are zero window probes that
the remote endpoint is sending in an exponentially-backed-off fashion
(very common), then I'd imagine that responding to only 1 in 64
exponentially-backed-off window-probe packets means that the remote
endpoint is often going to give up and close the connection before
they ever get an ACK with a non-zero window.

As for different link speeds, two ACKs per second means we bound
outgoing dupacks to 1Kbit/sec, which is tolerable for most Internet
hosts. If we were to use a packet-counting approach, then with a
middlebox multiplying incoming packets there is no bound on the
outgoing bit rate of our dupacks, and we are more likely to overload
the remote host's link.

neal