per-interface packet filters, design approach

[Bruce M Simpson]

Hi,

At this point I'm tempted to explicitly *not* roll support for IPFW1
in XORP's ACL manager precisely because of its limitations; see below.

On Tue, Dec 14, 2004 at 03:19:28PM +0100, Andre Oppermann wrote:
> 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.

OK. This is probably something I can deal with. Basically XORP has an
intermediate rule representation which tries to be generic enough to
deal with divergent packet filter implementations across various OS
platforms, and yet specific enough to be useful.

A XORP rule tuple looks like this:
 ifname, vifname, src, dst, proto, sport, dport, action
Rule matches take place on all fields but the 'action' part of the tuple.

The interface to XORP's packet ACL manager is transaction driven to ensure
atomicity. Where this atomicity can't be guaranteed by the underlying
back-end, the back-end should attempt to mimic it using whatever tricks
are necessary.

Snapshots get taken at two levels: XORP's intermediate representation
described above, and the back-end's state. These snapshots can be taken
either for the purpose of safely rolling back state when rulesets are
being changed, or for communicating rulesets between different parts of
the packet ACL system.

I would imagine that mapping between an IPFW2 'set' and a PaIpfwBackend
snapshot on the fly would do the trick.

I just committed the core of XORP's ACL manager last week, please feel
free to have a look at it and give me feedback.

Regards,
BMS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 167 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20041214/31d31609/attachment.bin