idnits 2.17.1 draft-petithuguenin-behave-turn-uri-03.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 554. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 560. 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 : ---------------------------------------------------------------------------- -- 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 (October 8, 2008) is 5678 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 (-16) exists of draft-ietf-behave-turn-10 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Petit-Huguenin 3 Internet-Draft 8x8, Inc. 4 Intended status: Standards Track October 8, 2008 5 Expires: April 11, 2009 7 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers 8 draft-petithuguenin-behave-turn-uri-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 11, 2009. 35 Abstract 37 This document defines two URI schemes and the resolution mechanism to 38 convert these URIs to a list of server transport addresses that can 39 be used between a Traversal Using Relays around NAT (TURN) client and 40 server. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 3. Syntax of a TURN or TURNS URI . . . . . . . . . . . . . . . . 3 47 4. TURN or TURNS URI Resolution . . . . . . . . . . . . . . . . . 4 48 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 49 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 50 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 51 7.1. TURN URI Registration . . . . . . . . . . . . . . . . . . 7 52 7.2. TURNS URI Registration . . . . . . . . . . . . . . . . . . 7 53 7.3. RELAY Application Service Tag Registration . . . . . . . . 8 54 7.4. turn.udp Application Protocol Tag Registration . . . . . . 8 55 7.5. turn.tcp Application Protocol Tag Registration . . . . . . 9 56 7.6. turn.tls Application Protocol Tag Registration . . . . . . 9 57 8. Running Code Considerations . . . . . . . . . . . . . . . . . 10 58 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 61 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 62 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 11 63 A.1. Modifications between -03 and -02 . . . . . . . . . . . . 11 64 A.2. Modifications between -02 and -01 . . . . . . . . . . . . 11 65 A.3. Modifications between -01 and -00 . . . . . . . . . . . . 11 66 A.4. Design Notes . . . . . . . . . . . . . . . . . . . . . . . 12 67 A.5. TODO List . . . . . . . . . . . . . . . . . . . . . . . . 12 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 Intellectual Property and Copyright Statements . . . . . . . . . . 13 71 1. Introduction 73 The TURN specification [I-D.ietf-behave-turn] defines a process for a 74 TURN client to find TURN servers by using DNS SRV resource records, 75 but this process does not let the TURN server administrators 76 provision the preferred TURN transport protocol between the client 77 and the server and for the TURN client to discover this preference. 78 This document defines a S-NAPTR application [RFC3958] for this 79 purpose. This application defines "RELAY" as application service tag 80 and "turn.udp", "turn.tcp", and "turn.tls" as application protocol 81 tags. 83 To simplify the provisioning of TURN clients, this document also 84 defines a TURN and a TURNS URI scheme and a resolution mechanism to 85 convert these URIs into a list of IP addresses, ports and TURN 86 transport protocols. 88 Another usage of the resolution mechanism described in this document 89 would be Remote Hosting as described in [RFC3958] section 4.4. For 90 example a VoIP provider who does not want to deploy TURN servers 91 could use the servers deployed by another company but could still 92 want to provide configuration parameters to its customers without 93 explicitly showing this relationship. The mechanism permits one to 94 implement this indirection, without preventing the company hosting 95 the TURN servers from manage them as it see fit. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 3. Syntax of a TURN or TURNS URI 105 A TURN/TURNS URI has the following ABNF syntax [RFC5234]: 107 turnURI = scheme ":" host [ ":" port ] [ "?transport=" transport ] 108 scheme = "turn" / "turns" 109 transport = "udp" / "tcp" / transport-ext 110 transport-ext = 1*unreserved 112 , and are specified in [RFC3986]. 114 4. TURN or TURNS URI Resolution 116 The URI resolution algorithm uses , , and 117 as input. It also uses a list ordered by preference of 118 TURN transports (UDP, TCP, TLS) supported by the application using 119 the TURN client. The output of the algorithm is a list of {IP 120 address, transport, port} tuples that a TURN client can try in order 121 to contact a TURN server. 123 The resolution stops when a TURN client gets a successful Allocate 124 response from a TURN server. After receiving a successful Allocate 125 response, the resolution context MUST be discarded and the URI 126 resolution algorithm MUST be restarted from the beginning for any 127 subsequent allocation. 129 In some steps and have to be converted to a TURN 130 transport. If is defined as "turn" and is 131 defined as "udp" then the TURN UDP transport is used. If is 132 defined as "turn" and is defined as "tcp" then the TURN 133 TCP transport is used. If is defined as "turns" and 134 is defined as "tcp" then the TURN TLS transport is used. 136 First the resolution algorithm checks that the URI can be resolved 137 with the list of TURN transports supported: 139 o If is defined as "turn" and is defined as 140 "udp" but the list of TURN transports does not contain UDP then 141 the resolution MUST stop with an error. 142 o If is defined as "turn" and is defined as 143 "tcp" but the list of TURN transports does not contain TCP or TLS 144 then the resolution MUST stop with an error. 145 o If is defined as "turns" and is defined as 146 "udp" then the algorithm MUST stop with an error. 147 o If is defined as "turns" and is defined as 148 "tcp" but the list of TURN transports does not contain TLS then 149 the resolution MUST stop with an error. 150 o If is defined as "turns" and is not defined 151 but the list of TURN transports does not contain TLS then the 152 resolution MUST stop with an error. 154 Then the algorithm applies the following steps. 156 1. If is an IP address then it indicates the specific IP 157 address to be used. If is not defined, the default port 158 declared in [I-D.ietf-behave-turn] for the SRV service name 159 defined in is used. If is defined then 160 and are converted to a TURN transport as 161 specified above. If is not defined, the TURN 162 transports supported by the application are tried by preference 163 order. If the TURN client cannot contact a TURN server with this 164 IP address and port on any of the transports then the resolution 165 MUST stop with an error. 166 2. If is a domain name and is defined, then is 167 resolved to a list of IP addresses via DNS A and AAAA queries. 168 If is defined then and are 169 converted to a TURN transport as specified above. If 170 is not defined, the TURN transports supported by the application 171 are tried by preference order. If the TURN client cannot contact 172 a TURN server with this port and any combination of transports 173 and resolved IP addresses then the resolution MUST stop with an 174 error. 175 3. If is a domain name and is not defined but 176 is defined then is converted to a list of IP 177 address and port tuples via a DNS SRV query as defined in 178 [I-D.ietf-behave-turn] section 6.1. is used for the 179 service name and is used for the protocol name in the 180 SRV algorithm [RFC2782]. If the TURN client cannot contact a 181 TURN server at any of the IP address, port and transport tuples 182 returned by the SRV algorithm then the resolution MUST stop with 183 an error. The SRV algorithm recommends doing an A query if the 184 SRV query returns an error or no SRV RR. In this case the 185 default port declared in [I-D.ietf-behave-turn] for the SRV 186 service name defined in must be used for contacting the 187 TURN server. Also in this case, this specification modifies the 188 SRV algorithm by recommending an A or AAAA query. 189 4. If is a domain name and and are not 190 defined, then is converted to an ordered list of IP 191 address, port and transport tuples via the S-NAPTR algorithm 192 defined in [RFC3958] with a "RELAY" Application Service Tag. The 193 TURN transports supported by the application are converted in 194 Application Protocol Tags by using "turn.udp" if the TURN 195 transport is UDP, "turn.tcp" if the TURN transport is TCP and 196 "turn.tls" if the TURN transport is TLS. The order to try the 197 protocol tags is provided by the ranking of the first set of 198 NAPTR records. If multiple protocol tags have the same ranking, 199 the preferred order set by the application is used. If the TURN 200 client cannot contact a TURN server with any of the IP address, 201 port and transport tuples returned by the S-NAPTR algorithm then 202 the resolution MUST stop with an error. If the first NAPTR SRV 203 query does not return any result then is converted to a 204 list of IP address and port tuples by using the algorithm 205 specified in step 3 for each of the TURN transports supported by 206 the application by order of preference. 208 5. Example 210 With the DNS RRs in Figure 1 and a preferred protocol list of {TLS, 211 TCP, UDP}, the resolution algorithm will convert the "turn: 212 example.com" URI to the list of IP addresses, port and protocol 213 tuples in Table 1. 215 example.com. 216 IN NAPTR 100 10 "" "RELAY:turn.udp" "" datagram.example.com. 217 IN NAPTR 200 10 "" "RELAY:turn.tcp:turn.tls" "" stream.example.com. 219 datagram.example.com. 220 IN NAPTR 100 10 "S" "RELAY:turn.udp" "" _udp._turn.example.com. 222 stream.example.com. 223 IN NAPTR 100 10 "A" "RELAY:turn.tls" "" a.example.com. 224 IN NAPTR 200 10 "S" "RELAY:turn.tcp" "" _tcp._turn.example.com. 226 _udp._turn.example.com. 227 IN SRV 0 0 5000 a.example.com. 229 _tcp._turn.example.com. 230 IN SRV 0 0 5000 a.example.com. 232 a.example.com. 233 IN A 192.0.2.1 235 Figure 1 237 +-------+----------+------------+------+ 238 | Order | Protocol | IP address | Port | 239 +-------+----------+------------+------+ 240 | 1 | UDP | 192.0.2.1 | 5000 | 241 | 2 | TLS | 192.0.2.1 | 3478 | 242 | 3 | TCP | 192.0.2.1 | 5000 | 243 +-------+----------+------------+------+ 245 Table 1 247 6. Security Considerations 249 Security considerations for TURN are discussed in 250 [I-D.ietf-behave-turn]. 252 The Application Service Tag and Application Protocol Tags defined in 253 this document do not introduce any specific security issues beyond 254 the security considerations discussed in [RFC3958]. 256 The turn: and turns: URI schemes do not introduce any specific 257 security issues beyond the security considerations discussed in 258 [RFC3986]. 260 7. IANA Considerations 262 7.1. TURN URI Registration 264 This section contains the registration information for the TURN URI 265 scheme in accordance with [RFC4395]. 267 URI scheme name: turn 269 Status: permanent 271 URI scheme syntax: See Section 3. 273 URI scheme semantics: See Section 4. 275 Encoding considerations: There are no encoding considerations beyond 276 those in [RFC3986]. 278 Applications/protocols that use this URI scheme name: 280 The "turn:" URI is intended to be used by applications that might 281 need access to a TURN server. 283 Interoperability considerations: N/A 285 Security considerations: See Section 6. 287 Contact: Marc Petit-Huguenin 289 Author/Change controller: The IESG 291 References: This document. 293 7.2. TURNS URI Registration 295 This section contains the registration information for the TURNS URI 296 scheme in accordance with [RFC4395]. 298 URI scheme name: turns 299 Status: permanent 301 URI scheme syntax: See Section 3. 303 URI scheme semantics: See Section 4. 305 Encoding considerations: There are no encoding considerations beyond 306 those in [RFC3986]. 308 Applications/protocols that use this URI scheme name: 310 The "turn:" URI is intended to be used by applications that might 311 need access to a TURN server. 313 Interoperability considerations: N/A 315 Security considerations: See Section 6. 317 Contact: Marc Petit-Huguenin 319 Author/Change controller: The IESG 321 References: This document. 323 7.3. RELAY Application Service Tag Registration 325 This section contains the registration information for the RELAY 326 Application Service Tag in accordance with [RFC3958]. 328 Application Protocol Tag: RELAY 330 Intended usage: See Section 4. 332 Interoperability considerations: N/A 334 Security considerations: See Section 6. 336 Relevant publications: This document. 338 Contact information: Marc Petit-Huguenin 340 Author/Change controller: The IESG 342 7.4. turn.udp Application Protocol Tag Registration 344 This section contains the registration information for the turn.udp 345 Application Protocol Tag in accordance with [RFC3958]. 347 Application Protocol Tag: turn.udp 349 Intended usage: See Section 4. 351 Interoperability considerations: N/A 353 Security considerations: See Section 6. 355 Relevant publications: This document. 357 Contact information: Marc Petit-Huguenin 359 Author/Change controller: The IESG 361 7.5. turn.tcp Application Protocol Tag Registration 363 This section contains the registration information for the turn.tcp 364 Application Protocol Tag in accordance with [RFC3958]. 366 Application Protocol Tag: turn.tcp 368 Intended usage: See Section 4. 370 Interoperability considerations: 372 Security considerations: See Section 6. 374 Relevant publications: This document. 376 Contact information: Marc Petit-Huguenin 378 Author/Change controller: The IESG 380 7.6. turn.tls Application Protocol Tag Registration 382 This section contains the registration information for the turn.tls 383 Application Protocol Tag in accordance with [RFC3958]. 385 Application Protocol Tag: turn.tls 387 Intended usage: See Section 4. 389 Interoperability considerations: N/A 391 Security considerations: See Section 6. 393 Relevant publications: This document. 395 Contact information: Marc Petit-Huguenin 397 Author/Change controller: The IESG 399 8. Running Code Considerations 401 The SIP client of the free and open source Zap project [1] uses the 402 resolution mechanism and TURN URI described in this document. 404 9. Acknowledgements 406 Thanks to Eilon Yardeni, Dan Wing, Alfred Hoenes and Jim Kleck for 407 their comments, suggestions and questions that helped to improve this 408 document. 410 This document was written with the xml2rfc tool described in 411 [RFC2629]. 413 10. References 415 10.1. Normative References 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, March 1997. 420 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 421 specifying the location of services (DNS SRV)", RFC 2782, 422 February 2000. 424 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 425 Resource Identifier (URI): Generic Syntax", STD 66, 426 RFC 3986, January 2005. 428 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 429 Specifications: ABNF", STD 68, RFC 5234, January 2008. 431 [I-D.ietf-behave-turn] 432 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 433 Relays around NAT (TURN): Relay Extensions to Session 434 Traversal Utilities for NAT (STUN)", 435 draft-ietf-behave-turn-10 (work in progress), 436 September 2008. 438 10.2. Informative References 440 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 441 June 1999. 443 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 444 Service Location Using SRV RRs and the Dynamic Delegation 445 Discovery Service (DDDS)", RFC 3958, January 2005. 447 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 448 Registration Procedures for New URI Schemes", BCP 115, 449 RFC 4395, February 2006. 451 URIs 453 [1] 455 Appendix A. Release notes 457 This section must be removed before publication as an RFC. 459 A.1. Modifications between -03 and -02 461 o Added Running Code Consideration section. 462 o Added Remote Hosting example in introduction. 463 o Changed back to opaque URIs because of [RFC4395] Section 2.2. Now 464 use "?" as separator. 465 o Added IANA considerations section. 466 o Added security considerations section. 468 A.2. Modifications between -02 and -01 470 o Receiving a successful Allocate response stops the resolution 471 mechanism and the resolution context must be discarded after this. 472 o Changed from opaque to hierarchical URIs because the ";" character 473 is used in . 474 o Various nits. 476 A.3. Modifications between -01 and -00 478 o Added in the ABNF. 479 o Use the and "literal" usages for free-form text defined 480 by [RFC5234]. 481 o Fixed various typos. 482 o Put the rule to convert and to a TURN 483 transport in a separate paragraph. 485 o Modified the SRV usage to be in line with RFC 2782. 486 o Clarified that the NAPTR protocol ranking must be used before the 487 application ranking. 488 o Added an example. 489 o Added release notes. 491 A.4. Design Notes 493 o The Application Service Tag is "RELAY" so other relaying 494 mechanisms (e.g. TWIST) than TURN can be registered as 495 Application Protocol Tags. 496 o S-NAPTR was preferred to U-NAPTR because there is no use case for 497 U-NAPTR. 498 o is not used in the URIs because it is deprecated. 499 is not used in the URIs because it is not used to guide 500 the resolution mechanism. 501 o As discussed in Dublin, there is no generic parameters in the URI 502 to prevent compatibity issues. 503 o Adding optional capabilities (IPv6 allocation, preserve bit, 504 etc...) in the resolution process was rejected at the Dublin 505 meeting. 507 A.5. TODO List 509 (Empty) 511 Author's Address 513 Marc Petit-Huguenin 514 8x8, Inc. 515 3151 Jay Street 516 Santa Clara, CA 95054 517 US 519 Phone: +1 408 654 0875 520 Email: marc@8x8.com 522 Full Copyright Statement 524 Copyright (C) The IETF Trust (2008). 526 This document is subject to the rights, licenses and restrictions 527 contained in BCP 78, and except as set forth therein, the authors 528 retain all their rights. 530 This document and the information contained herein are provided on an 531 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 532 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 533 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 534 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 535 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 536 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 538 Intellectual Property 540 The IETF takes no position regarding the validity or scope of any 541 Intellectual Property Rights or other rights that might be claimed to 542 pertain to the implementation or use of the technology described in 543 this document or the extent to which any license under such rights 544 might or might not be available; nor does it represent that it has 545 made any independent effort to identify any such rights. Information 546 on the procedures with respect to rights in RFC documents can be 547 found in BCP 78 and BCP 79. 549 Copies of IPR disclosures made to the IETF Secretariat and any 550 assurances of licenses to be made available, or the result of an 551 attempt made to obtain a general license or permission for the use of 552 such proprietary rights by implementers or users of this 553 specification can be obtained from the IETF on-line IPR repository at 554 http://www.ietf.org/ipr. 556 The IETF invites any interested party to bring to its attention any 557 copyrights, patents or patent applications, or other proprietary 558 rights that may cover technology that may be required to implement 559 this standard. Please address the information to the IETF at 560 ietf-ipr@ietf.org.