Date: Sun, 8 Jul 2001 13:26:29 -0700 From: "Crist J. Clark" <cristjc@earthlink.net> To: Yonatan Bokovza <Yonatan@xpert.com> Cc: "'freebsd-security@freebsd.org'" <freebsd-security@FreeBSD.ORG> Subject: Re: FW: Small TCP packets == very large overhead == DoS? Message-ID: <20010708132629.B307@blossom.cjclark.org> In-Reply-To: <EB513E68D3F5D41191CA00025558810150D4EF@mailserv.xpert.com>; from Yonatan@xpert.com on Sun, Jul 08, 2001 at 02:54:53PM %2B0300 References: <EB513E68D3F5D41191CA00025558810150D4EF@mailserv.xpert.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 08, 2001 at 02:54:53PM +0300, Yonatan Bokovza wrote: > Hi, > This was just on bugtraq. > Is net.inet.tcp.min_mss the solution? To what problem? As I get to below, it is a symetrical DoS attack. As a general class, these are not a big threat. Darren... you came up with this? > -----Original Message----- > From: Darren Reed [mailto:avalon@coombs.anu.edu.au] > Sent: Saturday, July 07, 2001 18:47 > To: bugtraq@securityfocus.com > Subject: Small TCP packets == very large overhead == DoS? [snip] > What's this mean? Well, if I connect to www.microsoft.com and set > my MSS to 143 (say), they need to send me 11 packets for every one > they would normally send me (with an MSS of 1436). Total output > for them is 1876 bytes - a 30% increase. However, that's not the > real problem. My experience is that hosts, especially PC's, have > a lot of trouble handling *LOTS* of interrupts. To send 2k out > via the network, it's no longer 2 packets but 20+ - a significant > increase in the workload. The problem for the attacker is that he needs to be ACKing all of these segments. It may take more packets to move 2kB, but the packets are not going out any more rapidly than they would if we just asked for 50kB file (which also requires 20+ more packets without the change in MSS). > What's most surprising is that there does not appear to be a documented > minimum, just as there is no "minimum MTU" size for IP. If there is, > please correct me. The absolute minimum MTU for IP is 68 (RFC791). > Oh, so how's this a potential denial of service attack? Generally, > network efficiency comes through sending lots of large packets...but > don't tell ATM folks that, of course :-) Does it work? *shrug* It > is not easy to test...the only testing I could do (with NetBSD) was > to use the TCP_MAXSEG setsockopt BUT this only affects the sending > MSS (now what use is that ? :-), but in testing, changing it from > the default 1460 to 1 caused number of packets to go from 9 to 2260 > to write 1436 bytes of data to discard. To send 100 * 1436 from > the NetBSD box to Solaris8 took 60 seconds (MSS of 1) vs ~1 with > an MSS of 1460. Of even more significance, one connection like > this made almost no difference after the first run but running a > second saw kernel CPU jump to 30% on an SS20/712 (I suspect there > are some serious TCP tuning happening dynamically). The sending > host was likewise afflicted with a signifcant CPU usage penalty if > more than one was running. There were some very surprising things > happening too - with just one session active, ~170-200pps were > seen with netstat on Solaris, but with the second, it was between > 1750 and 1850pps. Can you say "ACK storm" ? Oh, and for fun you > can enable TCP timestamping just to make those headers bigger and > run the system a bit harder whilst processing packets! Was this done on a LAN. Anyone can DoS themselves locally by generating enough noise. This is a Denial/Degredation of Service attack. I do not believe it constitutes a major threat. Like so many such hypothetical DoS attacks, it is symetrical. That is, it causes just as much hardship for the attacker as the attackee. Yes, the machine being attacked needs to send out more packets, but the attacker needs to be responding with just as many ACKs[0]. If the attacker wants to generate lots of packets from the system being attacked, why not make just multple connections or try to do big downloads? What does this attack do that more straight forward attempts to consume the attacked machine's resources don't? [0] There actually are ways to make ACKing asymetrical, but that opens up a whole range of attacks of which this one is no more interesting or effective than the rest. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010708132629.B307>