idnits 2.17.1 draft-ietf-tram-stun-origin-06.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 date (October 19, 2015) is 3112 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) == Unused Reference: 'RFC7350' is defined on line 512, but no explicit reference was found in the text ** 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) ** Obsolete normative reference: RFC 6122 (Obsoleted by RFC 7622) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-14 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM Working Group A. Johnston 3 Internet-Draft Avaya 4 Intended status: Standards Track J. Uberti 5 Expires: April 21, 2016 Google 6 J. Yoakum 7 K. Singh 8 Avaya 9 October 19, 2015 11 An Origin Attribute for the STUN Protocol 12 draft-ietf-tram-stun-origin-06 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 This specification defines an ORIGIN attribute for STUN that can be 19 used in similar ways to the HTTP header field of the same name. 20 WebRTC browsers utilizing STUN and TURN would include this attribute 21 which would provide servers with additional information about the 22 STUN and TURN requests they receive. This specification defines the 23 usage of the STUN ORIGIN attribute for web, SIP, and XMPP contexts. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 21, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 2. STUN ORIGIN attribute . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Origin Matching Rules . . . . . . . . . . . . . . . . . . 5 63 2.2. STUN Usage . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. TURN Usage . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.4. NAT Behavior Discovery Usage . . . . . . . . . . . . . . 6 66 2.5. ICE Usage . . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.6. Media Keep-Alive Usage . . . . . . . . . . . . . . . . . 6 68 2.7. SIP Keep-Alive Usage . . . . . . . . . . . . . . . . . . 6 69 2.8. Multiple Origins . . . . . . . . . . . . . . . . . . . . 7 70 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 7.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 STUN, or Session Traversal Utilities for NAT [RFC5389], is a protocol 82 used to assist other protocols traverse Network Address Translators 83 or NATs. TURN, or Traversal Using Relays around NAT [RFC5766], is a 84 STUN extension that allows endpoints to acquire a relayed address for 85 media flows. It is most commonly used in conjunction with ICE, 86 Interactive Connectivity Establishment [RFC5245], which is used to 87 establish peer-to-peer flows between endpoints through NATs and 88 firewalls. 90 STUN defines three authentication modes, depending on the STUN usage. 91 For STUN binding requests sent between peers, such as for ICE 92 connectivity checks, a short term authentication method is 93 recommended. Each peer contributes random strings which are 94 exchanged over signaling and used to authenticate the connectivity 95 checks. For TURN, a usage of STUN used to acquire and refresh relay 96 addresses, a long term authentication method is recommended. This 97 authentication is similar to SIP Digest [RFC3261], which involves an 98 authentication challenge for each request. A server, upon receipt of 99 a TURN request, generates an authentication challenge that includes a 100 realm and nonce. The client resends the TURN request supplying a 101 user name and password based on the realm indicated by the server. 102 For a STUN binding request sent to a STUN server, no authentication 103 is recommended, as generating the response is less work for a server 104 than the server utilizing the short term or long term authentication 105 approach. The server responds statelessly, so the only resources 106 used are those to process each request, which are minimal. 108 WebRTC, Web Real-Time Communications, adds peer-to-peer real-time, 109 interactive voice and video media capabilities and data channels to 110 browsers [I-D.ietf-rtcweb-overview] without a plugin or download, and 111 allows web developers to access this functionality using JavaScript 112 API calls [WebRTC-API]. WebRTC includes STUN, TURN, and ICE client 113 functionality built into browsers. For a session established between 114 two browsers, if either browser is behind a NAT, a STUN server is 115 necessary. Public STUN servers are currently available and a web 116 application can suggest a particular STUN server be used. In cases 117 where a particular combination of NAT mapping and filtering and/or 118 firewalling is present, a TURN server is needed to establish a peer 119 connection. In this case, TURN credentials need to be available to 120 the browser for the long term authentication approach. A TURN server 121 for WebRTC might serve a number of different domains and realms. 123 From the perspective of the web application provider, providing 124 service for a number of different domains and realms, it is useful to 125 know something about the source of the STUN request when processing 126 the request. For a web application provider STUN or TURN server, the 127 server will have no idea which web pages or sites are sending binding 128 requests to the service. In conventional applications, the SOFTWARE 129 attribute would provide some identifying information to the service, 130 but that no longer works when the browser is the application. For a 131 web application provider TURN server, the TURN server does not know 132 which realm to include in an authentication challenge. 134 In the web world, HTTP requests have the concept of origin. The 135 origin of a web page, as defined in [RFC6454], is defined by the 136 URI's scheme, host or IP address, and port portions. The HTTP Origin 137 header field inserted by the web browser carries this information and 138 is useful information for servers that receive HTTP requests 139 generated via JavaScript. For example, Cross Origin Resource 140 Sharing, CORS, allows an HTTP server to serve HTTP requests from 141 multiple origins. 143 This specification proposes extending the origin concept to STUN 144 requests. STUN requests generated by a web browser would include the 145 origin of the HTTP page that is initiating the Peer Connection. 146 Using this extra information, a STUN server could use the origin to 147 determine which STUN binding requests to respond to, reducing the 148 load on a STUN server. Using this information, a TURN server could 149 use the origin to determine which realm to include in the 150 authentication challenge. A TURN server can also use the origin 151 information for logging and analytics, and also as additional 152 information after authentication for providing service. This 153 specification also defines an origin for SIP and XMPP users of STUN 154 and TURN. 156 An important use case that the STUN Origin helps solve is the 157 operation of a multi-tenanted TURN server (i.e. a TURN server that 158 serves multiple, perhaps tens of thousands of different domains). 159 The problem associated with this use case is described in paragraph 6 160 of Section 4 of [RFC7376]. While it is possible for a TURN server to 161 use the same authentication credentials across many domains, a more 162 likely (and more manageable) scenario is to have separate credentials 163 for each domain, and hence a different realm for each domain. With 164 the TURN server configured with a mapping between a domain (conveyed 165 in the Origin) and the realm string (to be used in the authentication 166 challenge), a single TURN URI could be used across all domains, and 167 the resulting JavaScript code would be portable. 169 Note that the origin information is most useful as a hint in initial 170 STUN and TURN requests as received by a server. However, origin 171 information still has value throughout the session even after 172 authentication for logging and other purposes. 174 The following sections of this document define the STUN ORIGIN 175 attribute and define its usage. 177 1.1. Requirements Language 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 181 "OPTIONAL" in this document are to be interpreted as described in RFC 182 2119 [RFC2119]. 184 2. STUN ORIGIN attribute 186 This specification defines how to apply the web origin concept and 187 syntax of [RFC6454] to the STUN protocol. 189 This specification defines a new Attribute to the STUN protocol 190 [RFC5389]. The attribute is called ORIGIN and uses the syntax 191 defined in Section 15 of [RFC5389]. The number used for this in the 192 type field is 0x802F, chosen in the comprehension optional range. 194 The value of ORIGIN is a variable-length value. It MUST contain a 195 UTF-8 [RFC3629] encoded sequence of characters. Senders MAY include 196 multiple ORIGIN attributes in a request, and receivers MUST support 197 parsing and receiving multiple ORIGIN attributes. HTTP origins are 198 less than 267 characters (the maximum 253 character domain name plus 199 8 characters for the URI scheme plus 5 characters for the port 200 number). 202 For a web browser (HTTP User Agent), the contents of the ORIGIN 203 attribute is the unicode-serialization of an origin defined in 204 Section 6.1 of [RFC6454]. The origin value included is the same as 205 the Origin header field for an HTTP request generated from the web 206 page that is creating the Peer Connection. It does not include any 207 string terminating (\x00) character in the serialization. 209 For a SIP User Agent [RFC3261] using STUN and TURN, the ORIGIN 210 attribute is set to be the URI of the registrar server used by the 211 User Agent (i.e. the Request-URI of a REGISTER method). This is the 212 full Request-URI component of the SIP ABNF defined in [RFC3261]. For 213 example, a SIP user "sip:bob@biloxi.example.com" might register with 214 the Request-URI of "sip:registrar.biloxi.example.com". 216 For an XMPP client [RFC6120] using STUN and TURN, the ORIGIN 217 attribute is an XMPP URI [RFC5122] representing the full domainpart 218 of the client's Jabber ID (JID) as defined in the ABNF of [RFC6122]; 219 for example, if the client's JID is "juliet@im.example.com/balcony" 220 then the ORIGIN attribute would be "xmpp:im.example.com". 222 Other contexts can define a usage of the ORIGIN attribute to use an 223 appropriate URI or URL. 225 If an ORIGIN attribute is not present in a request, it is up to the 226 server how to handle the request. For example, it could assume a 227 default Origin. 229 2.1. Origin Matching Rules 231 For any usage of ORIGIN, the following rules MUST be followed to 232 ensure privacy. An ORIGIN attribute MUST NOT be included in a STUN 233 or TURN request if the fully qualified domain name (FQDN) of the 234 Origin does not match the FQDN of the STUN or TURN URI which was used 235 to reach the STUN or TURN server. That is, only if the domain of the 236 Origin is the same as the origin of the STUN or TURN server is the 237 Origin information sent. The FQDN comparison does not include ports 238 or URI schemes. For example, a web origin from 239 http://foo.example.com:8080 would match a TURN URI of 240 turn:foo.example.com. A SIP origin of sips:bar.example.org:5061 241 would match a STUN URI of stun:bar.example.org:999. 243 2.2. STUN Usage 245 For STUN requests sent without authentication to a STUN server (i.e. 246 STUN binding requests sent to a STUN server), the STUN client MUST 247 include the ORIGIN attribute if it matches per the rules of 248 Section 2.1. Otherwise, the ORIGIN attribute is omitted. 250 A STUN server can derive additional information for logging and 251 analytics about the request through the ORIGIN attribute, such as the 252 source of the request. For example, an enterprise STUN server might 253 only reply to STUN binding requests from certain domains. 255 2.3. TURN Usage 257 TURN [RFC5766] Allocate requests MUST include ORIGIN if it matches 258 per the rules of Section 2.1. Otherwise, the ORIGIN attribute is 259 omitted. For all other TURN requests, including the Send method, the 260 use of the ORIGIN attribute is NOT RECOMMENDED as it provides no 261 value. 263 A TURN server can use the ORIGIN attribute to determine which REALM 264 to include in the authentication challenge. A TURN server can also 265 use the ORIGIN attribute after authentication to provide appropriate 266 service. 268 2.4. NAT Behavior Discovery Usage 270 For the NAT Behavior Discovery Usage in [RFC5780], the rules for STUN 271 usage apply. 273 2.5. ICE Usage 275 ICE [RFC5245] connectivity checks MUST NOT include the ORIGIN 276 attribute. Including the ORIGIN attribute leaks information about 277 the site used by one peer to the other peer in the session. 279 2.6. Media Keep-Alive Usage 281 For media keep-alive STUN requests described in Section 20 of 282 [RFC5245], the rules for ICE usage apply. 284 2.7. SIP Keep-Alive Usage 286 For SIP keep-alive STUN requests described in [RFC5626], the ORIGIN 287 attribute MUST NOT be included. No valid use cases for the ORIGIN 288 attribute have been identified to date, and as a result the ORIGIN 289 attribute will be ignored. 291 2.8. Multiple Origins 293 Multiple Origins for HTTP Requests are described in Section 7.2 of 294 [RFC6454]. Multiple origins can occur when the same resource is 295 fetched by multiple origins at the same time (e.g. multiple tabs, 296 windows, frames, etc.). In the context of WebRTC, it doesn't make 297 sense for a STUN binding or TURN allocation to be shared across 298 origins (e.g. Peer Connections). Based on their definitions, 299 multiple SIP and XMPP origins also do not apply here. Therefore, if 300 a STUN request contains multiple origins, the first origin MUST be 301 used and the remaining origins ignored. 303 3. IANA Considerations 305 This specification, if approved, adds a new value to the IANA "STUN 306 Attributes Registry" created by [RFC5389]. The ORIGIN attribute 307 value is 0x802F. 309 4. Security Considerations 311 The security considerations of [RFC6454] apply to this extension. 312 Servers using the information present in the STUN ORIGIN attribute 313 need to realize that this attribute could be set arbitrarily by a 314 non-browser client or modified by an intermediary. The method 315 proposed in this document is not meant to replace existing STUN 316 authentication mechanisms but to provide additional information to 317 the server for logging and analytics and how to handle the request 318 after authentication. 320 Just as browsers do not allow a web application to set the HTTP 321 Origin header field via JavaScript, web browsers (HTTP User Agents) 322 MUST NOT allow a web application to set the STUN ORIGIN attribute 323 through JavaScript. 325 While the STUN MESSAGE-INTEGRITY attribute can provide integrity 326 protection for all attributes present in a STUN request, MESSAGE- 327 INTEGRITY is not present in the initial STUN message sent. As a 328 result, an ORIGIN attribute could be modified or removed from a STUN 329 request without the server knowing. DTLS or TLS transport SHOULD be 330 used when integrity protection for the ORIGIN attribute is important. 332 The STUN ORIGIN attribute has privacy implications. As a result, TLS 333 or DTLS transport SHOULD be used. If STUN requests containing the 334 origin attribute are not encrypted with TLS or DTLS, an on-path 335 attacker could determine this information by inspecting STUN messages 336 between the STUN client and STUN server. This information is often 337 available in other messages sent by the browser, such as DNS or HTTP 338 requests. However, in cases where secure HTTP is used, including the 339 ORIGIN attribute over an unencrypted transport could leak this 340 information. In cases where privacy is paramount, but TLS or DTLS 341 transport is not available, the ORIGIN attribute MAY be omitted. 343 The STUN ORIGIN attribute also has privacy implications in that the 344 origin information is shared with a STUN or TURN server which 345 otherwise might not know this information. This information could be 346 used to track usage of real-time communication services. A STUN or 347 TURN server will always know the public IP address of each user, but 348 the ORIGIN attribute provides more information about which service or 349 provider is being used. The particular STUN and TURN servers used 350 are usually selected by the real-time communications service provider 351 (i.e. the web provider for WebRTC or the SIP or XMPP service 352 provider). In addition, they are usually also run by the same 353 provider, or by a trusted partner, especially for TURN. However, a 354 service or provider using an untrusted third party STUN or TURN 355 server needs to recognize that the operator of the third party STUN 356 or TURN server will learn the identity of the service or provider 357 through this extension. In order to prevent the leakage of usage of 358 information, the Origin and STUN or TURN URI matching rules defined 359 in Section 2.1 MUST be used. These rules ensure that the inclusion 360 of the ORIGIN attribute does not provide any new information to the 361 operator of the STUN or TURN server than they already know. 363 5. Implementation Status 365 Note to RFC Editor: Please remove this entire section prior to 366 publication, including the reference to RFC 6982. 368 This section records the status of known implementations of the 369 protocol defined by this specification at the time of posting of this 370 Internet-Draft, and is based on a proposal described in [RFC6982]. 371 The description of implementations in this section is intended to 372 assist the IETF in its decision processes in progressing drafts to 373 RFCs. Please note that the listing of any individual implementation 374 here does not imply endorsement by the IETF. Furthermore, no effort 375 has been spent to verify the information presented here that was 376 supplied by IETF contributors. This is not intended as, and must not 377 be construed to be, a catalog of available implementations or their 378 features. Readers are advised to note that other implementations may 379 exist. 381 According to [RFC6982], "this will allow reviewers and working groups 382 to assign due consideration to documents that have the benefit of 383 running code, which may serve as evidence of valuable experimentation 384 and feedback that have made the implemented protocols more mature. 385 It is up to the individual working groups to use this information as 386 they see fit". 388 Two proof-of-concept implementations have been created in support of 389 this proposed standard. One provides a WebRTC enabled browser that 390 includes the appropriate STUN ORIGIN Attribute with the Origin 391 insight known to the browser in STUN/TURN messages sent to servers. 392 The other provides an example of a multiple realms capable TURN 393 server that takes advantage of Origin insight provided in the STUN 394 ORIGIN Attribute. 396 A Chrome browser implementation has been created by Graham Yoakum and 397 Ryan Yoakum (Skobalt LLC) and is freely licensed under the standard 398 terms of the open source Chromium and WebRTC projects. This proof- 399 of-concept version of the Google Chrome browser (nicknamed 'Chromeo') 400 sends Origin insight in STUN and TURN messages using the proposed new 401 STUN ORIGIN attribute with a value of 0x802F (as initially proposed, 402 however that value is easily changed in a single line of code). 403 'Chromeo' includes a Chrome flag to enable and disable this unique 404 feature (and is by default disabled to prevent any non-intentional 405 use of this feature until the standard is finalized). This 406 implementation is based on is draft-johnston-tram-stun-origin-02. 408 Coordinated changes to both the WebRTC and Chromium open source 409 projects have been formally submitted for consideration. The two 410 submitted change lists together implement the complete browser proof- 411 of-concept. 'Chromeo' has been built for Linux and STUN protocol 412 behavior has been verified using WireShark traces illustrating that 413 proper STUN Origin attributes are being included in STUN/TURN 414 messages sent by the browser to servers (screen captures of STUN 415 messages illustrating the Origin attribute and content are 416 available). 418 The WebRTC and Chromium open source projects can be found at: 419 http://www.webrtc.org/ and http://www.chromium.org/ 421 Google can choose to accept or modify the changes proposed for Chrome 422 and other browser vendors can access and take advantage of the 423 publicly available WebRTC and Chromium open source submissions as 424 desired. Hopefully this will enable browsers to quickly implement 425 STUN Origin enhancements. 427 A multiple realms capable advanced open source Origin enabled TURN 428 server (named 'Coturn') has been created by Oleg Moskalenko and is 429 freely licensed under the New BSD license. This reference 430 implementation and proof-of-concept provides a clone (a spin-off) of 431 the rfc5766-turn-server project adding Origin-based multiple realms 432 support. 434 'Coturn' is backward-compatible with rfc5766-turn-server project but 435 the code is more complex and it uses a different (also more complex) 436 database structure. It is the intent to add all IETF TRAM TURN 437 server related capabilities to this project as they mature. 'Coturn' 438 is publicly available and can be found at: https://github.com/coturn/ 439 coturn/ 441 6. Acknowledgements 443 Thanks to John Selbie, Tirumaleswar Reddy, Simon Perreault, Marc 444 Petit-Huguenin, Andy Hutton, and Oleg Moskalenko for their feedback 445 and reviews. Special thanks to Graham Yoakum and Ryan Yoakum of 446 Skobalt LLC and Oleg Moskalenko of rfc5766-turn-server project for 447 contributing open source proof-of-concept implementations for a 448 Chrome web browser and a multiple realms capable TURN server, quickly 449 demonstrating feasibility. 451 7. References 453 7.1. Normative References 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, 457 DOI 10.17487/RFC2119, March 1997, 458 . 460 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 461 A., Peterson, J., Sparks, R., Handley, M., and E. 462 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 463 DOI 10.17487/RFC3261, June 2002, 464 . 466 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 467 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 468 2003, . 470 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 471 (IRIs) and Uniform Resource Identifiers (URIs) for the 472 Extensible Messaging and Presence Protocol (XMPP)", 473 RFC 5122, DOI 10.17487/RFC5122, February 2008, 474 . 476 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 477 (ICE): A Protocol for Network Address Translator (NAT) 478 Traversal for Offer/Answer Protocols", RFC 5245, 479 DOI 10.17487/RFC5245, April 2010, 480 . 482 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 483 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 484 DOI 10.17487/RFC5389, October 2008, 485 . 487 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 488 "Managing Client-Initiated Connections in the Session 489 Initiation Protocol (SIP)", RFC 5626, 490 DOI 10.17487/RFC5626, October 2009, 491 . 493 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 494 Relays around NAT (TURN): Relay Extensions to Session 495 Traversal Utilities for NAT (STUN)", RFC 5766, 496 DOI 10.17487/RFC5766, April 2010, 497 . 499 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 500 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 501 March 2011, . 503 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 504 Protocol (XMPP): Address Format", RFC 6122, 505 DOI 10.17487/RFC6122, March 2011, 506 . 508 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 509 DOI 10.17487/RFC6454, December 2011, 510 . 512 [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 513 Layer Security (DTLS) as Transport for Session Traversal 514 Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, 515 August 2014, . 517 7.2. Informative References 519 [I-D.ietf-rtcweb-overview] 520 Alvestrand, H., "Overview: Real Time Protocols for 521 Browser-based Applications", draft-ietf-rtcweb-overview-14 522 (work in progress), June 2015. 524 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 525 Using Session Traversal Utilities for NAT (STUN)", 526 RFC 5780, DOI 10.17487/RFC5780, May 2010, 527 . 529 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 530 Code: The Implementation Status Section", RFC 6982, 531 DOI 10.17487/RFC6982, July 2013, 532 . 534 [RFC7376] Reddy, T., Ravindranath, R., Perumal, M., and A. Yegin, 535 "Problems with Session Traversal Utilities for NAT (STUN) 536 Long-Term Authentication for Traversal Using Relays around 537 NAT (TURN)", RFC 7376, DOI 10.17487/RFC7376, September 538 2014, . 540 [WebRTC-API] 541 Bergkvist, A., Burnett, D., Jennings, C., and A. 542 Narayanan, "WebRTC 1.0: Real-time Communication Between 543 Browsers", W3C Working Draft http://www.w3.org/TR/webrtc/, 544 2013, . 546 Authors' Addresses 548 Alan Johnston 549 Avaya 550 St. Louis, MO 551 USA 553 Email: alan.b.johnston@gmail.com 555 Justin Uberti 556 Google 557 Kirkland, WA 558 USA 560 Email: justin@uberti.name 562 John Yoakum 563 Avaya 564 Cary, NC 565 USA 567 Email: yoakum@avaya.com 568 Kundan Singh 569 Avaya 570 San Francisco, CA 571 USA 573 Email: kundan10@gmail.com