idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-evaluation-12.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 (January 23, 2014) is 3745 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-latching-04 == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-39 == Outdated reference: A later version (-22) exists of draft-ietf-mmusic-rtsp-nat-18 -- 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 (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Westerlund 3 Internet-Draft Ericsson 4 Intended status: Informational T. Zeng 5 Expires: July 27, 2014 6 January 23, 2014 8 The Evaluation of Different Network Address Translator (NAT) Traversal 9 Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) 10 draft-ietf-mmusic-rtsp-nat-evaluation-12 12 Abstract 14 This document describes several Network Address Translator (NAT) 15 traversal techniques that were considered to be used for establishing 16 the RTP media flows controlled by the Real-time Streaming Protocol 17 (RTSP). Each technique includes a description of how it would be 18 used, the security implications of using it and any other deployment 19 considerations it has. There are also discussions on how NAT 20 traversal techniques relate to firewalls and how each technique can 21 be applied in different use cases. These findings were used when 22 selecting the NAT traversal for RTSP 2.0, which is specified in a 23 separate document. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 27, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Network Address Translators . . . . . . . . . . . . . . . 4 61 1.2. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2. Detecting the loss of NAT mappings . . . . . . . . . . . . . 7 64 3. Requirements on Solutions . . . . . . . . . . . . . . . . . . 8 65 4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . 9 66 4.1. Stand-Alone STUN . . . . . . . . . . . . . . . . . . . . 10 67 4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . 10 68 4.1.2. Using STUN to traverse NAT without server 69 modifications . . . . . . . . . . . . . . . . . . . . 10 70 4.1.3. ALG considerations . . . . . . . . . . . . . . . . . 12 71 4.1.4. Deployment Considerations . . . . . . . . . . . . . . 13 72 4.1.5. Security Considerations . . . . . . . . . . . . . . . 14 73 4.2. Server Embedded STUN . . . . . . . . . . . . . . . . . . 14 74 4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . 14 75 4.2.2. Embedding STUN in RTSP . . . . . . . . . . . . . . . 14 76 4.2.3. Discussion On Co-located STUN Server . . . . . . . . 16 77 4.2.4. ALG considerations . . . . . . . . . . . . . . . . . 16 78 4.2.5. Deployment Considerations . . . . . . . . . . . . . . 16 79 4.2.6. Security Considerations . . . . . . . . . . . . . . . 17 80 4.3. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . 17 82 4.3.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 18 83 4.3.3. Implementation burden of ICE . . . . . . . . . . . . 20 84 4.3.4. Deployment Considerations . . . . . . . . . . . . . . 20 85 4.3.5. Security Consideration . . . . . . . . . . . . . . . 21 86 4.4. Latching . . . . . . . . . . . . . . . . . . . . . . . . 21 87 4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . 21 88 4.4.2. Necessary RTSP extensions . . . . . . . . . . . . . . 22 89 4.4.3. Deployment Considerations . . . . . . . . . . . . . . 22 90 4.4.4. Security Consideration . . . . . . . . . . . . . . . 23 91 4.5. A Variation to Latching . . . . . . . . . . . . . . . . . 24 92 4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . 24 93 4.5.2. Necessary RTSP extensions . . . . . . . . . . . . . . 25 94 4.5.3. Deployment Considerations . . . . . . . . . . . . . . 25 95 4.5.4. Security Considerations . . . . . . . . . . . . . . . 26 96 4.6. Three Way Latching . . . . . . . . . . . . . . . . . . . 26 97 4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . 26 98 4.6.2. Necessary RTSP extensions . . . . . . . . . . . . . . 26 99 4.6.3. Deployment Considerations . . . . . . . . . . . . . . 27 100 4.7. Application Level Gateways . . . . . . . . . . . . . . . 27 101 4.7.1. Introduction . . . . . . . . . . . . . . . . . . . . 27 102 4.7.2. Outline On how ALGs for RTSP work . . . . . . . . . . 28 103 4.7.3. Deployment Considerations . . . . . . . . . . . . . . 29 104 4.7.4. Security Considerations . . . . . . . . . . . . . . . 29 105 4.8. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 30 106 4.8.1. Introduction . . . . . . . . . . . . . . . . . . . . 30 107 4.8.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . 30 108 4.8.3. Deployment Considerations . . . . . . . . . . . . . . 30 109 4.8.4. Security Considerations . . . . . . . . . . . . . . . 31 110 4.9. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . 31 111 4.9.1. Introduction . . . . . . . . . . . . . . . . . . . . 31 112 4.9.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 32 113 4.9.3. Deployment Considerations . . . . . . . . . . . . . . 32 114 4.9.4. Security Considerations . . . . . . . . . . . . . . . 33 115 5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 34 116 6. Comparison of NAT traversal techniques . . . . . . . . . . . 34 117 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 118 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 119 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 120 10. Informative References . . . . . . . . . . . . . . . . . . . 37 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 123 1. Introduction 125 Today there is a proliferate deployment of different flavors of 126 Network Address Translator (NAT) boxes that in many cases only 127 loosely follow standards 128 [RFC3022][RFC2663][RFC3424][RFC4787][RFC5382]. NATs cause 129 discontinuity in address realms [RFC3424], therefore an application 130 protocol, such as Real-time Streaming Protocol (RTSP) 131 [RFC2326][I-D.ietf-mmusic-rfc2326bis], needs to deal with such 132 discontinuities caused by NATs. The problem is that, being a media 133 control protocol managing one or more media streams, RTSP carries 134 network address and port information within its protocol messages. 135 Because of this, even if RTSP itself, when carried over Transmission 136 Control Protocol (TCP) [RFC0793] for example, is not blocked by NATs, 137 its media streams may be blocked by NATs. This will occur unless 138 special protocol provisions are added to support NAT-traversal. 140 Like NATs, Firewalls are also middle boxes that need to be 141 considered. Firewalls help prevent unwanted traffic from getting in 142 or out of the protected network. RTSP is designed such that a 143 firewall can be configured to let RTSP controlled media streams go 144 through with minimal implementation effort. The minimal effort is to 145 implement an Application Level Gateway (ALG) to interpret RTSP 146 parameters. There is also a large class of firewalls, commonly home 147 firewalls, that uses a similar filtering behavior to what NAT has. 148 This type of firewalls can be handled using the same solution as 149 employed for NAT traversal instead of relying on ALGs. 151 This document describes several NAT-traversal mechanisms for RTSP 152 controlled media streaming. Many of these NAT solutions fall into 153 the category of "UNilateral Self-Address Fixing (UNSAF)" as defined 154 in [RFC3424] and quoted below: 156 "UNSAF is a process whereby some originating process attempts to 157 determine or fix the address (and port) by which it is known - e.g. 158 to be able to use address data in the protocol exchange, or to 159 advertise a public address from which it will receive connections." 161 Following the guidelines spelled out in RFC 3424, we describe the 162 required RTSP protocol extensions for each method, transition 163 strategies, and security concerns. 165 This document is capturing the evaluation done in the process to 166 recommend Firewall/NAT traversal methods for RTSP streaming servers 167 based on RFC 2326 [RFC2326] as well as the RTSP 2.0 core spec 168 [I-D.ietf-mmusic-rfc2326bis]. The evaluation is focused on NAT 169 traversal for the media streams carried over User Datagram Protocol 170 (UDP) [RFC0768] with Real-time Transport Protocol (RTP) [RFC3550] 171 over UDP being the main case for such usage. The findings should be 172 applicable to other protocols as long as they have similar 173 properties. 175 The resulting ICE-based RTSP NAT traversal mechanism is specified in 176 "A Network Address Translator (NAT) Traversal mechanism for media 177 controlled by Real-Time Streaming Protocol (RTSP)" 178 [I-D.ietf-mmusic-rtsp-nat]. 180 1.1. Network Address Translators 182 We begin by reviewing two quotes from Section 3 in "Network Address 183 Translation (NAT) Behavioral Requirements for Unicast UDP" [RFC4787] 184 concering NATs and their terminology: 186 "Readers are urged to refer to [RFC2663] for information on NAT 187 taxonomy and terminology. Traditional NAT is the most common type of 188 NAT device deployed. Readers may refer to [RFC3022] for detailed 189 information on traditional NAT. Traditional NAT has two main 190 varieties -- Basic NAT and Network Address/Port Translator (NAPT). 192 NAPT is by far the most commonly deployed NAT device. NAPT allows 193 multiple internal hosts to share a single public IP address 194 simultaneously. When an internal host opens an outgoing TCP or UDP 195 session through a NAPT, the NAPT assigns the session a public IP 196 address and port number, so that subsequent response packets from the 197 external endpoint can be received by the NAPT, translated, and 198 forwarded to the internal host. The effect is that the NAPT 199 establishes a NAT session to translate the (private IP address, 200 private port number) tuple to a (public IP address, public port 201 number) tuple, and vice versa, for the duration of the session. An 202 issue of relevance to peer-to-peer applications is how the NAT 203 behaves when an internal host initiates multiple simultaneous 204 sessions from a single (private IP, private port) endpoint to 205 multiple distinct endpoints on the external network. In this 206 specification, the term "NAT" refers to both "Basic NAT" and "Network 207 Address/Port Translator (NAPT)"." 209 "This document uses the term "address and port mapping" as the 210 translation between an external address and port and an internal 211 address and port. Note that this is not the same as an "address 212 binding" as defined in RFC 2663." 214 Note: In the above it would be more correct to use external 215 instead of public in the above text. The external IP address is 216 commonly a public one, but might be of other type if the NAT's 217 external side is in a private address domain. 219 In addition to the above quote there exists a number of address and 220 port mapping behaviors described in more detail in Section 4.1 of 221 "Network Address Translation (NAT) Behavioral Requirements for 222 Unicast UDP" [RFC4787] that are highly relevant to the discussion in 223 this document. 225 NATs also have a filtering behavior on traffic arriving on the 226 external side. Such behavior affects how well different methods for 227 NAT traversal works through these NATs. See Section 5 of "Network 228 Address Translation (NAT) Behavioral Requirements for Unicast UDP" 229 [RFC4787] for more information on the different types of filtering 230 that have been identified. 232 1.2. Firewalls 234 A firewall is a security gateway that enforces certain access control 235 policies between two network administrative domains: a private domain 236 (intranet) and a external domain, e.g. public Internet. Many 237 organizations use firewalls to prevent privacy intrusions and 238 malicious attacks to corporate computing resources in the private 239 intranet [RFC2588]. 241 A comparison between NAT and Firewall is given below: 243 1. A firewall sits at security enforcement/protection points, while 244 NAT sits at borders between two address domains. 246 2. NAT does not in itself provide security, although some access 247 control policies can be implemented using address translation 248 schemes. The inherent filtering behaviours are commonly mistaken 249 for real security policies. 251 It should be noted that many NAT devices intended for Residential or 252 small office/home office (SOHO) use include both NATs and firewall 253 functionality. 255 In the rest of this memo we use the phrase "NAT traversal" 256 interchangeably with "Firewall traversal", and "NAT/Firewall 257 traversal". 259 1.3. Glossary 261 Address-Dependent Mapping: The NAT reuses the port mapping for 262 subsequent packets sent from the same internal IP address and 263 port to the same external IP address, regardless of the 264 external port. See [RFC4787]. 266 Address and Port-Dependent Mapping: The NAT reuses the port mapping 267 for subsequent packets sent from the same internal IP address 268 and port to the same external IP address and port while the 269 mapping is still active. See [RFC4787]. 271 ALG: Application Level Gateway, an entity that can be embedded in a 272 NAT or other middlebox to perform the application layer 273 functions required for a particular protocol to traverse the 274 NAT/middlebox. 276 Endpoint-Independent Mapping: The NAT reuses the port mapping for 277 subsequent packets sent from the same internal IP address and 278 port to any external IP address and port. See [RFC4787]. 280 ICE: Interactive Connectivity Establishment, see [RFC5245]. 282 DNS: Domain Name Service 284 DoS: Denial of Service 286 DDoS: Distributed Denial of Service 288 NAT: Network Address Translator, see [RFC3022]. 290 NAPT: Network Address/Port Translator, see [RFC3022]. 292 RTP: Real-time Transport Protocol, see [RFC3550]. 294 RTSP: Real-Time Streaming Protocol, see [RFC2326] and 295 [I-D.ietf-mmusic-rfc2326bis]. 297 RTT: Round Trip Times. 299 SDP: Session Description Protocol, see [RFC4566]. 301 SSRC: Synchronization source in RTP, see [RFC3550]. 303 2. Detecting the loss of NAT mappings 305 Several NAT traversal techniques in the next chapter make use of the 306 fact that the NAT UDP mapping's external address and port can be 307 discovered. This information is then utilized to traverse the NAT 308 box. However any such information is only good while the mapping is 309 still valid. As the IAB's UNSAF document [RFC3424] points out, the 310 mapping can either timeout or change its properties. It is therefore 311 important for the NAT traversal solutions to handle the loss or 312 change of NAT mappings, according to RFC3424. 314 First, since NATs may also dynamically reclaim or readjust address/ 315 port translations, "keep-alive" and periodic re-polling may be 316 required according to RFC 3424. Secondly, it is possible to detect 317 and recover from the situation where the mapping has been changed or 318 removed. The loss of a mapping can be detected when no traffic 319 arrives for a while. Below we will give some recommendation on how 320 to detect loss of NAT mappings when using RTP/RTCP under RTSP 321 control. 323 A RTP session normally has both RTP and RTCP streams. The loss of a 324 RTP mapping can only be detected when expected traffic does not 325 arrive. If a client does not receive data within a few seconds after 326 having received the "200 OK" response to a PLAY request, there are 327 likely some middleboxes blocking the traffic. However, for a 328 receiver to be more certain to detect the case where no RTP traffic 329 was delivered due to NAT trouble, one should monitor the RTCP Sender 330 reports if they are received and not also blocked. The sender report 331 carries a field telling how many packets the server has sent. If 332 that has increased and no RTP packets has arrived for a few seconds 333 it is likely the RTP mapping has been removed. 335 The loss of mapping for RTCP is simpler to detect. RTCP is normally 336 sent periodically in each direction, even during the RTSP ready 337 state. If RTCP packets are missing for several RTCP intervals, the 338 mapping is likely lost. Note that if neither RTCP packets nor RTSP 339 messages are received by the RTSP server for a while, the RTSP server 340 has the option to delete the corresponding RTP session, SSRC and RTSP 341 session ID, because either the client can not get through a middle 342 box NAT/Firewall, or the client is mal-functioning. 344 3. Requirements on Solutions 346 This section considers the set of requirements for the evaluation of 347 RTSP NAT traversal solutions. 349 RTSP is a client-server protocol. Typically service providers deploy 350 RTSP servers in the public address realm. However, there are use 351 cases where the reverse is true: RTSP clients are connecting from 352 public address realm to RTSP servers behind home NATs. This is the 353 case for instance when home surveillance cameras running as RTSP 354 servers intend to stream video to cell phone users in the public 355 address realm through a home NAT. In terms of requirements, the 356 first requirement should be to solve the RTSP NAT traversal problem 357 for RTSP servers deployed in a public network, i.e. no NAT at the 358 server side. 360 The list of feature requirements for RTSP NAT solutions are given 361 below: 363 1. Must work for all flavors of NATs, including NATs with Address 364 and Port-Dependent Filtering. 366 2. Must work for firewalls (subject to pertinent firewall 367 administrative policies), including those with ALGs. 369 3. Should have minimal impact on clients in the open and not dual- 370 hosted. RTSP dual-hosting means that the RTSP signalling 371 protocol and the media protocol (e.g. RTP) are implemented on 372 different computers with different IP addresses. 374 * For instance, no extra delay from RTSP connection till arrival 375 of media 377 4. Should be simple to use/implement/administer so people actually 378 turn them on 380 * Otherwise people will resort to TCP tunneling through NATs 382 * Discovery of the address(es) assigned by NAT should happen 383 automatically, if possible 385 5. Should authenticate dual-hosted client transport handler to 386 prevent DDoS attacks. 388 The last requirement addresses the Distributed Denial-of-Service 389 (DDoS) threat, which relates to NAT traversal as explained below. 391 During NAT traversal, when the RTSP server determines the media 392 destination (address and port) for the client, the result may be that 393 the public IP address of the RTP receiver host is different than the 394 public IP address of the RTSP client host. This posts a DDoS threat 395 that has significant amplification potentials because the RTP media 396 streams in general consist of large number of IP packets. DDoS 397 attacks occur if the attacker fakes the messages in the NAT traversal 398 mechanism to trick the RTSP server into believing that the client's 399 RTP receiver is located on a separate host. For example, user A may 400 use his RTSP client to direct the RTSP server to send video RTP 401 streams to target.example.com in order to degrade the services 402 provided by target.example.com. Note a simple preventative measure 403 commonly deployed is for the RTSP server to disallow the cases where 404 the client's RTP receiver has a different public IP address than that 405 of the RTSP client. With the increased deployment of NAT middleboxes 406 by operators, i.e. carrier grade NAT (CGN), the reusing of a public 407 IP address for many customers reduces the protection provided. Also 408 in some applications (e.g., centralized conferencing), dual-hosted 409 RTSP/RTP clients have valid use cases. The key is how to 410 authenticate the messages exchanged during the NAT traversal process. 412 4. NAT Traversal Techniques 414 There exists a number of potential NAT traversal techniques that can 415 be used to allow RTSP to traverse NATs. They have different features 416 and are applicable to different topologies; their costs are also 417 different. They also vary in security levels. In the following 418 sections, each technique is outlined with discussions on the 419 corresponding advantages and disadvantages. 421 The main evaluation was done prior to 2007 and is based on what was 422 available then. This section includes NAT traversal techniques that 423 have not been formally specified anywhere else. The overview section 424 of this document may be the only publicly available specification of 425 some of the NAT traversal techniques. However that is not a real 426 barrier against doing an evaluation of the NAT traversal techniques. 427 Some other techniques have been recommended against or are no longer 428 possible due to standardization works' outcome or their failure to 429 progress within IETF after the initial evaluation in this document, 430 e.g. RTP No-Op [I-D.ietf-avt-rtp-no-op]. 432 4.1. Stand-Alone STUN 434 4.1.1. Introduction 436 Session Traversal Utilities for NAT (STUN) [RFC5389] is a 437 standardized protocol that allows a client to use secure means to 438 discover the presence of a NAT between itself and the STUN server. 439 The client uses the STUN server to discover the address mappings 440 assigned by the NAT. STUN is a client-server protocol. The STUN 441 client sends a request to a STUN server and the server returns a 442 response. There are two types of STUN messages - Binding Requests 443 and Indications. Binding requests are used when determining a 444 client's external address and solicits a response from the STUN 445 server with the seen address. 447 The first version of STUN [RFC3489] included categorization and 448 parameterization of NATs. This was abandoned in the updated version 449 [RFC5389] due to it being unreliable and brittle. Some of the below 450 discussed methods are based on RFC3489 functionality which will be 451 called out and the downside of that will be part of the 452 characterization. 454 4.1.2. Using STUN to traverse NAT without server modifications 456 This section describes how a client can use STUN to traverse NATs to 457 RTSP servers without requiring server modifications. Note that this 458 method has limited applicability and requires the server to be 459 available in the external/public address realm in regards to the 460 client located behind a NAT(s). 462 Limitations: 464 o The server must be located in either a public address realm or the 465 next hop external address realm in regards to the client. 467 o The client may only be located behind NATs that perform "Endpoint- 468 Independent" or "Address-Dependent" Mappings. Clients behind NATs 469 that do "Address and Port-Dependent" Mappings cannot use this 470 method. See [RFC4787] for full definition of these terms. 472 o Based on the discontinued middlebox classification of the replaced 473 STUN specification [RFC3489]. Thus brittle and unreliable. 475 Method: 477 A RTSP client using RTP transport over UDP can use STUN to traverse a 478 NAT(s) in the following way: 480 1. Use STUN to try to discover the type of NAT, and the timeout 481 period for any UDP mapping on the NAT. This is recommended to be 482 performed in the background as soon as IP connectivity is 483 established. If this is performed prior to establishing a 484 streaming session the delays in the session establishment will be 485 reduced. If no NAT is detected, normal SETUP should be used. 487 2. The RTSP client determines the number of UDP ports needed by 488 counting the number of needed media transport protocols sessions 489 in the multi-media presentation. This information is available 490 in the media description protocol, e.g. SDP [RFC4566]. For 491 example, each RTP session will in general require two UDP ports, 492 one for RTP, and one for RTCP. 494 3. For each UDP port required, establish a mapping and discover the 495 public/external IP address and port number with the help of the 496 STUN server. A successful mapping looks like: client's local 497 address/port <-> public address/port. 499 4. Perform the RTSP SETUP for each media. In the transport header 500 the following parameter should be included with the given values: 501 "dest_addr" [I-D.ietf-mmusic-rfc2326bis] or "destination" + 502 "client_port" [RFC2326] with the public/external IP address and 503 port pair for both RTP and RTCP. To be certain that this works 504 servers must allow a client to setup the RTP stream on any port, 505 not only even ports and with non-contiguous port numbers for RTP 506 and RTCP. This requires the new feature provided in the update 507 to RFC2326 [I-D.ietf-mmusic-rfc2326bis]. The server should 508 respond with a transport header containing an "src_addr" or 509 "source" + "server_port" parameters with the RTP and RTCP source 510 IP address and port of the media stream. 512 5. To keep the mappings alive, the client should periodically send 513 UDP traffic over all mappings needed for the session. For the 514 mapping carrying RTCP traffic the periodic RTCP traffic are 515 likely enough. For mappings carrying RTP traffic and for 516 mappings carrying RTCP packets at too low a frequency, keep-alive 517 messages should be sent. As keep alive messages, one could use 518 the RTP No-Op packet [I-D.ietf-avt-rtp-no-op] to the streaming 519 server's discard port (port number 9). The drawback of using RTP 520 No-Op is that the payload type number must be dynamically 521 assigned through RTSP first. Otherwise STUN could be used for 522 the keep-alive as well as empty UDP packets. 524 If a UDP mapping is lost, the above discovery process must be 525 repeated. The media stream also needs to be SETUP again to change 526 the transport parameters to the new ones. This will cause a glitch 527 in media playback. 529 To allow UDP packets to arrive from the server to a client behind a 530 "Address Dependent" filtering NAT, the client must first send a UDP 531 packet to establish filtering state in the NAT. The client, before 532 sending a RTSP PLAY request, must send a so called hole-punching 533 packet (such as a RTP No-Op packet) on each mapping, to the IP 534 address given as the servers source address. To create minimum 535 problems for the server these UDP packets should be sent to the 536 server's discard port (port number 9). Since UDP packets are 537 inherently unreliable, to ensure that at least one UDP message passes 538 the NAT, hole-punching packets should be retransmitted a reasonable 539 number of times. 541 For an "Address and Port Dependent" filtering NAT the client must 542 send messages to the exact ports used by the server to send UDP 543 packets before sending a RTSP PLAY request. This makes it possible 544 to use the above described process with the following additional 545 restrictions: for each port mapping, hole-punching packets need to be 546 sent first to the server's source address/port. To minimize 547 potential effects on the server from these messages the following 548 type of hole punching packets must be sent. RTP: an empty or less 549 than 12 bytes UDP packet. RTCP: A correctly formatted RTCP RR or SR 550 message. The above described adaptations for restricted NATs will 551 not work unless the server includes the "src_addr" in the "Transport" 552 header (which is the "source" transport parameter in RFC2326). 554 This method is brittle because it assumes one can use STUN to 555 classify the NAT behavior, which was found to be problematic 556 [RFC5389]. If the NAT changes the properties of the existing mapping 557 and filtering state for example due to load, then the methods will 558 fail. 560 4.1.3. ALG considerations 562 If a NAT supports RTSP ALG (Application Level Gateway) and is not 563 aware of the STUN traversal option, service failure may happen, 564 because a client discovers its public IP address and port numbers, 565 and inserts them in its SETUP requests. When the RTSP ALG processes 566 the SETUP request it may change the destination and port number, 567 resulting in unpredictable behavior. An ALG should not update 568 address fields which contains addresses other than the NATs internal 569 address domain. In cases where the ALG modifies fields unnecessarily 570 two alternatives exist: 572 1. Use TLS to encrypt the RTSP TCP connection to prevent the ALG 573 from reading and modifying the RTSP messages. 575 2. Turn off the STUN based NAT traversal mechanism 576 As it may be difficult to determine why the failure occurs, the usage 577 of TLS protected RTSP message exchange at all times would avoid this 578 issue. 580 4.1.4. Deployment Considerations 582 For the Stand-Alone usage of STUN the following applies: 584 Advantages: 586 o STUN is a solution first used by SIP based applications (See 587 section 1 and 2 of [RFC5389]). As shown above, with little or no 588 changes, the RTSP application can re-use STUN as a NAT traversal 589 solution, avoiding the pit-fall of solving a problem twice. 591 o Using STUN does not require RTSP server modifications; it only 592 affects the client implementation. 594 Disadvantages: 596 o Requires a STUN server deployed in the public address space. 598 o Only works with NATs that perform endpoint independent and address 599 dependent mappings. Address and Port-Dependent filtering NATs 600 create some issues. 602 o Brittle to NATs changing the properties of the NAT mapping and 603 filtering. 605 o Does not work with port and address dependent mapping NATs without 606 server modifications. 608 o Will mostly not work if a NAT uses multiple IP addresses, since 609 RTSP servers generally require all media streams to use the same 610 IP as used in the RTSP connection to prevent becoming a DDoS tool. 612 o Interaction problems exist when a RTSP-aware ALG interferes with 613 the use of STUN for NAT traversal unless TLS secured RTSP message 614 exchange is used. 616 o Using STUN requires that RTSP servers and clients support the 617 updated RTSP specification [I-D.ietf-mmusic-rfc2326bis], because 618 it is no longer possible to guarantee that RTP and RTCP ports are 619 adjacent to each other, as required by the "client_port" and 620 "server_port" parameters in RFC2326. 622 Transition: 624 The usage of STUN can be phased out gradually as the first step of a 625 STUN capable server or client should be to check the presence of 626 NATs. The removal of STUN capability in the client implementations 627 will have to wait until there is absolutely no need to use STUN. 629 4.1.5. Security Considerations 631 To prevent the RTSP server from being used as Denial of Service (DoS) 632 attack tools the RTSP Transport header parameter "destination" and 633 "dest_addr" are generally not allowed to point to any IP address 634 other than the one the RTSP message originates from. The RTSP server 635 is only prepared to make an exception to this rule when the client is 636 trusted (e.g., through the use of a secure authentication process, or 637 through some secure method of challenging the destination to verify 638 its willingness to accept the RTP traffic). Such a restriction means 639 that STUN in general does not work for use cases where RTSP and media 640 transport go to different addresses. 642 STUN combined with destination address restricted RTSP has the same 643 security properties as the core RTSP. It is protected from being 644 used as a DoS attack tool unless the attacker has the ability to 645 spoof the TCP connection carrying RTSP messages. 647 Using STUN's support for message authentication and secure transport 648 of RTSP messages, attackers cannot modify STUN responses or RTSP 649 messages (TLS) to change media destination. This protects against 650 hijacking, however as a client can be the initiator of an attack, 651 these mechanisms cannot securely prevent RTSP servers being used as 652 DoS attack tools. 654 4.2. Server Embedded STUN 656 4.2.1. Introduction 658 This Section describes an alternative to the stand-alone STUN usage 659 in the previous section that has quite significantly different 660 behavior. 662 4.2.2. Embedding STUN in RTSP 664 This section outlines the adaptation and embedding of STUN within 665 RTSP. This enables STUN to be used to traverse any type of NAT, 666 including address and Port-Dependent mapping NATs. This would 667 require RTSP level protocol changes. 669 This NAT traversal solution has limitations: 671 1. It does not work if both RTSP client and RTSP server are behind 672 separate NATs. 674 2. The RTSP server may, for security reasons, refuse to send media 675 streams to an IP different from the IP in the client RTSP 676 requests. 678 Deviations from STUN as defined in RFC 5389: 680 1. The RTSP application must provision the client with an identity 681 and shared secret to use in the STUN authentication; 683 2. We require STUN server to be co-located on RTSP server's media 684 source ports. 686 If STUN server is co-located with RTSP server's media source port, an 687 RTSP client using RTP transport over UDP can use STUN to traverse ALL 688 types of NATs. In the case of port and address dependent mapping 689 NATs, the party on the inside of the NAT must initiate UDP traffic. 690 The STUN Binding Request, being a UDP packet itself, can serve as the 691 traffic initiating packet. Subsequently, both the STUN Binding 692 Response packets and the RTP/RTCP packets can traverse the NAT, 693 regardless of whether the RTSP server or the RTSP client is behind 694 NAT (however only one of the can be behind a NAT). 696 Likewise, if an RTSP server is behind a NAT, then an embedded STUN 697 server must be co-located on the RTSP client's RTCP port. Also it 698 will become the client that needs to disclose his destination address 699 rather than the server, so the server can correctly determine its NAT 700 external source address for the media streams. In this case, we 701 assume that the client has some means of establishing TCP connection 702 to the RTSP server behind NAT so as to exchange RTSP messages with 703 the RTSP server, potentially using a proxy or static rules. 705 To minimize delay, we require that the RTSP server supporting this 706 option must inform the client about the RTP and RTCP ports from where 707 the server will send out RTP and RTCP packets, respectively. This 708 can be done by using the "server_port" parameter in RFC2326, and the 709 "src_addr" parameter in [I-D.ietf-mmusic-rfc2326bis]. Both are in 710 the RTSP Transport header. But in general this strategy will require 711 that one first do one SETUP request per media to learn the server 712 ports, then perform the STUN checks, followed by a subsequent SETUP 713 to change the client port and destination address to what was learned 714 during the STUN checks. 716 To be certain that RTCP works correctly the RTSP end-point (server or 717 client) will be required to send and receive RTCP packets from the 718 same port. 720 4.2.3. Discussion On Co-located STUN Server 722 In order to use STUN to traverse "address and port dependent" 723 filtering or mapping NATs the STUN server needs to be co-located with 724 the streaming server media output ports. This creates a de- 725 multiplexing problem: we must be able to differentiate a STUN packet 726 from a media packet. This will be done based on heuristics. The 727 existing STUN heuristics is the first byte in the packet and the 728 Magic Cookie field (added in RFC5389), which works fine between STUN 729 and RTP or RTCP where the first byte happens to be different. Thanks 730 to the magic cookie field it is unlikely that other protocols would 731 be mistaken for a STUN packet, but not assured. 733 4.2.4. ALG considerations 735 The same ALG traversal considerations as for Stand-Alone STUN applies 736 (Section 4.1.3). 738 4.2.5. Deployment Considerations 740 For the "Embedded STUN" method the following applies: 742 Advantages: 744 o STUN is a solution first used by SIP applications. As shown 745 above, with little or no changes, RTSP application can re-use STUN 746 as a NAT traversal solution, avoiding the pit-fall of solving a 747 problem twice. 749 o STUN has built-in message authentication features, which makes it 750 more secure against hi-jacking attacks. See next section for an 751 in-depth security discussion. 753 o This solution works as long as there is only one RTSP endpoint in 754 the private address realm, regardless of the NAT's type. There 755 may even be multiple NATs (see Figure 1 in [RFC5389]). 757 o Compared to other UDP based NAT traversal methods in this 758 document, STUN requires little new protocol development (since 759 STUN is already a IETF standard), and most likely less 760 implementation effort, since open source STUN server and client 761 implementations are available [STUN-IMPL][PJNATH]. There is the 762 need to embed STUN in RTSP server and client, which require a de- 763 multiplexer between STUN packets and RTP/RTCP packets. There is 764 also a need to register the proper feature tags. 766 Disadvantages: 768 o Some extensions to the RTSP core protocol, likely signaled by RTSP 769 feature tags, must be introduced. 771 o Requires an embedded STUN server to be co-located on each of the 772 RTSP server's media protocol's ports (e.g. RTP and RTCP ports), 773 which means more processing is required to de-multiplex STUN 774 packets from media packets. For example, the de-multiplexer must 775 be able to differentiate a RTCP RR packet from a STUN packet, and 776 forward the former to the streaming server, and the latter to the 777 STUN server. 779 o Does not support use cases that require the RTSP connection and 780 the media reception to happen at different addresses, unless the 781 server's security policy is relaxed. 783 o Interaction problems exist when a RTSP ALG is not aware of STUN 784 unless TLS is used to protect the RTSP messages. 786 o Using STUN requires that RTSP servers and clients support the 787 updated RTSP specification [I-D.ietf-mmusic-rfc2326bis], and they 788 both agree to support the NAT traversal feature. 790 o Increases the setup delay with at least the amount of time it 791 takes to perform STUN message exchanges. Most likely an extra 792 SETUP sequence will be required. 794 Transition: 796 The usage of STUN can be phased out gradually as the first step of a 797 STUN capable machine can be to check the presence of NATs for the 798 presently used network connection. The removal of STUN capability in 799 the client implementations will have to wait until there is 800 absolutely no need to use STUN. 802 4.2.6. Security Considerations 804 See Stand-Alone STUN (Section 4.1.5). 806 4.3. ICE 808 4.3.1. Introduction 810 ICE (Interactive Connectivity Establishment) [RFC5245] is a 811 methodology for NAT traversal that has been developed for SIP using 812 SDP offer/answer. The basic idea is to try, in a staggered parallel 813 fashion, all possible connection addresses that an endpoint may be 814 reachable by. This allows the endpoint to use the best available UDP 815 "connection" (meaning two UDP end-points capable of reaching each 816 other). The methodology has very nice properties in that basically 817 all NAT topologies are possible to traverse. 819 Here is how ICE works at a high level. End point A collects all 820 possible addresses that can be used, including local IP addresses, 821 STUN derived addresses, TURN addresses, etc. On each local port that 822 any of these address and port pairs lead to, a STUN server is 823 installed. This STUN server only accepts STUN requests using the 824 correct authentication through the use of a username and password. 826 End-point A then sends a request to establish connectivity with end- 827 point B, which includes all possible "destinations" [RFC5245] to get 828 the media through to A. Note that each of A's local address/port 829 pairs (host candidates and server reflexive base) has a STUN server 830 co-located. B in turn provides A with all its possible destinations 831 for the different media streams. A and B then uses a STUN client to 832 try to reach all the address and port pairs specified by A from its 833 corresponding destination ports. The destinations for which the STUN 834 requests successfully complete are then indicated and one is 835 selected. 837 If B fails to get any STUN response from A, all hope is not lost. 838 Certain NAT topologies require multiple tries from both ends before 839 successful connectivity is accomplished and therefore requests are 840 retransmitted multiple times. The STUN requests may also result in 841 that more connectivity alternatives (destinations) are discovered and 842 conveyed in the STUN responses. 844 4.3.2. Using ICE in RTSP 846 The usage of ICE for RTSP requires that both client and server be 847 updated to include the ICE functionality. If both parties implement 848 the necessary functionality the following steps could provide ICE 849 support for RTSP. 851 This assumes that it is possible to establish a TCP connection for 852 the RTSP messages between the client and the server. This is not 853 trivial in scenarios where the server is located behind a NAT, and 854 may require some TCP ports be opened, or the deployment of proxies, 855 etc. 857 The negotiation of ICE in RTSP of necessity will work different than 858 in SIP with SDP offer/answer. The protocol interactions are 859 different and thus the possibilities for transfer of states are also 860 somewhat different. The goal is also to avoid introducing extra 861 delay in the setup process at least for when the server is using a 862 public address and the client is either having a public address or is 863 behind NAT(s). This process is only intended to support PLAY mode, 864 i.e. media traffic flows from server to client. 866 1. The ICE usage begins in the SDP. The SDP for the service 867 indicates that ICE is supported at the server. No candidates can 868 be given here as that would not work with the on demand, DNS load 869 balancing, etc., that have the SDP indicate a resource on a 870 server park rather than a specific machine. 872 2. The client gathers addresses and puts together its candidates for 873 each media stream indicated in the session description. 875 3. In each SETUP request the client includes its candidates in an 876 ICE specific transport specification. This indicates for the 877 server the ICE support by the client. One candidate is the most 878 prioritized candidate and here the prioritization for this 879 address should be somewhat different compared to SIP. High 880 performance rather than always successful is recommended, as it 881 is most likely to be a server in the public. 883 4. The server responds to the SETUP (200 OK) for each media stream 884 with its candidates. A server with a public address usually only 885 provides a single ICE candidate. Also here one candidate is the 886 server primary address. 888 5. The connectivity checks are performed. For the server the 889 connectivity checks from the server to the clients have an 890 additional usage. They verify that there is someone willingly to 891 receive the media, thus preventing the server from unknowingly 892 performing a DoS attack. 894 6. Connectivity checks from the client promoting a candidate pair 895 were successful. Thus no further SETUP requests are necessary 896 and processing can proceed with step 7. If another address than 897 the primary has been verified by the client to work, that address 898 may then be promoted for usage in a SETUP request (Go to 7). If 899 the checks for the available candidates failed and if further 900 candidates have been derived during the connectivity checks, then 901 those can be signalled in new candidate lines in a SETUP request 902 updating the list (Go to 5). 904 7. Client issues PLAY request. If the server also has completed its 905 connectivity checks for the promoted candidate pair (based on 906 username as it may be derived addresses if the client was behind 907 NAT) then it can directly answer 200 OK (Go to 8). If the 908 connectivity check has not yet completed it responds with a 1xx 909 code to indicate that it is verifying the connectivity. If that 910 fails within the set timeout, an error is reported back. Client 911 needs to go back to 6. 913 8. Process completed and media can be delivered. ICE candidates not 914 used may be released. 916 To keep media paths alive the client needs to periodically send data 917 to the server. This will be realized with STUN. RTCP sent by the 918 client should be able to keep RTCP open but STUN will also be used 919 based on the same motivations as for ICE for SIP. 921 4.3.3. Implementation burden of ICE 923 The usage of ICE will require that a number of new protocols and new 924 RTSP/SDP features be implemented. This makes ICE the solution that 925 has the largest impact on client and server implementations amongst 926 all the NAT/Firewall traversal methods in this document. 928 RTSP server implementation requirements are: 930 o STUN server features 932 o Limited STUN client features 934 o SDP generation with more parameters. 936 o RTSP error code for ICE extension 938 RTSP client implementation requirements are: 940 o Limited STUN server features 942 o Limited STUN client features 944 o RTSP error code and ICE extension 946 4.3.4. Deployment Considerations 948 Advantages: 950 o Solves NAT connectivity discovery for basically all cases as long 951 as a TCP connection between the client and server can be 952 established. This includes servers behind NATs. (Note that a 953 proxy between address domains may be required to get TCP through). 955 o Improves defenses against DDoS attacks, since a media receiving 956 client requires authentications, via STUN on its media reception 957 ports. 959 Disadvantages: 961 o Increases the setup delay with at least the amount of time it 962 takes for the server to perform its STUN requests. 964 o Assumes that it is possible to de-multiplex between the packets of 965 the media protocol and STUN packets. 967 o Has fairly high implementation burden put on both RTSP server and 968 client. However, several Open Source ICE implementations do 969 exist, such as [NICE][PJNATH]. 971 4.3.5. Security Consideration 973 One should review the security consideration section of ICE and STUN 974 to understand that ICE contains some potential issues. However these 975 can be avoided by correctly using ICE in RTSP. In fact ICE does help 976 avoid the DDoS attack issue with RTSP substantially as it reduces the 977 possibility for a DDoS using RTSP servers to attackers that are on- 978 path between the RTSP server and the target and capable of 979 intercepting the STUN connectivity check packets and correctly send a 980 response to the server. 982 4.4. Latching 984 4.4.1. Introduction 986 Latching [I-D.ietf-mmusic-latching] is a NAT traversal solution that 987 is based on requiring RTSP clients to send UDP packets to the 988 server's media output ports. Conventionally, RTSP servers send RTP 989 packets in one direction: from server to client. Latching is similar 990 to connection-oriented traffic, where one side (e.g., the RTSP 991 client) first "connects" by sending a RTP packet to the other side's 992 RTP port, the recipient then replies to the originating IP and port. 993 This method is also referred to as "Late binding". It requires that 994 all RTP/RTCP transport is done symmetrical, i.e. Symmetric RTP 995 [RFC4961]. 997 Specifically, when the RTSP server receives the latching packet 998 (a.k.a. hole-punching packet, since it is used to punch a hole in the 999 Firewall/NAT and to aid the server for port binding and address 1000 mapping) from its client, it copies the source IP and Port number and 1001 uses them as delivery address for media packets. By having the 1002 server send media traffic back the same way as the client's packet 1003 are sent to the server, address mappings will be honored. Therefore 1004 this technique works for all types of NATs, given that the server is 1005 not behind a NAT. However, it does require server modifications. 1006 Unless there is built-in protection mechanism, latching is very 1007 vulnerable to DDoS attacks (See Security Considerations of 1008 [I-D.ietf-mmusic-latching]), because attackers can simply forge the 1009 source IP & Port of the latching packet. Using the rule for 1010 restricting IP address to the one of the signaling connection will 1011 need to be applied here also. However, that does not protect against 1012 hijacking from another client behind the same NAT. This can become a 1013 serious issue in deployments with CGNs. 1015 4.4.2. Necessary RTSP extensions 1017 To support Latching, the RTSP signaling must be extended to allow the 1018 RTSP client to indicate that it will use Latching. The client also 1019 needs to be able to signal its RTP SSRC to the server in its SETUP 1020 request. The RTP SSRC is used to establish some basic level of 1021 security against hijacking attacks or simply avoid mis-association 1022 when multiple clients are behind the same NAT. Care must be taken in 1023 choosing clients' RTP SSRC. First, it must be unique within all the 1024 RTP sessions belonging to the same RTSP session. Secondly, if the 1025 RTSP server is sending out media packets to multiple clients from the 1026 same send port, the RTP SSRC needs to be unique amongst those 1027 clients' RTP sessions. Recognizing that there is a potential that 1028 RTP SSRC collisions may occur, the RTSP server must be able to signal 1029 to a client that a collision has occurred and that it wants the 1030 client to use a different RTP SSRC carried in the SETUP response or 1031 use unique ports per RTSP session. Using unique ports limits an RTSP 1032 server in the number of sessions it can simultaneously handle per 1033 interface IP addresses. 1035 4.4.3. Deployment Considerations 1037 Advantages: 1039 o Works for all types of client-facing NATs. (Requirement 1 in 1040 Section 3). 1042 o Has no interaction problems with any RTSP ALG changing the 1043 client's information in the transport header. 1045 Disadvantages: 1047 o Requires modifications to both RTSP server and client. 1049 o Limited to work with servers that have an public IP address. 1051 o The format of the RTP packet for "connection setup" (a.k.a 1052 Latching packet) is yet to be defined. One possibility is to use 1053 RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op]. 1055 o SSRC management if RTP is used for latching due to risk for mis- 1056 association of clients to RTSP sessions at the server if SSRC 1057 collision occurs. 1059 o Has significant security considerations (Section 4.4.4) due to 1060 lack of strong authentication mechanism, compare with STUN message 1061 authentication, and will need to use address restrictions. 1063 4.4.4. Security Consideration 1065 Latching's major security issue is that RTP streams can be hijacked 1066 and directed towards any target that the attacker desires unless 1067 address restrictions are used. In the case of NATs with multiple 1068 clients on the inside of them, hijacking can still occur. This 1069 becomes a significant threat in the context of carrier grade NATs 1070 (CGN). 1072 The most serious security problem is the deliberate attack with the 1073 use of a RTSP client and Latching. The attacker uses RTSP to setup a 1074 media session. Then it uses Latching with a spoofed source address 1075 of the intended target of the attack. There is no defense against 1076 this attack other than restricting the possible address a latching 1077 packet can come from to the same as the RTSP TCP connection are from. 1078 This prevents Latching to be used in use cases that require different 1079 addresses for media destination and signalling. Even allowing only a 1080 limited address range containing the signalling address from where 1081 latching is allowed opens up a significant vulnerability as it is 1082 difficult to determine the address usage for the network the client 1083 connects from. 1085 A hijack attack can also be performed in various ways. The basic 1086 attack is based on the ability to read the RTSP signaling packets in 1087 order to learn the address and port the server will send from and 1088 also the SSRC the client will use. Having this information the 1089 attacker can send its own Latching packets containing the correct RTP 1090 SSRC to the correct address and port on the server. The RTSP server 1091 will then use the source IP and port from the Latching packet as the 1092 destination for the media packets it sends. 1094 Another variation of this attack is for a man in the middle to modify 1095 the RTP latching packet being sent by a client to the server by 1096 simply changing the source IP to the target one desires to attack. 1098 One can fend off the snooping based attack by applying encryption to 1099 the RTSP signaling transport. However, if the attacker is an man in 1100 the middle modifying latching packets, the attack is impossible to 1101 defend against other than through address restrictions. As a NAT re- 1102 writes the source IP and (possibly) port this cannot be 1103 authenticated, but authentication is required in order to protect 1104 against this type of DoS attack. 1106 Yet another issues is that these attacks also can be used to deny the 1107 client the service it desires from the RTSP server completely. The 1108 attacker modifies or originates its own latching packets with another 1109 port than what the legit latching packets uses, which results in that 1110 the media server sends the RTP/RTCP traffic to ports the client isn't 1111 listening for RTP/RTCP on. 1113 The amount of random non-guessable material in the latching packet 1114 determines how well Latching can fend off stream-hijacking performed 1115 by parties that are off the client to server network path, i.e. lacks 1116 the capability to see the client's latching packets. This proposal 1117 uses the 32-bit RTP SSRC field to this effect. Therefore it is 1118 important that this field is derived with a non-predictable random 1119 number generator. It should not be possible by knowing the algorithm 1120 used and a couple of basic facts, to derive what random number a 1121 certain client will use. 1123 An attacker not knowing the SSRC but aware of which port numbers that 1124 a server sends from can deploy a brute force attack on the server by 1125 testing a lot of different SSRCs until it finds a matching one. 1126 Therefore a server could implement functionality that blocks packets 1127 to ports or from sources that receive or send multiple Latching 1128 packets with different invalid SSRCs, especially when they are coming 1129 from the same IP/Port. Note that this mitigation in itself opens up 1130 a new venue for DoS attacks against legit users trying to latch. 1132 To improve the security against attackers the amount of random 1133 material could be increased. To achieve a longer random tag while 1134 still using RTP and RTCP, it will be necessary to develop RTP and 1135 RTCP payload formats for carrying the random material. 1137 4.5. A Variation to Latching 1139 4.5.1. Introduction 1141 Latching as described above requires the usage of a valid RTP format 1142 as the Latching packet, i.e. the first packet that the client sends 1143 to the server to set up virtual RTP connection. There is currently 1144 no appropriate RTP packet format for this purpose, although the RTP 1145 No-Op format was a proposal to fix the problem 1146 [I-D.ietf-avt-rtp-no-op], however, that work was abandoned. There 1147 exists a RFC that discusses the implication of different type of 1148 packets as keep-alives for RTP [RFC6263] and its findings are very 1149 relevant to the format of the Latching packet. 1151 Meanwhile, there has been NAT/Firewall traversal techniques deployed 1152 in the wireless streaming market place that use non-RTP messages as 1153 Latching packets. This section describes a variant based on a subset 1154 of those solutions that alters the previously described Latching 1155 solution. 1157 4.5.2. Necessary RTSP extensions 1159 In this variation of Latching, the Latching packet is a small UDP 1160 packet that does not contain an RTP header. In response to the 1161 client's Latching packet, the RTSP server sends back a similar 1162 Latching packet as a confirmation so the client can stop the so 1163 called "connection phase" of this NAT traversal technique. 1164 Afterwards, the client only has to periodically send Latching packets 1165 as keep-alive messages for the NAT mappings. 1167 The server listens on its RTP-media output port, and tries to decode 1168 any received UDP packet as Latching packet. This is valid since an 1169 RTSP server is not expecting RTP traffic from the RTSP client. Then, 1170 it can correlate the Latching packet with the RTSP client's session 1171 ID or the client's SSRC, and record the NAT bindings accordingly. 1172 The server then sends a Latching packet as the response to the 1173 client. 1175 The Latching packet can contain the SSRC to identify the RTP stream, 1176 and care must be taken if the packet is bigger than 12 bytes, 1177 ensuring that it is distinctively different from RTP packets, whose 1178 header size is 12 bytes. 1180 RTSP signaling can be added to do the following: 1182 1. Enable or disable such Latching message exchanges. When the 1183 Firewall/NAT has an RTSP-aware ALG, it is possible to disable 1184 Latching message exchange and let the ALG work out the address 1185 and port mappings. 1187 2. Configure the number of re-tries and the re-try interval of the 1188 Latching message exchanges. 1190 4.5.3. Deployment Considerations 1192 This approach has the following advantages when compared with the 1193 Latching approach (Section 4.4): 1195 1. There is no need to define RTP payload format for Firewall 1196 traversal, therefore it is simple to use, implement and 1197 administer (Requirement 4 in Section 3), instead a Latching 1198 protocol must be defined. 1200 2. When properly defined, this kind of Latching packet exchange can 1201 also authenticate RTP receivers, to prevent hijacking attacks. 1203 This approach has the following disadvantages when compared with the 1204 Latching approach: 1206 1. RTP traffic is normally accompanied by RTCP traffic. This 1207 approach needs to rely on RTCP RRs and SRs to enable NAT 1208 traversal for RTCP endpoints, use RTP/RTCP Multiplexing 1209 [RFC5761], or use the same type of Latching packets also for RTCP 1210 endpoints. 1212 2. The server's sender SSRC for the RTP stream or other session 1213 Identity information must be signaled in RTSP's SETUP response, 1214 in the Transport header of the RTSP SETUP response. 1216 4.5.4. Security Considerations 1218 Compared to the security properties of Latching this variant is 1219 slightly improved. First of all it allows for a larger random field 1220 in the Latching packets which makes it more unlikely for an off-path 1221 attacker to succeed in a hi-jack attack. Secondly the confirmation 1222 allows the client to know when Latching works and when it didn't and 1223 thus restart the Latching process by updating the SSRC. Thirdly if 1224 an authentication mechanism is included in the latching packet 1225 hijacking attacks can be prevented. 1227 Still the main security issue remain that the RTSP server can't know 1228 that the source address in the latching packet was coming from a RTSP 1229 client wanting to receive media and not one that likes to direct the 1230 media traffic to an DoS target. 1232 4.6. Three Way Latching 1234 4.6.1. Introduction 1236 The three way Latching is an attempt to try to resolve the most 1237 significant security issues for both previously discussed variants of 1238 Latching. By adding a server request response exchange directly 1239 after the initial latching the server can verify that the target 1240 address present in the latching packet is an active listener and 1241 confirm its desire to establish a media flow. 1243 4.6.2. Necessary RTSP extensions 1245 Uses the same RTSP extensions as the alternative latching method 1246 (Section 4.5) uses. The extensions for this variant are only in the 1247 format and transmission of the Latching packets. 1249 The client to server latching packet is similar to the Alternative 1250 Latching (Section 4.5), i.e. an UDP packet with some session 1251 identifier and a random value. When the server responds to the 1252 Latching packet with a Latching confirmation, it includes a random 1253 value (Nonce) of its own in addition to echoing back the one the 1254 client sent. Then a third message is added to the exchange. The 1255 client acknowledges the reception of the Latching confirmation 1256 message and echoes back the server's nonce. Thus confirming that the 1257 Latched address goes to a RTSP client that initiated the latching and 1258 is actually present at that address. The RTSP server will refuse to 1259 send any media until the Latching Acknowledgement has been received 1260 with a valid nonce. 1262 4.6.3. Deployment Considerations 1264 A solution with a 3-way handshake and its own Latching packets can be 1265 compared with the ICE-based solution (Section 4.3) and have the 1266 following differences: 1268 o Only works for servers with public IP addresses compared to any 1269 type of server 1271 o May be simpler to implement due to the avoidance of the ICE 1272 prioritization and check-board mechanisms. 1274 However, a 3-way Latching protocol is very similar to using STUN in 1275 both directions as Latching and verification protocol. Using STUN 1276 would remove the need for implementing a new protocol. 1278 4.7. Application Level Gateways 1280 4.7.1. Introduction 1282 An Application Level Gateway (ALG) reads the application level 1283 messages and performs necessary changes to allow the protocol to work 1284 through the middle box. However this behavior has some problems in 1285 regards to RTSP: 1287 1. It does not work when the RTSP protocol is used with end-to-end 1288 security. As the ALG can't inspect and change the application 1289 level messages the protocol will fail due to the middle box. 1291 2. ALGs need to be updated if extensions to the protocol are added. 1292 Due to deployment issues with changing ALGs this may also break 1293 the end-to-end functionality of RTSP. 1295 Due to the above reasons it is not recommended to use an RTSP ALG in 1296 NATs. This is especially important for NATs targeted to home users 1297 and small office environments, since it is very hard to upgrade NATs 1298 deployed in home or SOHO (small office/home office) environment. 1300 4.7.2. Outline On how ALGs for RTSP work 1302 In this section, we provide a step-by-step outline on how one could 1303 go about writing an ALG to enable RTSP to traverse a NAT. 1305 1. Detect any SETUP request. 1307 2. Try to detect the usage of any of the NAT traversal methods that 1308 replace the address and port of the Transport header parameters 1309 "destination" or "dest_addr". If any of these methods are used, 1310 then the ALG should not change the address. Ways to detect that 1311 these methods are used are: 1313 * For embedded STUN, it would be to watch for a feature tag, 1314 like "nat.stun". If any of those exists in the "supported", 1315 "proxy-require", or "require" headers of the RTSP exchange. 1317 * For stand alone STUN and TURN based solutions: This can be 1318 detected by inspecting the "destination" or "dest_addr" 1319 parameter. If it contains either one of the NAT's external IP 1320 addresses or a public IP address then such a solution is in 1321 use. However if multiple NATs are used this detection may 1322 fail. Remapping should only be done for addresses belonging 1323 to the NAT's own private address space. 1325 Otherwise continue to the next step. 1327 3. Create UDP mappings (client given IP/port <-> external IP/port) 1328 where needed for all possible transport specifications in the 1329 transport header of the request found in (1). Enter the external 1330 address and port(s) of these mappings in transport header. 1331 Mappings shall be created with consecutive public port numbers 1332 starting on an even number for RTP for each media stream. 1333 Mappings should also be given a long timeout period, at least 5 1334 minutes. 1336 4. When the SETUP response is received from the server, the ALG may 1337 remove the unused UDP mappings, i.e. the ones not present in the 1338 transport header. The session ID should also be bound to the UDP 1339 mappings part of that session. 1341 5. If SETUP response settles on RTP over TCP or RTP over RTSP as 1342 lower transport, do nothing: let TCP tunneling take care of NAT 1343 traversal. Otherwise go to next step. 1345 6. The ALG should keep the UDP mappings belonging to the RTSP 1346 session as long as: an RTSP message with the session's ID has 1347 been sent in the last timeout interval, or a UDP message has been 1348 sent on any of the UDP mappings during the last timeout interval. 1350 7. The ALG may remove a mapping as soon a TEARDOWN response has been 1351 received for that media stream. 1353 4.7.3. Deployment Considerations 1355 Advantage: 1357 o No impact on either client or server 1359 o Can work for any type of NATs 1361 Disadvantage: 1363 o When deployed they are hard to update to reflect protocol 1364 modifications and extensions. If not updated they will break the 1365 functionality. 1367 o When end-to-end security is used, the ALG functionality will fail. 1369 o Can interfere with other types of traversal mechanisms, such as 1370 STUN. 1372 Transition: 1374 An RTSP ALG will not be phased out in any automatic way. It must be 1375 removed, probably through the removal of the NAT it is associated 1376 with. 1378 4.7.4. Security Considerations 1380 An ALG will not work with deployment of end-to-end RTSP signaling 1381 security. Therefore deployment of ALG will likely result in clients 1382 located behind NATs not using end-to-end security. 1384 The creation of an UDP mapping based on the signalling message has 1385 some potential security implications. First of all if the RTSP 1386 client releases its ports and another application are assigned these 1387 instead it could receive RTP media as long as the mappings exist and 1388 the RTSP server has failed to be signalled or notice the lack of 1389 client response. 1391 A NAT with RTSP ALG that assigns mappings based on SETUP requests 1392 could potentially become victim of a resource exhaustion attack. If 1393 an attacker creates a lot of RTSP sessions, even without starting 1394 media transmission could exhaust the pool of available UDP ports on 1395 the NAT. Thus only a limited number of UDP mappings should be 1396 allowed to be created by the RTSP ALG. 1398 4.8. TCP Tunneling 1400 4.8.1. Introduction 1402 Using a TCP connection that is established from the client to the 1403 server ensures that the server can send data to the client. The 1404 connection opened from the private domain ensures that the server can 1405 send data back to the client. To send data originally intended to be 1406 transported over UDP requires the TCP connection to support some type 1407 of framing of the media data packets. Using TCP also results in the 1408 client having to accept that real-time performance can be impacted. 1409 TCP's problem of ensuring timely delivery was one of the reasons why 1410 RTP was developed. Problems that arise with TCP are: head-of-line 1411 blocking, delay introduced by retransmissions, highly varying rate 1412 due to the congestion control algorithm. If sufficient amount of 1413 buffering (several seconds) in the receiving client can be tolerated 1414 then TCP clearly can work. 1416 4.8.2. Usage of TCP tunneling in RTSP 1418 The RTSP core specification [I-D.ietf-mmusic-rfc2326bis] supports 1419 interleaving of media data on the TCP connection that carries RTSP 1420 signaling. See section 14 in [I-D.ietf-mmusic-rfc2326bis] for how to 1421 perform this type of TCP tunneling. There also exists another way of 1422 transporting RTP over TCP defined in Appendix C.2 in 1423 [I-D.ietf-mmusic-rfc2326bis]. For signaling and rules on how to 1424 establish the TCP connection in lieu of UDP, see appendix C.2 in 1425 [I-D.ietf-mmusic-rfc2326bis]. This is based on the framing of RTP 1426 over the TCP connection as described in RFC 4571 [RFC4571]. 1428 4.8.3. Deployment Considerations 1430 Advantage: 1432 o Works through all types of NATs where the RTSP server in not NATed 1433 or at least reachable like it was not. 1435 Disadvantage: 1437 o Functionality needs to be implemented on both server and client. 1439 o Will not always meet multimedia stream's real-time requirements. 1441 Transition: 1443 The tunneling over RTSP's TCP connection is not planned to be phased- 1444 out. It is intended to be a fallback mechanism and for usage when 1445 total media reliability is desired, even at the potential price of 1446 loss of real-time properties. 1448 4.8.4. Security Considerations 1450 The TCP tunneling of RTP has no known security problems besides those 1451 already presented in the RTSP specification. It is not possible to 1452 get any amplification effect for denial of service attacks due to 1453 TCP's flow control. A possible security consideration, when session 1454 media data is interleaved with RTSP, would be the performance 1455 bottleneck when RTSP encryption is applied, since all session media 1456 data also needs to be encrypted. 1458 4.9. TURN (Traversal Using Relay NAT) 1460 4.9.1. Introduction 1462 Traversal Using Relay NAT (TURN) [RFC5766] is a protocol for setting 1463 up traffic relays that allow clients behind NATs and firewalls to 1464 receive incoming traffic for both UDP and TCP. These relays are 1465 controlled and have limited resources. They need to be allocated 1466 before usage. TURN allows a client to temporarily bind an address/ 1467 port pair on the relay (TURN server) to its local source address/port 1468 pair, which is used to contact the TURN server. The TURN server will 1469 then forward packets between the two sides of the relay. 1471 To prevent DoS attacks on either recipient, the packets forwarded are 1472 restricted to the specific source address. On the client side it is 1473 restricted to the source setting up the allocation. On the external 1474 side this is limited to the source address/port pair that have been 1475 given permission by the TURN client creating the allocation. Packets 1476 from any other source on this address will be discarded. 1478 Using a TURN server makes it possible for a RTSP client to receive 1479 media streams from even an unmodified RTSP server. However the 1480 problem is those RTSP servers most likely restrict media destinations 1481 to no other IP address than the one the RTSP message arrives from. 1482 This means that TURN could only be used if the server knows and 1483 accepts that the IP belongs to a TURN server and the TURN server 1484 can't be targeted at an unknown address or also the RTSP connection 1485 is relayed through the same TURN server. 1487 4.9.2. Usage of TURN with RTSP 1489 To use a TURN server for NAT traversal, the following steps should be 1490 performed. 1492 1. The RTSP client connects with the RTSP server. The client 1493 retrieves the session description to determine the number of 1494 media streams. To avoid the issue with having RTSP connection 1495 and media traffic from different addresses also the TCP 1496 connection must be done through the same TURN server as the one 1497 in the next step. This will require the usage of TURN for TCP 1498 [RFC6062]. 1500 2. The client establishes the necessary bindings on the TURN server. 1501 It must choose the local RTP and RTCP ports that it desires to 1502 receive media packets. TURN supports requesting bindings of even 1503 port numbers and contiguous ranges. 1505 3. The RTSP client uses the acquired address and port allocations in 1506 the RTSP SETUP request using the destination header. 1508 4. The RTSP Server sends the SETUP reply, which must include the 1509 transport headers src_addr parameter (source and port in RTSP 1510 1.0). Note that the server is required to have a mechanism to 1511 verify that it is allowed to send media traffic to the given 1512 address. 1514 5. The RTSP Client uses the RTSP Server's response to create TURN 1515 permissions for the server's media traffic. 1517 6. The client requests that the server starts playing. The server 1518 starts sending media packets to the given destination address and 1519 ports. 1521 7. Media packets arrive at the TURN server on the external port; If 1522 the packets match an established permission, the TURN server 1523 forwards the media packets to the RTSP client. 1525 8. If the client pauses and media is not sent for about 75% of the 1526 mapping timeout the client should use TURN to refresh the 1527 bindings. 1529 4.9.3. Deployment Considerations 1531 Advantages: 1533 o Does not require any server modifications given that the server 1534 includes the src_addr header in the SETUP response. 1536 o Works for any type of NAT as long as the RTSP server has public 1537 reachable IP address. 1539 Disadvantage: 1541 o Requires another network element, namely the TURN server. 1543 o A TURN server for RTSP may not scale since the number of sessions 1544 it must forward is proportional to the number of client media 1545 sessions. 1547 o TURN server becomes a single point of failure. 1549 o Since TURN forwards media packets, it necessarily introduces 1550 delay. 1552 o An RTSP ALG may change the necessary destinations parameter. This 1553 will cause the media traffic to be sent to the wrong address. 1555 Transition: 1557 TURN is not intended to be phased-out completely, see Section 19 of 1558 [RFC5766]. However the usage of TURN could be reduced when the 1559 demand for having NAT traversal is reduced. 1561 4.9.4. Security Considerations 1563 The TURN server can become part of a denial of service attack towards 1564 any victim. To perform this attack the attacker must be able to 1565 eavesdrop on the packets from the TURN server towards a target for 1566 the DoS attack. The attacker uses the TURN server to setup a RTSP 1567 session with media flows going through the TURN server. The attacker 1568 is in fact creating TURN mappings towards a target by spoofing the 1569 source address of TURN requests. As the attacker will need the 1570 address of these mappings he must be able to eavesdrop or intercept 1571 the TURN responses going from the TURN server to the target. Having 1572 these addresses, he can set up a RTSP session and start delivery of 1573 the media. The attacker must be able to create these mappings. The 1574 attacker in this case may be traced by the TURN username in the 1575 mapping requests. 1577 This attack requires that the attacker has access to a user account 1578 on the TURN server to be able set up the TURN mappings. To prevent 1579 this attack the RTSP server needs to verify that the ultimate target 1580 destination accept this media stream. Which would require something 1581 like ICE's connectivity checks being run between the RTSP server and 1582 the RTSP client. 1584 5. Firewalls 1586 Firewalls exist for the purpose of protecting a network from traffic 1587 not desired by the firewall owner. Therefore it is a policy decision 1588 if a firewall will let RTSP and its media streams through or not. 1589 RTSP is designed to be firewall friendly in that it should be easy to 1590 design firewall policies to permit passage of RTSP traffic and its 1591 media streams. 1593 The firewall will need to allow the media streams associated with a 1594 RTSP session to pass through it. Therefore the firewall will need an 1595 ALG that reads RTSP SETUP and TEARDOWN messages. By reading the 1596 SETUP message the firewall can determine what type of transport and 1597 from where, the media stream packets will be sent. Commonly there 1598 will be the need to open UDP ports for RTP/RTCP. By looking at the 1599 source and destination addresses and ports the opening in the 1600 firewall can be minimized to the least necessary. The opening in the 1601 firewall can be closed after a TEARDOWN message for that session or 1602 the session itself times out. 1604 Simpler firewalls do allow a client to receive media as long as it 1605 has sent packets to the target. Depending on the security level this 1606 can have the same behavior as a NAT. The only difference is that no 1607 address translation is done. To use such a firewall a client would 1608 need to implement one of the above described NAT traversal methods 1609 that include sending packets to the server to open up the mappings. 1611 6. Comparison of NAT traversal techniques 1613 This section evaluates the techniques described above against the 1614 requirements listed in Section 3. 1616 In the following table, the columns correspond to the numbered 1617 requirements. For instance, the column under R1 corresponds to the 1618 first requirement in Section 3: must work for all flavors of NATs. 1619 The rows represent the different NAT/Firewall traversal techniques. 1620 Latch is short for Latching, "V. Latch" is short for "variation of 1621 Latching" as described in Section 4.5. "3-W Latch" is short for the 1622 Three Way Latching described in Section 4.6. 1624 A Summary of the requirements are: 1626 R1: Work for all flavors of NATs 1628 R2: Must work with Firewalls, including those with ALGs 1630 R3: Should have minimal impact on clients not behind NATs, counted 1631 in minimal number of additional RTTs 1633 R4: Should be simple to use, Implement and administer. 1635 R5: Should provide mitigation against DDoS attacks 1637 The following considerations are also added to requirements: 1639 C1: Will solution support both Clients and Servers behind NAT 1641 C2: Is the solution robust to changing NAT behaviors 1643 ------------+------+------+------+------+------+------+------+ 1644 | R1 | R2 | R3 | R4 | R5 | C1 | C2 | 1645 ------------+------+------+------+------+------+------+------+ 1646 STUN | No | Yes | 1 | Maybe| No | No | No | 1647 ------------+------+------+------+------+------+------+------+ 1648 Emb. STUN | Yes | Yes | 2 | Maybe| No | No | Yes | 1649 ------------+------+------+------+------+------+------+------+ 1650 ICE | Yes | Yes | 2.5 | No | Yes | Yes | Yes | 1651 ------------+------+------+------+------+------+------+------+ 1652 Latch | Yes | Yes | 1 | Maybe| No | No | Yes | 1653 ------------+------+------+------+------+------+------+------+ 1654 V. Latch | Yes | Yes | 1 | Yes | No | No | Yes | 1655 ------------+------+------+------+------+------+------+------+ 1656 3-W Latch | Yes | Yes | 1.5 | Maybe| Yes | No | Yes | 1657 ------------+------+------+------+------+------+------+------+ 1658 ALG |(Yes) | Yes | 0 | No | Yes | No | Yes | 1659 ------------+------+------+------+------+------+------+------+ 1660 TCP Tunnel | Yes | Yes | 1.5 | Yes | Yes | No | Yes | 1661 ------------+------+------+------+------+------+------+------+ 1662 TURN | Yes | Yes | 1 | No | Yes |(Yes) | Yes | 1663 ------------+------+------+------+------+------+------+------+ 1665 Figure 1: Comparison of fulfillment of requirements 1667 Looking at Figure 1 one would draw the conclusion that using TCP 1668 Tunneling or Three-Way Latching is the solutions that best fulfill 1669 the requirements. The different techniques were discussed in the 1670 MMUSIC WG. It was established that the WG would pursue an ICE based 1671 solution due to its generality and capability of handling also 1672 servers delivering media from behind NATs. TCP Tunneling is likely 1673 to be available as an alternative, due to its specification in the 1674 main RTSP specification. Thus it can be used if desired and the 1675 potential downsides of using TCP is acceptable in particular 1676 deployments. When it comes to Three-Way Latching it is a very 1677 competitive technique given that you don't need support for RTSP 1678 servers behind NATs. There were some discussion in the WG if the 1679 increased implementation burden of ICE is sufficiently motivated 1680 compared to a the Three-Way Latching solution for this generality. 1682 In the end the authors believe that reuse of ICE, the greater 1683 flexibility and anyway need to deploy a new solution was the decisive 1684 factors. 1686 The ICE based RTSP NAT traversal solution is specified in "A Network 1687 Address Translator (NAT) Traversal mechanism for media controlled by 1688 Real-Time Streaming Protocol (RTSP)" [I-D.ietf-mmusic-rtsp-nat]. 1690 7. IANA Considerations 1692 This document makes no request of IANA. 1694 Note to RFC Editor: this section may be removed on publication as an 1695 RFC. 1697 8. Security Considerations 1699 In the preceding sections we have discussed security merits of the 1700 different NAT/Firewall traversal methods for RTSP discussed here. In 1701 summary, the presence of NAT(s) is a security risk, as a client 1702 cannot perform source authentication of its IP address. This 1703 prevents the deployment of any future RTSP extensions providing 1704 security against hijacking of sessions by a man-in-the-middle. 1706 Each of the proposed solutions has security implications. Using STUN 1707 will provide the same level of security as RTSP without transport 1708 level security and source authentications, as long as the server does 1709 not allow media to be sent to a different IP-address than the RTSP 1710 client request was sent from. Using Latching will have a higher risk 1711 of session hijacking or denial of service than normal RTSP. The 1712 reason is that there exists a probability that an attacker is able to 1713 guess the random bits that the client uses to prove its identity when 1714 creating the address bindings. This can be solved in the variation 1715 of Latching (Section 4.5) with authentication features. Still both 1716 those variants of Latching are vulnerable against deliberate attack 1717 from the RTSP client to redirect the media stream requested to any 1718 target assuming it can spoof the source address. This security 1719 vulnerability is solved by performing a Three-way Latching procedure 1720 as discussed in Section 4.6. The usage of an RTSP ALG does not in 1721 itself increase the risk for session hijacking. However the 1722 deployment of ALGs as the sole mechanism for RTSP NAT traversal will 1723 prevent deployment of end-to-end encrypted RTSP signaling. The usage 1724 of TCP tunneling has no known security problems. However, it might 1725 provide a bottleneck when it comes to end-to-end RTSP signaling 1726 security if TCP tunneling is used on an interleaved RTSP signaling 1727 connection. The usage of TURN has severe risk of denial of service 1728 attacks against a client. The TURN server can also be used as a 1729 redirect point in a DDoS attack unless the server has strict enough 1730 rules for who may create bindings. 1732 9. Acknowledgements 1734 The author would also like to thank all persons on the MMUSIC working 1735 group's mailing list that has commented on this document. Persons 1736 having contributed in such way in no special order to this protocol 1737 are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon, 1738 Amir Wolf, Anders Klemets, Flemming Andreasen, Ari Keranen, Bill 1739 Atwood, and Colin Perkins. Thomas Zeng would also like to give 1740 special thanks to Greg Sherwood of PacketVideo for his input into 1741 this memo. 1743 Section 1.1 contains text originally written for RFC 4787 by Francois 1744 Audet and Cullen Jennings. 1746 10. Informative References 1748 [I-D.ietf-avt-rtp-no-op] 1749 Andreasen, F., "A No-Op Payload Format for RTP", draft- 1750 ietf-avt-rtp-no-op-04 (work in progress), May 2007. 1752 [I-D.ietf-mmusic-latching] 1753 Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT 1754 Traversal (HNT) for Media in Real-Time Communication", 1755 draft-ietf-mmusic-latching-04 (work in progress), October 1756 2013. 1758 [I-D.ietf-mmusic-rfc2326bis] 1759 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1760 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1761 (RTSP)", draft-ietf-mmusic-rfc2326bis-39 (work in 1762 progress), January 2014. 1764 [I-D.ietf-mmusic-rtsp-nat] 1765 Goldberg, J., Westerlund, M., and T. Zeng, "A Network 1766 Address Translator (NAT) Traversal mechanism for media 1767 controlled by Real-Time Streaming Protocol (RTSP)", draft- 1768 ietf-mmusic-rtsp-nat-18 (work in progress), January 2014. 1770 [NICE] "Libnice - The GLib ICE implementation, 1771 http://nice.freedesktop.org/wiki/", May 2013. 1773 [PJNATH] "PJNATH - Open Source ICE, STUN, and TURN Library, 1774 http://www.pjsip.org/pjnath/docs/html/", May 2013. 1776 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1777 August 1980. 1779 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1780 793, September 1981. 1782 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1783 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1785 [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May 1786 1999. 1788 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1789 Translator (NAT) Terminology and Considerations", RFC 1790 2663, August 1999. 1792 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1793 Address Translator (Traditional NAT)", RFC 3022, January 1794 2001. 1796 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1797 Self-Address Fixing (UNSAF) Across Network Address 1798 Translation", RFC 3424, November 2002. 1800 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1801 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1802 Through Network Address Translators (NATs)", RFC 3489, 1803 March 2003. 1805 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1806 Jacobson, "RTP: A Transport Protocol for Real-Time 1807 Applications", STD 64, RFC 3550, July 2003. 1809 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1810 Description Protocol", RFC 4566, July 2006. 1812 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1813 and RTP Control Protocol (RTCP) Packets over Connection- 1814 Oriented Transport", RFC 4571, July 2006. 1816 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1817 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1818 RFC 4787, January 2007. 1820 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 1821 BCP 131, RFC 4961, July 2007. 1823 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1824 (ICE): A Protocol for Network Address Translator (NAT) 1825 Traversal for Offer/Answer Protocols", RFC 5245, April 1826 2010. 1828 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1829 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1830 RFC 5382, October 2008. 1832 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1833 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1834 October 2008. 1836 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1837 Control Packets on a Single Port", RFC 5761, April 2010. 1839 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1840 Relays around NAT (TURN): Relay Extensions to Session 1841 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1843 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 1844 around NAT (TURN) Extensions for TCP Allocations", RFC 1845 6062, November 2010. 1847 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1848 Keeping Alive the NAT Mappings Associated with RTP / RTP 1849 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 1851 [STUN-IMPL] 1852 "Open Source STUN Server and Client, 1853 http://sourceforge.net/projects/stun/", May 2013. 1855 Authors' Addresses 1857 Magnus Westerlund 1858 Ericsson 1859 Farogatan 6 1860 Stockholm SE-164 80 1861 Sweden 1863 Phone: +46 8 719 0000 1864 Email: magnus.westerlund@ericsson.com 1866 Thomas Zeng 1868 Email: thomas.zeng@gmail.com