In some email I received from Chris G Demetriou, they wrote:
> 
> how is it implemented?  i.e. could you give me "implementation in a
> nutshell", and tell me why it's better than hacking something with
> BPF, or adding hooks for screend (which seems to be the standard
> thing to use, at least for BSDI), or something?

The IP packet filter implementation I've done works by adding a call
to "check" routing which returns either 0 or 1 (pass/block) in ipintr()
and ip_output().  Interaction with the packet filter is provided by a
set of ioctl's to add/delete/flush filter rules, examine filter
statistics and set flags.  The pseudo-device created in /dev (auto-
matically when it is loaded) also serves as a log device, so that
packets can selectively be logged from inside the kernel as they pass
through the filter.  Packets are logged in binary format, with
additional information about whether it passed/failed, interface it
was `on' and how big it is (all header information available is logged).
With an 8k `buffer' for this device, around 140 packets can be logged
before log entries start being lost (this is accounted for in the stats).
Packets are saved to the buffer in a circular fashion but if it ever
becomes empty, it resets itself to point to the start of the buffer.
I've tried to make the ruleset simple and general (with a BNF - I hope)
representation of the language I've implemented, providing the basis for
a very useful set of IP filters to be created.  By separating the
generation of the filters from the "device" itself, custom applications
can be created to add/remove rules through the use of ioctl calls which
have their own "filter language".

With consideration to BPF, without rewriting BPF, it doesn't provide
any facility to do anything other than filter packets.  If BPF were
to be used, then I assume you'd want to incorporate libpcap which is
being worked on at LBL.  To make it useful for firewalling, a mechanism
to log packets would need to be added as well as some sort of interaction
between kernel and user space.  From my understanding of the BPF, filters
are applied/loaded as a "whole set", rather than one at a time and are
compiled to work like this.

screend is nice, but slow for passing packets through.  A packet going
through the filter is moved out to a user process which examines the
packet and passes the result back to the kernel.  That doesn't seem to
me to be a very efficient way of doing packet filtering, unless you
deliberately want to slow things down.  screend also defragments packets
which is argueably not what it should be doing for packets which don't
have a final destination as being it.

In comparison with what's available, it's been designed to work as much
like the ruleset you'd expect in a router and give performance of about
the same, but provide a dedicated mechanism with which to filter IP packets
rather than messing around trying to work out what is and isn't needed of
other tools to create a working filterer.

darren

(does that answer your question(s) ?)