> > 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) [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
