> Below is an extract from a current set of packet filter rules I use to
> implement a firewall:
> 
> log in on le0 from any to any with ipopts
> block in log on le0 from any to any with short frag
> log in on le0 proto tcp from any to any port != 80 flags S
> block in log quick on le0 from 127.0.0.0/8 to any
> block in log quick on le0 from 128.250.132.0/24 to any
> pass in quick on le0 from any to 128.250.133.13/32
> pass in quick on le0 from 128.250.133.13/32 to any
> block in quick on le0 from any to any with ipopts
> pass in on le0 from any to any
> block in on le0 proto udp from any to 128.250.132.0/24
> block in on le0 proto tcp from any to 128.250.132.0/24 flags S
> block in on le0 proto icmp from any to 128.250.132.0/24
> 
> (quick = match and stop) - How easy would it be to write a BPF set of
> rules to do the same ?  The others are fall through and use the keyword
> at the start if it matches.

it's not entirely clear to me what all of your keywords means.

It seems to me that the above rules must be representable by another
set of rules, joined by conjunctions and disjunctions.  Given that,
and given that your matching primitives are translatable into BPF
primitives, your syntax should be convertable by a relatively simple
program.

The only significant different would be that logging would be done
different: in particular, the 'master's for input and output would
only control passing and blocking packets, not logging them; to log
them, you'd use a listener on a normal BPF device, set up to listen
on the "up-stream" (before blockage) side of the blocker.

I don't see how your "block quick" entries are different than they
would be if they were just "block" -- if i did, i could do a quick
conversion for you right now...

> I might also add, that it is possible, from the filters produced through
> what I've written, with not much effort to extract the filters from the
> kernel and present them back in a form which looks exactly the same as
> what you see above.  If you start using BPF (and decide to optimize your
> ruleset when you compile), then there is no guarantee of being able to
> redisplay it the same as it was before.  This isn't for debugging
> purposes (being able to view current filters), but more of a requirement
> of being able to view what is current upon demand.

Well, if you really want to, you could also store an unoptimized
version...

However, if i wanted to see what was really in the kernel, i think i'd
want to see the optimized version, but "whatever."

> Also, the above filtering takes into account that the packet is already
> an IP packet.  BPF code is usually produced for dealing with the entire
> packet present.

Determination of protocol type is just another conjunction or
disjunction to add on to the expression you're going to compile and
load.

It's as if you implicitly expressed "block in on le0 not ip", or
something.



I guess what i'm trying to say is that you've not convinced me that
your filter mechanism provides anything more than would a BPF
interface with syntactic sugar...


also, we still don't know a lot about your filtering implementation:

how _large_ is it?  i.e. how many lines of code?  how many bytes of
source?  how many bytes of object code?


chris