Re: packet filters for NetBSD in the future

[matthew sporleder <msporleder%gmail.com@localhost>]

On 2/13/09, Quentin Garnier <cube%cubidou.net@localhost> wrote:
> On Fri, Feb 13, 2009 at 10:07:09AM -0500, Thor Simon wrote:
>  > 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?
>
>  Another advantage pf had over ipfilter was binary compatibility with
>  previous releases.  However, it is no longer true.
>
>  At this point I think the inconvenience is that we don't have any
>  packet filter maintained in our tree.  Having one of them maintained
>  would be an improvement regardless of the qualities each of them has
>  over the other.
>
>  So if someone would step up and offer to maintain either one, that
>  would be a very strong reason to keep the relevant filter instead of
>  the other.
>
>  The thing that worries me is that people might be afraid to step up
>  because they know they'll have to deal with a bunch a vocal people
>  that will go at length explaining that the other filter is a lot more
>  important to have in NetBSD, and that it's scandal that NetBSD is
>  taking such a direction, etc.  Such is the reality of the NetBSD
>  community.
>
>  So let me assure that if someone was to step up and show that they have
>  the time and motivation to maintain either one, they'd receive my
>  strongest support.
>

Doesn't a lot of this simply rehash the old arguments about generic
interfaces for competing packet filters, classifiers, queuers,
slowdowninators, zimbapiladors, etc?

http://mail-index.netbsd.org/tech-net/2003/06/27/0013.html
http://mail-index.netbsd.org/tech-kern/2005/07/01/0011.html
http://mail-index.netbsd.org/current-users/2005/09/22/0021.html