Network Working Group                                      M. Westerlund
Internet-Draft                                                  Ericsson
Intended status: Standards Track                                 T. Zeng
Expires: January 8, 2008                                    July 7, 2007


   An Network Address Translator (NAT) Traversal mechanism for media
           controlled by Real-Time Streaming Protocol (RTSP)
                     draft-ietf-mmusic-rtsp-nat-05

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.

   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 8, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document defines a solution for Network Address Trans(NAT)
   traversal for the media stream associated with an Real-time Streaming
   Protocol version 2 (RTSP 2.0).  The mechanism is based on Interactive
   Connectivity Establishment (ICE) adapted for using RTSP as signalling
   channel.  The necessary RTSP protocol extensions and procedure is
   defined in this document.




Westerlund & Zeng        Expires January 8, 2008                [Page 1]

 
Internet-Draft  A Media NAT Traversal mechanism for RTSP       July 2007


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


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  RTSP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8






























Westerlund & Zeng        Expires January 8, 2008                [Page 2]

 
Internet-Draft  A Media NAT Traversal mechanism for RTSP       July 2007


.  Introduction

   Real-time Streaming Protocol (RTSP)
   [RFC2326][I-D.ietf-mmusic-rfc2326bis] is protocol used to setup and
   control one or more media streams delivering media to receivers.  It
   is RTSP's functionality of seting up media streams that get into
   serious issues with Network Address Translators (NAT) [RFC3022].
   Commonly the media will be totally blocked by the NAT unless extra
   provisions are taken by the protocol.  There is a clear and present
   need for NAT traversal mechanism for the media setup using RTSP.

   RTSP 1.0 [RFC2326] has quite a long time suffered from the lack of a
   standardized NAT [RFC3022] traversal mechanism for the media.
   However due to quality of the RTSP 1.0 specification, the work on
   updating RTSP was forced to abandom RTSP 1.0 and instead defined RTSP
   2.0 [I-D.ietf-mmusic-rfc2326bis].  RTSP 2.0 is similar to RTSP 1.0 in
   many aspects but contain a number of significant differencies.  It
   also contain a well defined extension mechanism allowing for
   extensions like NAT traversal to be defined in way that will be
   backwards compatible with RTSP 2.0 peers not supporting the
   extension.  This extension isn't defined for RTSP 1.0 due to that it
   can't be specified in any way such that it do not break RTSP 1.0
   syntax, and thus create compatibility issues.

   There has been a number of suggested ways of resolving the NAT-
   traversal of media for RTSP.  A large number are also used in
   implementations.  However as the evaluation of RTSP NAT traversal
   solutions [I-D.ietf-mmusic-rtsp-nat-evaluation] for the media has
   shown there are issues to consider.  In the end a mechanism based on
   Interactive Connectivity Establishment (ICE) was selected as it
   allows also servers to be located behind NATs and also provide a good
   mitigation against the security threat RTSP represent as Distributed
   Denial of Service (DDoS) attack tool.

   This document does not define a NAT traversal mechanism for the RTSP
   signalling itself.  That is for future work in the cases it is
   needed.  Which compared to the media is in fewer deployement cases.
   In all cases the server i reachable on a public IP address the
   traversal of NAT for the signalling will work.  Issues only arise
   when both server and client are behind NATs.  Solution beyond static
   configurations or proxy based solutions are for future studies.


.  Solution Overview

   This overview assumes that the reader has some familarity with how
   ICE [I-D.ietf-mmusic-ice] works.  As it primarily points out how the
   different ICE steps are accomplished in RTSP.



