idnits 2.17.1 draft-ietf-mmusic-latching-08.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 17, 2014) is 3594 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 19, 2014 Oracle 6 D. Wing 7 Cisco 8 June 17, 2014 10 Latching: Hosted NAT Traversal (HNT) for Media in Real-Time 11 Communication 12 draft-ietf-mmusic-latching-08 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 19, 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 uses numerous expressive primitives for message routing. As a 148 result, the HNT component for SIP is typically more implementation- 149 specific and deployment-specific than the SDP and media components. 150 For the purposes of this document it is hence assumed that signaling 151 intermediaries handle traffic in a way that allows protocols such as 152 SIP to function correctly across the NATs. 154 The rest of this document is going to focus primarily on use of HNT 155 for SIP. However, the mechanisms described here are relatively 156 generic and are often used with other protocols, such as XMPP 157 [RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], H.248/ 158 MEGACO [RFC5125], and H.323 [H.323]. 160 2. Background 162 The general problems with NAT traversal for protocols such as SIP 163 are: 165 1. The addresses and port numbers encoded in SDP bodies (or their 166 equivalents) by NATed User Agents (UAs) are not usable across the 167 Internet, because they represent the private network addressing 168 information of the UA rather than the addresses/ports that will 169 be mapped to/from by the NAT. 171 2. The policies inherent in NATs, and explicit in Firewalls, are 172 such that packets from outside the NAT cannot reach the UA until 173 the UA sends packets out first. 175 3. Some NATs apply endpoint dependent filtering on incoming packets, 176 as described in [RFC4787] and thus a UA may only be able to 177 receive packets from the same remote peer IP:port as it sends 178 packets out to. 180 In order to overcome these issues, signaling intermediaries such as 181 SIP SBCs on the public side of the NATs perform HNT for both 182 signaling and media. An example deployment model of HNT and SBCs is 183 shown in Figure 1. 185 +-----+ +-----+ 186 | SBC |-------| SBC | 187 +-----+ +-----+ 188 / \ 189 / Public Net \ 190 / \ 191 +-----+ +-----+ 192 |NAT-A| |NAT-B| 193 +-----+ +-----+ 194 / \ 195 / Private Net Private Net \ 196 / \ 197 +------+ +------+ 198 | UA-A | | UA-B | 199 +------+ +------+ 201 Figure 1: Signaling and Media Flows in a Common Deployment Scenario 203 3. Impact on Signaling 205 Along with codec and other media-layer information, session 206 establishment signaling also conveys, potentially private and non- 207 globally routable addressing information. Signaling intermediaries 208 would hence modify such information so that peer UAs are given the 209 (public) addressing information of a media relay controlled by the 210 intermediary. 212 In typical deployments, the media relay and signaling intermediary 213 (i.e., the SBC) are co-located, thereby sharing the same IP address. 214 Also, the address of the media relay would typically belong to the 215 same IP address family as the one used for signaling, as it is known 216 to work for that UA. In other words, signalling and media would 217 either both travel over IPv4 or IPv6. 219 The port numbers introduced in the signaling by the intermediary are 220 typically allocated dynamically. Allocation strategies are entirely 221 implementation dependent and they often vary from one product to the 222 next. 224 The offer/answer media negotiation model [RFC3264] is such that once 225 an offer is sent, the generator of the offer needs to be prepared to 226 receive media on the advertised address/ports. In practice such 227 media may or may not be received, depending on the implementations 228 participating in a given session, local policies, and call scenario. 229 For example if a SIP SDP Offer originally came from a UA behind a 230 NAT, the SIP SBC cannot send media to it until an SDP Answer is given 231 to the UA and latching (Section 4) occurs. Another example is when a 232 SIP SBC sends an SDP Offer in a SIP INVITE to a residential 233 customer's UA and receives back SDP in a 18x response, the SBC may 234 decide, for policy reasons, not to send media to that customer UA 235 until a SIP 200 response has been received (e.g., to prevent toll- 236 fraud). 238 4. Media Behavior, Latching 240 An UA that is behind a NAT would stream media from an address and a 241 port number (an address:port tuple) that are only valid in its local 242 network. Once packets cross the NAT, that address:port tuple will be 243 mapped to a public one. The UA however is not typically aware of the 244 public mapping and would often advertise the private address:port 245 tuple in signaling. This way, while a session is still being setup, 246 the signaling intermediary is not yet aware what addresses and ports 247 the caller and the callee would end up using for media traffic: it 248 has only seen them advertise the private addresses they use behind 249 their respective NATs. Therefore media relays used in HNT would 250 often use a mechanism called "latching". 252 Historically, "latching" only referred to the process by which SBCs 253 "latch" onto UDP packets from a given UA for security purposes, and 254 "symmetric-latching" is when the latched address:port tuples are used 255 to send media back to the UA. Today most people talk about them both 256 as "latching", and thus this document does as well. 258 The latching mechanism works as follows: 260 1. After receiving an offer from Alice (UAC located behind a NAT), a 261 signaling intermediary located on the public Internet would 262 allocate a set of IP address:port tuples on a media relay. The 263 set would then be advertised to Bob (UAS) so that he would use 264 those media relay address:port tuples for all media it wished to 265 send toward Alice (UAC). 267 2. Next, after receiving from Bob (UAS) an answer to its offer, the 268 signaling server would allocate a second address:port set on the 269 media relay. In it's the answer to Alice (UAC) the SBC will 270 replace Bob's address:port with this second set. This way Alice 271 will send media to this media relay address:port. 273 3. The media relay receives the media packets on the allocated 274 ports, and uses their respective source address:ports as a 275 destination for all media bound in the opposite direction. In 276 other words, it "latches" or locks on these source address:port 277 tuple. 279 4. This way, when Alice (UAC) streams media toward the media relay, 280 it would be received on the second address:port tuple. The 281 source address:port of her traffic would belong to the public 282 interface of Alice's NAT and anything that the relay sends back 283 to that address:port, would find its way to Alice. 285 5. Similarly the source of the media packets that Bob (UAS) is 286 sending would be latched upon and used for media going in that 287 direction. 289 6. Latching is usually done only once per peer and not allowed to 290 change or cause a re-latching until a new offer and answer get 291 exchanged (e.g., in a subsequent call or after a SIP peer has 292 gone on and off hold). The reasons for such restrictions are 293 mostly related to security: once a session has started a user 294 agent is not expected to suddenly start streaming from a 295 different port without sending a new offer first. A change may 296 indicate an attempt to hijack the session. In some cases 297 however, a port change may be caused by a re-mapping in a NAT 298 device standing between the SBC and the UA. More advanced SBCs 299 may therefore allow some level of flexibility on the re-latching 300 restrictions while carefully considering the potential security 301 implications of doing so. 303 Figure 2 describes how latching occurs for SIP where HNT is provided 304 by an SBC connected to two networks: 203.0.113/24 facing towards the 305 User Agent Client (UAC) network and 198.51.100/24 facing towards the 306 User Agent Server (UAS) network. 308 192.0.2.1 192.0.2.9/203.0.113.4 198.51.100.33 309 Alice NAT 203.0.113.9-SBC-198.51.100.2 Bob 310 ------- --- --- ------- 311 | | | | 312 1. |--SIP INVITE+offer c=192.0.2.1--->| | 313 | | | | 314 2. | | (SBC allocates 198.51.100.2:22007 | 315 | | for inbound RTP from Bob) | 316 | | | | 317 3. | | |-----INVITE+offer----->| 318 | | | c=198.51.100.2:22007 | 319 | | | | 320 4. | | |<------180 Ringing-----| 321 | | | | 322 | | | | 323 5. |<------180 Ringing----------------| | 324 | | | | 325 6. | | |<------200+answer------| 326 | | | | 327 7. | | (SBC allocates 203.0.113.9:36010 | 328 | | for inbound RTP from Alice) | 329 | | | | 330 8. |<-200+answer,c=203.0.113.9:36010--| c=198.51.100.33 | 331 | | | | 332 9. |------------ACK------------------>| | 333 10. | | |----------ACK--------->| 334 | | | | 335 11. |=====RTP,dest=203.0.113.9:36010==>| | 336 | | | | 337 12. | | (SBC latches to | 338 | | source IP address and | 339 | | port seen at (11)) | 340 | | | | 341 13. | | |<======= RTP ==========| 342 | | |dest:198.51.100.2:22007| 343 14. |<=====RTP, to latched address=====| | 344 | | | | 346 Figure 2: Latching by a SIP SBC across two interfaces 348 While XMPP implementations often rely on ICE to handle NAT traversal, 349 there are some that also support a non-ICE transport called XMPP 350 Jingle Raw UDP Transport Method [XEP-0177]. Figure 3 describes how 351 latching occurs for one such XMPP implementation where HNT is 352 provided by an XMPP server on the public internet. 354 192.0.2.1 192.0.2.9/203.0.113.4 203.0.113.9 198.51.100.8 355 Romeo NAT XMPP Server Juliet 356 ----- --- --- ----- 357 | | | | 358 1. |----session-initiate cand=192.0.2.1--->| | 359 | | | | 360 2. |<------------ack-----------------------| | 361 | | | | 362 3. | | (Server allocates 203.0.113.9:2200 | 363 | | for inbound RTP from Juliet) | 364 | | | | 365 4. | | |--session-initiate-->| 366 | | |cand=203.0.113.9:2200| 367 | | | | 368 5. | | |<--------ack---------| 369 | | | | 370 | | | | 371 6. | | |<---session-accept---| 372 | | | cand=198.51.100.8 | 373 | | | | 374 7. | | |---------ack-------->| 375 | | | | 376 8. | | (Server allocates 203.0.113.9:3300 | 377 | | for inbound RTP from Romeo) | 378 | | | | 379 9. |<-session-accept cand=203.0.113.9:3300-| | 380 | | | | 381 10. |-----------------ack------------------>| | 382 | | | | 383 | | | | 384 11. |======RTP, dest=203.0.113.9:3300======>| | 385 | | | | 386 12. | | (XMPP server latches to | 387 | | src IP 203.0.113.4 and | 388 | | src port seen at (11)) | 389 | | | | 390 13. | | |<======= RTP ========| 391 | | |dest=203.0.113.9:2200| 392 14. |<======RTP, to latched address=========| | 393 | | | | 395 Figure 3: Latching by an XMPP server across two interfaces 397 The above is a general description, and some details vary between 398 implementations or configuration settings. For example, some 399 intermediaries perform additional logic before latching on received 400 packet source information to prevent malicious attacks or latching 401 erroneously to previous media senders - often called "rogue-rtp" in 402 the industry. 404 It is worth pointing out that latching is not an exclusively "server 405 affair" and some clients may also use it in cases where they are 406 configured with a public IP address and they are contacted by a NATed 407 client with no other NAT traversal means. 409 In order for latching to function correctly, the UA behind the NAT 410 needs to support symmetric RTP. That is, it needs to use the same 411 ports for sending data as the ones it listens on for inbound packets. 412 Today this is the case for with, for example, almost all SIP and XMPP 413 clients. Also UAs need to make sure they can begin sending media 414 packets independently and without waiting for packets to arrive 415 first. In theory, it is possible that some UAs would not send 416 packets out first; for example if a SIP session begins in 'inactive' 417 or 'recvonly' SDP mode from the UA behind the NAT. In practice, 418 however, SIP sessions from regular UAs (the kind that one could find 419 behind a NAT) virtually never begin an inactive or 'recvonly' mode, 420 for obvious reasons. The media direction would also be problematic 421 if the SBC side indicated 'inactive' or 'sendonly' modes when it sent 422 SDP to the UA. However SBCs providing HNT would always be configured 423 to avoid this. 425 Given that, in order for latching to work properly, media relays need 426 to begin receiving media before they start sending, it is possible 427 for deadlocks to occur. This can happen when the UAC and the UAS in 428 a session are connected to different signaling intermediaries that 429 both provide HNT. In this case the media relays controlled by the 430 signaling servers could end up each waiting upon the other to 431 initiate the streaming. To prevent this relays would often attempt 432 to start streaming toward the address:port tuples provided in the 433 offer/answer even before receiving any inbound traffic. If the 434 entity they are streaming to is another HNT performing server it 435 would have provided its relay's public address and ports and the 436 early stream would find its target. 438 Although many SBCs only support UDP-based media latching, and in 439 particular RTP/RTCP, many SBCs support TCP-based media latching as 440 well. TCP-based latching is more complicated, and involves forcing 441 the UA behind the NAT to be the TCP client and sending the initial 442 SYN-flagged TCP packet to the SBC (i.e., be the 'active' mode side of 443 a TCP-based media session). If both UAs of a TCP-based media session 444 are behind NATs, then SBCs typically force both UAs to be the TCP 445 clients, and the SBC splices the TCP connections together. TCP 446 splicing is a well-known technique, as described in [tcp-splicing]. 448 HNT and latching in particular are generally found to be working 449 reliably but they do have obvious caveats. The first one usually 450 raised by IETF participants is that UAs are not aware of it 451 occurring. This makes it impossible for the mechanism to be used 452 with protocols such as ICE that try various traversal techniques in 453 an effort to choose the one that best suits a particular situation. 454 Overwriting address information in offers and answers may actually 455 completely prevent UAs from using ICE because of the ice-mismatch 456 rules described in [RFC5245] 458 The second issue raised by IETF participants is that it causes media 459 to go through a relay instead of directly over the IP-routed path 460 between the two participating UAs. While this adds obvious drawbacks 461 such as reduced scalability and often increased latency, it is also 462 considered a benefit by SBC administrators: if a customer pays for 463 "phone" service, for example, the media is what is truly being paid 464 for, and the administrators usually like to be able to detect that 465 media is flowing correctly, evaluate its quality, know if and why it 466 failed, etc. Also in some cases routing media through operator 467 controlled relays may route media over paths explicitly optimized for 468 media and hence offer better performance than regular Internet 469 routing. 471 5. Security Considerations 473 A common concern is that an SBC (or an XMPP server, all security 474 considerations apply to both) that implements HNT may latch to 475 incorrect and possibly malicious sources. The ICE [RFC5245] protocol 476 for example, provides authentication tokens (conveyed in the ice- 477 ufrag and ice-pwd attributes) that allow the identity of a peer to be 478 confirmed before engaging in media exchange with her. Without such 479 authentication, a malicious source could, for example, attempt a 480 resource exhaustion attack by flooding all possible media-latching 481 UDP ports on the SBC in order to prevent calls from succeeding. SBCs 482 have various mechanisms to prevent this from happening, or alert an 483 administrator when it does. Still, a sufficiently sophisticated 484 attacker may be able to bypass them for some time. The most common 485 example is typically referred to as "restricted-latching", whereby 486 the SBC will not latch to any packets from a source public IP address 487 other than the one the SIP UA uses for SIP signaling. This way the 488 SBC simply ignores and does not latch onto packets coming from the 489 attacker. In some cases the limitation may be loosened to allow 490 media from a range of IP addresses belonging to the same network in 491 order to allow for use cases such as decomposed UAs and various forms 492 of third party call control. However, since relaxing the 493 restrictions in such a way may provide attackers with a larger attack 494 surface, such configurations are generally performed only on a case- 495 by-case basis so that the specifics of individual deployments would 496 be taken into account. 498 All of the above problems would still arise if the attacker knows the 499 public source IP of the UA that is actually making the call. This 500 would allow them to still flood all of the SBC's public IP addresses 501 and ports with packets spoofing that SIP UA's public source IP 502 address. However, this would only impact media from that IP (or 503 range of IP addresses) rather than all calls that the SBC is 504 servicing. 506 A malicious source could send media packets to an SBC media-latching 507 UDP port in the hopes of being latched-to for the purpose of 508 receiving media for a given SIP session. SBCs have various 509 mechanisms to prevent this as well. Restricted latching for example 510 would also help in this case since the attacker can't make the SBC 511 send media packets back to themselves since the SBC will not latch 512 onto the attacker's media packets, not having seen the corresponding 513 signaling packets first. There could still be an issue if the 514 attacker happens to be either (1) in the IP routing path and thus can 515 spoof the same IP as the real UA and get the media coming back, in 516 which case the attacker hardly needs to attack at all to begin with, 517 or (2) the attacker is behind the same NAT as the legitimate SIP UA, 518 in which case the attacker's packets will be latched-to by the SBC 519 and the SBC will send media back to the attacker. In this latter 520 case, which may be of particular concern with Carrier-Grade NATs, the 521 legitimate SIP UA will likely end the call anyway when a human user 522 who does not hear anything hangs up. In the case of a non-human call 523 participant, such as an answering machine, this may not happen 524 (although many such automated UAs would also hang up when they do not 525 receive any media). The attacker could also redirect all media to 526 the real SIP UA after receiving it, in which case the attack would 527 likely remain undetected and succeed. Again, this would be of 528 particular concern with larger scale NATs serving many different 529 endpoints such as Carrier-Grade NATs. The larger the number of 530 devices fronted by a NAT is, the more use cases would vary and the 531 more the number of possible attack vectors would grow. 533 Naturally, SRTP [RFC3711] would help mitigate such threats and, if 534 used with the appropriate key negotiation mechanisms, would protect 535 the media from monitoring while in transit. It should therefore be 536 used independently of HNT. [RFC3261] Section 26 provides an overview 537 of additional threats and solutions on monitoring and session 538 interception. 540 With SRTP, if the SBC that performs the latching is actually 541 participating in the SRTP key exchange, then it would simply refuse 542 to latch onto a source unless it can authenticate it. Failing to 543 implement and use SRTP would represent a serious threat to users 544 connecting from behind Carrier-Grade NATs [RFC6888] and is considered 545 a harmful practice. 547 For SIP clients, HNT is usually transparent in the sense that the SIP 548 UA does not know it occurs. In certain cases it may be detectable, 549 such as when ICE is supported by the SIP UA and the SBC modifies the 550 default connection address and media port numbers in SDP, thereby 551 disabling ICE due to the mismatch condition. Even in that case, 552 however, the SIP UA only knows a middle box is relaying media, but 553 not necessarily that it is performing latching/HNT. 555 In order to perform HNT, the SBC has to modify SDP to and from the 556 SIP UA behind a NAT, and thus the SIP UA cannot use S/MIME [RFC5751], 557 and it cannot sign a sending request or verify a received request 558 using [RFC4474] unless the SBC re-signs the request. However, 559 neither S/MIME or [RFC4474] are widely deployed, thus not being able 560 to sign/verify requests appear not to be a concern at this 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, Alissa Cooper, Vijay K. Gurbani, Ari Keranen and Paul 581 Kyzivat for their reviews and 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