idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-evaluation-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 and authors 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 20, 2010) is 5210 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-avt-app-rtp-keepalive-07 == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-22 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- 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 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Westerlund 3 Internet-Draft Ericsson 4 Intended status: Informational T. Zeng 5 Expires: July 24, 2010 January 20, 2010 7 The evaluation of different NAT traversal Techniques for media 8 controlled by Real-time Streaming Protocol (RTSP) 9 draft-ietf-mmusic-rtsp-nat-evaluation-02 11 Abstract 13 This document describes several NAT traversal techniques that could 14 be used by RTSP. Each technique includes a description on how it 15 would be used, the security implications of using it and any other 16 deployment considerations it has. There are also disussions on how 17 NAT traversal techniques relates to firewalls and how each technique 18 can be applied in different use cases. These findings where used 19 when selecting the NAT traversal for RTSP solution to standardize in 20 the MMUSIC WG. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on July 24, 2010. 51 Copyright Notice 53 Copyright (c) 2010 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the BSD License. 66 This document may contain material from IETF Documents or IETF 67 Contributions published or made publicly available before November 68 10, 2008. The person(s) controlling the copyright in some of this 69 material may not have granted the IETF Trust the right to allow 70 modifications of such material outside the IETF Standards Process. 71 Without obtaining an adequate license from the person(s) controlling 72 the copyright in such materials, this document may not be modified 73 outside the IETF Standards Process, and derivative works of it may 74 not be created outside the IETF Standards Process, except to format 75 it for publication as an RFC or to translate it into languages other 76 than English. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 1.1. Network Address Translators . . . . . . . . . . . . . . . 5 82 1.2. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 5 83 1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 2. Detecting the loss of NAT mappings . . . . . . . . . . . . . . 7 85 3. Requirements on NAT-Traversal . . . . . . . . . . . . . . . . 7 86 4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . . 9 87 4.1. STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 88 4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 9 89 4.1.2. Using STUN to traverse NAT without server 90 modifications . . . . . . . . . . . . . . . . . . . . 10 91 4.1.3. Embedding STUN in RTSP . . . . . . . . . . . . . . . . 12 92 4.1.4. Discussion On Co-located STUN Server . . . . . . . . . 13 93 4.1.5. ALG considerations . . . . . . . . . . . . . . . . . . 13 94 4.1.6. Deployment Considerations . . . . . . . . . . . . . . 14 95 4.1.7. Security Considerations . . . . . . . . . . . . . . . 16 96 4.2. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 17 98 4.2.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 17 99 4.2.3. Implementation burden of ICE . . . . . . . . . . . . . 19 100 4.2.4. Deployment Considerations . . . . . . . . . . . . . . 19 101 4.2.5. Security Consideration . . . . . . . . . . . . . . . . 20 102 4.3. Symmetric RTP . . . . . . . . . . . . . . . . . . . . . . 20 103 4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 20 104 4.3.2. Necessary RTSP extensions . . . . . . . . . . . . . . 21 105 4.3.3. Deployment Considerations . . . . . . . . . . . . . . 21 106 4.3.4. Security Consideration . . . . . . . . . . . . . . . . 22 107 4.3.5. A Variation to Symmetric RTP . . . . . . . . . . . . . 23 108 4.4. Application Level Gateways . . . . . . . . . . . . . . . . 25 109 4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 25 110 4.4.2. Outline On how ALGs for RTSP work . . . . . . . . . . 25 111 4.4.3. Deployment Considerations . . . . . . . . . . . . . . 26 112 4.4.4. Security Considerations . . . . . . . . . . . . . . . 27 113 4.5. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 27 114 4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . . 27 115 4.5.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . . 27 116 4.5.3. Deployment Considerations . . . . . . . . . . . . . . 27 117 4.5.4. Security Considerations . . . . . . . . . . . . . . . 28 118 4.6. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . . 28 119 4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 28 120 4.6.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 29 121 4.6.3. Deployment Considerations . . . . . . . . . . . . . . 30 122 4.6.4. Security Considerations . . . . . . . . . . . . . . . 30 123 5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 31 124 6. Comparision of NAT traversal techniques . . . . . . . . . . . 32 125 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 126 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 127 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 128 10. Informative References . . . . . . . . . . . . . . . . . . . . 34 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 131 1. Introduction 133 Today there is a proliferate deployment of different flavors of 134 Network Address Translator (NAT) boxes that in many cases only 135 loosely follows standards[RFC3022][RFC2663][RFC3424]]. NATs cause 136 discontinuity in address realms [RFC3424], therefore an application 137 protocol, such as RTSP, needs to deal with such discontinuities 138 caused by NATs. The problem is that, being a media control protocol 139 managing one or more media streams, RTSP carries network address and 140 port information within its protocol messages. Because of this, even 141 if RTSP itself, when carried over TCP for example, may not be blocked 142 by NATs, its media streams may be blocked by NATs. This will occur 143 unless special protocol provisions are added to support NAT- 144 traversal. 146 Like NATs, firewalls (FWs) are also middle boxes that need to be 147 considered. Firewalls helps prevent unwanted traffic from getting in 148 or out of the protected network. RTSP is designed such that a 149 firewall can be configured to let RTSP controlled media streams to go 150 through with minimal implementation effort. The minimal effort is to 151 implement an ALG (Application Level Gateway) to interpret RTSP 152 parameters. There is also a large class of firewalls, commonly home 153 FWs, that uses a similar filtering behavior to what NAT has. This 154 type of firewalls can be handled using the same solution as employed 155 for NAT traversal instead of relying on ALGs. 157 This document describes several NAT-traversal mechanisms for RTSP 158 controlled media streaming. These NAT solutions fall into the 159 category of ""UNilateral Self-Address Fixing (UNSAF)" as defined in 160 [RFC3424] and quoted below: 162 "UNSAF is a process whereby some originating process attempts to 163 determine or fix the address (and port) by which it is known - e.g. 164 to be able to use address data in the protocol exchange, or to 165 advertise a public address from which it will receive connections." 167 Following the guidelines spelled out in RFC 3424, we describe the 168 required RTSP protocol extensions for each method, transition 169 strategies, and security concerns. 171 This document is capturing the evaluation done in the process to 172 recommend FW/NAT traversal methods for RTSP streaming servers based 173 on RFC 2326 [RFC2326] as well as the RTSP 2.0 core spec 174 [I-D.ietf-mmusic-rfc2326bis]. The evaluation is focused on NAT 175 traversal for the media streams carried over UDP [RFC0768]. Where 176 RTP [RFC3550] over UDP being the main case for such usage. The 177 findings should be applicable to other protocols as long as they have 178 similar properties. 180 1.1. Network Address Translators 182 Readers are urged to refer to [RFC2663] for information on NAT 183 taxonomy and terminology. Traditional NAT is the most common type of 184 NAT device deployed. Readers may refer to [RFC3022] for detailed 185 information on traditional NAT. Traditional NAT has two main 186 varieties -- Basic NAT and Network Address/Port Translator (NAPT). 188 NAPT is by far the most commonly deployed NAT device. NAPT allows 189 multiple internal hosts to share a single public IP address 190 simultaneously. When an internal host opens an outgoing TCP or UDP 191 session through a NAPT, the NAPT assigns the session a public IP 192 address and port number, so that subsequent response packets from the 193 external endpoint can be received by the NAPT, translated, and 194 forwarded to the internal host. The effect is that the NAPT 195 establishes a NAT session to translate the (private IP address, 196 private port number) tuple to a (public IP address, public port 197 number) tuple, and vice versa, for the duration of the session. An 198 issue of relevance to peer-to-peer applications is how the NAT 199 behaves when an internal host initiates multiple simultaneous 200 sessions from a single (private IP, private port) endpoint to 201 multiple distinct endpoints on the external network. In this 202 specification, the term "NAT" refers to both "Basic NAT" and "Network 203 Address/Port Translator (NAPT)". 205 This document uses the term "address and port mapping" as the 206 translation between an external address and port and an internal 207 address and port. Note that this is not the same as an "address 208 binding" as defined in RFC 2663. There exist a number of address and 209 port mapping behaviors described in more detail in Section 4.1 of 210 [RFC4787]. 212 NATs also have a filtering behavior on traffic arriving on the 213 external side. Such behavior effects how well different methods for 214 NAT traversal works through these NATs. See Section 5 of [RFC4787] 215 for more information on the different types of filtering that have 216 been identified. 218 1.2. Firewalls 220 A firewall (FW) is a security gateway that enforces certain access 221 control policies between two network administrative domains: a 222 private domain (intranet) and a public domain (public Internet). 223 Many organizations use firewalls to prevent privacy intrusions and 224 malicious attacks to corporate computing resources in the private 225 intranet [RFC2588]. 227 A comparison between NAT and FW is given below: 229 1. A firewall must sit between two network administrative domains, 230 while NAT does not have to sit between two domains. In fact, 231 there exist cases when in corporations there are many NAT boxes 232 within the intranet, in which case the NAT boxes sit between 233 subnets. 235 2. NAT does not in itself provide security, although some access 236 control policies can be implemented using address translation 237 schemes. The inherent filtering behaviours are commonly mistaken 238 for real security policies. 240 It should be noted that many NAT devices intended for small office/ 241 home office (SOHO) include both NATs and firewall functionality. 243 In the rest of this memo we use the phrase "NAT traversal" 244 interchangeably with "FW traversal", "NAT/FW traversal" and "NAT/ 245 Firewall traversal". 247 1.3. Glossary 249 ALG: Application Level Gateway, an entity that can be embedded in a 250 NAT or other middlebox to perform the application layer 251 functions required for a particular protocol to traverse the 252 NAT/middlebox. 254 ICE: Interactive Connectivity Establishment, see 255 [I-D.ietf-mmusic-ice]. 257 DNS: Domain Name Service 259 DDOS: Distributed Denial Of Service attacks 261 MID: Media Identifier from Grouping of media lines in SDP, see 262 [RFC3388]. 264 NAT: Network Address Translator, see [RFC3022]. 266 NAPT: Network Address/Port Translator, see [RFC3022]. 268 RTP: Real-time Transport Protocol, see [RFC3550]. 270 RTSP: Real-Time Streaming Protocol, see [RFC2326] and 271 [I-D.ietf-mmusic-rfc2326bis]. 273 SDP: Session Description Protocol, see [RFC4566]. 275 SSRC: Synchronization source in RTP, see [RFC3550]. 277 2. Detecting the loss of NAT mappings 279 Several NAT traversal techniques in the next chapter make use of the 280 fact that the NAT UDP mapping's external address and port can be 281 discovered. This information is then utilized to traverse the NAT 282 box. However any such information is only good while the mapping is 283 still valid. As the IAB's UNSAF document [RFC3424] points out, the 284 mapping can either timeout or change its properties. It is therefore 285 important for the NAT traversal solutions to handle the loss or 286 change of NAT mappings, according to RFC3424. 288 First, since NATs may also dynamically reclaim or readjust address/ 289 port translations, "keep-alive" and periodic re-polling may be 290 required according to RFC 3424. Secondly, it is possible to detect 291 and recover from the situation where the mapping has been changed or 292 removed. The loss of a mapping can be detected when no traffic 293 arrives for a while. Below we will give some recommendation on how 294 to detect loss of NAT mappings when using RTP/RTCP under RTSP 295 control. 297 A RTP session normally has both RTP and RTCP streams. The loss of a 298 RTP mapping can only be detected when expected traffic does not 299 arrive. If a client does not receive data within a few seconds after 300 having received the "200 OK" response to a PLAY request, there are 301 likely some middleboxes blocking the traffic. However, for a 302 receiver to be more certain to detect the case where no RTP traffic 303 was delivered due to NAT trouble, one should monitor the RTCP Sender 304 reports. The sender report carries a field telling how many packets 305 the server has sent. If that has increased and no RTP packets has 306 arrived for a few seconds it is likely the RTP mapping has been 307 removed. 309 The loss of mapping for RTCP is simpler to detect. RTCP is normally 310 sent periodically in each direction, even during the RTSP ready 311 state. If RTCP packets are missing for several RTCP intervals, the 312 mapping is likely to be lost. Note that if neither RTCP packets nor 313 RTSP messages are received by the RTSP server for a while, the RTSP 314 server has the option to delete the corresponding SSRC and RTSP 315 session ID, because either the client can not get through a middle 316 box NAT/FW, or that the client is mal-functioning. 318 3. Requirements on NAT-Traversal 320 This section considers the set of requirements for the evaulation of 321 RTSP NAT traversal solutions. 323 RTSP is a client-server protocol. Typically services providers 324 deploy RTSP servers in the public address realm. However, there are 325 use cases where the reverse is true: RTSP clients are connecting from 326 public address realm to RTSP servers behind home NATs. This is the 327 case for instance when home surveillance cameras running as RTSP 328 servers intend to stream video to cell phone users in the public 329 address realm through a home NAT. In terms of requirements, the 330 first requirement shoulb be to solve the RTSP NAT traversal problem 331 for RTSP servers deployed in a public network, i.e. no NAT at the 332 server side. 334 The list of feature requirements for RTSP NAT solutions are given 335 below: 337 1. MUST work for all flavors of NATs, including NATs with address 338 and port restricted filtering. 340 2. MUST work for firewalls (subject to pertinent firewall 341 administrative policies), including those with ALGs. 343 3. SHOULD have minimal impact on clients in the open and not dual- 344 hosted. RTSP dual-hosting means that RTSP protocol and the media 345 protocol (e.g. RTP) are implemented on different computers with 346 different IP addresses. 348 * For instance, no extra delay from RTSP connection till arrival 349 of media 351 4. SHOULD be simple to use/implement/administer that people actually 352 turn them on 354 * Otherwise people will resort to TCP tunneling through NATs 356 * Address discovery for NAT traversal should take place behind 357 the scene, if possible 359 5. SHOULD authenticate dual-hosted client transport handler to 360 prevent DDOS attacks. 362 The last requirement addresses the Distributed Denial-Of-Service 363 (DDOS) threat, which relates to NAT traversal as explained below. 365 During NAT traversal, when the RTSP server performs address 366 translation on a client, the result may be that the public IP address 367 of the RTP receiver host is different than the public IP address of 368 the RTSP client host. This posts a DDOS threat that has significant 369 amplification potentials because the RTP media streams in general 370 consist of large number of IP packets. DDOS attacks occur if the 371 attacker fakes the messages in the NAT traversal mechanism to trick 372 the RTSP server into believing that the client's RTP receiver is 373 located in a separate host. For example, user A may use his RTSP 374 client to direct the RTSP server to send video RTP streams to 375 target.example.com in order to degrade the services provided by 376 target.example.com. Note a simple preventative measure is for the 377 RTSP server to disallow the cases where the client's RTP receiver has 378 a different public IP address than that of the RTSP client. However, 379 in some applications (e.g., centralized conferencing), dual-hosted 380 RTSP/RTP clients have valid use cases. The key is how to 381 authenticate the messages exchanged during the NAT traversal process. 382 Message authentication is a big challenge in the current wired and 383 wireless networking environment. It may be necessary in the 384 immediate future to deploy NAT traversal solutions that do not have 385 full message authentication, but provide upgrade path to add 386 authentication features in the future. 388 4. NAT Traversal Techniques 390 There exist a number of potential NAT traversal techniques that can 391 be used to allow RTSP to traverse NATs. They have different features 392 and are applicable to different topologies; their cost is also 393 different. They also vary in security levels. In the following 394 sections, each technique is outlined in details with discussions on 395 the corresponding advantages and disadvantages. 397 This section includes NAT traversal techniques that have not been 398 formally specified anywhere else. The overview section of this 399 document may be the only publicly available specification of some of 400 the NAT traversal techniques. However that is no real barrier 401 against doing an evaluation of the NAT traversal technique. Some 402 other techniques are currently (at the time of writing) in a state of 403 flux due to ongoing standardization work on these techniques, e.g. 404 ICE [I-D.ietf-mmusic-ice], STUN [RFC5389] and RTP No-Op 405 [I-D.ietf-avt-rtp-no-op]. 407 4.1. STUN 409 4.1.1. Introduction 411 STUN - "Simple Traversal of UDP Through Network Address Translators" 412 [RFC3489][RFC5389] is a standardized protocol that allows a client to 413 use secure means to discover the presence of a NAT between himself 414 and the STUN server and the type of that NAT. The client then uses 415 the STUN server to discover the address bindings assigned by the NAT. 417 STUN is a client-server protocol. STUN client sends a request to a 418 STUN server and the server returns a response. There are two types 419 of STUN requests - Binding Requests, sent over UDP, and Shared Secret 420 Requests, sent over TLS over TCP. 422 STUN is in the process of being updated by the BEHAVE WG to address 423 issues found during usage. The BEHAVE WG intends to integrate it 424 better with TURN [I-D.ietf-behave-turn]. 426 4.1.2. Using STUN to traverse NAT without server modifications 428 This section describes how a client can use STUN to traverse NATs to 429 RTSP servers without requiring server modifications. Note that this 430 method has limited applicability and requires the server to be 431 available in the external/public address realm in regards to the 432 client located behind a NAT(s). 434 Limitations: 436 o The server must be located in either a public address realm or the 437 next hop external address realm in regards to the client. 439 o The client may only be located behind NATs that performing 440 Endpoint Independent or Address Dependent Mappings. Clients 441 behind NATs that do Address and Port Dependent Mappings cannot use 442 this method. 444 Method: 446 A RTSP client using RTP transport over UDP can use STUN to traverse a 447 NAT(s) in the following way: 449 1. Use STUN to try to discover the type of NAT, and the timeout 450 period for any UDP mapping on the NAT. This is RECOMMENDED to be 451 performed in the background as soon as IP connectivity is 452 established. If this is performed prior to establishing a 453 streaming session the delays in the session establishment will be 454 reduced. If no NAT is detected, normal SETUP SHOULD be used. 456 2. The RTSP client determines the number of UDP ports needed by 457 counting the number of needed media transport protocols sessions 458 in the multi-media presentation. This information is available 459 in the media description protocol, e.g. SDP [RFC4566]. For 460 example, each RTP session will in general require two UDP ports, 461 one for RTP, and one for RTCP. 463 3. For each UDP port required, establish a mapping and discover the 464 public/external IP address and port number with the help of the 465 STUN server. A successful mapping looks like: client's local 466 address/port <-> public address/port. 468 4. Perform the RTSP SETUP for each media. In the transport header 469 the following parameter SHOULD be included with the given values: 470 "dest_addr" [I-D.ietf-mmusic-rfc2326bis] or "destination" + 471 "client_port" [RFC2326] with the public/external IP address and 472 port pair for both RTP and RTCP. To be certain that this works 473 servers must allow a client to setup the RTP stream on any port, 474 not only even ports and with non-continuous port numbers for RTP 475 and RTCP. This requires the new feature provided in the update 476 to RFC2326 [I-D.ietf-mmusic-rfc2326bis]. The server should 477 respond with a transport header containing an "src_addr" or 478 "source parameter" + "server_port" with the RTP and RTCP source 479 IP address and port of the media stream. 481 5. To keep the mappings alive, the client SHOULD periodically send 482 UDP traffic over all mappings needed for the session. For the 483 mapping carrying RTCP traffic the periodic RTCP traffic may be 484 enough. For mappings carrying RTP traffic and for mappings 485 carrying RTCP packets at too low a frequency, keep-alive messages 486 SHOULD be sent. As keep alive messages, one could use the RTP 487 No-Op packet [I-D.ietf-avt-rtp-no-op] to the streaming server's 488 discard port (port number 9). The drawback of using RTP No-Op is 489 that the payload type number must be dynamically assigned through 490 RTSP first. Otherwise STUN could be used for the keep-alive as 491 well as empty UDP packets. 493 If a UDP mapping is lost, the above discovery process must be 494 repeated. The media stream also needs to be SETUP again to change 495 the transport parameters to the new ones. This will cause a glitch 496 in media playback. 498 To allow UDP packets to arrive from the server to a client behind a 499 "Address Dependent" filtering NAT, the client must send the very 500 first UDP packet to punch a hole in the NAT. The client, before 501 sending a RTSP PLAY request, must send a so called FW packet (such as 502 a RTP No-Op packet) on each mapping, to the IP address given as the 503 servers source address. To create minimum problems for the server 504 these UDP packets SHOULD be sent to the server's discard port (port 505 number 9). Since UDP packets are inherently unreliable, to ensure 506 that at least one UDP message passes the NAT, FW packets should be 507 retransmitted a reasonable number of times. 509 For a "Address and Port Dependent" filtering NAT the client must send 510 messages to the exact ports used by the server to send UDP packets 511 before sending a RTSP PLAY request. This makes it possible to use 512 the above described process with the following additional 513 restrictions: for each port mapping, FW packets need to be sent first 514 to the server's source address/port. To minimize potential effects 515 on the server from these messages the following type of FW packets 516 MUST be sent. RTP: an empty or less than 12 bytes UDP packet. RTCP: 517 A correctly formatted RTCP RR or SR message. The above described 518 adaptations for restricted NATs will not work unless the server 519 includes the "src_addr" in the "Transport" header (which is the 520 "source" transport parameter in RFC2326). 522 4.1.3. Embedding STUN in RTSP 524 This section outlines the adaptation and embedding of STUN within 525 RTSP. This enables STUN to be used to traverse any type of NAT, 526 including symmetric NATs. This would require protocol changes which 527 are beyond the scope of this memo. 529 This NAT traversal solution has limitations: 531 1. It does not work if both RTSP client and RTSP server are behind 532 separate NATs. 534 2. The RTSP server may, for security reasons, refuse to send media 535 streams to an IP different from the IP in the client RTSP 536 requests. 538 Therefore, if the client is behind a NAT that has multiple public 539 addresses, and the client's RTSP port and UDP port are mapped to 540 different IP addresses, RTSP SETUP may fail. 542 Deviations from STUN as defined in RFC 3489: 544 1. We allow RTSP applications to have the option to perform STUN 545 "Shared Secret Request" through RTSP, via extension to RTSP; 547 2. We require STUN server to be co-located on RTSP server's media 548 output ports. 550 In order to allow binding discovery without authentication, the STUN 551 server embedded in RTSP application must ignore authentication tag, 552 and the STUN client embedded in RTSP application must use dummy 553 authentication tag. 555 If STUN server is co-located with RTSP server's media output port, an 556 RTSP client using RTP transport over UDP can use STUN to traverse ALL 557 types of NATs. In the case of port and address dependent mapping 558 NATs, the party inside the NAT must initiate UDP traffic. The STUN 559 Bind Request, being a UDP packet itself, can serve as the traffic 560 initiating packet. Subsequently, both the STUN Binding Response 561 packets and the RTP/RTCP packets can traverse the NAT, regardless of 562 whether the RTSP server or the RTSP client is behind NAT. 564 Likewise, if an RTSP server is behind a NAT, then an embedded STUN 565 server must co-locate on the RTSP client's RTCP port. Also it will 566 become the client that needs to disclose his destination address 567 rather than the server so that the server correctly can determine its 568 NAT external source address for the media streams. In this case, we 569 assume that the client has some means of establishing TCP connection 570 to the RTSP server behind NAT so as to exchange RTSP messages with 571 the RTSP server. 573 To minimize delay, we require that the RTSP server supporting this 574 option must inform its client the RTP and RTCP ports from where the 575 server intend to send out RTP and RTCP packets, respectively. This 576 can be done by using the "server_port" parameter in RFC2326, and the 577 "src_addr" parameter in [I-D.ietf-mmusic-rfc2326bis]. Both are in 578 the RTSP Transport header. But in general this strategy will require 579 that one first do one SETUP request per media to learn the server 580 ports, then perform the STUN checks, followed by a subsequent SETUP 581 to change the client port and destination address to what was learned 582 during the STUN checks. 584 To be certain that RTCP works correctly the RTSP end-point (server or 585 client) will be required to send and receive RTCP packets from the 586 same port. 588 4.1.4. Discussion On Co-located STUN Server 590 In order to use STUN to traverse "address and port dependent" 591 filtering or mapping NATs the STUN server needs to be co-located with 592 the streaming server media output ports. This creates a de- 593 multiplexing problem: we must be able to differentiate a STUN packet 594 from a media packet. This will be done based on heuristics. A 595 common heuristics is the frist byte in the packet, which works fine 596 between STUN and RTP or RTCP where the first byte happens to be 597 different, but may not work as well with other media transport 598 protocols. 600 4.1.5. ALG considerations 602 If a NAT supports RTSP ALG (Application Level Gateway) and is not 603 aware of the STUN traversal option, service failure may happen, 604 because a client discovers its public IP address and port numbers, 605 and inserts them in its SETUP requests, when the RTSP ALG processes 606 the SETUP request it may change the destination and port number, 607 resulting in unpredictable behavior. In such cases two alternatives 608 exist: 610 1. The usage of TLS to encrypt the RTSP TCP connection to prevent 611 the ALG from reading and modifying the RTSP messages. 613 2. To turn of the STUN based NAT traversal mechanism 615 As it may be difficult to determine why the failure occurs, the usage 616 of TLS protected RTSP message exchange at all times would avoid this 617 issue. 619 4.1.6. Deployment Considerations 621 For the non-embedded usage of STUN the following applies: 623 Advantages: 625 o Using STUN does not require RTSP server modifications; it only 626 affects the client implementation. 628 Disadvantages: 630 o Requires a STUN server deployed in the public address space. 632 o Only works with NATs that perform endpoint independent and address 633 dependent mappings. Port and address dependent filtering NATs 634 create some issues. 636 o Does not work with port and address dependent mapping NATs without 637 server modifications. 639 o Will mostly not work if a NAT uses multiple IP addresses, since 640 RTSP server generally requires all media streams to use the same 641 IP as used in the RTSP connection to prevent becoming a DDOS tool. 643 o Interaction problems exist when a RTSP-aware ALG interferes with 644 the use of STUN for NAT traversal unless TLS secured RTSP message 645 exchange is used. 647 o Using STUN requires that RTSP servers and clients support the 648 updated RTSP specification, because it is no longer possible to 649 guarantee that RTP and RTCP ports are adjacent to each other, as 650 required by the "client_port" and "server_port" parameters in 651 RFC2326. 653 Transition: 655 The usage of STUN can be phased out gradually as the first step of a 656 STUN capable server or client should be to check the presence of 657 NATs. The removal of STUN capability in the client implementations 658 will have to wait until there is absolutely no need to use STUN. 660 For the "Embedded STUN" method the following applies: 662 Advantages: 664 o STUN is a solution first used by SIP applications. As shown 665 above, with little or no changes, RTSP application can re-use STUN 666 as a NAT traversal solution, avoiding the pit-fall of solving a 667 problem twice. 669 o STUN has built-in message authentication features, which makes it 670 more secure. See next section for an in-depth security 671 discussion. 673 o This solution works as long as there is only one RTSP end point in 674 the private address realm, regardless of the NAT's type. There 675 may even be multiple NATs (see figure 1 in RFC3489). 677 o Compares to other UDP based NAT traversal methods in this 678 document, STUN requires little new protocol development (since 679 STUN is already a IETF standard), and most likely less 680 implementation effort, since open source STUN server and client 681 have become available [STUN-IMPL]. There is the need to embed 682 STUN in RTSP server and client, which require a de-multiplexer 683 between STUN packets and RTP/RTCP packets. There is also a need 684 to register the proper feature tags. 686 Disadvantages: 688 o Some extensions to the RTSP core protocol, signaled by RTSP 689 feature tags, must be introduced. 691 o Requires an embedded STUN server to co-locate on each of RTSP 692 server's media protocol's ports (e.g. RTP and RTCP ports), which 693 means more processing is required to de-multiplex STUN packets 694 from media packets. For example, the de-multiplexer must be able 695 to differentiate a RTCP RR packet from a STUN packet, and forward 696 the former to the streaming server, the later to STUN server. 698 o Even if the RTSP server is in the open, and the client is behind a 699 multi-addressed NAT, it may still break if the RTSP server does 700 not allow RTP packets to be sent to an IP differs from the IP of 701 the client's RTSP request. 703 o Interaction problems exist when a RTSP ALG is not aware of STUN 704 unless TLS is used to protect the RTSP messages. 706 o Using STUN requires that RTSP servers and clients support the 707 updated RTSP specification, and they both agree to support the NAT 708 traversal feature. 710 o Increases the setup delay with at least the amount of time it 711 takes to perform STUN message exchanges. Most likely an extra 712 SETUP sequence will be required. 714 Transition: 716 The usage of STUN can be phased out gradually as the first step of a 717 STUN capable machine can be to check the presence of NATs for the 718 presently used network connection. The removal of STUN capability in 719 the client implementations will have to wait until there is 720 absolutely no need to use STUN. 722 4.1.7. Security Considerations 724 To prevent RTSP server being used as Denial of Service (DoS) attack 725 tools the RTSP Transport header parameter "destination" and 726 "dest_addr" are generally not allowed to point to any IP address 727 other than the one that RTSP message originates from. The RTSP 728 server is only prepared to make an exception of this rule when the 729 client is trusted (e.g., through the use of a secure authentication 730 process, or through some secure method of challenging the destination 731 to verify its willingness to accept the RTP traffic). Such 732 restriction means that STUN does not work for NATs that would assign 733 different IP addresses to different UDP flows on its public side. 734 Therefore the multi-addressed NATs will at times have trouble with 735 STUN-based RTSP NAT traversals. 737 In terms of security property, STUN combined with destination address 738 restricted RTSP has the same security properties as the core RTSP. 739 It is protected from being used as a DoS attack tool unless the 740 attacker has ability the to spoof the TCP connection carrying RTSP 741 messages. 743 Using STUN's support for message authentication and secure transport 744 of RTSP messages, attackers cannot modify STUN responses or RTSP 745 messages to change media destination. This protects against 746 hijacking, however as a client can be the initiator of an attack, 747 these mechanisms cannot securely prevent RTSP servers being used as 748 DoS attack tools. 750 4.2. ICE 752 4.2.1. Introduction 754 ICE (Interactive Connectivity Establishment) [I-D.ietf-mmusic-ice] is 755 a methodology for NAT traversal that has been developed for SIP using 756 SDP offer/answer. The basic idea is to try, in a parallel fashion, 757 all possible connection addresses that an end point may have. This 758 allows the end-point to use the best available UDP "connection" 759 (meaning two UDP end-points capable of reaching each other). The 760 methodology has very nice properties in that basically all NAT 761 topologies are possible to traverse. 763 Here is how ICE works on a high level. End point A collects all 764 possible address that can be used, including local IP addresses, STUN 765 derived addresses, TURN addresses, etc. On each local port that any 766 of these address and port pairs leads to, a STUN server is installed. 767 This STUN server only accepts STUN requests using the correct 768 authentication through the use of username and password. 770 End-point A then sends a request to establish connectivity with end- 771 point B, which includes all possible destinations to get the media 772 through too A. Note that each of A's published address/port pairs has 773 a STUN server co-located. B, in its turn provides A with all its 774 possible destinations for the different media streams. A and B then 775 uses a STUN client to try to reach all the address and port pairs 776 specified by A from its corresponding destination ports. The 777 destinations for which the STUN requests have successfully completed 778 are then indicated and selected. 780 If B fails to get any STUN response from A, all hope is not lost. 781 Certain NAT topologies require multiple tries from both ends before 782 successful connectivity is accomplished and therefore requests are 783 retransmitted multiple times. The STUN requests may also result in 784 that more connectivity alternatives are discovered and conveyed in 785 the STUN responses. 787 4.2.2. Using ICE in RTSP 789 The usage of ICE for RTSP requires that both client and server be 790 updated to include the ICE functionality. If both parties implement 791 the necessary functionality the following steps could provide ICE 792 support for RTSP. 794 This assumes that it is possible to establish a TCP connection for 795 the RTSP messages between the client and the server. This is not 796 trivial in scenarios where the server is located behind a NAT, and 797 may require some TCP ports been opened, or the deployment of proxies, 798 etc. 800 The negotiation of ICE in RTSP of necessity will work different than 801 in SIP with SDP offer/answer. The protocol interactions are 802 different and thus the possibilities for transfer of states are also 803 somewhat different. The goal is also to avoid introducing extra 804 delay in the setup process at least for when the server is using a 805 public address and the client is either having a public address or is 806 behind NAT(s). This process is only intended to support PLAY mode, 807 i.e. media traffic flows from server to client. 809 1. The ICE usage begins in the SDP. The SDP for the service 810 indicates that ICE is supported at the server. No candidates can 811 be given here as that would not work with the on demand, DNS load 812 balancing, etc., that make a SDP indicate a resource on a server 813 park rather than a specific machine. 815 2. The client gathers addresses and puts together its candidate for 816 each media stream indicated in the session description. 818 3. In each SETUP request the client includes its candidates, 819 promoting one for primary usage. This indicates for the server 820 the ICE support by the client. One candidate is the primary 821 candidate and here the prioritization for this address should be 822 somewhat different compared to SIP. High performance rather than 823 always successful is to recommended as it is most likely to be a 824 server in the public. 826 4. The server responds to the SETUP (200 OK) for each media stream 827 with its candidates. A server with a public address usually only 828 provides a single ICE candidate. Also here one candidate is the 829 server primary address. 831 5. The connectivity checks are performed. For the server the 832 connectivity checks from the server to the clients have an 833 additional usage. They verify that there is someone willingly to 834 receive the media, thus protecting itself from performing 835 unknowingly an DoS attack. 837 6. Connectivity checks from the client's primary to the server's 838 primary was successful. Thus no further SETUP requests are 839 necessary and processing can proceed with step 7. If another 840 address than the primary has been verified by the client to work, 841 that address may then be promoted for usage in a SETUP request 842 (Goto 7). If the checks for the availble candidates failed and 843 If further candidates have been derived during the connectivity 844 checks, then those can be promoted in new candidate lines in 845 SETUP request updating the list (Goto 5). 847 7. Client issues PLAY request. If the server also has completed its 848 connectivity checks for this primary addresses (based on username 849 as it may be derived addresses if the client was behind NAT) then 850 it can directly answer 200 OK (Goto 8). If the connectivity 851 check has not yet completed it responds with a 1xx code to 852 indicate that it is verifying the connectivity. If that fails 853 within the set timeout an error is reported back. Client needs 854 to go back to 6. 856 8. Process completed media can be delivered. ICE testing ports may 857 be released. 859 To keep media paths alive client must likely periodically send data 860 to the server. This could be realized with either STUN or RTP No-op 861 [I-D.ietf-avt-rtp-no-op] packets. RTCP sent by client should be able 862 to keep RTCP open. 864 4.2.3. Implementation burden of ICE 866 The usage of ICE will require that a number of new protocols and new 867 RTSP/SDP features be implemented. This makes ICE the solution that 868 has the largest impact on client and server implementations amongst 869 all the NAT/FW traversal methods in this document. 871 Some RTSP server implementation requirements are: 873 o STUN server features 875 o limited STUN client features 877 o SDP generation with more parameters. 879 o RTSP error code for ICE extension 881 Some client implantation requirements are: 883 o Limited STUN server features 885 o Limited STUN client features 887 o RTSP error code and ICE extension 889 4.2.4. Deployment Considerations 891 Advantages: 893 o Solves NAT connectivity discovery for basically all cases as long 894 as a TCP connection between them can be established. This 895 includes servers behind NATs. (Note that a proxy between address 896 domains may be required to get TCP through). 898 o Improves defenses against DDOS attacks, as media receiving client 899 requires authentications, via STUN on its media reception ports. 901 Disadvantages: 903 o Increases the setup delay with at least the amount of time it 904 takes for the server to perform its STUN requests. 906 o Assumes that it is possible to de-multiplex between media packets 907 and STUN packets. 909 o Has fairly high implementation burden put on both RTSP server and 910 client. 912 4.2.5. Security Consideration 914 One should review the security consideration section of ICE and STUN 915 to understand that ICE is contains some potential issues. However 916 these can be avoided by a correctly utilizing ICE in RTSP. In fact 917 ICE do help avoid the DDoS issue with RTSP substantially as it 918 reduces the possibility for a DDoS using RTSP servers to attackers 919 that are on-path between the RTSP server and the target and capable 920 of intercepting the STUN connectivity check packets and correctly 921 send a response to the server. 923 4.3. Symmetric RTP 925 4.3.1. Introduction 927 Symmetric RTP is a NAT traversal solution that is based on requiring 928 RTSP clients to send UDP packets to the server's media output ports. 929 Conventionally, RTSP servers send RTP packets in one direction: from 930 server to client. Symmetric RTP is similar to connection-oriented 931 traffic, where one side (e.g., the RTSP client) first "connects" by 932 sending a RTP packet to the other side's RTP port, the recipient then 933 replies to the originating IP and port. 935 Specifically, when the RTSP server receives the "connect" RTP packet 936 (a.k.a. FW packet, since it is used to punch a hole in the FW/NAT 937 and to aid the server for port binding and address mapping) from its 938 client, it copies the source IP and Port number and uses them as 939 delivery address for media packets. By having the server send media 940 traffic back the same way as the client's packet are sent to the 941 server, address mappings will be honored. Therefore this technique 942 works for all types of NATs. However, it does require server 943 modifications. Unless there is built-in protection mechanism, 944 symmetric RTP is very vulnerable to DDOS attacks, because attackers 945 can simply forge the source IP & Port of the binding packet. 947 4.3.2. Necessary RTSP extensions 949 To support symmetric RTP the RTSP signaling must be extended to allow 950 the RTSP client to indicate that it will use symmetric RTP. The 951 client also needs to be able to signal its RTP SSRC to the server in 952 its SETUP request. The RTP SSRC is used to establish some basic 953 level of security against hijacking attacks. Care must be taken in 954 choosing client's RTP SSRC. First, it must be unique within all the 955 RTP sessions belonging to the same RTSP session. Secondly, if the 956 RTSP server is sending out media packets to multiple clients from the 957 same send port, the RTP SSRC needs to be unique amongst those 958 clients' RTP sessions. Recognizing that there is a potential that 959 RTP SSRC collision may occur, the RTSP server must be able to signal 960 to client that a collision has occurred and that it wants the client 961 to use a different RTP SSRC carried in the SETUP response or use 962 unique ports per RTSP session. Using unique ports limits an RTSP 963 server in the number of session it can simultaneously handle per 964 interface IP addresses. 966 4.3.3. Deployment Considerations 968 Advantages: 970 o Works for all types of NATs, including those using multiple IP 971 addresses. (Requirement 1 in Section 3). 973 o Have no interaction problems with any RTSP ALG changing the 974 client's information in the transport header. 976 Disadvantages: 978 o Requires modifications to both RTSP server and client. 980 o Limited to work with servers that have an public IP address. 982 o The format of the RTP packet for "connection setup" (a.k.a FW 983 packet) is yet to be defined. One possibility is to use RTP No-Op 984 packet format in [I-D.ietf-avt-rtp-no-op]. 986 o Has worse security situation than STUN when using address 987 restrictions. 989 4.3.4. Security Consideration 991 Symmetric RTP's major security issue is that RTP streams can be 992 hijacked and directed towards any target that the attacker desires. 994 The most serious security problem is the deliberate attack with the 995 use of a RTSP client and symmetric RTP. The attacker uses RTSP to 996 setup a media session. Then it uses symmetric RTP with a spoofed 997 source address of the intended target of the attack. There is no 998 defense against this attack other than restricting the possible bind 999 address to be the same as the RTSP connection arrived on. This 1000 prevents symmetric RTP to be used with multi-address NATs. 1002 A hijack attack can also be performed in various ways. The basic 1003 attack is based on the ability to read the RTSP signaling packets in 1004 order to learn the address and port the server will send from and 1005 also the SSRC the client will use. Having this information the 1006 attacker can send its own NAT-traversal RTP packets containing the 1007 correct RTP SSRC to the correct address and port on the server. The 1008 destination of the packets is set as the source IP and port in these 1009 RTP packets. 1011 Another variation of this attack is for a man in the middle to modify 1012 the RTP binding packet being sent by a client to the server by simply 1013 changing the source IP to the target one desires to attack. 1015 One can fend off the first attack by applying encryption to the RTSP 1016 signaling transport. However, the second variation is impossible to 1017 defend against. As a NAT re-writes the source IP and port this 1018 cannot be authenticated, but authentication is required in order to 1019 protect against this type of DOS attack. 1021 Yet another issues is that these attacks also can be used to deny the 1022 client the service he desire from the RTSP server completely. For a 1023 man in the middle capable of reading the signalling traffic or 1024 intercepting the binding packets can completely deny the client 1025 service by modifying or originating binding packets of itself. 1027 The random SSRC tag in the binding packet determines how well 1028 symmetric RTP can fend off stream-hijacking performed by parties that 1029 are not "man-in-the-middle". This proposal uses the 32-bit RTP SSRC 1030 field to this effect. Therefore it is important that this field is 1031 derived with a non-predictable randomizer. It should not be possible 1032 by knowing the algorithm used and a couple of basic facts, to derive 1033 what random number a certain client will use. 1035 An attacker not knowing the SSRC but aware of which port numbers that 1036 a server sends from can deploy a brute force attack on the server by 1037 testing a lot of different SSRCs until it finds a matching one. 1038 Therefore a server SHOULD implement functionality that blocks ports 1039 that receive multiple FW packets (i.e. the packet that is sent to the 1040 server for FW traversal) with different invalid SSRCs, especially 1041 when they are coming from the same IP/Port. 1043 To improve the security against attackers the random tag's length 1044 could be increased. To achieve a longer random tag while still using 1045 RTP and RTCP, it will be necessary to develop RTP and RTCP payload 1046 formats for carrying the random tag. 1048 4.3.5. A Variation to Symmetric RTP 1050 Symmetric RTP requires a valid RTP format in the FW packet, which is 1051 the first packet that the client sends to the server to set up 1052 virtual RTP connection. There is currently no appropriate RTP packet 1053 format for this purpose, although the No-Op format is a proposal to 1054 fix the problem [I-D.ietf-avt-rtp-no-op]. There exist a document 1055 that discusses the implication of different type of packets as keep- 1056 alives for RTP [I-D.ietf-avt-app-rtp-keepalive] and its findings are 1057 very relevant to the FW packet. 1059 Meanwhile, there has been FW traversal techniques deployed in the 1060 wireless streaming market place that use non-RTP messages as FW 1061 packets. This section attempts to summarize a subset of those 1062 solutions that happens to use a variation to the standard symmetric 1063 RTP solution. 1065 In this variation of symmetric RTP, the FW packet is a small UDP 1066 packet that does not contain RTP header. Hence the solution can no 1067 longer be called symmetric RTP, yet it employs the same technique for 1068 FW traversal. In response to client's FW packet, RTSP server sends 1069 back a similar FW packet as a confirmation so that the client can 1070 stop the so called "connection phase" of this NAT traversal 1071 technique. Afterwards, the client only has to periodically send FW 1072 packets as keep-alive messages for the NAT mappings. 1074 The server listens on its RTP-media output port, and tries to decode 1075 any received UDP packet as FW packet. This is valid since an RTSP 1076 server is not expecting RTP traffic from the RTSP client. Then, it 1077 can correlate the FW packet with the RTSP client's session ID or the 1078 client's SSRC, and record the NAT bindings accordingly. The server 1079 then sends a FW packet as the response to the client. 1081 The FW packet can contain the SSRC to identify the RTP stream, and 1082 can be made no bigger than 12 bytes, making it distinctively 1083 different from RTP packets, whose header size is 12 bytes. 1085 RTSP signaling can be added to do the following: 1087 1. Enables or disables such FW message exchanges. When the FW/NAT 1088 has an RTSP-aware ALG, it is possible to disable FW message 1089 exchange and let ALG works out the address and port mappings. 1091 2. Configures the number of re-tries and the re-try interval of the 1092 FW message exchanges. 1094 Such FW packets may also contain digital signatures to support three- 1095 way handshake based receiver authentications, so as to prevent DDoS 1096 attacks described before. 1098 This approach has the following advantages when compared with the 1099 symmetric RTP approach: 1101 1. There is no need to define RTP payload format for FW traversal, 1102 therefore it is simple to use, implement and administer 1103 (Requirement 4 in Section 3), although a binding protocol must be 1104 defined. 1106 2. When properly defined, this kind of FW message exchange can also 1107 authenticate RTP receivers, so as to prevent DDoS attacks for 1108 dual-hosted RTSP client. By dual-hosted RTSP client we mean the 1109 kind that uses one "perceived" IP address for RTSP message 1110 exchange, and a different "perceived" IP address for RTP 1111 reception. (Requirement 5 in Section 3). 1113 This approach has the following disadvantages when compared with the 1114 symmetric RTP approach: 1116 1. RTP traffic is normally accompanied by RTCP traffic. This 1117 approach needs to rely on RTCP RRs and SRs to enable NAT 1118 traversal for RTCP endpoints, or use the same type of FW messages 1119 also for RTCP endpoints. 1121 2. The server's sender SSRC for the RTP stream must be signaled in 1122 RTSP's SETUP response, in the Transport header of the RTSP SETUP 1123 response. 1125 A solution with a 3-way handshaking and its own FW packets can be 1126 compared with ICE and have the following differencies: 1128 o Only works for servers with public IP addresses compared to any 1129 type of server 1131 o Is somewhat simpler to implement due to the avoidance of the ICE 1132 prioritization and checkboard mechanisms. 1134 However, a 3-way binding protocol is very similar to using STUN in 1135 both directions as binding protocol. Using STUN would remove the 1136 need for implementing a new protocol. 1138 4.4. Application Level Gateways 1140 4.4.1. Introduction 1142 An Application Level Gateway (ALG) reads the application level 1143 messages and performs necessary changes to allow the protocol to work 1144 through the middle box. However this behavior has some problems in 1145 regards to RTSP: 1147 1. It does not work when the RTSP protocol is used with end-to-end 1148 security. As the ALG can't inspect and change the application 1149 level messages the protocol will fail due to the middle box. 1151 2. ALGs need to be updated if extensions to the protocol are added. 1152 Due to deployment issues with changing ALGs this may also break 1153 the end-to-end functionality of RTSP. 1155 Due to the above reasons it is NOT RECOMMENDED to use an RTSP ALG in 1156 NATs. This is especially important for NATs targeted to home users 1157 and small office environments, since it is very hard to upgrade NATs 1158 deployed in home or SOHO (small office/home office) environment. 1160 4.4.2. Outline On how ALGs for RTSP work 1162 In this section, we provide a step-by-step outline on how one should 1163 go about writing an ALG to enable RTSP to traverse a NAT. 1165 1. Detect any SETUP request. 1167 2. Try to detect the usage of any of the NAT traversal methods that 1168 replace the address and port of the Transport header parameters 1169 "destination" or "dest_addr". If any of these methods are used, 1170 the ALG SHOULD NOT change the address. Ways to detect that these 1171 methods are used are: 1173 * For embedded STUN, it would be watch for a feature tag, like 1174 "nat.stun". If any of those exists in the "supported", 1175 "proxy-require", or "require" headers of the RTSP exchange. 1177 * For non-embedded STUN and TURN based solutions: This can in 1178 some case be detected by inspecting the "destination" or 1179 "dest_addr" parameter. If it contains either one of the NAT's 1180 external IP addresses or a public IP address. However if 1181 multiple NATs are used this detection may fail. Remapping 1182 should only be done for addresses belonging to the NATs own 1183 private address space. 1185 Otherwise continue to the next step. 1187 3. Create UDP mappings (client given IP/port <-> external IP/port) 1188 where needed for all possible transport specification in the 1189 transport header of the request found in (1). Enter the public 1190 address and port(s) of these mappings in transport header. 1191 Mappings SHALL be created with consecutive public port number 1192 starting on an even number for RTP for each media stream. 1193 Mappings SHOULD also be given a long timeout period, at least 5 1194 minutes. 1196 4. When the SETUP response is received from the server the ALG MAY 1197 remove the unused UDP mappings, i.e. the ones not present in the 1198 transport header. The session ID SHOULD also be bound to the UDP 1199 mappings part of that session. 1201 5. If SETUP response settles on RTP over TCP or RTP over RTSP as 1202 lower transport, do nothing: let TCP tunneling to take care of 1203 NAT traversal. Otherwise go to next step. 1205 6. The ALG SHOULD keep alive the UDP mappings belonging to the an 1206 RTSP session as long as: RTSP messages with the session's ID has 1207 been sent in the last timeout interval, or UDP messages are sent 1208 on any of the UDP mappings during the last timeout interval. 1210 7. The ALG MAY remove a mapping as soon a TEARDOWN response has been 1211 received for that media stream. 1213 4.4.3. Deployment Considerations 1215 Advantage: 1217 o No impact on either client or server 1219 o Can work for any type of NATs 1221 Disadvantage: 1223 o When deployed they are hard to update to reflect protocol 1224 modifications and extensions. If not updated they will break the 1225 functionality. 1227 o When end-to-end security is used the ALG functionality will fail. 1229 o Can interfere with other type of traversal mechanisms, such as 1230 STUN. 1232 Transition: 1234 An RTSP ALG will not be phased out in any automatically way. It must 1235 be removed, probably through the removal of the NAT it is associated 1236 with. 1238 4.4.4. Security Considerations 1240 An ALG will not work when deployment of end-to-end RTSP signaling 1241 security. Therefore deployment of ALG will likely result in that 1242 clients located behind NATs will not use end-to-end security. 1244 4.5. TCP Tunneling 1246 4.5.1. Introduction 1248 Using a TCP connection that is established from the client to the 1249 server ensures that the server can send data to the client. The 1250 connection opened from the private domain ensures that the server can 1251 send data back to the client. To send data originally intended to be 1252 transported over UDP requires the TCP connection to support some type 1253 of framing of the media data packets. Using TCP also results in that 1254 the client has to accept that real-time performance may no longer be 1255 possible. TCP's problem of ensuring timely deliver was the reasons 1256 why RTP was developed. Problems that arise with TCP are: head-of- 1257 line blocking, delay introduced by retransmissions, highly varying 1258 rate due to the congestion control algorithm. 1260 4.5.2. Usage of TCP tunneling in RTSP 1262 The RTSP core specification [I-D.ietf-mmusic-rfc2326bis] supports 1263 interleaving of media data on the TCP connection that carries RTSP 1264 signaling. See section 14 in [I-D.ietf-mmusic-rfc2326bis] for how to 1265 perform this type of TCP tunneling. There also exist another way of 1266 transporting RTP over TCP defined in Appendix . For signaling and 1267 rules on how to establish the TCP connection in lieu of UDP, see 1268 appendix C.2 in [I-D.ietf-mmusic-rfc2326bis]. This is based on the 1269 framing of RTP over the TCP connection as described in RFC 4571 1270 [RFC4571]. 1272 4.5.3. Deployment Considerations 1274 Advantage: 1276 o Works through all types of NATs where server is in the open. 1278 Disadvantage: 1280 o Functionality needs to be implemented on both server and client. 1282 o Will not always meet multimedia stream's real-time requirements. 1284 Transition: 1286 The tunneling over RTSP's TCP connection is not planned to be phased 1287 -out. It is intended to be a fallback mechanism and for usage when 1288 total media reliability is desired, even at the price of loss of 1289 real-time properties. 1291 4.5.4. Security Considerations 1293 The TCP tunneling of RTP has no known security problem besides those 1294 already presented in the RTSP specification. It is not possible to 1295 get any amplification effect that is desired for denial of service 1296 attacks due to TCP's flow control. A possible security 1297 consideration, when session media data is interleaved with RTSP, 1298 would be the performance bottleneck when RTSP encryption is applied, 1299 since all session media data also needs to be encrypted. 1301 4.6. TURN (Traversal Using Relay NAT) 1303 4.6.1. Introduction 1305 Traversal Using Relay NAT (TURN) [I-D.ietf-behave-turn] is a protocol 1306 for setting up traffic relays that allows clients behind NATs and 1307 firewalls to receive incoming traffic for both UDP and TCP. These 1308 relays are controlled and have limited resources. They need to be 1309 allocated before usage. TURN allows a client to temporarily bind an 1310 address/port pair on the relay (TURN server) to its local source 1311 address/port pair, which is used to contact the TURN server. The 1312 TURN server will then forward packets between the two sides of the 1313 relay. To prevent DOS attacks on either recipient, the packets 1314 forwarded are restricted to the specific source address. On the 1315 client side it is restricted to the source setting up the mapping. 1316 On the external side this is limited to the source address/port pair 1317 of the first packet arriving on the binding. After the first packet 1318 has arrived the mapping is "locked down" to that address. Packets 1319 from any other source on this address will be discarded. Using a 1320 TURN server makes it possible for a RTSP client to receive media 1321 streams from even an unmodified RTSP server. However the problem is 1322 those RTSP servers most likely restrict media destinations to no 1323 other IP address than the one RTSP message arrives. This means that 1324 TURN could only be used if the server knows and accepts that the IP 1325 belongs to a TURN server and the TURN server can't be targeted at an 1326 unknown address. Unfortunately TURN servers can be targeted at any 1327 host that has a public IP address by spoofing the source IP of TURN 1328 Allocation requests. 1330 4.6.2. Usage of TURN with RTSP 1332 To use a TURN server for NAT traversal, the following steps should be 1333 performed. 1335 1. The RTSP client connects with RTSP server. The client retrieves 1336 the session description to determine the number of media streams. 1337 To avoid the issue with having RTSP connection and media traffic 1338 from different addresses also the TCP connection must be done 1339 through the same TURN server as the one in the next step. 1341 2. The client establishes the necessary bindings on the TURN server. 1342 It must choose the local RTP and RTCP ports that it desires to 1343 receive media packets. TURN supports requesting bindings of even 1344 port numbers and continuous ranges. 1346 3. The RTSP client uses the acquired address and port mappings in 1347 the RTSP SETUP request using the destination header. Note that 1348 the server is required to have a mechanism to verify that it is 1349 allowed to send media traffic to the given address. The server 1350 SHOULD include its RTP SSRC in the SETUP response. 1352 4. Client requests that the Server starts playing. The server 1353 starts sending media packet to the given destination address and 1354 ports. 1356 5. The first media packet to arrive at the TURN server on the 1357 external port causes "lock down"; then TURN server forwards the 1358 media packets to the RTSP client. 1360 6. When media arrives at the client, the client should try to verify 1361 that the media packets are from the correct RTSP server, by 1362 matching the RTP SSRC of the packet. Source IP address of this 1363 packet will be that of the TURN server and can therefore not be 1364 used to verify that the correct source has caused lock down. 1366 7. If the client notices that some other source has caused lock down 1367 on the TURN server, the client should create new bindings and 1368 change the session transport parameters to reflect the new 1369 bindings. 1371 8. If the client pauses and media are not sent for about 75% of the 1372 mapping timeout the client should use TURN to refresh the 1373 bindings. 1375 4.6.3. Deployment Considerations 1377 Advantages: 1379 o Does not require any server modifications. 1381 o Works for any types of NAT as long as the server has public 1382 reachable IP address. 1384 Disadvantage: 1386 o Requires another network element, namely the TURN server. 1388 o A TURN server for RTSP is may not scale since the number of 1389 sessions it must forward is proportional to the number of client 1390 media sessions. 1392 o TURN server becomes a single point of failure. 1394 o Since TURN forwards media packets, it necessarily introduces 1395 delay. 1397 o Requires that the server can verify that the given destination 1398 address is valid to be used by the client. 1400 o An RTSP ALG MAY change the necessary destinations parameter. This 1401 will cause the media traffic to be sent to the wrong address. 1403 Transition: 1405 TURN is not intended to be phase-out completely, see chapter 11.2 of 1406 [I-D.ietf-behave-turn]. However the usage of TURN could be reduced 1407 when the demand for having NAT traversal is reduced. 1409 4.6.4. Security Considerations 1411 An eavesdropper of RTSP messages between the RTSP client and RTSP 1412 server will be able to do a simple denial of service attack on the 1413 media streams by sending messages to the destination address and port 1414 present in the RTSP SETUP messages. If the attacker's message can 1415 reach the TURN server before the RTSP server's message, the lock down 1416 can be accomplished towards some other address. This will result in 1417 that the TURN server will drop all the media server's packets when 1418 they arrive. This can be accomplished with little risk for the 1419 attacker of being caught, as it can be performed with a spoofed 1420 source IP. The client may detect this attack when it receives the 1421 lock down packet sent by the attacker as being mal-formatted and not 1422 corresponding to the expected context. It will also notice the lack 1423 of incoming packets. See bullet 7 in Section 4.6.2. 1425 The TURN server can also become part of a denial of service attack 1426 towards any victim. To perform this attack the attacker must be able 1427 to eavesdrop on the packets from the TURN server towards a target for 1428 the DOS attack. The attacker uses the TURN server to setup a RTSP 1429 session with media flows going through the TURN server. The attacker 1430 is in fact creating TURN mappings towards a target by spoofing the 1431 source address of TURN requests. As the attacker will need the 1432 address of these mappings he must be able to eavesdrop or intercept 1433 the TURN responses going from the TURN server to the target. Having 1434 these addresses, he can set up a RTSP session and starts delivery of 1435 the media. The attacker must be able to create these mappings. The 1436 attacker in this case may be traced by the TURN username in the 1437 mapping requests. 1439 The first attack can be made very hard by applying transport security 1440 for the RTSP messages, which will hide the TURN servers address and 1441 port numbers from any eavesdropper. 1443 The second attack requires that the attacker have access to a user 1444 account on the TURN server to be able set up the TURN mappings. To 1445 prevent this attack the server shall verify that the target 1446 destination accept this media stream. 1448 5. Firewalls 1450 Firewalls exist for the purpose of protecting a network from traffic 1451 not desired by the firewall owner. Therefore it is a policy decision 1452 if a firewall will let RTSP and its media streams through or not. 1453 RTSP is designed to be firewall friendly in that it should be easy to 1454 design firewall policies to permit passage of RTSP traffic and its 1455 media streams. 1457 The firewall will need to allow the media streams associated with a 1458 RTSP session pass through it. Therefore the firewall will need an 1459 ALG that reads RTSP SETUP and TEARDOWN messages. By reading the 1460 SETUP message the firewall can determine what type of transport and 1461 from where the media streams will use. Commonly there will be the 1462 need to open UDP ports for RTP/RTCP. By looking at the source and 1463 destination addresses and ports the opening in the firewall can be 1464 minimized to the least necessary. The opening in the firewall can be 1465 closed after a TEARDOWN message for that session or the session 1466 itself times out. 1468 Simpler firewalls do allow a client to receive media as long as it 1469 has sent packets to the target. Depending on the security level this 1470 can have the same behavior as a NAT. The only difference is that no 1471 address translation is done. To be able to use such a firewall a 1472 client would need to implement one of the above described NAT 1473 traversal methods that include sending packets to the server to open 1474 up the mappings. 1476 6. Comparision of NAT traversal techniques 1478 This section evaluates the techniques described above against the 1479 requirements listed in section Section 3. 1481 In the following table, the columns correspond to the numbered 1482 requirements. For instance, the column under R1 corresponds to the 1483 first requirement in section Section 3: MUST work for all flavors of 1484 NATs. The rows represent the different FW traversal techniques. 1485 SymRTP is short for symmetric RTP, "V.SymRTP" is short for "variation 1486 of symmetric RTP" as described in section Section 4.3.5. 1488 A Summary of the requirements are: 1490 R1 Work for all flavors of NATs 1492 R2 Most work with Firewalls, including them with ALGs 1494 R3 Should have minimal impact on clients not behind NATs 1496 R4 Should be simple to use, Implement and administrate. 1498 R5 Should provide a mitigation against DDoS attacks 1499 -----------------------------------------------+ 1500 | R1 | R2 | R3 | R4 | R5 | 1501 ------------+------+------+------+------+------+ 1502 STU | Yes | Yes | No | Maybe| No | 1503 ------------+------+------+------+------+------+ 1504 ICE | Yes | Yes | No | No | Yes | 1505 ------------+------+------+------+------+------+ 1506 SymRTP | Yes | Yes | Yes |Maybe | No | 1507 ------------+------+------+------+------+------+ 1508 V. SymRTP | Yes | Yes | Yes | Yes |future| 1509 ------------+------+------+------+------+------+ 1510 3-W SymRTP | Yes | Yes | Yes | Maybe| Yes | 1511 ------------+------+------+------+------+------+ 1512 TURN | Yes | Yes | No | No | Yes | 1513 ------------------------------------------------ 1514 The different techniques was discussed in the MMUSIC WG. It was 1515 established that the WG would pursue an ICE based solution due to its 1516 generality and capability of handle also servers delivering media 1517 from behind NATs. There has been some discussion if the increased 1518 implementation burden of ICE is motivated compared to a 3-W SymRTP 1519 solution for this generality. 1521 7. IANA Considerations 1523 This document makes no request of IANA. 1525 Note to RFC Editor: this section may be removed on publication as an 1526 RFC. 1528 8. Security Considerations 1530 In preceding sessions we have discussed security merits of each and 1531 every NAT/FW traversal methods for RTSP discussed here. In summary, 1532 the presence of NAT(s) is a security risk, as a client cannot perform 1533 source authentication of its IP address. This prevents the 1534 deployment of any future RTSP extensions providing security against 1535 hijacking of sessions by a man-in-the-middle. 1537 Each of the proposed solutions has security implications. Using STUN 1538 will provide the same level of security as RTSP with out transport 1539 level security and source authentications; as long as the server does 1540 not grant a client request to send media to different IP addresses. 1541 Using symmetric RTP will have a higher risk of session hijacking or 1542 denial of service than normal RTSP. The reason is that there exists 1543 a probability that an attacker is able to guess the random tag that 1544 the client uses to prove its identity when creating the address 1545 bindings. This can be solved in the variation of symmetric RTP 1546 (section 6.3.5) with authentication features. The usage of an RTSP 1547 ALG does not increase in itself the risk for session hijacking. 1548 However the deployment of ALGs as sole mechanism for RTSP NAT 1549 traversal will prevent deployment of encrypted end-to-end RTSP 1550 signaling. The usage of TCP tunneling has no known security 1551 problems. However it might provide a bottleneck when it comes to 1552 end-to-end RTSP signaling security if TCP tunneling is used on an 1553 interleaved RTSP signaling connection. The usage of TURN has severe 1554 risk of denial of service attacks against a client. The TURN server 1555 can also be used as a redirect point in a DDOS attack unless the 1556 server has strict enough rules for who may create bindings. 1558 9. Acknowledgements 1560 The author would also like to thank all persons on the MMUSIC working 1561 group's mailing list that has commented on this document. Persons 1562 having contributed in such way in no special order to this protocol 1563 are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon, 1564 Amir Wolf, Anders Klemets, and Colin Perkins. Thomas Zeng would also 1565 like to give special thanks to Greg Sherwood of PacketVideo for his 1566 input into this memo. 1568 Section Section 1.1 contains text originally written for RFC 4787 by 1569 Francois Audet and Cullen Jennings. 1571 10. Informative References 1573 [I-D.ietf-avt-app-rtp-keepalive] 1574 Marjou, X. and A. Sollaud, "Application Mechanism for 1575 maintaining alive the Network Address Translator (NAT) 1576 mappings associated to RTP flows.", 1577 draft-ietf-avt-app-rtp-keepalive-07 (work in progress), 1578 December 2009. 1580 [I-D.ietf-avt-rtp-no-op] 1581 Andreasen, F., "A No-Op Payload Format for RTP", 1582 draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. 1584 [I-D.ietf-behave-turn] 1585 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 1586 Relays around NAT (TURN): Relay Extensions to Session 1587 Traversal Utilities for NAT (STUN)", 1588 draft-ietf-behave-turn-16 (work in progress), July 2009. 1590 [I-D.ietf-mmusic-ice] 1591 Rosenberg, J., "Interactive Connectivity Establishment 1592 (ICE): A Protocol for Network Address Translator (NAT) 1593 Traversal for Offer/Answer Protocols", 1594 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1596 [I-D.ietf-mmusic-rfc2326bis] 1597 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1598 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1599 (RTSP)", draft-ietf-mmusic-rfc2326bis-22 (work in 1600 progress), July 2009. 1602 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1603 August 1980. 1605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1606 Requirement Levels", BCP 14, RFC 2119, March 1997. 1608 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1609 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1611 [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, 1612 May 1999. 1614 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1615 Translator (NAT) Terminology and Considerations", 1616 RFC 2663, August 1999. 1618 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1619 Address Translator (Traditional NAT)", RFC 3022, 1620 January 2001. 1622 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 1623 Schulzrinne, "Grouping of Media Lines in the Session 1624 Description Protocol (SDP)", RFC 3388, December 2002. 1626 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1627 Self-Address Fixing (UNSAF) Across Network Address 1628 Translation", RFC 3424, November 2002. 1630 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1631 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1632 Through Network Address Translators (NATs)", RFC 3489, 1633 March 2003. 1635 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1636 Jacobson, "RTP: A Transport Protocol for Real-Time 1637 Applications", STD 64, RFC 3550, July 2003. 1639 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1640 Description Protocol", RFC 4566, July 2006. 1642 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1643 and RTP Control Protocol (RTCP) Packets over Connection- 1644 Oriented Transport", RFC 4571, July 2006. 1646 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1647 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1648 RFC 4787, January 2007. 1650 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1651 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1652 October 2008. 1654 [STUN-IMPL] 1655 "Open Source STUN Server and Client, http:// 1656 www.vovida.org/applications/downloads/stun/index.html", 1657 June 2007. 1659 Authors' Addresses 1661 Magnus Westerlund 1662 Ericsson 1663 Farogatan 6 1664 Stockholm, SE-164 80 1665 Sweden 1667 Phone: +46 8 719 0000 1668 Fax: 1669 Email: magnus.westerlund@ericsson.com 1670 URI: 1672 Thomas Zeng 1674 Phone: 1675 Fax: 1676 Email: thomas.zeng@gmail.com 1677 URI: