Date: Fri, 21 Jan 2000 22:49:24 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Brett Glass <brett@lariat.org> Cc: security@freebsd.org Subject: Re: stream.c worst-case kernel paths Message-ID: <20000121224924.B3730@fw.wintelcom.net> In-Reply-To: <4.2.2.20000121205951.01a58bb0@localhost>; from brett@lariat.org on Fri, Jan 21, 2000 at 09:02:11PM -0700 References: <200001212353.PAA64927@apollo.backplane.com> <7263.948497709@critter.freebsd.dk> <200001212353.PAA64927@apollo.backplane.com> <20000121194609.A19536@fw.wintelcom.net> <4.2.2.20000121205951.01a58bb0@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
* Brett Glass <brett@lariat.org> [000121 20:31] wrote: > At 08:46 PM 1/21/2000 , Alfred Perlstein wrote: > > >Please look at tcp_input, notice the "goto drop" and "goto > >dropwithreset" jumps, they are scattered throught and after some > >pretty close examination (no tests yet) I've been able to see that > >we can signifigantly move the tcp checksum farther into the path. > > One of the first things the routine does is look for a socket that > matches the TCP header. This relies on the port numbers and control > bits, which are covered by the checksum. This is the hard limit > on how long you can defer the checksum. You're wrong, many combinations of tcp header flags are invalid depending on the tcp connection's state, as well as other factors i'm sure exist, but have yet to examine. If we are under attack and not sending ICMP or RST back then why checksum instead of just dropping it? Either way it's an invalid packet. Btw, i'm not totally sold on the checksum idea, i'd just like to see the results of the change in cpu workload once I accomplish this. -Alfred 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?20000121224924.B3730>