On May 6, 2005, at 8:47 AM, John . wrote:

> Well, you surely don't want to sort the firewall rules because they're
> evaluated in order and showing them any other way implies a wrong
> interpretation.

Not always true.   There are (or at least were) firewall ruleset 
optimization engines (code)
that could safely re-order a ruleset.

As a trivial example, if a ruleset is setup to always drop packets to 
1.0.0.0/8, then a later rule to drop packets to 1.1.1.1/32 will never 
be reached, and can safely be discarded.

At the end of the day, rulesets are a language to  describe computation 
on a dataset (the network packets).   The original "netgate" firewall 
actually ran a little p-code engine (and in the end we build a compiler 
that would generate native instructions) that ran a "program" that
"interpreted" the packet.   The result of the computation determined 
the outcome of the packet
processing.   bpf (and probably pf) do something quite similar.

Most firewalls also have a look-aside cache of previous results.   If 
"this" packet matches
the input variables of some previous packet (srcip, dstip, srcport, 
dstport, protocol, etc),
and you know the outcome of running the ruleset on the previous packet, 
its much quicker
to just lookup what to do with the packet.

Its also possible (in theory) to use a remote firewall's ruleset to 
perform useful general-purpose computation, albeit slowly.   (Someone 
has already done something similar with
the TCP checksum.)

jim