RE: [SIP] symmetric RTP as a solution for NAT traversal

Jonathan Rosenberg <jdrosen@dynamicsoft.com> Fri, 16 March 2001 07:23 UTC

Return-Path: <owner-confctrl>
Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id XAA22212 for confctrl-outgoing; Thu, 15 Mar 2001 23:23:40 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA22200 for <confctrl@zephyr.isi.edu>; Thu, 15 Mar 2001 23:23:38 -0800 (PST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2G7Nbq11679 for <confctrl@isi.edu>; Thu, 15 Mar 2001 23:23:37 -0800 (PST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA07728; Fri, 16 Mar 2001 02:26:51 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <FMX9QS49>; Fri, 16 Mar 2001 02:25:40 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF0128BC17@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: 'Christian Huitema' <huitema@exchange.microsoft.com>, Jonathan Rosenberg <jdrosen@dynamicsoft.com>, sip@lists.bell-labs.com, rem-conf@es.net, confctrl@ISI.EDU
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
Date: Fri, 16 Mar 2001 02:25:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk


 

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@exchange.microsoft.com]
> Sent: Thursday, March 15, 2001 10:22 PM
> To: Jonathan Rosenberg; sip@lists.bell-labs.com; rem-conf@es.net;
> confctrl@isi.edu
> Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
> 
> 
> Jonathan,
> 
> Your solution is interesting, but it does not deal with the 
> case of two
> PCs, both behind a NAT. 

It does. The document discusses the solution. It uses an external RTP
translator. Not optimal; I recognize that. Other solutions may be possible.

> Another way to solve the problem is to let the
> PC who is behind a NAT learn the external mapping of the RTP 
> port, e.g.
> that 10.0.0.9:3456 maps to 123.45.67.89:7891. There are quite 
> a few ways
> to do that, some of which could well end up being standardized. That
> would certainly be a nice complement to the symmetric RTP trick.

Absolutely. There are several tractable solutions if nats conform to the
UDP requirements which you have outlined, Christian, in:

http://search.ietf.org/internet-drafts/draft-huitema-natreq4udp-00.txt



> 
> However, there is a slight problem. We cannot assume that 
> NATs are aware
> of RTP's requirement for "port pairs", an even port for RTP, the next
> port for RTCP. We may well learn that port 3456 maps to
> 123.45.67.89:7891, and port 3457 maps to 123.45.67.89:9872. Now, if we
> intend to open the SDP spec and create attributes for the "symmetric
> RTP", we should perhaps also create an attribute specifying the RTCP
> port, when that port is not equal to RTP+1.

If we do some kind of solution where the external entity tells both UAs
their public addresses, then yes, this will be needed.

> 
> A mild objection to the symmetric RTP is the risk of session 
> hijacking.
> Arguably, that is a risk you can assume if the alternative is 
> no session
> at all, but you should still consider it...

How does symmetric RTP create a risk of hijacking?

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com