idnits 2.17.1 draft-johnston-tram-stun-origin-03.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 : ---------------------------------------------------------------------------- No issues found here. 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 (June 28, 2014) is 3588 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 (-19) exists of draft-ietf-rtcweb-overview-10 == Outdated reference: A later version (-05) exists of draft-ietf-tram-auth-problems-01 ** Downref: Normative reference to an Informational draft: draft-ietf-tram-auth-problems (ref. 'I-D.ietf-tram-auth-problems') ** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389) ** Obsolete normative reference: RFC 4020 (Obsoleted by RFC 7120) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) ** Downref: Normative reference to an Experimental RFC: RFC 5780 ** Obsolete normative reference: RFC 6122 (Obsoleted by RFC 7622) ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942) -- Possible downref: Non-RFC (?) normative reference: ref. 'WebRTC-API' Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Johnston 3 Internet-Draft Avaya 4 Intended status: Standards Track J. Uberti 5 Expires: December 30, 2014 Google 6 J. Yoakum 7 K. Singh 8 Avaya 9 June 28, 2014 11 An Origin Attribute for the STUN Protocol 12 draft-johnston-tram-stun-origin-03 14 Abstract 16 STUN, or Session Traversal Utilities for NAT, is a protocol used to 17 assist other protocols traverse Network Address Translators or NATs. 18 STUN, and STUN extensions such as TURN, or Traversal Using Relays 19 around NAT, and ICE, Interactive Communications Establishment, have 20 been around for many years but with WebRTC, Web Real-Time 21 Communications, STUN and related extensions are about to see major 22 deployments and implementation due to these protocols being 23 implemented in browsers. This specification defines an ORIGIN 24 attribute for STUN that can be used in similar ways to the HTTP 25 header field of the same name. WebRTC browsers utilizing STUN and 26 TURN would include this attribute which would provide servers with 27 additional information about the STUN and TURN requests they receive. 28 This specification defines the usage of the STUN ORIGIN attribute for 29 web and SIP contexts. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 30, 2014. 48 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 66 2. STUN ORIGIN attribute . . . . . . . . . . . . . . . . . . . . 5 67 2.1. STUN Usage . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.2. TURN Usage . . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.3. NAT Behavior Discovery Usage . . . . . . . . . . . . . . . 7 70 2.4. ICE Usage . . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.5. Media Keep-Alive Usage . . . . . . . . . . . . . . . . . . 7 72 2.6. SIP Keep-Alive Usage . . . . . . . . . . . . . . . . . . . 7 73 2.7. Multiple Origins . . . . . . . . . . . . . . . . . . . . . 7 74 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 78 7. Normative References . . . . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 STUN, or Session Traversal Utilities for NAT, is a protocol used to 84 assist other protocols traverse Network Address Translators or NATs. 85 TURN, or Traversal Using Relays around NAT [RFC5766], is a STUN 86 extension [RFC5389] that allows endpoints to acquire a relayed 87 address for media flows. It is most commonly used in conjunction 88 with ICE, Interactive Connectivity Establishment [RFC5245], which is 89 used to establish peer-to-peer flows between endpoints through NATs 90 and firewalls. 92 STUN defines three authentication modes, depending on the STUN usage. 93 For STUN binding requests sent between peers, such as for ICE 94 connectivity checks, a short term authentication method is 95 recommended. Each peer contributes random strings which are 96 exchanged over signaling and used to authenticate the connectivity 97 checks. For TURN, a usage of STUN used to acquire and refresh relay 98 addresses, a long term authentication method is recommended. This 99 authentication is similar to SIP Digest [RFC3261], which involves an 100 authentication challenge for each request. A server, upon receipt of 101 a TURN request, generates an authentication challenge that includes a 102 realm and nonce. The client resends the TURN request supplying a 103 user name and password based on the realm indicated by the server. 104 For a STUN binding request sent to a STUN server, no authentication 105 is recommended, as generating the response is less work for a server 106 than the server utilizing the short term or long term authentication 107 approach. In addition, the resource requirements of operating a STUN 108 server are minimal. 110 WebRTC, Web Real-Time Communications, adds peer-to-peer real-time, 111 interactive voice and video media capabilities and data channels to 112 browsers [I-D.ietf-rtcweb-overview] without a plugin or download, and 113 allows web developers to access this functionality using JavaScript 114 API calls [WebRTC-API]. WebRTC includes STUN, TURN, and ICE client 115 functionality built into browsers. For a session established between 116 two browsers, if either browser is behind a NAT, a STUN server is 117 necessary. Public STUN servers are currently available and a web 118 application can suggest a particular STUN server be used. In other 119 cases, a TURN server is needed to establish a peer connection. In 120 this case, TURN credentials need to be available to the browser for 121 the long term authentication approach. A TURN server for WebRTC 122 might serve a number of different domains and realms. 124 From the perspective of the web application provider, providing 125 service for a number of different domains and realms, it is useful to 126 know something about the source of the STUN request when processing 127 the request. For a web application provider STUN or TURN server, the 128 server will have no idea which web pages or sites are sending binding 129 requests to the service. In conventional applications, the SOFTWARE 130 attribute would provide some identifying information to the service, 131 but that no longer works when the browser is the application. For a 132 web application provider TURN server, the TURN server does not know 133 which realm to include in an authentication challenge. 135 In the web world, HTTP requests have the concept of origin. The 136 origin of a web page, as defined in [RFC6454], is defined by the 137 URI's scheme, host or IP address, and port portions. The HTTP Origin 138 header field inserted by the web browser carries this information and 139 is useful information for servers that receive HTTP requests 140 generated via JavaScript. For example, Cross Origin Resource 141 Sharing, CORS, allows an HTTP server to serve HTTP requests from 142 multiple origins. 144 This specification proposes extending the origin concept to STUN 145 requests. STUN requests generated by a web browser would include the 146 origin of the HTTP page that is initiating the Peer Connection. 147 Using this extra information, a STUN server could use the origin to 148 determine which STUN binding requests to respond to, reducing the 149 load on a STUN server. Using this information, a TURN server could 150 use the origin to determine which realm to include in the 151 authentication challenge. A TURN server can also use the origin 152 information for logging and analytics, and also as additional 153 information after authentication for providing service. 155 An important use case that the STUN Origin helps solve is the 156 operation of a multi-tenanted TURN server (i.e. a TURN server that 157 serves multiple, perhaps tens of thousands of different domains). 158 The problem associated with this use case is described in Section 4.5 159 of [I-D.ietf-tram-auth-problems]. While it is possible for a TURN 160 server to use the same authentication credentials across many 161 domains, a more likely (and more manageable) scenario is to have 162 separate credentials for each domain, and hence a different realm for 163 each domain. To implement this, a TURN server needs to know which 164 realm to include in authentication challenge to TURN clients. One 165 way to do this would be to create a unique TURN URI for each realm. 166 This would require either a separate IP address or port for each 167 realm, and this unique URI would need to be correctly provisioned by 168 each domain (i.e. included in JavaScript, which then could not be 169 copied between domains). Clearly, this doesn't scale for hundreds or 170 thousands of domains. Origin information solves this problem since 171 TURN requests will contain the domain in the Origin attribute. The 172 TURN server just needs to be configured with a mapping between a 173 domain (conveyed in the Origin) and the realm string (to be used in 174 the authentication challenge). Thus, a single TURN URI could be used 175 across all domains, and the resulting JavaScript code would be 176 portable. There is no need for thousands of IP addresses or ports to 177 be allocated and managed. 179 It has been suggested that this origin insight is not needed if the 180 server_name TLS extension in [RFC6066] is supported. This extension 181 allows a TLS client to provide to the TLS server the name of the 182 server they are contacting. In this case, the STUN or TURN client 183 using TLS transport would provide the domain from the TURN server URI 184 during the TLS client hello, allowing the TURN server to respond with 185 the appropriate server certificate. For the TURN server domain to be 186 used by the TURN server to choose the appropriate realm, this would 187 require a unique TURN URI to be provisioned per realm. This is not 188 scalable for supporting thousands of realms. Also, this URI would 189 need to be provisioned in the JavaScript, making the resulting code 190 non-portable. Finally, [RFC6066] provides no help for UDP or TCP 191 transport, which are the most commonly used transports today for STUN 192 and TURN. 194 Another approach that could be pursued is for the client to be 195 explicitly provisioned with a realm value, to which its username and 196 password are scoped. When using the long-term authentication method 197 to authenticate to a TURN server, the client would include this REALM 198 value in the initial, unauthorized requests, allowing the TURN server 199 to know which REALM to use in its authorization challenge. This 200 approach avoids many of the issues with the RFC 6066 approach, but it 201 still requires the realm value to be explicitly provisioned in 202 Javascript. In addition, it does not work in unauthenticated usages, 203 i.e. STUN binding requests sent to a STUN server. 205 Note that the origin information is most useful as a hint in initial 206 STUN and TURN requests as received by a server. However, origin 207 information still has value throughout the session even after 208 authentication for logging and other purposes. 210 The following sections of this document define the STUN ORIGIN 211 attribute and define its usage. 213 1.1. Requirements Language 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 217 document are to be interpreted as described in RFC 2119 [RFC2119]. 219 2. STUN ORIGIN attribute 221 This specification defines how to apply the web origin concept and 222 syntax of [RFC6454] to the STUN protocol. 224 This specification defines a new Attribute to the STUN protocol 225 [RFC5389]. The attribute is called ORIGIN and uses the syntax 226 defined in Section 15 of [RFC5389]. The number used for this in the 227 type field is 0x802F, chosen in the comprehension optional range. 228 The value of ORIGIN is a variable-length value. It MUST contain a 229 UTF-8 [RFC3629] encoded sequence of characters less than 268 bytes. 230 The value of 268 is chosen to be larger than the maximum 253 231 character domain name plus 8 characters for the URI scheme plus 5 232 characters for the port number. Senders MAY include multiple ORIGIN 233 attributes in a request, and receivers MUST support parsing and 234 receiving multiple ORIGIN attributes. 236 Editor's Note: At the appropriate time, the authors will work with 237 the chairs of TRAM to follow [RFC4020] procedures to ensure that no 238 attribute collisions occur while running code is being developed and 239 tested. 241 For a web browser (HTTP User Agent), the contents of the ORIGIN 242 attribute is the unicode-serialization of an origin defined in 243 Section 6.1 of [RFC6454]. The origin value included is the same as 244 the Origin header field for an HTTP request generated from the web 245 page that is creating the Peer Connection. It does not include any 246 string terminating (\x00) character in the serialization. To ensure 247 backwards compatibility with [RFC3489], the ORIGIN attribute is 248 padded to ensure its length is a multiple of 4 octets. 250 For a SIP User Agent [RFC3261] using STUN and TURN, the ORIGIN 251 attribute is set to be the URI of the registrar server used by the 252 User Agent (i.e. the Request-URI of a REGISTER method). 254 For a Jabber client [RFC6120] using STUN and TURN, the ORIGIN 255 attribute is the Jabber ID (JID) [RFC6122] of the Jabber Server that 256 the client is using. 258 Other contexts can define a usage of the ORIGIN attribute to use an 259 appropriate URI or URL. 261 If an ORIGIN attribute is not present in a request, it is up to the 262 server how to handle the request. For example, it could assume a 263 default Origin. 265 2.1. STUN Usage 267 For STUN requests sent without authentication to a STUN server (i.e. 268 STUN binding requests sent to a STUN server), the STUN client SHOULD 269 include the ORIGIN attribute. A STUN server can derive additional 270 information for logging and analytics about the request through the 271 ORIGIN attribute, such as the source of the request. For example, an 272 enterprise STUN server might only reply to STUN binding requests from 273 certain domains. 275 2.2. TURN Usage 277 For STUN requests sent using the long-term authentication method, 278 such as TURN [RFC5766] allocate requests, the STUN client SHOULD 279 include the ORIGIN attribute. A TURN server can use the ORIGIN 280 attribute to determine which REALM to include in the authentication 281 challenge. A TURN server can also use the ORIGIN attribute after 282 authentication to provide appropriate service. See the section below 283 on "Multiple Origins." 285 2.3. NAT Behavior Discovery Usage 287 For the NAT Behavior Discovery Usage in [RFC5780], the ORIGIN 288 attribute SHOULD be included in requests sent to a STUN server. This 289 usage is most similar to the STUN Usage described earlier. 291 2.4. ICE Usage 293 For STUN requests sent using the short-term authentication method, 294 such as ICE connectivity checks [RFC5245], the use of the ORIGIN 295 attribute is NOT RECOMMENDED. No valid use cases for the ORIGIN 296 attribute have been identified to date. 298 2.5. Media Keep-Alive Usage 300 For media keep-alive STUN requests described in Section 20 of 301 [RFC5245], the use of the ORIGIN attribute is NOT RECOMMENDED. No 302 valid use cases for the ORIGIN attribute have been identified to 303 date. 305 2.6. SIP Keep-Alive Usage 307 For SIP keep-alive STUN requests described in [RFC5626], the use of 308 the ORIGIN attribute is NOT RECOMMENDED. No valid use cases for the 309 ORIGIN attribute have been identified to date. 311 2.7. Multiple Origins 313 Multiple Origins for HTTP Requests are described in Section 7.2 of 314 [RFC6454]. As a result, a browser MAY generate a STUN request with 315 multiple ORIGIN attributes present. A browser MUST NOT include 316 multiple origins in a single ORIGIN attribute and instead use one 317 Origin per attribute. If the ORIGIN attribute is being used by a 318 TURN server to select the realm for authentication, the TURN server 319 MAY use any or all of the Origins to select the realm. Any future 320 new usage scenarios of the ORIGIN attribute need to describe how to 321 handle multiple Origins. 323 3. IANA Considerations 325 This specification, if approved, adds a new value to the IANA "STUN 326 Attributes Registry" created by [RFC5389]. The ORIGIN attribute 327 value is 0x802F. 329 4. Security Considerations 331 The security considerations of [RFC6454] apply to this extension. 332 Servers using the information present in the STUN ORIGIN attribute 333 need to realize that this attribute could be set arbitrarily by a 334 non-browser client or modified by an intermediary. The method 335 proposed in this document is not meant to replace existing STUN 336 authentication mechanisms but to provide additional information to 337 the server for logging and analytics and how to handle the request 338 after authentication. 340 Just as browsers do not allow a web application to set the Origin 341 header field via JavaScript, browsers should not allow a web 342 application through JavaScript to set the STUN ORIGIN attribute. 344 The STUN MESSAGE-INTEGRITY attribute can provide integrity protection 345 for all attributes present in a STUN request. However, MESSAGE- 346 INTEGRITY is not present in the initial STUN message sent, so the 347 initial ORIGIN attribute will not have integrity protection and hence 348 could be modified or removed from a STUN request without the server 349 knowing. Subsequent STUN requests containing the MESSAGE-INTEGRITY 350 attribute will provide integrity protection for the contents of the 351 ORIGIN attribute. The strength of this protection is a function of 352 the secret used to generate the MESSAGE-INTEGRITY value. 354 The STUN ORIGIN attribute does have privacy implications. The 355 recipient of the STUN request learns the web origin of the user. In 356 addition, an on-path attacker could determine this information by 357 inspecting STUN messages between the STUN client and STUN server, 358 depending on the transport used. This information is often available 359 in other messages sent by the browser, such as DNS or HTTP requests. 360 However, in cases where secure HTTP is used, including the ORIGIN 361 attribute over an unencrypted transport could leak this information. 362 STUN has a defined TLS transport; however, TLS transport is generally 363 unsuitable for the real-time media flows that follow STUN requests 364 and must use the same transport. The DTLS transport for STUN 365 [I-D.ietf-tram-stun-dtls] provides a very good privacy solution to 366 this problem. In cases where privacy is paramount, the ORIGIN 367 attribute SHOULD NOT be included or only included if DTLS or TLS 368 transport is used. 370 5. Implementation Status 372 Note to RFC Editor: Please remove this entire section prior to 373 publication, including the reference to RFC 6982. 375 This section records the status of known implementations of the 376 protocol defined by this specification at the time of posting of this 377 Internet-Draft, and is based on a proposal described in [RFC6982]. 378 The description of implementations in this section is intended to 379 assist the IETF in its decision processes in progressing drafts to 380 RFCs. Please note that the listing of any individual implementation 381 here does not imply endorsement by the IETF. Furthermore, no effort 382 has been spent to verify the information presented here that was 383 supplied by IETF contributors. This is not intended as, and must not 384 be construed to be, a catalog of available implementations or their 385 features. Readers are advised to note that other implementations may 386 exist. 388 According to [RFC6982], "this will allow reviewers and working groups 389 to assign due consideration to documents that have the benefit of 390 running code, which may serve as evidence of valuable experimentation 391 and feedback that have made the implemented protocols more mature. 392 It is up to the individual working groups to use this information as 393 they see fit". 395 Two proof-of-concept implementations have been created in support of 396 this proposed standard. One provides a WebRTC enabled browser that 397 includes the appropriate STUN ORIGIN Attribute with the Origin 398 insight known to the browser in STUN/TURN messages sent to servers. 399 The other provides an example of a multiple realms capable TURN 400 server that takes advantage of Origin insight provided in the STUN 401 ORIGIN Attribute. 403 A Chrome browser implementation has been created by Graham Yoakum and 404 Ryan Yoakum (Skobalt LLC) and is freely licensed under the standard 405 terms of the open source Chromium and WebRTC projects. This proof- 406 of-concept version of the Google Chrome browser (nicknamed 'Chromeo') 407 sends Origin insight in STUN and TURN messages using the proposed new 408 STUN ORIGIN attribute with a value of 0x802F (as initially proposed, 409 however that value is easily changed in a single line of code). 410 'Chromeo' includes a Chrome flag to enable and disable this unique 411 feature (and is by default disabled to prevent any non-intentional 412 use of this feature until the standard is finalized). This 413 implementation is based on is draft-johnston-tram-stun-origin-02. 415 Coordinated changes to both the WebRTC and Chromium open source 416 projects have been formally submitted for consideration. The two 417 submitted change lists together implement the complete browser proof- 418 of-concept. 'Chromeo' has been built for Linux and STUN protocol 419 behavior has been verified using WireShark traces illustrating that 420 proper STUN Origin attributes are being included in STUN/TURN 421 messages sent by the browser to servers (screen captures of STUN 422 messages illustrating the Origin attribute and content are 423 available). 425 The WebRTC and Chromium open source projects can be found at: 426 http://www.webrtc.org/ and http://www.chromium.org/ 428 Google can choose to accept or modify the changes proposed for Chrome 429 and other browser vendors can access and take advantage of the 430 publicly available WebRTC and Chromium open source submissions as 431 desired. Hopefully this will enable browsers to quickly implement 432 STUN Origin enhancements. 434 A multiple realms capable advanced open source Origin enabled TURN 435 server (named 'Coturn') has been created by Oleg Moskalenko and is 436 freely licensed under the New BSD license. This reference 437 implementation and proof-of-concept provides a clone (a spin-off) of 438 the rfc5766-turn-server project adding Origin-based multiple realms 439 support. 441 'Coturn' is backward-compatible with rfc5766-turn-server project but 442 the code is more complex and it uses a different (also more complex) 443 database structure. It is the intent to add all IETF TRAM TURN 444 server related capabilities to this project as they mature. 'Coturn' 445 is publicly available and can be found at: 446 https://code.google.com/p/coturn/ 448 6. Acknowledgements 450 Thanks to John Selbie, Tirumaleswar Reddy, Simon Perreault, Marc 451 Petit-Huguenin, Andy Hutton, and Oleg Moskalenko for their feedback 452 and reviews. Special thanks to Graham Yoakum and Ryan Yoakum of 453 Skobalt LLC and Oleg Moskalenko of rfc5766-turn-server project for 454 contributing open source proof-of-concept implementations for a 455 Chrome web browser and a multiple realms capable TURN server, quickly 456 demonstrating feasibility. 458 7. Normative References 460 [I-D.ietf-rtcweb-overview] 461 Alvestrand, H., "Overview: Real Time Protocols for 462 Browser-based Applications", draft-ietf-rtcweb-overview-10 463 (work in progress), June 2014. 465 [I-D.ietf-tram-auth-problems] 466 Reddy, T., R, R., Perumal, M., and A. Yegin, "Problems 467 with STUN long-term Authentication for TURN", 468 draft-ietf-tram-auth-problems-01 (work in progress), 469 May 2014. 471 [I-D.ietf-tram-stun-dtls] 472 Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 473 Layer Security (DTLS) as Transport for Session Traversal 474 Utilities for NAT (STUN)", draft-ietf-tram-stun-dtls-05 475 (work in progress), June 2014. 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, March 1997. 480 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 481 A., Peterson, J., Sparks, R., Handley, M., and E. 482 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 483 June 2002. 485 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 486 "STUN - Simple Traversal of User Datagram Protocol (UDP) 487 Through Network Address Translators (NATs)", RFC 3489, 488 March 2003. 490 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 491 10646", STD 63, RFC 3629, November 2003. 493 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 494 Standards Track Code Points", RFC 4020, February 2005. 496 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 497 (ICE): A Protocol for Network Address Translator (NAT) 498 Traversal for Offer/Answer Protocols", RFC 5245, 499 April 2010. 501 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 502 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 503 October 2008. 505 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 506 Initiated Connections in the Session Initiation Protocol 507 (SIP)", RFC 5626, October 2009. 509 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 510 Relays around NAT (TURN): Relay Extensions to Session 511 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 513 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 514 Using Session Traversal Utilities for NAT (STUN)", 515 RFC 5780, May 2010. 517 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 518 Extension Definitions", RFC 6066, January 2011. 520 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 521 Protocol (XMPP): Core", RFC 6120, March 2011. 523 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 524 Protocol (XMPP): Address Format", RFC 6122, March 2011. 526 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 527 December 2011. 529 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 530 Code: The Implementation Status Section", RFC 6982, 531 July 2013. 533 [WebRTC-API] 534 Bergkvist, A., Burnett, D., Jennings, C., and A. 535 Narayanan, "WebRTC 1.0: Real-time Communication Between 536 Browsers", W3C Working Draft http://www.w3.org/TR/webrtc/, 537 2013, . 539 Authors' Addresses 541 Alan Johnston 542 Avaya 543 St. Louis, MO 544 USA 546 Phone: 547 Email: alan.b.johnston@gmail.com 548 Justin Uberti 549 Google 550 Kirkland, WA 551 USA 553 Phone: 554 Email: justin@uberti.name 556 John Yoakum 557 Avaya 558 Cary, NC 559 USA 561 Phone: 562 Email: yoakum@avaya.com 564 Kundan Singh 565 Avaya 566 San Francisco, CA 567 USA 569 Phone: 570 Email: kundan10@gmail.com