idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2009) is 5400 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) == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-21 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-rtsp-nat-evaluation-01 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Goldberg 3 Internet-Draft Cisco 4 Intended status: Standards Track M. Westerlund 5 Expires: January 14, 2010 Ericsson 6 T. Zeng 7 Nextwave Wireless, Inc. 8 July 13, 2009 10 A Network Address Translator (NAT) Traversal mechanism for media 11 controlled by Real-Time Streaming Protocol (RTSP) 12 draft-ietf-mmusic-rtsp-nat-08 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 14, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document defines a solution for Network Address Translation 51 (NAT) traversal for datagram based media streams setup and controlled 52 with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses 53 Interactive Connectivity Establishment (ICE) adapted to use RTSP as a 54 signalling channel, defining the necessary extra RTSP extensions and 55 procedures. 57 Requirements Language 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [RFC2119]. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 67 3. RTSP Extensions . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. ICE Transport Lower Layer . . . . . . . . . . . . . . . . 6 69 3.2. ICE Candidate Transport Header Parameter . . . . . . . . . 8 70 3.3. ICE Password and Username Transport Header Parameters . . 11 71 3.4. ICE Feature Tag . . . . . . . . . . . . . . . . . . . . . 11 72 3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 11 73 3.5.1. 150 ICE connectivity checks in progress . . . . . . . 12 74 3.5.2. 480 ICE Processing Failed . . . . . . . . . . . . . . 12 75 3.6. New Reason for PLAY_NOTIFY . . . . . . . . . . . . . . . . 12 76 3.7. Server Side SDP Attribute for ICE Support . . . . . . . . 12 77 3.8. ICE Features Not Required in RTSP . . . . . . . . . . . . 13 78 3.8.1. ICE-Lite . . . . . . . . . . . . . . . . . . . . . . . 13 79 3.8.2. ICE-Mismatch . . . . . . . . . . . . . . . . . . . . . 13 80 3.8.3. ICE Remote Candidate Transport Header Parameter . . . 13 81 4. Detailed Solution . . . . . . . . . . . . . . . . . . . . . . 13 82 4.1. Session description and RTSP DESCRIBE (optional) . . . . . 14 83 4.2. Setting up the Media Streams . . . . . . . . . . . . . . . 15 84 4.3. RTSP SETUP Request . . . . . . . . . . . . . . . . . . . . 15 85 4.4. Gathering Candidates . . . . . . . . . . . . . . . . . . . 16 86 4.5. RTSP Server Response . . . . . . . . . . . . . . . . . . . 17 87 4.6. Server to Client ICE Connectivity Checks . . . . . . . . . 17 88 4.7. Client to Server ICE Connectivity Check . . . . . . . . . 18 89 4.8. Client Connectivity Checks Complete . . . . . . . . . . . 18 90 4.9. Server Connectivity Checks Complete . . . . . . . . . . . 18 91 4.10. Releasing Candidates . . . . . . . . . . . . . . . . . . . 19 92 4.11. Steady State . . . . . . . . . . . . . . . . . . . . . . . 19 93 4.12. re-SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 4.13. Server Side Changes After Steady State . . . . . . . . . . 19 96 5. ICE and Proxies . . . . . . . . . . . . . . . . . . . . . . . 21 97 5.1. Media Handling Proxies . . . . . . . . . . . . . . . . . . 22 98 5.2. Signalling Only Proxies . . . . . . . . . . . . . . . . . 22 99 5.3. Non-supporting Proxies . . . . . . . . . . . . . . . . . . 22 100 6. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . . . 23 101 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 24 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 103 8.1. RTSP Feature Tags . . . . . . . . . . . . . . . . . . . . 24 104 8.2. Transport Protocol Specifications . . . . . . . . . . . . 24 105 8.3. RTSP Transport Parameters . . . . . . . . . . . . . . . . 25 106 8.4. RTSP Status Codes . . . . . . . . . . . . . . . . . . . . 25 107 8.5. Notify-Reason value . . . . . . . . . . . . . . . . . . . 25 108 8.6. SDP Attribute . . . . . . . . . . . . . . . . . . . . . . 25 109 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 110 9.1. ICE and RTSP . . . . . . . . . . . . . . . . . . . . . . . 26 111 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 112 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 113 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 114 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 117 1. Introduction 119 Real-time Streaming Protocol (RTSP) 120 [RFC2326][I-D.ietf-mmusic-rfc2326bis] is a protocol used to setup and 121 control one or more media streams delivering media to receivers. It 122 is RTSP's functionality of setting up media streams that cause 123 serious issues with Network Address Translators (NAT) [RFC3022] 124 unless extra provisions are taken by the protocol. There is thus a 125 need for a NAT traversal mechanism for the media setup using RTSP. 127 RTSP 1.0 [RFC2326] has suffered from the lack of a standardized NAT 128 traversal mechanism for a long time, however due to quality of the 129 RTSP 1.0 specification, the work has had to wait on the recently 130 defined RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. RTSP 2.0 is similar 131 to RTSP 1.0 in many respects but significantly for this work, it 132 contains a well defined extension mechanism so allowing a NAT 133 traversal extension to be defined that is backwards compatible with 134 RTSP 2.0 peers not supporting the extension. This extension 135 mechanism was not possible in RTSP 1.0 as it would break RTSP 1.0 136 syntax so causing compatibility issues. 138 There have been a number of suggested ways of resolving the NAT- 139 traversal of media for RTSP of which a large number are already used 140 in implementations. The evaluation of these NAT traversal solutions 141 in[I-D.ietf-mmusic-rtsp-nat-evaluation] has shown that there are many 142 issues to consider, so after extensive evaluation, we selected a 143 mechanism based on Interactive Connectivity Establishment (ICE). 144 This was mainly two reasons: Firstly the mechanism supports RTSP 145 servers behind NATs and secondly the mechanism solves the security 146 threat that uses RTSP servers as Distributed Denial of Service (DDoS) 147 attack tools. 149 This document specifies an ICE based solution that is optimized for 150 media delivery server to client. If in the future extensions are 151 specified for other delivery modes than PLAY, then the optimizations 152 in regards to when PLAY request are sent needs to be reconsidered. 154 The NAT problem for RTSP signalling traffic itself is beyond the 155 scope of this document and is left for future study should the need 156 arise, because it is a less prevalent problem than the NAT problem 157 for RTSP media streams. 159 2. Solution Overview 161 This overview assumes that the reader has some familiarity with how 162 ICE [I-D.ietf-mmusic-ice] works, as it primarily points out how the 163 different ICE steps are accomplished in RTSP. 165 1. RTSP server can indicate it has support for ICE via an SDP 166 [RFC4566] attribute in, for example, the SDP returned in RTSP 167 DESCRIBE message. This allows RTSP clients to only send the new 168 ICE interchanges with servers that support ICE so as to limit 169 the overhead on current non-ICE supporting RTSP servers. If 170 RTSP DESCRIBE is used the normal capability determination 171 mechanism can be used, i.e. "Supported" header and the defined 172 feature tag. 174 2. RTSP client reviews the session description returned, for 175 example by an RTSP DESCRIBE message, to determine what media 176 streams need to be setup. For each of these media streams where 177 the transport protocol supports Session Traversal Utilities for 178 (NAT) (STUN) [RFC5389] based connectivity checks, the client 179 gathers candidate addresses. See section 4.1.1 in 180 [I-D.ietf-mmusic-ice]. The client also installs the STUN 181 servers on each of the local candidates. 183 3. RTSP client sends SETUP requests with both a transport 184 specification with a lower layer indicating ICE and a new RTSP 185 Transport header parameter listing the ICE candidates for each 186 media stream. 188 4. After receiving the list of candidates from a client, the RTSP 189 server gathers its own candidates. If the server has a public 190 IP address, then a single candidate per address family (e.g. 191 IPv4 and IPv6), media stream and media component tuple can be 192 included to reduce the number of combinations and speed up the 193 completion. 195 5. The server sets up the media and if successful responds to the 196 SETUP request with a 200 OK response. In that response the 197 server selects the transport specification using ICE and 198 includes its candidates in the server candidate parameter. 200 6. The server starts the connectivity checks following the 201 procedures described in Section 5.7 and 5.8 of 202 [I-D.ietf-mmusic-ice]. If the server has a public IP address 203 with a single candidate per media stream, component and address 204 family then one may configure the server to not initiate 205 connectivity checks. 207 7. The client receives the SETUP response and learns the candidate 208 address to use for the connectivity checks, and then initiates 209 its connectivity check, following the procedures in Section 6 of 210 [I-D.ietf-mmusic-ice]. 212 8. When a connectivity check from the client reaches the server it 213 will result in a triggered check from the server. This is why 214 servers with a public IP address can wait until this triggered 215 check to send out any checks for itself so saving resources and 216 mitigating the DDoS potential from server connectivity checks. 218 9. When the client has concluded its connectivity checks and has 219 correspondingly received the server connectivity checks on the 220 promoted candidates for all mandatory components of all media 221 streams, it can issue a PLAY request. If the connectivity 222 checks have not concluded successfully then the client may send 223 a new SETUP request assuming it has any new information or 224 believes the server may be able to do more that can result in 225 successful checks. 227 10. When the RTSP servers receives a PLAY request it checks to see 228 the connectivity checks has concluded successfully and only then 229 can play the stream. If there is a problem with the checks then 230 the server sends to the client either a 150 (ICE connectivity 231 checks in progress) response to show that it is still working on 232 the connectivity checks or a 480 (ICE Processing Failed) 233 response to indicate a failure of the checks. If the checks are 234 successful then the server sends a 200 OK response and starts 235 delivering media. 237 The client and server may release unused candidates when the ICE 238 processing has concluded and a single candidate per component has 239 been promoted. 241 The client shall continue to use STUN to send keep-alive for the used 242 bindings. This is important as often RTSP media sessions only 243 contain media traffic from the server to the client so the bindings 244 in the NAT needs to be refreshed by the client to server traffic 245 provided by the STUN keep-alive. 247 3. RTSP Extensions 249 This section defines the necessary RTSP extensions for performing ICE 250 with RTSP. Note that these extensions are based on the SDP 251 attributes in the ICE specification unless expressly indicated. 253 3.1. ICE Transport Lower Layer 255 A new lower layer "D-ICE" for transport specifications is defined. 256 This lower layer is datagram clean except that the protocol used must 257 be demultiplexiable with STUN messages (see STUN [RFC5389]). With 258 datagram clean we mean that it must be capable of describing the 259 length of the datagram, transport that datagram (as a binary chunk of 260 data) and provide it at the receiving side as one single item. This 261 lower layer can be any transport type defined for ICE which does 262 provide datagram transport capabilities. Though only UDP is defined 263 at present, however DCCP or TCP with framing may be specified and 264 used in the future. 266 This lower layer uses ICE to determine which of the different 267 candidates shall be used and then when the ICE processing has 268 concluded, uses the selected candidate to transport the datagrams 269 over this transport. 271 This lower layer transport can be combined with all upper layer media 272 transport protocols that are possible to demultiplex with STUN and 273 which use datagrams. This specification defines the following 274 combinations: 276 o RTP/AVP/D-ICE 278 o RTP/AVPF/D-ICE 280 o RTP/SAVP/D-ICE 282 o RTP/SAVPF/D-ICE 284 This list can easily be extended with more transport specifications 285 after having performed the evaluation that they are compatible with 286 D-ICE as lower layer. 288 The lower-layer "D-ICE" has the following rules for the inclusion of 289 transport parameters: 291 unicast: As ICE only supports unicast operations, thus it is 292 REQUIRED that one include the unicast indicator parameter, see 293 section 16.46 in [I-D.ietf-mmusic-rfc2326bis]. 295 candidates: The "candidates" parameter SHALL be included as this 296 specify at least one candidate to try to establish a working 297 transport path with. 299 dest_addr: This parameter SHALL NOT be included as "candidates" is 300 used instead to provide the necessary address information. 302 ICE-Password: This parameter SHALL be included. 304 ICE-ufrag: This parameter SHALL be included. 306 3.2. ICE Candidate Transport Header Parameter 308 This section defines a new RTSP transport parameter for carrying ICE 309 candidates related to the transport specification they appear within, 310 which may then be validated with an end-to-end connectivity check 311 using STUN [RFC5389]. Transport parameters may only occur once in 312 each transport specification. For transport specification using 313 "D-ICE" as lower layer, this parameter needs to be present. The 314 parameter can contain one or more ICE candidates. In the SETUP 315 response there is only a single transport specification, and if that 316 uses the "D-ICE" lower layer this parameter MUST be present and 317 include the server side candidates. 319 trns-parameter = 321 trns-parameter =/ SEMI ice-trn-par 322 ice-trn-par = "candidates" EQUAL DQ SWS ice-candidate 323 *(SEMI ice-candidate) SWS DQ 324 ice-candidate = foundation SP 325 component-id SP 326 transport SP 327 priority SP 328 connection-address SP 329 port SP 330 cand-type 331 [SP rel-addr] 332 [SP rel-port] 333 *(SP extension-att-name SP extension-att-value) 335 foundation = 336 component-id = 337 transport = 338 transport-extension = 339 priority = 340 cand-type = 341 candidate-types = 342 rel-addr = 343 rel-port = 344 extension-att-name = 345 extension-att-value = 346 ice-char = 347 connection-address = 348 port = 349 EQUAL = 350 DQ = 351 SWS = 352 SEMI = 354 : is the IP address of the candidate, allowing 355 for IPv4 addresses, IPv6 addresses and Fully qualified domain names 356 (FQDN), taken from [RFC4566]. The connection address SHOULD be on 357 the same format (explicit IP or FQDN) as in the dest_addr parameter 358 used to express fallbacks. An IP address SHOULD be used, but an FQDN 359 MAY be used in place of an IP address. In that case, when receiving 360 an SETUP request or response containing an FQDN in an candidate 361 parameter, the FQDN is looked up in the DNS first using an AAAA 362 record (assuming the agent supports IPv6), and if no result is found 363 or the agent only supports IPv4, using an A record. If the DNS query 364 returns more than one IP address, one is chosen, and then used for 365 the remainder of ICE processing which in RTSP is subsequent RTSP 366 SETUPs for the same RTSP session. 368 : is the port of the candidate taken from RFC 4566 [RFC4566]. 370 : indicates the transport protocol for the candidate. The 371 ICE specification only defines UDP. However, extensibility is 372 provided to allow for future transport protocols to be used with ICE, 373 such as TCP or the Datagram Congestion Control Protocol (DCCP) 374 [RFC4340]. 376 : is an identifier that is equivalent for two candidates 377 that are of the same type, share the same base, and come from the 378 same STUN server, and is composed of one to thirty two . 379 The foundation is used to optimize ICE performance in the Frozen 380 algorithm. 382 : identifies the specific component of the media stream 383 for which this is a candidate and os a positive integer between 1 and 384 256. It MUST start at 1 and MUST increment by 1 for each component 385 of a particular candidate. For media streams based on RTP, 386 candidates for the actual RTP media MUST have a component ID of 1, 387 and candidates for RTCP MUST have a component ID of 2. Other types 388 of media streams which require multiple components MUST develop 389 specifications which define the mapping of components to component 390 IDs. See Section 14 for additional discussion on extending ICE to 391 new media streams. 393 : is a positive integer between 1 and (2**31 - 1). 395 : encodes the type of candidate. The ICE specification 396 defines the values "host", "srflx", "prflx" and "relay" for host, 397 server reflexive, peer reflexive and relayed candidates, 398 respectively. The set of candidate types is extensible for the 399 future. 401 and : convey transport addresses related to the 402 candidate, useful for diagnostics and other purposes. and 403 MUST be present for server reflexive, peer reflexive and 404 relayed candidates. If a candidate is server or peer reflexive, 405 and is equal to the base for that server or 406 peer reflexive candidate. If the candidate is relayed, 407 and is equal to the mapped address in the Allocate 408 Response that provided the client with that relayed candidate (see 409 Appendix B.3 of [I-D.ietf-mmusic-ice] for a discussion of its 410 purpose). If the candidate is a host candidate and MUST be omitted. 413 3.3. ICE Password and Username Transport Header Parameters 415 The ICE password and username for each agent needs to be transported 416 using RTSP. For that purpose new transport header parameters are 417 defined. 419 There MUST be an "ICE-Password" and "ICE-ufrag" parameter for each 420 media stream. If two SETUP requests in the same RTSP session have 421 identical ICE-ufrag's, they MUST have identical ICE-Password's. The 422 ICE-ufrag and ICE-Password attributes MUST be chosen randomly at the 423 beginning of a session. The ICE-ufrag attribute MUST contain at 424 least 24 bits of randomness, and the ICE-Password attribute MUST 425 contain at least 128 bits of randomness. This means that the ICE- 426 ufrag attribute will be at least 4 characters long, and the ICE- 427 Password at least 22 characters long, since the grammar for these 428 attributes allows for 6 bits of randomness per character. The 429 attributes MAY be longer than 4 and 22 characters respectively, of 430 course, up to 256 characters. The upper limit allows for buffer 431 sizing in implementations. Its large upper limit allows for 432 increased amounts of randomness to be added over time. 434 The ABNF [RFC5234] for these parameters are: 436 trns-parameter =/ SEMI ice-password-par 437 trns-parameter =/ SEMI ice-ufrag-par 438 ice-password-par = "ICE-Password" EQUAL password 439 ice-ufrag-par = "ICE-ufrag" EQUAL ufrag 440 password = 441 ufrag = 442 EQUAL = 443 SEMI = 445 3.4. ICE Feature Tag 447 A feature tag is defined for use in the RTSP capabilities mechanism 448 for ICE support of media transport using datagrams: "setup.ice-d-m". 449 This feature tag indicates that one supports all the mandatory 450 functions of this specification. It is applicable to all types of 451 RTSP agents; clients, servers and proxies. 453 The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the 454 "Supported" header in all SETUP requests that contain the "D-ICE" 455 lower layer transport. 457 3.5. Status Codes 459 ICE needs two new RTSP response codes to indicate correctly progress 460 and errors. 462 +------+----------------------------------------------+-------------+ 463 | Code | Reason | Method | 464 +------+----------------------------------------------+-------------+ 465 | 150 | Server still working on ICE connectivity | PLAY | 466 | | checks | | 467 | 480 | ICE Connectivity check failure | PLAY, SETUP | 468 +------+----------------------------------------------+-------------+ 470 Table 1: New Status codes and their usage with RTSP methods 472 3.5.1. 150 ICE connectivity checks in progress 474 The 150 response code indicates that ICE connectivity checks are 475 still in progress and haven't concluded. This response SHALL be sent 476 within 200 milliseconds of receiving a PLAY request that currently 477 can't be fulfilled because ICE connectivity checks are still running. 478 Subsequently, every 3 seconds after the previous sent one, a 150 479 reply shall be sent until the ICE connectivity checks conclude either 480 successfully or in failure, and a final response for the request can 481 be provided. 483 3.5.2. 480 ICE Processing Failed 485 The 480 client error response code is used in cases when the request 486 can't be fulfilled due to a failure in the ICE processing, such as 487 that all the connectivity checks have timed out. This error message 488 can appear either in response to a SETUP request to indicate that no 489 candidate pair can be constructed or to a PLAY request that the 490 server's connectivity checks resulted in failure. 492 3.6. New Reason for PLAY_NOTIFY 494 A new value used in the PLAY_NOTIFY methods Notify-Reason header is 495 defined: "ice-restart". This reason indicates that a ICE restart 496 needs to happen on the identified resource and session. 498 Notify-Reas-val =/ "ice-restart" 500 3.7. Server Side SDP Attribute for ICE Support 502 If the server supports the media NAT traversal for RTSP controlled 503 sessions, as described in this RFC, then the Server SHOULD include 504 the "a=rtsp-ice-d-m" SDP attribute in any SDP (if used) describing 505 content served by the server. This is an session level attribute. 507 rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m" 509 3.8. ICE Features Not Required in RTSP 511 A number of ICE signalling features are not needed with RTSP and are 512 discussed below. 514 3.8.1. ICE-Lite 516 The ICE-Lite attribute shall not be used in the context of RTSP. The 517 ICE specification describes two implementations of ICE: Full and 518 Lite, where hosts that are not behind a NAT are allowed to implement 519 only Lite. For RTSP, the Lite implementation is insufficient because 520 it does not cause the media server to send a connectivity check, 521 which are used to protect against making the RTSP server a denial of 522 service tool. This document defines another variation implementation 523 of ICE, called ICE-RTSP. It has its own set of simplifications 524 suitable to RTSP. Conceptually, this implementation of ICE-RTSP is 525 between ICE-FULL and ICE-LITE for a server and simpler than ICE-FULL 526 for clients. 528 3.8.2. ICE-Mismatch 530 The ice-mismatch parameter indicates that the offer arrived with a 531 default destination for a media component that didn't have a 532 corresponding candidate attribute. This is not needed for RTSP as 533 the ICE based lower layer transport specification either is supported 534 or another alternative transport is used. This is always explicitly 535 indicated in the SETUP request and response. 537 3.8.3. ICE Remote Candidate Transport Header Parameter 539 The Remote candidate attribute is not needed for RTSP for the 540 following reasons. Each SETUP results in a independent ICE 541 processing chain which either fails or results in promoting a single 542 candidate pair to usage. If a new SETUP request for the same media 543 is sent this needs to use a new userfragment and password to avoid 544 any race conditions or uncertainty for which processing round the 545 STUN requests relate to. 547 4. Detailed Solution 549 This section describes in detail how the interaction and flow of ICE 550 works with RTSP messages. 552 4.1. Session description and RTSP DESCRIBE (optional) 554 The RTSP server should indicate it has support for ICE by sending the 555 "rtsp-ice-d-m" SDP attribute in the response to the RTSP DESCRIBE 556 message if SDP is used. This allows RTSP clients to only send the 557 new ICE interchanges with servers that support ICE so limiting the 558 overhead on current non-ICE supporting RTSP servers. When not using 559 RTSP DESCRIBE it is still recommended to use the SDP attribute for 560 session description. 562 A Client can also use the DESCRIBE request to determine explicitly if 563 both server and any proxies support ICE. The client includes the 564 "Supported" header with its supported feature tags, including 565 "setup.ice-d-m". Any proxy upon seeing the "Supported" header will 566 include the "Proxy-Supported" header with the feature tags it 567 supports. The server will echo back the "Proxy-Supported" header and 568 its own version of the Supported header so enabling a client to 569 determine if all involved parties support ICE or not. Note that even 570 if a proxy is present in the chain that doesn't indicate support for 571 ICE, it may still work. 573 For example: 574 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 575 CSeq: 312 576 User-Agent: PhonyClient 1.2 577 Accept: application/sdp, application/example 578 Supported: setup.ice-d-m 580 S->C: RTSP/2.0 200 OK 581 CSeq: 312 582 Date: 23 Jan 1997 15:35:06 GMT 583 Server: PhonyServer 1.1 584 Content-Type: application/sdp 585 Content-Length: 367 586 Supported: setup.ice-d-m 588 v=0 589 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 590 s=SDP Seminar 591 i=A Seminar on the session description protocol 592 u=http://www.example.com/lectures/sdp.ps 593 e=seminar@example.com (Seminar Management) 594 t=2873397496 2873404696 595 a=recvonly 596 a=rtsp-ice-d-m 597 a=control: * 598 m=audio 3456 RTP/AVP 0 599 a=control: /audio 600 m=video 2232 RTP/AVP 31 601 a=control: /video 603 4.2. Setting up the Media Streams 605 The RTSP client reviews the session description returned, for example 606 by an RTSP DESCRIBE message, to determine what media resources that 607 need to be setup. For each of these media streams where the 608 transport protocol supports ICE connectivity checks, the client shall 609 gather candidate addresses as described in section 4.1.1 in 610 [I-D.ietf-mmusic-ice] according to standard ICE rather than the ICE- 611 Lite implementation. 613 4.3. RTSP SETUP Request 615 The RTSP client will then send at least one SETUP request per media 616 stream to establish the media streams required for the desired 617 session. For each media stream where it desires to use ICE it will 618 include a transport specification with "D-ICE" as the lower layer, 619 and each media stream SHALL have its own unique ICE candidates. This 620 transport specification SHOULD be placed first in the list to give it 621 highest priority. It is RECOMMENDED that additional transport 622 specifications are provided as a fallback in case of non ICE 623 supporting proxies. For example (Note that some lines are broken in 624 contradiction with the defined syntax due to space restrictions in 625 the documenting format: 627 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 628 CSeq: 302 629 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=8hhY; 630 ICE-Password=asd88fgpdd777uzjYhagZg; candidates=" 631 1 1 UDP 2130706431 10.0.1.17 8998 typ host; 632 2 1 UDP 1694498815 192.0.2.3 45664 typ srflx 633 raddr 10.0.1.17 rport 9002", 634 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 635 RTP/AVP/TCP;unicast;interleaved=0-1 636 Accept-Ranges: NPT, UTC 637 User-Agent: PhonyClient/1.2 638 Supported: setup.ice-d-m 640 The RTSP client will be initiating and thus the controlling party in 641 the ICE processing. 643 4.4. Gathering Candidates 645 Upon receiving a SETUP request the server can determine what media 646 resource should be delivered and which transport alternatives that 647 the client supports. If one based on D-ICE is on the list of 648 supported transports and prefered among the support, the below 649 applies. 651 The transport specification will provide which media protocol is to 652 be used and based on this and the clients candidates, the server 653 determines the protocol and if it supports ICE with that protocol. 654 The server shall then gather its candidates according to section 655 4.1.1 in [I-D.ietf-mmusic-ice]. Servers that have an address that is 656 generally reachable by any clients within the address scope the 657 server intends to serve MAY be specially configured (high- 658 reachability configuration). This special configuration has the goal 659 of reducing the server side candidate to preferably a single one per 660 (address family, media stream, media component) tuple. Instead of 661 gathering all possible addresses including relayed and server 662 reflexive addresses, the server uses a single address per address 663 family that it knows it should be reachable by a client behind one or 664 more NATs. The reason for this special configuration is two fold: 665 Firstly it reduces the load on the server in address gathering and in 666 ICE processing during the connectivity checks. Secondly it will 667 reduce the number of permutations for candidate pairs significantly 668 thus potentially speeding up the conclusion of the ICE processing. 669 Note however that using this option on a server that doesn't fulfill 670 the requirement of being reachable is counter-productive and it is 671 important that this is correctly configured. 673 4.5. RTSP Server Response 675 The server determines if the SETUP request is successful from the 676 other perspectives and will return a 200 OK response, otherwise 677 returning an error code from the list in Table 4 in 678 [I-D.ietf-mmusic-rfc2326bis]. At that point the server, having 679 selected a transport specification using the "D-ICE" lower layer, 680 will need to include that transport specification in the response 681 message. The transport specification shall include the candidates 682 gathered in SectionSection 4.4 in the "candidates" transport header 683 parameter as well as the server's username and password. In the case 684 that there are no valid candidate pairs with the combination of the 685 client and servers candidates, a 480 (ICE Processing Failed) error 686 response shall be returned which must include the servers' 687 candidates. The return of a 480 error allows both the server and 688 client to release its candidates. 690 S->C: RTSP/2.0 200 OK 691 CSeq: 302 692 Session: 12345678 693 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=MkQ3; 694 ICE-Password=pos12Dgp9FcAjpq82ppaF; candidates=" 695 1 1 UDP 2130706431 192.0.2.56 50234 typ host" 696 Accept-Ranges: NPT 697 Date: 23 Jan 1997 15:35:06 GMT 698 Server: PhonyServer 1.1 699 Supported: setup.ice-d-m 701 4.6. Server to Client ICE Connectivity Checks 703 The server shall start the connectivity checks following the 704 procedures described in Section 5.7 and 5.8 of [I-D.ietf-mmusic-ice] 705 unless it is configured to use the high-reachability option. If it 706 is then it can suppress its own checks until the servers checks are 707 triggered by the client's connectivity checks. 709 Please note that section 5.8 does specify that the start of 710 initiation of the checks are paced and new ones are only started 711 every Ta seconds. The motivation for this is documented in Appendix 712 B.1 of [I-D.ietf-mmusic-ice] as for SIP/SDP all media streams within 713 an offer/answer dialog are running using the same queue. To ensure 714 the same behavior with RTSP, the server SHALL use a single pacer 715 queue for all media streams within each RTSP session. 717 The values for the pacing of STUN and TURN transactions Ta and RTO 718 can be configured but have some minimum values defined in the ICE 719 specification. 721 When a connectivity check from the client reaches the server it will 722 result in a triggered check from the server as specified in section 723 7.2.1.4 of [I-D.ietf-mmusic-ice]. This is why servers with a high 724 reachability address can wait until this triggered check to send out 725 any checks for itself so saving resources and mitigating the DDoS 726 potential. 728 4.7. Client to Server ICE Connectivity Check 730 The client receives the SETUP response and learns the candidate 731 address to use for the connectivity checks. The client shall 732 initiate its connectivity check, following the procedures in Section 733 6 of [I-D.ietf-mmusic-ice]. The STUN transaction pacer SHALL be used 734 across all media streams part of the same RTSP session. 736 Aggressive nomination SHALL be used with RTSP. This doesn't have the 737 negative impact that it has in offer/answer as media playing only 738 starts after issuing a PLAY request. 740 4.8. Client Connectivity Checks Complete 742 When the client has concluded all of its connectivity checks and has 743 nominated its desired candidate for a particular media stream, it MAY 744 issue a PLAY request for that stream. Note, that due to the 745 aggressive nomination, there is a risk that any outstanding check may 746 nominate another pair than what was already nominated. If the client 747 has locally determined that its checks have failed it may try 748 providing an extended set of candidates and update the server 749 candidate list by issuing a new SETUP request for the media stream. 751 If the client concluded its connectivity checks successfully and 752 therefore sent a PLAY request but the server cannot conclude 753 successfully, the server will respond with a 480 (ICE Processing 754 Failed). Upon receiving the 480 (ICE Processing Failed) response, 755 the client may send a new SETUP request assuming it has any new 756 information that can be included in the candidate list. If the 757 server is still performing the checks it will respond with a 150 (CE 758 connectivity checks in progress) response to indicate this. 760 4.9. Server Connectivity Checks Complete 762 When the RTSP server receives a PLAY request, it checks to see that 763 the connectivity checks have concluded successfully and only then 764 will it play the stream. If the PLAY request is for a particular 765 media stream, the server only needs to check that the connectivity 766 checks for that stream completely successfully. If the server has 767 not concluded its connectivity checks the server indicates that by 768 sending the 150 (ICE connectivity checks in progress) 769 (Section 3.5.1). If there is a problem with the checks then the 770 server sends to the client a 480 response to indicate a failure of 771 the checks. If the checks are successful then the server sends a 200 772 OK response and starts delivering media. 774 4.10. Releasing Candidates 776 Both server and client may release its non nominated candidates as 777 soon as a 200 PLAY response has been issued/received and no 778 outstanding connectivity checks exist. 780 4.11. Steady State 782 The client will continue to use STUN to send keep-alive for the used 783 bindings. This is important as normally RTSP play mode sessions only 784 contain traffic from the server to the client so the bindings in the 785 NAT need to be refreshed by the client to server traffic provided by 786 the STUN keep-alive. 788 4.12. re-SETUP 790 The server SHALL support SETUP requests in PLAYING state, as long as 791 the SETUP changes only the ICE parameters, which are: ICE-Password, 792 ICE-ufrag and the content of ICE candidates. 794 If the client decides to change any parameter related to the media 795 stream SETUP it will send a new SETUP request. In this new SETUP 796 request the client SHALL include a new different username and 797 password to use in the ICE processing. This request will also cause 798 the ICE processing to start from the beginning again. 800 If the RTSP session is in playing state at the time of sending the 801 SETUP request, the ICE connectivity checks SHALL use Regular 802 nomination. Any ongoing media delivery continues on the previously 803 nominated candidate pairs until the new pairs have been nominated for 804 the individual candidate. Once the nomination of the new candidate 805 pair has completed, all unused candidates may be released. 807 4.13. Server Side Changes After Steady State 809 A Server may require an ICE restart because of server side load 810 balancing or a failure resulting in an IP address and a port number 811 change. It shall use the PLAY_NOTIFY method to inform the client 812 (Section 13.5 [I-D.ietf-mmusic-rfc2326bis]) with a new Notify-Reason 813 header: ice-restart. The server will identify if the change is for a 814 single media or for the complete session by including the 815 corresponding URI in the PLAY_NOTIFY request. 817 Upon receiving and responding to this PLAY_NOTIFY with ice-restart 818 reason the client SHALL gather new ICE candidates, send SETUP 819 requests for each media stream part of the session. The server 820 provides its candidates in the SETUP response the same way as for the 821 first time ICE processing. Both server and client shall provide new 822 ICE usernames and passwords. The client MAY issue the SETUP request 823 while the session is in PLAYING state. 825 If the RTSP session is in PLAYING state when the client issues the 826 SETUP request the client SHALL use regular nomination. If not the 827 client will use the same procedures as for when first creating the 828 session. 830 Note that keepalives on the previous set of candidate pairs should 831 continue until all new candidate pairs have been nominated. After 832 having nominated a new set of candidate pairs, the client may 833 continue to receive media for some additional time. Even if the 834 server stops delivering media over that candidate pair at the time of 835 nomination, media may arrive for up to one maximum segment lifetime 836 as defined in TCP (2 minutes). Unfortuntately, if the RTSP server is 837 divided into a separate controller and media streame, a failure may 838 result in continued media delivery for a longer time than the maximum 839 segment liftime, thus source filtering is recommended. 841 For example: 843 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 844 CSeq: 854 845 Notify-Reason: ice-restart 846 Session: uZ3ci0K+Ld 847 Server: PhonyServer 1.1 849 C->S: RTSP/2.0 200 OK 850 CSeq: 854 851 User-Agent: PhonyClient/1.2 853 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 854 CSeq: 302 855 Session: uZ3ci0K+Ld 856 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=Kl1C; 857 ICE-Password=H4sICGjBsEcCA3Rlc3RzLX; candidates =" 858 1 1 UDP 2130706431 10.0.1.17 8998 typ host; 859 2 1 UDP 1694498815 192.0.2.3 51456 typ srflx 860 raddr 10.0.1.17 rport 9002", 862 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 863 RTP/AVP/TCP;unicast;interleaved=0-1 864 Accept-Ranges: NPT, UTC 865 User-Agent: PhonyClient/1.2 867 C->S: SETUP rtsp://server.example.com/fizzle/foo/video RTSP/2.0 868 CSeq: 303 869 Session: uZ3ci0K+Ld 870 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=hZv9; 871 ICE-Password=JAhA9myMHETTFNCrPtg+kJ; candidates=" 872 1 1 UDP 2130706431 10.0.1.17 9000 typ host; 873 2 1 UDP 1694498815 192.0.2.3 51576 typ srflx 874 raddr 10.0.1.17 rport 9004", 875 RTP/AVP/UDP; unicast; dest_addr=":6972"/":6973", 876 RTP/AVP/TCP;unicast;interleaved=0-1 877 Accept-Ranges: NPT, UTC 878 User-Agent: PhonyClient/1.2 880 S->C: RTSP/2.0 200 OK 881 CSeq: 302 882 Session: uZ3ci0K+Ld 883 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=CbDm; 884 ICE-Password=OfdXHws9XX0eBr6j2zz9Ak; candidates=" 885 1 1 UDP 2130706431 192.0.2.56 50234 typ host" 886 Accept-Ranges: NPT 887 Date: 23 Jan 1997 15:43:12 GMT 888 Server: PhonyServer 1.1 890 S->C: RTSP/2.0 200 OK 891 CSeq: 303 892 Session: uZ3ci0K+Ld 893 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=jigs; 894 ICE-Password=Dgx6fPj2lsa2WI8b7oJ7+s; candidates=" 895 1 1 UDP 2130706431 192.0.2.56 47233 typ host" 896 Accept-Ranges: NPT 897 Date: 23 Jan 1997 15:43:13 GMT 898 Server: PhonyServer 1.1 900 5. ICE and Proxies 902 RTSP allows for proxies which can be of two fundamental types 903 depending if they relay and potentially cache the media or not. 904 Their differing impact on the RTSP NAT traversal solution, including 905 backwards compatibility, is explained below. 907 5.1. Media Handling Proxies 909 An RTSP proxy that relays or caches the media stream for a particular 910 media session can be considered to split the media transport into two 911 parts: A media transport between the server and the proxy according 912 to the proxies need, and delivery from the proxy to the client. This 913 split means that the NAT traversal solution will need to be run on 914 each individual media leg according to need. 916 It is RECOMMENDED that any media handling proxy support the media NAT 917 traversal defined within this specification. This is for two 918 reasons: Firstly to enable clients to perform NAT traversal for the 919 media between the proxy and itself and secondly to allow the proxy to 920 be topology independent so able to support performing NAT traversal 921 for non-NAT traversal capable clients present in the same address 922 domain. 924 For a proxy to support the media NAT traversal defined in this 925 specification a proxy will need to implement the solution fully and 926 be ready as both a controlling and a controlled ICE peer. The proxy 927 also SHALL include the "setup.ice-d-m" feature tag in any applicable 928 capability negotiation headers, such as "Proxy-Supported." 930 5.2. Signalling Only Proxies 932 A signalling only proxy handles only the RTSP signalling and does not 933 have the media relayed through proxy functions. This type of proxy 934 is not likely to work unless the media NAT traversal solution is in 935 place between the client and the server, because the DoS protection 936 measures usually prevent media delivery to other addresses other than 937 from where the RTSP signalling arrives at the server. 939 The solution for the Signalling Only proxy is that it must forward 940 the RTSP SETUP requests including any transport specification with 941 the "D-ICE" lower layer and the related transport parameters. A 942 proxy supporting this functionality SHOULD indicate its capability by 943 always including the "setup.ice-d-m" feature tag in the "Proxy- 944 Supported" header. 946 5.3. Non-supporting Proxies 948 A media handling proxy that doesn't support the ICE media NAT 949 traversal specified here is assumed to remove the transport 950 specification and use any of the lower prioritized transport 951 specifications if provided by the requester. The specification of 952 such a non ICE transport enables the negotiation to complete, 953 although with a less prefered method as a NAT between the proxy and 954 the client will likely result in failure of the media path. 956 A non-media handling transport proxy is expected to ignore and simply 957 forward all unknown transport specifications, however, this can only 958 be guaranteed for proxies following the published RTSP 2.0 959 specification. 961 Unfortunately the usage of the "setup.ice-d-m" feature tag in the 962 proxy-require will have contradicting results. For a non ICE 963 supporting media handling proxy, the inclusion of the feature tag 964 will result in aborting the setup and indicating that it isn't 965 supported, which is desirable if you want to provide other fallbacks 966 or other transport configurations to handle the situation. For non- 967 supporting non-media handling proxies the result will also result in 968 aborting the setup, however, setup might have worked if the proxy- 969 require tag wasn't present. This variance in results is the reason 970 we don't recommend the usage of the Proxy-Require header. Instead we 971 recommend the usage of the Supported header to force proxies to 972 include the feature tags they support in the proxy-supported which 973 will provide a positive indication when all proxies in the chain 974 between the client and server support the functionality. Even if not 975 explicitly indicating support, any SETUP response including a 976 transport specification with "D-ICE" will be implicit indication that 977 the proxy chain supports at least passthrough of this media. 979 6. RTP and RTCP Multiplexing 981 [I-D.ietf-avt-rtp-and-rtcp-mux] specifies how and when RTP and RTCP 982 can be multiplexed on the same port. This multiplexing SHALL be 983 combined with ICE as it makes RTP and RTCP need only a single 984 component per media stream instead of two, so reducing the load on 985 the connectivity checks. For details on how one negotiate RTP and 986 RTCP multiplexing, see Appendix B [I-D.ietf-mmusic-rfc2326bis]. 988 Multiplexing RTP and RTCP has the benefit that it avoids the need for 989 handling two components per media stream when RTP is used as the 990 media transport protocol. This eliminates at least one STUN check 991 per media stream and will also reduce the time needed to complete the 992 ICE processing by at least the time it takes to pace out the 993 additional STUN checks of up to one complete round trip time fpr a 994 single media stream. In addition to the protocol performance 995 improvements, the server and client side complexities are reduced as 996 multiplexing halves the total number of STUN instances and holding 997 the associate state. Multiplexing will also reduce the combinations 998 and length of the list of possible candidates. 1000 The implementation of RTP and RTCP multiplexing is additional work 1001 required for this solution. However, when implementing the ICE 1002 solution a server or client will need to implement a de-multiplexer 1003 between the STUN, and RTP or RTCP packets below the RTP/RTCP 1004 implementation anyway, so the additional work of one new 1005 demultiplexing point directly connected to the STUN and RTP/RTCP 1006 seems small relative to the benefits provided. 1008 Due to the above mentioned benefits, RTSP servers and clients that 1009 supports "D-ICE" lower layer transport in combination with RTP SHALL 1010 also implement RTP and RTCP multiplexing as specified in this section 1011 and [I-D.ietf-avt-rtp-and-rtcp-mux]. 1013 7. Open Issues 1015 Below is listed the known open issues and questions that needs to be 1016 resolved: 1018 1. None 1020 8. IANA Considerations 1022 This document request registration in a number of registries, both 1023 for RTSP and SDP. 1025 8.1. RTSP Feature Tags 1027 This document request that one RTSP 2.0 feature tags are registered 1028 in the "RTSP feature tag" registry: 1030 setup.ice-d-m See Section Section 3.4. 1032 8.2. Transport Protocol Specifications 1034 This document needs to register a number of transport protocol 1035 combinations are registered in RTSP's "Transport Protocol 1036 Specifications" registry. 1038 "RTP/AVP/D-ICE" 1040 "RTP/AVPF/D-ICE" 1042 "RTP/SAVP/D-ICE" 1044 "RTP/SAVPF/D-ICE" 1046 8.3. RTSP Transport Parameters 1048 This document requests that 3 transport parameters are registered in 1049 RTSP's "Transport Parameters": 1051 "candidates": See Section Section 3.2. 1053 "ICE-Password": See Section Section 3.3. 1055 "ICE-ufrag": See Section Section 3.3. 1057 8.4. RTSP Status Codes 1059 This document requests that 2 assignments are done in the "RTSP 1060 Status Codes" registry. The suggested values are: 1062 150: See Section Section 3.5.1. 1064 480: See Section Section 3.5.2. 1066 8.5. Notify-Reason value 1068 This document requests that one assignment is done in the Notify- 1069 Reason header value registry. The suggested value is: 1071 ice-restart: See section Section 3.6. 1073 8.6. SDP Attribute 1075 The registration of one SDP attribute is requested: 1076 SDP Attribute ("att-field"): 1078 Attribute name: rtsp-ice-d-m 1079 Long form: ICE for RTSP datagram media NAT traversal 1080 Type of name: att-field 1081 Type of attribute: Session level only 1082 Subject to charset: No 1083 Purpose: RFC XXXX 1084 Reference: RFC XXXX 1085 Values: No values defined. 1086 Contact: Magnus Westerlund 1087 E-mail: magnus.westerlund@ericsson.com 1088 phone: +46 10 714 82 87 1090 9. Security Considerations 1092 ICE [I-D.ietf-mmusic-ice] provides an extensive discussion on 1093 security considerations which applies here as well. 1095 9.1. ICE and RTSP 1097 A long-standing risk with transmitting a packet stream over UDP is 1098 that the host may not be interested in receiving the stream. On 1099 today's Internet many hosts are behind NATs or operate host firewalls 1100 which do not respond to unsolicited packets with an ICMP port 1101 unreachable error. Thus, an attacker can construct SDP with a 1102 victim's IP address and cause a flood of media packets to be sent to 1103 a victim. The addition of ICE, as described in this document, 1104 provides protection from the attack described above. By performing 1105 the ICE connectivity check, the media server receives confirmation 1106 that the RTSP client wants the media. While this protection could 1107 also be implemented by requiring the IP addresses in the SDP match 1108 the IP address of the RTSP signaling packet, such a mechanism does 1109 not protect other hosts with the same IP address (such as behind the 1110 same NAT), and such a mechanism would prohibit separating the RTSP 1111 controller from the media playout device (e.g., an IP-enabled remote 1112 control and an IP-enabled television). 1114 10. Acknowledgements 1116 The authors would like to thank Remi Denis-Courmont for suggesting 1117 the method of integrating ICE in RTSP signalling, Dan Wing for help 1118 with the security section and numerous other issues. 1120 11. References 1122 11.1. Normative References 1124 [I-D.ietf-avt-rtp-and-rtcp-mux] 1125 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1126 Control Packets on a Single Port", 1127 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 1128 August 2007. 1130 [I-D.ietf-mmusic-ice] 1131 Rosenberg, J., "Interactive Connectivity Establishment 1132 (ICE): A Protocol for Network Address Translator (NAT) 1133 Traversal for Offer/Answer Protocols", 1134 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1136 [I-D.ietf-mmusic-rfc2326bis] 1137 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1138 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1139 (RTSP)", draft-ietf-mmusic-rfc2326bis-21 (work in 1140 progress), June 2009. 1142 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1143 Requirement Levels", BCP 14, RFC 2119, March 1997. 1145 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1146 Description Protocol", RFC 4566, July 2006. 1148 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1149 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1151 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1152 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1153 October 2008. 1155 11.2. Informative References 1157 [I-D.ietf-mmusic-rtsp-nat-evaluation] 1158 Westerlund, M. and T. Zeng, "The evaluation of different 1159 NAT traversal Techniques for media controlled by Real- 1160 time Streaming Protocol (RTSP)", 1161 draft-ietf-mmusic-rtsp-nat-evaluation-01 (work in 1162 progress), July 2008. 1164 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1165 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1167 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1168 Address Translator (Traditional NAT)", RFC 3022, 1169 January 2001. 1171 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1172 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1174 Authors' Addresses 1176 Jeff Goldberg 1177 Cisco 1178 11 New Square, Bedfont Lakes 1179 Feltham,, Middx TW14 8HA 1180 United Kingdom 1182 Phone: +44 20 8824 1000 1183 Fax: 1184 Email: jgoldber@cisco.com 1185 URI: 1187 Magnus Westerlund 1188 Ericsson 1189 Torshamsgatan 23 1190 Stockholm, SE-164 80 1191 Sweden 1193 Phone: +46 8 719 0000 1194 Fax: 1195 Email: magnus.westerlund@ericsson.com 1196 URI: 1198 Thomas Zeng 1199 Nextwave Wireless, Inc. 1200 12670 High Bluff Drive 1201 San Diego, CA 92130 1202 USA 1204 Phone: +1 858 480 3100 1205 Fax: 1206 Email: thomas.zeng@gmail.com 1207 URI: