From owner-freebsd-hackers@FreeBSD.ORG  Sun Feb 29 08:16:21 2004
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id B542D16A4CE
	for <freebsd-hackers@freebsd.org>;
	Sun, 29 Feb 2004 08:16:21 -0800 (PST)
Received: from mail.sandvine.com (sandvine.com [199.243.201.138])
	by mx1.FreeBSD.org (Postfix) with ESMTP id CAB2B43D2D
	for <freebsd-hackers@freebsd.org>;
	Sun, 29 Feb 2004 08:16:20 -0800 (PST)
	(envelope-from don@sandvine.com)
Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72)
	id <15P4579N>; Sun, 29 Feb 2004 11:16:19 -0500
Message-ID: <FE045D4D9F7AED4CBFF1B3B813C85337045D8313@mail.sandvine.com>
From: Don Bowman <don@sandvine.com>
To: 'Mike Silbersack' <silby@silby.com>,
	Don Bowman <don@sandvine.com>
Date: Sun, 29 Feb 2004 11:16:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
cc: freebsd-hackers@freebsd.org
Subject: RE: em0, polling performance, P4 2.8ghz FSB 800mhz
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Feb 2004 16:16:21 -0000

From: Mike Silbersack [mailto:silby@silby.com]
> On Sat, 28 Feb 2004, Don Bowman wrote:
> 
> > You could use ipfw to limit the damage of a syn flood, e.g.
> > a keep-state rule with a limit of ~2-5 per source IP, lower the
> > timeouts, increase the hash buckets in ipfw, etc. This would
> > use a mask on src-ip of all bits.
> > something like:
> > allow tcp from any to any setup limit src-addr 2
> >
> > this would only allow 2 concurrent TCP sessions per unique
> > source address. Depends on the syn flood you are expecting
> > to experience. You could also use dummynet to shape syn
> > traffic to a fixed level i suppose.
> 
> Does that really help?  If so, we need to optimize the syncache. :(

In a real-world situation, with some latency from the originating
syn-flood attacker, the syncache behaves fine.
In a synthetic test situation like this, with probably ~0 latency
from the initiator, the syncache gets overwhelmed too.