idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-evaluation-13.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 (February 10, 2014) is 3699 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-20 -- 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: August 14, 2014 6 February 10, 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-13 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 August 14, 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 [RFC3261] based applications 587 (See section 1 and 2 of [RFC5389]). As shown above, with little 588 or no changes, the RTSP application can re-use STUN as a NAT 589 traversal solution, avoiding the pit-fall of solving a problem 590 twice. 592 o Using STUN does not require RTSP server modifications; it only 593 affects the client implementation. 595 Disadvantages: 597 o Requires a STUN server deployed in the public address space. 599 o Only works with NATs that perform endpoint independent and address 600 dependent mappings. Address and Port-Dependent filtering NATs 601 create some issues. 603 o Brittle to NATs changing the properties of the NAT mapping and 604 filtering. 606 o Does not work with port and address dependent mapping NATs without 607 server modifications. 609 o Will mostly not work if a NAT uses multiple IP addresses, since 610 RTSP servers generally require all media streams to use the same 611 IP as used in the RTSP connection to prevent becoming a DDoS tool. 613 o Interaction problems exist when a RTSP-aware ALG interferes with 614 the use of STUN for NAT traversal unless TLS secured RTSP message 615 exchange is used. 617 o Using STUN requires that RTSP servers and clients support the 618 updated RTSP specification [I-D.ietf-mmusic-rfc2326bis], because 619 it is no longer possible to guarantee that RTP and RTCP ports are 620 adjacent to each other, as required by the "client_port" and 621 "server_port" parameters in RFC2326. 623 Transition: 625 The usage of STUN can be phased out gradually as the first step of a 626 STUN capable server or client should be to check the presence of 627 NATs. The removal of STUN capability in the client implementations 628 will have to wait until there is absolutely no need to use STUN. 630 4.1.5. Security Considerations 632 To prevent the RTSP server from being used as Denial of Service (DoS) 633 attack tools the RTSP Transport header parameter "destination" and 634 "dest_addr" are generally not allowed to point to any IP address 635 other than the one the RTSP message originates from. The RTSP server 636 is only prepared to make an exception to this rule when the client is 637 trusted (e.g., through the use of a secure authentication process, or 638 through some secure method of challenging the destination to verify 639 its willingness to accept the RTP traffic). Such a restriction means 640 that STUN in general does not work for use cases where RTSP and media 641 transport go to different addresses. 643 STUN combined with destination address restricted RTSP has the same 644 security properties as the core RTSP. It is protected from being 645 used as a DoS attack tool unless the attacker has the ability to 646 spoof the TCP connection carrying RTSP messages. 648 Using STUN's support for message authentication and secure transport 649 of RTSP messages, attackers cannot modify STUN responses or RTSP 650 messages (TLS) to change media destination. This protects against 651 hijacking, however as a client can be the initiator of an attack, 652 these mechanisms cannot securely prevent RTSP servers being used as 653 DoS attack tools. 655 4.2. Server Embedded STUN 657 4.2.1. Introduction 659 This Section describes an alternative to the stand-alone STUN usage 660 in the previous section that has quite significantly different 661 behavior. 663 4.2.2. Embedding STUN in RTSP 665 This section outlines the adaptation and embedding of STUN within 666 RTSP. This enables STUN to be used to traverse any type of NAT, 667 including address and Port-Dependent mapping NATs. This would 668 require RTSP level protocol changes. 670 This NAT traversal solution has limitations: 672 1. It does not work if both RTSP client and RTSP server are behind 673 separate NATs. 675 2. The RTSP server may, for security reasons, refuse to send media 676 streams to an IP different from the IP in the client RTSP 677 requests. 679 Deviations from STUN as defined in RFC 5389: 681 1. The RTSP application must provision the client with an identity 682 and shared secret to use in the STUN authentication; 684 2. We require STUN server to be co-located on RTSP server's media 685 source ports. 687 If STUN server is co-located with RTSP server's media source port, an 688 RTSP client using RTP transport over UDP can use STUN to traverse ALL 689 types of NATs. In the case of port and address dependent mapping 690 NATs, the party on the inside of the NAT must initiate UDP traffic. 691 The STUN Binding Request, being a UDP packet itself, can serve as the 692 traffic initiating packet. Subsequently, both the STUN Binding 693 Response packets and the RTP/RTCP packets can traverse the NAT, 694 regardless of whether the RTSP server or the RTSP client is behind 695 NAT (however only one of the can be behind a NAT). 697 Likewise, if an RTSP server is behind a NAT, then an embedded STUN 698 server must be co-located on the RTSP client's RTCP port. Also it 699 will become the client that needs to disclose his destination address 700 rather than the server, so the server can correctly determine its NAT 701 external source address for the media streams. In this case, we 702 assume that the client has some means of establishing TCP connection 703 to the RTSP server behind NAT so as to exchange RTSP messages with 704 the RTSP server, potentially using a proxy or static rules. 706 To minimize delay, we require that the RTSP server supporting this 707 option must inform the client about the RTP and RTCP ports from where 708 the server will send out RTP and RTCP packets, respectively. This 709 can be done by using the "server_port" parameter in RFC2326, and the 710 "src_addr" parameter in [I-D.ietf-mmusic-rfc2326bis]. Both are in 711 the RTSP Transport header. But in general this strategy will require 712 that one first do one SETUP request per media to learn the server 713 ports, then perform the STUN checks, followed by a subsequent SETUP 714 to change the client port and destination address to what was learned 715 during the STUN checks. 717 To be certain that RTCP works correctly the RTSP end-point (server or 718 client) will be required to send and receive RTCP packets from the 719 same port. 721 4.2.3. Discussion On Co-located STUN Server 723 In order to use STUN to traverse "address and port dependent" 724 filtering or mapping NATs the STUN server needs to be co-located with 725 the streaming server media output ports. This creates a de- 726 multiplexing problem: we must be able to differentiate a STUN packet 727 from a media packet. This will be done based on heuristics. The 728 existing STUN heuristics is the first byte in the packet and the 729 Magic Cookie field (added in RFC5389), which works fine between STUN 730 and RTP or RTCP where the first byte happens to be different. Thanks 731 to the magic cookie field it is unlikely that other protocols would 732 be mistaken for a STUN packet, but not assured. 734 4.2.4. ALG considerations 736 The same ALG traversal considerations as for Stand-Alone STUN applies 737 (Section 4.1.3). 739 4.2.5. Deployment Considerations 741 For the "Embedded STUN" method the following applies: 743 Advantages: 745 o STUN is a solution first used by SIP applications. As shown 746 above, with little or no changes, RTSP application can re-use STUN 747 as a NAT traversal solution, avoiding the pit-fall of solving a 748 problem twice. 750 o STUN has built-in message authentication features, which makes it 751 more secure against hi-jacking attacks. See next section for an 752 in-depth security discussion. 754 o This solution works as long as there is only one RTSP endpoint in 755 the private address realm, regardless of the NAT's type. There 756 may even be multiple NATs (see Figure 1 in [RFC5389]). 758 o Compared to other UDP based NAT traversal methods in this 759 document, STUN requires little new protocol development (since 760 STUN is already a IETF standard), and most likely less 761 implementation effort, since open source STUN server and client 762 implementations are available [STUN-IMPL][PJNATH]. There is the 763 need to embed STUN in RTSP server and client, which require a de- 764 multiplexer between STUN packets and RTP/RTCP packets. There is 765 also a need to register the proper feature tags. 767 Disadvantages: 769 o Some extensions to the RTSP core protocol, likely signaled by RTSP 770 feature tags, must be introduced. 772 o Requires an embedded STUN server to be co-located on each of the 773 RTSP server's media protocol's ports (e.g. RTP and RTCP ports), 774 which means more processing is required to de-multiplex STUN 775 packets from media packets. For example, the de-multiplexer must 776 be able to differentiate a RTCP RR packet from a STUN packet, and 777 forward the former to the streaming server, and the latter to the 778 STUN server. 780 o Does not support use cases that require the RTSP connection and 781 the media reception to happen at different addresses, unless the 782 server's security policy is relaxed. 784 o Interaction problems exist when a RTSP ALG is not aware of STUN 785 unless TLS is used to protect the RTSP messages. 787 o Using STUN requires that RTSP servers and clients support the 788 updated RTSP specification [I-D.ietf-mmusic-rfc2326bis], and they 789 both agree to support the NAT traversal feature. 791 o Increases the setup delay with at least the amount of time it 792 takes to perform STUN message exchanges. Most likely an extra 793 SETUP sequence will be required. 795 Transition: 797 The usage of STUN can be phased out gradually as the first step of a 798 STUN capable machine can be to check the presence of NATs for the 799 presently used network connection. The removal of STUN capability in 800 the client implementations will have to wait until there is 801 absolutely no need to use STUN. 803 4.2.6. Security Considerations 805 See Stand-Alone STUN (Section 4.1.5). 807 4.3. ICE 809 4.3.1. Introduction 811 ICE (Interactive Connectivity Establishment) [RFC5245] is a 812 methodology for NAT traversal that has been developed for SIP using 813 SDP offer/answer. The basic idea is to try, in a staggered parallel 814 fashion, all possible connection addresses that an endpoint may be 815 reachable by. This allows the endpoint to use the best available UDP 816 "connection" (meaning two UDP end-points capable of reaching each 817 other). The methodology has very nice properties in that basically 818 all NAT topologies are possible to traverse. 820 Here is how ICE works at a high level. End point A collects all 821 possible addresses that can be used, including local IP addresses, 822 STUN derived addresses, TURN addresses, etc. On each local port that 823 any of these address and port pairs lead to, a STUN server is 824 installed. This STUN server only accepts STUN requests using the 825 correct authentication through the use of a username and password. 827 End-point A then sends a request to establish connectivity with end- 828 point B, which includes all possible "destinations" [RFC5245] to get 829 the media through to A. Note that each of A's local address/port 830 pairs (host candidates and server reflexive base) has a STUN server 831 co-located. B in turn provides A with all its possible destinations 832 for the different media streams. A and B then uses a STUN client to 833 try to reach all the address and port pairs specified by A from its 834 corresponding destination ports. The destinations for which the STUN 835 requests successfully complete are then indicated and one is 836 selected. 838 If B fails to get any STUN response from A, all hope is not lost. 839 Certain NAT topologies require multiple tries from both ends before 840 successful connectivity is accomplished and therefore requests are 841 retransmitted multiple times. The STUN requests may also result in 842 that more connectivity alternatives (destinations) are discovered and 843 conveyed in the STUN responses. 845 4.3.2. Using ICE in RTSP 847 The usage of ICE for RTSP requires that both client and server be 848 updated to include the ICE functionality. If both parties implement 849 the necessary functionality the following steps could provide ICE 850 support for RTSP. 852 This assumes that it is possible to establish a TCP connection for 853 the RTSP messages between the client and the server. This is not 854 trivial in scenarios where the server is located behind a NAT, and 855 may require some TCP ports be opened, or the deployment of proxies, 856 etc. 858 The negotiation of ICE in RTSP of necessity will work different than 859 in SIP with SDP offer/answer. The protocol interactions are 860 different and thus the possibilities for transfer of states are also 861 somewhat different. The goal is also to avoid introducing extra 862 delay in the setup process at least for when the server is using a 863 public address and the client is either having a public address or is 864 behind NAT(s). This process is only intended to support PLAY mode, 865 i.e. media traffic flows from server to client. 867 1. The ICE usage begins in the SDP. The SDP for the service 868 indicates that ICE is supported at the server. No candidates can 869 be given here as that would not work with the on demand, DNS load 870 balancing, etc., that have the SDP indicate a resource on a 871 server park rather than a specific machine. 873 2. The client gathers addresses and puts together its candidates for 874 each media stream indicated in the session description. 876 3. In each SETUP request the client includes its candidates in an 877 ICE specific transport specification. This indicates for the 878 server the ICE support by the client. One candidate is the most 879 prioritized candidate and here the prioritization for this 880 address should be somewhat different compared to SIP. High 881 performance rather than always successful is recommended, as it 882 is most likely to be a server in the public. 884 4. The server responds to the SETUP (200 OK) for each media stream 885 with its candidates. A server with a public address usually only 886 provides a single ICE candidate. Also here one candidate is the 887 server primary address. 889 5. The connectivity checks are performed. For the server the 890 connectivity checks from the server to the clients have an 891 additional usage. They verify that there is someone willing to 892 receive the media, thus preventing the server from unknowingly 893 performing a DoS attack. 895 6. Connectivity checks from the client promoting a candidate pair 896 were successful. Thus no further SETUP requests are necessary 897 and processing can proceed with step 7. If another address than 898 the primary has been verified by the client to work, that address 899 may then be promoted for usage in a SETUP request (Go to 7). If 900 the checks for the available candidates failed and if further 901 candidates have been derived during the connectivity checks, then 902 those can be signalled in new candidate lines in a SETUP request 903 updating the list (Go to 5). 905 7. Client issues PLAY request. If the server also has completed its 906 connectivity checks for the promoted candidate pair (based on 907 username as it may be derived addresses if the client was behind 908 NAT) then it can directly answer 200 OK (Go to 8). If the 909 connectivity check has not yet completed it responds with a 1xx 910 code to indicate that it is verifying the connectivity. If that 911 fails within the set timeout, an error is reported back. Client 912 needs to go back to 6. 914 8. Process completed and media can be delivered. ICE candidates not 915 used may be released. 917 To keep media paths alive the client needs to periodically send data 918 to the server. This will be realized with STUN. RTCP sent by the 919 client should be able to keep RTCP open but STUN will also be used 920 based on the same motivations as for ICE for SIP. 922 4.3.3. Implementation burden of ICE 924 The usage of ICE will require that a number of new protocols and new 925 RTSP/SDP features be implemented. This makes ICE the solution that 926 has the largest impact on client and server implementations amongst 927 all the NAT/Firewall traversal methods in this document. 929 RTSP server implementation requirements are: 931 o STUN server features 933 o Limited STUN client features 935 o SDP generation with more parameters. 937 o RTSP error code for ICE extension 939 RTSP client implementation requirements are: 941 o Limited STUN server features 943 o Limited STUN client features 945 o RTSP error code and ICE extension 947 4.3.4. Deployment Considerations 949 Advantages: 951 o Solves NAT connectivity discovery for basically all cases as long 952 as a TCP connection between the client and server can be 953 established. This includes servers behind NATs. (Note that a 954 proxy between address domains may be required to get TCP through). 956 o Improves defenses against DDoS attacks, since a media receiving 957 client requires authentications, via STUN on its media reception 958 ports. 960 Disadvantages: 962 o Increases the setup delay with at least the amount of time it 963 takes for the server to perform its STUN requests. 965 o Assumes that it is possible to de-multiplex between the packets of 966 the media protocol and STUN packets. 968 o Has fairly high implementation burden put on both RTSP server and 969 client. However, several Open Source ICE implementations do 970 exist, such as [NICE][PJNATH]. 972 4.3.5. Security Consideration 974 One should review the security consideration section of ICE and STUN 975 to understand that ICE contains some potential issues. However these 976 can be avoided by correctly using ICE in RTSP. In fact ICE does help 977 avoid the DDoS attack issue with RTSP substantially as it reduces the 978 possibility for a DDoS using RTSP servers to attackers that are on- 979 path between the RTSP server and the target and capable of 980 intercepting the STUN connectivity check packets and correctly send a 981 response to the server. 983 4.4. Latching 985 4.4.1. Introduction 987 Latching [I-D.ietf-mmusic-latching] is a NAT traversal solution that 988 is based on requiring RTSP clients to send UDP packets to the 989 server's media output ports. Conventionally, RTSP servers send RTP 990 packets in one direction: from server to client. Latching is similar 991 to connection-oriented traffic, where one side (e.g., the RTSP 992 client) first "connects" by sending a RTP packet to the other side's 993 RTP port, the recipient then replies to the originating IP and port. 994 This method is also referred to as "Late binding". It requires that 995 all RTP/RTCP transport is done symmetrical, i.e. Symmetric RTP 996 [RFC4961]. 998 Specifically, when the RTSP server receives the latching packet 999 (a.k.a. hole-punching packet, since it is used to punch a hole in the 1000 Firewall/NAT and to aid the server for port binding and address 1001 mapping) from its client, it copies the source IP and Port number and 1002 uses them as delivery address for media packets. By having the 1003 server send media traffic back the same way as the client's packet 1004 are sent to the server, address mappings will be honored. Therefore 1005 this technique works for all types of NATs, given that the server is 1006 not behind a NAT. However, it does require server modifications. 1007 Unless there is built-in protection mechanism, latching is very 1008 vulnerable to both hijacking and becoming a tool in Distributed 1009 Denail of Service (DDoS) attacks (See Security Considerations of 1010 [I-D.ietf-mmusic-latching]), because attackers can simply forge the 1011 source IP & Port of the latching packet. Using the rule for 1012 restricting IP address to the one of the signaling connection will 1013 need to be applied here also. However, that does not protect against 1014 hijacking from another client behind the same NAT. This can become a 1015 serious issue in deployments with CGNs. 1017 4.4.2. Necessary RTSP extensions 1019 To support Latching, the RTSP signaling must be extended to allow the 1020 RTSP client to indicate that it will use Latching. The client also 1021 needs to be able to signal its RTP SSRC to the server in its SETUP 1022 request. The RTP SSRC is used to establish some basic level of 1023 security against hijacking attacks or simply avoid mis-association 1024 when multiple clients are behind the same NAT. Care must be taken in 1025 choosing clients' RTP SSRC. First, it must be unique within all the 1026 RTP sessions belonging to the same RTSP session. Secondly, if the 1027 RTSP server is sending out media packets to multiple clients from the 1028 same send port, the RTP SSRC needs to be unique amongst those 1029 clients' RTP sessions. Recognizing that there is a potential that 1030 RTP SSRC collisions may occur, the RTSP server must be able to signal 1031 to a client that a collision has occurred and that it wants the 1032 client to use a different RTP SSRC carried in the SETUP response or 1033 use unique ports per RTSP session. Using unique ports limits an RTSP 1034 server in the number of sessions it can simultaneously handle per 1035 interface IP addresses. 1037 4.4.3. Deployment Considerations 1039 Advantages: 1041 o Works for all types of client-facing NATs. (Requirement 1 in 1042 Section 3). 1044 o Has no interaction problems with any RTSP ALG changing the 1045 client's information in the transport header. 1047 Disadvantages: 1049 o Requires modifications to both RTSP server and client. 1051 o Limited to work with servers that have an public IP address. 1053 o The format of the RTP packet for "connection setup" (a.k.a 1054 Latching packet) is yet to be defined. One possibility is to use 1055 RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op]. 1057 o SSRC management if RTP is used for latching due to risk for mis- 1058 association of clients to RTSP sessions at the server if SSRC 1059 collision occurs. 1061 o Has significant security considerations (See Section 4.4.4), due 1062 to lack of a strong authentication mechanism and will need to use 1063 address restrictions. 1065 4.4.4. Security Consideration 1067 Latching's major security issue is that RTP streams can be hijacked 1068 and directed towards any target that the attacker desires unless 1069 address restrictions are used. In the case of NATs with multiple 1070 clients on the inside of them, hijacking can still occur. This 1071 becomes a significant threat in the context of carrier grade NATs 1072 (CGN). 1074 The most serious security problem is the deliberate attack with the 1075 use of a RTSP client and Latching. The attacker uses RTSP to setup a 1076 media session. Then it uses Latching with a spoofed source address 1077 of the intended target of the attack. There is no defense against 1078 this attack other than restricting the possible address a latching 1079 packet can come from to the same as the RTSP TCP connection are from. 1080 This prevents Latching to be used in use cases that require different 1081 addresses for media destination and signalling. Even allowing only a 1082 limited address range containing the signalling address from where 1083 latching is allowed opens up a significant vulnerability as it is 1084 difficult to determine the address usage for the network the client 1085 connects from. 1087 A hijack attack can also be performed in various ways. The basic 1088 attack is based on the ability to read the RTSP signaling packets in 1089 order to learn the address and port the server will send from and 1090 also the SSRC the client will use. Having this information the 1091 attacker can send its own Latching packets containing the correct RTP 1092 SSRC to the correct address and port on the server. The RTSP server 1093 will then use the source IP and port from the Latching packet as the 1094 destination for the media packets it sends. 1096 Another variation of this attack is for a man in the middle to modify 1097 the RTP latching packet being sent by a client to the server by 1098 simply changing the source IP to the target one desires to attack. 1100 One can fend off the snooping based attack by applying encryption to 1101 the RTSP signaling transport. However, if the attacker is a man in 1102 the middle modifying latching packets, the attack is impossible to 1103 defend against other than through address restrictions. As a NAT re- 1104 writes the source IP and (possibly) port this cannot be 1105 authenticated, but authentication is required in order to protect 1106 against this type of DoS attack. 1108 Yet another issue is that these attacks also can be used to deny the 1109 client the service it desires from the RTSP server completely. The 1110 attacker modifies or originates its own latching packets with another 1111 port than what the legit latching packets uses, which results in that 1112 the media server sends the RTP/RTCP traffic to ports the client isn't 1113 listening for RTP/RTCP on. 1115 The amount of random non-guessable material in the latching packet 1116 determines how well Latching can fend off stream-hijacking performed 1117 by parties that are off the client to server network path, i.e. lacks 1118 the capability to see the client's latching packets. This proposal 1119 uses the 32-bit RTP SSRC field to this effect. Therefore it is 1120 important that this field is derived with a non-predictable random 1121 number generator. It should not be possible by knowing the algorithm 1122 used and a couple of basic facts, to derive what random number a 1123 certain client will use. 1125 An attacker not knowing the SSRC but aware of which port numbers that 1126 a server sends from can deploy a brute force attack on the server by 1127 testing a lot of different SSRCs until it finds a matching one. 1128 Therefore a server could implement functionality that blocks packets 1129 to ports or from sources that receive or send multiple Latching 1130 packets with different invalid SSRCs, especially when they are coming 1131 from the same IP/Port. Note that this mitigation in itself opens up 1132 a new venue for DoS attacks against legit users trying to latch. 1134 To improve the security against attackers the amount of random 1135 material could be increased. To achieve a longer random tag while 1136 still using RTP and RTCP, it will be necessary to develop RTP and 1137 RTCP payload formats for carrying the random material. 1139 4.5. A Variation to Latching 1141 4.5.1. Introduction 1143 Latching as described above requires the usage of a valid RTP format 1144 as the Latching packet, i.e. the first packet that the client sends 1145 to the server to set up virtual RTP connection. There is currently 1146 no appropriate RTP packet format for this purpose, although the RTP 1147 No-Op format was a proposal to fix the problem 1148 [I-D.ietf-avt-rtp-no-op], however, that work was abandoned. There 1149 exists a RFC that discusses the implication of different type of 1150 packets as keep-alives for RTP [RFC6263] and its findings are very 1151 relevant to the format of the Latching packet. 1153 Meanwhile, there has been NAT/Firewall traversal techniques deployed 1154 in the wireless streaming market place that use non-RTP messages as 1155 Latching packets. This section describes a variant based on a subset 1156 of those solutions that alters the previously described Latching 1157 solution. 1159 4.5.2. Necessary RTSP extensions 1161 In this variation of Latching, the Latching packet is a small UDP 1162 packet that does not contain an RTP header. In response to the 1163 client's Latching packet, the RTSP server sends back a similar 1164 Latching packet as a confirmation so the client can stop the so 1165 called "connection phase" of this NAT traversal technique. 1166 Afterwards, the client only has to periodically send Latching packets 1167 as keep-alive messages for the NAT mappings. 1169 The server listens on its RTP-media output port, and tries to decode 1170 any received UDP packet as Latching packet. This is valid since an 1171 RTSP server is not expecting RTP traffic from the RTSP client. Then, 1172 it can correlate the Latching packet with the RTSP client's session 1173 ID or the client's SSRC, and record the NAT bindings accordingly. 1174 The server then sends a Latching packet as the response to the 1175 client. 1177 The Latching packet can contain the SSRC to identify the RTP stream, 1178 and care must be taken if the packet is bigger than 12 bytes, 1179 ensuring that it is distinctively different from RTP packets, whose 1180 header size is 12 bytes. 1182 RTSP signaling can be added to do the following: 1184 1. Enable or disable such Latching message exchanges. When the 1185 Firewall/NAT has an RTSP-aware ALG, it is possible to disable 1186 Latching message exchange and let the ALG work out the address 1187 and port mappings. 1189 2. Configure the number of re-tries and the re-try interval of the 1190 Latching message exchanges. 1192 4.5.3. Deployment Considerations 1194 This approach has the following advantages when compared with the 1195 Latching approach (Section 4.4): 1197 1. There is no need to define RTP payload format for Firewall 1198 traversal, therefore it is simple to use, implement and 1199 administer (Requirement 4 in Section 3), instead a Latching 1200 protocol must be defined. 1202 2. When properly defined, this kind of Latching packet exchange can 1203 also authenticate RTP receivers, to prevent hijacking attacks. 1205 This approach has the following disadvantages when compared with the 1206 Latching approach: 1208 1. RTP traffic is normally accompanied by RTCP traffic. This 1209 approach needs to rely on RTCP RRs and SRs to enable NAT 1210 traversal for RTCP endpoints, use RTP/RTCP Multiplexing 1211 [RFC5761], or use the same type of Latching packets also for RTCP 1212 endpoints. 1214 2. The server's sender SSRC for the RTP stream or other session 1215 Identity information must be signaled in RTSP's SETUP response, 1216 in the Transport header of the RTSP SETUP response. 1218 4.5.4. Security Considerations 1220 Compared to the security properties of Latching this variant is 1221 slightly improved. First of all it allows for a larger random field 1222 in the Latching packets which makes it more unlikely for an off-path 1223 attacker to succeed in a hi-jack attack. Secondly the confirmation 1224 allows the client to know when Latching works and when it didn't and 1225 thus restart the Latching process by updating the SSRC. Thirdly if 1226 an authentication mechanism is included in the latching packet 1227 hijacking attacks can be prevented. 1229 Still the main security issue remain that the RTSP server can't know 1230 that the source address in the latching packet was coming from a RTSP 1231 client wanting to receive media and not one that likes to direct the 1232 media traffic to an DoS target. 1234 4.6. Three Way Latching 1236 4.6.1. Introduction 1238 The three way Latching is an attempt to try to resolve the most 1239 significant security issues for both previously discussed variants of 1240 Latching. By adding a server request response exchange directly 1241 after the initial latching the server can verify that the target 1242 address present in the latching packet is an active listener and 1243 confirm its desire to establish a media flow. 1245 4.6.2. Necessary RTSP extensions 1247 Uses the same RTSP extensions as the alternative latching method 1248 (Section 4.5) uses. The extensions for this variant are only in the 1249 format and transmission of the Latching packets. 1251 The client to server latching packet is similar to the Alternative 1252 Latching (Section 4.5), i.e. an UDP packet with some session 1253 identifier and a random value. When the server responds to the 1254 Latching packet with a Latching confirmation, it includes a random 1255 value (Nonce) of its own in addition to echoing back the one the 1256 client sent. Then a third message is added to the exchange. The 1257 client acknowledges the reception of the Latching confirmation 1258 message and echoes back the server's nonce. Thus confirming that the 1259 Latched address goes to a RTSP client that initiated the latching and 1260 is actually present at that address. The RTSP server will refuse to 1261 send any media until the Latching Acknowledgement has been received 1262 with a valid nonce. 1264 4.6.3. Deployment Considerations 1266 A solution with a 3-way handshake and its own Latching packets can be 1267 compared with the ICE-based solution (Section 4.3) and have the 1268 following differences: 1270 o Only works for servers with public IP addresses compared to any 1271 type of server 1273 o May be simpler to implement due to the avoidance of the ICE 1274 prioritization and check-board mechanisms. 1276 However, a 3-way Latching protocol is very similar to using STUN in 1277 both directions as Latching and verification protocol. Using STUN 1278 would remove the need for implementing a new protocol. 1280 4.7. Application Level Gateways 1282 4.7.1. Introduction 1284 An Application Level Gateway (ALG) reads the application level 1285 messages and performs necessary changes to allow the protocol to work 1286 through the middle box. However this behavior has some problems in 1287 regards to RTSP: 1289 1. It does not work when the RTSP protocol is used with end-to-end 1290 security. As the ALG can't inspect and change the application 1291 level messages the protocol will fail due to the middle box. 1293 2. ALGs need to be updated if extensions to the protocol are added. 1294 Due to deployment issues with changing ALGs this may also break 1295 the end-to-end functionality of RTSP. 1297 Due to the above reasons it is not recommended to use an RTSP ALG in 1298 NATs. This is especially important for NATs targeted to home users 1299 and small office environments, since it is very hard to upgrade NATs 1300 deployed in home or SOHO (small office/home office) environment. 1302 4.7.2. Outline On how ALGs for RTSP work 1304 In this section, we provide a step-by-step outline on how one could 1305 go about writing an ALG to enable RTSP to traverse a NAT. 1307 1. Detect any SETUP request. 1309 2. Try to detect the usage of any of the NAT traversal methods that 1310 replace the address and port of the Transport header parameters 1311 "destination" or "dest_addr". If any of these methods are used, 1312 then the ALG should not change the address. Ways to detect that 1313 these methods are used are: 1315 * For embedded STUN, it would be to watch for a feature tag, 1316 like "nat.stun". If any of those exists in the "supported", 1317 "proxy-require", or "require" headers of the RTSP exchange. 1319 * For stand alone STUN and TURN based solutions: This can be 1320 detected by inspecting the "destination" or "dest_addr" 1321 parameter. If it contains either one of the NAT's external IP 1322 addresses or a public IP address then such a solution is in 1323 use. However if multiple NATs are used this detection may 1324 fail. Remapping should only be done for addresses belonging 1325 to the NAT's own private address space. 1327 Otherwise continue to the next step. 1329 3. Create UDP mappings (client given IP/port <-> external IP/port) 1330 where needed for all possible transport specifications in the 1331 transport header of the request found in (1). Enter the external 1332 address and port(s) of these mappings in transport header. 1333 Mappings shall be created with consecutive public port numbers 1334 starting on an even number for RTP for each media stream. 1335 Mappings should also be given a long timeout period, at least 5 1336 minutes. 1338 4. When the SETUP response is received from the server, the ALG may 1339 remove the unused UDP mappings, i.e. the ones not present in the 1340 transport header. The session ID should also be bound to the UDP 1341 mappings part of that session. 1343 5. If SETUP response settles on RTP over TCP or RTP over RTSP as 1344 lower transport, do nothing: let TCP tunneling take care of NAT 1345 traversal. Otherwise go to next step. 1347 6. The ALG should keep the UDP mappings belonging to the RTSP 1348 session as long as: an RTSP message with the session's ID has 1349 been sent in the last timeout interval, or a UDP message has been 1350 sent on any of the UDP mappings during the last timeout interval. 1352 7. The ALG may remove a mapping as soon a TEARDOWN response has been 1353 received for that media stream. 1355 4.7.3. Deployment Considerations 1357 Advantage: 1359 o No impact on either client or server 1361 o Can work for any type of NATs 1363 Disadvantage: 1365 o When deployed they are hard to update to reflect protocol 1366 modifications and extensions. If not updated they will break the 1367 functionality. 1369 o When end-to-end security is used, the ALG functionality will fail. 1371 o Can interfere with other types of traversal mechanisms, such as 1372 STUN. 1374 Transition: 1376 An RTSP ALG will not be phased out in any automatic way. It must be 1377 removed, probably through the removal of the NAT it is associated 1378 with. 1380 4.7.4. Security Considerations 1382 An ALG will not work with deployment of end-to-end RTSP signaling 1383 security. Therefore deployment of ALG will likely result in clients 1384 located behind NATs not using end-to-end security. 1386 The creation of an UDP mapping based on the signalling message has 1387 some potential security implications. First of all if the RTSP 1388 client releases its ports and another application are assigned these 1389 instead it could receive RTP media as long as the mappings exist and 1390 the RTSP server has failed to be signalled or notice the lack of 1391 client response. 1393 A NAT with RTSP ALG that assigns mappings based on SETUP requests 1394 could potentially become victim of a resource exhaustion attack. If 1395 an attacker creates a lot of RTSP sessions, even without starting 1396 media transmission could exhaust the pool of available UDP ports on 1397 the NAT. Thus only a limited number of UDP mappings should be 1398 allowed to be created by the RTSP ALG. 1400 4.8. TCP Tunneling 1402 4.8.1. Introduction 1404 Using a TCP connection that is established from the client to the 1405 server ensures that the server can send data to the client. The 1406 connection opened from the private domain ensures that the server can 1407 send data back to the client. To send data originally intended to be 1408 transported over UDP requires the TCP connection to support some type 1409 of framing of the media data packets. Using TCP also results in the 1410 client having to accept that real-time performance can be impacted. 1411 TCP's problem of ensuring timely delivery was one of the reasons why 1412 RTP was developed. Problems that arise with TCP are: head-of-line 1413 blocking, delay introduced by retransmissions, highly varying rate 1414 due to the congestion control algorithm. If sufficient amount of 1415 buffering (several seconds) in the receiving client can be tolerated 1416 then TCP clearly can work. 1418 4.8.2. Usage of TCP tunneling in RTSP 1420 The RTSP core specification [I-D.ietf-mmusic-rfc2326bis] supports 1421 interleaving of media data on the TCP connection that carries RTSP 1422 signaling. See section 14 in [I-D.ietf-mmusic-rfc2326bis] for how to 1423 perform this type of TCP tunneling. There also exists another way of 1424 transporting RTP over TCP defined in Appendix C.2 in 1425 [I-D.ietf-mmusic-rfc2326bis]. For signaling and rules on how to 1426 establish the TCP connection in lieu of UDP, see appendix C.2 in 1427 [I-D.ietf-mmusic-rfc2326bis]. This is based on the framing of RTP 1428 over the TCP connection as described in RFC 4571 [RFC4571]. 1430 4.8.3. Deployment Considerations 1432 Advantage: 1434 o Works through all types of NATs where the RTSP server in not NATed 1435 or at least reachable like it was not. 1437 Disadvantage: 1439 o Functionality needs to be implemented on both server and client. 1441 o Will not always meet multimedia stream's real-time requirements. 1443 Transition: 1445 The tunneling over RTSP's TCP connection is not planned to be phased- 1446 out. It is intended to be a fallback mechanism and for usage when 1447 total media reliability is desired, even at the potential price of 1448 loss of real-time properties. 1450 4.8.4. Security Considerations 1452 The TCP tunneling of RTP has no known security problems besides those 1453 already presented in the RTSP specification. It is not possible to 1454 get any amplification effect for denial of service attacks due to 1455 TCP's flow control. A possible security consideration, when session 1456 media data is interleaved with RTSP, would be the performance 1457 bottleneck when RTSP encryption is applied, since all session media 1458 data also needs to be encrypted. 1460 4.9. TURN (Traversal Using Relay NAT) 1462 4.9.1. Introduction 1464 Traversal Using Relay NAT (TURN) [RFC5766] is a protocol for setting 1465 up traffic relays that allow clients behind NATs and firewalls to 1466 receive incoming traffic for both UDP and TCP. These relays are 1467 controlled and have limited resources. They need to be allocated 1468 before usage. TURN allows a client to temporarily bind an address/ 1469 port pair on the relay (TURN server) to its local source address/port 1470 pair, which is used to contact the TURN server. The TURN server will 1471 then forward packets between the two sides of the relay. 1473 To prevent DoS attacks on either recipient, the packets forwarded are 1474 restricted to the specific source address. On the client side it is 1475 restricted to the source setting up the allocation. On the external 1476 side this is limited to the source address/port pair that have been 1477 given permission by the TURN client creating the allocation. Packets 1478 from any other source on this address will be discarded. 1480 Using a TURN server makes it possible for a RTSP client to receive 1481 media streams from even an unmodified RTSP server. However the 1482 problem is those RTSP servers most likely restrict media destinations 1483 to no other IP address than the one the RTSP message arrives from. 1484 This means that TURN could only be used if the server knows and 1485 accepts that the IP belongs to a TURN server and the TURN server 1486 can't be targeted at an unknown address or also the RTSP connection 1487 is relayed through the same TURN server. 1489 4.9.2. Usage of TURN with RTSP 1491 To use a TURN server for NAT traversal, the following steps should be 1492 performed. 1494 1. The RTSP client connects with the RTSP server. The client 1495 retrieves the session description to determine the number of 1496 media streams. To avoid the issue with having RTSP connection 1497 and media traffic from different addresses also the TCP 1498 connection must be done through the same TURN server as the one 1499 in the next step. This will require the usage of TURN for TCP 1500 [RFC6062]. 1502 2. The client establishes the necessary bindings on the TURN server. 1503 It must choose the local RTP and RTCP ports that it desires to 1504 receive media packets. TURN supports requesting bindings of even 1505 port numbers and contiguous ranges. 1507 3. The RTSP client uses the acquired address and port allocations in 1508 the RTSP SETUP request using the destination header. 1510 4. The RTSP Server sends the SETUP reply, which must include the 1511 transport headers src_addr parameter (source and port in RTSP 1512 1.0). Note that the server is required to have a mechanism to 1513 verify that it is allowed to send media traffic to the given 1514 address. 1516 5. The RTSP Client uses the RTSP Server's response to create TURN 1517 permissions for the server's media traffic. 1519 6. The client requests that the server starts playing. The server 1520 starts sending media packets to the given destination address and 1521 ports. 1523 7. Media packets arrive at the TURN server on the external port; If 1524 the packets match an established permission, the TURN server 1525 forwards the media packets to the RTSP client. 1527 8. If the client pauses and media is not sent for about 75% of the 1528 mapping timeout the client should use TURN to refresh the 1529 bindings. 1531 4.9.3. Deployment Considerations 1533 Advantages: 1535 o Does not require any server modifications given that the server 1536 includes the src_addr header in the SETUP response. 1538 o Works for any type of NAT as long as the RTSP server has public 1539 reachable IP address. 1541 Disadvantage: 1543 o Requires another network element, namely the TURN server. 1545 o A TURN server for RTSP may not scale since the number of sessions 1546 it must forward is proportional to the number of client media 1547 sessions. 1549 o TURN server becomes a single point of failure. 1551 o Since TURN forwards media packets, it necessarily introduces 1552 delay. 1554 o An RTSP ALG may change the necessary destinations parameter. This 1555 will cause the media traffic to be sent to the wrong address. 1557 Transition: 1559 TURN is not intended to be phased-out completely, see Section 19 of 1560 [RFC5766]. However the usage of TURN could be reduced when the 1561 demand for having NAT traversal is reduced. 1563 4.9.4. Security Considerations 1565 The TURN server can become part of a denial of service attack towards 1566 any victim. To perform this attack the attacker must be able to 1567 eavesdrop on the packets from the TURN server towards a target for 1568 the DoS attack. The attacker uses the TURN server to setup a RTSP 1569 session with media flows going through the TURN server. The attacker 1570 is in fact creating TURN mappings towards a target by spoofing the 1571 source address of TURN requests. As the attacker will need the 1572 address of these mappings he must be able to eavesdrop or intercept 1573 the TURN responses going from the TURN server to the target. Having 1574 these addresses, he can set up a RTSP session and start delivery of 1575 the media. The attacker must be able to create these mappings. The 1576 attacker in this case may be traced by the TURN username in the 1577 mapping requests. 1579 This attack requires that the attacker has access to a user account 1580 on the TURN server to be able set up the TURN mappings. To prevent 1581 this attack the RTSP server needs to verify that the ultimate target 1582 destination accept this media stream. Which would require something 1583 like ICE's connectivity checks being run between the RTSP server and 1584 the RTSP client. 1586 5. Firewalls 1588 Firewalls exist for the purpose of protecting a network from traffic 1589 not desired by the firewall owner. Therefore it is a policy decision 1590 if a firewall will let RTSP and its media streams through or not. 1591 RTSP is designed to be firewall friendly in that it should be easy to 1592 design firewall policies to permit passage of RTSP traffic and its 1593 media streams. 1595 The firewall will need to allow the media streams associated with a 1596 RTSP session to pass through it. Therefore the firewall will need an 1597 ALG that reads RTSP SETUP and TEARDOWN messages. By reading the 1598 SETUP message the firewall can determine what type of transport and 1599 from where, the media stream packets will be sent. Commonly there 1600 will be the need to open UDP ports for RTP/RTCP. By looking at the 1601 source and destination addresses and ports the opening in the 1602 firewall can be minimized to the least necessary. The opening in the 1603 firewall can be closed after a TEARDOWN message for that session or 1604 the session itself times out. 1606 Simpler firewalls do allow a client to receive media as long as it 1607 has sent packets to the target. Depending on the security level this 1608 can have the same behavior as a NAT. The only difference is that no 1609 address translation is done. To use such a firewall a client would 1610 need to implement one of the above described NAT traversal methods 1611 that include sending packets to the server to open up the mappings. 1613 6. Comparison of NAT traversal techniques 1615 This section evaluates the techniques described above against the 1616 requirements listed in Section 3. 1618 In the following table, the columns correspond to the numbered 1619 requirements. For instance, the column under R1 corresponds to the 1620 first requirement in Section 3: must work for all flavors of NATs. 1621 The rows represent the different NAT/Firewall traversal techniques. 1622 Latch is short for Latching, "V. Latch" is short for "variation of 1623 Latching" as described in Section 4.5. "3-W Latch" is short for the 1624 Three Way Latching described in Section 4.6. 1626 A Summary of the requirements are: 1628 R1: Work for all flavors of NATs 1630 R2: Must work with Firewalls, including those with ALGs 1632 R3: Should have minimal impact on clients not behind NATs, counted 1633 in minimal number of additional RTTs 1635 R4: Should be simple to use, Implement and administer. 1637 R5: Should provide mitigation against DDoS attacks 1639 The following considerations are also added to requirements: 1641 C1: Will solution support both Clients and Servers behind NAT 1643 C2: Is the solution robust to changing NAT behaviors 1645 ------------+------+------+------+------+------+------+------+ 1646 | R1 | R2 | R3 | R4 | R5 | C1 | C2 | 1647 ------------+------+------+------+------+------+------+------+ 1648 STUN | No | Yes | 1 | Maybe| No | No | No | 1649 ------------+------+------+------+------+------+------+------+ 1650 Emb. STUN | Yes | Yes | 2 | Maybe| No | No | Yes | 1651 ------------+------+------+------+------+------+------+------+ 1652 ICE | Yes | Yes | 2.5 | No | Yes | Yes | Yes | 1653 ------------+------+------+------+------+------+------+------+ 1654 Latch | Yes | Yes | 1 | Maybe| No | No | Yes | 1655 ------------+------+------+------+------+------+------+------+ 1656 V. Latch | Yes | Yes | 1 | Yes | No | No | Yes | 1657 ------------+------+------+------+------+------+------+------+ 1658 3-W Latch | Yes | Yes | 1.5 | Maybe| Yes | No | Yes | 1659 ------------+------+------+------+------+------+------+------+ 1660 ALG |(Yes) | Yes | 0 | No | Yes | No | Yes | 1661 ------------+------+------+------+------+------+------+------+ 1662 TCP Tunnel | Yes | Yes | 1.5 | Yes | Yes | No | Yes | 1663 ------------+------+------+------+------+------+------+------+ 1664 TURN | Yes | Yes | 1 | No | Yes |(Yes) | Yes | 1665 ------------+------+------+------+------+------+------+------+ 1667 Figure 1: Comparison of fulfillment of requirements 1669 Looking at Figure 1 one would draw the conclusion that using TCP 1670 Tunneling or Three-Way Latching is the solutions that best fulfill 1671 the requirements. The different techniques were discussed in the 1672 MMUSIC WG. It was established that the WG would pursue an ICE based 1673 solution due to its generality and capability of handling also 1674 servers delivering media from behind NATs. TCP Tunneling is likely 1675 to be available as an alternative, due to its specification in the 1676 main RTSP specification. Thus it can be used if desired and the 1677 potential downsides of using TCP is acceptable in particular 1678 deployments. When it comes to Three-Way Latching it is a very 1679 competitive technique given that you don't need support for RTSP 1680 servers behind NATs. There were some discussion in the WG if the 1681 increased implementation burden of ICE is sufficiently motivated 1682 compared to a the Three-Way Latching solution for this generality. 1684 In the end the authors believe that reuse of ICE, the greater 1685 flexibility and anyway need to deploy a new solution was the decisive 1686 factors. 1688 The ICE based RTSP NAT traversal solution is specified in "A Network 1689 Address Translator (NAT) Traversal mechanism for media controlled by 1690 Real-Time Streaming Protocol (RTSP)" [I-D.ietf-mmusic-rtsp-nat]. 1692 7. IANA Considerations 1694 This document makes no request of IANA. 1696 Note to RFC Editor: this section may be removed on publication as an 1697 RFC. 1699 8. Security Considerations 1701 In the preceding sections we have discussed security merits of the 1702 different NAT/Firewall traversal methods for RTSP discussed here. In 1703 summary, the presence of NAT(s) is a security risk, as a client 1704 cannot perform source authentication of its IP address. This 1705 prevents the deployment of any future RTSP extensions providing 1706 security against hijacking of sessions by a man-in-the-middle. 1708 Each of the proposed solutions has security implications. Using STUN 1709 will provide the same level of security as RTSP without transport 1710 level security and source authentications, as long as the server does 1711 not allow media to be sent to a different IP-address than the RTSP 1712 client request was sent from. Using Latching will have a higher risk 1713 of session hijacking or denial of service than normal RTSP. The 1714 reason is that there exists a probability that an attacker is able to 1715 guess the random bits that the client uses to prove its identity when 1716 creating the address bindings. This can be solved in the variation 1717 of Latching (Section 4.5) with authentication features. Still both 1718 those variants of Latching are vulnerable against deliberate attack 1719 from the RTSP client to redirect the media stream requested to any 1720 target assuming it can spoof the source address. This security 1721 vulnerability is solved by performing a Three-way Latching procedure 1722 as discussed in Section 4.6. The usage of an RTSP ALG does not in 1723 itself increase the risk for session hijacking. However the 1724 deployment of ALGs as the sole mechanism for RTSP NAT traversal will 1725 prevent deployment of end-to-end encrypted RTSP signaling. The usage 1726 of TCP tunneling has no known security problems. However, it might 1727 provide a bottleneck when it comes to end-to-end RTSP signaling 1728 security if TCP tunneling is used on an interleaved RTSP signaling 1729 connection. The usage of TURN has severe risk of denial of service 1730 attacks against a client. The TURN server can also be used as a 1731 redirect point in a DDoS attack unless the server has strict enough 1732 rules for who may create bindings. 1734 9. Acknowledgements 1736 The author would also like to thank all persons on the MMUSIC working 1737 group's mailing list that has commented on this document. Persons 1738 having contributed in such way in no special order to this protocol 1739 are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon, 1740 Amir Wolf, Anders Klemets, Flemming Andreasen, Ari Keranen, Bill 1741 Atwood, and Colin Perkins. Thomas Zeng would also like to give 1742 special thanks to Greg Sherwood of PacketVideo for his input into 1743 this memo. 1745 Section 1.1 contains text originally written for RFC 4787 by Francois 1746 Audet and Cullen Jennings. 1748 10. Informative References 1750 [I-D.ietf-avt-rtp-no-op] 1751 Andreasen, F., "A No-Op Payload Format for RTP", draft- 1752 ietf-avt-rtp-no-op-04 (work in progress), May 2007. 1754 [I-D.ietf-mmusic-latching] 1755 Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT 1756 Traversal (HNT) for Media in Real-Time Communication", 1757 draft-ietf-mmusic-latching-04 (work in progress), October 1758 2013. 1760 [I-D.ietf-mmusic-rfc2326bis] 1761 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1762 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1763 (RTSP)", draft-ietf-mmusic-rfc2326bis-39 (work in 1764 progress), January 2014. 1766 [I-D.ietf-mmusic-rtsp-nat] 1767 Goldberg, J., Westerlund, M., and T. Zeng, "A Network 1768 Address Translator (NAT) Traversal Mechanism for Media 1769 Controlled by Real-Time Streaming Protocol (RTSP)", draft- 1770 ietf-mmusic-rtsp-nat-20 (work in progress), February 2014. 1772 [NICE] "Libnice - The GLib ICE implementation, 1773 http://nice.freedesktop.org/wiki/", May 2013. 1775 [PJNATH] "PJNATH - Open Source ICE, STUN, and TURN Library, 1776 http://www.pjsip.org/pjnath/docs/html/", May 2013. 1778 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1779 August 1980. 1781 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1782 793, September 1981. 1784 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1785 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1787 [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May 1788 1999. 1790 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1791 Translator (NAT) Terminology and Considerations", RFC 1792 2663, August 1999. 1794 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1795 Address Translator (Traditional NAT)", RFC 3022, January 1796 2001. 1798 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1799 A., Peterson, J., Sparks, R., Handley, M., and E. 1800 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1801 June 2002. 1803 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1804 Self-Address Fixing (UNSAF) Across Network Address 1805 Translation", RFC 3424, November 2002. 1807 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1808 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1809 Through Network Address Translators (NATs)", RFC 3489, 1810 March 2003. 1812 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1813 Jacobson, "RTP: A Transport Protocol for Real-Time 1814 Applications", STD 64, RFC 3550, July 2003. 1816 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1817 Description Protocol", RFC 4566, July 2006. 1819 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1820 and RTP Control Protocol (RTCP) Packets over Connection- 1821 Oriented Transport", RFC 4571, July 2006. 1823 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1824 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1825 RFC 4787, January 2007. 1827 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 1828 BCP 131, RFC 4961, July 2007. 1830 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1831 (ICE): A Protocol for Network Address Translator (NAT) 1832 Traversal for Offer/Answer Protocols", RFC 5245, April 1833 2010. 1835 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1836 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1837 RFC 5382, October 2008. 1839 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1840 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1841 October 2008. 1843 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1844 Control Packets on a Single Port", RFC 5761, April 2010. 1846 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1847 Relays around NAT (TURN): Relay Extensions to Session 1848 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1850 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 1851 around NAT (TURN) Extensions for TCP Allocations", RFC 1852 6062, November 2010. 1854 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1855 Keeping Alive the NAT Mappings Associated with RTP / RTP 1856 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 1858 [STUN-IMPL] 1859 "Open Source STUN Server and Client, 1860 http://sourceforge.net/projects/stun/", May 2013. 1862 Authors' Addresses 1864 Magnus Westerlund 1865 Ericsson 1866 Farogatan 6 1867 Stockholm SE-164 80 1868 Sweden 1870 Phone: +46 8 719 0000 1871 Email: magnus.westerlund@ericsson.com 1872 Thomas Zeng 1874 Email: thomas.zeng@gmail.com