Subject: [midcom] Precedence of wildcards

From: "Christian Huitema" <[email-masked]>
Date: Fri, 7 Sep 2001 08:58:14 -0700

> I do not see how this affords a useful unambiguous way to determine
> the
> relative precedence of rules that may match a packet in the presence
> of
> wildcards.
> 
> If we have
> Rule 1:  SA= any, DA= 1.2.3.4, protocol= any, SP= any, DP= any
> Rule 2:  SA= any, DA= any,     protocol= tcp, SP= any, DP= any
> Then which rule does a tcp packet to address 1.2.3.4 match?

Note that my proposal is not to use "source address" and "destination
address", but "interior address" and "exterior address", precisely
because it is a better match to practical filters -- you are much more
likely to allow every external host to communicate with an interior
server than the other way around. The order I propose was:

>	Interior address
>	Protocol type
>	Interior port
>	Exterior address
>	Exterior port

Assuming that the rules are: 

 Rule 1:  IA= any, protocol= any, IP= any, EA= 1.2.3.4, EP= any
 Rule 2:  IA= any, protocol= tcp, IP= any, EA= any,     EP= any

Then rule 2 takes precedence. This may not be what you wish, but it is
unambiguous and predictable. It means that if you want to override rule
2, you will have to enter an extra rule: 

 Rule 2:  IA= any, protocol= tcp, IP= any, EA= 1.2.3.4, EP= any

Indeed, we could decide to decide that address values should take
precedence over protocol type, and change the ordering to: 

	Interior address
	Exterior address
	Protocol type
	Interior port
	Exterior port

In this case, rule 1 would take precedence. The basic point is that the
protocol should pick a very specific ordering, so that there is no
ambiguity.

-- Christian Huitema

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom

---

From: Mark Duffy <[email-masked]>
Date: Fri, 07 Sep 2001 14:32:45 -0400

At 08:58 AM 9/7/01 -0700, Christian Huitema wrote:
...
>server than the other way around. The order I propose was:

OK, I understand your point is to use interior/exterior rather than
source/dest.  From your earlier post, you would then have an action
associated with this rule such as { send, recv, sendrecv, closed } which
controls which direction(s) packets are permitted to flow.

However, I believe interior/exterior and source/dest are logically
equivalent since a simple converion can produce one from the other:

  For packets received (from the Interior) Interior addr = source address
and exterior addr = dest address.  
  And for packets sent (to the Interior) Interior addr = dest address and
exterior addr = source address.  

Therefore I don't understand *why* the interior/exterior view of things
lends itself any better than the source/dest view to imposing a canonical
ordering on widcarded rules.  Could you explain that?

Thanks, Mark

---

From: John LaCour <[email-masked]>
Date: Fri, 7 Sep 2001 11:56:41 -0700

I don't understand why we're talking about rule precedence.  
If a packet is allowed through under rule 1 or rule 2 the
result is the same.

Rule precedence is a middlebox implementation issue.  I don't
think there are any issues until MIDCOM is extended to include
policy changes that say "block this kind of traffic".  Even
then I'll probably stay in the camp that its a middlebox
implementation issue.

-John

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 8:58 AM
> To: Mark Duffy; [email-masked]
> Subject: [midcom] Precedence of wildcards
> 
>

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 7 Sep 2001 12:15:20 -0700

> If a packet is allowed through under rule 1 or rule 2 the

Because rules have attributes. I may well have two overlapping rules,
such as:

Rule 1: ID: IA=*, EA=*, Proto=TCP, IPort = *, EPort = *
        Attribute: only authorize outgoing connections
Rule 2: ID: IA=10.0.0.1, EA=*, Proto=TCP, IPort = 80, EPort = *
        Attribute: accept incoming connections.

It matters greatly whether apply one or the other...

> Rule precedence is a middlebox implementation issue.  

No it is not. We have agreed that it was a protocol requirement that the
result be predictable and consistent in the presence of multiple rules.

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 7 Sep 2001 12:23:19 -0700

> Therefore I don't understand *why* the interior/exterior view of
> things lends itself any better than the source/dest view to imposing a
> canonical ordering on widcarded rules.  Could you explain that?

Essentially because a lot of the firewall rules have the notion of
"incoming" and "outgoing", and also because in most cases you will issue
a single statement about both directions of traffic, such as "sendrecv"
or "recvonly." 

Suppose for example that you want to write a rule that bars all incoming
TCP connections. If you can tell "interior" and "exterior", you write:
	Rule ID: IA=*, EA=*, Proto=TCP, IPort=*, EPort=*,
	Attribute: bar incoming TCP
If you can only reason about source and destination addresses, you have
to explode that into multiple rules for the various address ranges. In
the case of the Microsoft internal networks, which include quite a large
list of different prefixes, you would probably end up with a few hundred
of lines.

-- Christian Huitema