--8P1HSweYDcXXzwPJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Folks...

I have implemented a new packet filter and classification engine
called ZPC -- Zembu Packet Classifier.  It was implemented because
of some limitations in IP Filter which weren't going to be easy to
work around in IP Filter.

The ZPC uses the BPF virtual machine as the core of the filter engine.
This has several advantages:

	(1) Can use libpcap to compile rules using a tcpdump(8)-like
	    syntax.

	(2) Rules are parsed in userspace, thus making the kernel portion
	    of the filter engine completely protocol agnostic.  This also
	    means that filtering can be done easily at any point, allowing
	    the userspace rule compiler to adjust the rules for differing
	    protocol header offsets (due to e.g. link-layer headers being
	    present or not) -- libpcap already does this.  This makes it
	    very easy to do e.g. transparent filtering at a bridge, or to
	    filter out Appletalk packets on a certain network interface.
	    Also, to extend the filter's capabilities, all you have to
	    do is extend a userspace library (libpcap).

	(3) The filter engine is very small.

	(4) Provides a good starting point for synthesis of rules
	    into native object code for very fast rule processing.
	    This is a project that I've already started working on.

The (not yet fully implemetned) ZPC packet logging facility uses a
format that can be read with tcpdump(8) (the reason it's not fully
implemented yet is because I need to extend the pcap save file format
just a bit, and need to get in touch with the tcpdump.org folks about
this).

The ZPC also has a way to load arbitrary packet processing methods
into a filtering point and to apply them to a packet using filter
rules.  This can be used to implement "return ICMP error" or "return
TCP RST" types of packet blocking (see ipf.conf(5), look for
"return-rst", or to implement NAT.  The method feature is similar
in concept to the "call" mentioned in IP Filter's documentation,
although IP Filter does not appear to completely implement the
feature.

Some of these methods (such as the "return ..." and NAT) will be
written and contributed like the rest of ZPC (tho, NAT isn't the
highest on my list, but it will be done eventually).

Zembu Labs would like to contribute this to the NetBSD project.
Obviously there will be certain parts that we will keep to ourselves
(some of the more interesting "methods"), but the core and above
mentioned methods we'd like to have in the NetBSD mainline.  We also
plan on contributing the synthesis engine for the BPF virtual machine
when it's working on a processor type or two.

It's still a work-in-progress, but it is working and in use.  I also
know of a few NetBSD users (including "NetBSD in product" folks) who
are interested in using it.  Some day, other packet classifiers in
the kernel (like the IPsec policy lookup engine, or the classifier
in ALTQ) could be changed to use this classification engine (which
is more generic than the others).

Attached is a formatted copy of the zpcctl(8) manual page that
describes the configuration of the ZPC.

If there's consensus here that this would be a nice thing to have
in the tree, then I'll go ahead and commit it to -current (something
I'd like to do fairly soon).

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>

--8P1HSweYDcXXzwPJ
Content-Type: text/plain; charset=us-ascii
Content-Description: zpcctl(8)
Content-Disposition: attachment; filename=foo
Content-Transfer-Encoding: quoted-printable

ZPCCTL(8)               NetBSD System Manager's Manual               ZPCCTL=
(8)

N=08NA=08AM=08ME=08E
     z=08zp=08pc=08cc=08ct=08tl=08l - configuration utility for the Zembu P=
acket Classifier

