From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 12:54:23 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8F9F16A4CE for ; Wed, 14 Jan 2004 12:54:23 -0800 (PST) Received: from smtpout.mac.com (A17-250-248-85.apple.com [17.250.248.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFA7243D55 for ; Wed, 14 Jan 2004 12:54:00 -0800 (PST) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i0EKs0mB011017; Wed, 14 Jan 2004 12:54:00 -0800 (PST) Received: from [10.1.1.193] (nfw2.codefab.com [66.234.138.66]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 3.0) with ESMTP id i0EKrxgj020506; Wed, 14 Jan 2004 12:54:00 -0800 (PST) In-Reply-To: <20040114082004.A43466@xorpc.icir.org> References: <20040114082004.A43466@xorpc.icir.org> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Wed, 14 Jan 2004 15:53:59 -0500 To: Luigi Rizzo X-Mailer: Apple Mail (2.609) cc: ipfw@freebsd.org Subject: Re: semantics of 'not-applicable' options in ipfw ? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 20:54:24 -0000 Hi, all-- On Jan 14, 2004, at 11:20 AM, Luigi Rizzo wrote: > As an example, if i say (using ipfw2 syntax, for simplicity) > > 100 count src-port 100 > 200 count not src-port 100 > > and i receive a fragment, or an ICMP packet (which does not have port > information available), should it match rule 100, rule 200, none > or both ? The current implementation in ipfw2 is to use binary > logic, so the outcome of a 'not-applicable' option is FALSE, > and its negation is TRUE (so in the above case rule 200 will succeed). The current behavior is reasonable, and matching none would also reasonable-- if it were documented as behaving that way, but the former is more intuitive. It seems unreasonable for an ICMP packet to match rule 100, thus disqualifying the "match both" case. > Do other firewalls use ternary logic where not-applicable > options and their negation will both fail ? I haven't seen another firewall use ternary logic, although I remember enough of EE to remember working with 0's, 1's, and X's for "don't care" or "not-applicable". If an output of a logic expression results in a don't-care, the behavior of that part of the system is undefined. We want the behavior of the firewall to be deterministic, right? (Most of the time, anyway-- I acknowledge the prob keyword is a counterexample, but that is a special case. :-) > (please do not complain on the example and the fact you could > insert a "{ proto tcp or proto udp }" block to make the > behaviour less ambiguous, my point is just to clarify and > specify what is the actual behaviour). It would be reasonable for IPFW to require that the use of src-port also require that a procotol which uses port numbers be specified, otherwise generate a warning to the user about the ambiguity. In other words, this would keep the current behavior. It would be reasonable for the use of src-port to imply a test of the form (if packet contains an identifiable port number) && (src-port matches the rule as written by the user). This corresponds to the "match none" case above. Perhaps it might even be reasonable for IPFW to decide that the port number of a packet for which no port number can be determined is 0, thereby removing the ambiguity in another fashion. Port 0 is reserved per IANA/RFC1700, so the primary real-world use for packets using port 0 is for TCP stack identification (used by NMAP et al). The reasoning for this last suggestion involves more of a notion of IPFW parsing a set of values from each packet it sees and falling back to sensible default values for information which is not present but is being tested by a rule anyway, either explicitly or by implication (such as asking for the port number of an ICMP packet). -- -Chuck