Subject: RE: [midcom] Topology considerations documents

From: "Christian Huitema" <[email-masked]>
Date: Thu, 6 Sep 2001 16:03:49 -0700

I have read all three drafts, and have these feelings that we are well
on our way to define a camel... I would like a different analysis,
starting with the simplest topology and extending to the more complex
topologies envisaged in the draft.

I guess we all agree that the simplest topology is that of the "basic
firewall" configuration: a protected domain that we can call "the
interior", and by opposition a non protected side that we can call "the
exterior". The concept of interior and exterior leads us in this case to
a very simple pinhole specification. The pinhole is identified by:
	Interior address
	Protocol type
	Interior port
	Exterior address
	Exterior port
Indeed, each of these values can be wildcarded, or maybe replaced by a
"prefix" in the case of addresses. The pinhole will then have
attributes, such as:
	Direction: send, recv, sendrecv, closed
	Mapping of the interior address to the outside, if NAT
	Maybe mapping of the exterior address on the inside
	Etc.
A very good outcome of the directionality, i.e. from the inside out, is
that we can order the list of pinholes, as if the 5 tuple was one big
number. This allows us to define unambiguously which pinhole is most
specifically matching a given packet header -- i.e., in the matching
list, the one that comes first in the ordering, assuming that wildcards
rank after specified values.

OK, so we have a cool simple solution for the simple case, so what about
the complex case, for example the case quoted in
draft-penfield-midcom-realms-00.txt in which a single box protects
several networks:

        +-------------+ 
        |             |           +------+ 
        | Customer A  |           |      |      +---------------+ 
        |             +-----------+      |      |               | 
        |  10.0.0.x   |           |      |      |               | 
        |             |           |      |      |   Service     | 
        +-------------+           |Middle|      |   Provider    | 
                                  |  Box +------+               | 
        +-------------+           |      |      |               | 
        |             |           |      |      |  192.168.20.x | 
        | Customer B  |           |      |      |               | 
        |             +-----------+      |      +---------------+ 
        |  10.0.0.x   |           |      | 
        |             |           +------+ 
        +-------------+

Well, we may observe that such constructs are by and large equivalent to
a multiple-box construct:

        +-------------+ 
        |             |           +------+ 
        | Customer A  |           |      |      +---------------+ 
        |             +-----------+ MB-A |      |               | 
        |  10.0.0.x   |           |      |      |               | 
        |             |           +......+      |   Service     | 
        +-------------+           .      .      |   Provider    | 
                                  .      +------+               | 
        +-------------+           .      .      |               | 
        |             |           +......+      |  192.168.20.x | 
        | Customer B  |           |      |      |               | 
        |             +-----------+ MB-B |      +---------------+ 
        |  10.0.0.x   |           |      | 
        |             |           +------+ 
        +-------------+

We don't want to split the hardware, but nothing prevents us from
adopting a logical view in which "MB-A" and "MB-B" are different "midcom
servers", i.e. have different logical names. So, if an agent wants to
open a port for A, it sends comment to the midcom server "MB-A", and to
"MB-B" if it wants to open a port for B. Pretty soon, we have a generic
mechanism with a clear naming rule -- a name associated with the
protected domain -- and a simple semantic -- interior and exterior.

Looks nice, uh?

-- Christian Huitema

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

---

From: Andrew Molitor <[email-masked]>
Date: Thu, 6 Sep 2001 18:17:25 -0500 (CDT)

> a multiple-box construct:

	It looks beautiful.

	How does the physical middlebox tell which logical middlebox a
given packet belongs to when it arrives on an interface?

	Also, what problem, precisely, is solved by including a
logical middlebox name in, say, a pinhole description sent via MIDCOM?

	So far we have these ways to adorn 5-tuples and, in general,
policy:

	- interface names
	- "Local Realm" names
	- logical middlebox names (presumably plus one of the earlier
	  two since the logical middlebox doesn't do anything for
	  directionality)

	Ain't it cool?

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 7 Sep 2001 09:28:12 -0400

----- Original Message -----
From: "Christian Huitema" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 06, 2001 7:03 PM
Subject: RE: [midcom] Topology considerations documents

> draft-penfield-midcom-realms-00.txt in which a single box protects

This may be an over simplification. What happens when the flow needs to go
from A to B? How does the midcom agent in SP create a single
ruleset/pinhole/whatever to do that?

A middlebox is multi-sided. In the simplest case it has two sides. But in
this case it has 3 and it MUST be able to handle flows between any of the 3
sides.

(-:bob

---

From: Scott Brim <[email-masked]>
Date: Thu, 13 Sep 2001 12:40:50 -0400

On Thu, Sep 06, 2001 04:03:49PM -0700, Christian Huitema allegedly wrote:
> on our way to define a camel... 

Yup

> I would like a different analysis,

Yup

> a very simple pinhole specification. The pinhole is identified by:

Except you assume that the agent knows a particular address [range] is
inside or outside.  How can it know that?  It looks like you're assuming
this "realm" infrastructure and administration is in place.

In the case of wildcards an agent does need to let the middlebox know if
it's talking about a rule for inside or outside addresses, but it can't
know if a specific address is inside or outside.

> 	Direction: send, recv, sendrecv, closed

I think this is a much less significant point, but for now I would like
to keep this simple.  First, take out "closed" -- if a rule doesn't
exist it's closed.  Second, "send" and "receive" are useful only if you
use inside/outside as your primary descriptor, and I don't think you can
(see above).  Finally, it's easy enough to have two one-way rulesets
that I would like to leave out the sendrecv option, for robustness.

> rank after specified values.

I don't see how that's different from any other rigid ordering.  Suppose
we rigidly specified srcaddr, srcport, dstaddr, dstport, proto -- with
the same rules?  What's different?

> draft-penfield-midcom-realms-00.txt in which a single box protects

In the current case, yes.  

> protected domain -- and a simple semantic -- interior and exterior.

How does the agent know which virtual middlebox connects to which
network?  This is a discovery problem, but you seem to imply that the
agent somehow gets "realm" topology information.

> Looks nice, uh?

Modulo all the problems :)