idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 11. To ensure that the binding is not lost the client SHOULD send a empty RTP/UDP packet with PT=0 to the server every tenth of the mapping timeout time that has been discovered for the NAT. The discovery can be performed by using STUN. The client SHOULD not send these packets as long as the server transmit RTP packets to the client. Unless the NAT mappings has very short timeouts or the RTCP bandwidth is severely restricted the RTCP traffic should automatically keep its connection open. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 2003) is 7732 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '31' is mentioned on line 145, but not defined -- Looks like a reference, but probably isn't: 'TBW' on line 192 == Unused Reference: '5' is defined on line 763, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 780, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 783, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2326 (ref. '1') (Obsoleted by RFC 7826) ** Obsolete normative reference: RFC 2327 (ref. '2') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1889 (ref. '5') (Obsoleted by RFC 3550) -- Unexpected draft version: The latest known version of draft-ietf-midcom-stun is -04, but you're referring to -05. == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-02 -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '9') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '10') (Obsoleted by RFC 8200) == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-comedia-04 == Outdated reference: A later version (-02) exists of draft-lazzaro-avt-rtp-framing-contrans-00 Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Magnus Westerlund 3 INTERNET-DRAFT Ericsson 4 Category: Standards Track February 21, 2003 5 Expires: August 2003 7 How to make Real-Time Streaming Protocol (RTSP) traverse Network 8 Address Translators (NAT) and interact with Firewalls. 9 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/lid-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This document is an individual submission to the IETF. Comments 32 should be directed to the authors. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document describes four different types of NAT traversal 41 techniques that can be used by RTSP. For each technique a description 42 on how it shall be used, what security implications it has and other 43 deployment considerations that exist is given. Further a description 44 on how RTSP relates to firewalls are also given. 46 TABLE OF CONTENTS 48 1. Definitions.........................................................3 49 1.1. Glossary.......................................................3 50 1.2. Terminology....................................................3 51 2. Introduction........................................................3 52 2.1. NATs...........................................................4 53 2.2. Firewalls......................................................5 54 3. NAT Traversal Techniques............................................5 55 3.1. STUN...........................................................5 56 3.1.1. Introduction..............................................5 57 3.1.2. Usage with RTSP...........................................5 58 3.1.3. Deployment Considerations.................................7 59 3.1.4. Security Considerations...................................7 60 3.2. Symmetric RTP..................................................8 61 3.2.1. Introduction..............................................8 62 3.2.2. Necessary RTSP extensions.................................8 63 3.2.3. Using Symmetric RTP in RTSP...............................9 64 3.2.4. Open Issues..............................................10 65 3.2.5. Deployment Considerations................................10 66 3.2.6. Security Consideration...................................11 67 3.3. Application Level Gateways....................................12 68 3.3.1. Introduction.............................................12 69 3.3.2. Using ALG for RTSP.......................................12 70 3.3.3. Deployment Considerations................................13 71 3.3.4. Security Considerations..................................13 72 3.4. TCP Tunneling.................................................13 73 3.4.1. Introduction.............................................13 74 3.4.2. Usage of TCP tunneling in RTSP...........................14 75 3.4.3. Deployment Considerations................................14 76 3.4.4. Security Considerations..................................14 77 4. Firewalls..........................................................14 78 5. Security Consideration.............................................15 79 6. IANA Consideration.................................................15 80 7. Acknowledgments....................................................15 81 8. Author's Addresses.................................................16 82 9. References.........................................................16 83 9.1. Normative references..........................................16 84 9.2. Informative References........................................16 85 10. IPR Notice........................................................17 86 11. Copyright Notice..................................................18 87 1. Definitions 89 1.1. Glossary 91 NAT - Network Address Translator, see [8]. 92 NAT-PT - Network Address Translator Protocol Translator, see [9] 93 RTSP - Real-Time Streaming Protocol, see [1] and [7]. 94 SDP - Session Description Protocol, see [2]. 96 1.2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [4]. 102 [Authors Note: This document reference a number of RTSP transport 103 header parameters that will not be part of the next RTSP draft 104 version. These parameter are "client_rtcp_port", "server_rtcp_port", 105 and will instead be replace with a more general mechanism. However as 106 this is not available in a published draft this will reference the 107 mechanism present in draft version 02 of [7]. ] 109 2. Introduction 111 Today there is unfortunately Network Address Translators (NAT) [8] 112 everywhere and a protocol needs to try to make sure that it can work 113 through them in some fashion. The problem with RTSP is that it 114 carries information about network addresses and ports inside itself. 115 It is primarily the media streams that are being blocked by NAT. 117 Firewalls are also middle boxes that needs to be considered. They are 118 deployed to prevent non-desired traffic/protocols to be used or reach 119 the protected network. RTSP is designed to allow a firewall to let 120 RTSP controlled streams through, if chosen to, with minimal 121 implementation problems. However there is need for more detailed 122 information on how a firewall may be configured to allow RTSP to be 123 used through it. 125 This document explains how some NAT traversal mechanism can be used 126 with RTSP. The necessary RTSP protocol extensions are defined. What 127 security problems arise from the different mechanisms is also 128 explained. 130 This document is not based on the so proposed standard RTSP of RFC 131 2326 [1]. It is instead based and depending on the updated RTSP 132 specification [7], which is under development in the MMUSIC WG. The 133 updated specification is a much-needed attempt to correct a number of 134 shortcomings of RFC 2326. One important change is that the 135 specification is split into several parts. So far only the updated 136 core specification of RTSP is available in [7]. This document is one 137 extension document to this core spec documenting a special 138 functionality that extends the RTSP protocol. It is intended to 139 maintain and update this document to be consistent with the core 140 protocol. 142 2.1. NATs 144 Today there exist a number of different NAT types and usage areas. 145 The different NAT types, cited from STUN [31]: 147 Full Cone: A full cone NAT is one where all requests from the same 148 internal IP address and port are mapped to the same external IP 149 address and port. Furthermore, any external host can send a packet to 150 the internal host, by sending a packet to the mapped external 151 address. 153 Restricted Cone: A restricted cone NAT is one where all requests from 154 the same internal IP address and port are mapped to the same external 155 IP address and port. Unlike a full cone NAT, an external host (with 156 IP address X) can send a packet to the internal host only if the 157 internal host had previously sent a packet to IP address X. 159 Port Restricted Cone: A port restricted cone NAT is like a restricted 160 cone NAT, but the restriction includes port numbers. Specifically, an 161 external host can send a packet, with source IP address X and source 162 port P, to the internal host only if the internal host had previously 163 sent a packet to IP address X and port P. 165 Symmetric: A symmetric NAT is one where all requests from the same 166 internal IP address and port, to a specific destination IP address 167 and port, are mapped to the same external IP address and port. If the 168 same host sends a packet with the same source address and port, but 169 to a different destination, a different mapping is used. Furthermore, 170 only the external host that receives a packet can send a UDP packet 171 back to the internal host. 173 NAT's are used on both small and large scale. The normal small-scale 174 user is home user that has a NAT to allow multiple computers share 175 the single IP address given by their Internet Service Provider (ISP). 176 The large scale users are the ISP's themselves that gives there users 177 private addresses. This is done both for control and lack of 178 addresses. 180 Native Address Translation and Protocol Translation (NAT-PT) [9] is 181 mechanism used for IPv4 to IPv6 transition. This device is used to 182 allow devices only having connectivity using one of the IP versions 183 to communicate with the other address domain. The other address 184 domain is addressable through the use of domain names. Then a DNS ALG 185 assigns temporary IP addresses in the requestor's domain. The NAT-PT 186 device translates this temporary address to the receivers true IP 187 address and at the same time modify all necessary fields to be 188 correct in the receiver's address domain. 190 2.2. Firewalls 192 [TBW] 194 3. NAT Traversal Techniques 196 There exist a number of NAT traversal techniques that can be to allow 197 RTSP to function through the NAT. However they have different 198 applicability and trade offs. There are also differing in there 199 security considerations. Each techniques chapter will outline the 200 advantage and disadvantage of using it. 202 3.1. STUN 204 3.1.1. Introduction 206 The STUN protocol [6] allows a client to discover the type of NAT(s) 207 he is behind and also discover a mappings public address and port 208 number. The protocol also allows discovery of the mappings timeout 209 period and can be used as keep alive mechanism. 211 How useful this protocol is depends on the type of NAT(s) the client 212 is behind. If the user is behind a full cone NAT, STUN allows the 213 RTSP client to traverse the NAT with some simple client side 214 adaptations. For restricted cone NATs STUN is still useful but 215 require some more adaptations. For symmetric NATs STUN requires such 216 severe server adaptations that it is not practical to use. 218 3.1.2. Usage with RTSP 220 A RTSP client using RTP transport over UDP can use STUN to traverse a 221 full cone NAT in the following way: 223 1. Use STUN to discover the type of NAT, if any, and the timeout 224 period for any UDP mapping on the NAT. This is RECOMMENDED to be 225 performed in the background as soon as IP connectivity is 226 established. If this is performed prior to the attempt to 227 establish a streaming session the possible delays in the session 228 establishment will be reduced. If no NAT is present, use the 229 normal SETUP behavior. 231 2. The RTSP client determines the number of UDP ports needed by 232 counting the number of RTP sessions part of the multi-media 233 presentation. This information is available in the media 234 description protocol used, e.g. SDP. In general each RTP session 235 will require two UDP ports, one for RTP, and one for RTCP. Ensure 236 that the same public IP address is used for each RTP/RTCP port 237 pair established. 239 3. For each UDP port required, establish a mapping and discover the 240 public IP address and port number with use of STUN. If successful 241 this results in that the client now knows for each port know the 242 mapping: clients local address/port <-> public address/port. 244 4. Perform the RTSP SETUP for each media. In the transport header the 245 following parameters SHOULD be included with the given values: 246 "destination" with the public IP address, "client_port" with the 247 public port of the mapping determined to be used for RTP, 248 "client_rtcp_port" with the port number of the mapping to be used 249 for RTCP. The parameter "client_rtcp_port" needs to be used unless 250 the client has managed to establish a mapping with two consecutive 251 numbers starting with an even one. To allow this to work servers 252 MUST allow a client to setup the RTP stream on any port, not only 253 even ports. The server SHALL respond with a transport header 254 containing the source IP address of the media streams. 256 5. To keep the mappings alive the client SHOULD periodically send UDP 257 traffic over all mappings needed for the session. STUN can be used 258 to determine the timeout period of the NAT(s) UDP mappings. For 259 the mapping carrying RTCP traffic the periodic RTCP traffic may be 260 sent frequently enough. If not or for RTP carrying mappings, empty 261 IP/UDP messages SHOULD be sent to the streaming servers discard 262 port (port number 9). 264 If a UDP mapping is lost above process is required to be performed 265 again and the media stream needs to be SETUP again changing the 266 transport parameters to the new ones. 268 To allow the UDP packets to arrive from the server to a client behind 269 a restricted NAT, any UDP messages must be sent to the server. 270 Therefore SHOULD the client, before sending a RTSP PLAY request send 271 an empty UDP message, on each mapping, to the IP address given as the 272 servers source address and its discard port (port number 9). 273 Otherwise no difference in procedure compared with a full cone NAT is 274 needed. 276 For a port restricted NAT the client must send messages to the exact 277 ports used by the server to send messages. This makes it possible to 278 use the above described process with the following additions: For 279 each port mapping, a UDP message needs to be sent to the servers 280 source address/port. To minimize potential effects on the server from 281 these messages the following type of messages MUST be sent. RTP: An 282 empty UDP message with out any payload. RTCP: A correctly formed RTCP 283 message. Unless enough bandwidth is assigned to RTCP it might not be 284 possible to keep the UDP mapping open. These messages SHOULD be sent 285 before sending a PLAY request and then periodically. As the messages 286 are unreliable there is no possibility to guarantee that mappings are 287 kept open. However to achieve good probability and at the same time 288 don't send unnecessary traffic it is RECOMMENDED that the client 289 sends the message with a period that is equal to the bindings timeout 290 divided by 10. 292 To be able to use STUN to traverse symmetric NATs the STUN server 293 needs to be co-located with the streaming server media distribution 294 ports. This creates an unclear demultiplexing point within the 295 server. As this will create implementations difficulties and possibly 296 security problems this SHOULD NOT be done. 297 If a NAT supports RTSP ALG and are not aware of the STUN traversal 298 option this may cause service failure. The problem arises it the STUN 299 using client inserts the public address and port number into a SETUP 300 request. When the RTSP ALG processes the SETUP request it may change 301 the destination and port number if it does not detect the fact that 302 the destination is one of the NAT's public addresses. If the NAT 303 creates mappings assuming that the client uses its local address and 304 ports in the request this will create unpredictable results. 306 3.1.3. Deployment Considerations 308 Advantages: 310 - Does not require RTSP server modifications, totally client 311 implemented tool. 313 Disadvantages: 315 - Requires a STUN server deployed in the public address space. 316 - Does only work well behind Cone NATs. Does not normally work with 317 Symmetric NATs. 318 - Will mostly not work from behind NATs using multiple IP addresses, 319 as it requires all streams to have the same IP, see below. 320 - Interaction problems when a RTSP ALG is not aware of STUN. 321 - Requires RTSP servers supporting the updated specification. 323 3.1.4. Security Considerations 325 To prevent RTSP server being Denial of Service (DoS) attack tools the 326 RTSP Transport header parameter "Destination" is not allowed to point 327 at other IP addresses then the one the RTSP message transport 328 originates from. The server is only allowed to do exception from this 329 when the client is trusted through a secure authentication process 330 with secure transport of RTSP message or a secure method of 331 challenging the destination that verify its acceptance of the traffic 332 is used. The restriction result in that STUN does not work for NATs 333 that would assign different IP addresses to different UDP flows on 334 its public side. Which results in that most multi-address NATs will 335 not work. 337 STUN used with destination address restrictions in place has the same 338 security properties as core RTSP. It cannot be used as a DoS attack 339 tool unless the attacker has possibility to intercept or reroute the 340 RTSP control traffic going from the server towards the intended 341 target IP. 343 3.2. Symmetric RTP 345 3.2.1. Introduction 347 Symmetric RTP is a NAT traversal solution that is based on that NATed 348 client sends packets to the server address to the servers send ports. 349 When the server receives the packet, it copies the source IP and Port 350 number and uses them as delivery address for servers packets. By 351 having the server send media traffic back the same way as the 352 client's packet are sent to the server they will use the opened 353 mappings. Therefore this technique also works for symmetric NATs. 355 It has the advantage of working for all types of NATs. However it 356 requires server modifications. Symmetric RTP is somewhat more 357 vulnerable to hijacking attacks, which will be explained in more 358 details below. 360 3.2.2. Necessary RTSP extensions 362 To support symmetric RTP the RTSP signaling must be extended to allow 363 the client to indicate that it will use symmetric RTP. The client 364 also needs to be able to signal its RTP SSRC to the server. The RTP 365 SSRC is used to establish a basic security level against hijacking 366 attacks. 368 A RTP specific Transport header parameter is defined to indicate that 369 symmetric RTP shall be used for the media transport. The parameter is 370 included in each Transport header specification where the client will 371 use symmetric RTP. A Server SHALL NOT accept the transport 372 specification unless it supports symmetric RTP. If the client has 373 requested to use symmetric RTP for a session the server MUST include 374 the parameter in the response. 376 The parameter is defined in ABNF [3] as: 378 symm-usage = "sym_rtp" "=" "1" 380 Which follows the definition in [7] for transport parameter 381 extensions. 383 Further a RTSP options tag that can be used to indicate support of 384 symmetric RTP according to this specification is defined. 386 nat.sym-rtp 388 This tag SHALL be included in the supported header by both clients 389 and server supporting symmetric RTP according to this specification. 391 3.2.3. Using Symmetric RTP in RTSP 393 The server and client uses Symmetric RTP in the following way: 395 1. The client knows or has determined by the use of STUN that it is 396 located behind a NAT. It may also determined the type of NAT it 397 is behind. 399 2. The client MAY investigate if the server supports symmetric RTP 400 by including the supported header with the tag "nat.sym-rtp" in 401 an OPTIONS or DESCRIBE request to the server. A server supporting 402 symmetric RTP will include the tag in its response. 404 3. The client determines that it will use symmetric RTP to traverse 405 the NAT. This decision is based on knowledge about the NAT type 406 and necessary support from the server. 408 4. The client sends a SETUP request to the server where all 409 transport specs using RTP/UDP for which the client desires to use 410 symmetric RTP for includes the parameter "sym_rtp=1". It MUST 411 also include the parameter "client_ssrc" in each transport 412 specification containing "sym_rtp=1". The "client_ssrc" contains 413 the random SSRC it is going to use for that RTP session. The SSRC 414 MUST be assigned in a random way as the randomness of the SSRC is 415 the basic security mechanism that prevents hijacking. Symmetric 416 RTP MUST only be requested for unicast transport. 418 5. The server chose the transport specification that it will use to 419 transport the media and send it response. When this transport 420 specification is one declaring the use of symmetric RTP the 421 server performs the following: 422 - The server MUST include the transport parameters "sym_rtp=1", 423 "source", and "server_port" in the response. 424 - The server MUST both send and receive data on the indicated 425 ports. Otherwise the NAT traversal will not work if the NAT is a 426 symmetric or port restricted one. 427 - The server ignores any of the transport header parameters 428 "destination", client_port, and client_rtcp_port. 430 6. The Server starts listening on the declared server ports after an 431 RTP/UDP packet containing the SSRC the client has declared it 432 will use. Any received RTP/UDP packet not containing the SSRC 433 that the client has declared MUST be ignored. When the server 434 receives a RTP/UDP packet containing the matching SSRC the server 435 stores the source IP and Port as being the destination address 436 and port for that media. It performs the corresponding actions 437 for the RTCP port to establish the destination of the RTCP 438 transmissions. 440 7. The client establishes the address binding at the server by 441 sending RTP or RTCP to the servers declared media address and 442 port from the port it desires to receive RTP/RTCP on. For the RTP 443 channel it sends a RTP/UDP message containing the SSRC that it 444 declared to the server that it would use. The RTP/UDP packet 445 SHALL NOT contain any payload data and use payload type 0. To the 446 servers RTCP port it sends a normal RTCP packet. 448 8. Upon reception of a packet creating the binding the server SHALL 449 respond. On the RTP port it SHALL respond with a single RTP/UDP 450 packet using payload type 0 and having a 0 byte payload. For each 451 received client packet that contains the correct SSRC the server 452 SHALL respond with a single packet. For RTCP it starts 453 transmitting RTCP packets according to the rules. 455 9. To prevent that the clients binding packets are not lost the 456 client SHOULD retransmit the binding RTP packet every 250 ms 457 until it receives a response with an empty RTP packet or it has 458 retransmitted 20 times. For RTCP it is enough to transmit RTCP 459 packet according to the normal rules. However a client MAY send 460 one RTCP packet every 500 ms until it receives an answer, or it 461 has tried for 10 seconds. 463 10. When the client has received answers for both RTP and RTCP it can 464 safely progress the session and send a PLAY request. 466 11. To ensure that the binding is not lost the client SHOULD send a 467 empty RTP/UDP packet with PT=0 to the server every tenth of the 468 mapping timeout time that has been discovered for the NAT. The 469 discovery can be performed by using STUN. The client SHOULD not 470 send these packets as long as the server transmit RTP packets to 471 the client. Unless the NAT mappings has very short timeouts or 472 the RTCP bandwidth is severely restricted the RTCP traffic should 473 automatically keep its connection open. 475 3.2.4. Open Issues 477 The proposal for symmetric RTP contains some open issues that needs 478 to be addressed. 480 What RTP payload type(s) shall the client use. Should it use one of 481 the types that the server has declared is going to use in the server 482 -> client direction or a static one? 484 Should the security be improved by having a RTP challenge that can 485 contain longer random identifiers? If that is the case it should have 486 a static payload type as the client can't establish dynamic payload 487 type declarations. 489 3.2.5. Deployment Considerations 491 Advantages: 493 - Works for all types of NATs, including those using multiple IP 494 addresses. 495 - Have no interaction problems with any RTSP ALG changing the 496 client's information in the transport header. 498 Disadvantages: 500 - Requires Server support. 501 - Has somewhat worse security situation then STUN when using address 502 restrictions. 504 3.2.6. Security Consideration 506 Symmetric RTP's major security issues are that streams can be 507 hijacked and directed towards any target that the attacker desires 508 the server's traffic to go to. 510 The attack can be performed in a few variations. The basic attack is 511 based on that an attacker can read the RTSP signaling packets and 512 those learn the address and port the server will send from and also 513 the SSRC the client will use. Having this information the attacker 514 can send its own RTP packets containing the correct RTP SSRC to the 515 correct address and port on the server. The destination of the 516 packets is set as the source IP and port in these RTP packets. 518 Another variation of this attack is to look at the RTP traffic being 519 directed to the server and simple change the source IP to the target 520 one desires to attack. 522 The first attack is possible to protect one self by applying 523 encryption of the RTSP signaling transport. However the second 524 variation is impossible to defend against. As the NAT rewrites the 525 source IP and port this can't be authenticated which would be 526 required to protect against this attack. 528 Symmetric RTP's strength against hijacking attacks by others then a 529 man in the middle is dependent on the random tag that is included in 530 the binding packets. This proposal uses the 32-bit RTP SSRC field to 531 this effect. Therefore it is important that this field is derived 532 with a non-predictive randomizer. It shall not be possible by knowing 533 the algorithm used and a couple of basic facts, be able to derive 534 what random number a certain client will use. 536 A attacker not knowing the SSRC but knowing which port numbers that a 537 server sends from can deploy a brute force attack on the server by 538 testing a lot of different SSRCs until it founds a matching one. 539 Therefore a server SHOULD implement functionality that blocks ports 540 that receive multiple binding packets with different SSRCs, especialy 541 if they are coming from the same IP/Port. 543 To improve the security against attackers not being man in the 544 middles the random tags length needs to be increased. To perform this 545 while still using RTP and RTCP would require the development of a RTP 546 payload format for carrying these and a corresponding one in RTCP. 548 3.3. Application Level Gateways 550 3.3.1. Introduction 552 An Application Level Gateway (ALG) reads the application level 553 messages and perform the necessary changes to allow the protocol to 554 work through the middle box. However this behavior has some problems 555 in regards to RTSP: 557 1. Does not work when protocol is used with end-to-end security. As 558 the ALG can't inspect and change the application level messages the 559 protocol will fail due to the middle box. 561 2. Needs to be updated if extensions to the protocol are added. Due 562 to deployment issues with changing ALG's this may also break the end- 563 to-end functionality of RTSP. 565 Due to the above reasons it is NOT RECOMMENDED to use an RTSP ALG in 566 NATs. This is especially important for NAT's targeted to home users 567 and small office environments. 569 3.3.2. Using ALG for RTSP 571 An ALG for the RTSP core specification [7] would need to perform the 572 following tasks and changes to RTSP: 574 1. Detect any SETUP request. 576 2. Determine if the SETUP request already employ STUN type traversal. 577 This is detected by detecting a destination header that contains 578 one of the NAT's public IP addresses. If that is present the ALG 579 MUST NOT modify the request. 581 3. Create UDP mappings (client given IP/port <-> public IP/port) 582 where needed for all possible transport specification in the 583 transport header of the request found in (1). Enter the public 584 address and port(s) of these mappings in transport header. 585 Mappings SHALL be created with consecutive public port number 586 starting on an even number for RTP each stream. Mappings SHOULD 587 also be given a long timeout period, at least 5 minutes. 589 4. When the response is received from the server the ALG MAY remove 590 the unused UDP mappings, i.e. the ones not present in the 591 transport header. The session ID SHOULD also be bound to the UDP 592 mappings part of that session. 594 5. The ALG SHOULD keep alive the UDP mappings belonging to the an 595 RTSP session as long as: RTSP messages with the session's ID has 596 been sent in the last RTSP session timeout interval, or UDP 597 messages are sent on any of the UDP mappings during the last RTSP 598 timeout interval. 600 6. The ALG MAY remove a mapping as soon a TEARDOWN response has been 601 received for that media stream. 603 3.3.3. Deployment Considerations 605 Advantage: 607 - No impact on either client or server 608 - Can be made for any type of NATs 610 Disadvantage: 612 - When deployed they are hard to have updated to reflect protocol 613 modifications and extensions. If not updated they will prevent 614 functionality. 615 - When end-to-end security is used the ALG functionality fails and 616 prevents the protocol functionality. 617 - Can interfere with other type of traversal mechanisms. 619 3.3.4. Security Considerations 621 An ALG will not work when deployment of end-to-end RTSP signaling 622 security. Therefore deployment of ALG will result in that end-to-end 623 security will not be used by clients located behind NATs. 625 3.4. TCP Tunneling 627 3.4.1. Introduction 629 Using a TCP connection that is established from the client to the 630 server ensures that the server can send data to the client. The 631 connection opened from the private domain ensures that the server can 632 send data back to the client. To send data original intended to be 633 transport over RTP requires the TCP connection to support some type 634 of framing of the RTP packets. 636 Using TCP also results in that the client has to accept that real- 637 time performance may no longer be possible. TCP's problem of ensuring 638 timely deliver was the reasons why RTP was developed. Problems that 639 arise with TCP are: Head of line blocking, Retransmissions, Highly 640 varying congestion control. 642 3.4.2. Usage of TCP tunneling in RTSP 644 The RTSP core specification [7] supports interleaving of media data 645 on the RTSP TCP signaling TCP connection. See section 10.13 in [7] 646 for how to perform this TCP tunneling. 648 There is currently work on one more way of transporting RTP over TCP 649 in AVT and MMUSIC. For signaling and rules on how to establish the 650 TCP connection is place of using UDP ports see [12]. Another draft 651 describes how to frame RTP over the TCP connection, see [13]. 653 3.4.3. Deployment Considerations 655 Advantage: 657 - Works through all types of NATs. 659 Disadvantage: 661 - Functionality needs to be implemented on both server and client. 662 - May not give real-time performance. 664 3.4.4. Security Considerations 666 The TCP tunneling of RTP has no known security problem besides them 667 already present in RTSP. It is not possible to get any amplification 668 effect that is desired for denial of service attacks due to TCP's 669 flow control. 671 Opening further server ports that one can connect does not worsen any 672 denial of service attacks that the server can be target of. 674 A possible consideration will be the performance bottleneck any RTSP 675 signaling encryption will become when all session media needs to be 676 encrypted. 678 4. Firewalls 680 Firewalls exist for a purpose to protect a network from traffic not 681 desired by the firewall owner. Therefore it is a policy decision if a 682 firewall will let RTSP and its media streams through or not. RTSP is 683 designed to be as easy as possible to process for a firewall with a 684 policy to let the traffic pass through. 686 The firewall will need to allow the media streams associated with a 687 RTSP session pass through it. Therefore the firewall will need an ALG 688 that reads RTSP SETUP and TEARDOWN messages. By reading the SETUP 689 message the firewall can determine what type of transport and from 690 where the media streams will use. Very common will be the need to 691 open UDP ports for RTP/RTCP. By looking at the source and destination 692 addresses and ports the opening in the firewall can be minimized to 693 the least necessary. The opening in the firewall can be closed after 694 a teardown message for that session or the session itself times out. 696 5. Security Consideration 698 The presence of NAT(s) is a security risk, as a client cannot perform 699 source authentication of its IP address. This prevents the deployment 700 of any future RTSP extensions providing security against hijacking of 701 sessions by a man in the middle. 703 Each of the different technique for doing NAT traversal has security 704 implications. 706 Using STUN as long as the server do not grant a client request to 707 send media to different IP addresses will provide the same level of 708 security as RTSP with out transport level security and source 709 authentication provides. 711 Usage of symmetric RTP will have a slightly higher risk of session 712 hijacking than normal RTSP. The reason is that there exists a 713 probability that an attacker is able to guess the random tag that the 714 client uses to prove its identity when creating the address bindings. 716 The usage of an RTSP ALG does not increase in itself the risk for 717 session hijacking. However the deployment of ALGs are sole mechanism 718 for RTSP NAT traversal will result in that usage of signaling 719 security will be prevented. 721 The usage of TCP tunneling has no known security problems. However it 722 might provide a bottleneck when it comes to end-to-end RTSP signaling 723 security if TCP tunneling is used on a interleaved RTSP signaling 724 connection. 726 6. IANA Consideration 728 This specification would like to register 1 new Transport header 729 parameter "sym_rtp" as defined in section 3.2.2. 731 It does also register one more RTSP option tag "nat.sym-rtp" as 732 defined in section 3.2.2. 734 7. Acknowledgments 736 The author would also like to thank all persons on the MMUSIC working 737 group's mailing list that has commented on this specification. 738 Persons having contributed in such way in special order to this 739 protocol are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, 740 David Yon, Amir Wolf, Anders Klemets, and Colin Perkins. 742 8. Author's Addresses 744 Magnus Westerlund Tel: +46 8 4048287 745 Ericsson Research Email: Magnus.Westerlund@ericsson.com 746 Ericsson AB 747 Torshamnsgatan 23 748 SE-164 80 Stockholm, SWEDEN 750 9. References 752 9.1. Normative references 754 [1] H. Schulzrinne, et. al., "Real Time Streaming Protocol (RTSP)", 755 IETF RFC 2326, April 1998. 756 [2] M. Handley, V. Jacobson, "Session Description Protocol (SDP)", 757 IETF RFC 2327, April 1998. 758 [3] D. Crocker and P. Overell, "Augmented BNF for syntax specifica- 759 tions: ABNF," RFC 2234, Internet Engineering Task Force, Nov. 760 1997. 761 [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement 762 Levels", RFC 2119, March 1997. 763 [5] H. Schulzrinne, et. al., "RTP: A Transport Protocol for Real- 764 Time Applications", IETF RFC 1889, January 1996. 765 [6] J. Rosenberg, et. Al., " STUN - Simple Traversal of UDP Through 766 Network Address Translators", IETF Draft, draft-ietf-midcom- 767 stun-05.txt, Dec. 2002. 768 [7] H. Schulzrinne, et. al., "Real Time Streaming Protocol (RTSP)", 769 draft-ietf-mmusic-rfc2326bis-02.txt, IETF draft, November 2002, 770 work in progress. 772 9.2. Informative References 774 [8] P. Srisuresh, K. Egevang, "Traditional IP Network Address 775 Translator (Traditional NAT)," RFC 3022, Internet Engineering 776 Task Force, January 2001. 777 [9] Tsirtsis, G. and Srisuresh, P., "Network Address Translation - 778 Protocol Translation (NAT-PT)", RFC 2766, Internet Engineering 779 Task Force, February 2000. 780 [10] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) 781 Specification", RFC 2460, Internet Engineering Task Force, 782 December 1998. 783 [11] J. Postel, "internet protocol", RFC 791, Internet Engineering 784 Task Force, September 1981. 785 [12] D. Yon, "Connection-Oriented Media Transport in SDP", IETF 786 draft, draft-ietf-mmusic-sdp-comedia-04.txt, July 2002. 788 [13] John Lazzaro, "Framing RTP and RTCP Packets over Connection- 789 Oriented Transport", IETF Draft, draft-lazzaro-avt-rtp-framing- 790 contrans-00.txt, January 2003. 792 10. IPR Notice 794 The IETF takes no position regarding the validity or scope of any 795 intellectual property or other rights that might be claimed to 796 pertain to the implementation or use of the technology described in 797 this document or the extent to which any license under such rights 798 might or might not be available; neither does it represent that it 799 has made any effort to identify any such rights. Information on the 800 IETF's procedures with respect to rights in standards-track and 801 standards-related documentation can be found in BCP-11. Copies of 802 claims of rights made available for publication and any assurances of 803 licenses to be made available, or the result of an attempt made to 804 obtain a general license or permission for the use of such 805 proprietary rights by implementors or users of this specification can 806 be obtained from the IETF Secretariat. 808 The IETF invites any interested party to bring to its attention any 809 copyrights, patents or patent applications, or other proprietary 810 rights which may cover technology that may be required to practice 811 this standard. Please address the information to the IETF Executive 812 Director. 814 11. Copyright Notice 816 Copyright (C) The Internet Society (2003). All Rights Reserved. 818 This document and translations of it may be copied and 819 furnished to others, and derivative works that comment on or 820 otherwise explain it or assist in its implementation may be 821 prepared, copied, published and distributed, in whole or in 822 part, without restriction of any kind, provided that the above 823 copyright notice and this paragraph are included on all such 824 copies and derivative works. However, this document itself may 825 not be modified in any way, such as by removing the copyright 826 notice or references to the Internet Society or other Internet 827 organizations, except as needed for the purpose of developing 828 Internet standards in which case the procedures for copyrights 829 defined in the Internet Standards process must be followed, or 830 as required to translate it into languages other than English. 832 The limited permissions granted above are perpetual and will 833 not be revoked by the Internet Society or its successors or 834 assigns. 836 This document and the information contained herein is provided 837 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 838 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 839 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 840 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 841 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 842 PARTICULAR PURPOSE. 844 This Internet-Draft expires in August 2003.