Re: Why so many packet filters?

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Mon, Aug 15, 2016 at 3:08 PM, Paul Goyette <paul%vps1.whooppee.com@localhost> wrote:
> On Mon, 15 Aug 2016, Ryota Ozaki wrote:
>
>> First of all, bpf (bpfjit) is different from the others. bpf sniffs
>> raw packets on rx/tx in network device drivers (grep bpf_mtap) and
>> also allows to send raw packets directly via ifp->if_output
>> (e.g., ether_output). It doesn't provide pass/block filters that
>> the others provide.
>>
>> bpfjit is just an optimization option of bpf. So we don't need to
>> treat it individually.
>
>
> OK, that makes sense.
>
>> pf, ipf and npf provide pass/block functionalities (and more) at
>> hook points (grep pfil_run_hooks) in the network stack via pfil(9),
>> which realizes say firewall and NAT/NAPT. They provide similar
>> functions but unfortunately their functions aren't compatible and
>> cannot replace one to another easily, IIUC. (Someone would explain
>> details of the differences.)
>
>
> I would very much like to know the differences. Also, can you use more than
> one of them at a time?

I don't know why though, npf and pf cannot be enabled in a kernel
at the same time. ipf can coexist with either.

> Do they share to same "hook points" but
> try to install different action routines?

Yes. Each hook points has multiple actions as a list. Each action
is evaluated in order; if an earlier action handles a packet,
later actions won't be evaluated.

>
>> npf is a newer filter than the others and designed for multi-core
>> systems. So basically we recommend npf when one want to use one of
>> them newly.
>
>
> Other than "it's newer", are there any significant differences between npf
> vs pf or ipf?

npf can run in parallel between CPU cores; that's the significant
difference. Of course the benefit requires MP-ification of the
network stack first.

>
>> BTW should we mark pf and ipf deprecated in netbsd-8 as they aren't
>> well maintained nowadays?
>
>
> Well, ipf is sort-of OK, since we at least have a reasonably complete set of
> ATF tests, so if something breaks we should find out.

Sure, but ATF tests cannot catch some sort of issues, for example
PR 50629 and 50168. I mean we still need some efforts to keep ipf
stable really.

I'm worry if we have man power to keep three different similar
functions stable. Shouldn't we concentrate on npf?

> But pf doesn't seem
> to have any tests, so we'll never know if it breaks.  It sure would be nice
> to not have to maintain untested code.  :)

:)

  ozaki-r