From owner-freebsd-net Tue Aug 20 5:42:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A80537B400; Tue, 20 Aug 2002 05:42:07 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A80543E4A; Tue, 20 Aug 2002 05:42:07 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7KCg6Ib046009; Tue, 20 Aug 2002 05:42:06 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7KCg6Au046008; Tue, 20 Aug 2002 05:42:06 -0700 (PDT) (envelope-from rizzo) Date: Tue, 20 Aug 2002 05:42:06 -0700 From: Luigi Rizzo To: ipfw@freebsd.org Subject: ambiguity of filter expressions (tcpdump and ipfw2) Message-ID: <20020820054206.A45915@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [Bcc to -net, but please keep the discussion on -ipfw] Hi, we have the following issue (both in tcpdump and ipfw2): when you specify a match pattern that is not applicable to the packet being processed (e.g. "src-port 80" on an ICMP packet), the match will simply fail and the packet will not be selected. However, when you put in a "not" operator (as in "not src-port 80") there are really two ways to implement the operation: 1. the basic match fails, so its negation will succeed. This is the way tcpdump operates (try a "tcpdump not port 80" and see how it matches all sort of non-tcp traffic), and also ipfw2 does the same thing for consistency with tcpdump (that is the official excuse -- in reality, i did not think of the issue in the first place, maybe the same happened to the tcpdump/libpcap authors). 2. The match operator is "not applicable" so both the direct form and the negation will fail. Now, using the first approach in a firewall might be somewhat dangerous, in the sense that, yes, the rule does exactly what you write, but that might not be what you really want. E.g. consider ipfw add allow not src-port 80 which could be meant to pass all tcp traffic not coming from a web server -- however, this rule would also leak all non-tcp and non-udp packets. The correct way to express the rule is of course to to include a "proto tcp" match pattern, but sometimes this can escape. The second approach would prevent such mistakes, though it might be non-obvious to people used to tcpdump syntax (although, i suspect "not" operators are not widely used there either). So, what do we do ? Implementing the second behavior requires rather trivial changes in the kernel, and no changes in the kernel-user interface or in the userland programs. ipfw2 syntax is not yet widely used so changing between one mode and the other would not give too much trouble to people. It might even be possible to provide a sysctl variable to choose between the two behaviours, though i'd rather not do that because it has a little bit of impact on run-time performance, and also because having yet another tunable increases confusion. I'd be inclined to leave things as they are, surely remark the issue in the manpage, and maybe make ipfw2 print out a "Warning" message about the use of a potentially unsafe match pattern, same as the compiler does when you use a "gets". Opinions anyone ? cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message