From owner-freebsd-hackers Tue Sep 24 23:30:33 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA20779 for hackers-outgoing; Tue, 24 Sep 1996 23:30:33 -0700 (PDT) Received: from pinky.junction.net (pinky.junction.net [199.166.227.12]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA20757 for ; Tue, 24 Sep 1996 23:30:31 -0700 (PDT) Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id WAA27461; Tue, 24 Sep 1996 22:43:45 -0700 Received: from localhost (michael@localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id XAA17636; Tue, 24 Sep 1996 23:24:38 -0700 Date: Tue, 24 Sep 1996 23:24:36 -0700 (PDT) From: Michael Dillon To: freebsd-hackers@freebsd.org cc: server-linux@netspace.org Subject: Random drop solves SYN flooding problems Message-ID: Organization: Memra Software Inc. - Internet consulting MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ------- Forwarded Message Date: Wed, 18 Sep 1996 14:32:14 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Subject: SYN bombing defense As reported here, in article in comp.protocols.tcp-ip, Robert Morris wrote: >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 >rfc1254. > ... 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 <> 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, vjs@sgi.com ------- End of Forwarded Message