idnits 2.17.1 draft-petithuguenin-behave-turn-uris-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5928]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 27, 2013) is 3856 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 normative reference: RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE M. Petit-Huguenin 3 Internet-Draft Impedance Mismatch 4 Intended status: Standards Track S. Nandakumar 5 Expires: March 31, 2014 G. Salgueiro 6 P. Jones 7 Cisco Systems 8 September 27, 2013 10 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers 11 draft-petithuguenin-behave-turn-uris-08 13 Abstract 15 This document specifies the syntax of Uniform Resource Identifier 16 (URI) schemes for the Traversal Using Relays around NAT (TURN) 17 protocol. It defines two URI schemes to provision the TURN 18 Resolution Mechanism [RFC5928]. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 31, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Definitions of the TURN and TURNS URI . . . . . . . . . . . . 3 57 3.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 3 58 3.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . 4 59 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 4 60 4.1. turnuri . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2. libjingle . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.3. Firefox . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 6.1. TURN URI Registration . . . . . . . . . . . . . . . . . . 6 66 6.2. TURNS URI Registration . . . . . . . . . . . . . . . . . 7 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 8.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 9 72 Appendix B. Design Notes . . . . . . . . . . . . . . . . . . . . 9 73 Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 10 74 C.1. Modifications between petithuguenin-behave-turn-uris-08 75 and petithuguenin-behave-turn-uris-07 . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 This document specifies the syntax and semantics of the Uniform 81 Resource Identifier (URI) scheme for the Traversal Using Relays 82 around NAT (TURN) protocol. 84 The TURN protocol is a specification allowing hosts behind NAT to 85 control the operation of a relay server. The relay server allows 86 hosts to exchange packets with its peers. The peers themselves may 87 also be behind NATs. RFC 5766 [RFC5766] defines the specifics of the 88 TURN protocol. 90 The "turn" and "turns" URI schemes are used to designate a TURN 91 server (also known as a relay) on Internet hosts accessible using the 92 TURN protocol. With the advent of standards such as [WEBRTC], we 93 anticipate a plethora of endpoints and web applications to be able to 94 identify and communicate with such a TURN server to carry out the 95 TURN protocol. This also implies those endpoints and/or applications 96 to be provisioned with appropriate configuration required to identify 97 the TURN server. Having an inconsistent syntax has its drawbacks and 98 can result in non-interoperable solutions. It can result in 99 solutions that are ambiguous and have implementation limitations on 100 the different aspects of the syntax and alike. The "turn/turns" URI 101 scheme helps alleviate most of these issues by providing a consistent 102 way to describe, configure and exchange the information identifying a 103 TURN server. This would also prevent the shortcomings inherent with 104 encoding similar information in non-uniform syntaxes such as the ones 105 proposed in [WEBRTC], for example. 107 [RFC5928] defines a resolution mechanism to convert a secure flag, a 108 host name or IP address, a potentially empty port, and a potentially 109 empty transport to a list of IP address, port, and TURN transport 110 tuples. 112 To simplify the provisioning of TURN clients, this document defines a 113 TURN and a TURNS URI scheme that can carry the four components needed 114 for the resolution mechanism. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" 119 in this document are to be interpreted as described in [RFC2119] when 120 they appear in ALL CAPS. When these words are not in ALL CAPS (such 121 as "should" or "Should"), they have their usual English meanings, and 122 are not to be interpreted as RFC 2119 key words. 124 3. Definitions of the TURN and TURNS URI 126 3.1. URI Scheme Syntax 128 A TURN/TURNS URI has the following formal ABNF syntax [RFC5234]: 130 turnURI = scheme ":" host [ ":" port ] 131 [ "?transport=" transport ] 132 scheme = "turn" / "turns" 133 transport = "udp" / "tcp" / transport-ext 134 transport-ext = 1*unreserved 136 , and are specified in [RFC3986]. While these two ABNF 137 productions are defined in [RFC3986] as components of the generic 138 hierarchical URI, this does not imply that that the turn and turns 139 schemes are hierarchical URIs. Developers MUST NOT use a generic 140 hierarchical URI parser to parse a turn or turns URI. 142 The , and components are passed without 143 modification to the [RFC5928] algorithm. is set to false if 144 is equal to "turn" and set to true if is equal to 145 "turns" and passed to the [RFC5928] algorithm with the other 146 components. 148 3.2. URI Scheme Semantics 150 The "turn" and "turns" URI schemes are used to designate a TURN 151 server (also known as a relay) on Internet hosts accessible using the 152 TURN protocol. The TURN protocol supports sending messages over UDP, 153 TCP or TLS-over-TCP. The "turns" URI scheme MUST be used when TURN 154 is run over TLS-over-TCP (or in the future DTLS-over-UDP) and the 155 "turn" scheme MUST be used otherwise. 157 The required part of the "turn" URI denotes the TURN server 158 host. 160 As specified in [RFC5766] and [RFC5928], the part, if present, 161 denotes the port on which the TURN server is awaiting connection 162 requests. If it is absent, the default port is 3478 for both UDP and 163 TCP. The default port for TURN over TLS is 5349. 165 4. Implementation Status 167 Note to RFC Editor: Please remove this section and the reference to 168 [RFC6982] before publication. 170 This section records the status of known implementations of the 171 protocol defined by this specification at the time of posting of this 172 Internet-Draft, and is based on a proposal described in [RFC6982]. 173 The description of implementations in this section is intended to 174 assist the IETF in its decision processes in progressing drafts to 175 RFCs. Please note that the listing of any individual implementation 176 here does not imply endorsement by the IETF. Furthermore, no effort 177 has been spent to verify the information presented here that was 178 supplied by IETF contributors. This is not intended as, and must not 179 be construed to be, a catalog of available implementations or their 180 features. Readers are advised to note that other implementations may 181 exist. 183 According to [RFC6982], "this will allow reviewers and working groups 184 to assign due consideration to documents that have the benefit of 185 running code, which may serve as evidence of valuable experimentation 186 and feedback that have made the implemented protocols more mature. 187 It is up to the individual working groups to use this information as 188 they see fit". 190 4.1. turnuri 191 Organization: Impedance Mismatch 193 Name: turnuri 0.3.4 http://debian.implementers.org/stable/source/ 194 turnuri.tar.gz 196 Description: A reference implementation of this document and of RFC 197 5928 [RFC5928]. 199 Level of maturity: Beta. 201 Coverage: Fully implements this specification and RFC 5928. 203 Licensing: AGPL3 205 Contact: Marc Petit-Huguenin . 207 4.2. libjingle 209 Organization: Google Inc. 211 Name: libjingle revision 4831 https://code.google.com/p/chromium/ 212 codesearch#chromium/src/third_party/libjingle/source/talk/app/ 213 webrtc/peerconnection.cc 215 Description: Libjingle is a set of components provided by Google to 216 implement Jingle protocols XEP-166 (http://xmpp.org/extensions/ 217 xep-0166.html) and XEP-167 (http://xmpp.org/extensions/ 218 xep-0167.html). 220 Level of maturity: Beta. 222 Coverage: Implements draft-petithuguenin-behave-turn-uris-07 223 without IPv6. The turn and turns schemes are parsed, and TLS is 224 used when the secure bit is set. The libjingle library does not 225 use the SRV and NAPTR RR from the RFC 5928 resolution mechanism. 227 Licensing: BSD 3-clauses license. 229 Contact: https://code.google.com/p/chromium/ 231 4.3. Firefox 233 Organization: Mozilla 235 Name: Firefox Aurora 21 http://hg.mozilla.org/mozilla-central/rev/ 236 6b5016ab9ebb 238 Description: Mozilla Firefox is a free and open source web browser. 240 Level of maturity: Beta. 242 Coverage: Implements draft-petithuguenin-behave-turn-uri-03 without 243 RFC 5928. The mozilla code parses the turn and turns schemes but 244 does not seems to use TLS. 246 Licensing: Mozilla Public License, v2.0. 248 Contact: http://www.mozilla.org/en-US/firefox/channel/ 250 5. Security Considerations 252 Security considerations for the resolution mechanism are discussed in 253 Section 5 of [RFC5928]. Note that this section contains normative 254 text defining authentication procedures to be followed by turn 255 clients when TLS is used. 257 The "turn" and "turns" URI schemes do not introduce any specific 258 security issues beyond the security considerations discussed in 259 [RFC3986]. 261 While the turn and turns URIs do not themselves include the username 262 or password that will be used to authenticate the TURN client, in 263 certain environments, such as WebRTC, the username and password will 264 almost certainly be provisioned remotely by an external agent at the 265 same time as a turns URI is sent to that client. Thus, in such 266 situations, if the username and password were received in clear there 267 would be little or no benefit to using a turns URI. For this reason 268 a TURN client MUST ensure that the username, password, and turns URI 269 and any other security-relevant parameters are received with 270 equivalent security before using the turns URI. Receiving those 271 parameters over another TLS session can provide the appropriate level 272 of security, if both TLS sessions are similarly parameterised, e.g. 273 with commensurate strength ciphersuites. 275 6. IANA Considerations 277 This section contains the registration information for the "turn" and 278 "turns" URI Schemes (in accordance with [RFC4395]). 280 6.1. TURN URI Registration 282 URI scheme name: turn 284 Status: permanent 286 URI scheme syntax: See Section 3.1. 288 URI scheme semantics: See Section 3.2. 290 Encoding considerations: There are no encoding considerations beyond 291 those in [RFC3986]. 293 Applications/protocols that use this URI scheme name: 295 The "turn" URI scheme is intended to be used by applications with 296 a need to identify a TURN server to be used for NAT traversal. 298 Interoperability considerations: N/A 300 Security considerations: See Section 5. 302 Contact: Marc Petit-Huguenin 304 Author/Change controller: The IESG 306 References: RFCXXXX 308 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 309 this specification, and remove this paragraph on publication.]] 311 6.2. TURNS URI Registration 313 URI scheme name: turns 315 Status: permanent 317 URI scheme syntax: See Section 3.1. 319 URI scheme semantics: See Section 3.2. 321 Encoding considerations: There are no encoding considerations beyond 322 those in [RFC3986]. 324 Applications/protocols that use this URI scheme name: 326 The "turns" URI scheme is intended to be used by applications with 327 a need to identify a TURN server to be used for NAT traversal over 328 a secure connection. 330 Interoperability considerations: N/A 332 Security considerations: See Section 5. 334 Contact: Marc Petit-Huguenin 335 Author/Change controller: The IESG 337 References: RFCXXXX 339 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 340 this specification, and remove this paragraph on publication.]] 342 7. Acknowledgements 344 Thanks to Margaret Wasserman, Magnus Westerlund, Juergen 345 Schoenwaelder, Sean Turner, Ted Hardie, Dave Thaler, Alfred E. 346 Heggestad, Eilon Yardeni, Dan Wing, Alfred Hoenes, and Jim Kleck for 347 the comments, suggestions and questions that helped improve the 348 draft-petithuguenin-behave-turn-uri-bis document. 350 Many thanks to Cullen Jennings for his detailed review and thoughtful 351 comments on the draft-nandakumar-rtcweb-turn-uri document. 353 Thanks to Bjoern Hoehrmann, Dan Wing, Russ Housley, S. Moonesamy, 354 Graham Klyne, Harald Alvestrand, Hadriel Kaplan, Tina Tsou, Spencer 355 Dawkins, Ted Lemon, Barry Leiba, Pete Resnick, and Stephen Farrell 356 for the comments, suggestions and questions that helped improve this 357 document. 359 The authors would also like to express their gratitude to Dan Wing 360 for his assistance in shepherding this document. We also want to 361 thank Gonzalo Camarillo, the Real-time Applications and 362 Infrastructure Director, for sponsoring this document as well his 363 careful reviews. 365 8. References 367 8.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 373 Resource Identifier (URI): Generic Syntax", STD 66, RFC 374 3986, January 2005. 376 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 377 Specifications: ABNF", STD 68, RFC 5234, January 2008. 379 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 380 Relays around NAT (TURN): Relay Extensions to Session 381 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 383 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT 384 (TURN) Resolution Mechanism", RFC 5928, August 2010. 386 8.2. Informative References 388 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 389 Registration Procedures for New URI Schemes", BCP 35, RFC 390 4395, February 2006. 392 [WEBRTC] Bergkvist, A., Burnett, D., Jennings, C., and A. 393 Narayanan, "WebRTC 1.0: Real-time Communication Between 394 Browsers", World Wide Web Consortium WD WD- 395 webrtc-20120821, August 2012, 396 . 398 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 399 Code: The Implementation Status Section", RFC 6982, July 400 2013. 402 Appendix A. Examples 404 Table 1 shows how the , and components are 405 populated from various URIs. For all these examples, the 406 component is populated with "example.org". 408 +---------------------------------+----------+--------+-------------+ 409 | URI | | | | 410 +---------------------------------+----------+--------+-------------+ 411 | turn:example.org | false | | | 412 | turns:example.org | true | | | 413 | turn:example.org:8000 | false | 8000 | | 414 | turn:example.org?transport=udp | false | | UDP | 415 | turn:example.org?transport=tcp | false | | TCP | 416 | turns:example.org?transport=tcp | true | | TLS | 417 +---------------------------------+----------+--------+-------------+ 419 Table 1 421 Appendix B. Design Notes 423 o One recurring comment was to stop using the suffix "s" on URI 424 scheme, and to move the secure option to a parameter (e.g. 425 ";proto=tls"). We decided against this idea because the STUN URI 426 does not have a ";proto=" parameter and we would have lost the 427 symmetry between the TURN and STUN URIs. A more detailed account 428 of the reasoning behind this is available at 432 o Following the advice of RFC 4395 section 2.2., and because the 433 TURN URI does not describe a hierarchical structure, the TURN URIs 434 are opaque URIs. 436 o is not used in the URIs because it is deprecated 437 [RFC3986]. and are not used in the URIs because 438 they do not guide the resolution mechanism. 440 o As discussed at IETF 72 in Dublin, there is no generic parameters 441 in the URI to prevent compatibility issues. 443 Appendix C. Release notes 445 This section must be removed before publication as an RFC. 447 C.1. Modifications between petithuguenin-behave-turn-uris-08 and 448 petithuguenin-behave-turn-uris-07 450 o s/eventually/potentially/ 452 o Changed the ABNF to use references from RFC 3986 instead of 453 copying them. 455 o Converted the design note about hierarchical parsers into a MUST 456 NOT statement. 458 o Updated the RFC 6982 forms for Chrome and Firefox. 460 o Added text in security section about verifying that username, 461 password and uris are received over a secure connection. 463 Authors' Addresses 465 Marc Petit-Huguenin 466 Impedance Mismatch 468 Email: petithug@acm.org 470 Suhas Nandakumar 471 Cisco Systems 472 170 West Tasman Drive 473 San Jose, CA 95134 474 US 476 Email: snandaku@cisco.com 477 Gonzalo Salgueiro 478 Cisco Systems 479 7200-12 Kit Creek Road 480 Research Triangle Park, NC 27709 481 US 483 Email: gsalguei@cisco.com 485 Paul E. Jones 486 Cisco Systems 487 7025 Kit Creek Road 488 Research Triangle Park, NC 27709 489 US 491 Email: paulej@packetizer.com