[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MMUSIC] RTSP and NATs

Hi Philippe,

Thanks for replying and giving your input. Comments inline.

philippe.gentric@philips.com 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 +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