fixing opt-ack DoS against TCP stack

fixing opt-ack DoS against TCP stack

[Gavin McCullagh]

Hi,

recently, a few of us came up with a novel (or so we thought) DoS attack
against TCP.  We spent some time implementing and testing it and found it
to work worryingly well.

It turns out that we are not the first to come across this attack.  Rob
Sherwood and colleagues in Maryland were a year or two ahead of us.  They
have published a paper entitled "Misbehaving TCP Receivers Can Cause
Internet-Wide Congestion Collapse".

	http://www.cs.umd.edu/~capveg/optack/optack-ccs05.pdf
	http://www.cs.umd.edu/~capveg/
	http://www.kb.cert.org/vuls/id/102014

Linux appears not to have implemented any fix for this vulnerability,
although Rob Sherwood wrote a patch against 2.4.24.

	http://www.cs.umd.edu/~capveg/optack/optack.patch

There seems to be a brief mention of it on the fedora-security list but I
can't find much discussion of it in linux circles otherwise.

	http://www.spinics.net/linux/fedora/fedora-security/msg00426.html
	http://www.securityfocus.com/bid/15468/

Is there some reason that this fix was not accepted or has this just
slipped under people's radars?  Should some fix not be implemented?  The
issue seems even more severe with the larger buffer sizes now in use.

Gavin

Re: fixing opt-ack DoS against TCP stack

[Gavin McCullagh]

Hi,

[ moving this to netdev as requested ]

On Tue, 09 Jan 2007, Stephen Hemminger wrote:

> Actually, this paper seems to be a zombified version of:
> 	http://www.cs.ucsd.edu/~savage/papers/CCR99.pdf

Thanks.  In fairness to them, the emphasis is slightly different, Savage et
al are more interested in improving a receiver's performance, whereas
Sherwood seems more interested in a DoS attack.  However...

> It is not clear that current Linux systems are prone to the attack for a
> couple of reasons. First, Linux does more counts packets not bytes so
> extra ack's would be ignored. Turning on ABC would also help.

The issue I'm raising is not as much how you could artifically increase
Cwnd by dividing ACKs or sending them early.  The issue as I see it is that
if the receiver doesn't send dup acks, the sender never backs off and may
eventually flood its own link.  As the receiver need only ACK the odd
packet, the amplification can be substantial.

As this issue is already moreorless solved (in the research sense), I'm not
keen to spend a lot of time writing it up.  So, here's a quick throw
together of a small example experiment I ran yesterday.

	http://www.hamilton.ie/gavinmc/drop_dupack_attack/

> Lastly, the patch looks like it could cause more problems. It probably would
> break some application and other non-attacking TCP stacks. For this case, IMHO
> we need to wait for more research. If you want to pursue the problem, it needs
> to go through the RFC process.

I must admit I didn't read the patch in detail.  As I understand it, the
fix should (in principal) be compatible with other TCP stacks who should
just see an odd extra dropped packet and react with a duplicate ack as
usual.

Gavin