netdev - Re: fixing opt-ack DoS against TCP stack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-id: <20070111131908.GS31536@nuim.ie>
Date:	Thu, 11 Jan 2007 13:19:08 +0000
From:	Gavin McCullagh <gavin.mccullagh@...m.ie>
To:	netdev@...r.kernel.org
Cc:	David Malone <David.Malone@...m.ie>,
	Douglas Leith <doug.leith@...m.ie>
Subject: 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

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html