Date: Tue, 14 Dec 2004 13:47:35 +0100 From: Andre Oppermann <andre@freebsd.org> To: Luigi Rizzo <rizzo@icir.org> Cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] Message-ID: <41BEE0E7.BD2316EB@freebsd.org> References: <20041213124051.GB32719@cell.sick.ru> <20041214085123.GB42820@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > > 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.) This is one of the difficulties of per-interface ACL's like in Cisco and Juniper. On the other hand the global-only approach has it's own difficulties with larger number of interfaces. > 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. Nonononononononononononononononononononononono. There MUST NOT be any firewall specific pointers or other information in struct ifnet or any other non-firewall private part of the kernel. Otherwise the entire independence we've gained with the nice and clean PFIL_HOOKS API goes down the drain. This MUST NOT happen again. The whole idea of the PFIL_HOOKS is to have independend and loadable firewall modules with different approaches, internal designs and so on. For example a way Gleb can get his way without any bickering from us is by creating his own gleb-firewall module using the PFIL_HOOKS API and put it into the ports tree for easy access, provided he doesn't modify the PFIL_HOOKS API (which he doesn't have to). > 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. Whatever. This is private to the firewall implementation of his choice. > 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. This is broken by design. This way we're back in the FreeBSD 4.x days of hacking the entire IP stack for one particular 'feature'. In those days there was no direct alternative but today we have PFIL_HOOKS and we MUST NOT fall back into old habits of hacking the world around a very particular and specific subset of functionality and thereby making the maintainance of the whole thing harder again. > 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. Maybe not the users but the developers are. I will curse the hell out of anyone f*cking up the stack that way. > 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. I'm all for discussing the merits of having per-interface firewall rules. Actually I agree that this is a nice thing to have on boxes with large number of interfaces. There are multiple way of getting there and we have nowhere near any kind of agreement on that. And this is where we have get at first before any code is implemented. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41BEE0E7.BD2316EB>