RFC 7604

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

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.

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.