From owner-freebsd-net@FreeBSD.ORG  Wed Feb 18 18:28:14 2004
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 18F5D16A4CE; Wed, 18 Feb 2004 18:28:14 -0800 (PST)
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id A8F6743D1D; Wed, 18 Feb 2004 18:28:13 -0800 (PST)
	(envelope-from wollman@khavrinen.lcs.mit.edu)
Received: from khavrinen.lcs.mit.edu (localhost.nic.fr [IPv6:::1])
	by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id i1J2SBDa028786
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256
	verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA);
	Wed, 18 Feb 2004 21:28:12 -0500 (EST)
	(envelope-from wollman@khavrinen.lcs.mit.edu)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id i1J2SBZA028783;
	Wed, 18 Feb 2004 21:28:11 -0500 (EST)
	(envelope-from wollman)
Date: Wed, 18 Feb 2004 21:28:11 -0500 (EST)
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Message-Id: <200402190228.i1J2SBZA028783@khavrinen.lcs.mit.edu>
To: Andre Oppermann <andre@FreeBSD.ORG>
In-Reply-To: <4034049A.906ACDB9@freebsd.org>
References: <20040218220230.GF47727@madman.celabo.org>
	<4034049A.906ACDB9@freebsd.org>
X-Spam-Score: -19.8 ()
	IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES
X-Scanned-By: MIMEDefang 2.37
cc: FreeBSD Security Officer Team <security-team@FreeBSD.ORG>
cc: freebsd-net@FreeBSD.ORG
Subject: Re: Fwd: [is this mbuf problem real?]
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2004 02:28:14 -0000

<<On Thu, 19 Feb 2004 01:34:34 +0100, Andre Oppermann <andre@FreeBSD.ORG> said:

>  - there seems to be no boundary on how many segments we keep in the
>    tcp reassembly queue

I'm not aware of any TCP implementation which ever had such a
limitation.  Perhaps all the others implemented something like that in
the past few years and we haven't kept up?  (I've certainly been aware
of the attack for at least five years if not ten.)

I think the right answer may be a combination of throwing stuff away
more aggressively and compacting what we keep.  (Since we are already
doing an m_pullup() on incoming TCP segments anyway, we should at a
minimum ensure that we don't waste a cluster on each tinygram,
although this obviously still has a pathological case.)

> Something like this is needed for TCP as well to cope with this kind
> of resource exhaustion attack.

I would hope it would be structured more like
`max_holes_per_reassembly_buffer'.

-GAWollman