From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 08:20:10 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 6C19C16A4CE for ; Wed, 14 Jan 2004 08:20:10 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5B7943D5D for ; Wed, 14 Jan 2004 08:20:04 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i0EGK4AF044887; Wed, 14 Jan 2004 08:20:04 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i0EGK4QH044886; Wed, 14 Jan 2004 08:20:04 -0800 (PST) (envelope-from rizzo) Date: Wed, 14 Jan 2004 08:20:04 -0800 From: Luigi Rizzo To: ipfw@freebsd.org Message-ID: <20040114082004.A43466@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: 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 16:20:10 -0000 As the subject says... what is people's opinion on the best semantics for 'not-applicable' options in ipfw rules ? 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). Do other firewalls use ternary logic where not-applicable options and their negation will both fail ? (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). cheers luigi