On Tue, 09 Jan 2007 10:37:18 +0000 Gavin McCullagh <gavin.mccullagh@xxxxxxx> wrote: > 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 Actually, this paper seems to be a zombified version of: http://www.cs.ucsd.edu/~savage/papers/CCR99.pdf > 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. 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. 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. -- Stephen Hemminger <shemminger@xxxxxxxx> - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
