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@xxxxxxx Mobile: +1 (978) 394-7754 ----------------------------------------------------