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