Date: Sat, 8 Jan 2000 00:34:31 -0800 (PST) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: luigi@info.iet.unipi.it (Luigi Rizzo) Cc: patrick@mindstep.com (Patrick Bihan-Faou), logix@foobar.franken.de (Harold Gutch), freebsd-current@FreeBSD.ORG, nate@mt.sri.com (Nate Williams) Subject: Re: ipfw optimizations Message-ID: <200001080834.AAA14383@gndrsh.dnsmgr.net> In-Reply-To: <200001080808.JAA09575@info.iet.unipi.it> from Luigi Rizzo at "Jan 8, 2000 09:08:29 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001080834.AAA14383>