From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 30 08:10:00 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7999D16A4CE for ; Sun, 30 Nov 2003 08:10:00 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F40243FBF for ; Sun, 30 Nov 2003 08:09:59 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.3) with ESMTP id hAUG9x2e049439; Sun, 30 Nov 2003 08:09:59 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id hAUG9wRL049437; Sun, 30 Nov 2003 08:09:58 -0800 (PST) (envelope-from rizzo) Date: Sun, 30 Nov 2003 08:09:58 -0800 From: Luigi Rizzo To: Antti Louko Message-ID: <20031130080958.A48029@xorpc.icir.org> References: <20031130065310.29349.qmail@alo.louko.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031130065310.29349.qmail@alo.louko.com>; from alo@iki.fi.invalid on Sun, Nov 30, 2003 at 06:53:10AM -0000 cc: freebsd-hackers@freebsd.org Subject: Re: ipfw/ipf IP filtering thoughts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2003 16:10:00 -0000 On Sun, Nov 30, 2003 at 06:53:10AM -0000, Antti Louko wrote: > Generally, I like the (Free)BSD way of doing things. But the IP > filtering modules available for FreeBSD lack one feature when compared > to Linux way (ipchains and iptables). There is no "call" instruction by design in ipfw2. The reason is that in many cases (e.g. after "divert" action or a dummynet pipe) packet processing might need to restart from the point where it was suspended. Having a "call"/"return" would require to save the return stack with the packet, which is expensive and was even very hard to do before having m_tags, or to introduce limitations in the actions, which is not nice and not backward compatible. I am not opposed on adding call/return actions (it would be trivial to do in ipfw2, except for the state saving part) but would really like to see a convincing example motivating their use. E.g. your example (do certain tests only if the packet matches X) can be trivially implemented by skipping to the end of the list if !X. If you are concerned by readability of the resulting list, I think you should consider ipfw[2] instructions as machine code and instead read/generate them from a higher level description in some scripting language. I have one (small) extension which might help in producing more efficient rulesets: introduce 'setflag'/'clearflag' actions (similar to "count") which can set or clear a small number of flags (think of them as the bits in a 32-bit number) when the packet matches, and then a "flags" command which can look for certain flag configurations. So you could write things like setflag 0x100 src-ip a/24,b/26,c/30 ... setflag 0x200 src-ip d/24,e,f ... allow flags 0x300:0x300 dst-port 22,80 allow flags 0x100:0x100 dst-port 25 etc. so you can record the result of a potentially long series of checks in a single flags and then act depending on the flag configuration. cheers luigi > In ipchains and iptables you have a sequential list of rules, very > much like in ipfw and ipf, but you can have several different lists > which have symbolic names and you can make calls from lists to other > lists based on normal packet criteria. If the list is exchausted, the > scan returns to the previous list. This makes it possible to make > filtering decisions much more efficient in complex situation. You can > for example scan a certain list only for eg. packets going to for > example port 25 and so on. In FreeBSD, you don't have this > "subroutine call" feature at all and you are limited to only one > sequential list with a "goto". > > Any ideas how to proceed. I think this would be really needed and > widely used if available. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"