idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-evaluation-15.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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 20, 2015) is 3293 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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 (~~), 1 warning (==), 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: October 22, 2015 April 20, 2015 7 The Comparison of Different Network Address Translator (NAT) Traversal 8 Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) 9 draft-ietf-mmusic-rtsp-nat-evaluation-15 11 Abstract 13 This document describes several Network Address Translator (NAT) 14 traversal techniques that were considered to be used for establishing 15 the RTP media flows controlled by the Real-time Streaming Protocol 16 (RTSP). Each technique includes a description of how it would be 17 used, the security implications of using it and any other deployment 18 considerations it has. There are also discussions on how NAT 19 traversal techniques relate to firewalls and how each technique can 20 be applied in different use cases. These findings were used when 21 selecting the NAT traversal for RTSP 2.0, which is specified in a 22 separate document. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 22, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Network Address Translators . . . . . . . . . . . . . . . 5 60 1.2. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 6 61 1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2. Detecting the loss of NAT mappings . . . . . . . . . . . . . 7 63 3. Requirements on Solutions . . . . . . . . . . . . . . . . . . 8 64 4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . 10 65 4.1. Stand-Alone STUN . . . . . . . . . . . . . . . . . . . . 10 66 4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . 10 67 4.1.2. Using STUN to traverse NAT without server 68 modifications . . . . . . . . . . . . . . . . . . . . 11 69 4.1.3. ALG considerations . . . . . . . . . . . . . . . . . 13 70 4.1.4. Deployment Considerations . . . . . . . . . . . . . . 14 71 4.1.5. Security Considerations . . . . . . . . . . . . . . . 15 72 4.2. Server Embedded STUN . . . . . . . . . . . . . . . . . . 15 73 4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . 15 74 4.2.2. Embedding STUN in RTSP . . . . . . . . . . . . . . . 15 75 4.2.3. Discussion On Co-located STUN Server . . . . . . . . 17 76 4.2.4. ALG considerations . . . . . . . . . . . . . . . . . 17 77 4.2.5. Deployment Considerations . . . . . . . . . . . . . . 17 78 4.2.6. Security Considerations . . . . . . . . . . . . . . . 18 79 4.3. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . 18 81 4.3.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 19 82 4.3.3. Implementation burden of ICE . . . . . . . . . . . . 21 83 4.3.4. ALG Considerations . . . . . . . . . . . . . . . . . 21 84 4.3.5. Deployment Considerations . . . . . . . . . . . . . . 22 85 4.3.6. Security Consideration . . . . . . . . . . . . . . . 22 86 4.4. Latching . . . . . . . . . . . . . . . . . . . . . . . . 22 87 4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . 22 88 4.4.2. Necessary RTSP extensions . . . . . . . . . . . . . . 23 89 4.4.3. ALG Considerations . . . . . . . . . . . . . . . . . 24 90 4.4.4. Deployment Considerations . . . . . . . . . . . . . . 24 91 4.4.5. Security Consideration . . . . . . . . . . . . . . . 25 92 4.5. A Variation to Latching . . . . . . . . . . . . . . . . . 26 93 4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . 26 94 4.5.2. Necessary RTSP extensions . . . . . . . . . . . . . . 27 95 4.5.3. ALG Considerations . . . . . . . . . . . . . . . . . 27 96 4.5.4. Deployment Considerations . . . . . . . . . . . . . . 27 97 4.5.5. Security Considerations . . . . . . . . . . . . . . . 28 98 4.6. Three Way Latching . . . . . . . . . . . . . . . . . . . 28 99 4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . 28 100 4.6.2. Necessary RTSP extensions . . . . . . . . . . . . . . 28 101 4.6.3. ALG Considerations . . . . . . . . . . . . . . . . . 29 102 4.6.4. Deployment Considerations . . . . . . . . . . . . . . 29 103 4.6.5. Security Considerations . . . . . . . . . . . . . . . 29 104 4.7. Application Level Gateways . . . . . . . . . . . . . . . 30 105 4.7.1. Introduction . . . . . . . . . . . . . . . . . . . . 30 106 4.7.2. Outline On how ALGs for RTSP work . . . . . . . . . . 30 107 4.7.3. Deployment Considerations . . . . . . . . . . . . . . 31 108 4.7.4. Security Considerations . . . . . . . . . . . . . . . 32 109 4.8. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 32 110 4.8.1. Introduction . . . . . . . . . . . . . . . . . . . . 33 111 4.8.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . 33 112 4.8.3. ALG Considerations . . . . . . . . . . . . . . . . . 33 113 4.8.4. Deployment Considerations . . . . . . . . . . . . . . 33 114 4.8.5. Security Considerations . . . . . . . . . . . . . . . 34 115 4.9. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . 34 116 4.9.1. Introduction . . . . . . . . . . . . . . . . . . . . 34 117 4.9.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 35 118 4.9.3. ALG Considerations . . . . . . . . . . . . . . . . . 36 119 4.9.4. Deployment Considerations . . . . . . . . . . . . . . 36 120 4.9.5. Security Considerations . . . . . . . . . . . . . . . 37 121 5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 37 122 6. Comparison of NAT traversal techniques . . . . . . . . . . . 38 123 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 124 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 125 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 126 10. Informative References . . . . . . . . . . . . . . . . . . . 41 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 129 1. Introduction 131 Today there is a proliferating deployment of different types of 132 Network Address Translator (NAT) boxes that in many cases only 133 loosely follow standards 134 [RFC3022][RFC2663][RFC3424][RFC4787][RFC5382]. NATs cause 135 discontinuity in address realms [RFC3424], therefore an application 136 protocol, such as Real-time Streaming Protocol (RTSP) 137 [RFC2326][I-D.ietf-mmusic-rfc2326bis], needs to deal with such 138 discontinuities caused by NATs. The problem is that, being a media 139 control protocol managing one or more media streams, RTSP carries 140 network address and port information within its protocol messages. 141 Because of this, even if RTSP itself, when carried over Transmission 142 Control Protocol (TCP) [RFC0793] for example, is not blocked by NATs, 143 its media streams may be blocked by NATs. This will occur unless 144 special protocol provisions are added to support NAT-traversal. 146 Like NATs, firewalls are also middle boxes that need to be 147 considered. Firewalls help prevent unwanted traffic from getting in 148 or out of the protected network. RTSP is designed such that a 149 firewall can be configured to let RTSP controlled media streams go 150 through with limited implementation effort. The effort needed is to 151 implement an Application Level Gateway (ALG) to interpret RTSP 152 parameters. There is also a large class of firewalls, commonly home 153 firewalls, that uses a filtering behavior that appear the same to 154 what NATs have. This type of firewall will be successfully traversed 155 using the same solution as employed for NAT traversal, instead of 156 relying on a RTSP ALG. Therefore firewalls will also be discussed 157 and some important differences highlighted. 159 This document describes several NAT-traversal mechanisms for RTSP 160 controlled media streaming. Many of these NAT solutions fall into 161 the category of "UNilateral Self-Address Fixing (UNSAF)" as defined 162 in [RFC3424] and quoted below: 164 "UNSAF is a process whereby some originating process attempts to 165 determine or fix the address (and port) by which it is known - e.g. 166 to be able to use address data in the protocol exchange, or to 167 advertise a public address from which it will receive connections." 169 Following the guidelines spelled out in RFC 3424, we describe the 170 required RTSP protocol extensions for each method, transition 171 strategies, and security concerns. The transition strategies are a 172 discussion of how and if the method encourage a move towards not 173 having any NATs on the path. 175 This document is capturing the evaluation done in the process to 176 recommend firewall/NAT traversal methods for RTSP streaming servers 177 based on RFC 2326 [RFC2326] as well as the RTSP 2.0 core spec 178 [I-D.ietf-mmusic-rfc2326bis]. The evaluation is focused on NAT 179 traversal for the media streams carried over User Datagram Protocol 180 (UDP) [RFC0768] with Real-time Transport Protocol (RTP) [RFC3550] 181 over UDP being the main case for such usage. The findings should be 182 applicable to other protocols as long as they have similar 183 properties. 185 At the time when the bulk of work on this document was done, a single 186 level of NAT was the dominant deployment for NATs, and multiple level 187 of NATs, including Carrier Grade NATs (CGNs) was not considered. 188 Thus, any characterizations or findings may not be applicable in such 189 scenarios, unless CGN or multiple level of NATs are explicitly noted. 191 An ICE-based RTSP NAT traversal mechanism is specified in "A Network 192 Address Translator (NAT) Traversal mechanism for media controlled by 193 Real-Time Streaming Protocol (RTSP)" [I-D.ietf-mmusic-rtsp-nat]. 195 1.1. Network Address Translators 197 We begin by reviewing two quotes from Section 3 in "Network Address 198 Translation (NAT) Behavioral Requirements for Unicast UDP" [RFC4787] 199 concerning NATs and their terminology: 201 "Readers are urged to refer to [RFC2663] for information on NAT 202 taxonomy and terminology. Traditional NAT is the most common type of 203 NAT device deployed. Readers may refer to [RFC3022] for detailed 204 information on traditional NAT. Traditional NAT has two main 205 varieties -- Basic NAT and Network Address/Port Translator (NAPT). 207 NAPT is by far the most commonly deployed NAT device. NAPT allows 208 multiple internal hosts to share a single public IP address 209 simultaneously. When an internal host opens an outgoing TCP or UDP 210 session through a NAPT, the NAPT assigns the session a public IP 211 address and port number, so that subsequent response packets from the 212 external endpoint can be received by the NAPT, translated, and 213 forwarded to the internal host. The effect is that the NAPT 214 establishes a NAT session to translate the (private IP address, 215 private port number) tuple to a (public IP address, public port 216 number) tuple, and vice versa, for the duration of the session. An 217 issue of relevance to peer-to-peer applications is how the NAT 218 behaves when an internal host initiates multiple simultaneous 219 sessions from a single (private IP, private port) endpoint to 220 multiple distinct endpoints on the external network. In this 221 specification, the term "NAT" refers to both "Basic NAT" and "Network 222 Address/Port Translator (NAPT)"." 224 "This document uses the term "address and port mapping" as the 225 translation between an external address and port and an internal 226 address and port. Note that this is not the same as an "address 227 binding" as defined in RFC 2663." 229 Note: In the above it would be more correct to use external IP 230 address instead of public IP address in the above text. The 231 external IP address is commonly a public one, but might be of 232 other type if the NAT's external side is in a private address 233 domain. 235 In addition to the above quote there exists a number of address and 236 port mapping behaviors described in more detail in Section 4.1 of 237 "Network Address Translation (NAT) Behavioral Requirements for 238 Unicast UDP" [RFC4787] that are highly relevant to the discussion in 239 this document. 241 NATs also have a filtering behavior on traffic arriving on the 242 external side. Such behavior affects how well different methods for 243 NAT traversal works through these NATs. See Section 5 of "Network 244 Address Translation (NAT) Behavioral Requirements for Unicast UDP" 245 [RFC4787] for more information on the different types of filtering 246 that have been identified. 248 1.2. Firewalls 250 A firewall is a security gateway that enforces certain access control 251 policies between two network administrative domains: a private domain 252 (intranet) and a external domain, e.g. Internet. Many organizations 253 use firewalls to prevent intrusions and an malicious attacks on 254 computing resources in the private intranet [RFC2588]. 256 A comparison between NAT and firewall is given below: 258 1. A firewall sits at security enforcement/protection points, while 259 NAT sits at borders between two address domains. 261 2. NAT does not in itself provide security, although some access 262 control policies can be implemented using address translation 263 schemes. The inherent filtering behaviours are commonly mistaken 264 for real security policies. 266 It should be noted that many NAT devices intended for Residential or 267 small office/home office (SOHO) use include both NATs and firewall 268 functionality. 270 1.3. Glossary 272 Address-Dependent Mapping: The NAT reuses the port mapping for 273 subsequent packets sent from the same internal IP address and 274 port to the same external IP address, regardless of the 275 external port. See [RFC4787]. 277 Address and Port-Dependent Mapping: The NAT reuses the port mapping 278 for subsequent packets sent from the same internal IP address 279 and port to the same external IP address and port while the 280 mapping is still active. See [RFC4787]. 282 ALG: Application Level Gateway, an entity that can be embedded in a 283 NAT or other middlebox to perform the application layer 284 functions required for a particular protocol to traverse the 285 NAT/middlebox. 287 Endpoint-Independent Mapping: The NAT reuses the port mapping for 288 subsequent packets sent from the same internal IP address and 289 port to any external IP address and port. See [RFC4787]. 291 ICE: Interactive Connectivity Establishment, see [RFC5245]. 293 DNS: Domain Name Service 295 DoS: Denial of Service 297 DDoS: Distributed Denial of Service 299 NAT: Network Address Translator, see [RFC3022]. 301 NAPT: Network Address/Port Translator, see [RFC3022]. 303 RTP: Real-time Transport Protocol, see [RFC3550]. 305 RTSP: Real-Time Streaming Protocol, see [RFC2326] and 306 [I-D.ietf-mmusic-rfc2326bis]. 308 RTT: Round Trip Times. 310 SDP: Session Description Protocol, see [RFC4566]. 312 SSRC: Synchronization source in RTP, see [RFC3550]. 314 2. Detecting the loss of NAT mappings 316 Several NAT traversal techniques in the next chapter make use of the 317 fact that the NAT UDP mapping's external address and port can be 318 discovered. This information is then utilized to traverse the NAT 319 box. However any such information is only good while the mapping is 320 still valid. As the IAB's UNSAF document [RFC3424] points out, the 321 mapping can either timeout or change its properties. It is therefore 322 important for the NAT traversal solutions to handle the loss or 323 change of NAT mappings, according to RFC3424. 325 First, since NATs may also dynamically reclaim or readjust address/ 326 port translations, "keep-alive" and periodic re-polling may be 327 required according to RFC 3424. Secondly, it is possible to detect 328 and recover from the situation where the mapping has been changed or 329 removed. The loss of a mapping can be detected when no traffic 330 arrives for a while. Below we will give some recommendation on how 331 to detect loss of NAT mappings when using RTP/RTCP under RTSP 332 control. 334 A RTP session normally has both RTP and RTCP streams. The loss of a 335 RTP mapping can only be detected when expected traffic does not 336 arrive. If a client does not receive media data within a few seconds 337 after having received the "200 OK" response to a RTSP PLAY request 338 which starts the media delivery, it may be the result of a middlebox 339 blocking the traffic. However, for a receiver to be more certain to 340 detect the case where no RTP traffic was delivered due to NAT 341 trouble, one should monitor the RTCP Sender reports if they are 342 received and not also blocked. The sender report carries a field 343 telling how many packets the server has sent. If that has increased 344 and no RTP packets has arrived for a few seconds it is likely the 345 mapping for the RTP stream has been removed. 347 The loss of mapping for RTCP is simpler to detect. RTCP is normally 348 sent periodically in each direction, even during the RTSP ready 349 state. If RTCP packets are missing for several RTCP intervals, the 350 mapping is likely lost. Note that if neither RTCP packets nor RTSP 351 messages are received by the RTSP server for a while (default 60 352 seconds), the RTSP server has the option to delete the corresponding 353 RTP session, SSRC and RTSP session ID, because either the client can 354 not get through a middle box NAT/firewall, or the client is mal- 355 functioning. 357 3. Requirements on Solutions 359 This section considers the set of requirements for the evaluation of 360 RTSP NAT traversal solutions. 362 RTSP is a client-server protocol. Typically service providers deploy 363 RTSP servers on the Internet or otherwise reachable address realm. 364 However, there are use cases where the reverse is true: RTSP clients 365 are connecting from any address realm to RTSP servers behind NATs, 366 e.g. in a home. This is the case for instance when home surveillance 367 cameras running as RTSP servers intend to stream video to cell phone 368 users in the public address realm through a home NAT. In terms of 369 requirements, the primary issue to solve is the RTSP NAT traversal 370 problem for RTSP servers deployed in a network where the server is on 371 the external side of any NAT, i.e. server is not behind a NAT. The 372 server behind a NAT is desirable, but of much lower priority. 374 An important consideration for any NAT traversal technique is whether 375 any protocol modification needs occur, where the implementation 376 burden occur, server, client or middlebox. If the incitement to get 377 RTSP to work over a NAT is sufficient to motivate the owner of the 378 server, client or middlebox to update or configure or otherwise 379 perform changes to the device and its software to support the NAT 380 traversal. Thus, the question of who this burden falls on and how 381 big it is is highly relevant. 383 The list of feature requirements for RTSP NAT solutions are given 384 below: 386 1. Must work for all flavors of NATs, including NATs with Address 387 and Port-Dependent Filtering. 389 2. Must work for firewalls (subject to pertinent firewall 390 administrative policies), including those with ALGs. 392 3. Should have minimal impact on clients not behind NATs and which 393 are not dual-hosted. RTSP dual-hosting means that the RTSP 394 signalling protocol and the media protocol (e.g. RTP) are 395 implemented on different computers with different IP addresses. 397 * For instance, no extra protocol RTT before arrival of media. 399 4. Should be simple to use/implement/administer so people actually 400 turn them on 402 * Discovery of the address(es) assigned by NAT should happen 403 automatically, if possible 405 5. Should authenticate dual-hosted client's media transport receiver 406 to prevent usage of RTSP servers for DDoS attacks. 408 The last requirement addresses the Distributed Denial-of-Service 409 (DDoS) threat, which relates to NAT traversal as explained below. 411 During NAT traversal, when the RTSP server determines the media 412 destination (address and port) for the client, the result may be that 413 the IP address of the RTP receiver host is different than the IP 414 address of the RTSP client host. This posts a DDoS threat that has 415 significant amplification potentials because the RTP media streams in 416 general consist of large number of IP packets. DDoS attacks can 417 occur if the attacker can fake the messages in the NAT traversal 418 mechanism to trick the RTSP server into believing that the client's 419 RTP receiver is located on a host to be attacked. For example, user 420 A may use his RTSP client to direct the RTSP server to send video RTP 421 streams to target.example.com in order to degrade the services 422 provided by target.example.com. 424 Note a simple mitigation is for the RTSP server to disallow the cases 425 where the client's RTP receiver has a different IP address than that 426 of the RTSP client. This is recommended behavior in RTSP 2.0 unless 427 other solutions to prevent this attack is present, See 21.2.1 in 428 [I-D.ietf-mmusic-rfc2326bis]. With the increased deployment of NAT 429 middleboxes by operators, i.e. carrier grade NAT (CGN), the reuse of 430 an IP address on the NAT's external side by many customers reduces 431 the protection provided. Also in some applications (e.g., 432 centralized conferencing), dual-hosted RTSP/RTP clients have valid 433 use cases. The key is how to authenticate the messages exchanged 434 during the NAT traversal process. 436 4. NAT Traversal Techniques 438 There exists a number of potential NAT traversal techniques that can 439 be used to allow RTSP to traverse NATs. They have different features 440 and are applicable to different topologies; their costs are also 441 different. They also vary in security levels. In the following 442 sections, each technique is outlined with discussions on the 443 corresponding advantages and disadvantages. 445 The survey of traversal techniques was done prior to 2007 and is 446 based on what was available then. This section includes NAT 447 traversal techniques that have not been formally specified anywhere 448 else. This document may be the only publicly available specification 449 of some of the NAT traversal techniques. However that is not a real 450 barrier against doing an evaluation of the NAT traversal techniques. 451 Some techniques used as part of some of the traversal solutions have 452 been recommended against or are no longer possible due to 453 standardization works' outcome or their failure to progress within 454 IETF after the initial evaluation in this document. For example RTP 455 No-Op [I-D.ietf-avt-rtp-no-op] was a proposed RTP payload format that 456 failed to be specified, thus it is not available for use today. In 457 each such case, the missing parts will be noted and some basic 458 reasons will be given. 460 4.1. Stand-Alone STUN 462 4.1.1. Introduction 464 Session Traversal Utilities for NAT (STUN) [RFC5389] is a 465 standardized protocol that allows a client to use secure means to 466 discover the presence of a NAT between itself and the STUN server. 467 The client uses the STUN server to discover the address mappings 468 assigned by the NAT. Then using the knowledge of these NAT mappings 469 use the external addresses to directly connect to the independent 470 RTSP server. However, this is only possible if the NAT mapping 471 behavior is such that the STUN server and RTSP server will see the 472 same external address and port for the same internal address and 473 port. 475 STUN is a client-server protocol. The STUN client sends a request to 476 a STUN server and the server returns a response. There are two types 477 of STUN messages - Binding Requests and Indications. Binding 478 requests are used when determining a client's external address and 479 solicits a response from the STUN server with the seen address. 481 Indications are used by the client for keep-alive messages towards 482 the server and requires no response from the server. 484 The first version of STUN [RFC3489] included categorization and 485 parameterization of NATs. This was abandoned in the updated version 486 [RFC5389] due to it being unreliable and brittle. This particular 487 traversal method uses the removed RFC3489 functionality to detect the 488 NAT type to give an early failure indication when the NAT is showing 489 the behavior that this method can't support. This method also 490 suggest using the RTP NO-OP payload format [I-D.ietf-avt-rtp-no-op] 491 for key-alives of the RTP traffic in the client to server direction. 492 This can be replaced with another form of UDP packet as will be 493 further discussed below. 495 4.1.2. Using STUN to traverse NAT without server modifications 497 This section describes how a client can use STUN to traverse NATs to 498 RTSP servers without requiring server modifications. Note that this 499 method has limited applicability and requires the server to be 500 available in the external/public address realm in regards to the 501 client located behind a NAT(s). 503 Limitations: 505 o The server must be located in either a public address realm or the 506 next hop external address realm in regards to the client. 508 o The client may only be located behind NATs that perform "Endpoint- 509 Independent" or "Address-Dependent" Mappings (STUN server and RTSP 510 server on same IP address). Clients behind NATs that do "Address 511 and Port-Dependent" Mappings cannot use this method. See 512 [RFC4787] for full definition of these terms. 514 o Based on the discontinued middlebox classification of the replaced 515 STUN specification [RFC3489]. Thus brittle and unreliable. 517 Method: 519 A RTSP client using RTP transport over UDP can use STUN to traverse a 520 NAT(s) in the following way: 522 1. Use STUN to try to discover the type of NAT, and the timeout 523 period for any UDP mapping on the NAT. This is recommended to be 524 performed in the background as soon as IP connectivity is 525 established. If this is performed prior to establishing a 526 streaming session the delays in the session establishment will be 527 reduced. If no NAT is detected, normal SETUP should be used. 529 2. The RTSP client determines the number of UDP ports needed by 530 counting the number of needed media transport protocols sessions 531 in the multi-media presentation. This information is available 532 in the media description protocol, e.g. SDP [RFC4566]. For 533 example, each RTP session will in general require two UDP ports, 534 one for RTP, and one for RTCP. 536 3. For each UDP port required, establish a mapping and discover the 537 public/external IP address and port number with the help of the 538 STUN server. A successful mapping looks like: client's local 539 address/port <-> public address/port. 541 4. Perform the RTSP SETUP for each media. In the transport header 542 the following parameter should be included with the given values: 543 "dest_addr" [I-D.ietf-mmusic-rfc2326bis] or "destination" + 544 "client_port" [RFC2326] with the public/external IP address and 545 port pair for both RTP and RTCP. To be certain that this works 546 servers must allow a client to setup the RTP stream on any port, 547 not only even ports and with non-contiguous port numbers for RTP 548 and RTCP. This requires the new feature provided in RTSP 2.0 549 [I-D.ietf-mmusic-rfc2326bis]. The server should respond with a 550 transport header containing an "src_addr" or "source" + 551 "server_port" parameters with the RTP and RTCP source IP address 552 and port of the media stream. 554 5. To keep the mappings alive, the client should periodically send 555 UDP traffic over all mappings needed for the session. For the 556 mapping carrying RTCP traffic the periodic RTCP traffic are 557 likely enough. For mappings carrying RTP traffic and for 558 mappings carrying RTCP packets at too low a frequency, keep-alive 559 messages should be sent. 561 If a UDP mapping is lost, the above discovery process must be 562 repeated. The media stream also needs to be SETUP again to change 563 the transport parameters to the new ones. This will cause a glitch 564 in media playback. 566 To allow UDP packets to arrive from the server to a client behind a 567 "Address Dependent" or "Address and Port Dependent" filtering NAT, 568 the client must first send a UDP packet to establish filtering state 569 in the NAT. The client, before sending a RTSP PLAY request, must 570 send a so called hole-punching packet on each mapping, to the IP 571 address and port given as the server's source address and port. For 572 a NAT that only is "Address Dependent" filtering, the hole-punching 573 packet could be sent to the server's discard port (port number 9). 574 For "Address and Port Dependent" filtering NATs the hole-punching 575 packet must go to the port used for sending UDP packets to the 576 client. To be able to do that the server need to include the 577 "src_addr" in the "Transport" header (which is the "source" transport 578 parameter in RFC2326). Since UDP packets are inherently unreliable, 579 to ensure that at least one UDP message passes the NAT, hole-punching 580 packets should be retransmitted a reasonable number of times. 582 As hole-punching and keep-alive messages, one could have used the RTP 583 No-Op packet [I-D.ietf-avt-rtp-no-op] had they been defined. That 584 would have ensured that the traffic would look like RTP and thus 585 likely have the least risk of being dropped by any firewall. The 586 drawback of using RTP No-Op is that the payload type number must be 587 dynamically assigned through RTSP first. Other options are STUN, a 588 RTP packet without any payload, or an UDP packet without any payload. 589 For RTCP it is most suitable to use correctly generated RTCP packets. 590 In general sending unsolicited traffic to the RTSP server may trigger 591 security functions resulting in blocking of the keep-alive messages 592 or termination of the RTSP session itself. 594 This method is further brittle as it doesn't support address and port 595 dependent mappings. Thus, it proposes to use the old STUN methods to 596 classify the NAT behavior, thus enabling early error indication. 597 This is strictly not required but will lead to failures during setup 598 when the NAT has the wrong behavior. This failure can also occur If 599 the NAT changes the properties of the existing mapping and filtering 600 state or between the classification message exchange and the actual 601 RTSP session setup. for example due to load. 603 4.1.3. ALG considerations 605 If a NAT supports RTSP ALG (Application Level Gateway) and is not 606 aware of the STUN traversal option, service failure may happen, 607 because a client discovers its NAT external IP address and port 608 numbers, and inserts them in its SETUP requests. When the RTSP ALG 609 processes the SETUP request it may change the destination and port 610 number, resulting in unpredictable behavior. An ALG should not 611 update address fields which contains addresses other than the NATs 612 internal address domain. In cases where the ALG modifies fields 613 unnecessarily two alternatives exist: 615 1. Use TLS to encrypt the RTSP TCP connection to prevent the ALG 616 from reading and modifying the RTSP messages. 618 2. Turn off the STUN based NAT traversal mechanism 620 As it may be difficult to determine why the failure occurs, the usage 621 of TLS protected RTSP message exchange at all times would avoid this 622 issue. 624 4.1.4. Deployment Considerations 626 For the Stand-Alone usage of STUN the following applies: 628 Advantages: 630 o STUN is a solution first used by SIP [RFC3261] based applications 631 (See section 1 and 2 of [RFC5389]). As shown above, with little 632 or no changes, the RTSP application can re-use STUN as a NAT 633 traversal solution, avoiding the pit-fall of solving a problem 634 twice. 636 o Using STUN does not require RTSP server modifications, assuming it 637 is a RTSP 2.0 compliant server; it only affects the client 638 implementation. 640 Disadvantages: 642 o Requires a STUN server deployed in the same address domain as the 643 server. 645 o Only works with NATs that perform endpoint independent and address 646 dependent mappings. Address and Port-Dependent filtering NATs 647 create some issues. 649 o Brittle to NATs changing the properties of the NAT mapping and 650 filtering. 652 o Does not work with port and address dependent mapping NATs without 653 server modifications. 655 o Will not work if a NAT uses multiple IP addresses, since RTSP 656 servers generally require all media streams to use the same IP as 657 used in the RTSP connection to prevent becoming a DDoS tool. 659 o Interaction problems exist when a RTSP-aware ALG interferes with 660 the use of STUN for NAT traversal unless TLS secured RTSP message 661 exchange is used. 663 o Using STUN requires that RTSP servers and clients support the 664 updated RTSP specification [I-D.ietf-mmusic-rfc2326bis], because 665 it is no longer possible to guarantee that RTP and RTCP ports are 666 adjacent to each other, as required by the "client_port" and 667 "server_port" parameters in RFC2326. 669 Transition: 671 The usage of STUN can be phased out gradually as the first step of a 672 STUN capable server or client should be to check the presence of 673 NATs. The removal of STUN capability in the client implementations 674 will have to wait until there is absolutely no need to use STUN. 676 4.1.5. Security Considerations 678 To prevent the RTSP server from being used as Denial of Service (DoS) 679 attack tools the RTSP Transport header parameter "destination" and 680 "dest_addr" are generally not allowed to point to any IP address 681 other than the one the RTSP message originates from. The RTSP server 682 is only prepared to make an exception to this rule when the client is 683 trusted (e.g., through the use of a secure authentication process, or 684 through some secure method of challenging the destination to verify 685 its willingness to accept the RTP traffic). Such a restriction means 686 that STUN in general does not work for use cases where RTSP and media 687 transport go to different addresses. 689 STUN combined with destination address restricted RTSP has the same 690 security properties as the core RTSP. It is protected from being 691 used as a DoS attack tool unless the attacker has the ability to 692 spoof the TCP connection carrying RTSP messages. 694 Using STUN's support for message authentication and secure transport 695 of RTSP messages, attackers cannot modify STUN responses or RTSP 696 messages (TLS) to change media destination. This protects against 697 hijacking, however as a client can be the initiator of an attack, 698 these mechanisms cannot securely prevent RTSP servers being used as 699 DoS attack tools. 701 4.2. Server Embedded STUN 703 4.2.1. Introduction 705 This Section describes an alternative to the stand-alone STUN usage 706 in the previous section that has quite significantly different 707 behavior. 709 4.2.2. Embedding STUN in RTSP 711 This section outlines the adaptation and embedding of STUN within 712 RTSP. This enables STUN to be used to traverse any type of NAT, 713 including address and Port-Dependent mapping NATs. This would 714 require RTSP level protocol changes. 716 This NAT traversal solution has limitations: 718 1. It does not work if both RTSP client and RTSP server are behind 719 separate NATs. 721 2. The RTSP server may, for security reasons, refuse to send media 722 streams to an IP different from the IP in the client RTSP 723 requests. 725 Deviations from STUN as defined in RFC 5389: 727 1. The RTSP application must provision the client with an identity 728 and shared secret to use in the STUN authentication; 730 2. We require STUN server to be co-located on RTSP server's media 731 source ports. 733 If STUN server is co-located with RTSP server's media source port, an 734 RTSP client using RTP transport over UDP can use STUN to traverse ALL 735 types of NATs. In the case of port and address dependent mapping 736 NATs, the party on the inside of the NAT must initiate UDP traffic. 737 The STUN Binding Request, being a UDP packet itself, can serve as the 738 traffic initiating packet. Subsequently, both the STUN Binding 739 Response packets and the RTP/RTCP packets can traverse the NAT, 740 regardless of whether the RTSP server or the RTSP client is behind 741 NAT (however only one of the can be behind a NAT). 743 Likewise, if an RTSP server is behind a NAT, then an embedded STUN 744 server must be co-located on the RTSP client's RTCP port. Also it 745 will become the client that needs to disclose his destination address 746 rather than the server, so the server can correctly determine its NAT 747 external source address for the media streams. In this case, we 748 assume that the client has some means of establishing TCP connection 749 to the RTSP server behind NAT so as to exchange RTSP messages with 750 the RTSP server, potentially using a proxy or static rules. 752 To minimize delay, we require that the RTSP server supporting this 753 option must inform the client about the RTP and RTCP ports from where 754 the server will send out RTP and RTCP packets, respectively. This 755 can be done by using the "server_port" parameter in RFC2326, and the 756 "src_addr" parameter in [I-D.ietf-mmusic-rfc2326bis]. Both are in 757 the RTSP Transport header. But in general this strategy will require 758 that one first do one SETUP request per media to learn the server 759 ports, then perform the STUN checks, followed by a subsequent SETUP 760 to change the client port and destination address to what was learned 761 during the STUN checks. 763 To be certain that RTCP works correctly the RTSP end-point (server or 764 client) will be required to send and receive RTCP packets from the 765 same port. 767 4.2.3. Discussion On Co-located STUN Server 769 In order to use STUN to traverse "address and port dependent" 770 filtering or mapping NATs the STUN server needs to be co-located with 771 the streaming server media output ports. This creates a de- 772 multiplexing problem: we must be able to differentiate a STUN packet 773 from a media packet. This will be done based on heuristics. The 774 existing STUN heuristics is the first byte in the packet and the 775 Magic Cookie field (added in RFC5389), which works fine between STUN 776 and RTP or RTCP where the first byte happens to be different. Thanks 777 to the magic cookie field it is unlikely that other protocols would 778 be mistaken for a STUN packet, but not assured. For more discussion 779 of this, please see Section 5.1.2 of [RFC5764]. 781 4.2.4. ALG considerations 783 The same ALG traversal considerations as for Stand-Alone STUN applies 784 (Section 4.1.3). 786 4.2.5. Deployment Considerations 788 For the "Embedded STUN" method the following applies: 790 Advantages: 792 o STUN is a solution first used by SIP applications. As shown 793 above, with little or no changes, RTSP application can re-use STUN 794 as a NAT traversal solution, avoiding the pit-fall of solving a 795 problem twice. 797 o STUN has built-in message authentication features, which makes it 798 more secure against hi-jacking attacks. See next section for an 799 in-depth security discussion. 801 o This solution works as long as there is only one RTSP endpoint in 802 the private address realm, regardless of the NAT's type. There 803 may even be multiple NATs (see Figure 1 in [RFC5389]). 805 o Compared to other UDP based NAT traversal methods in this 806 document, STUN requires little new protocol development (since 807 STUN is already a IETF standard), and most likely less 808 implementation effort, since open source STUN server and client 809 implementations are available [STUN-IMPL][PJNATH]. 811 Disadvantages: 813 o Some extensions to the RTSP core protocol, likely signaled by RTSP 814 feature tags, must be introduced. 816 o Requires an embedded STUN server to be co-located on each of the 817 RTSP server's media protocol's ports (e.g. RTP and RTCP ports), 818 which means more processing is required to de-multiplex STUN 819 packets from media packets. For example, the de-multiplexer must 820 be able to differentiate a RTCP RR packet from a STUN packet, and 821 forward the former to the streaming server, and the latter to the 822 STUN server. 824 o Does not support use cases that require the RTSP connection and 825 the media reception to happen at different addresses, unless the 826 server's security policy is relaxed. 828 o Interaction problems exist when a RTSP ALG is not aware of STUN 829 unless TLS is used to protect the RTSP messages. 831 o Using STUN requires that RTSP servers and clients support the 832 updated RTSP specification [I-D.ietf-mmusic-rfc2326bis], and they 833 both agree to support the NAT traversal feature. 835 o Increases the setup delay with at least the amount of time it 836 takes to perform STUN message exchanges. Most likely an extra 837 SETUP sequence will be required. 839 Transition: 841 The usage of STUN can be phased out gradually as the first step of a 842 STUN capable machine can be to check the presence of NATs for the 843 presently used network connection. The removal of STUN capability in 844 the client implementations will have to wait until there is 845 absolutely no need to use STUN, i.e. no NATs or firewalls. 847 4.2.6. Security Considerations 849 See Stand-Alone STUN (Section 4.1.5). 851 4.3. ICE 853 4.3.1. Introduction 855 ICE (Interactive Connectivity Establishment) [RFC5245] is a 856 methodology for NAT traversal that has been developed for SIP using 857 SDP offer/answer. The basic idea is to try, in a staggered parallel 858 fashion, all possible connection addresses that an endpoint may be 859 reachable by. This allows the endpoint to use the best available UDP 860 "connection" (meaning two UDP end-points capable of reaching each 861 other). The methodology has very nice properties in that basically 862 all NAT topologies are possible to traverse. 864 Here is how ICE works at a high level. End point A collects all 865 possible addresses that can be used, including local IP addresses, 866 STUN derived addresses, TURN addresses, etc. On each local port that 867 any of these address and port pairs lead to, a STUN server is 868 installed. This STUN server only accepts STUN requests using the 869 correct authentication through the use of a username and password. 871 End-point A then sends a request to establish connectivity with end- 872 point B, which includes all possible "destinations" [RFC5245] to get 873 the media through to A. Note that each of A's local address/port 874 pairs (host candidates and server reflexive base) has a STUN server 875 co-located. B in turn provides A with all its possible destinations 876 for the different media streams. A and B then uses a STUN client to 877 try to reach all the address and port pairs specified by A from its 878 corresponding destination ports. The destinations for which the STUN 879 requests successfully complete are then indicated and one is 880 selected. 882 If B fails to get any STUN response from A, all hope is not lost. 883 Certain NAT topologies require multiple tries from both ends before 884 successful connectivity is accomplished and therefore requests are 885 retransmitted multiple times. The STUN requests may also result in 886 that more connectivity alternatives (destinations) are discovered and 887 conveyed in the STUN responses. 889 4.3.2. Using ICE in RTSP 891 The usage of ICE for RTSP requires that both client and server be 892 updated to include the ICE functionality. If both parties implement 893 the necessary functionality the following steps could provide ICE 894 support for RTSP. 896 This assumes that it is possible to establish a TCP connection for 897 the RTSP messages between the client and the server. This is not 898 trivial in scenarios where the server is located behind a NAT, and 899 may require some TCP ports be opened, or the deployment of proxies, 900 etc. 902 The negotiation of ICE in RTSP of necessity will work different than 903 in SIP with SDP offer/answer. The protocol interactions are 904 different and thus the possibilities for transfer of states are also 905 somewhat different. The goal is also to avoid introducing extra 906 delay in the setup process at least for when the server is not behind 907 a NAT in regards to the client, and the client is either having an 908 address in the same address domain, or is behind NAT(s) which can 909 address the address domain of the server. This process is only 910 intended to support PLAY mode, i.e. media traffic flows from server 911 to client. 913 1. The ICE usage begins in the SDP. The SDP for the service 914 indicates that ICE is supported at the server. No candidates can 915 be given here as that would not work with the on demand, DNS load 916 balancing, etc., that have the SDP indicate a resource on a 917 server park rather than a specific machine. 919 2. The client gathers addresses and puts together its candidates for 920 each media stream indicated in the session description. 922 3. In each SETUP request the client includes its candidates in an 923 ICE specific transport specification. This indicates for the 924 server the ICE support by the client. One candidate is the most 925 prioritized candidate and here the prioritization for this 926 address should be somewhat different compared to SIP. High 927 performance candidates is recommended rather than candidates with 928 the highest likellihood of success, as it is more likely that a 929 server is not behind a NAT compared to a SIP user-agent. 931 4. The server responds to the SETUP (200 OK) for each media stream 932 with its candidates. A server not behind a NAT usually only 933 provides a single ICE candidate. Also here one candidate is the 934 server primary address. 936 5. The connectivity checks are performed. For the server the 937 connectivity checks from the server to the clients have an 938 additional usage. They verify that there is someone willing to 939 receive the media, thus preventing the server from unknowingly 940 performing a DoS attack. 942 6. Connectivity checks from the client promoting a candidate pair 943 were successful. Thus no further SETUP requests are necessary 944 and processing can proceed with step 7. If another address than 945 the primary has been verified by the client to work, that address 946 may then be promoted for usage in a SETUP request (Go to 7). If 947 the checks for the available candidates failed and if further 948 candidates have been derived during the connectivity checks, then 949 those can be signalled in new candidate lines in a SETUP request 950 updating the list (Go to 5). 952 7. Client issues PLAY request. If the server also has completed its 953 connectivity checks for the promoted candidate pair (based on 954 username as it may be derived addresses if the client was behind 955 NAT) then it can directly answer 200 OK (Go to 8). If the 956 connectivity check has not yet completed it responds with a 1xx 957 code to indicate that it is verifying the connectivity. If that 958 fails within the set timeout, an error is reported back. Client 959 needs to go back to 6. 961 8. Process completed and media can be delivered. ICE candidates not 962 used may be released. 964 To keep media paths alive the client needs to periodically send data 965 to the server. This will be realized with STUN. RTCP sent by the 966 client should be able to keep RTCP open but STUN will also be used 967 based on the same motivations as for ICE for SIP. 969 4.3.3. Implementation burden of ICE 971 The usage of ICE will require that a number of new protocols and new 972 RTSP/SDP features be implemented. This makes ICE the solution that 973 has the largest impact on client and server implementations among all 974 the NAT/firewall traversal methods in this document. 976 RTSP server implementation requirements are: 978 o STUN server features 980 o Limited STUN client features 982 o SDP generation with more parameters. 984 o RTSP error code for ICE extension 986 RTSP client implementation requirements are: 988 o Limited STUN server features 990 o Limited STUN client features 992 o RTSP error code and ICE extension 994 4.3.4. ALG Considerations 996 If there is an RTSP ALG that doesn't support the NAT traversal 997 method, it may interfere with the NAT traversal. As the usage of ICE 998 for the traversal manifest itself in the RTSP message primarily as 999 new transport specification, an ALG that passes through unknown will 1000 not prevent the traversal. An ALG that discards unknown 1001 specifications will however prevent the NAT traversal. These issues 1002 can be avoided by preventing the ALG to interfere with the signalling 1003 by using TLS for the RTSP message transport. 1005 An ALG that supports this traversal method, can on the most basic 1006 level just pass the transport specifications through. ALGs in NATs 1007 and Firewalls could use the ICE candidates to establish filtering 1008 state that would allow incoming STUN messages prior to any outgoing 1009 hole-punching packets, and in that way speed up the connectivity 1010 checks and reduce the risk of failures. 1012 4.3.5. Deployment Considerations 1014 Advantages: 1016 o Solves NAT connectivity discovery for basically all cases as long 1017 as a TCP connection between the client and server can be 1018 established. This includes servers behind NATs. (Note that a 1019 proxy between address domains may be required to get TCP through). 1021 o Improves defenses against DDoS attacks, since a media receiving 1022 client requires authentications, via STUN on its media reception 1023 ports. 1025 Disadvantages: 1027 o Increases the setup delay with at least the amount of time it 1028 takes for the server to perform its STUN requests. 1030 o Assumes that it is possible to de-multiplex between the packets of 1031 the media protocol and STUN packets. This is possible for RTP as 1032 discussed for example in Section 5.1.2 of [RFC5764]. 1034 o Has fairly high implementation burden put on both RTSP server and 1035 client. However, several Open Source ICE implementations do 1036 exist, such as [NICE][PJNATH]. 1038 4.3.6. Security Consideration 1040 One should review the security consideration section of ICE and STUN 1041 to understand that ICE contains some potential issues. However these 1042 can be avoided by correctly using ICE in RTSP. An important factor 1043 is to secure the signalling, i.e. use TLS between RTSP client and 1044 server. In fact ICE does help avoid the DDoS attack issue with RTSP 1045 substantially as it reduces the possibility for a DDoS using RTSP 1046 servers to attackers that are on-path between the RTSP server and the 1047 target and capable of intercepting the STUN connectivity check 1048 packets and correctly send a response to the server. 1050 4.4. Latching 1052 4.4.1. Introduction 1054 Latching is a NAT traversal solution that is based on requiring RTSP 1055 clients to send UDP packets to the server's media output ports. 1056 Conventionally, RTSP servers send RTP packets in one direction: from 1057 server to client. Latching is similar to connection-oriented 1058 traffic, where one side (e.g., the RTSP client) first "connects" by 1059 sending a RTP packet to the other side's RTP port, the recipient then 1060 replies to the originating IP and port. This method is also referred 1061 to as "Late binding". It requires that all RTP/RTCP transport is 1062 done symmetrical, i.e. Symmetric RTP [RFC4961]. There exist a 1063 description for latching of SIP negotiated media streams in Session 1064 Border Controllers [RFC7362]. 1066 Specifically, when the RTSP server receives the latching packet 1067 (a.k.a. hole-punching packet, since it is used to punch a hole in the 1068 firewall/NAT and to aid the server for port binding and address 1069 mapping) from its client, it copies the source IP and Port number and 1070 uses them as delivery address for media packets. By having the 1071 server send media traffic back the same way as the client's packet 1072 are sent to the server, address mappings will be honored. Therefore 1073 this technique works for all types of NATs, given that the server is 1074 not behind a NAT. However, it does require server modifications. 1075 The format of the latching packet will have to be defined. 1077 Latching is very vulnerable to both hijacking and becoming a tool in 1078 Distributed Denial of Service (DDoS) attacks (See Security 1079 Considerations of [RFC7362]), because attackers can simply forge the 1080 source IP & Port of the latching packet. Using the rule for 1081 restricting IP address to the one of the signaling connection will 1082 need to be applied here also. However, that does not protect against 1083 hijacking from another client behind the same NAT. This can become a 1084 serious issue in deployments with CGNs. 1086 4.4.2. Necessary RTSP extensions 1088 To support Latching, the RTSP signaling must be extended to allow the 1089 RTSP client to indicate that it will use Latching. The client also 1090 needs to be able to signal its RTP SSRC to the server in its SETUP 1091 request. The RTP SSRC is used to establish some basic level of 1092 security against hijacking attacks or simply avoid mis-association 1093 when multiple clients are behind the same NAT. Care must be taken in 1094 choosing clients' RTP SSRC. First, it must be unique within all the 1095 RTP sessions belonging to the same RTSP session. Secondly, if the 1096 RTSP server is sending out media packets to multiple clients from the 1097 same send port, the RTP SSRC needs to be unique among those clients' 1098 RTP sessions. Recognizing that there is a potential that RTP SSRC 1099 collisions may occur, the RTSP server must be able to signal to a 1100 client that a collision has occurred and that it wants the client to 1101 use a different RTP SSRC carried in the SETUP response or use unique 1102 ports per RTSP session. Using unique ports limits an RTSP server in 1103 the number of sessions it can simultaneously handle per interface IP 1104 addresses. 1106 The latching packet as discussed above should have field which can 1107 contain an client and RTP session identifier to correctly associate 1108 the latching packet with the correct context. If an RTP packet is to 1109 be used, there would have been a benefit to use a well defined RTP 1110 payload format for this purpose as the No-Op payload format proposed 1111 [I-D.ietf-avt-rtp-no-op]. However, in the absence of such a 1112 specification an RTP packet without a payload could be used. Using 1113 SSRC has the benefit that RTP and RTCP both would work as is. 1114 However, also other packet formats could be used that carry the 1115 necessary identification of the context, and such a solution is 1116 discussed in Section 4.5. 1118 4.4.3. ALG Considerations 1120 An RTSP ALG not supporting this method could interfer with the 1121 methods used to indicate that latching is to be done, as well as the 1122 SSRC signalling. Thus preventing the method from working. However, 1123 if the RTSP ALG instead opens the corresponding pinholes and create 1124 the necessary mapping in the NAT, traversal will still work. 1125 Securing the RTSP message transport using TLS will avoid this issue. 1127 An RTSP ALG that support this traversal method can for basic 1128 functionality simply pass the related signalling parameters 1129 transparently. Due to the security considerations for latching it 1130 might exist a benefit for an RTSP ALG that will enable NAT traversal 1131 to negotiate with the path and turn off the latching procedures when 1132 the ALG handles this. However, this opens up to failure modes when 1133 there are multiple levels of NAT and only one supports an RTSP ALG. 1135 4.4.4. Deployment Considerations 1137 Advantages: 1139 o Works for all types of client-facing NATs. (Requirement 1 in 1140 Section 3). 1142 o Has little interaction problems with any RTSP ALG changing the 1143 client's information in the transport header. 1145 Disadvantages: 1147 o Requires modifications to both RTSP server and client. 1149 o Limited to work with servers that are not behind a NAT. 1151 o The format of the packet for "connection setup" (a.k.a Latching 1152 packet) is not defined. 1154 o SSRC management if RTP is used for latching due to risk for mis- 1155 association of clients to RTSP sessions at the server if SSRC 1156 collision occurs. 1158 o Has significant security considerations (See Section 4.4.5), due 1159 to lack of a strong authentication mechanism and will need to use 1160 address restrictions. 1162 4.4.5. Security Consideration 1164 Latching's major security issue is that RTP streams can be hijacked 1165 and directed towards any target that the attacker desires unless 1166 address restrictions are used. In the case of NATs with multiple 1167 clients on the inside of them, hijacking can still occur. This 1168 becomes a significant threat in the context of carrier grade NATs 1169 (CGN). 1171 The most serious security problem is the deliberate attack with the 1172 use of a RTSP client and Latching. The attacker uses RTSP to setup a 1173 media session. Then it uses Latching with a spoofed source address 1174 of the intended target of the attack. There is no defense against 1175 this attack other than restricting the possible address a latching 1176 packet can come from to the same as the RTSP TCP connection are from. 1177 This prevents Latching to be used in use cases that require different 1178 addresses for media destination and signalling. Even allowing only a 1179 limited address range containing the signalling address from where 1180 latching is allowed opens up a significant vulnerability as it is 1181 difficult to determine the address usage for the network the client 1182 connects from. 1184 A hijack attack can also be performed in various ways. The basic 1185 attack is based on the ability to read the RTSP signaling packets in 1186 order to learn the address and port the server will send from and 1187 also the SSRC the client will use. Having this information the 1188 attacker can send its own Latching packets containing the correct RTP 1189 SSRC to the correct address and port on the server. The RTSP server 1190 will then use the source IP and port from the Latching packet as the 1191 destination for the media packets it sends. 1193 Another variation of this attack is for a man in the middle to modify 1194 the RTP latching packet being sent by a client to the server by 1195 simply changing the source IP and port to the target one desires to 1196 attack. 1198 One can fend off the snooping based attack by applying encryption to 1199 the RTSP signaling transport. However, if the attacker is a man in 1200 the middle modifying latching packets, the attack is impossible to 1201 defend against other than through address restrictions. As a NAT re- 1202 writes the source IP and (possibly) port this cannot be 1203 authenticated, but authentication is required in order to protect 1204 against this type of DoS attack. 1206 Yet another issue is that these attacks also can be used to deny the 1207 client the service it desires from the RTSP server completely. The 1208 attacker modifies or originates its own latching packets with another 1209 port than what the legit latching packets uses, which results in that 1210 the media server sends the RTP/RTCP traffic to ports the client isn't 1211 listening for RTP/RTCP on. 1213 The amount of random non-guessable material in the latching packet 1214 determines how well Latching can fend off stream-hijacking performed 1215 by parties that are off the client to server network path, i.e. lacks 1216 the capability to see the client's latching packets. The proposal 1217 above uses the 32-bit RTP SSRC field to this effect. Therefore it is 1218 important that this field is derived with a non-predictable random 1219 number generator. It should not be possible by knowing the algorithm 1220 used and a couple of basic facts, to derive what random number a 1221 certain client will use. 1223 An attacker not knowing the SSRC but aware of which port numbers that 1224 a server sends from can deploy a brute force attack on the server by 1225 testing a lot of different SSRCs until it finds a matching one. 1226 Therefore a server could implement functionality that blocks packets 1227 to ports or from sources that receive or send multiple Latching 1228 packets with different invalid SSRCs, especially when they are coming 1229 from the same IP/Port. Note that this mitigation in itself opens up 1230 a new venue for DoS attacks against legit users trying to latch. 1232 To improve the security against attackers the amount of random 1233 material could be increased. To achieve a longer random tag while 1234 still using RTP and RTCP, it will be necessary to develop RTP and 1235 RTCP payload formats for carrying the random material. 1237 4.5. A Variation to Latching 1239 4.5.1. Introduction 1241 Latching as described above requires the usage of a valid RTP format 1242 as the Latching packet, i.e. the first packet that the client sends 1243 to the server to establish a bi-directional transport flow for RTP 1244 streams. There is currently no appropriate RTP packet format for 1245 this purpose, although the RTP No-Op format was a proposal to fix the 1246 problem [I-D.ietf-avt-rtp-no-op], however, that work was abandoned. 1247 There exists a RFC that discusses the implication of different type 1248 of packets as keep-alives for RTP [RFC6263] and its findings are very 1249 relevant to the format of the Latching packet. 1251 Meanwhile, there has been NAT/firewall traversal techniques deployed 1252 in the wireless streaming market place that use non-RTP messages as 1253 Latching packets. This section describes a variant based on a subset 1254 of those solutions that alters the previously described Latching 1255 solution. 1257 4.5.2. Necessary RTSP extensions 1259 In this variation of Latching, the Latching packet is a small UDP 1260 packet that does not contain an RTP header. In response to the 1261 client's Latching packet, the RTSP server sends back a similar 1262 Latching packet as a confirmation so the client can stop the so 1263 called "connection phase" of this NAT traversal technique. 1264 Afterwards, the client only has to periodically send Latching packets 1265 as keep-alive messages for the NAT mappings. 1267 The server listens on its RTP-media output port, and tries to decode 1268 any received UDP packet as Latching packet. This is valid since an 1269 RTSP server is not expecting RTP traffic from the RTSP client. Then, 1270 it can correlate the Latching packet with the RTSP client's session 1271 ID or the client's SSRC, and record the NAT bindings accordingly. 1272 The server then sends a Latching packet as the response to the 1273 client. 1275 The Latching packet can contain the SSRC to identify the RTP stream, 1276 and care must be taken if the packet is bigger than 12 bytes, 1277 ensuring that it is distinctively different from RTP packets, whose 1278 header size is 12 bytes. 1280 RTSP signaling can be added to do the following: 1282 1. Enable or disable such Latching message exchanges. When the 1283 firewall/NAT has an RTSP-aware ALG, it is possible to disable 1284 Latching message exchange and let the ALG work out the address 1285 and port mappings. 1287 2. Configure the number of re-tries and the re-try interval of the 1288 Latching message exchanges. 1290 4.5.3. ALG Considerations 1292 See Latching ALG consideration Section 4.4.3. 1294 4.5.4. Deployment Considerations 1296 This approach has the following advantages when compared with the 1297 Latching approach (Section 4.4): 1299 1. There is no need to define RTP payload format for firewall 1300 traversal, therefore it is simple to use, implement and 1301 administer (Requirement 4 in Section 3), instead a Latching 1302 protocol must be defined. 1304 2. When properly defined, this kind of Latching packet exchange can 1305 also authenticate RTP receivers, to prevent hijacking attacks. 1307 This approach has the following disadvantages when compared with the 1308 Latching approach: 1310 1. The server's sender SSRC for the RTP stream or other session 1311 Identity information must be signaled in RTSP's SETUP response, 1312 in the Transport header of the RTSP SETUP response. 1314 4.5.5. Security Considerations 1316 Compared to the security properties of Latching this variant is 1317 slightly improved. First of all it allows for a larger random field 1318 in the Latching packets which makes it more unlikely for an off-path 1319 attacker to succeed in a hi-jack attack. Secondly the confirmation 1320 allows the client to know when Latching works and when it didn't and 1321 thus restart the Latching process by updating the SSRC. 1323 Still the main security issue remain that the RTSP server can't know 1324 that the source address in the latching packet was coming from a RTSP 1325 client wanting to receive media and not one that likes to direct the 1326 media traffic to an DoS target. 1328 4.6. Three Way Latching 1330 4.6.1. Introduction 1332 The three way latching is an attempt to try to resolve the most 1333 significant security issues for both previously discussed variants of 1334 Latching. By adding a server request response exchange directly 1335 after the initial latching the server can verify that the target 1336 address present in the latching packet is an active listener and 1337 confirm its desire to establish a media flow. 1339 4.6.2. Necessary RTSP extensions 1341 Uses the same RTSP extensions as the alternative latching method 1342 (Section 4.5) uses. The extensions for this variant are only in the 1343 format and transmission of the Latching packets. 1345 The client to server latching packet is similar to the Alternative 1346 Latching (Section 4.5), i.e. an UDP packet with some session 1347 identifier and a random value. When the server responds to the 1348 Latching packet with a Latching confirmation, it includes a random 1349 value (Nonce) of its own in addition to echoing back the one the 1350 client sent. Then a third message is added to the exchange. The 1351 client acknowledges the reception of the Latching confirmation 1352 message and echoes back the server's nonce. Thus confirming that the 1353 Latched address goes to a RTSP client that initiated the latching and 1354 is actually present at that address. The RTSP server will refuse to 1355 send any media until the Latching Acknowledgement has been received 1356 with a valid nonce. 1358 4.6.3. ALG Considerations 1360 See Latching ALG consideration Section 4.4.3. 1362 4.6.4. Deployment Considerations 1364 A solution with a 3-way handshake and its own Latching packets can be 1365 compared with the ICE-based solution (Section 4.3) and have the 1366 following differences: 1368 o Only works for servers that are not behind a NAT. 1370 o May be simpler to implement due to the avoidance of the ICE 1371 prioritization and check-board mechanisms. 1373 However, a 3-way Latching protocol is very similar to using STUN in 1374 both directions as Latching and verification protocol. Using STUN 1375 would remove the need for implementing a new protocol. 1377 4.6.5. Security Considerations 1379 The three way latching is significantly securer than its simpler 1380 versions discussed above. The client to server nonce which is 1381 included in signalling and also can be bigger than the 32-bits of 1382 random data that the SSRC field supports makes it very difficult for 1383 an off-path attacker to perform an denial of service attack by 1384 diverting the media. 1386 The client to server nonce and its echoing back does not protect 1387 against on-patch attacker, including malicious clients. However, the 1388 server to client nonce and its echoing back prevents malicious 1389 clients to divert the media stream by spoofing the source address and 1390 port, as it can't echo back the nonce in these cases. 1392 Three way latching is really only vulnerable to an on-path attacker 1393 that is quite capable. First the attacker can either learn the 1394 client to server nonce, by intercepting the signalling, or modifying 1395 the source information (target destination) of a client's latching 1396 packet. Secondly, it is also on-path between the server and target 1397 destination and can generate a response using the server's nonce. An 1398 adversary that has these capabilities are commonly capable of causing 1399 significantly worse damage than this using other methods. 1401 Three-way latching do results in that the server to client packet is 1402 bigger than the client to server packet, due to the inclusion of the 1403 server to client nonce in addition to the client to server nonce. 1404 Thus an amplification effect do exist, however, to achieve this 1405 amplification effect the attacker has to create a session state on 1406 the RTSP server. The RTSP server can also limit the number of 1407 response it will generate before considering the latching to be 1408 failed. 1410 4.7. Application Level Gateways 1412 4.7.1. Introduction 1414 An Application Level Gateway (ALG) reads the application level 1415 messages and performs necessary changes to allow the protocol to work 1416 through the middle box. However this behavior has some problems in 1417 regards to RTSP: 1419 1. It does not work when the RTSP protocol is used with end-to-end 1420 security. As the ALG can't inspect and change the application 1421 level messages the protocol will fail due to the middle box. 1423 2. ALGs need to be updated if extensions to the protocol are added. 1424 Due to deployment issues with changing ALGs this may also break 1425 the end-to-end functionality of RTSP. 1427 Due to the above reasons it is not recommended to use an RTSP ALG in 1428 NATs. This is especially important for NATs targeted to home users 1429 and small office environments, since it is very hard to upgrade NATs 1430 deployed in home or SOHO (small office/home office) environment. 1432 4.7.2. Outline On how ALGs for RTSP work 1434 In this section, we provide a step-by-step outline on how one could 1435 go about writing an ALG to enable RTSP to traverse a NAT. 1437 1. Detect any SETUP request. 1439 2. Try to detect the usage of any of the NAT traversal methods that 1440 replace the address and port of the Transport header parameters 1441 "destination" or "dest_addr". If any of these methods are used, 1442 then the ALG should not change the address. Ways to detect that 1443 these methods are used are: 1445 * For embedded STUN, it would be to watch for a feature tag, 1446 like "nat.stun". If any of those exists in the "supported", 1447 "proxy-require", or "require" headers of the RTSP exchange. 1449 * For stand alone STUN and TURN based solutions: This can be 1450 detected by inspecting the "destination" or "dest_addr" 1451 parameter. If it contains either one of the NAT's external IP 1452 addresses or a public IP address then such a solution is in 1453 use. However if multiple NATs are used this detection may 1454 fail. Remapping should only be done for addresses belonging 1455 to the NAT's own private address space. 1457 Otherwise continue to the next step. 1459 3. Create UDP mappings (client given IP/port <-> external IP/port) 1460 where needed for all possible transport specifications in the 1461 transport header of the request found in (1). Enter the external 1462 address and port(s) of these mappings in transport header. 1463 Mappings shall be created with consecutive external port numbers 1464 starting on an even number for RTP for each media stream. 1465 Mappings should also be given a long timeout period, at least 5 1466 minutes. 1468 4. When the SETUP response is received from the server, the ALG may 1469 remove the unused UDP mappings, i.e. the ones not present in the 1470 transport header. The session ID should also be bound to the UDP 1471 mappings part of that session. 1473 5. If SETUP response settles on RTP over TCP or RTP over RTSP as 1474 lower transport, do nothing: let TCP tunneling take care of NAT 1475 traversal. Otherwise go to next step. 1477 6. The ALG should keep the UDP mappings belonging to the RTSP 1478 session as long as: an RTSP message with the session's ID has 1479 been sent in the last timeout interval, or a UDP message has been 1480 sent on any of the UDP mappings during the last timeout interval. 1482 7. The ALG may remove a mapping as soon a TEARDOWN response has been 1483 received for that media stream. 1485 4.7.3. Deployment Considerations 1487 Advantage: 1489 o No impact on either client or server 1490 o Can work for any type of NATs 1492 Disadvantage: 1494 o When deployed they are hard to update to reflect protocol 1495 modifications and extensions. If not updated they will break the 1496 functionality. 1498 o When end-to-end security is used, the ALG functionality will fail. 1500 o Can interfere with other types of traversal mechanisms, such as 1501 STUN. 1503 Transition: 1505 An RTSP ALG will not be phased out in any automatic way. It must be 1506 removed, probably through the removal or update of the NAT it is 1507 associated with. 1509 4.7.4. Security Considerations 1511 An ALG will not work with deployment of end-to-end RTSP signaling 1512 security, however it will work with the hop-by-hop security method 1513 defined in Section 19.3 of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. 1514 Therefore deployment of ALG may result in clients located behind NATs 1515 not using end-to-end security, or more likely the selection a NAT 1516 traversal solution that allow for security. 1518 The creation of an UDP mapping based on the signalling message has 1519 some potential security implications. First of all if the RTSP 1520 client releases its ports and another application are assigned these 1521 instead it could receive RTP media as long as the mappings exist and 1522 the RTSP server has failed to be signalled or notice the lack of 1523 client response. 1525 A NAT with RTSP ALG that assigns mappings based on SETUP requests 1526 could potentially become victim of a resource exhaustion attack. If 1527 an attacker creates a lot of RTSP sessions, even without starting 1528 media transmission could exhaust the pool of available UDP ports on 1529 the NAT. Thus only a limited number of UDP mappings should be 1530 allowed to be created by the RTSP ALG. 1532 4.8. TCP Tunneling 1533 4.8.1. Introduction 1535 Using a TCP connection that is established from the client to the 1536 server ensures that the server can send data to the client. The 1537 connection opened from the private domain ensures that the server can 1538 send data back to the client. To send data originally intended to be 1539 transported over UDP requires the TCP connection to support some type 1540 of framing of the media data packets. Using TCP also results in the 1541 client having to accept that real-time performance can be impacted. 1542 TCP's problem of ensuring timely delivery was one of the reasons why 1543 RTP was developed. Problems that arise with TCP are: head-of-line 1544 blocking, delay introduced by retransmissions, highly varying rate 1545 due to the congestion control algorithm. If sufficient amount of 1546 buffering (several seconds) in the receiving client can be tolerated 1547 then TCP clearly work. 1549 4.8.2. Usage of TCP tunneling in RTSP 1551 The RTSP core specification [I-D.ietf-mmusic-rfc2326bis] supports 1552 interleaving of media data on the TCP connection that carries RTSP 1553 signaling. See section 14 in [I-D.ietf-mmusic-rfc2326bis] for how to 1554 perform this type of TCP tunneling. There also exists another way of 1555 transporting RTP over TCP defined in Appendix C.2 in 1556 [I-D.ietf-mmusic-rfc2326bis]. For signaling and rules on how to 1557 establish the TCP connection in lieu of UDP, see appendix C.2 in 1558 [I-D.ietf-mmusic-rfc2326bis]. This is based on the framing of RTP 1559 over the TCP connection as described in RFC 4571 [RFC4571]. 1561 4.8.3. ALG Considerations 1563 An RTSP ALG will face a different issue with TCP tunneling, at least 1564 the Interleaved version. Now the full data stream will flow can end 1565 up flowing through the ALG implementation. Thus it is important that 1566 the ALG is efficient in dealing with the interleaved media data 1567 frames to avoid consuming to much resource and thus creating 1568 performance issues. 1570 The RTSP ALG can also effect the transport specifications that 1571 indicate that TCP tunneling can be done and its priortization, 1572 including removing the transport specification, thus preventing TCP 1573 tunneling. 1575 4.8.4. Deployment Considerations 1577 Advantage: 1579 o Works through all types of NATs where the RTSP server in not NATed 1580 or at least reachable like it was not. 1582 Disadvantage: 1584 o Functionality needs to be implemented on both server and client. 1586 o Will not always meet multimedia stream's real-time requirements. 1588 Transition: 1590 The tunneling over RTSP's TCP connection is not planned to be phased- 1591 out. It is intended to be a fallback mechanism and for usage when 1592 total media reliability is desired, even at the potential price of 1593 loss of real-time properties. 1595 4.8.5. Security Considerations 1597 The TCP tunneling of RTP has no known significant security problems 1598 besides those already presented in the RTSP specification. It is 1599 difficult to get any amplification effect for denial of service 1600 attacks due to TCP's flow control. The RTSP server TCP socket, 1601 independently if used for media tunneling or only RTSP messages can 1602 be used for a redirected syn attack. By spoofing the source address 1603 of any TCP init packets, the TCP SYNs from the server can be directed 1604 towards a target. 1606 A possible security consideration, when session media data is 1607 interleaved with RTSP, would be the performance bottleneck when RTSP 1608 encryption is applied, since all session media data also needs to be 1609 encrypted. 1611 4.9. TURN (Traversal Using Relay NAT) 1613 4.9.1. Introduction 1615 Traversal Using Relay NAT (TURN) [RFC5766] is a protocol for setting 1616 up traffic relays that allow clients behind NATs and firewalls to 1617 receive incoming traffic for both UDP and TCP. These relays are 1618 controlled and have limited resources. They need to be allocated 1619 before usage. TURN allows a client to temporarily bind an address/ 1620 port pair on the relay (TURN server) to its local source address/port 1621 pair, which is used to contact the TURN server. The TURN server will 1622 then forward packets between the two sides of the relay. 1624 To prevent DoS attacks on either recipient, the packets forwarded are 1625 restricted to the specific source address. On the client side it is 1626 restricted to the source setting up the allocation. On the external 1627 side this is limited to the source address/port pair that have been 1628 given permission by the TURN client creating the allocation. Packets 1629 from any other source on this address will be discarded. 1631 Using a TURN server makes it possible for a RTSP client to receive 1632 media streams from even an unmodified RTSP server. However the 1633 problem is those RTSP servers most likely restrict media destinations 1634 to no other IP address than the one the RTSP message arrives from. 1635 This means that TURN could only be used if the server knows and 1636 accepts that the IP belongs to a TURN server and the TURN server 1637 can't be targeted at an unknown address. Alternatively, both the 1638 RTSP TCP connection as well as the RTP media is relayed through the 1639 same TURN server. 1641 4.9.2. Usage of TURN with RTSP 1643 To use a TURN server for NAT traversal, the following steps should be 1644 performed. 1646 1. The RTSP client connects with the RTSP server. The client 1647 retrieves the session description to determine the number of 1648 media streams. To avoid the issue with having RTSP connection 1649 and media traffic from different addresses also the TCP 1650 connection must be done through the same TURN server as the one 1651 in the next step. This will require the usage of TURN for TCP 1652 [RFC6062]. 1654 2. The client establishes the necessary bindings on the TURN server. 1655 It must choose the local RTP and RTCP ports that it desires to 1656 receive media packets. TURN supports requesting bindings of even 1657 port numbers and contiguous ranges. 1659 3. The RTSP client uses the acquired address and port allocations in 1660 the RTSP SETUP request using the destination header. 1662 4. The RTSP Server sends the SETUP reply, which must include the 1663 transport headers src_addr parameter (source and port in RTSP 1664 1.0). Note that the server is required to have a mechanism to 1665 verify that it is allowed to send media traffic to the given 1666 address unless TCP relaying of the RTSP messages also is 1667 performed. 1669 5. The RTSP Client uses the RTSP Server's response to create TURN 1670 permissions for the server's media traffic. 1672 6. The client requests that the server starts playing. The server 1673 starts sending media packets to the given destination address and 1674 ports. 1676 7. Media packets arrive at the TURN server on the external port; If 1677 the packets match an established permission, the TURN server 1678 forwards the media packets to the RTSP client. 1680 8. If the client pauses and media is not sent for about 75% of the 1681 mapping timeout the client should use TURN to refresh the 1682 bindings. 1684 4.9.3. ALG Considerations 1686 As the RTSP client inserts the address information of the TURN 1687 relay's external allocations in the SETUP messages, and ALG that 1688 replaces the address, without considering that the address do not 1689 belong to the internal address realm of the NAT, will prevent this 1690 mechanism from working. This can be prevented by securing the RTSP 1691 signalling. 1693 4.9.4. Deployment Considerations 1695 Advantages: 1697 o Does not require any server modifications given that the server 1698 includes the src_addr header in the SETUP response. 1700 o Works for any type of NAT as long as the RTSP server has reachable 1701 IP address that is not behind a NAT. 1703 Disadvantage: 1705 o Requires another network element, namely the TURN server. 1707 o A TURN server for RTSP may not scale since the number of sessions 1708 it must forward is proportional to the number of client media 1709 sessions. 1711 o The TURN server becomes a single point of failure. 1713 o Since TURN forwards media packets, it necessarily introduces 1714 delay. 1716 o An RTSP ALG may change the necessary destinations parameter. This 1717 will cause the media traffic to be sent to the wrong address. 1719 Transition: 1721 TURN is not intended to be phased-out completely, see Section 19 of 1722 [RFC5766]. However the usage of TURN could be reduced when the 1723 demand for having NAT traversal is reduced. 1725 4.9.5. Security Considerations 1727 The TURN server can become part of a denial of service attack towards 1728 any victim. To perform this attack the attacker must be able to 1729 eavesdrop on the packets from the TURN server towards a target for 1730 the DoS attack. The attacker uses the TURN server to setup a RTSP 1731 session with media flows going through the TURN server. The attacker 1732 is in fact creating TURN mappings towards a target by spoofing the 1733 source address of TURN requests. As the attacker will need the 1734 address of these mappings he must be able to eavesdrop or intercept 1735 the TURN responses going from the TURN server to the target. Having 1736 these addresses, he can set up a RTSP session and start delivery of 1737 the media. The attacker must be able to create these mappings. The 1738 attacker in this case may be traced by the TURN username in the 1739 mapping requests. 1741 This attack requires that the attacker has access to a user account 1742 on the TURN server to be able set up the TURN mappings. To prevent 1743 this attack the RTSP server needs to verify that the ultimate target 1744 destination accept this media stream. Which would require something 1745 like ICE's connectivity checks being run between the RTSP server and 1746 the RTSP client. 1748 5. Firewalls 1750 Firewalls exist for the purpose of protecting a network from traffic 1751 not desired by the firewall owner. Therefore it is a policy decision 1752 if a firewall will let RTSP and its media streams through or not. 1753 RTSP is designed to be firewall friendly in that it should be easy to 1754 design firewall policies to permit passage of RTSP traffic and its 1755 media streams. 1757 The firewall will need to allow the media streams associated with a 1758 RTSP session to pass through it. Therefore the firewall will need an 1759 ALG that reads RTSP SETUP and TEARDOWN messages. By reading the 1760 SETUP message the firewall can determine what type of transport and 1761 from where, the media stream packets will be sent. Commonly there 1762 will be the need to open UDP ports for RTP/RTCP. By looking at the 1763 source and destination addresses and ports the opening in the 1764 firewall can be minimized to the least necessary. The opening in the 1765 firewall can be closed after a TEARDOWN message for that session or 1766 the session itself times out. 1768 The above possibilities for firewalls to inspect and respond to the 1769 signalling are prevented if end-to-end confidentiality protection is 1770 used for the RTSP signalling, e.g. using the specified RTSP over TLS. 1771 This results in that firewalls can't be actively opening pinholes for 1772 the media streams based on the signalling. To enable an RTSP ALG in 1773 firewall to correctly function the hop-by-hop signalling security 1774 (See Section 19.3) in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] can be 1775 used. If not, other methods have to be used to enable the transport 1776 flows for the media. 1778 Simpler firewalls do allow a client to receive media as long as it 1779 has sent packets to the target. Depending on the security level this 1780 can have the same behavior as a NAT. The only difference is that no 1781 address translation is done. To use such a firewall a client would 1782 need to implement one of the above described NAT traversal methods 1783 that include sending packets to the server to open up the mappings. 1785 6. Comparison of NAT traversal techniques 1787 This section evaluates the techniques described above against the 1788 requirements listed in Section 3. 1790 In the following table, the columns correspond to the numbered 1791 requirements. For instance, the column under R1 corresponds to the 1792 first requirement in Section 3: must work for all flavors of NATs. 1793 The rows represent the different NAT/firewall traversal techniques. 1794 Latch is short for Latching, "V. Latch" is short for "variation of 1795 Latching" as described in Section 4.5. "3-W Latch" is short for the 1796 Three Way Latching described in Section 4.6. 1798 A Summary of the requirements are: 1800 R1: Work for all flavors of NATs 1802 R2: Must work with firewalls, including those with ALGs 1804 R3: Should have minimal impact on clients not behind NATs, counted 1805 in minimal number of additional RTTs 1807 R4: Should be simple to use, Implement and administer. 1809 R5: Should provide mitigation against DDoS attacks 1811 The following considerations are also added to requirements: 1813 C1: Will solution support both Clients and Servers behind NAT 1815 C2: Is the solution robust to changing NAT behaviors 1816 ------------+------+------+------+------+------+------+------+ 1817 | R1 | R2 | R3 | R4 | R5 | C1 | C2 | 1818 ------------+------+------+------+------+------+------+------+ 1819 STUN | No | Yes | 1 | Maybe| No | No | No | 1820 ------------+------+------+------+------+------+------+------+ 1821 Emb. STUN | Yes | Yes | 2 | Maybe| No | No | Yes | 1822 ------------+------+------+------+------+------+------+------+ 1823 ICE | Yes | Yes | 2.5 | No | Yes | Yes | Yes | 1824 ------------+------+------+------+------+------+------+------+ 1825 Latch | Yes | Yes | 1 | Maybe| No | No | Yes | 1826 ------------+------+------+------+------+------+------+------+ 1827 V. Latch | Yes | Yes | 1 | Yes | No | No | Yes | 1828 ------------+------+------+------+------+------+------+------+ 1829 3-W Latch | Yes | Yes | 1.5 | Maybe| Yes | No | Yes | 1830 ------------+------+------+------+------+------+------+------+ 1831 ALG |(Yes) | Yes | 0 | No | Yes | No | Yes | 1832 ------------+------+------+------+------+------+------+------+ 1833 TCP Tunnel | Yes | Yes | 1.5 | Yes | Yes | No | Yes | 1834 ------------+------+------+------+------+------+------+------+ 1835 TURN | Yes | Yes | 1 | No | Yes |(Yes) | Yes | 1836 ------------+------+------+------+------+------+------+------+ 1838 Figure 1: Comparison of fulfillment of requirements 1840 Looking at Figure 1 one would draw the conclusion that using TCP 1841 Tunneling or Three-Way Latching is the solutions that best fulfill 1842 the requirements. The different techniques were discussed in the 1843 MMUSIC WG. It was established that the WG would pursue an ICE based 1844 solution due to its generality and capability of handling also 1845 servers delivering media from behind NATs. TCP Tunneling is likely 1846 to be available as an alternative, due to its specification in the 1847 main RTSP specification. Thus it can be used if desired and the 1848 potential downsides of using TCP is acceptable in particular 1849 deployments. When it comes to Three-Way Latching it is a very 1850 competitive technique given that you don't need support for RTSP 1851 servers behind NATs. There were some discussion in the WG if the 1852 increased implementation burden of ICE is sufficiently motivated 1853 compared to a the Three-Way Latching solution for this generality. 1854 In the end the authors believe that reuse of ICE, the greater 1855 flexibility and anyway need to deploy a new solution was the decisive 1856 factors. 1858 The ICE based RTSP NAT traversal solution is specified in "A Network 1859 Address Translator (NAT) Traversal mechanism for media controlled by 1860 Real-Time Streaming Protocol (RTSP)" [I-D.ietf-mmusic-rtsp-nat]. 1862 7. IANA Considerations 1864 This document makes no request of IANA. 1866 Note to RFC Editor: this section may be removed on publication as an 1867 RFC. 1869 8. Security Considerations 1871 In the preceding sections we have discussed security merits of the 1872 different NAT/firewall traversal methods for RTSP discussed here. In 1873 summary, the presence of NAT(s) is a security risk, as a client 1874 cannot perform source authentication of its IP address. This 1875 prevents the deployment of any future RTSP extensions providing 1876 security against hijacking of sessions by a man-in-the-middle. 1878 Each of the proposed solutions has security implications. Using STUN 1879 will provide the same level of security as RTSP without transport 1880 level security and source authentications, as long as the server does 1881 not allow media to be sent to a different IP-address than the RTSP 1882 client request was sent from. 1884 Using Latching will have a higher risk of session hijacking or denial 1885 of service than normal RTSP. The reason is that there exists a 1886 probability that an attacker is able to guess the random bits that 1887 the client uses to prove its identity when creating the address 1888 bindings. This can be solved in the variation of Latching 1889 (Section 4.5) with authentication features. Still both those 1890 variants of Latching are vulnerable against deliberate attack from 1891 the RTSP client to redirect the media stream requested to any target 1892 assuming it can spoof the source address. This security 1893 vulnerability is solved by performing a Three-way Latching procedure 1894 as discussed in Section 4.6. 1896 ICE resolves the binding vulnerability of latching by using signed 1897 STUN messages, as well as requiring that both sides perform 1898 connectivity checks to verify that the target IP address in the 1899 candidate pair is both reachable and willing to respond. ICE can 1900 however create a significant amount of traffic if the number of 1901 candidate pairs are large. Thus pacing is required and 1902 implementations should attempt to limit their number of candidates to 1903 reduce the number of packets. 1905 If the signalling between the ICE peers (RTSP client and Server) is 1906 not confidentiality and integrity protected ICE is vulnerable to 1907 attacks where the candidate list is manipulated. Lack of signalling 1908 security will also simplify spoofing of STUN binding messages by 1909 revealing the secret used in signing. 1911 The usage of an RTSP ALG does not in itself increase the risk for 1912 session hijacking. However the deployment of ALGs as the sole 1913 mechanism for RTSP NAT traversal will prevent deployment of end-to- 1914 end encrypted RTSP signaling. 1916 The usage of TCP tunneling has no known security problems. However, 1917 it might provide a bottleneck when it comes to end-to-end RTSP 1918 signaling security if TCP tunneling is used on an interleaved RTSP 1919 signaling connection. 1921 The usage of TURN has severe risk of denial of service attacks 1922 against a client. The TURN server can also be used as a redirect 1923 point in a DDoS attack unless the server has strict enough rules for 1924 who may create bindings. 1926 The latching and variant of latching have so big security issues that 1927 they should not be used at all. The three way latching as well as 1928 ICE mitigates these security issues and performs the important 1929 return-routability check that prevents spoofed source addresses, and 1930 should be recommended for that reason. RTP ALG's is a security risk 1931 as they can create an incitement against using secure RTSP 1932 signalling. That can be avoided as ALGs requires trust in the 1933 middlebox, and that trust becomes explicit if one uses the hop-by-hop 1934 security solution as specified in Section 19.3 of RTSP 2.0. 1935 [I-D.ietf-mmusic-rfc2326bis]. The remaining methods can be 1936 considered safe enough, assuming that the appropriate security 1937 mechanisms are used and not ignored. 1939 9. Acknowledgements 1941 The author would also like to thank all persons on the MMUSIC working 1942 group's mailing list that has commented on this document. Persons 1943 having contributed in such way in no special order to this protocol 1944 are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon, 1945 Amir Wolf, Anders Klemets, Flemming Andreasen, Ari Keranen, Bill 1946 Atwood, Alissa Cooper, Colin Perkins, Sarah Banks and David Black. 1947 Thomas Zeng would also like to give special thanks to Greg Sherwood 1948 of PacketVideo for his input into this memo. 1950 Section 1.1 contains text originally written for RFC 4787 by Francois 1951 Audet and Cullen Jennings. 1953 10. Informative References 1955 [I-D.ietf-avt-rtp-no-op] 1956 Andreasen, F., "A No-Op Payload Format for RTP", draft- 1957 ietf-avt-rtp-no-op-04 (work in progress), May 2007. 1959 [I-D.ietf-mmusic-rfc2326bis] 1960 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1961 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1962 (RTSP)", draft-ietf-mmusic-rfc2326bis-40 (work in 1963 progress), February 2014. 1965 [I-D.ietf-mmusic-rtsp-nat] 1966 Goldberg, J., Westerlund, M., and T. Zeng, "A Network 1967 Address Translator (NAT) Traversal Mechanism for Media 1968 Controlled by Real-Time Streaming Protocol (RTSP)", draft- 1969 ietf-mmusic-rtsp-nat-22 (work in progress), July 2014. 1971 [NICE] "Libnice - The GLib ICE implementation, 1972 http://nice.freedesktop.org/wiki/", May 2013. 1974 [PJNATH] "PJNATH - Open Source ICE, STUN, and TURN Library, 1975 http://www.pjsip.org/pjnath/docs/html/", May 2013. 1977 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1978 August 1980. 1980 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1981 793, September 1981. 1983 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1984 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1986 [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May 1987 1999. 1989 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1990 Translator (NAT) Terminology and Considerations", RFC 1991 2663, August 1999. 1993 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1994 Address Translator (Traditional NAT)", RFC 3022, January 1995 2001. 1997 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1998 A., Peterson, J., Sparks, R., Handley, M., and E. 1999 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2000 June 2002. 2002 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 2003 Self-Address Fixing (UNSAF) Across Network Address 2004 Translation", RFC 3424, November 2002. 2006 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 2007 "STUN - Simple Traversal of User Datagram Protocol (UDP) 2008 Through Network Address Translators (NATs)", RFC 3489, 2009 March 2003. 2011 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2012 Jacobson, "RTP: A Transport Protocol for Real-Time 2013 Applications", STD 64, RFC 3550, July 2003. 2015 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2016 Description Protocol", RFC 4566, July 2006. 2018 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 2019 and RTP Control Protocol (RTCP) Packets over Connection- 2020 Oriented Transport", RFC 4571, July 2006. 2022 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 2023 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 2024 RFC 4787, January 2007. 2026 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2027 BCP 131, RFC 4961, July 2007. 2029 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2030 (ICE): A Protocol for Network Address Translator (NAT) 2031 Traversal for Offer/Answer Protocols", RFC 5245, April 2032 2010. 2034 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 2035 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 2036 RFC 5382, October 2008. 2038 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 2039 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 2040 October 2008. 2042 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2043 Security (DTLS) Extension to Establish Keys for the Secure 2044 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 2046 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 2047 Relays around NAT (TURN): Relay Extensions to Session 2048 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 2050 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 2051 around NAT (TURN) Extensions for TCP Allocations", RFC 2052 6062, November 2010. 2054 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 2055 Keeping Alive the NAT Mappings Associated with RTP / RTP 2056 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 2058 [RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT 2059 Traversal (HNT) for Media in Real-Time Communication", RFC 2060 7362, September 2014. 2062 [STUN-IMPL] 2063 "Open Source STUN Server and Client, 2064 http://sourceforge.net/projects/stun/", May 2013. 2066 Authors' Addresses 2068 Magnus Westerlund 2069 Ericsson 2070 Farogatan 6 2071 Stockholm SE-164 80 2072 Sweden 2074 Phone: +46 8 719 0000 2075 Email: magnus.westerlund@ericsson.com 2077 Thomas Zeng 2079 Email: thomas.zeng@gmail.com