per-interface packet filters, design approach

[Andre Oppermann]

Let's take a high level view of the issue at hand and the consider
some alternative approaches to the situation.

Current situation:

 a1. There is a need to have per-interface specific firewall rules.
 a2. We have multiple firewall packages which have multiple way to
     specify interface specific rules.
 a3. With large numbers of interface specific rules the rulesets get
     complex and hard to manage.
 a4. This seems to be mainly a problem with ipfw and it's skipto
     actions.

Request:

 b1. Users request a less complicated way of doing interface specific
     firewall rules.

Analysis:

 c1. This is primarily a USER interface/syntax/semantics issue.
 c2. The different user interface approaches of the different firewall
     packages we have require different changes to their USER interfaces
     to make it easier for per-interface rule sets.
 c3. The firewall packages we have can only deal with one global rule
     set per protocol family and direction currently.  They can't be
     loaded multiple times and can't have multiple rule set heads (only
     one entry point).

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.
 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