draft-ietf-mmusic-rtsp-nat-evaluation-13.txt   draft-ietf-mmusic-rtsp-nat-evaluation-14.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational T. Zeng Intended status: Informational T. Zeng
Expires: August 14, 2014 Expires: November 29, 2014
February 10, 2014 May 28, 2014
The Evaluation of Different Network Address Translator (NAT) Traversal The Evaluation of Different Network Address Translator (NAT) Traversal
Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)
draft-ietf-mmusic-rtsp-nat-evaluation-13 draft-ietf-mmusic-rtsp-nat-evaluation-14
Abstract Abstract
This document describes several Network Address Translator (NAT) This document describes several Network Address Translator (NAT)
traversal techniques that were considered to be used for establishing traversal techniques that were considered to be used for establishing
the RTP media flows controlled by the Real-time Streaming Protocol the RTP media flows controlled by the Real-time Streaming Protocol
(RTSP). Each technique includes a description of how it would be (RTSP). Each technique includes a description of how it would be
used, the security implications of using it and any other deployment used, the security implications of using it and any other deployment
considerations it has. There are also discussions on how NAT considerations it has. There are also discussions on how NAT
traversal techniques relate to firewalls and how each technique can traversal techniques relate to firewalls and how each technique can
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 14, 2014. This Internet-Draft will expire on November 29, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Network Address Translators . . . . . . . . . . . . . . . 4 1.1. Network Address Translators . . . . . . . . . . . . . . . 4
1.2. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Detecting the loss of NAT mappings . . . . . . . . . . . . . 7 2. Detecting the loss of NAT mappings . . . . . . . . . . . . . 7
3. Requirements on Solutions . . . . . . . . . . . . . . . . . . 8 3. Requirements on Solutions . . . . . . . . . . . . . . . . . . 8
4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . 9 4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . 9
4.1. Stand-Alone STUN . . . . . . . . . . . . . . . . . . . . 10 4.1. Stand-Alone STUN . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . 10
4.1.2. Using STUN to traverse NAT without server 4.1.2. Using STUN to traverse NAT without server
modifications . . . . . . . . . . . . . . . . . . . . 10 modifications . . . . . . . . . . . . . . . . . . . . 10
4.1.3. ALG considerations . . . . . . . . . . . . . . . . . 12 4.1.3. ALG considerations . . . . . . . . . . . . . . . . . 12
4.1.4. Deployment Considerations . . . . . . . . . . . . . . 13 4.1.4. Deployment Considerations . . . . . . . . . . . . . . 13
4.1.5. Security Considerations . . . . . . . . . . . . . . . 14 4.1.5. Security Considerations . . . . . . . . . . . . . . . 14
4.2. Server Embedded STUN . . . . . . . . . . . . . . . . . . 14 4.2. Server Embedded STUN . . . . . . . . . . . . . . . . . . 14
4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . 14 4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Embedding STUN in RTSP . . . . . . . . . . . . . . . 14 4.2.2. Embedding STUN in RTSP . . . . . . . . . . . . . . . 15
4.2.3. Discussion On Co-located STUN Server . . . . . . . . 16 4.2.3. Discussion On Co-located STUN Server . . . . . . . . 16
4.2.4. ALG considerations . . . . . . . . . . . . . . . . . 16 4.2.4. ALG considerations . . . . . . . . . . . . . . . . . 16
4.2.5. Deployment Considerations . . . . . . . . . . . . . . 16 4.2.5. Deployment Considerations . . . . . . . . . . . . . . 16
4.2.6. Security Considerations . . . . . . . . . . . . . . . 17 4.2.6. Security Considerations . . . . . . . . . . . . . . . 18
4.3. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . 17 4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . 18
4.3.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 18 4.3.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 18
4.3.3. Implementation burden of ICE . . . . . . . . . . . . 20 4.3.3. Implementation burden of ICE . . . . . . . . . . . . 20
4.3.4. Deployment Considerations . . . . . . . . . . . . . . 20 4.3.4. Deployment Considerations . . . . . . . . . . . . . . 21
4.3.5. Security Consideration . . . . . . . . . . . . . . . 21 4.3.5. Security Consideration . . . . . . . . . . . . . . . 21
4.4. Latching . . . . . . . . . . . . . . . . . . . . . . . . 21 4.4. Latching . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . 21 4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . 21
4.4.2. Necessary RTSP extensions . . . . . . . . . . . . . . 22 4.4.2. Necessary RTSP extensions . . . . . . . . . . . . . . 22
4.4.3. Deployment Considerations . . . . . . . . . . . . . . 22 4.4.3. Deployment Considerations . . . . . . . . . . . . . . 23
4.4.4. Security Consideration . . . . . . . . . . . . . . . 23 4.4.4. Security Consideration . . . . . . . . . . . . . . . 23
4.5. A Variation to Latching . . . . . . . . . . . . . . . . . 24 4.5. A Variation to Latching . . . . . . . . . . . . . . . . . 25
4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . 24 4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . 25
4.5.2. Necessary RTSP extensions . . . . . . . . . . . . . . 25 4.5.2. Necessary RTSP extensions . . . . . . . . . . . . . . 25
4.5.3. Deployment Considerations . . . . . . . . . . . . . . 25 4.5.3. Deployment Considerations . . . . . . . . . . . . . . 26
4.5.4. Security Considerations . . . . . . . . . . . . . . . 26 4.5.4. Security Considerations . . . . . . . . . . . . . . . 26
4.6. Three Way Latching . . . . . . . . . . . . . . . . . . . 26 4.6. Three Way Latching . . . . . . . . . . . . . . . . . . . 27
4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . 26 4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . 27
4.6.2. Necessary RTSP extensions . . . . . . . . . . . . . . 26 4.6.2. Necessary RTSP extensions . . . . . . . . . . . . . . 27
4.6.3. Deployment Considerations . . . . . . . . . . . . . . 27 4.6.3. Deployment Considerations . . . . . . . . . . . . . . 27
4.7. Application Level Gateways . . . . . . . . . . . . . . . 27 4.7. Application Level Gateways . . . . . . . . . . . . . . . 28
4.7.1. Introduction . . . . . . . . . . . . . . . . . . . . 27 4.7.1. Introduction . . . . . . . . . . . . . . . . . . . . 28
4.7.2. Outline On how ALGs for RTSP work . . . . . . . . . . 28 4.7.2. Outline On how ALGs for RTSP work . . . . . . . . . . 28
4.7.3. Deployment Considerations . . . . . . . . . . . . . . 29 4.7.3. Deployment Considerations . . . . . . . . . . . . . . 29
4.7.4. Security Considerations . . . . . . . . . . . . . . . 29 4.7.4. Security Considerations . . . . . . . . . . . . . . . 30
4.8. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 30 4.8. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 30
4.8.1. Introduction . . . . . . . . . . . . . . . . . . . . 30 4.8.1. Introduction . . . . . . . . . . . . . . . . . . . . 30
4.8.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . 30 4.8.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . 31
4.8.3. Deployment Considerations . . . . . . . . . . . . . . 30 4.8.3. Deployment Considerations . . . . . . . . . . . . . . 31
4.8.4. Security Considerations . . . . . . . . . . . . . . . 31 4.8.4. Security Considerations . . . . . . . . . . . . . . . 31
4.9. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . 31 4.9. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . 31
4.9.1. Introduction . . . . . . . . . . . . . . . . . . . . 31 4.9.1. Introduction . . . . . . . . . . . . . . . . . . . . 32
4.9.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 32 4.9.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 32
4.9.3. Deployment Considerations . . . . . . . . . . . . . . 32 4.9.3. Deployment Considerations . . . . . . . . . . . . . . 33
4.9.4. Security Considerations . . . . . . . . . . . . . . . 33 4.9.4. Security Considerations . . . . . . . . . . . . . . . 34
5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6. Comparison of NAT traversal techniques . . . . . . . . . . . 34 6. Comparison of NAT traversal techniques . . . . . . . . . . . 35
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
10. Informative References . . . . . . . . . . . . . . . . . . . 37 10. Informative References . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Today there is a proliferate deployment of different flavors of Today there is a proliferate deployment of different flavors of
Network Address Translator (NAT) boxes that in many cases only Network Address Translator (NAT) boxes that in many cases only
loosely follow standards loosely follow standards
[RFC3022][RFC2663][RFC3424][RFC4787][RFC5382]. NATs cause [RFC3022][RFC2663][RFC3424][RFC4787][RFC5382]. NATs cause
discontinuity in address realms [RFC3424], therefore an application discontinuity in address realms [RFC3424], therefore an application
protocol, such as Real-time Streaming Protocol (RTSP) protocol, such as Real-time Streaming Protocol (RTSP)
[RFC2326][I-D.ietf-mmusic-rfc2326bis], needs to deal with such [RFC2326][I-D.ietf-mmusic-rfc2326bis], needs to deal with such
discontinuities caused by NATs. The problem is that, being a media discontinuities caused by NATs. The problem is that, being a media
control protocol managing one or more media streams, RTSP carries control protocol managing one or more media streams, RTSP carries
network address and port information within its protocol messages. network address and port information within its protocol messages.
Because of this, even if RTSP itself, when carried over Transmission Because of this, even if RTSP itself, when carried over Transmission
Control Protocol (TCP) [RFC0793] for example, is not blocked by NATs, Control Protocol (TCP) [RFC0793] for example, is not blocked by NATs,
its media streams may be blocked by NATs. This will occur unless its media streams may be blocked by NATs. This will occur unless
special protocol provisions are added to support NAT-traversal. special protocol provisions are added to support NAT-traversal.
Like NATs, Firewalls are also middle boxes that need to be Like NATs, firewalls are also middle boxes that need to be
considered. Firewalls help prevent unwanted traffic from getting in considered. Firewalls help prevent unwanted traffic from getting in
or out of the protected network. RTSP is designed such that a or out of the protected network. RTSP is designed such that a
firewall can be configured to let RTSP controlled media streams go firewall can be configured to let RTSP controlled media streams go
through with minimal implementation effort. The minimal effort is to through with minimal implementation effort. The minimal effort is to
implement an Application Level Gateway (ALG) to interpret RTSP implement an Application Level Gateway (ALG) to interpret RTSP
parameters. There is also a large class of firewalls, commonly home parameters. There is also a large class of firewalls, commonly home
firewalls, that uses a similar filtering behavior to what NAT has. firewalls, that uses a similar filtering behavior to what NAT has.
This type of firewalls can be handled using the same solution as This type of firewalls can be handled using the same solution as
employed for NAT traversal instead of relying on ALGs. employed for NAT traversal instead of relying on ALGs.
skipping to change at page 4, line 25 skipping to change at page 4, line 25
"UNSAF is a process whereby some originating process attempts to "UNSAF is a process whereby some originating process attempts to
determine or fix the address (and port) by which it is known - e.g. 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 to be able to use address data in the protocol exchange, or to
advertise a public address from which it will receive connections." advertise a public address from which it will receive connections."
Following the guidelines spelled out in RFC 3424, we describe the Following the guidelines spelled out in RFC 3424, we describe the
required RTSP protocol extensions for each method, transition required RTSP protocol extensions for each method, transition
strategies, and security concerns. strategies, and security concerns.
This document is capturing the evaluation done in the process to This document is capturing the evaluation done in the process to
recommend Firewall/NAT traversal methods for RTSP streaming servers recommend firewall/NAT traversal methods for RTSP streaming servers
based on RFC 2326 [RFC2326] as well as the RTSP 2.0 core spec based on RFC 2326 [RFC2326] as well as the RTSP 2.0 core spec
[I-D.ietf-mmusic-rfc2326bis]. The evaluation is focused on NAT [I-D.ietf-mmusic-rfc2326bis]. The evaluation is focused on NAT
traversal for the media streams carried over User Datagram Protocol traversal for the media streams carried over User Datagram Protocol
(UDP) [RFC0768] with Real-time Transport Protocol (RTP) [RFC3550] (UDP) [RFC0768] with Real-time Transport Protocol (RTP) [RFC3550]
over UDP being the main case for such usage. The findings should be over UDP being the main case for such usage. The findings should be
applicable to other protocols as long as they have similar applicable to other protocols as long as they have similar
properties. 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 level
of NATs, including Carrier Grade NATs (CGNs) has been only partially
considered.
The resulting ICE-based RTSP NAT traversal mechanism is specified in The resulting ICE-based RTSP NAT traversal mechanism is specified in
"A Network Address Translator (NAT) Traversal mechanism for media "A Network Address Translator (NAT) Traversal mechanism for media
controlled by Real-Time Streaming Protocol (RTSP)" controlled by Real-Time Streaming Protocol (RTSP)"
[I-D.ietf-mmusic-rtsp-nat]. [I-D.ietf-mmusic-rtsp-nat].
1.1. Network Address Translators 1.1. Network Address Translators
We begin by reviewing two quotes from Section 3 in "Network Address We begin by reviewing two quotes from Section 3 in "Network Address
Translation (NAT) Behavioral Requirements for Unicast UDP" [RFC4787] Translation (NAT) Behavioral Requirements for Unicast UDP" [RFC4787]
concering NATs and their terminology: concering NATs and their terminology:
skipping to change at page 5, line 49 skipping to change at page 6, line 9
external side. Such behavior affects how well different methods for external side. Such behavior affects how well different methods for
NAT traversal works through these NATs. See Section 5 of "Network NAT traversal works through these NATs. See Section 5 of "Network
Address Translation (NAT) Behavioral Requirements for Unicast UDP" Address Translation (NAT) Behavioral Requirements for Unicast UDP"
[RFC4787] for more information on the different types of filtering [RFC4787] for more information on the different types of filtering
that have been identified. that have been identified.
1.2. Firewalls 1.2. Firewalls
A firewall is a security gateway that enforces certain access control A firewall is a security gateway that enforces certain access control
policies between two network administrative domains: a private domain policies between two network administrative domains: a private domain
(intranet) and a external domain, e.g. public Internet. Many (intranet) and a external domain, e.g. Internet. Many organizations
organizations use firewalls to prevent privacy intrusions and use firewalls to prevent privacy intrusions and malicious attacks to
malicious attacks to corporate computing resources in the private corporate computing resources in the private intranet [RFC2588].
intranet [RFC2588].
A comparison between NAT and Firewall is given below: A comparison between NAT and firewall is given below:
1. A firewall sits at security enforcement/protection points, while 1. A firewall sits at security enforcement/protection points, while
NAT sits at borders between two address domains. NAT sits at borders between two address domains.
2. NAT does not in itself provide security, although some access 2. NAT does not in itself provide security, although some access
control policies can be implemented using address translation control policies can be implemented using address translation
schemes. The inherent filtering behaviours are commonly mistaken schemes. The inherent filtering behaviours are commonly mistaken
for real security policies. for real security policies.
It should be noted that many NAT devices intended for Residential or It should be noted that many NAT devices intended for Residential or
small office/home office (SOHO) use include both NATs and firewall small office/home office (SOHO) use include both NATs and firewall
functionality. functionality.
In the rest of this memo we use the phrase "NAT traversal" In the rest of this memo we use the phrase "NAT traversal"
interchangeably with "Firewall traversal", and "NAT/Firewall interchangeably with "firewall traversal", and "NAT/firewall
traversal". traversal".
1.3. Glossary 1.3. Glossary
Address-Dependent Mapping: The NAT reuses the port mapping for Address-Dependent Mapping: The NAT reuses the port mapping for
subsequent packets sent from the same internal IP address and subsequent packets sent from the same internal IP address and
port to the same external IP address, regardless of the port to the same external IP address, regardless of the
external port. See [RFC4787]. external port. See [RFC4787].
Address and Port-Dependent Mapping: The NAT reuses the port mapping Address and Port-Dependent Mapping: The NAT reuses the port mapping
skipping to change at page 7, line 41 skipping to change at page 7, line 49
required according to RFC 3424. Secondly, it is possible to detect required according to RFC 3424. Secondly, it is possible to detect
and recover from the situation where the mapping has been changed or and recover from the situation where the mapping has been changed or
removed. The loss of a mapping can be detected when no traffic removed. The loss of a mapping can be detected when no traffic
arrives for a while. Below we will give some recommendation on how arrives for a while. Below we will give some recommendation on how
to detect loss of NAT mappings when using RTP/RTCP under RTSP to detect loss of NAT mappings when using RTP/RTCP under RTSP
control. control.
A RTP session normally has both RTP and RTCP streams. The loss of a A RTP session normally has both RTP and RTCP streams. The loss of a
RTP mapping can only be detected when expected traffic does not RTP mapping can only be detected when expected traffic does not
arrive. If a client does not receive data within a few seconds after arrive. If a client does not receive data within a few seconds after
having received the "200 OK" response to a PLAY request, there are having received the "200 OK" response to a PLAY request, it may be
likely some middleboxes blocking the traffic. However, for a the result of a middlebox blocking the traffic. However, for a
receiver to be more certain to detect the case where no RTP traffic 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 was delivered due to NAT trouble, one should monitor the RTCP Sender
reports if they are received and not also blocked. The sender report reports if they are received and not also blocked. The sender report
carries a field telling how many packets the server has sent. If carries a field telling how many packets the server has sent. If
that has increased and no RTP packets has arrived for a few seconds that has increased and no RTP packets has arrived for a few seconds
it is likely the RTP mapping has been removed. it is likely the RTP mapping has been removed.
The loss of mapping for RTCP is simpler to detect. RTCP is normally The loss of mapping for RTCP is simpler to detect. RTCP is normally
sent periodically in each direction, even during the RTSP ready sent periodically in each direction, even during the RTSP ready
state. If RTCP packets are missing for several RTCP intervals, the state. If RTCP packets are missing for several RTCP intervals, the
mapping is likely lost. Note that if neither RTCP packets nor RTSP mapping is likely lost. Note that if neither RTCP packets nor RTSP
messages are received by the RTSP server for a while, the RTSP server messages are received by the RTSP server for a while, the RTSP server
has the option to delete the corresponding RTP session, SSRC and RTSP has the option to delete the corresponding RTP session, SSRC and RTSP
session ID, because either the client can not get through a middle session ID, because either the client can not get through a middle
box NAT/Firewall, or the client is mal-functioning. box NAT/firewall, or the client is mal-functioning.
3. Requirements on Solutions 3. Requirements on Solutions
This section considers the set of requirements for the evaluation of This section considers the set of requirements for the evaluation of
RTSP NAT traversal solutions. RTSP NAT traversal solutions.
RTSP is a client-server protocol. Typically service providers deploy RTSP is a client-server protocol. Typically service providers deploy
RTSP servers in the public address realm. However, there are use RTSP servers on the Internet or otherwise reachable address realm.
cases where the reverse is true: RTSP clients are connecting from However, there are use cases where the reverse is true: RTSP clients
public address realm to RTSP servers behind home NATs. This is the are connecting from any address realm to RTSP servers behind NATs,
case for instance when home surveillance cameras running as RTSP e.g. in a home. This is the case for instance when home surveillance
servers intend to stream video to cell phone users in the public cameras running as RTSP servers intend to stream video to cell phone
address realm through a home NAT. In terms of requirements, the users in the public address realm through a home NAT. In terms of
first requirement should be to solve the RTSP NAT traversal problem requirements, the primary requirement should be to solve the RTSP NAT
for RTSP servers deployed in a public network, i.e. no NAT at the traversal problem for RTSP servers deployed in a network where the
server side. server is on the external side of any NAT, i.e. server is not behind
a NAT.
The list of feature requirements for RTSP NAT solutions are given The list of feature requirements for RTSP NAT solutions are given
below: below:
1. Must work for all flavors of NATs, including NATs with Address 1. Must work for all flavors of NATs, including NATs with Address
and Port-Dependent Filtering. and Port-Dependent Filtering.
2. Must work for firewalls (subject to pertinent firewall 2. Must work for firewalls (subject to pertinent firewall
administrative policies), including those with ALGs. administrative policies), including those with ALGs.
3. Should have minimal impact on clients in the open and not dual- 3. Should have minimal impact on clients not behind NATs and which
hosted. RTSP dual-hosting means that the RTSP signalling are not dual-hosted. RTSP dual-hosting means that the RTSP
protocol and the media protocol (e.g. RTP) are implemented on signalling protocol and the media protocol (e.g. RTP) are
different computers with different IP addresses. implemented on different computers with different IP addresses.
* For instance, no extra delay from RTSP connection till arrival * For instance, no extra delay from RTSP connection till arrival
of media of media
4. Should be simple to use/implement/administer so people actually 4. Should be simple to use/implement/administer so people actually
turn them on turn them on
* Otherwise people will resort to TCP tunneling through NATs * Otherwise people will resort to TCP tunneling through NATs
* Discovery of the address(es) assigned by NAT should happen * Discovery of the address(es) assigned by NAT should happen
automatically, if possible automatically, if possible
5. Should authenticate dual-hosted client transport handler to 5. Should authenticate dual-hosted client transport handler to
prevent DDoS attacks. prevent DDoS attacks.
The last requirement addresses the Distributed Denial-of-Service The last requirement addresses the Distributed Denial-of-Service
(DDoS) threat, which relates to NAT traversal as explained below. (DDoS) threat, which relates to NAT traversal as explained below.
During NAT traversal, when the RTSP server determines the media During NAT traversal, when the RTSP server determines the media
destination (address and port) for the client, the result may be that destination (address and port) for the client, the result may be that
the public IP address of the RTP receiver host is different than the the IP address of the RTP receiver host is different than the IP
public IP address of the RTSP client host. This posts a DDoS threat address of the RTSP client host. This posts a DDoS threat that has
that has significant amplification potentials because the RTP media significant amplification potentials because the RTP media streams in
streams in general consist of large number of IP packets. DDoS general consist of large number of IP packets. DDoS attacks occur if
attacks occur if the attacker fakes the messages in the NAT traversal the attacker fakes the messages in the NAT traversal mechanism to
mechanism to trick the RTSP server into believing that the client's trick the RTSP server into believing that the client's RTP receiver
RTP receiver is located on a separate host. For example, user A may is located on a separate host. For example, user A may use his RTSP
use his RTSP client to direct the RTSP server to send video RTP client to direct the RTSP server to send video RTP streams to
streams to target.example.com in order to degrade the services target.example.com in order to degrade the services provided by
provided by target.example.com. Note a simple preventative measure target.example.com. Note a simple preventative measure commonly
commonly deployed is for the RTSP server to disallow the cases where deployed is for the RTSP server to disallow the cases where the
the client's RTP receiver has a different public IP address than that client's RTP receiver has a different IP address than that of the
of the RTSP client. With the increased deployment of NAT middleboxes RTSP client. With the increased deployment of NAT middleboxes by
by operators, i.e. carrier grade NAT (CGN), the reusing of a public operators, i.e. carrier grade NAT (CGN), the reuse of an IP address
IP address for many customers reduces the protection provided. Also on the NAT's external side by many customers reduces the protection
in some applications (e.g., centralized conferencing), dual-hosted provided. Also in some applications (e.g., centralized
RTSP/RTP clients have valid use cases. The key is how to conferencing), dual-hosted RTSP/RTP clients have valid use cases.
authenticate the messages exchanged during the NAT traversal process. The key is how to authenticate the messages exchanged during the NAT
traversal process.
4. NAT Traversal Techniques 4. NAT Traversal Techniques
There exists a number of potential NAT traversal techniques that can There exists a number of potential NAT traversal techniques that can
be used to allow RTSP to traverse NATs. They have different features be used to allow RTSP to traverse NATs. They have different features
and are applicable to different topologies; their costs are also and are applicable to different topologies; their costs are also
different. They also vary in security levels. In the following different. They also vary in security levels. In the following
sections, each technique is outlined with discussions on the sections, each technique is outlined with discussions on the
corresponding advantages and disadvantages. corresponding advantages and disadvantages.
The main evaluation was done prior to 2007 and is based on what was The main evaluation was done prior to 2007 and is based on what was
available then. This section includes NAT traversal techniques that available then. This section includes NAT traversal techniques that
have not been formally specified anywhere else. The overview section have not been formally specified anywhere else. The overview section
of this document may be the only publicly available specification of of this document may be the only publicly available specification of
some of the NAT traversal techniques. However that is not a real some of the NAT traversal techniques. However that is not a real
barrier against doing an evaluation of the NAT traversal techniques. barrier against doing an evaluation of the NAT traversal techniques.
Some other techniques have been recommended against or are no longer Some other techniques have been recommended against or are no longer
possible due to standardization works' outcome or their failure to possible due to standardization works' outcome or their failure to
progress within IETF after the initial evaluation in this document, progress within IETF after the initial evaluation in this document,
e.g. RTP No-Op [I-D.ietf-avt-rtp-no-op]. e.g. RTP No-Op [I-D.ietf-avt-rtp-no-op].
4.1. Stand-Alone STUN 4.1. Stand-Alone STUN
4.1.1. Introduction 4.1.1. Introduction
Session Traversal Utilities for NAT (STUN) [RFC5389] is a Session Traversal Utilities for NAT (STUN) [RFC5389] is a
standardized protocol that allows a client to use secure means to standardized protocol that allows a client to use secure means to
discover the presence of a NAT between itself and the STUN server. discover the presence of a NAT between itself and the STUN server.
The client uses the STUN server to discover the address mappings The client uses the STUN server to discover the address mappings
assigned by the NAT. STUN is a client-server protocol. The STUN assigned by the NAT. STUN is a client-server protocol. The STUN
skipping to change at page 11, line 15 skipping to change at page 11, line 23
1. Use STUN to try to discover the type of NAT, and the timeout 1. Use STUN to try to discover the type of NAT, and the timeout
period for any UDP mapping on the NAT. This is recommended to be period for any UDP mapping on the NAT. This is recommended to be
performed in the background as soon as IP connectivity is performed in the background as soon as IP connectivity is
established. If this is performed prior to establishing a established. If this is performed prior to establishing a
streaming session the delays in the session establishment will be streaming session the delays in the session establishment will be
reduced. If no NAT is detected, normal SETUP should be used. reduced. If no NAT is detected, normal SETUP should be used.
2. The RTSP client determines the number of UDP ports needed by 2. The RTSP client determines the number of UDP ports needed by
counting the number of needed media transport protocols sessions counting the number of needed media transport protocols sessions
in the multi-media presentation. This information is available in the multi-media presentation. This information is available
in the media description protocol, e.g. SDP [RFC4566]. For in the media description protocol, e.g. SDP [RFC4566]. For
example, each RTP session will in general require two UDP ports, example, each RTP session will in general require two UDP ports,
one for RTP, and one for RTCP. one for RTP, and one for RTCP.
3. For each UDP port required, establish a mapping and discover the 3. For each UDP port required, establish a mapping and discover the
public/external IP address and port number with the help of the public/external IP address and port number with the help of the
STUN server. A successful mapping looks like: client's local STUN server. A successful mapping looks like: client's local
address/port <-> public address/port. address/port <-> public address/port.
4. Perform the RTSP SETUP for each media. In the transport header 4. Perform the RTSP SETUP for each media. In the transport header
the following parameter should be included with the given values: the following parameter should be included with the given values:
skipping to change at page 12, line 40 skipping to change at page 12, line 48
This method is brittle because it assumes one can use STUN to This method is brittle because it assumes one can use STUN to
classify the NAT behavior, which was found to be problematic classify the NAT behavior, which was found to be problematic
[RFC5389]. If the NAT changes the properties of the existing mapping [RFC5389]. If the NAT changes the properties of the existing mapping
and filtering state for example due to load, then the methods will and filtering state for example due to load, then the methods will
fail. fail.
4.1.3. ALG considerations 4.1.3. ALG considerations
If a NAT supports RTSP ALG (Application Level Gateway) and is not If a NAT supports RTSP ALG (Application Level Gateway) and is not
aware of the STUN traversal option, service failure may happen, aware of the STUN traversal option, service failure may happen,
because a client discovers its public IP address and port numbers, because a client discovers its NAT external IP address and port
and inserts them in its SETUP requests. When the RTSP ALG processes numbers, and inserts them in its SETUP requests. When the RTSP ALG
the SETUP request it may change the destination and port number, processes the SETUP request it may change the destination and port
resulting in unpredictable behavior. An ALG should not update number, resulting in unpredictable behavior. An ALG should not
address fields which contains addresses other than the NATs internal update address fields which contains addresses other than the NATs
address domain. In cases where the ALG modifies fields unnecessarily internal address domain. In cases where the ALG modifies fields
two alternatives exist: unnecessarily two alternatives exist:
1. Use TLS to encrypt the RTSP TCP connection to prevent the ALG 1. Use TLS to encrypt the RTSP TCP connection to prevent the ALG
from reading and modifying the RTSP messages. from reading and modifying the RTSP messages.
2. Turn off the STUN based NAT traversal mechanism 2. Turn off the STUN based NAT traversal mechanism
As it may be difficult to determine why the failure occurs, the usage As it may be difficult to determine why the failure occurs, the usage
of TLS protected RTSP message exchange at all times would avoid this of TLS protected RTSP message exchange at all times would avoid this
issue. issue.
4.1.4. Deployment Considerations 4.1.4. Deployment Considerations
For the Stand-Alone usage of STUN the following applies: For the Stand-Alone usage of STUN the following applies:
Advantages: Advantages:
skipping to change at page 13, line 20 skipping to change at page 13, line 29
For the Stand-Alone usage of STUN the following applies: For the Stand-Alone usage of STUN the following applies:
Advantages: Advantages:
o STUN is a solution first used by SIP [RFC3261] based applications o STUN is a solution first used by SIP [RFC3261] based applications
(See section 1 and 2 of [RFC5389]). As shown above, with little (See section 1 and 2 of [RFC5389]). As shown above, with little
or no changes, the RTSP application can re-use STUN as a NAT or no changes, the RTSP application can re-use STUN as a NAT
traversal solution, avoiding the pit-fall of solving a problem traversal solution, avoiding the pit-fall of solving a problem
twice. twice.
o Using STUN does not require RTSP server modifications; it only o Using STUN does not require RTSP server modifications, assuming it
affects the client implementation. is a RTSP 2.0 compliant server; it only affects the client
implementation.
Disadvantages: Disadvantages:
o Requires a STUN server deployed in the public address space. o Requires a STUN server deployed in the same address domain as the
server.
o Only works with NATs that perform endpoint independent and address o Only works with NATs that perform endpoint independent and address
dependent mappings. Address and Port-Dependent filtering NATs dependent mappings. Address and Port-Dependent filtering NATs
create some issues. create some issues.
o Brittle to NATs changing the properties of the NAT mapping and o Brittle to NATs changing the properties of the NAT mapping and
filtering. filtering.
o Does not work with port and address dependent mapping NATs without o Does not work with port and address dependent mapping NATs without
server modifications. server modifications.
skipping to change at page 17, line 9 skipping to change at page 17, line 24
need to embed STUN in RTSP server and client, which require a de- need to embed STUN in RTSP server and client, which require a de-
multiplexer between STUN packets and RTP/RTCP packets. There is multiplexer between STUN packets and RTP/RTCP packets. There is
also a need to register the proper feature tags. also a need to register the proper feature tags.
Disadvantages: Disadvantages:
o Some extensions to the RTSP core protocol, likely signaled by RTSP o Some extensions to the RTSP core protocol, likely signaled by RTSP
feature tags, must be introduced. feature tags, must be introduced.
o Requires an embedded STUN server to be co-located on each of the o Requires an embedded STUN server to be co-located on each of the
RTSP server's media protocol's ports (e.g. RTP and RTCP ports), RTSP server's media protocol's ports (e.g. RTP and RTCP ports),
which means more processing is required to de-multiplex STUN which means more processing is required to de-multiplex STUN
packets from media packets. For example, the de-multiplexer must packets from media packets. For example, the de-multiplexer must
be able to differentiate a RTCP RR packet from a STUN packet, and be able to differentiate a RTCP RR packet from a STUN packet, and
forward the former to the streaming server, and the latter to the forward the former to the streaming server, and the latter to the
STUN server. STUN server.
o Does not support use cases that require the RTSP connection and o Does not support use cases that require the RTSP connection and
the media reception to happen at different addresses, unless the the media reception to happen at different addresses, unless the
server's security policy is relaxed. server's security policy is relaxed.
skipping to change at page 17, line 37 skipping to change at page 17, line 52
o Increases the setup delay with at least the amount of time it o Increases the setup delay with at least the amount of time it
takes to perform STUN message exchanges. Most likely an extra takes to perform STUN message exchanges. Most likely an extra
SETUP sequence will be required. SETUP sequence will be required.
Transition: Transition:
The usage of STUN can be phased out gradually as the first step of a The usage of STUN can be phased out gradually as the first step of a
STUN capable machine can be to check the presence of NATs for the STUN capable machine can be to check the presence of NATs for the
presently used network connection. The removal of STUN capability in presently used network connection. The removal of STUN capability in
the client implementations will have to wait until there is the client implementations will have to wait until there is
absolutely no need to use STUN. absolutely no need to use STUN, i.e. no NATs or firewalls.
4.2.6. Security Considerations 4.2.6. Security Considerations
See Stand-Alone STUN (Section 4.1.5). See Stand-Alone STUN (Section 4.1.5).
4.3. ICE 4.3. ICE
4.3.1. Introduction 4.3.1. Introduction
ICE (Interactive Connectivity Establishment) [RFC5245] is a ICE (Interactive Connectivity Establishment) [RFC5245] is a
skipping to change at page 18, line 16 skipping to change at page 18, line 31
Here is how ICE works at a high level. End point A collects all Here is how ICE works at a high level. End point A collects all
possible addresses that can be used, including local IP addresses, possible addresses that can be used, including local IP addresses,
STUN derived addresses, TURN addresses, etc. On each local port that STUN derived addresses, TURN addresses, etc. On each local port that
any of these address and port pairs lead to, a STUN server is any of these address and port pairs lead to, a STUN server is
installed. This STUN server only accepts STUN requests using the installed. This STUN server only accepts STUN requests using the
correct authentication through the use of a username and password. correct authentication through the use of a username and password.
End-point A then sends a request to establish connectivity with end- End-point A then sends a request to establish connectivity with end-
point B, which includes all possible "destinations" [RFC5245] to get point B, which includes all possible "destinations" [RFC5245] to get
the media through to A. Note that each of A's local address/port the media through to A. Note that each of A's local address/port
pairs (host candidates and server reflexive base) has a STUN server pairs (host candidates and server reflexive base) has a STUN server
co-located. B in turn provides A with all its possible destinations co-located. B in turn provides A with all its possible destinations
for the different media streams. A and B then uses a STUN client to for the different media streams. A and B then uses a STUN client to
try to reach all the address and port pairs specified by A from its try to reach all the address and port pairs specified by A from its
corresponding destination ports. The destinations for which the STUN corresponding destination ports. The destinations for which the STUN
requests successfully complete are then indicated and one is requests successfully complete are then indicated and one is
selected. selected.
If B fails to get any STUN response from A, all hope is not lost. If B fails to get any STUN response from A, all hope is not lost.
Certain NAT topologies require multiple tries from both ends before Certain NAT topologies require multiple tries from both ends before
skipping to change at page 18, line 49 skipping to change at page 19, line 15
This assumes that it is possible to establish a TCP connection for This assumes that it is possible to establish a TCP connection for
the RTSP messages between the client and the server. This is not the RTSP messages between the client and the server. This is not
trivial in scenarios where the server is located behind a NAT, and trivial in scenarios where the server is located behind a NAT, and
may require some TCP ports be opened, or the deployment of proxies, may require some TCP ports be opened, or the deployment of proxies,
etc. etc.
The negotiation of ICE in RTSP of necessity will work different than The negotiation of ICE in RTSP of necessity will work different than
in SIP with SDP offer/answer. The protocol interactions are in SIP with SDP offer/answer. The protocol interactions are
different and thus the possibilities for transfer of states are also different and thus the possibilities for transfer of states are also
somewhat different. The goal is also to avoid introducing extra somewhat different. The goal is also to avoid introducing extra
delay in the setup process at least for when the server is using a delay in the setup process at least for when the server is not behind
public address and the client is either having a public address or is a NAT in regards to the client, and the client is either having an
behind NAT(s). This process is only intended to support PLAY mode, address in the same address domain, or is behind NAT(s) which can
i.e. media traffic flows from server to client. address the address domain of the server. This process is only
intended to support PLAY mode, i.e. media traffic flows from server
to client.
1. The ICE usage begins in the SDP. The SDP for the service 1. The ICE usage begins in the SDP. The SDP for the service
indicates that ICE is supported at the server. No candidates can indicates that ICE is supported at the server. No candidates can
be given here as that would not work with the on demand, DNS load be given here as that would not work with the on demand, DNS load
balancing, etc., that have the SDP indicate a resource on a balancing, etc., that have the SDP indicate a resource on a
server park rather than a specific machine. server park rather than a specific machine.
2. The client gathers addresses and puts together its candidates for 2. The client gathers addresses and puts together its candidates for
each media stream indicated in the session description. each media stream indicated in the session description.
3. In each SETUP request the client includes its candidates in an 3. In each SETUP request the client includes its candidates in an
ICE specific transport specification. This indicates for the ICE specific transport specification. This indicates for the
server the ICE support by the client. One candidate is the most server the ICE support by the client. One candidate is the most
prioritized candidate and here the prioritization for this prioritized candidate and here the prioritization for this
address should be somewhat different compared to SIP. High address should be somewhat different compared to SIP. High
performance rather than always successful is recommended, as it performance candidates is recommended rather than candidates with
is most likely to be a server in the public. the highest likelly hood of success, as it is more likely that a
server is not behind a NAT compared to a SIP user-agent.
4. The server responds to the SETUP (200 OK) for each media stream 4. The server responds to the SETUP (200 OK) for each media stream
with its candidates. A server with a public address usually only with its candidates. A server not behind a NAT usually only
provides a single ICE candidate. Also here one candidate is the provides a single ICE candidate. Also here one candidate is the
server primary address. server primary address.
5. The connectivity checks are performed. For the server the 5. The connectivity checks are performed. For the server the
connectivity checks from the server to the clients have an connectivity checks from the server to the clients have an
additional usage. They verify that there is someone willing to additional usage. They verify that there is someone willing to
receive the media, thus preventing the server from unknowingly receive the media, thus preventing the server from unknowingly
performing a DoS attack. performing a DoS attack.
6. Connectivity checks from the client promoting a candidate pair 6. Connectivity checks from the client promoting a candidate pair
skipping to change at page 20, line 20 skipping to change at page 20, line 34
To keep media paths alive the client needs to periodically send data To keep media paths alive the client needs to periodically send data
to the server. This will be realized with STUN. RTCP sent by the to the server. This will be realized with STUN. RTCP sent by the
client should be able to keep RTCP open but STUN will also be used client should be able to keep RTCP open but STUN will also be used
based on the same motivations as for ICE for SIP. based on the same motivations as for ICE for SIP.
4.3.3. Implementation burden of ICE 4.3.3. Implementation burden of ICE
The usage of ICE will require that a number of new protocols and new The usage of ICE will require that a number of new protocols and new
RTSP/SDP features be implemented. This makes ICE the solution that RTSP/SDP features be implemented. This makes ICE the solution that
has the largest impact on client and server implementations amongst has the largest impact on client and server implementations amongst
all the NAT/Firewall traversal methods in this document. all the NAT/firewall traversal methods in this document.
RTSP server implementation requirements are: RTSP server implementation requirements are:
o STUN server features o STUN server features
o Limited STUN client features o Limited STUN client features
o SDP generation with more parameters. o SDP generation with more parameters.
o RTSP error code for ICE extension o RTSP error code for ICE extension
skipping to change at page 21, line 21 skipping to change at page 21, line 35
the media protocol and STUN packets. the media protocol and STUN packets.
o Has fairly high implementation burden put on both RTSP server and o Has fairly high implementation burden put on both RTSP server and
client. However, several Open Source ICE implementations do client. However, several Open Source ICE implementations do
exist, such as [NICE][PJNATH]. exist, such as [NICE][PJNATH].
4.3.5. Security Consideration 4.3.5. Security Consideration
One should review the security consideration section of ICE and STUN One should review the security consideration section of ICE and STUN
to understand that ICE contains some potential issues. However these to understand that ICE contains some potential issues. However these
can be avoided by correctly using ICE in RTSP. In fact ICE does help can be avoided by correctly using ICE in RTSP. An important factor
avoid the DDoS attack issue with RTSP substantially as it reduces the is to secure the signalling, i.e. use TLS between RTSP client and
possibility for a DDoS using RTSP servers to attackers that are on- server. In fact ICE does help avoid the DDoS attack issue with RTSP
path between the RTSP server and the target and capable of substantially as it reduces the possibility for a DDoS using RTSP
intercepting the STUN connectivity check packets and correctly send a servers to attackers that are on-path between the RTSP server and the
response to the server. target and capable of intercepting the STUN connectivity check
packets and correctly send a response to the server.
4.4. Latching 4.4. Latching
4.4.1. Introduction 4.4.1. Introduction
Latching [I-D.ietf-mmusic-latching] is a NAT traversal solution that Latching [I-D.ietf-mmusic-latching] is a NAT traversal solution that
is based on requiring RTSP clients to send UDP packets to the is based on requiring RTSP clients to send UDP packets to the
server's media output ports. Conventionally, RTSP servers send RTP server's media output ports. Conventionally, RTSP servers send RTP
packets in one direction: from server to client. Latching is similar packets in one direction: from server to client. Latching is similar
to connection-oriented traffic, where one side (e.g., the RTSP to connection-oriented traffic, where one side (e.g., the RTSP
client) first "connects" by sending a RTP packet to the other side's client) first "connects" by sending a RTP packet to the other side's
RTP port, the recipient then replies to the originating IP and port. RTP port, the recipient then replies to the originating IP and port.
This method is also referred to as "Late binding". It requires that This method is also referred to as "Late binding". It requires that
all RTP/RTCP transport is done symmetrical, i.e. Symmetric RTP all RTP/RTCP transport is done symmetrical, i.e. Symmetric RTP
[RFC4961]. [RFC4961].
Specifically, when the RTSP server receives the latching packet Specifically, when the RTSP server receives the latching packet
(a.k.a. hole-punching packet, since it is used to punch a hole in the (a.k.a. hole-punching packet, since it is used to punch a hole in the
Firewall/NAT and to aid the server for port binding and address firewall/NAT and to aid the server for port binding and address
mapping) from its client, it copies the source IP and Port number and mapping) from its client, it copies the source IP and Port number and
uses them as delivery address for media packets. By having the uses them as delivery address for media packets. By having the
server send media traffic back the same way as the client's packet server send media traffic back the same way as the client's packet
are sent to the server, address mappings will be honored. Therefore are sent to the server, address mappings will be honored. Therefore
this technique works for all types of NATs, given that the server is this technique works for all types of NATs, given that the server is
not behind a NAT. However, it does require server modifications. not behind a NAT. However, it does require server modifications.
Unless there is built-in protection mechanism, latching is very Unless there is built-in protection mechanism, latching is very
vulnerable to both hijacking and becoming a tool in Distributed vulnerable to both hijacking and becoming a tool in Distributed
Denail of Service (DDoS) attacks (See Security Considerations of Denail of Service (DDoS) attacks (See Security Considerations of
[I-D.ietf-mmusic-latching]), because attackers can simply forge the [I-D.ietf-mmusic-latching]), because attackers can simply forge the
skipping to change at page 22, line 47 skipping to change at page 23, line 19
o Works for all types of client-facing NATs. (Requirement 1 in o Works for all types of client-facing NATs. (Requirement 1 in
Section 3). Section 3).
o Has no interaction problems with any RTSP ALG changing the o Has no interaction problems with any RTSP ALG changing the
client's information in the transport header. client's information in the transport header.
Disadvantages: Disadvantages:
o Requires modifications to both RTSP server and client. o Requires modifications to both RTSP server and client.
o Limited to work with servers that have an public IP address. o Limited to work with servers that are not behind a NAT.
o The format of the RTP packet for "connection setup" (a.k.a o The format of the RTP packet for "connection setup" (a.k.a
Latching packet) is yet to be defined. One possibility is to use Latching packet) is not defined. One possibility considered was
RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op]. to use RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op], a
proposal which has been abandoned.
o SSRC management if RTP is used for latching due to risk for mis- o SSRC management if RTP is used for latching due to risk for mis-
association of clients to RTSP sessions at the server if SSRC association of clients to RTSP sessions at the server if SSRC
collision occurs. collision occurs.
o Has significant security considerations (See Section 4.4.4), due o Has significant security considerations (See Section 4.4.4), due
to lack of a strong authentication mechanism and will need to use to lack of a strong authentication mechanism and will need to use
address restrictions. address restrictions.
4.4.4. Security Consideration 4.4.4. Security Consideration
skipping to change at page 24, line 44 skipping to change at page 25, line 18
material could be increased. To achieve a longer random tag while material could be increased. To achieve a longer random tag while
still using RTP and RTCP, it will be necessary to develop RTP and still using RTP and RTCP, it will be necessary to develop RTP and
RTCP payload formats for carrying the random material. RTCP payload formats for carrying the random material.
4.5. A Variation to Latching 4.5. A Variation to Latching
4.5.1. Introduction 4.5.1. Introduction
Latching as described above requires the usage of a valid RTP format Latching as described above requires the usage of a valid RTP format
as the Latching packet, i.e. the first packet that the client sends as the Latching packet, i.e. the first packet that the client sends
to the server to set up virtual RTP connection. There is currently to the server to establish a bi-directional transport flow for RTP
no appropriate RTP packet format for this purpose, although the RTP streams. There is currently no appropriate RTP packet format for
No-Op format was a proposal to fix the problem this purpose, although the RTP No-Op format was a proposal to fix the
[I-D.ietf-avt-rtp-no-op], however, that work was abandoned. There problem [I-D.ietf-avt-rtp-no-op], however, that work was abandoned.
exists a RFC that discusses the implication of different type of There exists a RFC that discusses the implication of different type
packets as keep-alives for RTP [RFC6263] and its findings are very of packets as keep-alives for RTP [RFC6263] and its findings are very
relevant to the format of the Latching packet. relevant to the format of the Latching packet.
Meanwhile, there has been NAT/Firewall traversal techniques deployed Meanwhile, there has been NAT/firewall traversal techniques deployed
in the wireless streaming market place that use non-RTP messages as in the wireless streaming market place that use non-RTP messages as
Latching packets. This section describes a variant based on a subset Latching packets. This section describes a variant based on a subset
of those solutions that alters the previously described Latching of those solutions that alters the previously described Latching
solution. solution.
4.5.2. Necessary RTSP extensions 4.5.2. Necessary RTSP extensions
In this variation of Latching, the Latching packet is a small UDP In this variation of Latching, the Latching packet is a small UDP
packet that does not contain an RTP header. In response to the packet that does not contain an RTP header. In response to the
client's Latching packet, the RTSP server sends back a similar client's Latching packet, the RTSP server sends back a similar
skipping to change at page 25, line 37 skipping to change at page 26, line 10
client. client.
The Latching packet can contain the SSRC to identify the RTP stream, The Latching packet can contain the SSRC to identify the RTP stream,
and care must be taken if the packet is bigger than 12 bytes, and care must be taken if the packet is bigger than 12 bytes,
ensuring that it is distinctively different from RTP packets, whose ensuring that it is distinctively different from RTP packets, whose
header size is 12 bytes. header size is 12 bytes.
RTSP signaling can be added to do the following: RTSP signaling can be added to do the following:
1. Enable or disable such Latching message exchanges. When the 1. Enable or disable such Latching message exchanges. When the
Firewall/NAT has an RTSP-aware ALG, it is possible to disable firewall/NAT has an RTSP-aware ALG, it is possible to disable
Latching message exchange and let the ALG work out the address Latching message exchange and let the ALG work out the address
and port mappings. and port mappings.
2. Configure the number of re-tries and the re-try interval of the 2. Configure the number of re-tries and the re-try interval of the
Latching message exchanges. Latching message exchanges.
4.5.3. Deployment Considerations 4.5.3. Deployment Considerations
This approach has the following advantages when compared with the This approach has the following advantages when compared with the
Latching approach (Section 4.4): Latching approach (Section 4.4):
1. There is no need to define RTP payload format for Firewall 1. There is no need to define RTP payload format for firewall
traversal, therefore it is simple to use, implement and traversal, therefore it is simple to use, implement and
administer (Requirement 4 in Section 3), instead a Latching administer (Requirement 4 in Section 3), instead a Latching
protocol must be defined. protocol must be defined.
2. When properly defined, this kind of Latching packet exchange can 2. When properly defined, this kind of Latching packet exchange can
also authenticate RTP receivers, to prevent hijacking attacks. also authenticate RTP receivers, to prevent hijacking attacks.
This approach has the following disadvantages when compared with the This approach has the following disadvantages when compared with the
Latching approach: Latching approach:
skipping to change at page 27, line 24 skipping to change at page 27, line 48
is actually present at that address. The RTSP server will refuse to is actually present at that address. The RTSP server will refuse to
send any media until the Latching Acknowledgement has been received send any media until the Latching Acknowledgement has been received
with a valid nonce. with a valid nonce.
4.6.3. Deployment Considerations 4.6.3. Deployment Considerations
A solution with a 3-way handshake and its own Latching packets can be A solution with a 3-way handshake and its own Latching packets can be
compared with the ICE-based solution (Section 4.3) and have the compared with the ICE-based solution (Section 4.3) and have the
following differences: following differences:
o Only works for servers with public IP addresses compared to any o Only works for servers that are not behind a NAT.
type of server
o May be simpler to implement due to the avoidance of the ICE o May be simpler to implement due to the avoidance of the ICE
prioritization and check-board mechanisms. prioritization and check-board mechanisms.
However, a 3-way Latching protocol is very similar to using STUN in However, a 3-way Latching protocol is very similar to using STUN in
both directions as Latching and verification protocol. Using STUN both directions as Latching and verification protocol. Using STUN
would remove the need for implementing a new protocol. would remove the need for implementing a new protocol.
4.7. Application Level Gateways 4.7. Application Level Gateways
skipping to change at page 28, line 38 skipping to change at page 29, line 13
use. However if multiple NATs are used this detection may use. However if multiple NATs are used this detection may
fail. Remapping should only be done for addresses belonging fail. Remapping should only be done for addresses belonging
to the NAT's own private address space. to the NAT's own private address space.
Otherwise continue to the next step. Otherwise continue to the next step.
3. Create UDP mappings (client given IP/port <-> external IP/port) 3. Create UDP mappings (client given IP/port <-> external IP/port)
where needed for all possible transport specifications in the where needed for all possible transport specifications in the
transport header of the request found in (1). Enter the external transport header of the request found in (1). Enter the external
address and port(s) of these mappings in transport header. address and port(s) of these mappings in transport header.
Mappings shall be created with consecutive public port numbers Mappings shall be created with consecutive external port numbers
starting on an even number for RTP for each media stream. starting on an even number for RTP for each media stream.
Mappings should also be given a long timeout period, at least 5 Mappings should also be given a long timeout period, at least 5
minutes. minutes.
4. When the SETUP response is received from the server, the ALG may 4. When the SETUP response is received from the server, the ALG may
remove the unused UDP mappings, i.e. the ones not present in the remove the unused UDP mappings, i.e. the ones not present in the
transport header. The session ID should also be bound to the UDP transport header. The session ID should also be bound to the UDP
mappings part of that session. mappings part of that session.
5. If SETUP response settles on RTP over TCP or RTP over RTSP as 5. If SETUP response settles on RTP over TCP or RTP over RTSP as
skipping to change at page 29, line 42 skipping to change at page 30, line 18
Transition: Transition:
An RTSP ALG will not be phased out in any automatic way. It must be An RTSP ALG will not be phased out in any automatic way. It must be
removed, probably through the removal of the NAT it is associated removed, probably through the removal of the NAT it is associated
with. with.
4.7.4. Security Considerations 4.7.4. Security Considerations
An ALG will not work with deployment of end-to-end RTSP signaling An ALG will not work with deployment of end-to-end RTSP signaling
security. Therefore deployment of ALG will likely result in clients security. Therefore deployment of ALG will likely result in clients
located behind NATs not using end-to-end security. located behind NATs not using end-to-end security, or more likely
select a NAT traversal solution that allow for security.
The creation of an UDP mapping based on the signalling message has The creation of an UDP mapping based on the signalling message has
some potential security implications. First of all if the RTSP some potential security implications. First of all if the RTSP
client releases its ports and another application are assigned these client releases its ports and another application are assigned these
instead it could receive RTP media as long as the mappings exist and instead it could receive RTP media as long as the mappings exist and
the RTSP server has failed to be signalled or notice the lack of the RTSP server has failed to be signalled or notice the lack of
client response. client response.
A NAT with RTSP ALG that assigns mappings based on SETUP requests A NAT with RTSP ALG that assigns mappings based on SETUP requests
could potentially become victim of a resource exhaustion attack. If could potentially become victim of a resource exhaustion attack. If
skipping to change at page 31, line 48 skipping to change at page 32, line 28
side this is limited to the source address/port pair that have been side this is limited to the source address/port pair that have been
given permission by the TURN client creating the allocation. Packets given permission by the TURN client creating the allocation. Packets
from any other source on this address will be discarded. from any other source on this address will be discarded.
Using a TURN server makes it possible for a RTSP client to receive Using a TURN server makes it possible for a RTSP client to receive
media streams from even an unmodified RTSP server. However the media streams from even an unmodified RTSP server. However the
problem is those RTSP servers most likely restrict media destinations problem is those RTSP servers most likely restrict media destinations
to no other IP address than the one the RTSP message arrives from. to no other IP address than the one the RTSP message arrives from.
This means that TURN could only be used if the server knows and This means that TURN could only be used if the server knows and
accepts that the IP belongs to a TURN server and the TURN server accepts that the IP belongs to a TURN server and the TURN server
can't be targeted at an unknown address or also the RTSP connection can't be targeted at an unknown address. Alternatively, both the
is relayed through the same TURN server. RTSP TCP connection as well as the RTP media is relayed through the
same TURN server.
4.9.2. Usage of TURN with RTSP 4.9.2. Usage of TURN with RTSP
To use a TURN server for NAT traversal, the following steps should be To use a TURN server for NAT traversal, the following steps should be
performed. performed.
1. The RTSP client connects with the RTSP server. The client 1. The RTSP client connects with the RTSP server. The client
retrieves the session description to determine the number of retrieves the session description to determine the number of
media streams. To avoid the issue with having RTSP connection media streams. To avoid the issue with having RTSP connection
and media traffic from different addresses also the TCP and media traffic from different addresses also the TCP
skipping to change at page 33, line 5 skipping to change at page 33, line 33
mapping timeout the client should use TURN to refresh the mapping timeout the client should use TURN to refresh the
bindings. bindings.
4.9.3. Deployment Considerations 4.9.3. Deployment Considerations
Advantages: Advantages:
o Does not require any server modifications given that the server o Does not require any server modifications given that the server
includes the src_addr header in the SETUP response. includes the src_addr header in the SETUP response.
o Works for any type of NAT as long as the RTSP server has public o Works for any type of NAT as long as the RTSP server has reachable
reachable IP address. IP address that is not behind a NAT.
Disadvantage: Disadvantage:
o Requires another network element, namely the TURN server. o Requires another network element, namely the TURN server.
o A TURN server for RTSP may not scale since the number of sessions o A TURN server for RTSP may not scale since the number of sessions
it must forward is proportional to the number of client media it must forward is proportional to the number of client media
sessions. sessions.
o TURN server becomes a single point of failure. o TURN server becomes a single point of failure.
skipping to change at page 34, line 25 skipping to change at page 35, line 5
RTSP session to pass through it. Therefore the firewall will need an RTSP session to pass through it. Therefore the firewall will need an
ALG that reads RTSP SETUP and TEARDOWN messages. By reading the ALG that reads RTSP SETUP and TEARDOWN messages. By reading the
SETUP message the firewall can determine what type of transport and SETUP message the firewall can determine what type of transport and
from where, the media stream packets will be sent. Commonly there from where, the media stream packets will be sent. Commonly there
will be the need to open UDP ports for RTP/RTCP. By looking at the will be the need to open UDP ports for RTP/RTCP. By looking at the
source and destination addresses and ports the opening in the source and destination addresses and ports the opening in the
firewall can be minimized to the least necessary. The opening in the firewall can be minimized to the least necessary. The opening in the
firewall can be closed after a TEARDOWN message for that session or firewall can be closed after a TEARDOWN message for that session or
the session itself times out. the session itself times out.
The above possibilities for firewalls to inspect and respond to the
signalling are prevented if confidentiality protection is used for
the RTSP signalling, e.g. using the specified RTSP over TLS. This
results in that firewalls can't be actively opening pinholes for the
media streams based on the signalling. Instead other methods have to
be used to enable the transport flows for the media.
Simpler firewalls do allow a client to receive media as long as it Simpler firewalls do allow a client to receive media as long as it
has sent packets to the target. Depending on the security level this has sent packets to the target. Depending on the security level this
can have the same behavior as a NAT. The only difference is that no can have the same behavior as a NAT. The only difference is that no
address translation is done. To use such a firewall a client would address translation is done. To use such a firewall a client would
need to implement one of the above described NAT traversal methods need to implement one of the above described NAT traversal methods
that include sending packets to the server to open up the mappings. that include sending packets to the server to open up the mappings.
6. Comparison of NAT traversal techniques 6. Comparison of NAT traversal techniques
This section evaluates the techniques described above against the This section evaluates the techniques described above against the
requirements listed in Section 3. requirements listed in Section 3.
In the following table, the columns correspond to the numbered In the following table, the columns correspond to the numbered
requirements. For instance, the column under R1 corresponds to the requirements. For instance, the column under R1 corresponds to the
first requirement in Section 3: must work for all flavors of NATs. first requirement in Section 3: must work for all flavors of NATs.
The rows represent the different NAT/Firewall traversal techniques. The rows represent the different NAT/firewall traversal techniques.
Latch is short for Latching, "V. Latch" is short for "variation of Latch is short for Latching, "V. Latch" is short for "variation of
Latching" as described in Section 4.5. "3-W Latch" is short for the Latching" as described in Section 4.5. "3-W Latch" is short for the
Three Way Latching described in Section 4.6. Three Way Latching described in Section 4.6.
A Summary of the requirements are: A Summary of the requirements are:
R1: Work for all flavors of NATs R1: Work for all flavors of NATs
R2: Must work with Firewalls, including those with ALGs R2: Must work with firewalls, including those with ALGs
R3: Should have minimal impact on clients not behind NATs, counted R3: Should have minimal impact on clients not behind NATs, counted
in minimal number of additional RTTs in minimal number of additional RTTs
R4: Should be simple to use, Implement and administer. R4: Should be simple to use, Implement and administer.
R5: Should provide mitigation against DDoS attacks R5: Should provide mitigation against DDoS attacks
The following considerations are also added to requirements: The following considerations are also added to requirements:
skipping to change at page 36, line 23 skipping to change at page 37, line 15
7. IANA Considerations 7. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
8. Security Considerations 8. Security Considerations
In the preceding sections we have discussed security merits of the In the preceding sections we have discussed security merits of the
different NAT/Firewall traversal methods for RTSP discussed here. In different NAT/firewall traversal methods for RTSP discussed here. In
summary, the presence of NAT(s) is a security risk, as a client summary, the presence of NAT(s) is a security risk, as a client
cannot perform source authentication of its IP address. This cannot perform source authentication of its IP address. This
prevents the deployment of any future RTSP extensions providing prevents the deployment of any future RTSP extensions providing
security against hijacking of sessions by a man-in-the-middle. security against hijacking of sessions by a man-in-the-middle.
Each of the proposed solutions has security implications. Using STUN Each of the proposed solutions has security implications. Using STUN
will provide the same level of security as RTSP without transport will provide the same level of security as RTSP without transport
level security and source authentications, as long as the server does level security and source authentications, as long as the server does
not allow media to be sent to a different IP-address than the RTSP not allow media to be sent to a different IP-address than the RTSP
client request was sent from. Using Latching will have a higher risk client request was sent from. Using Latching will have a higher risk
of session hijacking or denial of service than normal RTSP. The of session hijacking or denial of service than normal RTSP. The
reason is that there exists a probability that an attacker is able to reason is that there exists a probability that an attacker is able to
guess the random bits that the client uses to prove its identity when guess the random bits that the client uses to prove its identity when
creating the address bindings. This can be solved in the variation creating the address bindings. This can be solved in the variation
of Latching (Section 4.5) with authentication features. Still both of Latching (Section 4.5) with authentication features. Still both
those variants of Latching are vulnerable against deliberate attack those variants of Latching are vulnerable against deliberate attack
from the RTSP client to redirect the media stream requested to any from the RTSP client to redirect the media stream requested to any
target assuming it can spoof the source address. This security target assuming it can spoof the source address. This security
vulnerability is solved by performing a Three-way Latching procedure vulnerability is solved by performing a Three-way Latching procedure
as discussed in Section 4.6. The usage of an RTSP ALG does not in as discussed in Section 4.6. ICE resolves the binding vulnerability
itself increase the risk for session hijacking. However the of latching by using signed STUN messages, as well as requiring that
deployment of ALGs as the sole mechanism for RTSP NAT traversal will both sides perform connectivity checks to verify that the target IP
prevent deployment of end-to-end encrypted RTSP signaling. The usage address in the candidate pair is both reachable and willing to
of TCP tunneling has no known security problems. However, it might respond. ICE can however create a significant amount of traffic if
provide a bottleneck when it comes to end-to-end RTSP signaling the number of candidate pairs are large. Thus pacing is required and
security if TCP tunneling is used on an interleaved RTSP signaling implementations should attempt to limit their number of candidates to
connection. The usage of TURN has severe risk of denial of service reduce the number of packets. If the signalling between the ICE
attacks against a client. The TURN server can also be used as a peers (RTSP client and Server) is not confidentiality and integrity
redirect point in a DDoS attack unless the server has strict enough protected ICE is vulnerable to attacks where the candidate list is
rules for who may create bindings. manipulated. Lack of signalling security will also simplify spoofing
of STUN binding messages by revealing the secret used in signing.
The usage of an RTSP ALG does not in itself increase the risk for
session hijacking. However the deployment of ALGs as the sole
mechanism for RTSP NAT traversal will prevent deployment of end-to-
end encrypted RTSP signaling. The usage of TCP tunneling has no
known security problems. However, it might provide a bottleneck when
it comes to end-to-end RTSP signaling security if TCP tunneling is
used on an interleaved RTSP signaling connection. The usage of TURN
has severe risk of denial of service attacks against a client. The
TURN server can also be used as a redirect point in a DDoS attack
unless the server has strict enough rules for who may create
bindings.
9. Acknowledgements 9. Acknowledgements
The author would also like to thank all persons on the MMUSIC working The author would also like to thank all persons on the MMUSIC working
group's mailing list that has commented on this document. Persons group's mailing list that has commented on this document. Persons
having contributed in such way in no special order to this protocol having contributed in such way in no special order to this protocol
are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon, are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon,
Amir Wolf, Anders Klemets, Flemming Andreasen, Ari Keranen, Bill Amir Wolf, Anders Klemets, Flemming Andreasen, Ari Keranen, Bill
Atwood, and Colin Perkins. Thomas Zeng would also like to give Atwood, and Colin Perkins. Thomas Zeng would also like to give
special thanks to Greg Sherwood of PacketVideo for his input into special thanks to Greg Sherwood of PacketVideo for his input into
skipping to change at page 37, line 30 skipping to change at page 38, line 33
10. Informative References 10. Informative References
[I-D.ietf-avt-rtp-no-op] [I-D.ietf-avt-rtp-no-op]
Andreasen, F., "A No-Op Payload Format for RTP", draft- Andreasen, F., "A No-Op Payload Format for RTP", draft-
ietf-avt-rtp-no-op-04 (work in progress), May 2007. ietf-avt-rtp-no-op-04 (work in progress), May 2007.
[I-D.ietf-mmusic-latching] [I-D.ietf-mmusic-latching]
Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT
Traversal (HNT) for Media in Real-Time Communication", Traversal (HNT) for Media in Real-Time Communication",
draft-ietf-mmusic-latching-04 (work in progress), October draft-ietf-mmusic-latching-05 (work in progress), May
2013. 2014.
[I-D.ietf-mmusic-rfc2326bis] [I-D.ietf-mmusic-rfc2326bis]
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, "Real Time Streaming Protocol 2.0 and M. Stiemerling, "Real Time Streaming Protocol 2.0
(RTSP)", draft-ietf-mmusic-rfc2326bis-39 (work in (RTSP)", draft-ietf-mmusic-rfc2326bis-40 (work in
progress), January 2014. progress), February 2014.
[I-D.ietf-mmusic-rtsp-nat] [I-D.ietf-mmusic-rtsp-nat]
Goldberg, J., Westerlund, M., and T. Zeng, "A Network Goldberg, J., Westerlund, M., and T. Zeng, "A Network
Address Translator (NAT) Traversal Mechanism for Media Address Translator (NAT) Traversal Mechanism for Media
Controlled by Real-Time Streaming Protocol (RTSP)", draft- Controlled by Real-Time Streaming Protocol (RTSP)", draft-
ietf-mmusic-rtsp-nat-20 (work in progress), February 2014. ietf-mmusic-rtsp-nat-20 (work in progress), February 2014.
[NICE] "Libnice - The GLib ICE implementation, [NICE] "Libnice - The GLib ICE implementation,
http://nice.freedesktop.org/wiki/", May 2013. http://nice.freedesktop.org/wiki/", May 2013.
 End of changes. 62 change blocks. 
144 lines changed or deleted 178 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/