idnits 2.17.1 draft-kaplan-mmusic-latching-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 5, 2012) is 4434 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3489' is defined on line 505, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC6189' is defined on line 550, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Kaplan 3 Internet-Draft Acme Packet 4 Intended status: Informational E. Ivov 5 Expires: September 6, 2012 Jitsi 6 D. Wing 7 Cisco 8 March 5, 2012 10 Latching: Hosted NAT Traversal (HNT) for Media in Real-Time 11 Communication 12 draft-kaplan-mmusic-latching-00 14 Abstract 16 This document describes behavior of signalling intermediaries in RTC 17 deployments, sometimes referred to as Session Border Controllers 18 (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of 19 mechanisms, such as media relaying and latching, that such 20 intermediaries use to enable other RTC devices behind NATs to 21 communicate with each other. This document is non-normative, and is 22 only written to explain HNT in order to provide a reference to the 23 IETF community, as well as an informative description to 24 manufacturers, and users. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 6, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 5 64 5. Media Behavior, Latching . . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 Network Address Translators (NATs) are widely used in the Internet by 74 consumers and organizations. Although specific NAT behaviors vary, 75 this document uses the term "NAT" for devices that map any IPv4 or 76 IPv6 address and transport port number to another IPv4 or IPv6 77 address and transport port number. This includes consumer NAPTs, 78 Firewall-NATs, IPv4-IPv6 NATs, Carrier-Grade NATs, etc. 80 Protocols like SIP [RFC3261], and others that try to use a more 81 direct path for media than with signalling, are difficult to use 82 across NATs. They use IP addresses and transport port numbers 83 encoded in bodies such as SDP [RFC4566]> as well as, in the case of 84 SIP, various header fields. Such addresses and ports are unusable 85 unless all peers in a session are located behind the same NAT. 87 Mechanisms such as STUN [RFC5389], TURN [RFC5766], and ICE [RFC5245], 88 did not exist when protocols like SIP began being deployed. Session 89 Border Controllers (SBCs) that were already being used by SIP domains 90 for other SIP and media-related purposes began to use proprietary 91 mechanisms to enable SIP devices behind NATs to communicate across 92 the NATs. 94 The term often used for this behavior is Hosted NAT Traversal (HNT), 95 although some manufacturers sometimes use other names such as "Far- 96 end NAT Traversal" or "NAT assist" instead. The systems which 97 perform HNT are frequently SBCs as described in [RFC5853], although 98 other systems such as media gateways and "media proxies" sometimes 99 perform the same role. For the purposes of this document, all such 100 systems are referred to as SBCs, and the NAT traversal behavior is 101 called HNT. 103 As of this document's creation time, a vast majority of SIP domains 104 use HNT to enable SIP devices to communicate across NATs, despite the 105 publication of ICE. There are many reasons for this, but those 106 reasons are not relevant to this document's purpose and will not be 107 discussed. It is however worth pointing out that the current 108 deployment levels of HNT and NATs themselves make an exclusive 109 adoption of ICE highly unlikely in the foreseeable future. 111 The purpose of this document is to describe the mechanisms often used 112 for HNT at the SDP and media layer, in order to aid understanding the 113 implications and limitations imposed by it. Although the mechanisms 114 used in HNT are not novel to experts, publication in an IETF document 115 is useful as a means of providing common terminology and a reference 116 for related documents. 118 In no way does this document try to make a case for HNT or present it 119 as a solution that is somehow superior to alternatives such as ICE. 121 It is also worth mentioning that there are purely signaling-layer 122 components of HNT as well. One such component is briefly described 123 for SIP in [RFC5853], but that is not the focus of this document. 124 The SIP signaling-layer component of HNT is typically more 125 implementation-specific and deployment-specific than the SDP and 126 media components. For the purposes of this document it is hence 127 assumed that signaling intermediaries handle traffic in way that 128 allows protocols such as SIP to function correctly across the NATs. 130 The rest of this document is going to focus primarily on use of HNT 131 for SIP. However, the mechanisms described here are relatively 132 generic and are often used with other protocols, such as XMPP 133 [RFC6120], MGCP, H.248/MEGACO, and H.323. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 3. Background 143 The general problems with NAT traversal for protocols such as SIP 144 are: 145 1. The addresses and port numbers encoded in SDP bodies (or their 146 equivalents) by NATed User Agents (UAs) are not usable across the 147 Internet, because they represent the private addressing 148 information of the UA rather than the addresses/ports that will 149 be mapped to/from by the NAT. 150 2. The policies inherent in NATs, and explicit in Firewalls, are 151 such that packets from outside the NAT cannot reach the UA until 152 the UA sends packet out first. 153 3. Some NATs apply endpoint dependent filtering on incoming packets, 154 as described in [RFC4787] and thus a UA may only be able to 155 receive packets from the same remote peer IP:port as it sends 156 packets out to. 158 In order to overcome these issues, signaling intermediaries such as 159 SIP SBCs on the public side of the NATs perform HNT for both 160 signaling and media. An example deployment model of HNT and SBCs is 161 shown in Figure 1. 163 +-----+ +-----+ 164 | SBC |-------| SBC | 165 +-----+ +-----+ 166 / \ 167 / Public Net \ 168 / \ 169 +-----+ +-----+ 170 |NAT-A| |NAT-B| 171 +-----+ +-----+ 172 / \ 173 / Private Net Private Net \ 174 / \ 175 +------+ +------+ 176 | UA-A | | UA-B | 177 +------+ +------+ 179 Figure 1: Logical Deployment Paths 181 4. Impact on Signaling 183 Along with codec and other media-layer information, session 184 establishment signaling also conveys, potentially private and non- 185 globally routable addressing information. Signaling intermediaries 186 would hence modify such information so that peer UAs are given the 187 (public) addressing information of a media relay controlled by the 188 intermediary. 190 Quite often, the IP address of the newly introduced media relay may 191 be the same as that of the signaling intermediary (e.g. the SIP SBC) 192 or it may be a completely different one. In almost all cases 193 however, the new address would belong to the same IP address family 194 as the one used for signaling, since it is known to work for that UA. 196 The port numbers introduced in the signaling by the intermediary are 197 typically allocated dynamically. Allocation strategies are entirely 198 implementation dependent and they often vary from one product to the 199 next. 201 The offer/answer media negotiation model [RFC3264] is such that once 202 an offer is sent, the generator of the offer needs to be prepared to 203 receive media on the advertised address/ports. In practice such 204 media may or may not be received, depending on the implementations 205 participating in a given session, local policies, and call scenario. 206 For example if a SIP SDP Offer originally came from a UA behind a 207 NAT, the SIP SBC cannot send media to it until an SDP Answer is given 208 to the UA and latching (Section 5) occurs. Another example is when a 209 SIP SBC sends an SDP Offer in a SIP INVITE to a residential 210 customer's UA and receives back SDP in a 18x response, the SBC may 211 decide not to send media to that customer UA until a SIP 200 response 212 for policy reasons, to prevent toll-fraud. 214 5. Media Behavior, Latching 216 An UA behind a NAT streams media from a private address:port set that 217 once packets cross the NAT, will be mapped to a public set. The UA 218 however is not typically aware of the public mapping and would often 219 advertise in the private address:port couple in signaling. This way, 220 when the signalling intermediary performing HNT receives the private 221 addressing information from the UA it will not know what address/ 222 ports to send media to. Therefore media relays used in HNT would 223 often use a mechanism called "latching". 225 Historically, "latching" only referred to the process by which SBCs 226 "latch" onto UDP packets from a given UA for security purposes, and 227 "symmetric-latching" is when the latched address:ports are used to 228 send media back to the UA. Today most people talk about them both as 229 "latching", and thus this document does as well. 231 The latching mechanism works as follows: 232 1. After receiving an offer from a NATed UA, a signaling 233 intermediary located on the public Internet would allocate a set 234 of IP address:ports on a media relay. The set would then be 235 advertised to the remote party so that it would use it for all 236 media it wished to send toward the UA. 237 2. Next, after receiving an answer to its offer, the signaling 238 server would allocate a second address:port set on the media 239 relay. It would advertise this second set to the UA and use it 240 for all media traffic to and from the UA. 241 3. The media relay receives the media packets on the allocated 242 ports, and uses their source address and port as a destination 243 for all media bound in the opposite direction. In other words, 244 it "latches" or locks on these source address:port set. 245 4. This way all media streamed by the UA would be received on the 246 second address:port set. The source addresses and ports of the 247 traffic would belong to the public interface of the NAT in front 248 of the UA and anything that the relay sends there would find its 249 way to it. 250 5. Similarly the source of the stream originating at the remote 251 party would be latched upon and used for media going in that 252 direction. 253 6. Latching is usually done only once per peer and not allowed to 254 change or cause a re-latching until a new offer and answer get 255 exchanged. 257 Figure 2 describes how latching occurs for SIP where HNT is provided 258 by an SBC connected to two networks: 38.2.2/24 facing towards the UAC 259 network and 38.1.1/24 facing towards the UAS network. 261 10.0.0.1 262 SIP UAC NAT 38.2.2/24-SBC-38.1.1/24 SIP UAS 263 ------- --- --- ------- 264 | | | | 265 1. |-SIP INVITE+offer c=10.0.0.1-->| | 266 | | | | 267 2. | | (SBC allocates 38.1.1.2/22007 | 268 | | for inbound RTP from UAS, | 269 | | and 38.2.2.4/36010 for | 270 | | inbound RTP from UAC) | 271 | | | | 272 3. | | |-INVITE+offer-->| 273 | | | c=38.1.1.2/2207| 274 | | | | 275 4. | | |<-180 Ringing---| 276 | | | | 277 | | | | 278 5. |<---180 Ringing----------------| | 279 | | | | 280 6. | | |<-200+answer----| 281 7. |<-200+answer, c=38.2.2.4/36010-| c=114.1.1.3 | 282 | | | | 283 8. |--ACK------------------------->| | 284 9. | | |---ACK--------->| 285 | | | | 286 10. |==RTP, dest=38.2.2.4/36010====>| | 287 | | | | 288 11. | | (SBC latches to | 289 | | source IP address and | 290 | | port seen at (10)) | 291 | | | | 292 12. | | |<== RTP ========| 293 | | | | 294 13. |<==RTP, to latched address=====| | 295 | | | | 297 Figure 2: Latcing by a SIP SBC across two interfaces 299 While XMPP implementations often rely on ICE to handle NAT traversal, 300 there are some that also support a non-ICE transport called Raw UDP 301 [XEP-0177]. Figure 3 describes how latching occurs for one such XMPP 302 implementate where HNT is provided by an XMPP server on the public 303 internet. 305 10.0.0.1 10.0.0.9/1.2.3.4 3.4.5.6 5.6.7.8 306 XMPP Client1 NAT XMPP Server XMPP Client2 307 ------- --- --- ------- 308 | | | | 309 1. |----session-initiate cand=10.0.0.1-->| | 310 | | | | 311 2. |<------------ack---------------------| | 312 | | | | 313 3. | | (Server allocates 3.4.5.6/2200 | 314 | | for inbound RTP from Client2, | 315 | | and 3.4.5.6/3300 for | 316 | | inbound RTP from Client1) | 317 | | | | 318 4. | | |-session-initiate->| 319 | | | cand=3.4.5.6/2200 | 320 | | | | 321 5. | | |<-------ack--------| 322 | | | | 323 | | | | 324 6. | | |<--session-accept--| 325 | | | cand=5.6.7.8 | 326 | | | | 327 7. | | |--------ack------->| 328 8. |<--session-accept cand=3.4.5.6/3300--| | 329 | | | | 330 9. |-------------ack-------------------->| | 331 | | | | 332 | | | | 333 10. |========RTP, dest=3.4.5.6/3300======>| | 334 | | | | 335 11. | | (XMPP server latches to | 336 | | src IP 1.2.3.4 and src | 337 | | port seen at (10)) | 338 | | | | 339 12. | | |<== RTP ===========| 340 | | | | 341 13. |<======RTP, to latched address=======| | 342 | | | | 344 Figure 3: Latcing by a SIP SBC across two interfaces 346 The above is a general description, and some details vary between 347 implementations or configuration settings. For example, some 348 intermediaries perform additional logic before latching on received 349 packet source information to prevent malicious attacks or latching 350 erroneously to previous media senders - often called "rogue-rtp" in 351 the industry. 353 It is worth pointing out that latching is not an exclusively "server 354 affair" and some clients may also use it in cases where they are 355 configured with a public IP address and they are contacted by a NATed 356 client with no other NAT traversal means. 358 In order for latching to function correctly, the UA behind the NAT 359 needs to support symmetric RTP. That is, it needs to use the same 360 ports for sending data as the ones it listens on for inbound packets. 361 Today this is the case for with, for example, almost all SIP and XMPP 362 clients. Also UAs need to make sure they can begin sending media 363 packets independently and without waiting for packets to arrive 364 first. In theory, it is possible that some UAs would not send 365 packets out first; for example if a SIP session begins in 'inactive' 366 or 'recvonly' SDP mode from the UA behind the NAT. In practice, 367 however, SIP sessions from regular UAs (the kind that one could find 368 behind a NAT) virtually never begin in an inactive or recvonly mode, 369 for obvious reasons. The media direction would also be problematic 370 if the SBC side indicated 'inactive' or 'sendonly' modes when it sent 371 SDP to the UA. However SBCs providing HNT would always be configured 372 to avoid this. 374 Given that, in order for latching to work properly, media relays need 375 to begin receiving media before they start sending, it is possible 376 for deadlocks to occur. This can happen when the UAC and the UAS in 377 a session are connected to different signalling intermediaries that 378 both provide HNT. In this case the media relays controled by the 379 signalling servers could end up each waiting upon the other to 380 initiate the streaming. To prevent this relays would often attempt 381 to start streaming toward the address:port sets provided in the 382 offer/answer even before receiving any inbound traffic. If the 383 entity they are streaming to is another HNT performing server it 384 would have provided its relay's public address and ports and the 385 early stream would find its target. 387 Although many SBCs only support UDP-based media latching, and in 388 particular RTP/RTCP, many SBCs support TCP-based media latching as 389 well. TCP-based latching is more complicated, and involves forcing 390 the UA behind the NAT to be the TCP client and sending the initial 391 SYN-flagged TCP packet to the SBC (i.e., be the 'active' mode side of 392 a TCP-based media session). If both UAs of a TCP-based media session 393 are behind NATs, then SBCs typically force both UAs to be the TCP 394 clients, and the SBC splices the TCP connections together. TCP 395 splicing is a well-known technique, and described in [tcp-splicing]. 397 HNT and latcing in particular are generally found to be working 398 reliably but they do have obvious caveats. The first one usually 399 raised by IETF members is that UAs are not aware of it occurring. 400 This makes it impossible for the mechanism to be used with protocols 401 such as ICE that try various traversal techniques in an effort to 402 choose the one the best suits a particular situation. Overwriting 403 address information in in offers and answers may actually completely 404 prevent UAs from using ICE because of the ice-mismatch rules 405 described in [RFC5245] 407 The second issue raised by IETF members is that it causes media to go 408 through a relay instead of directly over the IP-routed path between 409 the two participating UAs. While this adds obvious drawbacks such as 410 reduced scalability and often increased latency, it is also 411 considered a benefit by SBC administrators: if a customer pays for 412 "phone" service, for example, the media is what is truly being paid 413 for, and the administrators usually like to be able to detect that 414 media is flowing correctly, evaluate its quality, know if and why it 415 failed, etc. Also in some cases routing media through operator 416 controlled relays may route media over paths explicitly optimized for 417 media and hence offer better performance than regular Internet 418 routing. 420 6. Security Considerations 422 The security implications for HNT are complicated. The mechanism 423 itself needs to be concerned with latching to incorrect and possibly 424 malicious sources. A malicious source could, for example, attempt a 425 resource exhaustion attack by flooding all possible media-latching 426 UDP ports on the SBC in order to prevent calls from succeeding. SBCs 427 have various mechanisms to prevent this from happening., or alert an 428 administrator, but a sufficiently sophisticated attacker may be able 429 to bypass them for some time. The most common example is typically 430 referred to as "restricted-latching", whereby the SBC will not latch 431 to any packets from a source public IP other than the one the SIP UA 432 uses for SIP signaling. In some cases the limitation may be loosened 433 to allos media from a range of IPs belonging to the same network. 434 This way the SBC simply ignores and does not latch onto packets 435 coming from the attacker. If the attacker knows the public source IP 436 of the real SIP UA making a call, then they could still flood all of 437 the SBC's public IPs and ports with packets spoofing that real SIP 438 UA's public source IP. However, this would only disturb media that 439 IP (or range of IPs) rather than all calls that the SBC is servicing. 441 A malicious source could send media packets to an SBC media-latching 442 UDP port in the hopes of being latched-to for the purpose of 443 receiving media for a given SIP session. SBCs have various 444 mechanisms to prevent this as well. Restricted latching for example 445 would also help in this case since the attacker can't make the SBC 446 send media packets back to themselves since the SBC will not latch 447 onto the attackers packets. There could still be an issue if the 448 attacker happens to be either (1) in the IP routing path and thus can 449 spoof the same IP as the real UA and get the media coming back, in 450 which case the attacker hardly needs to attack at all to begin with, 451 or (2) the attacker is behind the same NAT as the real SIP UA, in 452 which case the attacker's packets will be latched-to by the SBC and 453 the SBC will send media back to the attacker. In this latter case, 454 which is a corner-case to begin with, in practice the real SIP UA 455 will end the call anyway, because the human won't hear anything and 456 will hang up. EXCEPT, if it's not a human but rather an answering 457 machine, it may not hang up (though most answering machines do hang 458 up when they don't get media). The attacker could also redirect all 459 media to the real SIP UA after receiving it, in which case the attack 460 would likely remain undetected and succeed. Naturally, SRTP 461 [RFC3711] would prevent such an attack from being useful, and should 462 be used independently of HNT. 464 For SIP clients, HNT is usually transparent in the sense that the SIP 465 UA does not know it occurs. In certain cases it may be detectable, 466 such as when ICE is supported by the SIP UA and the SBC modifies the 467 default connection address and media port numbers in SDP, thereby 468 disabling ICE due to the mismatch condition. Even in that case, 469 however, the SIP UA only knows a middlebox is relaying media, but not 470 necessarily that it is performing latching/HNT. [TODO: need to 471 explain further] 473 In order to perform HNT, the SBC has to modify SDP to and from the 474 SIP UA behind a NAT, and thus the SIP UA cannot use S/MIME [RFC5751], 475 and it cannot sign a sending request or verify a received request 476 using [RFC4474] unless the SBC re-signs the request. However it is 477 sometimes argued that, neither S/MIME nor [RFC4474] are widely 478 deployed and that this may not be a real concern. 480 From a privacy perspective, media relaying is sometimes seen as a way 481 of protecting one's IP address and not revealing it to the remote 482 party. That kind of IP address masking is often perceived as 483 important. However, this is no longer an exclusive advantage of HNT 484 since it can also be accomplished by client-controlled relaying 485 mechanisms such as TURN [RFC5766], if the client explicitly wishes to 486 do so. 488 7. References 489 7.1. Normative References 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, March 1997. 494 7.2. Informative References 496 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 497 A., Peterson, J., Sparks, R., Handley, M., and E. 498 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 499 June 2002. 501 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 502 with Session Description Protocol (SDP)", RFC 3264, 503 June 2002. 505 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 506 "STUN - Simple Traversal of User Datagram Protocol (UDP) 507 Through Network Address Translators (NATs)", RFC 3489, 508 March 2003. 510 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 511 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 512 RFC 3711, March 2004. 514 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 515 Authenticated Identity Management in the Session 516 Initiation Protocol (SIP)", RFC 4474, August 2006. 518 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 519 Description Protocol", RFC 4566, July 2006. 521 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 522 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 523 RFC 4787, January 2007. 525 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 526 (ICE): A Protocol for Network Address Translator (NAT) 527 Traversal for Offer/Answer Protocols", RFC 5245, 528 April 2010. 530 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 531 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 532 October 2008. 534 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 535 Mail Extensions (S/MIME) Version 3.2 Message 536 Specification", RFC 5751, January 2010. 538 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 539 Relays around NAT (TURN): Relay Extensions to Session 540 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 542 [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 543 A., and M. Bhatia, "Requirements from Session Initiation 544 Protocol (SIP) Session Border Control (SBC) Deployments", 545 RFC 5853, April 2010. 547 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 548 Protocol (XMPP): Core", RFC 6120, March 2011. 550 [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 551 Path Key Agreement for Unicast Secure RTP", RFC 6189, 552 April 2011. 554 [XEP-0177] 555 Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan, 556 "XEP-0177: Jingle Raw UDP Transport Method", XEP XEP-0177, 557 December 2009. 559 Authors' Addresses 561 Hadriel Kaplan 562 Acme Packet 563 100 Crosby Drive 564 Bedford, MA 01730 565 USA 567 Email: hkaplan@acmepacket.com 569 Emil Ivov 570 Jitsi 571 Strasbourg 67000 572 France 574 Email: emcho@jitsi.org 575 Dan Wing 576 Cisco Systems, Inc. 577 170 West Tasman Drive 578 San Jose, CA 95134 579 USA 581 Email: dwing@cisco.com