Internet Engineering Task Force (IETF)                     M. Westerlund
Request for Comments: 7604                                      Ericsson
Category: Informational                                          T. Zeng
ISSN: 2070-1721                                         PacketVideo Corp
                                                          September 2015


            Comparison of Different NAT Traversal Techniques
    for Media Controlled by the Real-Time Streaming Protocol (RTSP)

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
   be applied in different use cases.  These findings were used when
   selecting the NAT traversal for RTSP 2.0, which is specified in a
   separate document.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7604.

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
   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 Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Network Address Translators . . . . . . . . . . . . . . .   5
     1.2.  Firewalls . . . . . . . . . . . . . . . . . . . . . . . .   6
     1.3.  Glossary  . . . . . . . . . . . . . . . . . . . . . . . .   7
   2.  Detecting the Loss of NAT Mappings  . . . . . . . . . . . . .   8
   3.  Requirements on Solutions . . . . . . . . . . . . . . . . . .   9
   4.  NAT-Traversal Techniques  . . . . . . . . . . . . . . . . . .  10
     4.1.  Stand-Alone STUN  . . . . . . . . . . . . . . . . . . . .  11
       4.1.1.  Introduction  . . . . . . . . . . . . . . . . . . . .  11
       4.1.2.  Using STUN to Traverse NAT without Server
               Modifications . . . . . . . . . . . . . . . . . . . .  11
       4.1.3.  ALG Considerations  . . . . . . . . . . . . . . . . .  14
       4.1.4.  Deployment Considerations . . . . . . . . . . . . . .  14
       4.1.5.  Security Considerations . . . . . . . . . . . . . . .  15
     4.2.  Server Embedded STUN  . . . . . . . . . . . . . . . . . .  16
       4.2.1.  Introduction  . . . . . . . . . . . . . . . . . . . .  16
       4.2.2.  Embedding STUN in RTSP  . . . . . . . . . . . . . . .  16
       4.2.3.  Discussion on Co-located STUN Server  . . . . . . . .  17
       4.2.4.  ALG Considerations  . . . . . . . . . . . . . . . . .  17
       4.2.5.  Deployment Considerations . . . . . . . . . . . . . .  18
       4.2.6.  Security Considerations . . . . . . . . . . . . . . .  19
     4.3.  ICE . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
       4.3.1.  Introduction  . . . . . . . . . . . . . . . . . . . .  19
       4.3.2.  Using ICE in RTSP . . . . . . . . . . . . . . . . . .  20
       4.3.3.  Implementation Burden of ICE  . . . . . . . . . . . .  21
       4.3.4.  ALG Considerations  . . . . . . . . . . . . . . . . .  22
       4.3.5.  Deployment Considerations . . . . . . . . . . . . . .  22
       4.3.6.  Security Considerations . . . . . . . . . . . . . . .  23

     4.4.  Latching  . . . . . . . . . . . . . . . . . . . . . . . .  23
       4.4.1.  Introduction  . . . . . . . . . . . . . . . . . . . .  23
       4.4.2.  Necessary RTSP Extensions . . . . . . . . . . . . . .  24
       4.4.3.  ALG Considerations  . . . . . . . . . . . . . . . . .  25
       4.4.4.  Deployment Considerations . . . . . . . . . . . . . .  25
       4.4.5.  Security Considerations . . . . . . . . . . . . . . .  26
     4.5.  A Variation to Latching . . . . . . . . . . . . . . . . .  27
       4.5.1.  Introduction  . . . . . . . . . . . . . . . . . . . .  27
       4.5.2.  Necessary RTSP Extensions . . . . . . . . . . . . . .  28
       4.5.3.  ALG Considerations  . . . . . . . . . . . . . . . . .  28
       4.5.4.  Deployment Considerations . . . . . . . . . . . . . .  28
       4.5.5.  Security Considerations . . . . . . . . . . . . . . .  29
     4.6.  Three-Way Latching  . . . . . . . . . . . . . . . . . . .  29
       4.6.1.  Introduction  . . . . . . . . . . . . . . . . . . . .  29
       4.6.2.  Necessary RTSP Extensions . . . . . . . . . . . . . .  29
       4.6.3.  ALG Considerations  . . . . . . . . . . . . . . . . .  30
       4.6.4.  Deployment Considerations . . . . . . . . . . . . . .  30
       4.6.5.  Security Considerations . . . . . . . . . . . . . . .  30
     4.7.  Application Level Gateways  . . . . . . . . . . . . . . .  31
       4.7.1.  Introduction  . . . . . . . . . . . . . . . . . . . .  31
       4.7.2.  Outline on How ALGs for RTSP Work . . . . . . . . . .  31
       4.7.3.  Deployment Considerations . . . . . . . . . . . . . .  32
       4.7.4.  Security Considerations . . . . . . . . . . . . . . .  33
     4.8.  TCP Tunneling . . . . . . . . . . . . . . . . . . . . . .  33
       4.8.1.  Introduction  . . . . . . . . . . . . . . . . . . . .  33
       4.8.2.  Usage of TCP Tunneling in RTSP  . . . . . . . . . . .  34
       4.8.3.  ALG Considerations  . . . . . . . . . . . . . . . . .  34
       4.8.4.  Deployment Considerations . . . . . . . . . . . . . .  34
       4.8.5.  Security Considerations . . . . . . . . . . . . . . .  35
     4.9.  Traversal Using Relays around NAT (TURN)  . . . . . . . .  35
       4.9.1.  Introduction  . . . . . . . . . . . . . . . . . . . .  35
       4.9.2.  Usage of TURN with RTSP . . . . . . . . . . . . . . .  36
       4.9.3.  ALG Considerations  . . . . . . . . . . . . . . . . .  37
       4.9.4.  Deployment Considerations . . . . . . . . . . . . . .  37
       4.9.5.  Security Considerations . . . . . . . . . . . . . . .  37
   5.  Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . .  38
   6.  Comparison of NAT Traversal Techniques  . . . . . . . . . . .  39
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  41
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  42
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  45
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  46

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 the Real-Time Streaming
   Protocol (RTSP) [RFC2326] [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 port information within its protocol messages.
   Because of this, even if RTSP itself, when carried over the
   Transmission Control Protocol (TCP) [RFC793], for example, is not
   blocked by NATs, its media streams may be blocked by NATs.  This will
   occur unless special protocol provisions are added to support NAT
   traversal.

   Like NATs, firewalls are also middleboxes that need to be considered.
   Firewalls help prevent unwanted traffic from getting in or out of the
   protected network.  RTSP is designed such that a firewall can be
   configured to let RTSP-controlled media streams go through with
   limited implementation effort.  The effort needed is to implement an
   Application Level Gateway (ALG) to interpret RTSP parameters.  There
   is also a large class of firewalls, commonly home firewalls, that use
   a filtering behavior that appears to be the same as what NATs have.
   This type of firewall will be successfully traversed using the same
   solution as employed for NAT traversal, instead of relying on an RTSP
   ALG.  Therefore, firewalls will also be discussed and some important
   differences highlighted.

   This document describes several NAT traversal mechanisms for RTSP-
   controlled media streaming.  Many of these NAT solutions fall into
   the category of "UNilateral Self-Address Fixing (UNSAF)" as defined
   in [RFC3424] and quoted below:

      [UNSAF] is a process whereby some originating process attempts to
      determine or fix the address (and port) by which it is known -
      e.g.  to be able to use address data in the protocol exchange, or
      to advertise a public address from which it will receive
      connections.

   Following the guidelines spelled out in RFC 3424, we describe the
   required RTSP extensions for each method, transition strategies, and
   security concerns.  The transition strategies are a discussion of how
   and if the method encourages a move towards not having any NATs on
   the path.

   This document is capturing the evaluation done in the process to
   recommend firewall/NAT traversal methods for RTSP streaming servers
   based on [RFC2326] as well as the RTSP 2.0 core specification [RTSP].
   The evaluation is focused on NAT traversal for the media streams
   carried over the User Datagram Protocol (UDP) [RFC768] with RTP
   [RFC3550] over UDP being the main case for such usage.  The findings
   should be applicable to other protocols as long as they have similar
   properties.

   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
   levels of NATs, including Carrier-Grade NATs (CGNs), were not
   considered.  Thus, any characterizations or findings may not be
   applicable in such scenarios, unless CGN or multiple levels of NATs
   are explicitly noted.

   An RTSP NAT traversal mechanism based on Interactive Connectivity
   Establishment (ICE) is specified in "A Network Address Translator
   (NAT) Traversal Mechanism for Media Controlled by Real-Time Streaming
   Protocol (RTSP)" [RTSP-NAT].

1.1.  Network Address Translators

   We begin by reviewing two quotes from Section 3 in "Network Address
   Translation (NAT) Behavioral Requirements for Unicast UDP" [RFC4787]
   concerning NATs and their terminology:

      Readers are urged to refer to [RFC2663] for information on NAT
      taxonomy and terminology.  Traditional NAT is the most common type
      of NAT device deployed.  Readers may refer to [RFC3022] for
      detailed information on traditional NAT.  Traditional NAT has two
      main varieties -- Basic NAT and Network Address/Port Translator
      (NAPT).

      NAPT is by far the most commonly deployed NAT device.  NAPT allows
      multiple internal hosts to share a single public IP address
      simultaneously.  When an internal host opens an outgoing TCP or
      UDP session through a NAPT, the NAPT assigns the session a public
      IP address and port number, so that subsequent response packets
      from the external endpoint can be received by the NAPT,
      translated, and forwarded to the internal host.  The effect is
      that the NAPT establishes a NAT session to translate the (private
      IP address, private port number) tuple to a (public IP address,
      public port number) tuple, and vice versa, for the duration of the
      session.  An issue of relevance to peer-to-peer applications is
      how the NAT behaves when an internal host initiates multiple
      simultaneous sessions from a single (private IP, private port)
      endpoint to multiple distinct endpoints on the external network.

      In this specification, the term "NAT" refers to both "Basic NAT"
      and "Network Address/Port Translator (NAPT)".

      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 text, it would be more correct to use an
      external IP address instead of a public IP address.  The external
      IP address is commonly a public one, but it might be of another
      type if the NAT's external side is in a private address domain.

   In addition to the above quote, there exists a number of address and
   port mapping behaviors described in more detail in Section 4.1 of
   [RFC4787] that are highly relevant to the discussion in this
   document.

   NATs also have a filtering behavior on traffic arriving on the
   external side.  Such behavior affects how well different methods for
   NAT traversal works through these NATs.  See Section 5 of [RFC4787]
   for more information on the different types of filtering that have
   been identified.

1.2.  Firewalls

   A firewall is a security gateway that enforces certain access control
   policies between two network administrative domains: a private domain
   (intranet) and an external domain, e.g., the Internet.  Many
   organizations use firewalls to prevent intrusions and malicious
   attacks on computing resources in the private intranet [RFC2588].

   A comparison between NAT and a firewall is given below:

   1.  A firewall sits at security enforcement/protection points, while
       NAT sits at borders between two address domains.

   2.  NAT does not in itself provide security, although some access
       control policies can be implemented using address translation
       schemes.  The inherent filtering behaviors are commonly mistaken
       for real security policies.

   It should be noted that many NAT devices intended for Residential or
   Small Office, Home Office (SOHO) use include both NATs and firewall
   functionality.

1.3.  Glossary

   Address-Dependent Mapping:  The NAT reuses the port mapping for
         subsequent packets sent from the same internal IP address and
         port to the same external IP address, regardless of the
         external port; see [RFC4787].

   Address and Port-Dependent Mapping:  The NAT reuses the port mapping
         for subsequent packets sent from the same internal IP address
         and port to the same external IP address and port while the
         mapping is still active; see [RFC4787].

   ALG:  Application Level Gateway is an entity that can be embedded in
         a NAT or other middlebox to perform the application layer
         functions required for a particular protocol to traverse the
         NAT/middlebox.

   Endpoint-Independent Mapping:  The NAT reuses the port mapping for
         subsequent packets sent from the same internal IP address and
         port to any external IP address and port; see [RFC4787].

   ICE:  Interactive Connectivity Establishment; see [RFC5245].

   DNS:  Domain Name Service

   DoS:  Denial of Service

   DDoS: Distributed Denial of Service

   NAT:  Network Address Translator; see [RFC3022].

   NAPT: Network Address/Port Translator; see [RFC3022].

   RTP:  Real-Time Transport Protocol; see [RFC3550].

   RTSP: Real-Time Streaming Protocol; see [RFC2326] and [RTSP].

   RTT:  Round Trip Times

   SDP:  Session Description Protocol; see [RFC4566].

   SSRC: Synchronization source in RTP; see [RFC3550].

2.  Detecting the Loss of NAT Mappings

   Several NAT traversal techniques in the next chapter make use of the
   fact that the NAT UDP mapping's external address and port can be
   discovered.  This information is then utilized to traverse the NAT
   box.  However, any such information is only good while the mapping is
   still valid.  As the IAB's UNSAF document [RFC3424] points out, the
   mapping can either timeout or change its properties.  It is therefore
   important for the NAT traversal solutions to handle the loss or
   change of NAT mappings, according to RFC 3424.

   First, since NATs may also dynamically reclaim or readjust address/
   port translations, "keep-alive" and periodic repolling may be
   required according to RFC 3424.  Second, it is possible to detect and
   recover from the situation where the mapping has been changed or
   removed.  The loss of a mapping can be detected when no traffic
   arrives for a while.  Below we will give some recommendations on how
   to detect the loss of NAT mappings when using RTP/RTCP under RTSP
   control.

   An RTP session normally has both RTP and RTCP streams.  The loss of
   an RTP mapping can only be detected when expected traffic does not
   arrive.  If a client does not receive media data within a few seconds
   after having received the "200 OK" response to an RTSP PLAY request
   that starts the media delivery, it may be the result of a middlebox
   blocking the traffic.  However, for a receiver to be more certain to
   detect the case where no RTP traffic was delivered due to NAT
   trouble, one should monitor the RTCP Sender reports if they are
   received and not also blocked.  The sender report carries a field
   telling how many packets the server has sent.  If that has increased
   and no RTP packets have arrived for a few seconds, it is likely the
   mapping for the RTP stream has been removed.

   The loss of mapping for RTCP is simpler to detect.  RTCP is normally
   sent periodically in each direction, even during the RTSP ready
   state.  If RTCP packets are missing for several RTCP intervals, the
   mapping is likely lost.  Note that if neither RTCP packets nor RTSP
   messages are received by the RTSP server for a while (default 60
   seconds), 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 middlebox NAT/firewall, or the client is
   malfunctioning.