Subject: Re: [MMUSIC] RTSP and NATs

From: [email-masked]
Date: Mon, 10 Feb 2003 17:13:39 +0100

Jonathan you wrote:

>I agree that symmetric RTP is clearly the best solution for RTSP as it
>is used today. I do not believe that relying on source IP being the same
> between the RTSP and RTP sessions is a good idea. This won't work in
>enterprises which may be natting into a multiplicity of IP addresses.

YES!
I fully agree, (see item 3 below)

Magnus,

(Sorry for the delay in responding to previous RTSP&NAT)

Having a RTSP server and a STUN server co-located at the same port
is no concern for us neither in terms of security nor in terms of implementation,
or to be more specific it is largely worth the trouble !
i.e. the trade of is rather simple: either you do that or
NATs will prevent you from using RTSP....

And yes, magnus, you are right, the first key issue is to inform the client about the ports
the server will be listening for incomming STUN packets,
which need to be the RTP and RTCP ports....

*******************************************

let me summarize the 4 open issues I see for RTSP/STUN/NAT:

(1) server signals its RTP and RTCP ports:

it can be done either:
(a) in the SDP (since its per-media ?) as in draft-ietf-mmusic-sdp4nat-03.txt
or
(b) in the headers of the response to DESCRIBE or SETUP

Note that if SETUP is used it is a failed-in-advance attempt
("hey, try again, because this wont work") causing 1 round trip,
so I dont like this solution much, and also there are cases when
you dont use DESCRIBE ...
so I would prefer solution (a)SDP.

2) there is the possiblity that inside DESCRIBE and/or SETUP the client
gives its IP address, then the server could compare this transported client IP
with the apparent IP address of the client,
Then the server could make a specific reply:
-we would need to define a new status-
for example:

 "463: See you from behind a NAT, use STUN on designated ports"

But this solution would only be a safe-guard,
I mean it is smart to assume that:

"When the server indicates explicit RTP and RTCP ports,
the client SHOULD send STUN queries toward the server
at these port numbers and wait for STUN responses
indicating the possible presence of NAT."

so that if you prefer to wait for a possible 463...
you loose... a round trip !-) too bad!

3) One key missing item  (as noted by Jonathan)
is also the capability at SETUP to indicate not only a specific
port number but also a specific IP address since through
some NATs RTP and RTCP packets will come out not only with
an (apparently) random port number but also
from a different apparent IP address !

So we _must_ add this capability....(but it is no big deal right?)

4) you also need to send packets periodically to keep
the NAT mappings "open". But the issue here is simply
to document that, right ?

regards,

Philippe Gentric
Software Architect
Philips MP4Net
"philippe dot gentric at philips dot com"
http://www.platform4.philips.com

                                                                                                                                              
                                                          To:   Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1                                     
                                                          cc:   IETF MMUSIC WG <[email-masked]>                                              
                                                          Subject:    Re: [MMUSIC] RTSP and NATs                                              
                                                                                                                                              
               Magnus Westerlund                          Classification:                                                                     
               <[email-masked]                                                                                                
               .se>                                                                                                                           
                                                                                                                                              
               05/02/2003 19:45                                                                                                               

Hi Philippe,

[email-masked] wrote:

>Magnus,
>
>I strongly support the recommendation to not use ALGs,
>therefore STUN should be used instead but then you wrote:
>
>
> > To be able to use STUN to traverse symmetric NATs the  STUN  server
> >  needs to be co-located with the streaming server media distribution
> >  ports. As this will create implementations difficulties and  possi-
> > bly security problems this SHOULD NOT be done.
>
>I am surprised, I would have proposed _on the contrary_ a "SHOULD" here
>(since traversing symetric NATs is a key feature) !
>
>
>also what do you mean by  "implementation difficulties" ? (I really cannot see any ?)
>and could you explicit what type of _additional_ security issues this would cause
>(i.e. issues that are not inherent to running either a RTSP or a STUN server in the first place ?)
>
>
The problem of running STUN for a symmetric NAT is that the STUN server
must be located at the servers sending port. So using the same RTSP
mechanism that are used for traversing a cone-nat the client would:
1. first contact a well known port with the server for each his media
stream to get the mapping of the stream. The client can't use any other
then the well known port because it doesn't know what port to send to.
2. In the SETUP ask the server to send from its STUN servers well known
port. It also needs to receive RTCP on that port.
3. For keep alive on the RTP port the client needs to send periodically
STUN messages to the STUN server.

