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