Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Dec 2004 15:19:28 +0100
From:      Andre Oppermann <andre@freebsd.org>
To:        Bruce M Simpson <bms@spc.org>
Cc:        freebsd-net@freebsd.org
Subject:   Re: per-interface packet filters, design approach
Message-ID:  <41BEF670.95C30ED5@freebsd.org>
References:  <41BEF2AF.470F9079@freebsd.org> <20041214141307.GA684@empiric.icir.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Bruce M Simpson wrote:
> 
> On Tue, Dec 14, 2004 at 03:03:27PM +0100, Andre Oppermann wrote:
> > Let's take a high level view of the issue at hand and the consider
> > some alternative approaches to the situation.
> [snip]
> 
> I'm wrapping up in Berkeley for the holidays, but I wanted to drop my 2c
> into this discussion.
> 
> What I'm really missing in IPFW is the ability to maintain one or more
> 'shadow rulesets'. These rulesets may not be the active rulesets, but
> I can manipulate them as tables, independently of the active ruleset(s),
> push rules into them, flush them, and then atomically switch them to be
> the active ruleset, using a single syscall.

IPFW2 does have this functionality.  It's called "sets" of rules which
you can atomically swap, enable, disable, flush and intermix with each
other.  It's there, read ipfw(8), it's on the 15th line.

> IPF and PF have such functionality, IPFW does not. The lack of a documented
> ABI/API for access to IPFW by applications other than ipfw(8) is something
> which I'm leaving out of the picture for the moment.

It got a lot easier with the micro-ops but you are right there is no
documented rule-API.  You could write the documentation though.

> I don't really consider using 'skipto' and separate sections of rule
> index number space a valid answer here, because we should have the ability
> to independently flush each ruleset.
> 
> When extended to stateful rules (I am talking here purely about the simple
> stateless packet filter case), this comes in even more useful.

As long as you don't disable the rule set containing the 'check-state'
rule then already active connections remain active but no new ones are
allowed by the disabled set.

-- 
Andre



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41BEF670.95C30ED5>