From owner-freebsd-security Sun Jul 8 17:39:16 2001 Delivered-To: freebsd-security@freebsd.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id AF49E37B403 for ; Sun, 8 Jul 2001 17:39:11 -0700 (PDT) (envelope-from cjc@earthlink.net) Received: from blossom.cjclark.org (dialup-209.245.140.126.Dial1.SanJose1.Level3.net [209.245.140.126]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id RAA15317; Sun, 8 Jul 2001 17:39:06 -0700 (PDT) Received: (from cjc@localhost) by blossom.cjclark.org (8.11.4/8.11.3) id f690d4D01640; Sun, 8 Jul 2001 17:39:04 -0700 (PDT) (envelope-from cjc) Date: Sun, 8 Jul 2001 17:39:04 -0700 From: "Crist J. Clark" To: Darren Reed Cc: cjclark@alum.mit.edu, Yonatan Bokovza , "'freebsd-security@freebsd.org'" Subject: Re: FW: Small TCP packets == very large overhead == DoS? Message-ID: <20010708173904.D307@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20010708132629.B307@blossom.cjclark.org> <200107082224.IAA08926@caligula.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107082224.IAA08926@caligula.anu.edu.au>; from avalon@coombs.anu.edu.au on Mon, Jul 09, 2001 at 08:24:28AM +1000 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jul 09, 2001 at 08:24:28AM +1000, Darren Reed wrote: > In some mail from Crist J. Clark, sie said: > > > > 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? > > So are most DoS attacks which have anything to do with sending large > numbers of packets. This is somewhat similar to ICMP smurf attacks > that are directed at broadcast addresses. A Smurf attack is asymetrical. The attacker sends out a very small number of packets and the amplifier network does the real work. So, attacker sends low volume of traffic, attackee gets drowned in a large volume, asymetric. Another thing I forgot to mention is that this is "unspoofable" in the sense that the TCP handshake needs to be completed for it to work. This also greatly reduces the risk. > [...] > > 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). > > Think TCP windows. Do I have to? *think* *ouch* I still don't see anything here that you couldn't do with "Daytona" TCP attack. This might be a way to make them worse. > > > 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). > > Yeah, enough for 64bytes of header options and 8 bytes of fragmented > data. Not what I'd call a "useful" minimum. How about the 576 byte (IIRC) value? It's not really a network MTU, but all host must be able to handle datagrams of that size. > [...] > > 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? > > PC's can only handle a set number of interrupts per second. Serving an > interrupt is fairly expensive. This attack decreases the efficiency of > the host in servicing interrupts in a dramatic fashion. The smaller > you can force the packets can be, the bigger the hit. Yeah, I understand it boils down to a packets/time issue. I still don't see how a high packet rate can be sustained. > In testing on my LAN, which is connected into a switch, the high packet > rate did not bother the switch (as it ought not to have) but it did the > boxes involved. It's not just about pumping more data through and > saturating the network, it's about causing the server to do more work > than it normally does in order to send the same amount of data. > > In this respect it's not primarily a network DoS attack, but a sytem > resources (CPU/interrupt servicing) DoS attack also. But I'd still like to see it done over the Internet rather than a LAN before anyone gets too excited. Although it might be something fun to mess with people on the LAN at DEFCON this weekend. -- 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