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

["Zimmermann, Alexander" <[e-mail]>]

Hi all,

I discussed this patch a bit w/ Neal yesterday. It was not clear to me
(and maybe shame on me) that exist cases in which TCP sends an (DUP)ACK
in response to a pure ACK. Parts of this „problem“ belongs to RFC793
(see background below). It’s maybe a good opportunity to include some
text about this in RFC793bis.

BTW: Do we think as WG that 793bis is a good thing to do? And if the
answer is yes, why do we not start an adoption call?

Alex

> Am 10.02.2015 um 03:11 schrieb Neal Cardwell <[e-mail]>:
> 
> TCP DoS scenarios involving ACK loops (aka "ACK storms" or "packet
> wars") have come up previously on the TCPM list. For example, Anil
> Agarwal brought them up in the Nov 2013 TCPM thread "TCP mismatched
> sequence numbers issue"
> 
> I wanted to mention that our TCP team at Google has recently submitted
> a patch series for Linux that mitigates such attacks by rate-limiting
> the dupacks that are sent in response to out-of-window incoming
> packets. The code has been in use at Google and was recently merged
> into the official Linux "net-next" tree, which means that it should
> land in the next official Linux release.
> 
> The patch series summary can be browsed at the following URL:
> 
>  http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=f06535c599354816cfbc653ce8965804c7385c61
> 
> Below I'm including the cover letter summarizing the patch series, for
> convenience/reference.
> 
> We are interested to hear any feedback folks may have.
> 
> Thanks!
> 
> neal
> 
> ==============
> 
> tcp: mitigate TCP ACK loops due to out-of-window validation dupacks
> 
> This patch series mitigates "ack loop" DoS scenarios by rate-limiting
> outgoing duplicate ACKs sent in response to incoming "out of window"
> segments.
> 
> Background
> -----------
> 
> There are several cases in which the TCP RFCs specify that a TCP
> endpoint should send a pure duplicate ACK in response to a pure
> duplicate ACK that appears to be invalid due to being "out of window":
> 
> (1) RFC 793 (section 3.9, page 69) specifies that endpoints should
>    send a duplicate ACK in response to an ACK when the incoming
>    sequence number is invalid due to being outside the receive
>    window: "If an incoming segment is not acceptable, an
>    acknowledgment should be sent in reply".
> 
> (2) RFC 793 (section 3.9, page 72) says: "If the ACK acknowledges
>    something not yet sent (SEG.ACK > SND.NXT) then send an ACK".
> 
> (3) RFC 1323 (section 4.2.1, page 18) specifies that endpoints should
>    send a duplicate ACK in response to an ACK when the PAWS check for
>    the incoming timestamp value fails: "If .... SEG.TSval < TS.Recent
>    and if TS.Recent is valid ... Send an acknowledgement in reply"
> 
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm