--- 1/draft-ietf-mmusic-rtsp-nat-evaluation-01.txt 2010-01-20 19:11:26.000000000 +0100 +++ 2/draft-ietf-mmusic-rtsp-nat-evaluation-02.txt 2010-01-20 19:11:26.000000000 +0100 @@ -1,115 +1,139 @@ Network Working Group M. Westerlund Internet-Draft Ericsson Intended status: Informational T. Zeng -Expires: January 12, 2009 July 11, 2008 +Expires: July 24, 2010 January 20, 2010 The evaluation of different NAT traversal Techniques for media controlled by Real-time Streaming Protocol (RTSP) - draft-ietf-mmusic-rtsp-nat-evaluation-01 + draft-ietf-mmusic-rtsp-nat-evaluation-02 + +Abstract + + This document describes several NAT traversal techniques that could + be used by 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 disussions on how + NAT traversal techniques relates to firewalls and how each technique + can be applied in different use cases. These findings where used + when selecting the NAT traversal for RTSP solution to standardize in + the MMUSIC WG. + +Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 12, 2009. + This Internet-Draft will expire on July 24, 2010. -Abstract +Copyright Notice - This document describes several NAT traversal techniques that could - be used by 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 disussions on how - NAT traversal techniques relates to firewalls and how each technique - can be applied in different use cases. These findings where used - when selecting the NAT traversal for RTSP solution to standardize in - the MMUSIC WG. + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. -Requirements Language + 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 + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Network Address Translators . . . . . . . . . . . . . . . 5 1.2. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Detecting the loss of NAT mappings . . . . . . . . . . . . . . 7 - 3. Requirements on NAT-Traversal . . . . . . . . . . . . . . . . 8 + 3. Requirements on NAT-Traversal . . . . . . . . . . . . . . . . 7 4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . . 9 4.1. STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 10 + 4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 9 4.1.2. Using STUN to traverse NAT without server modifications . . . . . . . . . . . . . . . . . . . . 10 4.1.3. Embedding STUN in RTSP . . . . . . . . . . . . . . . . 12 4.1.4. Discussion On Co-located STUN Server . . . . . . . . . 13 - 4.1.5. ALG considerations . . . . . . . . . . . . . . . . . . 14 + 4.1.5. ALG considerations . . . . . . . . . . . . . . . . . . 13 4.1.6. Deployment Considerations . . . . . . . . . . . . . . 14 4.1.7. Security Considerations . . . . . . . . . . . . . . . 16 4.2. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 17 4.2.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 17 4.2.3. Implementation burden of ICE . . . . . . . . . . . . . 19 - 4.2.4. Deployment Considerations . . . . . . . . . . . . . . 20 + 4.2.4. Deployment Considerations . . . . . . . . . . . . . . 19 4.2.5. Security Consideration . . . . . . . . . . . . . . . . 20 4.3. Symmetric RTP . . . . . . . . . . . . . . . . . . . . . . 20 4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 20 4.3.2. Necessary RTSP extensions . . . . . . . . . . . . . . 21 4.3.3. Deployment Considerations . . . . . . . . . . . . . . 21 4.3.4. Security Consideration . . . . . . . . . . . . . . . . 22 4.3.5. A Variation to Symmetric RTP . . . . . . . . . . . . . 23 4.4. Application Level Gateways . . . . . . . . . . . . . . . . 25 4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 25 4.4.2. Outline On how ALGs for RTSP work . . . . . . . . . . 25 4.4.3. Deployment Considerations . . . . . . . . . . . . . . 26 4.4.4. Security Considerations . . . . . . . . . . . . . . . 27 4.5. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 27 4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . . 27 4.5.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . . 27 - 4.5.3. Deployment Considerations . . . . . . . . . . . . . . 28 + 4.5.3. Deployment Considerations . . . . . . . . . . . . . . 27 4.5.4. Security Considerations . . . . . . . . . . . . . . . 28 4.6. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . . 28 4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 28 4.6.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 29 4.6.3. Deployment Considerations . . . . . . . . . . . . . . 30 4.6.4. Security Considerations . . . . . . . . . . . . . . . 30 5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6. Comparision of NAT traversal techniques . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 10. Informative References . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 - Intellectual Property and Copyright Statements . . . . . . . . . . 37 1. Introduction Today there is a proliferate deployment of different flavors of Network Address Translator (NAT) boxes that in many cases only loosely follows standards[RFC3022][RFC2663][RFC3424]]. NATs cause discontinuity in address realms [RFC3424], therefore an application protocol, such as RTSP, needs to deal with such discontinuities caused by NATs. The problem is that, being a media control protocol managing one or more media streams, RTSP carries network address and @@ -234,23 +258,20 @@ DDOS: Distributed Denial Of Service attacks MID: Media Identifier from Grouping of media lines in SDP, see [RFC3388]. NAT: Network Address Translator, see [RFC3022]. NAPT: Network Address/Port Translator, see [RFC3022]. - NAT-PT: Network Address Translator Protocol Translator, see - [RFC2766]. - RTP: Real-time Transport Protocol, see [RFC3550]. RTSP: Real-Time Streaming Protocol, see [RFC2326] and [I-D.ietf-mmusic-rfc2326bis]. SDP: Session Description Protocol, see [RFC4566]. SSRC: Synchronization source in RTP, see [RFC3550]. 2. Detecting the loss of NAT mappings @@ -373,35 +394,37 @@ sections, each technique is outlined in details with discussions on the corresponding advantages and disadvantages. 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. However that is no real barrier against doing an evaluation of the NAT traversal technique. Some other techniques are currently (at the time of writing) in a state of flux due to ongoing standardization work on these techniques, e.g. - ICE [I-D.ietf-mmusic-ice], STUN [I-D.ietf-behave-rfc3489bis] and RTP - No-Op [I-D.ietf-avt-rtp-no-op]. + ICE [I-D.ietf-mmusic-ice], STUN [RFC5389] and RTP No-Op + [I-D.ietf-avt-rtp-no-op]. 4.1. STUN + 4.1.1. Introduction STUN - "Simple Traversal of UDP Through Network Address Translators" - [RFC3489][I-D.ietf-behave-rfc3489bis] is a standardized protocol that - allows a client to use secure means to discover the presence of a NAT - between himself and the STUN server and the type of that NAT. The - client then uses the STUN server to discover the address bindings - assigned by the NAT. STUN is a client-server protocol. STUN client - sends a request to a STUN server and the server returns a response. - There are two types of STUN requests - Binding Requests, sent over - UDP, and Shared Secret Requests, sent over TLS over TCP. + [RFC3489][RFC5389] is a standardized protocol that allows a client to + use secure means to discover the presence of a NAT between himself + and the STUN server and the type of that NAT. The client then uses + the STUN server to discover the address bindings assigned by the NAT. + + STUN is a client-server protocol. STUN client sends a request to a + STUN server and the server returns a response. There are two types + of STUN requests - Binding Requests, sent over UDP, and Shared Secret + Requests, sent over TLS over TCP. STUN is in the process of being updated by the BEHAVE WG to address issues found during usage. The BEHAVE WG intends to integrate it better with TURN [I-D.ietf-behave-turn]. 4.1.2. Using STUN to traverse NAT without server modifications This section describes how a client can use STUN to traverse NATs to RTSP servers without requiring server modifications. Note that this method has limited applicability and requires the server to be @@ -1542,71 +1567,61 @@ Section Section 1.1 contains text originally written for RFC 4787 by Francois Audet and Cullen Jennings. 10. Informative References [I-D.ietf-avt-app-rtp-keepalive] Marjou, X. and A. Sollaud, "Application Mechanism for maintaining alive the Network Address Translator (NAT) mappings associated to RTP flows.", - draft-ietf-avt-app-rtp-keepalive-03 (work in progress), - April 2008. + draft-ietf-avt-app-rtp-keepalive-07 (work in progress), + December 2009. [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-behave-rfc3489bis] - Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, - "Session Traversal Utilities for (NAT) (STUN)", - draft-ietf-behave-rfc3489bis-16 (work in progress), - July 2008. - [I-D.ietf-behave-turn] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", - draft-ietf-behave-turn-08 (work in progress), June 2008. + draft-ietf-behave-turn-16 (work in progress), July 2009. [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in progress), October 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-18 (work in - progress), May 2008. + (RTSP)", draft-ietf-mmusic-rfc2326bis-22 (work in + progress), July 2009. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May 1999. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. - [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address - Translation - Protocol Translation (NAT-PT)", RFC 2766, - February 2000. - [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002. [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address @@ -1625,74 +1640,38 @@ Description Protocol", RFC 4566, July 2006. [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection- Oriented Transport", RFC 4571, July 2006. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. + [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for NAT (STUN)", RFC 5389, + October 2008. + [STUN-IMPL] "Open Source STUN Server and Client, http:// www.vovida.org/applications/downloads/stun/index.html", June 2007. Authors' Addresses Magnus Westerlund Ericsson - Torshamsgatan 23 + Farogatan 6 Stockholm, SE-164 80 Sweden Phone: +46 8 719 0000 Fax: Email: magnus.westerlund@ericsson.com URI: Thomas Zeng Phone: Fax: Email: thomas.zeng@gmail.com URI: - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org.