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

[Magnus Westerlund <[e-mail]>]

Thanks David,

I have put your editorial into my source. I will submit an update when 
suitable, likely after the rest of the IESG had given comments.

Cheers

Magnus

Black, David skrev den 2015-05-10 21:43:
> 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 ([e-mail]); [e-mail];
>> General Area Review Team ([e-mail]); [e-mail]
>> Cc: [e-mail]; [e-mail]; 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
>> [phone]             FAX: [phone]
>> [e-mail]        Mobile: [phone]
>> ----------------------------------------------------
>
>


-- 

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]
----------------------------------------------------------------------