idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-22.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. == 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 10, 2014) is 3571 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-rtsp-nat-evaluation-14 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 5 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 11, 2015 Ericsson 6 T. Zeng 7 Nextwave Wireless, Inc. 8 July 10, 2014 10 A Network Address Translator (NAT) Traversal Mechanism for Media 11 Controlled by Real-Time Streaming Protocol (RTSP) 12 draft-ietf-mmusic-rtsp-nat-22 14 Abstract 16 This document defines a solution for Network Address Translation 17 (NAT) traversal for datagram based media streams set up and 18 controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). 19 It uses Interactive Connectivity Establishment (ICE) adapted to use 20 RTSP as a signaling channel, defining the necessary RTSP extensions 21 and procedures. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 11, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 60 4. RTSP Extensions . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. ICE Transport Lower Layer . . . . . . . . . . . . . . . . 6 62 4.2. ICE Candidate Transport Header Parameter . . . . . . . . 7 63 4.3. ICE Password and Username Transport Header Parameters . . 10 64 4.4. ICE Feature Tag . . . . . . . . . . . . . . . . . . . . . 11 65 4.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . 11 66 4.5.1. 150 ICE Connectivity Checks in Progress . . . . . . . 12 67 4.5.2. 480 ICE Processing Failed . . . . . . . . . . . . . . 12 68 4.6. New Reason for PLAY_NOTIFY . . . . . . . . . . . . . . . 12 69 4.7. Server Side SDP Attribute for ICE Support . . . . . . . . 12 70 5. ICE-RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 5.1. ICE Features Not Required . . . . . . . . . . . . . . . . 13 72 5.1.1. ICE-Lite . . . . . . . . . . . . . . . . . . . . . . 13 73 5.1.2. ICE-Mismatch . . . . . . . . . . . . . . . . . . . . 13 74 5.1.3. ICE Remote Candidate Transport Header Parameter . . . 13 75 5.2. High-Reachability Configuration . . . . . . . . . . . . . 14 76 6. Detailed Solution . . . . . . . . . . . . . . . . . . . . . . 14 77 6.1. Session description and RTSP DESCRIBE (optional) . . . . 14 78 6.2. Setting up the Media Streams . . . . . . . . . . . . . . 15 79 6.3. RTSP SETUP Request . . . . . . . . . . . . . . . . . . . 15 80 6.4. Gathering Candidates . . . . . . . . . . . . . . . . . . 16 81 6.5. RTSP Server Response . . . . . . . . . . . . . . . . . . 17 82 6.6. Server to Client ICE Connectivity Checks . . . . . . . . 17 83 6.7. Client to Server ICE Connectivity Check . . . . . . . . . 18 84 6.8. Client Connectivity Checks Complete . . . . . . . . . . . 19 85 6.9. Server Connectivity Checks Complete . . . . . . . . . . . 19 86 6.10. Freeing Candidates . . . . . . . . . . . . . . . . . . . 20 87 6.11. Steady State . . . . . . . . . . . . . . . . . . . . . . 20 88 6.12. Re-SETUP . . . . . . . . . . . . . . . . . . . . . . . . 20 89 6.13. Server Side Changes After Steady State . . . . . . . . . 21 90 7. ICE and Proxies . . . . . . . . . . . . . . . . . . . . . . . 23 91 7.1. Media-Handling Proxies . . . . . . . . . . . . . . . . . 23 92 7.2. Signaling-Only Proxies . . . . . . . . . . . . . . . . . 24 93 7.3. Non-supporting Proxies . . . . . . . . . . . . . . . . . 24 94 8. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . . . 25 95 9. Fallback and Using Partial ICE functionality to improve 96 NAT/Firewall traversal . . . . . . . . . . . . . . . . . . . 26 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 99 10.1. RTSP Feature Tags . . . . . . . . . . . . . . . . . . . 27 100 10.2. Transport Protocol Identifiers . . . . . . . . . . . . . 28 101 10.3. RTSP Transport Parameters . . . . . . . . . . . . . . . 28 102 10.4. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 28 103 10.5. Notify-Reason value . . . . . . . . . . . . . . . . . . 28 104 10.6. SDP Attribute . . . . . . . . . . . . . . . . . . . . . 29 105 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 106 11.1. ICE and RTSP . . . . . . . . . . . . . . . . . . . . . . 29 107 11.2. Logging . . . . . . . . . . . . . . . . . . . . . . . . 30 108 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 109 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 110 13.1. Normative References . . . . . . . . . . . . . . . . . . 30 111 13.2. Informative References . . . . . . . . . . . . . . . . . 31 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 114 1. Introduction 116 Real-time Streaming Protocol (RTSP) [RFC2326] and RTSP 2.0 117 [I-D.ietf-mmusic-rfc2326bis] are protocols used to setup and control 118 one or more media streams delivering media to receivers. It is 119 RTSP's functionality of setting up media streams that causes serious 120 issues with Network Address Translators (NAT) [RFC3022] unless extra 121 provisions are taken by the protocol. There is thus a need for a NAT 122 traversal mechanism for the media setup using RTSP. 124 RTSP 1.0 [RFC2326] has suffered from the lack of a standardized NAT 125 traversal mechanism for a long time, however due to quality of the 126 RTSP 1.0 specification, the work was difficult to specify in an 127 interoperable fashion. This document is therefore built on the 128 specification of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. RTSP 2.0 is 129 similar to RTSP 1.0 in many respects but significantly for this work, 130 it contains a well defined extension mechanism that allows a NAT 131 traversal extension to be defined that is backwards compatible with 132 RTSP 2.0 peers not supporting the extension. This extension 133 mechanism was not possible in RTSP 1.0 as it would break RTSP 1.0 134 syntax and cause compatibility issues. 136 There have been a number of suggested ways of resolving the NAT- 137 traversal of media for RTSP of most of which are already used in 138 implementations. The evaluation of these NAT traversal solutions in 139 [I-D.ietf-mmusic-rtsp-nat-evaluation] has shown that there are many 140 issues to consider, so after extensive evaluation, a mechanism based 141 on Interactive Connectivity Establishment (ICE) [RFC5245] was 142 selected. There were mainly two reasons: Firstly, the mechanism 143 supports RTSP servers behind NATs and secondly, the mechanism 144 mitigates the security threat of using RTSP servers as Distributed 145 Denial of Service (DDoS) attack tools. 147 This document specifies an ICE-based solution that is optimized for 148 media delivery from server to client. If future extensions are 149 specified for other delivery modes than "PLAY", then the 150 optimizations in regards to when PLAY requests are sent needs to be 151 reconsidered. 153 The NAT problem for RTSP signaling traffic is a less prevalent 154 problem than the NAT problem for RTSP media streams. Consequently, 155 the former is left for future study. 157 The ICE usage defined in this specification is called ICE-RTSP and 158 does not match the full ICE for SIP/SDP or ICE-Lite as defined in the 159 ICE specification [RFC5245]. ICE-RTSP is tailored to the needs of 160 RTSP and is slightly simpler than ICE-Full for both clients and 161 servers. 163 2. Definitions 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in RFC 168 2119 [RFC2119]. 170 3. Solution Overview 172 This overview assumes that the reader has some familiarity with how 173 ICE [RFC5245] in the context of "SIP: Session Initiation Protocol" 174 [RFC3261] and "An Offer/Answer Model with the Session Description 175 Protocol (SDP)" [RFC3264] works, as it primarily points out how the 176 different ICE steps are accomplished in RTSP. 178 1. The RTSP server should indicate it has support for ICE via a new 179 SDP [RFC4566] attribute ("a=rtsp-ice-d-m") in, for example, the 180 SDP returned in the RTSP DESCRIBE message. This allows RTSP 181 clients to only perform the new ICE exchanges with servers that 182 support ICE. If RTSP DESCRIBE is used, the normal capability 183 determination mechanism should also be used, i.e., "Supported" 184 header with a new ICE feature tag. Note: Both mechanisms should 185 be supported, as there are various use cases where only one of 186 them is used. 188 2. The RTSP client reviews the session description returned, for 189 example by an RTSP DESCRIBE message, to determine what media 190 streams need to be setup. For each of these media streams where 191 the transport protocol supports Session Traversal Utilities for 192 (NAT) (STUN) [RFC5389] based connectivity checks, the client 193 gathers candidate addresses. See section 4.1.1 in ICE 195 [RFC5245]. The client then runs a STUN server on each of the 196 local candidates transport addresses it has gathered. 198 3. The RTSP client sends SETUP requests containing a transport 199 specification with a lower layer indicating ICE and a new RTSP 200 Transport header parameter "candidates" listing the ICE 201 candidates for each media stream. 203 4. After receiving the list of candidates from a client, the RTSP 204 server gathers its own candidates. If the server is not behind 205 a NAT, then a single candidate per address family (e.g., IPv4 206 and IPv6), media stream and media component tuple can be 207 included to reduce the number of combinations and speed up the 208 completion. 210 5. The server sets up the media and if successful responds to the 211 SETUP request with a 200 OK response. In that response the 212 server selects the transport specification using ICE and 213 includes its candidates in the candidates parameter. 215 6. The server starts the connectivity checks following the 216 procedures described in Section 5.7 and 5.8 of ICE [RFC5245]. 217 If the server is not behind a NAT and uses a public IP address 218 with a single candidate per (media stream, component, address 219 family) tuple, then the server may be configured to not initiate 220 connectivity checks. 222 7. The client receives the SETUP response and learns the candidate 223 addresses to use for the connectivity checks, and then initiates 224 its connectivity check, following the procedures in Section 6 of 225 ICE [RFC5245]. 227 8. When a connectivity check from the client reaches the server it 228 will result in a triggered check from the server. This is why 229 servers not behind a NAT can wait until this triggered check to 230 send out any checks for itself, so saving resources and 231 mitigating the DDoS potential from server initiated connectivity 232 checks. 234 9. When the client has concluded its connectivity checks, including 235 nominating candidates, and has correspondingly received the 236 server connectivity checks on the nominated candidates for all 237 mandatory components of all media streams, it can issue a PLAY 238 request. If the connectivity checks have not concluded 239 successfully, then the client may send a new SETUP request if it 240 has any new information or believes the server may be able to do 241 more that can result in successful checks. 243 10. When the RTSP server receives a PLAY request, it checks to see 244 that the connectivity checks have concluded successfully, and 245 only then can it play the stream. If there is a problem with 246 the checks then the server sends either a 150 (ICE connectivity 247 checks in progress) response to show that it is still working on 248 the connectivity checks, or a 480 (ICE Processing Failed) 249 response to indicate a failure of the checks. If the checks are 250 successful, then the server sends a 200 OK response and starts 251 delivering media. 253 The client and server may release unused candidates when the ICE 254 processing has concluded and a single candidate per component has 255 been nominated and a PLAY response has been received (Client) or sent 256 (Server). 258 The client needs to continue to use STUN as a keep-alive mechanism 259 for the used candidate pairs to keep their NAT bindings current. 260 RTSP Servers behind NATs will also need to send keep-alive messages 261 when not sending media. This is important since RTSP media sessions 262 often contain only media traffic from the server to the client so the 263 bindings in the NAT need to be refreshed by client to server traffic 264 provided by the STUN keep-alive. 266 4. RTSP Extensions 268 This section defines the necessary RTSP extensions for performing ICE 269 with RTSP. Note that these extensions are based on the SDP 270 attributes in the ICE specification unless expressly indicated 271 otherwise. 273 4.1. ICE Transport Lower Layer 275 A new lower layer "D-ICE" for transport specifications is defined. 276 This lower layer is datagram clean except that the protocol used must 277 be possible to demultiplex from STUN messages (see STUN [RFC5389]). 278 With datagram clean we mean that it has to be capable of describing 279 the length of the datagram, transport that datagram (as a binary 280 chunk of data) and provide it at the receiving side as one single 281 item. This lower layer can be any transport type defined for ICE 282 which does provide datagram transport capabilities. UDP based 283 transport candidates are defined in ICE [RFC5245] and MUST be 284 supported. It is OPTIONAL to also support TCP based candidates as 285 defined by "TCP Candidates with Interactive Connectivity 286 Establishment (ICE)" [RFC6544]. The TCP based candidate fulfills the 287 requirements on providing datagram transport and can thus be used in 288 combination with RTP. Additional transport types for candidates may 289 be defined in the future. 291 This lower layer uses ICE to determine which of the different 292 candidates shall be used and then, when the ICE processing has 293 concluded, uses the selected candidate to transport the datagrams 294 over this transport. 296 This lower layer transport can be combined with all upper layer media 297 transport protocols that are possible to demultiplex with STUN and 298 which use datagrams. This specification defines the following 299 combinations: 301 o RTP/AVP/D-ICE 303 o RTP/AVPF/D-ICE 305 o RTP/SAVP/D-ICE 307 o RTP/SAVPF/D-ICE 309 This list can be extended with more transport specifications after 310 having performed the evaluation that they are compatible with D-ICE 311 as lower layer. The registration is required to follow the registry 312 rules for the Transport Protocol Identifier (See Section 22.13.1 of 313 [I-D.ietf-mmusic-rfc2326bis]). 315 The lower-layer "D-ICE" has the following rules for the inclusion of 316 the RTSP transport header (Section 18.54 of RTSP 2.0 317 [I-D.ietf-mmusic-rfc2326bis]) parameters: 319 unicast: ICE only supports unicast operations, thus it is REQUIRED 320 that one include the unicast indicator parameter, (see section 321 18.54 in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]). 323 candidates: The "candidates" parameter SHALL be included as this 324 specifies at least one candidate to try to establish a working 325 transport path with. 327 dest_addr: This parameter MUST NOT be included since "candidates" is 328 used instead to provide the necessary address information. 330 ICE-Password: This parameter SHALL be included (See Section 4.2). 332 ICE-ufrag: This parameter SHALL be included (See Section 4.2). 334 4.2. ICE Candidate Transport Header Parameter 336 This section defines a new RTSP transport parameter for carrying ICE 337 candidates related to the transport specification they appear within, 338 which may then be validated with an end-to-end connectivity check 339 using STUN [RFC5389]. Transport parameters may only occur once in 340 each transport specification. For transport specifications using 341 "D-ICE" as lower layer, this parameter MUST be present. The 342 parameter can contain one or more ICE candidates. In the SETUP 343 response there is only a single transport specification, and if that 344 uses the "D-ICE" lower layer this parameter MUST be present and 345 include the server side candidates. 347 The ABNF [RFC5234] for these transport header parameters are: 349 trns-parameter = 351 trns-parameter =/ SEMI ice-trn-par 352 ice-trn-par = "candidates" EQUAL DQ SWS ice-candidate 353 *(SEMI ice-candidate) SWS DQ 354 ice-candidate = foundation SP 355 component-id SP 356 transport SP 357 priority SP 358 connection-address SP 359 port SP 360 cand-type 361 [SP rel-addr] 362 [SP rel-port] 363 [SP tcp-type-ext] ; Mandatory if transport = TCP 364 *(SP extension-att-name SP extension-att-value) 366 foundation = 367 component-id = 368 transport = 369 priority = 370 cand-type = 371 rel-addr = 372 rel-port = 373 tcp-type-ext = 374 extension-att-name = 375 extension-att-value = 376 connection-address = 377 port = 378 EQUAL = 379 DQ = 380 SWS = 381 SEMI = 382 SP = 384 : is the unicast IP address of the candidate, 385 allowing for IPv4 addresses, IPv6 addresses and Fully qualified 386 domain names (FQDN), taken from SDP [RFC4566]. Note, This context 387 MUST have a unicast address for this parameter, even though a 388 multicast address would be syntactically valid. The connection 389 address SHOULD use the same format (explicit IP or FQDN) as in the 390 dest_addr parameter used in the transport specification that 391 express any fallback. An IP address is preferred for simplicity, 392 but both an IP Address and FQDN can be used. In the FQDN case, 393 when receiving a SETUP request or response containing an FQDN in a 394 candidate parameter, the FQDN is looked up in the DNS first using 395 an AAAA record (assuming the agent supports IPv6), and if no 396 result is found or the agent only supports IPv4, using an A 397 record. If the DNS query returns more than one IP address, one is 398 chosen, and then used for the remainder of ICE processing which in 399 RTSP is subsequent RTSP SETUPs for the same RTSP session. 401 : is the port of the candidate; the syntax is defined by SDP 402 [RFC4566]. 404 : indicates the transport protocol for the candidate. 405 The ICE specification defines UDP. "TCP Candidates with 406 Interactive Connectivity Establishment (ICE)" [RFC6544] defines 407 how TCP is used as candidates. Additional extensibility is 408 provided to allow for future transport protocols to be used with 409 ICE, such as the Datagram Congestion Control Protocol (DCCP) 410 [RFC4340]. 412 : is an identifier that is equivalent for two 413 candidates that are of the same type, share the same base IP 414 address, and come from the same STUN server. It is composed of 415 one to thirty two . The foundation is used to optimize 416 ICE performance in the Frozen algorithm (as described in 417 [RFC5245]). 419 : identifies the specific component of the media 420 stream for which this is a candidate and is a positive integer 421 belonging to the range 1-256. It MUST start at 1 and MUST 422 increment by 1 for each component of a particular media stream. 423 For media streams based on RTP, candidates for the actual RTP 424 media MUST have a component ID of 1, and candidates for RTCP MUST 425 have a component ID of 2 unless RTP and RTCP Multiplexing 426 (Section 8) is used, in which case the second component is omitted 427 and RTP and RTCP are both transported over the first component. 428 Other types of media streams which require multiple components 429 MUST develop specifications which define the mapping of components 430 to component IDs. See Section 14 in [RFC5245] for additional 431 discussion on extending ICE to new media streams. 433 : is a positive integer in the range 1 to (2**31 - 1). 435 : encodes the type of candidate. The ICE specification 436 defines the values "host", "srflx", "prflx" and "relay" for host, 437 server reflexive, peer reflexive and relayed candidates, 438 respectively. The set of candidate types is extensible for the 439 future. 441 and : convey transport addresses related to the 442 candidate, useful for diagnostics and other purposes. 443 and MUST be present for server reflexive, peer 444 reflexive and relayed candidates. If a candidate is server or 445 peer reflexive, and are equal to the base 446 for that server or peer reflexive candidate. If the candidate is 447 relayed, and are equal to the mapped address 448 in the TURN Allocate Response that provided the client with that 449 relayed candidate (see Appendix B.3 of ICE [RFC5245] for a 450 discussion of its purpose). If the candidate is a host candidate 451 and MUST be omitted. 453 : conveys the candidate's connection type (active, 454 passive, or S-O) for TCP based candidates. This MUST be included 455 for candidates that have set to TCP and MUST NOT be 456 included for other transport types, including UDP. 458 and : These are prototypes 459 for future extensions of the candidate line. The ABNF for these 460 allow any 8-bit value except NUL, CR, or LF. However, the 461 extensions will occur within a structured line that uses the DQ, 462 SEMI, SWS and SP ABNF constructs as delimiters, thus those 463 delimiter characters MUST be escaped if they would occur within an 464 extension-att-name or extension-att-value. The escape mechanism 465 that MUST be used is the Percent-Encoding defined in Section 2.1 466 of [RFC3986]. This mechanism is selected as it anyway needs to be 467 supported in an RTSP implementation to deal with URIs. The byte 468 values (in hex) that MUST be escaped are the following ones: 0x09, 469 0x20, 0x22, 0x25, 0x3B. 471 4.3. ICE Password and Username Transport Header Parameters 473 The ICE password and username for each agent needs to be transported 474 using RTSP. For that purpose new Transport header parameters are 475 defined (see section 18.54 of [I-D.ietf-mmusic-rfc2326bis]. 477 There MUST be an "ICE-Password" and "ICE-ufrag" parameter for each 478 media stream. If two SETUP requests in the same RTSP session have 479 identical ICE-ufrag values, they MUST have identical ICE-Password 480 values. 482 The ICE-ufrag and ICE-Password parameter values MUST be chosen 483 randomly at the beginning of a session. The ICE-ufrag value MUST 484 contain at least 24 bits of randomness, and the ICE-Password value 485 MUST contain at least 128 bits of randomness. This means that the 486 ICE-ufrag value will be at least 4 characters long, and the ICE- 487 Password value at least 22 characters long, since the grammar for 488 these attributes allows for 6 bits of randomness per character. The 489 values MAY be longer than 4 and 22 characters respectively, of 490 course, up to 256 characters. The upper limit allows for buffer 491 sizing in implementations. Its large upper limit allows for 492 increased amounts of randomness to be added over time. 494 The ABNF [RFC5234] for these parameters are: 496 trns-parameter =/ SEMI ice-password-par 497 trns-parameter =/ SEMI ice-ufrag-par 498 ice-password-par = "ICE-Password" EQUAL DQ password DQ 499 ice-ufrag-par = "ICE-ufrag" EQUAL DQ ufrag DQ 500 password = 501 ufrag = 502 EQUAL = 503 SEMI = 504 DQ = 506 4.4. ICE Feature Tag 508 A feature tag is defined for use in the RTSP capabilities mechanism 509 for ICE support of media transport using datagrams: "setup.ice-d-m". 510 This feature tag indicates that one supports all the mandatory 511 functions of this specification. It is applicable to all types of 512 RTSP agents: clients, servers and proxies. 514 The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the 515 "Supported" header in all SETUP requests that contain the "D-ICE" 516 lower layer transport. Note, this is not a "MUST" as an RTSP client 517 can always attempt to perform a SETUP using ICE to see if it 518 functions or fails. However, including the feature tag in the 519 "Supported" header ensures that proxies supporting this specification 520 explicitly indicate such support, see Section 7. 522 4.5. Status Codes 524 ICE needs two new RTSP response codes to indicate progress and 525 errors. 527 +------+----------------------------------------------+-------------+ 528 | Code | Description | Method | 529 +------+----------------------------------------------+-------------+ 530 | 150 | Server still working on ICE connectivity | PLAY | 531 | | checks | | 532 | | | | 533 | 480 | ICE Connectivity check failure | PLAY, SETUP | 534 +------+----------------------------------------------+-------------+ 536 Table 1: New Status codes and their usage with RTSP methods 538 4.5.1. 150 ICE Connectivity Checks in Progress 540 The 150 response code indicates that ICE connectivity checks are 541 still in progress and haven't concluded. This response SHALL be sent 542 within 200 milliseconds of receiving a PLAY request that currently 543 can't be fulfilled because ICE connectivity checks are still running. 544 A client can expect network delays between the server and client 545 resulting in a response longer than 200 milliseconds. Subsequently, 546 every 3 seconds after the previous one was sent, a 150 reply SHALL be 547 sent until the ICE connectivity checks conclude either successfully 548 or in failure, and a final response for the request can be provided. 550 4.5.2. 480 ICE Processing Failed 552 The 480 client error response code is used in cases when the request 553 can't be fulfilled due to a failure in the ICE processing, such as 554 all the connectivity checks have timed out. This error message can 555 appear either in response to a SETUP request to indicate that no 556 candidate pair can be constructed, or in response to a PLAY request 557 to indicate that the server's connectivity checks resulted in 558 failure. 560 4.6. New Reason for PLAY_NOTIFY 562 A new value used in the PLAY_NOTIFY methods Notify-Reason header is 563 defined: "ice-restart". This reason indicates that an ICE restart 564 needs to happen on the identified resource and session. 566 Notify-Reas-val =/ "ice-restart" 568 4.7. Server Side SDP Attribute for ICE Support 570 If the server supports the media NAT traversal for RTSP controlled 571 sessions as described in this RFC, then the server SHOULD include the 572 "a=rtsp-ice-d-m" SDP attribute in any SDP (if used) describing 573 content served by the server. This is a session-level only 574 attribute, see [RFC4566]. 576 The ABNF [RFC5234] for the "rtsp-ice-d-m" attribute is: 578 rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m" 580 5. ICE-RTSP 582 This section discusses differences between the regular ICE usage 583 defined in [RFC5245] and ICE-RTSP. The reasons for the differences 584 relate to the clearer client/server roles that RTSP provides and how 585 the RTSP Session establishment signaling occurs within RTSP compared 586 to SIP/SDP Offer/Answer. 588 5.1. ICE Features Not Required 590 A number of ICE signaling features are not needed with RTSP and are 591 discussed below. 593 5.1.1. ICE-Lite 595 The ICE-Lite attribute SHALL NOT be used in the context of RTSP. The 596 ICE specification describes two implementations of ICE: Full and 597 Lite, where hosts that are not behind a NAT are allowed to implement 598 only Lite. For RTSP, the Lite implementation is insufficient because 599 it does not cause the media server to send a connectivity check, 600 which is used to protect against making the RTSP server a denial of 601 service tool. 603 5.1.2. ICE-Mismatch 605 The ice-mismatch parameter indicates that the offer arrived with a 606 default destination for a media component that didn't have a 607 corresponding candidate attribute. This is not needed for RTSP as 608 the ICE-based lower layer transport specification either is supported 609 or another alternative transport is used. This is always explicitly 610 indicated in the SETUP request and response. 612 5.1.3. ICE Remote Candidate Transport Header Parameter 614 The Remote candidate attribute is not needed for RTSP for the 615 following reasons. Each SETUP results in an independent ICE 616 processing chain which either fails or results in nominating a single 617 candidate pair to usage. If a new SETUP request for the same media 618 is sent, this needs to use a new username fragment and password to 619 avoid any race conditions or uncertainty about which round of 620 processing the STUN requests relate to. 622 5.2. High-Reachability Configuration 624 ICE-RTSP contains a high-reachability configuration when the RTSP 625 servers are not behind NATs. Please note that "not behind NATs" may 626 apply in some special cases also for RTSP servers behind NATs given 627 that they are in an address space that has reachability for all the 628 RTSP clients intended to able to reach the server. The high- 629 reachability configuration is similar to ICE-Lite as it allows for 630 some reduction in the server's burden. However, due to the need to 631 still verify that the client is actually present and wants to receive 632 the media stream, the server must also initiate binding requests and 633 await binding responses. The reduction for the high-reachability 634 configuration of ICE-RTSP is that they don't need to initiate their 635 own checks, and instead rely on triggered checks for verification. 636 This also removes a denial of service threat where a RTSP SETUP 637 request will trigger large amount of STUN connectivity checks towards 638 provided candidate addresses. 640 6. Detailed Solution 642 This section describes in detail how the interaction and flow of ICE 643 works with RTSP messages. 645 6.1. Session description and RTSP DESCRIBE (optional) 647 The RTSP server is RECOMMENDED to indicate it has support for ICE by 648 sending the "a=rtsp-ice-d-m" SDP attribute in the response to the 649 RTSP DESCRIBE message if SDP is used. This allows RTSP clients to 650 only send the new ICE exchanges with servers that support ICE thereby 651 limiting the overhead on current non-ICE supporting RTSP servers. 652 When not using RTSP DESCRIBE it is still RECOMMENDED to use the SDP 653 attribute for the session description. 655 A client can also use the DESCRIBE request to determine explicitly if 656 both server and any proxies support ICE. The client includes the 657 "Supported" header with its supported feature tags, including 658 "setup.ice-d-m". Any proxy upon seeing the "Supported" header will 659 include the "Proxy-Supported" header with the feature tags it 660 supports. The server will echo back the "Proxy-Supported" header and 661 its own version of the Supported header so enabling a client to 662 determine if all involved parties support ICE or not. Note that even 663 if a proxy is present in the chain that doesn't indicate support for 664 ICE, it may still work (see Section 7). 666 For example: 667 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 668 CSeq: 312 669 User-Agent: PhonyClient 1.2 670 Accept: application/sdp, application/example 671 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 673 S->C: RTSP/2.0 200 OK 674 CSeq: 312 675 Date: 23 Jan 1997 15:35:06 GMT 676 Server: PhonyServer 1.1 677 Content-Type: application/sdp 678 Content-Length: 367 679 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 681 v=0 682 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 683 s=SDP Seminar 684 i=A Seminar on the session description protocol 685 u=http://www.example.com/lectures/sdp.ps 686 e=seminar@example.com (Seminar Management) 687 t=2873397496 2873404696 688 a=recvonly 689 a=rtsp-ice-d-m 690 a=control: * 691 m=audio 3456 RTP/AVP 0 692 a=control: /audio 693 m=video 2232 RTP/AVP 31 694 a=control: /video 696 6.2. Setting up the Media Streams 698 The RTSP client reviews the session description returned, for example 699 by an RTSP DESCRIBE message, to determine what media resources need 700 to be setup. For each of these media streams where the transport 701 protocol supports ICE connectivity checks, the client SHALL gather 702 candidate addresses for UDP transport as described in section 4.1.1 703 in ICE [RFC5245] according to standard ICE rather than the ICE-Lite 704 implementation and according to section 5 of ICE TCP [RFC6544] for 705 TCP based candidates. 707 6.3. RTSP SETUP Request 709 The RTSP client will then send at least one SETUP request per media 710 stream to establish the media streams required for the desired 711 session. For each media stream where it desires to use ICE it MUST 712 include a transport specification with "D-ICE" as the lower layer, 713 and each media stream SHALL have its own unique combination of ICE 714 candidates and ICE-ufrag. This transport specification SHOULD be 715 placed first in the list to give it highest priority. It is 716 RECOMMENDED that additional transport specifications are provided as 717 a fallback in case of non-ICE supporting proxies. The RTSP client 718 will be initiating and thus the controlling party in the ICE 719 processing. For example (Note that some lines are broken in 720 contradiction with the defined syntax due to space restrictions in 721 the documenting format): 723 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 724 CSeq: 313 725 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=8hhY; 726 ICE-Password=asd88fgpdd777uzjYhagZg; candidates=" 727 1 1 UDP 2130706431 10.0.1.17 8998 typ host; 728 2 1 UDP 1694498815 192.0.2.3 45664 typ srflx 729 raddr 10.0.1.17 rport 8998"; RTCP-mux, 730 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 731 RTP/AVP/TCP; unicast;interleaved=0-1 732 Accept-Ranges: NPT, UTC 733 User-Agent: PhonyClient/1.2 734 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 736 6.4. Gathering Candidates 738 Upon receiving a SETUP request the server can determine what media 739 resource should be delivered and which transport alternatives the 740 client supports. If one based on D-ICE is on the list of supported 741 transports and preferred among the supported, the below applies. 743 The transport specification will indicate which media protocol is to 744 be used and based on this and the client's candidates, the server 745 determines the protocol and if it supports ICE with that protocol. 746 The server SHALL then gather its UDP candidates according to section 747 4.1.1 in ICE [RFC5245] and any TCP based ones according to section 5 748 of ICE TCP [RFC6544]. 750 Servers that have an address that is generally reachable by any 751 client within the address scope the server intends to serve MAY be 752 specially configured (high-reachability configuration). This special 753 configuration has the goal of reducing the server side candidate to 754 preferably a single one per (address family, media stream, media 755 component) tuple. Instead of gathering all possible addresses 756 including relayed and server reflexive addresses, the server uses a 757 single address per address family that the server knows should be 758 reachable by a client behind one or more NATs. The reason for this 759 special configuration is twofold: Firstly, it reduces the load on the 760 server in address gathering and in ICE processing during the 761 connectivity checks. Secondly, it will reduce the number of 762 permutations for candidate pairs significantly thus potentially 763 speeding up the conclusion of the ICE processing. Note however that 764 using this option on a server that doesn't fulfill the requirement of 765 being reachable is counter-productive and it is important that this 766 is correctly configured. 768 The above general consideration for servers applies also for TCP 769 based candidates. A general implementation should support several 770 candidate collection techniques and connection types. For TCP based 771 candidates a high-reachability configured server is recommended to 772 only offer Host candidates. In addition to passive connection types 773 the server can select to provide active or simultaneous-open (S-O) 774 connection types to match the client's candidates. 776 6.5. RTSP Server Response 778 The server determines if the SETUP request is successful, and if so 779 returns a 200 OK response; otherwise it returns an error code. At 780 that point the server, having selected a transport specification 781 using the "D-ICE" lower layer, will need to include that transport 782 specification in the response message. The transport specification 783 SHALL include the candidates gathered in Section 6.4 in the 784 "candidates" transport header parameter as well as the server's ICE 785 username fragment and password. In the case that there are no valid 786 candidate pairs with the combination of the client and server 787 candidates, a 480 (ICE Processing Failed) error response SHALL be 788 returned which MUST include the server's candidates. The return of a 789 480 error may allow both the server and client to release their 790 candidates, see Section 6.10. 792 Example of a successful response to the request in Section 6.3. 794 S->C: RTSP/2.0 200 OK 795 CSeq: 313 796 Session: 12345678 797 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=MkQ3; 798 ICE-Password=pos12Dgp9FcAjpq82ppaF; candidates=" 799 1 1 UDP 2130706431 192.0.2.56 50234 typ host" 800 Accept-Ranges: NPT 801 Date: 23 Jan 1997 15:35:06 GMT 802 Server: PhonyServer 1.1 803 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 805 6.6. Server to Client ICE Connectivity Checks 807 The server SHALL start the connectivity checks following the 808 procedures described in Section 5.7 and 5.8 of ICE [RFC5245] unless 809 it is configured to use the high-reachability option. If it is then 810 it MAY suppress its own checks until the server's checks are 811 triggered by the client's connectivity checks. 813 Please note that ICE [RFC5245] section 5.8 does specify that the 814 initiation of the checks are paced and new ones are only started 815 every Ta milliseconds. The motivation for this is documented in 816 Appendix B.1 of ICE [RFC5245] as for SIP/SDP all media streams within 817 an offer/answer dialog are running using the same queue. To ensure 818 the same behavior with RTSP, the server SHALL use a single pacer 819 queue for all media streams within each RTSP session. 821 The values for the pacing of STUN and TURN transactions Ta and RTO 822 can be configured but have the same minimum values defined in the ICE 823 specification. 825 When a connectivity check from the client reaches the server it will 826 result in a triggered check from the server as specified in 827 Section 7.2.1.4 of ICE [RFC5245]. This is why servers with a high- 828 reachability address can wait until this triggered check to send out 829 any checks for itself so saving resources and mitigating the DDoS 830 potential. 832 6.7. Client to Server ICE Connectivity Check 834 The client receives the SETUP response and learns the candidate 835 addresses to use for the connectivity checks. The client SHALL 836 initiate its connectivity check(s), following the procedures in 837 Section 6 of ICE [RFC5245]. The pacing of STUN transactions 838 (Section B.1 of [RFC5245]) SHALL be used across all media streams 839 that are part of the same RTSP session. 841 Aggressive nomination SHOULD be used with RTSP during initial SETUP 842 for a resource. This doesn't have all the negative impact that it 843 has in offer/answer as media playing only starts after issuing a PLAY 844 request. Thus the issue with a change of the media path being used 845 for delivery can be avoided by not issuing a PLAY request while STUN 846 connectivity checks are still outstanding. Aggressive nomination can 847 result in multiple candidate pairs having their nominated flag set 848 but according to Section 8.1.1.2 of ICE [RFC5245] when the PLAY 849 request is sent the media will arrive on the pair with the highest 850 priority. Note, different media resources may still end up with 851 different foundations. 853 The above does not change ICE and its handling of aggressive 854 nomination. When using aggressive nomination, a higher priority 855 candidate pair with an outstanding connectivity check message can 856 move into the Succeeded state and the candidate pair will have its 857 Nominated flag set. This results in the higher priority candidate 858 pair being used instead of the previous pair, which is also in the 859 Succeeded state. 861 To avoid this occurring during actual media transport, the RTSP 862 client can add additional logic when the ICE processing overall is 863 completed to indicate if there is still higher priority connectivity 864 checks outstanding. If some check is still outstanding, the 865 implementation can choose to wait until some additional timeout 866 triggers or the outstanding checks completes before progressing with 867 a PLAY request. An alternative is to accept the risk for a path 868 change during media delivery and start playing immediately. 870 RTSP clients that want to ensure that each media resource uses the 871 same path can use regular nomination where both the ICE processing 872 completion criteria can be controlled in addition to which media 873 streams being nominated for use. This does not affect the RTSP 874 server, as its role is the one of being controlled. 876 6.8. Client Connectivity Checks Complete 878 When the client has concluded all of its connectivity checks and has 879 nominated its desired candidate pair for a particular media stream, 880 it MAY issue a PLAY request for that stream. Note, that due to the 881 aggressive nomination, there is a risk that any outstanding check may 882 nominate another pair than what was already nominated. The candidate 883 pair with the highest priority will be used for the media. If the 884 client has locally determined that its checks have failed it may try 885 providing an extended set of candidates and update the server 886 candidate list by issuing a new SETUP request for the media stream. 888 If the client concluded its connectivity checks successfully and 889 therefore sent a PLAY request but the server cannot conclude 890 successfully, the server will respond with a 480 (ICE Processing 891 Failed). Upon receiving the 480 (ICE Processing Failed) response, 892 the client may send a new SETUP request assuming it has any new 893 information that can be included in the candidate list. If the 894 server is still performing the checks when receiving the PLAY request 895 it will respond with a 150 (ICE connectivity checks in progress) 896 response to indicate this. 898 6.9. Server Connectivity Checks Complete 900 When the RTSP server receives a PLAY request, it checks to see that 901 the connectivity checks have concluded successfully and only then 902 will it play the stream. If the PLAY request is for a particular 903 media stream, the server only needs to check that the connectivity 904 checks for that stream completed successfully. If the server has not 905 concluded its connectivity checks, the server indicates that by 906 sending the 150 (ICE connectivity checks in progress) 907 (Section 4.5.1). If there is a problem with the checks, then the 908 server sends a 480 response to indicate a failure of the checks. If 909 the checks are successful then the server sends a 200 OK response and 910 starts delivering media. 912 6.10. Freeing Candidates 914 Both server and client MAY free their non-selected candidates as soon 915 as a 200 PLAY response has been issued/received and no outstanding 916 connectivity checks exist. 918 Clients and servers MAY free all their gathered candidates after 919 having received or sent, respectively, a 480 response to a SETUP 920 request. Clients will likely free their candidates first after 921 having tried any additional actions that may resolve the issue, e.g., 922 verifying the address gathering, or use additional STUN or TURN 923 servers. Thus, a server will have to weigh the cost of doing address 924 gathering versus maintaining the gathered address for some time to 925 allow any new SETUP request to be issued by the client. 927 If the 480 response is sent in response to a PLAY request, the server 928 MUST NOT free its gathered candidates. Instead it will have to wait 929 for additional actions from the client, or to terminate the RTSP 930 session due to inactivity. 932 6.11. Steady State 934 The client and server SHALL use STUN to send keep-alive messages for 935 the nominated candidate pair(s) following the rules of Section 10 of 936 ICE [RFC5245]. This is important, as normally RTSP play mode 937 sessions only contain traffic from the server to the client so the 938 bindings in the NAT need to be refreshed by the client-to-server 939 traffic provided by the STUN keep-alive. 941 6.12. Re-SETUP 943 A client that decides to change any parameters related to the media 944 stream setup will send a new SETUP request. In this new SETUP 945 request the client MAY include a new different ICE username fragment 946 and password to use in the ICE processing. New ICE username and 947 password SHALL cause the ICE processing to start from the beginning 948 again, i.e., an ICE restart (Section 9.1.1.1 of [RFC5245]). The 949 client SHALL in case of ICE restart gather candidates and include the 950 candidates in the transport specification for D-ICE. 952 ICE restarts may be triggered due to changes of client or server 953 attachment to the network, such as changes to the media streams 954 destination or source address or port. Most RTSP parameter changes 955 would not require an ICE restart, but would use existing mechanisms 956 in RTSP to indicate from what point in the RTP stream they apply. 957 These include: Performing a pause prior to the parameter change and 958 then resume; or assuming the server supports using SETUP during the 959 PLAY state, using the RTP-Info header (Section 18.45 of 960 [I-D.ietf-mmusic-rfc2326bis]) to indicate from where in the media 961 stream the change shall apply. 963 Even if the server does not normally support SETUP during PLAY state, 964 it SHALL support SETUP requests in PLAY state for the purpose of 965 changing only the ICE parameters, which are ICE-Password, ICE-ufrag, 966 and the content of ICE candidates. 968 If the RTSP session is in playing state at the time of sending the 969 SETUP request requiring ICE restart, then the ICE connectivity checks 970 SHALL use Regular nomination. Any ongoing media delivery continues 971 on the previously nominated candidate pairs until the new pairs have 972 been nominated for the individual media stream. Once the nomination 973 of the new candidate pair has completed, all unused candidates may be 974 released. If the ICE processing fails and no new candidate pairs are 975 nominated for use, then the media stream MAY continue to use the 976 previously nominated candidate pairs while they still function. If 977 they appear to fail to transport media packets anymore then the 978 client can select between two actions. First, it can attempt any 979 actions available that might make ICE work, like trying another STUN/ 980 TURN server, or changing the transport parameters. In that case, the 981 client modifies the RTSP session, and if ICE is still to be used, the 982 client restarts ICE once more. If the client is unable to modify the 983 transport or ICE parameters, it MUST NOT restart the ICE processing, 984 and it SHOULD terminate the RTSP session. 986 6.13. Server Side Changes After Steady State 988 A server may require an ICE restart because of server side load 989 balancing or a failure resulting in an IP address and a port number 990 change. In that case the server SHALL use the PLAY_NOTIFY method to 991 inform the client (Section 13.5 [I-D.ietf-mmusic-rfc2326bis]) with a 992 new Notify-Reason header: ice-restart. The server will identify if 993 the change is for a single media or for the complete session by 994 including the corresponding URI in the PLAY_NOTIFY request. 996 Upon receiving and responding to this PLAY_NOTIFY with ice-restart 997 reason the client SHALL gather new ICE candidates and send SETUP 998 requests for each media stream part of the session. The server 999 provides its candidates in the SETUP response the same way as for the 1000 first time ICE processing. Both server and client SHALL provide new 1001 ICE user names and passwords. The client MAY issue the SETUP request 1002 while the session is in PLAYING state. 1004 If the RTSP session is in PLAYING state when the client issues the 1005 SETUP request, the client SHALL use Regular nomination. If not, the 1006 client will use the same procedures as for when first creating the 1007 session. 1009 Note that keepalive messages on the previous set of candidate pairs 1010 SHOULD continue until all new candidate pairs have been nominated. 1011 After having nominated a new set of candidate pairs, the client may 1012 continue to receive media for some additional time. Even if the 1013 server stops delivering media over that candidate pair at the time of 1014 nomination, media may arrive for up to one maximum segment lifetime 1015 as defined in TCP (2 minutes). Unfortunately, if the RTSP server is 1016 divided into a separate controller and media stream, a failure may 1017 result in continued media delivery for a longer time than the maximum 1018 segment lifetime, thus source filtering is RECOMMENDED. 1020 For example: 1022 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 1023 CSeq: 854 1024 Notify-Reason: ice-restart 1025 Session: uZ3ci0K+Ld 1026 Server: PhonyServer 1.1 1028 C->S: RTSP/2.0 200 OK 1029 CSeq: 854 1030 User-Agent: PhonyClient/1.2 1032 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 1033 CSeq: 314 1034 Session: uZ3ci0K+Ld 1035 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=Kl1C; 1036 ICE-Password=H4sICGjBsEcCA3Rlc3RzLX; candidates=" 1037 1 1 UDP 2130706431 10.0.1.17 8998 typ host; 1038 2 1 UDP 1694498815 192.0.2.3 51456 typ srflx 1039 raddr 10.0.1.17 rport 9002"; RTCP-mux, 1040 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 1041 RTP/AVP/TCP; unicast;interleaved=0-1 1042 Accept-Ranges: NPT, UTC 1043 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 1044 User-Agent: PhonyClient/1.2 1046 C->S: SETUP rtsp://server.example.com/fizzle/foo/video RTSP/2.0 1047 CSeq: 315 1048 Session: uZ3ci0K+Ld 1049 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=hZv9; 1050 ICE-Password=JAhA9myMHETTFNCrPtg+kJ; candidates=" 1051 1 1 UDP 2130706431 10.0.1.17 9000 typ host; 1052 2 1 UDP 1694498815 192.0.2.3 51576 typ srflx 1053 raddr 10.0.1.17 rport 9000"; RTCP-mux, 1054 RTP/AVP/UDP; unicast; dest_addr=":6972"/":6973", 1055 RTP/AVP/TCP; unicast;interleaved=0-1 1056 Accept-Ranges: NPT, UTC 1057 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 1058 User-Agent: PhonyClient/1.2 1060 S->C: RTSP/2.0 200 OK 1061 CSeq: 314 1062 Session: uZ3ci0K+Ld 1063 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=CbDm; 1064 ICE-Password=OfdXHws9XX0eBr6j2zz9Ak; candidates=" 1065 1 1 UDP 2130706431 192.0.2.56 50234 typ host" 1066 Accept-Ranges: NPT 1067 Date: 11 March 2011 13:17:46 GMT 1068 Server: PhonyServer 1.1 1069 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 1071 S->C: RTSP/2.0 200 OK 1072 CSeq: 315 1073 Session: uZ3ci0K+Ld 1074 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=jigs; 1075 ICE-Password=Dgx6fPj2lsa2WI8b7oJ7+s; candidates=" 1076 1 1 UDP 2130706431 192.0.2.56 47233 typ host" 1077 Accept-Ranges: NPT 1078 Date: 11 March 2011 13:17:47 GMT 1079 Server: PhonyServer 1.1 1080 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 1082 7. ICE and Proxies 1084 RTSP allows for proxies which can be of two fundamental types 1085 depending on whether they relay and potentially cache the media or 1086 not. Their differing impact on the RTSP NAT traversal solution, 1087 including backwards compatibility, is explained below. 1089 7.1. Media-Handling Proxies 1091 An RTSP proxy that relays or caches the media stream for a particular 1092 media session can be considered to split the media transport into two 1093 parts: A media transport between the server and the proxy according 1094 to the proxy's need, and delivery from the proxy to the client. This 1095 split means that the NAT traversal solution will be run on each 1096 individual media leg according to need. 1098 It is RECOMMENDED that any media-handling proxy support the media NAT 1099 traversal defined within this specification. This is for two 1100 reasons: Firstly, to enable clients to perform NAT traversal for the 1101 media between the proxy and itself, and secondly to allow the proxy 1102 to be topology independent to support performing NAT traversal (to 1103 the server) for non-NAT traversal capable clients present in the same 1104 address domain as the proxy. 1106 For a proxy to support the media NAT traversal defined in this 1107 specification a proxy will need to implement the solution fully and 1108 be able to act as both a controlling and a controlled ICE peer. The 1109 proxy also SHALL include the "setup.ice-d-m" feature tag in any 1110 applicable capability negotiation headers, such as "Proxy-Supported". 1112 7.2. Signaling-Only Proxies 1114 A signaling-only proxy handles only the RTSP signaling and does not 1115 have the media relayed through proxy functions. This type of proxy 1116 is not likely to work unless the media NAT traversal solution is in 1117 place between the client and the server, because the Denial of 1118 Service (DoS) protection measures, as discussed in Section 21.2.1 of 1119 RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis], usually prevent media delivery 1120 to addresses other than from where the RTSP signaling arrives at the 1121 server. 1123 The solution for the signaling-only proxy is that it must forward the 1124 RTSP SETUP requests including any transport specification with the 1125 "D-ICE" lower layer and the related transport parameters. A proxy 1126 supporting this functionality SHALL indicate its capability by always 1127 including the "setup.ice-d-m" feature tag in the "Proxy-Supported" 1128 header in any SETUP request or response. 1130 7.3. Non-supporting Proxies 1132 A media-handling proxy that doesn't support the ICE media NAT 1133 traversal specified here is assumed to remove the transport 1134 specification and use any of the lower prioritized transport 1135 specifications if provided by the requester. The specification of 1136 such a non-ICE transport enables the negotiation to complete, 1137 although with a less preferred method since a NAT between the proxy 1138 and the client may result in failure of the media path. 1140 A non-media-handling proxy is expected to ignore and simply forward 1141 all unknown transport specifications. However, this can only be 1142 guaranteed for proxies following the RTSP 2.0 specification 1143 [I-D.ietf-mmusic-rfc2326bis]. 1145 The usage of the "setup.ice-d-m" feature tag in the Proxy-Require 1146 header is NOT RECOMMENDED because it can have contradictory results. 1147 For a non ICE supporting but media-handling proxy, the inclusion of 1148 the feature tag will result in aborting the setup and indicating that 1149 it isn't supported, which is desirable if it is desirable to provide 1150 other fallbacks or other transport configurations to handle the 1151 situation. For non-ICE supporting non-media-handling proxies the 1152 result will be aborting the setup. However, setup might have worked 1153 if the feature tag wasn't present in the Proxy-Require header. This 1154 variance in results is the reason we don't recommend the usage of the 1155 Proxy-Require header. Instead we recommend the usage of the 1156 Supported header to force proxies to include the feature tags for the 1157 intersection of what the proxy chain supports in the Proxy-Supported 1158 header. This will provide a positive indication when all proxies in 1159 the chain between the client and server support the functionality. 1161 If a proxy doesn't support the setup.ice-d-m feature, but that proxy 1162 is not a media-handling proxy, the ICE-based setup could still work, 1163 since such a proxy may do passthrough on any transport parameters. 1164 Unfortunately the Proxy-Require and Proxy-Supported RTSP headers 1165 failed to provide that information. The only way of finding if this 1166 is the case or not is to try perform a SETUP including a Transport 1167 header with transport specifications using ICE. 1169 8. RTP and RTCP Multiplexing 1171 "Multiplexing RTP Data and Control Packets on a Single Port" 1172 [RFC5761] specifies how and when RTP and RTCP can be multiplexed on 1173 the same port. This multiplexing is beneficial when combined with 1174 ICE for RTSP as it makes RTP and RTCP need only a single component 1175 per media stream instead of two, so reducing the load on the 1176 connectivity checks. For details on how to negotiate RTP and RTCP 1177 multiplexing, see Appendix C of RTSP 2.0 1178 [I-D.ietf-mmusic-rfc2326bis]. 1180 Multiplexing RTP and RTCP has the benefit that it avoids the need for 1181 handling two components per media stream when RTP is used as the 1182 media transport protocol. This eliminates at least one STUN check 1183 per media stream and will also reduce the time needed to complete the 1184 ICE processing by at least the time it takes to pace out the 1185 additional STUN checks of up to one complete round trip time for a 1186 single media stream. In addition to the protocol performance 1187 improvements, the server and client side complexities are reduced as 1188 multiplexing halves the total number of STUN instances and holding 1189 the associated state. Multiplexing will also reduce the combinations 1190 and length of the list of possible candidates. 1192 The implementation of RTP and RTCP multiplexing is additional work 1193 required for this solution. However, when implementing the ICE 1194 solution a server or client will need to implement a de-multiplexer 1195 between the STUN, and RTP or RTCP packets below the RTP/RTCP 1196 implementation anyway, so the additional work of one new 1197 demultiplexing point directly connected to the STUN and RTP/RTCP 1198 seems small relative to the benefits provided. 1200 Due to the above mentioned benefits, RTSP servers and clients that 1201 support "D-ICE" lower layer transport in combination with RTP SHALL 1202 also implement and use RTP and RTCP multiplexing as specified in 1203 Appendix C.1.6.4 of [I-D.ietf-mmusic-rfc2326bis] and [RFC5761]. 1205 9. Fallback and Using Partial ICE functionality to improve NAT/Firewall 1206 traversal 1208 The need for fallback from ICE in RTSP should be less than for SIP 1209 using ICE in SDP offer/answer where a default destination candidate 1210 is very important to enable interworking with non-ICE capable 1211 endpoints. In RTSP, capability determination for ICE can happen 1212 prior to the RTSP SETUP request. This means a client should normally 1213 not need to include fallback alternatives when offering ICE, as the 1214 capability for ICE will already be determined. However, as described 1215 in this section, clients may wish to use part of the ICE 1216 functionality to improve NAT/Firewall traversal where the server is 1217 non-ICE capable. 1219 Section 4.1.4 of the ICE [RFC5245] specification does recommend that 1220 the default destination, i.e., what is used as fallback if the peer 1221 isn't ICE capable, is a candidate of relayed type to maximize the 1222 likelihood of successful transport of media. This is based on the 1223 peer in SIP using SDP offer/answer is almost as likely as the RTSP 1224 client to be behind a NAT. For RTSP the deployment of servers are 1225 much more heavily weighted towards deployment with public 1226 reachability. In fact since publicly reachable servers behind NAT 1227 either need to support ICE or have static configurations that allow 1228 traversal, one can assume that the server will have a public address 1229 or support ICE. Thus, the selection of the default destination 1230 address for RTSP can be differently prioritized. 1232 As an ICE enabled client behind a NAT needs to be configured with a 1233 STUN server address to be able to gather candidates successfully, 1234 this can be used to derive a server reflexive candidate for the 1235 client's port. How useful this is for a NAT'ed RTSP client as a 1236 default candidate depends on the properties of the NAT. As long as 1237 the NAT uses an address independent mapping, then using a STUN 1238 derived reflexive candidate is likely to be successful. This is 1239 however brittle in several ways, and the main reason why the original 1240 specification of STUN [RFC3489] and direct usage for NAT traversal 1241 was obsoleted. First, if the NATs behavior is attempted to be 1242 determined using STUN as described in [RFC3489], the determined 1243 behavior might not be representative of the behavior encountered in 1244 another mapping. Secondly, filter state towards the ports used by 1245 the server needs to be established. This requires that the server 1246 actually includes both address and ports in its response to the SETUP 1247 request. Thirdly messages need to be sent to these ports for keep- 1248 alive at a regular interval. How a server reacts to such unsolicited 1249 traffic is unknown. This brittleness may be accepted in fallback due 1250 to lack of support on the server side. 1252 To maximize the likelihood that an RTSP client is capable of 1253 receiving media a relay based address should be chosen as the default 1254 fallback address. However, for RTSP clients lacking a relay server, 1255 such as a TURN server, or where usage of such a server has 1256 significant cost associated with it, the usage of a STUN-derived 1257 server reflexive address as client default has a reasonable 1258 likelihood of functioning and may be used as an alternative. 1260 Fallback addresses need to be provided in their own transport 1261 specification using a specifier that does not include the "D-ICE" 1262 lower layer transport. Instead the selected protocol, e.g., UDP, 1263 needs to be explicitly or implicitly indicated. Secondly, the 1264 selected default candidate needs to be included in the SETUP request. 1265 If this candidate is server reflexive or relayed the aspect of keep- 1266 alive needs to be ensured. 1268 10. IANA Considerations 1270 This document requests registration in a number of registries, both 1271 for RTSP and SDP. For all the below registrations the contact person 1272 on behalf of the IETF WG MMUSIC is Magnus Westerlund; Postal address: 1273 Farogatan 6, 164 80 Stockholm, Sweden; Email: 1274 magnus.westerlund@ericsson.com. 1276 RFC-Editor Note: Please replace any occurrence of RFCXXXX in the 1277 below with the RFC number this specification is assigned. 1279 10.1. RTSP Feature Tags 1281 This document requests that one RTSP 2.0 feature tag is registered in 1282 the "RTSP 2.0 Feature-tags" registry: 1284 setup.ice-d-m A feature tag representing the support of the ICE- 1285 based establishment of datagram media transport that is capable of 1286 transport establishment through NAT and Firewalls. This feature 1287 tag applies to clients, servers and proxies and indicates support 1288 of all the mandatory functions of this specification. 1290 10.2. Transport Protocol Identifiers 1292 This document needs to register a number of transport protocol 1293 combinations in the RTSP 2.0 "Transport Protocol Identifiers" 1294 registry. 1296 "RTP/AVP/D-ICE" RTP using the AVP profile over an ICE established 1297 datagram flow. 1299 "RTP/AVPF/D-ICE" RTP using the AVPF profile over an ICE established 1300 datagram flow. 1302 "RTP/SAVP/D-ICE" RTP using the SAVP profile over an ICE established 1303 datagram flow. 1305 "RTP/SAVPF/D-ICE" RTP using the SAVPF profile over an ICE 1306 established datagram flow. 1308 10.3. RTSP Transport Parameters 1310 This document requests that 3 transport parameters are registered in 1311 the RTSP 2.0's "Transport Parameters" registry: 1313 "candidates": Listing the properties of one or more ICE candidate. 1314 See Section 4.2 of RFCXXXX. 1316 "ICE-Password": The ICE password used to authenticate the STUN 1317 binding request in the ICE connectivity checks. See Section 4.3 1318 of RFCXXXX. 1320 "ICE-ufrag": The ICE username fragment used to authenticate the STUN 1321 binding requests in the ICE connectivity checks. See Section 4.3 1322 of RFCXXXX. 1324 10.4. RTSP Status Codes 1326 This document requests that 2 assignments are done in the "RTSP 2.0 1327 Status Codes" registry. See Section 4.5 of RFCXXXX. 1329 10.5. Notify-Reason value 1331 This document requests that one assignment is done in the RTSP 2.0 1332 Notify-Reason header value registry. The defined value is: 1334 ice-restart: Server notifying the client about the need for an ICE 1335 restart. See Section 4.6. 1337 10.6. SDP Attribute 1339 The registration of one SDP attribute is requested: 1341 SDP Attribute ("att-field"): 1343 Attribute name: rtsp-ice-d-m 1344 Long form: ICE for RTSP datagram media NAT traversal 1345 Type of attribute: Session-level only 1346 Subject to charset: No 1347 Purpose: RFC XXXX, Section 4.7 1348 Values: No values defined 1349 Contact: Magnus Westerlund 1350 E-mail: magnus.westerlund@ericsson.com 1351 phone: +46 10 714 82 87 1353 11. Security Considerations 1355 ICE [RFC5245] and ICE TCP [RFC6544] provide an extensive discussion 1356 on security considerations which apply here as well. 1358 11.1. ICE and RTSP 1360 A long-standing risk with transmitting a packet stream over UDP is 1361 that the host may not be interested in receiving the stream. On 1362 today's Internet, many hosts are behind NATs or operate host 1363 firewalls which do not respond to unsolicited packets with an ICMP 1364 port unreachable error. Thus, an attacker can construct RTSP SETUP 1365 requests with a victim's IP address and cause a flood of media 1366 packets to be sent to a victim. The addition of ICE, as described in 1367 this document, provides protection from the attack described above. 1368 By performing the ICE connectivity check, the media server receives 1369 confirmation that the RTSP client wants the media. While this 1370 protection could also be implemented by requiring the IP addresses in 1371 the SDP match the IP address of the RTSP signaling packet, such a 1372 mechanism does not protect other hosts with the same IP address (such 1373 as behind the same NAT), and such a mechanism would prohibit 1374 separating the RTSP controller from the media play-out device (e.g., 1375 an IP-enabled remote control and an IP-enabled television); it also 1376 forces RTSP proxies to relay the media streams through them, even if 1377 they would otherwise be only signaling proxies. 1379 To protect against attacks on ICE based on signalling information, 1380 RTSP signalling SHOULD be protected using TLS to prevent 1381 eavesdropping and modification of information. 1383 The STUN amplification attack described in Section 18.5.2 in ICE 1384 [RFC5245] needs consideration. Servers that are able to run 1385 according to the high-reachability option have good mitigation 1386 against this attack as they only send connectivity checks towards an 1387 address and port pair they have received an incoming connectivity 1388 check from. This means an attacker requires both the capability to 1389 spoof source addresses and to signal the RTSP server a set of ICE 1390 candidates. Independently an ICE agent needs to implement the 1391 mitigation to reduce the volume of the amplification attack as 1392 described in the ICE specification. 1394 11.2. Logging 1396 The logging of NAT translations is helpful to analysts who need to be 1397 able to map sessions when investigating possible issues where the NAT 1398 happens. Care should be taken in the protection of these logs and 1399 consideration taken to log integrity, privacy protection, and purging 1400 logs occasionally (retention policies, etc.). Also, logging of 1401 connection errors and other messages established by this draft may be 1402 important. 1404 12. Acknowledgments 1406 The authors would like to thank Remi Denis-Courmont for suggesting 1407 the method of integrating ICE in RTSP signaling, Dan Wing for help 1408 with the security section and numerous other issues, Ari Keranen for 1409 review of the document and its ICE details. Flemming Andreasen and 1410 Alissa Cooper for a thorough review. In addition Bill Atwood has 1411 provided comments and suggestions for improvements. 1413 13. References 1415 13.1. Normative References 1417 [I-D.ietf-mmusic-rfc2326bis] 1418 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1419 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1420 (RTSP)", draft-ietf-mmusic-rfc2326bis-40 (work in 1421 progress), February 2014. 1423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1424 Requirement Levels", BCP 14, RFC 2119, March 1997. 1426 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1427 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1428 3986, January 2005. 1430 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1431 Description Protocol", RFC 4566, July 2006. 1433 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1434 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1436 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1437 (ICE): A Protocol for Network Address Translator (NAT) 1438 Traversal for Offer/Answer Protocols", RFC 5245, April 1439 2010. 1441 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1442 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1443 October 2008. 1445 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1446 Control Packets on a Single Port", RFC 5761, April 2010. 1448 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 1449 "TCP Candidates with Interactive Connectivity 1450 Establishment (ICE)", RFC 6544, March 2012. 1452 13.2. Informative References 1454 [I-D.ietf-mmusic-rtsp-nat-evaluation] 1455 Westerlund, M. and T. Zeng, "The Evaluation of Different 1456 Network Address Translator (NAT) Traversal Techniques for 1457 Media Controlled by Real-time Streaming Protocol (RTSP)", 1458 draft-ietf-mmusic-rtsp-nat-evaluation-14 (work in 1459 progress), May 2014. 1461 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1462 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1464 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1465 Address Translator (Traditional NAT)", RFC 3022, January 1466 2001. 1468 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1469 A., Peterson, J., Sparks, R., Handley, M., and E. 1470 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1471 June 2002. 1473 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1474 with Session Description Protocol (SDP)", RFC 3264, June 1475 2002. 1477 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1478 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1479 Through Network Address Translators (NATs)", RFC 3489, 1480 March 2003. 1482 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1483 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1485 Authors' Addresses 1487 Jeff Goldberg 1488 Cisco 1489 11 New Square, Bedfont Lakes 1490 Feltham,, Middx TW14 8HA 1491 United Kingdom 1493 Phone: +44 20 8824 1000 1494 Email: jgoldber@cisco.com 1496 Magnus Westerlund 1497 Ericsson 1498 Farogatan 6 1499 Stockholm SE-164 80 1500 Sweden 1502 Phone: +46 8 719 0000 1503 Email: magnus.westerlund@ericsson.com 1505 Thomas Zeng 1506 Nextwave Wireless, Inc. 1507 12670 High Bluff Drive 1508 San Diego, CA 92130 1509 USA 1511 Phone: +1 858 480 3100 1512 Email: thomas.zeng@gmail.com