idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-evaluation-16.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 (May 19, 2015) is 3265 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: November 20, 2015 May 19, 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-16 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 November 20, 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 . . . . . . . . . . . . . . . . . . . . . . . . 23 87 4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . . 27 94 4.5.2. Necessary RTSP extensions . . . . . . . . . . . . . . 27 95 4.5.3. ALG Considerations . . . . . . . . . . . . . . . . . 28 96 4.5.4. Deployment Considerations . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . 29 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 . . . . . . . . . . 31 107 4.7.3. Deployment Considerations . . . . . . . . . . . . . . 32 108 4.7.4. Security Considerations . . . . . . . . . . . . . . . 32 109 4.8. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 33 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 . . . . . . . . . . . . . . 34 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 . . . . . . . . . . . . . . . . . . . 42 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. The ICE 1049 connectivity checks with their random transaction IDs from the server 1050 to the client serves as return-routability check and prevents off- 1051 path attacker to succeed with address spoofing. Similar to Mobile 1052 IPV6's return routability procedure (Section 5.2.5 of [RFC6275]). 1054 4.4. Latching 1056 4.4.1. Introduction 1058 Latching is a NAT traversal solution that is based on requiring RTSP 1059 clients to send UDP packets to the server's media output ports. 1060 Conventionally, RTSP servers send RTP packets in one direction: from 1061 server to client. Latching is similar to connection-oriented 1062 traffic, where one side (e.g., the RTSP client) first "connects" by 1063 sending a RTP packet to the other side's RTP port, the recipient then 1064 replies to the originating IP and port. This method is also referred 1065 to as "Late binding". It requires that all RTP/RTCP transport is 1066 done symmetrical, i.e. Symmetric RTP [RFC4961]. There exist a 1067 description for latching of SIP negotiated media streams in Session 1068 Border Controllers [RFC7362]. 1070 Specifically, when the RTSP server receives the latching packet 1071 (a.k.a. hole-punching packet, since it is used to punch a hole in the 1072 firewall/NAT and to aid the server for port binding and address 1073 mapping) from its client, it copies the source IP and Port number and 1074 uses them as delivery address for media packets. By having the 1075 server send media traffic back the same way as the client's packet 1076 are sent to the server, address mappings will be honored. Therefore 1077 this technique works for all types of NATs, given that the server is 1078 not behind a NAT. However, it does require server modifications. 1079 The format of the latching packet will have to be defined. 1081 Latching is very vulnerable to both hijacking and becoming a tool in 1082 Distributed Denial of Service (DDoS) attacks (See Security 1083 Considerations of [RFC7362]), because attackers can simply forge the 1084 source IP & Port of the latching packet. Using the rule for 1085 restricting IP address to the one of the signaling connection will 1086 need to be applied here also. However, that does not protect against 1087 hijacking from another client behind the same NAT. This can become a 1088 serious issue in deployments with CGNs. 1090 4.4.2. Necessary RTSP extensions 1092 To support Latching, the RTSP signaling must be extended to allow the 1093 RTSP client to indicate that it will use Latching. The client also 1094 needs to be able to signal its RTP SSRC to the server in its SETUP 1095 request. The RTP SSRC is used to establish some basic level of 1096 security against hijacking attacks or simply avoid mis-association 1097 when multiple clients are behind the same NAT. Care must be taken in 1098 choosing clients' RTP SSRC. First, it must be unique within all the 1099 RTP sessions belonging to the same RTSP session. Secondly, if the 1100 RTSP server is sending out media packets to multiple clients from the 1101 same send port, the RTP SSRC needs to be unique among those clients' 1102 RTP sessions. Recognizing that there is a potential that RTP SSRC 1103 collisions may occur, the RTSP server must be able to signal to a 1104 client that a collision has occurred and that it wants the client to 1105 use a different RTP SSRC carried in the SETUP response or use unique 1106 ports per RTSP session. Using unique ports limits an RTSP server in 1107 the number of sessions it can simultaneously handle per interface IP 1108 addresses. 1110 The latching packet as discussed above should have field which can 1111 contain an client and RTP session identifier to correctly associate 1112 the latching packet with the correct context. If an RTP packet is to 1113 be used, there would have been a benefit to use a well defined RTP 1114 payload format for this purpose as the No-Op payload format proposed 1115 [I-D.ietf-avt-rtp-no-op]. However, in the absence of such a 1116 specification an RTP packet without a payload could be used. Using 1117 SSRC has the benefit that RTP and RTCP both would work as is. 1118 However, also other packet formats could be used that carry the 1119 necessary identification of the context, and such a solution is 1120 discussed in Section 4.5. 1122 4.4.3. ALG Considerations 1124 An RTSP ALG not supporting this method could interfer with the 1125 methods used to indicate that latching is to be done, as well as the 1126 SSRC signalling. Thus preventing the method from working. However, 1127 if the RTSP ALG instead opens the corresponding pinholes and create 1128 the necessary mapping in the NAT, traversal will still work. 1129 Securing the RTSP message transport using TLS will avoid this issue. 1131 An RTSP ALG that support this traversal method can for basic 1132 functionality simply pass the related signalling parameters 1133 transparently. Due to the security considerations for latching it 1134 might exist a benefit for an RTSP ALG that will enable NAT traversal 1135 to negotiate with the path and turn off the latching procedures when 1136 the ALG handles this. However, this opens up to failure modes when 1137 there are multiple levels of NAT and only one supports an RTSP ALG. 1139 4.4.4. Deployment Considerations 1141 Advantages: 1143 o Works for all types of client-facing NATs. (Requirement 1 in 1144 Section 3). 1146 o Has little interaction problems with any RTSP ALG changing the 1147 client's information in the transport header. 1149 Disadvantages: 1151 o Requires modifications to both RTSP server and client. 1153 o Limited to work with servers that are not behind a NAT. 1155 o The format of the packet for "connection setup" (a.k.a Latching 1156 packet) is not defined. 1158 o SSRC management if RTP is used for latching due to risk for mis- 1159 association of clients to RTSP sessions at the server if SSRC 1160 collision occurs. 1162 o Has significant security considerations (See Section 4.4.5), due 1163 to lack of a strong authentication mechanism and will need to use 1164 address restrictions. 1166 4.4.5. Security Consideration 1168 Latching's major security issue is that RTP streams can be hijacked 1169 and directed towards any target that the attacker desires unless 1170 address restrictions are used. In the case of NATs with multiple 1171 clients on the inside of them, hijacking can still occur. This 1172 becomes a significant threat in the context of carrier grade NATs 1173 (CGN). 1175 The most serious security problem is the deliberate attack with the 1176 use of a RTSP client and Latching. The attacker uses RTSP to setup a 1177 media session. Then it uses Latching with a spoofed source address 1178 of the intended target of the attack. There is no defense against 1179 this attack other than restricting the possible address a latching 1180 packet can come from to the same as the RTSP TCP connection are from. 1181 This prevents Latching to be used in use cases that require different 1182 addresses for media destination and signalling. Even allowing only a 1183 limited address range containing the signalling address from where 1184 latching is allowed opens up a significant vulnerability as it is 1185 difficult to determine the address usage for the network the client 1186 connects from. 1188 A hijack attack can also be performed in various ways. The basic 1189 attack is based on the ability to read the RTSP signaling packets in 1190 order to learn the address and port the server will send from and 1191 also the SSRC the client will use. Having this information the 1192 attacker can send its own Latching packets containing the correct RTP 1193 SSRC to the correct address and port on the server. The RTSP server 1194 will then use the source IP and port from the Latching packet as the 1195 destination for the media packets it sends. 1197 Another variation of this attack is for a man in the middle to modify 1198 the RTP latching packet being sent by a client to the server by 1199 simply changing the source IP and port to the target one desires to 1200 attack. 1202 One can fend off the snooping based attack by applying encryption to 1203 the RTSP signaling transport. However, if the attacker is a man in 1204 the middle modifying latching packets, the attack is impossible to 1205 defend against other than through address restrictions. As a NAT re- 1206 writes the source IP and (possibly) port this cannot be 1207 authenticated, but authentication is required in order to protect 1208 against this type of DoS attack. 1210 Yet another issue is that these attacks also can be used to deny the 1211 client the service it desires from the RTSP server completely. The 1212 attacker modifies or originates its own latching packets with another 1213 port than what the legit latching packets uses, which results in that 1214 the media server sends the RTP/RTCP traffic to ports the client isn't 1215 listening for RTP/RTCP on. 1217 The amount of random non-guessable material in the latching packet 1218 determines how well Latching can fend off stream-hijacking performed 1219 by parties that are off the client to server network path, i.e. lacks 1220 the capability to see the client's latching packets. The proposal 1221 above uses the 32-bit RTP SSRC field to this effect. Therefore it is 1222 important that this field is derived with a non-predictable random 1223 number generator. It should not be possible by knowing the algorithm 1224 used and a couple of basic facts, to derive what random number a 1225 certain client will use. 1227 An attacker not knowing the SSRC but aware of which port numbers that 1228 a server sends from can deploy a brute force attack on the server by 1229 testing a lot of different SSRCs until it finds a matching one. 1230 Therefore a server could implement functionality that blocks packets 1231 to ports or from sources that receive or send multiple Latching 1232 packets with different invalid SSRCs, especially when they are coming 1233 from the same IP/Port. Note that this mitigation in itself opens up 1234 a new venue for DoS attacks against legit users trying to latch. 1236 To improve the security against attackers the amount of random 1237 material could be increased. To achieve a longer random tag while 1238 still using RTP and RTCP, it will be necessary to develop RTP and 1239 RTCP payload formats for carrying the random material. 1241 4.5. A Variation to Latching 1242 4.5.1. Introduction 1244 Latching as described above requires the usage of a valid RTP format 1245 as the Latching packet, i.e. the first packet that the client sends 1246 to the server to establish a bi-directional transport flow for RTP 1247 streams. There is currently no appropriate RTP packet format for 1248 this purpose, although the RTP No-Op format was a proposal to fix the 1249 problem [I-D.ietf-avt-rtp-no-op], however, that work was abandoned. 1250 There exists a RFC that discusses the implication of different type 1251 of packets as keep-alives for RTP [RFC6263] and its findings are very 1252 relevant to the format of the Latching packet. 1254 Meanwhile, there has been NAT/firewall traversal techniques deployed 1255 in the wireless streaming market place that use non-RTP messages as 1256 Latching packets. This section describes a variant based on a subset 1257 of those solutions that alters the previously described Latching 1258 solution. 1260 4.5.2. Necessary RTSP extensions 1262 In this variation of Latching, the Latching packet is a small UDP 1263 packet that does not contain an RTP header. In response to the 1264 client's Latching packet, the RTSP server sends back a similar 1265 Latching packet as a confirmation so the client can stop the so 1266 called "connection phase" of this NAT traversal technique. 1267 Afterwards, the client only has to periodically send Latching packets 1268 as keep-alive messages for the NAT mappings. 1270 The server listens on its RTP-media output port, and tries to decode 1271 any received UDP packet as Latching packet. This is valid since an 1272 RTSP server is not expecting RTP traffic from the RTSP client. Then, 1273 it can correlate the Latching packet with the RTSP client's session 1274 ID or the client's SSRC, and record the NAT bindings accordingly. 1275 The server then sends a Latching packet as the response to the 1276 client. 1278 The Latching packet can contain the SSRC to identify the RTP stream, 1279 and care must be taken if the packet is bigger than 12 bytes, 1280 ensuring that it is distinctively different from RTP packets, whose 1281 header size is 12 bytes. 1283 RTSP signaling can be added to do the following: 1285 1. Enable or disable such Latching message exchanges. When the 1286 firewall/NAT has an RTSP-aware ALG, it is possible to disable 1287 Latching message exchange and let the ALG work out the address 1288 and port mappings. 1290 2. Configure the number of re-tries and the re-try interval of the 1291 Latching message exchanges. 1293 4.5.3. ALG Considerations 1295 See Latching ALG consideration Section 4.4.3. 1297 4.5.4. Deployment Considerations 1299 This approach has the following advantages when compared with the 1300 Latching approach (Section 4.4): 1302 1. There is no need to define RTP payload format for firewall 1303 traversal, therefore it is simple to use, implement and 1304 administer (Requirement 4 in Section 3), instead a Latching 1305 protocol must be defined. 1307 2. When properly defined, this kind of Latching packet exchange can 1308 also authenticate RTP receivers, to prevent hijacking attacks. 1310 This approach has the following disadvantages when compared with the 1311 Latching approach: 1313 1. The server's sender SSRC for the RTP stream or other session 1314 Identity information must be signaled in RTSP's SETUP response, 1315 in the Transport header of the RTSP SETUP response. 1317 4.5.5. Security Considerations 1319 Compared to the security properties of Latching this variant is 1320 slightly improved. First of all it allows for a larger random field 1321 in the Latching packets which makes it more unlikely for an off-path 1322 attacker to succeed in a hi-jack attack. Secondly the confirmation 1323 allows the client to know when Latching works and when it didn't and 1324 thus restart the Latching process by updating the SSRC. 1326 Still the main security issue remain that the RTSP server can't know 1327 that the source address in the latching packet was coming from a RTSP 1328 client wanting to receive media and not one that likes to direct the 1329 media traffic to an DoS target. 1331 4.6. Three Way Latching 1333 4.6.1. Introduction 1335 The three way latching is an attempt to try to resolve the most 1336 significant security issues for both previously discussed variants of 1337 Latching. By adding a server request response exchange directly 1338 after the initial latching the server can verify that the target 1339 address present in the latching packet is an active listener and 1340 confirm its desire to establish a media flow. 1342 4.6.2. Necessary RTSP extensions 1344 Uses the same RTSP extensions as the alternative latching method 1345 (Section 4.5) uses. The extensions for this variant are only in the 1346 format and transmission of the Latching packets. 1348 The client to server latching packet is similar to the Alternative 1349 Latching (Section 4.5), i.e. an UDP packet with some session 1350 identifier and a random value. When the server responds to the 1351 Latching packet with a Latching confirmation, it includes a random 1352 value (Nonce) of its own in addition to echoing back the one the 1353 client sent. Then a third message is added to the exchange. The 1354 client acknowledges the reception of the Latching confirmation 1355 message and echoes back the server's nonce. Thus confirming that the 1356 Latched address goes to a RTSP client that initiated the latching and 1357 is actually present at that address. The RTSP server will refuse to 1358 send any media until the Latching Acknowledgement has been received 1359 with a valid nonce. 1361 4.6.3. ALG Considerations 1363 See Latching ALG consideration Section 4.4.3. 1365 4.6.4. Deployment Considerations 1367 A solution with a 3-way handshake and its own Latching packets can be 1368 compared with the ICE-based solution (Section 4.3) and have the 1369 following differences: 1371 o Only works for servers that are not behind a NAT. 1373 o May be simpler to implement due to the avoidance of the ICE 1374 prioritization and check-board mechanisms. 1376 However, a 3-way Latching protocol is very similar to using STUN in 1377 both directions as Latching and verification protocol. Using STUN 1378 would remove the need for implementing a new protocol. 1380 4.6.5. Security Considerations 1382 Three way latching is significantly more secure than its simpler 1383 versions discussed above. The client to server nonce which is 1384 included in signalling and also can be bigger than the 32-bits of 1385 random data that the SSRC field supports makes it very difficult for 1386 an off-path attacker to perform an denial of service attack by 1387 diverting the media. 1389 The client to server nonce and its echoing back does not protect 1390 against on-patch attacker, including malicious clients. However, the 1391 server to client nonce and its echoing back prevents malicious 1392 clients to divert the media stream by spoofing the source address and 1393 port, as it can't echo back the nonce in these cases. Similar to the 1394 Mobile IPv6 return routability procedure (Section 5.2.5 of [RFC6275]) 1396 Three way latching is really only vulnerable to an on-path attacker 1397 that is quite capable. First the attacker can either learn the 1398 client to server nonce, by intercepting the signalling, or modifying 1399 the source information (target destination) of a client's latching 1400 packet. Secondly, it is also on-path between the server and target 1401 destination and can generate a response using the server's nonce. An 1402 adversary that has these capabilities are commonly capable of causing 1403 significantly worse damage than this using other methods. 1405 Three-way latching do results in that the server to client packet is 1406 bigger than the client to server packet, due to the inclusion of the 1407 server to client nonce in addition to the client to server nonce. 1408 Thus an amplification effect do exist, however, to achieve this 1409 amplification effect the attacker has to create a session state on 1410 the RTSP server. The RTSP server can also limit the number of 1411 response it will generate before considering the latching to be 1412 failed. 1414 4.7. Application Level Gateways 1416 4.7.1. Introduction 1418 An Application Level Gateway (ALG) reads the application level 1419 messages and performs necessary changes to allow the protocol to work 1420 through the middle box. However this behavior has some problems in 1421 regards to RTSP: 1423 1. It does not work when the RTSP protocol is used with end-to-end 1424 security. As the ALG can't inspect and change the application 1425 level messages the protocol will fail due to the middle box. 1427 2. ALGs need to be updated if extensions to the protocol are added. 1428 Due to deployment issues with changing ALGs this may also break 1429 the end-to-end functionality of RTSP. 1431 Due to the above reasons it is not recommended to use an RTSP ALG in 1432 NATs. This is especially important for NATs targeted to home users 1433 and small office environments, since it is very hard to upgrade NATs 1434 deployed in home or SOHO (small office/home office) environment. 1436 4.7.2. Outline On how ALGs for RTSP work 1438 In this section, we provide a step-by-step outline on how one could 1439 go about writing an ALG to enable RTSP to traverse a NAT. 1441 1. Detect any SETUP request. 1443 2. Try to detect the usage of any of the NAT traversal methods that 1444 replace the address and port of the Transport header parameters 1445 "destination" or "dest_addr". If any of these methods are used, 1446 then the ALG should not change the address. Ways to detect that 1447 these methods are used are: 1449 * For embedded STUN, it would be to watch for a feature tag, 1450 like "nat.stun". If any of those exists in the "supported", 1451 "proxy-require", or "require" headers of the RTSP exchange. 1453 * For stand alone STUN and TURN based solutions: This can be 1454 detected by inspecting the "destination" or "dest_addr" 1455 parameter. If it contains either one of the NAT's external IP 1456 addresses or a public IP address then such a solution is in 1457 use. However if multiple NATs are used this detection may 1458 fail. Remapping should only be done for addresses belonging 1459 to the NAT's own private address space. 1461 Otherwise continue to the next step. 1463 3. Create UDP mappings (client given IP/port <-> external IP/port) 1464 where needed for all possible transport specifications in the 1465 transport header of the request found in (1). Enter the external 1466 address and port(s) of these mappings in transport header. 1467 Mappings shall be created with consecutive external port numbers 1468 starting on an even number for RTP for each media stream. 1469 Mappings should also be given a long timeout period, at least 5 1470 minutes. 1472 4. When the SETUP response is received from the server, the ALG may 1473 remove the unused UDP mappings, i.e. the ones not present in the 1474 transport header. The session ID should also be bound to the UDP 1475 mappings part of that session. 1477 5. If SETUP response settles on RTP over TCP or RTP over RTSP as 1478 lower transport, do nothing: let TCP tunneling take care of NAT 1479 traversal. Otherwise go to next step. 1481 6. The ALG should keep the UDP mappings belonging to the RTSP 1482 session as long as: an RTSP message with the session's ID has 1483 been sent in the last timeout interval, or a UDP message has been 1484 sent on any of the UDP mappings during the last timeout interval. 1486 7. The ALG may remove a mapping as soon a TEARDOWN response has been 1487 received for that media stream. 1489 4.7.3. Deployment Considerations 1491 Advantage: 1493 o No impact on either client or server 1495 o Can work for any type of NATs 1497 Disadvantage: 1499 o When deployed they are hard to update to reflect protocol 1500 modifications and extensions. If not updated they will break the 1501 functionality. 1503 o When end-to-end security is used, the ALG functionality will fail. 1505 o Can interfere with other types of traversal mechanisms, such as 1506 STUN. 1508 Transition: 1510 An RTSP ALG will not be phased out in any automatic way. It must be 1511 removed, probably through the removal or update of the NAT it is 1512 associated with. 1514 4.7.4. Security Considerations 1516 An ALG will not work with deployment of end-to-end RTSP signaling 1517 security, however it will work with the hop-by-hop security method 1518 defined in Section 19.3 of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. 1519 Therefore deployment of ALG may result in clients located behind NATs 1520 not using end-to-end security, or more likely the selection a NAT 1521 traversal solution that allow for security. 1523 The creation of an UDP mapping based on the signalling message has 1524 some potential security implications. First of all if the RTSP 1525 client releases its ports and another application are assigned these 1526 instead it could receive RTP media as long as the mappings exist and 1527 the RTSP server has failed to be signalled or notice the lack of 1528 client response. 1530 A NAT with RTSP ALG that assigns mappings based on SETUP requests 1531 could potentially become victim of a resource exhaustion attack. If 1532 an attacker creates a lot of RTSP sessions, even without starting 1533 media transmission could exhaust the pool of available UDP ports on 1534 the NAT. Thus only a limited number of UDP mappings should be 1535 allowed to be created by the RTSP ALG. 1537 4.8. TCP Tunneling 1539 4.8.1. Introduction 1541 Using a TCP connection that is established from the client to the 1542 server ensures that the server can send data to the client. The 1543 connection opened from the private domain ensures that the server can 1544 send data back to the client. To send data originally intended to be 1545 transported over UDP requires the TCP connection to support some type 1546 of framing of the media data packets. Using TCP also results in the 1547 client having to accept that real-time performance can be impacted. 1548 TCP's problem of ensuring timely delivery was one of the reasons why 1549 RTP was developed. Problems that arise with TCP are: head-of-line 1550 blocking, delay introduced by retransmissions, highly varying rate 1551 due to the congestion control algorithm. If sufficient amount of 1552 buffering (several seconds) in the receiving client can be tolerated 1553 then TCP clearly work. 1555 4.8.2. Usage of TCP tunneling in RTSP 1557 The RTSP core specification [I-D.ietf-mmusic-rfc2326bis] supports 1558 interleaving of media data on the TCP connection that carries RTSP 1559 signaling. See section 14 in [I-D.ietf-mmusic-rfc2326bis] for how to 1560 perform this type of TCP tunneling. There also exists another way of 1561 transporting RTP over TCP defined in Appendix C.2 in 1562 [I-D.ietf-mmusic-rfc2326bis]. For signaling and rules on how to 1563 establish the TCP connection in lieu of UDP, see appendix C.2 in 1564 [I-D.ietf-mmusic-rfc2326bis]. This is based on the framing of RTP 1565 over the TCP connection as described in RFC 4571 [RFC4571]. 1567 4.8.3. ALG Considerations 1569 An RTSP ALG will face a different issue with TCP tunneling, at least 1570 the Interleaved version. Now the full data stream will flow can end 1571 up flowing through the ALG implementation. Thus it is important that 1572 the ALG is efficient in dealing with the interleaved media data 1573 frames to avoid consuming to much resource and thus creating 1574 performance issues. 1576 The RTSP ALG can also effect the transport specifications that 1577 indicate that TCP tunneling can be done and its priortization, 1578 including removing the transport specification, thus preventing TCP 1579 tunneling. 1581 4.8.4. Deployment Considerations 1583 Advantage: 1585 o Works through all types of NATs where the RTSP server in not NATed 1586 or at least reachable like it was not. 1588 Disadvantage: 1590 o Functionality needs to be implemented on both server and client. 1592 o Will not always meet multimedia stream's real-time requirements. 1594 Transition: 1596 The tunneling over RTSP's TCP connection is not planned to be phased- 1597 out. It is intended to be a fallback mechanism and for usage when 1598 total media reliability is desired, even at the potential price of 1599 loss of real-time properties. 1601 4.8.5. Security Considerations 1603 The TCP tunneling of RTP has no known significant security problems 1604 besides those already presented in the RTSP specification. It is 1605 difficult to get any amplification effect for denial of service 1606 attacks due to TCP's flow control. The RTSP server TCP socket, 1607 independently if used for media tunneling or only RTSP messages can 1608 be used for a redirected syn attack. By spoofing the source address 1609 of any TCP init packets, the TCP SYNs from the server can be directed 1610 towards a target. 1612 A possible security consideration, when session media data is 1613 interleaved with RTSP, would be the performance bottleneck when RTSP 1614 encryption is applied, since all session media data also needs to be 1615 encrypted. 1617 4.9. TURN (Traversal Using Relay NAT) 1619 4.9.1. Introduction 1621 Traversal Using Relay NAT (TURN) [RFC5766] is a protocol for setting 1622 up traffic relays that allow clients behind NATs and firewalls to 1623 receive incoming traffic for both UDP and TCP. These relays are 1624 controlled and have limited resources. They need to be allocated 1625 before usage. TURN allows a client to temporarily bind an address/ 1626 port pair on the relay (TURN server) to its local source address/port 1627 pair, which is used to contact the TURN server. The TURN server will 1628 then forward packets between the two sides of the relay. 1630 To prevent DoS attacks on either recipient, the packets forwarded are 1631 restricted to the specific source address. On the client side it is 1632 restricted to the source setting up the allocation. On the external 1633 side this is limited to the source address/port pair that have been 1634 given permission by the TURN client creating the allocation. Packets 1635 from any other source on this address will be discarded. 1637 Using a TURN server makes it possible for a RTSP client to receive 1638 media streams from even an unmodified RTSP server. However the 1639 problem is those RTSP servers most likely restrict media destinations 1640 to no other IP address than the one the RTSP message arrives from. 1641 This means that TURN could only be used if the server knows and 1642 accepts that the IP belongs to a TURN server and the TURN server 1643 can't be targeted at an unknown address. Alternatively, both the 1644 RTSP TCP connection as well as the RTP media is relayed through the 1645 same TURN server. 1647 4.9.2. Usage of TURN with RTSP 1649 To use a TURN server for NAT traversal, the following steps should be 1650 performed. 1652 1. The RTSP client connects with the RTSP server. The client 1653 retrieves the session description to determine the number of 1654 media streams. To avoid the issue with having RTSP connection 1655 and media traffic from different addresses also the TCP 1656 connection must be done through the same TURN server as the one 1657 in the next step. This will require the usage of TURN for TCP 1658 [RFC6062]. 1660 2. The client establishes the necessary bindings on the TURN server. 1661 It must choose the local RTP and RTCP ports that it desires to 1662 receive media packets. TURN supports requesting bindings of even 1663 port numbers and contiguous ranges. 1665 3. The RTSP client uses the acquired address and port allocations in 1666 the RTSP SETUP request using the destination header. 1668 4. The RTSP Server sends the SETUP reply, which must include the 1669 transport headers src_addr parameter (source and port in RTSP 1670 1.0). Note that the server is required to have a mechanism to 1671 verify that it is allowed to send media traffic to the given 1672 address unless TCP relaying of the RTSP messages also is 1673 performed. 1675 5. The RTSP Client uses the RTSP Server's response to create TURN 1676 permissions for the server's media traffic. 1678 6. The client requests that the server starts playing. The server 1679 starts sending media packets to the given destination address and 1680 ports. 1682 7. Media packets arrive at the TURN server on the external port; If 1683 the packets match an established permission, the TURN server 1684 forwards the media packets to the RTSP client. 1686 8. If the client pauses and media is not sent for about 75% of the 1687 mapping timeout the client should use TURN to refresh the 1688 bindings. 1690 4.9.3. ALG Considerations 1692 As the RTSP client inserts the address information of the TURN 1693 relay's external allocations in the SETUP messages, and ALG that 1694 replaces the address, without considering that the address do not 1695 belong to the internal address realm of the NAT, will prevent this 1696 mechanism from working. This can be prevented by securing the RTSP 1697 signalling. 1699 4.9.4. Deployment Considerations 1701 Advantages: 1703 o Does not require any server modifications given that the server 1704 includes the src_addr header in the SETUP response. 1706 o Works for any type of NAT as long as the RTSP server has reachable 1707 IP address that is not behind a NAT. 1709 Disadvantage: 1711 o Requires another network element, namely the TURN server. 1713 o A TURN server for RTSP may not scale since the number of sessions 1714 it must forward is proportional to the number of client media 1715 sessions. 1717 o The TURN server becomes a single point of failure. 1719 o Since TURN forwards media packets, it necessarily introduces 1720 delay. 1722 o An RTSP ALG may change the necessary destinations parameter. This 1723 will cause the media traffic to be sent to the wrong address. 1725 Transition: 1727 TURN is not intended to be phased-out completely, see Section 19 of 1728 [RFC5766]. However the usage of TURN could be reduced when the 1729 demand for having NAT traversal is reduced. 1731 4.9.5. Security Considerations 1733 The TURN server can become part of a denial of service attack towards 1734 any victim. To perform this attack the attacker must be able to 1735 eavesdrop on the packets from the TURN server towards a target for 1736 the DoS attack. The attacker uses the TURN server to setup a RTSP 1737 session with media flows going through the TURN server. The attacker 1738 is in fact creating TURN mappings towards a target by spoofing the 1739 source address of TURN requests. As the attacker will need the 1740 address of these mappings he must be able to eavesdrop or intercept 1741 the TURN responses going from the TURN server to the target. Having 1742 these addresses, he can set up a RTSP session and start delivery of 1743 the media. The attacker must be able to create these mappings. The 1744 attacker in this case may be traced by the TURN username in the 1745 mapping requests. 1747 This attack requires that the attacker has access to a user account 1748 on the TURN server to be able set up the TURN mappings. To prevent 1749 this attack the RTSP server needs to verify that the ultimate target 1750 destination accept this media stream. Which would require something 1751 like ICE's connectivity checks being run between the RTSP server and 1752 the RTSP client. 1754 5. Firewalls 1756 Firewalls exist for the purpose of protecting a network from traffic 1757 not desired by the firewall owner. Therefore it is a policy decision 1758 if a firewall will let RTSP and its media streams through or not. 1759 RTSP is designed to be firewall friendly in that it should be easy to 1760 design firewall policies to permit passage of RTSP traffic and its 1761 media streams. 1763 The firewall will need to allow the media streams associated with a 1764 RTSP session to pass through it. Therefore the firewall will need an 1765 ALG that reads RTSP SETUP and TEARDOWN messages. By reading the 1766 SETUP message the firewall can determine what type of transport and 1767 from where, the media stream packets will be sent. Commonly there 1768 will be the need to open UDP ports for RTP/RTCP. By looking at the 1769 source and destination addresses and ports the opening in the 1770 firewall can be minimized to the least necessary. The opening in the 1771 firewall can be closed after a TEARDOWN message for that session or 1772 the session itself times out. 1774 The above possibilities for firewalls to inspect and respond to the 1775 signalling are prevented if end-to-end confidentiality protection is 1776 used for the RTSP signalling, e.g. using the specified RTSP over TLS. 1777 This results in that firewalls can't be actively opening pinholes for 1778 the media streams based on the signalling. To enable an RTSP ALG in 1779 firewall to correctly function the hop-by-hop signalling security 1780 (See Section 19.3) in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] can be 1781 used. If not, other methods have to be used to enable the transport 1782 flows for the media. 1784 Simpler firewalls do allow a client to receive media as long as it 1785 has sent packets to the target. Depending on the security level this 1786 can have the same behavior as a NAT. The only difference is that no 1787 address translation is done. To use such a firewall a client would 1788 need to implement one of the above described NAT traversal methods 1789 that include sending packets to the server to open up the mappings. 1791 6. Comparison of NAT traversal techniques 1793 This section evaluates the techniques described above against the 1794 requirements listed in Section 3. 1796 In the following table, the columns correspond to the numbered 1797 requirements. For instance, the column under R1 corresponds to the 1798 first requirement in Section 3: must work for all flavors of NATs. 1799 The rows represent the different NAT/firewall traversal techniques. 1800 Latch is short for Latching, "V. Latch" is short for "variation of 1801 Latching" as described in Section 4.5. "3-W Latch" is short for the 1802 Three Way Latching described in Section 4.6. 1804 A Summary of the requirements are: 1806 R1: Work for all flavors of NATs 1808 R2: Must work with firewalls, including those with ALGs 1810 R3: Should have minimal impact on clients not behind NATs, counted 1811 in minimal number of additional RTTs 1813 R4: Should be simple to use, Implement and administer. 1815 R5: Should provide mitigation against DDoS attacks 1817 The following considerations are also added to requirements: 1819 C1: Will solution support both Clients and Servers behind NAT 1821 C2: Is the solution robust to changing NAT behaviors 1823 ------------+------+------+------+------+------+------+------+ 1824 | R1 | R2 | R3 | R4 | R5 | C1 | C2 | 1825 ------------+------+------+------+------+------+------+------+ 1826 STUN | No | Yes | 1 | Maybe| No | No | No | 1827 ------------+------+------+------+------+------+------+------+ 1828 Emb. STUN | Yes | Yes | 2 | Maybe| No | No | Yes | 1829 ------------+------+------+------+------+------+------+------+ 1830 ICE | Yes | Yes | 2.5 | No | Yes | Yes | Yes | 1831 ------------+------+------+------+------+------+------+------+ 1832 Latch | Yes | Yes | 1 | Maybe| No | No | Yes | 1833 ------------+------+------+------+------+------+------+------+ 1834 V. Latch | Yes | Yes | 1 | Yes | No | No | Yes | 1835 ------------+------+------+------+------+------+------+------+ 1836 3-W Latch | Yes | Yes | 1.5 | Maybe| Yes | No | Yes | 1837 ------------+------+------+------+------+------+------+------+ 1838 ALG |(Yes) | Yes | 0 | No | Yes | No | Yes | 1839 ------------+------+------+------+------+------+------+------+ 1840 TCP Tunnel | Yes | Yes | 1.5 | Yes | Yes | No | Yes | 1841 ------------+------+------+------+------+------+------+------+ 1842 TURN | Yes | Yes | 1 | No | Yes |(Yes) | Yes | 1843 ------------+------+------+------+------+------+------+------+ 1845 Figure 1: Comparison of fulfillment of requirements 1847 Looking at Figure 1 one would draw the conclusion that using TCP 1848 Tunneling or Three-Way Latching is the solutions that best fulfill 1849 the requirements. The different techniques were discussed in the 1850 MMUSIC WG. It was established that the WG would pursue an ICE based 1851 solution due to its generality and capability of handling also 1852 servers delivering media from behind NATs. TCP Tunneling is likely 1853 to be available as an alternative, due to its specification in the 1854 main RTSP specification. Thus it can be used if desired and the 1855 potential downsides of using TCP is acceptable in particular 1856 deployments. When it comes to Three-Way Latching it is a very 1857 competitive technique given that you don't need support for RTSP 1858 servers behind NATs. There were some discussion in the WG if the 1859 increased implementation burden of ICE is sufficiently motivated 1860 compared to a the Three-Way Latching solution for this generality. 1861 In the end the authors believe that reuse of ICE, the greater 1862 flexibility and anyway need to deploy a new solution was the decisive 1863 factors. 1865 The ICE based RTSP NAT traversal solution is specified in "A Network 1866 Address Translator (NAT) Traversal mechanism for media controlled by 1867 Real-Time Streaming Protocol (RTSP)" [I-D.ietf-mmusic-rtsp-nat]. 1869 7. IANA Considerations 1871 This document makes no request of IANA. 1873 Note to RFC Editor: this section may be removed on publication as an 1874 RFC. 1876 8. Security Considerations 1878 In the preceding sections we have discussed security merits of the 1879 different NAT/firewall traversal methods for RTSP discussed here. In 1880 summary, the presence of NAT(s) is a security risk, as a client 1881 cannot perform source authentication of its IP address. This 1882 prevents the deployment of any future RTSP extensions providing 1883 security against hijacking of sessions by a man-in-the-middle. 1885 Each of the proposed solutions has security implications. Using STUN 1886 will provide the same level of security as RTSP without transport 1887 level security and source authentications, as long as the server does 1888 not allow media to be sent to a different IP-address than the RTSP 1889 client request was sent from. 1891 Using Latching will have a higher risk of session hijacking or denial 1892 of service than normal RTSP. The reason is that there exists a 1893 probability that an attacker is able to guess the random bits that 1894 the client uses to prove its identity when creating the address 1895 bindings. This can be solved in the variation of Latching 1896 (Section 4.5) with authentication features. Still both those 1897 variants of Latching are vulnerable against deliberate attack from 1898 the RTSP client to redirect the media stream requested to any target 1899 assuming it can spoof the source address. This security 1900 vulnerability is solved by performing a Three-way Latching procedure 1901 as discussed in Section 4.6. 1903 ICE resolves the binding vulnerability of latching by using signed 1904 STUN messages, as well as requiring that both sides perform 1905 connectivity checks to verify that the target IP address in the 1906 candidate pair is both reachable and willing to respond. ICE can 1907 however create a significant amount of traffic if the number of 1908 candidate pairs are large. Thus pacing is required and 1909 implementations should attempt to limit their number of candidates to 1910 reduce the number of packets. 1912 If the signalling between the ICE peers (RTSP client and Server) is 1913 not confidentiality and integrity protected ICE is vulnerable to 1914 attacks where the candidate list is manipulated. Lack of signalling 1915 security will also simplify spoofing of STUN binding messages by 1916 revealing the secret used in signing. 1918 The usage of an RTSP ALG does not in itself increase the risk for 1919 session hijacking. However the deployment of ALGs as the sole 1920 mechanism for RTSP NAT traversal will prevent deployment of end-to- 1921 end encrypted RTSP signaling. 1923 The usage of TCP tunneling has no known security problems. However, 1924 it might provide a bottleneck when it comes to end-to-end RTSP 1925 signaling security if TCP tunneling is used on an interleaved RTSP 1926 signaling connection. 1928 The usage of TURN has severe risk of denial of service attacks 1929 against a client. The TURN server can also be used as a redirect 1930 point in a DDoS attack unless the server has strict enough rules for 1931 who may create bindings. 1933 The latching and variant of latching have so big security issues that 1934 they should not be used at all. The three way latching as well as 1935 ICE mitigates these security issues and performs the important 1936 return-routability checks that prevents spoofed source addresses, and 1937 should be recommended for that reason. RTP ALG's is a security risk 1938 as they can create an incitement against using secure RTSP 1939 signalling. That can be avoided as ALGs requires trust in the 1940 middlebox, and that trust becomes explicit if one uses the hop-by-hop 1941 security solution as specified in Section 19.3 of RTSP 2.0. 1942 [I-D.ietf-mmusic-rfc2326bis]. The remaining methods can be 1943 considered safe enough, assuming that the appropriate security 1944 mechanisms are used and not ignored. 1946 9. Acknowledgements 1948 The author would also like to thank all persons on the MMUSIC working 1949 group's mailing list that has commented on this document. Persons 1950 having contributed in such way in no special order to this protocol 1951 are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon, 1952 Amir Wolf, Anders Klemets, Flemming Andreasen, Ari Keranen, Bill 1953 Atwood, Alissa Cooper, Colin Perkins, Sarah Banks, David Black and 1954 Alvaro Retana. Thomas Zeng would also like to give special thanks to 1955 Greg Sherwood of PacketVideo for his input into this memo. 1957 Section 1.1 contains text originally written for RFC 4787 by Francois 1958 Audet and Cullen Jennings. 1960 10. Informative References 1962 [I-D.ietf-avt-rtp-no-op] 1963 Andreasen, F., "A No-Op Payload Format for RTP", draft- 1964 ietf-avt-rtp-no-op-04 (work in progress), May 2007. 1966 [I-D.ietf-mmusic-rfc2326bis] 1967 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1968 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1969 (RTSP)", draft-ietf-mmusic-rfc2326bis-40 (work in 1970 progress), February 2014. 1972 [I-D.ietf-mmusic-rtsp-nat] 1973 Goldberg, J., Westerlund, M., and T. Zeng, "A Network 1974 Address Translator (NAT) Traversal Mechanism for Media 1975 Controlled by Real-Time Streaming Protocol (RTSP)", draft- 1976 ietf-mmusic-rtsp-nat-22 (work in progress), July 2014. 1978 [NICE] "Libnice - The GLib ICE implementation, 1979 http://nice.freedesktop.org/wiki/", May 2013. 1981 [PJNATH] "PJNATH - Open Source ICE, STUN, and TURN Library, 1982 http://www.pjsip.org/pjnath/docs/html/", May 2013. 1984 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1985 August 1980. 1987 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1988 793, September 1981. 1990 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1991 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1993 [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May 1994 1999. 1996 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1997 Translator (NAT) Terminology and Considerations", RFC 1998 2663, August 1999. 2000 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2001 Address Translator (Traditional NAT)", RFC 3022, January 2002 2001. 2004 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2005 A., Peterson, J., Sparks, R., Handley, M., and E. 2006 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2007 June 2002. 2009 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 2010 Self-Address Fixing (UNSAF) Across Network Address 2011 Translation", RFC 3424, November 2002. 2013 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 2014 "STUN - Simple Traversal of User Datagram Protocol (UDP) 2015 Through Network Address Translators (NATs)", RFC 3489, 2016 March 2003. 2018 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2019 Jacobson, "RTP: A Transport Protocol for Real-Time 2020 Applications", STD 64, RFC 3550, July 2003. 2022 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2023 Description Protocol", RFC 4566, July 2006. 2025 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 2026 and RTP Control Protocol (RTCP) Packets over Connection- 2027 Oriented Transport", RFC 4571, July 2006. 2029 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 2030 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 2031 RFC 4787, January 2007. 2033 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2034 BCP 131, RFC 4961, July 2007. 2036 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2037 (ICE): A Protocol for Network Address Translator (NAT) 2038 Traversal for Offer/Answer Protocols", RFC 5245, April 2039 2010. 2041 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 2042 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 2043 RFC 5382, October 2008. 2045 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 2046 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 2047 October 2008. 2049 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2050 Security (DTLS) Extension to Establish Keys for the Secure 2051 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 2053 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 2054 Relays around NAT (TURN): Relay Extensions to Session 2055 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 2057 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 2058 around NAT (TURN) Extensions for TCP Allocations", RFC 2059 6062, November 2010. 2061 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 2062 Keeping Alive the NAT Mappings Associated with RTP / RTP 2063 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 2065 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 2066 in IPv6", RFC 6275, July 2011. 2068 [RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT 2069 Traversal (HNT) for Media in Real-Time Communication", RFC 2070 7362, September 2014. 2072 [STUN-IMPL] 2073 "Open Source STUN Server and Client, 2074 http://sourceforge.net/projects/stun/", May 2013. 2076 Authors' Addresses 2078 Magnus Westerlund 2079 Ericsson 2080 Farogatan 6 2081 Stockholm SE-164 80 2082 Sweden 2084 Phone: +46 8 719 0000 2085 Email: magnus.westerlund@ericsson.com 2087 Thomas Zeng 2089 Email: thomas.zeng@gmail.com