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. -- Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "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