From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 23:00:06 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4828316A4CE; Wed, 15 Dec 2004 23:00:06 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 934D243D2F; Wed, 15 Dec 2004 23:00:05 +0000 (GMT) (envelope-from kbyanc@posi.net) Received: from gateway.posi.net (adsl-63-201-91-37.dsl.snfc21.pacbell.net [63.201.91.37])iBFN0AMo031268; Wed, 15 Dec 2004 18:00:10 -0500 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (Postfix) with ESMTP id 3B50375E102; Wed, 15 Dec 2004 16:01:59 -0800 (PST) Date: Wed, 15 Dec 2004 16:01:59 -0800 (PST) From: Kelly Yancey To: Gleb Smirnoff In-Reply-To: <20041214130712.GA46386@cell.sick.ru> Message-ID: <20041215154837.C46745@gateway.posi.net> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Luigi Rizzo cc: Andre Oppermann cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 23:00:06 -0000 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/