From owner-freebsd-ipfw Mon Jun 10 1:47:56 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by hub.freebsd.org (Postfix) with ESMTP id 15DCF37B407; Mon, 10 Jun 2002 01:47:47 -0700 (PDT) Received: from vova by vbook.express.ru with local (Exim 3.36 #1) id 17HKpx-0000ql-00; Mon, 10 Jun 2002 12:47:41 +0400 Subject: Re: New ipfw code available From: "Vladimir B. " Grebenschikov To: Luigi Rizzo Cc: ipfw@freebsd.org, "current@freebsd.org" In-Reply-To: <20020608201909.A41807@iguana.icir.org> References: <20020608201909.A41807@iguana.icir.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.5 Date: 10 Jun 2002 12:47:40 +0400 Message-Id: <1023698860.576.29.camel@vbook.express.ru> Mime-Version: 1.0 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG =F7 Sun, 09.06.2002, =D7 07:19, Luigi Rizzo =CE=C1=D0=C9=D3=C1=CC: Hi > over the past 2-3 weeks I have done an extensive rewrite of the > ipfw code (userland + kernel) in an attempt to make it faster and > more flexible. >=20 > The idea (which I discussed a few times on the mailing lists) was > to replace the current ipfw rules (macroinstructions) with a set > of microinstructions, each of them performing a single operation > such as matching an address, or a port range, or a protocol flag, > etc. -- much in the spirit of BPF and derivatives -- and to let > the userland front-end compile ipfw(8) commands into an appropriate > set of microinstructions. Really COOL!=20 And what about radix-tree-based ip-list matching ? like this: ipfw add 1 allow ip from {1.2.3.0/24,1.3.5.0/24,17.2.3.4/45,11.2.3.4/30} or cat mylist | ipfw list add mylist - ipfw add 1 allow ip from @mylist or something like=20 If you deal with large access-lists ipfw becomes not best tool due to linear comparison. > translates to a couple of microinstructions (whose complete > implementation is below the instructions themselves): >=20 > O_IP_DST=20 > if (((ipfw_insn_ip *)cmd)->addr.s_addr =3D=3D > (dst_ip.s_addr & ((ipfw_insn_ip *)cmd)->mask.s_addr)) > goto cmd_match; > goto cmd_fail; >=20 > O_ACCEPT: > retval =3D 0; /* accept */ > goto accept; >=20 >=20 > But there is a lot more -- the instruction set is easily extensible, > and without backward compatibility problems. Furthermore, you can > build (and I have already implemented them) more complex rules by > assembling microinstructions with OR and NOT operands. I.e. you can write > something like: >=20 > pipe 10 tcp from 1.2.3.4 or 1.2.3.7 or not 1.2.3.0/28 21-25,1024-4095 \ > to any in recv ed0 or recv fxp1 or recv dc0 uid 35 or uid 50 >=20 > You get the idea...=20 >=20 > I have a fairly complete version of the above code at the moment, > which is only missing a small set of functionalities > (ip/tcp flags matching, "log" and fixing hooks to the stateful > code). However the glue to implement all the missing pieces is > already there, it is just a matter of adding a few lines of code > and testing things. > Other than that, the code is meant to be fully compatible with the > old syntax so you will not have to rewrite your existing rulesets. >=20 > I have put a preliminary snapshot of this code (for CURRENT) at >=20 > http://info.iet.unipi.it/~luigi/ipfw5.20020609.tgz >=20 > It replaces the following files from a recent (2002/05/14) version of -cu= rrent. >=20 > sys/netinet/ip_dummynet.c > sys/netinet/ip_fw.c > sys/netinet/ip_fw.h > sbin/ipfw/ipfw.c >=20 > I would be very grateful if someone could have a look at the > code, maybe give it a try, and see e.g. how it compiles your > typical ruleset and whether the new extensions can make your > ipfw rulesets simpler. >=20 > Feedback welcome, both on the architecture and on the implementation. >=20 > NOTE: if people wonder why I did not use BPF and reinvented the wheel: > the keyword is "backward compatiblity" -- i thought it was a bit too > complex to compile the existent ipfw syntax into BPF, especially because > BPF at least as far as i know does not handle UIDs, and GIDs and > interface matches and different "actions" than match or not match, > so i would have had to extend the code anyways, at which point i > thought I could as well write my own microinstruction set... >=20 > cheers > luigi > -----------------------------------+------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > Mobile +39-347-0373137 > -----------------------------------+------------------------------------- > to=20 >=20 > thanks > luigi >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message >=20 --=20 Vladimir B. Grebenschikov vova@sw.ru, SWsoft, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message