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