Subject: RE: [midcom] Topology considerations documents

From: John LaCour <[email-masked]>
Date: Thu, 6 Sep 2001 16:18:11 -0700

See comments below...

> 
>         +-------------+ 
>         |             |           +------+ 
>         | 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?

In total agreement. 

I just want a way in MIDCOM to specify MB-A or MB-B so that I can 
avoid having multiple MIDCOM servers on my middlebox and avoid duplicating 
authentication mechanisms whenever I have one middlebox agent talking 
to both MB-A and MB-B.

-John

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

---

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

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

> authentication mechanisms whenever I have one middlebox agent talking
This sounds very similar to an interface or realm identifier in the
protocol.

---

From: Scott Brim <[email-masked]>
Date: Thu, 13 Sep 2001 13:08:22 -0400

> authentication mechanisms whenever I have one middlebox agent talking 

I've rarely seen a case where virtualization of a device was known, and
taken account of, in the protocol to control that device.