Subject: Re: your packet filter thang...
To: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
From: Chris G Demetriou <Chris_G_Demetriou@LAGAVULIN.PDL.CS.CMU.EDU>
List: tech-kern
Date: 03/02/1995 12:56:37
> Of course, there would be
> problems; in particular, you would still have to impose an order on
> multiple filters from multiple user-land processes...or does BPF impose
> a restriction that makes that moot?

I feel that it's safe to say that there will be exactly one process
controlling the "master filters" for a given interface.  That process
will configure them, then go away.  if you want something
logging/watching packets in addition to blocking them, then start up
another process to do that, and tell bpf to apply its filter program
to the inputs _before_ they're passed through the blocker.

Normally bpf works like:

  le0 input -> bpf_{,m}tap -> ether_input
	       |         ^
	       |         \--\
	       |            |
	       \-> filters -/

with a similar flow of control for the output side.

There can be multiple filters, each for a /dev/bpf* device; if a
filter for a matches, the packet gets sent to its associated /dev/bpf*
device.


To do packet filtering via hacks to bpf, you'd have to rearrange
things so the input path looks like:

  le0 input -> bpf_{,m}tap -(if not blocked)-> ether_input
	       |         ^
	       |         \-----------------+<-- post-blocker filters -\
	       |                           ^       		      |
	       |       	       	       (if blocked)		      |
	       |                           ^    		      |
	       \--> pre-blocker filters -> blocker -(if not blocked) -/

with a similar flow of control on the output side.

There could be multiple pre-blocker filters, and multiple post-blocker
filters, each for a /dev/bpf* device, as before, allowing you
"before-blocker" or "after-blocker" packet-watching.

There could be exactly one blocker filter, and it matches, then the
packet is (blocked|allowed to pass) as specified by the filter.

note that a filter can be an arbitrarily complex entity; what you
would pass to BPF on the command line is "a filter."



One objection that i have to a packet filtering mechanism that's not
tightly integrated with BPF is that it's much harder (or perhaps even
impossible) to get access to packets on _both sides_ of the filter...

I also think (as i believe charles pointed out) that the blocking
itself is not necessarily coupled with (and should not be coupled
with, in the implementation) the watching/logging filters.  BPF
already exists to do stuff like logging, and i've yet to be convinced
that the correct way to do blocking is something other than an
adaptation of BPF.



chris