Date: Fri, 21 Jan 2000 19:34:47 -0700 From: Brett Glass <brett@lariat.org> To: Wes Peters <wes@softweyr.com>, Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Alfred Perlstein <bright@wintelcom.net>, security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <4.2.2.20000121193053.0198aec0@localhost> In-Reply-To: <388913CF.DE7F4B0B@softweyr.com> References: <7192.948496931@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
At 07:19 PM 1/21/2000 , Wes Peters wrote: > > 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. > >Except you may get a false match on a garbled packet, that just happened >to get garbled to match a different connection. The checksum is done >first to avoid such situations. Until the packet has been verified good, >none of the data in it can be trusted. Which checksum? The checksum for the header of an IP packet is distinct from the checksum of the TCP payload it may carry. So, once you've verified the checksum on the header, you CAN trust the source and destination addresses, option flags, etc. You just can't trust the payload yet. You can defer the TCP checksum until it's time to use the payload. --Brett 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?4.2.2.20000121193053.0198aec0>