Subject: RE: [midcom] pre-midcom work item

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 5 Oct 2001 01:48:40 -0400

> -----Original Message-----
> From: Mark Pietras [mailto:[email-masked]]
> Sent: Thursday, October 04, 2001 11:20 AM
> To: Jonathan Rosenberg; [email-masked]
> Subject: RE: [midcom] pre-midcom work item
> 
> 
> Jonathan,
> 
> More of a question about the _solution_ than the particulars of STUN:
> 
> Have you found a solution to the problem of "misguided" 
> media?  That is,
> when two clients are behind the same NAT and there's no 
> call-control/routing
> element with them in that same "realm?!", both will be forced 
> to assume that
> the other is on the "outside" the NAT.  Both the signaling 
> and the media
> will be sent "outside" just to be routed right back.  
> Signaling might not be
> a big deal, but media might be (from a latency or more interestingly a
> NAT-loading perspective).

There is a solution to this that I have been discussing with some folks
(there was actually a thread on the sip list about it), but its not
documented yet in any I-D. The basic idea is that the INVITE from the caller
would contain TWO SDP media streams. One lists the private address, and the
other, the public address obtained through STUN. There is some kind of FID
style tagging that lets the other side know that it should only use one of
them, and the one with the internal address is the higher priority. When the
called party gets this, it tries both streams, and uses the private address
if that succeeds, otherwise the public if it succeeds. The result is that
you get direct communication if both are behind the same NAT, and use the
NAT as a relay otherwise. 

Again, this is something commonly done in proprietary protocols,
particularly some network games. Seems like a really good idea for VoIP. It
needs some additional SDP work in order to function. 

Also, please note that this is quite orthogonal to stun. Stun is needed for
this approach to work, but they are independent.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: "Christopher A. Martin" <[email-masked]>
Date: Fri, 05 Oct 2001 07:55:29 -0500

Inline

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> Sent: Friday, October 05, 2001 12:49 AM
> To: 'Mark Pietras'; Jonathan Rosenberg; [email-masked]

I can see the idea of including the internal address in an external packet
(in the clear) as being considered as a possible security risk by the IT
community. This approach should be considered very carefully, since VoIP and
gaming are two completely different animals. When addressing MMoIP as a
whole one needs to remember that issues of privacy (including internal
topology) are key concerns with many individuals/organizations.

Of course many individuals immediately bring up the fact that everyone knows
about the RFC1918 address ranges, so whats the secret?  This applies more to
the use of NAT when it is used to hide legal address space as many
organizations do as an additional form of security/peering.

When divulging private address space within a packet that has been NAT'd can
also be useful in mapping a network, knowing that many network designers,
for instance, place routers at the top or bottom ranges of a network (i.e.,
10.1.1.1 or 10.1.1.254) and server farms within contiguous ranges, one could
easily use information gleaned, from what might appear as an apparent
attempt to contact internal users to map the network to identify possible
targets.

I am not trying to shoot down the idea, just want to make aware some of the
implications with an approach such as this.