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

[Flemming Andreasen <[e-mail]>]

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