Date: 10 Jun 2002 12:47:40 +0400 From: "Vladimir B. " Grebenschikov <vova@sw.ru> To: Luigi Rizzo <rizzo@icir.org> Cc: ipfw@freebsd.org, "current@freebsd.org" <current@freebsd.org> Subject: Re: New ipfw code available Message-ID: <1023698860.576.29.camel@vbook.express.ru> In-Reply-To: <20020608201909.A41807@iguana.icir.org> References: <20020608201909.A41807@iguana.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
=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-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1023698860.576.29.camel>