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.

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

   The list of Internet-Draft Shadow Directories can be accessed at

   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.


   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


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",
   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

   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

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

   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

   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


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

   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


   - Does not require RTSP server modifications, totally client
      implemented tool.


   - 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

   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

   Further a RTSP options tag that can be used to indicate support of
   symmetric RTP according to this specification is defined.


   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

   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


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
   - Have no interaction problems with any RTSP ALG changing the
      client's information in the transport header.


   - Requires Server support.
   - Has somewhat worse security situation then STUN when using address

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


   - No impact on either client or server
   - Can be made for any type of NATs


   - When deployed they are hard to have updated to reflect protocol
      modifications and extensions. If not updated they will prevent
   - 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


   - Works through all types of NATs.


   - 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

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

   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

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:
    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.
   [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

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

   This document and the information contained herein is provided

This Internet-Draft expires in August 2003.

Westerlund                  Standards Track                   [Page 18]