idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-evaluation-10.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 (November 18, 2013) is 3813 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-38 == Outdated reference: A later version (-22) exists of draft-ietf-mmusic-rtsp-nat-17 -- 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: May 22, 2014 6 November 18, 2013 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-10 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 on 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 relates to firewalls and how each technique can 21 be applied in different use cases. These findings where used when 22 selecting the NAT traversal for RTSP 2.0. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 22, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Network Address Translators . . . . . . . . . . . . . . . 4 72 1.2. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6 74 2. Detecting the loss of NAT mappings . . . . . . . . . . . . . 7 75 3. Requirements on Solutions . . . . . . . . . . . . . . . . . . 8 76 4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . 9 77 4.1. Stand-Alone STUN . . . . . . . . . . . . . . . . . . . . 10 78 4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . 10 79 4.1.2. Using STUN to traverse NAT without server 80 modifications . . . . . . . . . . . . . . . . . . . . 10 81 4.1.3. ALG considerations . . . . . . . . . . . . . . . . . 12 82 4.1.4. Deployment Considerations . . . . . . . . . . . . . . 13 83 4.1.5. Security Considerations . . . . . . . . . . . . . . . 14 84 4.2. Server Embedded STUN . . . . . . . . . . . . . . . . . . 14 85 4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . 14 86 4.2.2. Embedding STUN in RTSP . . . . . . . . . . . . . . . 14 87 4.2.3. Discussion On Co-located STUN Server . . . . . . . . 16 88 4.2.4. ALG considerations . . . . . . . . . . . . . . . . . 16 89 4.2.5. Deployment Considerations . . . . . . . . . . . . . . 16 90 4.2.6. Security Considerations . . . . . . . . . . . . . . . 17 91 4.3. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . 17 93 4.3.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 18 94 4.3.3. Implementation burden of ICE . . . . . . . . . . . . 20 95 4.3.4. Deployment Considerations . . . . . . . . . . . . . . 20 96 4.3.5. Security Consideration . . . . . . . . . . . . . . . 21 98 4.4. Latching . . . . . . . . . . . . . . . . . . . . . . . . 21 99 4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . 21 100 4.4.2. Necessary RTSP extensions . . . . . . . . . . . . . . 22 101 4.4.3. Deployment Considerations . . . . . . . . . . . . . . 22 102 4.4.4. Security Consideration . . . . . . . . . . . . . . . 23 103 4.5. A Variation to Latching . . . . . . . . . . . . . . . . . 24 104 4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . 24 105 4.5.2. Necessary RTSP extensions . . . . . . . . . . . . . . 25 106 4.5.3. Deployment Considerations . . . . . . . . . . . . . . 25 107 4.5.4. Security Considerations . . . . . . . . . . . . . . . 26 108 4.6. Three Way Latching . . . . . . . . . . . . . . . . . . . 26 109 4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . 26 110 4.6.2. Necessary RTSP extensions . . . . . . . . . . . . . . 26 111 4.6.3. Deployment Considerations . . . . . . . . . . . . . . 27 112 4.7. Application Level Gateways . . . . . . . . . . . . . . . 27 113 4.7.1. Introduction . . . . . . . . . . . . . . . . . . . . 27 114 4.7.2. Outline On how ALGs for RTSP work . . . . . . . . . . 27 115 4.7.3. Deployment Considerations . . . . . . . . . . . . . . 29 116 4.7.4. Security Considerations . . . . . . . . . . . . . . . 29 117 4.8. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 30 118 4.8.1. Introduction . . . . . . . . . . . . . . . . . . . . 30 119 4.8.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . 30 120 4.8.3. Deployment Considerations . . . . . . . . . . . . . . 30 121 4.8.4. Security Considerations . . . . . . . . . . . . . . . 31 122 4.9. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . 31 123 4.9.1. Introduction . . . . . . . . . . . . . . . . . . . . 31 124 4.9.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 31 125 4.9.3. Deployment Considerations . . . . . . . . . . . . . . 32 126 4.9.4. Security Considerations . . . . . . . . . . . . . . . 33 127 5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 34 128 6. Comparison of NAT traversal techniques . . . . . . . . . . . 34 129 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 130 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 131 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 132 10. Informative References . . . . . . . . . . . . . . . . . . . 37 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 135 1. Introduction 137 Today there is a proliferate deployment of different flavors of 138 Network Address Translator (NAT) boxes that in many cases only 139 loosely follow standards 140 [RFC3022][RFC2663][RFC3424][RFC4787][RFC5382]. NATs cause 141 discontinuity in address realms [RFC3424], therefore an application 142 protocol, such as Real-time Streaming Protocol (RTSP) 143 [RFC2326][I-D.ietf-mmusic-rfc2326bis], needs to deal with such 144 discontinuities caused by NATs. The problem is that, being a media 145 control protocol managing one or more media streams, RTSP carries 146 network address and port information within its protocol messages. 147 Because of this, even if RTSP itself, when carried over Transmission 148 Control Protocol (TCP) [RFC0793] for example, is not blocked by NATs, 149 its media streams may be blocked by NATs. This will occur unless 150 special protocol provisions are added to support NAT-traversal. 152 Like NATs, Firewalls are also middle boxes that need to be 153 considered. Firewalls helps prevent unwanted traffic from getting in 154 or out of the protected network. RTSP is designed such that a 155 firewall can be configured to let RTSP controlled media streams go 156 through with minimal implementation effort. The minimal effort is to 157 implement an Application Level Gateway (ALG) to interpret RTSP 158 parameters. There is also a large class of firewalls, commonly home 159 firewalls, that uses a similar filtering behavior to what NAT has. 160 This type of firewalls can be handled using the same solution as 161 employed for NAT traversal instead of relying on ALGs. 163 This document describes several NAT-traversal mechanisms for RTSP 164 controlled media streaming. Many of these NAT solutions fall into 165 the category of "UNilateral Self-Address Fixing (UNSAF)" as defined 166 in [RFC3424] and quoted below: 168 "UNSAF is a process whereby some originating process attempts to 169 determine or fix the address (and port) by which it is known - e.g. 170 to be able to use address data in the protocol exchange, or to 171 advertise a public address from which it will receive connections." 173 Following the guidelines spelled out in RFC 3424, we describe the 174 required RTSP protocol extensions for each method, transition 175 strategies, and security concerns. 177 This document is capturing the evaluation done in the process to 178 recommend Firewall/NAT traversal methods for RTSP streaming servers 179 based on RFC 2326 [RFC2326] as well as the RTSP 2.0 core spec 180 [I-D.ietf-mmusic-rfc2326bis]. The evaluation is focused on NAT 181 traversal for the media streams carried over User Datagram Protocol 182 (UDP) [RFC0768] with Real-time Transport Protocol (RTP) [RFC3550] 183 over UDP being the main case for such usage. The findings should be 184 applicable to other protocols as long as they have similar 185 properties. 187 The resulting ICE-based RTSP NAT traversal mechanism is specified in 188 "A Network Address Translator (NAT) Traversal mechanism for media 189 controlled by Real-Time Streaming Protocol (RTSP)" 190 [I-D.ietf-mmusic-rtsp-nat]. 192 1.1. Network Address Translators 193 Readers are urged to refer to "IP Network Address Translator (NAT) 194 Terminology and Considerations" [RFC2663] for information on NAT 195 taxonomy and terminology. Traditional NAT is the most common type of 196 NAT device deployed. Readers may refer to "Traditional IP Network 197 Address Translator (Traditional NAT)" [RFC3022] for detailed 198 information on traditional NAT. Traditional NAT has two main 199 varieties -- Basic NAT and Network Address/Port Translator (NAPT). 201 NAPT is by far the most commonly deployed NAT device. NAPT allows 202 multiple internal hosts to share a single public IP address 203 simultaneously. When an internal host opens an outgoing TCP or UDP 204 session through a NAPT, the NAPT assigns the session a public IP 205 address and port number, so that subsequent response packets from the 206 external endpoint can be received by the NAPT, translated, and 207 forwarded to the internal host. The effect is that the NAPT 208 establishes a NAT mapping to translate the (private IP address, 209 private port number) tuple to a (public IP address, public port 210 number) tuple, and vice versa, for the duration of the session. An 211 issue of relevance to peer-to-peer applications is how the NAT 212 behaves when an internal host initiates multiple simultaneous 213 sessions from a single (private IP, private port) endpoint to 214 multiple distinct endpoints on the external network. In this 215 specification, the term "NAT" refers to both "Basic NAT" and "Network 216 Address/Port Translator (NAPT)". 218 This document uses the term "address and port mapping" as the 219 translation between an external address and port and an internal 220 address and port. Note that this is not the same as an "address 221 binding" as defined in RFC 2663. There exist a number of address and 222 port mapping behaviors described in more detail in Section 4.1 of 223 "Network Address Translation (NAT) Behavioral Requirements for 224 Unicast UDP" [RFC4787]. 226 NATs also have a filtering behavior on traffic arriving on the 227 external side. Such behavior affects how well different methods for 228 NAT traversal works through these NATs. See Section 5 of "Network 229 Address Translation (NAT) Behavioral Requirements for Unicast UDP" 230 [RFC4787] for more information on the different types of filtering 231 that have been identified. 233 1.2. Firewalls 235 A firewall is a security gateway that enforces certain access control 236 policies between two network administrative domains: a private domain 237 (intranet) and a external domain, e.g. public Internet. Many 238 organizations use firewalls to prevent privacy intrusions and 239 malicious attacks to corporate computing resources in the private 240 intranet [RFC2588]. 242 A comparison between NAT and Firewall is given below: 244 1. A firewall must sit between two network administrative domains, 245 while NAT does not have to sit between two domains. 247 2. NAT does not in itself provide security, although some access 248 control policies can be implemented using address translation 249 schemes. The inherent filtering behaviours are commonly mistaken 250 for real security policies. 252 It should be noted that many NAT devices intended for Residential or 253 small office/home office (SOHO) use include both NATs and firewall 254 functionality. 256 In the rest of this memo we use the phrase "NAT traversal" 257 interchangeably with "Firewall traversal", and "NAT/Firewall 258 traversal". 260 1.3. Glossary 262 Address-Dependent Mapping: The NAT reuses the port mapping for 263 subsequent packets sent from the same internal IP address and 264 port to the same external IP address, regardless of the 265 external port. See [RFC4787]. 267 Address and Port-Dependent Mapping: The NAT reuses the port mapping 268 for subsequent packets sent from the same internal IP address 269 and port to the same external IP address and port while the 270 mapping is still active. See [RFC4787]. 272 ALG: Application Level Gateway, an entity that can be embedded in a 273 NAT or other middlebox to perform the application layer 274 functions required for a particular protocol to traverse the 275 NAT/middlebox. 277 Endpoint-Independent Mapping: The NAT reuses the port mapping for 278 subsequent packets sent from the same internal IP address and 279 port to any external IP address and port. See [RFC4787]. 281 ICE: Interactive Connectivity Establishment, see [RFC5245]. 283 DNS: Domain Name Service 285 DoS: Denial of Service 287 DDoS: Distributed Denial of Service 289 NAT: Network Address Translator, see [RFC3022]. 291 NAPT: Network Address/Port Translator, see [RFC3022]. 293 RTP: Real-time Transport Protocol, see [RFC3550]. 295 RTSP: Real-Time Streaming Protocol, see [RFC2326] and 296 [I-D.ietf-mmusic-rfc2326bis]. 298 RTT: Round Trip Times. 300 SDP: Session Description Protocol, see [RFC4566]. 302 SSRC: Synchronization source in RTP, see [RFC3550]. 304 2. Detecting the loss of NAT mappings 306 Several NAT traversal techniques in the next chapter make use of the 307 fact that the NAT UDP mapping's external address and port can be 308 discovered. This information is then utilized to traverse the NAT 309 box. However any such information is only good while the mapping is 310 still valid. As the IAB's UNSAF document [RFC3424] points out, the 311 mapping can either timeout or change its properties. It is therefore 312 important for the NAT traversal solutions to handle the loss or 313 change of NAT mappings, according to RFC3424. 315 First, since NATs may also dynamically reclaim or readjust address/ 316 port translations, "keep-alive" and periodic re-polling may be 317 required according to RFC 3424. Secondly, it is possible to detect 318 and recover from the situation where the mapping has been changed or 319 removed. The loss of a mapping can be detected when no traffic 320 arrives for a while. Below we will give some recommendation on how 321 to detect loss of NAT mappings when using RTP/RTCP under RTSP 322 control. 324 A RTP session normally has both RTP and RTCP streams. The loss of a 325 RTP mapping can only be detected when expected traffic does not 326 arrive. If a client does not receive data within a few seconds after 327 having received the "200 OK" response to a PLAY request, there are 328 likely some middleboxes blocking the traffic. However, for a 329 receiver to be more certain to detect the case where no RTP traffic 330 was delivered due to NAT trouble, one should monitor the RTCP Sender 331 reports. The sender report carries a field telling how many packets 332 the server has sent. If that has increased and no RTP packets has 333 arrived for a few seconds it is likely the RTP mapping has been 334 removed. 336 The loss of mapping for RTCP is simpler to detect. RTCP is normally 337 sent periodically in each direction, even during the RTSP ready 338 state. If RTCP packets are missing for several RTCP intervals, the 339 mapping is likely lost. Note that if neither RTCP packets nor RTSP 340 messages are received by the RTSP server for a while, the RTSP server 341 has the option to delete the corresponding RTP session, SSRC and RTSP 342 session ID, because either the client can not get through a middle 343 box NAT/Firewall, or that the client is mal-functioning. 345 3. Requirements on Solutions 347 This section considers the set of requirements for the evaluation of 348 RTSP NAT traversal solutions. 350 RTSP is a client-server protocol. Typically service providers deploy 351 RTSP servers in the public address realm. However, there are use 352 cases where the reverse is true: RTSP clients are connecting from 353 public address realm to RTSP servers behind home NATs. This is the 354 case for instance when home surveillance cameras running as RTSP 355 servers intend to stream video to cell phone users in the public 356 address realm through a home NAT. In terms of requirements, the 357 first requirement should be to solve the RTSP NAT traversal problem 358 for RTSP servers deployed in a public network, i.e. no NAT at the 359 server side. 361 The list of feature requirements for RTSP NAT solutions are given 362 below: 364 1. Must work for all flavors of NATs, including NATs with Address 365 and Port-Dependent Filtering. 367 2. Must work for firewalls (subject to pertinent firewall 368 administrative policies), including those with ALGs. 370 3. Should have minimal impact on clients in the open and not dual- 371 hosted. RTSP dual-hosting means that the RTSP signalling 372 protocol and the media protocol (e.g. RTP) are implemented on 373 different computers with different IP addresses. 375 * For instance, no extra delay from RTSP connection till arrival 376 of media 378 4. Should be simple to use/implement/administer so people actually 379 turn them on 381 * Otherwise people will resort to TCP tunneling through NATs 383 * Discovery of the address(es) assigned by NAT should happen 384 automatically, if possible 386 5. Should authenticate dual-hosted client transport handler to 387 prevent DDoS attacks. 389 The last requirement addresses the Distributed Denial-of-Service 390 (DDoS) threat, which relates to NAT traversal as explained below. 392 During NAT traversal, when the RTSP server determines the media 393 destination (address and port) for the client, the result may be that 394 the public IP address of the RTP receiver host is different than the 395 public IP address of the RTSP client host. This posts a DDoS threat 396 that has significant amplification potentials because the RTP media 397 streams in general consist of large number of IP packets. DDoS 398 attacks occur if the attacker fakes the messages in the NAT traversal 399 mechanism to trick the RTSP server into believing that the client's 400 RTP receiver is located on a separate host. For example, user A may 401 use his RTSP client to direct the RTSP server to send video RTP 402 streams to target.example.com in order to degrade the services 403 provided by target.example.com. Note a simple preventative measure 404 commonly deployed is for the RTSP server to disallow the cases where 405 the client's RTP receiver has a different public IP address than that 406 of the RTSP client. With the increased deployment of NAT middleboxes 407 by operators, i.e. carrier grade NAT (CGN), the reusing of a public 408 IP address for many customers reduces the protection provided. Also 409 in some applications (e.g., centralized conferencing), dual-hosted 410 RTSP/RTP clients have valid use cases. The key is how to 411 authenticate the messages exchanged during the NAT traversal process. 413 4. NAT Traversal Techniques 415 There exists a number of potential NAT traversal techniques that can 416 be used to allow RTSP to traverse NATs. They have different features 417 and are applicable to different topologies; their costs are also 418 different. They also vary in security levels. In the following 419 sections, each technique is outlined with discussions on the 420 corresponding advantages and disadvantages. 422 The main evaluation was done prior to 2007 and are based on what was 423 available then. This section includes NAT traversal techniques that 424 have not been formally specified anywhere else. The overview section 425 of this document may be the only publicly available specification of 426 some of the NAT traversal techniques. However that is not a real 427 barrier against doing an evaluation of the NAT traversal technique. 428 Some other techniques have been recommended against or are no longer 429 possible due to standardization works' outcome or their failure to 430 progress within IETF after the initial evaluation in this document, 431 e.g. RTP No-Op [I-D.ietf-avt-rtp-no-op]. 433 4.1. Stand-Alone STUN 435 4.1.1. Introduction 437 Session Traversal Utilities for NAT (STUN) [RFC5389] is a 438 standardized protocol that allows a client to use secure means to 439 discover the presence of a NAT between itself and the STUN server. 440 The client uses the STUN server to discover the address mappings 441 assigned by the NAT. STUN is a client-server protocol. The STUN 442 client sends a request to a STUN server and the server returns a 443 response. There are two types of STUN messages - Binding Requests 444 and Indications. Binding requests are used when determining a 445 client's external address and solicits a response from the STUN 446 server with the seen address. 448 The first version of STUN [RFC3489] included categorization and 449 parameterization of NATs. This was abandoned in the updated version 450 [RFC5389] due to it being unreliable and brittle. Some of the below 451 discussed methods are based on RFC3489 functionality which will be 452 called out and the downside of that will be part of the 453 characterization. 455 4.1.2. Using STUN to traverse NAT without server modifications 457 This section describes how a client can use STUN to traverse NATs to 458 RTSP servers without requiring server modifications. Note that this 459 method has limited applicability and requires the server to be 460 available in the external/public address realm in regards to the 461 client located behind a NAT(s). 463 Limitations: 465 o The server must be located in either a public address realm or the 466 next hop external address realm in regards to the client. 468 o The client may only be located behind NATs that perform "Endpoint- 469 Independent" or "Address-Dependent" Mappings. Clients behind NATs 470 that do "Address and Port-Dependent" Mappings cannot use this 471 method. See [RFC4787] for full definition of these terms. 473 o Based on the discontinued middlebox classification of the replaced 474 STUN specification [RFC3489]. Thus brittle and unreliable. 476 Method: 478 A RTSP client using RTP transport over UDP can use STUN to traverse a 479 NAT(s) in the following way: 481 1. Use STUN to try to discover the type of NAT, and the timeout 482 period for any UDP mapping on the NAT. This is recommend to be 483 performed in the background as soon as IP connectivity is 484 established. If this is performed prior to establishing a 485 streaming session the delays in the session establishment will be 486 reduced. If no NAT is detected, normal SETUP should be used. 488 2. The RTSP client determines the number of UDP ports needed by 489 counting the number of needed media transport protocols sessions 490 in the multi-media presentation. This information is available 491 in the media description protocol, e.g. SDP [RFC4566]. For 492 example, each RTP session will in general require two UDP ports, 493 one for RTP, and one for RTCP. 495 3. For each UDP port required, establish a mapping and discover the 496 public/external IP address and port number with the help of the 497 STUN server. A successful mapping looks like: client's local 498 address/port <-> public address/port. 500 4. Perform the RTSP SETUP for each media. In the transport header 501 the following parameter should be included with the given values: 502 "dest_addr" [I-D.ietf-mmusic-rfc2326bis] or "destination" + 503 "client_port" [RFC2326] with the public/external IP address and 504 port pair for both RTP and RTCP. To be certain that this works 505 servers must allow a client to setup the RTP stream on any port, 506 not only even ports and with non-contiguous port numbers for RTP 507 and RTCP. This requires the new feature provided in the update 508 to RFC2326 [I-D.ietf-mmusic-rfc2326bis]. The server should 509 respond with a transport header containing an "src_addr" or 510 "source" + "server_port" parameters with the RTP and RTCP source 511 IP address and port of the media stream. 513 5. To keep the mappings alive, the client should periodically send 514 UDP traffic over all mappings needed for the session. For the 515 mapping carrying RTCP traffic the periodic RTCP traffic are 516 likely enough. For mappings carrying RTP traffic and for 517 mappings carrying RTCP packets at too low a frequency, keep-alive 518 messages should be sent. As keep alive messages, one could use 519 the RTP No-Op packet [I-D.ietf-avt-rtp-no-op] to the streaming 520 server's discard port (port number 9). The drawback of using RTP 521 No-Op is that the payload type number must be dynamically 522 assigned through RTSP first. Otherwise STUN could be used for 523 the keep-alive as well as empty UDP packets. 525 If a UDP mapping is lost, the above discovery process must be 526 repeated. The media stream also needs to be SETUP again to change 527 the transport parameters to the new ones. This will cause a glitch 528 in media playback. 530 To allow UDP packets to arrive from the server to a client behind a 531 "Address Dependent" filtering NAT, the client must first send a UDP 532 packet to establish filtering state in the NAT. The client, before 533 sending a RTSP PLAY request, must send a so called hole-punching 534 packet (such as a RTP No-Op packet) on each mapping, to the IP 535 address given as the servers source address. To create minimum 536 problems for the server these UDP packets should be sent to the 537 server's discard port (port number 9). Since UDP packets are 538 inherently unreliable, to ensure that at least one UDP message passes 539 the NAT, hole-punching packets should be retransmitted a reasonable 540 number of times. 542 For an "Address and Port Dependent" filtering NAT the client must 543 send messages to the exact ports used by the server to send UDP 544 packets before sending a RTSP PLAY request. This makes it possible 545 to use the above described process with the following additional 546 restrictions: for each port mapping, hole-punching packets need to be 547 sent first to the server's source address/port. To minimize 548 potential effects on the server from these messages the following 549 type of hole punching packets must be sent. RTP: an empty or less 550 than 12 bytes UDP packet. RTCP: A correctly formatted RTCP RR or SR 551 message. The above described adaptations for restricted NATs will 552 not work unless the server includes the "src_addr" in the "Transport" 553 header (which is the "source" transport parameter in RFC2326). 555 This method is brittle because it assumes one can use STUN to 556 classify the NAT behavior, which was found to be problematic 557 [RFC5389]. If the NAT changes the properties of the existing mapping 558 and filtering state for example due to load, then the methods will 559 fail. 561 4.1.3. ALG considerations 563 If a NAT supports RTSP ALG (Application Level Gateway) and is not 564 aware of the STUN traversal option, service failure may happen, 565 because a client discovers its public IP address and port numbers, 566 and inserts them in its SETUP requests. When the RTSP ALG processes 567 the SETUP request it may change the destination and port number, 568 resulting in unpredictable behavior. An ALG should not update 569 address fields which contains addresses other than the NATs internal 570 address domain. In cases where the ALG modifies fields unnecessarily 571 two alternatives exist: 573 1. Use TLS to encrypt the RTSP TCP connection to prevent the ALG 574 from reading and modifying the RTSP messages. 576 2. Turn off the STUN based NAT traversal mechanism 577 As it may be difficult to determine why the failure occurs, the usage 578 of TLS protected RTSP message exchange at all times would avoid this 579 issue. 581 4.1.4. Deployment Considerations 583 For the Stand-Alone usage of STUN the following applies: 585 Advantages: 587 o STUN is a solution first used by SIP applications. As shown 588 above, with little or no changes, the RTSP application can re-use 589 STUN as a NAT traversal solution, avoiding the pit-fall of solving 590 a problem 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 willingly to 892 receive the media, thus protecting itself from performing 893 unknowingly an 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 client 919 should be able to keep RTCP open but STUN will also be used based on 920 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 them can be established. This 953 includes servers behind NATs. (Note that a proxy between address 954 domains may be required to get TCP through). 956 o Improves defenses against DDoS attacks, as media receiving client 957 requires authentications, via STUN on its media reception ports. 959 Disadvantages: 961 o Increases the setup delay with at least the amount of time it 962 takes for the server to perform its STUN requests. 964 o Assumes that it is possible to de-multiplex between the packets of 965 the media protocol and STUN packets. 967 o Has fairly high implementation burden put on both RTSP server and 968 client. However, several Open Source ICE implementations do 969 exist, such as [NICE][PJNATH]. 971 4.3.5. Security Consideration 973 One should review the security consideration section of ICE and STUN 974 to understand that ICE contains some potential issues. However these 975 can be avoided by correctly using ICE in RTSP. In fact ICE does help 976 avoid the DDoS attack issue with RTSP substantially as it reduces the 977 possibility for a DDoS using RTSP servers to attackers that are on- 978 path between the RTSP server and the target and capable of 979 intercepting the STUN connectivity check packets and correctly send a 980 response to the server. 982 4.4. Latching 984 4.4.1. Introduction 986 Latching is a NAT traversal solution that is based on requiring RTSP 987 clients to send UDP packets to the server's media output ports. 988 Conventionally, RTSP servers send RTP packets in one direction: from 989 server to client. Latching is similar to connection-oriented 990 traffic, where one side (e.g., the RTSP client) first "connects" by 991 sending a RTP packet to the other side's RTP port, the recipient then 992 replies to the originating IP and port. This method is also referred 993 to as "Late binding". It requires that all RTP/RTCP transport is 994 done symmetrical, i.e. Symmetric RTP [RFC4961]. 996 Specifically, when the RTSP server receives the latching packet 997 (a.k.a. hole-punching packet, since it is used to punch a hole in the 998 Firewall/NAT and to aid the server for port binding and address 999 mapping) from its client, it copies the source IP and Port number and 1000 uses them as delivery address for media packets. By having the 1001 server send media traffic back the same way as the client's packet 1002 are sent to the server, address mappings will be honored. Therefore 1003 this technique works for all types of NATs, given that the server is 1004 not behind a NAT. However, it does require server modifications. 1005 Unless there is built-in protection mechanism, latching is very 1006 vulnerable to DDoS attacks, because attackers can simply forge the 1007 source IP & Port of the latching packet. Using the rule for 1008 restricting IP address to the one of the signaling connection will 1009 need to be applied here also. However, that does not protect against 1010 hijacking from another client behind the same NAT. This can become a 1011 serious issue in deployments with CGNs. 1013 4.4.2. Necessary RTSP extensions 1015 To support Latching, the RTSP signaling must be extended to allow the 1016 RTSP client to indicate that it will use Latching. The client also 1017 needs to be able to signal its RTP SSRC to the server in its SETUP 1018 request. The RTP SSRC is used to establish some basic level of 1019 security against hijacking attacks or simply avoid mis-association 1020 when multiple clients are behind the same NAT. Care must be taken in 1021 choosing clients' RTP SSRC. First, it must be unique within all the 1022 RTP sessions belonging to the same RTSP session. Secondly, if the 1023 RTSP server is sending out media packets to multiple clients from the 1024 same send port, the RTP SSRC needs to be unique amongst those 1025 clients' RTP sessions. Recognizing that there is a potential that 1026 RTP SSRC collisions may occur, the RTSP server must be able to signal 1027 to a client that a collision has occurred and that it wants the 1028 client to use a different RTP SSRC carried in the SETUP response or 1029 use unique ports per RTSP session. Using unique ports limits an RTSP 1030 server in the number of sessions it can simultaneously handle per 1031 interface IP addresses. 1033 4.4.3. Deployment Considerations 1035 Advantages: 1037 o Works for all types of client-facing NATs. (Requirement 1 in 1038 Section 3). 1040 o Has no interaction problems with any RTSP ALG changing the 1041 client's information in the transport header. 1043 Disadvantages: 1045 o Requires modifications to both RTSP server and client. 1047 o Limited to work with servers that have an public IP address. 1049 o The format of the RTP packet for "connection setup" (a.k.a 1050 Latching packet) is yet to be defined. One possibility is to use 1051 RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op]. 1053 o SSRC management if RTP is used for latching due to risk for mis- 1054 association of clients to RTSP sessions at the server if SSRC 1055 collision occurs. 1057 o Has worse security situation than STUN due to lack of STUN message 1058 authentication and will need to use address restrictions. 1060 4.4.4. Security Consideration 1062 Latching's major security issue is that RTP streams can be hijacked 1063 and directed towards any target that the attacker desires unless 1064 address restrictions are used. In the case of NATs with multiple 1065 clients on the inside of them, hijacking can still occur. This 1066 becomes a significant threat in the context of carrier grade NATs 1067 (CGN). 1069 The most serious security problem is the deliberate attack with the 1070 use of a RTSP client and Latching. The attacker uses RTSP to setup a 1071 media session. Then it uses Latching with a spoofed source address 1072 of the intended target of the attack. There is no defense against 1073 this attack other than restricting the possible address a latching 1074 packet can come from to the same as the RTSP TCP connection are from. 1075 This prevents Latching to be used in use cases that require different 1076 addresses for media destination and signalling. 1078 A hijack attack can also be performed in various ways. The basic 1079 attack is based on the ability to read the RTSP signaling packets in 1080 order to learn the address and port the server will send from and 1081 also the SSRC the client will use. Having this information the 1082 attacker can send its own Latching packets containing the correct RTP 1083 SSRC to the correct address and port on the server. The RTSP server 1084 will then use the source IP and port from the Latching packet as the 1085 destination for the media packets it sends. 1087 Another variation of this attack is for a man in the middle to modify 1088 the RTP latching packet being sent by a client to the server by 1089 simply changing the source IP to the target one desires to attack. 1091 One can fend off the first attack by applying encryption to the RTSP 1092 signaling transport. However, the second variation is impossible to 1093 defend against. As a NAT re-writes the source IP and port this 1094 cannot be authenticated, but authentication is required in order to 1095 protect against this type of DoS attack. 1097 Yet another issues is that these attacks also can be used to deny the 1098 client the service it desires from the RTSP server completely. For a 1099 man in the middle capable of reading the signaling traffic or 1100 intercepting the latching packets can completely deny the client 1101 service by modifying or originating latching packets of itself. 1103 The amount of random non-guessable material in the latching packet 1104 determines how well Latching can fend off stream-hijacking performed 1105 by parties that are not "man-in-the-middle". This proposal uses the 1106 32-bit RTP SSRC field to this effect. Therefore it is important that 1107 this field is derived with a non-predictable random number generator. 1108 It should not be possible by knowing the algorithm used and a couple 1109 of basic facts, to derive what random number a certain client will 1110 use. 1112 An attacker not knowing the SSRC but aware of which port numbers that 1113 a server sends from can deploy a brute force attack on the server by 1114 testing a lot of different SSRCs until it finds a matching one. 1115 Therefore a server could implement functionality that blocks packets 1116 to ports or from sources that receive or send multiple Latching 1117 packets with different invalid SSRCs, especially when they are coming 1118 from the same IP/Port. Note that this mitigation in itself opens up 1119 a new venue for DoS attacks against legit users trying to latch. 1121 To improve the security against attackers the amount of random 1122 material could be increased. To achieve a longer random tag while 1123 still using RTP and RTCP, it will be necessary to develop RTP and 1124 RTCP payload formats for carrying the random material. 1126 4.5. A Variation to Latching 1128 4.5.1. Introduction 1130 Latching as described above requires the usage of a valid RTP format 1131 as the Latching packet, i.e. the first packet that the client sends 1132 to the server to set up virtual RTP connection. There existed no 1133 appropriate RTP packet format for this purpose, although the No-Op 1134 format was a proposal to fix the problem [I-D.ietf-avt-rtp-no-op]. 1135 However, that work was abandoned. There exists a RFC that discusses 1136 the implication of different type of packets as keep-alives for RTP 1137 [RFC6263] and its findings are very relevant to the format of the 1138 Latching packet. 1140 Meanwhile, there has been NAT/Firewall traversal techniques deployed 1141 in the wireless streaming market place that use non-RTP messages as 1142 Latching packets. This section describes a variant based on a subset 1143 of those solutions that alters the previously described Latching 1144 solution. 1146 4.5.2. Necessary RTSP extensions 1148 In this variation of Latching, the Latching packet is a small UDP 1149 packet that does not contain an RTP header. In response to client's 1150 Latching packet, the RTSP server sends back a similar Latching packet 1151 as a confirmation so the client can stop the so called "connection 1152 phase" of this NAT traversal technique. Afterwards, the client only 1153 has to periodically send Latching packets as keep-alive messages for 1154 the NAT mappings. 1156 The server listens on its RTP-media output port, and tries to decode 1157 any received UDP packet as Latching packet. This is valid since an 1158 RTSP server is not expecting RTP traffic from the RTSP client. Then, 1159 it can correlate the Latching packet with the RTSP client's session 1160 ID or the client's SSRC, and record the NAT bindings accordingly. 1161 The server then sends a Latching packet as the response to the 1162 client. 1164 The Latching packet can contain the SSRC to identify the RTP stream, 1165 and care must be taken if the packet is bigger than 12 bytes, 1166 ensuring that it is distinctively different from RTP packets, whose 1167 header size is 12 bytes. 1169 RTSP signaling can be added to do the following: 1171 1. Enable or disable such Latching message exchanges. When the 1172 Firewall/NAT has an RTSP-aware ALG, it is possible to disable 1173 Latching message exchange and let the ALG work out the address 1174 and port mappings. 1176 2. Configure the number of re-tries and the re-try interval of the 1177 Latching message exchanges. 1179 4.5.3. Deployment Considerations 1181 This approach has the following advantages when compared with the 1182 Latching approach (Section 4.4): 1184 1. There is no need to define RTP payload format for Firewall 1185 traversal, therefore it is simple to use, implement and 1186 administer (Requirement 4 in Section 3), instead a Latching 1187 protocol must be defined. 1189 2. When properly defined, this kind of Latching packet exchange can 1190 also authenticate RTP receivers, to prevent hijacking attacks. 1192 This approach has the following disadvantages when compared with the 1193 Latching approach: 1195 1. RTP traffic is normally accompanied by RTCP traffic. This 1196 approach needs to rely on RTCP RRs and SRs to enable NAT 1197 traversal for RTCP endpoints, use RTP/RTCP Multiplexing 1198 [RFC5761], or use the same type of Latching packets also for RTCP 1199 endpoints. 1201 2. The server's sender SSRC for the RTP stream or other session 1202 Identity information must be signaled in RTSP's SETUP response, 1203 in the Transport header of the RTSP SETUP response. 1205 4.5.4. Security Considerations 1207 Compared to the security properties of Latching this variant is 1208 slightly improved. First of all it allows for a larger random field 1209 in the Latching packets which makes it more unlikelier for an off- 1210 path attacker to succeed in a hi-jack attack. Secondly the 1211 confirmation allows the client to know when Latching works and when 1212 it didn't and thus restart the Latching process by updating the SSRC. 1213 Thirdly if an authentication mechanism are included in the latching 1214 packet hijacking attacks can be prevented. 1216 Still the main security issue remain that the RTSP server can't know 1217 that the source address in the latching packet was coming from a RTSP 1218 client wanting to receive media and not one that likes to direct the 1219 media traffic to an DoS target. 1221 4.6. Three Way Latching 1223 4.6.1. Introduction 1225 The three way Latching is an attempt to try to resolve the most 1226 significant security issues for both previously discussed variants of 1227 Latching. By adding a server request response exchange directly 1228 after the initial latching the server can verify that the target 1229 address present in the latching packet is an active listener and 1230 confirm its desire to establish a media flow. 1232 4.6.2. Necessary RTSP extensions 1234 Uses the same RTSP extensions as the alternative latching method 1235 (Section 4.5) uses. The extensions for this variant are only in the 1236 format and transmission of the Latching packets. 1238 The client to server latching packet is similar to the Alternative 1239 Latching (Section 4.5), i.e. an UDP packet with some session 1240 identifier and a random value. When the server responds to the 1241 Latching packet with a Latching confirmation, it includes a random 1242 value (Nonce) of its own in addition to echoing back the one the 1243 client sent. Then a third messages is added to the exchange. The 1244 client acknowledges the reception of the Latching confirmation 1245 message and echoes back the server's nonce. Thus confirming that the 1246 Latched address goes to a RTSP client that initiated the latching and 1247 is actually present at that address. The RTSP server will refuse to 1248 send any media until the Latching Acknowledgement has been received 1249 with a valid nonce. 1251 4.6.3. Deployment Considerations 1253 A solution with a 3-way handshake and its own Latching packets can be 1254 compared with the ICE-based solution (Section 4.3) and have the 1255 following differences: 1257 o Only works for servers with public IP addresses compared to any 1258 type of server 1260 o May be simpler to implement due to the avoidance of the ICE 1261 prioritization and check-board mechanisms. 1263 However, a 3-way Latching protocol is very similar to using STUN in 1264 both directions as Latching and verification protocol. Using STUN 1265 would remove the need for implementing a new protocol. 1267 4.7. Application Level Gateways 1269 4.7.1. Introduction 1271 An Application Level Gateway (ALG) reads the application level 1272 messages and performs necessary changes to allow the protocol to work 1273 through the middle box. However this behavior has some problems in 1274 regards to RTSP: 1276 1. It does not work when the RTSP protocol is used with end-to-end 1277 security. As the ALG can't inspect and change the application 1278 level messages the protocol will fail due to the middle box. 1280 2. ALGs need to be updated if extensions to the protocol are added. 1281 Due to deployment issues with changing ALGs this may also break 1282 the end-to-end functionality of RTSP. 1284 Due to the above reasons it is not recommended to use an RTSP ALG in 1285 NATs. This is especially important for NATs targeted to home users 1286 and small office environments, since it is very hard to upgrade NATs 1287 deployed in home or SOHO (small office/home office) environment. 1289 4.7.2. Outline On how ALGs for RTSP work 1290 In this section, we provide a step-by-step outline on how one could 1291 go about writing an ALG to enable RTSP to traverse a NAT. 1293 1. Detect any SETUP request. 1295 2. Try to detect the usage of any of the NAT traversal methods that 1296 replace the address and port of the Transport header parameters 1297 "destination" or "dest_addr". If any of these methods are used, 1298 then the ALG should not change the address. Ways to detect that 1299 these methods are used are: 1301 * For embedded STUN, it would be to watch for a feature tag, 1302 like "nat.stun". If any of those exists in the "supported", 1303 "proxy-require", or "require" headers of the RTSP exchange. 1305 * For stand alone STUN and TURN based solutions: This can be 1306 detected by inspecting the "destination" or "dest_addr" 1307 parameter. If it contains either one of the NAT's external IP 1308 addresses or a public IP address then such a solution is in 1309 use. However if multiple NATs are used this detection may 1310 fail. Remapping should only be done for addresses belonging 1311 to the NAT's own private address space. 1313 Otherwise continue to the next step. 1315 3. Create UDP mappings (client given IP/port <-> external IP/port) 1316 where needed for all possible transport specifications in the 1317 transport header of the request found in (1). Enter the external 1318 address and port(s) of these mappings in transport header. 1319 Mappings shall be created with consecutive public port numbers 1320 starting on an even number for RTP for each media stream. 1321 Mappings should also be given a long timeout period, at least 5 1322 minutes. 1324 4. When the SETUP response is received from the server, the ALG may 1325 remove the unused UDP mappings, i.e. the ones not present in the 1326 transport header. The session ID should also be bound to the UDP 1327 mappings part of that session. 1329 5. If SETUP response settles on RTP over TCP or RTP over RTSP as 1330 lower transport, do nothing: let TCP tunneling take care of NAT 1331 traversal. Otherwise go to next step. 1333 6. The ALG should keep the UDP mappings belonging to the RTSP 1334 session as long as: an RTSP messages with the session's ID has 1335 been sent in the last timeout interval, or a UDP messages has 1336 been sent on any of the UDP mappings during the last timeout 1337 interval. 1339 7. The ALG may remove a mapping as soon a TEARDOWN response has been 1340 received for that media stream. 1342 4.7.3. Deployment Considerations 1344 Advantage: 1346 o No impact on either client or server 1348 o Can work for any type of NATs 1350 Disadvantage: 1352 o When deployed they are hard to update to reflect protocol 1353 modifications and extensions. If not updated they will break the 1354 functionality. 1356 o When end-to-end security is used, the ALG functionality will fail. 1358 o Can interfere with other types of traversal mechanisms, such as 1359 STUN. 1361 Transition: 1363 An RTSP ALG will not be phased out in any automatic way. It must be 1364 removed, probably through the removal of the NAT it is associated 1365 with. 1367 4.7.4. Security Considerations 1369 An ALG will not work with deployment of end-to-end RTSP signaling 1370 security. Therefore deployment of ALG will likely result in clients 1371 located behind NATs not using end-to-end security. 1373 The creation of an UDP mapping based on the signalling message has 1374 some potential security implications. First of all if the RTSP 1375 client releases its ports and another application are assigned these 1376 instead it could receive RTP media as long as the mappings exist and 1377 the RTSP server has failed to be signalled or notice the lack of 1378 client response. 1380 An NAT with RTSP ALG that assigns mappings based on SETUP requests 1381 could potentially become victim of an resource exhaustion attack. If 1382 an attacker creates a lot of RTSP sessions, even without starting 1383 media transmission could exhaust the pool of available UDP ports on 1384 the NAT. Thus only a limited number of UDP mappings should be 1385 allowed to be created by the RTSP ALG. 1387 4.8. TCP Tunneling 1389 4.8.1. Introduction 1391 Using a TCP connection that is established from the client to the 1392 server ensures that the server can send data to the client. The 1393 connection opened from the private domain ensures that the server can 1394 send data back to the client. To send data originally intended to be 1395 transported over UDP requires the TCP connection to support some type 1396 of framing of the media data packets. Using TCP also results in the 1397 client having to accept that real-time performance can be impacted. 1398 TCP's problem of ensuring timely delivery was one of the reasons why 1399 RTP was developed. Problems that arise with TCP are: head-of-line 1400 blocking, delay introduced by retransmissions, highly varying rate 1401 due to the congestion control algorithm. If sufficient amount of 1402 buffering (several seconds) in the receiving client can be tolerated 1403 then TCP clearly can work. 1405 4.8.2. Usage of TCP tunneling in RTSP 1407 The RTSP core specification [I-D.ietf-mmusic-rfc2326bis] supports 1408 interleaving of media data on the TCP connection that carries RTSP 1409 signaling. See section 14 in [I-D.ietf-mmusic-rfc2326bis] for how to 1410 perform this type of TCP tunneling. There also exists another way of 1411 transporting RTP over TCP defined in Appendix C.2 in 1412 [I-D.ietf-mmusic-rfc2326bis]. For signaling and rules on how to 1413 establish the TCP connection in lieu of UDP, see appendix C.2 in 1414 [I-D.ietf-mmusic-rfc2326bis]. This is based on the framing of RTP 1415 over the TCP connection as described in RFC 4571 [RFC4571]. 1417 4.8.3. Deployment Considerations 1419 Advantage: 1421 o Works through all types of NATs where the RTSP server in not NATed 1422 or at least reachable like it was not. 1424 Disadvantage: 1426 o Functionality needs to be implemented on both server and client. 1428 o Will not always meet multimedia stream's real-time requirements. 1430 Transition: 1432 The tunneling over RTSP's TCP connection is not planned to be phased- 1433 out. It is intended to be a fallback mechanism and for usage when 1434 total media reliability is desired, even at the potential price of 1435 loss of real-time properties. 1437 4.8.4. Security Considerations 1439 The TCP tunneling of RTP has no known security problems besides those 1440 already presented in the RTSP specification. It is not possible to 1441 get any amplification effect for denial of service attacks due to 1442 TCP's flow control. A possible security consideration, when session 1443 media data is interleaved with RTSP, would be the performance 1444 bottleneck when RTSP encryption is applied, since all session media 1445 data also needs to be encrypted. 1447 4.9. TURN (Traversal Using Relay NAT) 1449 4.9.1. Introduction 1451 Traversal Using Relay NAT (TURN) [RFC5766] is a protocol for setting 1452 up traffic relays that allow clients behind NATs and firewalls to 1453 receive incoming traffic for both UDP and TCP. These relays are 1454 controlled and have limited resources. They need to be allocated 1455 before usage. TURN allows a client to temporarily bind an address/ 1456 port pair on the relay (TURN server) to its local source address/port 1457 pair, which is used to contact the TURN server. The TURN server will 1458 then forward packets between the two sides of the relay. 1460 To prevent DoS attacks on either recipient, the packets forwarded are 1461 restricted to the specific source address. On the client side it is 1462 restricted to the source setting up the allocation. On the external 1463 side this is limited to the source address/port pair that have been 1464 given permission by the TURN client creating the allocation. Packets 1465 from any other source on this address will be discarded. 1467 Using a TURN server makes it possible for a RTSP client to receive 1468 media streams from even an unmodified RTSP server. However the 1469 problem is those RTSP servers most likely restrict media destinations 1470 to no other IP address than the one the RTSP message arrives from. 1471 This means that TURN could only be used if the server knows and 1472 accepts that the IP belongs to a TURN server and the TURN server 1473 can't be targeted at an unknown address or also the RTSP connection 1474 is relayed through the same TURN server. 1476 4.9.2. Usage of TURN with RTSP 1478 To use a TURN server for NAT traversal, the following steps should be 1479 performed. 1481 1. The RTSP client connects with the RTSP server. The client 1482 retrieves the session description to determine the number of 1483 media streams. To avoid the issue with having RTSP connection 1484 and media traffic from different addresses also the TCP 1485 connection must be done through the same TURN server as the one 1486 in the next step. This will require the usage of TURN for TCP 1487 [RFC6062]. 1489 2. The client establishes the necessary bindings on the TURN server. 1490 It must choose the local RTP and RTCP ports that it desires to 1491 receive media packets. TURN supports requesting bindings of even 1492 port numbers and continuous ranges. 1494 3. The RTSP client uses the acquired address and port allocations in 1495 the RTSP SETUP request using the destination header. 1497 4. The RTSP Server sends the SETUP reply, which must include the 1498 transport headers src_addr parameter (source and port in RTSP 1499 1.0). Note that the server is required to have a mechanism to 1500 verify that it is allowed to send media traffic to the given 1501 address. 1503 5. The RTSP Client uses the RTSP Server's response to create TURN 1504 permissions for the server's media traffic. 1506 6. The client requests that the server starts playing. The server 1507 starts sending media packets to the given destination address and 1508 ports. 1510 7. Media packets arrive at the TURN server on the external port; If 1511 the packets match an established permission, the TURN server 1512 forwards the media packets to the RTSP client. 1514 8. If the client pauses and media is not sent for about 75% of the 1515 mapping timeout the client should use TURN to refresh the 1516 bindings. 1518 4.9.3. Deployment Considerations 1520 Advantages: 1522 o Does not require any server modifications given that the server 1523 includes the src_addr header in the SETUP response. 1525 o Works for any type of NAT as long as the RTSP server has public 1526 reachable IP address. 1528 Disadvantage: 1530 o Requires another network element, namely the TURN server. 1532 o A TURN server for RTSP may not scale since the number of sessions 1533 it must forward is proportional to the number of client media 1534 sessions. 1536 o TURN server becomes a single point of failure. 1538 o Since TURN forwards media packets, it necessarily introduces 1539 delay. 1541 o An RTSP ALG may change the necessary destinations parameter. This 1542 will cause the media traffic to be sent to the wrong address. 1544 Transition: 1546 TURN is not intended to be phased-out completely, see Section 19 of 1547 [RFC5766]. However the usage of TURN could be reduced when the 1548 demand for having NAT traversal is reduced. 1550 4.9.4. Security Considerations 1552 The TURN server can become part of a denial of service attack towards 1553 any victim. To perform this attack the attacker must be able to 1554 eavesdrop on the packets from the TURN server towards a target for 1555 the DoS attack. The attacker uses the TURN server to setup a RTSP 1556 session with media flows going through the TURN server. The attacker 1557 is in fact creating TURN mappings towards a target by spoofing the 1558 source address of TURN requests. As the attacker will need the 1559 address of these mappings he must be able to eavesdrop or intercept 1560 the TURN responses going from the TURN server to the target. Having 1561 these addresses, he can set up a RTSP session and start delivery of 1562 the media. The attacker must be able to create these mappings. The 1563 attacker in this case may be traced by the TURN username in the 1564 mapping requests. 1566 This attack requires that the attacker has access to a user account 1567 on the TURN server to be able set up the TURN mappings. To prevent 1568 this attack the RTSP server needs to verify that the ultimate target 1569 destination accept this media stream. Which would require something 1570 like ICE's connectivity checks being run between the RTSP server and 1571 the RTSP client. 1573 5. Firewalls 1575 Firewalls exist for the purpose of protecting a network from traffic 1576 not desired by the firewall owner. Therefore it is a policy decision 1577 if a firewall will let RTSP and its media streams through or not. 1578 RTSP is designed to be firewall friendly in that it should be easy to 1579 design firewall policies to permit passage of RTSP traffic and its 1580 media streams. 1582 The firewall will need to allow the media streams associated with a 1583 RTSP session to pass through it. Therefore the firewall will need an 1584 ALG that reads RTSP SETUP and TEARDOWN messages. By reading the 1585 SETUP message the firewall can determine what type of transport and 1586 from where, the media stream packets will be sent. Commonly there 1587 will be the need to open UDP ports for RTP/RTCP. By looking at the 1588 source and destination addresses and ports the opening in the 1589 firewall can be minimized to the least necessary. The opening in the 1590 firewall can be closed after a TEARDOWN message for that session or 1591 the session itself times out. 1593 Simpler firewalls do allow a client to receive media as long as it 1594 has sent packets to the target. Depending on the security level this 1595 can have the same behavior as a NAT. The only difference is that no 1596 address translation is done. To use such a firewall a client would 1597 need to implement one of the above described NAT traversal methods 1598 that include sending packets to the server to open up the mappings. 1600 6. Comparison of NAT traversal techniques 1602 This section evaluates the techniques described above against the 1603 requirements listed in Section 3. 1605 In the following table, the columns correspond to the numbered 1606 requirements. For instance, the column under R1 corresponds to the 1607 first requirement in Section 3: must work for all flavors of NATs. 1608 The rows represent the different NAT/Firewall traversal techniques. 1609 Latch is short for Latching, "V. Latch" is short for "variation of 1610 Latching" as described in Section 4.5. "3-W Latch" is short for the 1611 Three Way Latching described in Section 4.6. 1613 A Summary of the requirements are: 1615 R1: Work for all flavors of NATs 1617 R2: Must work with Firewalls, including those with ALGs 1619 R3: Should have minimal impact on clients not behind NATs, counted 1620 in minimal number of additional RTTs 1622 R4: Should be simple to use, Implement and administer. 1624 R5: Should provide mitigation against DDoS attacks 1626 The following considerations are also added to requirements: 1628 C1: Will solution support both Clients and Servers behind NAT 1630 C2: Is the solution robust to changing NAT behaviors 1632 ------------+------+------+------+------+------+------+------+ 1633 | R1 | R2 | R3 | R4 | R5 | C1 | C2 | 1634 ------------+------+------+------+------+------+------+------+ 1635 STUN | No | Yes | 1 | Maybe| No | No | No | 1636 ------------+------+------+------+------+------+------+------+ 1637 Emb. STUN | Yes | Yes | 2 | Maybe| No | No | Yes | 1638 ------------+------+------+------+------+------+------+------+ 1639 ICE | Yes | Yes | 2.5 | No | Yes | Yes | Yes | 1640 ------------+------+------+------+------+------+------+------+ 1641 Latch | Yes | Yes | 1 | Maybe| No | No | Yes | 1642 ------------+------+------+------+------+------+------+------+ 1643 V. Latch | Yes | Yes | 1 | Yes | No | No | Yes | 1644 ------------+------+------+------+------+------+------+------+ 1645 3-W Latch | Yes | Yes | 1.5 | Maybe| Yes | No | Yes | 1646 ------------+------+------+------+------+------+------+------+ 1647 ALG |(Yes) | Yes | 0 | No | Yes | No | Yes | 1648 ------------+------+------+------+------+------+------+------+ 1649 TCP Tunnel | Yes | Yes | 1.5 | Yes | Yes | No | Yes | 1650 ------------+------+------+------+------+------+------+------+ 1651 TURN | Yes | Yes | 1 | No | Yes |(Yes) | Yes | 1652 ------------+------+------+------+------+------+------+------+ 1654 Figure 1: Comparison of fulfillment of requirements 1656 Looking at Figure 1 one would draw the conclusion that using TCP 1657 Tunneling or Three-Way Latching is the solutions that best fulfill 1658 the requirements. The different techniques were discussed in the 1659 MMUSIC WG. It was established that the WG would pursue an ICE based 1660 solution due to its generality and capability of handling also 1661 servers delivering media from behind NATs. TCP Tunneling is likely 1662 to be available as an alternative, due to its specification in the 1663 main RTSP specification. Thus it can be used if desired and the 1664 potential downsides of using TCP is acceptable in particular 1665 deployments. When it comes to Three-Way Latching it is a very 1666 competitive technique given that you don't need support for RTSP 1667 servers behind NATs. There were some discussion in the WG if the 1668 increased implementation burden of ICE is sufficiently motivated 1669 compared to a the Three-Way Latching solution for this generality. 1671 In the end the authors believe that reuse of ICE, the greater 1672 flexibility and anyway need to deploy a new solution was the decisive 1673 factors. 1675 The ICE based RTSP NAT traversal solution is specified in "A Network 1676 Address Translator (NAT) Traversal mechanism for media controlled by 1677 Real-Time Streaming Protocol (RTSP)" [I-D.ietf-mmusic-rtsp-nat]. 1679 7. IANA Considerations 1681 This document makes no request of IANA. 1683 Note to RFC Editor: this section may be removed on publication as an 1684 RFC. 1686 8. Security Considerations 1688 In the preceding sections we have discussed security merits of the 1689 different NAT/Firewall traversal methods for RTSP discussed here. In 1690 summary, the presence of NAT(s) is a security risk, as a client 1691 cannot perform source authentication of its IP address. This 1692 prevents the deployment of any future RTSP extensions providing 1693 security against hijacking of sessions by a man-in-the-middle. 1695 Each of the proposed solutions has security implications. Using STUN 1696 will provide the same level of security as RTSP with out transport 1697 level security and source authentications, as long as the server does 1698 not allow media to be sent to a different IP-address than the RTSP 1699 client request was sent from. Using Latching will have a higher risk 1700 of session hijacking or denial of service than normal RTSP. The 1701 reason is that there exists a probability that an attacker is able to 1702 guess the random bits that the client uses to prove its identity when 1703 creating the address bindings. This can be solved in the variation 1704 of Latching (Section 4.5) with authentication features. Still both 1705 those variants of Latching is vulnerable against deliberate attack 1706 from the RTSP client to redirect the media stream requested to any 1707 target assuming it can spoof the source address. This security 1708 vulnerability is solved by performing a Three-way Latching procedure 1709 as discussed in Section 4.6. The usage of an RTSP ALG does not in 1710 itself increase the risk for session hijacking. However the 1711 deployment of ALGs as the sole mechanism for RTSP NAT traversal will 1712 prevent deployment of end-to-end encrypted RTSP signaling. The usage 1713 of TCP tunneling has no known security problems. However, it might 1714 provide a bottleneck when it comes to end-to-end RTSP signaling 1715 security if TCP tunneling is used on an interleaved RTSP signaling 1716 connection. The usage of TURN has severe risk of denial of service 1717 attacks against a client. The TURN server can also be used as a 1718 redirect point in a DDoS attack unless the server has strict enough 1719 rules for who may create bindings. 1721 9. Acknowledgements 1723 The author would also like to thank all persons on the MMUSIC working 1724 group's mailing list that has commented on this document. Persons 1725 having contributed in such way in no special order to this protocol 1726 are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon, 1727 Amir Wolf, Anders Klemets, Flemming Andreasen, Ari Keranen, and Colin 1728 Perkins. Thomas Zeng would also like to give special thanks to Greg 1729 Sherwood of PacketVideo for his input into this memo. 1731 Section 1.1 contains text originally written for RFC 4787 by Francois 1732 Audet and Cullen Jennings. 1734 10. Informative References 1736 [I-D.ietf-avt-rtp-no-op] 1737 Andreasen, F., "A No-Op Payload Format for RTP", draft- 1738 ietf-avt-rtp-no-op-04 (work in progress), May 2007. 1740 [I-D.ietf-mmusic-rfc2326bis] 1741 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1742 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1743 (RTSP)", draft-ietf-mmusic-rfc2326bis-38 (work in 1744 progress), October 2013. 1746 [I-D.ietf-mmusic-rtsp-nat] 1747 Goldberg, J., Westerlund, M., and T. Zeng, "A Network 1748 Address Translator (NAT) Traversal mechanism for media 1749 controlled by Real-Time Streaming Protocol (RTSP)", draft- 1750 ietf-mmusic-rtsp-nat-17 (work in progress), Nov 2013. 1752 [NICE] , "Libnice - The GLib ICE implementation, 1753 http://nice.freedesktop.org/wiki/", May 2013. 1755 [PJNATH] , "PJNATH - Open Source ICE, STUN, and TURN Library, 1756 http://www.pjsip.org/pjnath/docs/html/", May 2013. 1758 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1759 August 1980. 1761 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1762 793, September 1981. 1764 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1765 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1767 [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May 1768 1999. 1770 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1771 Translator (NAT) Terminology and Considerations", RFC 1772 2663, August 1999. 1774 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1775 Address Translator (Traditional NAT)", RFC 3022, January 1776 2001. 1778 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1779 Self-Address Fixing (UNSAF) Across Network Address 1780 Translation", RFC 3424, November 2002. 1782 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1783 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1784 Through Network Address Translators (NATs)", RFC 3489, 1785 March 2003. 1787 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1788 Jacobson, "RTP: A Transport Protocol for Real-Time 1789 Applications", STD 64, RFC 3550, July 2003. 1791 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1792 Description Protocol", RFC 4566, July 2006. 1794 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1795 and RTP Control Protocol (RTCP) Packets over Connection- 1796 Oriented Transport", RFC 4571, July 2006. 1798 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1799 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1800 RFC 4787, January 2007. 1802 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 1803 BCP 131, RFC 4961, July 2007. 1805 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1806 (ICE): A Protocol for Network Address Translator (NAT) 1807 Traversal for Offer/Answer Protocols", RFC 5245, April 1808 2010. 1810 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1811 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1812 RFC 5382, October 2008. 1814 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1815 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1816 October 2008. 1818 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1819 Control Packets on a Single Port", RFC 5761, April 2010. 1821 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1822 Relays around NAT (TURN): Relay Extensions to Session 1823 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1825 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 1826 around NAT (TURN) Extensions for TCP Allocations", RFC 1827 6062, November 2010. 1829 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1830 Keeping Alive the NAT Mappings Associated with RTP / RTP 1831 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 1833 [STUN-IMPL] 1834 , "Open Source STUN Server and Client, 1835 http://sourceforge.net/projects/stun/", May 2013. 1837 Authors' Addresses 1838 Magnus Westerlund 1839 Ericsson 1840 Farogatan 6 1841 Stockholm SE-164 80 1842 Sweden 1844 Phone: +46 8 719 0000 1845 Email: magnus.westerlund@ericsson.com 1847 Thomas Zeng 1849 Email: thomas.zeng@gmail.com