draft-ietf-mmusic-rtsp-nat-evaluation-06.txt   draft-ietf-mmusic-rtsp-nat-evaluation-07.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: May 27, 2013 November 23, 2012 Expires: November 24, 2013 May 23, 2013
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-06 draft-ietf-mmusic-rtsp-nat-evaluation-07
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 on how it would be (RTSP). Each technique includes a description on 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 relates to firewalls and how each technique can traversal techniques relates to firewalls and how each technique can
be applied in different use cases. These findings where used when be applied in different use cases. These findings where used when
selecting the NAT traversal for RTSP 2.0. selecting the NAT traversal for RTSP 2.0.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 27, 2013. This Internet-Draft will expire on November 24, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 3, line 7 skipping to change at page 2, line 24
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Network Address Translators . . . . . . . . . . . . . . . 6 1.1. Network Address Translators . . . . . . . . . . . . . . . 4
1.2. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Detecting the loss of NAT mappings . . . . . . . . . . . . . . 8 2. Detecting the loss of NAT mappings . . . . . . . . . . . . . 7
3. Requirements on NAT-Traversal . . . . . . . . . . . . . . . . 9 3. Requirements on Solutions . . . . . . . . . . . . . . . . . . 8
4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . . 10 4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . 9
4.1. Stand-Alone STUN . . . . . . . . . . . . . . . . . . . . . 11 4.1. Stand-Alone STUN . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . 11 modifications . . . . . . . . . . . . . . . . . . . . 10
4.1.3. ALG considerations . . . . . . . . . . . . . . . . . . 14 4.1.3. ALG considerations . . . . . . . . . . . . . . . . . 12
4.1.4. Deployment Considerations . . . . . . . . . . . . . . 14 4.1.4. Deployment Considerations . . . . . . . . . . . . . . 13
4.1.5. Security Considerations . . . . . . . . . . . . . . . 15 4.1.5. Security Considerations . . . . . . . . . . . . . . . 14
4.2. Server Embedded STUN . . . . . . . . . . . . . . . . . . . 16 4.2. Server Embedded STUN . . . . . . . . . . . . . . . . . . 14
4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . 14
4.2.2. Embedding STUN in RTSP . . . . . . . . . . . . . . . . 16 4.2.2. Embedding STUN in RTSP . . . . . . . . . . . . . . . 14
4.2.3. Discussion On Co-located STUN Server . . . . . . . . . 17 4.2.3. Discussion On Co-located STUN Server . . . . . . . . 16
4.2.4. ALG considerations . . . . . . . . . . . . . . . . . . 17 4.2.4. ALG considerations . . . . . . . . . . . . . . . . . 16
4.2.5. Deployment Considerations . . . . . . . . . . . . . . 17 4.2.5. Deployment Considerations . . . . . . . . . . . . . . 16
4.2.6. Security Considerations . . . . . . . . . . . . . . . 19 4.2.6. Security Considerations . . . . . . . . . . . . . . . 17
4.3. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 19 4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . 17
4.3.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 20 4.3.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 18
4.3.3. Implementation burden of ICE . . . . . . . . . . . . . 21 4.3.3. Implementation burden of ICE . . . . . . . . . . . . 20
4.3.4. Deployment Considerations . . . . . . . . . . . . . . 22 4.3.4. Deployment Considerations . . . . . . . . . . . . . . 20
4.3.5. Security Consideration . . . . . . . . . . . . . . . . 22 4.3.5. Security Consideration . . . . . . . . . . . . . . . 21
4.4. Latching . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.4. Latching . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 22 4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . 21
4.4.2. Necessary RTSP extensions . . . . . . . . . . . . . . 23 4.4.2. Necessary RTSP extensions . . . . . . . . . . . . . . 22
4.4.3. Deployment Considerations . . . . . . . . . . . . . . 23 4.4.3. Deployment Considerations . . . . . . . . . . . . . . 22
4.4.4. Security Consideration . . . . . . . . . . . . . . . . 24 4.4.4. Security Consideration . . . . . . . . . . . . . . . 23
4.5. A Variation to Latching . . . . . . . . . . . . . . . . . 25 4.5. A Variation to Latching . . . . . . . . . . . . . . . . . 24
4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . . 25 4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . 24
4.5.2. Necessary RTSP extensions . . . . . . . . . . . . . . 26 4.5.2. Necessary RTSP extensions . . . . . . . . . . . . . . 25
4.5.3. Deployment Considerations . . . . . . . . . . . . . . 27 4.5.3. Deployment Considerations . . . . . . . . . . . . . . 25
4.5.4. Security Considerations . . . . . . . . . . . . . . . 27 4.5.4. Security Considerations . . . . . . . . . . . . . . . 26
4.6. Three Way Latching . . . . . . . . . . . . . . . . . . . . 27 4.6. Three Way Latching . . . . . . . . . . . . . . . . . . . 26
4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 28 4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . 26
4.6.2. Necessary RTSP extensions . . . . . . . . . . . . . . 28 4.6.2. Necessary RTSP extensions . . . . . . . . . . . . . . 26
4.6.3. Deployment Considerations . . . . . . . . . . . . . . 28 4.6.3. Deployment Considerations . . . . . . . . . . . . . . 27
4.7. Application Level Gateways . . . . . . . . . . . . . . . . 28 4.7. Application Level Gateways . . . . . . . . . . . . . . . 27
4.7.1. Introduction . . . . . . . . . . . . . . . . . . . . . 29 4.7.1. Introduction . . . . . . . . . . . . . . . . . . . . 27
4.7.2. Outline On how ALGs for RTSP work . . . . . . . . . . 29 4.7.2. Outline On how ALGs for RTSP work . . . . . . . . . . 27
4.7.3. Deployment Considerations . . . . . . . . . . . . . . 30 4.7.3. Deployment Considerations . . . . . . . . . . . . . . 29
4.7.4. Security Considerations . . . . . . . . . . . . . . . 31 4.7.4. Security Considerations . . . . . . . . . . . . . . . 29
4.8. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 30
4.8. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 31 4.8.1. Introduction . . . . . . . . . . . . . . . . . . . . 30
4.8.1. Introduction . . . . . . . . . . . . . . . . . . . . . 31 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 . . . . . . . . . . . . . . 32 4.8.4. Security Considerations . . . . . . . . . . . . . . . 31
4.8.4. Security Considerations . . . . . . . . . . . . . . . 32 4.9. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . 31
4.9. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . . 32 4.9.1. Introduction . . . . . . . . . . . . . . . . . . . . 31
4.9.1. Introduction . . . . . . . . . . . . . . . . . . . . . 32 4.9.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 31
4.9.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 33 4.9.3. Deployment Considerations . . . . . . . . . . . . . . 32
4.9.3. Deployment Considerations . . . . . . . . . . . . . . 34 4.9.4. Security Considerations . . . . . . . . . . . . . . . 33
4.9.4. Security Considerations . . . . . . . . . . . . . . . 35 5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6. Comparison of NAT traversal techniques . . . . . . . . . . . 34
6. Comparison of NAT traversal techniques . . . . . . . . . . . . 36 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 10. Informative References . . . . . . . . . . . . . . . . . . . 37
10. Informative References . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
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
skipping to change at page 7, line 4 skipping to change at page 5, line 41
address and port. Note that this is not the same as an "address address and port. Note that this is not the same as an "address
binding" as defined in RFC 2663. There exist a number of address and binding" as defined in RFC 2663. There exist a number of address and
port mapping behaviors described in more detail in Section 4.1 of port mapping behaviors described in more detail in Section 4.1 of
"Network Address Translation (NAT) Behavioral Requirements for "Network Address Translation (NAT) Behavioral Requirements for
Unicast UDP" [RFC4787]. Unicast UDP" [RFC4787].
NATs also have a filtering behavior on traffic arriving on the NATs also have a filtering behavior on traffic arriving on the
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. public Internet. Many
organizations use firewalls to prevent privacy intrusions and organizations use firewalls to prevent privacy intrusions and
malicious attacks to corporate computing resources in the private malicious attacks to 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 must sit between two network administrative domains, 1. A firewall must sit between two network administrative domains,
while NAT does not have to sit between two domains. while NAT does not have to sit between two domains.
2. NAT does not in itself provide security, although some access 2. NAT does not in itself provide security, although some access
skipping to change at page 9, line 26 skipping to change at page 8, line 10
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 that the client is mal-functioning. box NAT/Firewall, or that the client is mal-functioning.
3. Requirements on NAT-Traversal 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 in the public address realm. However, there are use
cases where the reverse is true: RTSP clients are connecting from cases where the reverse is true: RTSP clients are connecting from
public address realm to RTSP servers behind home NATs. This is the public address realm to RTSP servers behind home NATs. This is the
case for instance when home surveillance cameras running as RTSP case for instance when home surveillance cameras running as RTSP
servers intend to stream video to cell phone users in the public servers intend to stream video to cell phone users in the public
address realm through a home NAT. In terms of requirements, the address realm through a home NAT. In terms of requirements, the
first requirement should be to solve the RTSP NAT traversal problem first requirement should be to solve the RTSP NAT traversal problem
for RTSP servers deployed in a public network, i.e. no NAT at the for RTSP servers deployed in a public network, i.e. no NAT at the
server side. server side.
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 restricted 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 in the open and not dual-
hosted. RTSP dual-hosting means that the RTSP signalling hosted. RTSP dual-hosting means that the RTSP signalling
protocol and the media protocol (e.g. RTP) are implemented on protocol and the media protocol (e.g. RTP) are implemented on
different computers with different IP addresses. 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
* Address discovery for NAT traversal should take automatically, * Discovery of the address(es) assigned by NAT should happen
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 public IP address of the RTP receiver host is different than the
skipping to change at page 10, line 42 skipping to change at page 9, line 26
streams in general consist of large number of IP packets. DDoS streams in general consist of large number of IP packets. DDoS
attacks occur if the attacker fakes the messages in the NAT traversal attacks occur if the attacker fakes the messages in the NAT traversal
mechanism to trick the RTSP server into believing that the client's mechanism to trick the RTSP server into believing that the client's
RTP receiver is located on a separate host. For example, user A may RTP receiver is located on a separate host. For example, user A may
use his RTSP client to direct the RTSP server to send video RTP use his RTSP client to direct the RTSP server to send video RTP
streams to target.example.com in order to degrade the services streams to target.example.com in order to degrade the services
provided by target.example.com. Note a simple preventative measure provided by target.example.com. Note a simple preventative measure
commonly deployed is for the RTSP server to disallow the cases where commonly deployed is for the RTSP server to disallow the cases where
the client's RTP receiver has a different public IP address than that the client's RTP receiver has a different public IP address than that
of the RTSP client. With the increased deployment of NAT middleboxes of the RTSP client. With the increased deployment of NAT middleboxes
by operators, i.e. carrier grade NAT (CGN), the reusing of a public by operators, i.e. carrier grade NAT (CGN), the reusing of a public
IP address for many customers reduces the protection provided. Also IP address for many customers reduces the protection provided. Also
in some applications (e.g., centralized conferencing), dual-hosted in some applications (e.g., centralized conferencing), dual-hosted
RTSP/RTP clients have valid use cases. The key is how to RTSP/RTP clients have valid use cases. The key is how to
authenticate the messages exchanged during the NAT traversal process. 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
skipping to change at page 18, line 17 skipping to change at page 16, line 46
in-depth security discussion. in-depth security discussion.
o This solution works as long as there is only one RTSP endpoint in o This solution works as long as there is only one RTSP endpoint in
the private address realm, regardless of the NAT's type. There the private address realm, regardless of the NAT's type. There
may even be multiple NATs (see Figure 1 in [RFC5389]). may even be multiple NATs (see Figure 1 in [RFC5389]).
o Compared to other UDP based NAT traversal methods in this o Compared to other UDP based NAT traversal methods in this
document, STUN requires little new protocol development (since document, STUN requires little new protocol development (since
STUN is already a IETF standard), and most likely less STUN is already a IETF standard), and most likely less
implementation effort, since open source STUN server and client implementation effort, since open source STUN server and client
implementations have become available [STUN-IMPL]. There is the implementations are available [STUN-IMPL][PJNATH]. There is the
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
skipping to change at page 19, line 35 skipping to change at page 18, line 16
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 20, line 25 skipping to change at page 19, line 12
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 using a
public address and the client is either having a public address or is public address and the client is either having a public address or is
behind NAT(s). This process is only intended to support PLAY mode, behind NAT(s). This process is only intended to support PLAY mode,
i.e. media traffic flows from server to client. 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.
skipping to change at page 22, line 32 skipping to change at page 21, line 19
Disadvantages: Disadvantages:
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 for the server to perform its STUN requests. takes for the server to perform its STUN requests.
o Assumes that it is possible to de-multiplex between the packets of o Assumes that it is possible to de-multiplex between the packets of
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. client. However, several Open Source ICE implementations do
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. In fact ICE does help
avoid the DDoS attack issue with RTSP substantially as it reduces the avoid the DDoS attack issue with RTSP substantially as it reduces the
possibility for a DDoS using RTSP servers to attackers that are on- possibility for a DDoS using RTSP servers to attackers that are on-
path between the RTSP server and the target and capable of path between the RTSP server and the target and capable of
intercepting the STUN connectivity check packets and correctly send a intercepting the STUN connectivity check packets and correctly send a
skipping to change at page 23, line 11 skipping to change at page 21, line 48
clients to send UDP packets to the server's media output ports. clients to send UDP packets to the server's media output ports.
Conventionally, RTSP servers send RTP packets in one direction: from Conventionally, RTSP servers send RTP packets in one direction: from
server to client. Latching is similar to connection-oriented server to client. Latching is similar to connection-oriented
traffic, where one side (e.g., the RTSP client) first "connects" by traffic, where one side (e.g., the RTSP client) first "connects" by
sending a RTP packet to the other side's RTP port, the recipient then sending a RTP packet to the other side's RTP port, the recipient then
replies to the originating IP and port. This method is also referred replies to the originating IP and port. This method is also referred
to as "Late binding". It requires that all RTP/RTCP transport is to as "Late binding". It requires that all RTP/RTCP transport is
done symmetrical, i.e. Symmetric RTP [RFC4961]. done symmetrical, i.e. Symmetric RTP [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
Firewall/NAT and to aid the server for port binding and address the 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 DDoS attacks, because attackers can simply forge the vulnerable to DDoS attacks, because attackers can simply forge the
source IP & Port of the latching packet. Using the rule for source IP & Port of the latching packet. Using the rule for
restricting IP address to the one of the signaling connection will restricting IP address to the one of the signaling connection will
skipping to change at page 25, line 50 skipping to change at page 24, line 39
To improve the security against attackers the amount of random To improve the security against attackers the amount of random
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 existed no to the server to set up virtual RTP connection. There existed no
appropriate RTP packet format for this purpose, although the No-Op appropriate RTP packet format for this purpose, although the No-Op
format was a proposal to fix the problem [I-D.ietf-avt-rtp-no-op]. format was a proposal to fix the problem [I-D.ietf-avt-rtp-no-op].
However, that work was abandoned. There exists a RFC that discusses However, that work was abandoned. There exists a RFC that discusses
the implication of different type of packets as keep-alives for RTP the implication of different type of packets as keep-alives for RTP
[RFC6263] and its findings are very relevant to the format of the [RFC6263] and its findings are very relevant to the format of the
Latching packet. 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
skipping to change at page 28, line 20 skipping to change at page 26, line 49
address present in the latching packet is an active listener and address present in the latching packet is an active listener and
confirm its desire to establish a media flow. confirm its desire to establish a media flow.
4.6.2. Necessary RTSP extensions 4.6.2. Necessary RTSP extensions
Uses the same RTSP extensions as the alternative latching method Uses the same RTSP extensions as the alternative latching method
(Section 4.5) uses. The extensions for this variant are only in the (Section 4.5) uses. The extensions for this variant are only in the
format and transmission of the Latching packets. format and transmission of the Latching packets.
The client to server latching packet is similar to the Alternative The client to server latching packet is similar to the Alternative
Latching (Section 4.5), i.e. an UDP packet with some session Latching (Section 4.5), i.e. an UDP packet with some session
identifier and a random value. When the server responds to the identifier and a random value. When the server responds to the
Latching packet with a Latching confirmation, it includes a random Latching packet with a Latching confirmation, it includes a random
value (Nonce) of its own in addition to echoing back the one the value (Nonce) of its own in addition to echoing back the one the
client sent. Then a third messages is added to the exchange. The client sent. Then a third messages is added to the exchange. The
client acknowledges the reception of the Latching confirmation client acknowledges the reception of the Latching confirmation
message and echoes back the server's nonce. Thus confirming that the message and echoes back the server's nonce. Thus confirming that the
Latched address goes to a RTSP client that initiated the latching and Latched address goes to a RTSP client that initiated the latching and
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.
skipping to change at page 30, line 15 skipping to change at page 28, line 39
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 public 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
lower transport, do nothing: let TCP tunneling take care of NAT lower transport, do nothing: let TCP tunneling take care of NAT
traversal. Otherwise go to next step. traversal. Otherwise go to next step.
6. The ALG should keep the UDP mappings belonging to the RTSP 6. The ALG should keep the UDP mappings belonging to the RTSP
session as long as: an RTSP messages with the session's ID has session as long as: an RTSP messages with the session's ID has
been sent in the last timeout interval, or a UDP messages has been sent in the last timeout interval, or a UDP messages has
skipping to change at page 31, line 11 skipping to change at page 29, line 35
STUN. STUN.
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 whit 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.
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.
skipping to change at page 32, line 51 skipping to change at page 31, line 31
4.9.1. Introduction 4.9.1. Introduction
Traversal Using Relay NAT (TURN) [RFC5766] is a protocol for setting Traversal Using Relay NAT (TURN) [RFC5766] is a protocol for setting
up traffic relays that allow clients behind NATs and firewalls to up traffic relays that allow clients behind NATs and firewalls to
receive incoming traffic for both UDP and TCP. These relays are receive incoming traffic for both UDP and TCP. These relays are
controlled and have limited resources. They need to be allocated controlled and have limited resources. They need to be allocated
before usage. TURN allows a client to temporarily bind an address/ before usage. TURN allows a client to temporarily bind an address/
port pair on the relay (TURN server) to its local source address/port port pair on the relay (TURN server) to its local source address/port
pair, which is used to contact the TURN server. The TURN server will pair, which is used to contact the TURN server. The TURN server will
then forward packets between the two sides of the relay. To prevent then forward packets between the two sides of the relay.
DoS attacks on either recipient, the packets forwarded are restricted
to the specific source address. On the client side it is restricted To prevent DoS attacks on either recipient, the packets forwarded are
to the source setting up the mapping. On the external side this is restricted to the specific source address. On the client side it is
limited to the source address/port pair of the first packet arriving restricted to the source setting up the allocation. On the external
on the binding. After the first packet has arrived the mapping is side this is limited to the source address/port pair that have been
"locked down" to that address. Packets from any other source on this given permission by the TURN client creating the allocation. Packets
address will be discarded. Using a TURN server makes it possible for from any other source on this address will be discarded.
a RTSP client to receive media streams from even an unmodified RTSP
server. However the problem is those RTSP servers most likely Using a TURN server makes it possible for a RTSP client to receive
restrict media destinations to no other IP address than the one the media streams from even an unmodified RTSP server. However the
RTSP message arrives from. This means that TURN could only be used problem is those RTSP servers most likely restrict media destinations
if the server knows and accepts that the IP belongs to a TURN server to no other IP address than the one the RTSP message arrives from.
and the TURN server can't be targeted at an unknown address or also This means that TURN could only be used if the server knows and
the RTSP connection is relayed through the same 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
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 36, line 26 skipping to change at page 35, line 4
the session itself times out. the session itself times out.
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:
C1: Will solution support both Clients and Servers behind NAT C1: Will solution support both Clients and Servers behind NAT
C2: How Robust is the solution to changing NAT behaviors C2: Is the solution robust to changing NAT behaviors
------------+------+------+------+------+------+------+------+ ------------+------+------+------+------+------+------+------+
| R1 | R2 | R3 | R4 | R5 | C1 | C2 | | R1 | R2 | R3 | R4 | R5 | C1 | C2 |
------------+------+------+------+------+------+------+------+ ------------+------+------+------+------+------+------+------+
STUN | No | Yes | 1 | Maybe| No | No | No | STUN | No | Yes | 1 | Maybe| No | No | No |
------------+------+------+------+------+------+------+------+ ------------+------+------+------+------+------+------+------+
Emb. STUN | Yes | Yes | 2 | Maybe| No | No | Yes | Emb. STUN | Yes | Yes | 2 | Maybe| No | No | Yes |
------------+------+------+------+------+------+------+------+ ------------+------+------+------+------+------+------+------+
ICE | Yes | Yes | 2.5 | No | Yes | Yes | Yes | ICE | Yes | Yes | 2.5 | No | Yes | Yes | Yes |
------------+------+------+------+------+------+------+------+ ------------+------+------+------+------+------+------+------+
skipping to change at page 39, line 12 skipping to change at page 37, line 32
attacks against a client. The TURN server can also be used as a 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 redirect point in a DDoS attack unless the server has strict enough
rules for who may create bindings. 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, and Colin Perkins. Thomas Zeng would also Amir Wolf, Anders Klemets, Flemming Andreasen, Ari Keranen, and Colin
like to give special thanks to Greg Sherwood of PacketVideo for his Perkins. Thomas Zeng would also like to give special thanks to Greg
input into this memo. Sherwood of PacketVideo for his input into this memo.
Section 1.1 contains text originally written for RFC 4787 by Francois Section 1.1 contains text originally written for RFC 4787 by Francois
Audet and Cullen Jennings. Audet and Cullen Jennings.
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", Andreasen, F., "A No-Op Payload Format for RTP", draft-
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-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-30 (work in (RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in
progress), July 2012. progress), April 2013.
[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)", controlled by Real-Time Streaming Protocol (RTSP)", draft-
draft-ietf-mmusic-rtsp-nat-14 (work in progress), ietf-mmusic-rtsp-nat-15 (work in progress), May 2013.
November 2012.
[NICE] , "Libnice - The GLib ICE implementation,
http://nice.freedesktop.org/wiki/", May 2013.
[PJNATH] , "PJNATH - Open Source ICE, STUN, and TURN Library,
http://www.pjsip.org/pjnath/docs/html/", May 2013.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
RFC 793, September 1981. 793, September 1981.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May
May 1999. 1999.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations", RFC
RFC 2663, August 1999. 2663, August 1999.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022, January
January 2001. 2001.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. IAB, "IAB Considerations for UNilateral Self-
Self-Address Fixing (UNSAF) Across Network Address Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
skipping to change at page 40, line 42 skipping to change at page 39, line 18
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, July 2007. BCP 131, RFC 4961, July 2007.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245, April
April 2010. 2010.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008. RFC 5382, October 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays
around NAT (TURN) Extensions for TCP Allocations", around NAT (TURN) Extensions for TCP Allocations", RFC
RFC 6062, November 2010. 6062, November 2010.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
Keeping Alive the NAT Mappings Associated with RTP / RTP Keeping Alive the NAT Mappings Associated with RTP / RTP
Control Protocol (RTCP) Flows", RFC 6263, June 2011. Control Protocol (RTCP) Flows", RFC 6263, June 2011.
[STUN-IMPL] [STUN-IMPL]
"Open Source STUN Server and Client, http:// , "Open Source STUN Server and Client,
www.vovida.org/applications/downloads/stun/index.html", http://sourceforge.net/projects/stun/", May 2013.
June 2007.
Authors' Addresses Authors' Addresses
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
Stockholm, SE-164 80 Stockholm SE-164 80
Sweden Sweden
Phone: +46 8 719 0000 Phone: +46 8 719 0000
Fax:
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
URI:
Thomas Zeng Thomas Zeng
Phone:
Fax:
Email: thomas.zeng@gmail.com Email: thomas.zeng@gmail.com
URI:
 End of changes. 44 change blocks. 
138 lines changed or deleted 138 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/