Date: Wed, 14 Jan 2004 15:53:59 -0500 From: Charles Swiger <cswiger@mac.com> To: Luigi Rizzo <rizzo@icir.org> Cc: ipfw@freebsd.org Subject: Re: semantics of 'not-applicable' options in ipfw ? Message-ID: <C6C10710-46D3-11D8-AA98-003065ABFD92@mac.com> In-Reply-To: <20040114082004.A43466@xorpc.icir.org> References: <20040114082004.A43466@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C6C10710-46D3-11D8-AA98-003065ABFD92>