idnits 2.17.1 draft-ram-straw-b2bua-stun-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 4, 2014) is 3582 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: 'RFC3711' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'RFC5763' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'RFC5764' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'I-D.ram-straw-b2bua-dtls-srtp' is defined on line 506, but no explicit reference was found in the text ** 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-00 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 5 errors (**), 0 flaws (~~), 7 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: January 5, 2015 Cisco 6 July 4, 2014 8 Session Traversal Utilities for NAT (STUN) Message Handling for Session 9 Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) 10 draft-ram-straw-b2bua-stun-00 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. 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 January 5, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Media Plane B2BUAs . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. ICE Termination with B2BUA . . . . . . . . . . . . . . . 5 64 3.3. ICE Passthrough with B2BUAs . . . . . . . . . . . . . . . 8 65 3.4. STUN Handling in B2BUA with Forked Signaling . . . . . . 11 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 71 7.2. Informative References . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 In many SIP deployments, SIP entities exist in the SIP signaling path 77 between the originating and final terminating endpoints, which go 78 beyond the definition of a SIP proxy, performing functions not 79 defined in Standards Track RFCs. These SIP entities, commonly known 80 as Back-to-Back User Agents (B2BUAs) are described in [RFC7092]. 82 The Session Initiation Protocol (SIP) [RFC3261], and other session 83 control protocols that try to use direct path for media, are 84 typically difficult to use across Network Address Translators (NATs). 85 These protocols use IP addresses and transport port numbers encoded 86 in the signaling, such as the Session Description Protocol (SDP) 87 [RFC4566] and, in the case of SIP, various header fields. Such 88 addresses and ports are unreachable unless all peers in a session are 89 located behind the same NAT. 91 Mechanisms such as Session Traversal Utilities for NAT (STUN) 92 [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and 93 Interactive Connectivity Establishment (ICE) [RFC5245] did not exist 94 when protocols like SIP began being deployed. Some mechanisms, such 95 as the early versions of STUN [RFC3489], started appearing but they 96 were unreliable and suffered a number of issues typical for 97 UNilateral Self-Address Fixing (UNSAF) and described in [RFC3424]. 98 For these and other reasons, Session Border Controllers (SBCs) that 99 were already being used by SIP domains for other SIP and media- 100 related purposes began to use proprietary mechanisms to enable SIP 101 devices behind NATs to communicate across the NAT. 102 [I-D.ietf-mmusic-latching] describes how B2BUAs can perform Hosted 103 NAT Traversal (HNT) to solve the NAT traversal problem. 105 Section 5 of [I-D.ietf-mmusic-latching] describes some of the issues 106 with SBCs implementing HNT and offers some mitigation strategies. 107 The most commonly used approach to solve these issues is "restricted- 108 latching", whereby the B2BUA will not latch to any packets from a 109 source public IP address other than the one the SIP UA uses for SIP 110 signaling. However, this is susceptible to attacks, where an 111 attacker who is able to see the source IP address of the SIP UA may 112 generate packets using the same IP address. There are other threats 113 described in Section 5 of [I-D.ietf-mmusic-latching] for which Secure 114 Real-time Transport Protocol (SRTP) can be used as a solution. 115 However, this would require the B2BUAs to be terminating/re- 116 originating SRTP, which is not always possible. A B2BUA can use ICE 117 [RFC5245], which provides authentication tokens (conveyed in the ice- 118 ufrag and ice-pwd attributes) that allow the identity of a peer to be 119 confirmed before engaging in media exchange. This can solve some of 120 the security concerns with HNT solution. Further, ICE has other 121 benefits like selecting an address when more than one address is 122 available (e.g. dual-stack), verifying that a path works before 123 connecting the call etc. For these reasons endpoints often use ICE 124 to pick a candidate pair for media traffic between two agents. 126 B2BUAs often operate on the media path and have the ability to modify 127 SIP headers and SDP bodies as part of their normal operation. Such 128 entities, when present on the media path, are likely to take an 129 active role in the session signaling depending on their level of 130 activity on the media path. For example, some B2BUAs modify portions 131 of the SDP body (e.g., IP address, port) and subsequently modify the 132 media packet headers as well. There are other types of B2BUAs that 133 modify the media payload (e.g., a media transcoder). Section 18.6 of 134 ICE [RFC5245] explains two different behaviors when B2BUAs are 135 present. Some B2BUAs are likely to remove all the SDP ICE attributes 136 before sending the SDP across to the other side. Consequently, the 137 call will appear to both endpoints as though the other side doesn't 138 support ICE. There are other types of B2BUAs that pass the ICE 139 attributes without modification, yet modify the default destination 140 for media (contained in the m= and c= lines and rtcp attribute) This 141 will be detected as an ICE mismatch and ICE processing is aborted for 142 the call. The call may continue if the endpoints are able to reach 143 each other over the default candidate (sent in m= and c= lines). 145 [RFC7092] describes three different categories of such B2BUAs, 146 according to the level of activities performed on the media plane: 148 A B2BUA that acts as a simple media relay effectively unaware of 149 anything that is transported and only modifies the transport 150 header (could be UDP/IP) of the media packets. 152 A B2BUA that performs a media-aware role. It inspects and 153 potentially modifies RTP or RTP Control Protocol (RTCP) headers; 154 but it does not modify the payload of RTP/RTCP. 156 A B2BUA that performs a media-termination role and operates at the 157 media payload layer, such as RTP/RTCP payload (e.g., a 158 transcoder). 160 When such a B2BUA operating on a media plane is involved in a call 161 between two endpoints performing ICE, then it SHOULD follow the 162 behavior described in this specification. 164 2. Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. 170 The following generalized terms are defined in [RFC3261], Section 6. 172 B2BUA: A SIP Back-to-Back User Agent, which is the logical 173 combination of a User Agent Server (UAS) and User Agent Client 174 (UAC). 176 UAS: A SIP User Agent Server. 178 UAC: A SIP User Agent Client. 180 All of the pertinent B2BUA terminology and taxonomy used in this 181 document is based on [RFC7092]. 183 Network Address Translators (NATs) are widely used in the Internet by 184 consumers and organizations. Although specific NAT behaviors vary, 185 this document uses the term "NAT", which maps to NAT and NAPT terms 186 from [RFC3022], for devices that map any IPv4 or IPv6 address and 187 transport port number to another IPv4 or IPv6 address and transport 188 port number. This includes consumer NATs, Firewall-NATs, IPv4-IPv6 189 NATs, Carrier-Grade NATs (CGNs) [RFC6888], etc. 191 3. Media Plane B2BUAs 193 3.1. Overview 195 When one or both of the endpoints are behind a NAT, and there is a 196 B2BUA between the endpoints, the B2BUAs MUST support ICE or at a 197 minimum support ICE LITE functionality as described in [RFC5245]. 198 Such B2BUAs MUST use the mechanism described in Section 2.2 of 199 [RFC5245] to demultiplex STUN packets that arrive on the Real-time 200 Transport Protocol(RTP)/RTP Control Protocol (RTCP) port. 202 The subsequent sections describe the behavior B2BUA's MUST follow for 203 handling ICE messages. A B2BUA can terminate ICE and thus have two 204 ICE contexts with either endpoint. The reason for ICE termination 205 could be due to the need for B2BUA to be in the media path ( e.g., 206 media transcoding, media recording, address hiding etc.) A B2BUA can 207 also be in ICE passthrough mode and passes across the candidate list 208 from one endpoint to the other side. A B2BUA may be in ICE 209 passthrough mode when it does not have a need to be on the media 210 path. The below sections describes the behaviors for these two 211 cases. 213 3.2. ICE Termination with B2BUA 215 A B2BUA that wishes to be in the media path follows the below steps: 217 When a B2BUA sends out SDP, it MUST advertise support for ICE and 218 MAY include B2BUA candidates of different types for each component 219 of each media stream. 221 If the B2BUA is in ICE lite mode as described in section 2.7 of 222 [RFC5245] then it MUST send a=ice-lite attribute and MUST include 223 B2BUAs host candidates for each component of each media stream. 225 If the B2BUA supports full ICE then it MAY include B2BUAs 226 candidates of different types for each component of each media 227 stream. 229 The B2BUA MUST generate new username, password values for ice- 230 ufrag and ice-pwd attributes when it sends out the SDP and MUST 231 NOT propagate the ufrag, password values it received in the 232 incoming SDP. This ensures that the short-term credentials used 233 for both the legs are different. The short-term credentials 234 include authentication tokens (conveyed in the ice-ufrag and ice- 235 pwd attributes), which the B2BUA can use to verify the identity of 236 the peer. B2BUA terminates the ICE messages on each leg and does 237 not propagate them. 239 The B2BUA MUST NOT propagate the candidate list received in the 240 incoming SDP to the outbound SDP and instead only advertise its 241 candidate list. In this way the B2BUA will be always in media 242 path. 244 Depending on whether the B2BUA supports ICE lite or full ICE it 245 implements the appropriate procedures mentioned in [RFC5245] for 246 ICE connectivity checks. 248 +-------+ +------------------+ +-----+ 249 | Alice | | Mediaplane B2BUA | | Bob | 250 +-------+ +------------------+ +-----+ 251 |(1) INVITE | (3)INVITE | 252 | a=ice-ufrag1 | a=ice-ufrag2 | 253 | a=ice-pwd1 | a=ice-pwd2 | 254 | (Alice's IP, port) | (B2BUA's IP, port) | 255 |(Alice's candidate list )| (B2BUA's candidate list)| 256 |------------------------>|-------------------------->| 257 | | | 258 | (2) 100 trying | | 259 |<------------------------| | 260 | | (4) 100 trying | 261 | |<--------------------------| 262 | | (5)200 OK | 263 | | a=ice-ufrag3 | 264 | | a=ice-pwd3 | 265 | | (Bob's IP, port) | 266 | | (Bob's candidate list) | 267 | |<--------------------------| 268 | (6) 200 OK | | 269 | a=ice-ufrag4 |-----------ACK------------>| 270 | a=ice-pwd4 | (7) | 271 | B2BUA's IP,port | | 272 | (B2BUA's cand list1) | | 273 |<------------------------| | 274 |--------ACK------------->| | 275 | (8) | | 276 | | | 277 |<----ICE Connectivity 1->| | 278 | checks+conclusion |<-----ICE Connectivity 2-->| 279 | (9) | checks +conclusion | 280 | | (10) | 281 |<-------Media packets -->|<----Media packets-------->| 282 | (13) | (14) | 283 | | | 284 |<---ICE keepalives 1---->| | 285 | (15) |<----ICE keep alives 2---->| 286 (16) 288 Figure 1: INVITE with SDP having ICE and with a Media Plane B2BUA 290 The above figure shows a sample call flow with two endpoints Alice 291 and Bob doing ICE and a B2BUA handing STUN messages from both the 292 endpoints. For the sake of brevity the entire ICE SDP attributes are 293 not shown. Also the STUN messages exchanged as part of ICE 294 connectivity checks are not shown. Key steps to note from the call 295 flow are: 297 1. Alice sends an INVITE with SDP having ICE candidates. 299 2. B2BUA modifies the received SDP from Alice by removing the 300 received candidate list, gathers its own candidates, generates 301 new username, password values for ice-ufrag and ice-pwd 302 attributes and forwards the INVITE (3) to Bob. 304 3. Bobs responds (5) to the INVITE with his own list of candidates. 306 4. B2BUA responds to the INVITE from Alice with SDP having B2BUA's 307 candidate list. B2BUA generates new username, password values 308 for ice-ufrag and ice-pwd attributes in the 200 OK response (6). 310 5. ICE Connectivity checks happen between Alice and the B2BUA in 311 step 9. Depending on whether the B2BUA supports ICE or ICE lite 312 it will follow the appropriate procedures mentioned in [RFC5245]. 313 ICE Connectivity checks also happen between Bob and the B2BUA in 314 step 10. Step 9 and 10 happen in parallel. The B2BUA always 315 terminates the ICE messages on each leg and have two independent 316 ICE contexts running. 318 6. Media flows between Alice and Bob via B2BUA (Step 13, 14). 320 7. STUN keepalives would be used between Alice and B2BUA (step 15) 321 and between Bob and B2BUA (step 16) to keep NAT, Firewall 322 bindings alive. 324 Since there are two independent ICE contexts on either side of the 325 B2BUA it is possible that ICE checks will conclude on one side before 326 concluding on the other side. This could result in an ongoing media 327 session for one end, while the other is still being set up. Any such 328 media received by the B2BUA would continue to be sent to the other 329 side on the default candidate address (that was sent in c= line). 331 3.3. ICE Passthrough with B2BUAs 333 If a B2BUA does not see a need to be in media path, it can do the 334 following steps mentioned in this section. 336 When a B2BUA receives an incoming SDP with ICE semantics it copies 337 the received candidate list, adds its own candidate list in the 338 outgoing SDP. The B2BUA also copies the ufrag/password values it 339 received in the incoming SDP to the outgoing SDP and then sends 340 out the SDP. 342 The B2BUAs candidates will have lower-priority than the candidates 343 provided by the endpoint, this way endpoint and remote peer 344 candidate pairs are tested first before trying candidate pairs 345 with B2BUA candidates. 347 After offer/answer is complete, the endpoints will have both the 348 B2BUA's and remote peer candidates. It will then use ICE 349 procedures described in [RFC5245] to nominate a candidate pair for 350 sending and receiving media streams. 352 With this approach the B2BUA will be in media path only if the ICE 353 checks between all the candidate pairs formed from the both the 354 endpoints fails. 356 +-------+ +------------------+ +-----+ 357 | Alice | | Mediaplane B2BUA | | Bob | 358 +-------+ +------------------+ +-----+ 359 |(1) INVITE | (3)INVITE | 360 | a=ice-ufrag1 | a=ice-ufrag1 | 361 | a=ice-pwd1 | a=ice-pwd1 | 362 | (Alice's IP, port) | (Alices's IP, port) | 363 |(Alice's candidate list )| (Alice's Candidate list + | 364 | B2BUA's candidate list1)| 365 |------------------------>|-------------------------->| 366 | | | 367 | (2) 100 trying | | 368 |<------------------------| | 369 | | (4) 100 trying | 370 | |<--------------------------| 371 | | (5)200 OK | 372 | | a=ice-ufrag2 | 373 | | a=ice-pwd2 | 374 | | (Bob's IP, port) | 375 | | (Bob's candidate list) | 376 | |<--------------------------| 377 | (6) 200 OK | | 378 | a=ice-ufrag2 |-----------ACK------------>| 379 | a=ice-pwd2 | (7) | 380 | (Bobs's IP,port) | | 381 | (B2BUA's cand list2 + | | 382 | Bob's Candidate list) | | 383 |<------------------------| | 384 |----------ACK----------->| | 385 | (8) | | 386 | | | 387 |<----ICE Connectivity 1 (9)------------------------->| 388 | | | 389 |<----ICE Connectivity 2->| | 390 | checks+conclusion |<-----ICE Connectivity 2-->| 391 | (10) | checks +conclusion | 392 | | (11) | 393 |<-------------------Media packets------------------->| 394 | (12) | 395 | | | 396 |<------------------ICE keepalives------------------->| 397 (13) 399 Figure 2: INVITE with SDP having ICE and with a Media Plane B2BUA in 400 ICE Passthrough mode 402 The above figure shows a sample call flow with two endpoints Alice 403 and Bob doing ICE and a B2BUA handing STUN messages from both the 404 endpoints. For the sake of brevity the entire ICE SDP attributes are 405 not shown. Also the STUN messages exchanged as part of ICE 406 connectivity checks are not shown. Key steps to note from the call 407 flow are: 409 1. Alice sends an INVITE with an SDP having its own candidate list. 411 2. B2BUA propagates the received candidate list in incoming SDP from 412 Alice after adding its own candidate list. The B2BUA also 413 propagates the received ice-ufrag, ice-password attributes from 414 Alice in the INVITE (3) to Bob. 416 3. Bob responds (5) to the INVITE with his own list of candidates. 418 4. B2BUA responds to the INVITE from Alice with an SDP having 419 B2BUA's candidate list and the candidate list received from Bob. 420 The B2BUA would also propagate the received ice-ufrag, ice- 421 password attributes from Bob in step (5) to Alice in the 200 OK 422 response (6). 424 5. ICE Connectivity checks happen between Alice and Bob in step 9. 425 ICE Connectivity checks also happens between Alice and B2BUA and 426 Bob and B2BUA as shown in step 10, 11. Step 9, 10 and 11 happen 427 in parallel. In this example Alice and Bob conclude ICE with a 428 candidate pair that enables them to send media directly. 430 6. Media flows between Alice and Bob in Step 12. 432 3.4. STUN Handling in B2BUA with Forked Signaling 434 Because of forking a B2BUA may receive multiple answers for a single 435 outbound INVITE. When this occurs the B2BUA should follow section 436 3.2 or 3.3 for all of those received answers. 438 4. Security Considerations 440 TBD 442 5. IANA Considerations 444 This document makes no request of IANA. 446 6. Acknowledgments 448 Special thanks to Dan Wing, Pal Martinsen, Charles Eckel, Marc Petit- 449 Huguenin, Simon Perreault and Lorenzo Miniero for their constructive 450 comments, suggestions, and early reviews that were critical to the 451 formulation and refinement of this document. 453 7. References 455 7.1. Normative References 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 461 Self-Address Fixing (UNSAF) Across Network Address 462 Translation", RFC 3424, November 2002. 464 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 465 "STUN - Simple Traversal of User Datagram Protocol (UDP) 466 Through Network Address Translators (NATs)", RFC 3489, 467 March 2003. 469 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 470 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 471 RFC 3711, March 2004. 473 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 474 Requirements for Security", BCP 106, RFC 4086, June 2005. 476 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 477 (ICE): A Protocol for Network Address Translator (NAT) 478 Traversal for Offer/Answer Protocols", RFC 5245, April 479 2010. 481 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 482 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 483 October 2008. 485 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 486 for Establishing a Secure Real-time Transport Protocol 487 (SRTP) Security Context Using Datagram Transport Layer 488 Security (DTLS)", RFC 5763, May 2010. 490 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 491 Security (DTLS) Extension to Establish Keys for the Secure 492 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 494 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 495 Relays around NAT (TURN): Relay Extensions to Session 496 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 498 7.2. Informative References 500 [I-D.ietf-mmusic-latching] 501 Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT 502 Traversal (HNT) for Media in Real-Time Communication", 503 draft-ietf-mmusic-latching-08 (work in progress), June 504 2014. 506 [I-D.ram-straw-b2bua-dtls-srtp] 507 R, R., Reddy, T., Salgueiro, G., and V. Pascual, "DTLS- 508 SRTP Handling in Session Initiation Protocol (SIP) Back- 509 to-Back User Agents (B2BUAs)", draft-ram-straw-b2bua-dtls- 510 srtp-00 (work in progress), June 2014. 512 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 513 Address Translator (Traditional NAT)", RFC 3022, January 514 2001. 516 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 517 A., Peterson, J., Sparks, R., Handley, M., and E. 518 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 519 June 2002. 521 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 522 Description Protocol", RFC 4566, July 2006. 524 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 525 and H. Ashida, "Common Requirements for Carrier-Grade NATs 526 (CGNs)", BCP 127, RFC 6888, April 2013. 528 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 529 Initiation Protocol (SIP) Back-to-Back User Agents", RFC 530 7092, December 2013. 532 Authors' Addresses 534 Ram Mohan Ravindranath 535 Cisco 536 Cessna Business Park 537 Sarjapur-Marathahalli Outer Ring Road 538 Bangalore, Karnataka 560103 539 India 541 Email: rmohanr@cisco.com 542 Tirumaleswar Reddy 543 Cisco 544 Cessna Business Park, Varthur Hobli 545 Sarjapur Marathalli Outer Ring Road 546 Bangalore, Karnataka 560103 547 India 549 Email: tireddy@cisco.com 551 Gonzalo Salgueiro 552 Cisco Systems, Inc. 553 7200-12 Kit Creek Road 554 Research Triangle Park, NC 27709 555 US 557 Email: gsalguei@cisco.com