Date: Fri, 21 Jan 2000 15:31:10 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Alfred Perlstein <bright@wintelcom.net>, Brett Glass <brett@lariat.org>, security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <200001212331.PAA64734@apollo.backplane.com> References: <7192.948496931@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:In message <200001212311.PAA64559@apollo.backplane.com>, Matthew Dillon writes:
:
:> No, this is far too dangerous. If a packet is bad due to being
:> corrupted then you want to throw it away (via the checksum check)
:> *BEFORE* you start messing around with the socket state. Otherwise
:> a perfectly legitimate packet that got corrupted in transit may
:> cause a disconnect or other failure.
:
:It makes a lot of sense to do cheap (relative to the checksum)
:checks on the packet before we do the checksum, as long as we
:don't modify any state before the checksum is validated.
:
:If it is cheaper to try to locate the pcb, than to calculate the
:checksum, the locate the pcb first and drop the packet before
:doing the checksum.
In general principle I agree with you. But realistically speaking it
doesn't cost very much to checksum an IP packet, and most machines will have
100 BaseT which is *ONLY* 10 MBytes/sec in bandwidth. It doesn't cost much
to checksum 10 MBytes/sec. Moving the location of the checksum code is
not going to make a big difference compared to band-limiting the output
packets.
Band-limiting the output packets makes a huge difference, especially to
machines on HUBs. We are talking at least an order of magnitude here.
:a lot. We're trying to do the same thing here. The general
:fix for this entire class of DoS attacks is therefore the same
:thing: Toss out the packet as soon as possible, and as cheaply
:as possible.
:--
:Poul-Henning Kamp FreeBSD coreteam member
Except that this will not fix anything. You are saving yourself a small
amount of cpu -- not enough to matter, really, in an attack of this sort.
It may be worth doing this sort of patch after the release, but if the goal
of the release is to fix bugs then the proper solution is to use the one that
we know already makes a difference - restricting the output path.
I went through all this crap while at BEST, dealing with 80+ MBit attacks from
IRC weenies. That's why ICMP_BANDLIM was committed to the tree in the
first place and also why I didn't bother messing with the input path.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001212331.PAA64734>