Subject: A reason to put RTSP server behind NAT (was RE: [MMUSIC] What is symmetric RTP?)

From: Thomas Zeng <[email-masked]>
Date: Fri, 28 Mar 2003 13:09:31 -0800

Magnus:

I would like to chime in to add an use case for putting RTSP server behind a
firewall.

Imagine a startup company wanting to install a live camera in a daycare to
offer "nannycam" services. The live camer feeds audio and video to a RTSP
server (running on the same CPU) for paid clients to view  their kids  by
connectting a RTSP video player. It's well-known that some big companies
offer
streaming video in their company daycares to their employees. Now someone
just wants the same service in other kids' daycare (so as to bridge the 
digital gap, among other things :-)

The daycare has a combo cable modem / NAT box to run a private network of a
few computers, one of which hosts the live camer as well as the RTSP server.

This is a case where RTSP server is behind a server NAT, while clients may
or may not be behind another NAT. Clients out side of the server NAT can
connect because the NAT box can forward RTSP port to the RTSP server
computer (via, say, Linux ipchains commands).

Of course one can ask the daycare to put the RTSP server box in the open,
but that means additional cost (it costs $5 dollars/month to get even a
dynamic IP address from Time-Warner cable company here in San Diego), some
one time fee to change network topology -- not to mention security
degradation.

Do you think this application is a legitimate use of RTSP protocol?

- thomas

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Friday, March 28, 2003 6:47 AM
To: Magnus Westerlund
Cc: [email-masked]
Subject: Re: [MMUSIC] What is symmetric RTP?

Magnus Westerlund wrote:

>> That said, I still believe that it is desirable to align RTSP NAT 
>> solutions with SIP. Symmetric RTP is nice, but it is not as general as 
>> the ICE-based approach I have proposed. There are many topologies 
>> where symmetric RTP will not work. Any topology where the server 
>> itself is behind a NAT. A good example is two enterprises. Lets say 
>> there is a manufacturer that makes widgets. They have customers in 
>> lots of enterprises. They want to run an RTSP server inside their 
>> enterprise, so users can connect and see videos providing customer 
>> support. If the customer enterprises are natted, and so is the widget 
>> manufacturer, symmetric RTP will not help. ICE would figure out the 
>> best approach. The only case in which ICE requires more than one 
>> exchange to work in this case is when both NATs are full-cone. In such 
>> a case, you can eliminate the second ICE exchange if you use a TURN 
>> relay.

> I can understand your desire to align RTSP and SIP. However when it 
> comes to usage of ICE it definitely gets problematic. First RTSP does 
> not have the SETUP exchange in place to accommodate something like ICE 
> need for one or more exchange with parameters both for the STUN server 
> and the given addresses. I don't say it is impossible however more work 
> will be needed to look at how it could be included. Then one will see 
> how many modifications it would requires. In the end it might be simpler 
> to take on the SIP session initiation and only keep RTSP's media 
> control.  However this is a radical proposal that would significantly 
> change the protocol.

Well, I suspect it would not change the protocol so much as only use a 
subset - the parts for control.

Regarding having RTSP itself support an offer/answer exchange with 
SETUP, generally only one exchange would be needed. So, its just an 
issue of putting more than one address in the SETUP.

> 
> One question I would like to know is how big the envisioned problem will 
> be with servers that reside in NATed networks. I can understand that SIP 
> must consider all cases as it set up communication between users which 
> are more likely to have NATed addresses. However looking at RTSP which 
> has a clear client to server structure, much like HTTP. If you move a 
> server to a NATed address you will also have problem setting up the TCP 
> connection. You simple will require a proxy between the address domains 
> to be able to communicate. Are there many that deploy HTTP servers in 
> private address spaces and actually intend them to be used by other 
> address domains? So far my view has been that as this is server, the 
> server owner can ensure that the server has an IP address that makes it 
> reachable by the intended clients. So in your widget manufacturer 
> example above, why does not he deploy the server in the public IP space. 
> I would assume that he has HTTP server that are also reachable. If you 
> don't share my opinion on this please speak up and give some motivation 
> why this is a useful example.

I think that you are making a fair point; if the widget manufacturer 
meant for this server to be reachable, they need to give it a public 
address.

I think the cases where this might not be true is where "server" becomes 
more loosely defined. You have in mind a big server meant for consumer 
streaming media applications. However, I can imagine using RTSP to do 
things like retrieve voicemails, and even control streams shared 
directly between two users (for example, one user calling another with 
sip and letting the called party hear an mp3 that the caller has on 
their PC). All of these are, IMHO, good uses for RTSP, and none of them 
will work with the symmetric-RTP only approach you are advocating.

[tzeng's comments start] 

[tzeng's comemnts end]

So - are these places you want RTSP to work?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 31 Mar 2003 10:14:11 +0200

Hi Thomas,

I think the application in itself is a valid one. However if one 
provides services that is assumed to be used from the the public net I 
still think it is a reasonable thing to assume that the service provider 
(nanny cam host) in this case uses a public IP address.

I think that Jonathan is right in his observation of the big question. 
Will private persons run RTSP servers to provide functionality in for 
example conversational calls. If the answer is yes, then we need to 
address the RTSP servers behind NAT problem. However looking at the 
current market it seems that the important question is how to solve the 
RTSP server in public network first. If someone is ready to start 
digging into solving this problem, please go ahead and provide input. 
The design of the solution for public IP RTSP servers may need to 
consider something out of a proposal for how to solve the private IP 
RTSP server problem. However it is obvious that such a solution must 
also address how to establish the control connection to the server.

Last I have one comment to what you write:

>one time fee to change network topology -- not to mention security
I kind of react to the last thing. Security degradation: NATs does not provide any security protection, it only provides some obscurity. A NATed machine may of course not be reachable and can therefore not be be directly attacked. However this a firewall can also provide. The major problem is the huge security gap that the deployment of a NAT creates. With NATs there is basically no guaranteed protection against hijacking or eavesdropping attacks as it is impossible to source authenticate. So saying that removing the NAT will reduce the security I think is wrong. 

Best Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]