idnits 2.17.1 draft-reddy-mmusic-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 (October 15, 2012) is 4210 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) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-09 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MMUSIC T. Reddy 2 Internet-Draft Muthu A M. Perumal 3 Intended status: Standards Track Ram Mohan. Ravindranath 4 Expires: April 18, 2013 D. Wing 5 Cisco 6 October 15, 2012 8 STUN Extensions for Firewall Traversal 9 draft-reddy-mmusic-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 April 18, 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 . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Different Components and the Trust model . . . . . . . . . 6 62 5. Usage and Processing . . . . . . . . . . . . . . . . . . . . . 6 63 5.1. Generating FW-FLOWDATA Attribute . . . . . . . . . . . . 6 64 5.2. Sending FW-FLOWDATA Attribute in Binding Request . . . . . 7 65 5.3. Firewalls processing FW-FLOWDATA Attribute . . . . . . . . 7 66 6. STUN Attribute Format . . . . . . . . . . . . . . . . . . . . 9 67 7. Key Provisioning . . . . . . . . . . . . . . . . . . . . . . . 10 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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, transport protocol and ports from the 86 session description and creates dynamic mapping for media to flow 87 through. This model has 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 TURN is also used as an alternative to permit media traffic, i.e. 120 Use TCP transport between the client and TURN server because 121 Firewalls are configured to block UDP entirely. 123 The use-case is explained in Section 4.2.4.1 of 125 [I-D.ietf-rtcweb-use-cases-and-requirements] refers to deploying a 126 TURN server to audit all media sessions from inside the company 127 premises to any external peer. 129 Using TURN for all such communication has the following problems: 131 o Single TURN server will result in single point of failure. 133 o TURN server could increase media latency and high-end TURN server 134 would be needed to cater to all such calls. 136 o TURN server is just providing the 5-tuple details (source IP 137 address, destination IP address, protocol number, source port 138 number, and destination port number) but no other details of the 139 WebRTC server using which the call is initiated 141 o Enterprise firewalls would typically have granular policies to 142 permit call initiated using selected WebRTC servers (Dr.Good) it 143 trusts and block others (Dr.Evil). 145 o It comes at a high cost to the provider of the TURN server, since 146 the server typically needs a high-bandwidth connection to the 147 Internet. As a consequence, it is best to use a TURN server only 148 when a direct communication path cannot be found. When the client 149 and a peer use ICE to determine the communication path, ICE will 150 use hole punching techniques to search for a direct path first and 151 only use a TURN server when a direct path cannot be found. 153 o The value of the Diffserv field may not be preserved. 155 o The Explicit Congestion Notification (ECN) field may be reset. 157 This draft has a solution where an authorized server (could be a Call 158 Agent or a WebRTC server ) generate a cryptographic token which is 159 passed to the endpoints. The endpoint includes the token in its ICE 160 connectivity checks. The firewall intercepts the ICE connectivity 161 checks containing the token, validates it, and permits the ICE 162 connectivity checks and the subsequent media flow through the 163 firewall. 165 2. Notational Conventions 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 This note uses terminology defined in [RFC5245]. 173 3. Problem Statement 175 In the below topology, an webRTC Server is deployed in the enterprise 176 Data Center. Alice makes a webRTC call to Bob. For the two endpoints 177 to successfully establish media sessions, firewalls FW1 and FW2 need 178 to permit the ICE connectivity checks and media traffic. In such 179 scenarios the mechanism described in this draft proposes a new 180 comprehension-optional FW-FLOWDATA STUN attribute to be included in 181 STUN Bind requests sent during ICE connectivity checks so that 182 firewalls will permit media traffic between internal peers. This 183 STUN attribute is created by the trusted WebRTC server and sent to 184 the endpoints to be propagated by the respective ICE agents during 185 ICE connectivity checks. 187 ========================= 188 | WebRTC Server | 189 ========================= 190 | Data Center 191 | 192 | 193 ================== 194 | WAN |-----+-+-------+---+----+-+-----+ 195 ================== | 196 | Branch office 2 | 197 Branch office 1 | | 198 | | 199 +-------+-------+ +----+-------+ 200 | Firewall 1 | | Firewall 2 | 201 | | | | 202 +-------+-------+ +----+-------+ 203 | | 204 | | 205 | | 206 ---+-+-----+-----------+-+-----+-------- -----+-+-----+------ 207 | | 208 +-+------+ +--------+ 209 | Alice | | Bob | 210 +--------+ +--------+ 212 Figure 1: WebRTC service in enterprise - internal call 214 4. Solution Overview 216 This section gives an overview of the solution and the different 217 components involved in the solution and the role of each component. 219 4.1. Different Components and the Trust model 221 Figure 1 above shows typical components involved in a WebRTC call 222 scenario. As part of the call setup, the WebRTC endpoint would have 223 to gather its candidates from a STUN/TURN server, send the candidates 224 in the offer to the peer endpoint. On receiving the answer from the 225 peer endpoint it starts the ICE connectivity checks. As discussed in 226 the problem statement, firewalls would typically block these ICE 227 connectivity checks and media flowing there after. To allow this 228 traffic a firewall needs to authorize the flow. 230 o A new comprehensive optional STUN attribute called FW-FLOWDATA is 231 defined as part of this draft. This is used by WebRTC endpoints 232 requiring firewall traversal. 234 o This STUN attribute FW-FLOWDATA is generated by the WebRTC server 235 in co-ordination with the WebRTC endpoint. 237 o Once the WebRTC session ends the firewall's dynamic mappings are 238 closed after timeout. 240 o DISCUSSION: Could we could have a FW-FLOWDATA attribute sent in a 241 STUN message to close the dynamic mappings in the firewalls? 243 5. Usage and Processing 245 An RTP endpoint which generates media can include the FW-FLOWDATA 246 attribute in its STUN Binding requests used in ICE connectivity 247 checks, to inform on-path firewalls to permit the flow. 249 5.1. Generating FW-FLOWDATA Attribute 251 The WebRTC server after processing the OFFER/ANSWER sends the FW- 252 FLOWDATA STUN attribute to both the peers to be included in the ICE 253 connectivity checks. The Authentication Tag field in the FW-FLOWDATA 254 attribute contains the digest of the FW-FLOWDATA attribute for data 255 origin authentication and integrity protection. The server first 256 selects the candidate address info based on OFFER/ANSWER exchange and 257 generates other fields of this attribute. The server then computes a 258 digest for the FW-FLOWDATA attribute using HMAC-SHA1. The key for 259 HMAC-SHA1 is provisioned using the technique in Section 7. The 260 result of which is truncated to 96 bits (retaining the left most 261 bits) to produce HMAC-SHA-1-96 and input into the Authentication Tag 262 field. The mechanism to send FW-FLOWDATA attribute from the WebRTC 263 server to the cient is outside the scope of this draft. But it is 264 assumed that signalling protocols used for WebRTC call setup will be 265 enhanced to deliver this new attribute to the WebRTC client. The 266 WebRTC server MUST provide a new FW-FLOWDATA to allow the media 267 session to continue before Lifetime expires. 269 5.2. Sending FW-FLOWDATA Attribute in Binding Request 271 Once a WebRTC endpoint receives the FW-FLOWDATA, it is responsible 272 for generating the STUN message and retransmitting the transactions 273 per the STUN specification. The FW-FLOWDATA attribute should be 274 placed before the FINGERPRINT attribute (if present) and after the 275 MESSAGE-INTEGRITY attribute. The STUN length field is adjusted to 276 point to the new end of the STUN message; that is, the STUN length 277 field always accurately indicates the length of the STUN message 278 (including the MESSAGE-INTEGRITY, FINGERPRINT, and FW-FLOWDATA 279 attributes). This does not interfere with 3rd party receivers of the 280 STUN message, as they will adjust the STUN length field to point to 281 the end of the MESSAGE-INTEGRITY field. Receivers that do not 282 understand the FW-FLOWDATA will ignore it. 284 FW-FLOWDATA attribute received by the WebRTC client is passed to the 285 web browser's ICE agent (API to be added in in W3C WebRTC-API 286 specification [I.D.w3c-webrtc]). The ICE agent includes the FW- 287 FLOWDATA attribute with all ICE connectivity checks, so that on-path 288 firewalls can validate and permit the ICE connectivity checks and 289 forthcoming media. The token MUST included in the ICE binding 290 indication packets (keepalive) (In case the lifetime expires) 292 For the FW-FLOWDATA attribute to be visible to the firewalls between 293 the client and the TURN server, the FW-FLOWDATA should be included in 294 the ALLOCATE request, channel bind or refresh messages going to the 295 TURN server. This is to avoid firewalls having to look for STUN 296 packets within STUN (TURN) packets. 298 5.3. Firewalls processing FW-FLOWDATA Attribute 300 Firewalls can reliably determine a UDP message is a STUN message 301 because all STUN messages sent as ICE connectivity checks include the 302 32-bit STUN magic cookie and the FINGERPRINT attribute. STUN 303 messages which are authenticated also include a MESSAGE-INTEGRITY 304 attribute which authenticates the fields prior to the MESSAGE- 305 INTEGRITY. 307 When the firewall receives a STUN binding request with FW-FLOWDATA 308 attribute it stores the Authentication Tag in the FW-FLOWDATA 309 attribute. The firewall then generates a digest for the FW-FLOWDATA 310 attribute using HMAC-SHA1. The result of which is truncated to 96 311 bits (retaining the left most bits) to produce HMAC-SHA-1-96. If the 312 value of the newly generated digest HMAC-SHA-1-96 is identical to the 313 stored one, the firewall can ensure that the FW-FLOWDATA attribute 314 has not been tampered with. Otherwise the packet is discarded. 316 To facilitate timestamp checking for replay attacks, each firewall 317 should perform the following check for each message: 319 When a message is received, the received timestamp, TSnew, is 320 checked, and the packet is accepted if the timestamp is recent enough 321 to the reception time of the packet, RDnew: 323 Lifetime + Delta > (RDnew - TSnew) 325 The recommended value for the allowed Delta is 30 seconds. If the 326 timestamp is NOT within the boundaries then discard the STUN message. 328 The firewall also performs the following checks: 330 o Ensures that the source IP address and UDP port of the packet 331 matches with one of the local CAI entries in the payload except 332 for peer-reflexive cases. 334 o Ensures the destination IP address and UDP port of the packet 335 matches with one of the local CAI entries in the packet payload 336 except for peer-reflexive cases. 338 o Firewall if located after NAT(peer-reflexive cases) can skip CAI 339 processing (It can be configurable option). For peer-reflexive 340 case, destination CAI MUST match in case of outgoing STUN packet 341 and source CAI MUST match incase of incoming STUN packet 343 If all the above checks pass then the firewall creates the 5-tuple 344 dynamic mapping using the local candidate IP address, local candidate 345 port, remote candidate IP address, remote candidate port, transport 346 protocol. The session time of the dynamic mapping will be set to a 347 short lifetime (default value of 60 seconds). 349 If the initial ICE connectivity check includes the ICE-CONTROLLING 350 attribute but does not include USE-CANDIDATE, ICE connectivity check 351 is successful and a subsequent ICE connectivity check includes both 352 these attributes, the firewall can determine that the ICE agent is 353 the controlling agent using regular nomination and this candidate 354 pair is nominated for media flow. The firewall then sets the session 355 time of the dynamic mapping equal to the Lifetime field in FW- 356 FLOWDATA attribute. 358 If the initial ICE connectivity check includes the ICE-CONTROLLING 359 attribute and the USE-CANDIDATE attribute, firewall can determine 360 that the ICE agent is the controlling agent using aggressive using 361 nomination. If the ICE connectivity check is successful It then 362 waits for the media traffic to flow before setting the session time 363 of the dynamic mapping equal to Lifetime field in FW-FLOWDATA 364 attribute. 366 DISCUSSION: If WebRTC implementations of RTP support multiplexing of 367 multiple media sessions onto a single RTP session, FW-FLOWDATA 368 attribute can be enhanced to carry a flag indicating the same so that 369 firewall can immediately close the dynamic mapping created for other 370 pairs in the ICE checklist once media starts flowing on one the 371 candidate pairs. In case of multi-homing firewalls can track 372 multiple host IP addresses using authentication supplicant or, for 373 hosts lacking the supplicant, use address-based authentication 374 method. 376 6. STUN Attribute Format 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Lifetime | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Nonce | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Timestamp | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | LCA Count | RCA Count | Reserved | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | | 390 | Candidate Address Info | 391 | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | | 394 | Authentication Tag | 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Figure 2: FW-FLOWDATA Attribute 400 Lifetime: 32-bit unsigned integer. The length of time in seconds 401 that the STUN attribute is valid for the purpose of firewall 402 creating dynamic mapping. The lifetime of the firewall dynamic 403 mapping is set to this value. After the lifetime expires the 404 mapping is deleted, unless the lifetime is extended using a 405 another FW-FLOWDATA attribute. 407 Nonce: 96-bit unsigned integer. Random value chosen by the WebRTC 408 Server that uniquely identifies the STUN attribute. 410 Timestamp: 64-bit unsigned integer field containing a timestamp. 411 The value indicates the number of seconds since January 1, 1970, 412 00:00 UTC, by using a fixed point format. In this format, the 413 integer number of seconds is contained in the first 48 bits of the 414 field, and the remaining 16 bits indicate the number of 1/64K 415 fractions of a second. 417 LCA Count: 8-bit unsigned integer. Number of local candidate 418 addresses. 420 RCA Count: 8-bit unsigned integer. Number of remote candidate 421 addresses. 423 Reserved: 16-bit unsigned integer. An unused field. It MUST be 424 initialized to zero by the sender and MUST be ignored by the 425 receiver. 427 Candidate Address Info: 428 0 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 |Family | Protocol | Port | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | | 434 | Address (32 bits or 128 bits) | 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 It consists of an 8-bit address family, L4 protocol (for example 438 17 for UDP, 6 for TCP) and a 16-bit port, followed by a fixed- 439 length value representing the IP address. If the 16-bit port 440 value is 0 it indicates "all ports". The address family can take 441 on the following values: 0x01:IPv4 and 0x02:IPv6. An endpoint may 442 send Zero or more CAI in its FLOWDATA 444 Authentication Tag: A 96-bit field that carries the Message 445 Authentication Code for the FW-FLOWDATA STUN attribute. 447 7. Key Provisioning 449 Static keys are preconfigured, either manually or through a network 450 management system. The simplest way to implement FW-FLOWDATA 451 validation is to use static keys. The provisioning of static keys 452 requires either manual operator intervention on the WebRTC Server and 453 each firewall in the enterprise or a network management system 454 performing the same task. 456 Alternatively using Dynamic Group Key Distribution, group keys are 457 dynamically distributed among the WebRTC server and enterprise 458 firewalls using GDOI [RFC6407]. In this way, each firewall requests 459 a group key from a key server as part of an encrypted and integrity- 460 protected key agreement protocol. Once the key server has 461 authenticated and authorized the firewalls, it distributes a group 462 key to the group member. The authentication in this model can be 463 based on public key mechanisms, thereby avoiding the need for static 464 key provisioning. 466 8. Security Considerations 468 Hosts using WebRTC calls will see lot of FW-FLOWDATA attributes. 469 They determine the key by trying a number of candidate keys and 470 seeing if one of them is correct. The attack works when the keys 471 have low entropy, such as a word from the dictionary. This attack 472 can be mitigated by using strong keys with large entropy. In 473 situations where even stronger mitigation is required, the keys can 474 be dynamically changed using GDOI. The WebRTC server controls how 475 long a firewall session is kept open via the Lifetime value and 476 WebRTC server could use different Lifetime values depending on the 477 anticipated level of trust of the device (e.g. company provided 478 laptop might be trusted more than a Bring Your Own Device (BYOD)); 479 the device with more trust need to obtain its authentication 480 attribute less often). Firewalls in addition to timestamp checking 481 can also maintain a cache of used Nonces, IP source addresses 482 associated with used Nonces as an effective countermeasure against 483 replay attacks. 485 All the security considerations applicable to STUN [RFC5389] and ICE 486 [RFC5245] are applicable to this document as well. 488 9. IANA Considerations 490 Allocate new STUN attribute value for FW-FLOWDATA from the 491 [STUN-ATTR] registry. 493 10. Acknowledgements 495 The authors would like to thank Prashanth Patil and Ramesh Nethi for 496 review comments. 498 11. References 500 11.1. Normative References 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, March 1997. 505 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 506 (ICE): A Protocol for Network Address Translator (NAT) 507 Traversal for Offer/Answer Protocols", RFC 5245, 508 April 2010. 510 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 511 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 512 October 2008. 514 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 515 of Interpretation", RFC 6407, October 2011. 517 11.2. Informative References 519 [I-D.ietf-rtcweb-use-cases-and-requirements] 520 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 521 Time Communication Use-cases and Requirements", 522 draft-ietf-rtcweb-use-cases-and-requirements-09 (work in 523 progress), June 2012. 525 [STUN-ATTR] 526 IANA, "IANA: STUN Attributes", December 2011, . 530 Authors' Addresses 532 Tirumaleswar Reddy 533 Cisco Systems, Inc. 534 Cessna Business Park, Varthur Hobli 535 Sarjapur Marathalli Outer Ring Road 536 Bangalore, Karnataka 560103 537 India 539 Email: tireddy@cisco.com 540 Muthu Arul Mozhi Perumal 541 Cisco Systems, Inc. 542 Cessna Business Park, Varthur Hobli 543 Sarjapur Marathalli Outer Ring Road 544 Bangalore, Karnataka 560103 545 India 547 Email: mperumal@cisco.com 549 Ram Mohan Ravindranath 550 Cisco Systems, Inc. 551 Cessna Business Park, Varthur Hobli 552 Sarjapur Marathalli Outer Ring Road 553 Bangalore, Karnataka 560103 554 India 556 Email: rmohanr@cisco.com 558 Dan Wing 559 Cisco Systems, Inc. 560 170 West Tasman Drive 561 San Jose, California 95134 562 USA 564 Email: dwing@cisco.com