idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-evaluation-05.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 (May 7, 2012) is 4372 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-29 == Outdated reference: A later version (-22) exists of draft-ietf-mmusic-rtsp-nat-12 -- 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 (~~), 3 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: November 8, 2012 May 7, 2012 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-05 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 November 8, 2012. 40 Copyright Notice 42 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . 22 93 4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 22 94 4.3.2. Necessary RTSP extensions . . . . . . . . . . . . . . 22 95 4.3.3. Deployment Considerations . . . . . . . . . . . . . . 23 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 The resulting ICE-based RTSP NAT traversal mechanism is specified in 174 "A Network Address Translator (NAT) Traversal mechanism for media 175 controlled by Real-Time Streaming Protocol (RTSP)" 176 [I-D.ietf-mmusic-rtsp-nat]. 178 1.1. Network Address Translators 180 Readers are urged to refer to "IP Network Address Translator (NAT) 181 Terminology and Considerations" [RFC2663] for information on NAT 182 taxonomy and terminology. Traditional NAT is the most common type of 183 NAT device deployed. Readers may refer to "Traditional IP Network 184 Address Translator (Traditional NAT)" [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 mapping 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 "Network Address Translation (NAT) Behavioral Requirements for 211 Unicast UDP" [RFC4787]. 213 NATs also have a filtering behavior on traffic arriving on the 214 external side. Such behavior effects how well different methods for 215 NAT traversal works through these NATs. See Section 5 of "Network 216 Address Translation (NAT) Behavioral Requirements for Unicast UDP" 218 [RFC4787] for more information on the different types of filtering 219 that have been identified. 221 1.2. Firewalls 223 A firewall (FW) is a security gateway that enforces certain access 224 control policies between two network administrative domains: a 225 private domain (intranet) and a external domain, e.g. public 226 Internet. Many organizations use firewalls to prevent privacy 227 intrusions and malicious attacks to corporate computing resources in 228 the private intranet [RFC2588]. 230 A comparison between NAT and FW is given below: 232 1. A firewall must sit between two network administrative domains, 233 while NAT does not have to sit between two domains. 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 [RFC5245]. 256 DNS: Domain Name Service 258 DDOS: Distributed Denial Of Service attacks 260 NAT: Network Address Translator, see [RFC3022]. 262 NAPT: Network Address/Port Translator, see [RFC3022]. 264 RTP: Real-time Transport Protocol, see [RFC3550]. 266 RTSP: Real-Time Streaming Protocol, see [RFC2326] and 267 [I-D.ietf-mmusic-rfc2326bis]. 269 SDP: Session Description Protocol, see [RFC4566]. 271 SSRC: Synchronization source in RTP, see [RFC3550]. 273 1.4. Definitions 275 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 276 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 277 "OPTIONAL" in this document are to be interpreted as described in RFC 278 2119 [RFC2119]. 280 2. Detecting the loss of NAT mappings 282 Several NAT traversal techniques in the next chapter make use of the 283 fact that the NAT UDP mapping's external address and port can be 284 discovered. This information is then utilized to traverse the NAT 285 box. However any such information is only good while the mapping is 286 still valid. As the IAB's UNSAF document [RFC3424] points out, the 287 mapping can either timeout or change its properties. It is therefore 288 important for the NAT traversal solutions to handle the loss or 289 change of NAT mappings, according to RFC3424. 291 First, since NATs may also dynamically reclaim or readjust address/ 292 port translations, "keep-alive" and periodic re-polling may be 293 required according to RFC 3424. Secondly, it is possible to detect 294 and recover from the situation where the mapping has been changed or 295 removed. The loss of a mapping can be detected when no traffic 296 arrives for a while. Below we will give some recommendation on how 297 to detect loss of NAT mappings when using RTP/RTCP under RTSP 298 control. 300 A RTP session normally has both RTP and RTCP streams. The loss of a 301 RTP mapping can only be detected when expected traffic does not 302 arrive. If a client does not receive data within a few seconds after 303 having received the "200 OK" response to a PLAY request, there are 304 likely some middleboxes blocking the traffic. However, for a 305 receiver to be more certain to detect the case where no RTP traffic 306 was delivered due to NAT trouble, one should monitor the RTCP Sender 307 reports. The sender report carries a field telling how many packets 308 the server has sent. If that has increased and no RTP packets has 309 arrived for a few seconds it is likely the RTP mapping has been 310 removed. 312 The loss of mapping for RTCP is simpler to detect. RTCP is normally 313 sent periodically in each direction, even during the RTSP ready 314 state. If RTCP packets are missing for several RTCP intervals, the 315 mapping is likely to be lost. Note that if neither RTCP packets nor 316 RTSP messages are received by the RTSP server for a while, the RTSP 317 server has the option to delete the corresponding RTP session, SSRC 318 and RTSP session ID, because either the client can not get through a 319 middle box NAT/FW, or that the client is mal-functioning. 321 3. Requirements on NAT-Traversal 323 This section considers the set of requirements for the evaulation of 324 RTSP NAT traversal solutions. 326 RTSP is a client-server protocol. Typically services providers 327 deploy RTSP servers in the public address realm. However, there are 328 use cases where the reverse is true: RTSP clients are connecting from 329 public address realm to RTSP servers behind home NATs. This is the 330 case for instance when home surveillance cameras running as RTSP 331 servers intend to stream video to cell phone users in the public 332 address realm through a home NAT. In terms of requirements, the 333 first requirement should be to solve the RTSP NAT traversal problem 334 for RTSP servers deployed in a public network, i.e. no NAT at the 335 server side. 337 The list of feature requirements for RTSP NAT solutions are given 338 below: 340 1. MUST work for all flavors of NATs, including NATs with address 341 and port restricted filtering. 343 2. MUST work for firewalls (subject to pertinent firewall 344 administrative policies), including those with ALGs. 346 3. SHOULD have minimal impact on clients in the open and not dual- 347 hosted. RTSP dual-hosting means that RTSP protocol and the media 348 protocol (e.g. RTP) are implemented on different computers with 349 different IP addresses. 351 * For instance, no extra delay from RTSP connection till arrival 352 of media 354 4. SHOULD be simple to use/implement/administer that people actually 355 turn them on 357 * Otherwise people will resort to TCP tunneling through NATs 358 * Address discovery for NAT traversal should take place behind 359 the scene, if possible 361 5. SHOULD authenticate dual-hosted client transport handler to 362 prevent DDOS attacks. 364 The last requirement addresses the Distributed Denial-Of-Service 365 (DDOS) threat, which relates to NAT traversal as explained below. 367 During NAT traversal, when the RTSP server determines the media 368 destination (Address and port) for client, the result may be that the 369 public IP address of the RTP receiver host is different than the 370 public IP address of the RTSP client host. This posts a DDOS threat 371 that has significant amplification potentials because the RTP media 372 streams in general consist of large number of IP packets. DDOS 373 attacks occur if the attacker fakes the messages in the NAT traversal 374 mechanism to trick the RTSP server into believing that the client's 375 RTP receiver is located in a separate host. For example, user A may 376 use his RTSP client to direct the RTSP server to send video RTP 377 streams to target.example.com in order to degrade the services 378 provided by target.example.com. Note a simple preventative measure 379 is for the RTSP server to disallow the cases where the client's RTP 380 receiver has a different public IP address than that of the RTSP 381 client. However, in some applications (e.g., centralized 382 conferencing), dual-hosted RTSP/RTP clients have valid use cases. 383 The key is how to authenticate the messages exchanged during the NAT 384 traversal process. Message authentication is a big challenge in the 385 current wired and wireless networking environment. It may be 386 necessary in the immediate future to deploy NAT traversal solutions 387 that do not have full message authentication, but provide upgrade 388 path to add authentication features in the future. 390 4. NAT Traversal Techniques 392 There exist a number of potential NAT traversal techniques that can 393 be used to allow RTSP to traverse NATs. They have different features 394 and are applicable to different topologies; their cost is also 395 different. They also vary in security levels. In the following 396 sections, each technique is outlined in details with discussions on 397 the corresponding advantages and disadvantages. 399 This section includes NAT traversal techniques that have not been 400 formally specified anywhere else. The overview section of this 401 document may be the only publicly available specification of some of 402 the NAT traversal techniques. However that is no real barrier 403 against doing an evaluation of the NAT traversal technique. Some 404 other techniques are currently (at the time of writing) in a state of 405 flux due to ongoing standardization work on these techniques or has 406 been not been progressed within IETF after the intiial evaluation in 407 this document, e.g. RTP No-Op [I-D.ietf-avt-rtp-no-op]. 409 4.1. STUN 411 4.1.1. Introduction 413 STUN - "Simple Traversal of UDP Through Network Address Translators" 414 [RFC3489][RFC5389] is a standardized protocol that allows a client to 415 use secure means to discover the presence of a NAT between himself 416 and the STUN server. The client uses the STUN server to discover the 417 address mappings assigned by the NAT. STUN is a client-server 418 protocol. STUN client sends a request to a STUN server and the 419 server returns a response. There are two types of STUN requests - 420 Binding Requests, sent over UDP, and Shared Secret Requests, sent 421 over TLS over TCP. 423 The first version of STUN [RFC3489] included categorization and 424 parameterization of NATs. This was abandoned in the updated version 425 due to it being unreliable. 427 4.1.2. Using STUN to traverse NAT without server modifications 429 This section describes how a client can use STUN to traverse NATs to 430 RTSP servers without requiring server modifications. Note that this 431 method has limited applicability and requires the server to be 432 available in the external/public address realm in regards to the 433 client located behind a NAT(s). 435 Limitations: 437 o The server must be located in either a public address realm or the 438 next hop external address realm in regards to the client. 440 o The client may only be located behind NATs that performing 441 Endpoint Independent or Address Dependent Mappings. Clients 442 behind NATs that do Address and Port Dependent Mappings cannot use 443 this method. 445 Method: 447 A RTSP client using RTP transport over UDP can use STUN to traverse a 448 NAT(s) in the following way: 450 1. Use STUN to try to discover the type of NAT, and the timeout 451 period for any UDP mapping on the NAT. This is RECOMMENDED to be 452 performed in the background as soon as IP connectivity is 453 established. If this is performed prior to establishing a 454 streaming session the delays in the session establishment will be 455 reduced. If no NAT is detected, normal SETUP SHOULD be used. 457 2. The RTSP client determines the number of UDP ports needed by 458 counting the number of needed media transport protocols sessions 459 in the multi-media presentation. This information is available 460 in the media description protocol, e.g. SDP [RFC4566]. For 461 example, each RTP session will in general require two UDP ports, 462 one for RTP, and one for RTCP. 464 3. For each UDP port required, establish a mapping and discover the 465 public/external IP address and port number with the help of the 466 STUN server. A successful mapping looks like: client's local 467 address/port <-> public address/port. 469 4. Perform the RTSP SETUP for each media. In the transport header 470 the following parameter SHOULD be included with the given values: 471 "dest_addr" [I-D.ietf-mmusic-rfc2326bis] or "destination" + 472 "client_port" [RFC2326] with the public/external IP address and 473 port pair for both RTP and RTCP. To be certain that this works 474 servers must allow a client to setup the RTP stream on any port, 475 not only even ports and with non-continuous port numbers for RTP 476 and RTCP. This requires the new feature provided in the update 477 to RFC2326 [I-D.ietf-mmusic-rfc2326bis]. The server should 478 respond with a transport header containing an "src_addr" or 479 "source parameter" + "server_port" with the RTP and RTCP source 480 IP address and port of the media stream. 482 5. To keep the mappings alive, the client SHOULD periodically send 483 UDP traffic over all mappings needed for the session. For the 484 mapping carrying RTCP traffic the periodic RTCP traffic may be 485 enough. For mappings carrying RTP traffic and for mappings 486 carrying RTCP packets at too low a frequency, keep-alive messages 487 SHOULD be sent. As keep alive messages, one could use the RTP 488 No-Op packet [I-D.ietf-avt-rtp-no-op] to the streaming server's 489 discard port (port number 9). The drawback of using RTP No-Op is 490 that the payload type number must be dynamically assigned through 491 RTSP first. Otherwise STUN could be used for the keep-alive as 492 well as empty UDP packets. 494 If a UDP mapping is lost, the above discovery process must be 495 repeated. The media stream also needs to be SETUP again to change 496 the transport parameters to the new ones. This will cause a glitch 497 in media playback. 499 To allow UDP packets to arrive from the server to a client behind a 500 "Address Dependent" filtering NAT, the client must first send a UDP 501 packet to establish filtering state in the NAT. The client, before 502 sending a RTSP PLAY request, must send a so called FW packet (such as 503 a RTP No-Op packet) on each mapping, to the IP address given as the 504 servers source address. To create minimum problems for the server 505 these UDP packets SHOULD be sent to the server's discard port (port 506 number 9). Since UDP packets are inherently unreliable, to ensure 507 that at least one UDP message passes the NAT, FW packets should be 508 retransmitted a reasonable number of times. 510 For a "Address and Port Dependent" filtering NAT the client must send 511 messages to the exact ports used by the server to send UDP packets 512 before sending a RTSP PLAY request. This makes it possible to use 513 the above described process with the following additional 514 restrictions: for each port mapping, FW packets need to be sent first 515 to the server's source address/port. To minimize potential effects 516 on the server from these messages the following type of FW packets 517 MUST be sent. RTP: an empty or less than 12 bytes UDP packet. RTCP: 518 A correctly formatted RTCP RR or SR message. The above described 519 adaptations for restricted NATs will not work unless the server 520 includes the "src_addr" in the "Transport" header (which is the 521 "source" transport parameter in RFC2326). 523 This method is also brittle because it relies on that one can use 524 STUN to classify the NAT behavior. If the NAT changes the properties 525 of the existing mapping and filtering state for example due to load, 526 then the methods will fail. 528 4.1.3. Embedding STUN in RTSP 530 This section outlines the adaptation and embedding of STUN within 531 RTSP. This enables STUN to be used to traverse any type of NAT, 532 including symmetric NATs. This would require protocol changes. 534 This NAT traversal solution has limitations: 536 1. It does not work if both RTSP client and RTSP server are behind 537 separate NATs. 539 2. The RTSP server may, for security reasons, refuse to send media 540 streams to an IP different from the IP in the client RTSP 541 requests. 543 Deviations from STUN as defined in RFC 3489: 545 1. We allow RTSP applications to have the option to perform STUN 546 "Shared Secret Request" through RTSP, via extension to RTSP; 548 2. We require STUN server to be co-located on RTSP server's media 549 output ports. 551 In order to allow binding discovery without authentication, the STUN 552 server embedded in RTSP application must ignore authentication tag, 553 and the STUN client embedded in RTSP application must use dummy 554 authentication tag. 556 If STUN server is co-located with RTSP server's media output port, an 557 RTSP client using RTP transport over UDP can use STUN to traverse ALL 558 types of NATs. In the case of port and address dependent mapping 559 NATs, the party inside the NAT must initiate UDP traffic. The STUN 560 Bind Request, being a UDP packet itself, can serve as the traffic 561 initiating packet. Subsequently, both the STUN Binding Response 562 packets and the RTP/RTCP packets can traverse the NAT, regardless of 563 whether the RTSP server or the RTSP client is behind NAT. 565 Likewise, if an RTSP server is behind a NAT, then an embedded STUN 566 server must co-locate on the RTSP client's RTCP port. Also it will 567 become the client that needs to disclose his destination address 568 rather than the server so that the server correctly can determine its 569 NAT external source address for the media streams. In this case, we 570 assume that the client has some means of establishing TCP connection 571 to the RTSP server behind NAT so as to exchange RTSP messages with 572 the RTSP server. 574 To minimize delay, we require that the RTSP server supporting this 575 option must inform its client the RTP and RTCP ports from where the 576 server intend to send out RTP and RTCP packets, respectively. This 577 can be done by using the "server_port" parameter in RFC2326, and the 578 "src_addr" parameter in [I-D.ietf-mmusic-rfc2326bis]. Both are in 579 the RTSP Transport header. But in general this strategy will require 580 that one first do one SETUP request per media to learn the server 581 ports, then perform the STUN checks, followed by a subsequent SETUP 582 to change the client port and destination address to what was learned 583 during the STUN checks. 585 To be certain that RTCP works correctly the RTSP end-point (server or 586 client) will be required to send and receive RTCP packets from the 587 same port. 589 4.1.4. Discussion On Co-located STUN Server 591 In order to use STUN to traverse "address and port dependent" 592 filtering or mapping NATs the STUN server needs to be co-located with 593 the streaming server media output ports. This creates a de- 594 multiplexing problem: we must be able to differentiate a STUN packet 595 from a media packet. This will be done based on heuristics. A 596 common heuristics is the first byte in the packet, which works fine 597 between STUN and RTP or RTCP where the first byte happens to be 598 different, but may not work as well with other media transport 599 protocols. 601 4.1.5. ALG considerations 603 If a NAT supports RTSP ALG (Application Level Gateway) and is not 604 aware of the STUN traversal option, service failure may happen, 605 because a client discovers its public IP address and port numbers, 606 and inserts them in its SETUP requests, when the RTSP ALG processes 607 the SETUP request it may change the destination and port number, 608 resulting in unpredictable behavior. An ALG should not update 609 address fields which contains addresses other than the NATs internal 610 address domain. In cases where the ALG modifies fields unnecessary 611 two alternatives exist: 613 1. The usage of TLS to encrypt the RTSP TCP connection to prevent 614 the ALG from reading and modifying the RTSP messages. 616 2. To turn off the STUN based NAT traversal mechanism 618 As it may be difficult to determine why the failure occurs, the usage 619 of TLS protected RTSP message exchange at all times would avoid this 620 issue. 622 4.1.6. Deployment Considerations 624 For the non-embedded usage of STUN the following applies: 626 Advantages: 628 o STUN is a solution first used by SIP applications. As shown 629 above, with little or no changes, RTSP application can re-use STUN 630 as a NAT traversal solution, avoiding the pit-fall of solving a 631 problem twice. 633 o Using STUN does not require RTSP server modifications; it only 634 affects the client implementation. 636 Disadvantages: 638 o Requires a STUN server deployed in the public address space. 640 o Only works with NATs that perform endpoint independent and address 641 dependent mappings. Port and address dependent filtering NATs 642 create some issues. 644 o Brittle to NATs changing the properties of the NAT mapping and 645 filtering. 647 o Does not work with port and address dependent mapping NATs without 648 server modifications. 650 o Will mostly not work if a NAT uses multiple IP addresses, since 651 RTSP server generally requires all media streams to use the same 652 IP as used in the RTSP connection to prevent becoming a DDOS tool. 654 o Interaction problems exist when a RTSP-aware ALG interferes with 655 the use of STUN for NAT traversal unless TLS secured RTSP message 656 exchange is used. 658 o Using STUN requires that RTSP servers and clients support the 659 updated RTSP specification, because it is no longer possible to 660 guarantee that RTP and RTCP ports are adjacent to each other, as 661 required by the "client_port" and "server_port" parameters in 662 RFC2326. 664 Transition: 666 The usage of STUN can be phased out gradually as the first step of a 667 STUN capable server or client should be to check the presence of 668 NATs. The removal of STUN capability in the client implementations 669 will have to wait until there is absolutely no need to use STUN. 671 For the "Embedded STUN" method the following applies: 673 Advantages: 675 o STUN is a solution first used by SIP applications. As shown 676 above, with little or no changes, RTSP application can re-use STUN 677 as a NAT traversal solution, avoiding the pit-fall of solving a 678 problem twice. 680 o STUN has built-in message authentication features, which makes it 681 more secure. See next section for an in-depth security 682 discussion. 684 o This solution works as long as there is only one RTSP end point in 685 the private address realm, regardless of the NAT's type. There 686 may even be multiple NATs (see figure 1 in RFC3489). 688 o Compares to other UDP based NAT traversal methods in this 689 document, STUN requires little new protocol development (since 690 STUN is already a IETF standard), and most likely less 691 implementation effort, since open source STUN server and client 692 have become available [STUN-IMPL]. There is the need to embed 693 STUN in RTSP server and client, which require a de-multiplexer 694 between STUN packets and RTP/RTCP packets. There is also a need 695 to register the proper feature tags. 697 Disadvantages: 699 o Some extensions to the RTSP core protocol, signaled by RTSP 700 feature tags, must be introduced. 702 o Requires an embedded STUN server to co-locate on each of RTSP 703 server's media protocol's ports (e.g. RTP and RTCP ports), which 704 means more processing is required to de-multiplex STUN packets 705 from media packets. For example, the de-multiplexer must be able 706 to differentiate a RTCP RR packet from a STUN packet, and forward 707 the former to the streaming server, the later to STUN server. 709 o Does not support use cases that requires the RTSP connection and 710 the media reception to happen at different addresses, unless the 711 servers sequrity policy is relaxed. 713 o Interaction problems exist when a RTSP ALG is not aware of STUN 714 unless TLS is used to protect the RTSP messages. 716 o Using STUN requires that RTSP servers and clients support the 717 updated RTSP specification, and they both agree to support the NAT 718 traversal feature. 720 o Increases the setup delay with at least the amount of time it 721 takes to perform STUN message exchanges. Most likely an extra 722 SETUP sequence will be required. 724 Transition: 726 The usage of STUN can be phased out gradually as the first step of a 727 STUN capable machine can be to check the presence of NATs for the 728 presently used network connection. The removal of STUN capability in 729 the client implementations will have to wait until there is 730 absolutely no need to use STUN. 732 4.1.7. Security Considerations 734 To prevent RTSP server being used as Denial of Service (DoS) attack 735 tools the RTSP Transport header parameter "destination" and 736 "dest_addr" are generally not allowed to point to any IP address 737 other than the one that RTSP message originates from. The RTSP 738 server is only prepared to make an exception of this rule when the 739 client is trusted (e.g., through the use of a secure authentication 740 process, or through some secure method of challenging the destination 741 to verify its willingness to accept the RTP traffic). Such 742 restriction means that STUN does not work for use cases where RTSP 743 and media transport goes to different address. 745 In terms of security property, STUN combined with destination address 746 restricted RTSP has the same security properties as the core RTSP. 747 It is protected from being used as a DoS attack tool unless the 748 attacker has ability the to spoof the TCP connection carrying RTSP 749 messages. 751 Using STUN's support for message authentication and secure transport 752 of RTSP messages, attackers cannot modify STUN responses or RTSP 753 messages to change media destination. This protects against 754 hijacking, however as a client can be the initiator of an attack, 755 these mechanisms cannot securely prevent RTSP servers being used as 756 DoS attack tools. 758 4.2. ICE 760 4.2.1. Introduction 762 ICE (Interactive Connectivity Establishment) [RFC5245] is a 763 methodology for NAT traversal that has been developed for SIP using 764 SDP offer/answer. The basic idea is to try, in a parallel fashion, 765 all possible connection addresses that an end point may have. This 766 allows the end-point to use the best available UDP "connection" 767 (meaning two UDP end-points capable of reaching each other). The 768 methodology has very nice properties in that basically all NAT 769 topologies are possible to traverse. 771 Here is how ICE works on a high level. End point A collects all 772 possible address that can be used, including local IP addresses, STUN 773 derived addresses, TURN addresses, etc. On each local port that any 774 of these address and port pairs leads to, a STUN server is installed. 775 This STUN server only accepts STUN requests using the correct 776 authentication through the use of username and password. 778 End-point A then sends a request to establish connectivity with end- 779 point B, which includes all possible destinations to get the media 780 through too A. Note that each of A's published address/port pairs has 781 a STUN server co-located. B, in its turn provides A with all its 782 possible destinations for the different media streams. A and B then 783 uses a STUN client to try to reach all the address and port pairs 784 specified by A from its corresponding destination ports. The 785 destinations for which the STUN requests have successfully completed 786 are then indicated and selected. 788 If B fails to get any STUN response from A, all hope is not lost. 789 Certain NAT topologies require multiple tries from both ends before 790 successful connectivity is accomplished and therefore requests are 791 retransmitted multiple times. The STUN requests may also result in 792 that more connectivity alternatives are discovered and conveyed in 793 the STUN responses. 795 4.2.2. Using ICE in RTSP 797 The usage of ICE for RTSP requires that both client and server be 798 updated to include the ICE functionality. If both parties implement 799 the necessary functionality the following steps could provide ICE 800 support for RTSP. 802 This assumes that it is possible to establish a TCP connection for 803 the RTSP messages between the client and the server. This is not 804 trivial in scenarios where the server is located behind a NAT, and 805 may require some TCP ports been opened, or the deployment of proxies, 806 etc. 808 The negotiation of ICE in RTSP of necessity will work different than 809 in SIP with SDP offer/answer. The protocol interactions are 810 different and thus the possibilities for transfer of states are also 811 somewhat different. The goal is also to avoid introducing extra 812 delay in the setup process at least for when the server is using a 813 public address and the client is either having a public address or is 814 behind NAT(s). This process is only intended to support PLAY mode, 815 i.e. media traffic flows from server to client. 817 1. The ICE usage begins in the SDP. The SDP for the service 818 indicates that ICE is supported at the server. No candidates can 819 be given here as that would not work with the on demand, DNS load 820 balancing, etc., that make a SDP indicate a resource on a server 821 park rather than a specific machine. 823 2. The client gathers addresses and puts together its candidate for 824 each media stream indicated in the session description. 826 3. In each SETUP request the client includes its candidates in a ICE 827 specific transport specification. This indicates for the server 828 the ICE support by the client. One candidate is the most 829 prioritized candidate and here the prioritization for this 830 address should be somewhat different compared to SIP. High 831 performance rather than always successful is to recommended as it 832 is most likely to be a server in the public. 834 4. The server responds to the SETUP (200 OK) for each media stream 835 with its candidates. A server with a public address usually only 836 provides a single ICE candidate. Also here one candidate is the 837 server primary address. 839 5. The connectivity checks are performed. For the server the 840 connectivity checks from the server to the clients have an 841 additional usage. They verify that there is someone willingly to 842 receive the media, thus protecting itself from performing 843 unknowingly an DoS attack. 845 6. Connectivity checks from the client promoting a candiadate pair 846 was successful. Thus no further SETUP requests are necessary and 847 processing can proceed with step 7. If another address than the 848 primary has been verified by the client to work, that address may 849 then be promoted for usage in a SETUP request (Goto 7). If the 850 checks for the availble candidates failed and If further 851 candidates have been derived during the connectivity checks, then 852 those can be signalled in new candidate lines in SETUP request 853 updating the list (Goto 5). 855 7. Client issues PLAY request. If the server also has completed its 856 connectivity checks for the promoted candidate pair (based on 857 username as it may be derived addresses if the client was behind 858 NAT) then it can directly answer 200 OK (Goto 8). If the 859 connectivity check has not yet completed it responds with a 1xx 860 code to indicate that it is verifying the connectivity. If that 861 fails within the set timeout an error is reported back. Client 862 needs to go back to 6. 864 8. Process completed media can be delivered. ICE candidates not 865 used may be released. 867 To keep media paths alive the client needs to periodically send data 868 to the server. This will be realized with STUN. RTCP sent by client 869 should be able to keep RTCP open but STUN will also be used based on 870 the same motivations as for ICE for SIP. 872 4.2.3. Implementation burden of ICE 874 The usage of ICE will require that a number of new protocols and new 875 RTSP/SDP features be implemented. This makes ICE the solution that 876 has the largest impact on client and server implementations amongst 877 all the NAT/FW traversal methods in this document. 879 RTSP server implementation requirements are: 881 o STUN server features 882 o limited STUN client features 884 o SDP generation with more parameters. 886 o RTSP error code for ICE extension 888 RTSP client implantation requirements are: 890 o Limited STUN server features 892 o Limited STUN client features 894 o RTSP error code and ICE extension 896 4.2.4. Deployment Considerations 898 Advantages: 900 o Solves NAT connectivity discovery for basically all cases as long 901 as a TCP connection between them can be established. This 902 includes servers behind NATs. (Note that a proxy between address 903 domains may be required to get TCP through). 905 o Improves defenses against DDOS attacks, as media receiving client 906 requires authentications, via STUN on its media reception ports. 908 Disadvantages: 910 o Increases the setup delay with at least the amount of time it 911 takes for the server to perform its STUN requests. 913 o Assumes that it is possible to de-multiplex between the packets of 914 the media protocol and STUN packets. 916 o Has fairly high implementation burden put on both RTSP server and 917 client. 919 4.2.5. Security Consideration 921 One should review the security consideration section of ICE and STUN 922 to understand that ICE contains some potential issues. However these 923 can be avoided by a correctly utilizing ICE in RTSP. In fact ICE do 924 help avoid the DDoS issue with RTSP substantially as it reduces the 925 possibility for a DDoS using RTSP servers to attackers that are on- 926 path between the RTSP server and the target and capable of 927 intercepting the STUN connectivity check packets and correctly send a 928 response to the server. 930 4.3. Symmetric RTP 932 4.3.1. Introduction 934 Symmetric RTP is a NAT traversal solution that is based on requiring 935 RTSP clients to send UDP packets to the server's media output ports. 936 Conventionally, RTSP servers send RTP packets in one direction: from 937 server to client. Symmetric RTP is similar to connection-oriented 938 traffic, where one side (e.g., the RTSP client) first "connects" by 939 sending a RTP packet to the other side's RTP port, the recipient then 940 replies to the originating IP and port. This method is also referred 941 to as "Late binding". 943 Specifically, when the RTSP server receives the "connect" RTP packet 944 (a.k.a. FW packet, since it is used to punch a hole in the FW/NAT 945 and to aid the server for port binding and address mapping) from its 946 client, it copies the source IP and Port number and uses them as 947 delivery address for media packets. By having the server send media 948 traffic back the same way as the client's packet are sent to the 949 server, address mappings will be honored. Therefore this technique 950 works for all types of NATs. However, it does require server 951 modifications. Unless there is built-in protection mechanism, 952 symmetric RTP is very vulnerable to DDOS attacks, because attackers 953 can simply forge the source IP & Port of the binding packet. Using 954 the rule for restriciting IP address to that one of the signalling 955 connection will need to be applied here also. 957 4.3.2. Necessary RTSP extensions 959 To support symmetric RTP the RTSP signaling must be extended to allow 960 the RTSP client to indicate that it will use symmetric RTP. The 961 client also needs to be able to signal its RTP SSRC to the server in 962 its SETUP request. The RTP SSRC is used to establish some basic 963 level of security against hijacking attacks. Care must be taken in 964 choosing client's RTP SSRC. First, it must be unique within all the 965 RTP sessions belonging to the same RTSP session. Secondly, if the 966 RTSP server is sending out media packets to multiple clients from the 967 same send port, the RTP SSRC needs to be unique amongst those 968 clients' RTP sessions. Recognizing that there is a potential that 969 RTP SSRC collision may occur, the RTSP server must be able to signal 970 to client that a collision has occurred and that it wants the client 971 to use a different RTP SSRC carried in the SETUP response or use 972 unique ports per RTSP session. Using unique ports limits an RTSP 973 server in the number of session it can simultaneously handle per 974 interface IP addresses. 976 4.3.3. Deployment Considerations 978 Advantages: 980 o Works for all types of NATs, including those using multiple IP 981 addresses. (Requirement 1 in Section 3). 983 o Have no interaction problems with any RTSP ALG changing the 984 client's information in the transport header. 986 Disadvantages: 988 o Requires modifications to both RTSP server and client. 990 o Limited to work with servers that have an public IP address. 992 o The format of the RTP packet for "connection setup" (a.k.a FW 993 packet) is yet to be defined. One possibility is to use RTP No-Op 994 packet format in [I-D.ietf-avt-rtp-no-op]. 996 o Has the same security situation as STUN and will need to use 997 address restrictions. 999 4.3.4. Security Consideration 1001 Symmetric RTP's major security issue is that RTP streams can be 1002 hijacked and directed towards any target that the attacker desires 1003 unless address restricitons are used. 1005 The most serious security problem is the deliberate attack with the 1006 use of a RTSP client and symmetric RTP. The attacker uses RTSP to 1007 setup a media session. Then it uses symmetric RTP with a spoofed 1008 source address of the intended target of the attack. There is no 1009 defense against this attack other than restricting the possible bind 1010 address to be the same as the RTSP connection arrived on. This 1011 prevents symmetric RTP to be used in use cases that require differet 1012 addresses for media destination and signalling. 1014 A hijack attack can also be performed in various ways. The basic 1015 attack is based on the ability to read the RTSP signaling packets in 1016 order to learn the address and port the server will send from and 1017 also the SSRC the client will use. Having this information the 1018 attacker can send its own NAT-traversal RTP packets containing the 1019 correct RTP SSRC to the correct address and port on the server. The 1020 destination of the packets is set as the source IP and port in these 1021 RTP packets. 1023 Another variation of this attack is for a man in the middle to modify 1024 the RTP binding packet being sent by a client to the server by simply 1025 changing the source IP to the target one desires to attack. 1027 One can fend off the first attack by applying encryption to the RTSP 1028 signaling transport. However, the second variation is impossible to 1029 defend against. As a NAT re-writes the source IP and port this 1030 cannot be authenticated, but authentication is required in order to 1031 protect against this type of DOS attack. 1033 Yet another issues is that these attacks also can be used to deny the 1034 client the service he desire from the RTSP server completely. For a 1035 man in the middle capable of reading the signalling traffic or 1036 intercepting the binding packets can completely deny the client 1037 service by modifying or originating binding packets of itself. 1039 The random nonce used in the binding packet determines how well 1040 symmetric RTP can fend off stream-hijacking performed by parties that 1041 are not "man-in-the-middle". This proposal uses the 32-bit RTP SSRC 1042 field to this effect. Therefore it is important that this field is 1043 derived with a non-predictable randomizer. It should not be possible 1044 by knowing the algorithm used and a couple of basic facts, to derive 1045 what random number a certain client will use. 1047 An attacker not knowing the SSRC but aware of which port numbers that 1048 a server sends from can deploy a brute force attack on the server by 1049 testing a lot of different SSRCs until it finds a matching one. 1050 Therefore a server SHOULD implement functionality that blocks ports 1051 that receive multiple FW packets (i.e. the packet that is sent to the 1052 server for FW traversal) with different invalid SSRCs, especially 1053 when they are coming from the same IP/Port. 1055 To improve the security against attackers the random tag's length 1056 could be increased. To achieve a longer random tag while still using 1057 RTP and RTCP, it will be necessary to develop RTP and RTCP payload 1058 formats for carrying the random tag. 1060 4.3.5. A Variation to Symmetric RTP 1062 Symmetric RTP requires a valid RTP format in the FW packet, which is 1063 the first packet that the client sends to the server to set up 1064 virtual RTP connection. There is currently no appropriate RTP packet 1065 format for this purpose, although the No-Op format was a proposal to 1066 fix the problem [I-D.ietf-avt-rtp-no-op]. However, that work has 1067 been abandoned. There exists a RFC that discusses the implication of 1068 different type of packets as keep-alives for RTP [RFC6263] and its 1069 findings are very relevant to the FW packet. 1071 Meanwhile, there has been FW traversal techniques deployed in the 1072 wireless streaming market place that use non-RTP messages as FW 1073 packets. This section attempts to summarize a subset of those 1074 solutions that happens to use a variation to the standard symmetric 1075 RTP solution. 1077 In this variation of symmetric RTP, the FW packet is a small UDP 1078 packet that does not contain RTP header. Hence the solution can no 1079 longer be called symmetric RTP, yet it employs the same technique for 1080 FW traversal. In response to client's FW packet, RTSP server sends 1081 back a similar FW packet as a confirmation so that the client can 1082 stop the so called "connection phase" of this NAT traversal 1083 technique. Afterwards, the client only has to periodically send FW 1084 packets as keep-alive messages for the NAT mappings. 1086 The server listens on its RTP-media output port, and tries to decode 1087 any received UDP packet as FW packet. This is valid since an RTSP 1088 server is not expecting RTP traffic from the RTSP client. Then, it 1089 can correlate the FW packet with the RTSP client's session ID or the 1090 client's SSRC, and record the NAT bindings accordingly. The server 1091 then sends a FW packet as the response to the client. 1093 The FW packet can contain the SSRC to identify the RTP stream, and 1094 care must be taken if the packet is bigger than 12 bytes, ensuring 1095 that it is distinctively different from RTP packets, whose header 1096 size is 12 bytes. 1098 RTSP signaling can be added to do the following: 1100 1. Enables or disables such FW message exchanges. When the FW/NAT 1101 has an RTSP-aware ALG, it is possible to disable FW message 1102 exchange and let ALG works out the address and port mappings. 1104 2. Configures the number of re-tries and the re-try interval of the 1105 FW message exchanges. 1107 Such FW packets may also contain digital signatures to support three- 1108 way handshake based receiver authentications, so as to prevent DDoS 1109 attacks described before. 1111 This approach has the following advantages when compared with the 1112 symmetric RTP approach: 1114 1. There is no need to define RTP payload format for FW traversal, 1115 therefore it is simple to use, implement and administer 1116 (Requirement 4 in Section 3), although a binding protocol must be 1117 defined. 1119 2. When properly defined, this kind of FW message exchange can also 1120 authenticate RTP receivers, so as to prevent DDoS attacks for 1121 dual-hosted RTSP client. By dual-hosted RTSP client we mean the 1122 kind that uses one "perceived" IP address for RTSP message 1123 exchange, and a different "perceived" IP address for RTP 1124 reception. (Requirement 5 in Section 3). 1126 This approach has the following disadvantages when compared with the 1127 symmetric RTP approach: 1129 1. RTP traffic is normally accompanied by RTCP traffic. This 1130 approach needs to rely on RTCP RRs and SRs to enable NAT 1131 traversal for RTCP endpoints, or use the same type of FW messages 1132 also for RTCP endpoints. 1134 2. The server's sender SSRC for the RTP stream must be signaled in 1135 RTSP's SETUP response, in the Transport header of the RTSP SETUP 1136 response. 1138 A solution with a 3-way handshaking and its own FW packets can be 1139 compared with ICE and have the following differencies: 1141 o Only works for servers with public IP addresses compared to any 1142 type of server 1144 o Is somewhat simpler to implement due to the avoidance of the ICE 1145 prioritization and checkboard mechanisms. 1147 However, a 3-way binding protocol is very similar to using STUN in 1148 both directions as binding protocol. Using STUN would remove the 1149 need for implementing a new protocol. 1151 4.4. Application Level Gateways 1153 4.4.1. Introduction 1155 An Application Level Gateway (ALG) reads the application level 1156 messages and performs necessary changes to allow the protocol to work 1157 through the middle box. However this behavior has some problems in 1158 regards to RTSP: 1160 1. It does not work when the RTSP protocol is used with end-to-end 1161 security. As the ALG can't inspect and change the application 1162 level messages the protocol will fail due to the middle box. 1164 2. ALGs need to be updated if extensions to the protocol are added. 1165 Due to deployment issues with changing ALGs this may also break 1166 the end-to-end functionality of RTSP. 1168 Due to the above reasons it is NOT RECOMMENDED to use an RTSP ALG in 1169 NATs. This is especially important for NATs targeted to home users 1170 and small office environments, since it is very hard to upgrade NATs 1171 deployed in home or SOHO (small office/home office) environment. 1173 4.4.2. Outline On how ALGs for RTSP work 1175 In this section, we provide a step-by-step outline on how one should 1176 go about writing an ALG to enable RTSP to traverse a NAT. 1178 1. Detect any SETUP request. 1180 2. Try to detect the usage of any of the NAT traversal methods that 1181 replace the address and port of the Transport header parameters 1182 "destination" or "dest_addr". If any of these methods are used, 1183 the ALG SHOULD NOT change the address. Ways to detect that these 1184 methods are used are: 1186 * For embedded STUN, it would be watch for a feature tag, like 1187 "nat.stun". If any of those exists in the "supported", 1188 "proxy-require", or "require" headers of the RTSP exchange. 1190 * For non-embedded STUN and TURN based solutions: This can in 1191 some case be detected by inspecting the "destination" or 1192 "dest_addr" parameter. If it contains either one of the NAT's 1193 external IP addresses or a public IP address. However if 1194 multiple NATs are used this detection may fail. Remapping 1195 should only be done for addresses belonging to the NATs own 1196 private address space. 1198 Otherwise continue to the next step. 1200 3. Create UDP mappings (client given IP/port <-> external IP/port) 1201 where needed for all possible transport specification in the 1202 transport header of the request found in (1). Enter the public 1203 address and port(s) of these mappings in transport header. 1204 Mappings SHALL be created with consecutive public port number 1205 starting on an even number for RTP for each media stream. 1206 Mappings SHOULD also be given a long timeout period, at least 5 1207 minutes. 1209 4. When the SETUP response is received from the server the ALG MAY 1210 remove the unused UDP mappings, i.e. the ones not present in the 1211 transport header. The session ID SHOULD also be bound to the UDP 1212 mappings part of that session. 1214 5. If SETUP response settles on RTP over TCP or RTP over RTSP as 1215 lower transport, do nothing: let TCP tunneling to take care of 1216 NAT traversal. Otherwise go to next step. 1218 6. The ALG SHOULD keep alive the UDP mappings belonging to the an 1219 RTSP session as long as: RTSP messages with the session's ID has 1220 been sent in the last timeout interval, or UDP messages are sent 1221 on any of the UDP mappings during the last timeout interval. 1223 7. The ALG MAY remove a mapping as soon a TEARDOWN response has been 1224 received for that media stream. 1226 4.4.3. Deployment Considerations 1228 Advantage: 1230 o No impact on either client or server 1232 o Can work for any type of NATs 1234 Disadvantage: 1236 o When deployed they are hard to update to reflect protocol 1237 modifications and extensions. If not updated they will break the 1238 functionality. 1240 o When end-to-end security is used the ALG functionality will fail. 1242 o Can interfere with other type of traversal mechanisms, such as 1243 STUN. 1245 Transition: 1247 An RTSP ALG will not be phased out in any automatically way. It must 1248 be removed, probably through the removal of the NAT it is associated 1249 with. 1251 4.4.4. Security Considerations 1253 An ALG will not work when deployment of end-to-end RTSP signaling 1254 security. Therefore deployment of ALG will likely result in that 1255 clients located behind NATs will not use end-to-end security. 1257 4.5. TCP Tunneling 1259 4.5.1. Introduction 1261 Using a TCP connection that is established from the client to the 1262 server ensures that the server can send data to the client. The 1263 connection opened from the private domain ensures that the server can 1264 send data back to the client. To send data originally intended to be 1265 transported over UDP requires the TCP connection to support some type 1266 of framing of the media data packets. Using TCP also results in that 1267 the client has to accept that real-time performance may no longer be 1268 possible. TCP's problem of ensuring timely deliver was the reasons 1269 why RTP was developed. Problems that arise with TCP are: head-of- 1270 line blocking, delay introduced by retransmissions, highly varying 1271 rate due to the congestion control algorithm. 1273 4.5.2. Usage of TCP tunneling in RTSP 1275 The RTSP core specification [I-D.ietf-mmusic-rfc2326bis] supports 1276 interleaving of media data on the TCP connection that carries RTSP 1277 signaling. See section 14 in [I-D.ietf-mmusic-rfc2326bis] for how to 1278 perform this type of TCP tunneling. There also exist another way of 1279 transporting RTP over TCP defined in Appendix C.2. For signaling and 1280 rules on how to establish the TCP connection in lieu of UDP, see 1281 appendix C.2 in [I-D.ietf-mmusic-rfc2326bis]. This is based on the 1282 framing of RTP over the TCP connection as described in RFC 4571 1283 [RFC4571]. 1285 4.5.3. Deployment Considerations 1287 Advantage: 1289 o Works through all types of NATs where server is in the open. 1291 Disadvantage: 1293 o Functionality needs to be implemented on both server and client. 1295 o Will not always meet multimedia stream's real-time requirements. 1297 Transition: 1299 The tunneling over RTSP's TCP connection is not planned to be phased- 1300 out. It is intended to be a fallback mechanism and for usage when 1301 total media reliability is desired, even at the price of loss of 1302 real-time properties. 1304 4.5.4. Security Considerations 1306 The TCP tunneling of RTP has no known security problem besides those 1307 already presented in the RTSP specification. It is not possible to 1308 get any amplification effect that is desired for denial of service 1309 attacks due to TCP's flow control. A possible security 1310 consideration, when session media data is interleaved with RTSP, 1311 would be the performance bottleneck when RTSP encryption is applied, 1312 since all session media data also needs to be encrypted. 1314 4.6. TURN (Traversal Using Relay NAT) 1316 4.6.1. Introduction 1318 Traversal Using Relay NAT (TURN) [RFC5766] is a protocol for setting 1319 up traffic relays that allows clients behind NATs and firewalls to 1320 receive incoming traffic for both UDP and TCP. These relays are 1321 controlled and have limited resources. They need to be allocated 1322 before usage. TURN allows a client to temporarily bind an address/ 1323 port pair on the relay (TURN server) to its local source address/port 1324 pair, which is used to contact the TURN server. The TURN server will 1325 then forward packets between the two sides of the relay. To prevent 1326 DOS attacks on either recipient, the packets forwarded are restricted 1327 to the specific source address. On the client side it is restricted 1328 to the source setting up the mapping. On the external side this is 1329 limited to the source address/port pair of the first packet arriving 1330 on the binding. After the first packet has arrived the mapping is 1331 "locked down" to that address. Packets from any other source on this 1332 address will be discarded. Using a TURN server makes it possible for 1333 a RTSP client to receive media streams from even an unmodified RTSP 1334 server. However the problem is those RTSP servers most likely 1335 restrict media destinations to no other IP address than the one RTSP 1336 message arrives. This means that TURN could only be used if the 1337 server knows and accepts that the IP belongs to a TURN server and the 1338 TURN server can't be targeted at an unknown address or also the RTSP 1339 connection is relayed through the same TURN server. 1341 4.6.2. Usage of TURN with RTSP 1343 To use a TURN server for NAT traversal, the following steps should be 1344 performed. 1346 1. The RTSP client connects with RTSP server. The client retrieves 1347 the session description to determine the number of media streams. 1348 To avoid the issue with having RTSP connection and media traffic 1349 from different addresses also the TCP connection must be done 1350 through the same TURN server as the one in the next step. This 1351 will require the usage of TURN for TCP [RFC6062]. 1353 2. The client establishes the necessary bindings on the TURN server. 1354 It must choose the local RTP and RTCP ports that it desires to 1355 receive media packets. TURN supports requesting bindings of even 1356 port numbers and continuous ranges. 1358 3. The RTSP client uses the acquired address and port mappings in 1359 the RTSP SETUP request using the destination header. Note that 1360 the server is required to have a mechanism to verify that it is 1361 allowed to send media traffic to the given address. The server 1362 SHOULD include its RTP SSRC in the SETUP response. 1364 4. Client requests that the Server starts playing. The server 1365 starts sending media packet to the given destination address and 1366 ports. 1368 5. The first media packet to arrive at the TURN server on the 1369 external port causes "lock down"; then TURN server forwards the 1370 media packets to the RTSP client. 1372 6. When media arrives at the client, the client should try to verify 1373 that the media packets are from the correct RTSP server, by 1374 matching the RTP SSRC of the packet. Source IP address of this 1375 packet will be that of the TURN server and can therefore not be 1376 used to verify that the correct source has caused lock down. 1378 7. If the client notices that some other source has caused lock down 1379 on the TURN server, the client should create new bindings and 1380 change the session transport parameters to reflect the new 1381 bindings. 1383 8. If the client pauses and media are not sent for about 75% of the 1384 mapping timeout the client should use TURN to refresh the 1385 bindings. 1387 4.6.3. Deployment Considerations 1389 Advantages: 1391 o Does not require any server modifications. 1393 o Works for any types of NAT as long as the server has public 1394 reachable IP address. 1396 Disadvantage: 1398 o Requires another network element, namely the TURN server. 1400 o A TURN server for RTSP is may not scale since the number of 1401 sessions it must forward is proportional to the number of client 1402 media sessions. 1404 o TURN server becomes a single point of failure. 1406 o Since TURN forwards media packets, it necessarily introduces 1407 delay. 1409 o An RTSP ALG MAY change the necessary destinations parameter. This 1410 will cause the media traffic to be sent to the wrong address. 1412 Transition: 1414 TURN is not intended to be phase-out completely, see chapter 11.2 of 1415 [RFC5766]. However the usage of TURN could be reduced when the 1416 demand for having NAT traversal is reduced. 1418 4.6.4. Security Considerations 1420 An eavesdropper of RTSP messages between the RTSP client and RTSP 1421 server will be able to do a simple denial of service attack on the 1422 media streams by sending messages to the destination address and port 1423 present in the RTSP SETUP messages. If the attacker's message can 1424 reach the TURN server before the RTSP server's message, the lock down 1425 can be accomplished towards some other address. This will result in 1426 that the TURN server will drop all the media server's packets when 1427 they arrive. This can be accomplished with little risk for the 1428 attacker of being caught, as it can be performed with a spoofed 1429 source IP. The client may detect this attack when it receives the 1430 lock down packet sent by the attacker as being mal-formatted and not 1431 corresponding to the expected context. It will also notice the lack 1432 of incoming packets. See bullet 7 in Section 4.6.2. 1434 The TURN server can also become part of a denial of service attack 1435 towards any victim. To perform this attack the attacker must be able 1436 to eavesdrop on the packets from the TURN server towards a target for 1437 the DOS attack. The attacker uses the TURN server to setup a RTSP 1438 session with media flows going through the TURN server. The attacker 1439 is in fact creating TURN mappings towards a target by spoofing the 1440 source address of TURN requests. As the attacker will need the 1441 address of these mappings he must be able to eavesdrop or intercept 1442 the TURN responses going from the TURN server to the target. Having 1443 these addresses, he can set up a RTSP session and starts delivery of 1444 the media. The attacker must be able to create these mappings. The 1445 attacker in this case may be traced by the TURN username in the 1446 mapping requests. 1448 The first attack can be made very hard by applying transport security 1449 for the RTSP messages, which will hide the TURN servers address and 1450 port numbers from any eavesdropper. 1452 The second attack requires that the attacker have access to a user 1453 account on the TURN server to be able set up the TURN mappings. To 1454 prevent this attack the server shall verify that the target 1455 destination accept this media stream. 1457 5. Firewalls 1459 Firewalls exist for the purpose of protecting a network from traffic 1460 not desired by the firewall owner. Therefore it is a policy decision 1461 if a firewall will let RTSP and its media streams through or not. 1462 RTSP is designed to be firewall friendly in that it should be easy to 1463 design firewall policies to permit passage of RTSP traffic and its 1464 media streams. 1466 The firewall will need to allow the media streams associated with a 1467 RTSP session pass through it. Therefore the firewall will need an 1468 ALG that reads RTSP SETUP and TEARDOWN messages. By reading the 1469 SETUP message the firewall can determine what type of transport and 1470 from where the media streams will use. Commonly there will be the 1471 need to open UDP ports for RTP/RTCP. By looking at the source and 1472 destination addresses and ports the opening in the firewall can be 1473 minimized to the least necessary. The opening in the firewall can be 1474 closed after a TEARDOWN message for that session or the session 1475 itself times out. 1477 Simpler firewalls do allow a client to receive media as long as it 1478 has sent packets to the target. Depending on the security level this 1479 can have the same behavior as a NAT. The only difference is that no 1480 address translation is done. To be able to use such a firewall a 1481 client would need to implement one of the above described NAT 1482 traversal methods that include sending packets to the server to open 1483 up the mappings. 1485 6. Comparision of NAT traversal techniques 1487 This section evaluates the techniques described above against the 1488 requirements listed in section Section 3. 1490 In the following table, the columns correspond to the numbered 1491 requirements. For instance, the column under R1 corresponds to the 1492 first requirement in section Section 3: MUST work for all flavors of 1493 NATs. The rows represent the different FW traversal techniques. 1494 SymRTP is short for symmetric RTP, "V.SymRTP" is short for "variation 1495 of symmetric RTP" as described in section Section 4.3.5. 1497 A Summary of the requirements are: 1499 R1 Work for all flavors of NATs 1500 R2 Most work with Firewalls, including them with ALGs 1502 R3 Should have minimal impact on clients not behind NATs 1504 R4 Should be simple to use, Implement and administrate. 1506 R5 Should provide a mitigation against DDoS attacks 1508 -----------------------------------------------+ 1509 | R1 | R2 | R3 | R4 | R5 | 1510 ------------+------+------+------+------+------+ 1511 STUN | Yes | Yes | No | Maybe| No | 1512 ------------+------+------+------+------+------+ 1513 ICE | Yes | Yes | No | No | Yes | 1514 ------------+------+------+------+------+------+ 1515 SymRTP | Yes | Yes | Yes |Maybe | No | 1516 ------------+------+------+------+------+------+ 1517 V. SymRTP | Yes | Yes | Yes | Yes |future| 1518 ------------+------+------+------+------+------+ 1519 3-W SymRTP | Yes | Yes | Yes | Maybe| Yes | 1520 ------------+------+------+------+------+------+ 1521 TURN | Yes | Yes | No | No | Yes | 1522 ------------------------------------------------ 1524 The different techniques was discussed in the MMUSIC WG. It was 1525 established that the WG would pursue an ICE based solution due to its 1526 generality and capability of handle also servers delivering media 1527 from behind NATs. There has been some discussion if the increased 1528 implementation burden of ICE is motivated compared to a 3-W SymRTP 1529 solution for this generality. 1531 The ICE based RTSP NAT traversal solution is specified in "A Network 1532 Address Translator (NAT) Traversal mechanism for media controlled by 1533 Real-Time Streaming Protocol (RTSP)" [I-D.ietf-mmusic-rtsp-nat]. 1535 7. IANA Considerations 1537 This document makes no request of IANA. 1539 Note to RFC Editor: this section may be removed on publication as an 1540 RFC. 1542 8. Security Considerations 1544 In preceding sessions we have discussed security merits of each and 1545 every NAT/FW traversal methods for RTSP discussed here. In summary, 1546 the presence of NAT(s) is a security risk, as a client cannot perform 1547 source authentication of its IP address. This prevents the 1548 deployment of any future RTSP extensions providing security against 1549 hijacking of sessions by a man-in-the-middle. 1551 Each of the proposed solutions has security implications. Using STUN 1552 will provide the same level of security as RTSP with out transport 1553 level security and source authentications; as long as the server does 1554 not grant a client request to send media to different IP addresses. 1555 Using symmetric RTP will have a higher risk of session hijacking or 1556 denial of service than normal RTSP. The reason is that there exists 1557 a probability that an attacker is able to guess the random tag that 1558 the client uses to prove its identity when creating the address 1559 bindings. This can be solved in the variation of symmetric RTP 1560 (section 6.3.5) with authentication features. The usage of an RTSP 1561 ALG does not increase in itself the risk for session hijacking. 1562 However the deployment of ALGs as sole mechanism for RTSP NAT 1563 traversal will prevent deployment of encrypted end-to-end RTSP 1564 signaling. The usage of TCP tunneling has no known security 1565 problems. However it might provide a bottleneck when it comes to 1566 end-to-end RTSP signaling security if TCP tunneling is used on an 1567 interleaved RTSP signaling connection. The usage of TURN has severe 1568 risk of denial of service attacks against a client. The TURN server 1569 can also be used as a redirect point in a DDOS attack unless the 1570 server has strict enough rules for who may create bindings. 1572 9. Acknowledgements 1574 The author would also like to thank all persons on the MMUSIC working 1575 group's mailing list that has commented on this document. Persons 1576 having contributed in such way in no special order to this protocol 1577 are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon, 1578 Amir Wolf, Anders Klemets, and Colin Perkins. Thomas Zeng would also 1579 like to give special thanks to Greg Sherwood of PacketVideo for his 1580 input into this memo. 1582 Section Section 1.1 contains text originally written for RFC 4787 by 1583 Francois Audet and Cullen Jennings. 1585 10. Informative References 1587 [I-D.ietf-avt-rtp-no-op] 1588 Andreasen, F., "A No-Op Payload Format for RTP", 1589 draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. 1591 [I-D.ietf-mmusic-rfc2326bis] 1592 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1593 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1594 (RTSP)", draft-ietf-mmusic-rfc2326bis-29 (work in 1595 progress), March 2012. 1597 [I-D.ietf-mmusic-rtsp-nat] 1598 Goldberg, J., Westerlund, M., and T. Zeng, "A Network 1599 Address Translator (NAT) Traversal mechanism for media 1600 controlled by Real-Time Streaming Protocol (RTSP)", 1601 draft-ietf-mmusic-rtsp-nat-12 (work in progress), 1602 May 2012. 1604 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1605 August 1980. 1607 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1608 RFC 793, September 1981. 1610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1611 Requirement Levels", BCP 14, RFC 2119, March 1997. 1613 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1614 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1616 [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, 1617 May 1999. 1619 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1620 Translator (NAT) Terminology and Considerations", 1621 RFC 2663, August 1999. 1623 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1624 Address Translator (Traditional NAT)", RFC 3022, 1625 January 2001. 1627 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1628 Self-Address Fixing (UNSAF) Across Network Address 1629 Translation", RFC 3424, November 2002. 1631 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1632 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1633 Through Network Address Translators (NATs)", RFC 3489, 1634 March 2003. 1636 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1637 Jacobson, "RTP: A Transport Protocol for Real-Time 1638 Applications", STD 64, RFC 3550, July 2003. 1640 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1641 Description Protocol", RFC 4566, July 2006. 1643 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1644 and RTP Control Protocol (RTCP) Packets over Connection- 1645 Oriented Transport", RFC 4571, July 2006. 1647 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1648 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1649 RFC 4787, January 2007. 1651 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1652 (ICE): A Protocol for Network Address Translator (NAT) 1653 Traversal for Offer/Answer Protocols", RFC 5245, 1654 April 2010. 1656 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1657 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1658 October 2008. 1660 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1661 Relays around NAT (TURN): Relay Extensions to Session 1662 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1664 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 1665 around NAT (TURN) Extensions for TCP Allocations", 1666 RFC 6062, November 2010. 1668 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1669 Keeping Alive the NAT Mappings Associated with RTP / RTP 1670 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 1672 [STUN-IMPL] 1673 "Open Source STUN Server and Client, http:// 1674 www.vovida.org/applications/downloads/stun/index.html", 1675 June 2007. 1677 Authors' Addresses 1679 Magnus Westerlund 1680 Ericsson 1681 Farogatan 6 1682 Stockholm, SE-164 80 1683 Sweden 1685 Phone: +46 8 719 0000 1686 Fax: 1687 Email: magnus.westerlund@ericsson.com 1688 URI: 1690 Thomas Zeng 1692 Phone: 1693 Fax: 1694 Email: thomas.zeng@gmail.com 1695 URI: