idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-evaluation-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 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 (March 14, 2011) is 4785 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-27 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- 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 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 9 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: September 15, 2011 March 14, 2011 7 The Evaluation of Different Network Addres Translator (NAT) Traversal 8 Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) 9 draft-ietf-mmusic-rtsp-nat-evaluation-03 11 Abstract 13 This document describes several Network Address Translator (NAT) 14 traversal techniques that was considered to be used by Real-time 15 Streaming Protocol (RTSP). Each technique includes a description on 16 how it would be used, the security implications of using it and any 17 other deployment considerations it has. There are also disussions on 18 how NAT traversal techniques relates to firewalls and how each 19 technique can be applied in different use cases. These findings 20 where used when selecting the NAT traversal for RTSP 2.0 standardized 21 in the MMUSIC WG. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 15, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1.1. Network Address Translators . . . . . . . . . . . . . . . 6 71 1.2. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 74 2. Detecting the loss of NAT mappings . . . . . . . . . . . . . . 8 75 3. Requirements on NAT-Traversal . . . . . . . . . . . . . . . . 9 76 4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . . 10 77 4.1. STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 11 79 4.1.2. Using STUN to traverse NAT without server 80 modifications . . . . . . . . . . . . . . . . . . . . 11 81 4.1.3. Embedding STUN in RTSP . . . . . . . . . . . . . . . . 13 82 4.1.4. Discussion On Co-located STUN Server . . . . . . . . . 14 83 4.1.5. ALG considerations . . . . . . . . . . . . . . . . . . 15 84 4.1.6. Deployment Considerations . . . . . . . . . . . . . . 15 85 4.1.7. Security Considerations . . . . . . . . . . . . . . . 17 86 4.2. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 18 88 4.2.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 19 89 4.2.3. Implementation burden of ICE . . . . . . . . . . . . . 20 90 4.2.4. Deployment Considerations . . . . . . . . . . . . . . 21 91 4.2.5. Security Consideration . . . . . . . . . . . . . . . . 21 92 4.3. Symmetric RTP . . . . . . . . . . . . . . . . . . . . . . 21 93 4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 22 94 4.3.2. Necessary RTSP extensions . . . . . . . . . . . . . . 22 95 4.3.3. Deployment Considerations . . . . . . . . . . . . . . 22 96 4.3.4. Security Consideration . . . . . . . . . . . . . . . . 23 97 4.3.5. A Variation to Symmetric RTP . . . . . . . . . . . . . 24 98 4.4. Application Level Gateways . . . . . . . . . . . . . . . . 26 99 4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 26 100 4.4.2. Outline On how ALGs for RTSP work . . . . . . . . . . 27 101 4.4.3. Deployment Considerations . . . . . . . . . . . . . . 28 102 4.4.4. Security Considerations . . . . . . . . . . . . . . . 28 103 4.5. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 28 104 4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . . 28 105 4.5.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . . 29 106 4.5.3. Deployment Considerations . . . . . . . . . . . . . . 29 107 4.5.4. Security Considerations . . . . . . . . . . . . . . . 29 108 4.6. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . . 30 109 4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 30 110 4.6.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 30 111 4.6.3. Deployment Considerations . . . . . . . . . . . . . . 31 112 4.6.4. Security Considerations . . . . . . . . . . . . . . . 32 113 5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 33 114 6. Comparision of NAT traversal techniques . . . . . . . . . . . 33 115 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 116 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 117 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 118 10. Informative References . . . . . . . . . . . . . . . . . . . . 35 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 121 1. Introduction 123 Today there is a proliferate deployment of different flavors of 124 Network Address Translator (NAT) boxes that in many cases only 125 loosely follows standards [RFC3022][RFC2663][RFC3424]]. NATs cause 126 discontinuity in address realms [RFC3424], therefore an application 127 protocol, such as Real-time Streaming Protocol (RTSP) 128 [RFC2326][I-D.ietf-mmusic-rfc2326bis], needs to deal with such 129 discontinuities caused by NATs. The problem is that, being a media 130 control protocol managing one or more media streams, RTSP carries 131 network address and port information within its protocol messages. 132 Because of this, even if RTSP itself, when carried over Transmission 133 Control Protocol (TCP) [RFC0793] for example, may not be blocked by 134 NATs, its media streams may be blocked by NATs. This will occur 135 unless special protocol provisions are added to support NAT- 136 traversal. 138 Like NATs, firewalls (FWs) are also middle boxes that need to be 139 considered. Firewalls helps prevent unwanted traffic from getting in 140 or out of the protected network. RTSP is designed such that a 141 firewall can be configured to let RTSP controlled media streams to go 142 through with minimal implementation effort. The minimal effort is to 143 implement an Application Level Gateway (ALG) to interpret RTSP 144 parameters. There is also a large class of firewalls, commonly home 145 firewalls, that uses a similar filtering behavior to what NAT has. 146 This type of firewalls can be handled using the same solution as 147 employed for NAT traversal instead of relying on ALGs. 149 This document describes several NAT-traversal mechanisms for RTSP 150 controlled media streaming. These NAT solutions fall into the 151 category of "UNilateral Self-Address Fixing (UNSAF)" as defined in 152 [RFC3424] and quoted below: 154 "UNSAF is a process whereby some originating process attempts to 155 determine or fix the address (and port) by which it is known - e.g. 156 to be able to use address data in the protocol exchange, or to 157 advertise a public address from which it will receive connections." 159 Following the guidelines spelled out in RFC 3424, we describe the 160 required RTSP protocol extensions for each method, transition 161 strategies, and security concerns. 163 This document is capturing the evaluation done in the process to 164 recommend FW/NAT traversal methods for RTSP streaming servers based 165 on RFC 2326 [RFC2326] as well as the RTSP 2.0 core spec 166 [I-D.ietf-mmusic-rfc2326bis]. The evaluation is focused on NAT 167 traversal for the media streams carried over User Datagram Protocol 168 (UDP) [RFC0768]. Where Real-time Transport Protocol (RTP) [RFC3550] 169 over UDP being the main case for such usage. The findings should be 170 applicable to other protocols as long as they have similar 171 properties. 173 1.1. Network Address Translators 175 Readers are urged to refer to "IP Network Address Translator (NAT) 176 Terminology and Considerations" [RFC2663] for information on NAT 177 taxonomy and terminology. Traditional NAT is the most common type of 178 NAT device deployed. Readers may refer to "Traditional IP Network 179 Address Translator (Traditional NAT)" [RFC3022] for detailed 180 information on traditional NAT. Traditional NAT has two main 181 varieties -- Basic NAT and Network Address/Port Translator (NAPT). 183 NAPT is by far the most commonly deployed NAT device. NAPT allows 184 multiple internal hosts to share a single public IP address 185 simultaneously. When an internal host opens an outgoing TCP or UDP 186 session through a NAPT, the NAPT assigns the session a public IP 187 address and port number, so that subsequent response packets from the 188 external endpoint can be received by the NAPT, translated, and 189 forwarded to the internal host. The effect is that the NAPT 190 establishes a NAT mapping to translate the (private IP address, 191 private port number) tuple to a (public IP address, public port 192 number) tuple, and vice versa, for the duration of the session. An 193 issue of relevance to peer-to-peer applications is how the NAT 194 behaves when an internal host initiates multiple simultaneous 195 sessions from a single (private IP, private port) endpoint to 196 multiple distinct endpoints on the external network. In this 197 specification, the term "NAT" refers to both "Basic NAT" and "Network 198 Address/Port Translator (NAPT)". 200 This document uses the term "address and port mapping" as the 201 translation between an external address and port and an internal 202 address and port. Note that this is not the same as an "address 203 binding" as defined in RFC 2663. There exist a number of address and 204 port mapping behaviors described in more detail in Section 4.1 of 205 "Network Address Translation (NAT) Behavioral Requirements for 206 Unicast UDP" [RFC4787]. 208 NATs also have a filtering behavior on traffic arriving on the 209 external side. Such behavior effects how well different methods for 210 NAT traversal works through these NATs. See Section 5 of "Network 211 Address Translation (NAT) Behavioral Requirements for Unicast UDP" 212 [RFC4787] for more information on the different types of filtering 213 that have been identified. 215 1.2. Firewalls 217 A firewall (FW) is a security gateway that enforces certain access 218 control policies between two network administrative domains: a 219 private domain (intranet) and a external domain, e.g. public 220 Internet. Many organizations use firewalls to prevent privacy 221 intrusions and malicious attacks to corporate computing resources in 222 the private intranet [RFC2588]. 224 A comparison between NAT and FW is given below: 226 1. A firewall must sit between two network administrative domains, 227 while NAT does not have to sit between two domains. 229 2. NAT does not in itself provide security, although some access 230 control policies can be implemented using address translation 231 schemes. The inherent filtering behaviours are commonly mistaken 232 for real security policies. 234 It should be noted that many NAT devices intended for small office/ 235 home office (SOHO) include both NATs and firewall functionality. 237 In the rest of this memo we use the phrase "NAT traversal" 238 interchangeably with "FW traversal", "NAT/FW traversal" and "NAT/ 239 Firewall traversal". 241 1.3. Glossary 243 ALG: Application Level Gateway, an entity that can be embedded in a 244 NAT or other middlebox to perform the application layer 245 functions required for a particular protocol to traverse the 246 NAT/middlebox. 248 ICE: Interactive Connectivity Establishment, see [RFC5245]. 250 DNS: Domain Name Service 252 DDOS: Distributed Denial Of Service attacks 254 NAT: Network Address Translator, see [RFC3022]. 256 NAPT: Network Address/Port Translator, see [RFC3022]. 258 RTP: Real-time Transport Protocol, see [RFC3550]. 260 RTSP: Real-Time Streaming Protocol, see [RFC2326] and 261 [I-D.ietf-mmusic-rfc2326bis]. 263 SDP: Session Description Protocol, see [RFC4566]. 265 SSRC: Synchronization source in RTP, see [RFC3550]. 267 1.4. Definitions 269 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 270 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 271 "OPTIONAL" in this document are to be interpreted as described in RFC 272 2119 [RFC2119]. 274 2. Detecting the loss of NAT mappings 276 Several NAT traversal techniques in the next chapter make use of the 277 fact that the NAT UDP mapping's external address and port can be 278 discovered. This information is then utilized to traverse the NAT 279 box. However any such information is only good while the mapping is 280 still valid. As the IAB's UNSAF document [RFC3424] points out, the 281 mapping can either timeout or change its properties. It is therefore 282 important for the NAT traversal solutions to handle the loss or 283 change of NAT mappings, according to RFC3424. 285 First, since NATs may also dynamically reclaim or readjust address/ 286 port translations, "keep-alive" and periodic re-polling may be 287 required according to RFC 3424. Secondly, it is possible to detect 288 and recover from the situation where the mapping has been changed or 289 removed. The loss of a mapping can be detected when no traffic 290 arrives for a while. Below we will give some recommendation on how 291 to detect loss of NAT mappings when using RTP/RTCP under RTSP 292 control. 294 A RTP session normally has both RTP and RTCP streams. The loss of a 295 RTP mapping can only be detected when expected traffic does not 296 arrive. If a client does not receive data within a few seconds after 297 having received the "200 OK" response to a PLAY request, there are 298 likely some middleboxes blocking the traffic. However, for a 299 receiver to be more certain to detect the case where no RTP traffic 300 was delivered due to NAT trouble, one should monitor the RTCP Sender 301 reports. The sender report carries a field telling how many packets 302 the server has sent. If that has increased and no RTP packets has 303 arrived for a few seconds it is likely the RTP mapping has been 304 removed. 306 The loss of mapping for RTCP is simpler to detect. RTCP is normally 307 sent periodically in each direction, even during the RTSP ready 308 state. If RTCP packets are missing for several RTCP intervals, the 309 mapping is likely to be lost. Note that if neither RTCP packets nor 310 RTSP messages are received by the RTSP server for a while, the RTSP 311 server has the option to delete the corresponding RTP session, SSRC 312 and RTSP session ID, because either the client can not get through a 313 middle box NAT/FW, or that the client is mal-functioning. 315 3. Requirements on NAT-Traversal 317 This section considers the set of requirements for the evaulation of 318 RTSP NAT traversal solutions. 320 RTSP is a client-server protocol. Typically services providers 321 deploy RTSP servers in the public address realm. However, there are 322 use cases where the reverse is true: RTSP clients are connecting from 323 public address realm to RTSP servers behind home NATs. This is the 324 case for instance when home surveillance cameras running as RTSP 325 servers intend to stream video to cell phone users in the public 326 address realm through a home NAT. In terms of requirements, the 327 first requirement should be to solve the RTSP NAT traversal problem 328 for RTSP servers deployed in a public network, i.e. no NAT at the 329 server side. 331 The list of feature requirements for RTSP NAT solutions are given 332 below: 334 1. MUST work for all flavors of NATs, including NATs with address 335 and port restricted filtering. 337 2. MUST work for firewalls (subject to pertinent firewall 338 administrative policies), including those with ALGs. 340 3. SHOULD have minimal impact on clients in the open and not dual- 341 hosted. RTSP dual-hosting means that RTSP protocol and the media 342 protocol (e.g. RTP) are implemented on different computers with 343 different IP addresses. 345 * For instance, no extra delay from RTSP connection till arrival 346 of media 348 4. SHOULD be simple to use/implement/administer that people actually 349 turn them on 351 * Otherwise people will resort to TCP tunneling through NATs 352 * Address discovery for NAT traversal should take place behind 353 the scene, if possible 355 5. SHOULD authenticate dual-hosted client transport handler to 356 prevent DDOS attacks. 358 The last requirement addresses the Distributed Denial-Of-Service 359 (DDOS) threat, which relates to NAT traversal as explained below. 361 During NAT traversal, when the RTSP server determines the media 362 destination (Address and port) for client, the result may be that the 363 public IP address of the RTP receiver host is different than the 364 public IP address of the RTSP client host. This posts a DDOS threat 365 that has significant amplification potentials because the RTP media 366 streams in general consist of large number of IP packets. DDOS 367 attacks occur if the attacker fakes the messages in the NAT traversal 368 mechanism to trick the RTSP server into believing that the client's 369 RTP receiver is located in a separate host. For example, user A may 370 use his RTSP client to direct the RTSP server to send video RTP 371 streams to target.example.com in order to degrade the services 372 provided by target.example.com. Note a simple preventative measure 373 is for the RTSP server to disallow the cases where the client's RTP 374 receiver has a different public IP address than that of the RTSP 375 client. However, in some applications (e.g., centralized 376 conferencing), dual-hosted RTSP/RTP clients have valid use cases. 377 The key is how to authenticate the messages exchanged during the NAT 378 traversal process. Message authentication is a big challenge in the 379 current wired and wireless networking environment. It may be 380 necessary in the immediate future to deploy NAT traversal solutions 381 that do not have full message authentication, but provide upgrade 382 path to add authentication features in the future. 384 4. NAT Traversal Techniques 386 There exist a number of potential NAT traversal techniques that can 387 be used to allow RTSP to traverse NATs. They have different features 388 and are applicable to different topologies; their cost is also 389 different. They also vary in security levels. In the following 390 sections, each technique is outlined in details with discussions on 391 the corresponding advantages and disadvantages. 393 This section includes NAT traversal techniques that have not been 394 formally specified anywhere else. The overview section of this 395 document may be the only publicly available specification of some of 396 the NAT traversal techniques. However that is no real barrier 397 against doing an evaluation of the NAT traversal technique. Some 398 other techniques are currently (at the time of writing) in a state of 399 flux due to ongoing standardization work on these techniques, e.g. 400 RTP No-Op [I-D.ietf-avt-rtp-no-op]. 402 4.1. STUN 404 4.1.1. Introduction 406 STUN - "Simple Traversal of UDP Through Network Address Translators" 407 [RFC3489][RFC5389] is a standardized protocol that allows a client to 408 use secure means to discover the presence of a NAT between himself 409 and the STUN server. The client uses the STUN server to discover the 410 address mappings assigned by the NAT. STUN is a client-server 411 protocol. STUN client sends a request to a STUN server and the 412 server returns a response. There are two types of STUN requests - 413 Binding Requests, sent over UDP, and Shared Secret Requests, sent 414 over TLS over TCP. 416 The first version of STUN [RFC3489] included categorization and 417 parameterization of NATs. This was abandoned in the updated version 418 due to it being unreliable. 420 4.1.2. Using STUN to traverse NAT without server modifications 422 This section describes how a client can use STUN to traverse NATs to 423 RTSP servers without requiring server modifications. Note that this 424 method has limited applicability and requires the server to be 425 available in the external/public address realm in regards to the 426 client located behind a NAT(s). 428 Limitations: 430 o The server must be located in either a public address realm or the 431 next hop external address realm in regards to the client. 433 o The client may only be located behind NATs that performing 434 Endpoint Independent or Address Dependent Mappings. Clients 435 behind NATs that do Address and Port Dependent Mappings cannot use 436 this method. 438 Method: 440 A RTSP client using RTP transport over UDP can use STUN to traverse a 441 NAT(s) in the following way: 443 1. Use STUN to try to discover the type of NAT, and the timeout 444 period for any UDP mapping on the NAT. This is RECOMMENDED to be 445 performed in the background as soon as IP connectivity is 446 established. If this is performed prior to establishing a 447 streaming session the delays in the session establishment will be 448 reduced. If no NAT is detected, normal SETUP SHOULD be used. 450 2. The RTSP client determines the number of UDP ports needed by 451 counting the number of needed media transport protocols sessions 452 in the multi-media presentation. This information is available 453 in the media description protocol, e.g. SDP [RFC4566]. For 454 example, each RTP session will in general require two UDP ports, 455 one for RTP, and one for RTCP. 457 3. For each UDP port required, establish a mapping and discover the 458 public/external IP address and port number with the help of the 459 STUN server. A successful mapping looks like: client's local 460 address/port <-> public address/port. 462 4. Perform the RTSP SETUP for each media. In the transport header 463 the following parameter SHOULD be included with the given values: 464 "dest_addr" [I-D.ietf-mmusic-rfc2326bis] or "destination" + 465 "client_port" [RFC2326] with the public/external IP address and 466 port pair for both RTP and RTCP. To be certain that this works 467 servers must allow a client to setup the RTP stream on any port, 468 not only even ports and with non-continuous port numbers for RTP 469 and RTCP. This requires the new feature provided in the update 470 to RFC2326 [I-D.ietf-mmusic-rfc2326bis]. The server should 471 respond with a transport header containing an "src_addr" or 472 "source parameter" + "server_port" with the RTP and RTCP source 473 IP address and port of the media stream. 475 5. To keep the mappings alive, the client SHOULD periodically send 476 UDP traffic over all mappings needed for the session. For the 477 mapping carrying RTCP traffic the periodic RTCP traffic may be 478 enough. For mappings carrying RTP traffic and for mappings 479 carrying RTCP packets at too low a frequency, keep-alive messages 480 SHOULD be sent. As keep alive messages, one could use the RTP 481 No-Op packet [I-D.ietf-avt-rtp-no-op] to the streaming server's 482 discard port (port number 9). The drawback of using RTP No-Op is 483 that the payload type number must be dynamically assigned through 484 RTSP first. Otherwise STUN could be used for the keep-alive as 485 well as empty UDP packets. 487 If a UDP mapping is lost, the above discovery process must be 488 repeated. The media stream also needs to be SETUP again to change 489 the transport parameters to the new ones. This will cause a glitch 490 in media playback. 492 To allow UDP packets to arrive from the server to a client behind a 493 "Address Dependent" filtering NAT, the client must first send a UDP 494 packet to establish filtering state in the NAT. The client, before 495 sending a RTSP PLAY request, must send a so called FW packet (such as 496 a RTP No-Op packet) on each mapping, to the IP address given as the 497 servers source address. To create minimum problems for the server 498 these UDP packets SHOULD be sent to the server's discard port (port 499 number 9). Since UDP packets are inherently unreliable, to ensure 500 that at least one UDP message passes the NAT, FW packets should be 501 retransmitted a reasonable number of times. 503 For a "Address and Port Dependent" filtering NAT the client must send 504 messages to the exact ports used by the server to send UDP packets 505 before sending a RTSP PLAY request. This makes it possible to use 506 the above described process with the following additional 507 restrictions: for each port mapping, FW packets need to be sent first 508 to the server's source address/port. To minimize potential effects 509 on the server from these messages the following type of FW packets 510 MUST be sent. RTP: an empty or less than 12 bytes UDP packet. RTCP: 511 A correctly formatted RTCP RR or SR message. The above described 512 adaptations for restricted NATs will not work unless the server 513 includes the "src_addr" in the "Transport" header (which is the 514 "source" transport parameter in RFC2326). 516 This method is also brittle because it relies on that one can use 517 STUN to classify the NAT behavior. If the NAT changes the properties 518 of the existing mapping and filtering state for example due to load, 519 then the methods will fail. 521 4.1.3. Embedding STUN in RTSP 523 This section outlines the adaptation and embedding of STUN within 524 RTSP. This enables STUN to be used to traverse any type of NAT, 525 including symmetric NATs. This would require protocol changes. 527 This NAT traversal solution has limitations: 529 1. It does not work if both RTSP client and RTSP server are behind 530 separate NATs. 532 2. The RTSP server may, for security reasons, refuse to send media 533 streams to an IP different from the IP in the client RTSP 534 requests. 536 Deviations from STUN as defined in RFC 3489: 538 1. We allow RTSP applications to have the option to perform STUN 539 "Shared Secret Request" through RTSP, via extension to RTSP; 541 2. We require STUN server to be co-located on RTSP server's media 542 output ports. 544 In order to allow binding discovery without authentication, the STUN 545 server embedded in RTSP application must ignore authentication tag, 546 and the STUN client embedded in RTSP application must use dummy 547 authentication tag. 549 If STUN server is co-located with RTSP server's media output port, an 550 RTSP client using RTP transport over UDP can use STUN to traverse ALL 551 types of NATs. In the case of port and address dependent mapping 552 NATs, the party inside the NAT must initiate UDP traffic. The STUN 553 Bind Request, being a UDP packet itself, can serve as the traffic 554 initiating packet. Subsequently, both the STUN Binding Response 555 packets and the RTP/RTCP packets can traverse the NAT, regardless of 556 whether the RTSP server or the RTSP client is behind NAT. 558 Likewise, if an RTSP server is behind a NAT, then an embedded STUN 559 server must co-locate on the RTSP client's RTCP port. Also it will 560 become the client that needs to disclose his destination address 561 rather than the server so that the server correctly can determine its 562 NAT external source address for the media streams. In this case, we 563 assume that the client has some means of establishing TCP connection 564 to the RTSP server behind NAT so as to exchange RTSP messages with 565 the RTSP server. 567 To minimize delay, we require that the RTSP server supporting this 568 option must inform its client the RTP and RTCP ports from where the 569 server intend to send out RTP and RTCP packets, respectively. This 570 can be done by using the "server_port" parameter in RFC2326, and the 571 "src_addr" parameter in [I-D.ietf-mmusic-rfc2326bis]. Both are in 572 the RTSP Transport header. But in general this strategy will require 573 that one first do one SETUP request per media to learn the server 574 ports, then perform the STUN checks, followed by a subsequent SETUP 575 to change the client port and destination address to what was learned 576 during the STUN checks. 578 To be certain that RTCP works correctly the RTSP end-point (server or 579 client) will be required to send and receive RTCP packets from the 580 same port. 582 4.1.4. Discussion On Co-located STUN Server 584 In order to use STUN to traverse "address and port dependent" 585 filtering or mapping NATs the STUN server needs to be co-located with 586 the streaming server media output ports. This creates a de- 587 multiplexing problem: we must be able to differentiate a STUN packet 588 from a media packet. This will be done based on heuristics. A 589 common heuristics is the first byte in the packet, which works fine 590 between STUN and RTP or RTCP where the first byte happens to be 591 different, but may not work as well with other media transport 592 protocols. 594 4.1.5. ALG considerations 596 If a NAT supports RTSP ALG (Application Level Gateway) and is not 597 aware of the STUN traversal option, service failure may happen, 598 because a client discovers its public IP address and port numbers, 599 and inserts them in its SETUP requests, when the RTSP ALG processes 600 the SETUP request it may change the destination and port number, 601 resulting in unpredictable behavior. An ALG should not update 602 address fields which contains addresses other than the NATs internal 603 address domain. In cases where the ALG modifies fields unnecessary 604 two alternatives exist: 606 1. The usage of TLS to encrypt the RTSP TCP connection to prevent 607 the ALG from reading and modifying the RTSP messages. 609 2. To turn off the STUN based NAT traversal mechanism 611 As it may be difficult to determine why the failure occurs, the usage 612 of TLS protected RTSP message exchange at all times would avoid this 613 issue. 615 4.1.6. Deployment Considerations 617 For the non-embedded usage of STUN the following applies: 619 Advantages: 621 o STUN is a solution first used by SIP applications. As shown 622 above, with little or no changes, RTSP application can re-use STUN 623 as a NAT traversal solution, avoiding the pit-fall of solving a 624 problem twice. 626 o Using STUN does not require RTSP server modifications; it only 627 affects the client implementation. 629 Disadvantages: 631 o Requires a STUN server deployed in the public address space. 633 o Only works with NATs that perform endpoint independent and address 634 dependent mappings. Port and address dependent filtering NATs 635 create some issues. 637 o Brittle to NATs changing the properties of the NAT mapping and 638 filtering. 640 o Does not work with port and address dependent mapping NATs without 641 server modifications. 643 o Will mostly not work if a NAT uses multiple IP addresses, since 644 RTSP server generally requires all media streams to use the same 645 IP as used in the RTSP connection to prevent becoming a DDOS tool. 647 o Interaction problems exist when a RTSP-aware ALG interferes with 648 the use of STUN for NAT traversal unless TLS secured RTSP message 649 exchange is used. 651 o Using STUN requires that RTSP servers and clients support the 652 updated RTSP specification, because it is no longer possible to 653 guarantee that RTP and RTCP ports are adjacent to each other, as 654 required by the "client_port" and "server_port" parameters in 655 RFC2326. 657 Transition: 659 The usage of STUN can be phased out gradually as the first step of a 660 STUN capable server or client should be to check the presence of 661 NATs. The removal of STUN capability in the client implementations 662 will have to wait until there is absolutely no need to use STUN. 664 For the "Embedded STUN" method the following applies: 666 Advantages: 668 o STUN is a solution first used by SIP applications. As shown 669 above, with little or no changes, RTSP application can re-use STUN 670 as a NAT traversal solution, avoiding the pit-fall of solving a 671 problem twice. 673 o STUN has built-in message authentication features, which makes it 674 more secure. See next section for an in-depth security 675 discussion. 677 o This solution works as long as there is only one RTSP end point in 678 the private address realm, regardless of the NAT's type. There 679 may even be multiple NATs (see figure 1 in RFC3489). 681 o Compares to other UDP based NAT traversal methods in this 682 document, STUN requires little new protocol development (since 683 STUN is already a IETF standard), and most likely less 684 implementation effort, since open source STUN server and client 685 have become available [STUN-IMPL]. There is the need to embed 686 STUN in RTSP server and client, which require a de-multiplexer 687 between STUN packets and RTP/RTCP packets. There is also a need 688 to register the proper feature tags. 690 Disadvantages: 692 o Some extensions to the RTSP core protocol, signaled by RTSP 693 feature tags, must be introduced. 695 o Requires an embedded STUN server to co-locate on each of RTSP 696 server's media protocol's ports (e.g. RTP and RTCP ports), which 697 means more processing is required to de-multiplex STUN packets 698 from media packets. For example, the de-multiplexer must be able 699 to differentiate a RTCP RR packet from a STUN packet, and forward 700 the former to the streaming server, the later to STUN server. 702 o Does not support use cases that requires the RTSP connection and 703 the media reception to happen at different addresses, unless the 704 servers sequrity policy is relaxed. 706 o Interaction problems exist when a RTSP ALG is not aware of STUN 707 unless TLS is used to protect the RTSP messages. 709 o Using STUN requires that RTSP servers and clients support the 710 updated RTSP specification, and they both agree to support the NAT 711 traversal feature. 713 o Increases the setup delay with at least the amount of time it 714 takes to perform STUN message exchanges. Most likely an extra 715 SETUP sequence will be required. 717 Transition: 719 The usage of STUN can be phased out gradually as the first step of a 720 STUN capable machine can be to check the presence of NATs for the 721 presently used network connection. The removal of STUN capability in 722 the client implementations will have to wait until there is 723 absolutely no need to use STUN. 725 4.1.7. Security Considerations 727 To prevent RTSP server being used as Denial of Service (DoS) attack 728 tools the RTSP Transport header parameter "destination" and 729 "dest_addr" are generally not allowed to point to any IP address 730 other than the one that RTSP message originates from. The RTSP 731 server is only prepared to make an exception of this rule when the 732 client is trusted (e.g., through the use of a secure authentication 733 process, or through some secure method of challenging the destination 734 to verify its willingness to accept the RTP traffic). Such 735 restriction means that STUN does not work for use cases where RTSP 736 and media transport goes to different address. 738 In terms of security property, STUN combined with destination address 739 restricted RTSP has the same security properties as the core RTSP. 740 It is protected from being used as a DoS attack tool unless the 741 attacker has ability the to spoof the TCP connection carrying RTSP 742 messages. 744 Using STUN's support for message authentication and secure transport 745 of RTSP messages, attackers cannot modify STUN responses or RTSP 746 messages to change media destination. This protects against 747 hijacking, however as a client can be the initiator of an attack, 748 these mechanisms cannot securely prevent RTSP servers being used as 749 DoS attack tools. 751 4.2. ICE 753 4.2.1. Introduction 755 ICE (Interactive Connectivity Establishment) [RFC5245] is a 756 methodology for NAT traversal that has been developed for SIP using 757 SDP offer/answer. The basic idea is to try, in a parallel fashion, 758 all possible connection addresses that an end point may have. This 759 allows the end-point to use the best available UDP "connection" 760 (meaning two UDP end-points capable of reaching each other). The 761 methodology has very nice properties in that basically all NAT 762 topologies are possible to traverse. 764 Here is how ICE works on a high level. End point A collects all 765 possible address that can be used, including local IP addresses, STUN 766 derived addresses, TURN addresses, etc. On each local port that any 767 of these address and port pairs leads to, a STUN server is installed. 768 This STUN server only accepts STUN requests using the correct 769 authentication through the use of username and password. 771 End-point A then sends a request to establish connectivity with end- 772 point B, which includes all possible destinations to get the media 773 through too A. Note that each of A's published address/port pairs has 774 a STUN server co-located. B, in its turn provides A with all its 775 possible destinations for the different media streams. A and B then 776 uses a STUN client to try to reach all the address and port pairs 777 specified by A from its corresponding destination ports. The 778 destinations for which the STUN requests have successfully completed 779 are then indicated and selected. 781 If B fails to get any STUN response from A, all hope is not lost. 782 Certain NAT topologies require multiple tries from both ends before 783 successful connectivity is accomplished and therefore requests are 784 retransmitted multiple times. The STUN requests may also result in 785 that more connectivity alternatives are discovered and conveyed in 786 the STUN responses. 788 4.2.2. Using ICE in RTSP 790 The usage of ICE for RTSP requires that both client and server be 791 updated to include the ICE functionality. If both parties implement 792 the necessary functionality the following steps could provide ICE 793 support for RTSP. 795 This assumes that it is possible to establish a TCP connection for 796 the RTSP messages between the client and the server. This is not 797 trivial in scenarios where the server is located behind a NAT, and 798 may require some TCP ports been opened, or the deployment of proxies, 799 etc. 801 The negotiation of ICE in RTSP of necessity will work different than 802 in SIP with SDP offer/answer. The protocol interactions are 803 different and thus the possibilities for transfer of states are also 804 somewhat different. The goal is also to avoid introducing extra 805 delay in the setup process at least for when the server is using a 806 public address and the client is either having a public address or is 807 behind NAT(s). This process is only intended to support PLAY mode, 808 i.e. media traffic flows from server to client. 810 1. The ICE usage begins in the SDP. The SDP for the service 811 indicates that ICE is supported at the server. No candidates can 812 be given here as that would not work with the on demand, DNS load 813 balancing, etc., that make a SDP indicate a resource on a server 814 park rather than a specific machine. 816 2. The client gathers addresses and puts together its candidate for 817 each media stream indicated in the session description. 819 3. In each SETUP request the client includes its candidates, 820 promoting one for primary usage. This indicates for the server 821 the ICE support by the client. One candidate is the primary 822 candidate and here the prioritization for this address should be 823 somewhat different compared to SIP. High performance rather than 824 always successful is to recommended as it is most likely to be a 825 server in the public. 827 4. The server responds to the SETUP (200 OK) for each media stream 828 with its candidates. A server with a public address usually only 829 provides a single ICE candidate. Also here one candidate is the 830 server primary address. 832 5. The connectivity checks are performed. For the server the 833 connectivity checks from the server to the clients have an 834 additional usage. They verify that there is someone willingly to 835 receive the media, thus protecting itself from performing 836 unknowingly an DoS attack. 838 6. Connectivity checks from the client's primary to the server's 839 primary was successful. Thus no further SETUP requests are 840 necessary and processing can proceed with step 7. If another 841 address than the primary has been verified by the client to work, 842 that address may then be promoted for usage in a SETUP request 843 (Goto 7). If the checks for the availble candidates failed and 844 If further candidates have been derived during the connectivity 845 checks, then those can be signalled in new candidate lines in 846 SETUP request updating the list (Goto 5). 848 7. Client issues PLAY request. If the server also has completed its 849 connectivity checks for this primary addresses (based on username 850 as it may be derived addresses if the client was behind NAT) then 851 it can directly answer 200 OK (Goto 8). If the connectivity 852 check has not yet completed it responds with a 1xx code to 853 indicate that it is verifying the connectivity. If that fails 854 within the set timeout an error is reported back. Client needs 855 to go back to 6. 857 8. Process completed media can be delivered. ICE testing ports may 858 be released. 860 To keep media paths alive the client needs to periodically send data 861 to the server. This could be realized with either STUN or RTP No-op 862 [I-D.ietf-avt-rtp-no-op] packets. RTCP sent by client should be able 863 to keep RTCP open. 865 4.2.3. Implementation burden of ICE 867 The usage of ICE will require that a number of new protocols and new 868 RTSP/SDP features be implemented. This makes ICE the solution that 869 has the largest impact on client and server implementations amongst 870 all the NAT/FW traversal methods in this document. 872 RTSP server implementation requirements are: 874 o STUN server features 876 o limited STUN client features 878 o SDP generation with more parameters. 880 o RTSP error code for ICE extension 882 RTSP client implantation requirements are: 884 o Limited STUN server features 886 o Limited STUN client features 888 o RTSP error code and ICE extension 890 4.2.4. Deployment Considerations 892 Advantages: 894 o Solves NAT connectivity discovery for basically all cases as long 895 as a TCP connection between them can be established. This 896 includes servers behind NATs. (Note that a proxy between address 897 domains may be required to get TCP through). 899 o Improves defenses against DDOS attacks, as media receiving client 900 requires authentications, via STUN on its media reception ports. 902 Disadvantages: 904 o Increases the setup delay with at least the amount of time it 905 takes for the server to perform its STUN requests. 907 o Assumes that it is possible to de-multiplex between media packets 908 and STUN packets. 910 o Has fairly high implementation burden put on both RTSP server and 911 client. 913 4.2.5. Security Consideration 915 One should review the security consideration section of ICE and STUN 916 to understand that ICE is contains some potential issues. However 917 these can be avoided by a correctly utilizing ICE in RTSP. In fact 918 ICE do help avoid the DDoS issue with RTSP substantially as it 919 reduces the possibility for a DDoS using RTSP servers to attackers 920 that are on-path between the RTSP server and the target and capable 921 of intercepting the STUN connectivity check packets and correctly 922 send a response to the server. 924 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. Using 946 the rule for restriciting IP address to that one of the signalling 947 connection will need to be applied here also. 949 4.3.2. Necessary RTSP extensions 951 To support symmetric RTP the RTSP signaling must be extended to allow 952 the RTSP client to indicate that it will use symmetric RTP. The 953 client also needs to be able to signal its RTP SSRC to the server in 954 its SETUP request. The RTP SSRC is used to establish some basic 955 level of security against hijacking attacks. Care must be taken in 956 choosing client's RTP SSRC. First, it must be unique within all the 957 RTP sessions belonging to the same RTSP session. Secondly, if the 958 RTSP server is sending out media packets to multiple clients from the 959 same send port, the RTP SSRC needs to be unique amongst those 960 clients' RTP sessions. Recognizing that there is a potential that 961 RTP SSRC collision may occur, the RTSP server must be able to signal 962 to client that a collision has occurred and that it wants the client 963 to use a different RTP SSRC carried in the SETUP response or use 964 unique ports per RTSP session. Using unique ports limits an RTSP 965 server in the number of session it can simultaneously handle per 966 interface IP addresses. 968 4.3.3. Deployment Considerations 970 Advantages: 972 o Works for all types of NATs, including those using multiple IP 973 addresses. (Requirement 1 in Section 3). 975 o Have no interaction problems with any RTSP ALG changing the 976 client's information in the transport header. 978 Disadvantages: 980 o Requires modifications to both RTSP server and client. 982 o Limited to work with servers that have an public IP address. 984 o The format of the RTP packet for "connection setup" (a.k.a FW 985 packet) is yet to be defined. One possibility is to use RTP No-Op 986 packet format in [I-D.ietf-avt-rtp-no-op]. 988 o Has the same security situation as STUN and will need to use 989 address restrictions. 991 4.3.4. Security Consideration 993 Symmetric RTP's major security issue is that RTP streams can be 994 hijacked and directed towards any target that the attacker desires 995 unless address restricitons are used. 997 The most serious security problem is the deliberate attack with the 998 use of a RTSP client and symmetric RTP. The attacker uses RTSP to 999 setup a media session. Then it uses symmetric RTP with a spoofed 1000 source address of the intended target of the attack. There is no 1001 defense against this attack other than restricting the possible bind 1002 address to be the same as the RTSP connection arrived on. This 1003 prevents symmetric RTP to be used in use cases that require differet 1004 addresses for media destination and signalling. 1006 A hijack attack can also be performed in various ways. The basic 1007 attack is based on the ability to read the RTSP signaling packets in 1008 order to learn the address and port the server will send from and 1009 also the SSRC the client will use. Having this information the 1010 attacker can send its own NAT-traversal RTP packets containing the 1011 correct RTP SSRC to the correct address and port on the server. The 1012 destination of the packets is set as the source IP and port in these 1013 RTP packets. 1015 Another variation of this attack is for a man in the middle to modify 1016 the RTP binding packet being sent by a client to the server by simply 1017 changing the source IP to the target one desires to attack. 1019 One can fend off the first attack by applying encryption to the RTSP 1020 signaling transport. However, the second variation is impossible to 1021 defend against. As a NAT re-writes the source IP and port this 1022 cannot be authenticated, but authentication is required in order to 1023 protect against this type of DOS attack. 1025 Yet another issues is that these attacks also can be used to deny the 1026 client the service he desire from the RTSP server completely. For a 1027 man in the middle capable of reading the signalling traffic or 1028 intercepting the binding packets can completely deny the client 1029 service by modifying or originating binding packets of itself. 1031 The random nonce used in the binding packet determines how well 1032 symmetric RTP can fend off stream-hijacking performed by parties that 1033 are not "man-in-the-middle". This proposal uses the 32-bit RTP SSRC 1034 field to this effect. Therefore it is important that this field is 1035 derived with a non-predictable randomizer. It should not be possible 1036 by knowing the algorithm used and a couple of basic facts, to derive 1037 what random number a certain client will use. 1039 An attacker not knowing the SSRC but aware of which port numbers that 1040 a server sends from can deploy a brute force attack on the server by 1041 testing a lot of different SSRCs until it finds a matching one. 1042 Therefore a server SHOULD implement functionality that blocks ports 1043 that receive multiple FW packets (i.e. the packet that is sent to the 1044 server for FW traversal) with different invalid SSRCs, especially 1045 when they are coming from the same IP/Port. 1047 To improve the security against attackers the random tag's length 1048 could be increased. To achieve a longer random tag while still using 1049 RTP and RTCP, it will be necessary to develop RTP and RTCP payload 1050 formats for carrying the random tag. 1052 4.3.5. A Variation to Symmetric RTP 1054 Symmetric RTP requires a valid RTP format in the FW packet, which is 1055 the first packet that the client sends to the server to set up 1056 virtual RTP connection. There is currently no appropriate RTP packet 1057 format for this purpose, although the No-Op format is a proposal to 1058 fix the problem [I-D.ietf-avt-rtp-no-op]. There exist a document 1059 that discusses the implication of different type of packets as keep- 1060 alives for RTP [I-D.ietf-avt-app-rtp-keepalive] and its findings are 1061 very relevant to the FW packet. 1063 Meanwhile, there has been FW traversal techniques deployed in the 1064 wireless streaming market place that use non-RTP messages as FW 1065 packets. This section attempts to summarize a subset of those 1066 solutions that happens to use a variation to the standard symmetric 1067 RTP solution. 1069 In this variation of symmetric RTP, the FW packet is a small UDP 1070 packet that does not contain RTP header. Hence the solution can no 1071 longer be called symmetric RTP, yet it employs the same technique for 1072 FW traversal. In response to client's FW packet, RTSP server sends 1073 back a similar FW packet as a confirmation so that the client can 1074 stop the so called "connection phase" of this NAT traversal 1075 technique. Afterwards, the client only has to periodically send FW 1076 packets as keep-alive messages for the NAT mappings. 1078 The server listens on its RTP-media output port, and tries to decode 1079 any received UDP packet as FW packet. This is valid since an RTSP 1080 server is not expecting RTP traffic from the RTSP client. Then, it 1081 can correlate the FW packet with the RTSP client's session ID or the 1082 client's SSRC, and record the NAT bindings accordingly. The server 1083 then sends a FW packet as the response to the client. 1085 The FW packet can contain the SSRC to identify the RTP stream, and 1086 can be made no bigger than 12 bytes, making it distinctively 1087 different from RTP packets, whose header size is 12 bytes. 1089 RTSP signaling can be added to do the following: 1091 1. Enables or disables such FW message exchanges. When the FW/NAT 1092 has an RTSP-aware ALG, it is possible to disable FW message 1093 exchange and let ALG works out the address and port mappings. 1095 2. Configures the number of re-tries and the re-try interval of the 1096 FW message exchanges. 1098 Such FW packets may also contain digital signatures to support three- 1099 way handshake based receiver authentications, so as to prevent DDoS 1100 attacks described before. 1102 This approach has the following advantages when compared with the 1103 symmetric RTP approach: 1105 1. There is no need to define RTP payload format for FW traversal, 1106 therefore it is simple to use, implement and administer 1107 (Requirement 4 in Section 3), although a binding protocol must be 1108 defined. 1110 2. When properly defined, this kind of FW message exchange can also 1111 authenticate RTP receivers, so as to prevent DDoS attacks for 1112 dual-hosted RTSP client. By dual-hosted RTSP client we mean the 1113 kind that uses one "perceived" IP address for RTSP message 1114 exchange, and a different "perceived" IP address for RTP 1115 reception. (Requirement 5 in Section 3). 1117 This approach has the following disadvantages when compared with the 1118 symmetric RTP approach: 1120 1. RTP traffic is normally accompanied by RTCP traffic. This 1121 approach needs to rely on RTCP RRs and SRs to enable NAT 1122 traversal for RTCP endpoints, or use the same type of FW messages 1123 also for RTCP endpoints. 1125 2. The server's sender SSRC for the RTP stream must be signaled in 1126 RTSP's SETUP response, in the Transport header of the RTSP SETUP 1127 response. 1129 A solution with a 3-way handshaking and its own FW packets can be 1130 compared with ICE and have the following differencies: 1132 o Only works for servers with public IP addresses compared to any 1133 type of server 1135 o Is somewhat simpler to implement due to the avoidance of the ICE 1136 prioritization and checkboard mechanisms. 1138 However, a 3-way binding protocol is very similar to using STUN in 1139 both directions as binding protocol. Using STUN would remove the 1140 need for implementing a new protocol. 1142 4.4. Application Level Gateways 1144 4.4.1. Introduction 1146 An Application Level Gateway (ALG) reads the application level 1147 messages and performs necessary changes to allow the protocol to work 1148 through the middle box. However this behavior has some problems in 1149 regards to RTSP: 1151 1. It does not work when the RTSP protocol is used with end-to-end 1152 security. As the ALG can't inspect and change the application 1153 level messages the protocol will fail due to the middle box. 1155 2. ALGs need to be updated if extensions to the protocol are added. 1156 Due to deployment issues with changing ALGs this may also break 1157 the end-to-end functionality of RTSP. 1159 Due to the above reasons it is NOT RECOMMENDED to use an RTSP ALG in 1160 NATs. This is especially important for NATs targeted to home users 1161 and small office environments, since it is very hard to upgrade NATs 1162 deployed in home or SOHO (small office/home office) environment. 1164 4.4.2. Outline On how ALGs for RTSP work 1166 In this section, we provide a step-by-step outline on how one should 1167 go about writing an ALG to enable RTSP to traverse a NAT. 1169 1. Detect any SETUP request. 1171 2. Try to detect the usage of any of the NAT traversal methods that 1172 replace the address and port of the Transport header parameters 1173 "destination" or "dest_addr". If any of these methods are used, 1174 the ALG SHOULD NOT change the address. Ways to detect that these 1175 methods are used are: 1177 * For embedded STUN, it would be watch for a feature tag, like 1178 "nat.stun". If any of those exists in the "supported", 1179 "proxy-require", or "require" headers of the RTSP exchange. 1181 * For non-embedded STUN and TURN based solutions: This can in 1182 some case be detected by inspecting the "destination" or 1183 "dest_addr" parameter. If it contains either one of the NAT's 1184 external IP addresses or a public IP address. However if 1185 multiple NATs are used this detection may fail. Remapping 1186 should only be done for addresses belonging to the NATs own 1187 private address space. 1189 Otherwise continue to the next step. 1191 3. Create UDP mappings (client given IP/port <-> external IP/port) 1192 where needed for all possible transport specification in the 1193 transport header of the request found in (1). Enter the public 1194 address and port(s) of these mappings in transport header. 1195 Mappings SHALL be created with consecutive public port number 1196 starting on an even number for RTP for each media stream. 1197 Mappings SHOULD also be given a long timeout period, at least 5 1198 minutes. 1200 4. When the SETUP response is received from the server the ALG MAY 1201 remove the unused UDP mappings, i.e. the ones not present in the 1202 transport header. The session ID SHOULD also be bound to the UDP 1203 mappings part of that session. 1205 5. If SETUP response settles on RTP over TCP or RTP over RTSP as 1206 lower transport, do nothing: let TCP tunneling to take care of 1207 NAT traversal. Otherwise go to next step. 1209 6. The ALG SHOULD keep alive the UDP mappings belonging to the an 1210 RTSP session as long as: RTSP messages with the session's ID has 1211 been sent in the last timeout interval, or UDP messages are sent 1212 on any of the UDP mappings during the last timeout interval. 1214 7. The ALG MAY remove a mapping as soon a TEARDOWN response has been 1215 received for that media stream. 1217 4.4.3. Deployment Considerations 1219 Advantage: 1221 o No impact on either client or server 1223 o Can work for any type of NATs 1225 Disadvantage: 1227 o When deployed they are hard to update to reflect protocol 1228 modifications and extensions. If not updated they will break the 1229 functionality. 1231 o When end-to-end security is used the ALG functionality will fail. 1233 o Can interfere with other type of traversal mechanisms, such as 1234 STUN. 1236 Transition: 1238 An RTSP ALG will not be phased out in any automatically way. It must 1239 be removed, probably through the removal of the NAT it is associated 1240 with. 1242 4.4.4. Security Considerations 1244 An ALG will not work when deployment of end-to-end RTSP signaling 1245 security. Therefore deployment of ALG will likely result in that 1246 clients located behind NATs will not use end-to-end security. 1248 4.5. TCP Tunneling 1250 4.5.1. Introduction 1252 Using a TCP connection that is established from the client to the 1253 server ensures that the server can send data to the client. The 1254 connection opened from the private domain ensures that the server can 1255 send data back to the client. To send data originally intended to be 1256 transported over UDP requires the TCP connection to support some type 1257 of framing of the media data packets. Using TCP also results in that 1258 the client has to accept that real-time performance may no longer be 1259 possible. TCP's problem of ensuring timely deliver was the reasons 1260 why RTP was developed. Problems that arise with TCP are: head-of- 1261 line blocking, delay introduced by retransmissions, highly varying 1262 rate due to the congestion control algorithm. 1264 4.5.2. Usage of TCP tunneling in RTSP 1266 The RTSP core specification [I-D.ietf-mmusic-rfc2326bis] supports 1267 interleaving of media data on the TCP connection that carries RTSP 1268 signaling. See section 14 in [I-D.ietf-mmusic-rfc2326bis] for how to 1269 perform this type of TCP tunneling. There also exist another way of 1270 transporting RTP over TCP defined in Appendix C.2. For signaling and 1271 rules on how to establish the TCP connection in lieu of UDP, see 1272 appendix C.2 in [I-D.ietf-mmusic-rfc2326bis]. This is based on the 1273 framing of RTP over the TCP connection as described in RFC 4571 1274 [RFC4571]. 1276 4.5.3. Deployment Considerations 1278 Advantage: 1280 o Works through all types of NATs where server is in the open. 1282 Disadvantage: 1284 o Functionality needs to be implemented on both server and client. 1286 o Will not always meet multimedia stream's real-time requirements. 1288 Transition: 1290 The tunneling over RTSP's TCP connection is not planned to be phased- 1291 out. It is intended to be a fallback mechanism and for usage when 1292 total media reliability is desired, even at the price of loss of 1293 real-time properties. 1295 4.5.4. Security Considerations 1297 The TCP tunneling of RTP has no known security problem besides those 1298 already presented in the RTSP specification. It is not possible to 1299 get any amplification effect that is desired for denial of service 1300 attacks due to TCP's flow control. A possible security 1301 consideration, when session media data is interleaved with RTSP, 1302 would be the performance bottleneck when RTSP encryption is applied, 1303 since all session media data also needs to be encrypted. 1305 4.6. TURN (Traversal Using Relay NAT) 1307 4.6.1. Introduction 1309 Traversal Using Relay NAT (TURN) [RFC5766] is a protocol for setting 1310 up traffic relays that allows clients behind NATs and firewalls to 1311 receive incoming traffic for both UDP and TCP. These relays are 1312 controlled and have limited resources. They need to be allocated 1313 before usage. TURN allows a client to temporarily bind an address/ 1314 port pair on the relay (TURN server) to its local source address/port 1315 pair, which is used to contact the TURN server. The TURN server will 1316 then forward packets between the two sides of the relay. To prevent 1317 DOS attacks on either recipient, the packets forwarded are restricted 1318 to the specific source address. On the client side it is restricted 1319 to the source setting up the mapping. On the external side this is 1320 limited to the source address/port pair of the first packet arriving 1321 on the binding. After the first packet has arrived the mapping is 1322 "locked down" to that address. Packets from any other source on this 1323 address will be discarded. Using a TURN server makes it possible for 1324 a RTSP client to receive media streams from even an unmodified RTSP 1325 server. However the problem is those RTSP servers most likely 1326 restrict media destinations to no other IP address than the one RTSP 1327 message arrives. This means that TURN could only be used if the 1328 server knows and accepts that the IP belongs to a TURN server and the 1329 TURN server can't be targeted at an unknown address or also the RTSP 1330 connection is relayed through the same TURN server. 1332 4.6.2. Usage of TURN with RTSP 1334 To use a TURN server for NAT traversal, the following steps should be 1335 performed. 1337 1. The RTSP client connects with RTSP server. The client retrieves 1338 the session description to determine the number of media streams. 1339 To avoid the issue with having RTSP connection and media traffic 1340 from different addresses also the TCP connection must be done 1341 through the same TURN server as the one in the next step. This 1342 will require the usage of TURN for TCP [RFC6062]. 1344 2. The client establishes the necessary bindings on the TURN server. 1345 It must choose the local RTP and RTCP ports that it desires to 1346 receive media packets. TURN supports requesting bindings of even 1347 port numbers and continuous ranges. 1349 3. The RTSP client uses the acquired address and port mappings in 1350 the RTSP SETUP request using the destination header. Note that 1351 the server is required to have a mechanism to verify that it is 1352 allowed to send media traffic to the given address. The server 1353 SHOULD include its RTP SSRC in the SETUP response. 1355 4. Client requests that the Server starts playing. The server 1356 starts sending media packet to the given destination address and 1357 ports. 1359 5. The first media packet to arrive at the TURN server on the 1360 external port causes "lock down"; then TURN server forwards the 1361 media packets to the RTSP client. 1363 6. When media arrives at the client, the client should try to verify 1364 that the media packets are from the correct RTSP server, by 1365 matching the RTP SSRC of the packet. Source IP address of this 1366 packet will be that of the TURN server and can therefore not be 1367 used to verify that the correct source has caused lock down. 1369 7. If the client notices that some other source has caused lock down 1370 on the TURN server, the client should create new bindings and 1371 change the session transport parameters to reflect the new 1372 bindings. 1374 8. If the client pauses and media are not sent for about 75% of the 1375 mapping timeout the client should use TURN to refresh the 1376 bindings. 1378 4.6.3. Deployment Considerations 1380 Advantages: 1382 o Does not require any server modifications. 1384 o Works for any types of NAT as long as the server has public 1385 reachable IP address. 1387 Disadvantage: 1389 o Requires another network element, namely the TURN server. 1391 o A TURN server for RTSP is may not scale since the number of 1392 sessions it must forward is proportional to the number of client 1393 media sessions. 1395 o TURN server becomes a single point of failure. 1397 o Since TURN forwards media packets, it necessarily introduces 1398 delay. 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 [RFC5766]. However the usage of TURN could be reduced when the 1407 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 1491 R2 Most work with Firewalls, including them with ALGs 1493 R3 Should have minimal impact on clients not behind NATs 1495 R4 Should be simple to use, Implement and administrate. 1497 R5 Should provide a mitigation against DDoS attacks 1499 -----------------------------------------------+ 1500 | R1 | R2 | R3 | R4 | R5 | 1501 ------------+------+------+------+------+------+ 1502 STUN | 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 ------------------------------------------------ 1515 The different techniques was discussed in the MMUSIC WG. It was 1516 established that the WG would pursue an ICE based solution due to its 1517 generality and capability of handle also servers delivering media 1518 from behind NATs. There has been some discussion if the increased 1519 implementation burden of ICE is motivated compared to a 3-W SymRTP 1520 solution for this generality. 1522 7. IANA Considerations 1524 This document makes no request of IANA. 1526 Note to RFC Editor: this section may be removed on publication as an 1527 RFC. 1529 8. Security Considerations 1531 In preceding sessions we have discussed security merits of each and 1532 every NAT/FW traversal methods for RTSP discussed here. In summary, 1533 the presence of NAT(s) is a security risk, as a client cannot perform 1534 source authentication of its IP address. This prevents the 1535 deployment of any future RTSP extensions providing security against 1536 hijacking of sessions by a man-in-the-middle. 1538 Each of the proposed solutions has security implications. Using STUN 1539 will provide the same level of security as RTSP with out transport 1540 level security and source authentications; as long as the server does 1541 not grant a client request to send media to different IP addresses. 1542 Using symmetric RTP will have a higher risk of session hijacking or 1543 denial of service than normal RTSP. The reason is that there exists 1544 a probability that an attacker is able to guess the random tag that 1545 the client uses to prove its identity when creating the address 1546 bindings. This can be solved in the variation of symmetric RTP 1547 (section 6.3.5) with authentication features. The usage of an RTSP 1548 ALG does not increase in itself the risk for session hijacking. 1549 However the deployment of ALGs as sole mechanism for RTSP NAT 1550 traversal will prevent deployment of encrypted end-to-end RTSP 1551 signaling. The usage of TCP tunneling has no known security 1552 problems. However it might provide a bottleneck when it comes to 1553 end-to-end RTSP signaling security if TCP tunneling is used on an 1554 interleaved RTSP signaling connection. The usage of TURN has severe 1555 risk of denial of service attacks against a client. The TURN server 1556 can also be used as a redirect point in a DDOS attack unless the 1557 server has strict enough rules for who may create bindings. 1559 9. Acknowledgements 1561 The author would also like to thank all persons on the MMUSIC working 1562 group's mailing list that has commented on this document. Persons 1563 having contributed in such way in no special order to this protocol 1564 are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon, 1565 Amir Wolf, Anders Klemets, and Colin Perkins. Thomas Zeng would also 1566 like to give special thanks to Greg Sherwood of PacketVideo for his 1567 input into this memo. 1569 Section Section 1.1 contains text originally written for RFC 4787 by 1570 Francois Audet and Cullen Jennings. 1572 10. Informative References 1574 [I-D.ietf-avt-app-rtp-keepalive] 1575 Marjou, X. and A. Sollaud, "Application Mechanism for 1576 keeping alive the Network Address Translator (NAT) 1577 mappings associated to RTP/RTCP flows.", 1578 draft-ietf-avt-app-rtp-keepalive-10 (work in progress), 1579 March 2011. 1581 [I-D.ietf-avt-rtp-no-op] 1582 Andreasen, F., "A No-Op Payload Format for RTP", 1583 draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. 1585 [I-D.ietf-mmusic-rfc2326bis] 1586 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1587 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1588 (RTSP)", draft-ietf-mmusic-rfc2326bis-27 (work in 1589 progress), March 2011. 1591 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1592 August 1980. 1594 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1595 RFC 793, September 1981. 1597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1598 Requirement Levels", BCP 14, RFC 2119, March 1997. 1600 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1601 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1603 [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, 1604 May 1999. 1606 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1607 Translator (NAT) Terminology and Considerations", 1608 RFC 2663, August 1999. 1610 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1611 Address Translator (Traditional NAT)", RFC 3022, 1612 January 2001. 1614 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1615 Self-Address Fixing (UNSAF) Across Network Address 1616 Translation", RFC 3424, November 2002. 1618 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1619 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1620 Through Network Address Translators (NATs)", RFC 3489, 1621 March 2003. 1623 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1624 Jacobson, "RTP: A Transport Protocol for Real-Time 1625 Applications", STD 64, RFC 3550, July 2003. 1627 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1628 Description Protocol", RFC 4566, July 2006. 1630 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1631 and RTP Control Protocol (RTCP) Packets over Connection- 1632 Oriented Transport", RFC 4571, July 2006. 1634 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1635 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1636 RFC 4787, January 2007. 1638 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1639 (ICE): A Protocol for Network Address Translator (NAT) 1640 Traversal for Offer/Answer Protocols", RFC 5245, 1641 April 2010. 1643 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1644 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1645 October 2008. 1647 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1648 Relays around NAT (TURN): Relay Extensions to Session 1649 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1651 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 1652 around NAT (TURN) Extensions for TCP Allocations", 1653 RFC 6062, November 2010. 1655 [STUN-IMPL] 1656 "Open Source STUN Server and Client, http:// 1657 www.vovida.org/applications/downloads/stun/index.html", 1658 June 2007. 1660 Authors' Addresses 1662 Magnus Westerlund 1663 Ericsson 1664 Farogatan 6 1665 Stockholm, SE-164 80 1666 Sweden 1668 Phone: +46 8 719 0000 1669 Fax: 1670 Email: magnus.westerlund@ericsson.com 1671 URI: 1673 Thomas Zeng 1675 Phone: 1676 Fax: 1677 Email: thomas.zeng@gmail.com 1678 URI: