Re: packet filters for NetBSD in the future

[yancm%sdf.lonestar.org@localhost]

> I am curious about the future direction of NetBSD with regard to packet
filtering.  Here is why:
>
> 1) An intention to replace ipfilter with pf has been announced, but:
>       * This appears to be largely on the ground that ipfilter is
>         unmaintained in our tree, and
>
>       * pf is also currently unmaintained in our tree.
>
> 2) pf is considerably simpler than ipfilter (mostly, it seems, because
it
>    is much newer and has less historical portability baggage).
>
> 3) We have third and fourth filter engines in our tree, the ipsec
security
>    policy engine and the altq classification engine.  This is clearly
redundant both in the source tree and at runtime (at runtime, doing
PFIL_HOOKS filters and then two other kinds of filtering can slow
things down considerably for little net gain).
>
>       * Itojun's intent was to unify the ipsec and altq filtering
>         using pf as the engine.  This is a large part of why pf is
>         currently in our tree, as I understand it.  Nobody has ever
>         done the analogous work to let ipfilter serve this role.
>
> 4) pf is essentially subsystem-locked by the softnet lock.  On the
>    other hand, ipfilter has much finer-grained locking because it can
run in other kernels which have pushed locks down into the network
stack.
>
> Given this set of facts, it's not clear to me what the right path
forward is.  #4 seems likely to be a considerable inconvenience in the
future if we go with pf.  On the other hand, ipfilter's author is a
NetBSD developer, but even he doesn't have time to maintain the version
in the NetBSD source tree (as far as I can tell) and it seems unlikely
that he or anyone else will step forward to address #3.
>
> Still nobody has stepped forward for the comparatively simple task of
updating and maintaining pf, either.
>
> What are others' opinions on this?

I'm not sure you wanted a mere user response to this, but...

I've been using NetBSD for 12 years and ipf for 10 years or so, I've
even helped track down an ipf bug or two in the past.

ipf is maintained as an independent package with it's own web sites and
mailing lists and is usable in several *nix systems as you say.  Darren
has been working on release candidates for v4.1.32. I've also
seen some talk of v5.0.x versions.

Darren occasionally updates the NetBSD version with his base code 
releases. My observation is that as he has gotten busier, this is less
frequent than in the past.

I've taken some stabs at updating my local source tree to his
updated base releases, but it's a bit too involved for my skills
and time constraints. It might be easier if we moved from a kernel
integrated code base to an LKM version. I tried to make that happen at one
time and again my limitations stymied me.

The ipf version in NetBSD_4_Stable (ipf v4.1.23) is outdated and
contains some regressions that are apparently addressed in NetBSD_5_Beta
(ipf v4.1.29). The particular issue is rules that include quick and
keep state don't work properly in 4.1.23... There are some workarounds
that only slightly reduce rule processing efficiency.

From what I can tell pf syntax and ipf syntax are pretty similar...
(I've wondered about the cross lineage between the two codes are,  but
basic googling did not yield anything for me...)

Because of the above issue I considered switching to pf and picking up 
ALTQ support, but translating and debugging the tools and scripts I have
also takes time I do not have, so instead I've just decided to upgrade to
the NetBSD 5 branch sooner than I otherwise might have.

In the long run, I suspect only Darren can maintain the ipfilter code. I
suspect it would be possible to run an SOC project to automate
integration of Darren's base releases into the kernel and userland,
possibly via conversion to LKM for the kernel side.
[This would be my vote at the moment]

Integration of the other aspects (ALTQ, etc.) you mention seems
unlikely given the complexity of the code and Darren's limited time.

--gene