idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-15.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 (May 02, 2013) is 4011 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-34 ** 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-06 -- 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.I. Goldberg 3 Internet-Draft Cisco 4 Intended status: Standards Track M. Westerlund 5 Expires: November 03, 2013 Ericsson 6 T. Zeng 7 Nextwave Wireless, Inc. 8 May 02, 2013 10 A Network Address Translator (NAT) Traversal mechanism for media 11 controlled by Real-Time Streaming Protocol (RTSP) 12 draft-ietf-mmusic-rtsp-nat-15 14 Abstract 16 This document defines a solution for Network Address Translation 17 (NAT) traversal for datagram based media streams setup and controlled 18 with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses 19 Interactive Connectivity Establishment (ICE) adapted to use RTSP as a 20 signalling channel, defining the necessary extra RTSP extensions and 21 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 November 03, 2013. 40 Copyright Notice 42 Copyright (c) 2013 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 . . . . . . . . 8 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 . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . . 22 91 7.1. Media Handling Proxies . . . . . . . . . . . . . . . . . 23 92 7.2. Signalling Only Proxies . . . . . . . . . . . . . . . . . 23 93 7.3. Non-supporting Proxies . . . . . . . . . . . . . . . . . 23 94 8. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . . . 24 95 9. Fallback and Using Partial ICE functionality to improve 96 NAT/Firewall traversal . . . . . . . . . . . . . . . . . . . 25 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 99 10.1. RTSP Feature Tags . . . . . . . . . . . . . . . . . . . 27 100 10.2. Transport Protocol Specifications . . . . . . . . . . . 27 101 10.3. RTSP Transport Parameters . . . . . . . . . . . . . . . 27 102 10.4. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 28 103 10.5. Notify-Reason value . . . . . . . . . . . . . . . . . . 28 104 10.6. SDP Attribute . . . . . . . . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . . . . 30 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 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 cause 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 itself is beyond the 153 scope of this document and is left for future study should the need 154 arise, because it is a less prevalent problem than the NAT problem 155 for RTSP media streams. 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", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in RFC 2119 [RFC2119]. 169 3. Solution Overview 171 This overview assumes that the reader has some familiarity with how 172 ICE [RFC5245] in the context of "SIP: Session Initiation Protocol" 173 [RFC3261] and "An Offer/Answer Model with the Session Description 174 Protocol (SDP)" [RFC3264] works, as it primarily points out how the 175 different ICE steps are accomplished in RTSP. 177 1. The RTSP server should indicate it has support for ICE via a new 178 SDP [RFC4566] attribute ("a=rtsp-ice-d-m") in, for example, the 179 SDP returned in the RTSP DESCRIBE message. This allows RTSP 180 clients to only perform the new ICE exchanges with servers that 181 support ICE. If RTSP DESCRIBE is used, the normal capability 182 determination mechanism should also be used, i.e., "Supported" 183 header with a new ICE feature tag. Note: Both mechanisms should 184 supported, as there are various use cases where only one of them 185 is used. 187 2. The RTSP client reviews the session description returned, for 188 example by an RTSP DESCRIBE message, to determine what media 189 streams need to be setup. For each of these media streams where 190 the transport protocol supports Session Traversal Utilities for 191 (NAT) (STUN) [RFC5389] based connectivity checks, the client 192 gathers candidate addresses. See section 4.1.1 in ICE 193 [RFC5245]. The client then runs a STUN server on each of the 194 local candidates transport addresses it has gathered. 196 3. The RTSP client sends SETUP requests with both a transport 197 specification with a lower layer indicating ICE and a new RTSP 198 Transport header parameter "candidates" listing the ICE 199 candidates for each media stream. 201 4. After receiving the list of candidates from a client, the RTSP 202 server gathers its own candidates. If the server is not behind 203 a NAT, then a single candidate per address family (e.g. IPv4 204 and IPv6), media stream and media component tuple can be 205 included to reduce the number of combinations and speed up the 206 completion. 208 5. The server sets up the media and if successful responds to the 209 SETUP request with a 200 OK response. In that response the 210 server selects the transport specification using ICE and 211 includes its candidates in the candidates parameter. 213 6. The server starts the connectivity checks following the 214 procedures described in Section 5.7 and 5.8 of ICE [RFC5245]. 215 If the server is not behind a NAT and uses a public IP address 216 with a single candidate per media stream, component and address 217 family, then the server may be configured to not initiate 218 connectivity checks. 220 7. The client receives the SETUP response and learns the candidate 221 addresses to use for the connectivity checks, and then initiates 222 its connectivity check, following the procedures in Section 6 of 223 ICE [RFC5245]. 225 8. When a connectivity check from the client reaches the server it 226 will result in a triggered check from the server. This is why 227 servers not behind a NAT can wait until this triggered check to 228 send out any checks for itself, so saving resources and 229 mitigating the DDoS potential from server connectivity checks. 231 9. When the client has concluded its connectivity checks, including 232 promoting candidates, and has correspondingly received the 233 server connectivity checks on the promoted candidates for all 234 mandatory components of all media streams, it can issue a PLAY 235 request. If the connectivity checks have not concluded 236 successfully, then the client may send a new SETUP request if it 237 has any new information or believes the server may be able to do 238 more that can result in successful checks. 240 10. When the RTSP servers receives a PLAY request, it checks to see 241 that the connectivity checks have concluded successfully, and 242 only then can it play the stream. If there is a problem with 243 the checks then the server sends either a 150 (ICE connectivity 244 checks in progress) response to show that it is still working on 245 the connectivity checks, or a 480 (ICE Processing Failed) 246 response to indicate a failure of the checks. If the checks are 247 successful, then the server sends a 200 OK response and starts 248 delivering media. 250 The client and server may release unused candidates when the ICE 251 processing has concluded and a single candidate per component has 252 been promoted and a PLAY response has been received (Client) or sent 253 (Server). 255 The client needs to continue to use STUN as a keep-alive mechanism 256 for the used candidate pairs to keep their NAT bindings current. 257 RTSP Servers behind NATs will also need to send keep-alive messages 258 when not sending media. This is important since RTSP media sessions 259 often contain only media traffic from the server to the client so the 260 bindings in the NAT need to be refreshed by client to server traffic 261 provided by the STUN keep-alive. 263 4. RTSP Extensions 265 This section defines the necessary RTSP extensions for performing ICE 266 with RTSP. Note that these extensions are based on the SDP 267 attributes in the ICE specification unless expressly indicated. 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 easily be extended with more transport specifications 306 after having performed the evaluation that they are compatible with 307 D-ICE as lower layer. 309 The lower-layer "D-ICE" has the following rules for the inclusion of 310 the RTSP transport header (Section 18.52 of RTSP 2.0 311 [I-D.ietf-mmusic-rfc2326bis]) parameters: 313 unicast: As ICE only supports unicast operations, thus it is 314 REQUIRED that one include the unicast indicator parameter, (see 315 section 18.52 in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]). 317 candidates: The "candidates" parameter SHALL be included as this 318 specify at least one candidate to try to establish a working 319 transport path with. 321 dest_addr: This parameter SHALL NOT be included as "candidates" is 322 used instead to provide the necessary address information. 324 ICE-Password: This parameter SHALL be included (See 325 Section Section 4.2). 327 ICE-ufrag: This parameter SHALL be included (See 328 Section 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 trns-parameter = 345 trns-parameter =/ SEMI ice-trn-par 346 ice-trn-par = "candidates" EQUAL DQ SWS ice-candidate 347 *(SEMI ice-candidate) SWS DQ 348 ice-candidate = foundation SP 349 component-id SP 350 transport SP 351 priority SP 352 connection-address SP 353 port SP 354 cand-type 355 [SP rel-addr] 356 [SP rel-port] 357 [SP tcp-type-ext] ; Mandatory if transport = TCP 358 *(SP extension-att-name SP extension-att-value) 360 foundation = 361 component-id = 362 transport = 363 priority = 364 cand-type = 365 rel-addr = 366 rel-port = 367 tcp-type-ext = 368 extension-att-name = 369 extension-att-value = 370 connection-address = 371 port = 372 EQUAL = 373 DQ = 374 SWS = 375 SEMI = 376 : is the unicast IP address of the candidate, 377 allowing for IPv4 addresses, IPv6 addresses and Fully qualified 378 domain names (FQDN), taken from SDP [RFC4566]. Note, the syntax 379 allows multicast addresses, but they SHALL NOT be used in this 380 context. The connection address SHOULD be on the same format 381 (explicit IP or FQDN) as in the dest_addr parameter used to 382 express fallbacks. An IP address SHOULD be used, but an FQDN MAY 383 be used in place of an IP address. In that case, when receiving a 384 SETUP request or response containing an FQDN in a candidate 385 parameter, the FQDN is looked up in the DNS first using an AAAA 386 record (assuming the agent supports IPv6), and if no result is 387 found or the agent only supports IPv4, using an A record. If the 388 DNS query returns more than one IP address, one is chosen, and 389 then used for the remainder of ICE processing which in RTSP is 390 subsequent RTSP SETUPs for the same RTSP session. 392 : is the port of the candidate; the syntax is defined by SDP 393 [RFC4566]. 395 : indicates the transport protocol for the candidate. 396 The ICE specification defines UDP. "TCP Candidates with 397 Interactive Connectivity Establishment (ICE)" [RFC6544] defines 398 how TCP is used as candidates. Additional extensibility is 399 provided to allow for future transport protocols to be used with 400 ICE, such as the Datagram Congestion Control Protocol (DCCP) 401 [RFC4340]. 403 : is an identifier that is equivalent for two 404 candidates that are of the same type, share the same base, and 405 come from the same STUN server, and is composed of one to thirty 406 two . The foundation is used to optimize ICE 407 performance in the Frozen algorithm (as described in [RFC5245]). 409 : identifies the specific component of the media 410 stream for which this is a candidate and is a positive integer 411 between 1 and 256. It MUST start at 1 and MUST increment by 1 for 412 each component of a particular candidate. For media streams based 413 on RTP, candidates for the actual RTP media MUST have a component 414 ID of 1, and candidates for RTCP MUST have a component ID of 2 415 unless RTP and RTCP Multiplexing (Section 8) is used when the 416 second component is omitted and RTP and RTCP is both transported 417 over the first component. Other types of media streams which 418 require multiple components MUST develop specifications which 419 define the mapping of components to component IDs. See Section 14 420 in [RFC5245] for additional discussion on extending ICE to new 421 media streams. 423 : is a positive integer between 1 and (2**31 - 1). 425 : encodes the type of candidate. The ICE specification 426 defines the values "host", "srflx", "prflx" and "relay" for host, 427 server reflexive, peer reflexive and relayed candidates, 428 respectively. The set of candidate types is extensible for the 429 future. 431 and : convey transport addresses related to the 432 candidate, useful for diagnostics and other purposes. 433 and MUST be present for server reflexive, peer 434 reflexive and relayed candidates. If a candidate is server or 435 peer reflexive, and is equal to the base for 436 that server or peer reflexive candidate. If the candidate is 437 relayed, and is equal to the mapped address 438 in the Allocate Response that provided the client with that 439 relayed candidate (see Appendix B.3 of ICE [RFC5245] for a 440 discussion of its purpose). If the candidate is a host candidate 441 and MUST be omitted. 443 : conveys the candidates connection type (active, 444 passive, or S-O) for TCP based candidates. This MUST be included 445 for candidates that have set to TCP and MUST NOT be 446 included for other transport types, including UDP, unless 447 explicitly specified for that transport protocol. 449 4.3. ICE Password and Username Transport Header Parameters 451 The ICE password and username for each agent needs to be transported 452 using RTSP. For that purpose new transport header parameters are 453 defined (see section 18.52 of [I-D.ietf-mmusic-rfc2326bis]. 455 There MUST be an "ICE-Password" and "ICE-ufrag" parameter for each 456 media stream. If two SETUP requests in the same RTSP session have 457 identical ICE-ufrag's, they MUST have identical ICE-Password's. The 458 ICE-ufrag and ICE-Password attributes MUST be chosen randomly at the 459 beginning of a session. The ICE-ufrag attribute MUST contain at 460 least 24 bits of randomness, and the ICE-Password attribute MUST 461 contain at least 128 bits of randomness. This means that the ICE- 462 ufrag attribute will be at least 4 characters long, and the ICE- 463 Password at least 22 characters long, since the grammar for these 464 attributes allows for 6 bits of randomness per character. The 465 attributes MAY be longer than 4 and 22 characters respectively, of 466 course, up to 256 characters. The upper limit allows for buffer 467 sizing in implementations. Its large upper limit allows for 468 increased amounts of randomness to be added over time. 470 The ABNF [RFC5234] for these parameters are: 472 trns-parameter =/ SEMI ice-password-par 473 trns-parameter =/ SEMI ice-ufrag-par 474 ice-password-par = "ICE-Password" EQUAL DQ password DQ 475 ice-ufrag-par = "ICE-ufrag" EQUAL DQ ufrag DQ 476 password = 477 ufrag = 478 EQUAL = 479 SEMI = 480 DQ = 482 4.4. ICE Feature Tag 484 A feature tag is defined for use in the RTSP capabilities mechanism 485 for ICE support of media transport using datagrams: "setup.ice-d-m". 486 This feature tag indicates that one supports all the mandatory 487 functions of this specification. It is applicable to all types of 488 RTSP agents; clients, servers and proxies. 490 The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the 491 "Supported" header in all SETUP requests that contain the "D-ICE" 492 lower layer transport. 494 4.5. Status Codes 496 ICE needs two new RTSP response codes to indicate correctly progress 497 and errors. 499 +---------+------------------------------------------+--------------+ 500 | Code | Reason | Method | 501 +---------+------------------------------------------+--------------+ 502 | 150 | Server still working on ICE connectivity | PLAY | 503 | | checks | | 504 | | | | 505 | 480 | ICE Connectivity check failure | PLAY, SETUP | 506 +---------+------------------------------------------+--------------+ 508 Table 1: New Status codes and their usage with RTSP methods 510 4.5.1. 150 ICE connectivity checks in progress 511 The 150 response code indicates that ICE connectivity checks are 512 still in progress and haven't concluded. This response SHALL be sent 513 within 200 milliseconds of receiving a PLAY request that currently 514 can't be fulfilled because ICE connectivity checks are still running. 515 Subsequently, every 3 seconds after the previous one was sent, a 150 516 reply shall be sent until the ICE connectivity checks conclude either 517 successfully or in failure, and a final response for the request can 518 be provided. 520 4.5.2. 480 ICE Processing Failed 522 The 480 client error response code is used in cases when the request 523 can't be fulfilled due to a failure in the ICE processing, such as 524 all the connectivity checks have timed out. This error message can 525 appear either in response to a SETUP request to indicate that no 526 candidate pair can be constructed, or in response to a PLAY request 527 to indicate that the server's connectivity checks resulted in 528 failure. 530 4.6. New Reason for PLAY_NOTIFY 532 A new value used in the PLAY_NOTIFY methods Notify-Reason header is 533 defined: "ice-restart". This reason indicates that a ICE restart 534 needs to happen on the identified resource and session. 536 Notify-Reas-val =/ "ice-restart" 538 4.7. Server Side SDP Attribute for ICE Support 540 If the server supports the media NAT traversal for RTSP controlled 541 sessions as described in this RFC, then the Server SHOULD include the 542 "a=rtsp-ice-d-m" SDP attribute in any SDP (if used) describing 543 content served by the server. This is an session level only 544 attribute. 546 The ABNF [RFC5234] for the "rtsp-ice-d-m" attribute is: 548 rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m" 550 5. ICE-RTSP 552 This section discusses differences between the regular ICE usage 553 defined in [RFC5245] and ICE-RTSP. The reasons for the differences 554 relate to the clearer client/server roles that RTSP provides and how 555 the RTSP Session establishment signalling occurs within RTSP compared 556 to SIP/SDP Offer/Answer. 558 5.1. ICE Features Not Required 560 A number of ICE signalling features are not needed with RTSP and are 561 discussed below. 563 5.1.1. ICE-Lite 565 The ICE-Lite attribute shall not be used in the context of RTSP. The 566 ICE specification describes two implementations of ICE: Full and 567 Lite, where hosts that are not behind a NAT are allowed to implement 568 only Lite. For RTSP, the Lite implementation is insufficient because 569 it does not cause the media server to send a connectivity check, 570 which is used to protect against making the RTSP server a denial of 571 service tool. 573 5.1.2. ICE-Mismatch 575 The ice-mismatch parameter indicates that the offer arrived with a 576 default destination for a media component that didn't have a 577 corresponding candidate attribute. This is not needed for RTSP as 578 the ICE based lower layer transport specification either is supported 579 or another alternative transport is used. This is always explicitly 580 indicated in the SETUP request and response. 582 5.1.3. ICE Remote Candidate Transport Header Parameter 584 The Remote candidate attribute is not needed for RTSP for the 585 following reasons. Each SETUP results in an independent ICE 586 processing chain which either fails or results in promoting a single 587 candidate pair to usage. If a new SETUP request for the same media 588 is sent, this needs to use a new username fragment and password to 589 avoid any race conditions or uncertainty about which round of 590 processing the STUN requests relate to. 592 5.2. High-Reachability Configuration 594 ICE-RTSP contains a high-reachability configuration when the RTSP 595 Servers are not behind NATs. Please note that "not behind NATs" may 596 apply in some special cases also for RTSP Servers behind NATs given 597 that they are in an address space that has reachability for all the 598 RTSP clients intended to able to reach the server. The high- 599 reachability configuration is similar to ICE-Lite as it allows for 600 some reduction in the server's burden. However, due to the need to 601 still verify that the client is actually present, the server must 602 also initiate binding requests and await binding responses. The 603 reduction for the high-reachability configuration of ICE-RTSP is that 604 they don't need to initiate their own checks, and instead rely on 605 triggered checks for verification. This also removes a denial of 606 service threat where a RTSP SETUP request will trigger large amount 607 of STUN connectivity checks towards provided candidate addresses. 609 6. Detailed Solution 611 This section describes in detail how the interaction and flow of ICE 612 works with RTSP messages. 614 6.1. Session description and RTSP DESCRIBE (optional) 616 The RTSP server should indicate it has support for ICE by sending the 617 "a=rtsp-ice-d-m" SDP attribute in the response to the RTSP DESCRIBE 618 message if SDP is used. This allows RTSP clients to only send the 619 new ICE exchanges with servers that support ICE thereby limiting the 620 overhead on current non-ICE supporting RTSP servers. When not using 621 RTSP DESCRIBE it is still RECOMMENDED to use the SDP attribute for 622 the session description. 624 A Client can also use the DESCRIBE request to determine explicitly if 625 both server and any proxies support ICE. The client includes the 626 "Supported" header with its supported feature tags, including 627 "setup.ice-d-m". Any proxy upon seeing the "Supported" header will 628 include the "Proxy-Supported" header with the feature tags it 629 supports. The server will echo back the "Proxy-Supported" header and 630 its own version of the Supported header so enabling a client to 631 determine if all involved parties support ICE or not. Note that even 632 if a proxy is present in the chain that doesn't indicate support for 633 ICE, it may still work. 635 For example: 636 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 637 CSeq: 312 638 User-Agent: PhonyClient 1.2 639 Accept: application/sdp, application/example 640 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 642 S->C: RTSP/2.0 200 OK 643 CSeq: 312 644 Date: 23 Jan 1997 15:35:06 GMT 645 Server: PhonyServer 1.1 646 Content-Type: application/sdp 647 Content-Length: 367 648 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 650 v=0 651 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 652 s=SDP Seminar 653 i=A Seminar on the session description protocol 654 u=http://www.example.com/lectures/sdp.ps 655 e=seminar@example.com (Seminar Management) 656 t=2873397496 2873404696 657 a=recvonly 658 a=rtsp-ice-d-m 659 a=control: * 660 m=audio 3456 RTP/AVP 0 661 a=control: /audio 662 m=video 2232 RTP/AVP 31 663 a=control: /video 665 6.2. Setting up the Media Streams 667 The RTSP client reviews the session description returned, for example 668 by an RTSP DESCRIBE message, to determine what media resources need 669 to be setup. For each of these media streams where the transport 670 protocol supports ICE connectivity checks, the client SHALL gather 671 candidate addresses for UDP transport as described in section 4.1.1 672 in ICE [RFC5245] according to standard ICE rather than the ICE-Lite 673 implementation and according to section 5 of ICE TCP [RFC6544] for 674 TCP based candidates. 676 6.3. RTSP SETUP Request 678 The RTSP client will then send at least one SETUP request per media 679 stream to establish the media streams required for the desired 680 session. For each media stream where it desires to use ICE it will 681 include a transport specification with "D-ICE" as the lower layer, 682 and each media stream SHALL have its own unique combination of ICE 683 candidates and ICE-ufrag. This transport specification SHOULD be 684 placed first in the list to give it highest priority. It is 685 RECOMMENDED that additional transport specifications are provided as 686 a fallback in case of non-ICE supporting proxies. The RTSP client 687 will be initiating and thus the controlling party in the ICE 688 processing. For example (Note that some lines are broken in 689 contradiction with the defined syntax due to space restrictions in 690 the documenting format): 692 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 693 CSeq: 313 694 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=8hhY; 695 ICE-Password=asd88fgpdd777uzjYhagZg; candidates=" 696 1 1 UDP 2130706431 10.0.1.17 8998 typ host; 697 2 1 UDP 1694498815 192.0.2.3 45664 typ srflx 698 raddr 10.0.1.17 rport 8998"; RTCP-mux, 699 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 700 RTP/AVP/TCP;unicast;interleaved=0-1 702 Accept-Ranges: NPT, UTC 703 User-Agent: PhonyClient/1.2 704 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 706 6.4. Gathering Candidates 708 Upon receiving a SETUP request the server can determine what media 709 resource should be delivered and which transport alternatives that 710 the client supports. If one based on D-ICE is on the list of 711 supported transports and preferred among the supported, the below 712 applies. 714 The transport specification will provide which media protocol is to 715 be used and based on this and the clients candidates, the server 716 determines the protocol and if it supports ICE with that protocol. 717 The server shall then gather its UDP candidates according to section 718 4.1.1 in ICE [RFC5245] and any TCP based ones according to section 5 719 of ICE TCP [RFC6544]. 721 Servers that have an address that is generally reachable by any 722 client within the address scope the server intends to serve MAY be 723 specially configured (high-reachability configuration). This special 724 configuration has the goal of reducing the server side candidate to 725 preferably a single one per (address family, media stream, media 726 component) tuple. Instead of gathering all possible addresses 727 including relayed and server reflexive addresses, the server uses a 728 single address per address family that it knows it should be 729 reachable by a client behind one or more NATs. The reason for this 730 special configuration is twofold: Firstly it reduces the load on the 731 server in address gathering and in ICE processing during the 732 connectivity checks. Secondly it will reduce the number of 733 permutations for candidate pairs significantly thus potentially 734 speeding up the conclusion of the ICE processing. Note however that 735 using this option on a server that doesn't fulfill the requirement of 736 being reachable is counter-productive and it is important that this 737 is correctly configured. 739 The above general consideration for servers applies also for TCP 740 based candidates. A general implementation should support several 741 candidate collection techniques and connection types. For TCP based 742 candidates a high-reachability configured server is recommended to 743 only offer Host candidates. In addition to passive connection types 744 the server can select to provide active or SO connection types to 745 match the client's candidates. 747 6.5. RTSP Server Response 748 The server determines if the SETUP request is successful from the 749 other perspectives and if so returns a 200 OK response; otherwise it 750 returns an error code. At that point the server, having selected a 751 transport specification using the "D-ICE" lower layer, will need to 752 include that transport specification in the response message. The 753 transport specification SHALL include the candidates gathered in 754 Section 6.4 in the "candidates" transport header parameter as well as 755 the server's username fragment and password. In the case that there 756 are no valid candidate pairs with the combination of the client and 757 server candidates, a 480 (ICE Processing Failed) error response SHALL 758 be returned which MUST include the server's candidates. The return 759 of a 480 error allows both the server and client to release their 760 candidates. 762 Example of a successful response to the request in Section 6.3. 764 S->C: RTSP/2.0 200 OK 765 CSeq: 313 766 Session: 12345678 767 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=MkQ3; 768 ICE-Password=pos12Dgp9FcAjpq82ppaF; candidates=" 769 1 1 UDP 2130706431 192.0.2.56 50234 typ host" 770 Accept-Ranges: NPT 771 Date: 23 Jan 1997 15:35:06 GMT 772 Server: PhonyServer 1.1 773 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 775 6.6. Server to Client ICE Connectivity Checks 777 The server shall start the connectivity checks following the 778 procedures described in Section 5.7 and 5.8 of ICE [RFC5245] unless 779 it is configured to use the high-reachability option. If it is then 780 it MAY suppress its own checks until the servers checks are triggered 781 by the client's connectivity checks. 783 Please note that ICE [RFC5245] section 5.8 does specify that the 784 initiation of the checks are paced and new ones are only started 785 every Ta milliseconds. The motivation for this is documented in 786 Appendix B.1 of ICE [RFC5245] as for SIP/SDP all media streams within 787 an offer/answer dialog are running using the same queue. To ensure 788 the same behavior with RTSP, the server SHALL use a single pacer 789 queue for all media streams within each RTSP session. 791 The values for the pacing of STUN and TURN transactions Ta and RTO 792 can be configured but have the same minimum values defined in the ICE 793 specification. 795 When a connectivity check from the client reaches the server it will 796 result in a triggered check from the server as specified in 797 Section 7.2.1.4 of ICE [RFC5245]. This is why servers with a high 798 reachability address can wait until this triggered check to send out 799 any checks for itself so saving resources and mitigating the DDoS 800 potential. 802 6.7. Client to Server ICE Connectivity Check 804 The client receives the SETUP response and learns the candidate 805 addresses to use for the connectivity checks. The client SHALL 806 initiate its connectivity check, following the procedures in 807 Section 6 of ICE [RFC5245]. The pacing of STUN transactions 808 (Section B.1 of [RFC5245]) SHALL be used across all media streams 809 that are part of the same RTSP session. 811 Aggressive nomination SHOULD be used with RTSP during initial SETUP 812 for a resource. This doesn't have all the negative impact that it 813 has in offer/answer as media playing only starts after issuing a PLAY 814 request. Thus the issue with a change of the media path being used 815 for delivery can be avoided by not issuing a PLAY request while STUN 816 connectivity checks are still outstanding. Aggressive nomination can 817 result in multiple candidate pairs having their nominated flag set 818 but according to Section 8.1.1.2 of ICE [RFC5245] when the PLAY 819 request is sent the media will arrive on the pair with the highest 820 priority. Note, different media resources may still end up with 821 different foundations. 823 Note: The above does not change ICE and its handling of aggressive 824 nomination. Using aggressive nomination, a higher priority candidate 825 pair with an outstanding connectivity check message can move into the 826 Succeded state and will have its Nominated flag set. This happening 827 after another candidate pair for a given media stream having moved 828 into Succeded state. Thus moving the used pair to this higher 829 priority candidate pair. To avoid this occurring during actual media 830 transport, the RTSP client can add additional logic when the ICE 831 processing overall is completed to indicate if there is still higher 832 priority connectivity checks outstanding. If some check is still 833 outstanding, the implementation can choose to wait until some 834 additional timeout triggers or the outstanding checks completes 835 before progressing with a PLAY request. An alternative is to accept 836 the risk for a path change during media delivery and start playing 837 immediately. 839 RTSP clients that want to ensure that each media resource uses the 840 same path can use regular nomination where both the ICE processing 841 completion criteria can be controlled in addition to which media 842 streams being nominated for use. This does not affect the RTSP 843 server, as its role is the one of being controlled. 845 6.8. Client Connectivity Checks Complete 847 When the client has concluded all of its connectivity checks and has 848 nominated its desired candidate pair for a particular media stream, 849 it MAY issue a PLAY request for that stream. Note, that due to the 850 aggressive nomination, there is a risk that any outstanding check may 851 nominate another pair than what was already nominated. The candidate 852 pair with the highest priority will be used for the media. If the 853 client has locally determined that its checks have failed it may try 854 providing an extended set of candidates and update the server 855 candidate list by issuing a new SETUP request for the media stream. 857 If the client concluded its connectivity checks successfully and 858 therefore sent a PLAY request but the server cannot conclude 859 successfully, the server will respond with a 480 (ICE Processing 860 Failed). Upon receiving the 480 (ICE Processing Failed) response, 861 the client may send a new SETUP request assuming it has any new 862 information that can be included in the candidate list. If the 863 server is still performing the checks when receiving the PLAY request 864 it will respond with a 150 (ICE connectivity checks in progress) 865 response to indicate this. 867 6.9. Server Connectivity Checks Complete 869 When the RTSP server receives a PLAY request, it checks to see that 870 the connectivity checks have concluded successfully and only then 871 will it play the stream. If the PLAY request is for a particular 872 media stream, the server only needs to check that the connectivity 873 checks for that stream completed successfully. If the server has not 874 concluded its connectivity checks, the server indicates that by 875 sending the 150 (ICE connectivity checks in progress) 876 (Section 4.5.1). If there is a problem with the checks, then the 877 server sends a 480 response to indicate a failure of the checks. If 878 the checks are successful then the server sends a 200 OK response and 879 starts delivering media. 881 6.10. Freeing Candidates 883 Both server and client MAY free its non selected candidates as soon 884 as a 200 PLAY response has been issued/received and no outstanding 885 connectivity checks exist. 887 6.11. Steady State 889 The client and server SHALL use STUN to send keep-alive messages for 890 the nominated candidate pair(s) following the rules of Section 10 of 891 ICE [RFC5245]. This is important as normally RTSP play mode sessions 892 only contain traffic from the server to the client so the bindings in 893 the NAT need to be refreshed by the client to server traffic provided 894 by the STUN keep-alive. 896 6.12. Re-SETUP 898 A client that decides to change any parameters related to the media 899 stream setup will send a new SETUP request. In this new SETUP 900 request the client MAY include a new different username fragment and 901 password to use in the ICE processing. New username and password 902 SHALL cause the ICE processing to start from the beginning again, 903 i.e. an ICE restart (Section 9.1.1.1 of [RFC5245]). The client 904 SHALL in case of ICE restart gather candidates and include the 905 candidates in the transport specification for D-ICE. 907 ICE restarts may be triggered due to changes of clients or servers 908 attachment to the network, i.e. changes to the media streams 909 destination or source address or port. Most RTSP parameter changes 910 would not require an ICE restart, instead existing mechanisms in RTSP 911 for indicating from where in the RTP stream they apply should be 912 used. These include: Performing a pause prior to the parameter 913 change and then resume; or assuming the server supports using SETUP 914 during the PLAY state, using the RTP-Info header (Section 18.43 of 915 [I-D.ietf-mmusic-rfc2326bis]) to indicate from where in the media 916 stream the change shall apply. 918 The server SHALL support SETUP requests in PLAY state, as long as the 919 SETUP changes only the ICE parameters, which are: ICE-Password, ICE- 920 ufrag and the content of ICE candidates. 922 If the RTSP session is in playing state at the time of sending the 923 SETUP request requiring ICE restart, then the ICE connectivity checks 924 SHALL use Regular nomination. Any ongoing media delivery continues 925 on the previously nominated candidate pairs until the new pairs have 926 been nominated for the individual candidate. Once the nomination of 927 the new candidate pair has completed, all unused candidates may be 928 released. 930 6.13. Server Side Changes After Steady State 932 A Server may require an ICE restart because of server side load 933 balancing or a failure resulting in an IP address and a port number 934 change. It shall use the PLAY_NOTIFY method to inform the client 935 (Section 13.5 [I-D.ietf-mmusic-rfc2326bis]) with a new Notify-Reason 936 header: ice-restart. The server will identify if the change is for a 937 single media or for the complete session by including the 938 corresponding URI in the PLAY_NOTIFY request. 940 Upon receiving and responding to this PLAY_NOTIFY with ice-restart 941 reason the client SHALL gather new ICE candidates, send SETUP 942 requests for each media stream part of the session. The server 943 provides its candidates in the SETUP response the same way as for the 944 first time ICE processing. Both server and client shall provide new 945 ICE user names and passwords. The client MAY issue the SETUP request 946 while the session is in PLAYING state. 948 If the RTSP session is in PLAYING state when the client issues the 949 SETUP request, the client SHALL use regular nomination. If not the 950 client will use the same procedures as for when first creating the 951 session. 953 Note that keepalive messages on the previous set of candidate pairs 954 should continue until all new candidate pairs have been nominated. 955 After having nominated a new set of candidate pairs, the client may 956 continue to receive media for some additional time. Even if the 957 server stops delivering media over that candidate pair at the time of 958 nomination, media may arrive for up to one maximum segment lifetime 959 as defined in TCP (2 minutes). Unfortunately, if the RTSP server is 960 divided into a separate controller and media stream, a failure may 961 result in continued media delivery for a longer time than the maximum 962 segment lifetime, thus source filtering is RECOMMENDED. 964 For example: 966 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 967 CSeq: 854 968 Notify-Reason: ice-restart 969 Session: uZ3ci0K+Ld 970 Server: PhonyServer 1.1 972 C->S: RTSP/2.0 200 OK 973 CSeq: 854 974 User-Agent: PhonyClient/1.2 976 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 977 CSeq: 314 978 Session: uZ3ci0K+Ld 979 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=Kl1C; 980 ICE-Password=H4sICGjBsEcCA3Rlc3RzLX; candidates=" 981 1 1 UDP 2130706431 10.0.1.17 8998 typ host; 982 2 1 UDP 1694498815 192.0.2.3 51456 typ srflx 983 raddr 10.0.1.17 rport 9002"; RTCP-mux, 984 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 985 RTP/AVP/TCP;unicast;interleaved=0-1 986 Accept-Ranges: NPT, UTC 987 User-Agent: PhonyClient/1.2 989 C->S: SETUP rtsp://server.example.com/fizzle/foo/video RTSP/2.0 990 CSeq: 315 991 Session: uZ3ci0K+Ld 992 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=hZv9; 993 ICE-Password=JAhA9myMHETTFNCrPtg+kJ; candidates=" 994 1 1 UDP 2130706431 10.0.1.17 9000 typ host; 995 2 1 UDP 1694498815 192.0.2.3 51576 typ srflx 996 raddr 10.0.1.17 rport 9000"; RTCP-mux, 997 RTP/AVP/UDP; unicast; dest_addr=":6972"/":6973", 998 RTP/AVP/TCP;unicast;interleaved=0-1 999 Accept-Ranges: NPT, UTC 1000 User-Agent: PhonyClient/1.2 1002 S->C: RTSP/2.0 200 OK 1003 CSeq: 314 1004 Session: uZ3ci0K+Ld 1005 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=CbDm; 1006 ICE-Password=OfdXHws9XX0eBr6j2zz9Ak; candidates=" 1007 1 1 UDP 2130706431 192.0.2.56 50234 typ host" 1008 Accept-Ranges: NPT 1009 Date: 11 March 2011 13:17:46 GMT 1010 Server: PhonyServer 1.1 1012 S->C: RTSP/2.0 200 OK 1013 CSeq: 315 1014 Session: uZ3ci0K+Ld 1015 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=jigs; 1016 ICE-Password=Dgx6fPj2lsa2WI8b7oJ7+s; candidates=" 1017 1 1 UDP 2130706431 192.0.2.56 47233 typ host" 1018 Accept-Ranges: NPT 1019 Date: 11 March 2011 13:17:47 GMT 1020 Server: PhonyServer 1.1 1022 7. ICE and Proxies 1023 RTSP allows for proxies which can be of two fundamental types 1024 depending on whether they relay and potentially cache the media or 1025 not. Their differing impact on the RTSP NAT traversal solution, 1026 including backwards compatibility, is explained below. 1028 7.1. Media Handling Proxies 1030 An RTSP proxy that relays or caches the media stream for a particular 1031 media session can be considered to split the media transport into two 1032 parts: A media transport between the server and the proxy according 1033 to the proxy's need, and delivery from the proxy to the client. This 1034 split means that the NAT traversal solution will need to be run on 1035 each individual media leg according to need. 1037 It is RECOMMENDED that any media handling proxy support the media NAT 1038 traversal defined within this specification. This is for two 1039 reasons: Firstly to enable clients to perform NAT traversal for the 1040 media between the proxy and itself, and secondly to allow the proxy 1041 to be topology independent to support performing NAT traversal (to 1042 the server) for non-NAT traversal capable clients present in the same 1043 address domain as the proxy. 1045 For a proxy to support the media NAT traversal defined in this 1046 specification a proxy will need to implement the solution fully and 1047 be able to act as both a controlling and a controlled ICE peer. The 1048 proxy also SHALL include the "setup.ice-d-m" feature tag in any 1049 applicable capability negotiation headers, such as "Proxy-Supported." 1051 7.2. Signalling Only Proxies 1053 A signalling only proxy handles only the RTSP signalling and does not 1054 have the media relayed through proxy functions. This type of proxy 1055 is not likely to work unless the media NAT traversal solution is in 1056 place between the client and the server, because the Denial of 1057 Service (DoS) protection measures, as discussed in Section 21.2.1 of 1058 RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis], usually prevent media delivery 1059 to other addresses other than from where the RTSP signalling arrives 1060 at the server. 1062 The solution for the Signalling Only proxy is that it must forward 1063 the RTSP SETUP requests including any transport specification with 1064 the "D-ICE" lower layer and the related transport parameters. A 1065 proxy supporting this functionality SHOULD indicate its capability by 1066 always including the "setup.ice-d-m" feature tag in the "Proxy- 1067 Supported" header. 1069 7.3. Non-supporting Proxies 1070 A media handling proxy that doesn't support the ICE media NAT 1071 traversal specified here is assumed to remove the transport 1072 specification and use any of the lower prioritized transport 1073 specifications if provided by the requester. The specification of 1074 such a non ICE transport enables the negotiation to complete, 1075 although with a less preferred method since a NAT between the proxy 1076 and the client may result in failure of the media path. 1078 A non-media handling proxy is expected to ignore and simply forward 1079 all unknown transport specifications, however, this can only be 1080 guaranteed for proxies following the published RTSP 2.0 specification 1081 [I-D.ietf-mmusic-rfc2326bis]. 1083 Unfortunately the usage of the "setup.ice-d-m" feature tag in the 1084 Proxy-Require will have contradicting results. For a non ICE 1085 supporting but media handling proxy, the inclusion of the feature tag 1086 will result in aborting the setup and indicating that it isn't 1087 supported, which is desirable if you want to provide other fallbacks 1088 or other transport configurations to handle the situation. For non- 1089 supporting non-media handling proxies the result will also result in 1090 aborting the setup, however, setup might have worked if the proxy- 1091 require tag wasn't present. This variance in results is the reason 1092 we don't recommend the usage of the Proxy-Require header. Instead we 1093 recommend the usage of the Supported header to force proxies to 1094 include the feature tags they support in the Proxy-Supported header, 1095 which will provide a positive indication when all proxies in the 1096 chain between the client and server support the functionality. In 1097 case one or more proxy does not explicitly indicate support, it will 1098 remove the feature tag "setup.ice-d-m". If that proxy is a non-media 1099 handling one and the client would despite the lack of explicit 1100 indication would attempt a setup using D-ICE transport, it is likely 1101 to work. Thus giving the client explicit indication of support in 1102 the SETUP response that the proxy chain supports at least passthrough 1103 of this media. Where the Require and Support RTSP headers failed to 1104 provide that information. 1106 8. RTP and RTCP Multiplexing 1108 "Multiplexing RTP Data and Control Packets on a Single Port" 1109 [RFC5761] specifies how and when RTP and RTCP can be multiplexed on 1110 the same port. This multiplexing SHALL be combined with ICE as it 1111 makes RTP and RTCP need only a single component per media stream 1112 instead of two, so reducing the load on the connectivity checks. For 1113 details on how to negotiate RTP and RTCP multiplexing, see Appendix C 1114 of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. 1116 Multiplexing RTP and RTCP has the benefit that it avoids the need for 1117 handling two components per media stream when RTP is used as the 1118 media transport protocol. This eliminates at least one STUN check 1119 per media stream and will also reduce the time needed to complete the 1120 ICE processing by at least the time it takes to pace out the 1121 additional STUN checks of up to one complete round trip time for a 1122 single media stream. In addition to the protocol performance 1123 improvements, the server and client side complexities are reduced as 1124 multiplexing halves the total number of STUN instances and holding 1125 the associated state. Multiplexing will also reduce the combinations 1126 and length of the list of possible candidates. 1128 The implementation of RTP and RTCP multiplexing is additional work 1129 required for this solution. However, when implementing the ICE 1130 solution a server or client will need to implement a de-multiplexer 1131 between the STUN, and RTP or RTCP packets below the RTP/RTCP 1132 implementation anyway, so the additional work of one new 1133 demultiplexing point directly connected to the STUN and RTP/RTCP 1134 seems small relative to the benefits provided. 1136 Due to the above mentioned benefits, RTSP servers and clients that 1137 support "D-ICE" lower layer transport in combination with RTP SHALL 1138 also implement RTP and RTCP multiplexing as specified in this section 1139 and [RFC5761]. 1141 9. Fallback and Using Partial ICE functionality to improve NAT/Firewall 1142 traversal 1144 The need for fallback from ICE in RTSP should be less than for SIP 1145 using ICE in SDP offer/answer where a default destination candidate 1146 is very important to enable interworking with non-ICE capable 1147 endpoints. In RTSP, capability determination for ICE can happen 1148 prior to the RTSP SETUP request. This means a client should normally 1149 not need to include fallback alternatives when offering ICE, as the 1150 capability for ICE will already be determined. However, as described 1151 in this section, clients may wish to use part of the ICE 1152 functionality to improve NAT/Firewall traversal where the server is 1153 non-ICE capable. 1155 Section 4.1.4 of the ICE [RFC5245] specification does recommend that 1156 the default destination, i.e. what is used as fallback if the peer 1157 isn't ICE capable, is a candidate of relayed type to maximize the 1158 likelihood of successful transport of media. This is based on the 1159 peer in SIP SDP offer/answer is almost as likely as the RTSP client 1160 to be behind a NAT. For RTSP the deployment of servers are much more 1161 heavily weighted towards deployment with public reachability. In 1162 fact since publicly reachable servers behind NAT either need to 1163 support ICE or have static configurations that allow traversal, one 1164 can assume that the server will have a public address or support ICE. 1165 Thus, the selection of the default destination address for RTSP can 1166 be differently prioritized. 1168 As an ICE enabled client behind a NAT needs to be configured with a 1169 STUN server address to be able to gather candidates successfully, 1170 this can be used to derive a server reflexive candidate for the 1171 clients port. How useful this is for a NAT'ed RTSP client as a 1172 default candidate depends on the properties of the NAT. As long as 1173 the NAT use an address independent mapping, then using a STUN derived 1174 reflexive candidate is likely to be successfully. This is however 1175 brittle in several ways. First, if the NATs behavior is attempted to 1176 be determined using STUN as described in [RFC3489], the determined 1177 behavior might not be representative of the behavior encountered in 1178 another mapping. Secondly, filter state towards the ports used by 1179 the server needs to be established. This requires that the server 1180 actually includes both address and ports in its response to the SETUP 1181 request. Thirdly messages need to be sent to these ports for keep- 1182 alive at a regular interval. How a server reacts to such unsolicited 1183 traffic is unknown. This brittleness may be accepted in fallback due 1184 to lack of support on the server side. 1186 To maximize the likelihood that an RTSP client is capable of 1187 receiving media a relay based address should be chosen as the default 1188 fallback address. However, for RTSP clients lacking a relay server, 1189 like a TURN server, or where usage of such a server has significant 1190 cost associated with it the usage of a STUN derived server reflexive 1191 address as client default has a reasonable likelihood of functioning 1192 and may be used as an alternative. 1194 Fallback addresses need to be provided in their own transport 1195 specification using a specifier that does not include the "D-ICE" 1196 lower layer transport. Instead the selected protocol, e.g. UDP 1197 needs to be explicitly or implicitly indicated. Secondly the 1198 selected default candidate needs to be included in the SETUP request. 1199 If this candidate is server reflexive or relayed the aspect of keep- 1200 alive needs to be ensured. 1202 10. IANA Considerations 1204 This document requests registration in a number of registries, both 1205 for RTSP and SDP. For all the below registrations the contact person 1206 on behalf of the IETF WG MMUSIC is Magnus Westerlund; Postal address: 1207 Farogatan 6, 164 80 Stockholm, Sweden; Email: 1208 magnus.westerlund@ericsson.com. 1210 RFC-Editor Note: Please replace any occurrence of RFCXXXX in the 1211 below with the RFC number this specification is assigned. 1213 10.1. RTSP Feature Tags 1215 This document request that one RTSP 2.0 feature tag is registered in 1216 the "RTSP 2.0 Feature-tags" registry: 1218 setup.ice-d-m A feature tag representing the support of the ICE 1219 based establishment of datagram media transport that is capable of 1220 transport establishment through NAT and Firewalls. This feature 1221 tag applies to clients, servers and proxies and indicates that 1222 support of all the mandatory functions of this specification. 1224 10.2. Transport Protocol Specifications 1226 This document needs to register a number of transport protocol 1227 combinations in the RTSP 2.0 "Transport Protocol Specifications" 1228 registry. 1230 "RTP/AVP/D-ICE" RTP using the AVP profile over an ICE established 1231 datagram flow. 1233 "RTP/AVPF/D-ICE" RTP using the AVPF profile over an ICE established 1234 datagram flow. 1236 "RTP/SAVP/D-ICE" RTP using the SAVP profile over an ICE established 1237 datagram flow. 1239 "RTP/SAVPF/D-ICE" RTP using the SAVPF profile over an ICE 1240 established datagram flow. 1242 10.3. RTSP Transport Parameters 1244 This document requests that 3 transport parameters are registered in 1245 the RTSP 2.0's "Transport Parameters" registry: 1247 "candidates": Listing the properties of one or more ICE candidate. 1248 See Section Section 4.2 of RFCXXXX. 1250 "ICE-Password": The ICE password used to authenticate the STUN 1251 binding request in the ICE connectivity checks. See 1252 Section Section 4.3 of RFCXXXX. 1254 "ICE-ufrag": The ICE username fragment used to authenticate the STUN 1255 binding requests in the ICE connectivity checks. See 1256 Section Section 4.3 of RFCXXXX. 1258 10.4. RTSP Status Codes 1260 This document requests that 2 assignments are done in the "RTSP 2.0 1261 Status Codes" registry. The values are: 1263 150: The 150 response code indicates that ICE connectivity checks 1264 are still in progress and haven't concluded. This response SHALL 1265 be sent within 200 milliseconds of receiving a PLAY request that 1266 currently can't be fulfilled because ICE connectivity checks are 1267 still running. Subsequently, every 3 seconds after the previous 1268 sent one, a 150 reply shall be sent until the ICE connectivity 1269 checks conclude either successfully or in failure, and a final 1270 response for the request can be provided. 1272 480: The 480 client error response code is used in cases when the 1273 request can't be fulfilled due to a failure in the ICE processing, 1274 such as that all the connectivity checks have timed out. This 1275 error message can appear either in response to a SETUP request to 1276 indicate that no candidate pair can be constructed or to a PLAY 1277 request that the server's connectivity checks resulted in failure. 1279 10.5. Notify-Reason value 1281 This document requests that one assignment is done in the RTSP 2.0 1282 Notify-Reason header value registry. The defined value is: 1284 ice-restart: Server notifying the client about the need for an ICE 1285 restart. See section Section 4.6. 1287 10.6. SDP Attribute 1289 The registration of one SDP attribute is requested: 1291 SDP Attribute ("att-field"): 1293 Attribute name: rtsp-ice-d-m 1294 Long form: ICE for RTSP datagram media NAT traversal 1295 Type of attribute: Session level only 1296 Subject to charset: No 1297 Purpose: RFC XXXX, Section 4.7 1298 Values: No values defined. 1299 Contact: Magnus Westerlund 1300 E-mail: magnus.westerlund@ericsson.com 1301 phone: +46 10 714 82 87 1303 11. Security Considerations 1305 ICE [RFC5245] and ICE TCP [RFC6544] provide an extensive discussion 1306 on security considerations which apply here as well. 1308 11.1. ICE and RTSP 1310 A long-standing risk with transmitting a packet stream over UDP is 1311 that the host may not be interested in receiving the stream. On 1312 today's Internet many hosts are behind NATs or operate host firewalls 1313 which do not respond to unsolicited packets with an ICMP port 1314 unreachable error. Thus, an attacker can construct RTSP SETUP 1315 requests with a victim's IP address and cause a flood of media 1316 packets to be sent to a victim. The addition of ICE, as described in 1317 this document, provides protection from the attack described above. 1318 By performing the ICE connectivity check, the media server receives 1319 confirmation that the RTSP client wants the media. While this 1320 protection could also be implemented by requiring the IP addresses in 1321 the SDP match the IP address of the RTSP signaling packet, such a 1322 mechanism does not protect other hosts with the same IP address (such 1323 as behind the same NAT), and such a mechanism would prohibit 1324 separating the RTSP controller from the media play-out device (e.g., 1325 an IP-enabled remote control and an IP-enabled television); it also 1326 forces RTSP proxies to relay the media streams through them, even if 1327 they would otherwise be only signalling proxies. 1329 To protect against the attacks in ICE based on signalling information 1330 RTSP signalling should be protected using TLS to prevent 1331 eavesdropping and modification of information. 1333 The STUN amplification attack described in Section 18.5.2 in ICE 1334 [RFC5245] needs consideration. Servers that are able to run 1335 according to the high-reachability option have good mitigation 1336 against this attack as they only send connectivity checks towards an 1337 address and port pair they have received an incoming connectivity 1338 check from. This means an attacker requires both the capability to 1339 spoof source addresses and to signal the RTSP server a set of ICE 1340 candidates. Independently an ICE agent needs to implement the 1341 mitigation to reduce the volume of the amplification attack as 1342 described in the ICE specification. 1344 12. Acknowledgements 1346 The authors would like to thank Remi Denis-Courmont for suggesting 1347 the method of integrating ICE in RTSP signalling, Dan Wing for help 1348 with the security section and numerous other issues, Ari Keranen for 1349 review of the document and its ICE details. 1351 13. References 1353 13.1. Normative References 1355 [I-D.ietf-mmusic-rfc2326bis] 1356 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1357 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1358 (RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in 1359 progress), April 2013. 1361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1362 Requirement Levels", BCP 14, RFC 2119, March 1997. 1364 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1365 Description Protocol", RFC 4566, July 2006. 1367 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1368 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1370 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1371 (ICE): A Protocol for Network Address Translator (NAT) 1372 Traversal for Offer/Answer Protocols", RFC 5245, April 1373 2010. 1375 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1376 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1377 October 2008. 1379 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1380 Control Packets on a Single Port", RFC 5761, April 2010. 1382 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B.B., and A.B. 1383 Roach, "TCP Candidates with Interactive Connectivity 1384 Establishment (ICE)", RFC 6544, March 2012. 1386 13.2. Informative References 1388 [I-D.ietf-mmusic-rtsp-nat-evaluation] 1389 Westerlund, M. and T. Zeng, "The Evaluation of Different 1390 Network Address Translator (NAT) Traversal Techniques for 1391 Media Controlled by Real-time Streaming Protocol (RTSP)", 1392 draft-ietf-mmusic-rtsp-nat-evaluation-06 (work in 1393 progress), November 2012. 1395 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1396 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1398 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1399 Address Translator (Traditional NAT)", RFC 3022, January 1400 2001. 1402 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1403 A., Peterson, J., Sparks, R., Handley, M., and E. 1404 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1405 June 2002. 1407 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1408 with Session Description Protocol (SDP)", RFC 3264, June 1409 2002. 1411 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1412 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1413 Through Network Address Translators (NATs)", RFC 3489, 1414 March 2003. 1416 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1417 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1419 Authors' Addresses 1421 Jeff Goldberg 1422 Cisco 1423 11 New Square, Bedfont Lakes 1424 Feltham,, Middx TW14 8HA 1425 United Kingdom 1427 Phone: +44 20 8824 1000 1428 Email: jgoldber@cisco.com 1430 Magnus Westerlund 1431 Ericsson 1432 Farogatan 6 1433 Stockholm SE-164 80 1434 Sweden 1436 Phone: +46 8 719 0000 1437 Email: magnus.westerlund@ericsson.com 1438 Thomas Zeng 1439 Nextwave Wireless, Inc. 1440 12670 High Bluff Drive 1441 San Diego, CA 92130 1442 USA 1444 Phone: +1 858 480 3100 1445 Email: thomas.zeng@gmail.com