Network Working Group Magnus Westerlund
INTERNET-DRAFT Ericsson
Category: Standards Track February 21, 2003
Expires: August 2003
How to make Real-Time Streaming Protocol (RTSP) traverse Network
Address Translators (NAT) and interact with Firewalls.
<draft-ietf-mmusic-rtsp-nat-00.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes four different types of NAT traversal
techniques that can be used by RTSP. For each technique a description
on how it shall be used, what security implications it has and other
deployment considerations that exist is given. Further a description
on how RTSP relates to firewalls are also given.
Westerlund [Page 1]
INTERNET-DRAFT How to make RTSP traverse NAT & FW Feb. 21, 2003
TABLE OF CONTENTS
1. Definitions.........................................................3
1.1. Glossary.......................................................3
1.2. Terminology....................................................3
2. Introduction........................................................3
2.1. NATs...........................................................4
2.2. Firewalls......................................................5
3. NAT Traversal Techniques............................................5
3.1. STUN...........................................................5
3.1.1. Introduction..............................................5
3.1.2. Usage with RTSP...........................................5
3.1.3. Deployment Considerations.................................7
3.1.4. Security Considerations...................................7
3.2. Symmetric RTP..................................................8
3.2.1. Introduction..............................................8
3.2.2. Necessary RTSP extensions.................................8
3.2.3. Using Symmetric RTP in RTSP...............................9
3.2.4. Open Issues..............................................10
3.2.5. Deployment Considerations................................10
3.2.6. Security Consideration...................................11
3.3. Application Level Gateways....................................12
3.3.1. Introduction.............................................12
3.3.2. Using ALG for RTSP.......................................12
3.3.3. Deployment Considerations................................13
3.3.4. Security Considerations..................................13
3.4. TCP Tunneling.................................................13
3.4.1. Introduction.............................................13
3.4.2. Usage of TCP tunneling in RTSP...........................14
3.4.3. Deployment Considerations................................14
3.4.4. Security Considerations..................................14
4. Firewalls..........................................................14
5. Security Consideration.............................................15
6. IANA Consideration.................................................15
7. Acknowledgments....................................................15
8. Author's Addresses.................................................16
9. References.........................................................16
9.1. Normative references..........................................16
9.2. Informative References........................................16
10. IPR Notice........................................................17
11. Copyright Notice..................................................18
Westerlund Standards Track [Page 2]
INTERNET-DRAFT How to make RTSP traverse NAT & FW Feb. 21, 2003
1. Definitions
1.1. Glossary
NAT - Network Address Translator, see [8].
NAT-PT - Network Address Translator Protocol Translator, see [9]
RTSP - Real-Time Streaming Protocol, see [1] and [7].
SDP - Session Description Protocol, see [2].
1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
[Authors Note: This document reference a number of RTSP transport
header parameters that will not be part of the next RTSP draft
version. These parameter are "client_rtcp_port", "server_rtcp_port",
and will instead be replace with a more general mechanism. However as
this is not available in a published draft this will reference the
mechanism present in draft version 02 of [7]. ]
2. Introduction
Today there is unfortunately Network Address Translators (NAT) [8]
everywhere and a protocol needs to try to make sure that it can work
through them in some fashion. The problem with RTSP is that it
carries information about network addresses and ports inside itself.
It is primarily the media streams that are being blocked by NAT.
Firewalls are also middle boxes that needs to be considered. They are
deployed to prevent non-desired traffic/protocols to be used or reach
the protected network. RTSP is designed to allow a firewall to let
RTSP controlled streams through, if chosen to, with minimal
implementation problems. However there is need for more detailed
information on how a firewall may be configured to allow RTSP to be
used through it.
This document explains how some NAT traversal mechanism can be used
with RTSP. The necessary RTSP protocol extensions are defined. What
security problems arise from the different mechanisms is also
explained.
This document is not based on the so proposed standard RTSP of RFC
2326 [1]. It is instead based and depending on the updated RTSP
specification [7], which is under development in the MMUSIC WG. The
updated specification is a much-needed attempt to correct a number of
shortcomings of RFC 2326. One important change is that the
specification is split into several parts. So far only the updated
core specification of RTSP is available in [7]. This document is one
extension document to this core spec documenting a special
Westerlund Standards Track [Page 3]
INTERNET-DRAFT How to make RTSP traverse NAT & FW Feb. 21, 2003
functionality that extends the RTSP protocol. It is intended to
maintain and update this document to be consistent with the core
protocol.
2.1. NATs
Today there exist a number of different NAT types and usage areas.
The different NAT types, cited from STUN [31]:
Full Cone: A full cone NAT is one where all requests from the same
internal IP address and port are mapped to the same external IP
address and port. Furthermore, any external host can send a packet to
the internal host, by sending a packet to the mapped external
address.
Restricted Cone: A restricted cone NAT is one where all requests from
the same internal IP address and port are mapped to the same external
IP address and port. Unlike a full cone NAT, an external host (with
IP address X) can send a packet to the internal host only if the
internal host had previously sent a packet to IP address X.
Port Restricted Cone: A port restricted cone NAT is like a restricted
cone NAT, but the restriction includes port numbers. Specifically, an
external host can send a packet, with source IP address X and source
port P, to the internal host only if the internal host had previously
sent a packet to IP address X and port P.
Symmetric: A symmetric NAT is one where all requests from the same
internal IP address and port, to a specific destination IP address
and port, are mapped to the same external IP address and port. If the
same host sends a packet with the same source address and port, but
to a different destination, a different mapping is used. Furthermore,
only the external host that receives a packet can send a UDP packet
back to the internal host.
NAT's are used on both small and large scale. The normal small-scale
user is home user that has a NAT to allow multiple computers share
the single IP address given by their Internet Service Provider (ISP).
The large scale users are the ISP's themselves that gives there users
private addresses. This is done both for control and lack of
addresses.
Native Address Translation and Protocol Translation (NAT-PT) [9] is
mechanism used for IPv4 to IPv6 transition. This device is used to
allow devices only having connectivity using one of the IP versions
to communicate with the other address domain. The other address
domain is addressable through the use of domain names. Then a DNS ALG
assigns temporary IP addresses in the requestor's domain. The NAT-PT
device translates this temporary address to the receivers true IP
address and at the same time modify all necessary fields to be
correct in the receiver's address domain.
Westerlund Standards Track [Page 4]
INTERNET-DRAFT How to make RTSP traverse NAT & FW Feb. 21, 2003
2.2. Firewalls
[TBW]
3. NAT Traversal Techniques
There exist a number of NAT traversal techniques that can be to allow
RTSP to function through the NAT. However they have different
applicability and trade offs. There are also differing in there
security considerations. Each techniques chapter will outline the
advantage and disadvantage of using it.
3.1. STUN
3.1.1. Introduction
The STUN protocol [6] allows a client to discover the type of NAT(s)
he is behind and also discover a mappings public address and port
number. The protocol also allows discovery of the mappings timeout
period and can be used as keep alive mechanism.
How useful this protocol is depends on the type of NAT(s) the client
is behind. If the user is behind a full cone NAT, STUN allows the
RTSP client to traverse the NAT with some simple client side
adaptations. For restricted cone NATs STUN is still useful but
require some more adaptations. For symmetric NATs STUN requires such
severe server adaptations that it is not practical to use.
3.1.2. Usage with RTSP
A RTSP client using RTP transport over UDP can use STUN to traverse a
full cone NAT in the following way:
1. Use STUN to discover the type of NAT, if any, and the timeout
period for any UDP mapping on the NAT. This is RECOMMENDED to be
performed in the background as soon as IP connectivity is
established. If this is performed prior to the attempt to
establish a streaming session the possible delays in the session
establishment will be reduced. If no NAT is present, use the
normal SETUP behavior.
2. The RTSP client determines the number of UDP ports needed by
counting the number of RTP sessions part of the multi-media
presentation. This information is available in the media
description protocol used, e.g. SDP. In general each RTP session
will require two UDP ports, one for RTP, and one for RTCP. Ensure
that the same public IP address is used for each RTP/RTCP port
pair established.
Westerlund Standards Track [Page 5]
INTERNET-DRAFT How to make RTSP traverse NAT & FW Feb. 21, 2003
3. For each UDP port required, establish a mapping and discover the
public IP address and port number with use of STUN. If successful
this results in that the client now knows for each port know the
mapping: clients local address/port <-> public address/port.
4. Perform the RTSP SETUP for each media. In the transport header the
following parameters SHOULD be included with the given values:
"destination" with the public IP address, "client_port" with the
public port of the mapping determined to be used for RTP,
"client_rtcp_port" with the port number of the mapping to be used
for RTCP. The parameter "client_rtcp_port" needs to be used unless
the client has managed to establish a mapping with two consecutive
numbers starting with an even one. To allow this to work servers
MUST allow a client to setup the RTP stream on any port, not only
even ports. The server SHALL respond with a transport header
containing the source IP address of the media streams.
5. To keep the mappings alive the client SHOULD periodically send UDP
traffic over all mappings needed for the session. STUN can be used
to determine the timeout period of the NAT(s) UDP mappings. For
the mapping carrying RTCP traffic the periodic RTCP traffic may be
sent frequently enough. If not or for RTP carrying mappings, empty
IP/UDP messages SHOULD be sent to the streaming servers discard
port (port number 9).
If a UDP mapping is lost above process is required to be performed
again and the media stream needs to be SETUP again changing the
transport parameters to the new ones.
To allow the UDP packets to arrive from the server to a client behind
a restricted NAT, any UDP messages must be sent to the server.
Therefore SHOULD the client, before sending a RTSP PLAY request send
an empty UDP message, on each mapping, to the IP address given as the
servers source address and its discard port (port number 9).
Otherwise no difference in procedure compared with a full cone NAT is
needed.
For a port restricted NAT the client must send messages to the exact
ports used by the server to send messages. This makes it possible to
use the above described process with the following additions: For
each port mapping, a UDP message needs to be sent to the servers
source address/port. To minimize potential effects on the server from
these messages the following type of messages MUST be sent. RTP: An
empty UDP message with out any payload. RTCP: A correctly formed RTCP
message. Unless enough bandwidth is assigned to RTCP it might not be
possible to keep the UDP mapping open. These messages SHOULD be sent
before sending a PLAY request and then periodically. As the messages
are unreliable there is no possibility to guarantee that mappings are
kept open. However to achieve good probability and at the same time
don't send unnecessary traffic it is RECOMMENDED that the client
Westerlund Standards Track [Page 6]
INTERNET-DRAFT How to make RTSP traverse NAT & FW Feb. 21, 2003
sends the message with a period that is equal to the bindings timeout
divided by 10.
To be able to use STUN to traverse symmetric NATs the STUN server
needs to be co-located with the streaming server media distribution
ports. This creates an unclear demultiplexing point within the
server. As this will create implementations difficulties and possibly
security problems this SHOULD NOT be done.
If a NAT supports RTSP ALG and are not aware of the STUN traversal
option this may cause service failure. The problem arises it the STUN
using client inserts the public address and port number into a SETUP
request. When the RTSP ALG processes the SETUP request it may change
the destination and port number if it does not detect the fact that
the destination is one of the NAT's public addresses. If the NAT
creates mappings assuming that the client uses its local address and
ports in the request this will create unpredictable results.
3.1.3. Deployment Considerations
Advantages:
- Does not require RTSP server modifications, totally client
implemented tool.
Disadvantages:
- Requires a STUN server deployed in the public address space.
- Does only work well behind Cone NATs. Does not normally work with
Symmetric NATs.
- Will mostly not work from behind NATs using multiple IP addresses,
as it requires all streams to have the same IP, see below.
- Interaction problems when a RTSP ALG is not aware of STUN.
- Requires RTSP servers supporting the updated specification.
3.1.4. Security Considerations
To prevent RTSP server being Denial of Service (DoS) attack tools the
RTSP Transport header parameter "Destination" is not allowed to point
at other IP addresses then the one the RTSP message transport
originates from. The server is only allowed to do exception from this
when the client is trusted through a secure authentication process
with secure transport of RTSP message or a secure method of
challenging the destination that verify its acceptance of the traffic
is used. The restriction result in that STUN does not work for NATs
that would assign different IP addresses to different UDP flows on
its public side. Which results in that most multi-address NATs will
not work.
STUN used with destination address restrictions in place has the same
security properties as core RTSP. It cannot be used as a DoS attack
tool unless the attacker has possibility to intercept or reroute the
Westerlund Standards Track [Page 7]
INTERNET-DRAFT How to make RTSP traverse NAT & FW Feb. 21, 2003
RTSP control traffic going from the server towards the intended
target IP.
3.2. Symmetric RTP
3.2.1. Introduction
Symmetric RTP is a NAT traversal solution that is based on that NATed
client sends packets to the server address to the servers send ports.
When the server receives the packet, it copies the source IP and Port
number and uses them as delivery address for servers packets. By
having the server send media traffic back the same way as the
client's packet are sent to the server they will use the opened
mappings. Therefore this technique also works for symmetric NATs.
It has the advantage of working for all types of NATs. However it
requires server modifications. Symmetric RTP is somewhat more
vulnerable to hijacking attacks, which will be explained in more
details below.
3.2.2. Necessary RTSP extensions
To support symmetric RTP the RTSP signaling must be extended to allow
the client to indicate that it will use symmetric RTP. The client
also needs to be able to signal its RTP SSRC to the server. The RTP
SSRC is used to establish a basic security level against hijacking
attacks.
A RTP specific Transport header parameter is defined to indicate that
symmetric RTP shall be used for the media transport. The parameter is
included in each Transport header specification where the client will
use symmetric RTP. A Server SHALL NOT accept the transport
specification unless it supports symmetric RTP. If the client has
requested to use symmetric RTP for a session the server MUST include
the parameter in the response.
The parameter is defined in ABNF [3] as:
symm-usage = "sym_rtp" "=" "1"
Which follows the definition in [7] for transport parameter
extensions.
Further a RTSP options tag that can be used to indicate support of
symmetric RTP according to this specification is defined.
nat.sym-rtp
This tag SHALL be included in the supported header by both clients
and server supporting symmetric RTP according to this specification.
Westerlund Standards Track [Page 8]
INTERNET-DRAFT How to make RTSP traverse NAT & FW Feb. 21, 2003
3.2.3. Using Symmetric RTP in RTSP
The server and client uses Symmetric RTP in the following way:
1. The client knows or has determined by the use of STUN that it is
located behind a NAT. It may also determined the type of NAT it
is behind.
2. The client MAY investigate if the server supports symmetric RTP
by including the supported header with the tag "nat.sym-rtp" in
an OPTIONS or DESCRIBE request to the server. A server supporting
symmetric RTP will include the tag in its response.
3. The client determines that it will use symmetric RTP to traverse
the NAT. This decision is based on knowledge about the NAT type
and necessary support from the server.
4. The client sends a SETUP request to the server where all
transport specs using RTP/UDP for which the client desires to use
symmetric RTP for includes the parameter "sym_rtp=1". It MUST
also include the parameter "client_ssrc" in each transport
specification containing "sym_rtp=1". The "client_ssrc" contains
the random SSRC it is going to use for that RTP session. The SSRC
MUST be assigned in a random way as the randomness of the SSRC is
the basic security mechanism that prevents hijacking. Symmetric
RTP MUST only be requested for unicast transport.
5. The server chose the transport specification that it will use to
transport the media and send it response. When this transport
specification is one declaring the use of symmetric RTP the
server performs the following:
- The server MUST include the transport parameters "sym_rtp=1",
"source", and "server_port" in the response.
- The server MUST both send and receive data on the indicated
ports. Otherwise the NAT traversal will not work if the NAT is a
symmetric or port restricted one.
- The server ignores any of the transport header parameters
"destination", client_port, and client_rtcp_port.
6. The Server starts listening on the declared server ports after an
RTP/UDP packet containing the SSRC the client has declared it
will use. Any received RTP/UDP packet not containing the SSRC
that the client has declared MUST be ignored. When the server
receives a RTP/UDP packet containing the matching SSRC the server
stores the source IP and Port as being the destination address
and port for that media. It performs the corresponding actions
for the RTCP port to establish the destination of the RTCP
transmissions.
7. The client establishes the address binding at the server by
sending RTP or RTCP to the servers declared media address and
Westerlund Standards Track [Page 9]
INTERNET-DRAFT How to make RTSP traverse NAT & FW Feb. 21, 2003
port from the port it desires to receive RTP/RTCP on. For the RTP
channel it sends a RTP/UDP message containing the SSRC that it
declared to the server that it would use. The RTP/UDP packet
SHALL NOT contain any payload data and use payload type 0. To the
servers RTCP port it sends a normal RTCP packet.
8. Upon reception of a packet creating the binding the server SHALL
respond. On the RTP port it SHALL respond with a single RTP/UDP
packet using payload type 0 and having a 0 byte payload. For each
received client packet that contains the correct SSRC the server
SHALL respond with a single packet. For RTCP it starts
transmitting RTCP packets according to the rules.
9. To prevent that the clients binding packets are not lost the
client SHOULD retransmit the binding RTP packet every 250 ms
until it receives a response with an empty RTP packet or it has
retransmitted 20 times. For RTCP it is enough to transmit RTCP
packet according to the normal rules. However a client MAY send
one RTCP packet every 500 ms until it receives an answer, or it
has tried for 10 seconds.
10. When the client has received answers for both RTP and RTCP it can
safely progress the session and send a PLAY request.
11. To ensure that the binding is not lost the client SHOULD send a
empty RTP/UDP packet with PT=0 to the server every tenth of the
mapping timeout time that has been discovered for the NAT. The
discovery can be performed by using STUN. The client SHOULD not
send these packets as long as the server transmit RTP packets to
the client. Unless the NAT mappings has very short timeouts or
the RTCP bandwidth is severely restricted the RTCP traffic should
automatically keep its connection open.
3.2.4. Open Issues
The proposal for symmetric RTP contains some open issues that needs
to be addressed.
What RTP payload type(s) shall the client use. Should it use one of
the types that the server has declared is going to use in the server
-> client direction or a static one?
Should the security be improved by having a RTP challenge that can
contain longer random identifiers? If that is the case it should have
a static payload type as the client can't establish dynamic payload
type declarations.
3.2.5. Deployment Considerations
Advantages:
Westerlund Standards Track [Page 10]
INTERNET-DRAFT How to make RTSP traverse NAT & FW Feb. 21, 2003
- Works for all types of NATs, including those using multiple IP
addresses.
- Have no interaction problems with any RTSP ALG changing the
client's information in the transport header.
Disadvantages:
- Requires Server support.
- Has somewhat worse security situation then STUN when using address
restrictions.
3.2.6. Security Consideration
Symmetric RTP's major security issues are that streams can be
hijacked and directed towards any target that the attacker desires
the server's traffic to go to.
The attack can be performed in a few variations. The basic attack is
based on that an attacker can read the RTSP signaling packets and
those learn the address and port the server will send from and also
the SSRC the client will use. Having this information the attacker
can send its own RTP packets containing the correct RTP SSRC to the
correct address and port on the server. The destination of the
packets is set as the source IP and port in these RTP packets.
Another variation of this attack is to look at the RTP traffic being
directed to the server and simple change the source IP to the target
one desires to attack.
The first attack is possible to protect one self by applying
encryption of the RTSP signaling transport. However the second
variation is impossible to defend against. As the NAT rewrites the
source IP and port this can't be authenticated which would be
required to protect against this attack.
Symmetric RTP's strength against hijacking attacks by others then a
man in the middle is dependent on the random tag that is included in
the binding packets. This proposal uses the 32-bit RTP SSRC field to
this effect. Therefore it is important that this field is derived
with a non-predictive randomizer. It shall not be possible by knowing
the algorithm used and a couple of basic facts, be able to derive
what random number a certain client will use.
A attacker not knowing the SSRC but knowing which port numbers that a
server sends from can deploy a brute force attack on the server by
testing a lot of different SSRCs until it founds a matching one.
Therefore a server SHOULD implement functionality that blocks ports
that receive multiple binding packets with different SSRCs, especialy
if they are coming from the same IP/Port.
Westerlund Standards Track [Page 11]
INTERNET-DRAFT How to make RTSP traverse NAT & FW Feb. 21, 2003
To improve the security against attackers not being man in the
middles the random tags length needs to be increased. To perform this
while still using RTP and RTCP would require the development of a RTP
payload format for carrying these and a corresponding one in RTCP.
3.3. Application Level Gateways
3.3.1. Introduction
An Application Level Gateway (ALG) reads the application level
messages and perform the necessary changes to allow the protocol to
work through the middle box. However this behavior has some problems
in regards to RTSP:
1. Does not work when protocol is used with end-to-end security. As
the ALG can't inspect and change the application level messages the
protocol will fail due to the middle box.
2. Needs to be updated if extensions to the protocol are added. Due
to deployment issues with changing ALG's this may also break the end-
to-end functionality of RTSP.
Due to the above reasons it is NOT RECOMMENDED to use an RTSP ALG in
NATs. This is especially important for NAT's targeted to home users
and small office environments.
3.3.2. Using ALG for RTSP
An ALG for the RTSP core specification [7] would need to perform the
following tasks and changes to RTSP:
1. Detect any SETUP request.
2. Determine if the SETUP request already employ STUN type traversal.
This is detected by detecting a destination header that contains
one of the NAT's public IP addresses. If that is present the ALG
MUST NOT modify the request.
3. Create UDP mappings (client given IP/port <-> public IP/port)
where needed for all possible transport specification in the
transport header of the request found in (1). Enter the public
address and port(s) of these mappings in transport header.
Mappings SHALL be created with consecutive public port number
starting on an even number for RTP each stream. Mappings SHOULD
also be given a long timeout period, at least 5 minutes.
4. When the response is received from the server the ALG MAY 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
mappings part of that session.
Westerlund Standards Track [Page 12]
INTERNET-DRAFT How to make RTSP traverse NAT & FW Feb. 21, 2003
5. The ALG SHOULD keep alive the UDP mappings belonging to the an
RTSP session as long as: RTSP messages with the session's ID has
been sent in the last RTSP session timeout interval, or UDP
messages are sent on any of the UDP mappings during the last RTSP
timeout interval.
6. The ALG MAY remove a mapping as soon a TEARDOWN response has been
received for that media stream.
3.3.3. Deployment Considerations
Advantage:
- No impact on either client or server
- Can be made for any type of NATs
Disadvantage:
- When deployed they are hard to have updated to reflect protocol
modifications and extensions. If not updated they will prevent
functionality.
- When end-to-end security is used the ALG functionality fails and
prevents the protocol functionality.
- Can interfere with other type of traversal mechanisms.
3.3.4. Security Considerations
An ALG will not work when deployment of end-to-end RTSP signaling
security. Therefore deployment of ALG will result in that end-to-end
security will not be used by clients located behind NATs.
3.4. TCP Tunneling
3.4.1. Introduction
Using a TCP connection that is established from the client to the
server ensures that the server can send data to the client. The
connection opened from the private domain ensures that the server can
send data back to the client. To send data original intended to be
transport over RTP requires the TCP connection to support some type
of framing of the RTP packets.
Using TCP also results in that the client has to accept that real-
time performance may no longer be possible. TCP's problem of ensuring
timely deliver was the reasons why RTP was developed. Problems that
arise with TCP are: Head of line blocking, Retransmissions, Highly
varying congestion control.
Westerlund Standards Track [Page 13]
INTERNET-DRAFT How to make RTSP traverse NAT & FW Feb. 21, 2003
3.4.2. Usage of TCP tunneling in RTSP
The RTSP core specification [7] supports interleaving of media data
on the RTSP TCP signaling TCP connection. See section 10.13 in [7]
for how to perform this TCP tunneling.
There is currently work on one more way of transporting RTP over TCP
in AVT and MMUSIC. For signaling and rules on how to establish the
TCP connection is place of using UDP ports see [12]. Another draft
describes how to frame RTP over the TCP connection, see [13].
3.4.3. Deployment Considerations
Advantage:
- Works through all types of NATs.
Disadvantage:
- Functionality needs to be implemented on both server and client.
- May not give real-time performance.
3.4.4. Security Considerations
The TCP tunneling of RTP has no known security problem besides them
already present in RTSP. It is not possible to get any amplification
effect that is desired for denial of service attacks due to TCP's
flow control.
Opening further server ports that one can connect does not worsen any
denial of service attacks that the server can be target of.
A possible consideration will be the performance bottleneck any RTSP
signaling encryption will become when all session media needs to be
encrypted.
4. Firewalls
Firewalls exist for a purpose to protect a network from traffic not
desired by the firewall owner. Therefore it is a policy decision if a
firewall will let RTSP and its media streams through or not. RTSP is
designed to be as easy as possible to process for a firewall with a
policy to let the traffic pass through.
The firewall will need to allow the media streams associated with a
RTSP session pass through it. Therefore the firewall will need an ALG
that reads RTSP SETUP and TEARDOWN messages. By reading the SETUP
message the firewall can determine what type of transport and from
where the media streams will use. Very common will be the need to
open UDP ports for RTP/RTCP. By looking at the source and destination
addresses and ports the opening in the firewall can be minimized to
Westerlund Standards Track [Page 14]
INTERNET-DRAFT How to make RTSP traverse NAT & FW Feb. 21, 2003
the least necessary. The opening in the firewall can be closed after
a teardown message for that session or the session itself times out.
5. Security Consideration
The presence of NAT(s) is a security risk, as a client cannot perform
source authentication of its IP address. This prevents the deployment
of any future RTSP extensions providing security against hijacking of
sessions by a man in the middle.
Each of the different technique for doing NAT traversal has security
implications.
Using STUN as long as the server do not grant a client request to
send media to different IP addresses will provide the same level of
security as RTSP with out transport level security and source
authentication provides.
Usage of symmetric RTP will have a slightly higher risk of session
hijacking than normal RTSP. The reason is that there exists a
probability that an attacker is able to guess the random tag that the
client uses to prove its identity when creating the address bindings.
The usage of an RTSP ALG does not increase in itself the risk for
session hijacking. However the deployment of ALGs are sole mechanism
for RTSP NAT traversal will result in that usage of signaling
security will be prevented.
The usage of TCP tunneling has no known security problems. However it
might provide a bottleneck when it comes to end-to-end RTSP signaling
security if TCP tunneling is used on a interleaved RTSP signaling
connection.
6. IANA Consideration
This specification would like to register 1 new Transport header
parameter "sym_rtp" as defined in section 3.2.2.
It does also register one more RTSP option tag "nat.sym-rtp" as
defined in section 3.2.2.
7. Acknowledgments
The author would also like to thank all persons on the MMUSIC working
group's mailing list that has commented on this specification.
Persons having contributed in such way in special order to this
protocol are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall,
David Yon, Amir Wolf, Anders Klemets, and Colin Perkins.
Westerlund Standards Track [Page 15]
INTERNET-DRAFT How to make RTSP traverse NAT & FW Feb. 21, 2003
8. Author's Addresses
Magnus Westerlund Tel: +46 8 4048287
Ericsson Research Email: Magnus.Westerlund@ericsson.com
Ericsson AB
Torshamnsgatan 23
SE-164 80 Stockholm, SWEDEN
9. References
9.1. Normative references
[1] H. Schulzrinne, et. al., "Real Time Streaming Protocol (RTSP)",
IETF RFC 2326, April 1998.
[2] M. Handley, V. Jacobson, "Session Description Protocol (SDP)",
IETF RFC 2327, April 1998.
[3] D. Crocker and P. Overell, "Augmented BNF for syntax specifica-
tions: ABNF," RFC 2234, Internet Engineering Task Force, Nov.
1997.
[4] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[5] H. Schulzrinne, et. al., "RTP: A Transport Protocol for Real-
Time Applications", IETF RFC 1889, January 1996.
[6] J. Rosenberg, et. Al., " STUN - Simple Traversal of UDP Through
Network Address Translators", IETF Draft, draft-ietf-midcom-
stun-05.txt, Dec. 2002.
[7] H. Schulzrinne, et. al., "Real Time Streaming Protocol (RTSP)",
draft-ietf-mmusic-rfc2326bis-02.txt, IETF draft, November 2002,
work in progress.
9.2. Informative References
[8] P. Srisuresh, K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)," RFC 3022, Internet Engineering
Task Force, January 2001.
[9] Tsirtsis, G. and Srisuresh, P., "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, Internet Engineering
Task Force, February 2000.
[10] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, Internet Engineering Task Force,
December 1998.
[11] J. Postel, "internet protocol", RFC 791, Internet Engineering
Task Force, September 1981.
[12] D. Yon, "Connection-Oriented Media Transport in SDP", IETF
draft, draft-ietf-mmusic-sdp-comedia-04.txt, July 2002.
Westerlund Standards Track [Page 16]
INTERNET-DRAFT How to make RTSP traverse NAT & FW Feb. 21, 2003
[13] John Lazzaro, "Framing RTP and RTCP Packets over Connection-
Oriented Transport", IETF Draft, draft-lazzaro-avt-rtp-framing-
contrans-00.txt, January 2003.
10. IPR Notice
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Westerlund Standards Track [Page 17]
INTERNET-DRAFT How to make RTSP traverse NAT & FW Feb. 21, 2003
11. Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
This Internet-Draft expires in August 2003.
Westerlund Standards Track [Page 18]
