From owner-freebsd-security Tue Jan 25 22: 6: 8 2000 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id DD6DD14A04; Tue, 25 Jan 2000 22:06:02 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id WAA10216; Tue, 25 Jan 2000 22:05:44 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id WAA77519; Tue, 25 Jan 2000 22:05:44 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id WAA28922; Tue, 25 Jan 2000 22:05:43 -0800 (PST) From: Don Lewis Message-Id: <200001260605.WAA28922@salsa.gv.tsc.tdk.com> Date: Tue, 25 Jan 2000 22:05:43 -0800 In-Reply-To: <4.2.2.20000125113518.01a59100@localhost> References: <4.2.2.20000125095042.01a5aba0@localhost> <200001251722.KAA04527@harmony.village.org> <4.2.2.20000125113518.01a59100@localhost> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Brett Glass , Matthew Dillon Subject: Re: Merged patches Cc: security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Followups to -net only, please. On Jan 25, 11:52am, Brett Glass wrote: } Subject: Re: Merged patches } Switches also make the code more readable and make it easy to handle } every case. Some of the problems we're seeing in this code have been caused } by failure to account for some combinations of the TCP option flags. The best } way to ensure code correctness -- now and for the long term -- is to use } a construct that makes it easy to be sure you cover all the bases! It's } not only good style; it's good insurance. A switch based on the TCP flags would be a very unnatural implementation. For instance, most of the processing done on a packet received on an established connection is the same whether the FIN bit is set or not. If the switch expression was based on the flags, then a large part of the code would be duplicated between these two cases. Also, the code may do some processing on the segment, clear the SYN and/or FIN bits, and then continue. A implementation that used a switch based on the socket state would be somewhat more natural, but this is still not an exact fit. As a matter of fact, if you look at the implemention, this is pretty much what a lot of it does. switch (tp->t_state) { case TCPS_LISTEN: { ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message