From owner-freebsd-security Thu Sep 19 22:46:42 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA04503 for security-outgoing; Thu, 19 Sep 1996 22:46:42 -0700 (PDT) Received: from psychotic.communica.com.au (gw.communica.com.au [203.8.94.161]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA04442 for ; Thu, 19 Sep 1996 22:46:34 -0700 (PDT) Received: from communica.com.au (newton@frenzy [192.82.222.1]) by psychotic.communica.com.au (8.6.12/8.6.9) with SMTP id PAA09059; Fri, 20 Sep 1996 15:13:16 +0930 Received: by communica.com.au (4.1/SMI-4.1) id AA11812; Fri, 20 Sep 96 15:12:44 CST From: newton@communica.com.au (Mark Newton) Message-Id: <9609200542.AA11812@communica.com.au> Subject: Re: comments on the SYN attack To: imp@village.org (Warner Losh) Date: Fri, 20 Sep 1996 15:12:43 +0930 (CST) Cc: newton@communica.com.au, security@FreeBSD.org In-Reply-To: <199609200513.XAA26063@rover.village.org> from "Warner Losh" at Sep 19, 96 11:13:21 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Warner Losh wrote: > However, my gut tells me that the random victum will give better > behavior than the shoot the oldest one. Oh? I believe that statistically speaking the two cases provide an identical chance of booting away an individual packet: Consider that the deterministic case is precisely equivalent to the random case with a pseudorandom number generator which just coincidentally always returns the identity of the oldest SYN packet... [ indeed, if you're looking at an individual packet, the present implementation is identical as well: it just "randomly" drops the "youngest" packet on the queue, ie: the one that has arrived at a time when there aren't enough resources to keep it ] > If you have a queue length of 1000, and can deliver 500 bogus SYNs in > the 200mS that it takes, then you'd have a 60% chance of not dropping > the good SYN (1 - .999 ^ 500 = 60%). If you can deliver 1000 bogus > SYNs in that time, then the deterministic method would have a 0% > chance, and the random method would have a 35% chance of surviving (if > bc on my machine for .999^1000 can be trusted). You're assuming that a SYN is going to spend all of that 200mSec in the queue (remember, I provided that number as an upper-bound for the purposes of discussion, not as an axiomatic interval symtomatic of catastrophic failure!). 1000 bogus SYNs in 200mSec is something that takes of the order of 200kbps of bandwidth to support. On a 200kbps channel, I'd be willing to wager that the vast majority of your SYNs are answered with SYN-ACKs (and thereby removed from this equation) within 50mSec or less, meaning that the oldest SYN would almost always be one with an unreachable return address. Keep in mind that this is making the attacker work a lot harder too - He only needs to send about five packets per second to keep queues congested under present implementations! By thowing away the oldest SYN, you're effectively extending the present algorithm by adding a variable-length timeout instead of a 75-second timeout. The size of that variable-length timeout is dependent on the demand being placed on your system. That dynamicism is biased to provide newly arrived legitimate SYNs a fair chance of survival before they're treated as bogus and thrown away due to high demand. Given that you'll end up throwing away good SYNs if you're short on resources anyway, I'd rather select which good ones get chucked on a best-efforts basis instead of a random basis. The only way you'd throw away a good SYN is if its source address was on the other side of a link that was so slow that it was indistinguishible from an unreachable host for the purposes of SYN-warfare. At that point, it becomes the "best choice" for droppage for a (relatively) good reason, rather than a random impulse. By throwing away a random SYN, you're effectively treating all packets as bogus until proven otherwise, *AND* creating the possibility that you'll randomly boot 'em up the arse before they've had a chance to provide you with that proof. Sure, if you look at a single packet in isolation after declaring that "all things are equal" then you'll probably give an individual packet a better chance of survival; But that approach ignores the fact that all things *aren't* equal, and that it is highly likely that the oldest packet in the SYN queue is there because the SYN-ACK has been dropped by a router because its destination is unreachable. > Given that SYNs are > retransmitted, then you'd be able to get after 2 tries on the average. I'd suggest that the deterministic solution would let you in on 1 try. Usually :-) You're implementation is also computationally expensive: Random numbers aren't cheap, and I wouldn't like to spend too much of my life calculating thousands of them per second... - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au