Date: Tue, 14 Dec 2004 13:07:20 +0300 From: Gleb Smirnoff <glebius@freebsd.org> To: Luigi Rizzo <rizzo@icir.org> Cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] Message-ID: <20041214100720.GA44948@cell.sick.ru> In-Reply-To: <20041214015603.A75019@xorpc.icir.org> References: <20041213124051.GB32719@cell.sick.ru> <20041213104200.A62152@xorpc.icir.org> <20041214085123.GB42820@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 14, 2004 at 01:56:03AM -0800, Luigi Rizzo wrote: L> > Again, this feature is not for all. This is for people who build complicated L> > routers on FreeBSD. It is not going to hurt standard host setups. L> L> Trying to summarise the discussion with a hopefully unbiased position: L> L> As i also said before, i agree that when the number of interfaces L> becomes large, managing ipfw lists can become difficult (though i L> see no way your technique can help without the assistance of scripts L> generating the actual lists for each interface making sure that the L> 'common' checks are in sync, etc.) L> L> Implementationwise, the kernel side is evidently trivial as the L> original code already supports the idea of multiple chains. All L> you need is to extend the struct ifnet with a pointer to the chain, L> or use some other trick (e.g. going through ifindex) to quickly L> associate a chain to the input (and possibly output) interface. Yes, except that it points not to a chain but to pfil_hook_head, so that the feature can be later extended to other filtering facilities. L> If i understand well (and this is an option i had not considered L> myself, but sounds very reasonable and is the key idea that L> convinced me!) you are going to make the feature L> mutually exclusive with the old firewall -- either you use L> the global chain for all interfaces, or you use the private L> chains. It remains open what to do if you have registered a L> private chain only on a few interfaces, but that's just a matter L> of defining a reasonable policy, e.g. fallback to the global chain L> or something like that. They are suggested to be mutually exclusive. But administrator can decide to do filtering on per interface basis and global filtering, too. We are not going to deny this, if someone needs this. In this case it will be filtered in this order: input interface 'in' filter global filter called from ip_input global filter called from ip_output output interface 'out' filter L> The additional iper-packet cost is effectively zero -- instead of L> accessing the chain through a global variable, you access it through L> a field of struct ifnet, which is already accessed a zillion times L> in the processing of the packet. L> L> In userland, it is equally trivial to add a new ipfw flag to select L> the interface/direction on which the command should operate. L> As a safety measure, I would recommend to dump, in ipfw's output, L> a warning message (disabled through another flag) all times L> the configuration has something inconsistent (e.g. some but not all L> interfaces have private chains registered, etc.) Filtering on all interfaces is not mandatory. L> Once you do the above, i don't see how users could be negatively L> affected by the change, either in performance or ease of use. L> L> I believe that one still needs the assistance of scripts to generate L> the private chains of rules making sure that they are all in sync etc., but L> this is a problem that exists for other packet filters as well. L> L> So, from my point of view, i say go ahead, post a short L> description of the feature and usage examples if mine above is L> not what you have in mind, and that should convince those who L> are reluctant too. Sure. I'm going to document this well. Several examples in /usr/share/examples is minimum. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041214100720.GA44948>