Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Jan 2000 15:11:06 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Alfred Perlstein <bright@wintelcom.net>
Cc:        Brett Glass <brett@lariat.org>, security@FreeBSD.ORG
Subject:   Re: stream.c worst-case kernel paths
Message-ID:  <200001212311.PAA64559@apollo.backplane.com>
References:  <4.2.2.20000120182425.01886ec0@localhost> <20000120195257.G14030@fw.wintelcom.net>

next in thread | previous in thread | raw e-mail | index | archive | help

:It's a pretty good analysis, besideds the improvements mentioned
:here i _really_ think we should be able to delay the checksum as
:far as possible, I've been playing with this for a bit and I'll
:see how far it can be safely moved.
:
:Doing a checksum on an invalid packet is not worth it, might as
:well take the packet at face value, allow it to drop out, and
:only when it's about to be accepted _finally_ take the hit and do
:the checksum.
:
:As far as limiting RST and ICMP I really believe it's time that
:such things are _on_ by default.
:
:-Alfred

    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.

						-Matt


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?200001212311.PAA64559>