On Sun, Aug 22, 2004 at 12:18:15AM -0500, Alex X. Liu wrote:
> Did I miss any advantage of choosing the last matching rule?
First, pf can do both. Read pf.conf(5) about the 'quick' keyword:
quick
If a packet matches a rule which has the quick option set, this
rule is considered the last matching rule, and evaluation of subse-
quent rules is skipped.
So, if you prefer first-matching, just use 'quick' on all your rules,
which has the precise effect of making the entire ruleset
first-matching.
The question then splits into
a) Why does pf support both first- and last-matching?
As a matter of choice. With first-matching, you have to put the most
specific rules first, and the more generic rules last. For many people,
that's not the natural flow of thought when writing rulesets. With
last-matching, you put the more generic rules (how to deal with tcp in
general) first, and go into more detail later on (how to deal with
specific tcp ports). When I read a ruleset, I personally like going from
generic to specific as I read from top to bottom, but that's me. Some
people read from right to left, and that works for them.
The performance cost of last-matching (which does exist, as you point
out correctly) is insignificant in most real-life setups. An easy to
write and read (and therefore maintain) ruleset, which matches the
author's flow of thought, is much more important. If you have doubts,
you can easily convert one into the other, and compare performance.
Except for very extreme cases, you won't notice any difference.
b) Why is last-matching default?
Because pf's ruleset syntax is based on IPFilter's, and many of our
users were familiar with those semantics (which defaults to last-match).
The default is not meant to represent my personal preference (and not
yours, either), but the majority (or at least a large part) of all
users', simple as that :)
At worst, if you do prefer writing and reading first-matching ruleset,
you'll have to remember to add 'quick' to all rules, which should be
only a minor nuisance.
Daniel
