FW: New Denial of Service Attack ...
Dan Kohn (email@example.com)
Wed, 25 Sep 1996 11:01:36 -0700
>From: Hans-Werner Braun
>Sent: Wednesday, September 25, 1996 9:10 AM
>Subject: FW: New Denial of Service Attack ...
>Sent: Tuesday, 24 September, 1996 22:52
>To: firstname.lastname@example.org; email@example.com
>Subject: Re: New Denial of Service Attack ...
>----- Begin Included Message -----
>Subject: Re: FW: Latest attacks....
>Date: Thu, 19 Sep 1996 08:39:02 +0100
>From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
>this just in on your trusty end2end research group's list (sorry, i
>know some of you may already read it)
>this guy is usually technically excellent, so i think we can trust
>that this solution is valid, will propagate, and is deployable for
>server sites that worry (you only need kernel reconfig rights for unix
>to add this - NT and MAC servers may have a tad more of a problem:-).
>------- Forwarded Message
>Date: Wed, 18 Sep 1996 14:32:14 -0600
>From: firstname.lastname@example.org (Vernon Schryver)
>Subject: SYN bombing defense
>As reported here, in article
>in comp.protocols.tcp-ip, Robert Morris
>>Perhaps TCP's listen queue should use random early drop (RED), a
>>technique used by routers to prevent any one source from monopolizing
>>a queue. See http://www-nrg.ee.lbl.gov/floyd/abstracts.html#FJ93 or
>I've just hacked IRIX 6.3 to do random-drop when sonewconn() in
>tcp_input.c fails. It works great! An IP22 receiving 1200 bogus
>SYN's per second directed to port 23 continues to answer requests
>for new telnet as if nothing is happening.
>I don't think that random <<Early>> drop is necessary or desirable.
>It is not as if we're trying to drop packets early to trigger
>slow start in the sources.
>As I figure it, as long as the length of the queue is longer than RTT
>of the real telnet client times the rate of bogus SYNs, the real
>clients have an excellent probability of getting through on their
>first attempt. For example, at 1200 bogus SYNs/sec and the IRIX 6.3
>telnet listen queue of 383, there should be no trouble with peers
>with RTT up to about 300 milliseconds. I've tested with a telnet
>client 250 milliseconds away while simultaneously bombing the machine
>from nearby with ~1200 SYNs/sec, and see no telnet TCP retransmissions.
>Vernon Schryver, email@example.com
>------- End of Forwarded Message
>----- End Included Message -----