per-interface packet filters [summary]
rizzo at icir.org
Tue Dec 14 01:56:06 PST 2004
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.
More information about the freebsd-net