per-interface packet filters, design approach

[Roman Kurakin]

Hi,

    Could we also add ability to keep state between reseting of the rules?

For, example, if I use keepstates, after flushing and setting new rules that
could be different by two lines from an old one I kick my self from that
server with out any serious reason, I didn't change anything for ssh.

IMHO this could be done by keepstate for a while after flushing, but I 
didn't
ever look inside this code.

rik

Andre Oppermann wrote:

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