S=08SY=08YN=08NO=08OP=08PS=08SI=08IS=08S
     z=08zp=08pc=08cc=08ct=08tl=08l [-=08-a=08a _=08f_=08a_=08m_=08i_=08l_=
=08y] [-=08-i=08i _=08i_=08f_=08n_=08e_=08t] create
     z=08zp=08pc=08cc=08ct=08tl=08l [-=08-a=08a _=08f_=08a_=08m_=08i_=08l_=
=08y] [-=08-i=08i _=08i_=08f_=08n_=08e_=08t] destroy
     z=08zp=08pc=08cc=08ct=08tl=08l [-=08-a=08a _=08f_=08a_=08m_=08i_=08l_=
=08y] [-=08-i=08i _=08i_=08f_=08n_=08e_=08t] enable
     z=08zp=08pc=08cc=08ct=08tl=08l [-=08-a=08a _=08f_=08a_=08m_=08i_=08l_=
=08y] [-=08-i=08i _=08i_=08f_=08n_=08e_=08t] disable
     z=08zp=08pc=08cc=08ct=08tl=08l [-=08-a=08a _=08f_=08a_=08m_=08i_=08l_=
=08y] [-=08-i=08i _=08i_=08f_=08n_=08e_=08t] flush
     z=08zp=08pc=08cc=08ct=08tl=08l [-=08-a=08a _=08f_=08a_=08m_=08i_=08l_=
=08y] [-=08-i=08i _=08i_=08f_=08n_=08e_=08t] load [-=08-d=08d] [-=08-D=08D]=
 [-=08-f=08f _=08c_=08o_=08n_=08f_=08i_=08g] [-=08-O=08O] [-=08-r=08r]

D=08DE=08ES=08SC=08CR=08RI=08IP=08PT=08TI=08IO=08ON=08N
     z=08zp=08pc=08cc=08ct=08tl=08l is used to configure the Zembu Packet C=
lassifier, a general pur-
     pose packet classification and filter engine.

     Classification and filter points are specified using the mutually excl=
u-
     sive -=08-a=08a and -=08-i=08i options:

     -=08-a=08a _=08f_=08a_=08m_=08i_=08l_=08y
             Specify the filtering point corresponding to the address family
             _=08f_=08a_=08m_=08i_=08l_=08y.  Valid address families are ``=
inet'' and ``inet6''.

     -=08-i=08i _=08i_=08f_=08n_=08e_=08t
             Specify the filtering point corresponding to the network inter-
             face _=08i_=08f_=08n_=08e_=08t.  The network interface specifi=
ed must be present on
             the system.

     If a filtering point is not specified, the default address family
     ``inet'' is selected.

     The following commands are available:

     create   Create the specified filter instance.

     destroy  Destroy the specified filter instance.

     enable   Enable the specified filter instance.

     disable  Disable the specified filter instance.

     flush    Flush the rules from the specified filter instance.

     load     Load rules into the specified filter instance.  The options to
              this command are:

              -=08-d=08d      Dump the rules to the standard output after p=
arsing
                      them.  This is useful if you suspect a bug in the rule
                      parser.

              -=08-D=08D      Like the -=08-d=08d flag, but also dumps the =
virtual machine
                      bytecode that is generated by the packet-matching com-
                      piler.

              -=08-f=08f _=08c_=08o_=08n_=08f_=08i_=08g
                      Load the rules from the file _=08c_=08o_=08n_=08f_=08=
i_=08g.  An argument of
                      ``-'' causes rules to be loaded from the standard inp=
ut.
                      If a file is not specified, the rules will be taken f=
rom
                      the file _=08/_=08e_=08t_=08c_=08/_=08z_=08p_=08c_=08=
__=08K_=08E_=08Y_=08._=08c_=08o_=08n_=08f, where _=08K_=08E_=08Y is the nam=
e of the
                      address family or network interface associated with t=
he
                      filtering point.

              -=08-O=08O      Do not run the packet-matching code optimizer=
.  This is
                      useful only if you suspect a bug in the optimizer.

              -=08-r=08r      By default, z=08zp=08pc=08cc=08ct=08tl=08l ap=
pends the rules to the current set
                      of rules already associated with the filtering point.
                      This option causes the new rules to replace the curre=
nt
                      set.

