Date: Fri, 20 Sep 1996 15:12:43 +0930 (CST) From: newton@communica.com.au (Mark Newton) To: imp@village.org (Warner Losh) Cc: newton@communica.com.au, security@FreeBSD.org Subject: Re: comments on the SYN attack Message-ID: <9609200542.AA11812@communica.com.au> In-Reply-To: <199609200513.XAA26063@rover.village.org> from "Warner Losh" at Sep 19, 96 11:13:21 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9609200542.AA11812>