On Fri, May 06, 2005 at 12:37:42PM -0400, Jason Dixon wrote:
>
> PF uses a method called "skip steps" to only compare
> against rules that are relevant.
for people curious on how to write the ruleset to be more amicable
to skipsteps ( eg - in such that is it not "fragmented", if you'll
excuse the term, or otherwise is setup to have a minimum logical
number of skips as it's parsed ), perhaps see line 1182 in:
/* $OpenBSD: pf.c,v 1.487 2005/04/22 09:53:18 dhartmei Exp $ */
i could be reading it wrong, but i've been using that order as a
guide when writing the ruleset.
back to OT, as far as to answer the question of "why start with block",
and also leading into what the thread has turned into, being a
discussion about "use quick for all rules or not"; in general, i would
suggest that it matters only in so far as to say which philosophy will
ensure the maintainer{,s} of the ruleset are able to most effectively
maintain it?
in general, trying to not sound too much a twit, it seems to just boil
down to that. which one clicks best with the natural groove of the
person/people editing the rules.
many times, people haven't seem to have gotten the impression about
openbsd as i have. to me, it seems that evidence abounds that
the people responsible for the everything are much better at being
responsible for the everything than my dumb ass self who has not
submitted probably any more than 200 lines of diffs to the cause is.
to say that it is a guilty-until-proven-innocent scheme, i believe,
is to not see the whole picture. rather, if you're smarter and
correcter than the System (eg: those who have made the System), then
you've probably either:
A) quietly worked around the problem yourself (fixed privately)
B) submitted a diff (fixed publically)
for some, the performance boost of using 'quick' becomes very
valuable. i know of an ISP who had soekris boxes acting as
routers for up to 300 people a pop. a combination of factors
led to the discovery that, at least at that time i knew of it,
it was appropriate to run these statelessly. the pf.conf
was rendered out via python, and was quite long. it was very
simple, but it was very many lines of simple things. in this
circumstance, 'quick' helped a lot.
the supposition that one needs 'quick' for performance reasons
is justified with a wee soekris running stateless with -le 8
rules for each of -le 300 people; but many times it seems people
are just enchanted with the idea of ++FASTARR, regardless
of anything else other than it sounds ++FASTARR.
i guess what i am babbling about is that for all cases where
one has empirical data showing the results of ~identical
rulesets, one using 'quick' and one not, the "do we need it"
gray area is ~eliminated. in the absence of such data,
it is a matter of taste/style and nothing more than what
the monkey at the typewriter will be able to fix more quickly
when he breaks it.
me personally? i hate first-match. blech. but whatever,
it's just me personally.
> On May 5, 2005, at 8:43 AM, Jonathan Camenisch wrote:
>
> (since I intend to try to do things in a standard "pf way").
it feels to me that pf is built from the ground up to be last-match,
with a maximized possibility to function in a first-match context.
jared
