1999-08-03-14:51:45 Bill Stackpole:
> There are two approaches to dealing with SYN floods. Support so many tcp
> connections that no one can send you enough open request to use them all.
> The other is to adaptively reduce the time-out for SYN requests based on
> the number of available connections that remain. In other words, I have 20
> connections available and a 30 second timeout. When I have only 8 conections
> available the timeout is reduced to 10. Only 3, reduced to 5, etc.
The first one (just support lots of half-open connections) was the solution
offered by most vendors in their first round of patches. I hadn't heard of
adaptively lowering timeout; that one sounds like it has the potential to be
at least mildly annoying, since it'll make TCP connection establishment
(successfully completing the famous "3-way handshake") substantially less
reliable while you are under heavy attack. Certainly would want to combine the
queue-size-dependant-delays with a greatly increased queue so it'll be way
harder to keep you nearly saturated.
Linux took a completely different approach, which is sorta nice; they call it
syncookies, and as I understand it you push the job of "remembering" that
there's a half-open connection back on the client. Rather than attempting to
keep some local memory of the half-open connection after you catch a syn, just
encode what you need to remember in a part of the syn/ack that will come back
to you in the following ack. If I remember aright.
Then there's Random Early Drop, favoured of the congention-control maniacs who
hack router designs and TCP protocol theory; I remember reading a very lucid
argument that Random Early Drop would preferentially toss the half-opens from
the synflooder in such a wonderfully great proportion that with a reasonably
large queue, synflooders would have a hard time making tcp connection setup
appreciably less reliable. This has similar characteristics to your strategy
#2, adaptively lowering the timeout.
-Bennett
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
