Subject: RE: [Megaco] remote SOURCE address

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 7 Sep 2001 15:38:39 -0400

On the one hand, you're absolutely right about what sec. 10.3 assumes.  On
the other, I suspect it's an optimistic assumption.  It's especially
dangerous where NATs sit between the source and destination.

Anyone else want to comment?

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 5:04 PM
To: MEGACO list
Subject: [Megaco] remote SOURCE address

Section 7.1.8, "Local and Remote Descriptors" distinguishes 
between the two with:

	"Local refers to the media received by the MG and
	Remote refers to the media sent by the MG."

I'd like to see a clarification stating that the remote
destination address (specified by the Remote Descriptor)
is also the remote source address.  (Where "address"
means IP address AND port in UDP.)

Section 10.3 discusses checking the IP address and port
of inbound packets against the Remote Descriptor (but 
doesn't require it).  This presumes that the Remote 
Descriptor describes the remote SOURCE address.

Comments?
-troy

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

---

From: Troy Cauble <[email-masked]>
Date: Mon, 10 Sep 2001 17:33:12 -0400

Tom,

NATs cause issues more fundamental than whether or 
not the remote source address is the remote destination 
address.  Setting up the media stream through NATs is
tricky in general.  I don't think the requirement that
the remote destination address be the remote source address
adds any difficulty.

If you can negotiate an exposed IP4 address and port on 
the NAT to serve as the other MG's remote destination 
address, I see no reason that it can't also serve as the
remote source address.

The setup is an interesting question though.  If an MG is 
behind a NAT, returning it's hidden (probably non-routable) 
address in response to an Add wouldn't be any good.  It seems
that either

A) the MG must be NAT-aware and return an IP and port (*) 
on the NAT in response to an Add, or 

B) the NAT is smart enough to hack H.248 messages as they pass
through!  (Unlikely!)

Either is pretty ugly.

  *  Unless given some ability to reserve ports on the NAT box,
     I think an MG could operate as an "exposed host".  But I
     think this approach could still have NAT-port-conflicts
     with applications on other hosts.  Otherwise the MG could 
     be restricted to a resonably small, known range of port numbers.  
     Either way, you run into problems supporting more than one MG 
     behind the same NAT.

Have NATs been addressed anywhere (w.r.t. H.248)?

If it wasn't obvious, I brought up the remote-source-address question
because I'm worried about "barge-in".  As 10.3 points out, having a 
known remote source address to check against isn't perfect (address 
spoofing), but it's better than nothing.

I really don't see encryption as a practical means of stopping "barge-in".

What's an MG supposed to do, accept RTP traffic from anywhere?

-troy

> Tom-PT Taylor wrote:

---

From: Matt Holdrege <[email-masked]>
Date: Mon, 10 Sep 2001 15:53:33 -0700

>B) the NAT is smart enough to hack H.248 messages as they pass

Why unlikely? NAT's for H.323 have existed for a couple of years now and 
that can be a heck of a lot harder than H.248. However the RTP issues may 
far outweigh the MEGACO issues and anyone who has to deal with NAT and VoIP 
is going to have a lot of headaches.