Network Working Group Magnus Westerlund INTERNET-DRAFT Ericsson Category: Standards Track Thomas Zeng Expires:
December 2003August 2004 PacketVideo June 30, 2003Network Solutions Feb 16, 2004 How to Enable Real-Time Streaming Protocol (RTSP) traverse Network Address Translators (NAT) and interact with Firewalls. <draft-ietf-mmusic-rtsp-nat-01.txt><draft-ietf-mmusic-rtsp-nat-02.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).(2004). All Rights Reserved. Abstract This document describes six 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 are given. Further a description on how RTSP relates to firewalls is given. TABLE OF CONTENTS 1. Definitions.........................................................3 1.1. Glossary.......................................................3 1.2. Terminology....................................................3 2. Changes.............................................................3 3. Introduction........................................................4 3.1. NATs...........................................................5NATs...........................................................4 3.2. Firewalls......................................................6Firewalls......................................................5 4. Requirements........................................................6 5. Detecting the loss of NAT mappings..................................6 5.6. NAT Traversal Techniques............................................7 5.1. STUN...........................................................7 5.1.1. Introduction..............................................7 22.214.171.124.1. STUN...........................................................8 6.1.1. Introduction..............................................8 6.1.2. Using STUN to traverse NAT without server modifications...8 126.96.36.199.1.3. Embedding STUN in RTSP...................................10 188.8.131.52.1.4. Discussion On Co-located STUN Server.....................13 5.1.5.Server.....................11 6.1.5. ALG considerations.......................................13 5.1.6.considerations.......................................12 6.1.6. Deployment Considerations................................13 5.1.7.Considerations................................12 6.1.7. Security Considerations..................................15 5.2. ICE...........................................................16 5.2.1. Introduction.............................................16 5.2.2.Considerations..................................13 6.2. ICE...........................................................14 6.2.1. Introduction.............................................14 6.2.2. Using ICE in RTSP........................................17 5.2.3. Required Protocol Extensions.............................18 5.2.4.RTSP........................................15 156.2.3. Implementation burden of ICE.............................18 5.2.5.ICE...........................15 6.2.4. Deployment Considerations................................18 5.2.6.Considerations................................15 6.2.5. Security Considerations..................................19 5.3.Considerations..................................16 6.3. Symmetric RTP.................................................20 5.3.1. Introduction.............................................20 5.3.2. Necessary RTSP extensions................................20 5.3.3.RTP.................................................16 6.3.1. Introduction.............................................16 166.3.2. Using Symmetric RTP in RTSP..............................21 5.3.4.RTSP............................17 6.3.3. Open Issues..............................................23 5.3.5.Issues..............................................17 6.3.4. Deployment Considerations................................24 5.3.6.Considerations................................17 6.3.5. Security Consideration...................................24 5.4.Consideration...................................17 6.4. Application Level Gateways....................................25 5.4.1. Introduction.............................................25 5.4.2.Gateways....................................18 6.4.1. Introduction.............................................18 6.4.2. Guidelines On Writing ALGs for RTSP......................26 5.4.3.RTSP......................19 6.4.3. Deployment Considerations................................27 5.4.4.Considerations................................20 6.4.4. Security Considerations..................................27 5.5.Considerations..................................20 6.5. TCP Tunneling.................................................27 5.5.1. Introduction.............................................27 5.5.2.Tunneling.................................................20 6.5.1. Introduction.............................................20 6.5.2. Usage of TCP tunneling in RTSP...........................28 5.5.3.RTSP...........................21 6.5.3. Deployment Considerations................................28 5.5.4.Considerations................................21 6.5.4. Security Considerations..................................28 5.6.Considerations..................................21 6.6. TURN (Traversal Using Relay NAT)..............................29 5.6.1. Introduction.............................................29 5.6.2.NAT)..............................21 6.6.1. Introduction.............................................21 6.6.2. Usage of TURN with RTSP..................................29 5.6.3.RTSP..................................22 6.6.3. Deployment Considerations................................30 5.6.4.Considerations................................23 6.6.4. Security Considerations..................................31 6. Firewalls..........................................................31Considerations..................................23 7. Open Issues........................................................32Firewalls..........................................................24 8. Security Consideration.............................................32Open Issues........................................................25 9. IANA Consideration.................................................33Security Consideration.............................................25 10. Acknowledgments...................................................33IANA Consideration................................................26 11. Author's Addresses................................................33Acknowledgments...................................................26 12. References........................................................35 12.1.Author's Addresses................................................26 13. References........................................................27 13.1. Normative references.........................................35 12.2.references.........................................27 13.2. Informative References.......................................35 13. IPR Notice........................................................36References.......................................27 14. IPR Notice........................................................28 15. Copyright Notice..................................................36Notice..................................................29 1. Definitions 1.1. Glossary ALG –û Application Level Gateway, an entity that can be embedded in a NAT to perform the application layer functions required for a particular protocol to traverse the NAT  ICE - Interactive Connectivity Establishment, see . DNS –û Domain Name Service MID - Media Identifier from Grouping of media lines in SDP, see . NAT - Network Address Translator, see . NAT-PT - Network Address Translator Protocol Translator, see  RTP - Real-time Transport Protocol, see . RTSP - Real-Time Streaming Protocol, see  and . SDP - Session Description Protocol, see . SSRC - Synchronization source in RTP, see . TBD - To Be Decided 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 . 2. Changes The following changes has been done since draft-ietf-mmusic-rtsp-nat- 00.txt: - New co-author Thomas Zeng. -Added a chapter onrequirements section, per discussions during IETF 58. - Delegated the usage ofdiscussion on using ICE in RTSP. - Added a definitionfor how to use STUN embeddedRTSP to traverse symmetric NATs. - Added chapter on detecting loss of NAT mappings. - More text on Firewalls. - Symmetric RTP description has been extended with use case witha few well-known ports on the server side.separate draft. - Added text on transition strategies forRemoved all the methods. - Improved languagesolutions proposal in the whole draft. - An Open Issues section has been created.regards protocol changing mechanism. 3. Introduction Today there is a proliferative deployment of different flavors of Network Address Translator (NAT) boxes that in practice follow no open standards . NATs cause discontinuity in address realms , therefore a protocol, such as RTSP, needs to try to make sure that it can deal with such discontinuities caused by NATs. The problem with RTSP is that, being a media control protocol that manages one or more media streams, it carries information about network addresses and ports inside itself. Because of this, even if RTSP itself, when carried over TCP for example, is not blocked by NATs, its media streams are often blocked by NATs when RTSP based streaming servers are deployed as is and without special provisions to support NAT traversal. Like NATs, firewalls (FWs) are also middle boxes that need to be considered. They are deployed to prevent non-desired traffic/protocols to be able to get in or out of the protected network. RTSP is designed such that a firewall can be configured to let RTSP controlled media streams to go through with minimal implementation problems. However there is a need for more detailed information on how FWs should be configured to work with RTSP. This document describes the usage of known NAT traversal mechanisms that can be used with RTSP. Following the guidelines spelled out in , we describe the required RTSP protocol extensions for each method, transition strategies, and we also discuss each method’smethodÆs security concerns. Some of the NAT/FW traversal solutions are based on IETF internet drafts in their early stage of standardization (e.g., ICE and TURN). Given the current demand for NAT traversal solutions in the RTSP market place, it is foreseeable that a standard be created or adopted, in a timely fashion, by IETF MMUSIC WG to solve NAT traversal problem specifically for RTSP based streaming systems.This document is not based on RFC 2326 . It is instead based and dependent on the updated RTSP specification , which is under development in IETF 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 . This document is one extension document to this core spec to document a special functionality that extends the RTSP protocol. This document is intended to be updated to stay consistent with the core protocol. 3.1. NATs Today there exist a number of different NAT types and usage areas. The different NAT types are cited here from STUN : 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. NATs 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 give there users private addresses. This is done both for control and for lack of IP addresses. Native Address Translation and Protocol Translation (NAT-PT)  is a 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. If 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. 3.2. Firewalls A firewall (FW) is a security gateway that enforces certain access control policies between two network administrative domains: a private domain (intranet) and a pulic domain (public internet). Many organizations use firewalls to prevent privacy intrusions and malicious attacks to corporate computing resources in the private intranet . A comparison between NAT and FW are given below: 1. FW must be a gateway between two network administrative domains, while NAT does not have to sit between two domains. In fact, in many corporations there are many NAT boxes within the intranet, in which case the NAT boxes sit between subnets. 2. NAT does not in itself provide security, although some access control policies can be implemented using address translation schemes. 3. NAT and FWs are similar in that they can both be configured to allow multiple network hosts to share a single public IP address. In other words, a host behind a NAT or FW can have a private IP address and a public one, so for NAT and FW there is the issue of address mapping which is important in order for RTSP protocol to work properly when there are NATs and FWs between the RTSP server and its clients. In the rest of this memo we use the phrase ôNAT traversalö interchangeably with ôNAT/FW traversalö and ôNAT/Firewall traversalö. 4. DetectingRequirements This section considers the lossset of requirements when designing or evaluating RTSP NAT mappings Several ofsolutions. RTSP is a client/server protocol, and as such the described NAT traversal techniquestargeted applications in general deploy RTSP servers in the next chapterpublic address realm. However, there are use cases where the fact that the NAT UDP mapping's externalreverse is true: RTSP clients are connecting from public address and port can be discovered.realm to RTSP servers behind home NATs. This informationis then utilized to directthe traffic intendedcase for the local side's addressinstance when home surveillance cameras running as RTSP servers intend to the externalstream video to cell phone users in the public address realm through a home NAT. The first priority should be to solve the RTSP NAT traversal problem for RTSP servers deployed in the open. The list of feature requirements for RTSP NAT solutions are given below: 1. MUST work for all flavors of NATs, including symmetric NATs 2. MUST work for firewalls (subject to pertinent firewall administrative policies), including those with ALGs 3. SHOULD have minimal impact on clients in the open and not dual- hosted o For instance, no extra delay from RTSP connection till arrival of media 4. SHOULD be simple to use/implement/administer that people actually turn them on o Otherwise people will resort to TCP tunneling through NATs o Address discovery for NAT traversal should take place behind the scene, if possible 5. SHOULD authenticate dual-hosted client transport handler to prevent DDOS attacks 5. Detecting the loss of NAT mappings Several of the NAT traversal techniques in the next chapter use the fact that the NAT UDP mapping's external address and port can be discovered. This information is then utilized to direct the traffic intended for the local side's address to the external instead. However any such information is only valid while the mapping is intact. As the IAB's UNSAF document  points outout, the mapping can either timeout or change its properties. It is therefore important for the NAT/FWNAT traversal solutions to handle the loss or change of NAT mappings, according to UNSAF. First, it is important to ensure that there exists the possibility to send keep-alive traffic to minimize the probability of timeout. The difficulty is that the timeout timer can have varying length between different NATs. That is the reason why that UNSAF recommends usage of STUN to determine this timeout. Secondly, it is possible to detect and recover from the situation where the mapping has been changed or removed. The possibility to detect a lost mapping is based on the fact that no traffic will arrive. Below we will give some recommendation on how to detect loss of NAT mappings when using RTP/RTCP under RTSP control. For RTP session there is normally a need to have both RTP and RTCP functioning. The loss of a RTP mapping can only be detected when expected traffic does not arrive. If no data arrives after having issued a PLAY request and received the 200 response, one can normally expect to receive RTP packets within a few seconds. However, for a receiver to be certain to detect the case where no RTP traffic was delivered due to NAT trouble, one should monitor the RTCP Sender reports. The sender report carries a field telling how many packets the server has sent. If that has increased and no RTP packets has arrived for a few seconds it is very likely the RTP mapping has been removed. The loss of mapping carrying RTCP is simpler to detect. As RTCP is normally sent periodically in each direction, even during the RTSP ready state, if RTCP packets are missing for several RTCP intervals, the mapping is likely to be lost. Note that if no RTCP packets are received by the RTSP server for a while, the RTSP server has the option to delete the corresponding SSRC and RTSP session ID, which means either the client could not get through a middle box NAT/FW, or that the client is mal-functioning. 5.6. NAT Traversal Techniques There exist a number of NAT traversal techniques that can be used to allow RTSP to traverse NATs. However they have different features, they are applicable to different topologies; and the cost is also different. They also differ in their security considerations. In the following sections, each technique is outlined in details in terms of its advantages and disadvantages. Not all of the techniques are yet described in the full details needed to actually use this document as a specification for how to use them. These sections are included to present comparison amongst the different methods in order for one to identify the most suitable method for a particular RTSP deployment scenario. There are methods that use protocols in early stage of standardization, such as TURN and ICE. 184.108.40.206. STUN 220.127.116.11.1.1. Introduction STUN – Simpleû ôSimple Traversal of UDP Through Network Address TranslatorsTranslatorsö  is a standardized protocol developed by the MIDCOM WG that allows a client to use secure means to discover the presence of a NAT between himself and the STUN server and the type of that NAT. The client then uses the STUN server to discover the address bindings assigned by the NAT. The protocol also allows discovery of the mappings timeout period and can be used in any keep-alive mechanism. STUN is a client-server protocol. STUN client sends a request to a STUN server and the server returns a response. There are two types of STUN requests –û Binding Requests, sent over UDP, and Shared Secret Requests, sent over TLS over TCP. We note here that for RTSP clients running on embedded devices, it may not be practical to require TLS be implemented on the embedded device (such as a cell phone). Therefore in the next section we propose to adapt RFC 3489 () so as to let RTSP use a subset of STUN packets/features for NAT traversal, but without requiring full implementation of STUN in an RTSP server or RTSP client. We note that RFC 3489 has provisions for STUN to be embedded in another application (see section 6 of ). 18.104.22.168.1.2. Using STUN to traverse NAT without server modifications This section describes how a client can use STUN to traverse NATs to RTSP servers without requiring server modifications. However this method has limited applicability and requires the server to be available in the external/public address realm in regards to the client located behind a NAT(s). Limitations: - The server must be located in either a public address realm or the next hop external address realm in regards to the client. - The client may only be located behind NATs that are of the full cone, address restricted, or port restricted type. Clients behind symmetric NATs cannot use this method. Method: A RTSP client using RTP transport over UDP can use STUN to traverse a full cone NAT(s) 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 establishing a streaming session the possible delays in the session establishment will be reduced. If no NAT is detected, normal SETUP SHOULD be used. 2. The RTSP client determines the number of UDP ports needed by counting the number of needed media transport protocols sessions in the multi-media presentation. This information is available in the media description protocol, e.g. SDP. For example, each RTP session will in general require two UDP ports, one for RTP, and one for RTCP. 3. For each UDP port required, establish a mapping and discover the public/external IP address and port number with the help of the STUN server. If successful a mapping has been established: clients local address/port <-> public address/port. 4. Perform the RTSP SETUP for each media. In the transport header the following parameter SHOULD be included with the given values: "dest_addr" with the public/external IP address and port pair for both RTP and RTCP. To allow this to work servers MUST allow a client to setup the RTP stream on any port, not only even ports. The server SHOULD respond with a transport header containing an "src_addr" parameter with the RTP and RTCP source IP address and port of the media stream. 5. To keep the mappings alive, the client SHOULD periodically send UDP traffic over all mappings needed for the session. STUN MAY 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 enough. For mappings carrying RTP traffic and for mappings carrying RTCP packets not frequent enough, keep alive messages SHOULD be sent. As keep alive messages, empty IP/UDP messages SHOULD be sent to the streaming servers discard port (port number 9). If a UDP mapping is lost then the above discovery process is required to be performed again. The media stream needs to be SETUP again to change the transport parameters to the new ones. This will likely cause a glitch in media playback. To allow UDP packets to arrive from the server to a client behind a restricted NAT, some UDP packets must first be sent to the server. The client, before sending a RTSP PLAY request, must send an empty or small UDP message, on each mapping, to the IP address given as the servers source address. To create minimum problems for the server these UDP packets SHOULD be sent to the server's discard port (port number 9) and contain no or very little data. To ensure that at least one UDP message passes the NAT, several messages are recommended to be sent. For a port restricted NAT the client must send messages to the exact ports used by the server to send UDP packets before sending a RTSP PLAY request. This makes it possible to use the above described process with the following additional restrictions: For each port mapping, UDP packets needs to be sent first 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 or less than 12 bytes large UDP message. RTCP: A correctly formed RTCP message. The above described adaptations for restricted NATs will not work unless the server includes the "src_addr" "Transport" header parameter. 22.214.171.124.1.3. Embedding STUN in RTSP This section describesoutlines the adaptation and embedding of STUN within RTSP. This enables STUN to be used to traverse any type of NAT, including symmetric NATs. This adaptation is an extension to the core RTSPAny protocol ,changes are beyond the scope of this memo and thereforeis signaled by feature tag. As specifiedinstead defined in , features are recommended to be negotiated using "supported" headers. We define the feature tag for embeddedTBD internet draft. Limitations: This NAT traversal solution (using STUN with out authentication support as: nat.stun and for embedded STUN supporting authentication as: nat.stun-auth If one side supports "nat.stun-auth" but the other side only supports "nat.stun", then both sides must go through negotiation and possibly downgrade to using "nat.stun". If one RTSP end system refuses to accept "nat.stun", then do not use STUN for RTSP. Limitations: This NAT traversal solution (using STUN with RTSP) has limitations: 1. It does not work if both RTSP clientRTSP) has limitations: 1. It does not work if both RTSP client and RTSP server are behind separate NATs. 2. In the case of "nat.stun", theThe RTSP server may, for security reasons, refuse to send media streams to an IP different from the IP in the client RTSP requests. Therefore, if the client is behind a NAT that has multiple public addresses, and the client’sclientÆs RTSP port and UDP port are mapped to different IP addresses, RTSP SETUP will fail. Deviations from STUN as defined in RFC2389RFC 3489 Specifically, we differ from RFC3489 in two aspects: 1. We allow RTSP applications to have the option to perform "binding discovery" without authentication; 2. We require STUN server be co-located on RTSP server’sserverÆs media ports. In order to allow binding discovery without authentication, the STUN server embedded in RTSP application would ignore authentication tag, and the STUN client embedded in RTSP application would use dummy authentication tag, as well. In order to use STUN to solve NAT traversal when RTSP client is behind a symmetric NAT, STUN server must co-locate on RTSP server’sserverÆs media ports. This can be done, for instance, by embedding STUN server in RTSP server. In fact, if STUN server is indeed co-located with RTSP server’sserverÆs media port, then a RTSP client using RTP transport over UDP can use STUN to traverse ALL types of NATs that have been defined in section 3.1. In the case of symmetric NAT, the party inside the NAT must initiate UDP traffic. The STUN Bind Request, being a UDP packet itself, can serve as the traffic initiating packet. Subsequently, both the STUN Binding Response packets and the RTP/RTCP packets can traverse the NAT, regardless of whether the RTSP server or the RTSP client is behind NAT. Likewise, if a RTSP server is behind a NAT, then an embedded STUN server must co-locate on the RTSP client’sclientÆs RTCP port. In this case, we assume that the client has some means to establish TCP connection to the RTSP server behind NAT so as to exchange RTSP messages with the RTSP server. RTSP implementations supporting such features must use the feature tag, (nat.stun-auth or nat.stun) to indicate to each other the availability of such embedded, co-located STUN servers.To minimize delay, we require that the RTSP server supporting this option must inform its client the RTP and RTCP ports that the server intend to send RTP and RTCP packets, respectively. To minimize the keep-alive traffic for address mapping, we also require that the RTSP end-point (server or client) sends and receives RTCP packets from the same port. RTSP NAT Traversal Algorithm Using6.1.4. Discussion On Co-located STUN The actual NAT traversal algorithm contains six steps. Step 1: This first step is for both RTSP server and clientServer In order to discover whether there is a NAT, and if yes, the timeout period for UDP mapping on the NAT. For the RTSP client, as soon as it has learnt thatuse STUN to traverse symmetric NATs the RTSPSTUN server supportsneeds to be co-located with the "nat.stun" or "nat.stun-auth" feature, and that it has learntstreaming server media ports, i.e., the RTSP server’sport from which RTP and RTCP ports, it should send STUN requestpackets will be sent. This creates a de- multiplexing problem: we must be able to those ports,differentiate a STUN packet from a media packet. This will be done based on heuristics. This works fine between STUN and also include the appropriate feature tag (either nat.stunRTP or nat.stun-auth) in all of its relevant RTSP requests and responses. OnRTCP where the first byte has always present difference, but this can't be guaranteed to work with other hand,media protocols. 6.1.5. ALG considerations If a NAT supports RTSP server can figure out whether itALG (Application Level Gateway) and is innot aware of the STUN traversal option, service failure may happen, because a client discovers its public Internet at start up time. If it turns out thatIP address and port numbers, and inserts them in its SETUP requests, when the RTSP server isALG processes the SETUP request it may change the destination and port number, resulting in a private address realm,unpredictable behavior. 6.1.6. Deployment Considerations For the RTSP server must be prepared to receivenon-embedded usage of STUN Binding Request on its RTCP receive port (so as to help RTSP client’s RTCP RR reports to reachthe right destination). Otherwise, if it turns out thatfollowing applies: Advantages: - Using STUN does not require RTSP server ismodifications; it only affects the client implementation. Disadvantages: - Requires a STUN server deployed in the public address realm, it must be prepared to do the following:space. - If "nat.stun" is the agreed-upon feature tag betweenOnly works with Cone NATs. Restricted Cone NATs create some issues. Does not work with Symmetric NATs without server and client, themodifications. - Will mostly not work if a NAT uses multiple IP addresses, since RTSP server must monitor its RTP and RTCP send ports for STUN Binding Requests; - If "nat.stun-auth" isgenerally requires all media streams to use the agreed-upon feature tag between server and client,same IP as used in the RTSP server must monitor its RTP and RTCP send ports forconnection (for more on this subject, see next section, security considerations). - Interaction problems exist when a RTSP ALG is not aware of STUN. - Using STUN Shared Secrete Requestsrequires that RTSP servers and Binding Requests; Step 2: Theclients support the updated RTSP client determinesspecification. Transition: The usage of STUN can be phased out gradually as the numberfirst step of UDP ports needed by countinga STUN capable machine can be to check the numberpresence of RTP sessions inNATs for the multi-media presentation. This information is availablepresently used network connection. The removal of STUN capability in the media description protocol, e.g. SDP , and according to the client’s media selection criteria. In general each RTP session will require two UDP ports, one for RTP, and one for RTCP. The RTSPclient also obtains, for each RTP session, the media port from which RTSP serverimplementations will send outhowever most probably wait until no need at all exists to use STUN. For the RTP packets. Step 3: This step applies ifEmbedded STUN method the client knows, from step 1, that itfollowing applies: Advantages: - STUN is behind NAT. For each UDP port required, thea solution first used by SIP applications. As shown above, with little or no changes, RTSP client must openapplication can re-use STUN as a local socket using an available UDP port onNAT traversal solution, avoiding the host computer, establishpit-fall of solving a mapping and discoverproblem twice. - STUN has built-in message authentication features, which makes it more secure. See next section for an in-depth security discussion. - This solution works as long as there is only one RTSP end point in the public IPprivate address and port number with the helprealm, regardless of the STUN server co- located at the RTSP server’s media ports. Assume STUN protocol exchange is successful, an address mapping willNATÆs type. There may even be sent backmultiple NATs (see figure 1 in ). - Compares to the RTSP clientother UDP based NAT traversal methods in athis document, STUN response packet, then the RTSP client must record the mapping between client’s local address/portrequires little new protocol development (since STUN is already a IETF standard), and most likely less implementation effort, since open source STUN server and the external address/port in its database. Step 4: RTSPclient then performshave become available . There is the need to embed STUN in RTSP SETUP for each media. Inserver and client, which require a de-multiplexer between STUN packets and RTP/RTCP packets. There is also a need to register the transport headerproper feature tags. Disadvantages: - Some extensions to the following parameter SHOULDRTSP core protocol, signaled by RTSP feature tags, must be included with the given values: "dest_addr" with the external IP address and port pair for bothintroduced. - Requires an embedded STUN server to co-locate on each of RTSP serverÆs media protocol's ports (e.g. RTP and RTCP. To allow thisRTCP ports), which means more processing is required to work servers MUST allowde-multiplex STUN packets from media packets. For example, the de-multiplexer must be able to differentiate a clientRTCP RR packet from a STUN packet, and forward the former to setupthe RTP stream on any port,streaming server, the later to STUN server. - It does not only even ports. Step 5: This step only applieswork if client is innone of the open, butRTSP server discovers, withand client is in the help of apublic STUN server, that itaddress realm, and each of them is the onebehind a different NAT. - Even if the RTSP server obtains the client’s RTCP port number fromis in the SETUP request,open, and immediately sends STUN request to that port to obtain the address mapping. Assume againthe mappingclient is obtained successfully, then the server SHALL respond with a transport header containingbehind a "src_addr" parameter withmulti-addressed NAT, it may still break if the mapped RTCP sourceRTSP server does not allow RTP packets to be sent to an IP address and port. Step 6: To keep the mappings alive,differs from the party that is behind NAT SHOULD periodically send UDP traffic over all mappings needed forIP of the sessionclientÆs RTSP request. - Interaction problems exist when no traffica RTSP ALG is received. For the mapping carrying RTCP trafficnot aware of STUN. - Using STUN requires that RTSP servers and clients support the periodic RTCP traffic may be enough. For mappings carrying RTP trafficupdated RTSP specification, and for mappings carrying RTCP traffic infrequently, keep alive messages SHOULD be sent.they both agree to support the proper feature tag. Transition: The usage of STUN packetscan servebe phased out gradually as keep alive messages, given the requirement to have STUN server collocates onthe RTSP server’s media ports. Iffirst step of a UDP mapping is lost then the above discovery process is required to be performed again. The media stream needs toSTUN capable machine can be SETUP againto changecheck the transport parameters topresence of NATs for the new ones. This will likely cause a glitch in media playback. 5.1.4. Discussion On Co-locatedpresently used network connection. The removal of STUN Server In ordercapability in the client implementations will however most probably wait until there is no need at all to use STUN to traverse symmetric NATs the STUNSTUN. 6.1.7. Security Considerations To prevent RTSP server needs to be co-located withbeing used as Denial of Service (DoS) attack tools the streaming server media \ports, i.e., the port from which RTP packets will be sent. This creates a de- multiplexing problem: we must be able to differentiate a STUN packet from a media packet. This will be done based on heuristics. This works fine between STUNRTSP Transport header parameter "destination" and RTP or RTCP where the first byte has always present difference, but this can't be guaranteed"dest_addr" are generally not allowed to work withpoint to any IP address other media protocols. 5.1.5. ALG considerations If a NAT supportsthan the one that RTSP ALG (Application Level Gateway) andmessage originates from. The RTSP server is not awareonly prepared to make an exception of the STUN traversal option, service failure may happen, because a client discovers its public IP address and port numbers, and inserts them in its SETUP requests,this rule when the RTSP ALG processesclient is trusted (e.g., through the SETUP request it may changeuse of a secure authentication process, or through some secure method of challenging the destination and port number, resulting in unpredictable behavior. 5.1.6. Deployment Considerations For the non-embedded usage of STUNto verify its willingness to accept the following applies: Advantages: - UsingUDP traffic). Such restriction means that STUN does not require RTSP server modifications, it only affects the client implementation. Disadvantages: - Requires a STUN server deployed in thework for NATs that would assign different IP addresses to different UDP flows on its public address space. - Only works with Cone NATs. Restricted Coneside. Therefore most multi-addressed NATs create some issues. Doeswill not work with Symmetric NATs without server modifications. - Will mostly not work if a NAT uses multiple IP addresses, sinceSTUN. In terms of security property, STUN combined with destination address restricted RTSP server generally requires all media streams to usehas the same IPsecurity properties as used inthe RTSP connection (for more on this subject, see next section, security considerations). - Interaction problems exist whencore RTSP. It is protected from being used as a DoS attack tool unless the attacker has ability to hijack RTSP ALG is not aware of STUN. -stream. Using STUN requires that RTSP servers and clientsSTUN's support the updated RTSP specification. Transition: The usagefor message authentication and secure transport of RTSP messages, attackers cannot modify STUN can be phased out graduallyresponses or RTSP messages to change media destination. This protects against hijacking, however as the first step ofa STUN capable machineclient can be to checkthe presenceinitiator of NATs for the presentlyan attack, these mechanisms cannot securely prevent RTSP servers being used network connection.as DoS attack tools. 6.2. ICE 6.2.1. Introduction ICE (Interactive Connectivity Establishment)  is a methodology for NAT traversal that is under development for SIP. The removal of STUN capabilitybasic idea is to try, in the client implementations will however most probably wait until no need ata parallel fashion, all existspossible connection addresses that an end point may have. This allows the end-point to use STUN. For the Embedded STUN methodthe following applies: Advantages: - STUNbest available UDP "connection" (meaning two UDP end-points capable of reaching each other). The methodology has very nice properties in that basically all NAT topologies are possible to traverse. Here is a solution first used by SIP applications. As shown above, with little or no changes, RTSP applicationhow ICE works. End point A collects all possible address that can re-usebe used, including local IP addresses, STUN as a NAT traversal solution, avoiding the pit-fallderived addresses, TURN addresses. On each local port that any of solvingthese address and port pairs leads to, a problem twice. -STUN has built-in message authentication features, which makes it more secure. See next section for an in-depth security discussion. - This solution works as long as thereserver is installed. This STUN server only one RTSP end point inaccepts STUN requests using the private address realm, regardlesscorrect authentication through the use of username and password. End-point A then sends a request to establish connectivity with end- point B, which includes all possible ways to get the NAT’s type. There may even be multiple NATs (see figure 1 in ). - Comparesmedia through to other UDP based NAT traversal methods in this document, STUN requires little new protocol development (since STUN is alreadyA. Note that each of AÆs published address/port pairs has a IETF standard), and most likely less implementation effort, since open sourceSTUN server and client have become available . There is the needco-located. B, before responding to embedA, uses a STUN in RTSP serverclient to try to reach all the address and client,port pairs specified by A. The destinations for which require a de-multiplexer betweenthe STUN packets and RTP/RTCP packets. Thererequests have successfully completed are then indicated. If bi-directional communication is also a need to registerintended the proper feature tags. Disadvantages: - Feature tagsend-point B must be registered with IANA. - Requires an embedded STUN server to co-locate on each of RTSP server’s media protocol's ports (e.g. RTPthen in its turn offer A all its reachable address and RTCP ports),port pairs, which means more processing is requiredthen are tested by A. If B fails to de-multiplexget any STUN packetsresponse from media packets. For example, the de-multiplexer must be able to differentiate a RTCP RR packetA, all hope is not lost. Certain NAT topologies require multiple tries from aboth ends before successful connectivity is accomplished. The STUN packet,requests may also result in that more connectivity alternatives are discovered and forward the former to the streaming server,conveyed in the later toSTUN server. - It does not work if none of the RTSP server and clientresponses. This chapter is in the public address realm, and each of themnot yet a full technical solution. It is behindmostly a different NAT. - Even if thefeasibility study on how ICE could be applied to RTSP server is in the open,and the client is behind a multi-addressed NAT,what properties it may still break if thewould have. One nice thing about ICE for RTSP serveris that it does not allow RTP packets to be sentmake it possible to an IP differs from the IP of the client’sdeploy RTSP request. - Interaction problems exist whenserver behind NAT/FIRWALL, a desirable option to some RTSP ALG is not aware of STUN. -applications. 6.2.2. Using STUNICE in RTSP The usage of ICE for RTSP requires that RTSP serversboth client and clients support theserver be updated RTSP specification, and they both agreeto supportinclude the proper feature tag. Transition: The usage of STUN can be phased out gradually asICE functionality. If both parties implement the first step of a STUN capable machine cannecessary functionality the following step-by-step algorithm could be used to check the presence of NATsaccomplish connectivity for the presently used network connection. The removal of STUN capability in the client implementations will however most probably wait until there is no need at all to use STUN. When thereUDP traffic. This assumes that it is no more needpossible to use STUN,establish a TCP connection for the feature tags, "nat.stun" and "nat.stun-auth", can be de-registered at IANA. 5.1.7. Security Considerations To preventRTSP server being used as Denial of Service (DoS) attack toolsmessages between the RTSP Transport header parameter "Destination"client and "dest_addr" are generally not allowed to point to any IP address other thanthe one that RTSP message originates from. The RTSP serverserver. This is only prepared to make an exception of this rule whennot trivial in scenarios where the clientserver is trusted (e.g., through the use oflocated behind a secure authentication process, or throughNAT, and may require some secure method of challengingTCP ports been opened, or the destination to verify its willingnessdeployment of proxies, etc. Refer to accept the UDP traffic). Such restriction means that STUN does not work for NATs that would assign different IP addressesthe mapping of ICE to different UDP flows on its public side. Therefore most multi-addressed NATsRTSP. 6.2.3. Implementation burden of ICE The usage of ICE will not work with STUN. In termsrequire that a number of security property, STUN combined with destination address restricted RTSP hasnew protocols and new RTSP/SDP features be implemented. This makes ICE the same security properties assolution that has the core RTSP. It is protected from being used as a DoS attack tool unlesslargest impact on client and server implementations amongst all the attacker has ability to hijackNAT/FW traversal methods in this document. Some RTSP stream. Using STUN's support for message authentication and secure transport ofserver implementation requirements are: - Full STUN server features - limited STUN client features - Dynamic SDP generation with more parameters. - RTSP messages, attackers cannot modifyerror code for ICE extension Some client implantation requirements are: - Limited STUN responses orserver features - Limited STUN client features - RTSP messages to change media destination. This protects against hijacking, howevererror code and ICE extension 6.2.4. Deployment Considerations Advantages: - Solves NAT connectivity discovery for basically all cases as long as a clientTCP connection between them can be established in the initiator of an attack, these mechanisms can't be used to protectfirst hand. This includes servers against being DoS attack tools. 5.2. ICE 5.2.1. Introduction ICE (Interactive Connectivity Establishment)  is a methodology for NAT traversalbehind NATs. (Note that is under development for SIP. The basic idea is to try, ina parallel fashion, all possible connection addresses that an end pointproxy between address domains may have. This allows the end-pointbe required to useget TCP through). - Improves defenses against DDOS attacks as media receiving client requires authentications, via STUN on its media reception ports. See  for more details. Disadvantages: - Increases the best available UDP "connection" (meaning two UDP end-points capable of reaching each other). The methodology has very nice properties in that basically all NAT topologies are possible to traverse. Here is how ICE works. End point A collects all possible address that can be used, including local IP addresses, STUN derived addresses, TURN addresses. On each local port that any of these address and port pairs leads to, a STUN server is installed. This STUN server only accepts STUN requests using the correct authentication through the use of username and password. End-point A then sends a request to establish connectivity with end- point B, which includes all possible ways to get the media through to A. Note that each of A’s published address/port pairs has a STUN server co-located. B, before responding to A, uses a STUN client to try to reach all the address and port pairs specified by A. The destinations for which the STUN requests have successfully completed are then indicated. If bi-directional communication is intended the end-point B must then in its turn offer A all its reachable address and port pairs, which then are tested by A. If B fails to get any STUN response from A, all hope is not lost. Certain NAT topologies require multiple tries from both ends before successful connectivity is accomplished. The STUN requests may also result in that more connectivity alternatives are discovered and conveyed in the STUN responses. This chapter is not yet a full technical solution. It is mostly a feasibility study on how ICE could be applied to RTSP and what properties it would have. One nice thing about ICE for RTSP is that it does make it possible to deploy RTSP server behind NAT/FIRWALL, a desirable option to some RTSP applications. 5.2.2. Using ICE in RTSP The usage of ICE for RTSP requires that both client and server be updated to include the ICE functionality. If both parties implement the necessary functionality the following step-by-step algorithm could be used to accomplish connectivity for the UDP traffic. This assumes that it is possible to establish a TCP connection for the RTSP messages between the client and the server. This is not trivial in scenarios where the server is located behind a NAT, and may require some TCP ports been opened, or the deployment of proxies, etc. 1. The client retrieves the SDP from the ICE enabled RTSP server. This SDP contains indication that the RTSP server supports ICE and gives the address/ports for each media and its necessary UDP streams. This may require a SDP extension or possibly the "c=" lines in which port numbers can be used. This will however require the server to send media streams from well-known ports. This will result in that many sessions will go over the same ports for servers handling multiple users. 2. The client analyzes the SDP and determines the number of local UDP ports it will need. For each port it also installs a STUN server with authentication requirement using an authentication tag. From these ports the client then tries a STUN request to the server's announced ports, which are intercepted by the co-located STUN servers. If successful, the client’s NAT bindings, as seen by the RTSP server, are discovered by these STUN servers and sent back to the RTSP client. Also, other addresses, including addresses from public STUN servers and TURN addresses, can be collected by the RTSP client. 3. Client creates a SETUP request where he includes a number of transport header specifications. The client may offer more than one transport configurations, but for each configuration it will need to create multiple specifications of destination addresses that it has learned in descending priority order. The client also includes in the transport specification the ICE indicator carrying the user name and password required by the client's STUN servers. 4. The server receives the SETUP request and selects which transport specification it would like to accept. Here all specifications are the same except for destination address/port. For all specifications in the configuration the server tries to "STUN" these addresses/ports. Depending on the answer, the following results may happen: A. The RTSP server successfully connects to the client’s STUN server, and the RTSP server selects the specification with highest priority that yields a successful response and include that address/port in the SETUP response's transport headers destination field. The media is ready to be played. B. The server fails to reach any of the client’s STUN servers. It uses a new error code to inform the client of this. At the same time it includes an updated SDP, which contains all addresses that it is reachable on. The server might have learned some new reachable addresses since the initial SDP. The client then tries again by going to step 2 above and repeat the entire process. If it fails multiple times the server and client eventually give up. 5.2.3. Required Protocol Extensions 1. A SDP extension to indicates that the server supports ICE. It will also require that grouping of media lines  with the alternative semantics  be used in the SDP to indicate the different alternatives. 2. A new Transport header parameter that indicates that ICE shall be used on these streams and a way to convey the authentication user name and password that the server shall use to contact the client’s STUN server. 3. A RTSP error code for failed ICE setup. That error code will also need to include entity body in the response to carry the updated SDP description. 5.2.4. Implementation burden of ICE The usage of ICE will require that a number of new protocols and new RTSP/SDP features be implemented. This makes ICE the solution that has the largest impact on client and server implementations amongst all the NAT/FW traversal methods in this document. A RTSP server implementation requirements: - Full STUN server features - limited STUN client features - SDP extensions that includes MID  and ICE features - Dynamic SDP generation with more parameters. - RTSP error code for ICE extension Client: - Limited STUN server features - Limited STUN client features - SDP extensions that include MID  and ICE features - RTSP error code and ICE extension 5.2.5. Deployment Considerations Advantages: - Solves NAT connectivity discovery for basically all cases as long as a TCP connection between them can be established in the first hand. This includes servers behind NATs. (Note that a proxy between address domains may be required to get TCP through). - Prevents DOS attacks as media receiving client is required to do STUN responses with authentications on its media reception ports, see 5.2.6. Disadvantages: - Increases the setup delay with at least the amount of time it takes the server to perform its STUN requests. - Forces servers to use a few well-known media ports. - Assumes that it is possible to de-multiplex between media packets and STUN packets. - Has high implementation burden for both server and client. Given the complexity of ICE, it is foreseeable that practitioners may opt to use TCP tunneling to deploy RTSP based services. Note that TCP tunneling can result in loss of real-time properties for the media streams. - ICE is not a standard yet. It is only an initial proposal in the SIPPING working group. - ICE has the same consideration regarding ALGs as STUN, see section 5.1.5. Transition: The use of ICE enables a client to phase-out not needed methods of creating NAT bindings. However the usage of ICE to ensure that media delivery is not done to unwanted receiver is not intended to be removed as it strengthens security. 5.2.6. Security Considerations ICE has the advantage that it prevents RTSP servers from being used as DoS tools. The protection is achieved due to the STUN request sent from the server to the client. A client requesting media gives the destination address and port for the server to deliver the media too. The server tries these port using STUN requests. If the client does not have prior knowledge about the media stream no STUN server are present. The usage of user name and password ensures that only the server that the client has requested to deliver media can issue valid STUN request. This solution is only vulnerable to a man in the middle attack, where the attacker can redirect and answer the STUN request before it reaches the targeted host. If one utilizes a secure channel for the RTSP messages a potential attacker can't eavesdrop the RTSP messages carrying the STUN username and password. However an eavesdropper of the STUN request can still learn them. There exist possibility to also fend off such attacks, by using HMAC  in the STUN request and send the shared secret in the protected RTSP messages. However this risk is considered small and the client can also refuse to answer STUN requests if these requests arrive undesirably frequent, which may be a sign that someone is trying to break the hash algorithm in the HMAC code. The simplest usage scenario of ICE will result in that the RTSP server utilize a few well known ports for sending media and having its STUN server available on. The solution does not force this usage onto the server, as sender ports can be created dynamically at the time of RTSP DESCRIBE request. However the amount of resources needed to maintain this usage will be significantly larger then for using a few well-known ports. The usage of well-known ports will simplify certain types of attacks on the server, like overload attacks using STUN. 5.3. Symmetric RTP 5.3.1. Introduction Symmetric RTP is a NAT traversal solution that is based on requiring NATed clients to send UDP packets to the server’s media send ports. In core RTSP, usage of RTP over UDP is uni-directional, where the server sends RTP packets to client’s RTP port. Symmetric RTP is similar to connection-oriented traffic, where one side (e.g., the RTSP client) first "connects" by sending a RTP packet to the other side’s RTP port, the recipient then replies to the originating IP and port. Specifically, when the RTSP server receives the "connect" RTP packet from its client, it copies the source IP and Port number and uses them as delivery address for media packets. By having the server send media traffic back the same way as the client's packet are sent to the server, address mappings will be honored. Therefore this technique has the advantage of working for all types of NATs. However, it does require server modifications. Symmetric RTP is somewhat more vulnerable to hijacking attacks, which will be explained in more details in the section discussing security concerns. 5.3.2. Necessary RTSP extensions To support symmetric RTP the RTSP signaling must be extended to allow the RTSP client to indicate that it will use symmetric RTP. The client also needs to be able to signal its RTP SSRC to the server in its SETUP request. The RTP SSRC is used to establish some basic level of security against hijacking attacks. Care must be taken in choosing client’s RTP SSRC. First, it must be unique within all the RTP sessions belonging to the same RTSP session. Secondly, if the RTSP server is sending out media packets to multiple clients from the same send port, the RTP SSRC needs to be unique amongst those clients’ RTP sessions. Recognizing that there is a potential that RTP SSRC collision may occur, the RTSP server must be able to signal to client that a collision has occurred and that it wants the client to use a different RTP SSRC carried in the SETUP response. 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 this parameter ("sym_rtp") in the response. The parameter is defined in ABNF  as: symm-usage = "sym_rtp" "=" "1" Which follows the definition in  for transport parameter extensions. It is also necessary to define a "Transport" header parameter, "client_ssrc", to carry the SSRC that the client will use. In RTP, SSRC parameter is only valid for uni-cast transmission. It identifies the synchronization source to be associated with the media stream, and is expressed as an eight-digit hexadecimal value. In cases where a client will use multiple SSRCs it SHOULD NOT use this parameter. The parameter is defined in ABNF  as: client_ssrc_def = "client_ssrc" "=" ssrc Where "ssrc" is defined in . Further, a RTSP options tag that can be used to indicate support of symmetric RTP according to this specification is defined below: nat.sym-rtp This tag SHALL be included in the supported header by both clients and servers supporting symmetric RTP according to this specification. 5.3.3. Using Symmetric RTP in RTSP The server and client uses Symmetric RTP in the following way: 1. The client can optionally determine through the use of STUN that it is located behind a NAT. If the client uses STUN it should also determine the timeout 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 the knowledge about the NAT type and the necessary support from the server. If there is no NAT the client SHOULD NOT use symmetric RTP due to the higher risk of session hijacking. 4. The client sends a SETUP request which has the parameter "sym_rtp=1" in the transport line. 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, unless in SETUP response the server over-ride "client_ssrc", in which case the client must use the server assigned SSRC. The SSRC MUST be generated 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 chooses the transport specification that it will use to transport the media. When this transport specification is the one declaring the use of symmetric RTP the server performs the following: - The server MUST include the transport parameters "sym_rtp=1", and "src_dest" in the response. - The server MUST both send and receive data on the indicated ports. - The server SHALL ignore any of the transport header parameters "destination", and client_port. - If the server is using the same UDP send port to send media packets to multiple RTSP clients, it must also check for client RTP SSRC collisions. If in a SETUP request, the "client_ssrc" is already in use, the server must assign a different SSRC that is unique, and signal it in SETUP response. 6. The Server starts listening on the declared server ports for RTP/UDP packets containing valid client SSRCs. Any received RTP/UDP packet not containing a valid client SSRC SHOULD be ignored. When a RTP/UDP packet containing valid client SSRC is received, the server looks up the id of the client media session using the unique client SSRC, stores the source IP and Port as being the destination address and port for that media session (i.e., RTP session). It performs the corresponding actions for the RTCP port to establish the destination of the RTCP transmissions as well. 7. The client establishes the address bindingsetup delay with at least the server by sending RTP or RTCP to the servers declared media address and port from the port it desires to receive RTP/RTCP on. For the RTP channel it sends a RTP/UDP packet containing the client SSRC. 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 receptionamount of a "binding packet" 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 SSRCtime it takes the server SHALL respond with a single packet. For RTCP the client starts transmitting RTCP packets accordingto the normal RTCP timing rules. Theperform its STUN requests. - Assumes that it is possible to de-multiplex between media packets and STUN packets. - Has fairly high implementation burden for both server SHALL also send RTCP as soonand client. Exactly implantation complexity needs to be assessed once ICE is fully defined as it receivesa RTCP packet creating the binding. 9. To ensurestandard. Currently ICE is still a protocol under development. 6.3. Symmetric RTP 6.3.1. Introduction Symmetric RTP is a NAT traversal solution that theis based on requiring NATed clients bindingto send UDP packets are not lostto the client SHOULD retransmitserverÆs media send ports. In core RTSP, usage of RTP over UDP is uni-directional, where the bindingserver sends RTP packet every 250 ms until it receives a response with an emptypackets to clientÆs RTP port. Symmetric RTP packet or it has retransmitted 20 times. For RTCP itis enough to transmit RTCP packet accordingsimilar to connection-oriented traffic, where one side (e.g., the normal rules. HoweverRTSP client) first "connects" by sending a client MAY send one RTCPRTP packet every 500 ms until it receives an answer, or it has tried for 10 seconds. 10. Whento the client has received answers for bothother sideÆs RTP and RTCP it can safely progressport, the sessionrecipient then replies to the originating IP and send a PLAY request. 11. To ensure thatport. Specifically, when the binding is not lostRTSP server receives the client SHOULD send a empty RTP/UDP"connect" RTP packet with PT=0 to the server every tenth offrom its client, it copies the mapping timeout time that has discoveredsource IP and Port number and uses them as delivery address for media packets. By having the NAT. The discovery can be performed by using STUN. The client SHOULD NOTserver send these packets as longmedia traffic back the same way as the server transmit RTP packetsclient's packet are sent to the client. Unless the NATserver, address mappings will be honored. Therefore this technique has very short timeouts orthe RTCP bandwidthadvantage of working for all types of NATs. However, it does require server modifications. Symmetric RTP is severely restrictedsomewhat more vulnerable to hijacking attacks, which will be explained in more details in the RTCP traffic should automatically keep its connection open. 5.3.4. Open Issues The proposal forsection discussing security concerns. 6.3.2. Necessary RTSP extensions To support symmetric RTP contains some open issuesthe RTSP signaling must be extended to allow the RTSP client to indicate that it will use symmetric RTP. The client also needs to be addressed. - Should it be allowedable to change a binding once it has been established? Probably not as it would be security weakness, however this resultsignal its RTP SSRC to the server in that RTSPits SETUP must berequest. The RTP SSRC is used to update the server destination once a binding has been lost and restored. - Whatestablish some basic level of security against hijacking attacks. Care must be taken in choosing clientÆs RTP payload type(s) shall the client use. ShouldSSRC. First, it use one ofmust be unique within all the types thatRTP sessions belonging to the same RTSP session. Secondly, if the RTSP server has declaredis goingsending out media packets to use inmultiple clients from the same send port, the RTP SSRC needs to be unique amongst those clientsÆ RTP sessions. Recognizing that there is a potential that RTP SSRC collision may occur, the RTSP server ->must be able to signal to client direction orthat a static one? - Shouldcollision has occurred and that it wants the security be improved by havingclient to use a different RTP challenge that can contain longer random identifiers? If that isSSRC carried in the case it should have a static payload type asSETUP response. Details of the client can't establish dynamic payload type declarations. 5.3.5.RTSP extension are beyond the scope of this draft and will be defined in a TBD RTSP extension draft. 6.3.3. Deployment Considerations Advantages: - 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. - Still requires STUN to discover the timeout of NAT bindings. Transition: The usage of symmetric RTP can be phased out as long as the client has a way of detecting that it does not need it any more. Possible ways of detecting this is the use of STUN as proposed in the optional first step. Another way is that it simply is replaced with something better. 126.96.36.199.3.4. Security Consideration Symmetric RTP's major security issue is that RTP streams can be hijacked and directed towards any target that the attacker desires. The method has also no protection if client desires to initiate media streams to a target it desiresto do a DOS attack on.launch DDOS attacks. The most serious security problem is the deliberate attack with the use of a RTSP client and symmetric RTP. The attacker uses RTSP to setup a media session. Then it uses symmetric RTP with a spoofed source address of the intended target of the attack. There is no defense against this attack other than restricting the possible bind address to be the same as the RTSP connection arrived on. This prevents symmetric RTP to be used with multi-address NATs. The hijack attack can be performed in various ways. The basic attack is based on the ability to read the RTSP signaling packets in order to 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 modify the RTP binding packet being sent to the server by simply changing the source IP to the target one desires to attack. One can protect oneself against the first attack by applying encryption to the RTSP signaling transport. However, the second variation is impossible to defend against. As a NAT re-writes the source IP and port this cannot be authenticated, which is required in order to protect against this type of DOS attack. The random SSRC tag in the binding packet determines how well symmetric RTP can fend off streaming hijacking performed by parties that are not "men-in-the-middle". 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 should not be possible by knowing the algorithm used and a couple of basic facts, to derive what random number a certain client will use. An attacker not knowing the SSRC but aware of 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 finds a matching one. Therefore a server SHOULD implement functionality that blocks ports that receive multiple binding packets with different invalid SSRCs, especially when they are coming from the same IP/Port. To improve the security against attackers the random tags length could be increased. To achieve a longer random tag while still using RTP and RTCP, it will be necessary to develop RTP and RTCP payload formats for carrying the random tag. 188.8.131.52. Application Level Gateways 184.108.40.206.4.1. Introduction An Application Level Gateway (ALG) reads the application level messages and performs necessary changes to allow the protocol to work through the middle box. However this behavior has some problems in regards to RTSP: 1. It does not work when the RTSP 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. ALGs need 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, since it is very hard to upgrade NAT’sNATÆs deployed in home or SOHO (small office/home office) environment. 220.127.116.11.4.2. Guidelines On Writing ALGs for RTSP In this section, we provide a step-by-step guideline on how one should go about writing an ALG to enable RTSP to traverse a NAT. 1. Detect any SETUP request. 2. Try to detect the usage of any of the NAT traversal methods that replace the address and port of the Transport header parameters "destination" or "dest_addr". If any of these methods are used, the ALG SHOULD NOT change the address. Ways to detect that these methods are used are: - For embedded STUN, watch for the feature tag "nat.stun". If any of those exists in the "supported", "proxy-require", or "require" headers of the RTSP exchange. - For non-embedded STUN and TURN based solutions: This can in some case be detected by inspecting the "destination" or "dest_addr" parameter. If it contains either one of the NAT's external IP addresses or a public IP address. However if multiple NATs are used this detection may fail. Otherwise continue to the next step. 3. Create UDP mappings (client given IP/port <-> external 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 SETUP 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. 5. If SETUP response settles on RTP over TCP or RTP over RTSP as lower transport, do nothing: let TCP tunneling to take care of NAT traversal. Otherwise go to next step. 6. 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 timeout interval, or UDP messages are sent on any of the UDP mappings during the last timeout interval. 7. The ALG MAY remove a mapping as soon a TEARDOWN response has been received for that media stream. 18.104.22.168.4.3. Deployment Considerations Advantage: - No impact on either client or server - Can work for any type of NATs Disadvantage: - When deployed they are hard to update to reflect protocol modifications and extensions. If not updated they will break the functionality. - When end-to-end security is used the ALG functionality will fail. - Can interfere with other type of traversal mechanisms, such as STUN. Transition: An RTSP ALG will not be phased out in any automatically way. It must be removed, probably through the removal of the NAT it is associated with. 22.214.171.124.4.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. 126.96.36.199. TCP Tunneling 188.8.131.52.5.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 originally intended to be transported over UDP 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, delay introduced by retransmissions, highly varying congestion control. 184.108.40.206.5.2. Usage of TCP tunneling in RTSP The RTSP core specification  supports interleaving of media data on the TCP connection that carries RTSP signaling. See section 10.13 in  for how to perform this type of TCP tunneling. There is currently new 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 in lieu of UDP, see . Another draft describes how to frame RTP over the TCP connection is described in . 220.127.116.11.5.3. Deployment Considerations Advantage: - Works through all types of NATs.NATs where server is in the open. Disadvantage: - Functionality needs to be implemented on both server and client. - MayWill not givealways meet multimedia streamÆs real-time performance.requirements. Transition: The tunneling over RTSP's TCP connection is not planned to be phased -out. It is intended to be a fallback mechanism and for usage when total media reliability is desired, even at the price of loss of real-time properties. 18.104.22.168.5.4. Security Considerations The TCP tunneling of RTP has no known security problem besides those 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. A possible security considerationconsideration, when session media data is interleaved with RTSP, would be the performance bottleneck when RTSP encryption is applied, since all session media data also needs to be encrypted. 22.214.171.124. TURN (Traversal Using Relay NAT) 126.96.36.199.6.1. Introduction Traversal Using Relay NAT (TURN)  is a protocol for setting up traffic relays that allows clients behind NATs and firewalls to receive incoming traffic for both UDP and TCP. These relays are controlled and have limited resources. They need to be allocated before usage. TURN allows a client to temporarily bind an address/port pair on the relay (TURN server) to its local source address/port pair, which is used to contact the TURN server. The TURN server will then forward packets between the two sides of the relay. To prevent DOS attacks on either recipient, the packets forwarded are restricted to the specific source address. On the client side it is restricted to the source setting up the mapping. On the external side this is limited to the source address/port pair of the first packet arriving on the binding. After the first packet has arrived the mapping is "locked down" to that address. Packets from any other source on this address will be discarded. Using a TURN server makes it possible for a RTSP client to receive media streams from even an unmodified RTSP server. However the problem is that RTSP server may restrict that destinations other than the IP address that the RTSP message arrives from shall not be accepted. This means that TURN could only be used if the server knows and accepts that the IP belongs to a TURN server and the TURN server can't be targeted at an unknown address. Unfortunately TURN servers can be targeted at any host that has a public IP address by spoofing the source IP of TURN Allocation requests. 188.8.131.52.6.2. Usage of TURN with RTSP To use a TURN server for NAT traversal, the following steps should be performed. 1. The RTSP client connects with RTSP server. The client retrieves the session description to determine the number of media streams. 2. The client establishes the necessary bindings on the TURN server. It must choose the local RTP and RTCP ports that it desires to receive media packets. TURN supports requesting bindings of even port numbers and continuous ranges. 3. The RTSP client uses the acquired address and port mappings in the RTSP SETUP request using the destination header. Note that the server is required to have a mechanism to verify that it is allowed to send media traffic to the given address. The server SHOULD include its RTP SSRC in the SETUP response. 4. Client requests that the Server starts playing. The server starts sending media packet to the given destination address and ports. 5. The first media packet to arrive at the TURN server on the external port causes "lock down"; then TURN server forwards the media packets to the RTSP client. 6. When media arrives at the client, the client should try to verify that the media packets are from the correct RTSP server, by matching the RTP SSRC of the packet. Source IP address of this packet will be that of the TURN server and can therefore not be used to verify that the correct source has caused lock down. 7. If the client notices that some other source has caused lock down on the TURN server, the client should create new bindings and change the session transport parameters to reflect the new bindings. 8. If the client pauses and media are not sent for about 75% of the mapping timeout the client should use TURN to refresh the bindings. 184.108.40.206.6.3. Deployment Considerations Advantages: - Does not require any server modifications. - Works for any types of NAT as long as the server has public reachable IP address. Disadvantage - TURN is not yet a standard. - Requires another network element, namely the TURN server. - Such a TURN server for RTSP is not scalable since the number of sessions it must forward is proportional to the number of client media sessions. - TURN server becomes a single point of failure. - Since TURN forwards media packets, it necessarily introduces delay. - Requires that the server can verify that the given destination address is valid to be used by the client. - An RTSP ALG MAY change the necessary destinations parameter. This will cause the media traffic to be sent to the wrong address. Transition: TURN is not intended to be phase-out completely, see chapter 11.2 of . However the usage of TURN could be reduced when the demand for having NAT traversal is reduced. 220.127.116.11.6.4. Security Considerations An eavesdropper of RTSP messages between the RTSP client and RTSP server will be able to do a simple denial of service attack on the media streams by sending messages to the destination address and port present in the RTSP SETUP messages. If the attackersattackerÆs message can reach the TURN server before the RTSP server's message, the lock down can be accomplished towards some other address. This will result in that the TURN server will drop all the media server's packets when they arrive. This can be accomplished with little risk for the attacker of being caught, as it can be performed with a spoofed source IP. The client may detect this attack when it receives the lock down packet sent by the attacker as being mal-formatted and not corresponding to the expected context. It will also notice the lack of incoming packets. See bullet 7 in section 18.104.22.168.6.2. The TURN server can also become part of a denial of service attack towards any victim. To perform this attack the attacker must be able to eavesdrop on the packets from the TURN server towards a target for the DOS attack. The attacker uses the TURN server to setup a RTSP session with media flows going through the TURN server. The attacker is in fact creating TURN mappings towards a target by spoofing the source address of TURN requests. As the attacker will need the address of these mappings he must be able to eavesdrop or intercept the TURN responses going from the TURN server to the target. Having these addresses, he can set up a RTSP session and starts delivery of the media. The attacker must be able to create these mappings. The attacker in this case may be traced by the TURN username in the mapping requests. The first attack can be made very hard by applying transport security for the RTSP messages, which will hide the TURN servers address and port numbers from any eavesdropper. The second attack requires that the attacker have access to a user account on the TURN server to be able set up the TURN mappings. To prevent this attack the server shall verify that the target destination accept this media stream. 6.7. Firewalls Firewalls exist for the purpose of protecting 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 firewall friendly in that it should be easy to design firewall policies to permit passage of RTSP traffic and its media streams. 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. Commonly there 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 the least necessary. The opening in the firewall can be closed after a teardown message for that session or the session itself times out. Simpler firewalls do allow a client to receive media as long as it has sent packets to the target. Depending on the security level this can have the same behavior as a full cone NAT or a Symmetric NAT. The only difference is that no address translation is done. To be able to use such a firewall a client would need to implement one of the above described NAT traversal methods that includesinclude sending packets to the server to open up the mappings. 7.8. Open Issues The below list the currentSome open issues with this draft: - The lost mappings text needs better text. - Their isAt some point we need to decide onrecommend one of the server modifying schemes andRTSP NAT solution so as to ensure that a stable specification of that method exist.implementations can inter-operate. This decision processwill require that requirements, security and desired goals are evaluated against implementation cost and the probability to get itthe final solution deployed. - The ALG recommendations needsneed to be improved and clearer.clarified. - The firewall RTSP ALG recommendations need to be written as they are different from the NAT ALG in some perspectives. 8.9. Security Consideration In preceding sessions we have discussed security merits of each and every NAT/FW traversal methods for RTSP. In summary, 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 these has security implications. Using STUN will provide the same level of security as RTSP with out transport level security and source authentications,authentications; as long as the server dodoes not grant a client request to send media to different IP addresses. Using 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 as sole mechanism for RTSP NAT traversal will prevent deployment of encrypted end-to- end RTSP signaling. 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. The usage of TURN has high risk of denial of service attacks against a client. The TURN server can also be used as a redirect point in a DDOS attack unless the server has strict enough rules for who may create bindings. 9.10. IANA Consideration This specification would like to register 2 new Transport header parameters "sym_rtp" and "client_ssrc" as defined in section 5.3.2. Itdoes also register one more RTSP feature tag "nat.sym-rtp" as defined in section 5.3.2. 10.not define any protocol extensions hence no IANA action is requested. 11. 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 no special order to this protocol are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon, Amir Wolf, Anders Klemets, and Colin Perkins. Thomas Zeng would also like to give special thanks to Greg Sherwood of PacketVideo for his input into this protocol. 11.memo. 12. 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 Thomas Zeng Tel: 1-858-731-54651-858-320-3125 PacketVideo Corp.Network Solutions Email: email@example.com 10350 Science Center Dr.firstname.lastname@example.org 9605 Scranton Rd., Suite 400 San Diego, CA92121 12.13. References 22.214.171.124. Normative references  H. Schulzrinne, et. al., "Real Time Streaming Protocol (RTSP)", IETF RFC 2326, April 1998.  M. Handley, V. Jacobson, "Session Description Protocol (SDP)", IETF RFC 2327, April 1998.  D. Crocker and P. Overell, "Augmented BNF for syntax specifica- tions: ABNF," RFC 2234, Internet Engineering Task Force, Nov. 1997.  S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.  H. Schulzrinne, et. al., "RTP: A Transport Protocol for Real- Time Applications", IETF RFC 1889, January 1996.  J. Rosenberg, et. Al., " STUN - Simple Traversal of UDP Through Network Address Translators", IETF RFC 3489, March 2003  H. Schulzrinne, et. al., "Real Time Streaming Protocol (RTSP)", draft-ietf-mmusic-rfc2326bis-04.txt, IETF draft, June 2003, work in progress.  J. Rosenberg, et. Al., "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom-turn-01.txt, IETF draft, March 2003, work in progress.  J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for the Session Initiation Protocol (SIP)," draft-rosenberg-sipping- ice-00, IETF draft, February 2003, work in progress.  G. Camarillo, et. al., "Grouping of Media Lines in the Session Description Protocol (SDP)," IETF RFC 3388, December 2002.  G. Camarillo, J. Rosenberg, " The Alternative Semantics for the Session Description Protocol Grouping Framework," draft- camarillo-mmusic-alt-01.txt, IETF draft, June 2002, work in progress. 126.96.36.199. Informative References  P. Srisuresh, K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)," RFC 3022, Internet Engineering Task Force, January 2001.  Tsirtsis, G. and Srisuresh, P., "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, Internet Engineering Task Force, February 2000.  S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, Internet Engineering Task Force, December 1998.  J. Postel, "internet protocol", RFC 791, Internet Engineering Task Force, September 1981.  D. Yon, "Connection-Oriented Media Transport in SDP", IETF draft, draft-ietf-mmusic-sdp-comedia-04.txt, July 2002.  John Lazzaro, "Framing RTP and RTCP Packets over Connection- Oriented Transport", IETF Draft, draft-lazzaro-avt-rtp-framing- contrans-00.txt, January 2003.  D. Daigle, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, Internet Engineering Task Force, Nov. 2002  R. Finlayason, "IP Multicast and Firewalls", RFC 2588, Internet Engineering Task Force, May 1999  Krawczyk, H., Bellare, M., and Canetti, R.: "HMAC: Keyed-hashing for message authentication". IETF RFC 2104, February 1997  Open Source STUN Server and Client, http://www.vovida.org/applications/downloads/stun/index.html 13. Zeng, T.M.: ôMapping ICE (Interactive Connectivity Establishment) to RTSPö, IETF draft, draft-zeng-mmusic-map-ice- rtsp-00.txt, Feb 2004 14. 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. 14.15. Copyright Notice Copyright (C) The Internet Society (2003).(2004). 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 December 2003.August 2004.