From owner-freebsd-ipfw Mon Jun 24 13:59:44 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from cleopatra.rubiconproject.com (cleopatra.rubiconproject.com [63.95.167.9]) by hub.freebsd.org (Postfix) with ESMTP id D808037B423 for ; Mon, 24 Jun 2002 13:57:38 -0700 (PDT) Received: from jmk65.rubiconproject.com. (252-65.rubiconproject.com [10.255.252.65]) by cleopatra.rubiconproject.com (8.11.6/8.9.3) with ESMTP id g5OKvQ603722; Mon, 24 Jun 2002 13:57:26 -0700 Date: Mon, 24 Jun 2002 13:57:21 -0700 (Pacific Daylight Time) From: Jeff Kletsky To: Luigi Rizzo Cc: ipfw@freebsd.org Subject: Re: New ipfw code available Message-ID: X-X-Sender: jkletsky@cleopatra.rubiconproject.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Luigi and Group: In my searches for a way to clear accounting on ipfw pipes, I came across this thread. http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=35657+40570+/usr/local/www/db/text/2002/freebsd-ipfw/20020609.freebsd-ipfw Running a commercial site that relies on the robustness of the ipfw code, I'd like to throw in a few suggestions about the documentation and user-land utilities. First, let me say that this type of flexibility and control has the potential to make my life a lot easier!!! For firewalls to be reliable, the rules need to be both predictable and easily understandable. Having used pcap for some time now, I cannot say that the filter expressions are either, especially when more than just basic in their complexity. The original post's example: "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" can be interpreted in many ways, depending on operator binding and precedence. I'd hate to be wrong.... I need to be able to *easily* look at a rule and understand what it does, both when writing it, and when reading it later as output from the loaded ruleset. Constructs such as 1000 skipto 1010 ip from ${safe_src} to ${safe_dst} 1005 deny log ip from ${generally_unsafe_src} to ${generally_unsafe_dst} 1010 (do something else here) are, while inefficient, easy to read and to understand if the appropriate behaviour applies. I would like to suggest that the syntax and precedence rules for the microcode be very clear and unambiguously documented. Parenthesis or some other construct should be allowed to ensure that the rules are properly interpreted. On output, I would suggest that a similar construct clearly indicate the logic. Yes, I'd help with the documentation and, as my skills permit, the output formatting... Jeff P.S. Implementing 'ipfw pipe [n] zero' to zero the counters (and possibly clean out the inactive flowsets ala expire_queues()) is on my list, though I have a lot more code-comprehension to do. Anyone else who wants to provide suggestions or tackle it is more than welcome! -- Jeffrey Marc Kletsky Director Of Product Management SpotLife Inc. 1950 Leslie St. San Mateo, CA 94403 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message