idnits 2.17.1 draft-ietf-behave-turn-uri-03.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 (August 19, 2009) is 5357 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) -- 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 (~~), 1 warning (==), 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 August 19, 2009 5 Expires: February 20, 2010 7 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers 8 draft-ietf-behave-turn-uri-03 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 February 20, 2010. 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 generate a list of server transport addresses that can be tried to 48 create a Traversal Using Relays around NAT (TURN) allocation. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Syntax of a TURN or TURNS URI . . . . . . . . . . . . . . . . 3 55 4. TURN or TURNS URI Resolution . . . . . . . . . . . . . . . . . 4 56 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 59 7.1. TURN URI Registration . . . . . . . . . . . . . . . . . . 8 60 7.2. TURNS URI Registration . . . . . . . . . . . . . . . . . . 8 61 7.3. RELAY Application Service Tag Registration . . . . . . . . 9 62 7.4. turn.udp Application Protocol Tag Registration . . . . . . 9 63 7.5. turn.tcp Application Protocol Tag Registration . . . . . . 10 64 7.6. turn.tls Application Protocol Tag Registration . . . . . . 10 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 69 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 11 70 A.1. Modifications between ietf-03 and ietf-02 . . . . . . . . 11 71 A.2. Modifications between ietf-02 and ietf-01 . . . . . . . . 12 72 A.3. Modifications between ietf-01 and ietf-00 . . . . . . . . 12 73 A.4. Modifications between petithuguenin-03 and ietf-00 . . . . 12 74 A.5. Modifications between petithuguenin-03 and 75 petithuguenin-02 . . . . . . . . . . . . . . . . . . . . . 12 76 A.6. Modifications between petithuguenin-02 and 77 petithuguenin-01 . . . . . . . . . . . . . . . . . . . . . 12 78 A.7. Modifications between petithuguenin-01 and 79 petithuguenin-00 . . . . . . . . . . . . . . . . . . . . . 13 80 A.8. Design Notes . . . . . . . . . . . . . . . . . . . . . . . 13 81 A.9. Running Code Considerations . . . . . . . . . . . . . . . 13 82 A.10. TODO List . . . . . . . . . . . . . . . . . . . . . . . . 13 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 The TURN specification [I-D.ietf-behave-turn] defines a process for a 88 TURN client to find TURN servers by using DNS SRV resource records, 89 but this process does not let the TURN server administrators 90 provision the preferred TURN transport protocol between the client 91 and the server and for the TURN client to discover this preference. 92 This document defines a S-NAPTR application [RFC3958] for this 93 purpose. This application defines "RELAY" as an application service 94 tag and "turn.udp", "turn.tcp", and "turn.tls" as application 95 protocol tags. 97 To simplify the provisioning of TURN clients, this document also 98 defines a TURN and a TURNS URI scheme and a resolution mechanism to 99 convert these URIs into a list of IP addresses, ports and TURN 100 transport protocols. 102 Another usage of the resolution mechanism described in this document 103 would be Remote Hosting as described in [RFC3958] section 4.4. For 104 example a VoIP provider who does not want to deploy TURN servers 105 could use the servers deployed by another company but could still 106 want to provide configuration parameters to its customers without 107 explicitly showing this relationship. The mechanism permits one to 108 implement this indirection, without preventing the company hosting 109 the TURN servers from managing them as it see fit. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 3. Syntax of a TURN or TURNS URI 119 A TURN/TURNS URI has the following ABNF syntax [RFC5234]: 121 turnURI = scheme ":" host [ ":" port ] [ "?transport=" transport ] 122 scheme = "turn" / "turns" 123 transport = "udp" / "tcp" / transport-ext 124 transport-ext = 1*unreserved 126 , and are specified in [RFC3986]. 128 4. TURN or TURNS URI Resolution 130 The URI resolution mechanism is used only to create an allocation. 131 All other transactions use the IP address, transport and port used 132 for a successful allocation creation. 134 The URI resolution algorithm uses , , and 135 as input. It also uses as input a list ordered by 136 preference of TURN transports (UDP, TCP, TLS) supported by the 137 application using the TURN client. The output of the algorithm is a 138 list of {IP address, transport, port} tuples that a TURN client can 139 try in order to create an allocation on a TURN server. 141 An Allocate error response as specified in section 6.4 of 142 [I-D.ietf-behave-turn] is processed as a failure as specified by 143 [RFC3958] section 2.2.4. The resolution stops when a TURN client 144 gets a successful Allocate response from a TURN server. After an 145 allocation succeeds or all the allocations fail, the resolution 146 context MUST be discarded and the URI resolution algorithm MUST be 147 restarted from the beginning for any subsequent allocation. Servers 148 blacklisted as described in section 6.4 of [I-D.ietf-behave-turn] 149 should not be used for the specified duration even if returned by a 150 subsequent resolution. 152 First the resolution algorithm checks that the URI can be resolved 153 with the list of TURN transports supported by the application: 155 o If is defined as "turn" and is defined as 156 "udp" but the list of TURN transports supported by the application 157 does not contain UDP then the resolution MUST stop with an error. 158 o If is defined as "turn" and is defined as 159 "tcp" but the list of TURN transports supported by the application 160 does not contain TCP then the resolution MUST stop with an error. 161 o If is defined as "turns" and is defined as 162 "udp" then the algorithm MUST stop with an error. 163 o If is defined as "turns" and is defined as 164 "tcp" but the list of TURN transports supported by the application 165 does not contain TLS then the resolution MUST stop with an error. 166 o If is defined as "turns" and is not defined 167 but the list of TURN transports supported by the application does 168 not contain TLS then the resolution MUST stop with an error. 169 o If is defined but unknown then the resolution MUST 170 stop with an error. 172 After verifying the validity of the URI elements, the algorithm 173 applies the steps described below. Note that in some steps, 174 and have to be converted to a TURN transport. If 175 is defined as "turn" and is defined as "udp" 176 then the TURN UDP transport is used. If is defined as 177 "turn" and is defined as "tcp" then the TURN TCP 178 transport is used. If is defined as "turns" and 179 is defined as "tcp" then the TURN TLS transport is used. This is 180 summarized in Table 1. 182 +----------+-------------+----------------+ 183 | | | TURN Transport | 184 +----------+-------------+----------------+ 185 | "turn" | "udp" | UDP | 186 | "turn" | "tcp" | TCP | 187 | "turns" | "tcp" | TLS | 188 +----------+-------------+----------------+ 190 Table 1 192 1. If is an IP address then it indicates the specific IP 193 address to be used. If is not defined, the default port 194 declared in [I-D.ietf-behave-turn] for the SRV service name 195 defined in is used. If is defined then 196 and are converted to a TURN transport as 197 specified in Table 1. If is not defined, the TURN 198 transports supported by the application are tried by preference 199 order. If the TURN client cannot contact a TURN server with this 200 IP address and port on any of the transports supported by the 201 application then the resolution MUST stop with an error. 203 2. If is a domain name and is defined, then is 204 resolved to a list of IP addresses via DNS A and AAAA queries. 205 If is defined, then and are 206 converted to a TURN transport as specified in Table 1. If 207 is not defined, the TURN transports supported by the 208 application are tried in preference order. If the TURN client 209 cannot contact a TURN server with this port and any combination 210 of transports supported by the application and resolved IP 211 addresses then the resolution MUST stop with an error. The TURN 212 client can choose the order to contact the resolved IP addresses 213 in any implementation-specific way. 215 3. If is a domain name and is not defined but 216 is defined, then is converted to a list of IP 217 address and port tuples via a DNS SRV query as defined in 218 [I-D.ietf-behave-turn] section 6.1. is used for the 219 service name and is used for the protocol name in the 220 SRV algorithm [RFC2782]. If the TURN client cannot contact a 221 TURN server at any of the IP address, port and transport tuples 222 returned by the SRV algorithm then the resolution MUST stop with 223 an error. The SRV algorithm recommends doing an A query if the 224 SRV query returns an error or no SRV RR. In this case the 225 default port declared in [I-D.ietf-behave-turn] for the SRV 226 service name defined in must be used for contacting the 227 TURN server. Also in this case, this specification modifies the 228 SRV algorithm by recommending an A and AAAA query. 230 4. If is a domain name and and are not 231 defined, then is converted to an ordered list of IP 232 address, port and transport tuples via the S-NAPTR algorithm 233 defined in [RFC3958] with a "RELAY" Application Service Tag. The 234 TURN transports supported by the application are converted in 235 Application Protocol Tags by using "turn.udp" if the TURN 236 transport is UDP, "turn.tcp" if the TURN transport is TCP and 237 "turn.tls" if the TURN transport is TLS. The order to try the 238 protocol tags is provided by the ranking of the first set of 239 NAPTR records. If multiple protocol tags have the same ranking, 240 the preferred order set by the application is used. If the TURN 241 client cannot contact a TURN server with any of the IP address, 242 port and transport tuples returned by the S-NAPTR algorithm, then 243 the resolution MUST stop with an error. If the first NAPTR SRV 244 query does not return any result then is converted to a 245 list of IP address and port tuples by using the algorithm 246 specified in step 3 for each of the TURN transports supported by 247 the application in order of preference. 249 5. Example 251 With the DNS RRs in Figure 1 and an ordered TURN transport list of 252 {TLS, TCP, UDP}, the resolution algorithm will convert the "turn: 253 example.com" URI to the list of IP addresses, port and protocol 254 tuples in Table 2. 256 example.com. 257 IN NAPTR 100 10 "" "RELAY:turn.udp" "" datagram.example.com. 258 IN NAPTR 200 10 "" "RELAY:turn.tcp:turn.tls" "" stream.example.com. 260 datagram.example.com. 261 IN NAPTR 100 10 "S" "RELAY:turn.udp" "" _udp._turn.example.com. 263 stream.example.com. 264 IN NAPTR 100 10 "S" "RELAY:turn.tcp" "" _turn._tcp.example.com. 265 IN NAPTR 200 10 "A" "RELAY:turn.tls" "" a.example.com. 267 _turn._udp.example.com. 268 IN SRV 0 0 3478 a.example.com. 270 _turn._tcp.example.com. 271 IN SRV 0 0 5000 a.example.com. 273 a.example.com. 274 IN A 192.0.2.1 276 Figure 1 278 +-------+----------+------------+------+ 279 | Order | Protocol | IP address | Port | 280 +-------+----------+------------+------+ 281 | 1 | UDP | 192.0.2.1 | 3478 | 282 | 2 | TLS | 192.0.2.1 | 5349 | 283 | 3 | TCP | 192.0.2.1 | 5000 | 284 +-------+----------+------------+------+ 286 Table 2 288 6. Security Considerations 290 Security considerations for TURN are discussed in 291 [I-D.ietf-behave-turn]. 293 The Application Service Tag and Application Protocol Tags defined in 294 this document do not introduce any specific security issues beyond 295 the security considerations discussed in [RFC3958]. 297 The "turn" and "turns" URI schemes do not introduce any specific 298 security issues beyond the security considerations discussed in 299 [RFC3986]. 301 7. IANA Considerations 303 This section contains the registration information for the "turn" and 304 "turns" URI Schemes (in accordance with [RFC4395]), one S-NAPTR 305 Application Service Tag, and three S-NAPTR Application Protocol Tags 306 (in accordance with [RFC3958]). 308 7.1. TURN URI Registration 310 URI scheme name: turn 312 Status: permanent 314 URI scheme syntax: See Section 3. 316 URI scheme semantics: See Section 4. 318 Encoding considerations: There are no encoding considerations beyond 319 those in [RFC3986]. 321 Applications/protocols that use this URI scheme name: 323 The "turn" URI scheme is intended to be used by applications that 324 might need access to a TURN server. 326 Interoperability considerations: N/A 328 Security considerations: See Section 6. 330 Contact: Marc Petit-Huguenin 332 Author/Change controller: The IESG 334 References: This document. 336 7.2. TURNS URI Registration 338 URI scheme name: turns 340 Status: permanent 342 URI scheme syntax: See Section 3. 344 URI scheme semantics: See Section 4. 346 Encoding considerations: There are no encoding considerations beyond 347 those in [RFC3986]. 349 Applications/protocols that use this URI scheme name: 351 The "turns" URI scheme is intended to be used by applications that 352 might need access to a TURN server. 354 Interoperability considerations: N/A 356 Security considerations: See Section 6. 358 Contact: Marc Petit-Huguenin 360 Author/Change controller: The IESG 362 References: This document. 364 7.3. RELAY Application Service Tag Registration 366 Application Protocol Tag: RELAY 368 Intended usage: See Section 4. 370 Interoperability considerations: N/A 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.4. turn.udp Application Protocol Tag Registration 382 Application Protocol Tag: turn.udp 384 Intended usage: See Section 4. 386 Interoperability considerations: N/A 388 Security considerations: See Section 6. 390 Relevant publications: This document. 392 Contact information: Marc Petit-Huguenin 394 Author/Change controller: The IESG 396 7.5. turn.tcp Application Protocol Tag Registration 398 Application Protocol Tag: turn.tcp 400 Intended usage: See Section 4. 402 Interoperability considerations: 404 Security considerations: See Section 6. 406 Relevant publications: This document. 408 Contact information: Marc Petit-Huguenin 410 Author/Change controller: The IESG 412 7.6. turn.tls Application Protocol Tag Registration 414 Application Protocol Tag: turn.tls 416 Intended usage: See Section 4. 418 Interoperability considerations: N/A 420 Security considerations: See Section 6. 422 Relevant publications: This document. 424 Contact information: Marc Petit-Huguenin 426 Author/Change controller: The IESG 428 8. Acknowledgements 430 Thanks to Dave Thaler, Alfred E. Heggestad, Eilon Yardeni, Dan Wing, 431 Alfred Hoenes and Jim Kleck for their comments, suggestions and 432 questions that helped to improve this document. 434 This document was written with the xml2rfc tool described in 435 [RFC2629]. 437 9. References 438 9.1. Normative References 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, March 1997. 443 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 444 specifying the location of services (DNS SRV)", RFC 2782, 445 February 2000. 447 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 448 Service Location Using SRV RRs and the Dynamic Delegation 449 Discovery Service (DDDS)", RFC 3958, January 2005. 451 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 452 Resource Identifier (URI): Generic Syntax", STD 66, 453 RFC 3986, January 2005. 455 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 456 Specifications: ABNF", STD 68, RFC 5234, January 2008. 458 [I-D.ietf-behave-turn] 459 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 460 Relays around NAT (TURN): Relay Extensions to Session 461 Traversal Utilities for NAT (STUN)", 462 draft-ietf-behave-turn-16 (work in progress), July 2009. 464 9.2. Informative References 466 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 467 June 1999. 469 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 470 Registration Procedures for New URI Schemes", BCP 35, 471 RFC 4395, February 2006. 473 URIs 475 [1] 477 [2] 479 Appendix A. Release notes 481 This section must be removed before publication as an RFC. 483 A.1. Modifications between ietf-03 and ietf-02 485 o A turn:?transport=TCP URI fails if the list of supported 486 transports contains only TLS. Using a TLS transport in this case 487 was underspecified. 488 o Reordered paragraphes in section 4. 489 o Added table for conversion of and to TURN 490 transport. 491 o Various editorial modifications. 492 o SRV algorithm changed to "...recommending an A and AAAA query." 493 o Put back the changelog for the versions before been accepted as WG 494 item. 496 A.2. Modifications between ietf-02 and ietf-01 498 o Shorten the abstract so it does not overflow on the second page. 499 o Added text to explicitly say that the resolution is only to create 500 an allocation. 501 o Added text about failures. 502 o Fixed the default port for TLS in the example. 503 o Changed some priority in the example for RFC3958 section 2.2.5. 504 o Fixed the service/protocol order for the SRV RR in the example. 505 o Removed reference to draft-wood-tae-specifying-uri-transports as 506 it has an experimental status. 508 A.3. Modifications between ietf-01 and ietf-00 510 o Fixed the contact email. 511 o Changed the IPR to trust200902. 512 o Added case for transport defined but unknown. 513 o Moved RFC 3958 to Normative References. 514 o Added study of draft-wood-tae-specifying-uri-transports in TODO 515 list. 517 A.4. Modifications between petithuguenin-03 and ietf-00 519 o Renamed the document to "draft-ietf-behave-turn-uri". 520 o Changed author affiliation. 521 o Fixed the text in the IANA considerations. 523 A.5. Modifications between petithuguenin-03 and petithuguenin-02 525 o Added Running Code Consideration section. 526 o Added Remote Hosting example in introduction. 527 o Changed back to opaque URIs because of [RFC4395] Section 2.2. Now 528 use "?" as separator. 530 o Added IANA considerations section. 531 o Added security considerations section. 533 A.6. Modifications between petithuguenin-02 and petithuguenin-01 535 o Receiving a successful Allocate response stops the resolution 536 mechanism and the resolution context must be discarded after this. 537 o Changed from opaque to hierarchical URIs because the ";" character 538 is used in . 539 o Various nits. 541 A.7. Modifications between petithuguenin-01 and petithuguenin-00 543 o Added in the ABNF. 544 o Use the and "literal" usages for free-form text defined 545 by [RFC5234]. 546 o Fixed various typos. 547 o Put the rule to convert and to a TURN 548 transport in a separate paragraph. 549 o Modified the SRV usage to be in line with RFC 2782. 550 o Clarified that the NAPTR protocol ranking must be used before the 551 application ranking. 552 o Added an example. 553 o Added release notes. 555 A.8. Design Notes 557 o The Application Service Tag is "RELAY" so other relaying 558 mechanisms than TURN (e.g., TWIST) can be registered as 559 Application Protocol Tags. 560 o S-NAPTR was preferred to U-NAPTR because there is no use case for 561 U-NAPTR. 562 o is not used in the URIs because it is deprecated. 563 is not used in the URIs because it is not used to guide 564 the resolution mechanism. 565 o As discussed in Dublin, there is no generic parameters in the URI 566 to prevent compatibity issues. 567 o Adding optional capabilities (IPv6 allocation, preserve bit, 568 etc...) in the resolution process was rejected at the Dublin 569 meeting. 571 A.9. Running Code Considerations 573 o Zap [1]. Eilon Yardeni, 8x8 Inc. Implements version -00 574 o Reference Implementation of TURN URI parser and resolver. [2]. 575 Marc Petit-Huguenin. Implements version -00 to -02 577 A.10. TODO List 579 (Empty) 581 Author's Address 583 Marc Petit-Huguenin 584 (Unaffiliated) 586 Email: petithug@acm.org