idnits 2.17.1 draft-ietf-straw-b2bua-stun-08.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 (May 18, 2015) is 3266 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) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) ** Downref: Normative reference to an Informational RFC: RFC 7092 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 STRAW Ram. Ravindranath 3 Internet-Draft T. Reddy 4 Intended status: Standards Track G. Salgueiro 5 Expires: November 19, 2015 Cisco 6 May 18, 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-08 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. 22 This document defines behavior for a B2BUA performing ICE processing. 23 The goal of this draft is to ensure that B2BUAs properly handles SIP 24 messages that carry ICE semantics in Session Description 25 Protocol(SDP) and STUN messages received as part of the ICE 26 procedures for NAT and Firewall traversal of multimedia sessions. 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 November 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. SDP-Modifying Signaling-only B2BUA . . . . . . . . . . . . . 5 65 4. Media Plane B2BUAs . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.2. Mandatory ICE Termination with B2BUA . . . . . . . . . . 6 68 4.3. Optional ICE Termination with B2BUA . . . . . . . . . . . 8 69 4.4. STUN Handling in B2BUA with Forked Signaling . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 In many Session Initiation Protocol (SIP) deployments, SIP entities 81 exist in the SIP signaling and media path between the originating and 82 final terminating endpoints, which go beyond the definition of a 83 traditional SIP proxy. These SIP entities, commonly known as Back- 84 to-Back User Agents (B2BUAs), are described in [RFC7092] and often 85 perform functions not defined in Standards Track RFCs. 87 SIP [RFC3261], and other session control protocols that try to use 88 direct path for media, are typically difficult to use across Network 89 Address Translators (NATs). These protocols use IP addresses and 90 transport port numbers encoded in the signaling, such as the Session 91 Description Protocol (SDP) [RFC4566] and, in the case of SIP, various 92 header fields. Such addresses and ports are unreachable if any peers 93 are separated by NATs. 95 Mechanisms such as Session Traversal Utilities for NAT (STUN) 96 [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and 97 Interactive Connectivity Establishment (ICE) [RFC5245] did not exist 98 when protocols like SIP began being deployed. Some mechanisms, such 99 as the early versions of STUN, started appearing but they were 100 unreliable and suffered a number of issues typical for UNilateral 101 Self-Address Fixing (UNSAF) and described in [RFC3424]. For these 102 reasons, B2BUAs are being used by SIP domains for SIP and media- 103 related purposes. These B2BUAs use proprietary mechanisms to enable 104 SIP devices behind NATs to communicate across the NAT. 106 [RFC7362] describes how B2BUAs can perform Hosted NAT Traversal (HNT) 107 in certain deployments. Section 5 of [RFC7362] describes some of the 108 issues with SBCs implementing HNT and offers some mitigation 109 strategies. The most commonly used approach to solve these issues is 110 restricted-latching defined in section 5 of [RFC7362], whereby the 111 B2BUA will not latch to any packets from a source public IP address 112 other than the one the SIP UA uses for SIP signaling. However, this 113 is susceptible to attacks, where an attacker who is able to see the 114 source IP address of the SIP UA may generate packets using the same 115 IP address. There are other threats described in Section 5 of 116 [RFC7362] for which Secure Real-time Transport Protocol (SRTP) 117 [RFC3711] can be used as a solution. However, this would require the 118 B2BUAs to terminate and re-originate SRTP, which is not always 119 desirable. 121 This document describes proper behavior of B2BUAs performing ICE 122 processing. This includes defining consistent handling of SIP 123 messages carrying ICE semantics in SDP and STUN messages received as 124 part of the ICE procedures performed on the media path for NAT and 125 Firewall traversal of multimedia sessions. 127 A B2BUA can use ICE [RFC5245], which provides authentication tokens 128 (conveyed in the ice-ufrag and ice-pwd attributes) that allow the 129 identity of a peer to be confirmed before engaging in media exchange. 130 This can solve some of the security concerns with HNT solution. 131 Further, ICE has other benefits like selecting an address when more 132 than one address is available (e.g., dual-stack environment where 133 host can have both IPv4 and IPv6 addresses), verifying that a path 134 works before connecting the call etc. For these reasons endpoints 135 often use ICE to pick a candidate pair for media traffic between two 136 agents. 138 B2BUAs often operate on the media path and have the ability to modify 139 SIP headers and SDP bodies as part of their normal operation. Such 140 entities, when present on the media path, are likely to take an 141 active role in the session signaling depending on their level of 142 activity on the media path. For example, some B2BUAs modify portions 143 of the SDP body (e.g., IP address, port) and subsequently modify the 144 media packet headers as well. Section 18.6 of ICE [RFC5245] explains 145 two different behaviors when B2BUAs are present. Some B2BUAs are 146 likely to remove all the SDP ICE attributes before sending the SDP 147 across to the other side. Consequently, the call will appear to both 148 endpoints as though the other side doesn't support ICE. There are 149 other types of B2BUAs that pass the ICE attributes without 150 modification, yet modify the default destination for media contained 151 in the m= and c= lines and rtcp attribute (defined in [RFC3605]). 152 This will be detected as an ICE mismatch and ICE processing will be 153 aborted for the session. The session may continue if the endpoints 154 are able to reach each other over the default candidate (sent in m= 155 and c= lines). 157 Section 3.1.3 of [RFC7092] defines a SDP-Modifying Signaling-only 158 B2BUA that operates in the signaling plane only and is not in the 159 media path, but it does modify SDP bodies and is thus aware of and 160 understands SDP syntax and semantics. Such B2BUA MUST follow the 161 behavior mentioned in Section 3. 163 Section 3.2 of [RFC7092] describes three different categories of 164 B2BUAs that operates on both signaling(SIP and SDP) and media plane 165 according to the level of involvement and active participation in the 166 media plane: 168 o A B2BUA that acts as a simple media relay effectively unaware of 169 anything that is transported and only modifies the transport 170 header (could be UDP/IP) of the media packets. 172 o A B2BUA that performs a media-aware role. It inspects and 173 potentially modifies RTP or RTP Control Protocol (RTCP) headers; 174 but it does not modify the payload of RTP/RTCP. 176 o A B2BUA that performs a media-termination role and operates at the 177 media payload layer, such as RTP/RTCP payload (e.g., a 178 transcoder). 180 When B2BUAs that operate on media plane (media relay, media-aware or 181 media-termination) is involved in a session between two endpoints 182 performing ICE, then it MUST follow the behavior described in 183 Section 4. 185 2. Terminology 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in [RFC2119]. 191 All of the pertinent B2BUA terminology and taxonomy used in this 192 document is defined in [RFC7092]. 194 Network Address Translators (NATs) are widely used in the Internet by 195 consumers and organizations. Although specific NAT behaviors vary, 196 this document uses the term "NAT", which maps to NAT and NAPT terms 197 from [RFC3022], for devices that map any IPv4 or IPv6 address and 198 transport port number to another IPv4 or IPv6 address and transport 199 port number. This includes consumer NATs, Firewall-NATs, IPv4-IPv6 200 NATs, Carrier-Grade NATs (CGNs) [RFC6888], etc. 202 3. SDP-Modifying Signaling-only B2BUA 204 An SDP-Modifying Signaling-only B2BUA is one that operates in the 205 signaling plane only and is not in the media path, but it modifies 206 SDP bodies as described in section 3.1.3 of [RFC7092]. Such B2BUAs 207 MUST NOT change IP address in c= line, port in m= line and ICE 208 semantics of SDP as doing so can cause ICE-mismatch. 210 4. Media Plane B2BUAs 212 4.1. Overview 214 When one or both of the endpoints are behind a NAT, and there is a 215 B2BUA between the endpoints, the B2BUAs MUST support ICE or at a 216 minimum support ICE LITE functionality as described in [RFC5245]. 217 Such B2BUAs MUST use the mechanism described in Section 2.2 of 218 [RFC5245] to demultiplex STUN packets that arrive on the Real-time 219 Transport Protocol(RTP)/RTP Control Protocol (RTCP) port. 221 The subsequent sections describe the behavior B2BUAs MUST follow for 222 handling ICE messages. A B2BUA can terminate ICE and thus have two 223 ICE contexts with either endpoint. The reason for ICE termination 224 could be due to the need for B2BUA to be in the media path ( e.g., 225 address hiding for privacy, interworking between ICE to no-ICE, 226 etc.). A B2BUA can also be in optional ICE termination mode and 227 passes across the candidate list and STUN short-term credentials 228 (ice-ufrag and ice-pwd attributes) from one endpoint to the other 229 side after adding its own candidates. A B2BUA can be in optional ICE 230 termination mode when it does not have a need to be on the media 231 path. The below sections describes the behaviors for these two 232 cases. 234 4.2. Mandatory ICE Termination with B2BUA 236 A B2BUA that wishes to always be in the media path follows the below 237 steps: 239 o When a B2BUA sends out SDP, it MUST advertise support for ICE and 240 MAY include B2BUA candidates of different types for each component 241 of each media stream. 243 o If the B2BUA is in ICE lite mode as described in Section 2.7 of 244 [RFC5245] then it MUST send a=ice-lite attribute and MUST include 245 B2BUAs host candidates for each component of each media stream. 247 o If the B2BUA supports full ICE then it MAY include B2BUAs 248 candidates of different types for each component of each media 249 stream. 251 o The B2BUA MUST generate new username, password values for ice- 252 ufrag and ice-pwd attributes when it sends out the SDP and MUST 253 NOT propagate the ufrag, password values it received in the 254 incoming SDP. This ensures that the short-term credentials used 255 for both the legs are different. The short-term credentials 256 include authentication tokens (conveyed in the ice-ufrag and ice- 257 pwd attributes), which the B2BUA can use to verify the identity of 258 the peer. B2BUA terminates the ICE messages on each leg and does 259 not propagate them. 261 o The B2BUA MUST NOT propagate the candidate list received in the 262 incoming SDP to the outbound SDP and instead only advertise its 263 candidate list. The B2BUA MUST also add its default candidate in 264 the c= line (IP address) and m= line (port). In this way the 265 B2BUA will be always in the media path. 267 o Depending on whether the B2BUA supports ICE lite or full ICE it 268 implements the appropriate procedures mentioned in [RFC5245] for 269 ICE connectivity checks. 271 +-------+ +------------------+ +-----+ 272 | Alice | | Mediaplane B2BUA | | Bob | 273 +-------+ +------------------+ +-----+ 274 |(1) INVITE | (3)INVITE | 275 | a=ice-ufrag1 | a=ice-ufrag2 | 276 | a=ice-pwd1 | a=ice-pwd2 | 277 | (Alice's IP, port) | (B2BUAs IP, port) | 278 |(Alice's candidate list )| (B2BUAs candidate list) | 279 |------------------------>|-------------------------->| 280 | | | 281 | (2) 100 trying | | 282 |<------------------------| | 283 | | (4) 100 trying | 284 | |<--------------------------| 285 | | (5)200 OK | 286 | | a=ice-ufrag3 | 287 | | a=ice-pwd3 | 288 | | (Bob's IP, port) | 289 | | (Bob's candidate list) | 290 | |<--------------------------| 291 | (6) 200 OK | | 292 | a=ice-ufrag4 |-----------ACK------------>| 293 | a=ice-pwd4 | (7) | 294 | B2BUAs IP,port | | 295 | (B2BUAs cand list1) | | 296 |<------------------------| | 297 |--------ACK------------->| | 298 | (8) | | 299 | | | 300 |<----ICE Connectivity 1->| | 301 | checks+conclusion |<-----ICE Connectivity 2-->| 302 | (9) | checks +conclusion | 303 | | (10) | 304 |<-------Media packets -->|<----Media packets-------->| 305 | (13) | (14) | 306 | | | 307 |<---ICE keepalives 1---->| | 308 | (15) |<----ICE keep alives 2---->| 309 (16) 311 Figure 1: INVITE with SDP having ICE and with a Media Plane B2BUA 312 terminating ICE 314 The above figure shows an example call flow with two endpoints Alice 315 and Bob doing ICE and a B2BUA handing STUN messages from both the 316 endpoints. For the sake of brevity the entire ICE SDP attributes are 317 not shown. Also the STUN messages exchanged as part of ICE 318 connectivity checks are not shown. Key steps to note from the call 319 flow are: 321 o Alice sends an INVITE with SDP having ICE candidates. 323 o B2BUA modifies the received SDP from Alice by removing the 324 received candidate list, gathers its own candidates, generates new 325 username, password values for ice-ufrag and ice-pwd attributes. 326 The B2BUA also changes the c= line and m= line to have its default 327 candidate and forwards the INVITE (3) to Bob. 329 o Bob responds (5) to the INVITE with his own list of candidates. 331 o B2BUA responds to the INVITE from Alice with SDP having B2BUAs 332 candidate list. B2BUA generates new username, password values for 333 ice-ufrag and ice-pwd attributes in the 200 OK response (6). 335 o ICE Connectivity checks happen between Alice and the B2BUA in step 336 9. Depending on whether the B2BUA supports ICE or ICE lite it 337 will follow the appropriate procedures mentioned in [RFC5245]. 338 ICE Connectivity checks also happen between Bob and the B2BUA in 339 step 10. Step 9 and 10 happen in parallel. The B2BUA always 340 terminates the ICE messages on each leg and has two independent 341 ICE contexts running. 343 o Media flows between Alice and Bob via B2BUA (Step 13, 14). 345 o STUN keepalives would be used between Alice and B2BUA (step 15) 346 and between Bob and B2BUA (step 16) to keep NAT and Firewall 347 bindings alive. 349 Since there are two independent ICE contexts on either side of the 350 B2BUA it is possible that ICE checks will conclude on one side before 351 concluding on the other side. This could result in an ongoing media 352 session for one end, while the other is still being set up. Any such 353 media received by the B2BUA would continue to be sent to the other 354 side on the default candidate address (that was sent in c= line). 356 4.3. Optional ICE Termination with B2BUA 358 A B2BUA willing to be in the media path only for NAT traversal, but 359 does not otherwise require to be in the media path can do the 360 following steps mentioned in this section. 362 o When a B2BUA receives an incoming SDP with ICE semantics it copies 363 the received candidate list and appends its own candidate list in 364 the outgoing SDP. The B2BUA also copies the ufrag/password values 365 it received in the incoming SDP to the outgoing SDP and then sends 366 out the SDP. 368 o The B2BUAs candidates MAY have lower-priority than the candidates 369 provided by the endpoint, this way endpoint and remote peer 370 candidate pairs are tested first before trying candidate pairs 371 with B2BUA candidates. 373 o After offer/answer is complete, the endpoints will have both the 374 B2BUAs and remote peer candidates. It will then use ICE 375 procedures described in Section 8 of [RFC5245] to nominate a 376 candidate pair for sending and receiving media streams. 378 o With this approach the B2BUA will be in the media path only if the 379 ICE checks between all the candidate pairs formed from both the 380 endpoints fail. 382 +-------+ +------------------+ +-----+ 383 | Alice | | Mediaplane B2BUA | | Bob | 384 +-------+ +------------------+ +-----+ 385 |(1) INVITE | (3)INVITE | 386 | a=ice-ufrag1 | a=ice-ufrag1 | 387 | a=ice-pwd1 | a=ice-pwd1 | 388 | (Alice's IP, port) | (Alices's IP, port) | 389 |(Alice's candidate list )| (Alice's Candidate list + | 390 | | B2BUAs candidate list1) | 391 |------------------------>|-------------------------->| 392 | | | 393 | (2) 100 trying | | 394 |<------------------------| | 395 | | (4) 100 trying | 396 | |<--------------------------| 397 | | (5)200 OK | 398 | | a=ice-ufrag2 | 399 | | a=ice-pwd2 | 400 | | (Bob's IP, port) | 401 | | (Bob's candidate list) | 402 | |<--------------------------| 403 | (6) 200 OK | | 404 | a=ice-ufrag2 |-----------ACK------------>| 405 | a=ice-pwd2 | (7) | 406 | (Bobs's IP,port) | | 407 | (B2BUAs cand list2 + | | 408 | Bob's Candidate list) | | 409 |<------------------------| | 410 |----------ACK----------->| | 411 | (8) | | 412 | | | 413 |<----ICE Connectivity 1 (9)------------------------->| 414 | | | 415 |<----ICE Connectivity 2->| | 416 | checks+conclusion |<-----ICE Connectivity 2-->| 417 | (10) | checks +conclusion | 418 | | (11) | 419 |<-------------------Media packets------------------->| 420 | (12) | 421 | | | 422 |<------------------ICE keepalives------------------->| 423 (13) 425 Figure 2: INVITE with SDP having ICE and with a Media Plane B2BUA in 426 optional ICE termination mode 428 The above figure shows a sample call flow with two endpoints Alice 429 and Bob doing ICE and a B2BUA handing STUN messages from both the 430 endpoints. For the sake of brevity the entire ICE SDP attributes are 431 not shown. Also the STUN messages exchanged as part of ICE 432 connectivity checks are not shown. Key steps to note from the call 433 flow are: 435 o Alice sends an INVITE with an SDP having its own candidate list. 437 o B2BUA propagates the received candidate list in incoming SDP from 438 Alice after adding its own candidate list. The B2BUA also 439 propagates the received ice-ufrag, ice-password attributes from 440 Alice in the INVITE (3) to Bob. In this example, the B2BUA does 441 not modify the default candidate sent in the c= line and m= line 442 and retains the values sent originally from Alice. If B2BUA wants 443 to be in the media path when ICE connectivity checks between 444 endpoints fails or one of the endpoints does not support ICE, then 445 it overwrites its candidate address and port as a default 446 candidate in the m= and c= lines. 448 o Bob responds (5) to the INVITE with his own list of candidates. 450 o B2BUA responds to the INVITE from Alice with an SDP having B2BUAs 451 candidate list and the candidate list received from Bob. The 452 B2BUA would also propagate the received ice-ufrag, ice-password 453 attributes from Bob in step (5) to Alice in the 200 OK response 454 (6). 456 o ICE Connectivity checks happen between Alice and Bob in step 9. 457 ICE Connectivity checks also happens between Alice and B2BUA and 458 Bob and B2BUA as shown in step 10, 11. Step 9, 10 and 11 happen 459 in parallel. In this example Alice and Bob conclude ICE with a 460 candidate pair that enables them to send media directly. 462 o Media flows between Alice and Bob in Step 12. 464 4.4. STUN Handling in B2BUA with Forked Signaling 466 Because of forking, a B2BUA might receive multiple answers for a 467 single outbound INVITE. When this occurs the B2BUA SHOULD follow 468 section 3.2 or 3.3 for all of those received answers. 470 5. Security Considerations 472 ICE as described in Section 2.5 of [RFC5245] uses STUN short-term 473 credential mechanism for authentication and message integrity. STUN 474 connectivity checks include MESSAGE-INTEGRITY attribute that contains 475 HMAC-SHA1 of the STUN message and the HMAC is computed using the key 476 exchanged in the signaling channel. The signaling channel between 477 the endpoints and B2BUA MUST be encrypted so that the key is not 478 visible to eavesdropper otherwise the security benefits of short-term 479 authentication would be lost. 481 6. IANA Considerations 483 This document makes no request of IANA. 485 7. Acknowledgments 487 Special thanks to Dan Wing, Pal Martinsen, Charles Eckel, Marc Petit- 488 Huguenin, Simon Perreault, Lorenzo Miniero, Ari Keranen and 489 Parthasarathi R for their constructive comments, suggestions, and 490 early reviews that were critical to the formulation and refinement of 491 this document. 493 Thanks to Ben Campbell, Barry Leiba, Nevil Brownlee, Spencer Dawkins, 494 Sam Hartman, Stephen Farrell, Kathleen Moriarty and Francis Dupont 495 for their thoughtful review comments. 497 8. References 499 8.1. Normative References 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 522 Initiation Protocol (SIP) Back-to-Back User Agents", RFC 523 7092, December 2013. 525 8.2. Informative References 527 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 528 Address Translator (Traditional NAT)", RFC 3022, January 529 2001. 531 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 532 A., Peterson, J., Sparks, R., Handley, M., and E. 533 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 534 June 2002. 536 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 537 Self-Address Fixing (UNSAF) Across Network Address 538 Translation", RFC 3424, November 2002. 540 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 541 in Session Description Protocol (SDP)", RFC 3605, October 542 2003. 544 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 545 Description Protocol", RFC 4566, July 2006. 547 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 548 and H. Ashida, "Common Requirements for Carrier-Grade NATs 549 (CGNs)", BCP 127, RFC 6888, April 2013. 551 [RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT 552 Traversal (HNT) for Media in Real-Time Communication", RFC 553 7362, September 2014. 555 Authors' Addresses 557 Ram Mohan Ravindranath 558 Cisco 559 Cessna Business Park 560 Sarjapur-Marathahalli Outer Ring Road 561 Bangalore, Karnataka 560103 562 IN 564 Email: rmohanr@cisco.com 565 Tirumaleswar Reddy 566 Cisco 567 Cessna Business Park, Varthur Hobli 568 Sarjapur Marathalli Outer Ring Road 569 Bangalore, Karnataka 560103 570 IN 572 Email: tireddy@cisco.com 574 Gonzalo Salgueiro 575 Cisco Systems, Inc. 576 7200-12 Kit Creek Road 577 Research Triangle Park, NC 27709 578 US 580 Email: gsalguei@cisco.com