per-interface packet filters, design approach

[Josh Kayse]

On Tue, 14 Dec 2004 14:27:01 -0500, Josh Kayse <josh.kayse at gmail.com> wrote:
> As someone who is quite new to all of this, take my thoughts with a
> grain of salt.  That being said, this is my view on the matter.
> 
> On Tue, 14 Dec 2004 15:03:27 +0100, Andre Oppermann <andre at freebsd.org> wrote:
> > Let's take a high level view of the issue at hand and the consider
> > some alternative approaches to the situation.
> >
> > Current situation:
> <snip>
> > Implementation approaches:
> >
> >  d1. The PFIL_HOOKS API has one hook per direction per protocol and
> >      passes the interface information to the firewall package.
> >  d2. Should the PFIL_HOOKS API be changed and be per interface instead
> >      of per protocol?  All firewall packages need to be modified and
> >      we are no longer compatible with the PFIL_HOOKS API.
> 
> I don't think so because as has been said, the PFIL_HOOKS API provides
> all the needed information.
> 
> >  d3. Should the interface specific rules sets be per firewall package
> >      in the way that best suits the package?  No kernel API is changed.
> >  d4. What is the user interface syntax and semantics for each firewall
> >      package that someone wants to be modified?  Provide examples for
> >      those you are interested in.
> >  d5. Should it be a replica of Cisco|Juniper approaches or can we do
> >      better in syntax or semantics?  Think outside of the box.
> >
> > Lets continue the discussion from here.
> >
> > --
> > Andre
> > _______________________________________________
> <snip>
> 
I'm spreaking of d3.
> I think so as it would be the best change, in my oblivious opinion.  I
> would see it as the firewall package receives the mbuf, checks the
> interface, if it is processing rules on the interface, or if there is
> a global set of rules, to then continue processing the packet.  If it
> isn't, it should just return/get out, whatever.  I do believe this
> would require a change in rule processing.  The firewall package would
> keep track of the different 'chains' for the rulesets.
> 
> As far as writing rules go, I think that it would be simple to make a
> script that takes a set of firewall configuration rulesets and merges
> them so that they do not collide.  I think it take more work to get it
> to make it pretty, but I don't see it being impossible.
> 
> I'm sure that I'm not understanding exactly what the problem is, so
> please, let me know what I'm missing, thanks.
> 
> --
> Joshua Kayse
> Computer Engineering
> 


-- 
Joshua Kayse
Computer Engineering