From owner-freebsd-security Fri Jan 21 15:11:22 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 872971562E for ; Fri, 21 Jan 2000 15:11:15 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA64559; Fri, 21 Jan 2000 15:11:06 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 15:11:06 -0800 (PST) From: Matthew Dillon Message-Id: <200001212311.PAA64559@apollo.backplane.com> To: Alfred Perlstein Cc: Brett Glass , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <4.2.2.20000120182425.01886ec0@localhost> <20000120195257.G14030@fw.wintelcom.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :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