per-interface packet filters

[Vladimir Grebenschikov]

В вт, 14/12/2004 в 16:02 +0100, Andre Oppermann пишет:
> Vladimir Grebenschikov wrote:
> > 
> > ÷ ×Ô, 14/12/2004 × 13:54 +0100, Andre Oppermann ÐÉÛÅÔ:
> > > It's about HOW to implement it.  I think the ways proposed so far are
> > > hackish, too complex and outside of our framework which was very well
> > > designed and allows this kind of feature without any of the hacks and
> > > extentions discussed here.
> > >
> > > We have to properly DESIGN these feature instead of just hacking them
> > > in.
> > 
> > Well, I agree, that it is about how to design it.
> > But I do not think that proposed solution is hackish, and I not alone
> > with it.
> 
> It breaks the PFIL_HOOKS API.

If I not mistaken Gleb claims that do not break:

G> please don't take this hard. I'm not going to change pfil(4) API,
G> since it has everything required.

> > Let's imagine our firewall framework as general firewall, able to be
> > plugged on different layers, after that you can get following:
> > 
> > 1. Plug firewall (dedicated chain) between netgraph nodes
> 
> [Doesn't work before and after PFIL_HOOKS API breakage.  You'd need a
>  ipfw netgraph node for that anyway.]

Yes, but is about "how netgraph interfere with ipfw" sometimes, netgraph
filtering has nothing common with host filtering.

> > 2. Plug firewall on any specific interface
> > 3. Plug firewall on any network packet processing input/output (current)
> > 4. Plug it into bridging code
> 
> How do you represent this complexity in syntax and semantics?

First what jump into my mind:

flows management:
ipfw flow add $customer1 iface fxp0
ipfw flow del $customer2 iface fxp0
ipfw flow set $customer1 iface fxp1
ipfw flow default $extrenal
ipfw flow list

changes rules for flow
ipfw flow use $customer1 add ip from any to any
...

or as variant
ipfw -F $customer1 add ip from any to any
...

I think there can be better interface if think a bit about it.

> This is the tricky problem to be solved first.  Then we can start arguing
> about implementation issues, API's, ABI's and other related things.

Again, Gleb do not going to change API or ABI.

> So give me syntax and semantics examples how you want to operate this
> functionality?
 
see above 

> We do not dispute the need for per-interface rules.  

Ok, so we agree that it is good idea ? 

> The question is *how* to represent it.  
> In fact that is the only question because the functionality is already there, 
> only hard to use.  I haven't yet seen how you make it easier to use other 
> than saying "ipfw per-interface". But that doesn't answer my question.

So what 

> > In this list interface looks very reasonable as place to plug, for me it
> > looks even more reasonable then our usual input/output, because packet
> > on ether output gives you no idea where it come from - local or remote,
> > especially in complex setups, with often changing interface names and
> > indexes (pptp server for example). It is not clear how to write rules
> > that affects only local traffic and transit traffic (I do not mean loop-
> > back when talk about local traffic)
> 
> With cloned devices you have a problem anyway.  Who puts the correct
> ipfw chain head pointer into struct ifnet in your example?  devd perhaps?

mpd while start pptp session, or like

> Please enlighten me.

-- 
Vladimir B. Grebenchikov
vova at fbsd.ru