[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: packet filters for NetBSD in the future
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
> 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?
Main Index |
Thread Index |