idnits 2.17.1 draft-petithuguenin-behave-turn-uris-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (February 2, 2012) is 4467 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) == Missing Reference: 'RFC2818' is mentioned on line 278, but not defined ** Obsolete undefined reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE M. Petit-Huguenin 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track S. Nandakumar 5 Expires: August 5, 2012 G. Salgueiro 6 P. Jones 7 Cisco Systems 8 February 2, 2012 10 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers 11 draft-petithuguenin-behave-turn-uris-00 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 that can be used to provision 18 the configuration values needed by the resolution mechanism defined 19 in [RFC5928]. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. This document may not be modified, 25 and derivative works of it may not be created, except to format it 26 for publication as an RFC or to translate it into languages other 27 than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 5, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Syntax of a TURN or TURNS URI . . . . . . . . . . . . . . . . 4 61 3.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 4 62 3.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 6 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 5.1. TURN URI Registration . . . . . . . . . . . . . . . . . . 7 66 5.2. TURNS URI Registration . . . . . . . . . . . . . . . . . . 8 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 71 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10 72 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . . 11 73 B.1. Merge of draft-nandakumar-rtcweb-turn-uri-00 and 74 draft-petithuguenin-behave-turn-uri-bis-05 . . . . . . . . 11 75 B.2. Modifications between petithuguenin-05 and 76 petithuguenin-04 . . . . . . . . . . . . . . . . . . . . . 11 77 B.3. Modifications between petithuguenin-04 and 78 petithuguenin-03 . . . . . . . . . . . . . . . . . . . . . 12 79 B.4. Modifications between petithuguenin-03 and 80 petithuguenin-02 . . . . . . . . . . . . . . . . . . . . . 12 81 B.5. Modifications between petithuguenin-02 and 82 petithuguenin-01 . . . . . . . . . . . . . . . . . . . . . 12 83 B.6. Modifications between petithuguenin-01 and 84 petithuguenin-00 . . . . . . . . . . . . . . . . . . . . . 12 85 B.7. Design Notes . . . . . . . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 This document specifies the syntax and semantics of the Uniform 91 Resource Identifier (URI) scheme for the Traversal Using Relays 92 around NAT (TURN) protocol. 94 The TURN protocol is a specification allowing hosts behind NAT to 95 control the operation of a relay server. The relay server allows 96 hosts to exchange packets with its peers. The peers themselves may 97 also be behind NATs. RFC 5766 [RFC5766] defines the specifics of the 98 TURN protocol. 100 The "turn/turns" URI scheme is used to designate a TURN server (also 101 known as a relay) on Internet hosts accessible using the TURN 102 protocol. With the advent of standards such as [WEBRTC], we 103 anticipate a plethora of endpoints and web applications to be able to 104 identify and communicate with such a TURN server to carry out the 105 TURN protocol. This also implies those endpoints and/or applications 106 to be provisioned with appropriate configuration required to identify 107 the TURN server. Having an inconsistent syntax has its drawbacks and 108 can result in non-interoperable solutions. It can result in 109 solutions that are ambiguous and have implementation limitations on 110 the different aspects of the syntax and alike. The "turn/turns" URI 111 scheme helps alleviate most of these issues by providing a consistent 112 way to describe, configure and exchange the information identifying a 113 TURN server. This would also prevent the shortcomings inherent with 114 encoding similar information in non-uniform syntaxes such as the ones 115 proposed in [WEBRTC], for example. 117 [RFC5928] defines a resolution mechanism to convert a secure flag, a 118 host name or IP address, an eventually empty port, and an eventually 119 empty transport to a list of IP address, port, and TURN transport 120 tuples. 122 To simplify the provisioning of TURN clients, this document defines a 123 TURN and a TURNS URI scheme that can carry the four components needed 124 for the resolution mechanism. 126 A reference implementation [REF-IMPL] is available. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" are 135 appropriate when valid exceptions to a general requirement are known 136 to exist or appear to exist, and it is infeasible or impractical to 137 enumerate all of them. However, they should not be interpreted as 138 permitting implementors to fail to implement the general requirement 139 when such failure would result in interoperability failure. 141 3. Syntax of a TURN or TURNS URI 143 3.1. URI Scheme Syntax 145 The "turn" URI takes the following form (the syntax below is non- 146 normative): 148 turn:@: 149 turns:@: 151 Note that with the "@" (at) sign character, as well as the 152 part and the preceding ":" (colon) character, is OPTIONAL. 154 A TURN/TURNS URI has the following formal ABNF syntax [RFC5234]: 156 turnURI = scheme ":" [ userinfo "@" ] turn-host 157 [ ":" turn-port ] [ "?transport=" transport ] 158 scheme = "turn" / "turns" 159 userinfo = user [ ":" password ] 160 user = 1*(%x21-24 / %x26-39 / %x3B-3F / %x41-7F 161 / escaped) 162 ; The symbols "%", ":", "@", and symbols 163 ; with a character value below 0x21 may 164 ; be represented as escaped sequences. 165 password = 1*(%x21-24 / %x26-3F / %x41-7F / escaped) 166 ; The symbols "%", "@", and symbols with 167 ; a character value below 0x21 may be 168 ; represented as escaped sequences. 169 transport = "udp" / "tcp" / transport-ext 170 transport-ext = 1*unreserved 171 turn-host = IP-literal / IPv4address / reg-name 172 turn-port = *DIGIT 173 IP-literal = "[" ( IPv6address / IPvFuture ) "]" 174 IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) 175 IPv6address = 6( h16 ":" ) ls32 176 / "::" 5( h16 ":" ) ls32 177 / [ h16 ] "::" 4( h16 ":" ) ls32 178 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 179 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 180 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 181 / [ *4( h16 ":" ) h16 ] "::" ls32 182 / [ *5( h16 ":" ) h16 ] "::" h16 183 / [ *6( h16 ":" ) h16 ] "::" 184 h16 = 1*4HEXDIG 185 ls32 = ( h16 ":" h16 ) / IPv4address 186 IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet 187 dec-octet = DIGIT ; 0-9 188 / %x31-39 DIGIT ; 10-99 189 / "1" 2DIGIT ; 100-199 190 / "2" %x30-34 DIGIT ; 200-249 191 / "25" %x30-35 ; 250-255 192 reg-name = *( unreserved / pct-encoded / sub-delims ) 193 escaped = "%" HEXDIG HEXDIG 195 , , and are specified in 196 [RFC3986]. 198 The , and components are passed without 199 modification to the [RFC5928] algorithm. is set to false if 200 is equal to "turn" and set to true if is equal to 201 "turns" and passed to the [RFC5928] algorithm with the other 202 components. The core rules , and are used 203 as described in Appendix B of RFC 5234 [RFC5234]. 205 The eventual and components are used as input for 206 the TURN [RFC5766] protocol itself. 208 3.2. URI Scheme Semantics 210 The TURN protocol supports sending messages over UDP, TCP or TLS- 211 over-TCP. The "turns" URI scheme SHALL be used when TURN is run over 212 TLS-over-TCP (or in the future DTLS-over-UDP) and the "turn" scheme 213 SHALL be used otherwise. 215 The required part of the "turn" URI denotes the TURN server 216 host. 218 The part identifies the credentials required for the long- 219 term credential mechanism as described in the section 10.2 of RFC 220 5389 [RFC5389]. 222 The part, if present, denotes the port on which the TURN 223 server is awaiting connection requests. If it is absent, the default 224 port SHALL be 3478 for both UDP and TCP. The default port for TURN 225 over TLS SHALL be 5349. 227 The part specifies the username and password. Both the 228 and values are UTF-8 encoded and escaped as per 229 section 2.5 of RFC 3986 [RFC3986]. 231 4. Security Considerations 233 Security considerations for the resolution mechanism are discussed in 234 [RFC5928]. 236 As described in Section 3.2.1 of STD 66 [RFC3986], having 237 authentication information (specifically passwords) in a URI means 238 that the URI must be handled carefully: 240 The passing of authentication information in clear text has proven 241 to be a security risk in almost every case where it has been used. 243 Section 3.2.1 contains advice on handling URI that contain passwords 244 in the userinfo portion. Implementations of this specification MUST 245 implement that advice. 247 Specifically if a URI that contains credentials leaks, then it would 248 allow an attacker to use the TURN server which is referenced by the 249 URI. Such an attack has two major impacts. First, it uses up the 250 operator's bandwidth. Second, if the operator bills the user for 251 TURN server usage, then it may expose the user to costs incurred by 252 the attacker. However, the attacker never obtains the user's private 253 information, nor does this attack allow for traffic amplification. 255 The expected use environment mitigates to some degree concerns about 256 TURN URIs compared to other URIs, such as HTTPS. First, users do not 257 dereference TURN URIs directly. Instead, they are passed to the TURN 258 stack. Thus, concerns about confusion or leakage due to the URI 259 being displayed to the user are significantly reduced; indeed the URI 260 need never be available to the user at all. 262 One of the primary use cases for a TURN URI with credentials is 263 WebRTC. In this case, a web server will be offering a calling 264 service and may have an associated TURN server it can use. In this 265 case, the browser will need to use the TURN server and the browser 266 has no long term or preexisting relationship with the TURN server. 267 The web server needs to provide some credential to the client which 268 it can use to access the TURN server. Since TURN authentication is 269 via username and password, this implies that the credential is a 270 username/password pair. While this must be transmitted securely 271 (i.e., over HTTPS), the security properties are the same whether the 272 password is carried separately or is part of the URL. Moreover, 273 because the web server and TURN servers can cooperate, a new password 274 can be issued for every call, making short-term credentials feasible 275 and thus significantly mitigating the risk. 277 If a TURN URI is transferred between hosts, it MUST be done over a 278 protocol that provides confidentiality such as HTTPS [RFC2818]. It 279 is RECOMMENDED that the credential only be valid for a single call 280 and preferably for no more than one day. That "preferably" is bad. 282 5. IANA Considerations 284 This section contains the registration information for the "turn" and 285 "turns" URI Schemes (in accordance with [RFC4395]). 287 5.1. TURN URI Registration 289 URI scheme name: turn 291 Status: permanent 293 URI scheme syntax: See Section 3. 295 URI scheme semantics: See [RFC5928]. 297 Encoding considerations: There are no encoding considerations beyond 298 those in [RFC3986]. 300 Applications/protocols that use this URI scheme name: 302 The "turn" URI scheme is intended to be used by applications that 303 might need access to a TURN server. 305 Interoperability considerations: N/A 307 Security considerations: See Section 4. 309 Contact: Marc Petit-Huguenin 311 Author/Change controller: The IESG 313 References: RFCXXXX 315 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 316 this specification, and remove this paragraph on publication.]] 318 5.2. TURNS URI Registration 320 URI scheme name: turns 322 Status: permanent 324 URI scheme syntax: See Section 3. 326 URI scheme semantics: See [RFC5928]. 328 Encoding considerations: There are no encoding considerations beyond 329 those in [RFC3986]. 331 Applications/protocols that use this URI scheme name: 333 The "turns" URI scheme is intended to be used by applications that 334 might need access to a TURN server over a secure connection. 336 Interoperability considerations: N/A 338 Security considerations: See Section 4. 340 Contact: Marc Petit-Huguenin 342 Author/Change controller: The IESG 344 References: RFCXXXX 346 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 347 this specification, and remove this paragraph on publication.]] 349 6. Acknowledgements 351 Thanks to Margaret Wasserman, Magnus Westerlund, Juergen 352 Schoenwaelder, Sean Turner, Ted Hardie, Dave Thaler, Alfred E. 353 Heggestad, Eilon Yardeni, Dan Wing, Alfred Hoenes, and Jim Kleck for 354 their comments, suggestions and questions that helped to improve the 355 draft-petithuguenin-behave-turn-uri-bis document. 357 Many thanks to Cullen Jennings for his detailed review and thoughtful 358 comments on the draft-nandakumar-rtcweb-turn-uri document. 360 The and ABNF productions have been copied 361 from the and ABNF productions from [RFC3986]. 363 This document was written with the xml2rfc tool described in 364 [RFC2629]. 366 7. References 368 7.1. Normative References 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, March 1997. 373 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 374 Resource Identifier (URI): Generic Syntax", STD 66, 375 RFC 3986, January 2005. 377 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 378 Specifications: ABNF", STD 68, RFC 5234, January 2008. 380 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 381 Relays around NAT (TURN): Relay Extensions to Session 382 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 384 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT 385 (TURN) Resolution Mechanism", RFC 5928, August 2010. 387 7.2. Informative References 389 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 390 June 1999. 392 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 393 Registration Procedures for New URI Schemes", BCP 35, 394 RFC 4395, February 2006. 396 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 397 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 398 October 2008. 400 [RFC5769] Denis-Courmont, R., "Test Vectors for Session Traversal 401 Utilities for NAT (STUN)", RFC 5769, April 2010. 403 [WEBRTC] W3C, "WebRTC 1.0: Real-time Communication Between 404 Browsers". 406 . 408 [REF-IMPL] 409 Petit-Huguenin, MPH., "Reference Implementation of TURN 410 resolver and TURN URI parser". 412 . 415 Appendix A. Examples 417 Table 1 shows how the , and components are 418 populated from various URIs. For all these examples, the 419 component is populated with "example.org". 421 +---------------------------------+----------+--------+-------------+ 422 | URI | | | | 423 +---------------------------------+----------+--------+-------------+ 424 | turn:example.org | false | | | 425 | turn:user:pwd@example.org | false | | | 426 | turns:example.org | true | | | 427 | turns:user:pwd@example.org | true | | | 428 | turn:example.org:8000 | false | 8000 | | 429 | turn:example.org?transport=udp | false | | UDP | 430 | turn:example.org?transport=tcp | false | | TCP | 431 | turns:example.org?transport=tcp | true | | TLS | 432 +---------------------------------+----------+--------+-------------+ 434 Table 1 436 Table 2 shows how the , and components 437 are populated from various URIs. For all the examples, the secure 438 component is populated with false and the port and transport 439 components are empty. 441 +---------------------------+------------+------------+-------------+ 442 | URI | | | | 443 +---------------------------+------------+------------+-------------+ 444 | turn:example.org | | | example.org | 445 | turn:192.0.2.1 | | | 192.0.2.1 | 446 | turn:[2001:DB8::1] | | | 2001:DB8::1 | 447 | turn:user@example.org | user | | example.org | 448 | turn:user:pwd@example.org | user | pwd | example.org | 449 +---------------------------+------------+------------+-------------+ 451 Table 2 453 The following example produces the username and password used as 454 example in section 2.4 of [RFC5769]: 456 turn:%E3%83%9E%E3%83%88%E3%83%AA%E3%83%83%E3%82%AF%E3%82%B9:The%C2% 457 ADM%C2%AAtr%E2%85%A8@example.org 459 Appendix B. Release notes 461 This section must be removed before publication as an RFC. 463 B.1. Merge of draft-nandakumar-rtcweb-turn-uri-00 and 464 draft-petithuguenin-behave-turn-uri-bis-05 466 o Changed author list. 467 o Draft is now standard track. 468 o Merged abstract, introduction, acknowledgement and security 469 sections. 470 o Added two introductory paragraphs to the beginning iof the 471 introduction. 472 o Took Section 3 and divided it into Section 3.1 URI Scheme Syntax 473 and Section 3.2 URI Scheme Semantics. 474 o Explained that most components are passed as is to RFC 5928. 475 o Added username and password in ABNF. 476 o Added RFC 5389 as reference. 477 o Added examples. 478 o Updated design notes. 479 o Various minor nits and grammatical issues fixed. 481 B.2. Modifications between petithuguenin-05 and petithuguenin-04 483 o Nits. 484 o Fixed schemes registration. 486 B.3. Modifications between petithuguenin-04 and petithuguenin-03 488 o Fixed references code link. 490 B.4. Modifications between petithuguenin-03 and petithuguenin-02 492 o Updated RFC references. 494 B.5. Modifications between petithuguenin-02 and petithuguenin-01 496 o Nits. 498 B.6. Modifications between petithuguenin-01 and petithuguenin-00 500 o Shorten I-D references. 502 B.7. Design Notes 504 o As discussed in Dublin, there is no generic parameters in the URI 505 to prevent compatibity issues. 507 Authors' Addresses 509 Marc Petit-Huguenin 510 Unaffiliated 512 Email: petithug@acm.org 514 Suhas Nandakumar 515 Cisco Systems 516 170 West Tasman Drive 517 San Jose, CA 95134 518 US 520 Email: snandaku@cisco.com 522 Gonzalo Salgueiro 523 Cisco Systems 524 7200-12 Kit Creek Road 525 Research Triangle Park, NC 27709 526 US 528 Email: gsalguei@cisco.com 529 Paul E. Jones 530 Cisco Systems 531 7025 Kit Creek Road 532 Research Triangle Park, NC 27709 533 US 535 Email: paulej@packetizer.com