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

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, March 16, 2001 12:56 PM
> To: Jonathan Rosenberg
> Cc: 'Michael Thomas'; Jonathan Rosenberg; [email-masked]';
> [email-masked]'; [email-masked]'
> Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
> 
> 
> 
> And of course there are SIP-ALGs that don't cost an arm and
> a leg that solve all these problems (my biased opinion).
> 
> If SIP proxy vendors are interested in partnering to solve
> this problem for their customers we would welcome that.
> 
> > >
> > > On a different tangent, (never being one to shy
> > > away from having multiple contradictory opinions
> > > on the same subject), plain old firewalls (not
> > > NAT'ing firewalls) are current still a problem
> > > since they typically block the dynamic range for
> > > RTP.
> >
> 
> This problem is solved by a SIP ALG sitting in parallel with
> a this kind of a firewall. AKA a side-car approach in which
> timer based pin holes are created in the SIP-ALG.

I guess I'm just not making myself clear here.

This "side-car" approach, ala midcom, is just fine for service provider
networks, where the provider is rolling out a firewall/NAT and is well aware
of this application, and the need to support it. Same story for an
enterprise rolling out sip internally. Indeed, my company sells just such a
solution. That is NOT the problem space I am talking about.

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. Sounds like a great way to go out of business.
The alternative is that the provider modifies the components they have
control over - the client device and the server, so they work through
Linksys and *any* other NAT their customers might have. Unlike Linksys, who
would need to worry about every protocol that might ever get used (whcih
they simply won't), the sip service provider needs to only worry about one
protocol - sip. The sip provider is the one making money on the service, so
it is them who is motivated to solve this problem.

Another example. Many cable modem providers have NATs that hide their entire
network. Every subscriber that gets cable modem service from one of these
providers is behind a nat, and doesn't even know it. The subscriber wants
sip services from some other provider. There is no way, ever, that the cable
modem provider is going to allow random SIP providers to control their
firewalls. Nor is the cable modem provider motivated to upgrade their nat to
support sip alg. The cable provider won't make any money from it. Their
subscribers aren't using sip services (they can't). Why bother?

This is not a theoretical problem for which we posit the theoretically ideal
solution. I already know the ideal solution, which is to throw all the nats
out and deploy IPV6. Now waiting for that is a really good way to go out of
business.

Solutions like what I am proposing have already been done in countless other
applications, where there were no standards. Even within VoIP, proprietary
VoIP protocols are using solutions like what I describe in order to traverse
NATs (yahoo, MSN, AOL voice). Those guys care about deployment, and so do I.
But, I also care about standards. So, instead of having everyone hack things
up horribly in a proprietary way, I'm proposing a small modification to the
way this stuff is handled, which can help all of us deploy SIP now through
existing NATs. Shiv can wait for everyone to upgrade their NATs (several
years, probably). I'd rather not.

-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: Kevin Marks <[email-masked]>
Date: Fri, 16 Mar 2001 21:18:09 -0800

At 11:40 pm -0500 16/3/01, Jonathan Rosenberg wrote:
>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.

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 20 Mar 2001 09:52:04 -0600

The Apple Air port doesn't have a SIP ALG either. No consumer device does.
It is amazingly, astoundingly unlikely that the residential consumer who is
buying airports today is going to rip them out and put in an "IETF approved
SIP natting midbox controllled by a carrier proxy" tomorrow. It JUST ISN'T
GOING TO HAPPEN.

We have to design our protocols so that they can be used with readily
available off-the-shelf consumer systems if we want those consumers to use
our protocols.

So let's pull our collective ostrich-head out of our happy little
rose-colored sandbox and figure out how to make this stuff work. Jonathan's
definitely on a useful track here. I want to be able to use my SIP phone at
my house, darnit!

Thank you, I feel better now.

--
Dean

----- Original Message -----
From: "Kevin Marks" <[email-masked]>
To: "Jonathan Rosenberg" <[email-masked]>;
<[email-masked]>
Cc: "'Michael Thomas'" <[email-masked]>; <[email-masked]>
Sent: Friday, March 16, 2001 11:18 PM
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal