Re: [MMUSIC] RTSP and NATs

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 <mmusic@ietf.org>                                              
                                                          Subject:    Re: [MMUSIC] RTSP and NATs                                              

               Magnus Westerlund                          Classification:                                                                     
               <magnus.westerlund@era.ericsson                                                                                                
               .se>                                                                                                                           

               05/02/2003 19:45                                                                                                               

Hi Philippe,

philippe.gentric@philips.com 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: magnus.westerlund@era.ericsson.se

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic