From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 23 15:00:19 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BA5F71C; Sun, 23 Mar 2014 15:00:19 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id C611E186; Sun, 23 Mar 2014 15:00:18 +0000 (UTC) Received: from Toshi.lariat.org (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id JAA00968; Sun, 23 Mar 2014 09:00:11 -0600 (MDT) Message-Id: <201403231500.JAA00968@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 23 Mar 2014 08:56:07 -0600 To: Julian Elischer , RW , freebsd-security@freebsd.org, ipfw@freebsd.org From: Brett Glass Subject: Re: URGENT? In-Reply-To: <532E723C.2090109@freebsd.org> References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 15:00:19 -0000 At 11:33 PM 3/22/2014, Julian Elischer wrote: >in ipfw that's up to you.. >but I usually put the check-state quite early in my rule sets. I don't, because I want packets to touch as few rules as possible for the sake of efficiency. One "check state" can cause an awful lot of work to be done! In my IPFW rule sets, I divide the work up by interface, and so there's a "check-state" only for interfaces and directions (in vs. out) to which automatically generated rules will apply. The problem is that this is still inefficient, because there's only one batch of automatically generated rules, containing some that will never apply in certain situations. My rule sets would be more efficient if I could divide the automatically created rules into multiple batches, and do "keep-state N" and "check-state N" to check only the batch that needed to be tested in a particular spot. This ought to be a relatively easy patch, and I've thought many times about coding and submitting it. "N" would default to zero, so the old behavior would be preserved if there was no "N" at the end so as not to violate POLA. >I am working on a new rc.firewall that is much more efficient. >the trouble is that the script to make it do what I want is a bit >more complicated. >I'll put it out for discussion later. maybe tonight. Would like to see it! --Brett Glass