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