idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-evaluation-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 27, 2013) is 3981 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-34 == Outdated reference: A later version (-22) exists of draft-ietf-mmusic-rtsp-nat-15 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Westerlund 3 Internet-Draft Ericsson 4 Intended status: Informational T. Zeng 5 Expires: November 28, 2013 May 27, 2013 7 The Evaluation of Different Network Address Translator (NAT) Traversal 8 Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) 9 draft-ietf-mmusic-rtsp-nat-evaluation-08 11 Abstract 13 This document describes several Network Address Translator (NAT) 14 traversal techniques that were considered to be used for establishing 15 the RTP media flows controlled by the Real-time Streaming Protocol 16 (RTSP). Each technique includes a description on how it would be 17 used, the security implications of using it and any other deployment 18 considerations it has. There are also discussions on how NAT 19 traversal techniques relates to firewalls and how each technique can 20 be applied in different use cases. These findings where used when 21 selecting the NAT traversal for RTSP 2.0. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 28, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1. Network Address Translators . . . . . . . . . . . . . . . 4 71 1.2. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 5 72 1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6 73 2. Detecting the loss of NAT mappings . . . . . . . . . . . . . 7 74 3. Requirements on Solutions . . . . . . . . . . . . . . . . . . 8 75 4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . 9 76 4.1. Stand-Alone STUN . . . . . . . . . . . . . . . . . . . . 10 77 4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . 10 78 4.1.2. Using STUN to traverse NAT without server 79 modifications . . . . . . . . . . . . . . . . . . . . 10 80 4.1.3. ALG considerations . . . . . . . . . . . . . . . . . 12 81 4.1.4. Deployment Considerations . . . . . . . . . . . . . . 13 82 4.1.5. Security Considerations . . . . . . . . . . . . . . . 14 83 4.2. Server Embedded STUN . . . . . . . . . . . . . . . . . . 14 84 4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . 14 85 4.2.2. Embedding STUN in RTSP . . . . . . . . . . . . . . . 14 86 4.2.3. Discussion On Co-located STUN Server . . . . . . . . 16 87 4.2.4. ALG considerations . . . . . . . . . . . . . . . . . 16 88 4.2.5. Deployment Considerations . . . . . . . . . . . . . . 16 89 4.2.6. Security Considerations . . . . . . . . . . . . . . . 17 90 4.3. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . 17 92 4.3.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 18 93 4.3.3. Implementation burden of ICE . . . . . . . . . . . . 20 94 4.3.4. Deployment Considerations . . . . . . . . . . . . . . 20 95 4.3.5. Security Consideration . . . . . . . . . . . . . . . 21 96 4.4. Latching . . . . . . . . . . . . . . . . . . . . . . . . 21 97 4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . 21 98 4.4.2. Necessary RTSP extensions . . . . . . . . . . . . . . 22 99 4.4.3. Deployment Considerations . . . . . . . . . . . . . . 22 100 4.4.4. Security Consideration . . . . . . . . . . . . . . . 23 101 4.5. A Variation to Latching . . . . . . . . . . . . . . . . . 24 102 4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . 24 103 4.5.2. Necessary RTSP extensions . . . . . . . . . . . . . . 25 104 4.5.3. Deployment Considerations . . . . . . . . . . . . . . 25 105 4.5.4. Security Considerations . . . . . . . . . . . . . . . 26 106 4.6. Three Way Latching . . . . . . . . . . . . . . . . . . . 26 107 4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . 26 108 4.6.2. Necessary RTSP extensions . . . . . . . . . . . . . . 26 109 4.6.3. Deployment Considerations . . . . . . . . . . . . . . 27 110 4.7. Application Level Gateways . . . . . . . . . . . . . . . 27 111 4.7.1. Introduction . . . . . . . . . . . . . . . . . . . . 27 112 4.7.2. Outline On how ALGs for RTSP work . . . . . . . . . . 27 113 4.7.3. Deployment Considerations . . . . . . . . . . . . . . 29 114 4.7.4. Security Considerations . . . . . . . . . . . . . . . 29 115 4.8. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 30 116 4.8.1. Introduction . . . . . . . . . . . . . . . . . . . . 30 117 4.8.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . 30 118 4.8.3. Deployment Considerations . . . . . . . . . . . . . . 30 119 4.8.4. Security Considerations . . . . . . . . . . . . . . . 31 120 4.9. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . 31 121 4.9.1. Introduction . . . . . . . . . . . . . . . . . . . . 31 122 4.9.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 31 123 4.9.3. Deployment Considerations . . . . . . . . . . . . . . 32 124 4.9.4. Security Considerations . . . . . . . . . . . . . . . 33 125 5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 34 126 6. Comparison of NAT traversal techniques . . . . . . . . . . . 34 127 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 128 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 129 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 130 10. Informative References . . . . . . . . . . . . . . . . . . . 37 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 133 1. Introduction 135 Today there is a proliferate deployment of different flavors of 136 Network Address Translator (NAT) boxes that in many cases only 137 loosely follow standards 138 [RFC3022][RFC2663][RFC3424][RFC4787][RFC5382]. NATs cause 139 discontinuity in address realms [RFC3424], therefore an application 140 protocol, such as Real-time Streaming Protocol (RTSP) 141 [RFC2326][I-D.ietf-mmusic-rfc2326bis], needs to deal with such 142 discontinuities caused by NATs. The problem is that, being a media 143 control protocol managing one or more media streams, RTSP carries 144 network address and port information within its protocol messages. 146 Because of this, even if RTSP itself, when carried over Transmission 147 Control Protocol (TCP) [RFC0793] for example, is not blocked by NATs, 148 its media streams may be blocked by NATs. This will occur unless 149 special protocol provisions are added to support NAT-traversal. 151 Like NATs, Firewalls are also middle boxes that need to be 152 considered. Firewalls helps prevent unwanted traffic from getting in 153 or out of the protected network. RTSP is designed such that a 154 firewall can be configured to let RTSP controlled media streams go 155 through with minimal implementation effort. The minimal effort is to 156 implement an Application Level Gateway (ALG) to interpret RTSP 157 parameters. There is also a large class of firewalls, commonly home 158 firewalls, that uses a similar filtering behavior to what NAT has. 159 This type of firewalls can be handled using the same solution as 160 employed for NAT traversal instead of relying on ALGs. 162 This document describes several NAT-traversal mechanisms for RTSP 163 controlled media streaming. Many of these NAT solutions fall into 164 the category of "UNilateral Self-Address Fixing (UNSAF)" as defined 165 in [RFC3424] and quoted below: 167 "UNSAF is a process whereby some originating process attempts to 168 determine or fix the address (and port) by which it is known - e.g. 169 to be able to use address data in the protocol exchange, or to 170 advertise a public address from which it will receive connections." 172 Following the guidelines spelled out in RFC 3424, we describe the 173 required RTSP protocol extensions for each method, transition 174 strategies, and security concerns. 176 This document is capturing the evaluation done in the process to 177 recommend Firewall/NAT traversal methods for RTSP streaming servers 178 based on RFC 2326 [RFC2326] as well as the RTSP 2.0 core spec 179 [I-D.ietf-mmusic-rfc2326bis]. The evaluation is focused on NAT 180 traversal for the media streams carried over User Datagram Protocol 181 (UDP) [RFC0768] with Real-time Transport Protocol (RTP) [RFC3550] 182 over UDP being the main case for such usage. The findings should be 183 applicable to other protocols as long as they have similar 184 properties. 186 The resulting ICE-based RTSP NAT traversal mechanism is specified in 187 "A Network Address Translator (NAT) Traversal mechanism for media 188 controlled by Real-Time Streaming Protocol (RTSP)" 189 [I-D.ietf-mmusic-rtsp-nat]. 191 1.1. Network Address Translators 192 Readers are urged to refer to "IP Network Address Translator (NAT) 193 Terminology and Considerations" [RFC2663] for information on NAT 194 taxonomy and terminology. Traditional NAT is the most common type of 195 NAT device deployed. Readers may refer to "Traditional IP Network 196 Address Translator (Traditional NAT)" [RFC3022] for detailed 197 information on traditional NAT. Traditional NAT has two main 198 varieties -- Basic NAT and Network Address/Port Translator (NAPT). 200 NAPT is by far the most commonly deployed NAT device. NAPT allows 201 multiple internal hosts to share a single public IP address 202 simultaneously. When an internal host opens an outgoing TCP or UDP 203 session through a NAPT, the NAPT assigns the session a public IP 204 address and port number, so that subsequent response packets from the 205 external endpoint can be received by the NAPT, translated, and 206 forwarded to the internal host. The effect is that the NAPT 207 establishes a NAT mapping to translate the (private IP address, 208 private port number) tuple to a (public IP address, public port 209 number) tuple, and vice versa, for the duration of the session. An 210 issue of relevance to peer-to-peer applications is how the NAT 211 behaves when an internal host initiates multiple simultaneous 212 sessions from a single (private IP, private port) endpoint to 213 multiple distinct endpoints on the external network. In this 214 specification, the term "NAT" refers to both "Basic NAT" and "Network 215 Address/Port Translator (NAPT)". 217 This document uses the term "address and port mapping" as the 218 translation between an external address and port and an internal 219 address and port. Note that this is not the same as an "address 220 binding" as defined in RFC 2663. There exist a number of address and 221 port mapping behaviors described in more detail in Section 4.1 of 222 "Network Address Translation (NAT) Behavioral Requirements for 223 Unicast UDP" [RFC4787]. 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 must sit between two network administrative domains, 244 while NAT does not have to sit between two 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. The sender report carries a field telling how many packets 331 the server has sent. If that has increased and no RTP packets has 332 arrived for a few seconds it is likely the RTP mapping has been 333 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 that 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 are 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 technique. 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 recommend 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 applications. As shown 587 above, with little or no changes, the RTSP application can re-use 588 STUN as a NAT traversal solution, avoiding the pit-fall of solving 589 a problem twice. 591 o Using STUN does not require RTSP server modifications; it only 592 affects the client implementation. 594 Disadvantages: 596 o Requires a STUN server deployed in the public address space. 598 o Only works with NATs that perform endpoint independent and address 599 dependent mappings. Address and Port-Dependent filtering NATs 600 create some issues. 602 o Brittle to NATs changing the properties of the NAT mapping and 603 filtering. 605 o Does not work with port and address dependent mapping NATs without 606 server modifications. 608 o Will mostly not work if a NAT uses multiple IP addresses, since 609 RTSP servers generally require all media streams to use the same 610 IP as used in the RTSP connection to prevent becoming a DDoS tool. 612 o Interaction problems exist when a RTSP-aware ALG interferes with 613 the use of STUN for NAT traversal unless TLS secured RTSP message 614 exchange is used. 616 o Using STUN requires that RTSP servers and clients support the 617 updated RTSP specification [I-D.ietf-mmusic-rfc2326bis], because 618 it is no longer possible to guarantee that RTP and RTCP ports are 619 adjacent to each other, as required by the "client_port" and 620 "server_port" parameters in RFC2326. 622 Transition: 624 The usage of STUN can be phased out gradually as the first step of a 625 STUN capable server or client should be to check the presence of 626 NATs. The removal of STUN capability in the client implementations 627 will have to wait until there is absolutely no need to use STUN. 629 4.1.5. Security Considerations 631 To prevent the RTSP server from being used as Denial of Service (DoS) 632 attack tools the RTSP Transport header parameter "destination" and 633 "dest_addr" are generally not allowed to point to any IP address 634 other than the one the RTSP message originates from. The RTSP server 635 is only prepared to make an exception to this rule when the client is 636 trusted (e.g., through the use of a secure authentication process, or 637 through some secure method of challenging the destination to verify 638 its willingness to accept the RTP traffic). Such a restriction means 639 that STUN in general does not work for use cases where RTSP and media 640 transport go to different addresses. 642 STUN combined with destination address restricted RTSP has the same 643 security properties as the core RTSP. It is protected from being 644 used as a DoS attack tool unless the attacker has the ability to 645 spoof the TCP connection carrying RTSP messages. 647 Using STUN's support for message authentication and secure transport 648 of RTSP messages, attackers cannot modify STUN responses or RTSP 649 messages (TLS) to change media destination. This protects against 650 hijacking, however as a client can be the initiator of an attack, 651 these mechanisms cannot securely prevent RTSP servers being used as 652 DoS attack tools. 654 4.2. Server Embedded STUN 656 4.2.1. Introduction 658 This Section describes an alternative to the stand-alone STUN usage 659 in the previous section that has quite significantly different 660 behavior. 662 4.2.2. Embedding STUN in RTSP 664 This section outlines the adaptation and embedding of STUN within 665 RTSP. This enables STUN to be used to traverse any type of NAT, 666 including address and Port-Dependent mapping NATs. This would 667 require RTSP level protocol changes. 669 This NAT traversal solution has limitations: 671 1. It does not work if both RTSP client and RTSP server are behind 672 separate NATs. 674 2. The RTSP server may, for security reasons, refuse to send media 675 streams to an IP different from the IP in the client RTSP 676 requests. 678 Deviations from STUN as defined in RFC 5389: 680 1. The RTSP application must provision the client with an identity 681 and shared secret to use in the STUN authentication; 683 2. We require STUN server to be co-located on RTSP server's media 684 source ports. 686 If STUN server is co-located with RTSP server's media source port, an 687 RTSP client using RTP transport over UDP can use STUN to traverse ALL 688 types of NATs. In the case of port and address dependent mapping 689 NATs, the party on the inside of the NAT must initiate UDP traffic. 690 The STUN Binding Request, being a UDP packet itself, can serve as the 691 traffic initiating packet. Subsequently, both the STUN Binding 692 Response packets and the RTP/RTCP packets can traverse the NAT, 693 regardless of whether the RTSP server or the RTSP client is behind 694 NAT (however only one of the can be behind a NAT). 696 Likewise, if an RTSP server is behind a NAT, then an embedded STUN 697 server must be co-located on the RTSP client's RTCP port. Also it 698 will become the client that needs to disclose his destination address 699 rather than the server, so the server can correctly determine its NAT 700 external source address for the media streams. In this case, we 701 assume that the client has some means of establishing TCP connection 702 to the RTSP server behind NAT so as to exchange RTSP messages with 703 the RTSP server, potentially using a proxy or static rules. 705 To minimize delay, we require that the RTSP server supporting this 706 option must inform the client about the RTP and RTCP ports from where 707 the server will send out RTP and RTCP packets, respectively. This 708 can be done by using the "server_port" parameter in RFC2326, and the 709 "src_addr" parameter in [I-D.ietf-mmusic-rfc2326bis]. Both are in 710 the RTSP Transport header. But in general this strategy will require 711 that one first do one SETUP request per media to learn the server 712 ports, then perform the STUN checks, followed by a subsequent SETUP 713 to change the client port and destination address to what was learned 714 during the STUN checks. 716 To be certain that RTCP works correctly the RTSP end-point (server or 717 client) will be required to send and receive RTCP packets from the 718 same port. 720 4.2.3. Discussion On Co-located STUN Server 722 In order to use STUN to traverse "address and port dependent" 723 filtering or mapping NATs the STUN server needs to be co-located with 724 the streaming server media output ports. This creates a de- 725 multiplexing problem: we must be able to differentiate a STUN packet 726 from a media packet. This will be done based on heuristics. The 727 existing STUN heuristics is the first byte in the packet and the 728 Magic Cookie field (added in RFC5389), which works fine between STUN 729 and RTP or RTCP where the first byte happens to be different. Thanks 730 to the magic cookie field it is unlikely that other protocols would 731 be mistaken for a STUN packet, but not assured. 733 4.2.4. ALG considerations 735 The same ALG traversal considerations as for Stand-Alone STUN applies 736 (Section 4.1.3). 738 4.2.5. Deployment Considerations 740 For the "Embedded STUN" method the following applies: 742 Advantages: 744 o STUN is a solution first used by SIP applications. As shown 745 above, with little or no changes, RTSP application can re-use STUN 746 as a NAT traversal solution, avoiding the pit-fall of solving a 747 problem twice. 749 o STUN has built-in message authentication features, which makes it 750 more secure against hi-jacking attacks. See next section for an 751 in-depth security discussion. 753 o This solution works as long as there is only one RTSP endpoint in 754 the private address realm, regardless of the NAT's type. There 755 may even be multiple NATs (see Figure 1 in [RFC5389]). 757 o Compared to other UDP based NAT traversal methods in this 758 document, STUN requires little new protocol development (since 759 STUN is already a IETF standard), and most likely less 760 implementation effort, since open source STUN server and client 761 implementations are available [STUN-IMPL][PJNATH]. There is the 762 need to embed STUN in RTSP server and client, which require a de- 763 multiplexer between STUN packets and RTP/RTCP packets. There is 764 also a need to register the proper feature tags. 766 Disadvantages: 768 o Some extensions to the RTSP core protocol, likely signaled by RTSP 769 feature tags, must be introduced. 771 o Requires an embedded STUN server to be co-located on each of the 772 RTSP server's media protocol's ports (e.g. RTP and RTCP ports), 773 which means more processing is required to de-multiplex STUN 774 packets from media packets. For example, the de-multiplexer must 775 be able to differentiate a RTCP RR packet from a STUN packet, and 776 forward the former to the streaming server, and the latter to the 777 STUN server. 779 o Does not support use cases that require the RTSP connection and 780 the media reception to happen at different addresses, unless the 781 server's security policy is relaxed. 783 o Interaction problems exist when a RTSP ALG is not aware of STUN 784 unless TLS is used to protect the RTSP messages. 786 o Using STUN requires that RTSP servers and clients support the 787 updated RTSP specification [I-D.ietf-mmusic-rfc2326bis], and they 788 both agree to support the NAT traversal feature. 790 o Increases the setup delay with at least the amount of time it 791 takes to perform STUN message exchanges. Most likely an extra 792 SETUP sequence will be required. 794 Transition: 796 The usage of STUN can be phased out gradually as the first step of a 797 STUN capable machine can be to check the presence of NATs for the 798 presently used network connection. The removal of STUN capability in 799 the client implementations will have to wait until there is 800 absolutely no need to use STUN. 802 4.2.6. Security Considerations 804 See Stand-Alone STUN (Section 4.1.5). 806 4.3. ICE 808 4.3.1. Introduction 810 ICE (Interactive Connectivity Establishment) [RFC5245] is a 811 methodology for NAT traversal that has been developed for SIP using 812 SDP offer/answer. The basic idea is to try, in a staggered parallel 813 fashion, all possible connection addresses that an endpoint may be 814 reachable by. This allows the endpoint to use the best available UDP 815 "connection" (meaning two UDP end-points capable of reaching each 816 other). The methodology has very nice properties in that basically 817 all NAT topologies are possible to traverse. 819 Here is how ICE works at a high level. End point A collects all 820 possible addresses that can be used, including local IP addresses, 821 STUN derived addresses, TURN addresses, etc. On each local port that 822 any of these address and port pairs lead to, a STUN server is 823 installed. This STUN server only accepts STUN requests using the 824 correct authentication through the use of a username and password. 826 End-point A then sends a request to establish connectivity with end- 827 point B, which includes all possible "destinations" [RFC5245] to get 828 the media through to A. Note that each of A's local address/port 829 pairs (host candidates and server reflexive base) has a STUN server 830 co-located. B in turn provides A with all its possible destinations 831 for the different media streams. A and B then uses a STUN client to 832 try to reach all the address and port pairs specified by A from its 833 corresponding destination ports. The destinations for which the STUN 834 requests successfully complete are then indicated and one is 835 selected. 837 If B fails to get any STUN response from A, all hope is not lost. 838 Certain NAT topologies require multiple tries from both ends before 839 successful connectivity is accomplished and therefore requests are 840 retransmitted multiple times. The STUN requests may also result in 841 that more connectivity alternatives (destinations) are discovered and 842 conveyed in the STUN responses. 844 4.3.2. Using ICE in RTSP 846 The usage of ICE for RTSP requires that both client and server be 847 updated to include the ICE functionality. If both parties implement 848 the necessary functionality the following steps could provide ICE 849 support for RTSP. 851 This assumes that it is possible to establish a TCP connection for 852 the RTSP messages between the client and the server. This is not 853 trivial in scenarios where the server is located behind a NAT, and 854 may require some TCP ports be opened, or the deployment of proxies, 855 etc. 857 The negotiation of ICE in RTSP of necessity will work different than 858 in SIP with SDP offer/answer. The protocol interactions are 859 different and thus the possibilities for transfer of states are also 860 somewhat different. The goal is also to avoid introducing extra 861 delay in the setup process at least for when the server is using a 862 public address and the client is either having a public address or is 863 behind NAT(s). This process is only intended to support PLAY mode, 864 i.e. media traffic flows from server to client. 866 1. The ICE usage begins in the SDP. The SDP for the service 867 indicates that ICE is supported at the server. No candidates can 868 be given here as that would not work with the on demand, DNS load 869 balancing, etc., that have the SDP indicate a resource on a 870 server park rather than a specific machine. 872 2. The client gathers addresses and puts together its candidates for 873 each media stream indicated in the session description. 875 3. In each SETUP request the client includes its candidates in an 876 ICE specific transport specification. This indicates for the 877 server the ICE support by the client. One candidate is the most 878 prioritized candidate and here the prioritization for this 879 address should be somewhat different compared to SIP. High 880 performance rather than always successful is recommended, as it 881 is most likely to be a server in the public. 883 4. The server responds to the SETUP (200 OK) for each media stream 884 with its candidates. A server with a public address usually only 885 provides a single ICE candidate. Also here one candidate is the 886 server primary address. 888 5. The connectivity checks are performed. For the server the 889 connectivity checks from the server to the clients have an 890 additional usage. They verify that there is someone willingly to 891 receive the media, thus protecting itself from performing 892 unknowingly an DoS attack. 894 6. Connectivity checks from the client promoting a candidate pair 895 were successful. Thus no further SETUP requests are necessary 896 and processing can proceed with step 7. If another address than 897 the primary has been verified by the client to work, that address 898 may then be promoted for usage in a SETUP request (Go to 7). If 899 the checks for the available candidates failed and if further 900 candidates have been derived during the connectivity checks, then 901 those can be signalled in new candidate lines in a SETUP request 902 updating the list (Go to 5). 904 7. Client issues PLAY request. If the server also has completed its 905 connectivity checks for the promoted candidate pair (based on 906 username as it may be derived addresses if the client was behind 907 NAT) then it can directly answer 200 OK (Go to 8). If the 908 connectivity check has not yet completed it responds with a 1xx 909 code to indicate that it is verifying the connectivity. If that 910 fails within the set timeout, an error is reported back. Client 911 needs to go back to 6. 913 8. Process completed and media can be delivered. ICE candidates not 914 used may be released. 916 To keep media paths alive the client needs to periodically send data 917 to the server. This will be realized with STUN. RTCP sent by client 918 should be able to keep RTCP open but STUN will also be used based on 919 the same motivations as for ICE for SIP. 921 4.3.3. Implementation burden of ICE 923 The usage of ICE will require that a number of new protocols and new 924 RTSP/SDP features be implemented. This makes ICE the solution that 925 has the largest impact on client and server implementations amongst 926 all the NAT/Firewall traversal methods in this document. 928 RTSP server implementation requirements are: 930 o STUN server features 932 o limited STUN client features 934 o SDP generation with more parameters. 936 o RTSP error code for ICE extension 938 RTSP client implementation requirements are: 940 o Limited STUN server features 942 o Limited STUN client features 944 o RTSP error code and ICE extension 946 4.3.4. Deployment Considerations 948 Advantages: 950 o Solves NAT connectivity discovery for basically all cases as long 951 as a TCP connection between them can be established. This 952 includes servers behind NATs. (Note that a proxy between address 953 domains may be required to get TCP through). 955 o Improves defenses against DDoS attacks, as media receiving client 956 requires authentications, via STUN on its media reception ports. 958 Disadvantages: 960 o Increases the setup delay with at least the amount of time it 961 takes for the server to perform its STUN requests. 963 o Assumes that it is possible to de-multiplex between the packets of 964 the media protocol and STUN packets. 966 o Has fairly high implementation burden put on both RTSP server and 967 client. However, several Open Source ICE implementations do 968 exist, such as [NICE][PJNATH]. 970 4.3.5. Security Consideration 972 One should review the security consideration section of ICE and STUN 973 to understand that ICE contains some potential issues. However these 974 can be avoided by correctly using ICE in RTSP. In fact ICE does help 975 avoid the DDoS attack issue with RTSP substantially as it reduces the 976 possibility for a DDoS using RTSP servers to attackers that are on- 977 path between the RTSP server and the target and capable of 978 intercepting the STUN connectivity check packets and correctly send a 979 response to the server. 981 4.4. Latching 983 4.4.1. Introduction 985 Latching is a NAT traversal solution that is based on requiring RTSP 986 clients to send UDP packets to the server's media output ports. 987 Conventionally, RTSP servers send RTP packets in one direction: from 988 server to client. Latching is similar to connection-oriented 989 traffic, where one side (e.g., the RTSP client) first "connects" by 990 sending a RTP packet to the other side's RTP port, the recipient then 991 replies to the originating IP and port. This method is also referred 992 to as "Late binding". It requires that all RTP/RTCP transport is 993 done symmetrical, i.e. Symmetric RTP [RFC4961]. 995 Specifically, when the RTSP server receives the latching packet 996 (a.k.a. hole-punching packet, since it is used to punch a hole in 997 the Firewall/NAT and to aid the server for port binding and address 998 mapping) from its client, it copies the source IP and Port number and 999 uses them as delivery address for media packets. By having the 1000 server send media traffic back the same way as the client's packet 1001 are sent to the server, address mappings will be honored. Therefore 1002 this technique works for all types of NATs, given that the server is 1003 not behind a NAT. However, it does require server modifications. 1004 Unless there is built-in protection mechanism, latching is very 1005 vulnerable to DDoS attacks, because attackers can simply forge the 1006 source IP & Port of the latching packet. Using the rule for 1007 restricting IP address to the one of the signaling connection will 1008 need to be applied here also. However, that does not protect against 1009 hijacking from another client behind the same NAT. This can become a 1010 serious issue in deployments with CGNs. 1012 4.4.2. Necessary RTSP extensions 1014 To support Latching, the RTSP signaling must be extended to allow the 1015 RTSP client to indicate that it will use Latching. The client also 1016 needs to be able to signal its RTP SSRC to the server in its SETUP 1017 request. The RTP SSRC is used to establish some basic level of 1018 security against hijacking attacks or simply avoid mis-association 1019 when multiple clients are behind the same NAT. Care must be taken in 1020 choosing clients' RTP SSRC. First, it must be unique within all the 1021 RTP sessions belonging to the same RTSP session. Secondly, if the 1022 RTSP server is sending out media packets to multiple clients from the 1023 same send port, the RTP SSRC needs to be unique amongst those 1024 clients' RTP sessions. Recognizing that there is a potential that 1025 RTP SSRC collisions may occur, the RTSP server must be able to signal 1026 to a client that a collision has occurred and that it wants the 1027 client to use a different RTP SSRC carried in the SETUP response or 1028 use unique ports per RTSP session. Using unique ports limits an RTSP 1029 server in the number of sessions it can simultaneously handle per 1030 interface IP addresses. 1032 4.4.3. Deployment Considerations 1034 Advantages: 1036 o Works for all types of client-facing NATs. (Requirement 1 in 1037 Section 3). 1039 o Has no interaction problems with any RTSP ALG changing the 1040 client's information in the transport header. 1042 Disadvantages: 1044 o Requires modifications to both RTSP server and client. 1046 o Limited to work with servers that have an public IP address. 1048 o The format of the RTP packet for "connection setup" (a.k.a 1049 Latching packet) is yet to be defined. One possibility is to use 1050 RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op]. 1052 o SSRC management if RTP is used for latching due to risk for mis- 1053 association of clients to RTSP sessions at the server if SSRC 1054 collision occurs. 1056 o Has worse security situation than STUN due to lack of STUN message 1057 authentication and will need to use address restrictions. 1059 4.4.4. Security Consideration 1061 Latching's major security issue is that RTP streams can be hijacked 1062 and directed towards any target that the attacker desires unless 1063 address restrictions are used. In the case of NATs with multiple 1064 clients on the inside of them, hijacking can still occur. This 1065 becomes a significant threat in the context of carrier grade NATs 1066 (CGN). 1068 The most serious security problem is the deliberate attack with the 1069 use of a RTSP client and Latching. The attacker uses RTSP to setup a 1070 media session. Then it uses Latching with a spoofed source address 1071 of the intended target of the attack. There is no defense against 1072 this attack other than restricting the possible address a latching 1073 packet can come from to the same as the RTSP TCP connection are from. 1074 This prevents Latching to be used in use cases that require different 1075 addresses for media destination and signalling. 1077 A hijack attack can also be performed in various ways. The basic 1078 attack is based on the ability to read the RTSP signaling packets in 1079 order to learn the address and port the server will send from and 1080 also the SSRC the client will use. Having this information the 1081 attacker can send its own Latching packets containing the correct RTP 1082 SSRC to the correct address and port on the server. The RTSP server 1083 will then use the source IP and port from the Latching packet as the 1084 destination for the media packets it sends. 1086 Another variation of this attack is for a man in the middle to modify 1087 the RTP latching packet being sent by a client to the server by 1088 simply changing the source IP to the target one desires to attack. 1090 One can fend off the first attack by applying encryption to the RTSP 1091 signaling transport. However, the second variation is impossible to 1092 defend against. As a NAT re-writes the source IP and port this 1093 cannot be authenticated, but authentication is required in order to 1094 protect against this type of DoS attack. 1096 Yet another issues is that these attacks also can be used to deny the 1097 client the service it desires from the RTSP server completely. For a 1098 man in the middle capable of reading the signaling traffic or 1099 intercepting the latching packets can completely deny the client 1100 service by modifying or originating latching packets of itself. 1102 The amount of random non-guessable material in the latching packet 1103 determines how well Latching can fend off stream-hijacking performed 1104 by parties that are not "man-in-the-middle". This proposal uses the 1105 32-bit RTP SSRC field to this effect. Therefore it is important that 1106 this field is derived with a non-predictable random number generator. 1107 It should not be possible by knowing the algorithm used and a couple 1108 of basic facts, to derive what random number a certain client will 1109 use. 1111 An attacker not knowing the SSRC but aware of which port numbers that 1112 a server sends from can deploy a brute force attack on the server by 1113 testing a lot of different SSRCs until it finds a matching one. 1114 Therefore a server could implement functionality that blocks packets 1115 to ports or from sources that receive or send multiple Latching 1116 packets with different invalid SSRCs, especially when they are coming 1117 from the same IP/Port. Note that this mitigation in itself opens up 1118 a new venue for DoS attacks against legit users trying to latch. 1120 To improve the security against attackers the amount of random 1121 material could be increased. To achieve a longer random tag while 1122 still using RTP and RTCP, it will be necessary to develop RTP and 1123 RTCP payload formats for carrying the random material. 1125 4.5. A Variation to Latching 1127 4.5.1. Introduction 1129 Latching as described above requires the usage of a valid RTP format 1130 as the Latching packet, i.e. the first packet that the client sends 1131 to the server to set up virtual RTP connection. There existed no 1132 appropriate RTP packet format for this purpose, although the No-Op 1133 format was a proposal to fix the problem [I-D.ietf-avt-rtp-no-op]. 1134 However, that work was abandoned. There exists a RFC that discusses 1135 the implication of different type of packets as keep-alives for RTP 1136 [RFC6263] and its findings are very relevant to the format of the 1137 Latching packet. 1139 Meanwhile, there has been NAT/Firewall traversal techniques deployed 1140 in the wireless streaming market place that use non-RTP messages as 1141 Latching packets. This section describes a variant based on a subset 1142 of those solutions that alters the previously described Latching 1143 solution. 1145 4.5.2. Necessary RTSP extensions 1147 In this variation of Latching, the Latching packet is a small UDP 1148 packet that does not contain an RTP header. In response to client's 1149 Latching packet, the RTSP server sends back a similar Latching packet 1150 as a confirmation so the client can stop the so called "connection 1151 phase" of this NAT traversal technique. Afterwards, the client only 1152 has to periodically send Latching packets as keep-alive messages for 1153 the NAT mappings. 1155 The server listens on its RTP-media output port, and tries to decode 1156 any received UDP packet as Latching packet. This is valid since an 1157 RTSP server is not expecting RTP traffic from the RTSP client. Then, 1158 it can correlate the Latching packet with the RTSP client's session 1159 ID or the client's SSRC, and record the NAT bindings accordingly. 1160 The server then sends a Latching packet as the response to the 1161 client. 1163 The Latching packet can contain the SSRC to identify the RTP stream, 1164 and care must be taken if the packet is bigger than 12 bytes, 1165 ensuring that it is distinctively different from RTP packets, whose 1166 header size is 12 bytes. 1168 RTSP signaling can be added to do the following: 1170 1. Enable or disable such Latching message exchanges. When the 1171 Firewall/NAT has an RTSP-aware ALG, it is possible to disable 1172 Latching message exchange and let the ALG work out the address 1173 and port mappings. 1175 2. Configure the number of re-tries and the re-try interval of the 1176 Latching message exchanges. 1178 4.5.3. Deployment Considerations 1180 This approach has the following advantages when compared with the 1181 Latching approach (Section 4.4): 1183 1. There is no need to define RTP payload format for Firewall 1184 traversal, therefore it is simple to use, implement and 1185 administer (Requirement 4 in Section 3), instead a Latching 1186 protocol must be defined. 1188 2. When properly defined, this kind of Latching packet exchange can 1189 also authenticate RTP receivers, to prevent hijacking attacks. 1191 This approach has the following disadvantages when compared with the 1192 Latching approach: 1194 1. RTP traffic is normally accompanied by RTCP traffic. This 1195 approach needs to rely on RTCP RRs and SRs to enable NAT 1196 traversal for RTCP endpoints, use RTP/RTCP Multiplexing 1197 [RFC5761], or use the same type of Latching packets also for RTCP 1198 endpoints. 1200 2. The server's sender SSRC for the RTP stream or other session 1201 Identity information must be signaled in RTSP's SETUP response, 1202 in the Transport header of the RTSP SETUP response. 1204 4.5.4. Security Considerations 1206 Compared to the security properties of Latching this variant is 1207 slightly improved. First of all it allows for a larger random field 1208 in the Latching packets which makes it more unlikelier for an off- 1209 path attacker to succeed in a hi-jack attack. Secondly the 1210 confirmation allows the client to know when Latching works and when 1211 it didn't and thus restart the Latching process by updating the SSRC. 1212 Thirdly if an authentication mechanism are included in the latching 1213 packet hijacking attacks can be prevented. 1215 Still the main security issue remain that the RTSP server can't know 1216 that the source address in the latching packet was coming from a RTSP 1217 client wanting to receive media and not one that likes to direct the 1218 media traffic to an DoS target. 1220 4.6. Three Way Latching 1222 4.6.1. Introduction 1224 The three way Latching is an attempt to try to resolve the most 1225 significant security issues for both previously discussed variants of 1226 Latching. By adding a server request response exchange directly 1227 after the initial latching the server can verify that the target 1228 address present in the latching packet is an active listener and 1229 confirm its desire to establish a media flow. 1231 4.6.2. Necessary RTSP extensions 1233 Uses the same RTSP extensions as the alternative latching method 1234 (Section 4.5) uses. The extensions for this variant are only in the 1235 format and transmission of the Latching packets. 1237 The client to server latching packet is similar to the Alternative 1238 Latching (Section 4.5), i.e. an UDP packet with some session 1239 identifier and a random value. When the server responds to the 1240 Latching packet with a Latching confirmation, it includes a random 1241 value (Nonce) of its own in addition to echoing back the one the 1242 client sent. Then a third messages is added to the exchange. The 1243 client acknowledges the reception of the Latching confirmation 1244 message and echoes back the server's nonce. Thus confirming that the 1245 Latched address goes to a RTSP client that initiated the latching and 1246 is actually present at that address. The RTSP server will refuse to 1247 send any media until the Latching Acknowledgement has been received 1248 with a valid nonce. 1250 4.6.3. Deployment Considerations 1252 A solution with a 3-way handshake and its own Latching packets can be 1253 compared with the ICE-based solution (Section 4.3) and have the 1254 following differences: 1256 o Only works for servers with public IP addresses compared to any 1257 type of server 1259 o May be simpler to implement due to the avoidance of the ICE 1260 prioritization and check-board mechanisms. 1262 However, a 3-way Latching protocol is very similar to using STUN in 1263 both directions as Latching and verification protocol. Using STUN 1264 would remove the need for implementing a new protocol. 1266 4.7. Application Level Gateways 1268 4.7.1. Introduction 1270 An Application Level Gateway (ALG) reads the application level 1271 messages and performs necessary changes to allow the protocol to work 1272 through the middle box. However this behavior has some problems in 1273 regards to RTSP: 1275 1. It does not work when the RTSP protocol is used with end-to-end 1276 security. As the ALG can't inspect and change the application 1277 level messages the protocol will fail due to the middle box. 1279 2. ALGs need to be updated if extensions to the protocol are added. 1280 Due to deployment issues with changing ALGs this may also break 1281 the end-to-end functionality of RTSP. 1283 Due to the above reasons it is not recommended to use an RTSP ALG in 1284 NATs. This is especially important for NATs targeted to home users 1285 and small office environments, since it is very hard to upgrade NATs 1286 deployed in home or SOHO (small office/home office) environment. 1288 4.7.2. Outline On how ALGs for RTSP work 1289 In this section, we provide a step-by-step outline on how one could 1290 go about writing an ALG to enable RTSP to traverse a NAT. 1292 1. Detect any SETUP request. 1294 2. Try to detect the usage of any of the NAT traversal methods that 1295 replace the address and port of the Transport header parameters 1296 "destination" or "dest_addr". If any of these methods are used, 1297 then the ALG should not change the address. Ways to detect that 1298 these methods are used are: 1300 * For embedded STUN, it would be to watch for a feature tag, 1301 like "nat.stun". If any of those exists in the "supported", 1302 "proxy-require", or "require" headers of the RTSP exchange. 1304 * For stand alone STUN and TURN based solutions: This can be 1305 detected by inspecting the "destination" or "dest_addr" 1306 parameter. If it contains either one of the NAT's external IP 1307 addresses or a public IP address then such a solution is in 1308 use. However if multiple NATs are used this detection may 1309 fail. Remapping should only be done for addresses belonging 1310 to the NAT's own private address space. 1312 Otherwise continue to the next step. 1314 3. Create UDP mappings (client given IP/port <-> external IP/port) 1315 where needed for all possible transport specifications in the 1316 transport header of the request found in (1). Enter the external 1317 address and port(s) of these mappings in transport header. 1318 Mappings shall be created with consecutive public port numbers 1319 starting on an even number for RTP for each media stream. 1320 Mappings should also be given a long timeout period, at least 5 1321 minutes. 1323 4. When the SETUP response is received from the server, the ALG may 1324 remove the unused UDP mappings, i.e. the ones not present in the 1325 transport header. The session ID should also be bound to the UDP 1326 mappings part of that session. 1328 5. If SETUP response settles on RTP over TCP or RTP over RTSP as 1329 lower transport, do nothing: let TCP tunneling take care of NAT 1330 traversal. Otherwise go to next step. 1332 6. The ALG should keep the UDP mappings belonging to the RTSP 1333 session as long as: an RTSP messages with the session's ID has 1334 been sent in the last timeout interval, or a UDP messages has 1335 been sent on any of the UDP mappings during the last timeout 1336 interval. 1338 7. The ALG may remove a mapping as soon a TEARDOWN response has been 1339 received for that media stream. 1341 4.7.3. Deployment Considerations 1343 Advantage: 1345 o No impact on either client or server 1347 o Can work for any type of NATs 1349 Disadvantage: 1351 o When deployed they are hard to update to reflect protocol 1352 modifications and extensions. If not updated they will break the 1353 functionality. 1355 o When end-to-end security is used, the ALG functionality will fail. 1357 o Can interfere with other types of traversal mechanisms, such as 1358 STUN. 1360 Transition: 1362 An RTSP ALG will not be phased out in any automatic way. It must be 1363 removed, probably through the removal of the NAT it is associated 1364 with. 1366 4.7.4. Security Considerations 1368 An ALG will not work with deployment of end-to-end RTSP signaling 1369 security. Therefore deployment of ALG will likely result in clients 1370 located behind NATs not using end-to-end security. 1372 The creation of an UDP mapping based on the signalling message has 1373 some potential security implications. First of all if the RTSP 1374 client releases its ports and another application are assigned these 1375 instead it could receive RTP media as long as the mappings exist and 1376 the RTSP server has failed to be signalled or notice the lack of 1377 client response. 1379 An NAT with RTSP ALG that assigns mappings based on SETUP requests 1380 could potentially become victim of an resource exhaustion attack. If 1381 an attacker creates a lot of RTSP sessions, even without starting 1382 media transmission could exhaust the pool of available UDP ports on 1383 the NAT. Thus only a limited number of UDP mappings should be 1384 allowed to be created by the RTSP ALG. 1386 4.8. TCP Tunneling 1388 4.8.1. Introduction 1390 Using a TCP connection that is established from the client to the 1391 server ensures that the server can send data to the client. The 1392 connection opened from the private domain ensures that the server can 1393 send data back to the client. To send data originally intended to be 1394 transported over UDP requires the TCP connection to support some type 1395 of framing of the media data packets. Using TCP also results in the 1396 client having to accept that real-time performance can be impacted. 1397 TCP's problem of ensuring timely delivery was one of the reasons why 1398 RTP was developed. Problems that arise with TCP are: head-of-line 1399 blocking, delay introduced by retransmissions, highly varying rate 1400 due to the congestion control algorithm. If sufficient amount of 1401 buffering (several seconds) in the receiving client can be tolerated 1402 then TCP clearly can work. 1404 4.8.2. Usage of TCP tunneling in RTSP 1406 The RTSP core specification [I-D.ietf-mmusic-rfc2326bis] supports 1407 interleaving of media data on the TCP connection that carries RTSP 1408 signaling. See section 14 in [I-D.ietf-mmusic-rfc2326bis] for how to 1409 perform this type of TCP tunneling. There also exists another way of 1410 transporting RTP over TCP defined in Appendix C.2 in 1411 [I-D.ietf-mmusic-rfc2326bis]. For signaling and rules on how to 1412 establish the TCP connection in lieu of UDP, see appendix C.2 in 1413 [I-D.ietf-mmusic-rfc2326bis]. This is based on the framing of RTP 1414 over the TCP connection as described in RFC 4571 [RFC4571]. 1416 4.8.3. Deployment Considerations 1418 Advantage: 1420 o Works through all types of NATs where the RTSP server in not NATed 1421 or at least reachable like it was not. 1423 Disadvantage: 1425 o Functionality needs to be implemented on both server and client. 1427 o Will not always meet multimedia stream's real-time requirements. 1429 Transition: 1431 The tunneling over RTSP's TCP connection is not planned to be phased- 1432 out. It is intended to be a fallback mechanism and for usage when 1433 total media reliability is desired, even at the potential price of 1434 loss of real-time properties. 1436 4.8.4. Security Considerations 1438 The TCP tunneling of RTP has no known security problems besides those 1439 already presented in the RTSP specification. It is not possible to 1440 get any amplification effect for denial of service attacks due to 1441 TCP's flow control. A possible security consideration, when session 1442 media data is interleaved with RTSP, would be the performance 1443 bottleneck when RTSP encryption is applied, since all session media 1444 data also needs to be encrypted. 1446 4.9. TURN (Traversal Using Relay NAT) 1448 4.9.1. Introduction 1450 Traversal Using Relay NAT (TURN) [RFC5766] is a protocol for setting 1451 up traffic relays that allow clients behind NATs and firewalls to 1452 receive incoming traffic for both UDP and TCP. These relays are 1453 controlled and have limited resources. They need to be allocated 1454 before usage. TURN allows a client to temporarily bind an address/ 1455 port pair on the relay (TURN server) to its local source address/port 1456 pair, which is used to contact the TURN server. The TURN server will 1457 then forward packets between the two sides of the relay. 1459 To prevent DoS attacks on either recipient, the packets forwarded are 1460 restricted to the specific source address. On the client side it is 1461 restricted to the source setting up the allocation. On the external 1462 side this is limited to the source address/port pair that have been 1463 given permission by the TURN client creating the allocation. Packets 1464 from any other source on this address will be discarded. 1466 Using a TURN server makes it possible for a RTSP client to receive 1467 media streams from even an unmodified RTSP server. However the 1468 problem is those RTSP servers most likely restrict media destinations 1469 to no other IP address than the one the RTSP message arrives from. 1470 This means that TURN could only be used if the server knows and 1471 accepts that the IP belongs to a TURN server and the TURN server 1472 can't be targeted at an unknown address or also the RTSP connection 1473 is relayed through the same TURN server. 1475 4.9.2. Usage of TURN with RTSP 1477 To use a TURN server for NAT traversal, the following steps should be 1478 performed. 1480 1. The RTSP client connects with the RTSP server. The client 1481 retrieves the session description to determine the number of 1482 media streams. To avoid the issue with having RTSP connection 1483 and media traffic from different addresses also the TCP 1484 connection must be done through the same TURN server as the one 1485 in the next step. This will require the usage of TURN for TCP 1486 [RFC6062]. 1488 2. The client establishes the necessary bindings on the TURN server. 1489 It must choose the local RTP and RTCP ports that it desires to 1490 receive media packets. TURN supports requesting bindings of even 1491 port numbers and continuous ranges. 1493 3. The RTSP client uses the acquired address and port allocations in 1494 the RTSP SETUP request using the destination header. 1496 4. The RTSP Server sends the SETUP reply, which must include the 1497 transport headers src_addr parameter (source and port in RTSP 1498 1.0). Note that the server is required to have a mechanism to 1499 verify that it is allowed to send media traffic to the given 1500 address. 1502 5. The RTSP Client uses the RTSP Servers response to create TURN 1503 permissions for the server's media traffic. 1505 6. The client requests that the server starts playing. The server 1506 starts sending media packets to the given destination address and 1507 ports. 1509 7. The first media packet to arrive at the TURN server on the 1510 external port; If matching established permissions the TURN 1511 server forwards the media packets to the RTSP client. 1513 8. If the client pauses and media is not sent for about 75% of the 1514 mapping timeout the client should use TURN to refresh the 1515 bindings. 1517 4.9.3. Deployment Considerations 1519 Advantages: 1521 o Does not require any server modifications given that the server 1522 includes the src_addr header in the SETUP response. 1524 o Works for any type of NAT as long as the RTSP server has public 1525 reachable IP address. 1527 Disadvantage: 1529 o Requires another network element, namely the TURN server. 1531 o A TURN server for RTSP may not scale since the number of sessions 1532 it must forward is proportional to the number of client media 1533 sessions. 1535 o TURN server becomes a single point of failure. 1537 o Since TURN forwards media packets, it necessarily introduces 1538 delay. 1540 o An RTSP ALG may change the necessary destinations parameter. This 1541 will cause the media traffic to be sent to the wrong address. 1543 Transition: 1545 TURN is not intended to be phased-out completely, see Section 19 of 1546 [RFC5766]. However the usage of TURN could be reduced when the 1547 demand for having NAT traversal is reduced. 1549 4.9.4. Security Considerations 1551 The TURN server can become part of a denial of service attack towards 1552 any victim. To perform this attack the attacker must be able to 1553 eavesdrop on the packets from the TURN server towards a target for 1554 the DoS attack. The attacker uses the TURN server to setup a RTSP 1555 session with media flows going through the TURN server. The attacker 1556 is in fact creating TURN mappings towards a target by spoofing the 1557 source address of TURN requests. As the attacker will need the 1558 address of these mappings he must be able to eavesdrop or intercept 1559 the TURN responses going from the TURN server to the target. Having 1560 these addresses, he can set up a RTSP session and start delivery of 1561 the media. The attacker must be able to create these mappings. The 1562 attacker in this case may be traced by the TURN username in the 1563 mapping requests. 1565 This attack requires that the attacker has access to a user account 1566 on the TURN server to be able set up the TURN mappings. To prevent 1567 this attack the RTSP server needs to verify that the ultimate target 1568 destination accept this media stream. Which would require something 1569 like ICE's connectivity checks being run between the RTSP server and 1570 the RTSP client. 1572 5. Firewalls 1574 Firewalls exist for the purpose of protecting a network from traffic 1575 not desired by the firewall owner. Therefore it is a policy decision 1576 if a firewall will let RTSP and its media streams through or not. 1577 RTSP is designed to be firewall friendly in that it should be easy to 1578 design firewall policies to permit passage of RTSP traffic and its 1579 media streams. 1581 The firewall will need to allow the media streams associated with a 1582 RTSP session to pass through it. Therefore the firewall will need an 1583 ALG that reads RTSP SETUP and TEARDOWN messages. By reading the 1584 SETUP message the firewall can determine what type of transport and 1585 from where, the media stream packets will be sent. Commonly there 1586 will be the need to open UDP ports for RTP/RTCP. By looking at the 1587 source and destination addresses and ports the opening in the 1588 firewall can be minimized to the least necessary. The opening in the 1589 firewall can be closed after a TEARDOWN message for that session or 1590 the session itself times out. 1592 Simpler firewalls do allow a client to receive media as long as it 1593 has sent packets to the target. Depending on the security level this 1594 can have the same behavior as a NAT. The only difference is that no 1595 address translation is done. To use such a firewall a client would 1596 need to implement one of the above described NAT traversal methods 1597 that include sending packets to the server to open up the mappings. 1599 6. Comparison of NAT traversal techniques 1601 This section evaluates the techniques described above against the 1602 requirements listed in Section 3. 1604 In the following table, the columns correspond to the numbered 1605 requirements. For instance, the column under R1 corresponds to the 1606 first requirement in Section 3: must work for all flavors of NATs. 1607 The rows represent the different NAT/Firewall traversal techniques. 1608 Latch is short for Latching, "V. Latch" is short for "variation of 1609 Latching" as described in Section 4.5. "3-W Latch" is short for the 1610 Three Way Latching described in Section 4.6. 1612 A Summary of the requirements are: 1614 R1: Work for all flavors of NATs 1616 R2: Must work with Firewalls, including those with ALGs 1618 R3: Should have minimal impact on clients not behind NATs, counted 1619 in minimal number of additional RTTs 1621 R4: Should be simple to use, Implement and administer. 1623 R5: Should provide mitigation against DDoS attacks 1625 The following considerations are also added to requirements: 1627 C1: Will solution support both Clients and Servers behind NAT 1629 C2: Is the solution robust to changing NAT behaviors 1631 ------------+------+------+------+------+------+------+------+ 1632 | R1 | R2 | R3 | R4 | R5 | C1 | C2 | 1633 ------------+------+------+------+------+------+------+------+ 1634 STUN | No | Yes | 1 | Maybe| No | No | No | 1635 ------------+------+------+------+------+------+------+------+ 1636 Emb. STUN | Yes | Yes | 2 | Maybe| No | No | Yes | 1637 ------------+------+------+------+------+------+------+------+ 1638 ICE | Yes | Yes | 2.5 | No | Yes | Yes | Yes | 1639 ------------+------+------+------+------+------+------+------+ 1640 Latch | Yes | Yes | 1 | Maybe| No | No | Yes | 1641 ------------+------+------+------+------+------+------+------+ 1642 V. Latch | Yes | Yes | 1 | Yes | No | No | Yes | 1643 ------------+------+------+------+------+------+------+------+ 1644 3-W Latch | Yes | Yes | 1.5 | Maybe| Yes | No | Yes | 1645 ------------+------+------+------+------+------+------+------+ 1646 ALG |(Yes) | Yes | 0 | No | Yes | No | Yes | 1647 ------------+------+------+------+------+------+------+------+ 1648 TCP Tunnel | Yes | Yes | 1.5 | Yes | Yes | No | Yes | 1649 ------------+------+------+------+------+------+------+------+ 1650 TURN | Yes | Yes | 1 | No | Yes |(Yes) | Yes | 1651 ------------+------+------+------+------+------+------+------+ 1653 Figure 1: Comparison of fulfillment of requirements 1655 Looking at Figure 1 one would draw the conclusion that using TCP 1656 Tunneling or Three-Way Latching is the solutions that best fulfill 1657 the requirements. The different techniques were discussed in the 1658 MMUSIC WG. It was established that the WG would pursue an ICE based 1659 solution due to its generality and capability of handling also 1660 servers delivering media from behind NATs. TCP Tunneling is likely 1661 to be available as an alternative, due to its specification in the 1662 main RTSP specification. Thus it can be used if desired and the 1663 potential downsides of using TCP is acceptable in particular 1664 deployments. When it comes to Three-Way Latching it is a very 1665 competitive technique given that you don't need support for RTSP 1666 servers behind NATs. There were some discussion in the WG if the 1667 increased implementation burden of ICE is sufficiently motivated 1668 compared to a the Three-Way Latching solution for this generality. 1670 In the end the authors believe that reuse of ICE, the greater 1671 flexibility and anyway need to deploy a new solution was the decisive 1672 factors. 1674 The ICE based RTSP NAT traversal solution is specified in "A Network 1675 Address Translator (NAT) Traversal mechanism for media controlled by 1676 Real-Time Streaming Protocol (RTSP)" [I-D.ietf-mmusic-rtsp-nat]. 1678 7. IANA Considerations 1680 This document makes no request of IANA. 1682 Note to RFC Editor: this section may be removed on publication as an 1683 RFC. 1685 8. Security Considerations 1687 In the preceding sections we have discussed security merits of the 1688 different NAT/Firewall traversal methods for RTSP discussed here. In 1689 summary, the presence of NAT(s) is a security risk, as a client 1690 cannot perform source authentication of its IP address. This 1691 prevents the deployment of any future RTSP extensions providing 1692 security against hijacking of sessions by a man-in-the-middle. 1694 Each of the proposed solutions has security implications. Using STUN 1695 will provide the same level of security as RTSP with out transport 1696 level security and source authentications, as long as the server does 1697 not allow media to be sent to a different IP-address than the RTSP 1698 client request was sent from. Using Latching will have a higher risk 1699 of session hijacking or denial of service than normal RTSP. The 1700 reason is that there exists a probability that an attacker is able to 1701 guess the random bits that the client uses to prove its identity when 1702 creating the address bindings. This can be solved in the variation 1703 of Latching (Section 4.5) with authentication features. Still both 1704 those variants of Latching is vulnerable against deliberate attack 1705 from the RTSP client to redirect the media stream requested to any 1706 target assuming it can spoof the source address. This security 1707 vulnerability is solved by performing a Three-way Latching procedure 1708 as discussed in Section 4.6. The usage of an RTSP ALG does not in 1709 itself increase the risk for session hijacking. However the 1710 deployment of ALGs as the sole mechanism for RTSP NAT traversal will 1711 prevent deployment of end-to-end encrypted RTSP signaling. The usage 1712 of TCP tunneling has no known security problems. However, it might 1713 provide a bottleneck when it comes to end-to-end RTSP signaling 1714 security if TCP tunneling is used on an interleaved RTSP signaling 1715 connection. The usage of TURN has severe risk of denial of service 1716 attacks against a client. The TURN server can also be used as a 1717 redirect point in a DDoS attack unless the server has strict enough 1718 rules for who may create bindings. 1720 9. Acknowledgements 1722 The author would also like to thank all persons on the MMUSIC working 1723 group's mailing list that has commented on this document. Persons 1724 having contributed in such way in no special order to this protocol 1725 are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon, 1726 Amir Wolf, Anders Klemets, Flemming Andreasen, Ari Keranen, and Colin 1727 Perkins. Thomas Zeng would also like to give special thanks to Greg 1728 Sherwood of PacketVideo for his input into this memo. 1730 Section 1.1 contains text originally written for RFC 4787 by Francois 1731 Audet and Cullen Jennings. 1733 10. Informative References 1735 [I-D.ietf-avt-rtp-no-op] 1736 Andreasen, F., "A No-Op Payload Format for RTP", draft- 1737 ietf-avt-rtp-no-op-04 (work in progress), May 2007. 1739 [I-D.ietf-mmusic-rfc2326bis] 1740 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1741 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1742 (RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in 1743 progress), April 2013. 1745 [I-D.ietf-mmusic-rtsp-nat] 1746 Goldberg, J., Westerlund, M., and T. Zeng, "A Network 1747 Address Translator (NAT) Traversal mechanism for media 1748 controlled by Real-Time Streaming Protocol (RTSP)", draft- 1749 ietf-mmusic-rtsp-nat-15 (work in progress), May 2013. 1751 [NICE] , "Libnice - The GLib ICE implementation, 1752 http://nice.freedesktop.org/wiki/", May 2013. 1754 [PJNATH] , "PJNATH - Open Source ICE, STUN, and TURN Library, 1755 http://www.pjsip.org/pjnath/docs/html/", May 2013. 1757 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1758 August 1980. 1760 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1761 793, September 1981. 1763 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1764 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1766 [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May 1767 1999. 1769 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1770 Translator (NAT) Terminology and Considerations", RFC 1771 2663, August 1999. 1773 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1774 Address Translator (Traditional NAT)", RFC 3022, January 1775 2001. 1777 [RFC3424] Daigle, L. IAB, "IAB Considerations for UNilateral Self- 1778 Address Fixing (UNSAF) Across Network Address 1779 Translation", RFC 3424, November 2002. 1781 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1782 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1783 Through Network Address Translators (NATs)", RFC 3489, 1784 March 2003. 1786 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1787 Jacobson, "RTP: A Transport Protocol for Real-Time 1788 Applications", STD 64, RFC 3550, July 2003. 1790 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1791 Description Protocol", RFC 4566, July 2006. 1793 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1794 and RTP Control Protocol (RTCP) Packets over Connection- 1795 Oriented Transport", RFC 4571, July 2006. 1797 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1798 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1799 RFC 4787, January 2007. 1801 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 1802 BCP 131, RFC 4961, July 2007. 1804 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1805 (ICE): A Protocol for Network Address Translator (NAT) 1806 Traversal for Offer/Answer Protocols", RFC 5245, April 1807 2010. 1809 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1810 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1811 RFC 5382, October 2008. 1813 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1814 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1815 October 2008. 1817 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1818 Control Packets on a Single Port", RFC 5761, April 2010. 1820 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1821 Relays around NAT (TURN): Relay Extensions to Session 1822 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1824 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 1825 around NAT (TURN) Extensions for TCP Allocations", RFC 1826 6062, November 2010. 1828 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1829 Keeping Alive the NAT Mappings Associated with RTP / RTP 1830 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 1832 [STUN-IMPL] 1833 , "Open Source STUN Server and Client, 1834 http://sourceforge.net/projects/stun/", May 2013. 1836 Authors' Addresses 1837 Magnus Westerlund 1838 Ericsson 1839 Farogatan 6 1840 Stockholm SE-164 80 1841 Sweden 1843 Phone: +46 8 719 0000 1844 Email: magnus.westerlund@ericsson.com 1846 Thomas Zeng 1848 Email: thomas.zeng@gmail.com