draft-ietf-mmusic-rtsp-nat-evaluation-09.txt   draft-ietf-mmusic-rtsp-nat-evaluation-10.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: November 30, 2013 May 29, 2013 Expires: May 22, 2014
November 18, 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-09 draft-ietf-mmusic-rtsp-nat-evaluation-10
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
skipping to change at page 1, line 39 skipping to change at page 1, line 40
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 November 30, 2013. This Internet-Draft will expire on May 22, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 5, line 48 skipping to change at page 5, line 48
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 8, line 23 skipping to change at page 8, line 23
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-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 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
skipping to change at page 9, line 26 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 9, line 50 skipping to change at page 9, line 50
The main evaluation was done prior to 2007 and are based on what was The main evaluation was done prior to 2007 and are 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 technique. barrier against doing an evaluation of the NAT traversal technique.
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 15
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 recommend to be period for any UDP mapping on the NAT. This is recommend 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 17, line 9 skipping to change at page 17, line 9
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 18, line 16 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 19, line 12 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 21, line 45 skipping to change at page 21, line 45
4.4.1. Introduction 4.4.1. Introduction
Latching is a NAT traversal solution that is based on requiring RTSP Latching is a NAT traversal solution that is based on requiring RTSP
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 (a.k.a. hole-punching packet, since it is used to punch a hole in the
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 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 24, line 39 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 26, line 49 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 28, line 39 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 32, line 34 skipping to change at page 32, line 34
verify that it is allowed to send media traffic to the given verify that it is allowed to send media traffic to the given
address. address.
5. The RTSP Client uses the RTSP Server's response to create TURN 5. The RTSP Client uses the RTSP Server's response to create TURN
permissions for the server's media traffic. permissions for the server's media traffic.
6. The client requests that the server starts playing. The server 6. The client requests that the server starts playing. The server
starts sending media packets to the given destination address and starts sending media packets to the given destination address and
ports. ports.
7. The first media packet arrive at the TURN server on the external 7. Media packets arrive at the TURN server on the external port; If
port; If the packet matches an established permission the TURN the packets match an established permission, the TURN server
server forwards the media packet to the RTSP client. forwards the media packets to the RTSP client.
8. If the client pauses and media is not sent for about 75% of the 8. If the client pauses and media is not sent for about 75% of the
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
skipping to change at page 34, line 41 skipping to change at page 34, line 41
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
skipping to change at page 38, line 4 skipping to change at page 38, line 4
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-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-34 (work in (RTSP)", draft-ietf-mmusic-rfc2326bis-38 (work in
progress), April 2013. progress), October 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)", draft- controlled by Real-Time Streaming Protocol (RTSP)", draft-
ietf-mmusic-rtsp-nat-16 (work in progress), May 2013. ietf-mmusic-rtsp-nat-17 (work in progress), Nov 2013.
[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.
[PJNATH] , "PJNATH - Open Source ICE, STUN, and TURN Library, [PJNATH] , "PJNATH - Open Source ICE, STUN, and TURN Library,
http://www.pjsip.org/pjnath/docs/html/", May 2013. 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.
skipping to change at page 38, line 39 skipping to change at page 38, line 39
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", RFC Translator (NAT) Terminology and Considerations", 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, January Address Translator (Traditional NAT)", RFC 3022, January
2001. 2001.
[RFC3424] Daigle, L. IAB, "IAB Considerations for UNilateral Self- [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Address Fixing (UNSAF) Across Network Address Self-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.
 End of changes. 22 change blocks. 
27 lines changed or deleted 28 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/