draft-ietf-mmusic-rtsp-nat-evaluation-00.txt   draft-ietf-mmusic-rtsp-nat-evaluation-01.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: December 31, 2007 June 29, 2007 Expires: January 12, 2009 July 11, 2008
The evaluation of different NAT traversal Techniques for media The evaluation of different NAT traversal Techniques for media
controlled by Real-time Streaming Protocol (RTSP) controlled by Real-time Streaming Protocol (RTSP)
draft-ietf-mmusic-rtsp-nat-evaluation-00 draft-ietf-mmusic-rtsp-nat-evaluation-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 31, 2007. This Internet-Draft will expire on January 12, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes several NAT traversal techniques that could This document describes several NAT traversal techniques that could
be used by RTSP. Each technique includes a description on how it be used by RTSP. Each technique includes a description on how it
would be used, the security implications of using it and any other would be used, the security implications of using it and any other
deployment considerations it has. There are also disussions on how deployment considerations it has. There are also disussions on how
NAT traversal techniques relates to firewalls and how each technique NAT traversal techniques relates to firewalls and how each technique
can be applied in different use cases. These findings where used can be applied in different use cases. These findings where used
when selecting the NAT traversal for RTSP solution to standardize in when selecting the NAT traversal for RTSP solution to standardize in
skipping to change at page 2, line 27 skipping to change at page 2, line 26
1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Detecting the loss of NAT mappings . . . . . . . . . . . . . . 7 2. Detecting the loss of NAT mappings . . . . . . . . . . . . . . 7
3. Requirements on NAT-Traversal . . . . . . . . . . . . . . . . 8 3. Requirements on NAT-Traversal . . . . . . . . . . . . . . . . 8
4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . . 9 4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . . 9
4.1. STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 10
4.1.2. Using STUN to traverse NAT without server 4.1.2. Using STUN to traverse NAT without server
modifications . . . . . . . . . . . . . . . . . . . . 10 modifications . . . . . . . . . . . . . . . . . . . . 10
4.1.3. Embedding STUN in RTSP . . . . . . . . . . . . . . . . 12 4.1.3. Embedding STUN in RTSP . . . . . . . . . . . . . . . . 12
4.1.4. Discussion On Co-located STUN Server . . . . . . . . . 13 4.1.4. Discussion On Co-located STUN Server . . . . . . . . . 13
4.1.5. ALG considerations . . . . . . . . . . . . . . . . . . 13 4.1.5. ALG considerations . . . . . . . . . . . . . . . . . . 14
4.1.6. Deployment Considerations . . . . . . . . . . . . . . 14 4.1.6. Deployment Considerations . . . . . . . . . . . . . . 14
4.1.7. Security Considerations . . . . . . . . . . . . . . . 16 4.1.7. Security Considerations . . . . . . . . . . . . . . . 16
4.2. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 17
4.2.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 17 4.2.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 17
4.2.3. Implementation burden of ICE . . . . . . . . . . . . . 19 4.2.3. Implementation burden of ICE . . . . . . . . . . . . . 19
4.2.4. Deployment Considerations . . . . . . . . . . . . . . 19 4.2.4. Deployment Considerations . . . . . . . . . . . . . . 20
4.2.5. Security Consideration . . . . . . . . . . . . . . . . 20 4.2.5. Security Consideration . . . . . . . . . . . . . . . . 20
4.3. Symmetric RTP . . . . . . . . . . . . . . . . . . . . . . 20 4.3. Symmetric RTP . . . . . . . . . . . . . . . . . . . . . . 20
4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 20 4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 20
4.3.2. Necessary RTSP extensions . . . . . . . . . . . . . . 21 4.3.2. Necessary RTSP extensions . . . . . . . . . . . . . . 21
4.3.3. Deployment Considerations . . . . . . . . . . . . . . 21 4.3.3. Deployment Considerations . . . . . . . . . . . . . . 21
4.3.4. Security Consideration . . . . . . . . . . . . . . . . 21 4.3.4. Security Consideration . . . . . . . . . . . . . . . . 22
4.3.5. A Variation to Symmetric RTP . . . . . . . . . . . . . 23 4.3.5. A Variation to Symmetric RTP . . . . . . . . . . . . . 23
4.4. Application Level Gateways . . . . . . . . . . . . . . . . 24 4.4. Application Level Gateways . . . . . . . . . . . . . . . . 25
4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 24 4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 25
4.4.2. Outline On how ALGs for RTSP work . . . . . . . . . . 25 4.4.2. Outline On how ALGs for RTSP work . . . . . . . . . . 25
4.4.3. Deployment Considerations . . . . . . . . . . . . . . 26 4.4.3. Deployment Considerations . . . . . . . . . . . . . . 26
4.4.4. Security Considerations . . . . . . . . . . . . . . . 26 4.4.4. Security Considerations . . . . . . . . . . . . . . . 27
4.5. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 26 4.5. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 27
4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . . 26 4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . . 27
4.5.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . . 27 4.5.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . . 27
4.5.3. Deployment Considerations . . . . . . . . . . . . . . 27 4.5.3. Deployment Considerations . . . . . . . . . . . . . . 28
4.5.4. Security Considerations . . . . . . . . . . . . . . . 27 4.5.4. Security Considerations . . . . . . . . . . . . . . . 28
4.6. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . . 28 4.6. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . . 28
4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 28 4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 28
4.6.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 28 4.6.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 29
4.6.3. Deployment Considerations . . . . . . . . . . . . . . 29 4.6.3. Deployment Considerations . . . . . . . . . . . . . . 30
4.6.4. Security Considerations . . . . . . . . . . . . . . . 30 4.6.4. Security Considerations . . . . . . . . . . . . . . . 30
5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6. Comparision of NAT traversal techniques . . . . . . . . . . . 31 6. Comparision of NAT traversal techniques . . . . . . . . . . . 32
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
10. Informative References . . . . . . . . . . . . . . . . . . . . 33 10. Informative References . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 37
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 follows standards[RFC3022][RFC2663][RFC3424]]. NATs cause loosely follows standards[RFC3022][RFC2663][RFC3424]]. NATs cause
discontinuity in address realms [RFC3424], therefore an application discontinuity in address realms [RFC3424], therefore an application
protocol, such as RTSP, needs to deal with such discontinuities protocol, such as RTSP, needs to deal with such discontinuities
caused by NATs. The problem is that, being a media control protocol caused by NATs. The problem is that, being a media control protocol
managing one or more media streams, RTSP carries network address and managing one or more media streams, RTSP carries network address and
port information within its protocol messages. Because of this, even port information within its protocol messages. Because of this, even
if RTSP itself, when carried over TCP for example, may not be blocked if RTSP itself, when carried over TCP for example, may not be blocked
by NATs, its media streams may be blocked by NATs. This will occur by NATs, its media streams may be blocked by NATs. This will occur
unless special protocol provisions are added to support NAT- unless special protocol provisions are added to support NAT-
traversal. traversal.
Like NATs, firewalls (FWs) are also middle boxes that need to be Like NATs, firewalls (FWs) are also middle boxes that need to be
considered. to prevent unwanted traffic from getting in or out of the considered. Firewalls helps prevent unwanted traffic from getting in
protected network. RTSP is designed such that a firewall can be or out of the protected network. RTSP is designed such that a
configured to let RTSP controlled media streams to go through with firewall can be configured to let RTSP controlled media streams to go
minimal implementation effort. The minimal effort is to implement an through with minimal implementation effort. The minimal effort is to
ALG (Application Level Gateway) to interpret RTSP parameters. There implement an ALG (Application Level Gateway) to interpret RTSP
is also a large class of firewalls, commonly home FWs, that uses a parameters. There is also a large class of firewalls, commonly home
similar filtering behavior to what NAT has. This type of firewalls FWs, that uses a similar filtering behavior to what NAT has. This
can be handled using the same solution as employed for NAT traversal type of firewalls can be handled using the same solution as employed
instead of relying on ALGs. for NAT traversal instead of relying on ALGs.
This document describes several NAT-traversal mechanisms for RTSP This document describes several NAT-traversal mechanisms for RTSP
controlled media streaming. These NAT solutions fall into the controlled media streaming. These NAT solutions fall into the
category of ""UNilateral Self-Address Fixing (UNSAF)" as defined in category of ""UNilateral Self-Address Fixing (UNSAF)" as defined in
[RFC3424] and quoted below: [RFC3424] and quoted below:
"UNSAF is a process whereby some originating process attempts to "UNSAF is a process whereby some originating process attempts to
determine or fix the address (and port) by which it is known - e.g. determine or fix the address (and port) by which it is known - e.g.
to be able to use address data in the protocol exchange, or to to be able to use address data in the protocol exchange, or to
advertise a public address from which it will receive connections." advertise a public address from which it will receive connections."
Following the guidelines spelled out in RFC 3424, we describe the Following the guidelines spelled out in RFC 3424, we describe the
required RTSP protocol extensions for each method, transition required RTSP protocol extensions for each method, transition
strategies, and security concerns. strategies, and security concerns.
This document is capturing the evaluation done in the process to This document is capturing the evaluation done in the process to
recommend FW/NAT traversal methods for RTSP streaming servers based recommend FW/NAT traversal methods for RTSP streaming servers based
on RFC 2326 [RFC2326] as well as the RTSP 2.0 core spec on RFC 2326 [RFC2326] as well as the RTSP 2.0 core spec
[I-D.ietf-mmusic-rfc2326bis]. [I-D.ietf-mmusic-rfc2326bis]. The evaluation is focused on NAT
traversal for the media streams carried over UDP [RFC0768]. Where
RTP [RFC3550] over UDP being the main case for such usage. The
findings should be applicable to other protocols as long as they have
similar properties.
1.1. Network Address Translators 1.1. Network Address Translators
Readers are urged to refer to [RFC2663] for information on NAT Readers are urged to refer to [RFC2663] for information on NAT
taxonomy and terminology. Traditional NAT is the most common type of taxonomy and terminology. Traditional NAT is the most common type of
NAT device deployed. Readers may refer to [RFC3022] for detailed NAT device deployed. Readers may refer to [RFC3022] for detailed
information on traditional NAT. Traditional NAT has two main information on traditional NAT. Traditional NAT has two main
varieties -- Basic NAT and Network Address/Port Translator (NAPT). varieties -- Basic NAT and Network Address/Port Translator (NAPT).
NAPT is by far the most commonly deployed NAT device. NAPT allows NAPT is by far the most commonly deployed NAT device. NAPT allows
skipping to change at page 13, line 15 skipping to change at page 13, line 15
If STUN server is co-located with RTSP server's media output port, an If STUN server is co-located with RTSP server's media output port, an
RTSP client using RTP transport over UDP can use STUN to traverse ALL RTSP client using RTP transport over UDP can use STUN to traverse ALL
types of NATs. In the case of port and address dependent mapping types of NATs. In the case of port and address dependent mapping
NATs, the party inside the NAT must initiate UDP traffic. The STUN NATs, the party inside the NAT must initiate UDP traffic. The STUN
Bind Request, being a UDP packet itself, can serve as the traffic Bind Request, being a UDP packet itself, can serve as the traffic
initiating packet. Subsequently, both the STUN Binding Response initiating packet. Subsequently, both the STUN Binding Response
packets and the RTP/RTCP packets can traverse the NAT, regardless of packets and the RTP/RTCP packets can traverse the NAT, regardless of
whether the RTSP server or the RTSP client is behind NAT. whether the RTSP server or the RTSP client is behind NAT.
Likewise, if an RTSP server is behind a NAT, then an embedded STUN Likewise, if an RTSP server is behind a NAT, then an embedded STUN
server must co-locate on the RTSP client's RTCP port. In this case, server must co-locate on the RTSP client's RTCP port. Also it will
we assume that the client has some means of establishing TCP become the client that needs to disclose his destination address
connection to the RTSP server behind NAT so as to exchange RTSP rather than the server so that the server correctly can determine its
messages with the RTSP server. NAT external source address for the media streams. In this case, we
assume that the client has some means of establishing TCP connection
to the RTSP server behind NAT so as to exchange RTSP messages with
the RTSP server.
To minimize delay, we require that the RTSP server supporting this To minimize delay, we require that the RTSP server supporting this
option must inform its client the RTP and RTCP ports from where the option must inform its client the RTP and RTCP ports from where the
server intend to send out RTP and RTCP packets, respectively. This server intend to send out RTP and RTCP packets, respectively. This
can be done by using the "server_port" parameter in RFC2326, and the can be done by using the "server_port" parameter in RFC2326, and the
"src_addr" parameter in [I-D.ietf-mmusic-rfc2326bis]. Both are in "src_addr" parameter in [I-D.ietf-mmusic-rfc2326bis]. Both are in
the RTSP Transport header. But in general this strategy will require the RTSP Transport header. But in general this strategy will require
that one first do one SETUP request per media to learn the server that one first do one SETUP request per media to learn the server
ports, then perform the STUN checks, followed by a subsequent SETUP ports, then perform the STUN checks, followed by a subsequent SETUP
to change the client port and destination address to what was learned to change the client port and destination address to what was learned
skipping to change at page 14, line 5 skipping to change at page 14, line 12
different, but may not work as well with other media transport different, but may not work as well with other media transport
protocols. protocols.
4.1.5. ALG considerations 4.1.5. ALG considerations
If a NAT supports RTSP ALG (Application Level Gateway) and is not If a NAT supports RTSP ALG (Application Level Gateway) and is not
aware of the STUN traversal option, service failure may happen, aware of the STUN traversal option, service failure may happen,
because a client discovers its public IP address and port numbers, because a client discovers its public IP address and port numbers,
and inserts them in its SETUP requests, when the RTSP ALG processes and inserts them in its SETUP requests, when the RTSP ALG processes
the SETUP request it may change the destination and port number, the SETUP request it may change the destination and port number,
resulting in unpredictable behavior. In such cases a convenient way resulting in unpredictable behavior. In such cases two alternatives
should be provided to turn off STUN-based NAT traversal. exist:
1. The usage of TLS to encrypt the RTSP TCP connection to prevent
the ALG from reading and modifying the RTSP messages.
2. To turn of the STUN based NAT traversal mechanism
As it may be difficult to determine why the failure occurs, the usage
of TLS protected RTSP message exchange at all times would avoid this
issue.
4.1.6. Deployment Considerations 4.1.6. Deployment Considerations
For the non-embedded usage of STUN the following applies: For the non-embedded usage of STUN the following applies:
Advantages: Advantages:
o Using STUN does not require RTSP server modifications; it only o Using STUN does not require RTSP server modifications; it only
affects the client implementation. affects the client implementation.
Disadvantages: Disadvantages:
o Requires a STUN server deployed in the public address space. o Requires a STUN server deployed in the public address space.
o Only works with endpoint independent and address dependent o Only works with NATs that perform endpoint independent and address
mapping. Port and address dependent filtering NATs create some dependent mappings. Port and address dependent filtering NATs
issues. create some issues.
o Does not work with port and address dependent mapping NATs without o Does not work with port and address dependent mapping NATs without
server modifications. server modifications.
o Will mostly not work if a NAT uses multiple IP addresses, since o Will mostly not work if a NAT uses multiple IP addresses, since
RTSP server generally requires all media streams to use the same RTSP server generally requires all media streams to use the same
IP as used in the RTSP connection. IP as used in the RTSP connection to prevent becoming a DDOS tool.
o Interaction problems exist when a RTSP-aware ALG interferes with o Interaction problems exist when a RTSP-aware ALG interferes with
the use of STUN for NAT traversal. the use of STUN for NAT traversal unless TLS secured RTSP message
exchange is used.
o Using STUN requires that RTSP servers and clients support the o Using STUN requires that RTSP servers and clients support the
updated RTSP specification, because it is no longer possible to updated RTSP specification, because it is no longer possible to
guarantee that RTP and RTCP ports are adjacent to each other, as guarantee that RTP and RTCP ports are adjacent to each other, as
required by the "client_port" and "server_port" parameters in required by the "client_port" and "server_port" parameters in
RFC2326. RFC2326.
Transition: Transition:
The usage of STUN can be phased out gradually as the first step of a The usage of STUN can be phased out gradually as the first step of a
skipping to change at page 15, line 44 skipping to change at page 16, line 12
means more processing is required to de-multiplex STUN packets means more processing is required to de-multiplex STUN packets
from media packets. For example, the de-multiplexer must be able from media packets. For example, the de-multiplexer must be able
to differentiate a RTCP RR packet from a STUN packet, and forward to differentiate a RTCP RR packet from a STUN packet, and forward
the former to the streaming server, the later to STUN server. the former to the streaming server, the later to STUN server.
o Even if the RTSP server is in the open, and the client is behind a o Even if the RTSP server is in the open, and the client is behind a
multi-addressed NAT, it may still break if the RTSP server does multi-addressed NAT, it may still break if the RTSP server does
not allow RTP packets to be sent to an IP differs from the IP of not allow RTP packets to be sent to an IP differs from the IP of
the client's RTSP request. the client's RTSP request.
o Interaction problems exist when a RTSP ALG is not aware of STUN. o Interaction problems exist when a RTSP ALG is not aware of STUN
unless TLS is used to protect the RTSP messages.
o Using STUN requires that RTSP servers and clients support the o Using STUN requires that RTSP servers and clients support the
updated RTSP specification, and they both agree to support the updated RTSP specification, and they both agree to support the NAT
proper feature tag. traversal feature.
o Increases the setup delay with at least the amount of time it o Increases the setup delay with at least the amount of time it
takes to perform STUN message exchanges. Most likely an extra takes to perform STUN message exchanges. Most likely an extra
SETUP sequence will be required. SETUP sequence will be required.
Transition: Transition:
The usage of STUN can be phased out gradually as the first step of a The usage of STUN can be phased out gradually as the first step of a
STUN capable machine can be to check the presence of NATs for the STUN capable machine can be to check the presence of NATs for the
presently used network connection. The removal of STUN capability in presently used network connection. The removal of STUN capability in
skipping to change at page 16, line 46 skipping to change at page 17, line 17
messages to change media destination. This protects against messages to change media destination. This protects against
hijacking, however as a client can be the initiator of an attack, hijacking, however as a client can be the initiator of an attack,
these mechanisms cannot securely prevent RTSP servers being used as these mechanisms cannot securely prevent RTSP servers being used as
DoS attack tools. DoS attack tools.
4.2. ICE 4.2. ICE
4.2.1. Introduction 4.2.1. Introduction
ICE (Interactive Connectivity Establishment) [I-D.ietf-mmusic-ice] is ICE (Interactive Connectivity Establishment) [I-D.ietf-mmusic-ice] is
a methodology for NAT traversal that is under development for SIP a methodology for NAT traversal that has been developed for SIP using
using SDP offer/answer. The basic idea is to try, in a parallel SDP offer/answer. The basic idea is to try, in a parallel fashion,
fashion, all possible connection addresses that an end point may all possible connection addresses that an end point may have. This
have. This allows the end-point to use the best available UDP allows the end-point to use the best available UDP "connection"
"connection" (meaning two UDP end-points capable of reaching each (meaning two UDP end-points capable of reaching each other). The
other). The methodology has very nice properties in that basically methodology has very nice properties in that basically all NAT
all NAT topologies are possible to traverse. topologies are possible to traverse.
Here is how ICE works on a high level. End point A collects all Here is how ICE works on a high level. End point A collects all
possible address that can be used, including local IP addresses, STUN possible address that can be used, including local IP addresses, STUN
derived addresses, TURN addresses, etc. On each local port that any derived addresses, TURN addresses, etc. On each local port that any
of these address and port pairs leads to, a STUN server is installed. of these address and port pairs leads to, a STUN server is installed.
This STUN server only accepts STUN requests using the correct This STUN server only accepts STUN requests using the correct
authentication through the use of username and password. authentication through the use of 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 to get the media point B, which includes all possible destinations to get the media
skipping to change at page 18, line 35 skipping to change at page 19, line 4
server primary address. server primary address.
5. The connectivity checks are performed. For the server the 5. The connectivity checks are performed. For the server the
connectivity checks from the server to the clients have an connectivity checks from the server to the clients have an
additional usage. They verify that there is someone willingly to additional usage. They verify that there is someone willingly to
receive the media, thus protecting itself from performing receive the media, thus protecting itself from performing
unknowingly an DoS attack. unknowingly an DoS attack.
6. Connectivity checks from the client's primary to the server's 6. Connectivity checks from the client's primary to the server's
primary was successful. Thus no further SETUP requests are primary was successful. Thus no further SETUP requests are
necessary and processing can proceed with step 7. If the checks necessary and processing can proceed with step 7. If another
for the primary failed and If further candidates have been address than the primary has been verified by the client to work,
derived during the connectivity checks, then those can be that address may then be promoted for usage in a SETUP request
promoted in new candidate lines in SETUP request updating the (Goto 7). If the checks for the availble candidates failed and
list (Goto 5). If another address than the primary has been If further candidates have been derived during the connectivity
verified by the client to work, that address may then be promoted checks, then those can be promoted in new candidate lines in
for usage in a SETUP request (Goto 7). SETUP request updating the list (Goto 5).
7. Client issues PLAY request. If the server also has completed its 7. Client issues PLAY request. If the server also has completed its
connectivity checks for this primary addresses (based on username connectivity checks for this primary addresses (based on username
as it may be derived addresses if the client was behind NAT) then as it may be derived addresses if the client was behind NAT) then
it can directly answer 200 OK (Goto 8). If the connectivity it can directly answer 200 OK (Goto 8). If the connectivity
check has not yet completed it responds with a 1xx code to check has not yet completed it responds with a 1xx code to
indicate that it is verifying the connectivity. If that fails indicate that it is verifying the connectivity. If that fails
within the set timeout an error is reported back. Client needs within the set timeout an error is reported back. Client needs
to go back to 6. to go back to 6.
skipping to change at page 20, line 5 skipping to change at page 20, line 20
o Solves NAT connectivity discovery for basically all cases as long o Solves NAT connectivity discovery for basically all cases as long
as a TCP connection between them can be established. This as a TCP connection between them can be established. This
includes servers behind NATs. (Note that a proxy between address includes servers behind NATs. (Note that a proxy between address
domains may be required to get TCP through). domains may be required to get TCP through).
o Improves defenses against DDOS attacks, as media receiving client o Improves defenses against DDOS attacks, as media receiving client
requires authentications, via STUN on its media reception ports. requires authentications, via STUN on its media reception ports.
Disadvantages: Disadvantages:
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.
Assumes that it is possible to de-multiplex between media packets o Assumes that it is possible to de-multiplex between media packets
and STUN packets. and STUN packets.
Has fairly high implementation burden put on both RTSP server and o Has fairly high implementation burden put on both RTSP server and
client. The precise implantation complexity needs to be assessed client.
once ICE is fully defined as a standard. Currently ICE is still a
protocol under development.
4.2.5. Security Consideration 4.2.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 is contains some potential issues. However to understand that ICE is contains some potential issues. However
these can be avoided by a correctly utilizing ICE in RTSP. In fact these can be avoided by a correctly utilizing ICE in RTSP. In fact
ICE do help avoid the DDoS issue with RTSP substantially as it ICE do help avoid the DDoS issue with RTSP substantially as it
reduces the possibility for a DDoS using RTSP servers to attackers reduces the possibility for a DDoS using RTSP servers to attackers
that are on-path between the RTSP server and the target and capable that are on-path between the RTSP server and the target and capable
of intercepting the STUN connectivity check packets and correctly of intercepting the STUN connectivity check packets and correctly
skipping to change at page 23, line 16 skipping to change at page 23, line 28
could be increased. To achieve a longer random tag while still using could be increased. To achieve a longer random tag while still using
RTP and RTCP, it will be necessary to develop RTP and RTCP payload RTP and RTCP, it will be necessary to develop RTP and RTCP payload
formats for carrying the random tag. formats for carrying the random tag.
4.3.5. A Variation to Symmetric RTP 4.3.5. A Variation to Symmetric RTP
Symmetric RTP requires a valid RTP format in the FW packet, which is Symmetric RTP requires a valid RTP format in the FW packet, which is
the first packet that the client sends to the server to set up the first packet that the client sends to the server to set up
virtual RTP connection. There is currently no appropriate RTP packet virtual RTP connection. There is currently no appropriate RTP packet
format for this purpose, although the No-Op format is a proposal to format for this purpose, although the No-Op format is a proposal to
fix the problem [I-D.ietf-avt-rtp-no-op]. fix the problem [I-D.ietf-avt-rtp-no-op]. There exist a document
that discusses the implication of different type of packets as keep-
alives for RTP [I-D.ietf-avt-app-rtp-keepalive] and its findings are
very relevant to the FW packet.
Meanwhile, there has been FW traversal techniques deployed in the Meanwhile, there has been FW traversal techniques deployed in the
wireless streaming market place that use non-RTP messages as FW wireless streaming market place that use non-RTP messages as FW
packets. This section attempts to summarize a subset of those packets. This section attempts to summarize a subset of those
solutions that happens to use a variation to the standard symmetric solutions that happens to use a variation to the standard symmetric
RTP solution. RTP solution.
In this variation of symmetric RTP, the FW packet is a small UDP In this variation of symmetric RTP, the FW packet is a small UDP
packet that does not contain RTP header. Hence the solution can no packet that does not contain RTP header. Hence the solution can no
longer be called symmetric RTP, yet it employs the same technique for longer be called symmetric RTP, yet it employs the same technique for
skipping to change at page 23, line 47 skipping to change at page 24, line 14
client's SSRC, and record the NAT bindings accordingly. The server client's SSRC, and record the NAT bindings accordingly. The server
then sends a FW packet as the response to the client. then sends a FW packet as the response to the client.
The FW packet can contain the SSRC to identify the RTP stream, and The FW packet can contain the SSRC to identify the RTP stream, and
can be made no bigger than 12 bytes, making it distinctively can be made no bigger than 12 bytes, making it distinctively
different from RTP packets, whose header size is 12 bytes. different from RTP packets, whose header size is 12 bytes.
RTSP signaling can be added to do the following: RTSP signaling can be added to do the following:
1. Enables or disables such FW message exchanges. When the FW/NAT 1. Enables or disables such FW message exchanges. When the FW/NAT
has an RTSP-aware ALG, it is better to disable FW message has an RTSP-aware ALG, it is possible to disable FW message
exchange and let ALG works out the address and port mappings. exchange and let ALG works out the address and port mappings.
2. Configures the number of re-tries and the re-try interval of the 2. Configures the number of re-tries and the re-try interval of the
FW message exchanges. FW message exchanges.
Such FW packets may also contain digital signatures to support three- Such FW packets may also contain digital signatures to support three-
way handshake based receiver authentications, so as to prevent DDoS way handshake based receiver authentications, so as to prevent DDoS
attacks described before. attacks described before.
This approach has the following advantages when compared with the This approach has the following advantages when compared with the
skipping to change at page 24, line 36 skipping to change at page 24, line 51
1. RTP traffic is normally accompanied by RTCP traffic. This 1. RTP traffic is normally accompanied by RTCP traffic. This
approach needs to rely on RTCP RRs and SRs to enable NAT approach needs to rely on RTCP RRs and SRs to enable NAT
traversal for RTCP endpoints, or use the same type of FW messages traversal for RTCP endpoints, or use the same type of FW messages
also for RTCP endpoints. also for RTCP endpoints.
2. The server's sender SSRC for the RTP stream must be signaled in 2. The server's sender SSRC for the RTP stream must be signaled in
RTSP's SETUP response, in the Transport header of the RTSP SETUP RTSP's SETUP response, in the Transport header of the RTSP SETUP
response. response.
A solution with a 3-way handshaking and its own FW packets can be
compared with ICE and have the following differencies:
o Only works for servers with public IP addresses compared to any
type of server
o Is somewhat simpler to implement due to the avoidance of the ICE
prioritization and checkboard mechanisms.
However, a 3-way binding protocol is very similar to using STUN in
both directions as binding protocol. Using STUN would remove the
need for implementing a new protocol.
4.4. Application Level Gateways 4.4. Application Level Gateways
4.4.1. Introduction 4.4.1. Introduction
An Application Level Gateway (ALG) reads the application level An Application Level Gateway (ALG) reads the application level
messages and performs necessary changes to allow the protocol to work messages and performs necessary changes to allow the protocol to work
through the middle box. However this behavior has some problems in through the middle box. However this behavior has some problems in
regards to RTSP: regards to RTSP:
1. It does not work when the RTSP protocol is used with end-to-end 1. It does not work when the RTSP protocol is used with end-to-end
skipping to change at page 27, line 6 skipping to change at page 27, line 36
4.5. TCP Tunneling 4.5. TCP Tunneling
4.5.1. Introduction 4.5.1. Introduction
Using a TCP connection that is established from the client to the Using a TCP connection that is established from the client to the
server ensures that the server can send data to the client. The server ensures that the server can send data to the client. The
connection opened from the private domain ensures that the server can connection opened from the private domain ensures that the server can
send data back to the client. To send data originally intended to be send data back to the client. To send data originally intended to be
transported over UDP requires the TCP connection to support some type transported over UDP requires the TCP connection to support some type
of framing of the RTP packets. Using TCP also results in that the of framing of the media data packets. Using TCP also results in that
client has to accept that real-time performance may no longer be the client has to accept that real-time performance may no longer be
possible. TCP's problem of ensuring timely deliver was the reasons possible. TCP's problem of ensuring timely deliver was the reasons
why RTP was developed. Problems that arise with TCP are: head-of- why RTP was developed. Problems that arise with TCP are: head-of-
line blocking, delay introduced by retransmissions, highly varying line blocking, delay introduced by retransmissions, highly varying
congestion control. rate due to the congestion control algorithm.
4.5.2. Usage of TCP tunneling in RTSP 4.5.2. Usage of TCP tunneling in RTSP
The RTSP core specification [I-D.ietf-mmusic-rfc2326bis] supports The RTSP core specification [I-D.ietf-mmusic-rfc2326bis] supports
interleaving of media data on the TCP connection that carries RTSP interleaving of media data on the TCP connection that carries RTSP
signaling. See section 10.13 in [I-D.ietf-mmusic-rfc2326bis] for how signaling. See section 14 in [I-D.ietf-mmusic-rfc2326bis] for how to
to perform this type of TCP tunneling. There is currently new perform this type of TCP tunneling. There also exist another way of
finished work on one more way of transporting RTP over TCP in AVT and transporting RTP over TCP defined in Appendix . For signaling and
MMUSIC. For signaling and rules on how to establish the TCP rules on how to establish the TCP connection in lieu of UDP, see
connection in lieu of UDP, see [RFC4091]. Another draft describes appendix C.2 in [I-D.ietf-mmusic-rfc2326bis]. This is based on the
how to frame RTP over the TCP connection is described in RFC 4571 framing of RTP over the TCP connection as described in RFC 4571
[RFC4571]. [RFC4571].
4.5.3. Deployment Considerations 4.5.3. Deployment Considerations
Advantage: Advantage:
o Works through all types of NATs where server is in the open. o Works through all types of NATs where server is in the open.
Disadvantage: Disadvantage:
skipping to change at page 32, line 26 skipping to change at page 33, line 15
| R1 | R2 | R3 | R4 | R5 | | R1 | R2 | R3 | R4 | R5 |
------------+------+------+------+------+------+ ------------+------+------+------+------+------+
STU | Yes | Yes | No | Maybe| No | STU | Yes | Yes | No | Maybe| No |
------------+------+------+------+------+------+ ------------+------+------+------+------+------+
ICE | Yes | Yes | No | No | Yes | ICE | Yes | Yes | No | No | Yes |
------------+------+------+------+------+------+ ------------+------+------+------+------+------+
SymRTP | Yes | Yes | Yes |Maybe | No | SymRTP | Yes | Yes | Yes |Maybe | No |
------------+------+------+------+------+------+ ------------+------+------+------+------+------+
V. SymRTP | Yes | Yes | Yes | Yes |future| V. SymRTP | Yes | Yes | Yes | Yes |future|
------------+------+------+------+------+------+ ------------+------+------+------+------+------+
3-W SymRTP | Yes | Yes | Yes | Maybe| Yes |
------------+------+------+------+------+------+
TURN | Yes | Yes | No | No | Yes | TURN | Yes | Yes | No | No | Yes |
------------------------------------------------ ------------------------------------------------
The different techniques was discussed in the MMUSIC WG. It was
established that the WG would pursue an ICE based solution due to its
generality and capability of handle also servers delivering media
from behind NATs. There has been some discussion if the increased
implementation burden of ICE is motivated compared to a 3-W SymRTP
solution for this generality.
7. IANA Considerations 7. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
8. Security Considerations 8. Security Considerations
In preceding sessions we have discussed security merits of each and In preceding sessions we have discussed security merits of each and
every NAT/FW traversal methods for RTSP. In summary, the presence of every NAT/FW traversal methods for RTSP discussed here. In summary,
NAT(s) is a security risk, as a client cannot perform source the presence of NAT(s) is a security risk, as a client cannot perform
authentication of its IP address. This prevents the deployment of source authentication of its IP address. This prevents the
any future RTSP extensions providing security against hijacking of deployment of any future RTSP extensions providing security against
sessions by a man-in-the-middle. hijacking of sessions by a man-in-the-middle.
Each of the proposed solutions has security implications. Using STUN Each of the proposed solutions has security implications. Using STUN
will provide the same level of security as RTSP with out transport will provide the same level of security as RTSP with out transport
level security and source authentications; as long as the server does level security and source authentications; as long as the server does
not grant a client request to send media to different IP addresses. not grant a client request to send media to different IP addresses.
Using symmetric RTP will have a higher risk of session hijacking or Using symmetric RTP will have a higher risk of session hijacking or
denial of service than normal RTSP. The reason is that there exists denial of service than normal RTSP. The reason is that there exists
a probability that an attacker is able to guess the random tag that a probability that an attacker is able to guess the random tag that
the client uses to prove its identity when creating the address the client uses to prove its identity when creating the address
bindings. This can be solved in the variation of symmetric RTP bindings. This can be solved in the variation of symmetric RTP
skipping to change at page 33, line 34 skipping to change at page 34, line 32
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, and Colin Perkins. Thomas Zeng would also
like to give special thanks to Greg Sherwood of PacketVideo for his like to give special thanks to Greg Sherwood of PacketVideo for his
input into this memo. input into this memo.
Section Section 1.1 contains text originally written for RFC 4787 by Section Section 1.1 contains text originally written for RFC 4787 by
Francois Audet and Cullen Jennings. Francois Audet and Cullen Jennings.
10. Informative References 10. Informative References
[I-D.ietf-avt-app-rtp-keepalive]
Marjou, X. and A. Sollaud, "Application Mechanism for
maintaining alive the Network Address Translator (NAT)
mappings associated to RTP flows.",
draft-ietf-avt-app-rtp-keepalive-03 (work in progress),
April 2008.
[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-ietf-avt-rtp-no-op-04 (work in progress), May 2007. draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007.
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., "Session Traversal Utilities for (NAT) Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
(STUN)", draft-ietf-behave-rfc3489bis-06 (work in "Session Traversal Utilities for (NAT) (STUN)",
progress), March 2007. draft-ietf-behave-rfc3489bis-16 (work in progress),
July 2008.
[I-D.ietf-behave-turn] [I-D.ietf-behave-turn]
Rosenberg, J., "Obtaining Relay Addresses from Simple Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Traversal Underneath NAT (STUN)", Relays around NAT (TURN): Relay Extensions to Session
draft-ietf-behave-turn-03 (work in progress), March 2007. Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-08 (work in progress), June 2008.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment 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", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-16 (work in progress), June 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-mmusic-rfc2326bis] [I-D.ietf-mmusic-rfc2326bis]
Schulzrinne, H., "Real Time Streaming Protocol 2.0 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
(RTSP)", draft-ietf-mmusic-rfc2326bis-15 (work in and M. Stiemerling, "Real Time Streaming Protocol 2.0
progress), June 2007. (RTSP)", draft-ietf-mmusic-rfc2326bis-18 (work in
progress), May 2008.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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 1999. May 1999.
skipping to change at page 34, line 51 skipping to change at page 36, line 14
[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.
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network
Address Types (ANAT) Semantics for the Session Description
Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets over Connection- and RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", RFC 4571, July 2006. Oriented Transport", RFC 4571, July 2006.
[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.
skipping to change at page 36, line 7 skipping to change at page 37, line 7
Thomas Zeng Thomas Zeng
Phone: Phone:
Fax: Fax:
Email: thomas.zeng@gmail.com Email: thomas.zeng@gmail.com
URI: URI:
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 36, line 44 skipping to change at line 1700
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 44 change blocks. 
103 lines changed or deleted 149 lines changed or added

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