ipfw prefix-list support request

[Max Laier]

On Tuesday 18 May 2004 00:10, Luigi Rizzo wrote:

> I think for the code you could try to borrow something from pf.

I'll try to describe a bit how it is handled in pf, to give you some more 
hints in case you are going to look at the code ...

> On Mon, May 17, 2004 at 04:42:05PM +0300, Dmitry Sergienko wrote:
> > Hi!
> >
> > I'm thinking about external prefix-lists in ipfw. This is like
>
> I think everybody agrees that it would be great to have in ipfw2
> named objects such as list of ports, prefixes, etc that one can
> dynamically modify without having to rewrite rules.
>
> The issues are:
>  + (minor but important) find a decent syntax -- your example
>
>         ipfw add 100 allow ip from prefix-list goodcustomers to any
>
>    is ambiguous as prefix-list could be a hostname and goodcustomers
>    a service name. Given that this is ipfw2, you can use ipfw2 syntax
>    and define a new keyword 'src-prefix-list' to be used as
>
>         ipfw add 100 allow src-prefix-list goodcustomers ...

pf defines tables:
	table <somename> [initial ips]
and uses "<" and ">" to enclose a table in a filter rule. Like:
	pass on xl0 from <somename> to any
This might be problematic as ipfw uses shell scripts to feed the rules into 
ipfw, so "<>" might have special meaning ...

>  + define the semantics clearly -- do you want longest prefix match,
>    or just any match (it does make a difference in the management of
>    counters);
>
>  + implement the list efficiently -- to avoid huge search times, one
>    implement the list as some kind of compressed trie. HOWEVER, if the
>    list is short (some 10 entries) a linear search is probably a lot
>    more efficient, so your code should cover both cases.

pf uses the existing radix-tree implementation for the tables. This provides 
lookups in O(32) for IPv4 and O(128) for IPv6 which means it's a constant 
time lookup. Unfortunately, the radix code has some locking requirements that 
add overhead but it's sure worth looking at.
Using the radix-tree here, also decides how to deal with the matching: special 
case wins over common case, making it possible to say something like: Allow 
10/8 but not 10.0.5/24 ... it's really neat. Look in pf.conf(5) and the pf 
faq on www.openbsd.org for more examples and explaination.

>  + remember that ipfw(2) accepts one line at a time -- so there will be
>    times when the configuration is inconsistent e.g. you might have rules
>    pointing to a non-existing list. Make sure the handling of these cases
>    is not terribly expensive.

I have no clue how to address this, but I find it a rather gross way of 
dealing with a ruleSET ...

Final note: The pf code to handle this resides in sys/contrib/pf/net/ 
pf_table.c and is not very easy to read. It's supposably more easy to start 
with a new implementation starting from the radix code and taking the pf 
behaviour as reference/inspiration.

I hope that helps.

-- 
Best regards,				| mlaier at freebsd.org
Max Laier				| ICQ #67774661
http://pf4freebsd.love2party.net/	| mlaier at EFnet