idnits 2.17.1 draft-ietf-mmusic-latching-02.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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 10, 2013) is 3972 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ivov 3 Internet-Draft Jitsi 4 Intended status: Informational H. Kaplan 5 Expires: December 12, 2013 Acme Packet 6 D. Wing 7 Cisco 8 June 10, 2013 10 Latching: Hosted NAT Traversal (HNT) for Media in Real-Time 11 Communication 12 draft-ietf-mmusic-latching-02 14 Abstract 16 This document describes behavior of signalling intermediaries in 17 Real-Time Communication (RTC) deployments, sometimes referred to as 18 Session Border Controllers (SBCs), when performing Hosted NAT 19 Traversal (HNT). HNT is a set of mechanisms, such as media relaying 20 and latching, that such intermediaries use to enable other RTC 21 devices behind NATs to communicate with each other. This document is 22 non-normative, and is only written to explain HNT in order to provide 23 a reference to the IETF community, as well as an informative 24 description to 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 December 12, 2013. 43 Copyright Notice 45 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 5 63 4. Media Behavior, Latching . . . . . . . . . . . . . . . . . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 67 8. Informative References . . . . . . . . . . . . . . . . . . . 12 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 70 1. Introduction 72 Network Address Translators (NATs) are widely used in the Internet by 73 consumers and organizations. Although specific NAT behaviors vary, 74 this document uses the term "NAT" for devices that map any IPv4 or 75 IPv6 address and transport port number to another IPv4 or IPv6 76 address and transport port number. This includes consumer NATs, 77 Firewall-NATs, IPv4-IPv6 NATs, Carrier-Grade NATs, etc. 79 Protocols like SIP [RFC3261], and others that try to use a more 80 direct path for media than with signalling, are difficult to use 81 across NATs. They use IP addresses and transport port numbers 82 encoded in bodies such as SDP [RFC4566] as well as, in the case of 83 SIP, various header fields. Such addresses and ports are unusable 84 unless all peers in a session are located behind the same NAT. 86 Mechanisms such as Session Traversal Utilities for NAT (STUN) 87 [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and 88 Interactive Connectivity Establishment (ICE) [RFC5245] did not exist 89 when protocols like SIP began being deployed. Some mechanisms, such 90 as the early versions of STUN [RFC3489], had started appearing but 91 they were unreliable and suffered a number of issues typical for 92 UNilateral Self-Address Fixing (UNSAF) and described in [RFC3424]. 93 For these and other reasons, Session Border Controllers (SBCs) that 94 were already being used by SIP domains for other SIP and media- 95 related purposes began to use proprietary mechanisms to enable SIP 96 devices behind NATs to communicate across the NATs. 98 The term often used for this behavior is Hosted NAT Traversal (HNT), 99 although some manufacturers sometimes use other names such as "Far- 100 end NAT Traversal" or "NAT assist" instead. The systems which 101 perform HNT are frequently SBCs as described in [RFC5853], although 102 other systems such as media gateways and "media proxies" sometimes 103 perform the same role. For the purposes of this document, all such 104 systems are referred to as SBCs, and the NAT traversal behavior is 105 called HNT. 107 As of this document's creation time, a vast majority of SIP domains 108 use HNT to enable SIP devices to communicate across NATs, despite the 109 publication of ICE. There are many reasons for this, but those 110 reasons are not relevant to this document's purpose and will not be 111 discussed. It is however worth pointing out that the current 112 deployment levels of HNT and NATs themselves make an exclusive 113 adoption of ICE highly unlikely in the foreseeable future. 115 The purpose of this document is to describe the mechanisms often used 116 for HNT at the SDP and media layer, in order to aid understanding the 117 implications and limitations imposed by it. Although the mechanisms 118 used in HNT are not novel to experts, publication in an IETF document 119 is useful as a means of providing common terminology and a reference 120 for related documents. 122 In no way does this document try to make a case for HNT or present it 123 as a solution that is somehow better than alternatives such as ICE. 124 The mechanisms described here, popular as they may be, are not 125 necessarily considered best practice or recommended operation. 127 It is also worth mentioning that there are purely signaling-layer 128 components of HNT as well. One such component is briefly described 129 for SIP in [RFC5853], but that is not the focus of this document. 130 The SIP signaling-layer component of HNT is typically more 131 implementation-specific and deployment-specific than the SDP and 132 media components. For the purposes of this document it is hence 133 assumed that signaling intermediaries handle traffic in way that 134 allows protocols such as SIP to function correctly across the NATs. 136 The rest of this document is going to focus primarily on use of HNT 137 for SIP. However, the mechanisms described here are relatively 138 generic and are often used with other protocols, such as XMPP 139 [RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], H.248/ 140 MEGACO [RFC5125], and H.323 [H.323]. 142 2. Background 144 The general problems with NAT traversal for protocols such as SIP 145 are: 147 1. The addresses and port numbers encoded in SDP bodies (or their 148 equivalents) by NATed User Agents (UAs) are not usable across the 149 Internet, because they represent the private network addressing 150 information of the UA rather than the addresses/ports that will 151 be mapped to/from by the NAT. 153 2. The policies inherent in NATs, and explicit in Firewalls, are 154 such that packets from outside the NAT cannot reach the UA until 155 the UA sends packet out first. 157 3. Some NATs apply endpoint dependent filtering on incoming packets, 158 as described in [RFC4787] and thus a UA may only be able to 159 receive packets from the same remote peer IP:port as it sends 160 packets out to. 162 In order to overcome these issues, signaling intermediaries such as 163 SIP SBCs on the public side of the NATs perform HNT for both 164 signaling and media. An example deployment model of HNT and SBCs is 165 shown in Figure 1. 167 +-----+ +-----+ 168 | SBC |-------| SBC | 169 +-----+ +-----+ 170 / \ 171 / Public Net \ 172 / \ 173 +-----+ +-----+ 174 |NAT-A| |NAT-B| 175 +-----+ +-----+ 176 / \ 177 / Private Net Private Net \ 178 / \ 179 +------+ +------+ 180 | UA-A | | UA-B | 181 +------+ +------+ 183 Figure 1: Logical Deployment Paths 185 3. Impact on Signaling 187 Along with codec and other media-layer information, session 188 establishment signaling also conveys, potentially private and non- 189 globally routable addressing information. Signaling intermediaries 190 would hence modify such information so that peer UAs are given the 191 (public) addressing information of a media relay controlled by the 192 intermediary. 194 Quite often, the IP address of the newly introduced media relay may 195 be the same as that of the signaling intermediary (e.g. the SIP SBC) 196 or it may be a completely different one. In almost all cases 197 however, the new address would belong to the same IP address family 198 as the one used for signaling, since it is known to work for that UA. 200 The port numbers introduced in the signaling by the intermediary are 201 typically allocated dynamically. Allocation strategies are entirely 202 implementation dependent and they often vary from one product to the 203 next. 205 The offer/answer media negotiation model [RFC3264] is such that once 206 an offer is sent, the generator of the offer needs to be prepared to 207 receive media on the advertised address/ports. In practice such 208 media may or may not be received, depending on the implementations 209 participating in a given session, local policies, and call scenario. 210 For example if a SIP SDP Offer originally came from a UA behind a 211 NAT, the SIP SBC cannot send media to it until an SDP Answer is given 212 to the UA and latching (Section 4) occurs. Another example is when a 213 SIP SBC sends an SDP Offer in a SIP INVITE to a residential 214 customer's UA and receives back SDP in a 18x response, the SBC may 215 decide not to send media to that customer UA until a SIP 200 response 216 for policy reasons, to prevent toll-fraud. 218 4. Media Behavior, Latching 219 An UA behind a NAT streams media from a private address:port set that 220 once packets cross the NAT, will be mapped to a public set. The UA 221 however is not typically aware of the public mapping and would often 222 advertise the private address:port couple in signaling. This way, 223 when the signalling intermediary performing HNT receives private 224 addressing information from from a NATed UA it will not know what 225 address/ports to send media to. Therefore media relays used in HNT 226 would often use a mechanism called "latching". 228 Historically, "latching" only referred to the process by which SBCs 229 "latch" onto UDP packets from a given UA for security purposes, and 230 "symmetric-latching" is when the latched address:ports are used to 231 send media back to the UA. Today most people talk about them both as 232 "latching", and thus this document does as well. 234 The latching mechanism works as follows: 236 1. After receiving an offer from a NATed UA, a signaling 237 intermediary located on the public Internet would allocate a set 238 of IP address:ports on a media relay. The set would then be 239 advertised to the remote party so that it would use those media 240 relay address:ports for all media it wished to send toward the 241 UA. 243 2. Next, after receiving an answer to its offer, the signaling 244 server would allocate a second address:port set on the media 245 relay. It would advertise this second set in the answer to the 246 UA. The UA will then send to this media relay address:port. 248 3. The media relay receives the media packets on the allocated 249 ports, and uses their source address and port as a destination 250 for all media bound in the opposite direction. In other words, 251 it "latches" or locks on these source address:port set. 253 4. This way all media streamed by the UA would be received on the 254 second address:port set. The source addresses and ports of the 255 traffic would belong to the public interface of the NAT in front 256 of the UA and anything that the relay sends there would find its 257 way to it. 259 5. Similarly the source of the stream originating at the remote 260 party would be latched upon and used for media going in that 261 direction. 263 6. Latching is usually done only once per peer and not allowed to 264 change or cause a re-latching until a new offer and answer get 265 exchanged (e.g. in a subsequent call or after a SIP peer has gone 266 on and off hold). The reasons for such restrictions are mostly 267 related to security: once a session has started a user agent is 268 not expected to suddenly start streaming from a different port 269 without sending a new offer first. A change may indicate an 270 attempt to hijack the session. In some cases however, a port 271 change may be caused by a re-mapping in a NAT device standing 272 between the SBC and the UA. More advanced SBCs may therefore 273 allow some level of flexibility on the re-latching restrictions 274 while carefully considering the potential security implications 275 of doing so. 277 Figure 2 describes how latching occurs for SIP where HNT is provided 278 by an SBC connected to two networks: 203.0.113/24 facing towards the 279 User Agent Client (UAC) network and 198.51.100/24 facing towards the 280 User Agent Server (UAS) network. 282 192.0.2.1 198.51.100.33 283 Alice NAT 203.0.113.0/24-SBC-198.51.100.0/24 Bob 284 ------- --- --- ------- 285 | | | | 286 1. |--SIP INVITE+offer c=192.0.2.1--->| | 287 | | | | 288 2. | | (SBC allocates 198.51.100.2:22007 | 289 | | for inbound RTP from UAS) | 290 | | | | 291 3. | | |---INVITE+offer---->| 292 | | |c=198.51.100.2:22007| 293 | | | | 294 4. | | |<---180 Ringing-----| 295 | | | | 296 | | | | 297 5. |<------180 Ringing----------------| | 298 | | | | 299 6. | | |<---200+answer------| 300 | | | | 301 7. | | (SBC allocates 203.0.113.4:36010 | 302 | | for inbound RTP from UAC) | 303 | | | | 304 8. |<-200+answer,c=203.0.113.4:36010--| c=198.51.100.33 | 305 | | | | 306 9. |------------ACK------------------>| | 307 10. | | |-------ACK--------->| 308 | | | | 309 11. |=====RTP,dest=203.0.113.4:36010==>| | 310 | | | | 311 12. | | (SBC latches to | 312 | | source IP address and | 313 | | port seen at (10)) | 314 | | | | 315 13. | | |<====== RTP ========| 316 | | | | 317 14. |<=====RTP, to latched address=====| | 318 | | | | 320 Figure 2: Latching by a SIP SBC across two interfaces 322 While XMPP implementations often rely on ICE to handle NAT traversal, 323 there are some that also support a non-ICE transport called XMPP 324 Jingle Raw UDP Transport Method [XEP-0177]. Figure 3 describes how 325 latching occurs for one such XMPP implementation where HNT is 326 provided by an XMPP server on the public internet. 328 192.0.2.1 192.0.2.9/203.0.113.4 203.0.113.9 198.51.100.8 329 XMPP Client1 NAT XMPP Server XMPP Client2 330 ----- --- --- ----- 331 | | | | 332 1. |----session-initiate cand=192.0.2.1--->| | 333 | | | | 334 2. |<------------ack-----------------------| | 335 | | | | 336 3. | | (Server allocates 203.0.113.9:2200 | 337 | | for inbound RTP from Client2) | 338 | | | | 339 4. | | |--session-initiate->| 340 | | cand=203.0.113.9:2200| 341 | | | | 342 5. | | |<-------ack---------| 343 | | | | 344 | | | | 345 6. | | |<--session-accept---| 346 | | | cand=198.51.100.8 | 347 | | | | 348 7. | | |--------ack-------> | 349 | | | | 350 8. | | (Server allocates 203.0.113.9:3300 | 351 | | for inbound RTP from Client1) | 352 | | | | 353 9. |<-session-accept cand=203.0.113.9:3300-| | 354 | | | | 355 10. |-----------------ack------------------>| | 356 | | | | 357 | | | | 358 11. |======RTP, dest=203.0.113.9:3300======>| | 359 | | | | 361 12. | | (XMPP server latches to | 362 | | src IP 203.0.113.4 and | 363 | | src port seen at (10)) | 364 | | | | 365 13. | | |<====== RTP ========| 366 | | | | 367 14. |<======RTP, to latched address=========| | 368 | | | | 370 Figure 3: Latching by a SIP SBC across two interfaces 372 The above is a general description, and some details vary between 373 implementations or configuration settings. For example, some 374 intermediaries perform additional logic before latching on received 375 packet source information to prevent malicious attacks or latching 376 erroneously to previous media senders - often called "rogue-rtp" in 377 the industry. 379 It is worth pointing out that latching is not an exclusively "server 380 affair" and some clients may also use it in cases where they are 381 configured with a public IP address and they are contacted by a NATed 382 client with no other NAT traversal means. 384 In order for latching to function correctly, the UA behind the NAT 385 needs to support symmetric RTP. That is, it needs to use the same 386 ports for sending data as the ones it listens on for inbound packets. 387 Today this is the case for with, for example, almost all SIP and XMPP 388 clients. Also UAs need to make sure they can begin sending media 389 packets independently and without waiting for packets to arrive 390 first. In theory, it is possible that some UAs would not send 391 packets out first; for example if a SIP session begins in 'inactive' 392 or 'recvonly' SDP mode from the UA behind the NAT. In practice, 393 however, SIP sessions from regular UAs (the kind that one could find 394 behind a NAT) virtually never begin an inactive or 'recvonly' mode, 395 for obvious reasons. The media direction would also be problematic 396 if the SBC side indicated 'inactive' or 'sendonly' modes when it sent 397 SDP to the UA. However SBCs providing HNT would always be configured 398 to avoid this. 400 Given that, in order for latching to work properly, media relays need 401 to begin receiving media before they start sending, it is possible 402 for deadlocks to occur. This can happen when the UAC and the UAS in 403 a session are connected to different signalling intermediaries that 404 both provide HNT. In this case the media relays controlled by the 405 signalling servers could end up each waiting upon the other to 406 initiate the streaming. To prevent this relays would often attempt 407 to start streaming toward the address:port sets provided in the offer 408 /answer even before receiving any inbound traffic. If the entity 409 they are streaming to is another HNT performing server it would have 410 provided its relay's public address and ports and the early stream 411 would find its target. 413 Although many SBCs only support UDP-based media latching, and in 414 particular RTP/RTCP, many SBCs support TCP-based media latching as 415 well. TCP-based latching is more complicated, and involves forcing 416 the UA behind the NAT to be the TCP client and sending the initial 417 SYN-flagged TCP packet to the SBC (i.e., be the 'active' mode side of 418 a TCP-based media session). If both UAs of a TCP-based media session 419 are behind NATs, then SBCs typically force both UAs to be the TCP 420 clients, and the SBC splices the TCP connections together. TCP 421 splicing is a well-known technique, and described in [tcp-splicing]. 423 HNT and latching in particular are generally found to be working 424 reliably but they do have obvious caveats. The first one usually 425 raised by IETF members is that UAs are not aware of it occurring. 426 This makes it impossible for the mechanism to be used with protocols 427 such as ICE that try various traversal techniques in an effort to 428 choose the one the best suits a particular situation. Overwriting 429 address information in in offers and answers may actually completely 430 prevent UAs from using ICE because of the ice-mismatch rules 431 described in [RFC5245] 433 The second issue raised by IETF members is that it causes media to go 434 through a relay instead of directly over the IP-routed path between 435 the two participating UAs. While this adds obvious drawbacks such as 436 reduced scalability and often increased latency, it is also 437 considered a benefit by SBC administrators: if a customer pays for 438 "phone" service, for example, the media is what is truly being paid 439 for, and the administrators usually like to be able to detect that 440 media is flowing correctly, evaluate its quality, know if and why it 441 failed, etc. Also in some cases routing media through operator 442 controlled relays may route media over paths explicitly optimized for 443 media and hence offer better performance than regular Internet 444 routing. 446 5. Security Considerations 448 A common concern is that an SBC that implements HNT may latch to 449 incorrect and possibly malicious sources. A malicious source could, 450 for example, attempt a resource exhaustion attack by flooding all 451 possible media-latching UDP ports on the SBC in order to prevent 452 calls from succeeding. SBCs have various mechanisms to prevent this 453 from happening, or alert an administrator when it does. Still, a 454 sufficiently sophisticated attacker may be able to bypass them for 455 some time. The most common example is typically referred to as 456 "restricted-latching", whereby the SBC will not latch to any packets 457 from a source public IP address other than the one the SIP UA uses 458 for SIP signaling. This way the SBC simply ignores and does not 459 latch onto packets coming from the attacker. In some cases the 460 limitation may be loosened to allow media from a range of IP 461 addresses belonging to the same network in order to allow for use 462 cases such as decomposed UAs and various forms of third party call 463 control. However, since relaxing the restrictions in such a way may 464 widen the gap for potential attackers, such configurations are 465 generally performed only on a case-by-case basis so that the 466 specifics of individual deployments would be taken into account. 468 In all of the above problems would still arise if the attacker knows 469 the public source IP of the UA that is actually making the call. 470 This would allow them to still flood all of the SBC's public IP 471 addresses and ports with packets spoofing that SIP UA's public source 472 IP address. However, this would only disturb media from that IP (or 473 range of IP addresses) rather than all calls that the SBC is 474 servicing. 476 A malicious source could send media packets to an SBC media-latching 477 UDP port in the hopes of being latched-to for the purpose of 478 receiving media for a given SIP session. SBCs have various 479 mechanisms to prevent this as well. Restricted latching for example 480 would also help in this case since the attacker can't make the SBC 481 send media packets back to themselves since the SBC will not latch 482 onto the attacker's packets. There could still be an issue if the 483 attacker happens to be either (1) in the IP routing path and thus can 484 spoof the same IP as the real UA and get the media coming back, in 485 which case the attacker hardly needs to attack at all to begin with, 486 or (2) the attacker is behind the same NAT as the legitimate SIP UA, 487 in which case the attacker's packets will be latched-to by the SBC 488 and the SBC will send media back to the attacker. In this latter 489 case, which may be of particular concern with carrier grade NATs, the 490 legitimate SIP UA will end the call anyway, because a human user 491 would not hear anything and will hang up. In the case of a non-human 492 call participant, such as an answering machine, this may not happen 493 (although many such automated UAs would also hang up when they do not 494 receive any media). The attacker could also redirect all media to 495 the real SIP UA after receiving it, in which case the attack would 496 likely remain undetected and succeed. Again, this would be of 497 particular concern with larger scale NATs serving many different 498 endpoints serving many different endpoints such as carrier grade 499 NATs. The larger the number of devices fronted by a NAT is, the more 500 use cases would vary and the more the number of possible attack 501 vectors would grow. 503 Naturally, SRTP [RFC3711] would help mitigate such threats and should 504 be used independently of HNT. For example, in cases where end-to-end 505 encryption is used it would still be possible for an attacker to 506 hijack a session despite the use of SRTP and perform a denial of 507 service attack. However, media integrity would not be compromised. 508 Additionally if the SBC that performs the latching is actually 509 participating in the SRTP key exchange then it would simply refuse to 510 latch onto a source unless it can authenticate it. 512 For SIP clients, HNT is usually transparent in the sense that the SIP 513 UA does not know it occurs. In certain cases it may be detectable, 514 such as when ICE is supported by the SIP UA and the SBC modifies the 515 default connection address and media port numbers in SDP, thereby 516 disabling ICE due to the mismatch condition. Even in that case, 517 however, the SIP UA only knows a middle box is relaying media, but 518 not necessarily that it is performing latching/HNT. 520 In order to perform HNT, the SBC has to modify SDP to and from the 521 SIP UA behind a NAT, and thus the SIP UA cannot use S/MIME [RFC5751], 522 and it cannot sign a sending request or verify a received request 523 using [RFC4474] unless the SBC re-signs the request. However it is 524 sometimes argued that, neither S/MIME nor [RFC4474] are widely 525 deployed and that this may not be a real concern. 527 From a privacy perspective, media relaying is sometimes seen as a way 528 of protecting one's IP address and not revealing it to the remote 529 party. That kind of IP address masking is often perceived as 530 important. However, this is no longer an exclusive advantage of HNT 531 since it can also be accomplished by client-controlled relaying 532 mechanisms such as TURN [RFC5766], if the client explicitly wishes to 533 do so. 535 6. IANA Considerations 537 This document has no actions for IANA. 539 Note to the RFC-Editor: please remove this section prior to 540 publication as an RFC. 542 7. Acknowledgements 544 The authors would like to thank Flemming Andreasen, Miguel A. 545 Garcia, Ari Keraenen and Paul Kyzivat for their reviews and 546 suggestions on improving this document. 548 8. Informative References 550 [H.323] International Telecommunication Union , "Packet Based 551 Multimedia Communication Systems", Recommendation H.323, 552 July 2003. 554 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 555 A., Peterson, J., Sparks, R., Handley, M., and E. 556 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 557 June 2002. 559 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 560 with Session Description Protocol (SDP)", RFC 3264, June 561 2002. 563 [RFC3424] Daigle, L. IAB, "IAB Considerations for UNilateral Self- 564 Address Fixing (UNSAF) Across Network Address 565 Translation", RFC 3424, November 2002. 567 [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control 568 Protocol (MGCP) Version 1.0", RFC 3435, January 2003. 570 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 571 "STUN - Simple Traversal of User Datagram Protocol (UDP) 572 Through Network Address Translators (NATs)", RFC 3489, 573 March 2003. 575 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 576 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 577 RFC 3711, March 2004. 579 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 580 Authenticated Identity Management in the Session 581 Initiation Protocol (SIP)", RFC 4474, August 2006. 583 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 584 Description Protocol", RFC 4566, July 2006. 586 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 587 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 588 RFC 4787, January 2007. 590 [RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", 591 RFC 5125, February 2008. 593 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 594 (ICE): A Protocol for Network Address Translator (NAT) 595 Traversal for Offer/Answer Protocols", RFC 5245, April 596 2010. 598 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 599 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 600 October 2008. 602 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 603 Mail Extensions (S/MIME) Version 3.2 Message 604 Specification", RFC 5751, January 2010. 606 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 607 Relays around NAT (TURN): Relay Extensions to Session 608 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 610 [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 611 A., and M. Bhatia, "Requirements from Session Initiation 612 Protocol (SIP) Session Border Control (SBC) Deployments", 613 RFC 5853, April 2010. 615 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 616 Protocol (XMPP): Core", RFC 6120, March 2011. 618 [XEP-0177] 619 Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan, 620 "XEP-0177: Jingle Raw UDP Transport Method", XEP XEP-0177, 621 December 2009. 623 Authors' Addresses 625 Emil Ivov 626 Jitsi 627 Strasbourg 67000 628 France 630 Email: emcho@jitsi.org 632 Hadriel Kaplan 633 Acme Packet 634 100 Crosby Drive 635 Bedford, MA 01730 636 USA 638 Email: hkaplan@acmepacket.com 639 Dan Wing 640 Cisco Systems, Inc. 641 170 West Tasman Drive 642 San Jose, CA 95134 643 USA 645 Email: dwing@cisco.com