[MMUSIC] Re: draft-ietf-mmusic-rtsp-nat-00.txt

[Magnus Westerlund <[e-mail]>]

Hi, Philippe,

My comments below:

[e-mail] wrote:

>Magnus,
>
>First bravo for this draft, it is a very useful document.
>
>I have a few comments, mostly about STUN
>(you know I am a STUN fan!)
>
>I note that in the STUN section you write:
>
>" 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."
>
>This is true and it is a very interresting feature indeed,
>but then when you had the reader say "ahah!" and
>start to get really interrested you cold shower it with:
>
>"This creates an unclear demultiplexing point within the
>   server. As this will create implementations difficulties and possibly
>   security problems this SHOULD NOT be done."
>
>I think that a "should not" is really too strong here if it is
>an implementation issue, co-locating is not in itself
>a big issue for exemple a lot of RTSP servers
>are also HTTP servers right?
>(the "possible security problems" would have to be compared
>with the alternative solutions!...)
>  
>

I think this is something we need to discuss further. My current view is 
that due to the lack of a well defined demultiplexing structure between 
media protocol and STUN on the servers ports makes STUN solutions for 
symmetric NATs a bad choice. As pointed out you need to compare the 
media protocols bit structure with STUN request. This is not safe 
operation. I do agree that RTP and RTCP seems to be reasonable safe to 
demultiplex, however it is impossible to know that all protocols media 
protocols will work.

I also find your example with HTTP and RTSP a bad example. HTTP and RTSP 
are distinguished using the nice demultiplexing mechanism of ports. 
Normally HTTP request goes to port 80 while RTSP goes to port number 
540. This is a well defined demultiplexing.

>**************
>
>BTW in the Symetric RTP section you write:
>
>"It has the advantage of working for all types of NATs. However it requires server modifications."
>
>Therefore I conclude that there is no difference
>in terms of implementation between STUN and symetric RTP
>since in both case you need to change the RTSP server,
>and in a similar fashion!
>

Yes, unless you can use STUN to find two port numbers that match the RTP 
rule of consecutive even and odd ports. Both solutions requires updates. 
However STUNs are less from a RTSP protocol perspective.

>
>Also you write in the same section:
>
>"   1. The client knows or has determined by the use of STUN that it is
>       located behind a NAT. It may also determined the type of NAT it
>       is behind."
>
>So If one wants to use Symetric RTP one will have to implement STUN _anyway_ !
>
I need to clarify that this is OPTIONAL behavior that MAY improve the 
performance of the solution.

>For implementers the advantages of symetric RTP are therefore difficult to see ?
>and then the reason why, by comparison, would co-located-STUN get a "SHOULD NOT" gets
>really difficult to understand!
>  
>
As explained before this is not a clean solution.

>****************
>
>Anyway I would propose to reword the section  3.1.3. as:
>
>
>"There are 2 ways to use STUN dependign if the STUN server
>is co-located with the streaming server media distribution ports or not.
>
>3.1.3.1. STUN server outside
>
> Advantages:
>
>   - Does not require RTSP server modifications, totally client
>      implemented tool.
>
>   Disadvantages:
>
>   - Requires a STUN server deployed in the public address space.
>   - Does only work well behind Cone NATs. Does not work with
>      Symmetric NATs.
>
>3.1.3.2. STUN server inside (co-located at the server media distribution
>   ports)
>
> Advantages:
>
>   - Works with all NATs including Symmetric NATs (however see the security section about sending RTP
>data at a different public IP address than the one of the RTSP client).
>
>   Disadvantages:
>
>   - Requires a modified RTSP server with co-located STUN server.
>  
>
In the second case you forgot the disadvantage of not being guaranteed 
to be able to correctly distinguish media packets and STUN request.

Another thing that it seems that I forgot being a disadvantage of STUN 
is that it does not work if the media mappings would get different IP 
addresses, either between each UDP stream or with the TCP connection. 
The reason is the restriction that RTSP must use to prevent DOS attacks.

>**************************************
>
>Last  open issue about STUN:
>
>you describe a number of RTSP modifications for symetric RTP
>and none for STUN while there could be one very useful thing:
>
>In the response to DESCRIBE the server should indicate
>the UDP ports it is planning to use so that the client can immediately
>STUN toward these ports, and then the STUN server reply can
>be used for SETUP (saves a lot of round trips).
>
>The question is how can a server indicate its
>RTP _AND_ RTCP port numbers ?
>
>For example you can do that with a header in the RTSP response:
>
>
>   C->S: DESCRIBE rtsp://foo/twister RTSP/1.0
>           CSeq: 1
>
>   S->C: RTSP/1.0 200 OK
>           CSeq: 1
>           Transport: RTP/AVP;server-rtp-port=4056;server-rtcp-port=4057
>           Content-Type: application/sdp
>           Content-Length: xxx
>
>           v=0
>           o=- 2890844256 2890842807 IN IP4 172.16.2.93
>           s=RTSP Session
>           etc...
>
>Also you can include this informationin SDP,
>which may be better since the client may get the SDP
>by some other means, right?
>
>  
>
Actually you can include this information in the SDP without any extra 
extensions is just the matter of defining the usage. The RTP port number 
can be located in its normal place on the m= line. The RTCP port can be 
set by the attribute defined by
draft-ietf-mmusic-sdp4nat-03.txt. To make this in a good fashion the 
server should define a RTSP feature tag that indicates this 
functionality and that the server should provide the information when 
sending the DESCRIBE response.

I think we need to further discuss the RTSP NAT traversal solutions and 
possible optimization. My draft was intended to be a common ground to 
discuss around.

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