From owner-freebsd-ipfw@FreeBSD.ORG Mon May 17 20:24:08 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C74DB16A4CE for ; Mon, 17 May 2004 20:24:08 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBD1343D58 for ; Mon, 17 May 2004 20:24:01 -0700 (PDT) (envelope-from max@love2party.net) Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BPvCy-0001cr-00 for freebsd-ipfw@freebsd.org; Tue, 18 May 2004 05:24:00 +0200 Received: from [216.58.85.218] (helo=[10.0.0.49]) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BPvCx-0000Fo-00 for freebsd-ipfw@freebsd.org; Tue, 18 May 2004 05:24:00 +0200 From: Max Laier To: freebsd-ipfw@freebsd.org Date: Tue, 18 May 2004 05:25:33 +0200 User-Agent: KMail/1.6.2 References: <40A8C12D.5040906@email.dp.ua> <20040517151050.B63591@xorpc.icir.org> In-Reply-To: <20040517151050.B63591@xorpc.icir.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405180525.36273.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e28873fbe4dbe612ce62ab869898ff08 Subject: Re: ipfw prefix-list support request X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2004 03:24:09 -0000 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 [initial ips] and uses "<" and ">" to enclose a table in a filter rule. Like: pass on xl0 from 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