idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-evaluation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1649. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1655. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 29, 2007) is 6118 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-06 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-03 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-16 == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-15 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 4091 (Obsoleted by RFC 5245) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Westerlund 2 Internet-Draft Ericsson 3 Intended status: Informational T. Zeng 4 Expires: December 31, 2007 June 29, 2007 6 The evaluation of different NAT traversal Techniques for media 7 controlled by Real-time Streaming Protocol (RTSP) 8 draft-ietf-mmusic-rtsp-nat-evaluation-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 31, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes several NAT traversal techniques that could 42 be used by RTSP. Each technique includes a description on how it 43 would be used, the security implications of using it and any other 44 deployment considerations it has. There are also disussions on how 45 NAT traversal techniques relates to firewalls and how each technique 46 can be applied in different use cases. These findings where used 47 when selecting the NAT traversal for RTSP solution to standardize in 48 the MMUSIC WG. 50 Requirements Language 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119]. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Network Address Translators . . . . . . . . . . . . . . . 5 60 1.2. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2. Detecting the loss of NAT mappings . . . . . . . . . . . . . . 7 63 3. Requirements on NAT-Traversal . . . . . . . . . . . . . . . . 8 64 4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . . 9 65 4.1. STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 10 67 4.1.2. Using STUN to traverse NAT without server 68 modifications . . . . . . . . . . . . . . . . . . . . 10 69 4.1.3. Embedding STUN in RTSP . . . . . . . . . . . . . . . . 12 70 4.1.4. Discussion On Co-located STUN Server . . . . . . . . . 13 71 4.1.5. ALG considerations . . . . . . . . . . . . . . . . . . 13 72 4.1.6. Deployment Considerations . . . . . . . . . . . . . . 14 73 4.1.7. Security Considerations . . . . . . . . . . . . . . . 16 74 4.2. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 16 76 4.2.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 17 77 4.2.3. Implementation burden of ICE . . . . . . . . . . . . . 19 78 4.2.4. Deployment Considerations . . . . . . . . . . . . . . 19 79 4.2.5. Security Consideration . . . . . . . . . . . . . . . . 20 80 4.3. Symmetric RTP . . . . . . . . . . . . . . . . . . . . . . 20 81 4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 20 82 4.3.2. Necessary RTSP extensions . . . . . . . . . . . . . . 21 83 4.3.3. Deployment Considerations . . . . . . . . . . . . . . 21 84 4.3.4. Security Consideration . . . . . . . . . . . . . . . . 21 85 4.3.5. A Variation to Symmetric RTP . . . . . . . . . . . . . 23 86 4.4. Application Level Gateways . . . . . . . . . . . . . . . . 24 87 4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 24 88 4.4.2. Outline On how ALGs for RTSP work . . . . . . . . . . 25 89 4.4.3. Deployment Considerations . . . . . . . . . . . . . . 26 90 4.4.4. Security Considerations . . . . . . . . . . . . . . . 26 91 4.5. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 26 92 4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . . 26 93 4.5.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . . 27 94 4.5.3. Deployment Considerations . . . . . . . . . . . . . . 27 95 4.5.4. Security Considerations . . . . . . . . . . . . . . . 27 96 4.6. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . . 28 97 4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 28 98 4.6.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 28 99 4.6.3. Deployment Considerations . . . . . . . . . . . . . . 29 100 4.6.4. Security Considerations . . . . . . . . . . . . . . . 30 101 5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 31 102 6. Comparision of NAT traversal techniques . . . . . . . . . . . 31 103 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 106 10. Informative References . . . . . . . . . . . . . . . . . . . . 33 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 108 Intellectual Property and Copyright Statements . . . . . . . . . . 36 110 1. Introduction 112 Today there is a proliferate deployment of different flavors of 113 Network Address Translator (NAT) boxes that in many cases only 114 loosely follows standards[RFC3022][RFC2663][RFC3424]]. NATs cause 115 discontinuity in address realms [RFC3424], therefore an application 116 protocol, such as RTSP, needs to deal with such discontinuities 117 caused by NATs. The problem is that, being a media control protocol 118 managing one or more media streams, RTSP carries network address and 119 port information within its protocol messages. Because of this, even 120 if RTSP itself, when carried over TCP for example, may not be blocked 121 by NATs, its media streams may be blocked by NATs. This will occur 122 unless special protocol provisions are added to support NAT- 123 traversal. 125 Like NATs, firewalls (FWs) are also middle boxes that need to be 126 considered. to prevent unwanted traffic from getting in or out of the 127 protected network. RTSP is designed such that a firewall can be 128 configured to let RTSP controlled media streams to go through with 129 minimal implementation effort. The minimal effort is to implement an 130 ALG (Application Level Gateway) to interpret RTSP parameters. There 131 is also a large class of firewalls, commonly home FWs, that uses a 132 similar filtering behavior to what NAT has. This type of firewalls 133 can be handled using the same solution as employed for NAT traversal 134 instead of relying on ALGs. 136 This document describes several NAT-traversal mechanisms for RTSP 137 controlled media streaming. These NAT solutions fall into the 138 category of ""UNilateral Self-Address Fixing (UNSAF)" as defined in 139 [RFC3424] and quoted below: 141 "UNSAF is a process whereby some originating process attempts to 142 determine or fix the address (and port) by which it is known - e.g. 143 to be able to use address data in the protocol exchange, or to 144 advertise a public address from which it will receive connections." 146 Following the guidelines spelled out in RFC 3424, we describe the 147 required RTSP protocol extensions for each method, transition 148 strategies, and security concerns. 150 This document is capturing the evaluation done in the process to 151 recommend FW/NAT traversal methods for RTSP streaming servers based 152 on RFC 2326 [RFC2326] as well as the RTSP 2.0 core spec 153 [I-D.ietf-mmusic-rfc2326bis]. 155 1.1. Network Address Translators 157 Readers are urged to refer to [RFC2663] for information on NAT 158 taxonomy and terminology. Traditional NAT is the most common type of 159 NAT device deployed. Readers may refer to [RFC3022] for detailed 160 information on traditional NAT. Traditional NAT has two main 161 varieties -- Basic NAT and Network Address/Port Translator (NAPT). 163 NAPT is by far the most commonly deployed NAT device. NAPT allows 164 multiple internal hosts to share a single public IP address 165 simultaneously. When an internal host opens an outgoing TCP or UDP 166 session through a NAPT, the NAPT assigns the session a public IP 167 address and port number, so that subsequent response packets from the 168 external endpoint can be received by the NAPT, translated, and 169 forwarded to the internal host. The effect is that the NAPT 170 establishes a NAT session to translate the (private IP address, 171 private port number) tuple to a (public IP address, public port 172 number) tuple, and vice versa, for the duration of the session. An 173 issue of relevance to peer-to-peer applications is how the NAT 174 behaves when an internal host initiates multiple simultaneous 175 sessions from a single (private IP, private port) endpoint to 176 multiple distinct endpoints on the external network. In this 177 specification, the term "NAT" refers to both "Basic NAT" and "Network 178 Address/Port Translator (NAPT)". 180 This document uses the term "address and port mapping" as the 181 translation between an external address and port and an internal 182 address and port. Note that this is not the same as an "address 183 binding" as defined in RFC 2663. There exist a number of address and 184 port mapping behaviors described in more detail in Section 4.1 of 185 [RFC4787]. 187 NATs also have a filtering behavior on traffic arriving on the 188 external side. Such behavior effects how well different methods for 189 NAT traversal works through these NATs. See Section 5 of [RFC4787] 190 for more information on the different types of filtering that have 191 been identified. 193 1.2. Firewalls 195 A firewall (FW) is a security gateway that enforces certain access 196 control policies between two network administrative domains: a 197 private domain (intranet) and a public domain (public Internet). 198 Many organizations use firewalls to prevent privacy intrusions and 199 malicious attacks to corporate computing resources in the private 200 intranet [RFC2588]. 202 A comparison between NAT and FW is given below: 204 1. A firewall must sit between two network administrative domains, 205 while NAT does not have to sit between two domains. In fact, 206 there exist cases when in corporations there are many NAT boxes 207 within the intranet, in which case the NAT boxes sit between 208 subnets. 210 2. NAT does not in itself provide security, although some access 211 control policies can be implemented using address translation 212 schemes. The inherent filtering behaviours are commonly mistaken 213 for real security policies. 215 It should be noted that many NAT devices intended for small office/ 216 home office (SOHO) include both NATs and firewall functionality. 218 In the rest of this memo we use the phrase "NAT traversal" 219 interchangeably with "FW traversal", "NAT/FW traversal" and "NAT/ 220 Firewall traversal". 222 1.3. Glossary 224 ALG: Application Level Gateway, an entity that can be embedded in a 225 NAT or other middlebox to perform the application layer 226 functions required for a particular protocol to traverse the 227 NAT/middlebox. 229 ICE: Interactive Connectivity Establishment, see 230 [I-D.ietf-mmusic-ice]. 232 DNS: Domain Name Service 234 DDOS: Distributed Denial Of Service attacks 236 MID: Media Identifier from Grouping of media lines in SDP, see 237 [RFC3388]. 239 NAT: Network Address Translator, see [RFC3022]. 241 NAPT: Network Address/Port Translator, see [RFC3022]. 243 NAT-PT: Network Address Translator Protocol Translator, see 244 [RFC2766]. 246 RTP: Real-time Transport Protocol, see [RFC3550]. 248 RTSP: Real-Time Streaming Protocol, see [RFC2326] and 249 [I-D.ietf-mmusic-rfc2326bis]. 251 SDP: Session Description Protocol, see [RFC4566]. 253 SSRC: Synchronization source in RTP, see [RFC3550]. 255 2. Detecting the loss of NAT mappings 257 Several NAT traversal techniques in the next chapter make use of the 258 fact that the NAT UDP mapping's external address and port can be 259 discovered. This information is then utilized to traverse the NAT 260 box. However any such information is only good while the mapping is 261 still valid. As the IAB's UNSAF document [RFC3424] points out, the 262 mapping can either timeout or change its properties. It is therefore 263 important for the NAT traversal solutions to handle the loss or 264 change of NAT mappings, according to RFC3424. 266 First, since NATs may also dynamically reclaim or readjust address/ 267 port translations, "keep-alive" and periodic re-polling may be 268 required according to RFC 3424. Secondly, it is possible to detect 269 and recover from the situation where the mapping has been changed or 270 removed. The loss of a mapping can be detected when no traffic 271 arrives for a while. Below we will give some recommendation on how 272 to detect loss of NAT mappings when using RTP/RTCP under RTSP 273 control. 275 A RTP session normally has both RTP and RTCP streams. The loss of a 276 RTP mapping can only be detected when expected traffic does not 277 arrive. If a client does not receive data within a few seconds after 278 having received the "200 OK" response to a PLAY request, there are 279 likely some middleboxes blocking the traffic. However, for a 280 receiver to be more certain to detect the case where no RTP traffic 281 was delivered due to NAT trouble, one should monitor the RTCP Sender 282 reports. The sender report carries a field telling how many packets 283 the server has sent. If that has increased and no RTP packets has 284 arrived for a few seconds it is likely the RTP mapping has been 285 removed. 287 The loss of mapping for RTCP is simpler to detect. RTCP is normally 288 sent periodically in each direction, even during the RTSP ready 289 state. If RTCP packets are missing for several RTCP intervals, the 290 mapping is likely to be lost. Note that if neither RTCP packets nor 291 RTSP messages are received by the RTSP server for a while, the RTSP 292 server has the option to delete the corresponding SSRC and RTSP 293 session ID, because either the client can not get through a middle 294 box NAT/FW, or that the client is mal-functioning. 296 3. Requirements on NAT-Traversal 298 This section considers the set of requirements for the evaulation of 299 RTSP NAT traversal solutions. 301 RTSP is a client-server protocol. Typically services providers 302 deploy RTSP servers in the public address realm. However, there are 303 use cases where the reverse is true: RTSP clients are connecting from 304 public address realm to RTSP servers behind home NATs. This is the 305 case for instance when home surveillance cameras running as RTSP 306 servers intend to stream video to cell phone users in the public 307 address realm through a home NAT. In terms of requirements, the 308 first requirement shoulb be to solve the RTSP NAT traversal problem 309 for RTSP servers deployed in a public network, i.e. no NAT at the 310 server side. 312 The list of feature requirements for RTSP NAT solutions are given 313 below: 315 1. MUST work for all flavors of NATs, including NATs with address 316 and port restricted filtering. 318 2. MUST work for firewalls (subject to pertinent firewall 319 administrative policies), including those with ALGs. 321 3. SHOULD have minimal impact on clients in the open and not dual- 322 hosted. RTSP dual-hosting means that RTSP protocol and the media 323 protocol (e.g. RTP) are implemented on different computers with 324 different IP addresses. 326 * For instance, no extra delay from RTSP connection till arrival 327 of media 329 4. SHOULD be simple to use/implement/administer that people actually 330 turn them on 332 * Otherwise people will resort to TCP tunneling through NATs 334 * Address discovery for NAT traversal should take place behind 335 the scene, if possible 337 5. SHOULD authenticate dual-hosted client transport handler to 338 prevent DDOS attacks. 340 The last requirement addresses the Distributed Denial-Of-Service 341 (DDOS) threat, which relates to NAT traversal as explained below. 343 During NAT traversal, when the RTSP server performs address 344 translation on a client, the result may be that the public IP address 345 of the RTP receiver host is different than the public IP address of 346 the RTSP client host. This posts a DDOS threat that has significant 347 amplification potentials because the RTP media streams in general 348 consist of large number of IP packets. DDOS attacks occur if the 349 attacker fakes the messages in the NAT traversal mechanism to trick 350 the RTSP server into believing that the client's RTP receiver is 351 located in a separate host. For example, user A may use his RTSP 352 client to direct the RTSP server to send video RTP streams to 353 target.example.com in order to degrade the services provided by 354 target.example.com. Note a simple preventative measure is for the 355 RTSP server to disallow the cases where the client's RTP receiver has 356 a different public IP address than that of the RTSP client. However, 357 in some applications (e.g., centralized conferencing), dual-hosted 358 RTSP/RTP clients have valid use cases. The key is how to 359 authenticate the messages exchanged during the NAT traversal process. 360 Message authentication is a big challenge in the current wired and 361 wireless networking environment. It may be necessary in the 362 immediate future to deploy NAT traversal solutions that do not have 363 full message authentication, but provide upgrade path to add 364 authentication features in the future. 366 4. NAT Traversal Techniques 368 There exist a number of potential NAT traversal techniques that can 369 be used to allow RTSP to traverse NATs. They have different features 370 and are applicable to different topologies; their cost is also 371 different. They also vary in security levels. In the following 372 sections, each technique is outlined in details with discussions on 373 the corresponding advantages and disadvantages. 375 This section includes NAT traversal techniques that have not been 376 formally specified anywhere else. The overview section of this 377 document may be the only publicly available specification of some of 378 the NAT traversal techniques. However that is no real barrier 379 against doing an evaluation of the NAT traversal technique. Some 380 other techniques are currently (at the time of writing) in a state of 381 flux due to ongoing standardization work on these techniques, e.g. 382 ICE [I-D.ietf-mmusic-ice], STUN [I-D.ietf-behave-rfc3489bis] and RTP 383 No-Op [I-D.ietf-avt-rtp-no-op]. 385 4.1. STUN 386 4.1.1. Introduction 388 STUN - "Simple Traversal of UDP Through Network Address Translators" 389 [RFC3489][I-D.ietf-behave-rfc3489bis] is a standardized protocol that 390 allows a client to use secure means to discover the presence of a NAT 391 between himself and the STUN server and the type of that NAT. The 392 client then uses the STUN server to discover the address bindings 393 assigned by the NAT. STUN is a client-server protocol. STUN client 394 sends a request to a STUN server and the server returns a response. 395 There are two types of STUN requests - Binding Requests, sent over 396 UDP, and Shared Secret Requests, sent over TLS over TCP. 398 STUN is in the process of being updated by the BEHAVE WG to address 399 issues found during usage. The BEHAVE WG intends to integrate it 400 better with TURN [I-D.ietf-behave-turn]. 402 4.1.2. Using STUN to traverse NAT without server modifications 404 This section describes how a client can use STUN to traverse NATs to 405 RTSP servers without requiring server modifications. Note that this 406 method has limited applicability and requires the server to be 407 available in the external/public address realm in regards to the 408 client located behind a NAT(s). 410 Limitations: 412 o The server must be located in either a public address realm or the 413 next hop external address realm in regards to the client. 415 o The client may only be located behind NATs that performing 416 Endpoint Independent or Address Dependent Mappings. Clients 417 behind NATs that do Address and Port Dependent Mappings cannot use 418 this method. 420 Method: 422 A RTSP client using RTP transport over UDP can use STUN to traverse a 423 NAT(s) in the following way: 425 1. Use STUN to try to discover the type of NAT, and the timeout 426 period for any UDP mapping on the NAT. This is RECOMMENDED to be 427 performed in the background as soon as IP connectivity is 428 established. If this is performed prior to establishing a 429 streaming session the delays in the session establishment will be 430 reduced. If no NAT is detected, normal SETUP SHOULD be used. 432 2. The RTSP client determines the number of UDP ports needed by 433 counting the number of needed media transport protocols sessions 434 in the multi-media presentation. This information is available 435 in the media description protocol, e.g. SDP [RFC4566]. For 436 example, each RTP session will in general require two UDP ports, 437 one for RTP, and one for RTCP. 439 3. For each UDP port required, establish a mapping and discover the 440 public/external IP address and port number with the help of the 441 STUN server. A successful mapping looks like: client's local 442 address/port <-> public address/port. 444 4. Perform the RTSP SETUP for each media. In the transport header 445 the following parameter SHOULD be included with the given values: 446 "dest_addr" [I-D.ietf-mmusic-rfc2326bis] or "destination" + 447 "client_port"[RFC2326] with the public/external IP address and 448 port pair for both RTP and RTCP. To be certain that this works 449 servers must allow a client to setup the RTP stream on any port, 450 not only even ports and with non-continuous port numbers for RTP 451 and RTCP. This requires the new feature provided in the update 452 to RFC2326 [I-D.ietf-mmusic-rfc2326bis]. The server should 453 respond with a transport header containing an "src_addr" or 454 "source parameter" + "server_port" with the RTP and RTCP source 455 IP address and port of the media stream. 457 5. To keep the mappings alive, the client SHOULD periodically send 458 UDP traffic over all mappings needed for the session. For the 459 mapping carrying RTCP traffic the periodic RTCP traffic may be 460 enough. For mappings carrying RTP traffic and for mappings 461 carrying RTCP packets at too low a frequency, keep-alive messages 462 SHOULD be sent. As keep alive messages, one could use the RTP 463 No-Op packet [I-D.ietf-avt-rtp-no-op] to the streaming server's 464 discard port (port number 9). The drawback of using RTP No-Op is 465 that the payload type number must be dynamically assigned through 466 RTSP first. Otherwise STUN could be used for the keep-alive as 467 well as empty UDP packets. 469 If a UDP mapping is lost, the above discovery process must be 470 repeated. The media stream also needs to be SETUP again to change 471 the transport parameters to the new ones. This will cause a glitch 472 in media playback. 474 To allow UDP packets to arrive from the server to a client behind a 475 "Address Dependent" filtering NAT, the client must send the very 476 first UDP packet to punch a hole in the NAT. The client, before 477 sending a RTSP PLAY request, must send a so called FW packet (such as 478 a RTP No-Op packet) on each mapping, to the IP address given as the 479 servers source address. To create minimum problems for the server 480 these UDP packets SHOULD be sent to the server's discard port (port 481 number 9). Since UDP packets are inherently unreliable, to ensure 482 that at least one UDP message passes the NAT, FW packets should be 483 retransmitted a reasonable number of times. 485 For a "Address and Port Dependent" filtering NAT the client must send 486 messages to the exact ports used by the server to send UDP packets 487 before sending a RTSP PLAY request. This makes it possible to use 488 the above described process with the following additional 489 restrictions: for each port mapping, FW packets need to be sent first 490 to the server's source address/port. To minimize potential effects 491 on the server from these messages the following type of FW packets 492 MUST be sent. RTP: an empty or less than 12 bytes UDP packet. RTCP: 493 A correctly formatted RTCP RR or SR message. The above described 494 adaptations for restricted NATs will not work unless the server 495 includes the "src_addr" in the "Transport" header (which is the 496 "source" transport parameter in RFC2326). 498 4.1.3. Embedding STUN in RTSP 500 This section outlines the adaptation and embedding of STUN within 501 RTSP. This enables STUN to be used to traverse any type of NAT, 502 including symmetric NATs. This would require protocol changes which 503 are beyond the scope of this memo. 505 This NAT traversal solution has limitations: 507 1. It does not work if both RTSP client and RTSP server are behind 508 separate NATs. 510 2. The RTSP server may, for security reasons, refuse to send media 511 streams to an IP different from the IP in the client RTSP 512 requests. 514 Therefore, if the client is behind a NAT that has multiple public 515 addresses, and the client's RTSP port and UDP port are mapped to 516 different IP addresses, RTSP SETUP may fail. 518 Deviations from STUN as defined in RFC 3489: 520 1. We allow RTSP applications to have the option to perform STUN 521 "Shared Secret Request" through RTSP, via extension to RTSP; 523 2. We require STUN server to be co-located on RTSP server's media 524 output ports. 526 In order to allow binding discovery without authentication, the STUN 527 server embedded in RTSP application must ignore authentication tag, 528 and the STUN client embedded in RTSP application must use dummy 529 authentication tag. 531 If STUN server is co-located with RTSP server's media output port, an 532 RTSP client using RTP transport over UDP can use STUN to traverse ALL 533 types of NATs. In the case of port and address dependent mapping 534 NATs, the party inside the NAT must initiate UDP traffic. The STUN 535 Bind Request, being a UDP packet itself, can serve as the traffic 536 initiating packet. Subsequently, both the STUN Binding Response 537 packets and the RTP/RTCP packets can traverse the NAT, regardless of 538 whether the RTSP server or the RTSP client is behind NAT. 540 Likewise, if an RTSP server is behind a NAT, then an embedded STUN 541 server must co-locate on the RTSP client's RTCP port. In this case, 542 we assume that the client has some means of establishing TCP 543 connection to the RTSP server behind NAT so as to exchange RTSP 544 messages with the RTSP server. 546 To minimize delay, we require that the RTSP server supporting this 547 option must inform its client the RTP and RTCP ports from where the 548 server intend to send out RTP and RTCP packets, respectively. This 549 can be done by using the "server_port" parameter in RFC2326, and the 550 "src_addr" parameter in [I-D.ietf-mmusic-rfc2326bis]. Both are in 551 the RTSP Transport header. But in general this strategy will require 552 that one first do one SETUP request per media to learn the server 553 ports, then perform the STUN checks, followed by a subsequent SETUP 554 to change the client port and destination address to what was learned 555 during the STUN checks. 557 To be certain that RTCP works correctly the RTSP end-point (server or 558 client) will be required to send and receive RTCP packets from the 559 same port. 561 4.1.4. Discussion On Co-located STUN Server 563 In order to use STUN to traverse "address and port dependent" 564 filtering or mapping NATs the STUN server needs to be co-located with 565 the streaming server media output ports. This creates a de- 566 multiplexing problem: we must be able to differentiate a STUN packet 567 from a media packet. This will be done based on heuristics. A 568 common heuristics is the frist byte in the packet, which works fine 569 between STUN and RTP or RTCP where the first byte happens to be 570 different, but may not work as well with other media transport 571 protocols. 573 4.1.5. ALG considerations 575 If a NAT supports RTSP ALG (Application Level Gateway) and is not 576 aware of the STUN traversal option, service failure may happen, 577 because a client discovers its public IP address and port numbers, 578 and inserts them in its SETUP requests, when the RTSP ALG processes 579 the SETUP request it may change the destination and port number, 580 resulting in unpredictable behavior. In such cases a convenient way 581 should be provided to turn off STUN-based NAT traversal. 583 4.1.6. Deployment Considerations 585 For the non-embedded usage of STUN the following applies: 587 Advantages: 589 o Using STUN does not require RTSP server modifications; it only 590 affects the client implementation. 592 Disadvantages: 594 o Requires a STUN server deployed in the public address space. 596 o Only works with endpoint independent and address dependent 597 mapping. Port and address dependent filtering NATs create some 598 issues. 600 o Does not work with port and address dependent mapping NATs without 601 server modifications. 603 o Will mostly not work if a NAT uses multiple IP addresses, since 604 RTSP server generally requires all media streams to use the same 605 IP as used in the RTSP connection. 607 o Interaction problems exist when a RTSP-aware ALG interferes with 608 the use of STUN for NAT traversal. 610 o Using STUN requires that RTSP servers and clients support the 611 updated RTSP specification, because it is no longer possible to 612 guarantee that RTP and RTCP ports are adjacent to each other, as 613 required by the "client_port" and "server_port" parameters in 614 RFC2326. 616 Transition: 618 The usage of STUN can be phased out gradually as the first step of a 619 STUN capable server or client should be to check the presence of 620 NATs. The removal of STUN capability in the client implementations 621 will have to wait until there is absolutely no need to use STUN. 623 For the "Embedded STUN" method the following applies: 625 Advantages: 627 o STUN is a solution first used by SIP applications. As shown 628 above, with little or no changes, RTSP application can re-use STUN 629 as a NAT traversal solution, avoiding the pit-fall of solving a 630 problem twice. 632 o STUN has built-in message authentication features, which makes it 633 more secure. See next section for an in-depth security 634 discussion. 636 o This solution works as long as there is only one RTSP end point in 637 the private address realm, regardless of the NAT's type. There 638 may even be multiple NATs (see figure 1 in RFC3489). 640 o Compares to other UDP based NAT traversal methods in this 641 document, STUN requires little new protocol development (since 642 STUN is already a IETF standard), and most likely less 643 implementation effort, since open source STUN server and client 644 have become available [STUN-IMPL]. There is the need to embed 645 STUN in RTSP server and client, which require a de-multiplexer 646 between STUN packets and RTP/RTCP packets. There is also a need 647 to register the proper feature tags. 649 Disadvantages: 651 o Some extensions to the RTSP core protocol, signaled by RTSP 652 feature tags, must be introduced. 654 o Requires an embedded STUN server to co-locate on each of RTSP 655 server's media protocol's ports (e.g. RTP and RTCP ports), which 656 means more processing is required to de-multiplex STUN packets 657 from media packets. For example, the de-multiplexer must be able 658 to differentiate a RTCP RR packet from a STUN packet, and forward 659 the former to the streaming server, the later to STUN server. 661 o Even if the RTSP server is in the open, and the client is behind a 662 multi-addressed NAT, it may still break if the RTSP server does 663 not allow RTP packets to be sent to an IP differs from the IP of 664 the client's RTSP request. 666 o Interaction problems exist when a RTSP ALG is not aware of STUN. 668 o Using STUN requires that RTSP servers and clients support the 669 updated RTSP specification, and they both agree to support the 670 proper feature tag. 672 o Increases the setup delay with at least the amount of time it 673 takes to perform STUN message exchanges. Most likely an extra 674 SETUP sequence will be required. 676 Transition: 678 The usage of STUN can be phased out gradually as the first step of a 679 STUN capable machine can be to check the presence of NATs for the 680 presently used network connection. The removal of STUN capability in 681 the client implementations will have to wait until there is 682 absolutely no need to use STUN. 684 4.1.7. Security Considerations 686 To prevent RTSP server being used as Denial of Service (DoS) attack 687 tools the RTSP Transport header parameter "destination" and 688 "dest_addr" are generally not allowed to point to any IP address 689 other than the one that RTSP message originates from. The RTSP 690 server is only prepared to make an exception of this rule when the 691 client is trusted (e.g., through the use of a secure authentication 692 process, or through some secure method of challenging the destination 693 to verify its willingness to accept the RTP traffic). Such 694 restriction means that STUN does not work for NATs that would assign 695 different IP addresses to different UDP flows on its public side. 696 Therefore the multi-addressed NATs will at times have trouble with 697 STUN-based RTSP NAT traversals. 699 In terms of security property, STUN combined with destination address 700 restricted RTSP has the same security properties as the core RTSP. 701 It is protected from being used as a DoS attack tool unless the 702 attacker has ability the to spoof the TCP connection carrying RTSP 703 messages. 705 Using STUN's support for message authentication and secure transport 706 of RTSP messages, attackers cannot modify STUN responses or RTSP 707 messages to change media destination. This protects against 708 hijacking, however as a client can be the initiator of an attack, 709 these mechanisms cannot securely prevent RTSP servers being used as 710 DoS attack tools. 712 4.2. ICE 714 4.2.1. Introduction 716 ICE (Interactive Connectivity Establishment) [I-D.ietf-mmusic-ice] is 717 a methodology for NAT traversal that is under development for SIP 718 using SDP offer/answer. The basic idea is to try, in a parallel 719 fashion, all possible connection addresses that an end point may 720 have. This allows the end-point to use the best available UDP 721 "connection" (meaning two UDP end-points capable of reaching each 722 other). The methodology has very nice properties in that basically 723 all NAT topologies are possible to traverse. 725 Here is how ICE works on a high level. End point A collects all 726 possible address that can be used, including local IP addresses, STUN 727 derived addresses, TURN addresses, etc. On each local port that any 728 of these address and port pairs leads to, a STUN server is installed. 729 This STUN server only accepts STUN requests using the correct 730 authentication through the use of username and password. 732 End-point A then sends a request to establish connectivity with end- 733 point B, which includes all possible destinations to get the media 734 through too A. Note that each of A's published address/port pairs has 735 a STUN server co-located. B, in its turn provides A with all its 736 possible destinations for the different media streams. A and B then 737 uses a STUN client to try to reach all the address and port pairs 738 specified by A from its corresponding destination ports. The 739 destinations for which the STUN requests have successfully completed 740 are then indicated and selected. 742 If B fails to get any STUN response from A, all hope is not lost. 743 Certain NAT topologies require multiple tries from both ends before 744 successful connectivity is accomplished and therefore requests are 745 retransmitted multiple times. The STUN requests may also result in 746 that more connectivity alternatives are discovered and conveyed in 747 the STUN responses. 749 4.2.2. Using ICE in RTSP 751 The usage of ICE for RTSP requires that both client and server be 752 updated to include the ICE functionality. If both parties implement 753 the necessary functionality the following steps could provide ICE 754 support for RTSP. 756 This assumes that it is possible to establish a TCP connection for 757 the RTSP messages between the client and the server. This is not 758 trivial in scenarios where the server is located behind a NAT, and 759 may require some TCP ports been opened, or the deployment of proxies, 760 etc. 762 The negotiation of ICE in RTSP of necessity will work different than 763 in SIP with SDP offer/answer. The protocol interactions are 764 different and thus the possibilities for transfer of states are also 765 somewhat different. The goal is also to avoid introducing extra 766 delay in the setup process at least for when the server is using a 767 public address and the client is either having a public address or is 768 behind NAT(s). This process is only intended to support PLAY mode, 769 i.e. media traffic flows from server to client. 771 1. The ICE usage begins in the SDP. The SDP for the service 772 indicates that ICE is supported at the server. No candidates can 773 be given here as that would not work with the on demand, DNS load 774 balancing, etc., that make a SDP indicate a resource on a server 775 park rather than a specific machine. 777 2. The client gathers addresses and puts together its candidate for 778 each media stream indicated in the session description. 780 3. In each SETUP request the client includes its candidates, 781 promoting one for primary usage. This indicates for the server 782 the ICE support by the client. One candidate is the primary 783 candidate and here the prioritization for this address should be 784 somewhat different compared to SIP. High performance rather than 785 always successful is to recommended as it is most likely to be a 786 server in the public. 788 4. The server responds to the SETUP (200 OK) for each media stream 789 with its candidates. A server with a public address usually only 790 provides a single ICE candidate. Also here one candidate is the 791 server primary address. 793 5. The connectivity checks are performed. For the server the 794 connectivity checks from the server to the clients have an 795 additional usage. They verify that there is someone willingly to 796 receive the media, thus protecting itself from performing 797 unknowingly an DoS attack. 799 6. Connectivity checks from the client's primary to the server's 800 primary was successful. Thus no further SETUP requests are 801 necessary and processing can proceed with step 7. If the checks 802 for the primary failed and If further candidates have been 803 derived during the connectivity checks, then those can be 804 promoted in new candidate lines in SETUP request updating the 805 list (Goto 5). If another address than the primary has been 806 verified by the client to work, that address may then be promoted 807 for usage in a SETUP request (Goto 7). 809 7. Client issues PLAY request. If the server also has completed its 810 connectivity checks for this primary addresses (based on username 811 as it may be derived addresses if the client was behind NAT) then 812 it can directly answer 200 OK (Goto 8). If the connectivity 813 check has not yet completed it responds with a 1xx code to 814 indicate that it is verifying the connectivity. If that fails 815 within the set timeout an error is reported back. Client needs 816 to go back to 6. 818 8. Process completed media can be delivered. ICE testing ports may 819 be released. 821 To keep media paths alive client must likely periodically send data 822 to the server. This could be realized with either STUN or RTP No-op 823 [I-D.ietf-avt-rtp-no-op] packets. RTCP sent by client should be able 824 to keep RTCP open. 826 4.2.3. Implementation burden of ICE 828 The usage of ICE will require that a number of new protocols and new 829 RTSP/SDP features be implemented. This makes ICE the solution that 830 has the largest impact on client and server implementations amongst 831 all the NAT/FW traversal methods in this document. 833 Some RTSP server implementation requirements are: 835 o STUN server features 837 o limited STUN client features 839 o SDP generation with more parameters. 841 o RTSP error code for ICE extension 843 Some client implantation requirements are: 845 o Limited STUN server features 847 o Limited STUN client features 849 o RTSP error code and ICE extension 851 4.2.4. Deployment Considerations 853 Advantages: 855 o Solves NAT connectivity discovery for basically all cases as long 856 as a TCP connection between them can be established. This 857 includes servers behind NATs. (Note that a proxy between address 858 domains may be required to get TCP through). 860 o Improves defenses against DDOS attacks, as media receiving client 861 requires authentications, via STUN on its media reception ports. 863 Disadvantages: 865 Increases the setup delay with at least the amount of time it 866 takes for the server to perform its STUN requests. 868 Assumes that it is possible to de-multiplex between media packets 869 and STUN packets. 871 Has fairly high implementation burden put on both RTSP server and 872 client. The precise implantation complexity needs to be assessed 873 once ICE is fully defined as a standard. Currently ICE is still a 874 protocol under development. 876 4.2.5. Security Consideration 878 One should review the security consideration section of ICE and STUN 879 to understand that ICE is contains some potential issues. However 880 these can be avoided by a correctly utilizing ICE in RTSP. In fact 881 ICE do help avoid the DDoS issue with RTSP substantially as it 882 reduces the possibility for a DDoS using RTSP servers to attackers 883 that are on-path between the RTSP server and the target and capable 884 of intercepting the STUN connectivity check packets and correctly 885 send a response to the server. 887 4.3. Symmetric RTP 889 4.3.1. Introduction 891 Symmetric RTP is a NAT traversal solution that is based on requiring 892 RTSP clients to send UDP packets to the server's media output ports. 893 Conventionally, RTSP servers send RTP packets in one direction: from 894 server to client. Symmetric RTP is similar to connection-oriented 895 traffic, where one side (e.g., the RTSP client) first "connects" by 896 sending a RTP packet to the other side's RTP port, the recipient then 897 replies to the originating IP and port. 899 Specifically, when the RTSP server receives the "connect" RTP packet 900 (a.k.a. FW packet, since it is used to punch a hole in the FW/NAT 901 and to aid the server for port binding and address mapping) from its 902 client, it copies the source IP and Port number and uses them as 903 delivery address for media packets. By having the server send media 904 traffic back the same way as the client's packet are sent to the 905 server, address mappings will be honored. Therefore this technique 906 works for all types of NATs. However, it does require server 907 modifications. Unless there is built-in protection mechanism, 908 symmetric RTP is very vulnerable to DDOS attacks, because attackers 909 can simply forge the source IP & Port of the binding packet. 911 4.3.2. Necessary RTSP extensions 913 To support symmetric RTP the RTSP signaling must be extended to allow 914 the RTSP client to indicate that it will use symmetric RTP. The 915 client also needs to be able to signal its RTP SSRC to the server in 916 its SETUP request. The RTP SSRC is used to establish some basic 917 level of security against hijacking attacks. Care must be taken in 918 choosing client's RTP SSRC. First, it must be unique within all the 919 RTP sessions belonging to the same RTSP session. Secondly, if the 920 RTSP server is sending out media packets to multiple clients from the 921 same send port, the RTP SSRC needs to be unique amongst those 922 clients' RTP sessions. Recognizing that there is a potential that 923 RTP SSRC collision may occur, the RTSP server must be able to signal 924 to client that a collision has occurred and that it wants the client 925 to use a different RTP SSRC carried in the SETUP response or use 926 unique ports per RTSP session. Using unique ports limits an RTSP 927 server in the number of session it can simultaneously handle per 928 interface IP addresses. 930 4.3.3. Deployment Considerations 932 Advantages: 934 o Works for all types of NATs, including those using multiple IP 935 addresses. (Requirement 1 in Section 3). 937 o Have no interaction problems with any RTSP ALG changing the 938 client's information in the transport header. 940 Disadvantages: 942 o Requires modifications to both RTSP server and client. 944 o Limited to work with servers that have an public IP address. 946 o The format of the RTP packet for "connection setup" (a.k.a FW 947 packet) is yet to be defined. One possibility is to use RTP No-Op 948 packet format in [I-D.ietf-avt-rtp-no-op]. 950 o Has worse security situation than STUN when using address 951 restrictions. 953 4.3.4. Security Consideration 955 Symmetric RTP's major security issue is that RTP streams can be 956 hijacked and directed towards any target that the attacker desires. 958 The most serious security problem is the deliberate attack with the 959 use of a RTSP client and symmetric RTP. The attacker uses RTSP to 960 setup a media session. Then it uses symmetric RTP with a spoofed 961 source address of the intended target of the attack. There is no 962 defense against this attack other than restricting the possible bind 963 address to be the same as the RTSP connection arrived on. This 964 prevents symmetric RTP to be used with multi-address NATs. 966 A hijack attack can also be performed in various ways. The basic 967 attack is based on the ability to read the RTSP signaling packets in 968 order to learn the address and port the server will send from and 969 also the SSRC the client will use. Having this information the 970 attacker can send its own NAT-traversal RTP packets containing the 971 correct RTP SSRC to the correct address and port on the server. The 972 destination of the packets is set as the source IP and port in these 973 RTP packets. 975 Another variation of this attack is for a man in the middle to modify 976 the RTP binding packet being sent by a client to the server by simply 977 changing the source IP to the target one desires to attack. 979 One can fend off the first attack by applying encryption to the RTSP 980 signaling transport. However, the second variation is impossible to 981 defend against. As a NAT re-writes the source IP and port this 982 cannot be authenticated, but authentication is required in order to 983 protect against this type of DOS attack. 985 Yet another issues is that these attacks also can be used to deny the 986 client the service he desire from the RTSP server completely. For a 987 man in the middle capable of reading the signalling traffic or 988 intercepting the binding packets can completely deny the client 989 service by modifying or originating binding packets of itself. 991 The random SSRC tag in the binding packet determines how well 992 symmetric RTP can fend off stream-hijacking performed by parties that 993 are not "man-in-the-middle". This proposal uses the 32-bit RTP SSRC 994 field to this effect. Therefore it is important that this field is 995 derived with a non-predictable randomizer. It should not be possible 996 by knowing the algorithm used and a couple of basic facts, to derive 997 what random number a certain client will use. 999 An attacker not knowing the SSRC but aware of which port numbers that 1000 a server sends from can deploy a brute force attack on the server by 1001 testing a lot of different SSRCs until it finds a matching one. 1002 Therefore a server SHOULD implement functionality that blocks ports 1003 that receive multiple FW packets (i.e. the packet that is sent to the 1004 server for FW traversal) with different invalid SSRCs, especially 1005 when they are coming from the same IP/Port. 1007 To improve the security against attackers the random tag's length 1008 could be increased. To achieve a longer random tag while still using 1009 RTP and RTCP, it will be necessary to develop RTP and RTCP payload 1010 formats for carrying the random tag. 1012 4.3.5. A Variation to Symmetric RTP 1014 Symmetric RTP requires a valid RTP format in the FW packet, which is 1015 the first packet that the client sends to the server to set up 1016 virtual RTP connection. There is currently no appropriate RTP packet 1017 format for this purpose, although the No-Op format is a proposal to 1018 fix the problem [I-D.ietf-avt-rtp-no-op]. 1020 Meanwhile, there has been FW traversal techniques deployed in the 1021 wireless streaming market place that use non-RTP messages as FW 1022 packets. This section attempts to summarize a subset of those 1023 solutions that happens to use a variation to the standard symmetric 1024 RTP solution. 1026 In this variation of symmetric RTP, the FW packet is a small UDP 1027 packet that does not contain RTP header. Hence the solution can no 1028 longer be called symmetric RTP, yet it employs the same technique for 1029 FW traversal. In response to client's FW packet, RTSP server sends 1030 back a similar FW packet as a confirmation so that the client can 1031 stop the so called "connection phase" of this NAT traversal 1032 technique. Afterwards, the client only has to periodically send FW 1033 packets as keep-alive messages for the NAT mappings. 1035 The server listens on its RTP-media output port, and tries to decode 1036 any received UDP packet as FW packet. This is valid since an RTSP 1037 server is not expecting RTP traffic from the RTSP client. Then, it 1038 can correlate the FW packet with the RTSP client's session ID or the 1039 client's SSRC, and record the NAT bindings accordingly. The server 1040 then sends a FW packet as the response to the client. 1042 The FW packet can contain the SSRC to identify the RTP stream, and 1043 can be made no bigger than 12 bytes, making it distinctively 1044 different from RTP packets, whose header size is 12 bytes. 1046 RTSP signaling can be added to do the following: 1048 1. Enables or disables such FW message exchanges. When the FW/NAT 1049 has an RTSP-aware ALG, it is better to disable FW message 1050 exchange and let ALG works out the address and port mappings. 1052 2. Configures the number of re-tries and the re-try interval of the 1053 FW message exchanges. 1055 Such FW packets may also contain digital signatures to support three- 1056 way handshake based receiver authentications, so as to prevent DDoS 1057 attacks described before. 1059 This approach has the following advantages when compared with the 1060 symmetric RTP approach: 1062 1. There is no need to define RTP payload format for FW traversal, 1063 therefore it is simple to use, implement and administer 1064 (Requirement 4 in Section 3), although a binding protocol must be 1065 defined. 1067 2. When properly defined, this kind of FW message exchange can also 1068 authenticate RTP receivers, so as to prevent DDoS attacks for 1069 dual-hosted RTSP client. By dual-hosted RTSP client we mean the 1070 kind that uses one "perceived" IP address for RTSP message 1071 exchange, and a different "perceived" IP address for RTP 1072 reception. (Requirement 5 in Section 3). 1074 This approach has the following disadvantages when compared with the 1075 symmetric RTP approach: 1077 1. RTP traffic is normally accompanied by RTCP traffic. This 1078 approach needs to rely on RTCP RRs and SRs to enable NAT 1079 traversal for RTCP endpoints, or use the same type of FW messages 1080 also for RTCP endpoints. 1082 2. The server's sender SSRC for the RTP stream must be signaled in 1083 RTSP's SETUP response, in the Transport header of the RTSP SETUP 1084 response. 1086 4.4. Application Level Gateways 1088 4.4.1. Introduction 1090 An Application Level Gateway (ALG) reads the application level 1091 messages and performs necessary changes to allow the protocol to work 1092 through the middle box. However this behavior has some problems in 1093 regards to RTSP: 1095 1. It does not work when the RTSP protocol is used with end-to-end 1096 security. As the ALG can't inspect and change the application 1097 level messages the protocol will fail due to the middle box. 1099 2. ALGs need to be updated if extensions to the protocol are added. 1100 Due to deployment issues with changing ALGs this may also break 1101 the end-to-end functionality of RTSP. 1103 Due to the above reasons it is NOT RECOMMENDED to use an RTSP ALG in 1104 NATs. This is especially important for NATs targeted to home users 1105 and small office environments, since it is very hard to upgrade NATs 1106 deployed in home or SOHO (small office/home office) environment. 1108 4.4.2. Outline On how ALGs for RTSP work 1110 In this section, we provide a step-by-step outline on how one should 1111 go about writing an ALG to enable RTSP to traverse a NAT. 1113 1. Detect any SETUP request. 1115 2. Try to detect the usage of any of the NAT traversal methods that 1116 replace the address and port of the Transport header parameters 1117 "destination" or "dest_addr". If any of these methods are used, 1118 the ALG SHOULD NOT change the address. Ways to detect that these 1119 methods are used are: 1121 * For embedded STUN, it would be watch for a feature tag, like 1122 "nat.stun". If any of those exists in the "supported", 1123 "proxy-require", or "require" headers of the RTSP exchange. 1125 * For non-embedded STUN and TURN based solutions: This can in 1126 some case be detected by inspecting the "destination" or 1127 "dest_addr" parameter. If it contains either one of the NAT's 1128 external IP addresses or a public IP address. However if 1129 multiple NATs are used this detection may fail. Remapping 1130 should only be done for addresses belonging to the NATs own 1131 private address space. 1133 Otherwise continue to the next step. 1135 3. Create UDP mappings (client given IP/port <-> external IP/port) 1136 where needed for all possible transport specification in the 1137 transport header of the request found in (1). Enter the public 1138 address and port(s) of these mappings in transport header. 1139 Mappings SHALL be created with consecutive public port number 1140 starting on an even number for RTP for each media stream. 1141 Mappings SHOULD also be given a long timeout period, at least 5 1142 minutes. 1144 4. When the SETUP response is received from the server the ALG MAY 1145 remove the unused UDP mappings, i.e. the ones not present in the 1146 transport header. The session ID SHOULD also be bound to the UDP 1147 mappings part of that session. 1149 5. If SETUP response settles on RTP over TCP or RTP over RTSP as 1150 lower transport, do nothing: let TCP tunneling to take care of 1151 NAT traversal. Otherwise go to next step. 1153 6. The ALG SHOULD keep alive the UDP mappings belonging to the an 1154 RTSP session as long as: RTSP messages with the session's ID has 1155 been sent in the last timeout interval, or UDP messages are sent 1156 on any of the UDP mappings during the last timeout interval. 1158 7. The ALG MAY remove a mapping as soon a TEARDOWN response has been 1159 received for that media stream. 1161 4.4.3. Deployment Considerations 1163 Advantage: 1165 o No impact on either client or server 1167 o Can work for any type of NATs 1169 Disadvantage: 1171 o When deployed they are hard to update to reflect protocol 1172 modifications and extensions. If not updated they will break the 1173 functionality. 1175 o When end-to-end security is used the ALG functionality will fail. 1177 o Can interfere with other type of traversal mechanisms, such as 1178 STUN. 1180 Transition: 1182 An RTSP ALG will not be phased out in any automatically way. It must 1183 be removed, probably through the removal of the NAT it is associated 1184 with. 1186 4.4.4. Security Considerations 1188 An ALG will not work when deployment of end-to-end RTSP signaling 1189 security. Therefore deployment of ALG will likely result in that 1190 clients located behind NATs will not use end-to-end security. 1192 4.5. TCP Tunneling 1194 4.5.1. Introduction 1196 Using a TCP connection that is established from the client to the 1197 server ensures that the server can send data to the client. The 1198 connection opened from the private domain ensures that the server can 1199 send data back to the client. To send data originally intended to be 1200 transported over UDP requires the TCP connection to support some type 1201 of framing of the RTP packets. Using TCP also results in that the 1202 client has to accept that real-time performance may no longer be 1203 possible. TCP's problem of ensuring timely deliver was the reasons 1204 why RTP was developed. Problems that arise with TCP are: head-of- 1205 line blocking, delay introduced by retransmissions, highly varying 1206 congestion control. 1208 4.5.2. Usage of TCP tunneling in RTSP 1210 The RTSP core specification [I-D.ietf-mmusic-rfc2326bis] supports 1211 interleaving of media data on the TCP connection that carries RTSP 1212 signaling. See section 10.13 in [I-D.ietf-mmusic-rfc2326bis] for how 1213 to perform this type of TCP tunneling. There is currently new 1214 finished work on one more way of transporting RTP over TCP in AVT and 1215 MMUSIC. For signaling and rules on how to establish the TCP 1216 connection in lieu of UDP, see [RFC4091]. Another draft describes 1217 how to frame RTP over the TCP connection is described in RFC 4571 1218 [RFC4571]. 1220 4.5.3. Deployment Considerations 1222 Advantage: 1224 o Works through all types of NATs where server is in the open. 1226 Disadvantage: 1228 o Functionality needs to be implemented on both server and client. 1230 o Will not always meet multimedia stream's real-time requirements. 1232 Transition: 1234 The tunneling over RTSP's TCP connection is not planned to be phased 1235 -out. It is intended to be a fallback mechanism and for usage when 1236 total media reliability is desired, even at the price of loss of 1237 real-time properties. 1239 4.5.4. Security Considerations 1241 The TCP tunneling of RTP has no known security problem besides those 1242 already presented in the RTSP specification. It is not possible to 1243 get any amplification effect that is desired for denial of service 1244 attacks due to TCP's flow control. A possible security 1245 consideration, when session media data is interleaved with RTSP, 1246 would be the performance bottleneck when RTSP encryption is applied, 1247 since all session media data also needs to be encrypted. 1249 4.6. TURN (Traversal Using Relay NAT) 1251 4.6.1. Introduction 1253 Traversal Using Relay NAT (TURN) [I-D.ietf-behave-turn] is a protocol 1254 for setting up traffic relays that allows clients behind NATs and 1255 firewalls to receive incoming traffic for both UDP and TCP. These 1256 relays are controlled and have limited resources. They need to be 1257 allocated before usage. TURN allows a client to temporarily bind an 1258 address/port pair on the relay (TURN server) to its local source 1259 address/port pair, which is used to contact the TURN server. The 1260 TURN server will then forward packets between the two sides of the 1261 relay. To prevent DOS attacks on either recipient, the packets 1262 forwarded are restricted to the specific source address. On the 1263 client side it is restricted to the source setting up the mapping. 1264 On the external side this is limited to the source address/port pair 1265 of the first packet arriving on the binding. After the first packet 1266 has arrived the mapping is "locked down" to that address. Packets 1267 from any other source on this address will be discarded. Using a 1268 TURN server makes it possible for a RTSP client to receive media 1269 streams from even an unmodified RTSP server. However the problem is 1270 those RTSP servers most likely restrict media destinations to no 1271 other IP address than the one RTSP message arrives. This means that 1272 TURN could only be used if the server knows and accepts that the IP 1273 belongs to a TURN server and the TURN server can't be targeted at an 1274 unknown address. Unfortunately TURN servers can be targeted at any 1275 host that has a public IP address by spoofing the source IP of TURN 1276 Allocation requests. 1278 4.6.2. Usage of TURN with RTSP 1280 To use a TURN server for NAT traversal, the following steps should be 1281 performed. 1283 1. The RTSP client connects with RTSP server. The client retrieves 1284 the session description to determine the number of media streams. 1285 To avoid the issue with having RTSP connection and media traffic 1286 from different addresses also the TCP connection must be done 1287 through the same TURN server as the one in the next step. 1289 2. The client establishes the necessary bindings on the TURN server. 1290 It must choose the local RTP and RTCP ports that it desires to 1291 receive media packets. TURN supports requesting bindings of even 1292 port numbers and continuous ranges. 1294 3. The RTSP client uses the acquired address and port mappings in 1295 the RTSP SETUP request using the destination header. Note that 1296 the server is required to have a mechanism to verify that it is 1297 allowed to send media traffic to the given address. The server 1298 SHOULD include its RTP SSRC in the SETUP response. 1300 4. Client requests that the Server starts playing. The server 1301 starts sending media packet to the given destination address and 1302 ports. 1304 5. The first media packet to arrive at the TURN server on the 1305 external port causes "lock down"; then TURN server forwards the 1306 media packets to the RTSP client. 1308 6. When media arrives at the client, the client should try to verify 1309 that the media packets are from the correct RTSP server, by 1310 matching the RTP SSRC of the packet. Source IP address of this 1311 packet will be that of the TURN server and can therefore not be 1312 used to verify that the correct source has caused lock down. 1314 7. If the client notices that some other source has caused lock down 1315 on the TURN server, the client should create new bindings and 1316 change the session transport parameters to reflect the new 1317 bindings. 1319 8. If the client pauses and media are not sent for about 75% of the 1320 mapping timeout the client should use TURN to refresh the 1321 bindings. 1323 4.6.3. Deployment Considerations 1325 Advantages: 1327 o Does not require any server modifications. 1329 o Works for any types of NAT as long as the server has public 1330 reachable IP address. 1332 Disadvantage: 1334 o Requires another network element, namely the TURN server. 1336 o A TURN server for RTSP is may not scale since the number of 1337 sessions it must forward is proportional to the number of client 1338 media sessions. 1340 o TURN server becomes a single point of failure. 1342 o Since TURN forwards media packets, it necessarily introduces 1343 delay. 1345 o Requires that the server can verify that the given destination 1346 address is valid to be used by the client. 1348 o An RTSP ALG MAY change the necessary destinations parameter. This 1349 will cause the media traffic to be sent to the wrong address. 1351 Transition: 1353 TURN is not intended to be phase-out completely, see chapter 11.2 of 1354 [I-D.ietf-behave-turn]. However the usage of TURN could be reduced 1355 when the demand for having NAT traversal is reduced. 1357 4.6.4. Security Considerations 1359 An eavesdropper of RTSP messages between the RTSP client and RTSP 1360 server will be able to do a simple denial of service attack on the 1361 media streams by sending messages to the destination address and port 1362 present in the RTSP SETUP messages. If the attacker's message can 1363 reach the TURN server before the RTSP server's message, the lock down 1364 can be accomplished towards some other address. This will result in 1365 that the TURN server will drop all the media server's packets when 1366 they arrive. This can be accomplished with little risk for the 1367 attacker of being caught, as it can be performed with a spoofed 1368 source IP. The client may detect this attack when it receives the 1369 lock down packet sent by the attacker as being mal-formatted and not 1370 corresponding to the expected context. It will also notice the lack 1371 of incoming packets. See bullet 7 in Section 4.6.2. 1373 The TURN server can also become part of a denial of service attack 1374 towards any victim. To perform this attack the attacker must be able 1375 to eavesdrop on the packets from the TURN server towards a target for 1376 the DOS attack. The attacker uses the TURN server to setup a RTSP 1377 session with media flows going through the TURN server. The attacker 1378 is in fact creating TURN mappings towards a target by spoofing the 1379 source address of TURN requests. As the attacker will need the 1380 address of these mappings he must be able to eavesdrop or intercept 1381 the TURN responses going from the TURN server to the target. Having 1382 these addresses, he can set up a RTSP session and starts delivery of 1383 the media. The attacker must be able to create these mappings. The 1384 attacker in this case may be traced by the TURN username in the 1385 mapping requests. 1387 The first attack can be made very hard by applying transport security 1388 for the RTSP messages, which will hide the TURN servers address and 1389 port numbers from any eavesdropper. 1391 The second attack requires that the attacker have access to a user 1392 account on the TURN server to be able set up the TURN mappings. To 1393 prevent this attack the server shall verify that the target 1394 destination accept this media stream. 1396 5. Firewalls 1398 Firewalls exist for the purpose of protecting a network from traffic 1399 not desired by the firewall owner. Therefore it is a policy decision 1400 if a firewall will let RTSP and its media streams through or not. 1401 RTSP is designed to be firewall friendly in that it should be easy to 1402 design firewall policies to permit passage of RTSP traffic and its 1403 media streams. 1405 The firewall will need to allow the media streams associated with a 1406 RTSP session pass through it. Therefore the firewall will need an 1407 ALG that reads RTSP SETUP and TEARDOWN messages. By reading the 1408 SETUP message the firewall can determine what type of transport and 1409 from where the media streams will use. Commonly there will be the 1410 need to open UDP ports for RTP/RTCP. By looking at the source and 1411 destination addresses and ports the opening in the firewall can be 1412 minimized to the least necessary. The opening in the firewall can be 1413 closed after a TEARDOWN message for that session or the session 1414 itself times out. 1416 Simpler firewalls do allow a client to receive media as long as it 1417 has sent packets to the target. Depending on the security level this 1418 can have the same behavior as a NAT. The only difference is that no 1419 address translation is done. To be able to use such a firewall a 1420 client would need to implement one of the above described NAT 1421 traversal methods that include sending packets to the server to open 1422 up the mappings. 1424 6. Comparision of NAT traversal techniques 1426 This section evaluates the techniques described above against the 1427 requirements listed in section Section 3. 1429 In the following table, the columns correspond to the numbered 1430 requirements. For instance, the column under R1 corresponds to the 1431 first requirement in section Section 3: MUST work for all flavors of 1432 NATs. The rows represent the different FW traversal techniques. 1433 SymRTP is short for symmetric RTP, "V.SymRTP" is short for "variation 1434 of symmetric RTP" as described in section Section 4.3.5. 1436 A Summary of the requirements are: 1438 R1 Work for all flavors of NATs 1440 R2 Most work with Firewalls, including them with ALGs 1442 R3 Should have minimal impact on clients not behind NATs 1444 R4 Should be simple to use, Implement and administrate. 1446 R5 Should provide a mitigation against DDoS attacks 1448 -----------------------------------------------+ 1449 | R1 | R2 | R3 | R4 | R5 | 1450 ------------+------+------+------+------+------+ 1451 STU | Yes | Yes | No | Maybe| No | 1452 ------------+------+------+------+------+------+ 1453 ICE | Yes | Yes | No | No | Yes | 1454 ------------+------+------+------+------+------+ 1455 SymRTP | Yes | Yes | Yes |Maybe | No | 1456 ------------+------+------+------+------+------+ 1457 V. SymRTP | Yes | Yes | Yes | Yes |future| 1458 ------------+------+------+------+------+------+ 1459 TURN | Yes | Yes | No | No | Yes | 1460 ------------------------------------------------ 1462 7. IANA Considerations 1464 This document makes no request of IANA. 1466 Note to RFC Editor: this section may be removed on publication as an 1467 RFC. 1469 8. Security Considerations 1471 In preceding sessions we have discussed security merits of each and 1472 every NAT/FW traversal methods for RTSP. In summary, the presence of 1473 NAT(s) is a security risk, as a client cannot perform source 1474 authentication of its IP address. This prevents the deployment of 1475 any future RTSP extensions providing security against hijacking of 1476 sessions by a man-in-the-middle. 1478 Each of the proposed solutions has security implications. Using STUN 1479 will provide the same level of security as RTSP with out transport 1480 level security and source authentications; as long as the server does 1481 not grant a client request to send media to different IP addresses. 1482 Using symmetric RTP will have a higher risk of session hijacking or 1483 denial of service than normal RTSP. The reason is that there exists 1484 a probability that an attacker is able to guess the random tag that 1485 the client uses to prove its identity when creating the address 1486 bindings. This can be solved in the variation of symmetric RTP 1487 (section 6.3.5) with authentication features. The usage of an RTSP 1488 ALG does not increase in itself the risk for session hijacking. 1489 However the deployment of ALGs as sole mechanism for RTSP NAT 1490 traversal will prevent deployment of encrypted end-to-end RTSP 1491 signaling. The usage of TCP tunneling has no known security 1492 problems. However it might provide a bottleneck when it comes to 1493 end-to-end RTSP signaling security if TCP tunneling is used on an 1494 interleaved RTSP signaling connection. The usage of TURN has severe 1495 risk of denial of service attacks against a client. The TURN server 1496 can also be used as a redirect point in a DDOS attack unless the 1497 server has strict enough rules for who may create bindings. 1499 9. Acknowledgements 1501 The author would also like to thank all persons on the MMUSIC working 1502 group's mailing list that has commented on this document. Persons 1503 having contributed in such way in no special order to this protocol 1504 are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon, 1505 Amir Wolf, Anders Klemets, and Colin Perkins. Thomas Zeng would also 1506 like to give special thanks to Greg Sherwood of PacketVideo for his 1507 input into this memo. 1509 Section Section 1.1 contains text originally written for RFC 4787 by 1510 Francois Audet and Cullen Jennings. 1512 10. Informative References 1514 [I-D.ietf-avt-rtp-no-op] 1515 Andreasen, F., "A No-Op Payload Format for RTP", 1516 draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. 1518 [I-D.ietf-behave-rfc3489bis] 1519 Rosenberg, J., "Session Traversal Utilities for (NAT) 1520 (STUN)", draft-ietf-behave-rfc3489bis-06 (work in 1521 progress), March 2007. 1523 [I-D.ietf-behave-turn] 1524 Rosenberg, J., "Obtaining Relay Addresses from Simple 1525 Traversal Underneath NAT (STUN)", 1526 draft-ietf-behave-turn-03 (work in progress), March 2007. 1528 [I-D.ietf-mmusic-ice] 1529 Rosenberg, J., "Interactive Connectivity Establishment 1530 (ICE): A Protocol for Network Address Translator (NAT) 1531 Traversal for Offer/Answer Protocols", 1532 draft-ietf-mmusic-ice-16 (work in progress), June 2007. 1534 [I-D.ietf-mmusic-rfc2326bis] 1535 Schulzrinne, H., "Real Time Streaming Protocol 2.0 1536 (RTSP)", draft-ietf-mmusic-rfc2326bis-15 (work in 1537 progress), June 2007. 1539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1540 Requirement Levels", BCP 14, RFC 2119, March 1997. 1542 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1543 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1545 [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, 1546 May 1999. 1548 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1549 Translator (NAT) Terminology and Considerations", 1550 RFC 2663, August 1999. 1552 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1553 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1554 February 2000. 1556 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1557 Address Translator (Traditional NAT)", RFC 3022, 1558 January 2001. 1560 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 1561 Schulzrinne, "Grouping of Media Lines in the Session 1562 Description Protocol (SDP)", RFC 3388, December 2002. 1564 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1565 Self-Address Fixing (UNSAF) Across Network Address 1566 Translation", RFC 3424, November 2002. 1568 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1569 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1570 Through Network Address Translators (NATs)", RFC 3489, 1571 March 2003. 1573 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1574 Jacobson, "RTP: A Transport Protocol for Real-Time 1575 Applications", STD 64, RFC 3550, July 2003. 1577 [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network 1578 Address Types (ANAT) Semantics for the Session Description 1579 Protocol (SDP) Grouping Framework", RFC 4091, June 2005. 1581 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1582 Description Protocol", RFC 4566, July 2006. 1584 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1585 and RTP Control Protocol (RTCP) Packets over Connection- 1586 Oriented Transport", RFC 4571, July 2006. 1588 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1589 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1590 RFC 4787, January 2007. 1592 [STUN-IMPL] 1593 "Open Source STUN Server and Client, http:// 1594 www.vovida.org/applications/downloads/stun/index.html", 1595 June 2007. 1597 Authors' Addresses 1599 Magnus Westerlund 1600 Ericsson 1601 Torshamsgatan 23 1602 Stockholm, SE-164 80 1603 Sweden 1605 Phone: +46 8 719 0000 1606 Fax: 1607 Email: magnus.westerlund@ericsson.com 1608 URI: 1610 Thomas Zeng 1612 Phone: 1613 Fax: 1614 Email: thomas.zeng@gmail.com 1615 URI: 1617 Full Copyright Statement 1619 Copyright (C) The IETF Trust (2007). 1621 This document is subject to the rights, licenses and restrictions 1622 contained in BCP 78, and except as set forth therein, the authors 1623 retain all their rights. 1625 This document and the information contained herein are provided on an 1626 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1627 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1628 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1629 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1630 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1631 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1633 Intellectual Property 1635 The IETF takes no position regarding the validity or scope of any 1636 Intellectual Property Rights or other rights that might be claimed to 1637 pertain to the implementation or use of the technology described in 1638 this document or the extent to which any license under such rights 1639 might or might not be available; nor does it represent that it has 1640 made any independent effort to identify any such rights. Information 1641 on the procedures with respect to rights in RFC documents can be 1642 found in BCP 78 and BCP 79. 1644 Copies of IPR disclosures made to the IETF Secretariat and any 1645 assurances of licenses to be made available, or the result of an 1646 attempt made to obtain a general license or permission for the use of 1647 such proprietary rights by implementers or users of this 1648 specification can be obtained from the IETF on-line IPR repository at 1649 http://www.ietf.org/ipr. 1651 The IETF invites any interested party to bring to its attention any 1652 copyrights, patents or patent applications, or other proprietary 1653 rights that may cover technology that may be required to implement 1654 this standard. Please address the information to the IETF at 1655 ietf-ipr@ietf.org. 1657 Acknowledgment 1659 Funding for the RFC Editor function is provided by the IETF 1660 Administrative Support Activity (IASA).