Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7604

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

Pages: 46
Informational
Part 1 of 3 – Pages 1 to 8
None   None   Next

Top   ToC   RFC7604 - Page 1
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.
Top   ToC   RFC7604 - Page 2
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
Top   ToC   RFC7604 - Page 3
     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
Top   ToC   RFC7604 - Page 4

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.
Top   ToC   RFC7604 - Page 5
   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.
Top   ToC   RFC7604 - Page 6
      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.
Top   ToC   RFC7604 - Page 7

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].
Top   ToC   RFC7604 - Page 8

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.


(next page on part 2)

Next Section