Telechat Review of draft-ietf-mmusic-rtsp-nat-evaluation-15
review-ietf-mmusic-rtsp-nat-evaluation-15-opsdir-telechat-black-2015-05-15-00

Well, it's been almost a year since the review of the -14 version, but the draft
has now been revised, and significantly improved.

Document: draft-ietf-mmusic-rtsp-nat-evaluation-15
Reviewer: David L. Black
Review Date: May 10, 2015
IESG Telechat Date: May 14, 2015

Summary: This draft is almost ready for publication, but has nits that
should be corrected before publication.  

The -15 version has significant changes in response to the Gen-ART/OPS-Dir
review of the -14 version, e.g., addition of quite a bit of new text on ALG
considerations.  The two major issues from the review have been resolved
as follows:

> [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,

The title change to the draft, plus several other text changes, notably
to the first sentence of the second paragraph of Section 4, suffice to
address this concern.

> [2] (problems with vague descriptions of mechanisms)

The RTP No-OP discussion has been significantly rewritten and text has
been added Section 4.1.1 on STUN characterization of NATs to address
this vagueness concern.

All of the minor issues have been addressed.

-- Editorial Comments:

Section 4.6.5

OLD
	The three way latching is significantly securer than
NEW
	Three way latching is significantly more secure than

I saw a number of other editorial items in the newly added text that
I'll leave to the RFC Editor.

idnits 2.13.02 found an obsolete reference:

  -- Obsolete informational reference (is this intentional?): RFC 3489
     (Obsoleted by RFC 5389)

This is intentional, as the draft refers to an obsolete STUN feature
in that obsolete RFC, so this idnits complaint can be ignored.

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Saturday, June 14, 2014 10:57 PM
> To: Magnus Westerlund (magnus.westerlund at ericsson.com); thomas.zeng at gmail.com;
> General Area Review Team (gen-art at ietf.org); ops-dir at ietf.org
> Cc: mmusic at ietf.org; ietf at ietf.org; Black, David
> Subject: Gen-ART and OPS-Dir review of draft-ietf-mmusic-rtsp-nat-evaluation-
> 14
> 
> This is a combined Gen-ART and OPS-DIR review.
> Boilerplate for both follows ...
> 
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> <

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> I have reviewed this document as part of the Operational directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments
> were written primarily for the benefit of the operational area directors.
> Document editors and WG chairs should treat these comments just like any other
> last call comments.
> 
> Document: draft-ietf-mmusic-rtsp-nat-evaluation-14
> Reviewer: David L. Black
> Review Date: June 14, 2014
> IETF LC End Date: June 13, 2014
> 
> Summary: This draft is on the right track, but has open issues
> 		described in the review.
> 
> This draft describes and evaluates a number of proposed NAT traversal
> mechanisms for RTSP.  The draft covers a lot of detailed material
> about the proposed mechanisms, and necessarily assumes that the reader
> has some reasonable familiarity with NAT and RTP concepts.
> 
> 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.
> 
> Also in the text quoted from section 4 above "overview section" is
> misleading, as the documentation is in Section 4 - I suggest deleting
> "The overview section of". [Editorial]
> 
> [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.
> 
> Minor issues:
> 
> [A] Firewall paragraph in Introduction confuses ALG implementation with
> firewall configuration (presumably UDP pinholes).  It needs to clearly
> separate those two concepts, as the current text implies that punching
> a UDP (pin)hole is part of the firewall implementation, whereas it's
> actually part of the operational configuration of the firewall.
> 
> [B] Still in the Introduction (Section 1):
> 
>    At the time when the bulk of work on this document was done, a single
>    level of NAT was the dominant deployment for NATs, and multiple level
>    of NATs, including Carrier Grade NATs (CGNs) has been only partially
>    considered.
> 
> That's vague - please provide a clear statement of what is out of scope for
> this draft.  It looks like everything other than Basic NAT techniques is
> out of scope.
> 
> -- Section 1.2
> [C]
>    Many organizations
>    use firewalls to prevent privacy intrusions and malicious attacks to
>    corporate computing resources in the private intranet [RFC2588].
> 
> Please remove the word "privacy" - I don't believe it's correct in this
> context, as many of the intrusions are intended to compromise far more than
> privacy. I would also change "to prevent" -> "to counter" as many current
> attacks are not prevented by firewalls.
> 
> This needs more explanation:
> 
>    2.  NAT does not in itself provide security, although some access
>        control policies can be implemented using address translation
>        schemes.  The inherent filtering behaviours are commonly mistaken
>        for real security policies.
> 
> At a minimum, explain what sort of "security" is not provided.  In addition,
> I suggest noting that a NAT can provide some privacy by concealing
> address/port
> usage on the private side of the NAT.
> 
> [D] Still in Section 1.2:
> 
>    In the rest of this memo we use the phrase "NAT traversal"
>    interchangeably with "firewall traversal", and "NAT/firewall
>    traversal".
> 
> No, don't do that, please.  This is a NAT traversal document that considers
> the effects of NAT traversal techniques on firewalls, so the term "NAT
> traversal" should be the primary term.
> 
> -- 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)?
> 
> -- Section 3
> [F]
>    3.  Should have minimal impact on clients not behind NATs and which
>        are not dual-hosted.  RTSP dual-hosting means that the RTSP
>        signalling protocol and the media protocol (e.g.  RTP) are
>        implemented on different computers with different IP addresses.
> 
>        *  For instance, no extra delay from RTSP connection till arrival
>           of media
> 
> By comparison to requirement R3 in Section 6, the above text is too broad.
> The R3 requirement considered in this draft is specifically about additional
> protocol round trips; "extra delay" could be introduced for other reasons.
> 
> [G] Still in Section 3
> 
>    4.  Should be simple to use/implement/administer so people actually
>        turn them on
> 
>        *  Otherwise people will resort to TCP tunneling through NATs
> 
> Not so fast ... TCP tunneling is one of the evaluated techniques (see
> Section 4.8), so that text isn't right.  Deletion of the
> "* Otherwise ..." sub-bullet should suffice to deal with this.
> 
> [H] Still in Section 3
> 
>    5.  Should authenticate dual-hosted client transport handler to
>        prevent DDoS attacks.
> 
> What's a "dual-hosted client transport handler" ???  I suggest adding
> this term and dual-hosting/dual-hosted to the Glossary in Section 1.3.
> 
> [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.
> 
> [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.
> 
> [K] Why are ALG considerations only applicable to STUN-based techniques?
> 
> -- Section 4.3.4 Disadvantages list
> [L]
>    o  Assumes that it is possible to de-multiplex between the packets of
>       the media protocol and STUN packets.
> 
> That is actually possible, although the demux technique is not exactly
> elegant Add a pointer to Section 5.1.2 of RFC 5764 for information on
> how this can be done.
> 
> -- Section 4.4.1
> [M]
>    Latching [I-D.ietf-mmusic-latching] is a NAT traversal solution that
>    is based on requiring RTSP clients to send UDP packets to the
>    server's media output ports.
> 
> Well, draft-ietf-mmusic-latching is about to be approved for publication
> as an RFC, but it does not apply to RTSP.  Additional RTSP extension work
> would be required, as specified in section 4.4.2. Please make that clear
> at the start of this section, and include a forward pointer to section 4.4.2.
> 
> [N] Section 4.6 - Where are the security considerations for 3-way Latching?
> 
> -- Section 4.8.4
> [O]
>    It is not possible to
>    get any amplification effect for denial of service attacks due to
>    TCP's flow control.
> 
> That's not correct or at least not a complete discussion of denial of service
> possibilities - if an attacker can cause a lot of TCP SYNs to be sent to a
> target/victim, the result can be a DDoS attack.  The text quoted above needs
> to be rewritten to address this possibility.
> 
> Nits/editorial comments:
> 
> There are additional editorial cleanups that I'll leave to the RFC Editor,
> but I noted a few things that seem to deserve mention here:
> 
> - Section 1, 1st paragraph
> 
>    Today there is a proliferate deployment of different flavors of
> 
> "proliferate" -> "proliferating", "flavors" -> "types"
> 
> -- Section 1.1:
> 
>    "This document uses the term "address and port mapping" as the
>    translation between an external address and port and an internal
>    address and port.  Note that this is not the same as an "address
>    binding" as defined in RFC 2663."
> 
>       Note: In the above it would be more correct to use external
>       instead of public in the above text.  The external IP address is
>       commonly a public one, but might be of other type if the NAT's
>       external side is in a private address domain.
> 
> That's confusing - I think this can be improved by using more precise
> terms in the first sentence (including adding quotes):
> 	 external instead of public ->
> 		 "external IP address" instead of "public IP address"
> 
> -- Section 2
> 
>    The loss of a
>    RTP mapping can only be detected when expected traffic does not
>    arrive.  If a client does not receive data within a few seconds after
>    having received the "200 OK" response to a PLAY request, it may be
>    the result of a middlebox blocking the traffic.
> 
> Are "200 OK" and "PLAY request" sent via RTP?  I don't think so ...
> please clarify.
> 
> -- Section 4
> 
> Add an explanation of what the "Transition:" text discusses for each
> mechanism are about - transition from what to what?  I believe that
> these chunks of text concern transitioning to a (hypothetical, IMHO)
> world in which NATs don't exist.
> 
> -- Section 4.3.4 Disadvantages list
> 
>    o  Assumes that it is possible to de-multiplex between the packets of
>       the media protocol and STUN packets.
> 
> It is possible, although not elegant.  Add a pointer to Section 5.1.2
> of RFC 5764 for this.
> 
> -- Section 5
> 
>    DDoS attacks occur if
>    the attacker fakes the messages in the NAT traversal mechanism to
>    trick the RTSP server into believing that the client's RTP receiver
>    is located on a separate host.
> 
> "a separate host" -> "the host to be attacked".
> 
> -- Section 8
> 
> The second paragraph in this section summarizes the security considerations
> from Section 4.  It ought to be followed by a paragraph that compares/
> contrasts the degree of security risks of the various NAT traversal mechanisms
> to draw some conclusions - e.g., are some of the proposed mechanisms simply
> infeasible/implausible because the security risks are too high?
> 
> idnits 2.13.01 found a few minor concerns with the references:
> 
>   == Outdated reference: A later version (-07) exists of
>      draft-ietf-mmusic-latching-05
> 
>   == Outdated reference: A later version (-21) exists of
>      draft-ietf-mmusic-rtsp-nat-20
> 
>   -- Obsolete informational reference (is this intentional?): RFC 3489
>      (Obsoleted by RFC 5389)
> 
> The final concern deserves attention - it would be a good thing if the
> need to reference to RFC 3489 could be eliminated.  See [J] above for
> one suggested step towards that end.
> 
> --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---
> 
> In general, there is a lot of operational considerations material
> (applicable to A.1 questions) in this draft.  Beyond that, management
> considerations (A.2 questions) are generally inapplicable.
> 
> A.1.1.  Has deployment been discussed?
> 
> 	Yes, there is significant good material on deployment considerations.
> 
> A.1.3.  Has the migration path been discussed?
> 
> 	Not much, but discussion of migration is mostly deferrable to the
> 	documentation of the selected NAT traversal mechanism and its
> 	components.  Ease/difficulty of adding the NAT traversal support
> 	could have been an evaluation consideration, but was not used.
> 	On balance, this seems ok.
> 
> A.1.4.  Have the Requirements on other protocols and functional
>        components been discussed?
> 
> 	Yes, the discussion of each NAT traversal mechanism indicates what,
> 	if any changes would be needed to protocols used by that mechanism.
> 
> 	But ... see major issue [2] above on the need for clarification
> 	of the discussion of obsolete/unusable protocol changes/features.
> 
> A.1.9 Is configuration discussed?
> 
> 	Yes, as part of the deployment considerations discussion, and
> 	the desire to avoid complexity of configuration is one of the
> 	evaluation criteria (R4).
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> david.black at emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------