From owner-freebsd-arch Tue Nov 23 23:58:54 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id EAA241501B for ; Tue, 23 Nov 1999 23:58:50 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA26852 for ; Wed, 24 Nov 1999 08:58:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA32689 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 08:58:49 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id DCAFD1501B; Tue, 23 Nov 1999 23:58:21 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40346>; Wed, 24 Nov 1999 18:51:11 +1100 Content-return: prohibited Date: Wed, 24 Nov 1999 18:58:01 +1100 From: Peter Jeremy Subject: Re: new IPFW In-reply-to: To: Brian Fundakowski Feldman Cc: arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov24.185111est.40346@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-24 17:33:04 +1100, Brian Fundakowski Feldman wrote: > All actions except for deny should have a "continue" option, where >the packet matching would both match that rule and follow its action, >but also pass on to the next rule. I don't quite follow what Brian means here. I'd like to suggest an additional 'goto rule N' command which, together with a pattern negation operator gives a fairly powerful language. Check out the filtering options in ppp(8) (the examples in /etc/ppp/ppp.conf.sample make them a bit clearer). >This would >allow actual logic in rules, albeit with slightly more complexity in >the IPFW implementation in the kernel. This would be a huge gain for >the administrator of the firewall, in that {,s}he could use a more >natural programming syntax, rather than the current, simplistic, >absolutely non-programmable (but klugeable) IPFW. IMHO, the complexity would be better in a userland `rule compiler' which produced (maybe more) simple rules for the kernel to execute. I suspect that trying to support complex rules in the kernel is unlikely to be a 'win' - think CISC vs RISC. A totally different approach is that used by bpf and libpcap. This could also form the basis of a reasonable IPFW implementation (but the API would probably need to change). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message