Subject: [midcom] RE: Precedence of wildcards

From: Mark Duffy <[email-masked]>
Date: Sun, 09 Sep 2001 16:29:01 -0400

At 12:23 PM 9/7/01 -0700, Christian Huitema wrote:
>> 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

I don't see why, if using source/dest, such an explosion of rules would
take place.  Recallling that "realm" is also part of the equation, for the
above case, one rule is also sufficient from source/dest perspective:
     Rule ID:  Realm=realm-1, SA=*, DA=*, Proto=TCP, SPort=*, DPort=*,
     Attribute: bar incoming TCP

Now, since the above example has wildcard for all the addresses and ports
anyway, it is not too surprising that source/dest vs interior/exterior
didn't matter.  Suppose we had another, higher precedence policy to allow
incoming TCP to port 80 on a particular server:

With interior/exterior view the rule might be:
     Rule ID:  Realm=realm-1, IA=1.2.3.4, EA=*, Proto=TCP, IPort=80, EPort=*,
     Attribute: allow incoming TCP

With source/dest view the rule might be:
     Rule ID:  Realm=realm-1, SA=* DA=1.2.3.4, Proto=TCP, SPort=*, DPort=80,
     Attribute: allow incoming TCP
If we observe that the behavior of the FW-middlebox is that it allows the
incoming TCP syns with the above 5-tuple, and as part of its stateful
behavior it then also allows packets with the reverse 5-tuple (SA=1.2.3.4
DA=<specific-value>, Proto=TCP, SPort=80, DPort=<specific-value>) to flow
in the opposite direction then again it appears to me that the source/dest
and interior/exterior views are about equivalent.  

Can you provide a specific example where an explosion of rules would take
place?

Another consideration in whether the midcom protocol should have a
source/dest or interior/exterion slant is compatibility with the existing
base of middlebox devices.  I would have guessed that most are oriented to
source/dest, although I am saying that without much specific knowledge.

--Mark

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

---

From: Scott Brim <[email-masked]>
Date: Sun, 9 Sep 2001 18:03:12 -0400

> >list of different prefixes, you would probably end up with a few hundred

First of all, unless you assume some external means for the agent to
know, to start with, that its endpoint addresses are inside or outside,
then not all ruleset requests can be phrased in these terms -- but they
certainly can be phrased in terms of source and destination.

Second, if you want to bar all TCP connections from crossing a
middlebox, just bar all TCP connections.  No discrimination between
inside and outside is necessary or useful, so this example isn't very
good for you.

>      Attribute: bar incoming TCP

Mark, you're using "realm ID" in this case simply to mean "inside".
Aside from the fact that this rule doesn't mean much (see above), your
goal could easily be met by a simple flag, like the "outside okay" flag
I suggested, as opposed to a system of realm identifiers and all they
require.

> and interior/exterior views are about equivalent.  

Sure.

> source/dest, although I am saying that without much specific knowledge.

Most implementations apparently use *both*.  After all with overlapping
address spaces a particular source could be either inside or outside.
The question for me is whether an agent can have confidence in all cases
about whether a particular address that it's concerned about is inside
or outside.  I think not.