idnits 2.17.1 draft-ietf-straw-b2bua-stun-01.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 2, 2015) is 3342 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) ** Downref: Normative reference to an Informational RFC: RFC 3424 ** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389) ** 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 (-03) exists of draft-ram-straw-b2bua-dtls-srtp-01 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 STRAW R. Ravindranath 3 Internet-Draft T. Reddy 4 Intended status: Standards Track G. Salgueiro 5 Expires: August 6, 2015 Cisco 6 February 2, 2015 8 Session Traversal Utilities for NAT (STUN) Message Handling for Session 9 Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) 10 draft-ietf-straw-b2bua-stun-01 12 Abstract 14 Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) 15 are often designed to be on the media path, rather than just 16 intercepting signaling. This means that B2BUAs often act on the 17 media path leading to separate media legs that the B2BUA correlates 18 and bridges together. When acting on the media path, B2BUAs are 19 likely to receive Session Traversal Utilities for NAT (STUN) packets 20 as part of Interactive Connectivity Establishment (ICE) processing. 21 It is critical that B2BUAs handle these STUN messages properly. 23 This document defines behavior for a B2BUA performing ICE processing. 24 The goal of this draft is to ensure that ICE used for NAT and 25 Firewall traversal of multimedia sessions works when there are B2BUAs 26 in place and the B2BUAs handle STUN messages properly. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 6, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Media Plane B2BUAs . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. ICE Termination with B2BUA . . . . . . . . . . . . . . . 5 67 3.3. ICE Passthrough with B2BUAs . . . . . . . . . . . . . . . 8 68 3.4. STUN Handling in B2BUA with Forked Signaling . . . . . . 11 69 4. SDP-Modifying Signaling-only B2BUA . . . . . . . . . . . . . 11 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 8.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 In many SIP deployments, SIP entities exist in the SIP signaling and 81 media path between the originating and final terminating endpoints, 82 which go beyond the definition of a traditional SIP proxy. These SIP 83 entities, commonly known as Back-to-Back User Agents (B2BUAs), are 84 described in [RFC7092] and often perform functions not defined in 85 Standards Track RFCs. 87 The Session Initiation Protocol (SIP) [RFC3261], and other session 88 control protocols that try to use direct path for media, are 89 typically difficult to use across Network Address Translators (NATs). 90 These protocols use IP addresses and transport port numbers encoded 91 in the signaling, such as the Session Description Protocol (SDP) 92 [RFC4566] and, in the case of SIP, various header fields. Such 93 addresses and ports are unreachable unless all peers in a session are 94 located behind the same NAT. 96 Mechanisms such as Session Traversal Utilities for NAT (STUN) 97 [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and 98 Interactive Connectivity Establishment (ICE) [RFC5245] did not exist 99 when protocols like SIP began being deployed. Some mechanisms, such 100 as the early versions of STUN [RFC3489], started appearing but they 101 were unreliable and suffered a number of issues typical for 102 UNilateral Self-Address Fixing (UNSAF) and described in [RFC3424]. 103 For these and other reasons, Session Border Controllers (SBCs) that 104 were already being used by SIP domains for other SIP and media- 105 related purposes began to use proprietary mechanisms to enable SIP 106 devices behind NATs to communicate across the NAT. [RFC7362] 107 describes how B2BUAs can perform Hosted NAT Traversal (HNT) in 108 certain deployments. 110 Section 5 of [RFC7362] describes some of the issues with SBCs 111 implementing HNT and offers some mitigation strategies. The most 112 commonly used approach to solve these issues is "restricted- 113 latching", whereby the B2BUA will not latch to any packets from a 114 source public IP address other than the one the SIP UA uses for SIP 115 signaling. However, this is susceptible to attacks, where an 116 attacker who is able to see the source IP address of the SIP UA may 117 generate packets using the same IP address. There are other threats 118 described in Section 5 of [RFC7362] for which Secure Real-time 119 Transport Protocol (SRTP) [RFC3711] can be used as a solution. 120 However, this would require the B2BUAs to be terminating/re- 121 originating SRTP, which is not always desirable. A B2BUA can use ICE 122 [RFC5245], which provides authentication tokens (conveyed in the ice- 123 ufrag and ice-pwd attributes) that allow the identity of a peer to be 124 confirmed before engaging in media exchange. This can solve some of 125 the security concerns with HNT solution. Further, ICE has other 126 benefits like selecting an address when more than one address is 127 available (e.g., dual-stack environment where host can have both IPv4 128 and IPv6 addresses), verifying that a path works before connecting 129 the call etc. For these reasons endpoints often use ICE to pick a 130 candidate pair for media traffic between two agents. 132 B2BUAs often operate on the media path and have the ability to modify 133 SIP headers and SDP bodies as part of their normal operation. Such 134 entities, when present on the media path, are likely to take an 135 active role in the session signaling depending on their level of 136 activity on the media path. For example, some B2BUAs modify portions 137 of the SDP body (e.g., IP address, port) and subsequently modify the 138 media packet headers as well. Section 18.6 of ICE [RFC5245] explains 139 two different behaviors when B2BUAs are present. Some B2BUAs are 140 likely to remove all the SDP ICE attributes before sending the SDP 141 across to the other side. Consequently, the call will appear to both 142 endpoints as though the other side doesn't support ICE. There are 143 other types of B2BUAs that pass the ICE attributes without 144 modification, yet modify the default destination for media contained 145 in the m= and c= lines and rtcp attribute (defined in [RFC3605]). 146 This will be detected as an ICE mismatch and ICE processing is 147 aborted for the call. The call may continue if the endpoints are 148 able to reach each other over the default candidate (sent in m= and 149 c= lines). 151 Section 3.2 of [RFC7092] describes three different categories of 152 B2BUAs that operates on both signaling(SIP and SDP) and media plane 153 according to the level of involvement and active participation in the 154 media plane: 156 o A B2BUA that acts as a simple media relay effectively unaware of 157 anything that is transported and only modifies the transport 158 header (could be UDP/IP) of the media packets. 160 o A B2BUA that performs a media-aware role. It inspects and 161 potentially modifies RTP or RTP Control Protocol (RTCP) headers; 162 but it does not modify the payload of RTP/RTCP. 164 o A B2BUA that performs a media-termination role and operates at the 165 media payload layer, such as RTP/RTCP payload (e.g., a 166 transcoder). 168 When such a B2BUA operating on a media plane is involved in a call 169 between two endpoints performing ICE, then it MUST follow the 170 behavior described in section 3 of this specification. 172 Section 3.1.3 of [RFC7092] defines a SDP-Modifying Signaling-only 173 B2BUA that operates in the signaling plane only and is not in the 174 media path, but it does modify SDP bodies and is thus aware of and 175 understands SDP syntax and semantics. Such B2BUA MUST follow the 176 behavior mentioned in Section 4 of this specification. 178 2. Terminology 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119]. 184 The following generalized terms are defined in [RFC3261], Section 6. 186 B2BUA: A SIP Back-to-Back User Agent, which is the logical 187 combination of a User Agent Server (UAS) and User Agent Client 188 (UAC). 190 UAS: A SIP User Agent Server. 192 UAC: A SIP User Agent Client. 194 All of the pertinent B2BUA terminology and taxonomy used in this 195 document is based on [RFC7092]. 197 Network Address Translators (NATs) are widely used in the Internet by 198 consumers and organizations. Although specific NAT behaviors vary, 199 this document uses the term "NAT", which maps to NAT and NAPT terms 200 from [RFC3022], for devices that map any IPv4 or IPv6 address and 201 transport port number to another IPv4 or IPv6 address and transport 202 port number. This includes consumer NATs, Firewall-NATs, IPv4-IPv6 203 NATs, Carrier-Grade NATs (CGNs) [RFC6888], etc. 205 3. Media Plane B2BUAs 207 3.1. Overview 209 When one or both of the endpoints are behind a NAT, and there is a 210 B2BUA between the endpoints, the B2BUAs MUST support ICE or at a 211 minimum support ICE LITE functionality as described in [RFC5245]. 212 Such B2BUAs MUST use the mechanism described in Section 2.2 of 213 [RFC5245] to demultiplex STUN packets that arrive on the Real-time 214 Transport Protocol(RTP)/RTP Control Protocol (RTCP) port. 216 The subsequent sections describe the behavior B2BUA's MUST follow for 217 handling ICE messages. A B2BUA can terminate ICE and thus have two 218 ICE contexts with either endpoint. The reason for ICE termination 219 could be due to the need for B2BUA to be in the media path ( e.g., 220 address hiding for privacy, etc.) A B2BUA can also be in ICE 221 passthrough mode and passes across the candidate list from one 222 endpoint to the other side. A B2BUA may be in ICE passthrough mode 223 when it does not have a need to be on the media path. The below 224 sections describes the behaviors for these two cases. 226 3.2. ICE Termination with B2BUA 228 A B2BUA that wishes to be in the media path follows the below steps: 230 o When a B2BUA sends out SDP, it MUST advertise support for ICE and 231 MAY include B2BUA candidates of different types for each component 232 of each media stream. 234 o If the B2BUA is in ICE lite mode as described in Section 2.7 of 235 [RFC5245] then it MUST send a=ice-lite attribute and MUST include 236 B2BUAs host candidates for each component of each media stream. 238 o If the B2BUA supports full ICE then it MAY include B2BUAs 239 candidates of different types for each component of each media 240 stream. 242 o The B2BUA MUST generate new username, password values for ice- 243 ufrag and ice-pwd attributes when it sends out the SDP and MUST 244 NOT propagate the ufrag, password values it received in the 245 incoming SDP. This ensures that the short-term credentials used 246 for both the legs are different. The short-term credentials 247 include authentication tokens (conveyed in the ice-ufrag and ice- 248 pwd attributes), which the B2BUA can use to verify the identity of 249 the peer. B2BUA terminates the ICE messages on each leg and does 250 not propagate them. 252 o The B2BUA MUST NOT propagate the candidate list received in the 253 incoming SDP to the outbound SDP and instead only advertise its 254 candidate list. In this way the B2BUA will be always in the media 255 path. 257 o Depending on whether the B2BUA supports ICE lite or full ICE it 258 implements the appropriate procedures mentioned in [RFC5245] for 259 ICE connectivity checks. 261 +-------+ +------------------+ +-----+ 262 | Alice | | Mediaplane B2BUA | | Bob | 263 +-------+ +------------------+ +-----+ 264 |(1) INVITE | (3)INVITE | 265 | a=ice-ufrag1 | a=ice-ufrag2 | 266 | a=ice-pwd1 | a=ice-pwd2 | 267 | (Alice's IP, port) | (B2BUA's IP, port) | 268 |(Alice's candidate list )| (B2BUA's candidate list)| 269 |------------------------>|-------------------------->| 270 | | | 271 | (2) 100 trying | | 272 |<------------------------| | 273 | | (4) 100 trying | 274 | |<--------------------------| 275 | | (5)200 OK | 276 | | a=ice-ufrag3 | 277 | | a=ice-pwd3 | 278 | | (Bob's IP, port) | 279 | | (Bob's candidate list) | 280 | |<--------------------------| 281 | (6) 200 OK | | 282 | a=ice-ufrag4 |-----------ACK------------>| 283 | a=ice-pwd4 | (7) | 284 | B2BUA's IP,port | | 285 | (B2BUA's cand list1) | | 286 |<------------------------| | 287 |--------ACK------------->| | 288 | (8) | | 289 | | | 290 |<----ICE Connectivity 1->| | 291 | checks+conclusion |<-----ICE Connectivity 2-->| 292 | (9) | checks +conclusion | 293 | | (10) | 294 |<-------Media packets -->|<----Media packets-------->| 295 | (13) | (14) | 296 | | | 297 |<---ICE keepalives 1---->| | 298 | (15) |<----ICE keep alives 2---->| 299 (16) 301 Figure 1: INVITE with SDP having ICE and with a Media Plane B2BUA 303 The above figure shows a sample call flow with two endpoints Alice 304 and Bob doing ICE and a B2BUA handing STUN messages from both the 305 endpoints. For the sake of brevity the entire ICE SDP attributes are 306 not shown. Also the STUN messages exchanged as part of ICE 307 connectivity checks are not shown. Key steps to note from the call 308 flow are: 310 o Alice sends an INVITE with SDP having ICE candidates. 312 o B2BUA modifies the received SDP from Alice by removing the 313 received candidate list, gathers its own candidates, generates new 314 username, password values for ice-ufrag and ice-pwd attributes and 315 forwards the INVITE (3) to Bob. 317 o Bob responds (5) to the INVITE with his own list of candidates. 319 o B2BUA responds to the INVITE from Alice with SDP having B2BUA's 320 candidate list. B2BUA generates new username, password values for 321 ice-ufrag and ice-pwd attributes in the 200 OK response (6). 323 o ICE Connectivity checks happen between Alice and the B2BUA in step 324 9. Depending on whether the B2BUA supports ICE or ICE lite it 325 will follow the appropriate procedures mentioned in [RFC5245]. 326 ICE Connectivity checks also happen between Bob and the B2BUA in 327 step 10. Step 9 and 10 happen in parallel. The B2BUA always 328 terminates the ICE messages on each leg and have two independent 329 ICE contexts running. 331 o Media flows between Alice and Bob via B2BUA (Step 13, 14). 333 o STUN keepalives would be used between Alice and B2BUA (step 15) 334 and between Bob and B2BUA (step 16) to keep NAT and Firewall 335 bindings alive. 337 Since there are two independent ICE contexts on either side of the 338 B2BUA it is possible that ICE checks will conclude on one side before 339 concluding on the other side. This could result in an ongoing media 340 session for one end, while the other is still being set up. Any such 341 media received by the B2BUA would continue to be sent to the other 342 side on the default candidate address (that was sent in c= line). 344 3.3. ICE Passthrough with B2BUAs 346 If a B2BUA does not see a need to be in the media path, it can do the 347 following steps mentioned in this section. 349 o When a B2BUA receives an incoming SDP with ICE semantics it copies 350 the received candidate list and appends its own candidate list in 351 the outgoing SDP. The B2BUA also copies the ufrag/password values 352 it received in the incoming SDP to the outgoing SDP and then sends 353 out the SDP. 355 o The B2BUAs candidates MAY have lower-priority than the candidates 356 provided by the endpoint, this way endpoint and remote peer 357 candidate pairs are tested first before trying candidate pairs 358 with B2BUA candidates. 360 o After offer/answer is complete, the endpoints will have both the 361 B2BUA's and remote peer candidates. It will then use ICE 362 procedures described in [RFC5245] to nominate a candidate pair for 363 sending and receiving media streams. 365 o With this approach the B2BUA will be in the media path only if the 366 ICE checks between all the candidate pairs formed from both the 367 endpoints fail. 369 +-------+ +------------------+ +-----+ 370 | Alice | | Mediaplane B2BUA | | Bob | 371 +-------+ +------------------+ +-----+ 372 |(1) INVITE | (3)INVITE | 373 | a=ice-ufrag1 | a=ice-ufrag1 | 374 | a=ice-pwd1 | a=ice-pwd1 | 375 | (Alice's IP, port) | (Alices's IP, port) | 376 |(Alice's candidate list )| (Alice's Candidate list + | 377 | B2BUA's candidate list1)| 378 |------------------------>|-------------------------->| 379 | | | 380 | (2) 100 trying | | 381 |<------------------------| | 382 | | (4) 100 trying | 383 | |<--------------------------| 384 | | (5)200 OK | 385 | | a=ice-ufrag2 | 386 | | a=ice-pwd2 | 387 | | (Bob's IP, port) | 388 | | (Bob's candidate list) | 389 | |<--------------------------| 390 | (6) 200 OK | | 391 | a=ice-ufrag2 |-----------ACK------------>| 392 | a=ice-pwd2 | (7) | 393 | (Bobs's IP,port) | | 394 | (B2BUA's cand list2 + | | 395 | Bob's Candidate list) | | 396 |<------------------------| | 397 |----------ACK----------->| | 398 | (8) | | 399 | | | 400 |<----ICE Connectivity 1 (9)------------------------->| 401 | | | 402 |<----ICE Connectivity 2->| | 403 | checks+conclusion |<-----ICE Connectivity 2-->| 404 | (10) | checks +conclusion | 405 | | (11) | 406 |<-------------------Media packets------------------->| 407 | (12) | 408 | | | 409 |<------------------ICE keepalives------------------->| 410 (13) 412 Figure 2: INVITE with SDP having ICE and with a Media Plane B2BUA in 413 ICE Passthrough mode 415 The above figure shows a sample call flow with two endpoints Alice 416 and Bob doing ICE and a B2BUA handing STUN messages from both the 417 endpoints. For the sake of brevity the entire ICE SDP attributes are 418 not shown. Also the STUN messages exchanged as part of ICE 419 connectivity checks are not shown. Key steps to note from the call 420 flow are: 422 o Alice sends an INVITE with an SDP having its own candidate list. 424 o B2BUA propagates the received candidate list in incoming SDP from 425 Alice after adding its own candidate list. The B2BUA also 426 propagates the received ice-ufrag, ice-password attributes from 427 Alice in the INVITE (3) to Bob. 429 o Bob responds (5) to the INVITE with his own list of candidates. 431 o B2BUA responds to the INVITE from Alice with an SDP having B2BUA's 432 candidate list and the candidate list received from Bob. The 433 B2BUA would also propagate the received ice-ufrag, ice-password 434 attributes from Bob in step (5) to Alice in the 200 OK response 435 (6). 437 o ICE Connectivity checks happen between Alice and Bob in step 9. 438 ICE Connectivity checks also happens between Alice and B2BUA and 439 Bob and B2BUA as shown in step 10, 11. Step 9, 10 and 11 happen 440 in parallel. In this example Alice and Bob conclude ICE with a 441 candidate pair that enables them to send media directly. 443 o Media flows between Alice and Bob in Step 12. 445 3.4. STUN Handling in B2BUA with Forked Signaling 447 Because of forking a B2BUA may receive multiple answers for a single 448 outbound INVITE. When this occurs the B2BUA should follow section 449 3.2 or 3.3 for all of those received answers. 451 4. SDP-Modifying Signaling-only B2BUA 453 An SDP-Modifying Signaling-only B2BUA is one that operates in the 454 signaling plane only and is not in the media path, but it modifies 455 SDP bodies as described in section 3.1.3 of [RFC7092]. Such B2BUAs 456 MUST ensure that they dont change C line and ICE semantics of SDP as 457 doing so can cause ICE-mismatch. 459 5. Security Considerations 461 ICE as described in Section 2.5 of [RFC5245] uses STUN short-term 462 credential mechanism for authentication and message integrity. STUN 463 connectivity checks include MESSAGE-INTEGRITY attribute that contains 464 HMAC-SHA1 of the STUN message and the HMAC is computed using the key 465 exchanged in the signaling channel. The signaling channel between 466 the endpoints and B2BUA MUST be encrypted so that the key is not 467 visible to eavesdropper otherwise the security benefits of short-term 468 authentication would be lost. 470 The recommendations mentioned in Appendix of [RFC5245] for ICE and 471 Lite Agents also apply to a B2BUA doing ICE. 473 B2BUA when handling secure traffic (SRTP/SRTCP) SHOULD follow the 474 procedures mentioned in [I-D.ram-straw-b2bua-dtls-srtp] to ensure 475 that Man-in-the-Middle attacks are not possible. 477 6. IANA Considerations 479 This document makes no request of IANA. 481 7. Acknowledgments 483 Special thanks to Dan Wing, Pal Martinsen, Charles Eckel, Marc Petit- 484 Huguenin, Simon Perreault, Lorenzo Miniero and Ari Keranen for their 485 constructive comments, suggestions, and early reviews that were 486 critical to the formulation and refinement of this document. 488 8. References 490 8.1. Normative References 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, March 1997. 495 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 496 Self-Address Fixing (UNSAF) Across Network Address 497 Translation", RFC 3424, November 2002. 499 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 500 "STUN - Simple Traversal of User Datagram Protocol (UDP) 501 Through Network Address Translators (NATs)", RFC 3489, 502 March 2003. 504 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 505 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 506 RFC 3711, March 2004. 508 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 509 (ICE): A Protocol for Network Address Translator (NAT) 510 Traversal for Offer/Answer Protocols", RFC 5245, April 511 2010. 513 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 514 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 515 October 2008. 517 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 518 Relays around NAT (TURN): Relay Extensions to Session 519 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 521 8.2. Informative References 523 [I-D.ram-straw-b2bua-dtls-srtp] 524 R, R., Reddy, T., Salgueiro, G., Pascual, V., and P. 525 Ravindran, "DTLS-SRTP Handling in Session Initiation 526 Protocol (SIP) Back-to-Back User Agents (B2BUAs)", draft- 527 ram-straw-b2bua-dtls-srtp-01 (work in progress), December 528 2014. 530 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 531 Address Translator (Traditional NAT)", RFC 3022, January 532 2001. 534 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 535 A., Peterson, J., Sparks, R., Handley, M., and E. 536 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 537 June 2002. 539 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 540 in Session Description Protocol (SDP)", RFC 3605, October 541 2003. 543 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 544 Description Protocol", RFC 4566, July 2006. 546 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 547 and H. Ashida, "Common Requirements for Carrier-Grade NATs 548 (CGNs)", BCP 127, RFC 6888, April 2013. 550 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 551 Initiation Protocol (SIP) Back-to-Back User Agents", RFC 552 7092, December 2013. 554 [RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT 555 Traversal (HNT) for Media in Real-Time Communication", RFC 556 7362, September 2014. 558 Authors' Addresses 560 Ram Mohan Ravindranath 561 Cisco 562 Cessna Business Park 563 Sarjapur-Marathahalli Outer Ring Road 564 Bangalore, Karnataka 560103 565 India 567 Email: rmohanr@cisco.com 569 Tirumaleswar Reddy 570 Cisco 571 Cessna Business Park, Varthur Hobli 572 Sarjapur Marathalli Outer Ring Road 573 Bangalore, Karnataka 560103 574 India 576 Email: tireddy@cisco.com 578 Gonzalo Salgueiro 579 Cisco Systems, Inc. 580 7200-12 Kit Creek Road 581 Research Triangle Park, NC 27709 582 US 584 Email: gsalguei@cisco.com