[MMUSIC] Gen-ART and OPS-Dir review of draft-ietf-mmusic-rtsp-nat-evaluation-14

["Black, David" <[e-mail]>]

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
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------