tech-net archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
packet filters for NetBSD in the future
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?
--
Thor Lancelot Simon
Coyote Point Systems, Inc. <tls%coyotepoint.com@localhost>
Millerton, NY, USA
Home |
Main Index |
Thread Index |
Old Index