From owner-freebsd-current Fri Feb 2 16:51:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA24071 for current-outgoing; Fri, 2 Feb 1996 16:51:34 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA24062 for ; Fri, 2 Feb 1996 16:51:19 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id QAA22113; Fri, 2 Feb 1996 16:49:09 -0800 From: "Rodney W. Grimes" Message-Id: <199602030049.QAA22113@GndRsh.aac.dev.com> Subject: Re: ip_fw ordering of rules.. To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Fri, 2 Feb 1996 16:49:09 -0800 (PST) Cc: phk@critter.tfs.com, nate@sri.MT.net, imb@scgt.oz.au, current@FreeBSD.org In-Reply-To: <199602022119.WAA23947@keltia.freenix.fr> from "Ollivier Robert" at Feb 2, 96 10:19:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk > > It seems that Poul-Henning Kamp said: > > It basically sorts so that the rule covering most addresses come first. > > > > It doesn't look at deny/pass in that context, so if you say: > > I'm coming a little bit late on the subject, but I think that we should > remove the sorting altogether. Sorting make the software do things you > don't expect (as in Poul-Henning's example). > > In that respect, anyone using ipfw can't afford the potential risk. > > > deny some specific port > > allow the rest > > > > It will come out as: > > allow everything > > a deny rule never used. > > Sorting access lists is *evil*. "Building Internet FIREWALLS", D. Brent Chapman and Elizabeth D. Zwicky, O'Reilly & Associates, Inc., pp173: "It Should Apply Rules in the Order Specified" You want your packet fileter to apply, in a predicatable order, the rules you specify for it. By far the simplest order is the order is which you, the person configuring the router, specify the rules. Unfortunately, some products, instead of applying rules in the order you specify, try to reorder and merge rules to achieve greater efficiency in applying the rules. This causes several problems: o Reordering rules makes it difficult for you to figure out what's going on, and what the router is going to do with a particular set of filtering instructions. Configuring a packet filtering system is already complicated enough, without having a vendor add additonal complications by merging and reordering rule sets. o If there are any quirks or bugs in the merging or reordering of rule sets (and there often are, because it's something that's very difficult for the vendors to test), it becomes impossible to figure out what the system is going to do with a given set of filters. o Most importantly, reordering rules can break a rule set that would work just fine if it had not been reordered. 3 more pages of samples showing why it is bad and evil to do this... then pp 176: You should make sure the packet filtering router you select doesn't reorder rule sets. Enough said??? Can we remove the sorting PLEASE?? -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD