Date: Tue, 18 May 2004 05:25:33 +0200 From: Max Laier <max@love2party.net> To: freebsd-ipfw@freebsd.org Subject: Re: ipfw prefix-list support request Message-ID: <200405180525.36273.max@love2party.net> In-Reply-To: <20040517151050.B63591@xorpc.icir.org> References: <40A8C12D.5040906@email.dp.ua> <20040517151050.B63591@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org Max Laier | ICQ #67774661 http://pf4freebsd.love2party.net/ | mlaier@EFnet
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200405180525.36273.max>