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

Magnus,

I expect indeed that we will discuss this more especially during the SFO meeting and I agree your draft is an excellent basis!

you write:

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

Well I dont know about other protocols but the use of STUN in the RTSP scenario is *extremely* safe:

1) your client sends and receives STUN on the UDP ports it has choosen for RTP and RTCP
_but_ since this is *before* the SETUP  there is *only* a STUN client behind these UDP ports,
(the RTP/RTCP stack does not have to be initialized yet). And vice versa
i.e. as soon as STUN completed you can stop the STUN client to
start the RTP/RTCP session !

=> so on the client side it is totally safe.

2) the server does NOT listen for incomming data on the RTP ports:
there will be the STUN server listening behind these ports, nothing else

=> no possible collision of STUN with RTP on the server side

3) then the server needs to  distinguish between RTCP RR
and STUN on the RTCP port but the headers are _really_ different.

for starters the first bit is different  (1 for RTCP, 0 for STUN)!

but let us imagine that a STUN packet (of an hypothetical future extended version!)
will by chance match the first 32 bits of a paussible RTCP RR packet,
then what is the probability of having the 32 bits SSRC (random, fixed per transaction)
match the first 32 bits of the 128 STUn tID (random, changing every message) ?
2 to the power 64 ?

etc ...

I dont see how even the worse implementation can collide ?

> As explained before this is not a clean solution.

"Striving to better, oft we mar what's well." (William Shakespeare)

regards,

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

                                                          To:   Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1                                     
                                                          cc:   mmusic@ietf.org                                                               
                                                          Subject:    [MMUSIC] Re: draft-ietf-mmusic-rtsp-nat-00.txt                          

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

               Sent by:                                                                                                                       
               mmusic-admin@ietf.org                                                                                                          

               28/02/2003 11:28                                                                                                               

Hi, Philippe,

My comments below:

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

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