Westerlund & Zeng        Expires January 8, 2008                [Page 3]

 
Internet-Draft  A Media NAT Traversal mechanism for RTSP       July 2007


   1.  The server includes in the session description an SDP attribute
       to indicate that the server has ICE capabilites for this session.
       This is an optimization that allows clients to not spend
       resources in cases when the SDP indication is missing.

   2.  The client reviews the session description to determine what
       media resources that are going to be setup.  For each of these
       media resources where the transport protocol supports
       connectivity checks the client gathers candidate addresses.  See
       section 4.1.1 in [I-D.ietf-mmusic-ice].  The client also installs
       the STUN servers on each of the local candidates.

   3.  A new RTSP Transport header parameter (name tbd) is used to
       include all the candidates for each media resource in the SETUP
       request the client sends.  One of these candidates are promoted
       to default candidate per transport stream required for the media
       resource by including it as if ICE would not be used in the
       dest_addr parameter.

   4.  The RTSP server receives the list of candidates for the media
       resource to setup.  It then gathers its candidates.  For servers
       having a public IP address a single candidate can be included and
       promoted to default directly.

   5.  The server sets up the media and responds to the SETUP request if
       otherwise succesfully with 200 OK respons.  In that respons the
       server includes its candidates in the server candidate parameter
       and the default in the src_addr parameter.  Servers not being
       behind a NAT or other type of middlebox and with a single
       candidate should not intitiate its connectivyt checks yet.  If
       behind a NAT or other middlebox should now initiate its
       connectivity checks following the procedures described in Section
       5.7 and 5.8 of [I-D.ietf-mmusic-ice].

   6.  The client receives the SETUP response and learns the candidate
       address to use for the connectivity checks.  Then it initiates
       its connectivy checks.  In other words it follows the procedures
       in Section 6 of [I-D.ietf-mmusic-ice].

   7.  When a connectivity check from the client reahces the server it
       should result in a triggered check from the server.  This is why
       severs not behind a middlebox can wait until this triggered check
       to send out any checks for itself.  This saves resources and
       somewhat mittigates the DDoS potential.

   8.  When the client has concluded its connectivity checks and also
       received connectiviy checks on the promoted candidates for all
       the media components it can issue a PLAY request.  If the



Westerlund & Zeng        Expires January 8, 2008                [Page 4]

 
Internet-Draft  A Media NAT Traversal mechanism for RTSP       July 2007


       connectivity checks have not concluded succesfully then the
       client may send a new SETUP request assuming it has any new
       information or thinks the server may be able to do more that can
       result in succesful checks.

   9.  When the RTSP servers receives a PLAY request it checks if its
       connectivity checks has concluded succesfully.  If not it issues
       a 1xx response to indicate that it is still working on the
       connectivity checks.  If the checks has failed it issues a 4xx to
       indicate that unsuccessful completion of the checks to the
       client.  Upon sucess the server sends a 200 OK and starts
       delivering media.

   The client may release unused candidates by sending a new SETUP
   request that only contains the used candidates.  This SETUP request
   shall only change the candidate list, and the default candidate to
   the used ones.  No other parameters should be changed.  After
   succesful completion of this request may the client release the
   resources.

   The client will continue to use STUN to send keep-alive for the used
   bindings.  This is important as normally RTSP play mode sessions will
   only contain traffic from the server to the client.  As many NATs
   requires traffic from the client towards the server to keep the
   bindings alive these keep-alives are vital.


.  RTSP Extensions

   To be written


.  Open Issues

   This whole draft is currently an open issues.  The actual
   implementation of ICE for RTSP is yet to be written down in all
   necessary details.


.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.






Westerlund & Zeng        Expires January 8, 2008                [Page 5]

 
Internet-Draft  A Media NAT Traversal mechanism for RTSP       July 2007


.  Security Considerations

   To be written


.  Acknowledgements


.  References

8.1.  Normative References

   [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-16 (work in progress), June 2007.

   [I-D.ietf-mmusic-rfc2326bis]
              Schulzrinne, H., "Real Time Streaming Protocol 2.0
              (RTSP)", draft-ietf-mmusic-rfc2326bis-15 (work in
              progress), June 2007.

   [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.

8.2.  Informative References

   [I-D.ietf-mmusic-rtsp-nat-evaluation]
              Westerlund, M., "The evaluation of different NAT traversal
              Techniques for media controlled by  Real-time Streaming
              Protocol (RTSP)", draft-ietf-mmusic-rtsp-nat-evaluation-00
              (work in progress), July 2007.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.











Westerlund & Zeng        Expires January 8, 2008                [Page 6]

 
Internet-Draft  A Media NAT Traversal mechanism for RTSP       July 2007


Authors' Addresses

   Magnus Westerlund
   Ericsson
   Torshamsgatan 23
   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:






























Westerlund & Zeng        Expires January 8, 2008                [Page 7]

 
Internet-Draft  A Media NAT Traversal mechanism for RTSP       July 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Westerlund & Zeng        Expires January 8, 2008                [Page 8]