This is a mess for a implementor. It need to have a STUN server
receiving the STUN messages while the RTP/RTCP stack should receive all
other messages. Also all the clients need to reside on the same port
number which creates a multiplexing nightmare.

If you change the setup phase so that the streams are first SETUP to
dummy ports then reconfigured with a later message, the STUN could be
located at each media streams source address. However in this setup it
is actually better to use symmetric RTP in all regards except perhaps
hi-jacking of media streams. However with certain restrictions you can
actually end up with at least the same level of security that RTSP
provides today.

How are you using STUN to traverse a symmetric NAT?

Best Regards

Magnus

--

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]

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Feb 2003 12:02:25 +0100

Hi Philippe,

Thanks for replying and giving your input. Comments inline.

>NATs will prevent you from using RTSP....

Yes, but co-locating STUN and RTP/RTCP sender ports does create 
demultiplexing problems. There is no real multiplexing point between 
these two protocols. Both will be run over IP/UDP. No indication in UDP 
points out if the UDP payload is a STUN message or a RTP/RTCP message. 
Matching based on message structure is not a sure thing. Therefore I 
would much rather use another approach.

 From this point of view symmetric RTP may be a much better solution 
from the multiplexing perspective. Of course this has the security 
problems. The advantage of symmetric RTP using SSRC as identifier is 
that is has no demultiplexing problem and at least gives basic security. 
For all others than the man in the middle guessing correctly a 32 bit 
number is rather hard. And the man in the middle is still impossible to 
protect against.

>which need to be the RTP and RTCP ports....
One solution would be to use the well known port of STUN. That allows a 
client to first initiate a STUN request to the server. Upon detecting 
the clients public IP/port it sends a RTSP SETUP with this information 
and actually tells the server by using Server_port of the STUN port that 
it would the server to send media from these ports. This of course has 
the problem that the server will need to demultiplex all incoming 
RTP/RTCP traffic based on source IP/port to know which session it 
belongs to. Also any type of load balancing between ports will be 
impossible.

To achieve load balancing between ports it will be a requirement to have 
signaling indicating which port the client shall connect the different 
flows to when doing STUN. It will still be required for the client to 
tell the server which port it must use.

>you loose... a round trip !-) too bad!

Might be a good addition. A question, are you assuming that any request 
containing destination IP that mismatch the source of the control flow 
will behind a NAT? This will then not work for non-transparent proxies. 
Actually I think we have a large problem in RTSP with proxies and where 
to send the media data. If a proxies is part of the TCP path to a server 
that connection will not have source IP equal to destination address of 
traffic. Then a server shall not send traffic to that source.

>from a different apparent IP address !
I think a solution like what Tom has suggested will be required to fix 
this in a general way. However this solution has one very big problem 
with it. It opens up the DOS attack possibilities of RTSP. If your 
allowed to freely specify any IP/port this mechanism will be the certain 
choice of any DOS attacker. So we can't allow this to be used because 
this have worse security properties than symmetric RTP. So either we 
accept that  NATs that gives out different IP address to the same client 
does not work or it will be required to create a security scheme that 
allows us to authorize the destination of the media traffic.

>So we _must_ add this capability....(but it is no big deal right?)
It is solveable but it will only work with servers that has been 
updated. But this is of course true with any
server side changes.

>to document that, right ?
Yes, that is true independent which NAT traversal technique you use, 
STUN, or symmetric RTP.

Some conclusions:
Actually using STUN might not be possible at all from a security 
perspective if the TCP connection comes from a different IP addresses 
then the media streams. This will only work for single IP address NATs. 
Other solutions needs an authorization mechanism for the destination.

Symmetric RTP seems to have better security despite all. Also it works 
for symmetric NATs without creating multiplexing problems, at least if 
we rely on RTP/RTCP's SSRC.

Best Regards

Magnus Westerlund