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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 15 Mar 2001 14:29:03 -0500

> -----Original Message-----
> From: Dirk Kutscher [mailto:[email-masked]]
> Sent: Thursday, March 15, 2001 11:00 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]'; [email-masked]'; [email-masked]'
> Subject: Re: symmetric RTP as a solution for NAT traversal
> 
>    Jonathan> The draft goes into details about all of this. It
>    Jonathan> requires only small changes to existing SIP/SDP/RTP
>    Jonathan> devices to support, and can solve a problem which I
>    Jonathan> believe will continue to hamper ubiquitous deployment of
>    Jonathan> SIP.
>
>    Jonathan> Comments? I'll be discussing this work in more detail on
>    Jonathan> Friday during the SIP session at IETF 50.
>
>Jonathan, Henning,
>
>interesting idea! Some comments:
>
>I think, both the ALG- and the "bidirectional RTP" approach have their
>merits and drawbacks:
>
>What is nice about the bidirectional RTP approach is that users are
>not required to install additional SIP-ALG boxes in order to use their
>SIP telephony equipment (assuming a few characteristics of the typical
>installed NAT device).
>
>What's not so nice is that both endpoints *and* provider-operated
>proxies have to be NAT-aware: e.g., endpoints have to use the pseudo
>hostname in the Contact-header of REGISTER requests and make use of
>a=direction (and BAVP) in the session description. Proxies will have
>to support this stuff (plus the SDP-manipulation and
>RTP-translator-control).

Its a practical issue of what it takes to deploy a real system.

Fundamentally, the concept of ALG does not scale up. There are lots of new
Internet applications all of the time. The people who make NATs cannot keep
track of all of them, and grow the expertise to be able to support every
protocol (plus their extensions, revisions, interop testing, etc.) in a
timely fashion. The new breed of residential NAT is a $150 consumer device;
I just don't see how those boxes can support EVERY protocol, and they won't.
Those vendors will wait until there is a large demand for specific
application, and then introduce it. 

Consider SIP specifically. THe basic nat alg is not awfully hard, but upon
further study, you realize there are issues like no-SDP in the invites,
early media, preconditions, SDP in ACK, multiple m lines, re-invites with no
SDP, and so on. That list of issues which would affect an ALG will grow, I
fear. We are still debating issues like early media that could result in
additional extensions that better handle it. Is it reasonable to assume that
every vendor of every nat box is going to realistically track these things,
and support them in their releases as fast as the sip vendors will? I think
not. Not even close. Similar argument for H.323. 

So, if I want to deploy a new application, I can either (1) wait for all the
nats in the world to introduce ALGs for the protocol, and then wait for them
to be deployed, replacing any existing nats in peoples homes and
enterprises. Then I deploy my protocol. Besides the fact that we're talking
several years here, there is a chicken and egg problem - if the application
isn't widely deployed (and can't be, because of nat), why would people
bother to widely deploy ALGs for it? 

This is the core argument behind the midcom framework, which is to
*separate* the application layer processing to support nat, and the actual
nat packet processing itself. Its another form of decomposition, like our
MGC/MG/SG decomposition in MGCP/megaco. For the case here, there is no
control relationship possible between the application servers in the
network, and the nat. However, the principle is the same: the alg for a
protocol should live with the vendors that understand that protocol, and
live in the boxes that provide that protocol service. When I build a server
to provide a service, the onus is ultimately on ME to make sure that the
service works for my customers. That has nothing to do with nat, thats just
a truth of deploying a real service.

>
>
>
>ALG-based solutions (given corresponding NAT-device and firewall
>control) would at least allow users to deploy "plain", NAT-naive SIP
>endsystems, and providers would not have to support the
>SDP-manipulation and RTP translator functionality in their
>proxies. Basically, it allows to keep the knowledge of NAT inside the
>NATed network.

Well, as I argue above, thats not actually going to work in practice. Right
now, people are doing horrible things like tunneling RTP over HTTPS. Here is
an opportunity, through what amounts to really simple extensions in the
client, to allow this application to traverse NATs in a sensible way.

I'll also add that our enhancements have other benefits beyond nat. They
also deal with problems related to multi-homing and self discovery of IP
addresses, as we describe in the document. We have seen these problems in
real systems as well, and they are hampering deployment just as the nat
problem is. I suspect there are other benefits lurking as well. 

Another way to describe it is thusly: all that we are doing is back-filling
into SIP/SDP/RTP  the nat friendly protocol guidelines which have since been
published by IETF. 

>
>A note on the use of SDP: Since bidirectional RTP is not a different
>transport (it's just a convention on the usage of source and
>destination ports) and we are still using the RFC 1890 profile, maybe
>it's more appropriate to use an a= line to signal the use of
>bidirectional RTP?

I'm just going with the conventions which are already described in the
conmedia draft, since I think symmetric RTP is another connectin oriented
transport. However, I am not a stickler for the syntax. So long as we convey
the desired semantics, I'm fine.

-Jonathan R.

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

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 15 Mar 2001 19:22:27 -0800

Jonathan,

Your solution is interesting, but it does not deal with the case of two
PCs, both behind a NAT. 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.

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.

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...

-- Christian Huitema

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2001 2:56 PM
> To: [email-masked]'; [email-masked]'; [email-masked]'
> Cc: Jonathan Rosenberg
> Subject: [SIP] symmetric RTP as a solution for NAT traversal
> 
> Folks,
> 
> I would like to draw your attention to some work we have done on NAT
> traversal for sip, documented in:
> 
>
http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-01.txt
> 
> Earlier versions of this draft recommended running RTP over TCP to
> traverse
> NATs, which is very unappealing. This -01 draft describes a way to run
RTP
> over UDP, and still traverse off the shelf, vanilla, regular, ALG-free
> NATs.
> However, to do so requires a small change in the way RTP is done for
> unicast, and a small update to some ongoing SDP work. Thats the reason
for
> my broad cross-post.
> 
> The problem with RTP usage for unicast (at least within SIP), is that
> there
> are effectively two RTP sessions established; the caller specifies, in
the
> INVITE, the IP address and port pair where they would like to receive
> packets, and the called party specifies, in the 200 OK, the IP address
and
> port where they'd like to receive packets. There are no restrictions
on
> the
> source port for sending to these addresses. Unfortunately, this is why
NAT
> traversal is hard. Most NATs which support UDP create NAT bindings,
based
> on
> the source address of packets, when a packet is sent outwards.
However,
> here, we must create the binding by inspecting the SDP. Thats why ALGs
> were
> needed for UDP.
> 
> So, our solution is to fix that. To do so, we define symmetric RTP
(aka
> bidirectional RTP in the draft). Symmetric RTP runs over UDP, but it
uses
> a
> single connection, rather than two. One participant in a call acts as
the
> active side, and another, the passive side. The active participant
sends
> the
> RTP packet, and the passive side receives it. Packets are sent back
from
> the
> passive user to the active one, using the source address learned from
the
> RTP packet just received. So, lets say Joe calls Bob. Joe acts as the
> active
> side of the RTP connection. When the 200 OK arrives from Bob, it
contains
> Bob's address for RTP; say its IP address X and port Y (abbreviated
> {X,Y}).
> So, Joe sends packets, using source address/port {U,V}, to {X,Y}. Lets
say
> Joe is behind a NAT. Sending this RTP packet creates a binding in the
NAT,
> from {U,V} to {A,B}, and rewrites the source IP address/port of the
packet
> to this pair. When Bob receives this, Bob can send media back to Joe,
> using
> destination address {A,B} and source {X,Y}. These packets arrive at
Joe's
> NAT, and because a binding has been established, the destination is
> rewritten to {U,V}, and then delivered to Joe. Voila. RTP over UDP has
> just
> traversed a NAT without an ALG. The IP address Joe provided in his SDP
was
> never used, which was good, since it was wrong.
> 
> Note that who is active, and who is passive, as far as setting up the
RTP
> connections, is completely unrelated to who initiates the call.
> 
> This little trick means that we can establish RTP-over-UDP calls with
SIP
> through vanilla NATs so long as one side has a public address. This
covers
> a
> huge amount of calling patterns we are seeing, right off the bat,
> including
> PC to phone and phone to PC. In the case where both are behind NATs,
the
> draft describes usage of an RTP translator that can be used as an
> intermediary. Other solutions may be possible depending on how the NAT
> treats UDP packets. More to come.
> 
> I have left out some details about how we determine who is active, and
who
> is passive, and how this is signaled. Well, fortunately for us, there
has
> been some excellent work in mmusic on the following draft:
> 
>
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-00.txt
> 
> which discusses exactly how to use connection oriented media within
SDP.
> All
> we need to do is define an additional keyword, BRTP, or something like
> that,
> to describe this new type of connection oriented media, symmetric (aka
> bidirectional) RTP.
> 
> The draft goes into details about all of this. It requires only small
> changes to existing SIP/SDP/RTP devices to support, and can solve a
> problem
> which I believe will continue to hamper ubiquitous deployment of SIP.
> 
> Comments? I'll be discussing this work in more detail on Friday during
the
> SIP session at IETF 50.
> Thanks,
> Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Mar 2001 02:25:33 -0500

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Thursday, March 15, 2001 10:22 PM
> To: Jonathan Rosenberg; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
> 
> 
> Jonathan,
> 
> 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

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

> 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.

> at all, but you should still consider it...

How does symmetric RTP create a risk of hijacking?

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Mar 2001 23:46:37 -0500

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Friday, March 16, 2001 11:39 AM
> To: Jonathan Rosenberg
> Cc: 'Michael Thomas'; [email-masked]'; [email-masked]';
> [email-masked]'
> Jonathan Rosenberg writes:
>  > > From: Michael Thomas [mailto:[email-masked]]
>  > > Ie, allow RTP on a well
>  > > known port and demux using the SSCR? I seem to
>  > > recall that this has a fatal problem, but I can't
>  > > remember what it is. I really should go re-read my
>  > > Chapman/Zwicky first, but... If we could do this
>  > > your BRTP proposal would make RTP look like any
>  > > old UDP command/response protocol from the
>  > > firewall standpoiont which might interesting.
>  > 
>  > It doesn't work when there are machines that have
>  > multiple processes, each of which is terminating RTP.
>  > Thats because you can no longer use the system provided
>  > demux (ports), and now must resort to a new, intermediate
>  > demux layer (using ssrc). Plus, it would require signaling
>  > the SSRC within SDP/SIP. Much akin to the SCTP stream discussion
>  > in a separate thread on the sip list.
> 
>    On the first part, that's mainly an OS implementation
>    issue; in fact, an OS could just ignore this problem
>    and allow processes to camp on the well known port on 
>    a first come first serve basis and it would probably
>    work sort of OK until things got sorted out.

I don't follow you. If its FCFS, all the other apps won't get any 
of their packets. 

> 
>    The second part is more interesting. I think that
>    we all agree that this would require some sort of 
>    hint in SDP; I believe you suggested calling it
>    BRTP ala the 1890 profile convention (*). If we
>    assumed that that is what was placed into SDP,
>    the normal thing a server does is reverses the
>    source and destination port to reply, and the
>    receiver could just camp on its source port to
>    get the return flow, right? 

Yes.

In fact, you might
>    not even need to modify SDP at all if you got
>    an IANA registered port and used that as the 
>    key of whether to do BRTP or not. 

I generally prefer to be explicit about it. Either way its an extension
to the client in semantics. May as well reflect that in syntax.

Christian writes:
> You discard the SDP information and instead reply to whatever address
> the first RTP packet came from. If this first packet comes 
> from a third
> party, you end up with a session to the third party instead 
> of a session
> to the original target. As I said, this is a mild risk: the 
> third party
> has to be able to find out which port you listen to, and it 
> has to have
> good timing. Also, the third party has to find a way to shut down the
> original target of the call.

The same thing can pretty much happen in current SIP/SDP/RTP. I snoop some
SIP/SDP on the wire, and learn the IP address port the caller is listening
on. I then send them packets. The called party will also send packets to the
caller. The caller can't tell who is the real called party, and who is the
attacker. So, it either plays both (which is what would happen using RTP
semantics - mix all SSRC you receive on a session), drops the call, or picks
one (the wrong one half the time). Seems just as bad. 

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Mar 2001 00:49:09 -0500

> From: Kevin Marks [mailto:[email-masked]]
> Sent: Saturday, March 17, 2001 12:18 AM
> To: Jonathan Rosenberg; [email-masked]'
> Cc: 'Michael Thomas'; [email-masked]'
> At 11:40 pm -0500 16/3/01, Jonathan Rosenberg wrote:
> >I am talking here about NATs which sit between subscribers and their
> >providers, where there is NOT A RELATIONSHIP between the NAT 
> and the proxies
> >run by sip provider. In this scenario, there is no way to 
> connect the NAT to
> >an ALG in the network.
> >
> >Let me give an example. I have a nat box at home. Its made 
> by Linksys. You
> >can buy them in CompUSA for $150. It is meant to be an easy 
> to use, cheap,
> >consumer device. It does not have SIP ALG support embedded 
> in it. Nor does
> >it have controls that allow an external proxy ALG sitting in 
> the network to
> >control it. Nor am I alone in having such NATs. OK, now I 
> want to get SIP
> >service. Apparently, Shiv is proposing that I wait for 
> Linksys to embed an
> >ALG in their $150 box, if that should ever happen, or wait for midcom
> >support in that box, once the standards are complete. He 
> also proposes that
> >my SIP service provider wait to turn on service, until their 
> potential
> >customers get such new boxes.
> 
> So get an Apple AirPort BaseStation. It does NAT, translates RTP, 
> acts as a DHCP server and give you 802.11 connectivity too.
> 

Its not appealing to a service provider to need to tell their customers to
throw away their existing nat boxes, and buy new ones. I'd rather get
service from a provider that allows me to get service without having to
throw things away and buy new ones. It also doesn't work in the case where
the cable provider has a nat. It doesn't work when the subscriber is in an
enterprise, where the business owns a nat. It doesn't work when the
subscriber logs in from a hotel, where the hotel owns the nat. It doesn't
work when the subscriber is at one of those Internet cafe's with lan, and
the cafe owns a nat. It doesn't work when the subscriber is visiting an
internet docking port in an airport, the the airport docking provider has a
nat. In none of these cases, and many others like it, with existing, SIP
unaware nats, can the subscriber tell the owner of the nat to throw it away
and buy a new one. There are an awful lot of nats deployed that don't
understand SIP. A LOT. Can these all be thrown away tomorrow? No. 

Will every nat eventually have a SIP ALG in it? Yes. When? Not for a while.
What I am proposing allows us a transition until that happens. The proposal
also has advantages beyond NAT, such as solving some irritating problems
with multihomed hosts connected through VPN.

-Jonathan R.

---