per-interface packet filters

[Max Laier]

On Monday 13 December 2004 13:40, Gleb Smirnoff wrote:
>   Dear networkers,
>
>   I finally managed to pronounce my idea, although I'm afraid
> of a bikeshed it is going to be burried under.
>
> When managing a complex router with many interfaces the output
> of `ipfw show` (or ipf/pf analog) is getting long and difficult to
> understand. It is also important that many packets are checked
> against the rules that can never be applied to them, wasting CPU
> cycles.

That's an error in the ruleset evaluation code then. Pf automatically jumps 
over rules that cannot be matched after one failed. If you have a block of 
1000 rules "on xl0" and the first one does not match because of the interface 
pf will continue checking with rule #1001. I am not sure if such shortcuts 
are possible for ipfw, but I suggest looking into that first.

> A simple example can be local network router with many inner interfaces
> and with one interface to internet. Actually filtering is desired
> only in external interface, and there is no need for local traffic
> to enter packet fitlering routines, e.g. ipfw_chk().

This is a very special case and you will only penalize the common case (i.e. 
looking for a per interface ruleset etc.)

> I'd like to implement per-interface pfil hooks, like in Cisco
> world. Each interface may have 'in' list of rules, 'out' list
> of rules. Current global ip_{input,output}, filters may coexist
> with per-interface ones, but can be turned off.

If you want this behavior you can - for instance - use pf anchors. For 
instance like this:
    anchor INTERN on xl0
    anchor EXTERN on tun0
    ...
see the "ANCHORS AND NAMED RULESETS" section of pf.conf(5). You can even do 
things like:
    anchor SPAM on tun0 proto tcp from any to any port smtp

You can then load rulesets into each anchor and pf steps into the ruleset only 
if the conditions are meat. Of course you can also look at the rules in a 
given anchor, expand the complete ruleset and have "normal" rules in 
conjunction with the anchors. That's the way to go - in my humble opinion.

> Our PFIL interface is quite ready for this, and this is very nice.
> I'll start with creating/editing alternative chains in ipfw. Then
> we will need to add possibility to register per-interface hooks
> in pfil, and add possibility to pass one more optional argument
> from pfil to the filter itself.

pfil already passes the interface. So if you really want to do this - I 
personally don't think it is the right way to go - you can do it *inside* the 
pfil hook without messing the API for everything else. I don't see what is 
missing in the current API that will stop you from doing so.

> I'm glad to see any constructive comments on plan.

Sorry, I don't see the point. If you are going to penalize the common case for 
this I will object.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20041213/1be16b0a/attachment.bin