Re: Rationale for BSD (I)PF rule order?

["Bill Royds" <Bill () royds net>]

Is it not better to have a ruleset firing on closest fit?. Decide on which
rule to apply based on a nesting of address space (single hosts with subnets
within domains within interfaces, exact ports within port ranges etc.) and
match on protocol (UDP versus ICMP versus TCP etc.) Rules are made of tuples
similar to sockets, except that there are other possible dimensions added
(protocol, authenticated, un-authenticated, source interface, destination
interface, time of day, phase of moon etc.). Order of rule firing based on
textual order is always going to create problems.
If the firewall can generate this tree implied by nesting, then rul elookup
will be faster as well, since the maximum lookup is log(nesting factor) and
it can still be done with hash table lookup.


----- Original Message ----- 
From: "Mikael Olsson" <mikael.olsson () clavister com>
To: "Holger Kipp" <holger.kipp () alogis com>
Cc: "Volker Tanger" <volker.tanger () discon de>;
<firewall-wizards () honor icsalabs com>
Sent: Friday, May 09, 2003 3:08 PM
Subject: Re: [fw-wiz] Rationale for BSD (I)PF rule order?


:
: Holger Kipp wrote:
: >
: > For me it is easier to create a treelike strukture of rules using head
and
: > group and going from coarse to fine grained rules. With linear rules
(first match),
: > ordering of rules is more important, and with 20+ rules you get problems
with
: > side effects (rule 20 is never evaluated because rule 8 will fire first.
:
: Please.. I'm missing something. I feel I really must be missing
: something, because this is not making sense to me.
:
: Would someone _please_ tell me _how_ this differs from a last-match
: ruleset where rule 1 never does anything because rule 8 always
: overrides it?  Except for the first-match ruleset reaching the
: same wrong conclusion faster, that is?
:
: The way I see it, ordering is precisely as important in both cases.
: And you could even optimize a last-match ruleset lookup by making
: it lookup backwards and stop as soon as a rule triggers.
:
: Granted, mixed-mode lookups (i.e. using the "quick" keyword in a few
: places) could potentially get you out of trouble caused by a badly
: structured ruleset.  But mixing in too much of this, with a worst-case
: fustercluck of 50%/50% quick/non-quick, just strikes me as a disaster
: waiting to happen; especially so in a multiple-admin situation.
:
:
:
: -- 
: Mikael Olsson, Clavister AB
: Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
: Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
: Fax: +46 (0)660 122 50       WWW: http://www.clavister.com
: _______________________________________________
: firewall-wizards mailing list
: firewall-wizards () honor icsalabs com
: http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards