From owner-freebsd-hackers  Fri Sep 27 13:56:00 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id NAA18119
          for hackers-outgoing; Fri, 27 Sep 1996 13:56:00 -0700 (PDT)
Received: from dream.demos.su (dream.demos.su [194.87.1.2])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA18062
          for <hackers@freebsd.org>; Fri, 27 Sep 1996 13:55:54 -0700 (PDT)
Received: by dream.demos.su id AAA00303;
  (8.6.12/D) Sat, 28 Sep 1996 00:55:25 +0400
To: Bill Fenner <fenner@parc.xerox.com>,
        Guido van Rooij <guido@gvr.win.tue.nl>
Cc: Paul Antonov <apg@demos.net>, hackers@freebsd.org
References: <96Sep27.133646pdt.177476@crevenia.parc.xerox.com>
In-Reply-To: <96Sep27.133646pdt.177476@crevenia.parc.xerox.com>;
    from Bill Fenner at Fri, 27 Sep 1996 13:36:38 PDT
Message-ID: <oFyy3JouB0@dream.demos.su>
Organization: Demos, Moscow, Russia
Date: Sat, 28 Sep 1996 00:55:24 +0400 (MSD)
X-Mailer: Mail/@ [v2.40 FreeBSD]
From: apg@demos.net (Paul Antonov)
X-NCC-RegID: su.demos
Subject: Re: patch against SYN floods (RED impl.)
Lines: 21
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In message <96Sep27.133646pdt.177476@crevenia.parc.xerox.com> Bill
    Fenner writes:

>Not only that, but it's relatively dangerous to use information supplied
>by the attacker as part of your "random" number.  For example, the attacker
>could vary his initial sequence number by tv_usec / 33 and keep the
>"random" number constant.

Yes, I agree that better random function is necessary. My own test flood
generator uses random seq's - it's too good :) Any ideas?

>The "oldest-drop" code in -current works well for moderate attack rates;
>a "random-drop" mode works better for a heavy attack.  The best thing
>would be an automatic switch based upon the rate of queue drops.

Mmm, I just tested - only 10 syns/sec bring down 2.2-current with default
listen() queue parameters, and even 100 doesn't do anything noticeable
with the above patch. 'oldest-drop' introduces too strong RTT discrimination.
No problem when you're on the same ethernet, but when you're at home ...;-)

-- Paul