R=08RU=08UL=08LE=08E S=08SY=08YN=08NT=08TA=08AX=08X
     The rule syntax is based on the packet matching syntax used by the
     tcpdump(8) command.  In general, a rule has the following syntax:

     ACTION [MODIFIERS] [DIRECTION] [on _=08i_=08f_=08n_=08e_=08t] [match _=
=08e_=08x_=08p_=08r_=08e_=08s_=08s_=08i_=08o_=08n]

     The following actions are defined:

     pass    Pass the packet through the filtering point

     block   Block the packet (do not let it pass the filtering point)

     call _=08m_=08e_=08t_=08h_=08o_=08d
             Call the packet processing method _=08m_=08e_=08t_=08h_=08o_=
=08d.  The processing method
             may choose to pass or block the packet.  If the packet is to be
             passed, the method may also choose to allow further rule match=
ing
             to occur on the packet or to end rule processing on the packet.

     The following modifiers are defined:

     log     Log the packet that matched the rule.

     quick   Normally, the classification engine performs processing on the
             last rule that matches a packet.  This modifier causes a packet
             matching a rule to be processed immediately.  If futher rule p=
ro-
             cessing is requested (via the ``call'' action), any previously
             matched rules are forgotten, so that rules that may have match=
ed
             before the quick rule are not processed after all rules have b=
een
             checked.

     The following directions are defined:

     in      This indicates an inbound (network to host) packet.

     out     This indicates an outbound (host to network) packet.

     Note that if no direction is specified, the default is to consider both
     inbound and outbound directions.

     It is also possible to create sub-groups of rules that are processed u=
pon
     a match of the parent rule (regardless of whether or not the rule's ac-
     tion is taken).  The sub-groups are indicated using ``{'' and ``}''
     around the grouped rules.  Consider the following set of rules:

           # Block all ICMP except for certain ones that are
           # generally OK.
           block in match icmp {
                   pass match icmp[icmptype] =3D=3D icmp-echoreply or \
                       icmp[icmptype] =3D=3D icmp-echo or \
                       icmp[icmptype] =3D=3D icmp-unreach
           }

           # Immediately allow any packet corresponding to an
           # already-established TCP connection or any response
           # to a connection we are initiating.
           pass quick in match (tcp[tcpflags] & tcp-syn) =3D=3D 0 or \
               (tcp[tcpflags] & (tcp-syn|tcp-ack)) =3D=3D (tcp-syn|tcp-ack)

           pass in match tcp port 80

     In this example, any incoming ICMP packet will match the first rule, a=
nd
     will default to ``block''.  However, processing then continues in the
     braced rule sub-group, and ICMP ECHO RESPONSE, ECHO REQUEST, and HOST =
UN-
     REACHABLE packets are allowed through.  Note that even though the rule=
 in
     the sub-group does not have a ``quick'' modifier, rule processing stops
     at the end of the sub-group, and the rule immediately following the su=
b-
     group will not be tested.

     For complete details on the packet matching expression syntax (to be u=
sed
     with the ``match'' keyword), see the tcpdump(8) manual page.

F=08FI=08IL=08LE=08ES=08S
     /etc/zpc_KEY.conf
             Configuration file for the filtering point _=08K_=08E_=08Y.

     /dev/zpcctl
             Zembu Packet Classifier configuration device

S=08SE=08EE=08E A=08AL=08LS=08SO=08O
     bpf(4), inet(4), inet6(4), pcap(3), tcpdump(8), zpc(4)

H=08HI=08IS=08ST=08TO=08OR=08RY=08Y
     The z=08zp=08pc=08cc=08ct=08tl=08l command first appeared in NetBSD 1.=
6.

A=08AU=08UT=08TH=08HO=08OR=08RS=08S
     The Zembu Packet Classifier and the z=08zp=08pc=08cc=08ct=08tl=08l com=
mand were written by Jason
     R. Thorpe <thorpej@zembu.com> and contributed by Zembu Labs, Inc.

NetBSD                         December 23, 2000                           =
  3

--8P1HSweYDcXXzwPJ--