idnits 2.17.1 draft-ietf-behave-turn-uri-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- The document date (March 7, 2009) is 5528 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-13 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) == Outdated reference: A later version (-08) exists of draft-wood-tae-specifying-uri-transports-04 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 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 (Unaffiliated) 4 Intended status: Standards Track March 7, 2009 5 Expires: September 8, 2009 7 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers 8 draft-ietf-behave-turn-uri-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 8, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document defines two URI schemes and the resolution mechanism to 47 convert these URIs to a list of server transport addresses that can 48 be used between a Traversal Using Relays around NAT (TURN) client and 49 server. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Syntax of a TURN or TURNS URI . . . . . . . . . . . . . . . . 3 56 4. TURN or TURNS URI Resolution . . . . . . . . . . . . . . . . . 4 57 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 7.1. TURN URI Registration . . . . . . . . . . . . . . . . . . 7 61 7.2. TURNS URI Registration . . . . . . . . . . . . . . . . . . 7 62 7.3. RELAY Application Service Tag Registration . . . . . . . . 8 63 7.4. turn.udp Application Protocol Tag Registration . . . . . . 8 64 7.5. turn.tcp Application Protocol Tag Registration . . . . . . 9 65 7.6. turn.tls Application Protocol Tag Registration . . . . . . 9 66 8. Running Code Considerations . . . . . . . . . . . . . . . . . 9 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 70 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 71 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 11 72 A.1. Modifications between -01 and -00 . . . . . . . . . . . . 11 73 A.2. Design Notes . . . . . . . . . . . . . . . . . . . . . . . 11 74 A.3. TODO List . . . . . . . . . . . . . . . . . . . . . . . . 11 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 The TURN specification [I-D.ietf-behave-turn] defines a process for a 80 TURN client to find TURN servers by using DNS SRV resource records, 81 but this process does not let the TURN server administrators 82 provision the preferred TURN transport protocol between the client 83 and the server and for the TURN client to discover this preference. 84 This document defines a S-NAPTR application [RFC3958] for this 85 purpose. This application defines "RELAY" as application service tag 86 and "turn.udp", "turn.tcp", and "turn.tls" as application protocol 87 tags. 89 To simplify the provisioning of TURN clients, this document also 90 defines a TURN and a TURNS URI scheme and a resolution mechanism to 91 convert these URIs into a list of IP addresses, ports and TURN 92 transport protocols. 94 Another usage of the resolution mechanism described in this document 95 would be Remote Hosting as described in [RFC3958] section 4.4. For 96 example a VoIP provider who does not want to deploy TURN servers 97 could use the servers deployed by another company but could still 98 want to provide configuration parameters to its customers without 99 explicitly showing this relationship. The mechanism permits one to 100 implement this indirection, without preventing the company hosting 101 the TURN servers from managing them as it see fit. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. Syntax of a TURN or TURNS URI 111 A TURN/TURNS URI has the following ABNF syntax [RFC5234]: 113 turnURI = scheme ":" host [ ":" port ] [ "?transport=" transport ] 114 scheme = "turn" / "turns" 115 transport = "udp" / "tcp" / transport-ext 116 transport-ext = 1*unreserved 118 , and are specified in [RFC3986]. 120 4. TURN or TURNS URI Resolution 122 The URI resolution algorithm uses , , and 123 as input. It also uses a list ordered by preference of 124 TURN transports (UDP, TCP, TLS) supported by the application using 125 the TURN client. The output of the algorithm is a list of {IP 126 address, transport, port} tuples that a TURN client can try in order 127 to contact a TURN server. 129 The resolution stops when a TURN client gets a successful Allocate 130 response from a TURN server. After receiving a successful Allocate 131 response, the resolution context MUST be discarded and the URI 132 resolution algorithm MUST be restarted from the beginning for any 133 subsequent allocation. 135 In some steps and have to be converted to a TURN 136 transport. If is defined as "turn" and is 137 defined as "udp" then the TURN UDP transport is used. If is 138 defined as "turn" and is defined as "tcp" then the TURN 139 TCP transport is used. If is defined as "turns" and 140 is defined as "tcp" then the TURN TLS transport is used. 142 First the resolution algorithm checks that the URI can be resolved 143 with the list of TURN transports supported: 145 o If is defined as "turn" and is defined as 146 "udp" but the list of TURN transports does not contain UDP then 147 the resolution MUST stop with an error. 148 o If is defined as "turn" and is defined as 149 "tcp" but the list of TURN transports does not contain TCP or TLS 150 then the resolution MUST stop with an error. 151 o If is defined as "turns" and is defined as 152 "udp" then the algorithm MUST stop with an error. 153 o If is defined as "turns" and is defined as 154 "tcp" but the list of TURN transports does not contain TLS then 155 the resolution MUST stop with an error. 156 o If is defined as "turns" and is not defined 157 but the list of TURN transports does not contain TLS then the 158 resolution MUST stop with an error. 159 o If is defined but unknown then the resolution MUST 160 stop with an error. 162 Then the algorithm applies the following steps. 164 1. If is an IP address then it indicates the specific IP 165 address to be used. If is not defined, the default port 166 declared in [I-D.ietf-behave-turn] for the SRV service name 167 defined in is used. If is defined then 168 and are converted to a TURN transport as 169 specified above. If is not defined, the TURN 170 transports supported by the application are tried by preference 171 order. If the TURN client cannot contact a TURN server with this 172 IP address and port on any of the transports then the resolution 173 MUST stop with an error. 174 2. If is a domain name and is defined, then is 175 resolved to a list of IP addresses via DNS A and AAAA queries. 176 If is defined then and are 177 converted to a TURN transport as specified above. If 178 is not defined, the TURN transports supported by the application 179 are tried by preference order. If the TURN client cannot contact 180 a TURN server with this port and any combination of transports 181 and resolved IP addresses then the resolution MUST stop with an 182 error. 183 3. If is a domain name and is not defined but 184 is defined then is converted to a list of IP 185 address and port tuples via a DNS SRV query as defined in 186 [I-D.ietf-behave-turn] section 6.1. is used for the 187 service name and is used for the protocol name in the 188 SRV algorithm [RFC2782]. If the TURN client cannot contact a 189 TURN server at any of the IP address, port and transport tuples 190 returned by the SRV algorithm then the resolution MUST stop with 191 an error. The SRV algorithm recommends doing an A query if the 192 SRV query returns an error or no SRV RR. In this case the 193 default port declared in [I-D.ietf-behave-turn] for the SRV 194 service name defined in must be used for contacting the 195 TURN server. Also in this case, this specification modifies the 196 SRV algorithm by recommending an A or AAAA query. 197 4. If is a domain name and and are not 198 defined, then is converted to an ordered list of IP 199 address, port and transport tuples via the S-NAPTR algorithm 200 defined in [RFC3958] with a "RELAY" Application Service Tag. The 201 TURN transports supported by the application are converted in 202 Application Protocol Tags by using "turn.udp" if the TURN 203 transport is UDP, "turn.tcp" if the TURN transport is TCP and 204 "turn.tls" if the TURN transport is TLS. The order to try the 205 protocol tags is provided by the ranking of the first set of 206 NAPTR records. If multiple protocol tags have the same ranking, 207 the preferred order set by the application is used. If the TURN 208 client cannot contact a TURN server with any of the IP address, 209 port and transport tuples returned by the S-NAPTR algorithm then 210 the resolution MUST stop with an error. If the first NAPTR SRV 211 query does not return any result then is converted to a 212 list of IP address and port tuples by using the algorithm 213 specified in step 3 for each of the TURN transports supported by 214 the application by order of preference. 216 5. Example 218 With the DNS RRs in Figure 1 and a preferred protocol list of {TLS, 219 TCP, UDP}, the resolution algorithm will convert the "turn: 220 example.com" URI to the list of IP addresses, port and protocol 221 tuples in Table 1. 223 example.com. 224 IN NAPTR 100 10 "" "RELAY:turn.udp" "" datagram.example.com. 225 IN NAPTR 200 10 "" "RELAY:turn.tcp:turn.tls" "" stream.example.com. 227 datagram.example.com. 228 IN NAPTR 100 10 "S" "RELAY:turn.udp" "" _udp._turn.example.com. 230 stream.example.com. 231 IN NAPTR 100 10 "A" "RELAY:turn.tls" "" a.example.com. 232 IN NAPTR 200 10 "S" "RELAY:turn.tcp" "" _tcp._turn.example.com. 234 _udp._turn.example.com. 235 IN SRV 0 0 5000 a.example.com. 237 _tcp._turn.example.com. 238 IN SRV 0 0 5000 a.example.com. 240 a.example.com. 241 IN A 192.0.2.1 243 Figure 1 245 +-------+----------+------------+------+ 246 | Order | Protocol | IP address | Port | 247 +-------+----------+------------+------+ 248 | 1 | UDP | 192.0.2.1 | 5000 | 249 | 2 | TLS | 192.0.2.1 | 3478 | 250 | 3 | TCP | 192.0.2.1 | 5000 | 251 +-------+----------+------------+------+ 253 Table 1 255 6. Security Considerations 257 Security considerations for TURN are discussed in 258 [I-D.ietf-behave-turn]. 260 The Application Service Tag and Application Protocol Tags defined in 261 this document do not introduce any specific security issues beyond 262 the security considerations discussed in [RFC3958]. 264 The "turn" and "turns" URI schemes do not introduce any specific 265 security issues beyond the security considerations discussed in 266 [RFC3986]. 268 7. IANA Considerations 270 This section contains the registration information for the "turn" and 271 "turns" URI Schemes (in accordance with [RFC4395]), one S-NAPTR 272 Application Service Tag, and three S-NAPTR Application Protocol Tags 273 (in accordance with [RFC3958]). 275 7.1. TURN URI Registration 277 URI scheme name: turn 279 Status: permanent 281 URI scheme syntax: See Section 3. 283 URI scheme semantics: See Section 4. 285 Encoding considerations: There are no encoding considerations beyond 286 those in [RFC3986]. 288 Applications/protocols that use this URI scheme name: 290 The "turn" URI scheme is intended to be used by applications that 291 might need access to a TURN server. 293 Interoperability considerations: N/A 295 Security considerations: See Section 6. 297 Contact: Marc Petit-Huguenin 299 Author/Change controller: The IESG 301 References: This document. 303 7.2. TURNS URI Registration 305 URI scheme name: turns 307 Status: permanent 308 URI scheme syntax: See Section 3. 310 URI scheme semantics: See Section 4. 312 Encoding considerations: There are no encoding considerations beyond 313 those in [RFC3986]. 315 Applications/protocols that use this URI scheme name: 317 The "turns" URI scheme is intended to be used by applications that 318 might need access to a TURN server. 320 Interoperability considerations: N/A 322 Security considerations: See Section 6. 324 Contact: Marc Petit-Huguenin 326 Author/Change controller: The IESG 328 References: This document. 330 7.3. RELAY Application Service Tag Registration 332 Application Protocol Tag: RELAY 334 Intended usage: See Section 4. 336 Interoperability considerations: N/A 338 Security considerations: See Section 6. 340 Relevant publications: This document. 342 Contact information: Marc Petit-Huguenin 344 Author/Change controller: The IESG 346 7.4. turn.udp Application Protocol Tag Registration 348 Application Protocol Tag: turn.udp 350 Intended usage: See Section 4. 352 Interoperability considerations: N/A 354 Security considerations: See Section 6. 356 Relevant publications: This document. 358 Contact information: Marc Petit-Huguenin 360 Author/Change controller: The IESG 362 7.5. turn.tcp Application Protocol Tag Registration 364 Application Protocol Tag: turn.tcp 366 Intended usage: See Section 4. 368 Interoperability considerations: 370 Security considerations: See Section 6. 372 Relevant publications: This document. 374 Contact information: Marc Petit-Huguenin 376 Author/Change controller: The IESG 378 7.6. turn.tls Application Protocol Tag Registration 380 Application Protocol Tag: turn.tls 382 Intended usage: See Section 4. 384 Interoperability considerations: N/A 386 Security considerations: See Section 6. 388 Relevant publications: This document. 390 Contact information: Marc Petit-Huguenin 392 Author/Change controller: The IESG 394 8. Running Code Considerations 396 o Zap [1]. Eilon Yardeni, 8x8 Inc. Implements version -00 398 9. Acknowledgements 400 Thanks to Eilon Yardeni, Dan Wing, Alfred Hoenes and Jim Kleck for 401 their comments, suggestions and questions that helped to improve this 402 document. 404 This document was written with the xml2rfc tool described in 405 [RFC2629]. 407 10. References 409 10.1. Normative References 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, March 1997. 414 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 415 specifying the location of services (DNS SRV)", RFC 2782, 416 February 2000. 418 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 419 Service Location Using SRV RRs and the Dynamic Delegation 420 Discovery Service (DDDS)", RFC 3958, January 2005. 422 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 423 Resource Identifier (URI): Generic Syntax", STD 66, 424 RFC 3986, January 2005. 426 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 427 Specifications: ABNF", STD 68, RFC 5234, January 2008. 429 [I-D.ietf-behave-turn] 430 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 431 Relays around NAT (TURN): Relay Extensions to Session 432 Traversal Utilities for NAT (STUN)", 433 draft-ietf-behave-turn-13 (work in progress), 434 February 2009. 436 10.2. Informative References 438 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 439 June 1999. 441 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 442 Registration Procedures for New URI Schemes", BCP 35, 443 RFC 4395, February 2006. 445 [I-D.wood-tae-specifying-uri-transports] 446 Wood, L., "Specifying transport mechanisms for retrieval 447 or delivery of URIs", 448 draft-wood-tae-specifying-uri-transports-04 (work in 449 progress), February 2009. 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 -01 and -00 461 o Fixed the contact email. 462 o Changed the IPR to trust200902. 463 o Added case for transport defined but unknown. 464 o Moved RFC 3958 to Normative References. 465 o Added study of [I-D.wood-tae-specifying-uri-transports] in TODO 466 list. 468 A.2. Design Notes 470 o The Application Service Tag is "RELAY" so other relaying 471 mechanisms than TURN (e.g., TWIST) can be registered as 472 Application Protocol Tags. 473 o S-NAPTR was preferred to U-NAPTR because there is no use case for 474 U-NAPTR. 475 o is not used in the URIs because it is deprecated. 476 is not used in the URIs because it is not used to guide 477 the resolution mechanism. 478 o As discussed in Dublin, there is no generic parameters in the URI 479 to prevent compatibity issues. 480 o Adding optional capabilities (IPv6 allocation, preserve bit, 481 etc...) in the resolution process was rejected at the Dublin 482 meeting. 484 A.3. TODO List 486 o Evaluate if [I-D.wood-tae-specifying-uri-transports] could be a 487 replacement for the ?transport= parameter. 489 Author's Address 491 Marc Petit-Huguenin 492 (Unaffiliated) 494 Email: petithug@acm.org