idnits 2.17.1 draft-reddy-rtcweb-stun-auth-fw-traversal-00.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 (July 8, 2012) is 4300 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: 'RFC5766' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtcweb-use-cases-and-requirements' is defined on line 517, 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) == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-09 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RTCWEB T. Reddy 2 Internet-Draft Muthu A M. Perumal 3 Intended status: Standards Track R. Ram Mohan 4 Expires: January 9, 2013 D. Wing 5 Cisco 6 July 8, 2012 8 STUN Extensions for Authenticated Firewall Traversal 9 draft-reddy-rtcweb-stun-auth-fw-traversal-00 11 Abstract 13 Some networks deploy firewalls configured to block UDP traffic. When 14 SIP user agents or WebRTC endpoints are deployed behind such 15 firewalls, media cannot be sent over UDP across the firewall, but 16 must be sent using TCP (which causes a different user experience) or 17 through a session border controller. 19 This draft describes an alternate model wherein extensions to ICE 20 connectivity checks can be examined by the firewall to permit 21 outgoing UDP flows across the firewall. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 9, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 59 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Different Components and the Trust model . . . . . . . . . 5 62 5. Usage and Processing . . . . . . . . . . . . . . . . . . . . . 6 63 5.1. Generating FW-FLOWDATA Attribute . . . . . . . . . . . . 6 64 5.2. Sending FW-FLOWDATA Attribute in Binding Request . . . . . 6 65 5.3. Firewalls processing FW-FLOWDATA Attribute . . . . . . . . 7 66 6. STUN Attribute Format . . . . . . . . . . . . . . . . . . . . 9 67 7. Key Provisioning . . . . . . . . . . . . . . . . . . . . . . . 11 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 To protect networks using real-time communications, firewalls or 79 session border controllers are typically deployed. 81 Firewalls include Application Layer Gateway functionality, which 82 intercepts and analyzes the session signaling traffic such as the 83 Session Initiation Protocol (SIP) traffic and creates dynamic mapping 84 to permit the media traffic. In particular, firewall extracts the 85 media transport addresses and ports from the session description and 86 creates dynamic mapping for media to flow through. This model has 87 the following problems: 89 1. It does not work if the session signaling is end-to-end encrypted 90 (say, using TLS). 92 2. It does not work if a non-standard session signaling is used that 93 the firewall does not understand. 95 3. It does not work if the session signaling and media traverse 96 different firewalls. 98 When an enterprise deploys WebRTC, the above problems are relevant 99 because: 101 1. The session signaling between the WebRTC application running in 102 the browser and the web server could be using TLS. 104 2. WebRTC does not enforce a particular session signaling protocol 105 to be used. So, the firewall may not be able to understand it. 107 3. This session signaling and the peer-to-peer media may traverse 108 different firewalls. 110 As a result the firewall may block ICE connectivity checks and media 111 traffic. 113 Session Border Controllers (SBCs) are active participants with call 114 signaling. Like firewalls, they also create dynamic mappings to 115 permit media traffic. This forces call signaling and media through 116 specific IP addresses, belonging to the SBC or an SBC-controlled 117 media relay device. 119 This draft has the WebRTC server generate a cryptographic token which 120 is passed to the WebRTC endpoint. The endpoint includes the token in 121 its ICE connectivity checks. The firewall intercepts the ICE 122 connectivity checks containing the token, validates it, and permits 123 the ICE connectivity checks and the subsequent media flow through the 124 firewall. 126 2. Notational Conventions 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 This note uses terminology defined in [RFC5245]. 134 3. Problem Statement 136 In the below topology, a WebRTC server is deployed in the enterprise 137 Data Center. Alice makes a WebRTC call to Bob. For the two endpoints 138 to successfully establish media sessions, firewalls FW1 and FW2 need 139 to permit the ICE connectivity checks and media traffic. In such 140 scenarios the mechanism described in this draft proposes a new 141 comprehension-optional FW-FLOWDATA STUN attribute to be included in 142 STUN Bind requests sent during ICE connectivity checks so that 143 firewalls will permit media traffic between internal peers. This 144 STUN attribute is created by the trusted WebRTC server and sent to 145 the endpoints to be propagated by the respective ICE agents during 146 ICE connectivity checks. 148 ==================== 149 | WebRTC Server | 150 ==================== 151 | Data Center 152 | 153 | 154 ================== 155 | WAN |-----+-+-------+---+----+-+-----+ 156 ================== | 157 | Branch office 2 | 158 Branch office 1 | | 159 | | 160 +-------+-------+ +----+-------+ 161 | Firewall 1 | | Firewall 2 | 162 | | | | 163 +-------+-------+ +----+-------+ 164 | | 165 | | 166 | | 167 ---+-+-----+-----------+-+-----+-------- -----+-+-----+------ 168 | | 169 +-+------+ +--------+ 170 | Alice | | Bob | 171 +--------+ +--------+ 173 Figure 1: WebRTC service in enterprise - internal call 175 4. Solution Overview 177 This section gives an overview of the solution and the different 178 components involved in the solution and the role of each component. 180 4.1. Different Components and the Trust model 182 Figure 1 above shows typical components involved in a WebRTC 183 scenario. As part of the call setup, the WebRTC endpoint would have 184 to gather its candidates from a STUN/TURN server, send the candidates 185 in the offer to the peer endpoint. On receiving the answer from the 186 peer endpoint it starts the ICE connectivity checks. As discussed in 187 the problem statement, firewalls would typically block these ICE 188 connectivity checks and media flowing there after. To allow this 189 traffic a firewall needs to authorize the flow. 191 o A new comprehensive optional STUN attribute called FW-FLOWDATA is 192 defined as part of this draft. This is used by WebRTC endpoints 193 requiring firewall traversal. 195 o This STUN attribute FW-FLOWDATA is generated by the WebRTC server 196 in co-ordination with the WebRTC endpoint. 198 o Once the WebRTC session ends the firewall's dynamic mappings are 199 closed after timeout. 201 o DISCUSSION: Could we could have a FW-FLOWDATA attribute sent in a 202 STUN message to close the dynamic mappings in the firewalls? 204 5. Usage and Processing 206 An RTP endpoint which generates media can include the FW-FLOWDATA 207 attribute in its STUN Binding requests used in ICE connectivity 208 checks, to inform on-path firewalls to permit the flow. 210 5.1. Generating FW-FLOWDATA Attribute 212 The WebRTC server after processing the OFFER/ANSWER sends the FW- 213 FLOWDATA STUN attribute to both the peers to be included in the ICE 214 connectivity checks. The Authentication Tag field in the FW-FLOWDATA 215 attribute contains the digest of the FW-FLOWDATA attribute for data 216 origin authentication and integrity protection. The server first 217 selects the candidate address info based on OFFER/ANSWER exchange and 218 generates other fields of this attribute. The server then computes a 219 digest for the FW-FLOWDATA attribute using HMAC-SHA1. The key for 220 HMAC-SHA1 is provisioned using the technique in Section 7. The 221 result of which is truncated to 96 bits (retaining the left most 222 bits) to produce HMAC-SHA-1-96 and input into the Authentication Tag 223 field. The mechanism to send FW-FLOWDATA attribute from the WebRTC 224 server to the cient is outside the scope of this draft. But it is 225 assumed that signalling protocols used for WebRTC call setup will be 226 enhanced to deliver this new attribute to the WebRTC client. The 227 WebRTC server MUST provide a new FW-FLOWDATA to allow the media 228 session to continue before Lifetime expires. 230 5.2. Sending FW-FLOWDATA Attribute in Binding Request 232 Once a WebRTC endpoint receives the FW-FLOWDATA, it is responsible 233 for generating the STUN message and retransmitting the transactions 234 per the STUN specification. The FW-FLOWDATA attribute should be 235 placed before the FINGERPRINT attribute (if present) and after the 236 MESSAGE-INTEGRITY attribute. The STUN length field is adjusted to 237 point to the new end of the STUN message; that is, the STUN length 238 field always accurately indicates the length of the STUN message 239 (including the MESSAGE-INTEGRITY, FINGERPRINT, and FW-FLOWDATA 240 attributes). This does not interfere with 3rd party receivers of the 241 STUN message, as they will adjust the STUN length field to point to 242 the end of the MESSAGE-INTEGRITY field. Receivers that do not 243 understand the FW-FLOWDATA will ignore it. 245 FW-FLOWDATA attribute received by the WebRTC client is passed to the 246 web browser's ICE agent (API to be added in in W3C WebRTC-API 247 specification [I.D.w3c-webrtc]). The ICE agent includes the FW- 248 FLOWDATA attribute with all ICE connectivity checks, so that on-path 249 firewalls can validate and permit the ICE connectivity checks and 250 forthcoming media. 252 For the FW-FLOWDATA attribute to be visible to the firewalls between 253 the client and the TURN server, the FW-FLOWDATA should be included in 254 the ALLOCATE request, channel bind or refresh messages going to the 255 TURN server. This is to avoid firewalls having to look for STUN 256 packets within STUN (TURN) packets. 258 5.3. Firewalls processing FW-FLOWDATA Attribute 260 Firewalls can reliably determine a UDP message is a STUN message 261 because all STUN messages sent as ICE connectivity checks include the 262 32-bit STUN magic cookie and the FINGERPRINT attribute. STUN 263 messages which are authenticated also include a MESSAGE-INTEGRITY 264 attribute which authenticates the fields prior to the MESSAGE- 265 INTEGRITY. 267 When the firewall receives a STUN binding request with FW-FLOWDATA 268 attribute it stores the Authentication Tag in the FW-FLOWDATA 269 attribute. The firewall then generates a digest for the FW-FLOWDATA 270 attribute using HMAC-SHA1. The result of which is truncated to 96 271 bits (retaining the left most bits) to produce HMAC-SHA-1-96. If the 272 value of the newly generated digest HMAC-SHA-1-96 is identical to the 273 stored one, the firewall can ensure that the FW-FLOWDATA attribute 274 has not been tampered with. Otherwise the packet is discarded. 276 To facilitate timestamp checking for replay attacks, each firewall 277 SHOULD store the following information for each host: (The timestamp 278 check is mostly brought from SEND [RFC3971]) 280 o The receive time of the last received and accepted STUN message 281 with FW-FLOWDATA Attribute. This is called RDlast. 283 o The timestamp in the last received and accepted STUN message with 284 FW-FLOWDATA Attribute. This is called TSlast. 286 When a message is received from a new host (i.e., one that is not 287 stored in the cache), the received timestamp, TSnew, is checked, and 288 the packet is accepted if the timestamp is recent enough to the 289 reception time of the packet, RDnew: 291 -Delta < (RDnew - TSnew) < +Delta 293 The recommended value for the allowed Delta is 180 seconds. If the 294 timestamp is NOT within the boundaries then discard the STUN message. 296 When a message is received from a known host (i.e., one that already 297 has an entry in the cache), the timestamp is checked against the 298 previously received STUN message with FW-FLOWDATA Attribute: 300 TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz 302 If this inequality does not hold, firewall SHOULD discard the 303 message. If, on the other hand, the inequality holds, then firewall 304 SHOULD process the message. Moreover, if the above inequality holds 305 and TSnew > TSlast, the receiver SHOULD update RDlast and TSlast. 306 Otherwise, the receiver MUST NOT update RDlast or TSlast. The 307 default value of fuzz is 1 second and drift 1 % (0.01). 309 The firewall also performs the following checks: 311 o Ensures that the source IP address and UDP port of the packet 312 matches with one of the local CAI entries or remote CAI entries in 313 the payload unless the firewall is configured to ignore this 314 check. 316 o Ensures the destination IP address and UDP port of the packet 317 matches with one of the remote CAI entries or local CAI entries in 318 the packet payload. 320 If all the above checks pass then the firewall creates the 5-tuple 321 dynamic mapping using the local candidate IP address, local candidate 322 port, remote candidate IP address, remote candidate port, transport 323 protocol. The session time of the dynamic mapping will be set to a 324 short lifetime (default value of 60 seconds). 326 o If the initial ICE connectivity check includes the ICE-CONTROLLING 327 attribute but does not include USE-CANDIDATE and a subsequent ICE 328 connectivity check includes both these attributes, the firewall can 329 determine that the ICE agent is the controlling agent using regular 330 nomination and this candidate pair is nominated for media flow. The 331 firewall then sets the session time of the dynamic mapping equal to 332 the Lifetime field in FW-FLOWDATA attribute. 334 o If the initial ICE connectivity check includes the ICE-CONTROLLED 335 attribute but does not include USE-CANDIDATE and a subsequent ICE 336 connectivity check includes both the attributes, the firewall can 337 determine that the ICE agent is the controlled agent using regular 338 nomination and this candidate pair is nominated for media flow. The 339 firewall then sets the session time of the dynamic mapping equal to 340 the Lifetime field in FW-FLOWDATA attribute. 342 o If the initial ICE connectivity check includes the ICE-CONTROLLING 343 attribute and the USE-CANDIDATE attribute, firewall can determine 344 that the ICE agent is the controlling agent using aggressive using 345 nomination. It then waits for the media traffic to flow before 346 setting the session time of the dynamic mapping equal to Lifetime 347 field in FW-FLOWDATA attribute. 349 o If the initial ICE connectivity check includes the ICE-CONTROLLED 350 attribute and the USE-CANDIDATE attribute, the firewall can determine 351 that the ICE agent is the controlled agent using aggressive 352 nomination. Tt then waits for the media traffic to flow before 353 setting session time of the dynamic mapping equal to Lifetime field 354 in FW-FLOWDATA Attribute. 356 This technique would ensure that dynamic mappings created for pairs 357 in ICE checklist which are not nominated for sending media will be 358 removed after a short duration of time. 360 DISCUSSION: If WebRTC implementations of RTP support multiplexing of 361 multiple media sessions onto a single RTP session, FW-FLOWDATA 362 attribute can be enhanced to carry a flag indicating the same so that 363 firewall can immediately close the dynamic mapping created for other 364 pairs in the ICE checklist once media starts flowing on one the 365 candidate pairs. In case of multi-homing firewalls can track 366 multiple host IP addresses using authentication supplicant or, for 367 hosts lacking the supplicant, use address-based authentication 368 method. 370 6. STUN Attribute Format 371 0 1 2 3 372 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Lifetime | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Nonce | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Timestamp | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | LCA Count | RCA Count | Reserved | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | 383 | Candidate Address Info | 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | | 387 | Authentication Tag | 388 | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Figure 2: FW-FLOWDATA Attribute 393 Lifetime: 32-bit unsigned integer. The length of time in seconds 394 that the STUN attribute is valid for the purpose of firewall 395 creating dynamic mapping. The lifetime of the firewall dynamic 396 mapping is set to this value. After the lifetime expires the 397 mapping is deleted, unless the lifetime is extended using a 398 another FW-FLOWDATA attribute. 400 Nonce: 96-bit unsigned integer. Random value chosen by the WebRTC 401 Server that uniquely identifies the STUN attribute. 403 Timestamp: 64-bit unsigned integer field containing a timestamp. 404 The value indicates the number of seconds since January 1, 1970, 405 00:00 UTC, by using a fixed point format. In this format, the 406 integer number of seconds is contained in the first 48 bits of the 407 field, and the remaining 16 bits indicate the number of 1/64K 408 fractions of a second. 410 LCA Count: 8-bit unsigned integer. Number of local candidate 411 addresses. 413 RCA Count: 8-bit unsigned integer. Number of remote candidate 414 addresses. 416 Reserved: 16-bit unsigned integer. An unused field. It MUST be 417 initialized to zero by the sender and MUST be ignored by the 418 receiver. 420 Candidate Address Info: 421 0 1 2 3 422 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 |Family | Protocol | Port | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | | 427 | Address (32 bits or 128 bits) | 428 | | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 It consists of an 8-bit address family, L4 protocol (for example 431 17 for UDP, 6 for TCP) and a 16-bit port, followed by a fixed- 432 length value representing the IP address. If the 16-bit port 433 value is 0 it indicates "all ports". The address family can take 434 on the following values: 0x01:IPv4 and 0x02:IPv6. 436 Authentication Tag: A 96-bit field that carries the Message 437 Authentication Code for the FW-FLOWDATA STUN attribute. 439 7. Key Provisioning 441 Static keys are preconfigured, either manually or through a network 442 management system. The simplest way to implement FW-FLOWDATA 443 validation is to use static keys. The provisioning of static keys 444 requires either manual operator intervention on the WebRTC Server and 445 each firewall in the enterprise or a network management system 446 performing the same task. 448 Alternatively using Dynamic Group Key Distribution, group keys are 449 dynamically distributed among the WebRTC server and enterprise 450 firewalls using GDOI [RFC6407]. In this way, each firewall requests 451 a group key from a key server as part of an encrypted and integrity- 452 protected key agreement protocol. Once the key server has 453 authenticated and authorized the firewalls, it distributes a group 454 key to the group member. The authentication in this model can be 455 based on public key mechanisms, thereby avoiding the need for static 456 key provisioning. 458 8. Security Considerations 460 Hosts using WebRTC calls will see lot of FW-FLOWDATA attributes. 461 They determine the key by trying a number of candidate keys and 462 seeing if one of them is correct. The attack works when the keys 463 have low entropy, such as a word from the dictionary. This attack 464 can be mitigated by using strong keys with large entropy. In 465 situations where even stronger mitigation is required, the keys can 466 be dynamically changed using GDOI. The WebRTC server controls how 467 long a firewall session is kept open via the Lifetime value and 468 WebRTC server could use different Lifetime values depending on the 469 anticipated level of trust of the device (e.g. company provided 470 laptop might be trusted more than a Bring Your Own Device (BYOD)); 471 the device with more trust need to obtain its authentication 472 attribute less often). Firewalls in addition to timestamp checking 473 can also maintain a cache of used Nonces, IP source addresses as an 474 effective countermeasure against replay attacks. 476 All the security considerations applicable to STUN [RFC5389] and ICE 477 [RFC5245] are applicable to this document as well. 479 9. IANA Considerations 481 Allocate new STUN attribute value for FW-FLOWDATA from the 482 [STUN-ATTR] registry. 484 10. Acknowledgements 486 The authors would like to thank Prashanth Patil and Ramesh Nethi for 487 review comments. 489 11. References 491 11.1. Normative References 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997. 496 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 497 Neighbor Discovery (SEND)", RFC 3971, March 2005. 499 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 500 (ICE): A Protocol for Network Address Translator (NAT) 501 Traversal for Offer/Answer Protocols", RFC 5245, 502 April 2010. 504 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 505 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 506 October 2008. 508 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 509 Relays around NAT (TURN): Relay Extensions to Session 510 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 512 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 513 of Interpretation", RFC 6407, October 2011. 515 11.2. Informative References 517 [I-D.ietf-rtcweb-use-cases-and-requirements] 518 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 519 Time Communication Use-cases and Requirements", 520 draft-ietf-rtcweb-use-cases-and-requirements-09 (work in 521 progress), June 2012. 523 [STUN-ATTR] 524 IANA, "IANA: STUN Attributes", December 2011, . 528 Authors' Addresses 530 Tirumaleswar Reddy 531 Cisco Systems, Inc. 532 Cessna Business Park, Varthur Hobli 533 Sarjapur Marathalli Outer Ring Road 534 Bangalore, Karnataka 560103 535 India 537 Email: tireddy@cisco.com 539 Muthu Arul Mozhi Perumal 540 Cisco Systems, Inc. 541 Cessna Business Park, Varthur Hobli 542 Sarjapur Marathalli Outer Ring Road 543 Bangalore, Karnataka 560103 544 India 546 Email: mperumal@cisco.com 547 Ram Mohan R 548 Cisco Systems, Inc. 549 Cessna Business Park, Varthur Hobli 550 Sarjapur Marathalli Outer Ring Road 551 Bangalore, Karnataka 560103 552 India 554 Email: rmohanr@cisco.com 556 Dan Wing 557 Cisco Systems, Inc. 558 170 West Tasman Drive 559 San Jose, California 95134 560 USA 562 Email: dwing@cisco.com