Re: Gen-ART and OPS-Dir review of draft-ietf-mmusic-rtsp-nat-evaluation-14

[Magnus Westerlund <[e-mail]>]

Hi David,

I have finally gotten to do the update of this document. I thank you
very much as I believe the document has gotten substantially better and
more consistent due to your and Sarah Banks review comments.

I will say upfront that the updated version has not become a
masterpiece, but it will suck a bit less. My view is that this document
contains some valuable pieces of information, but it is not worth
spending tons of time in editing.

I have some inline response to your comments and question below.

Black, David skrev den 2014-06-15 04:56:
> 
> Document: draft-ietf-mmusic-rtsp-nat-evaluation-14
> Reviewer: David L. Black
> Review Date: June 14, 2014
> IETF LC End Date: June 13, 2014
> 
> 
> Major issues:
> 
> [1] The abstract characterizes this draft as the evaluation that lead to
> the mmusic WG's choice of the NAT traversal technique for RTSP, but
> the evaluation in this draft did not drive that choice, as indicated
> in Section 6:
> 
>    Looking at Figure 1 one would draw the conclusion that using TCP
>    Tunneling or Three-Way Latching is the solutions that best fulfill
>    the requirements.  The different techniques were discussed in the
>    MMUSIC WG.  It was established that the WG would pursue an ICE based
>    solution due to its generality and capability of handling also
>    servers delivering media from behind NATs.
> 
> OTOH, there appears to be a lot  of useful material in this draft that
> should be published in an informational RFC, not only the comparison, of
> NAT traversal techniques, but also documentation of some of those
> techniques, as indicated in Section 4:
> 
>    This section includes NAT traversal techniques that
>    have not been formally specified anywhere else.  The overview section
>    of this document may be the only publicly available specification of
>    some of the NAT traversal techniques.
> 
> This may be fairly simple to address, as the last sentence in the
> abstract and the Section 6 text quoted above are the primary sources
> of this issue.  It may also help to change the title of this draft
> from "The Evaluation of ..." to "Comparison of ..." and do something
> analogous to other occurrences of the word "evaluation" in this draft.
> 

Yes, I have attempted to do what your suggest. I think it mostly
resolves the issue.



> 
> [2] Section 4 says:
> 
>    Some other techniques have been recommended against or are no longer
>    possible due to standardization works' outcome or their failure to
>    progress within IETF after the initial evaluation in this document,
>    e.g.  RTP No-Op [I-D.ietf-avt-rtp-no-op].
> 
> That's too vague, an explicit list should be provided of techniques in
> Section 4 that should not or cannot currently be used, starting with RTP
> No-Op including an explanation of why that is the case for each technique.
> There's also an important editorial clarification needed - these
> "other techniques" are not NAT traversal techniques; they are possible
> elements of some NAT traversal techniques.
> 
> This text is 4.1.1 is part of this issue:
> 
>    The first version of STUN [RFC3489] included categorization and
>    parameterization of NATs.  This was abandoned in the updated version
>    [RFC5389] due to it being unreliable and brittle.  Some of the below
>    discussed methods are based on RFC3489 functionality which will be
>    called out and the downside of that will be part of the
>    characterization.

I have attempted to be clearer in the text when methods are based on
either deprecated or abandoned proposals. However, from my perspective,
especially for abandoned work, if one would have wanted to pursue a
mechanism based on abandoned work it could have been resurrected.
Deprecated is worse as that usually have a good motivation behind its
removal.

> 
> Minor issues:
> 
> -- Section 2, last paragraph.
> [E]
>    Note that if neither RTCP packets nor RTSP
>    messages are received by the RTSP server for a while, the RTSP server
>    has the option to delete the corresponding RTP session, SSRC and RTSP
>    session ID, because either the client can not get through a middle
>    box NAT/firewall, or the client is mal-functioning.
> 
> Is there any delay recommended before RTSP server reuse of that set of
> identifying information (RTP session, SSRC and RTSP session ID)?

No, to my knowledge there exist no such recommendation. However, the
RTSP session is basically defined by the RTSP session context and the
used 5-tuples. The SSRC are scoped by session, and should be randomly
generated to minimize the risk of collision. RTSP session IDs needs to
be generated with very low probability of collision with any recently used.



> 
> [I] Still in Section 3
> 
>    Note a simple preventative measure commonly
>    deployed is for the RTSP server to disallow the cases where the
>    client's RTP receiver has a different IP address than that of the
>    RTSP client.  With the increased deployment of NAT middleboxes by
>    operators, i.e. carrier grade NAT (CGN), the reuse of an IP address
>    on the NAT's external side by many customers reduces the protection
>    provided.  Also in some applications (e.g., centralized
>    conferencing), dual-hosted RTSP/RTP clients have valid use cases.
>    The key is how to authenticate the messages exchanged during the NAT
>    traversal process.
> 
> Is that "measure commonly deployed" recommended?  The above text chunk
> feels like Security Considerations text, and this text could usefully
> be moved to Section 8.

In RTSP 2.0 this is well documented and recommended practice. See
Section 21.2.2 in
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/

> 
> [J] Section 4.1.1 relies on STUN's abandoned NAT type classification
> functionality to determine where to send the hole-punching UDP packets.
> What's wrong with always sending those packets to the "server's source
> address/port"?  That should work for both types of NATs, thereby removing
> the dependency on STUN classification of NAT types.

Actually that is not the main reason. The difference between 4.1
Stand-alone STUN and 4.2 Embedded STUN is where the STUN server is. In
4.2 the STUN server is sharing the server port, thus taking care of
handling the STUN requests and sending respone. For 4.1 the server can
be either on its own IP or share IP but have a different port compared
to the RTSP server. The classification method is basically to detect
cases where the method would fail, prior to really attempting them. One
could skip the classification and instead fail during SETUP. But that
will result in the server starting to send media, which will not be
delivered to the client. This late failure I think is desirable to
avoid. But, this has been clarified:

   The first version of STUN [RFC3489] included categorization and
   parameterization of NATs.  This was abandoned in the updated version
   [RFC5389] due to it being unreliable and brittle.  This particular
   traversal method uses the removed RFC3489 functionality to detect the
   NAT type to give an early failure indication when the NAT is showing
   the behavior that this method can't support.  This method also
   suggest using the RTP NO-OP payload format [I-D.ietf-avt-rtp-no-op]
   for key-alives of the RTP traffic in the client to server direction.
   This can be replaced with another form of UDP packet as will be
   further discussed below.

> 
> [K] Why are ALG considerations only applicable to STUN-based techniques?

They are applicable to all cases. I have corrected this in this version.
In most cases the main finding about ALGs was listed in the Deployment
considerations.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------