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