Re: [MMUSIC] RTSP and NATs

[Magnus Westerlund <[e-mail]>]

Hi Philippe,

Thanks for replying and giving your input. Comments inline.

[e-mail] wrote:

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

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.


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

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

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.

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

>
>4) you also need to send packets periodically to keep
>the NAT mappings "open". But the issue here is simply
>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 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]



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