From owner-freebsd-security Fri Jan 21 18:35: 7 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 22C70156D6 for ; Fri, 21 Jan 2000 18:35:04 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id TAA27787; Fri, 21 Jan 2000 19:34:48 -0700 (MST) Message-Id: <4.2.2.20000121193053.0198aec0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 19:34:47 -0700 To: Wes Peters , Poul-Henning Kamp From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Matthew Dillon , Alfred Perlstein , security@FreeBSD.ORG In-Reply-To: <388913CF.DE7F4B0B@softweyr.com> References: <7192.948496931@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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