idnits 2.17.1 draft-ietf-mmusic-latching-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. -- 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 (May 07, 2013) is 4006 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 551, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3015 (Obsoleted by RFC 3525) -- 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 (~~), 2 warnings (==), 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: November 08, 2013 Acme Packet 6 D. Wing 7 Cisco 8 May 07, 2013 10 Latching: Hosted NAT Traversal (HNT) for Media in Real-Time 11 Communication 12 draft-ietf-mmusic-latching-01 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 November 08, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 4 63 4. Media Behavior, Latching . . . . . . . . . . . . . . . . . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 8.2. Informative References . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 Network Address Translators (NATs) are widely used in the Internet by 75 consumers and organizations. Although specific NAT behaviors vary, 76 this document uses the term "NAT" for devices that map any IPv4 or 77 IPv6 address and transport port number to another IPv4 or IPv6 78 address and transport port number. This includes consumer NATs, 79 Firewall-NATs, IPv4-IPv6 NATs, Carrier-Grade NATs, etc. 81 Protocols like SIP [RFC3261], and others that try to use a more 82 direct path for media than with signalling, are difficult to use 83 across NATs. They use IP addresses and transport port numbers 84 encoded in bodies such as SDP [RFC4566] as well as, in the case of 85 SIP, various header fields. Such addresses and ports are unusable 86 unless all peers in a session are located behind the same NAT. 88 Mechanisms such as Session Traversal Utilities for NAT (STUN) 89 [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and 90 Interactive Connectivity Establishment (ICE) [RFC5245] did not exist 91 when protocols like SIP began being deployed. Session Border 92 Controllers (SBCs) that were already being used by SIP domains for 93 other SIP and media-related purposes began to use proprietary 94 mechanisms to enable SIP devices behind NATs to communicate across 95 the NATs. 97 The term often used for this behavior is Hosted NAT Traversal (HNT), 98 although some manufacturers sometimes use other names such as "Far- 99 end NAT Traversal" or "NAT assist" instead. The systems which 100 perform HNT are frequently SBCs as described in [RFC5853], although 101 other systems such as media gateways and "media proxies" sometimes 102 perform the same role. For the purposes of this document, all such 103 systems are referred to as SBCs, and the NAT traversal behavior is 104 called HNT. 106 As of this document's creation time, a vast majority of SIP domains 107 use HNT to enable SIP devices to communicate across NATs, despite the 108 publication of ICE. There are many reasons for this, but those 109 reasons are not relevant to this document's purpose and will not be 110 discussed. It is however worth pointing out that the current 111 deployment levels of HNT and NATs themselves make an exclusive 112 adoption of ICE highly unlikely in the foreseeable future. 114 The purpose of this document is to describe the mechanisms often used 115 for HNT at the SDP and media layer, in order to aid understanding the 116 implications and limitations imposed by it. Although the mechanisms 117 used in HNT are not novel to experts, publication in an IETF document 118 is useful as a means of providing common terminology and a reference 119 for related documents. 121 In no way does this document try to make a case for HNT or present it 122 as a solution that is somehow better than alternatives such as ICE. 123 The mechanisms described here, popular as they may be, are not 124 necessarily considered best practice or recommended operation. 126 It is also worth mentioning that there are purely signaling-layer 127 components of HNT as well. One such component is briefly described 128 for SIP in [RFC5853], but that is not the focus of this document. 129 The SIP signaling-layer component of HNT is typically more 130 implementation-specific and deployment-specific than the SDP and 131 media components. For the purposes of this document it is hence 132 assumed that signaling intermediaries handle traffic in way that 133 allows protocols such as SIP to function correctly across the NATs. 135 The rest of this document is going to focus primarily on use of HNT 136 for SIP. However, the mechanisms described here are relatively 137 generic and are often used with other protocols, such as XMPP 138 [RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], H.248/ 139 MEGACO [RFC3015], and H.323 [H.323]. 141 2. Background 143 The general problems with NAT traversal for protocols such as SIP 144 are: 146 1. The addresses and port numbers encoded in SDP bodies (or their 147 equivalents) by NATed User Agents (UAs) are not usable across the 148 Internet, because they represent the private network addressing 149 information of the UA rather than the addresses/ports that will 150 be mapped to/from by the NAT. 152 2. The policies inherent in NATs, and explicit in Firewalls, are 153 such that packets from outside the NAT cannot reach the UA until 154 the UA sends packet out first. 156 3. Some NATs apply endpoint dependent filtering on incoming packets, 157 as described in [RFC4787] and thus a UA may only be able to 158 receive packets from the same remote peer IP:port as it sends 159 packets out to. 161 In order to overcome these issues, signaling intermediaries such as 162 SIP SBCs on the public side of the NATs perform HNT for both 163 signaling and media. An example deployment model of HNT and SBCs is 164 shown in Figure 1. 166 +-----+ +-----+ 167 | SBC |-------| SBC | 168 +-----+ +-----+ 169 / \ 170 / Public Net \ 171 / \ 172 +-----+ +-----+ 173 |NAT-A| |NAT-B| 174 +-----+ +-----+ 175 / \ 176 / Private Net Private Net \ 177 / \ 178 +------+ +------+ 179 | UA-A | | UA-B | 180 +------+ +------+ 182 Figure 1: Logical Deployment Paths 184 3. Impact on Signaling 186 Along with codec and other media-layer information, session 187 establishment signaling also conveys, potentially private and non- 188 globally routable addressing information. Signaling intermediaries 189 would hence modify such information so that peer UAs are given the 190 (public) addressing information of a media relay controlled by the 191 intermediary. 193 Quite often, the IP address of the newly introduced media relay may 194 be the same as that of the signaling intermediary (e.g. the SIP SBC) 195 or it may be a completely different one. In almost all cases 196 however, the new address would belong to the same IP address family 197 as the one used for signaling, since it is known to work for that UA. 199 The port numbers introduced in the signaling by the intermediary are 200 typically allocated dynamically. Allocation strategies are entirely 201 implementation dependent and they often vary from one product to the 202 next. 204 The offer/answer media negotiation model [RFC3264] is such that once 205 an offer is sent, the generator of the offer needs to be prepared to 206 receive media on the advertised address/ports. In practice such 207 media may or may not be received, depending on the implementations 208 participating in a given session, local policies, and call scenario. 209 For example if a SIP SDP Offer originally came from a UA behind a 210 NAT, the SIP SBC cannot send media to it until an SDP Answer is given 211 to the UA and latching (Section 4) occurs. Another example is when a 212 SIP SBC sends an SDP Offer in a SIP INVITE to a residential 213 customer's UA and receives back SDP in a 18x response, the SBC may 214 decide not to send media to that customer UA until a SIP 200 response 215 for policy reasons, to prevent toll-fraud. 217 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 266 gone on and off hold). The reasons for such restrictions are 267 mostly related to security: once a session has started a user 268 agent is not expected to suddenly start streaming from a 269 different port without sending a new offer first. A change may 270 indicate an attempt to hijack the session. In some cases 271 however, a port change may be caused by a re-mapping in a NAT 272 device standing between the SBC and the UA. More advanced SBCs 273 may therefore allow some level of flexibility on the re-latching 274 restrictions while carefully considering the potential security 275 implications 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 | | | | 360 12. | | (XMPP server latches to | 361 | | src IP 203.0.113.4 and | 362 | | src port seen at (10)) | 363 | | | | 364 13. | | |<====== RTP ========| 365 | | | | 366 14. |<======RTP, to latched address=========| | 367 | | | | 369 Figure 3: Latching by a SIP SBC across two interfaces 371 The above is a general description, and some details vary between 372 implementations or configuration settings. For example, some 373 intermediaries perform additional logic before latching on received 374 packet source information to prevent malicious attacks or latching 375 erroneously to previous media senders - often called "rogue-rtp" in 376 the industry. 378 It is worth pointing out that latching is not an exclusively "server 379 affair" and some clients may also use it in cases where they are 380 configured with a public IP address and they are contacted by a NATed 381 client with no other NAT traversal means. 383 In order for latching to function correctly, the UA behind the NAT 384 needs to support symmetric RTP. That is, it needs to use the same 385 ports for sending data as the ones it listens on for inbound packets. 386 Today this is the case for with, for example, almost all SIP and XMPP 387 clients. Also UAs need to make sure they can begin sending media 388 packets independently and without waiting for packets to arrive 389 first. In theory, it is possible that some UAs would not send 390 packets out first; for example if a SIP session begins in 'inactive' 391 or 'recvonly' SDP mode from the UA behind the NAT. In practice, 392 however, SIP sessions from regular UAs (the kind that one could find 393 behind a NAT) virtually never begin an inactive or 'recvonly' mode, 394 for obvious reasons. The media direction would also be problematic 395 if the SBC side indicated 'inactive' or 'sendonly' modes when it sent 396 SDP to the UA. However SBCs providing HNT would always be configured 397 to avoid this. 399 Given that, in order for latching to work properly, media relays need 400 to begin receiving media before they start sending, it is possible 401 for deadlocks to occur. This can happen when the UAC and the UAS in 402 a session are connected to different signalling intermediaries that 403 both provide HNT. In this case the media relays controlled by the 404 signalling servers could end up each waiting upon the other to 405 initiate the streaming. To prevent this relays would often attempt 406 to start streaming toward the address:port sets provided in the offer 407 /answer even before receiving any inbound traffic. If the entity 408 they are streaming to is another HNT performing server it would have 409 provided its relay's public address and ports and the early stream 410 would find its target. 412 Although many SBCs only support UDP-based media latching, and in 413 particular RTP/RTCP, many SBCs support TCP-based media latching as 414 well. TCP-based latching is more complicated, and involves forcing 415 the UA behind the NAT to be the TCP client and sending the initial 416 SYN-flagged TCP packet to the SBC (i.e., be the 'active' mode side of 417 a TCP-based media session). If both UAs of a TCP-based media session 418 are behind NATs, then SBCs typically force both UAs to be the TCP 419 clients, and the SBC splices the TCP connections together. TCP 420 splicing is a well-known technique, and described in [tcp-splicing]. 422 HNT and latching in particular are generally found to be working 423 reliably but they do have obvious caveats. The first one usually 424 raised by IETF members is that UAs are not aware of it occurring. 425 This makes it impossible for the mechanism to be used with protocols 426 such as ICE that try various traversal techniques in an effort to 427 choose the one the best suits a particular situation. Overwriting 428 address information in in offers and answers may actually completely 429 prevent UAs from using ICE because of the ice-mismatch rules 430 described in [RFC5245] 432 The second issue raised by IETF members is that it causes media to go 433 through a relay instead of directly over the IP-routed path between 434 the two participating UAs. While this adds obvious drawbacks such as 435 reduced scalability and often increased latency, it is also 436 considered a benefit by SBC administrators: if a customer pays for 437 "phone" service, for example, the media is what is truly being paid 438 for, and the administrators usually like to be able to detect that 439 media is flowing correctly, evaluate its quality, know if and why it 440 failed, etc. Also in some cases routing media through operator 441 controlled relays may route media over paths explicitly optimized for 442 media and hence offer better performance than regular Internet 443 routing. 445 5. Security Considerations 447 A common concern is that an SBC that implements HNT may latch to 448 incorrect and possibly malicious sources. A malicious source could, 449 for example, attempt a resource exhaustion attack by flooding all 450 possible media-latching UDP ports on the SBC in order to prevent 451 calls from succeeding. SBCs have various mechanisms to prevent this 452 from happening, or alert an administrator when it does. Still, a 453 sufficiently sophisticated attacker may be able to bypass them for 454 some time. The most common example is typically referred to as 455 "restricted-latching", whereby the SBC will not latch to any packets 456 from a source public IP address other than the one the SIP UA uses 457 for SIP signaling. This way the SBC simply ignores and does not 458 latch onto packets coming from the attacker. In some cases the 459 limitation may be loosened to allow media from a range of IP 460 addresses belonging to the same network in order to allow for use 461 cases such as decomposed UAs and various forms of third party call 462 control. However, since relaxing the restrictions in such a way may 463 widen the gap for potential attackers, such configurations are 464 generally performed only on a case-by-case basis so that the 465 specifics of individual deployments would be taken into account. 467 In all of the above problems would still arise if the attacker knows 468 the public source IP of the UA that is actually making the call. 469 This would allow them to still flood all of the SBC's public IP 470 addresses and ports with packets spoofing that SIP UA's public source 471 IP address. However, this would only disturb media from that IP (or 472 range of IP addresses) rather than all calls that the SBC is 473 servicing. 475 A malicious source could send media packets to an SBC media-latching 476 UDP port in the hopes of being latched-to for the purpose of 477 receiving media for a given SIP session. SBCs have various 478 mechanisms to prevent this as well. Restricted latching for example 479 would also help in this case since the attacker can't make the SBC 480 send media packets back to themselves since the SBC will not latch 481 onto the attacker's packets. There could still be an issue if the 482 attacker happens to be either (1) in the IP routing path and thus can 483 spoof the same IP as the real UA and get the media coming back, in 484 which case the attacker hardly needs to attack at all to begin with, 485 or (2) the attacker is behind the same NAT as the legitimate SIP UA, 486 in which case the attacker's packets will be latched-to by the SBC 487 and the SBC will send media back to the attacker. In this latter 488 case, which may be of particular concern with carrier grade NATs, the 489 legitimate SIP UA will end the call anyway, because a human user 490 would not hear anything and will hang up. In the case of a non-human 491 call participant, such as an answering machine, this may not happen 492 (although many such automated UAs would also hang up when they do not 493 receive any media). The attacker could also redirect all media to 494 the real SIP UA after receiving it, in which case the attack would 495 likely remain undetected and succeed. Again, this would be of 496 particular concern with larger scale NATs serving many different 497 endpoints serving many different endpoints such as carrier grade 498 NATs. The larger the number of devices fronted by a NAT is, the more 499 use cases would vary and the more the number of possible attack 500 vectors would grow. 502 Naturally, SRTP [RFC3711] would help mitigate such threats and should 503 be used independently of HNT. For example, in cases where end-to-end 504 encryption is used it would still be possible for an attacker to 505 hijack a session despite the use of SRTP and perform a denial of 506 service attack. However, media integrity would not be compromised. 507 Additionally if the SBC that performs the latching is actually 508 participating in the SRTP key exchange then it would simply refuse to 509 latch onto a source unless it can authenticate it. 511 For SIP clients, HNT is usually transparent in the sense that the SIP 512 UA does not know it occurs. In certain cases it may be detectable, 513 such as when ICE is supported by the SIP UA and the SBC modifies the 514 default connection address and media port numbers in SDP, thereby 515 disabling ICE due to the mismatch condition. Even in that case, 516 however, the SIP UA only knows a middle box is relaying media, but 517 not necessarily that it is performing latching/HNT. 519 In order to perform HNT, the SBC has to modify SDP to and from the 520 SIP UA behind a NAT, and thus the SIP UA cannot use S/MIME [RFC5751], 521 and it cannot sign a sending request or verify a received request 522 using [RFC4474] unless the SBC re-signs the request. However it is 523 sometimes argued that, neither S/MIME nor [RFC4474] are widely 524 deployed and that this may not be a real concern. 526 From a privacy perspective, media relaying is sometimes seen as a way 527 of protecting one's IP address and not revealing it to the remote 528 party. That kind of IP address masking is often perceived as 529 important. However, this is no longer an exclusive advantage of HNT 530 since it can also be accomplished by client-controlled relaying 531 mechanisms such as TURN [RFC5766], if the client explicitly wishes to 532 do so. 534 6. IANA Considerations 536 This document has no actions for IANA. 538 Note to the RFC-Editor: please remove this section prior to 539 publication as an RFC. 541 7. Acknowledgements 543 The authors would like to thank Flemming Andreasen, Miguel A. 544 Garcia, Ari Keraenen and Paul Kyzivat for their reviews and 545 suggestions on improving this document. 547 8. References 549 8.1. Normative References 551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, March 1997. 554 8.2. Informative References 556 [H.323] International Telecommunication Union , "Packet Based 557 Multimedia Communication Systems", Recommendation H.323, 558 July 2003. 560 [RFC3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, 561 B., and J. Segers, "Megaco Protocol Version 1.0", RFC 562 3015, November 2000. 564 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 565 A., Peterson, J., Sparks, R., Handley, M., and E. 566 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 567 June 2002. 569 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 570 with Session Description Protocol (SDP)", RFC 3264, June 571 2002. 573 [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control 574 Protocol (MGCP) Version 1.0", RFC 3435, January 2003. 576 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 577 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 578 RFC 3711, March 2004. 580 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 581 Authenticated Identity Management in the Session 582 Initiation Protocol (SIP)", RFC 4474, August 2006. 584 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 585 Description Protocol", RFC 4566, July 2006. 587 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 588 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 589 RFC 4787, January 2007. 591 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 592 (ICE): A Protocol for Network Address Translator (NAT) 593 Traversal for Offer/Answer Protocols", RFC 5245, April 594 2010. 596 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 597 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 598 October 2008. 600 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 601 Mail Extensions (S/MIME) Version 3.2 Message 602 Specification", RFC 5751, January 2010. 604 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 605 Relays around NAT (TURN): Relay Extensions to Session 606 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 608 [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 609 A., and M. Bhatia, "Requirements from Session Initiation 610 Protocol (SIP) Session Border Control (SBC) Deployments", 611 RFC 5853, April 2010. 613 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 614 Protocol (XMPP): Core", RFC 6120, March 2011. 616 [XEP-0177] 617 Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan, 618 "XEP-0177: Jingle Raw UDP Transport Method", XEP XEP-0177, 619 December 2009. 621 Authors' Addresses 623 Emil Ivov 624 Jitsi 625 Strasbourg 67000 626 France 628 Email: emcho@jitsi.org 630 Hadriel Kaplan 631 Acme Packet 632 100 Crosby Drive 633 Bedford, MA 01730 634 USA 636 Email: hkaplan@acmepacket.com 638 Dan Wing 639 Cisco Systems, Inc. 640 170 West Tasman Drive 641 San Jose, CA 95134 642 USA 644 Email: dwing@cisco.com