tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: packet filters for NetBSD in the future

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

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.

Quentin Garnier - -
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

Attachment: pgpRLYx5xI4xO.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index