From owner-freebsd-current Sat Jan 8 0:34:57 2000 Delivered-To: freebsd-current@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 2A9AD15859 for ; Sat, 8 Jan 2000 00:34:54 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id AAA14383; Sat, 8 Jan 2000 00:34:31 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200001080834.AAA14383@gndrsh.dnsmgr.net> Subject: Re: ipfw optimizations In-Reply-To: <200001080808.JAA09575@info.iet.unipi.it> from Luigi Rizzo at "Jan 8, 2000 09:08:29 am" To: luigi@info.iet.unipi.it (Luigi Rizzo) Date: Sat, 8 Jan 2000 00:34:31 -0800 (PST) Cc: patrick@mindstep.com (Patrick Bihan-Faou), logix@foobar.franken.de (Harold Gutch), freebsd-current@FreeBSD.ORG, nate@mt.sri.com (Nate Williams) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > clnsrv "allow " tcp "" 43 "${tcp_nicname_c}" "${tcp_nicname_s}" > > clnsrv "allow " tcp "" 53 "${tcp_domain_c}" "${tcp_domain_s}" > ... > > ... on and on up to the 1024 and then a few splattered after that. > > looks like the search path can become extremely long!. Yes, on under powered routers I sometimes take a dump of ``ipfw -a'' and take a look at the counts and reorder the rules. Note that 95% of tcp traffic hits a rule before all of these that is ``tcp.... established'', so the only time we run down through the search is on a setup packet. Most of our routers running this have plenty of CPU power due to the demands of gated/bgp/ospf so this has not become an issue. I can always add a few skipto's as well that would speed things up if I needed to :-) ipfw add 5000 skipto 20000 tcp from any to any 22-113 > > > The single largest optimization would probably be a dispatch based on > > source or destination port, the latter being more prevelent. > > ok... dispatch on ports is easy to implement, easier than dispatch > on (masked) IP's. A Patricia tree might work well here, it would defanitly work well for any attempt to dispatch on masked IP's. > > I can't easily send out the actual IP firewall list, it may expose > > what ever router I grabbed it off of to an attack :-) > > understand -- this is why i just asked only about the structure of the > ruleset and the length of the longest search path. :-) Even a 50% loaded set of T-1's running the 300 rule set on an old Pentium-II 300 uses more CPU time doing bgp/ospf than it does doing the firewall rules :-) One thing has hit me about your implementation of this scattered rule set, nahhh.. shouldn't be a problem if done as pointers to rules, but the couting of packets and bytes must be done in the pre-exploded rule set. Also have you thought about adding a special interface device name to handle packets as they traverse ip_forward? I know Poul's or someone elses drawing of the H style firewall could be implemented if we had a way to apply rules as they traverse the ip_forward code and an easy way to expand your scheme to include that would be to add something like ``via fwd, in via fwd, out via fwd''. Note that I _think_ but am not certain that NAT tapping/injection occurs in ip_forward so this could be of benefit to those doing NAT. Anotherwords the full blown H style 2 interface firewall has 6 nodes: 1 2 | | | | 5--6 | | | | 3 4 Nodes 1/2 are the input/output of one interface, 3/4 are the input/output of the other interface and 5/6 are the input/output side of the forward/translator engine. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message