Subject: RE: [midcom] accept R3a1 & R3a2

From: "Cedric Aoun" <[email-masked]>
Date: Wed, 10 Oct 2001 16:05:59 +0100

Scott,
The topology I have in mind is the following

 ++++++++++           ++++++++++	     ++++++++++++	
 +foo.com    +MB1-----+the net      +-------MB2+MA   bar.com+
 ++++++++++	        ++++++++++              +++++++++++

In case the Midcom Agent sends a Midcom request to MiddleBox1
we don't want the protocol messages to contain any IP addresses or ports
relevant to the bar.com realm.
This is what I actually meant.

If this is a mother hood and apple pie requirement let's drop it, if it is
not we have to add it to the list.
Cedric

-----Original Message-----
From: Scott Brim [mailto:[email-masked]]
Sent: Wednesday, October 10, 2001 4:16 PM
To: Aoun, Cedric [QPD:MA01:EXCH]
Cc: 'Melinda Shore'; midcom mail-list
Subject: Re: [midcom] accept R3a1 & R3a2

On Tue, Oct 02, 2001 02:40:22PM +0100, Cedric Aoun allegedly wrote:
> I want to stress that we need a requirement such as: The Midcom
> protocol MUST work through NATs.  Mechanisms such as the informant
> method will not work through NATs so we should not forget this
> requirement.  In the case of  VoIP services provided by service
> providers (i.e. Telephony Service Providers), the Midcom agent might
> be behind a NAT .

Cedric, I think you're confused.  Agents are only relevant in terms of
the middleboxes they can control.  

In the case above, where an agent is "behind" a NAT, does it control
that NAT?  If so there is no problem, because they share an address
space.  

If you're saying there is a client on one side of a NAT, and some midcom
agent on the other side, and the agent does NOT control the NAT, then
the agent is irrelevant and you can take it out of your picture -- what
you have is the current situation, with no agent at all.  (Midcom agents
are distinct from application helpers.)

In a situation with a simple network and no scope for a separate agent
device, e.g. a home network, you provide a software "shim" to match the
application.  That bit of software has application-specific
intelligence, and is either a simple midcom agent to control the NAT or
something that speaks one of the short-term protocol approaches people
are discussing now.

So I don't think your objection has merit.

..Scott

---

From: Scott Brim <[email-masked]>
Date: Wed, 10 Oct 2001 12:27:47 -0400

> The topology I have in mind is the following

As long as the MA in the picture is a midcom agent, not an application
helper of some sort, I have trouble believing this scenario would be
deployed in real life.  

Can any ISP (not vendor) out there give any example of where they would
want such a scenario?  We're talking about a security relationship
between agent and middlebox crossing a NAT.

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