Re: [MMUSIC] WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-05

[Flemming Andreasen <[e-mail]>]

The WGLC for the RTSP NAT Evaluation draft is now closed.

We will need resolution to the comments below and an updated document 
addressing them as the next steps before we can move forward.

Thanks

-- Flemming (MMUSIC co-chair)


On 10/11/12 3:35 PM, Flemming Andreasen wrote:
> I have reviewed the RTSP NAT Evaluation document and have several 
> comments on it, both technical and editorial. I will provide the main 
> technical comments below and send the minor and editorial comments 
> directly to the authors in a more "user-friendly" format.
>
>
> Major comments
>
> - STUN based on either RFC 3489 or RFC 5389 (or both). The draft 
> discusses use of STUN as a NAT traversal mechanism (with some RTSP 
> operational "extensions"), and in so doing it references both RFC 3489 
> (which is obsolete) and RFC 5389 (the replacement). Furthermore, in 
> several places, it bases and describes operation on now defunct 
> (obsolete) RFC 3489 logic and messages instead of RFC 5389. This 
> either needs to be rectified, or we should have a very good 
> explanation in the document as to why we are using RFC 3489 (and then 
> be clear which parts are based on RFC 3489 and which are based on RFC 
> 5389).
>
> - "Symmetric RTP" is called out as a potential solution for NAT 
> traversal with 3 different variations. Note that symmetric RTP is 
> defined in RFC 4961, and what is described in this document as 
> "symmetric RTP" looks a lot more like latching to me, with all the 
> potential issues that brings (and then some due to the shared use of 
> ports and hence shared SSRC space between different clients, as noted 
> in the document). The document needs to clear up its terminology in 
> this area ("connect", "binding", latch, symmetric RTP, etc.) and be 
> clearer about what is being proposed (which is latching as far as I 
> can tell, however it makes reference to certain mechanisms that aren't 
> fully described, e.g. binding packets with random nonces).
>
>
> Other significant comments
>
> - The draft intends to investigate and outline different RTSP NAT 
> traversal proposals with the goal of picking one for further detailed 
> specification (which can be found in the draft-ietf-mmusic-rtsp-nat 
> spec). There is a mixture of RFC 2119 language and more informal 
> language in several of these descriptions. Given that these are 
> high-level descriptions and have not been specified in detail, I do 
> not think we should give any other impression and hence I think RFC 
> 2119 language should be avoided.
>
> - The draft suggests that the RTSP server needs to enforce that 
> signaling and media come from the same IP-address as a security remedy 
> in several places, however this may not work with larger scale NATs 
> (e.g. carrier-grade NATs) where the NAT may be using more than one 
> external IP-address.
>
> - The comparison section is missing two of the alternatives considered 
> (namely ALG and TCP tunneling). Also, the comparison chart would lead 
> most people to a different solution than the one chosen. To some 
> extent, I think it's because the requirements list is a simplified 
> list of all the considerations behind each of the proposals (as more 
> fully explained in the document overall). There are additional 
> drawbacks to some of these other solutions that do not show up in the 
> table (e.g. unauthenticated "latching" and requirement for RTSP server 
> to have public IP-address). It would be worthwhile briefly recapping 
> those and hence further motivate the choice of ICE in this section.
>
> Thanks
>
> -- Flemming
>
>
>
> On 9/23/12 11:52 PM, Flemming Andreasen wrote:
>> This is to announce a 2 week Working Group Last Call for
>>
>>     draft-ietf-mmusic-rtsp-nat-evaluation-05
>>
>> as Informational. Please review and provide any comments you may have 
>> on the document by October 7, 2012. Comments should be sent to the 
>> document authors and the MMUSIC WG list. If you review the document 
>> but do not have any comments, please send a note to that effect as well.
>>
>>
>> Thanks
>>
>>        Flemming
>>
>>
>>
>> Draft Info:
>>
>> This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.
>>
>> 	Title           : The Evaluation of Different Network Addres Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)
>> 	Author(s)       : Magnus Westerlund
>>                            Thomas Zeng
>> 	Filename        : draft-ietf-mmusic-rtsp-nat-evaluation-05.txt
>> 	Pages           : 38
>> 	Date            : 2012-05-07
>>
>>     This document describes several Network Address Translator (NAT)
>>     traversal techniques that was considered to be used by Real-time
>>     Streaming Protocol (RTSP).  Each technique includes a description on
>>     how it would be used, the security implications of using it and any
>>     other deployment considerations it has.  There are also disussions on
>>     how NAT traversal techniques relates to firewalls and how each
>>     technique can be applied in different use cases.  These findings
>>     where used when selecting the NAT traversal for RTSP 2.0 standardized
>>     in the MMUSIC WG.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-05.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-05.txt
>>
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation/
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic