idnits 2.17.1 draft-ietf-tram-stun-origin-05.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 (February 19, 2015) is 3346 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 490, 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-13 -- 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: August 23, 2015 Google 6 J. Yoakum 7 K. Singh 8 Avaya 9 February 19, 2015 11 An Origin Attribute for the STUN Protocol 12 draft-ietf-tram-stun-origin-05 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 August 23, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 61 2. STUN ORIGIN attribute . . . . . . . . . . . . . . . . . . . . 5 62 2.1. STUN Usage . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2. TURN Usage . . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. NAT Behavior Discovery Usage . . . . . . . . . . . . . . . 6 65 2.4. ICE Usage . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.5. Media Keep-Alive Usage . . . . . . . . . . . . . . . . . . 7 67 2.6. SIP Keep-Alive Usage . . . . . . . . . . . . . . . . . . . 7 68 2.7. Multiple Origins . . . . . . . . . . . . . . . . . . . . . 7 69 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 STUN, or Session Traversal Utilities for NAT, is a protocol used to 81 assist other protocols traverse Network Address Translators or NATs. 82 TURN, or Traversal Using Relays around NAT [RFC5766], is a STUN 83 extension [RFC5389] that allows endpoints to acquire a relayed 84 address for media flows. It is most commonly used in conjunction 85 with ICE, Interactive Connectivity Establishment [RFC5245], which is 86 used to establish peer-to-peer flows between endpoints through NATs 87 and firewalls. 89 STUN defines three authentication modes, depending on the STUN usage. 90 For STUN binding requests sent between peers, such as for ICE 91 connectivity checks, a short term authentication method is 92 recommended. Each peer contributes random strings which are 93 exchanged over signaling and used to authenticate the connectivity 94 checks. For TURN, a usage of STUN used to acquire and refresh relay 95 addresses, a long term authentication method is recommended. This 96 authentication is similar to SIP Digest [RFC3261], which involves an 97 authentication challenge for each request. A server, upon receipt of 98 a TURN request, generates an authentication challenge that includes a 99 realm and nonce. The client resends the TURN request supplying a 100 user name and password based on the realm indicated by the server. 101 For a STUN binding request sent to a STUN server, no authentication 102 is recommended, as generating the response is less work for a server 103 than the server utilizing the short term or long term authentication 104 approach. The server responds statelessly, so the only resources 105 used are those to process each request, which are minimal. 107 WebRTC, Web Real-Time Communications, adds peer-to-peer real-time, 108 interactive voice and video media capabilities and data channels to 109 browsers [I-D.ietf-rtcweb-overview] without a plugin or download, and 110 allows web developers to access this functionality using JavaScript 111 API calls [WebRTC-API]. WebRTC includes STUN, TURN, and ICE client 112 functionality built into browsers. For a session established between 113 two browsers, if either browser is behind a NAT, a STUN server is 114 necessary. Public STUN servers are currently available and a web 115 application can suggest a particular STUN server be used. In cases 116 where a particular combination of NAT mapping and filtering and/or 117 firewalling is present, a TURN server is needed to establish a peer 118 connection. In this case, TURN credentials need to be available to 119 the browser for the long term authentication approach. A TURN server 120 for WebRTC might serve a number of different domains and realms. 122 From the perspective of the web application provider, providing 123 service for a number of different domains and realms, it is useful to 124 know something about the source of the STUN request when processing 125 the request. For a web application provider STUN or TURN server, the 126 server will have no idea which web pages or sites are sending binding 127 requests to the service. In conventional applications, the SOFTWARE 128 attribute would provide some identifying information to the service, 129 but that no longer works when the browser is the application. For a 130 web application provider TURN server, the TURN server does not know 131 which realm to include in an authentication challenge. 133 In the web world, HTTP requests have the concept of origin. The 134 origin of a web page, as defined in [RFC6454], is defined by the 135 URI's scheme, host or IP address, and port portions. The HTTP Origin 136 header field inserted by the web browser carries this information and 137 is useful information for servers that receive HTTP requests 138 generated via JavaScript. For example, Cross Origin Resource 139 Sharing, CORS, allows an HTTP server to serve HTTP requests from 140 multiple origins. 142 This specification proposes extending the origin concept to STUN 143 requests. STUN requests generated by a web browser would include the 144 origin of the HTTP page that is initiating the Peer Connection. 145 Using this extra information, a STUN server could use the origin to 146 determine which STUN binding requests to respond to, reducing the 147 load on a STUN server. Using this information, a TURN server could 148 use the origin to determine which realm to include in the 149 authentication challenge. A TURN server can also use the origin 150 information for logging and analytics, and also as additional 151 information after authentication for providing service. This 152 specification also defines an origin for SIP and XMPP users of STUN 153 and TURN. 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 [RFC7376]. While it is possible for a TURN server to use the same 160 authentication credentials across many domains, a more likely (and 161 more manageable) scenario is to have separate credentials for each 162 domain, and hence a different realm for each domain. With the TURN 163 server configured with a mapping between a domain (conveyed in the 164 Origin) and the realm string (to be used in the authentication 165 challenge), a single TURN URI could be used across all domains, and 166 the resulting JavaScript code would be portable. 168 Note that the origin information is most useful as a hint in initial 169 STUN and TURN requests as received by a server. However, origin 170 information still has value throughout the session even after 171 authentication for logging and other purposes. 173 The following sections of this document define the STUN ORIGIN 174 attribute and define its usage. 176 1.1. Requirements Language 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in RFC 181 2119 [RFC2119]. 183 2. STUN ORIGIN attribute 185 This specification defines how to apply the web origin concept and 186 syntax of [RFC6454] to the STUN protocol. 188 This specification defines a new Attribute to the STUN protocol 189 [RFC5389]. The attribute is called ORIGIN and uses the syntax 190 defined in Section 15 of [RFC5389]. The number used for this in the 191 type field is 0x802F, chosen in the comprehension optional range. 192 The value of ORIGIN is a variable-length value. It MUST contain a 193 UTF-8 [RFC3629] encoded sequence of characters. Senders MAY include 194 multiple ORIGIN attributes in a request, and receivers MUST support 195 parsing and receiving multiple ORIGIN attributes. The size of 196 ORIGINs included in a STUN message can have a major impact on the 197 size of a STUN packet, and could potentially cause UDP fragmentation. 198 HTTP origins are less than 267 characters (the maximum 253 character 199 domain name plus 8 characters for the URI scheme plus 5 characters 200 for the port 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. STUN Usage 231 For STUN requests sent without authentication to a STUN server (i.e. 232 STUN binding requests sent to a STUN server), the STUN client MUST 233 include the ORIGIN attribute when the origin is a web origin. For 234 other origins, such as SIP or XMPP, the STUN client SHOULD include 235 the ORIGIN attribute. 237 Note that for privacy reasons, an empty ORIGIN attribute can be 238 sent, as described in the Security Considerations. 240 A STUN server can derive additional information for logging and 241 analytics about the request through the ORIGIN attribute, such as the 242 source of the request. For example, an enterprise STUN server might 243 only reply to STUN binding requests from certain domains. 245 2.2. TURN Usage 247 When the origin is a web origin, TURN [RFC5766] Allocate requests 248 MUST include the ORIGIN attribute. For all other TURN requests, 249 including the Send method, the use of the ORIGIN attribute is NOT 250 RECOMMENDED. For other origins, such as SIP or XMPP, TURN Allocate 251 requests SHOULD include the ORIGIN attribute. A TURN server can use 252 the ORIGIN attribute to determine which REALM to include in the 253 authentication challenge. A TURN server can also use the ORIGIN 254 attribute after authentication to provide appropriate service. 256 2.3. NAT Behavior Discovery Usage 258 For the NAT Behavior Discovery Usage in [RFC5780], the rules for STUN 259 usage apply. 261 2.4. ICE Usage 263 ICE [RFC5245] connectivity checks MUST NOT include the ORIGIN 264 attribute. Including the ORIGIN attribute leaks information about 265 the site used by one peer to the other peer in the session. 267 2.5. Media Keep-Alive Usage 269 For media keep-alive STUN requests described in Section 20 of 270 [RFC5245], the rules for ICE usage apply. 272 2.6. SIP Keep-Alive Usage 274 For SIP keep-alive STUN requests described in [RFC5626], the use of 275 the ORIGIN attribute is NOT RECOMMENDED. No valid use cases for the 276 ORIGIN attribute have been identified to date, and as a result the 277 ORIGIN attribute will be ignored. 279 2.7. Multiple Origins 281 Multiple Origins for HTTP Requests are described in Section 7.2 of 282 [RFC6454]. Multiple origins can occur when the same resource is 283 fetched by multiple origins at the same time (e.g. multiple tabs, 284 windows, frames, etc.). In the context of WebRTC, it doesn't make 285 sense for a STUN binding or TURN allocation to be shared across 286 origins (e.g. Peer Connections). Based on their definitions, 287 multiple SIP and XMPP origins also do not apply here. Therefore, if 288 a STUN request contains multiple origins, the first origin MUST be 289 used and the remaining origins ignored. 291 3. IANA Considerations 293 This specification, if approved, adds a new value to the IANA "STUN 294 Attributes Registry" created by [RFC5389]. The ORIGIN attribute 295 value is 0x802F. 297 4. Security Considerations 299 The security considerations of [RFC6454] apply to this extension. 300 Servers using the information present in the STUN ORIGIN attribute 301 need to realize that this attribute could be set arbitrarily by a 302 non-browser client or modified by an intermediary. The method 303 proposed in this document is not meant to replace existing STUN 304 authentication mechanisms but to provide additional information to 305 the server for logging and analytics and how to handle the request 306 after authentication. 308 Just as browsers do not allow a web application to set the HTTP 309 Origin header field via JavaScript, web browsers (HTTP User Agents) 310 MUST NOT allow a web application to set the STUN ORIGIN attribute 311 through JavaScript. 313 While the STUN MESSAGE-INTEGRITY attribute can provide integrity 314 protection for all attributes present in a STUN request, MESSAGE- 315 INTEGRITY is not present in the initial STUN message sent. As a 316 result, an ORIGIN attribute could be modified or removed from a STUN 317 request without the server knowing. DTLS or TLS transport SHOULD be 318 used when integrity protection for the ORIGIN attribute is important. 320 The STUN ORIGIN attribute has privacy implications. As a result, TLS 321 or DTLS transport SHOULD be used. If STUN requests containing the 322 origin attribute are not encrypted with TLS or DTLS, an on-path 323 attacker could determine this information by inspecting STUN messages 324 between the STUN client and STUN server. This information is often 325 available in other messages sent by the browser, such as DNS or HTTP 326 requests. However, in cases where secure HTTP is used, including the 327 ORIGIN attribute over an unencrypted transport could leak this 328 information. In cases where privacy is paramount, but TLS or DTLS 329 transport is not available, the ORIGIN attribute MAY be sent with an 330 empty (null) origin value. It is up to the server what to do when 331 receiving such an empty origin. The server could fail the request, 332 or the server could assume an origin and attempt to process the 333 request. 335 The STUN ORIGIN attribute also has privacy implications in that the 336 origin information is shared with a STUN or TURN server which 337 otherwise might not know this information. This information could be 338 used to track usage of real-time communication services. A STUN or 339 TURN server will always know the public IP address of each user, but 340 the ORIGIN attribute provides more information about which service or 341 provider is being used. The particular STUN and TURN servers used 342 are usually selected by the real-time communications service provider 343 (i.e. the web provider for WebRTC or the SIP or XMPP service 344 provider). In addition, they are usually also run by the same 345 provider, or by a trusted partner, especially for TURN. However, a 346 service or provider using an untrusted third party STUN or TURN 347 server needs to recognize that the operator of the third party STUN 348 or TURN server will learn the identity of the service or provider 349 through this extension. In cases where the STUN or TURN client does 350 not wish to share origin information with the server for privacy 351 reasons, the ORIGIN attribute MAY be sent with an empty (null) origin 352 value. It is up to the server what to do when receiving such an 353 empty origin. The server could fail the request, or the server could 354 assume an origin and attempt to process the request. 356 5. Implementation Status 358 Note to RFC Editor: Please remove this entire section prior to 359 publication, including the reference to RFC 6982. 361 This section records the status of known implementations of the 362 protocol defined by this specification at the time of posting of this 363 Internet-Draft, and is based on a proposal described in [RFC6982]. 364 The description of implementations in this section is intended to 365 assist the IETF in its decision processes in progressing drafts to 366 RFCs. Please note that the listing of any individual implementation 367 here does not imply endorsement by the IETF. Furthermore, no effort 368 has been spent to verify the information presented here that was 369 supplied by IETF contributors. This is not intended as, and must not 370 be construed to be, a catalog of available implementations or their 371 features. Readers are advised to note that other implementations may 372 exist. 374 According to [RFC6982], "this will allow reviewers and working groups 375 to assign due consideration to documents that have the benefit of 376 running code, which may serve as evidence of valuable experimentation 377 and feedback that have made the implemented protocols more mature. 378 It is up to the individual working groups to use this information as 379 they see fit". 381 Two proof-of-concept implementations have been created in support of 382 this proposed standard. One provides a WebRTC enabled browser that 383 includes the appropriate STUN ORIGIN Attribute with the Origin 384 insight known to the browser in STUN/TURN messages sent to servers. 385 The other provides an example of a multiple realms capable TURN 386 server that takes advantage of Origin insight provided in the STUN 387 ORIGIN Attribute. 389 A Chrome browser implementation has been created by Graham Yoakum and 390 Ryan Yoakum (Skobalt LLC) and is freely licensed under the standard 391 terms of the open source Chromium and WebRTC projects. This proof- 392 of-concept version of the Google Chrome browser (nicknamed 'Chromeo') 393 sends Origin insight in STUN and TURN messages using the proposed new 394 STUN ORIGIN attribute with a value of 0x802F (as initially proposed, 395 however that value is easily changed in a single line of code). 396 'Chromeo' includes a Chrome flag to enable and disable this unique 397 feature (and is by default disabled to prevent any non-intentional 398 use of this feature until the standard is finalized). This 399 implementation is based on is draft-johnston-tram-stun-origin-02. 401 Coordinated changes to both the WebRTC and Chromium open source 402 projects have been formally submitted for consideration. The two 403 submitted change lists together implement the complete browser proof- 404 of-concept. 'Chromeo' has been built for Linux and STUN protocol 405 behavior has been verified using WireShark traces illustrating that 406 proper STUN Origin attributes are being included in STUN/TURN 407 messages sent by the browser to servers (screen captures of STUN 408 messages illustrating the Origin attribute and content are 409 available). 411 The WebRTC and Chromium open source projects can be found at: 412 http://www.webrtc.org/ and http://www.chromium.org/ 414 Google can choose to accept or modify the changes proposed for Chrome 415 and other browser vendors can access and take advantage of the 416 publicly available WebRTC and Chromium open source submissions as 417 desired. Hopefully this will enable browsers to quickly implement 418 STUN Origin enhancements. 420 A multiple realms capable advanced open source Origin enabled TURN 421 server (named 'Coturn') has been created by Oleg Moskalenko and is 422 freely licensed under the New BSD license. This reference 423 implementation and proof-of-concept provides a clone (a spin-off) of 424 the rfc5766-turn-server project adding Origin-based multiple realms 425 support. 427 'Coturn' is backward-compatible with rfc5766-turn-server project but 428 the code is more complex and it uses a different (also more complex) 429 database structure. It is the intent to add all IETF TRAM TURN 430 server related capabilities to this project as they mature. 'Coturn' 431 is publicly available and can be found at: 432 https://code.google.com/p/coturn/ 434 6. Acknowledgements 436 Thanks to John Selbie, Tirumaleswar Reddy, Simon Perreault, Marc 437 Petit-Huguenin, Andy Hutton, and Oleg Moskalenko for their feedback 438 and reviews. Special thanks to Graham Yoakum and Ryan Yoakum of 439 Skobalt LLC and Oleg Moskalenko of rfc5766-turn-server project for 440 contributing open source proof-of-concept implementations for a 441 Chrome web browser and a multiple realms capable TURN server, quickly 442 demonstrating feasibility. 444 7. References 446 7.1. Normative References 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, March 1997. 451 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 452 A., Peterson, J., Sparks, R., Handley, M., and E. 453 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 454 June 2002. 456 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 457 10646", STD 63, RFC 3629, November 2003. 459 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 460 (IRIs) and Uniform Resource Identifiers (URIs) for the 461 Extensible Messaging and Presence Protocol (XMPP)", 462 RFC 5122, February 2008. 464 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 465 (ICE): A Protocol for Network Address Translator (NAT) 466 Traversal for Offer/Answer Protocols", RFC 5245, 467 April 2010. 469 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 470 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 471 October 2008. 473 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 474 Initiated Connections in the Session Initiation Protocol 475 (SIP)", RFC 5626, October 2009. 477 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 478 Relays around NAT (TURN): Relay Extensions to Session 479 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 481 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 482 Protocol (XMPP): Core", RFC 6120, March 2011. 484 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 485 Protocol (XMPP): Address Format", RFC 6122, March 2011. 487 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 488 December 2011. 490 [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 491 Layer Security (DTLS) as Transport for Session Traversal 492 Utilities for NAT (STUN)", RFC 7350, August 2014. 494 7.2. Informative References 496 [I-D.ietf-rtcweb-overview] 497 Alvestrand, H., "Overview: Real Time Protocols for 498 Browser-based Applications", draft-ietf-rtcweb-overview-13 499 (work in progress), November 2014. 501 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 502 Using Session Traversal Utilities for NAT (STUN)", 503 RFC 5780, May 2010. 505 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 506 Code: The Implementation Status Section", RFC 6982, 507 July 2013. 509 [RFC7376] Reddy, T., Ravindranath, R., Perumal, M., and A. Yegin, 510 "Problems with Session Traversal Utilities for NAT (STUN) 511 Long-Term Authentication for Traversal Using Relays around 512 NAT (TURN)", RFC 7376, September 2014. 514 [WebRTC-API] 515 Bergkvist, A., Burnett, D., Jennings, C., and A. 516 Narayanan, "WebRTC 1.0: Real-time Communication Between 517 Browsers", W3C Working Draft http://www.w3.org/TR/webrtc/, 518 2013, . 520 Authors' Addresses 522 Alan Johnston 523 Avaya 524 St. Louis, MO 525 USA 527 Phone: 528 Email: alan.b.johnston@gmail.com 530 Justin Uberti 531 Google 532 Kirkland, WA 533 USA 535 Phone: 536 Email: justin@uberti.name 538 John Yoakum 539 Avaya 540 Cary, NC 541 USA 543 Phone: 544 Email: yoakum@avaya.com 545 Kundan Singh 546 Avaya 547 San Francisco, CA 548 USA 550 Phone: 551 Email: kundan10@gmail.com