Date: Wed, 15 Dec 2004 16:01:59 -0800 (PST) From: Kelly Yancey <kbyanc@posi.net> To: Gleb Smirnoff <glebius@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] Message-ID: <20041215154837.C46745@gateway.posi.net> In-Reply-To: <20041214130712.GA46386@cell.sick.ru> References: <20041213124051.GB32719@cell.sick.ru> <20041213104200.A62152@xorpc.icir.org> <20041214015603.A75019@xorpc.icir.org> <41BEE0E7.BD2316EB@freebsd.org> <20041214130712.GA46386@cell.sick.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 14 Dec 2004, Gleb Smirnoff wrote:
> On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote:
> A> > Implementationwise, the kernel side is evidently trivial as the
> A> > original code already supports the idea of multiple chains. All
> A> > you need is to extend the struct ifnet with a pointer to the chain,
> A> > or use some other trick (e.g. going through ifindex) to quickly
> A> > associate a chain to the input (and possibly output) interface.
> A>
> A> Nonononononononononononononononononononononono.
> A>
> A> There MUST NOT be any firewall specific pointers or other information
> A> in struct ifnet or any other non-firewall private part of the kernel.
> A> Otherwise the entire independence we've gained with the nice and clean
> A> PFIL_HOOKS API goes down the drain. This MUST NOT happen again.
> A>
> A> The whole idea of the PFIL_HOOKS is to have independend and loadable
> A> firewall modules with different approaches, internal designs and so
> A> on.
>
> The whole idea of PFIL_HOOKS is to have independend and loadable firewall
> modules, which can be attached to different parts of kernel! There is no
> such requirement that, pfil hooks MUST be sticked to a single entry point
> in ip_input() and ip_output().
>
> Pfils attached to interface belong to interface, and thus should be stored
> in struct ifnet. This is the way it is done in per-interface filters.
>
> A> For example a way Gleb can get his way without any bickering from us
> A> is by creating his own gleb-firewall module using the PFIL_HOOKS API
> A> and put it into the ports tree for easy access, provided he doesn't
> A> modify the PFIL_HOOKS API (which he doesn't have to).
>
> I am not going to create a new firewall or change PFIL_HOOKS. I'm going
> to attach *the existing* pfil_hooks to a different place, to perform
> filtering with *existing* firewalls.
How about a generic per-interface pfil demultiplexer? That is, a module
that uses the existing pfil hooks to in turn call per-interface hooks.
As Luigi suggested earlier, it would be possible to use the interface
index to index an array private to the multiplexer's implementation.
If each element in this array had its own pfil_head, then the demultiplexer
could then call pfil_run_hooks() using that list. This would allow you
to have your per-interface hooks in a generic way without changing a line
of existing code. It could be entirely encapsulated in kld. Provided an
API to manipulate the per-interface pfil registration, you could even run
different filters on different interfaces.
You'de even have a chance of back-porting it to FreeBSD 5.x since you
won't be changing the ifnet structure at all.
Just a thought,
Kelly
--
Kelly Yancey - kbyanc@{posi.net,FreeBSD.org} - kelly@nttmcl.com
Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041215154837.C46745>