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