Re: fixing opt-ack DoS against TCP stack

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