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 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]