Date: Wed, 18 Feb 2004 21:28:11 -0500 (EST) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: Andre Oppermann <andre@FreeBSD.ORG> Cc: freebsd-net@FreeBSD.ORG Subject: Re: Fwd: [is this mbuf problem real?] Message-ID: <200402190228.i1J2SBZA028783@khavrinen.lcs.mit.edu> In-Reply-To: <4034049A.906ACDB9@freebsd.org> References: <20040218220230.GF47727@madman.celabo.org> <4034049A.906ACDB9@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
<<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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402190228.i1J2SBZA028783>