per-interface packet filters

[Jeremie Le Hen]

On Tue, Dec 14, 2004 at 04:20:31PM +0300, Gleb Smirnoff wrote:
>>> ipfw syntax will be 100% backward compatible. The following keywords would
>>> be added:
>>> 
>>> ipfw chain list                 - list configured chains
>>> ipfw chain add | delete         - delete, remove chain
>>> ipfw chain _number_ [common rule definition]    - add/delete rules to
>>>                                                   non-default chain
>>> 
>>> It would be possible to attach chains to interfaces specifing also
>>> direction. It will be done with ifconfig, or a specific utility (not yet
>>> decided).
>> 
>> Why don't you specify the interface directly in the syntax?  That would be
>> more in line with ease of use instead of having yet another logical
>> indirection?
>> 
>>  ipfw fxp0 add permit ip from any to any
> 
> Because one chain may be used for several interfaces. One can be used for
> ng_pfil node. One can be not used at all, but it is hanging there, so that
> it can replace the one used by interface (this is what bms requested for
> XORP). 

If you introduce this kind of logical indirection, why would you
restrict these chains to be used only if the interface matched ?  I
mean that any of available packet-filter matches (src or dst ip, proto,
ports, TCP flags or even ttl...) may be used as a requirement to reach
this chain.  This is how the Linux NetFilter framework is designed [1].
    Quote from Linux iptables(8) manual page [2] :
    << Iptables is used to set up, maintain, and inspect the tables of
       IP packet filter rules in the Linux kernel. Several different
       tables may be defined. Each table contains a number of built-in
       chains and may also contain user-defined chains.

       Each chain is a list of rules which can match a set of packets.
       Each rule specifies what to do with a packet that matches. This
       is called a `target', which may be a jump to a user-defined
       chain in the same table. >>


Note that I am not saying that NetFilter is better (I would be silly
to do it here ;-)), but nevertheless it may have some interesting ideas
to consider while talking about extending FreeBSD firewall framework,
IMHO.

[1] http://www.docum.org/docum.org/kptd/
[2] http://sman.informatik.htw-dresden.de/man/ALL/iptables.html#sect2

Regards,
-- 
Jeremie Le Hen
jeremie at le-hen.org