idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-17.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 (November 18, 2013) is 3811 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-38 ** 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-10 -- 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: May 22, 2014 Ericsson 6 T. Zeng 7 Nextwave Wireless, Inc. 8 November 18, 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-17 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 May 22, 2014. 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 . . . . . . . . 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 . . . . . . . 11 67 4.5.2. 480 ICE Processing Failed . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . 12 72 5.1.1. ICE-Lite . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . 13 77 6.1. Session description and RTSP DESCRIBE (optional) . . . . 13 78 6.2. Setting up the Media Streams . . . . . . . . . . . . . . 15 79 6.3. RTSP SETUP Request . . . . . . . . . . . . . . . . . . . 15 80 6.4. Gathering Candidates . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . 17 84 6.8. Client Connectivity Checks Complete . . . . . . . . . . . 18 85 6.9. Server Connectivity Checks Complete . . . . . . . . . . . 19 86 6.10. Freeing Candidates . . . . . . . . . . . . . . . . . . . 19 87 6.11. Steady State . . . . . . . . . . . . . . . . . . . . . . 19 88 6.12. Re-SETUP . . . . . . . . . . . . . . . . . . . . . . . . 19 89 6.13. Server Side Changes After Steady State . . . . . . . . . 20 90 7. ICE and Proxies . . . . . . . . . . . . . . . . . . . . . . . 22 91 7.1. Media Handling Proxies . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . 24 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 99 10.1. RTSP Feature Tags . . . . . . . . . . . . . . . . . . . 26 100 10.2. Transport Protocol Specifications . . . . . . . . . . . 26 101 10.3. RTSP Transport Parameters . . . . . . . . . . . . . . . 27 102 10.4. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 27 103 10.5. Notify-Reason value . . . . . . . . . . . . . . . . . . 27 104 10.6. SDP Attribute . . . . . . . . . . . . . . . . . . . . . 27 105 11. Security Considerations . . . . . . . . . . . . . . . . . . . 28 106 11.1. ICE and RTSP . . . . . . . . . . . . . . . . . . . . . . 28 107 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 108 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 109 13.1. Normative References . . . . . . . . . . . . . . . . . . 29 110 13.2. Informative References . . . . . . . . . . . . . . . . . 30 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 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 and 204 IPv6), media stream and media component tuple can be included to 205 reduce the number of combinations and speed up the completion. 207 5. The server sets up the media and if successful responds to the 208 SETUP request with a 200 OK response. In that response the 209 server selects the transport specification using ICE and 210 includes its candidates in the candidates parameter. 212 6. The server starts the connectivity checks following the 213 procedures described in Section 5.7 and 5.8 of ICE [RFC5245]. 214 If the server is not behind a NAT and uses a public IP address 215 with a single candidate per media stream, component and address 216 family, then the server may be configured to not initiate 217 connectivity checks. 219 7. The client receives the SETUP response and learns the candidate 220 addresses to use for the connectivity checks, and then initiates 221 its connectivity check, following the procedures in Section 6 of 222 ICE [RFC5245]. 224 8. When a connectivity check from the client reaches the server it 225 will result in a triggered check from the server. This is why 226 servers not behind a NAT can wait until this triggered check to 227 send out any checks for itself, so saving resources and 228 mitigating the DDoS potential from server connectivity 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 servers 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. 268 4.1. ICE Transport Lower Layer 270 A new lower layer "D-ICE" for transport specifications is defined. 271 This lower layer is datagram clean except that the protocol used must 272 be possible to demultiplex from STUN messages (see STUN [RFC5389]). 273 With datagram clean we mean that it must be capable of describing the 274 length of the datagram, transport that datagram (as a binary chunk of 275 data) and provide it at the receiving side as one single item. This 276 lower layer can be any transport type defined for ICE which does 277 provide datagram transport capabilities. UDP based transport 278 candidates are defined in ICE [RFC5245] and MUST be supported. It is 279 OPTIONAL to also support TCP based candidates as defined by "TCP 280 Candidates with Interactive Connectivity Establishment (ICE)" 281 [RFC6544]. The TCP based candidate fulfills the requirements on 282 providing datagram transport and can thus be used in combination with 283 RTP. Additional transport types for candidates may be defined in the 284 future. 286 This lower layer uses ICE to determine which of the different 287 candidates shall be used and then when the ICE processing has 288 concluded, uses the selected candidate to transport the datagrams 289 over this transport. 291 This lower layer transport can be combined with all upper layer media 292 transport protocols that are possible to demultiplex with STUN and 293 which use datagrams. This specification defines the following 294 combinations: 296 o RTP/AVP/D-ICE 298 o RTP/AVPF/D-ICE 300 o RTP/SAVP/D-ICE 302 o RTP/SAVPF/D-ICE 304 This list can easily be extended with more transport specifications 305 after having performed the evaluation that they are compatible with 306 D-ICE as lower layer. 308 The lower-layer "D-ICE" has the following rules for the inclusion of 309 the RTSP transport header (Section 18.52 of RTSP 2.0 310 [I-D.ietf-mmusic-rfc2326bis]) parameters: 312 unicast: As ICE only supports unicast operations, thus it is 313 REQUIRED that one include the unicast indicator parameter, (see 314 section 18.52 in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]). 316 candidates: The "candidates" parameter SHALL be included as this 317 specify at least one candidate to try to establish a working 318 transport path with. 320 dest_addr: This parameter SHALL NOT be included as "candidates" is 321 used instead to provide the necessary address information. 323 ICE-Password: This parameter SHALL be included (See 324 Section Section 4.2). 326 ICE-ufrag: This parameter SHALL be included (See 327 Section Section 4.2). 329 4.2. ICE Candidate Transport Header Parameter 330 This section defines a new RTSP transport parameter for carrying ICE 331 candidates related to the transport specification they appear within, 332 which may then be validated with an end-to-end connectivity check 333 using STUN [RFC5389]. Transport parameters may only occur once in 334 each transport specification. For transport specifications using 335 "D-ICE" as lower layer, this parameter MUST be present. The 336 parameter can contain one or more ICE candidates. In the SETUP 337 response there is only a single transport specification, and if that 338 uses the "D-ICE" lower layer this parameter MUST be present and 339 include the server side candidates. 341 trns-parameter = 343 trns-parameter =/ SEMI ice-trn-par 344 ice-trn-par = "candidates" EQUAL DQ SWS ice-candidate 345 *(SEMI ice-candidate) SWS DQ 346 ice-candidate = foundation SP 347 component-id SP 348 transport SP 349 priority SP 350 connection-address SP 351 port SP 352 cand-type 353 [SP rel-addr] 354 [SP rel-port] 355 [SP tcp-type-ext] ; Mandatory if transport = TCP 356 *(SP extension-att-name SP extension-att-value) 358 foundation = 359 component-id = 360 transport = 361 priority = 362 cand-type = 363 rel-addr = 364 rel-port = 365 tcp-type-ext = 366 extension-att-name = 367 extension-att-value = 368 connection-address = 369 port = 370 EQUAL = 371 DQ = 372 SWS = 373 SEMI = 375 : is the unicast IP address of the candidate, 376 allowing for IPv4 addresses, IPv6 addresses and Fully qualified 377 domain names (FQDN), taken from SDP [RFC4566]. Note, the syntax 378 allows multicast addresses, but they SHALL NOT be used in this 379 context. The connection address SHOULD be on the same format 380 (explicit IP or FQDN) as in the dest_addr parameter used to 381 express fallbacks. An IP address SHOULD be used, but an FQDN MAY 382 be used in place of an IP address. In that case, when receiving a 383 SETUP request or response containing an FQDN in a candidate 384 parameter, the FQDN is looked up in the DNS first using an AAAA 385 record (assuming the agent supports IPv6), and if no result is 386 found or the agent only supports IPv4, using an A record. If the 387 DNS query returns more than one IP address, one is chosen, and 388 then used for the remainder of ICE processing which in RTSP is 389 subsequent RTSP SETUPs for the same RTSP session. 391 : is the port of the candidate; the syntax is defined by SDP 392 [RFC4566]. 394 : indicates the transport protocol for the candidate. 395 The ICE specification defines UDP. "TCP Candidates with 396 Interactive Connectivity Establishment (ICE)" [RFC6544] defines 397 how TCP is used as candidates. Additional extensibility is 398 provided to allow for future transport protocols to be used with 399 ICE, such as the Datagram Congestion Control Protocol (DCCP) 400 [RFC4340]. 402 : is an identifier that is equivalent for two 403 candidates that are of the same type, share the same base, and 404 come from the same STUN server, and is composed of one to thirty 405 two . The foundation is used to optimize ICE 406 performance in the Frozen algorithm (as described in [RFC5245]). 408 : identifies the specific component of the media 409 stream for which this is a candidate and is a positive integer 410 between 1 and 256. It MUST start at 1 and MUST increment by 1 for 411 each component of a particular media stream. For media streams 412 based on RTP, candidates for the actual RTP media MUST have a 413 component ID of 1, and candidates for RTCP MUST have a component 414 ID of 2 unless RTP and RTCP Multiplexing (Section 8) is used when 415 the second component is omitted and RTP and RTCP is both 416 transported over the first component. Other types of media 417 streams which require multiple components MUST develop 418 specifications which define the mapping of components to component 419 IDs. See Section 14 in [RFC5245] for additional discussion on 420 extending ICE to new media streams. 422 : is a positive integer between 1 and (2**31 - 1). 424 : encodes the type of candidate. The ICE specification 425 defines the values "host", "srflx", "prflx" and "relay" for host, 426 server reflexive, peer reflexive and relayed candidates, 427 respectively. The set of candidate types is extensible for the 428 future. 430 and : convey transport addresses related to the 431 candidate, useful for diagnostics and other purposes. 432 and MUST be present for server reflexive, peer 433 reflexive and relayed candidates. If a candidate is server or 434 peer reflexive, and is equal to the base for 435 that server or peer reflexive candidate. If the candidate is 436 relayed, and is equal to the mapped address 437 in the Allocate Response that provided the client with that 438 relayed candidate (see Appendix B.3 of ICE [RFC5245] for a 439 discussion of its purpose). If the candidate is a host candidate 440 and MUST be omitted. 442 : conveys the candidates connection type (active, 443 passive, or S-O) for TCP based candidates. This MUST be included 444 for candidates that have set to TCP and MUST NOT be 445 included for other transport types, including UDP, unless 446 explicitly specified for that transport protocol. 448 4.3. ICE Password and Username Transport Header Parameters 450 The ICE password and username for each agent needs to be transported 451 using RTSP. For that purpose new transport header parameters are 452 defined (see section 18.52 of [I-D.ietf-mmusic-rfc2326bis]. 454 There MUST be an "ICE-Password" and "ICE-ufrag" parameter for each 455 media stream. If two SETUP requests in the same RTSP session have 456 identical ICE-ufrag's, they MUST have identical ICE-Password's. The 457 ICE-ufrag and ICE-Password attributes MUST be chosen randomly at the 458 beginning of a session. The ICE-ufrag attribute MUST contain at 459 least 24 bits of randomness, and the ICE-Password attribute MUST 460 contain at least 128 bits of randomness. This means that the ICE- 461 ufrag attribute will be at least 4 characters long, and the ICE- 462 Password at least 22 characters long, since the grammar for these 463 attributes allows for 6 bits of randomness per character. The 464 attributes MAY be longer than 4 and 22 characters respectively, of 465 course, up to 256 characters. The upper limit allows for buffer 466 sizing in implementations. Its large upper limit allows for 467 increased amounts of randomness to be added over time. 469 The ABNF [RFC5234] for these parameters are: 471 trns-parameter =/ SEMI ice-password-par 472 trns-parameter =/ SEMI ice-ufrag-par 473 ice-password-par = "ICE-Password" EQUAL DQ password DQ 474 ice-ufrag-par = "ICE-ufrag" EQUAL DQ ufrag DQ 475 password = 476 ufrag = 477 EQUAL = 478 SEMI = 479 DQ = 481 4.4. ICE Feature Tag 483 A feature tag is defined for use in the RTSP capabilities mechanism 484 for ICE support of media transport using datagrams: "setup.ice-d-m". 485 This feature tag indicates that one supports all the mandatory 486 functions of this specification. It is applicable to all types of 487 RTSP agents; clients, servers and proxies. 489 The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the 490 "Supported" header in all SETUP requests that contain the "D-ICE" 491 lower layer transport. 493 4.5. Status Codes 495 ICE needs two new RTSP response codes to indicate correctly progress 496 and errors. 498 +---------+------------------------------------------+--------------+ 499 | Code | Reason | Method | 500 +---------+------------------------------------------+--------------+ 501 | 150 | Server still working on ICE connectivity | PLAY | 502 | | checks | | 503 | | | | 504 | 480 | ICE Connectivity check failure | PLAY, SETUP | 505 +---------+------------------------------------------+--------------+ 507 Table 1: New Status codes and their usage with RTSP methods 509 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 521 The 480 client error response code is used in cases when the request 522 can't be fulfilled due to a failure in the ICE processing, such as 523 all the connectivity checks have timed out. This error message can 524 appear either in response to a SETUP request to indicate that no 525 candidate pair can be constructed, or in response to a PLAY request 526 to indicate that the server's connectivity checks resulted in 527 failure. 529 4.6. New Reason for PLAY_NOTIFY 531 A new value used in the PLAY_NOTIFY methods Notify-Reason header is 532 defined: "ice-restart". This reason indicates that a ICE restart 533 needs to happen on the identified resource and session. 535 Notify-Reas-val =/ "ice-restart" 537 4.7. Server Side SDP Attribute for ICE Support 539 If the server supports the media NAT traversal for RTSP controlled 540 sessions as described in this RFC, then the Server SHOULD include the 541 "a=rtsp-ice-d-m" SDP attribute in any SDP (if used) describing 542 content served by the server. This is an session level only 543 attribute. 545 The ABNF [RFC5234] for the "rtsp-ice-d-m" attribute is: 547 rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m" 549 5. ICE-RTSP 551 This section discusses differences between the regular ICE usage 552 defined in [RFC5245] and ICE-RTSP. The reasons for the differences 553 relate to the clearer client/server roles that RTSP provides and how 554 the RTSP Session establishment signalling occurs within RTSP compared 555 to SIP/SDP Offer/Answer. 557 5.1. ICE Features Not Required 559 A number of ICE signalling features are not needed with RTSP and are 560 discussed below. 562 5.1.1. ICE-Lite 564 The ICE-Lite attribute shall not be used in the context of RTSP. The 565 ICE specification describes two implementations of ICE: Full and 566 Lite, where hosts that are not behind a NAT are allowed to implement 567 only Lite. For RTSP, the Lite implementation is insufficient because 568 it does not cause the media server to send a connectivity check, 569 which is used to protect against making the RTSP server a denial of 570 service tool. 572 5.1.2. ICE-Mismatch 574 The ice-mismatch parameter indicates that the offer arrived with a 575 default destination for a media component that didn't have a 576 corresponding candidate attribute. This is not needed for RTSP as 577 the ICE based lower layer transport specification either is supported 578 or another alternative transport is used. This is always explicitly 579 indicated in the SETUP request and response. 581 5.1.3. ICE Remote Candidate Transport Header Parameter 583 The Remote candidate attribute is not needed for RTSP for the 584 following reasons. Each SETUP results in an independent ICE 585 processing chain which either fails or results in nominating a single 586 candidate pair to usage. If a new SETUP request for the same media 587 is sent, this needs to use a new username fragment and password to 588 avoid any race conditions or uncertainty about which round of 589 processing the STUN requests relate to. 591 5.2. High-Reachability Configuration 593 ICE-RTSP contains a high-reachability configuration when the RTSP 594 Servers are not behind NATs. Please note that "not behind NATs" may 595 apply in some special cases also for RTSP Servers behind NATs given 596 that they are in an address space that has reachability for all the 597 RTSP clients intended to able to reach the server. The high- 598 reachability configuration is similar to ICE-Lite as it allows for 599 some reduction in the server's burden. However, due to the need to 600 still verify that the client is actually present, the server must 601 also initiate binding requests and await binding responses. The 602 reduction for the high-reachability configuration of ICE-RTSP is that 603 they don't need to initiate their own checks, and instead rely on 604 triggered checks for verification. This also removes a denial of 605 service threat where a RTSP SETUP request will trigger large amount 606 of STUN connectivity checks towards provided candidate addresses. 608 6. Detailed Solution 610 This section describes in detail how the interaction and flow of ICE 611 works with RTSP messages. 613 6.1. Session description and RTSP DESCRIBE (optional) 615 The RTSP server should indicate it has support for ICE by sending the 616 "a=rtsp-ice-d-m" SDP attribute in the response to the RTSP DESCRIBE 617 message if SDP is used. This allows RTSP clients to only send the 618 new ICE exchanges with servers that support ICE thereby limiting the 619 overhead on current non-ICE supporting RTSP servers. When not using 620 RTSP DESCRIBE it is still RECOMMENDED to use the SDP attribute for 621 the session description. 623 A Client can also use the DESCRIBE request to determine explicitly if 624 both server and any proxies support ICE. The client includes the 625 "Supported" header with its supported feature tags, including 626 "setup.ice-d-m". Any proxy upon seeing the "Supported" header will 627 include the "Proxy-Supported" header with the feature tags it 628 supports. The server will echo back the "Proxy-Supported" header and 629 its own version of the Supported header so enabling a client to 630 determine if all involved parties support ICE or not. Note that even 631 if a proxy is present in the chain that doesn't indicate support for 632 ICE, it may still work. 634 For example: 635 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 636 CSeq: 312 637 User-Agent: PhonyClient 1.2 638 Accept: application/sdp, application/example 639 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 641 S->C: RTSP/2.0 200 OK 642 CSeq: 312 643 Date: 23 Jan 1997 15:35:06 GMT 644 Server: PhonyServer 1.1 645 Content-Type: application/sdp 646 Content-Length: 367 647 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 649 v=0 650 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 651 s=SDP Seminar 652 i=A Seminar on the session description protocol 653 u=http://www.example.com/lectures/sdp.ps 654 e=seminar@example.com (Seminar Management) 655 t=2873397496 2873404696 656 a=recvonly 657 a=rtsp-ice-d-m 658 a=control: * 659 m=audio 3456 RTP/AVP 0 660 a=control: /audio 661 m=video 2232 RTP/AVP 31 662 a=control: /video 664 6.2. Setting up the Media Streams 666 The RTSP client reviews the session description returned, for example 667 by an RTSP DESCRIBE message, to determine what media resources need 668 to be setup. For each of these media streams where the transport 669 protocol supports ICE connectivity checks, the client SHALL gather 670 candidate addresses for UDP transport as described in section 4.1.1 671 in ICE [RFC5245] according to standard ICE rather than the ICE-Lite 672 implementation and according to section 5 of ICE TCP [RFC6544] for 673 TCP based candidates. 675 6.3. RTSP SETUP Request 677 The RTSP client will then send at least one SETUP request per media 678 stream to establish the media streams required for the desired 679 session. For each media stream where it desires to use ICE it will 680 include a transport specification with "D-ICE" as the lower layer, 681 and each media stream SHALL have its own unique combination of ICE 682 candidates and ICE-ufrag. This transport specification SHOULD be 683 placed first in the list to give it highest priority. It is 684 RECOMMENDED that additional transport specifications are provided as 685 a fallback in case of non-ICE supporting proxies. The RTSP client 686 will be initiating and thus the controlling party in the ICE 687 processing. For example (Note that some lines are broken in 688 contradiction with the defined syntax due to space restrictions in 689 the documenting format): 691 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 692 CSeq: 313 693 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=8hhY; 694 ICE-Password=asd88fgpdd777uzjYhagZg; candidates=" 695 1 1 UDP 2130706431 10.0.1.17 8998 typ host; 696 2 1 UDP 1694498815 192.0.2.3 45664 typ srflx 697 raddr 10.0.1.17 rport 8998"; RTCP-mux, 698 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 699 RTP/AVP/TCP;unicast;interleaved=0-1 700 Accept-Ranges: NPT, UTC 701 User-Agent: PhonyClient/1.2 702 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 704 6.4. Gathering Candidates 706 Upon receiving a SETUP request the server can determine what media 707 resource should be delivered and which transport alternatives that 708 the client supports. If one based on D-ICE is on the list of 709 supported transports and preferred among the supported, the below 710 applies. 712 The transport specification will provide which media protocol is to 713 be used and based on this and the clients candidates, the server 714 determines the protocol and if it supports ICE with that protocol. 715 The server shall then gather its UDP candidates according to section 716 4.1.1 in ICE [RFC5245] and any TCP based ones according to section 5 717 of ICE TCP [RFC6544]. 719 Servers that have an address that is generally reachable by any 720 client within the address scope the server intends to serve MAY be 721 specially configured (high-reachability configuration). This special 722 configuration has the goal of reducing the server side candidate to 723 preferably a single one per (address family, media stream, media 724 component) tuple. Instead of gathering all possible addresses 725 including relayed and server reflexive addresses, the server uses a 726 single address per address family that it knows it should be 727 reachable by a client behind one or more NATs. The reason for this 728 special configuration is twofold: Firstly it reduces the load on the 729 server in address gathering and in ICE processing during the 730 connectivity checks. Secondly it will reduce the number of 731 permutations for candidate pairs significantly thus potentially 732 speeding up the conclusion of the ICE processing. Note however that 733 using this option on a server that doesn't fulfill the requirement of 734 being reachable is counter-productive and it is important that this 735 is correctly configured. 737 The above general consideration for servers applies also for TCP 738 based candidates. A general implementation should support several 739 candidate collection techniques and connection types. For TCP based 740 candidates a high-reachability configured server is recommended to 741 only offer Host candidates. In addition to passive connection types 742 the server can select to provide active or simultaneous-open (S-O) 743 connection types to match the client's candidates. 745 6.5. RTSP Server Response 747 The server determines if the SETUP request is successful from the 748 other perspectives and if so returns a 200 OK response; otherwise it 749 returns an error code. At that point the server, having selected a 750 transport specification using the "D-ICE" lower layer, will need to 751 include that transport specification in the response message. The 752 transport specification SHALL include the candidates gathered in 753 Section 6.4 in the "candidates" transport header parameter as well as 754 the server's username fragment and password. In the case that there 755 are no valid candidate pairs with the combination of the client and 756 server candidates, a 480 (ICE Processing Failed) error response SHALL 757 be returned which MUST include the server's candidates. The return 758 of a 480 error allows both the server and client to release their 759 candidates. 761 Example of a successful response to the request in Section 6.3. 763 S->C: RTSP/2.0 200 OK 764 CSeq: 313 765 Session: 12345678 766 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=MkQ3; 767 ICE-Password=pos12Dgp9FcAjpq82ppaF; candidates=" 768 1 1 UDP 2130706431 192.0.2.56 50234 typ host" 769 Accept-Ranges: NPT 770 Date: 23 Jan 1997 15:35:06 GMT 771 Server: PhonyServer 1.1 772 Supported: setup.ice-d-m, setup.rtp.rtcp.mux 774 6.6. Server to Client ICE Connectivity Checks 776 The server shall start the connectivity checks following the 777 procedures described in Section 5.7 and 5.8 of ICE [RFC5245] unless 778 it is configured to use the high-reachability option. If it is then 779 it MAY suppress its own checks until the servers checks are triggered 780 by the client's connectivity checks. 782 Please note that ICE [RFC5245] section 5.8 does specify that the 783 initiation of the checks are paced and new ones are only started 784 every Ta milliseconds. The motivation for this is documented in 785 Appendix B.1 of ICE [RFC5245] as for SIP/SDP all media streams within 786 an offer/answer dialog are running using the same queue. To ensure 787 the same behavior with RTSP, the server SHALL use a single pacer 788 queue for all media streams within each RTSP session. 790 The values for the pacing of STUN and TURN transactions Ta and RTO 791 can be configured but have the same minimum values defined in the ICE 792 specification. 794 When a connectivity check from the client reaches the server it will 795 result in a triggered check from the server as specified in 796 Section 7.2.1.4 of ICE [RFC5245]. This is why servers with a high 797 reachability address can wait until this triggered check to send out 798 any checks for itself so saving resources and mitigating the DDoS 799 potential. 801 6.7. Client to Server ICE Connectivity Check 803 The client receives the SETUP response and learns the candidate 804 addresses to use for the connectivity checks. The client SHALL 805 initiate its connectivity check, following the procedures in 806 Section 6 of ICE [RFC5245]. The pacing of STUN transactions 807 (Section B.1 of [RFC5245]) SHALL be used across all media streams 808 that are part of the same RTSP session. 810 Aggressive nomination SHOULD be used with RTSP during initial SETUP 811 for a resource. This doesn't have all the negative impact that it 812 has in offer/answer as media playing only starts after issuing a PLAY 813 request. Thus the issue with a change of the media path being used 814 for delivery can be avoided by not issuing a PLAY request while STUN 815 connectivity checks are still outstanding. Aggressive nomination can 816 result in multiple candidate pairs having their nominated flag set 817 but according to Section 8.1.1.2 of ICE [RFC5245] when the PLAY 818 request is sent the media will arrive on the pair with the highest 819 priority. Note, different media resources may still end up with 820 different foundations. 822 Note: The above does not change ICE and its handling of aggressive 823 nomination. Using aggressive nomination, a higher priority candidate 824 pair with an outstanding connectivity check message can move into the 825 Succeded state and will have its Nominated flag set. This happening 826 after another candidate pair for a given media stream having moved 827 into Succeded state. Thus moving the used pair to this higher 828 priority candidate pair. To avoid this occurring during actual media 829 transport, the RTSP client can add additional logic when the ICE 830 processing overall is completed to indicate if there is still higher 831 priority connectivity checks outstanding. If some check is still 832 outstanding, the implementation can choose to wait until some 833 additional timeout triggers or the outstanding checks completes 834 before progressing with a PLAY request. An alternative is to accept 835 the risk for a path change during media delivery and start playing 836 immediately. 838 RTSP clients that want to ensure that each media resource uses the 839 same path can use regular nomination where both the ICE processing 840 completion criteria can be controlled in addition to which media 841 streams being nominated for use. This does not affect the RTSP 842 server, as its role is the one of being controlled. 844 6.8. Client Connectivity Checks Complete 846 When the client has concluded all of its connectivity checks and has 847 nominated its desired candidate pair for a particular media stream, 848 it MAY issue a PLAY request for that stream. Note, that due to the 849 aggressive nomination, there is a risk that any outstanding check may 850 nominate another pair than what was already nominated. The candidate 851 pair with the highest priority will be used for the media. If the 852 client has locally determined that its checks have failed it may try 853 providing an extended set of candidates and update the server 854 candidate list by issuing a new SETUP request for the media stream. 856 If the client concluded its connectivity checks successfully and 857 therefore sent a PLAY request but the server cannot conclude 858 successfully, the server will respond with a 480 (ICE Processing 859 Failed). Upon receiving the 480 (ICE Processing Failed) response, 860 the client may send a new SETUP request assuming it has any new 861 information that can be included in the candidate list. If the 862 server is still performing the checks when receiving the PLAY request 863 it will respond with a 150 (ICE connectivity checks in progress) 864 response to indicate this. 866 6.9. Server Connectivity Checks Complete 868 When the RTSP server receives a PLAY request, it checks to see that 869 the connectivity checks have concluded successfully and only then 870 will it play the stream. If the PLAY request is for a particular 871 media stream, the server only needs to check that the connectivity 872 checks for that stream completed successfully. If the server has not 873 concluded its connectivity checks, the server indicates that by 874 sending the 150 (ICE connectivity checks in progress) 875 (Section 4.5.1). If there is a problem with the checks, then the 876 server sends a 480 response to indicate a failure of the checks. If 877 the checks are successful then the server sends a 200 OK response and 878 starts delivering media. 880 6.10. Freeing Candidates 882 Both server and client MAY free its non selected candidates as soon 883 as a 200 PLAY response has been issued/received and no outstanding 884 connectivity checks exist. 886 6.11. Steady State 888 The client and server SHALL use STUN to send keep-alive messages for 889 the nominated candidate pair(s) following the rules of Section 10 of 890 ICE [RFC5245]. This is important as normally RTSP play mode sessions 891 only contain traffic from the server to the client so the bindings in 892 the NAT need to be refreshed by the client to server traffic provided 893 by the STUN keep-alive. 895 6.12. Re-SETUP 897 A client that decides to change any parameters related to the media 898 stream setup will send a new SETUP request. In this new SETUP 899 request the client MAY include a new different username fragment and 900 password to use in the ICE processing. New username and password 901 SHALL cause the ICE processing to start from the beginning again, 902 i.e. an ICE restart (Section 9.1.1.1 of [RFC5245]). The client SHALL 903 in case of ICE restart gather candidates and include the candidates 904 in the transport specification for D-ICE. 906 ICE restarts may be triggered due to changes of clients or servers 907 attachment to the network, i.e. changes to the media streams 908 destination or source address or port. Most RTSP parameter changes 909 would not require an ICE restart, instead existing mechanisms in RTSP 910 for indicating from where in the RTP stream they apply should be 911 used. These include: Performing a pause prior to the parameter 912 change and then resume; or assuming the server supports using SETUP 913 during the PLAY state, using the RTP-Info header (Section 18.43 of 914 [I-D.ietf-mmusic-rfc2326bis]) to indicate from where in the media 915 stream the change shall apply. 917 The server SHALL support SETUP requests in PLAY state, as long as the 918 SETUP changes only the ICE parameters, which are: ICE-Password, ICE- 919 ufrag and the content of ICE candidates. 921 If the RTSP session is in playing state at the time of sending the 922 SETUP request requiring ICE restart, then the ICE connectivity checks 923 SHALL use Regular nomination. Any ongoing media delivery continues 924 on the previously nominated candidate pairs until the new pairs have 925 been nominated for the individual candidate. Once the nomination of 926 the new candidate pair has completed, all unused candidates may be 927 released. 929 6.13. Server Side Changes After Steady State 931 A Server may require an ICE restart because of server side load 932 balancing or a failure resulting in an IP address and a port number 933 change. It shall use the PLAY_NOTIFY method to inform the client 934 (Section 13.5 [I-D.ietf-mmusic-rfc2326bis]) with a new Notify-Reason 935 header: ice-restart. The server will identify if the change is for a 936 single media or for the complete session by including the 937 corresponding URI in the PLAY_NOTIFY request. 939 Upon receiving and responding to this PLAY_NOTIFY with ice-restart 940 reason the client SHALL gather new ICE candidates, send SETUP 941 requests for each media stream part of the session. The server 942 provides its candidates in the SETUP response the same way as for the 943 first time ICE processing. Both server and client shall provide new 944 ICE user names and passwords. The client MAY issue the SETUP request 945 while the session is in PLAYING state. 947 If the RTSP session is in PLAYING state when the client issues the 948 SETUP request, the client SHALL use regular nomination. If not the 949 client will use the same procedures as for when first creating the 950 session. 952 Note that keepalive messages on the previous set of candidate pairs 953 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 1024 RTSP allows for proxies which can be of two fundamental types 1025 depending on whether they relay and potentially cache the media or 1026 not. Their differing impact on the RTSP NAT traversal solution, 1027 including backwards compatibility, is explained below. 1029 7.1. Media Handling Proxies 1031 An RTSP proxy that relays or caches the media stream for a particular 1032 media session can be considered to split the media transport into two 1033 parts: A media transport between the server and the proxy according 1034 to the proxy's need, and delivery from the proxy to the client. This 1035 split means that the NAT traversal solution will need to be run on 1036 each individual media leg according to need. 1038 It is RECOMMENDED that any media handling proxy support the media NAT 1039 traversal defined within this specification. This is for two 1040 reasons: Firstly to enable clients to perform NAT traversal for the 1041 media between the proxy and itself, and secondly to allow the proxy 1042 to be topology independent to support performing NAT traversal (to 1043 the server) for non-NAT traversal capable clients present in the same 1044 address domain as the proxy. 1046 For a proxy to support the media NAT traversal defined in this 1047 specification a proxy will need to implement the solution fully and 1048 be able to act as both a controlling and a controlled ICE peer. The 1049 proxy also SHALL include the "setup.ice-d-m" feature tag in any 1050 applicable capability negotiation headers, such as "Proxy-Supported." 1052 7.2. Signalling Only Proxies 1054 A signalling only proxy handles only the RTSP signalling and does not 1055 have the media relayed through proxy functions. This type of proxy 1056 is not likely to work unless the media NAT traversal solution is in 1057 place between the client and the server, because the Denial of 1058 Service (DoS) protection measures, as discussed in Section 21.2.1 of 1059 RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis], usually prevent media delivery 1060 to other addresses other than from where the RTSP signalling arrives 1061 at the server. 1063 The solution for the Signalling Only proxy is that it must forward 1064 the RTSP SETUP requests including any transport specification with 1065 the "D-ICE" lower layer and the related transport parameters. A 1066 proxy supporting this functionality SHOULD indicate its capability by 1067 always including the "setup.ice-d-m" feature tag in the "Proxy- 1068 Supported" header. 1070 7.3. Non-supporting Proxies 1072 A media handling proxy that doesn't support the ICE media NAT 1073 traversal specified here is assumed to remove the transport 1074 specification and use any of the lower prioritized transport 1075 specifications if provided by the requester. The specification of 1076 such a non ICE transport enables the negotiation to complete, 1077 although with a less preferred method since a NAT between the proxy 1078 and the client may result in failure of the media path. 1080 A non-media handling proxy is expected to ignore and simply forward 1081 all unknown transport specifications, however, this can only be 1082 guaranteed for proxies following the published RTSP 2.0 specification 1083 [I-D.ietf-mmusic-rfc2326bis]. 1085 Unfortunately the usage of the "setup.ice-d-m" feature tag in the 1086 Proxy-Require will have contradicting results. For a non ICE 1087 supporting but media handling proxy, the inclusion of the feature tag 1088 will result in aborting the setup and indicating that it isn't 1089 supported, which is desirable if you want to provide other fallbacks 1090 or other transport configurations to handle the situation. For non- 1091 supporting non-media handling proxies the result will also result in 1092 aborting the setup, however, setup might have worked if the proxy- 1093 require tag wasn't present. This variance in results is the reason 1094 we don't recommend the usage of the Proxy-Require header. Instead we 1095 recommend the usage of the Supported header to force proxies to 1096 include the feature tags they support in the Proxy-Supported header, 1097 which will provide a positive indication when all proxies in the 1098 chain between the client and server support the functionality. In 1099 case one or more proxy does not explicitly indicate support, it will 1100 remove the feature tag "setup.ice-d-m". If that proxy is a non-media 1101 handling one and the client would despite the lack of explicit 1102 indication would attempt a setup using D-ICE transport, it is likely 1103 to work. Thus giving the client explicit indication of support in 1104 the SETUP response that the proxy chain supports at least passthrough 1105 of this media. Where the Require and Support RTSP headers failed to 1106 provide that information. 1108 8. RTP and RTCP Multiplexing 1110 "Multiplexing RTP Data and Control Packets on a Single Port" 1111 [RFC5761] specifies how and when RTP and RTCP can be multiplexed on 1112 the same port. This multiplexing SHALL be combined with ICE as it 1113 makes RTP and RTCP need only a single component per media stream 1114 instead of two, so reducing the load on the connectivity checks. For 1115 details on how to negotiate RTP and RTCP multiplexing, see Appendix C 1116 of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. 1118 Multiplexing RTP and RTCP has the benefit that it avoids the need for 1119 handling two components per media stream when RTP is used as the 1120 media transport protocol. This eliminates at least one STUN check 1121 per media stream and will also reduce the time needed to complete the 1122 ICE processing by at least the time it takes to pace out the 1123 additional STUN checks of up to one complete round trip time for a 1124 single media stream. In addition to the protocol performance 1125 improvements, the server and client side complexities are reduced as 1126 multiplexing halves the total number of STUN instances and holding 1127 the associated state. Multiplexing will also reduce the combinations 1128 and length of the list of possible candidates. 1130 The implementation of RTP and RTCP multiplexing is additional work 1131 required for this solution. However, when implementing the ICE 1132 solution a server or client will need to implement a de-multiplexer 1133 between the STUN, and RTP or RTCP packets below the RTP/RTCP 1134 implementation anyway, so the additional work of one new 1135 demultiplexing point directly connected to the STUN and RTP/RTCP 1136 seems small relative to the benefits provided. 1138 Due to the above mentioned benefits, RTSP servers and clients that 1139 support "D-ICE" lower layer transport in combination with RTP SHALL 1140 also implement RTP and RTCP multiplexing as specified in this section 1141 and [RFC5761]. 1143 9. Fallback and Using Partial ICE functionality to improve NAT/Firewall 1144 traversal 1146 The need for fallback from ICE in RTSP should be less than for SIP 1147 using ICE in SDP offer/answer where a default destination candidate 1148 is very important to enable interworking with non-ICE capable 1149 endpoints. In RTSP, capability determination for ICE can happen 1150 prior to the RTSP SETUP request. This means a client should normally 1151 not need to include fallback alternatives when offering ICE, as the 1152 capability for ICE will already be determined. However, as described 1153 in this section, clients may wish to use part of the ICE 1154 functionality to improve NAT/Firewall traversal where the server is 1155 non-ICE capable. 1157 Section 4.1.4 of the ICE [RFC5245] specification does recommend that 1158 the default destination, i.e. what is used as fallback if the peer 1159 isn't ICE capable, is a candidate of relayed type to maximize the 1160 likelihood of successful transport of media. This is based on the 1161 peer in SIP SDP offer/answer is almost as likely as the RTSP client 1162 to be behind a NAT. For RTSP the deployment of servers are much more 1163 heavily weighted towards deployment with public reachability. In 1164 fact since publicly reachable servers behind NAT either need to 1165 support ICE or have static configurations that allow traversal, one 1166 can assume that the server will have a public address or support ICE. 1167 Thus, the selection of the default destination address for RTSP can 1168 be differently prioritized. 1170 As an ICE enabled client behind a NAT needs to be configured with a 1171 STUN server address to be able to gather candidates successfully, 1172 this can be used to derive a server reflexive candidate for the 1173 clients port. How useful this is for a NAT'ed RTSP client as a 1174 default candidate depends on the properties of the NAT. As long as 1175 the NAT use an address independent mapping, then using a STUN derived 1176 reflexive candidate is likely to be successfully. This is however 1177 brittle in several ways. First, if the NATs behavior is attempted to 1178 be determined using STUN as described in [RFC3489], the determined 1179 behavior might not be representative of the behavior encountered in 1180 another mapping. Secondly, filter state towards the ports used by 1181 the server needs to be established. This requires that the server 1182 actually includes both address and ports in its response to the SETUP 1183 request. Thirdly messages need to be sent to these ports for keep- 1184 alive at a regular interval. How a server reacts to such unsolicited 1185 traffic is unknown. This brittleness may be accepted in fallback due 1186 to lack of support on the server side. 1188 To maximize the likelihood that an RTSP client is capable of 1189 receiving media a relay based address should be chosen as the default 1190 fallback address. However, for RTSP clients lacking a relay server, 1191 like a TURN server, or where usage of such a server has significant 1192 cost associated with it the usage of a STUN derived server reflexive 1193 address as client default has a reasonable likelihood of functioning 1194 and may be used as an alternative. 1196 Fallback addresses need to be provided in their own transport 1197 specification using a specifier that does not include the "D-ICE" 1198 lower layer transport. Instead the selected protocol, e.g. UDP needs 1199 to be explicitly or implicitly indicated. Secondly the selected 1200 default candidate needs to be included in the SETUP request. If this 1201 candidate is server reflexive or relayed the aspect of keep-alive 1202 needs to be ensured. 1204 10. IANA Considerations 1206 This document requests registration in a number of registries, both 1207 for RTSP and SDP. For all the below registrations the contact person 1208 on behalf of the IETF WG MMUSIC is Magnus Westerlund; Postal address: 1209 Farogatan 6, 164 80 Stockholm, Sweden; Email: 1210 magnus.westerlund@ericsson.com. 1212 RFC-Editor Note: Please replace any occurrence of RFCXXXX in the 1213 below with the RFC number this specification is assigned. 1215 10.1. RTSP Feature Tags 1217 This document request that one RTSP 2.0 feature tag is registered in 1218 the "RTSP 2.0 Feature-tags" registry: 1220 setup.ice-d-m A feature tag representing the support of the ICE 1221 based establishment of datagram media transport that is capable of 1222 transport establishment through NAT and Firewalls. This feature 1223 tag applies to clients, servers and proxies and indicates that 1224 support of all the mandatory functions of this specification. 1226 10.2. Transport Protocol Specifications 1228 This document needs to register a number of transport protocol 1229 combinations in the RTSP 2.0 "Transport Protocol Specifications" 1230 registry. 1232 "RTP/AVP/D-ICE" RTP using the AVP profile over an ICE established 1233 datagram flow. 1235 "RTP/AVPF/D-ICE" RTP using the AVPF profile over an ICE established 1236 datagram flow. 1238 "RTP/SAVP/D-ICE" RTP using the SAVP profile over an ICE established 1239 datagram flow. 1241 "RTP/SAVPF/D-ICE" RTP using the SAVPF profile over an ICE 1242 established datagram flow. 1244 10.3. RTSP Transport Parameters 1246 This document requests that 3 transport parameters are registered in 1247 the RTSP 2.0's "Transport Parameters" registry: 1249 "candidates": Listing the properties of one or more ICE candidate. 1250 See Section Section 4.2 of RFCXXXX. 1252 "ICE-Password": The ICE password used to authenticate the STUN 1253 binding request in the ICE connectivity checks. See 1254 Section Section 4.3 of RFCXXXX. 1256 "ICE-ufrag": The ICE username fragment used to authenticate the STUN 1257 binding requests in the ICE connectivity checks. See 1258 Section Section 4.3 of RFCXXXX. 1260 10.4. RTSP Status Codes 1262 This document requests that 2 assignments are done in the "RTSP 2.0 1263 Status Codes" registry. The values are: 1265 150: The 150 response code indicates that ICE connectivity checks 1266 are still in progress and haven't concluded. This response SHALL 1267 be sent within 200 milliseconds of receiving a PLAY request that 1268 currently can't be fulfilled because ICE connectivity checks are 1269 still running. Subsequently, every 3 seconds after the previous 1270 sent one, a 150 reply shall be sent until the ICE connectivity 1271 checks conclude either successfully or in failure, and a final 1272 response for the request can be provided. 1274 480: The 480 client error response code is used in cases when the 1275 request can't be fulfilled due to a failure in the ICE processing, 1276 such as that all the connectivity checks have timed out. This 1277 error message can appear either in response to a SETUP request to 1278 indicate that no candidate pair can be constructed or to a PLAY 1279 request that the server's connectivity checks resulted in failure. 1281 10.5. Notify-Reason value 1283 This document requests that one assignment is done in the RTSP 2.0 1284 Notify-Reason header value registry. The defined value is: 1286 ice-restart: Server notifying the client about the need for an ICE 1287 restart. See section Section 4.6. 1289 10.6. SDP Attribute 1291 The registration of one SDP attribute is requested: 1293 SDP Attribute ("att-field"): 1295 Attribute name: rtsp-ice-d-m 1296 Long form: ICE for RTSP datagram media NAT traversal 1297 Type of attribute: Session level only 1298 Subject to charset: No 1299 Purpose: RFC XXXX, Section 4.7 1300 Values: No values defined. 1301 Contact: Magnus Westerlund 1302 E-mail: magnus.westerlund@ericsson.com 1303 phone: +46 10 714 82 87 1305 11. Security Considerations 1307 ICE [RFC5245] and ICE TCP [RFC6544] provide an extensive discussion 1308 on security considerations which apply here as well. 1310 11.1. ICE and RTSP 1312 A long-standing risk with transmitting a packet stream over UDP is 1313 that the host may not be interested in receiving the stream. On 1314 today's Internet many hosts are behind NATs or operate host firewalls 1315 which do not respond to unsolicited packets with an ICMP port 1316 unreachable error. Thus, an attacker can construct RTSP SETUP 1317 requests with a victim's IP address and cause a flood of media 1318 packets to be sent to a victim. The addition of ICE, as described in 1319 this document, provides protection from the attack described above. 1320 By performing the ICE connectivity check, the media server receives 1321 confirmation that the RTSP client wants the media. While this 1322 protection could also be implemented by requiring the IP addresses in 1323 the SDP match the IP address of the RTSP signaling packet, such a 1324 mechanism does not protect other hosts with the same IP address (such 1325 as behind the same NAT), and such a mechanism would prohibit 1326 separating the RTSP controller from the media play-out device (e.g., 1327 an IP-enabled remote control and an IP-enabled television); it also 1328 forces RTSP proxies to relay the media streams through them, even if 1329 they would otherwise be only signalling proxies. 1331 To protect against the attacks in ICE based on signalling information 1332 RTSP signalling should be protected using TLS to prevent 1333 eavesdropping and modification of information. 1335 The STUN amplification attack described in Section 18.5.2 in ICE 1336 [RFC5245] needs consideration. Servers that are able to run 1337 according to the high-reachability option have good mitigation 1338 against this attack as they only send connectivity checks towards an 1339 address and port pair they have received an incoming connectivity 1340 check from. This means an attacker requires both the capability to 1341 spoof source addresses and to signal the RTSP server a set of ICE 1342 candidates. Independently an ICE agent needs to implement the 1343 mitigation to reduce the volume of the amplification attack as 1344 described in the ICE specification. 1346 12. Acknowledgements 1348 The authors would like to thank Remi Denis-Courmont for suggesting 1349 the method of integrating ICE in RTSP signalling, Dan Wing for help 1350 with the security section and numerous other issues, Ari Keranen for 1351 review of the document and its ICE details. 1353 13. References 1355 13.1. Normative References 1357 [I-D.ietf-mmusic-rfc2326bis] 1358 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1359 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1360 (RTSP)", draft-ietf-mmusic-rfc2326bis-38 (work in 1361 progress), October 2013. 1363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1364 Requirement Levels", BCP 14, RFC 2119, March 1997. 1366 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1367 Description Protocol", RFC 4566, July 2006. 1369 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1370 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1372 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1373 (ICE): A Protocol for Network Address Translator (NAT) 1374 Traversal for Offer/Answer Protocols", RFC 5245, April 1375 2010. 1377 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1378 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1379 October 2008. 1381 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1382 Control Packets on a Single Port", RFC 5761, April 2010. 1384 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 1385 "TCP Candidates with Interactive Connectivity 1386 Establishment (ICE)", RFC 6544, March 2012. 1388 13.2. Informative References 1390 [I-D.ietf-mmusic-rtsp-nat-evaluation] 1391 Westerlund, M. and T. Zeng, "The Evaluation of Different 1392 Network Address Translator (NAT) Traversal Techniques for 1393 Media Controlled by Real-time Streaming Protocol (RTSP)", 1394 draft-ietf-mmusic-rtsp-nat-evaluation-10 (work in 1395 progress), Nov 2013. 1397 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1398 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1400 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1401 Address Translator (Traditional NAT)", RFC 3022, January 1402 2001. 1404 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1405 A., Peterson, J., Sparks, R., Handley, M., and E. 1406 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1407 June 2002. 1409 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1410 with Session Description Protocol (SDP)", RFC 3264, June 1411 2002. 1413 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1414 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1415 Through Network Address Translators (NATs)", RFC 3489, 1416 March 2003. 1418 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1419 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1421 Authors' Addresses 1423 Jeff Goldberg 1424 Cisco 1425 11 New Square, Bedfont Lakes 1426 Feltham,, Middx TW14 8HA 1427 United Kingdom 1429 Phone: +44 20 8824 1000 1430 Email: jgoldber@cisco.com 1431 Magnus Westerlund 1432 Ericsson 1433 Farogatan 6 1434 Stockholm SE-164 80 1435 Sweden 1437 Phone: +46 8 719 0000 1438 Email: magnus.westerlund@ericsson.com 1440 Thomas Zeng 1441 Nextwave Wireless, Inc. 1442 12670 High Bluff Drive 1443 San Diego, CA 92130 1444 USA 1446 Phone: +1 858 480 3100 1447 Email: thomas.zeng@gmail.com