--- 1/draft-ietf-mmusic-rtsp-nat-evaluation-15.txt 2015-05-19 01:17:15.930154024 -0700 +++ 2/draft-ietf-mmusic-rtsp-nat-evaluation-16.txt 2015-05-19 01:17:16.018156155 -0700 @@ -1,19 +1,19 @@ Network Working Group M. Westerlund Internet-Draft Ericsson Intended status: Informational T. Zeng -Expires: October 22, 2015 April 20, 2015 +Expires: November 20, 2015 May 19, 2015 The Comparison of Different Network Address Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) - draft-ietf-mmusic-rtsp-nat-evaluation-15 + draft-ietf-mmusic-rtsp-nat-evaluation-16 Abstract This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-time Streaming Protocol (RTSP). Each technique includes a description of how it would be used, the security implications of using it and any other deployment considerations it has. There are also discussions on how NAT traversal techniques relate to firewalls and how each technique can @@ -29,21 +29,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 22, 2015. + This Internet-Draft will expire on November 20, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -76,61 +76,61 @@ 4.2.4. ALG considerations . . . . . . . . . . . . . . . . . 17 4.2.5. Deployment Considerations . . . . . . . . . . . . . . 17 4.2.6. Security Considerations . . . . . . . . . . . . . . . 18 4.3. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . 18 4.3.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 19 4.3.3. Implementation burden of ICE . . . . . . . . . . . . 21 4.3.4. ALG Considerations . . . . . . . . . . . . . . . . . 21 4.3.5. Deployment Considerations . . . . . . . . . . . . . . 22 4.3.6. Security Consideration . . . . . . . . . . . . . . . 22 - 4.4. Latching . . . . . . . . . . . . . . . . . . . . . . . . 22 - 4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . 22 + 4.4. Latching . . . . . . . . . . . . . . . . . . . . . . . . 23 + 4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . 23 4.4.2. Necessary RTSP extensions . . . . . . . . . . . . . . 23 4.4.3. ALG Considerations . . . . . . . . . . . . . . . . . 24 4.4.4. Deployment Considerations . . . . . . . . . . . . . . 24 4.4.5. Security Consideration . . . . . . . . . . . . . . . 25 4.5. A Variation to Latching . . . . . . . . . . . . . . . . . 26 - 4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . 26 + 4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . 27 4.5.2. Necessary RTSP extensions . . . . . . . . . . . . . . 27 - 4.5.3. ALG Considerations . . . . . . . . . . . . . . . . . 27 - 4.5.4. Deployment Considerations . . . . . . . . . . . . . . 27 + 4.5.3. ALG Considerations . . . . . . . . . . . . . . . . . 28 + 4.5.4. Deployment Considerations . . . . . . . . . . . . . . 28 4.5.5. Security Considerations . . . . . . . . . . . . . . . 28 4.6. Three Way Latching . . . . . . . . . . . . . . . . . . . 28 4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . 28 - 4.6.2. Necessary RTSP extensions . . . . . . . . . . . . . . 28 + 4.6.2. Necessary RTSP extensions . . . . . . . . . . . . . . 29 4.6.3. ALG Considerations . . . . . . . . . . . . . . . . . 29 4.6.4. Deployment Considerations . . . . . . . . . . . . . . 29 4.6.5. Security Considerations . . . . . . . . . . . . . . . 29 4.7. Application Level Gateways . . . . . . . . . . . . . . . 30 4.7.1. Introduction . . . . . . . . . . . . . . . . . . . . 30 - 4.7.2. Outline On how ALGs for RTSP work . . . . . . . . . . 30 - 4.7.3. Deployment Considerations . . . . . . . . . . . . . . 31 + 4.7.2. Outline On how ALGs for RTSP work . . . . . . . . . . 31 + 4.7.3. Deployment Considerations . . . . . . . . . . . . . . 32 4.7.4. Security Considerations . . . . . . . . . . . . . . . 32 - 4.8. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 32 + 4.8. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 33 4.8.1. Introduction . . . . . . . . . . . . . . . . . . . . 33 4.8.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . 33 4.8.3. ALG Considerations . . . . . . . . . . . . . . . . . 33 - 4.8.4. Deployment Considerations . . . . . . . . . . . . . . 33 + 4.8.4. Deployment Considerations . . . . . . . . . . . . . . 34 4.8.5. Security Considerations . . . . . . . . . . . . . . . 34 4.9. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . 34 4.9.1. Introduction . . . . . . . . . . . . . . . . . . . . 34 4.9.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 35 4.9.3. ALG Considerations . . . . . . . . . . . . . . . . . 36 4.9.4. Deployment Considerations . . . . . . . . . . . . . . 36 4.9.5. Security Considerations . . . . . . . . . . . . . . . 37 5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6. Comparison of NAT traversal techniques . . . . . . . . . . . 38 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 - 10. Informative References . . . . . . . . . . . . . . . . . . . 41 + 10. Informative References . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 1. Introduction Today there is a proliferating deployment of different types of Network Address Translator (NAT) boxes that in many cases only loosely follow standards [RFC3022][RFC2663][RFC3424][RFC4787][RFC5382]. NATs cause discontinuity in address realms [RFC3424], therefore an application protocol, such as Real-time Streaming Protocol (RTSP) @@ -1038,21 +1038,25 @@ 4.3.6. Security Consideration One should review the security consideration section of ICE and STUN to understand that ICE contains some potential issues. However these can be avoided by correctly using ICE in RTSP. An important factor is to secure the signalling, i.e. use TLS between RTSP client and server. In fact ICE does help avoid the DDoS attack issue with RTSP substantially as it reduces the possibility for a DDoS using RTSP servers to attackers that are on-path between the RTSP server and the target and capable of intercepting the STUN connectivity check - packets and correctly send a response to the server. + packets and correctly send a response to the server. The ICE + connectivity checks with their random transaction IDs from the server + to the client serves as return-routability check and prevents off- + path attacker to succeed with address spoofing. Similar to Mobile + IPV6's return routability procedure (Section 5.2.5 of [RFC6275]). 4.4. Latching 4.4.1. Introduction Latching is a NAT traversal solution that is based on requiring RTSP clients to send UDP packets to the server's media output ports. Conventionally, RTSP servers send RTP packets in one direction: from server to client. Latching is similar to connection-oriented traffic, where one side (e.g., the RTSP client) first "connects" by @@ -1369,32 +1372,33 @@ o May be simpler to implement due to the avoidance of the ICE prioritization and check-board mechanisms. However, a 3-way Latching protocol is very similar to using STUN in both directions as Latching and verification protocol. Using STUN would remove the need for implementing a new protocol. 4.6.5. Security Considerations - The three way latching is significantly securer than its simpler + Three way latching is significantly more secure than its simpler versions discussed above. The client to server nonce which is included in signalling and also can be bigger than the 32-bits of random data that the SSRC field supports makes it very difficult for an off-path attacker to perform an denial of service attack by diverting the media. The client to server nonce and its echoing back does not protect against on-patch attacker, including malicious clients. However, the server to client nonce and its echoing back prevents malicious clients to divert the media stream by spoofing the source address and - port, as it can't echo back the nonce in these cases. + port, as it can't echo back the nonce in these cases. Similar to the + Mobile IPv6 return routability procedure (Section 5.2.5 of [RFC6275]) Three way latching is really only vulnerable to an on-path attacker that is quite capable. First the attacker can either learn the client to server nonce, by intercepting the signalling, or modifying the source information (target destination) of a client's latching packet. Secondly, it is also on-path between the server and target destination and can generate a response using the server's nonce. An adversary that has these capabilities are commonly capable of causing significantly worse damage than this using other methods. @@ -1919,40 +1926,40 @@ signaling connection. The usage of TURN has severe risk of denial of service attacks against a client. The TURN server can also be used as a redirect point in a DDoS attack unless the server has strict enough rules for who may create bindings. The latching and variant of latching have so big security issues that they should not be used at all. The three way latching as well as ICE mitigates these security issues and performs the important - return-routability check that prevents spoofed source addresses, and + return-routability checks that prevents spoofed source addresses, and should be recommended for that reason. RTP ALG's is a security risk as they can create an incitement against using secure RTSP signalling. That can be avoided as ALGs requires trust in the middlebox, and that trust becomes explicit if one uses the hop-by-hop security solution as specified in Section 19.3 of RTSP 2.0. [I-D.ietf-mmusic-rfc2326bis]. The remaining methods can be considered safe enough, assuming that the appropriate security mechanisms are used and not ignored. 9. Acknowledgements The author would also like to thank all persons on the MMUSIC working group's mailing list that has commented on this document. Persons having contributed in such way in no special order to this protocol are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon, Amir Wolf, Anders Klemets, Flemming Andreasen, Ari Keranen, Bill - Atwood, Alissa Cooper, Colin Perkins, Sarah Banks and David Black. - Thomas Zeng would also like to give special thanks to Greg Sherwood - of PacketVideo for his input into this memo. + Atwood, Alissa Cooper, Colin Perkins, Sarah Banks, David Black and + Alvaro Retana. Thomas Zeng would also like to give special thanks to + Greg Sherwood of PacketVideo for his input into this memo. Section 1.1 contains text originally written for RFC 4787 by Francois Audet and Cullen Jennings. 10. Informative References [I-D.ietf-avt-rtp-no-op] Andreasen, F., "A No-Op Payload Format for RTP", draft- ietf-avt-rtp-no-op-04 (work in progress), May 2007. @@ -2048,20 +2055,23 @@ Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", RFC 6062, November 2010. [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows", RFC 6263, June 2011. + [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support + in IPv6", RFC 6275, July 2011. + [RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication", RFC 7362, September 2014. [STUN-IMPL] "Open Source STUN Server and Client, http://sourceforge.net/projects/stun/", May 2013. Authors' Addresses