Subject: RE: [midcom] Megaco and NAT

From: Steve Davies <[email-masked]>
Date: Thu, 21 Jun 2001 22:39:46 +0100

The restriction with Midcom is that it doesn't scale down - a call agent is
needed to handle calls, especially inbound calls otherwise there would be a
permanent inbound connection to every endpoint though the FW/NAT which is
obviously a security concern. Megaco doesn't really fit this model as the
call agent and endpoint (gateway or terminal) are usually on opposites sides
of the firewall/NAT.

You might like to look at the draft below which describes a protocol
agnostic method for secure but transparent traversal through firewalls and
NATs. No change to the firewall or NAT is needed. No firewall/NAT control
protocol is needed. Today we have only included call flows for H.323 and
SIP, but it could be extended for MGCP/Megaco if there was interest.  

http://search.ietf.org/internet-drafts/draft-davies-fw-nat-traversal-00.txt.

Steve
-----Original Message-----
From: Matt Holdrege [mailto:[email-masked]]
Sent: 21 June 2001 00:16
To: T. N. M. Kumar; [email-masked]
Subject: Re: [midcom] Megaco and NAT

Not really. If you wish to develop an ALG for MEGACO, you might want to 
first decide if you care about binary or text encoding, then write your own 
ALG for H.245 or SDP respectively. At that time, I would recommend 
submitting an individual draft and see what WG has the interest or the 
mandate to produce such an RFC.

At 02:02 PM 6/20/2001, T. N. M. Kumar wrote:
>I understand this working group at one point of time was addressing
>issues related to Megaco working with NAT.
>
>Any pointers to information appreciated.
>- Kumar
>
>
>
>_______________________________________________
>midcom mailing list
>[email-masked]
>http://www.ietf.org/mailman/listinfo/midcom

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

---

From: "Melinda Shore" <[email-masked]>
Date: Thu, 21 Jun 2001 17:59:30 -0400

> obviously a security concern. 

To your first point - a call agent isn't needed, but a
midcom agent is.  There's no reason that a midcom agent
cannot be resident in an endpoint (indeed, we explicitly
assume that it can be).  To your second point, policy
allows us to restrict what sort of inbound connections
would be permitted.

Melinda

---

From: Scott Brim <[email-masked]>
Date: Thu, 21 Jun 2001 18:05:33 -0400

Also, you can incrementally move applications to the agent model.  If
discovery goes the way it looks like it will, your existing firewall can
continue to function just as it is in parallel for outgoing calls.