--- 1/draft-ietf-mmusic-rtsp-nat-evaluation-09.txt 2013-11-18 07:14:53.455882728 -0800 +++ 2/draft-ietf-mmusic-rtsp-nat-evaluation-10.txt 2013-11-18 07:14:53.531884656 -0800 @@ -1,19 +1,20 @@ Network Working Group M. Westerlund Internet-Draft Ericsson Intended status: Informational T. Zeng -Expires: November 30, 2013 May 29, 2013 +Expires: May 22, 2014 + November 18, 2013 The Evaluation of Different Network Address Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) - draft-ietf-mmusic-rtsp-nat-evaluation-09 + draft-ietf-mmusic-rtsp-nat-evaluation-10 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 on 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 relates to firewalls and how each technique can @@ -28,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 November 30, 2013. + This Internet-Draft will expire on May 22, 2014. Copyright Notice Copyright (c) 2013 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 @@ -986,22 +987,22 @@ 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 sending a RTP packet to the other side's RTP port, the recipient then replies to the originating IP and port. This method is also referred to as "Late binding". It requires that all RTP/RTCP transport is done symmetrical, i.e. Symmetric RTP [RFC4961]. Specifically, when the RTSP server receives the latching packet - (a.k.a. hole-punching packet, since it is used to punch a hole in - the Firewall/NAT and to aid the server for port binding and address + (a.k.a. hole-punching packet, since it is used to punch a hole in the + Firewall/NAT and to aid the server for port binding and address mapping) from its client, it copies the source IP and Port number and uses them as delivery address for media packets. By having the server send media traffic back the same way as the client's packet are sent to the server, address mappings will be honored. Therefore this technique works for all types of NATs, given that the server is not behind a NAT. However, it does require server modifications. Unless there is built-in protection mechanism, latching is very vulnerable to DDoS attacks, because attackers can simply forge the source IP & Port of the latching packet. Using the rule for restricting IP address to the one of the signaling connection will @@ -1499,23 +1500,23 @@ verify that it is allowed to send media traffic to the given address. 5. The RTSP Client uses the RTSP Server's response to create TURN permissions for the server's media traffic. 6. The client requests that the server starts playing. The server starts sending media packets to the given destination address and ports. - 7. The first media packet arrive at the TURN server on the external - port; If the packet matches an established permission the TURN - server forwards the media packet to the RTSP client. + 7. Media packets arrive at the TURN server on the external port; If + the packets match an established permission, the TURN server + forwards the media packets to the RTSP client. 8. If the client pauses and media is not sent for about 75% of the mapping timeout the client should use TURN to refresh the bindings. 4.9.3. Deployment Considerations Advantages: o Does not require any server modifications given that the server @@ -1732,28 +1733,28 @@ 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. [I-D.ietf-mmusic-rfc2326bis] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, "Real Time Streaming Protocol 2.0 - (RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in - progress), April 2013. + (RTSP)", draft-ietf-mmusic-rfc2326bis-38 (work in + progress), October 2013. [I-D.ietf-mmusic-rtsp-nat] Goldberg, J., Westerlund, M., and T. Zeng, "A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP)", draft- - ietf-mmusic-rtsp-nat-16 (work in progress), May 2013. + ietf-mmusic-rtsp-nat-17 (work in progress), Nov 2013. [NICE] , "Libnice - The GLib ICE implementation, http://nice.freedesktop.org/wiki/", May 2013. [PJNATH] , "PJNATH - Open Source ICE, STUN, and TURN Library, http://www.pjsip.org/pjnath/docs/html/", May 2013. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. @@ -1767,22 +1768,22 @@ 1999. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. - [RFC3424] Daigle, L. IAB, "IAB Considerations for UNilateral Self- - Address Fixing (UNSAF) Across Network Address + [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral + Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.