Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Jan 2004 15:53:59 -0500
From:      Charles Swiger <>
To:        Luigi Rizzo <>
Subject:   Re: semantics of 'not-applicable' options in ipfw ?
Message-ID:  <>
In-Reply-To: <>
References:  <>

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).


Want to link to this message? Use this URL: <>