From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 13:16:54 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 CB71C16A4CF for ; Tue, 14 Dec 2004 13:16:54 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E18DF43D41 for ; Tue, 14 Dec 2004 13:16:53 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 26579 invoked from network); 14 Dec 2004 13:05:46 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2004 13:05:46 -0000 Message-ID: <41BEE7C5.CA51ED08@freebsd.org> Date: Tue, 14 Dec 2004 14:16:53 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20041213124051.GB32719@cell.sick.ru> <20041213104200.A62152@xorpc.icir.org> <20041214085123.GB42820@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <41BEE0E7.BD2316EB@freebsd.org> <20041214130712.GA46386@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: freebsd-net@freebsd.org cc: Max Laier 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: Tue, 14 Dec 2004 13:16:54 -0000 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(). PFIL_HOOKS is meant to be once on input and output per protocol and not per interface. That is the reason why there is the interface pointer in the argument list. > 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. Again, you are changing the way PFIL_HOOKS are called. > 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. The existing firewalls need to be modified anyway to be able to deal with per-interface hooks. They are not made for it. This makes your argument moot. But please hold on, I'm writing an email with a different proposed approach. Let's continue the discussion when all have read it. Give me a few minutes. -- Andre