idnits 2.17.1 draft-ietf-mmusic-rtsp-nat-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1090. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1101. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1108. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1114. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2008) is 5904 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 (-18) exists of draft-ietf-behave-rfc3489bis-15 == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-17 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-rtsp-nat-evaluation-00 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Goldberg 3 Internet-Draft Cisco 4 Intended status: Standards Track M. Westerlund 5 Expires: August 28, 2008 Ericsson 6 T. Zeng 7 Nextwave Wireless, Inc. 8 February 25, 2008 10 An Network Address Translator (NAT) Traversal mechanism for media 11 controlled by Real-Time Streaming Protocol (RTSP) 12 draft-ietf-mmusic-rtsp-nat-06 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 28, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document defines a solution for Network Address Translation 46 (NAT) traversal for datagram based media streams setup and controlled 47 with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses 48 Interactive Connectivity Establishment (ICE) adapted to use RTSP as a 49 signalling channel, defining the necessary extra RTSP extensions and 50 procedures. 52 Requirements Language 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [RFC2119]. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 62 3. RTSP Extensions . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. ICE Transport Lower Layer . . . . . . . . . . . . . . . . 6 64 3.2. ICE Candidate Transport Header Parameter . . . . . . . . . 7 65 3.3. ICE Password and Username Transport Header Parameters . . 10 66 3.4. ICE Feature Tag . . . . . . . . . . . . . . . . . . . . . 10 67 3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 11 68 3.5.1. 150 ICE connectivity checks in progress . . . . . . . 11 69 3.5.2. 480 ICE Processing Failed . . . . . . . . . . . . . . 11 70 3.6. Server Side SDP Attribute for ICE Support . . . . . . . . 11 71 3.7. ICE Features Not Required in RTSP . . . . . . . . . . . . 12 72 3.7.1. ICE-Lite . . . . . . . . . . . . . . . . . . . . . . . 12 73 3.7.2. ICE-Mismatch . . . . . . . . . . . . . . . . . . . . . 12 74 3.7.3. ICE Remote Candidate Transport Header Parameter . . . 12 75 4. Detailed Solution . . . . . . . . . . . . . . . . . . . . . . 12 76 4.1. Session description and RTSP DESCRIBE (optional) . . . . . 13 77 4.2. Setting up the Media Resources . . . . . . . . . . . . . . 14 78 4.3. RTSP SETUP Request . . . . . . . . . . . . . . . . . . . . 14 79 4.4. Gathering Candidates . . . . . . . . . . . . . . . . . . . 15 80 4.5. RTSP Server Response . . . . . . . . . . . . . . . . . . . 16 81 4.6. Server to Client ICE Connectivity Checks . . . . . . . . . 16 82 4.7. Client to Server ICE Connectivity Check . . . . . . . . . 17 83 4.8. Client Connectivity Checks Complete . . . . . . . . . . . 17 84 4.9. Server Connectivity Checks Complete . . . . . . . . . . . 17 85 4.10. Releasing Candidates . . . . . . . . . . . . . . . . . . . 17 86 4.11. Steady State . . . . . . . . . . . . . . . . . . . . . . . 18 87 4.12. re-SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 5. ICE and Proxies . . . . . . . . . . . . . . . . . . . . . . . 18 89 5.1. Media Handling Proxies . . . . . . . . . . . . . . . . . . 18 90 5.2. Signalling Only Proxies . . . . . . . . . . . . . . . . . 19 91 5.3. Non-supporting Proxies . . . . . . . . . . . . . . . . . . 19 92 6. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . . . 20 93 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 95 8.1. RTSP Feature Tags . . . . . . . . . . . . . . . . . . . . 21 96 8.2. Transport Protocol Specifications . . . . . . . . . . . . 21 97 8.3. RTSP Transport Parameters . . . . . . . . . . . . . . . . 21 98 8.4. RTSP Status Codes . . . . . . . . . . . . . . . . . . . . 22 99 8.5. SDP Attribute . . . . . . . . . . . . . . . . . . . . . . 22 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 101 9.1. ICE and RTSP . . . . . . . . . . . . . . . . . . . . . . . 22 102 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 103 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 105 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 107 Intellectual Property and Copyright Statements . . . . . . . . . . 26 109 1. Introduction 111 Real-time Streaming Protocol (RTSP) 112 [RFC2326][I-D.ietf-mmusic-rfc2326bis] is a protocol used to setup and 113 control one or more media streams delivering media to receivers. It 114 is RTSP's functionality of setting up media streams that get into 115 serious issues with Network Address Translators (NAT) [RFC3022]. 116 Commonly the media will be totally blocked by the NAT unless extra 117 provisions are taken by the protocol. There is a clear and present 118 need for NAT traversal mechanism for the media setup using RTSP. 120 RTSP 1.0 [RFC2326] has suffered from the lack of a standardized NAT 121 traversal mechanism for a long time, however due to quality of the 122 RTSP 1.0 specification, the work has had to wait on the recently 123 defined RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. RTSP 2.0 is similar 124 to RTSP 1.0 in many respects but significantly for this work, it 125 contains a well defined extension mechanism so allowing a NAT 126 traversal extension to be defined that is backwards compatible with 127 RTSP 2.0 peers not supporting the extension. This extension 128 mechanism was not possible in RTSP 1.0 as it would break RTSP 1.0 129 syntax so causing compatibility issues. 131 There have been a number of suggested ways of resolving the NAT- 132 traversal of media for RTSP of which a large number are already used 133 in implementations. The evaluation of these NAT traversal solutions 134 in[I-D.ietf-mmusic-rtsp-nat-evaluation] has shown that there are many 135 issues to consider, so after extensive evaluation, we selected a 136 mechanism based on Interactive Connectivity Establishment (ICE). 137 This was mainly two reasons: Firstly the mechanism supports RTSP 138 servers behind NATs and secondly the mechanism solves the security 139 threat that uses RTSP servers as Distributed Denial of Service (DDoS) 140 attack tools. 142 The NAT problem for RTSP signalling traffic itself is beyond the 143 scope of this document and is left for future study should the need 144 arise, because it is a less prevalent problem than the NAT problem 145 for RTSP media streams. 147 2. Solution Overview 149 This overview assumes that the reader has some familiarity with how 150 ICE [I-D.ietf-mmusic-ice] works, as it primarily points out how the 151 different ICE steps are accomplished in RTSP. 153 1. RTSP server can indicate it has support for ICE via an SDP 154 [RFC4566] attribute in, for example, the SDP returned in RTSP 155 DESCRIBE message. This allows RTSP clients to only send the new 156 ICE interchanges with servers that support ICE so as to limit 157 the overhead on current non-ICE supporting RTSP servers. If 158 RTSP DESCRIBE is used the normal capability determination 159 mechanism can be used, i.e. "Supported" header and the defined 160 feature tag. 162 2. RTSP client reviews the session description returned, for 163 example by an RTSP DESCRIBE message, to determine what media 164 resources that need to be setup. For each of these media 165 resources where the transport protocol supports Session 166 Traversal Utilities for (NAT) (STUN) 167 [I-D.ietf-behave-rfc3489bis] based connectivity checks, the 168 client gathers candidate addresses. See section 4.1.1 in 169 [I-D.ietf-mmusic-ice]. The client also installs the STUN 170 servers on each of the local candidates. 172 3. RTSP client sends a SETUP request with both a transport 173 specification with a lower layer indicating ICE and a new RTSP 174 Transport header parameter listing the ICE candidates for each 175 media resource. RTSP proxies in non-ICE transport 176 specifications should be treated at lower priority than those 177 transport specifications supporting ICE. 179 4. After receiving the list of candidates from a client, the RTSP 180 server gathers its own candidates. If the server has a public 181 IP address then a single candidate per address family (e.g. 182 IPv4 and IPv6) can be included to reduce the number of 183 combinations and speed up the completion. 185 5. The server sets up the media and if successful responds to the 186 SETUP request with a 200 OK response. In that response the 187 server selects the transport specification using ICE and 188 includes its candidates in the server candidate parameter. 190 6. If the server is behind a NAT then it starts the connectivity 191 checks following the procedures described in Section 5.7 and 5.8 192 of [I-D.ietf-mmusic-ice]. If the server has a public IP address 193 with a single candidate then it can refrain from server 194 initiated connectivity checks and rely on triggered checks. 196 7. The client receives the SETUP response and learns the candidate 197 address to use for the connectivity checks, and then initiates 198 its connectivity check, following the procedures in Section 6 of 199 [I-D.ietf-mmusic-ice]. 201 8. When a connectivity check from the client reaches the server it 202 will result in a triggered check from the server. This is why 203 servers with a public IP address can wait until this triggered 204 check to send out any checks for itself so saving resources and 205 mitigating the DDoS potential from server connectivity checks. 207 9. When the client has concluded its connectivity checks and has 208 corresponding received the server connectivity checks on the 209 promoted candidates for all components of all media streams, it 210 can issue a PLAY request. If the connectivity checks have not 211 concluded successfully then the client may send a new SETUP 212 request assuming it has any new information or believes the 213 server may be able to do more that can result in successful 214 checks. 216 10. When the RTSP servers receives a PLAY request it checks to see 217 the connectivity checks has concluded successfully and only then 218 can play the stream. If there is a problem with the checks then 219 the server sends to the client either a 150 (ICE connectivity 220 checks in progress) response to show that it is still working on 221 the connectivity checks or a 480 (ICE Processing Failed) 222 response to indicate a failure of the checks. If the checks are 223 successful then the server sends a 200 OK response and starts 224 delivering media. 226 The client may release unused candidates when the ICE processing has 227 concluded and a single candidate per component has been promoted. 229 The client shall continue to use STUN to send keep-alive for the used 230 bindings. This is important as often RTSP media sessions only 231 contain media traffic from the server to the client so the bindings 232 in the NAT needs to be refreshed by the client to server traffic 233 provided by the STUN keep-alive. 235 3. RTSP Extensions 237 This section defines the necessary RTSP extensions for performing ICE 238 with RTSP. Note that these extensions are based on the SDP 239 attributes in the ICE specification unless expressly indicated. 241 3.1. ICE Transport Lower Layer 243 A new lower layer "D-ICE" for transport specifications is defined. 244 This lower layer is datagram clean except that the protocol used must 245 be demultiplexiable with STUN messages (see STUN 246 [I-D.ietf-behave-rfc3489bis]). With datagram clean we mean that it 247 must be capable of describing the length of the datagram, transport 248 that datagram (as a binary chunk of data) and provide it at the 249 receiving side as one single item. This lower layer can be any 250 transport type defined for ICE which does provide datagram transport 251 capabilities. Though only UDP is defined at present, however TCP 252 with framing may be specified and used in the future. 254 This lower layer uses ICE to determine which of the different 255 candidates shall be used and then when the ICE processing has 256 concluded, uses the selected candidate to transport the datagrams 257 over this transport. 259 This lower layer transport can be combined with all upper layer media 260 transport protocols that are possible to demultiplex with STUN and 261 which use datagrams. This specification defines the following 262 combinations: 264 o RTP/AVP/D-ICE 266 o RTP/AVPF/D-ICE 268 o RTP/SAVP/D-ICE 270 o RTP/SAVPF/D-ICE 272 This list can easily be extended with more transport specifications 273 after having performed the evaluation that they are compatible with 274 D-ICE as lower layer. 276 The lower-layer "D-ICE" has the following rules for the inclusion of 277 transport parameters: 279 unicast: As ICE only supports unicast operations, thus it is 280 REQUIRED that one include the unicast indicator parameter, see 281 section 16.46 in [I-D.ietf-mmusic-rfc2326bis]. 283 candidates: The "candidates" parameter SHALL be included as this 284 specify at least one candidate to try to establish a working 285 transport path with. 287 dest_addr: This parameter SHALL NOT be included as "candidates" is 288 used instead to provide the necessary address information. 290 ICE-Password: This parameter SHALL be included. 292 ICE-Userfrag: This parameter SHALL be included. 294 3.2. ICE Candidate Transport Header Parameter 296 This section defines a new RTSP transport parameter for carrying ICE 297 candidates related to the transport specification they appear within, 298 which may then be validated with an end-to-end connectivity check 299 using STUN [I-D.ietf-behave-rfc3489bis]. Transport parameters may 300 only occur once in each transport specification. For transport 301 specification using "D-ICE" as lower layer, this parameter needs to 302 be present. The parameter can contain one or more ICE candidates. 303 In the SETUP response there is only a single transport specification, 304 and if that uses the "D-ICE" lower layer this parameter also needs to 305 present including the server side candidates. 307 tr-parameter =/ SEMI ice-trn-par 308 ice-trn-par = "candidates" EQUAL DQ SWS ice-candidate 309 *(SEMI ice-candidate) SWS DQ 310 ice-candidate = foundation SP 311 component-id SP 312 transport SP 313 priority SP 314 connection-address SP 315 port SP 316 cand-type 317 [SP rel-addr] 318 [SP rel-port] 319 *(SP extension-att-name SP extension-att-value) 321 foundation = 322 component-id = 323 transport = 324 transport-extension = 325 priority = 326 cand-type = 327 candidate-types = 328 rel-addr = 329 rel-port = 330 extension-att-name = 331 extension-att-value = 332 ice-char = 333 connection-address = 334 port = 335 EQUAL = 336 DQ = 337 SWS = 338 SEMI = 340 : is the IP address of the candidate, allowing 341 for IPv4 addresses, IPv6 addresses and Fully qualified domain names 342 (FQDN), taken from [RFC4566]. The connection address SHOULD be on 343 the same format (explicit IP or FQDN) as in the dest_addr parameter 344 used to express default for the matching candidate. An IP address 345 SHOULD be used, but an FQDN MAY be used in place of an IP address. 346 In that case, when receiving an offer or answer containing an FQDN in 347 an a=candidate attribute, the FQDN is looked up in the DNS first 348 using an AAAA record (assuming the agent supports IPv6), and if no 349 result is found or the agent only supports IPv4, using an A. If the 350 DNS query returns more than one IP address, one is chosen, and then 351 used for the remainder of ICE processing. 353 : is the port of the candidate taken from RFC 4566 [RFC4566]. 355 : indicates the transport protocol for the candidate. The 356 ICE specification only defines UDP. However, extensibility is 357 provided to allow for future transport protocols to be used with ICE, 358 such as TCP or the Datagram Congestion Control Protocol (DCCP) 359 [RFC4340]. 361 : is an identifier that is equivalent for two candidates 362 that are of the same type, share the same base, and come from the 363 same STUN server, and is composed of one to thirty two . 364 The foundation is used to optimize ICE performance in the Frozen 365 algorithm. 367 : identifies the specific component of the media stream 368 for which this is a candidate and os a positive integer between 1 and 369 256. It MUST start at 1 and MUST increment by 1 for each component 370 of a particular candidate. For media streams based on RTP, 371 candidates for the actual RTP media MUST have a component ID of 1, 372 and candidates for RTCP MUST have a component ID of 2. Other types 373 of media streams which require multiple components MUST develop 374 specifications which define the mapping of components to component 375 IDs. See Section 14 for additional discussion on extending ICE to 376 new media streams. 378 : is a positive integer between 1 and (2**31 - 1). 380 : encodes the type of candidate. The ICE specification 381 defines the values "host", "srflx", "prflx" and "relay" for host, 382 server reflexive, peer reflexive and relayed candidates, 383 respectively. The set of candidate types is extensible for the 384 future. 386 and : convey transport addresses related to the 387 candidate, useful for diagnostics and other purposes. and 388 MUST be present for server reflexive, peer reflexive and 389 relayed candidates. If a candidate is server or peer reflexive, 390 and is equal to the base for that server or 391 peer reflexive candidate. If the candidate is relayed, 392 and is equal to the mapped address in the Allocate 393 Response that provided the client with that relayed candidate (see 394 Appendix B.3 for a discussion of its purpose). If the candidate is a 395 host candidate and MUST be omitted. 397 3.3. ICE Password and Username Transport Header Parameters 399 The ICE password and username for each agent needs to be transported 400 using RTSP. For that purpose new transport header parameters are 401 defined. 403 There MUST be an "ICE-Password" and "ICE-Userfrag" parameter for each 404 media stream. If two SETUP requests in the same RTSP session have 405 identical ICE-Userfrag's, they MUST have identical ICE-Password's. 406 The ICE-Userfrag and ICE-Password attributes MUST be chosen randomly 407 at the beginning of a session. The ICE-Userfrag attribute MUST 408 contain at least 24 bits of randomness, and the ICE-Password 409 attribute MUST contain at least 128 bits of randomness. This means 410 that the ICE-Userfrag attribute will be at least 4 characters long, 411 and the ICE-Password at least 22 characters long, since the grammar 412 for these attributes allows for 6 bits of randomness per character. 413 The attributes MAY be longer than 4 and 22 characters respectively, 414 of course, up to 256 characters. The upper limit allows for buffer 415 sizing in implementations. Its large upper limit allows for 416 increased amounts of randomness to be added over time. 418 The ABNF [RFC5234] for these parameters are: 420 tr-parameter =/ SEMI ice-password-par 421 tr-parameter =/ SEMI ice-userfrag-par 422 ice-password-par = ICE-Password" HCOLON password 423 ice-userfrag-par = ICE-Userfrag" HCOLON ufrag 424 password = 425 ufrag = 426 HCOLON = 427 SEMI = 429 3.4. ICE Feature Tag 431 A feature tag is defined for usage in the RTSP capabilities mechanism 432 for ICE support for media transport using datagrams: "setup.ice-d-m". 433 This feature tag indicates that one support all the mandatory to 434 support functions of this specification. It is applicable to all 435 types of RTSP agents; clients, servers and proxies. 437 The RTSP client should send the feature tag "setup.ice-d-m" in the 438 "Supported" header in all SETUP requests that contain the "D-ICE" 439 lower layer transport. 441 3.5. Status Codes 443 ICE needs two new RTSP response codes to indicate correctly progress 444 and errors. 446 +------+----------------------------------------------+-------------+ 447 | Code | Reason | Method | 448 +------+----------------------------------------------+-------------+ 449 | 150 | Server still working on ICE connectivity | PLAY | 450 | | checks | | 451 | 480 | ICE Connectivity check failure | PLAY, SETUP | 452 +------+----------------------------------------------+-------------+ 454 Table 1: New Status codes and their usage with RTSP methods 456 3.5.1. 150 ICE connectivity checks in progress 458 The 150 response code indicates that ICE connectivity checks are 459 still in progress and haven't concluded. This response SHALL be sent 460 within 200 milliseconds of receiving a PLAY request that currently 461 can't be fulfilled because ICE connectivity checks are still running. 462 Subsequently, every 3 seconds after the previous sent one, a 150 463 reply shall be sent until the ICE connectivity checks conclude either 464 successfully or in failure, and a final response for the request can 465 be provided. 467 3.5.2. 480 ICE Processing Failed 469 The 480 client error response code is used in cases when the request 470 can't be fulfilled due to a failure in the ICE processing, such as 471 that all the connectivity checks have timed out. This error message 472 can appear either in response to a SETUP request to indicate that no 473 candidate pair can be constructed or to a PLAY request that the 474 server's connectivity checks resulted in failure. 476 3.6. Server Side SDP Attribute for ICE Support 478 If the server supports the media NAT traversal for RTSP controlled 479 sessions, as described in this RFC, then the Server SHALL include the 480 "a=rtsp-ice-d-m" SDP attribute in any SDP (if used) describing 481 content served by the server. This is an session level attribute. 483 rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m" 485 3.7. ICE Features Not Required in RTSP 487 A number of ICE signalling features are not needed with RTSP and are 488 discussed below. 490 3.7.1. ICE-Lite 492 The ICE-Lite attribute shall not be used in the context of RTSP. The 493 ICE specification describes two implementations of ICE: Full and 494 Lite, where hosts that are not behind a NAT are allowed to implement 495 only Lite. For RTSP, the Lite implementation is insufficient because 496 it does not cause the media server to send a connectivity check, 497 which are used to protect against making the RTSP server a denial of 498 service tool. This document defines another variation implementation 499 of ICE, called ICE-RTSP. It has its own set of simplifications 500 suitable to RTSP. Conceptually, this implementation of ICE-RTSP is 501 between ICE-FULL and ICE-LITE for a server and simpler than ICE-FULL 502 for clients. 504 3.7.2. ICE-Mismatch 506 The ice-mismatch parameter indicates that the offer arrived with a 507 default destination for a media component that didn't have a 508 corresponding candidate attribute. This is not needed for RTSP as 509 the ICE based lower layer transport specification either is supported 510 or another alternative transport is used. This is always explicitly 511 indicated in the SETUP request and response. 513 3.7.3. ICE Remote Candidate Transport Header Parameter 515 The Remote candidate attribute is not needed for RTSP for the 516 following reasons. Each SETUP results in a independent ICE 517 processing chain which either fails or results in promoting a single 518 candidate pair to usage. If a new SETUP request for the same media 519 is sent this needs to use a new userfragment and password to avoid 520 any race conditions or uncertainty for which processing round the 521 STUN requests relate to. 523 4. Detailed Solution 525 This section describes in detail how the interaction and flow of ICE 526 works with RTSP messages. 528 4.1. Session description and RTSP DESCRIBE (optional) 530 The RTSP server should indicate it has support for ICE by sending the 531 "rtsp-ice-d-m" SDP attribute in the response to the RTSP DESCRIBE 532 message if SDP is used. This allows RTSP clients to only send the 533 new ICE interchanges with servers that support ICE so limiting the 534 overhead on current non-ICE supporting RTSP servers. When not using 535 RTSP DESCRIBE it is still recommended to use the SDP attribute for 536 session description. 538 A Client can also use the DESCRIBE request to determine explicitly if 539 both server and any proxies support ICE. The client includes the 540 "Supported" header with its supported feature tags, including 541 "setup.ice-d-m". Any proxy upon seeing the "Supported" header will 542 include the "Proxy-Supported" header with the feature tags it 543 supports. The server will echo back the "Proxy-Supported" header and 544 its own version of the Supported header so enabling a client to 545 determine if all involved parties support ICE or not. Note that even 546 if a proxy is present in the chain that doesn't indicate support for 547 ICE, it may still work. 549 For example: 550 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 551 CSeq: 312 552 User-Agent: PhonyClient 1.2 553 Accept: application/sdp, application/example 554 Supported: setup.ice-d-m 556 S->C: RTSP/2.0 200 OK 557 CSeq: 312 558 Date: 23 Jan 1997 15:35:06 GMT 559 Server: PhonyServer 1.1 560 Content-Type: application/sdp 561 Content-Length: 367 562 Supported: setup.ice-d-m 564 v=0 565 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 566 s=SDP Seminar 567 i=A Seminar on the session description protocol 568 u=http://www.example.com/lectures/sdp.ps 569 e=seminar@example.com (Seminar Management) 570 t=2873397496 2873404696 571 a=recvonly 572 a=rtsp-ice-d-m 573 a=control: * 574 m=audio 3456 RTP/AVP 0 575 a=control: /audio 576 m=video 2232 RTP/AVP 31 577 a=control: /video 579 4.2. Setting up the Media Resources 581 The RTSP client reviews the session description returned, for example 582 by an RTSP DESCRIBE message, to determine what media resources that 583 need to be setup. For each of these media resources where the 584 transport protocol supports ICE connectivity checks, the client shall 585 gather candidate addresses as described in section 4.1.1 in 586 [I-D.ietf-mmusic-ice] according to standard ICE rather than the ICE- 587 Lite implementation. 589 4.3. RTSP SETUP Request 591 The RTSP client will then send one or more SETUP requests to 592 establish the media streams required for the desired session. For 593 each media stream where it desires to use ICE it will include a 594 transport specification with "D-ICE" as the lower layer. This 595 transport specification SHOULD be placed first in the list to give it 596 highest priority. It is RECOMMENDED that additional transport 597 specifications are provided as a fallback in case of non ICE 598 supporting proxies. For example (Note that some lines are broken in 599 contradiction with the defined syntax due to space restrictions in 600 the documenting format: 601 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 602 CSeq: 302 603 Transport: RTP/AVP/D-ICE; unicast; candidates = " 604 1 1 UDP 2130706431 10.0.1.1 8998 typ host; 605 2 1 UDP 1694498815 192.0.2.3 45664 typ srflx 606 raddr 10.0.1.1 rport 9002", 607 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 608 RTP/AVP/TCP;unicast;interleaved=0-1 609 Accept-Ranges: NPT, UTC 610 User-Agent: PhonyClient/1.2 611 Supported: setup.ice-d-m 613 The client will be initiating and thus the controlling party in the 614 ICE processing. 616 4.4. Gathering Candidates 618 Upon receiving a SETUP request the server can determine what media 619 resource should be delivered and which transport alternatives that 620 the client supports. If one based on D-ICE is first on the list of 621 supported transports, the below applies, otherwise another transport 622 method is preferred and supported. 624 The transport specification will provide which media protocol is to 625 be used and based on this and the clients candidates, the server 626 determines the protocol and if it supports ICE with that protocol. 627 The server shall then gather its candidates according to section 628 4.1.1 in [I-D.ietf-mmusic-ice]. Servers that have an address that is 629 generally reachable by any clients within the address scope the 630 server intends to serve MAY be specially configured (high- 631 reachability configuration). This special configuration has the goal 632 of reducing the server side candidate to preferably a single one per 633 address family. Instead of gathering all possible addresses 634 including relayed and server reflexive addresses, the server uses a 635 single address per address family that it knows it should be 636 reachable by a client behind one or more NATs. The reason for this 637 special configuration is two fold: Firstly it reduces the load on the 638 server in address gathering and in ICE processing during the 639 connectivity checks. Secondly it will reduce the number of 640 permutations for candidate pairs significantly thus potentially 641 speeding up the conclusion of the ICE processing. Note however that 642 using this option on a server that doesn't fulfill the requirement of 643 being reachable is counter-productive and it is important that this 644 is correctly configured. 646 4.5. RTSP Server Response 648 The server determines if the SETUP request is successful from the 649 other perspectives and will return a 200 OK response, otherwise 650 returning an error code from the list in Table 4 in 651 [I-D.ietf-mmusic-rfc2326bis]. At that point the server, having 652 selected a transport specification using the "D-ICE" lower layer, 653 will need to include that transport specification in the response 654 message. The transport specification shall include the candidates 655 gathered in SectionSection 4.4 in the "candidates" transport header 656 parameter as well as the server's username and password. In the case 657 that there are no valid candidate pairs with the combination of the 658 client and servers candidates, a 480 (ICE Processing Failed) error 659 response shall be returned which must include the servers' 660 candidates. The return of a 480 error may allow both the server and 661 client to release its candidates. 663 S->C: RTSP/2.0 200 OK 664 CSeq: 302 665 Session: 12345678 666 Transport: RTP/AVP/D-ICE; unicast; candidates = " 667 1 1 UDP 2130706431 192.0.2.56 50234 typ host" 668 Accept-Ranges: NPT 669 Date: 23 Jan 1997 15:35:06 GMT 670 Server: PhonyServer 1.1 671 Supported: setup.ice-d-m 673 4.6. Server to Client ICE Connectivity Checks 675 The server shall start the connectivity checks following the 676 procedures described in Section 5.7 and 5.8 of [I-D.ietf-mmusic-ice] 677 unless it is configured to use the high-reachability option. If it 678 is then it can suppress its own checks until the servers checks are 679 triggered by the client's connectivity checks. 681 The server SHALL use a single pacer for all STUN transactions within 682 a single RTSP session, i.e across all media streams that are part of 683 the same RTSP session. 685 When a connectivity check from the client reaches the server it will 686 result in a triggered check from the server as specified in section 687 7.2.1.4 of [I-D.ietf-mmusic-ice]. This is why servers with a high 688 reachability address can wait until this triggered check to send out 689 any checks for itself so saving resources and mitigating the DDoS 690 potential. 692 4.7. Client to Server ICE Connectivity Check 694 The client receives the SETUP response and learns the candidate 695 address to use for the connectivity checks. The client shall 696 initiate its connectivity check, following the procedures in Section 697 6 of [I-D.ietf-mmusic-ice]. 699 Aggressive nomination SHALL be used with RTSP. This doesn't have the 700 negative impact that it has in offer/answer as media playing only 701 starts after issuing a PLAY request. 703 4.8. Client Connectivity Checks Complete 705 When the client has concluded its connectivity checks and has 706 correspondingly received the server connectivity checks on the 707 promoted candidates for all the media components, it can issue a PLAY 708 request. If the client has locally determined that its checks have 709 failed it may try providing an extended set of candidates and update 710 the server candidate list by issuing a new SETUP request for the 711 media stream. 713 If the client concluded its connectivity checks succesfully and 714 therefore sent a PLAY request but the server have not concluded 715 successfully, the server will respond with a 480 (ICE Processing 716 Failed). Upon receiving the 480 (ICE Processing Failed) response, 717 then the client may send a new SETUP request assuming it has any new 718 information that can be included in the candidate list. 720 4.9. Server Connectivity Checks Complete 722 When the RTSP server receives a PLAY request, it checks to see that 723 the connectivity checks have concluded successfully and only then 724 will it play the stream. If there is a problem with the checks then 725 the server sends to the client either a new 150 (ICE connectivity 726 checks in progress) response to show that it is still working on the 727 connectivity checks or a new 480 response to indicate a failure of 728 the checks. If the checks are successful then the server sends a 200 729 OK response and starts delivering media. The new RTSP errors add to 730 the list in Table 4 in [I-D.ietf-mmusic-rfc2326bis] as below: 732 4.10. Releasing Candidates 734 Both server and client may release its non nominated candidates as 735 soon as a 200 PLAY response has been issued/received. 737 4.11. Steady State 739 The client will continue to use STUN to send keep-alive for the used 740 bindings. This is important as normally RTSP play mode sessions only 741 contain traffic from the server to the client so the bindings in the 742 NAT needs to be refreshed by the cleint to server traffic provided by 743 the STUN keep-alive. 745 4.12. re-SETUP 747 If the client decides to change any parameter related to the media 748 stream SETUP it will send a new SETUP request. In this new SETUP 749 request the client SHALL include a new different username and 750 password to use in the ICE processing. This request will also cause 751 the ICE processing to start from the beginning again. 753 If the RTSP session is in playing state at the time of sending the 754 SETUP request, the ICE connectivity checks SHALL use Regular 755 nomination. Any ongoing media delivery continues on the previously 756 nominated candidate pairs until the new pairs have been nominated for 757 the individual candidate. Once the nomination of the new candidate 758 pair has completed, all unused candidates may be released. 760 5. ICE and Proxies 762 RTSP allows for proxies which can be of two fundamental types 763 depending if they relay and potentially cache the media or not. 764 Their differing impact on the RTSP NAT traversal solution including 765 backwards compatibility is explained below. 767 5.1. Media Handling Proxies 769 An RTSP proxy that relays or caches the media stream for a particular 770 media session can be considered to split the media transport into two 771 parts: A media transport between the server and the proxy according 772 to the proxies need, and delivery from the proxy to the client. This 773 split means that the NAT traversal solution will need to be run on 774 each individual media leg according to need. 776 It is RECOMMENDED that any media handling proxy support the media NAT 777 traversal defined within this specification. This is for two 778 reasons: Firstly to enable clients to perform NAT traversal for the 779 media between the proxy and itself and secondly to allow the proxy to 780 be topology independent so able to support performing NAT traversal 781 for non-NAT traversal capable clients present in the same address 782 domain. 784 For a proxy to support the media NAT traversal defined in this 785 specification a proxy will need to implement the solution fully and 786 be ready as both a controlling and a controlled ICE peer. The proxy 787 also SHALL include the "setup.ice-d-m" feature tag in any applicable 788 capability negotiation headers, such as "Proxy-Supported". 790 5.2. Signalling Only Proxies 792 A signalling only proxy handles only the RTSP signalling and does not 793 have the media relayed through proxy functions. This type of proxy 794 is not likely to work unless the media NAT traversal solution is in 795 place between the client and the server, because the DoS protection 796 measures usually prevent media delivery to other addresses other than 797 from where the RTSP signalling arrives at the server. 799 The solution for the Signalling Only proxy is that it must forward 800 the RTSP SETUP requests including any transport specification with 801 the "D-ICE" lower layer and the related transport parameters. A 802 proxy supporting this functionality SHOULD indicate its capability by 803 always including the "setup.ice-d-m" feature tag in the "Proxy- 804 Supported" header. 806 5.3. Non-supporting Proxies 808 A media handling proxy that doesn't support the ICE media NAT 809 traversal specified here is assumed to remove the transport 810 specification and use any of the lower prioritized transport 811 specifications if provided by the requester. The specification of 812 such a non ICE transport enables the negotiation to complete, 813 although with a less prefered method as a NAT between the proxy and 814 the client will result in failure of the media path. 816 A non-media handling transport proxy is expected to ignore and simply 817 forward all unknown transport specifications, however, this can only 818 be guaranteed for proxies following the published RTSP 2.0 819 specification. 821 Unfortunately the usage of the "setup.ice-d-m" feature tag in the 822 proxy-require will have contradicting results. For a non ICE 823 supporting media handling proxy, the inclusion of the feature tag 824 will result in aborting the setup and indicating that it isn't 825 supported, which is desirable if you want to provide other fallbacks 826 or other transport configurations to handle the situation. For non- 827 supporting non-media handling proxies the result will also result in 828 aborting the setup, however, setup might have worked if the proxy- 829 require tag wasn't present. This variance in results makes usage of 830 proxy-require not recommended. We recommend instead the usage of the 831 Supported header to force proxies to include the feature tags they 832 support in the proxy-supported which will provide a positive 833 indication when all proxies in the chain between the client and 834 server support the functionality. Even if not explicitly indicating 835 support, any SETUP response including a transport specification with 836 "D-ICE" will be implicit indication that the proxy chain supports at 837 least passthrough of this media. 839 6. RTP and RTCP Multiplexing 841 [I-D.ietf-avt-rtp-and-rtcp-mux] specifies how and when RTP and RTCP 842 can be multiplexed on the same port. This multiplexing is highly 843 recommended to combine with ICE as it makes RTP and RTCP only need a 844 single component per media stream instead of two, so reducing the 845 load on the connectivity checks. 847 To enable signalling for the usage of RTP and RTCP multiplexing a new 848 RTSP transport header parameter is defined. The formal syntax (ABNF 849 [RFC5234]) of this parameter is the following: 851 tr-parameter =/ SEMI rtcp-mux-par 852 rtcp-mux-par = "rtp-rtcp-mux" 853 SEMI = 854 EQUAL = 856 The "rtp-rtcp-mux" parameter MAY be included in any transport 857 specification that use RTP where RTP and RTCP multiplexing is desired 858 and indicates in a SETUP request that multiplexing is requested. If 859 the SETUP response also includes the parameter then RTP and RTCP 860 multiplexing SHALL be used for that transport specification. A SETUP 861 request may indicate address information for both RTP and RTCP for 862 backwards compatibility reasons. If RTP and RTCP multiplexing is 863 used then only the information specified for RTP SHALL be used. 865 For capability exchange, an RTSP feature tag for RTP and RTCP 866 multiplexing is defined: "setup.rtp-mux". 868 RTSP servers and clients that supports "D-ICE" lower layer transport 869 in combination with RTP SHALL also implement RTP and RTCP 870 multiplexing as specified in this section and 871 [I-D.ietf-avt-rtp-and-rtcp-mux]. 873 7. Open Issues 875 Below is listed the known open issues and questions that needs to be 876 resolved: 878 1. Need a descriptive section on how ICE works for RTSP folks. 880 2. No solution has been specified for how RTSP server's can initiate 881 a ICE restart. Either to add candidates or to reinitate the 882 connectivity checks in response to lost bindings. Basically 883 required to find a solution for this. 885 3. Does we need to support multiple components? 887 4. Is the role and processing the most optimal one that can be used? 889 8. IANA Considerations 891 This document request registration in a number of registries, both 892 for RTSP and SDP. 894 8.1. RTSP Feature Tags 896 This document request that two RTSP feature tags are registered in 897 the "RTSP feature tag" registry: 899 setup.rtp-mux See Section Section 6. 901 setup.ice-d-m See Section Section 3.4. 903 8.2. Transport Protocol Specifications 905 This document needs to register a number of transport protocol 906 combinations are registered in RTSP's "Transport Protocol 907 Specifications" registry. 909 "RTP/AVP/D-ICE": 911 "RTP/AVPF/D-ICE": 913 "RTP/SAVP/D-ICE": 915 "RTP/SAVPF/D-ICE": 917 8.3. RTSP Transport Parameters 919 This document requests that 4 transport parameters are registered in 920 RTSP's "Transport Parameters": 922 "candidates": See Section Section 3.2. 924 "ICE-Password": See Section Section 3.3. 926 "ICE-Userfrag": See Section Section 3.3. 928 "rtp-rtcp-mux": See Section Section 6. 930 8.4. RTSP Status Codes 932 This document requests that 2 assignments are done in the "RTSP 933 Status Codes" registry. The suggested values are: 935 150: See Section Section 3.5.1. 937 480: See Section Section 3.5.2. 939 8.5. SDP Attribute 941 The registration of one SDP attribute is requested: 942 SDP Attribute ("att-field"): 944 Attribute name: rtsp-ice-d-m 945 Long form: ICE for RTSP datagram media NAT traversal 946 Type of name: att-field 947 Type of attribute: Session level only 948 Subject to charset: No 949 Purpose: RFC XXXX 950 Reference: RFC XXXX 951 Values: No values defined. 952 Contact: Magnus Westerlund 953 E-mail: magnus.westerlund@ericsson.com 954 phone: +46 8 404 82 87 956 9. Security Considerations 958 ICE [I-D.ietf-mmusic-ice] provides an extensive discussion on 959 security considerations which applies here as well. 961 9.1. ICE and RTSP 963 A long-standing risk with transmitting a packet stream over UDP is 964 that the host may not be interested in receiving the stream. On 965 today's Internet many hosts are behind NATs or operate host firewalls 966 which do not respond to unsolicited packets with an ICMP port 967 unreachable error. Thus, an attacker can construct SDP with a 968 victim's IP address and cause a flood of media packets to be sent to 969 a victim. The addition of ICE, as described in this document, 970 provides protection from the attack described above. By performing 971 the ICE connectivity check, the media server receives confirmation 972 that the RTSP client wants the media. While this protection could 973 also be implemented by requiring the IP addresses in the SDP match 974 the IP address of the RTSP signaling packet, such a mechanism does 975 not protect other hosts with the same IP address (such as behind the 976 same NAT), and such a mechanism would prohibit separating the RTSP 977 controller from the media playout device (e.g., an IP-enabled remote 978 control and an IP-enabled television). 980 10. Acknowledgements 982 The authors would like to thank Remi Denis-Courmont for suggesting 983 the method of integrating ICE in RTSP signalling, Dan Wing for help 984 with the security section and numerous other issues. 986 11. References 988 11.1. Normative References 990 [I-D.ietf-avt-rtp-and-rtcp-mux] 991 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 992 Control Packets on a Single Port", 993 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 994 August 2007. 996 [I-D.ietf-behave-rfc3489bis] 997 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 998 "Session Traversal Utilities for (NAT) (STUN)", 999 draft-ietf-behave-rfc3489bis-15 (work in progress), 1000 February 2008. 1002 [I-D.ietf-mmusic-ice] 1003 Rosenberg, J., "Interactive Connectivity Establishment 1004 (ICE): A Protocol for Network Address Translator (NAT) 1005 Traversal for Offer/Answer Protocols", 1006 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1008 [I-D.ietf-mmusic-rfc2326bis] 1009 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1010 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1011 (RTSP)", draft-ietf-mmusic-rfc2326bis-17 (work in 1012 progress), February 2008. 1014 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1015 Requirement Levels", BCP 14, RFC 2119, March 1997. 1017 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1018 Description Protocol", RFC 4566, July 2006. 1020 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1021 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1023 11.2. Informative References 1025 [I-D.ietf-mmusic-rtsp-nat-evaluation] 1026 Westerlund, M., "The evaluation of different NAT traversal 1027 Techniques for media controlled by Real-time Streaming 1028 Protocol (RTSP)", draft-ietf-mmusic-rtsp-nat-evaluation-00 1029 (work in progress), July 2007. 1031 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1032 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1034 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1035 Address Translator (Traditional NAT)", RFC 3022, 1036 January 2001. 1038 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1039 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1041 Authors' Addresses 1043 Jeff Goldberg 1044 Cisco 1045 11 New Square, Bedfont Lakes 1046 Feltham,, Middx TW14 8HA 1047 United Kingdom 1049 Phone: +44 20 8824 1000 1050 Fax: 1051 Email: jgoldber@cisco.com 1052 URI: 1054 Magnus Westerlund 1055 Ericsson 1056 Torshamsgatan 23 1057 Stockholm, SE-164 80 1058 Sweden 1060 Phone: +46 8 719 0000 1061 Fax: 1062 Email: magnus.westerlund@ericsson.com 1063 URI: 1065 Thomas Zeng 1066 Nextwave Wireless, Inc. 1067 12670 High Bluff Drive 1068 San Diego, CA 92130 1069 USA 1071 Phone: +1 858 480 3100 1072 Fax: 1073 Email: thomas.zeng@gmail.com 1074 URI: 1076 Full Copyright Statement 1078 Copyright (C) The IETF Trust (2008). 1080 This document is subject to the rights, licenses and restrictions 1081 contained in BCP 78, and except as set forth therein, the authors 1082 retain all their rights. 1084 This document and the information contained herein are provided on an 1085 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1086 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1087 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1088 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1089 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1090 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1092 Intellectual Property 1094 The IETF takes no position regarding the validity or scope of any 1095 Intellectual Property Rights or other rights that might be claimed to 1096 pertain to the implementation or use of the technology described in 1097 this document or the extent to which any license under such rights 1098 might or might not be available; nor does it represent that it has 1099 made any independent effort to identify any such rights. Information 1100 on the procedures with respect to rights in RFC documents can be 1101 found in BCP 78 and BCP 79. 1103 Copies of IPR disclosures made to the IETF Secretariat and any 1104 assurances of licenses to be made available, or the result of an 1105 attempt made to obtain a general license or permission for the use of 1106 such proprietary rights by implementers or users of this 1107 specification can be obtained from the IETF on-line IPR repository at 1108 http://www.ietf.org/ipr. 1110 The IETF invites any interested party to bring to its attention any 1111 copyrights, patents or patent applications, or other proprietary 1112 rights that may cover technology that may be required to implement 1113 this standard. Please address the information to the IETF at 1114 ietf-ipr@ietf.org. 1116 Acknowledgment 1118 Funding for the RFC Editor function is provided by the IETF 1119 Administrative Support Activity (IASA).