summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7362.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7362.txt')
-rw-r--r--doc/rfc/rfc7362.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc7362.txt b/doc/rfc/rfc7362.txt
new file mode 100644
index 0000000..3a4d615
--- /dev/null
+++ b/doc/rfc/rfc7362.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) E. Ivov
+Request for Comments: 7362 Jitsi
+Category: Informational H. Kaplan
+ISSN: 2070-1721 Oracle
+ D. Wing
+ Cisco
+ September 2014
+
+
+ Latching: Hosted NAT Traversal (HNT)
+ for Media in Real-Time Communication
+
+Abstract
+
+ This document describes the behavior of signaling intermediaries in
+ Real-Time Communication (RTC) deployments, sometimes referred to as
+ Session Border Controllers (SBCs), when performing Hosted NAT
+ Traversal (HNT). HNT is a set of mechanisms, such as media relaying
+ and latching, that such intermediaries use to enable other RTC
+ devices behind NATs to communicate with each other.
+
+ This document is non-normative and is only written to explain HNT in
+ order to provide a reference to the Internet community and an
+ informative description to manufacturers and users.
+
+ Latching, which is one of the HNT components, has a number of
+ security issues covered here. Because of those, and unless all
+ security considerations explained here are taken into account and
+ solved, the IETF advises against use of the latching mechanism over
+ the Internet and recommends other solutions, such as the Interactive
+ Connectivity Establishment (ICE) protocol.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7362.
+
+
+
+
+Ivov, et al. Informational [Page 1]
+
+RFC 7362 Hosted NAT Traversal for Media in RTC September 2014
+
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 5
+ 4. Media Behavior and Latching . . . . . . . . . . . . . . . . . 6
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . 14
+ 7.2. Informative References . . . . . . . . . . . . . . . . . 14
+
+1. Introduction
+
+ Network Address Translators (NATs) are widely used in the Internet by
+ consumers and organizations. Although specific NAT behaviors vary,
+ this document uses the term "NAT" for devices that map any IPv4 or
+ IPv6 address and transport port number to another IPv4 or IPv6
+ address and transport port number. This includes consumer NATs,
+ firewall/NATs, IPv4-IPv6 NATs, Carrier-Grade NATs (CGNs) [RFC6888],
+ etc.
+
+ The Session Initiation Protocol (SIP) [RFC3261], and others that try
+ to use a more direct path for media than with signaling, are
+ difficult to use across NATs. These protocols use IP addresses and
+ transport port numbers encoded in bodies such as the Session
+ Description Protocol (SDP) [RFC4566] and, in the case of SIP, various
+ header fields. Such addresses and ports are unusable unless all
+ peers in a session are located behind the same NAT.
+
+ Mechanisms such as Session Traversal Utilities for NAT (STUN)
+ [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and
+ Interactive Connectivity Establishment (ICE) [RFC5245] did not exist
+
+
+
+Ivov, et al. Informational [Page 2]
+
+RFC 7362 Hosted NAT Traversal for Media in RTC September 2014
+
+
+ when protocols like SIP began being deployed. Some mechanisms, such
+ as the early versions of STUN [RFC3489], had started appearing, but
+ they were unreliable and suffered a number of issues typical for
+ UNilateral Self-Address Fixing (UNSAF), as described in [RFC3424].
+ For these and other reasons, Session Border Controllers (SBCs) that
+ were already being used by SIP domains for other SIP and media-
+ related purposes began to use proprietary mechanisms to enable SIP
+ devices behind NATs to communicate across the NATs. These mechanisms
+ are often transparent to endpoints and rely on a dynamic address and
+ port discovery technique called "latching".
+
+ The term often used for this behavior is "Hosted NAT Traversal
+ (HNT)"; a number of manufacturers sometimes use other names such as
+ "Far-end NAT Traversal" or "NAT assist" instead. The systems that
+ perform HNT are frequently SBCs as described in [RFC5853], although
+ other systems such as media gateways and "media proxies" sometimes
+ perform the same role. For the purposes of this document, all such
+ systems are referred to as SBCs and the NAT traversal behavior is
+ called HNT.
+
+ At the time of this document's publication, a vast majority of SIP
+ domains use HNT to enable SIP devices to communicate across NATs
+ despite the publication of ICE. There are many reasons for this, but
+ those reasons are not relevant to this document's purpose and will
+ not be discussed. It is, however, worth pointing out that the
+ current deployment levels of HNT and NATs make the complete
+ extinction of this practice highly unlikely in the foreseeable
+ future.
+
+ The purpose of this document is to describe the mechanisms often used
+ for HNT at the SDP and media layer in order to aid understanding the
+ implications and limitations imposed by it. Although the mechanisms
+ used in HNT are well known in the community, publication in an IETF
+ document is useful as a means of providing common terminology and a
+ reference for related documents.
+
+ This document does not attempt to make a case for HNT or present it
+ as a solution that is somehow better than alternatives such as ICE.
+ Due to the security issues presented in Section 5, the latching
+ mechanism is considered inappropriate for general use on the Internet
+ unless all security considerations are taken into account and solved.
+ The IETF is instead advising for the use of the Interactive
+ Connectivity Establishment (ICE) [RFC5245] and Traversal Using Relays
+ around NAT (TURN) [RFC5766] protocols.
+
+ It is also worth mentioning that there are purely signaling-layer
+ components of HNT as well. One such component is briefly described
+ for SIP in [RFC5853], but that is not the focus of this document.
+
+
+
+Ivov, et al. Informational [Page 3]
+
+RFC 7362 Hosted NAT Traversal for Media in RTC September 2014
+
+
+ SIP uses numerous expressive primitives for message routing. As a
+ result, the HNT component for SIP is typically more implementation-
+ specific and deployment-specific than the SDP and media components.
+ For the purposes of this document it is hence assumed that signaling
+ intermediaries handle traffic in a way that allows protocols such as
+ SIP to function correctly across the NATs.
+
+ The rest of this document focuses primarily on the use of HNT for
+ SIP. However, the mechanisms described here are relatively generic
+ and are often used with other protocols such as the Extensible
+ Messaging and Presence Protocol (XMPP) [RFC6120], Media Gateway
+ Control Protocol (MGCP) [RFC3435], Megaco/H.248 [RFC5125], and H.323
+ [H.323].
+
+2. Background
+
+ The general problems with NAT traversal for protocols such as SIP
+ are:
+
+ 1. The addresses and port numbers encoded in SDP bodies (or their
+ equivalents) by NATed User Agents (UAs) are not usable across the
+ Internet because they represent the private network addressing
+ information of the UA rather than the addresses/ports that will
+ be mapped to/from by the NAT.
+
+ 2. The policies inherent in NATs, and explicit in firewalls, are
+ such that packets from outside the NAT cannot reach the UA until
+ the UA sends packets out first.
+
+ 3. Some NATs apply endpoint-dependent filtering on incoming packets,
+ as described in [RFC4787]; thus, a UA may only be able to receive
+ packets from the same remote peer IP:port as it sends packets out
+ to.
+
+ In order to overcome these issues, signaling intermediaries such as
+ SIP SBCs on the public side of the NATs perform HNT for both
+ signaling and media. An example deployment model of HNT and SBCs is
+ shown in Figure 1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ivov, et al. Informational [Page 4]
+
+RFC 7362 Hosted NAT Traversal for Media in RTC September 2014
+
+
+ +-----+ +-----+
+ | SBC |-------| SBC |
+ +-----+ +-----+
+ / \
+ / Public Net \
+ / \
+ +-----+ +-----+
+ |NAT-A| |NAT-B|
+ +-----+ +-----+
+ / \
+ / Private Net Private Net \
+ / \
+ +------+ +------+
+ | UA-A | | UA-B |
+ +------+ +------+
+
+ Figure 1: Signaling and Media Flows in a Common Deployment Scenario
+
+3. Impact on Signaling
+
+ Along with codec and other media-layer information, session
+ establishment signaling also conveys potentially private and non-
+ globally routable addressing information. Signaling intermediaries
+ would hence modify such information so that peer UAs are given the
+ (public) addressing information of a media relay controlled by the
+ intermediary.
+
+ In typical deployments, the media relay and signaling intermediary
+ (i.e., the SBC) are co-located, thereby sharing the same IP address.
+ Also, the address of the media relay would typically belong to the
+ same IP address family as the one used for signaling (as it is known
+ to work for that UA). In other words, signaling and media would both
+ travel over either IPv4 or IPv6.
+
+ The port numbers introduced in the signaling by the intermediary are
+ typically allocated dynamically. Allocation strategies are entirely
+ implementation dependent and they often vary from one product to the
+ next.
+
+ The offer/answer media negotiation model [RFC3264] is such that once
+ an offer is sent, the generator of the offer needs to be prepared to
+ receive media on the advertised address/ports. In practice, such
+ media may or may not be received depending on the implementations
+ participating in a given session, local policies, and the call
+ scenario. For example, if a SIP SDP offer originally came from a UA
+ behind a NAT, the SIP SBC cannot send media to it until an SDP answer
+ is given to the UA and latching (Section 4) occurs. Another example
+ is, when a SIP SBC sends an SDP offer in a SIP INVITE to a
+
+
+
+Ivov, et al. Informational [Page 5]
+
+RFC 7362 Hosted NAT Traversal for Media in RTC September 2014
+
+
+ residential customer's UA and receives back SDP in a 18x response,
+ the SBC may decide, for policy reasons, not to send media to that
+ customer UA until a SIP 200 response has been received (e.g., to
+ prevent toll fraud).
+
+4. Media Behavior and Latching
+
+ An UA that is behind a NAT would stream media from an address and a
+ port number (an address:port tuple) that are only valid in its local
+ network. Once packets cross the NAT, that address:port tuple will be
+ mapped to a public one. The UA, however, is not typically aware of
+ the public mapping and would often advertise the private address:port
+ tuple in signaling. This way, while a session is still being set up,
+ the signaling intermediary is not yet aware what addresses and ports
+ the caller and the callee would end up using for media traffic: it
+ has only seen them advertise the private addresses they use behind
+ their respective NATs. Therefore, media relays used in HNT would
+ often use a mechanism called "latching".
+
+ Historically, "latching" only referred to the process by which SBCs
+ "latch" onto UDP packets from a given UA for security purposes, and
+ "symmetric-latching" is when the latched address:port tuples are used
+ to send media back to the UA. Today, most people talk about them
+ both as "latching"; thus, this document does as well.
+
+ The latching mechanism works as follows:
+
+ 1. After receiving an offer from Alice (User Agent Client (UAC)
+ located behind a NAT), a signaling intermediary located on the
+ public Internet would allocate a set of IP address:port tuples on
+ a media relay. The set would then be advertised to Bob (User
+ Agent Server (UAS)) so that he would use those media relay
+ address:port tuples for all media he wished to send toward Alice
+ (UAC).
+
+ 2. Next, after receiving from Bob (UAS) an answer to its offer, the
+ signaling server would allocate a second address:port set on the
+ media relay. In its answer to Alice (UAC), the SBC will replace
+ Bob's address:port with this second set. This way, Alice will
+ send media to this media relay address:port.
+
+ 3. The media relay receives the media packets on the allocated ports
+ and uses their respective source address:ports as a destination
+ for all media bound in the opposite direction. In other words,
+ it "latches" or locks on these source address:port tuples.
+
+
+
+
+
+
+Ivov, et al. Informational [Page 6]
+
+RFC 7362 Hosted NAT Traversal for Media in RTC September 2014
+
+
+ 4. This way, when Alice (UAC) streams media toward the media relay,
+ it would be received on the second address:port tuple. The
+ source address:port of her traffic would belong to the public
+ interface of Alice's NAT, and anything that the relay sends back
+ to that address:port would find its way to Alice.
+
+ 5. Similarly, the source of the media packets that Bob (UAS) is
+ sending would be latched upon and used for media going in that
+ direction.
+
+ 6. Latching is usually done only once per peer and not allowed to
+ change or cause a re-latching until a new offer and answer get
+ exchanged (e.g., in a subsequent call or after a SIP peer has
+ gone on and off hold). The reasons for such restrictions are
+ mostly related to security: once a session has started, a user
+ agent is not expected to suddenly start streaming from a
+ different port without sending a new offer first. A change may
+ indicate an attempt to hijack the session. In some cases,
+ however, a port change may be caused by a re-mapping in a NAT
+ device standing between the SBC and the UA. More advanced SBCs
+ may therefore allow some level of flexibility on the re-latching
+ restrictions while carefully considering the potential security
+ implications of doing so.
+
+ Figure 2 describes how latching occurs for SIP where HNT is provided
+ by an SBC connected to two networks: 203.0.113/24 facing towards the
+ UAC network and 198.51.100/24 facing towards the UAS network.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ivov, et al. Informational [Page 7]
+
+RFC 7362 Hosted NAT Traversal for Media in RTC September 2014
+
+
+ 192.0.2.1 192.0.2.9/203.0.113.4 198.51.100.33
+ Alice NAT 203.0.113.9-SBC-198.51.100.2 Bob
+ ------- --- --- -------
+ | | | |
+ 1. |--SIP INVITE+offer c=192.0.2.1--->| |
+ | | | |
+ 2. | | (SBC allocates 198.51.100.2:22007 |
+ | | for inbound RTP from Bob) |
+ | | | |
+ 3. | | |-----INVITE+offer----->|
+ | | | c=198.51.100.2:22007 |
+ | | | |
+ 4. | | |<------180 Ringing-----|
+ | | | |
+ | | | |
+ 5. |<------180 Ringing----------------| |
+ | | | |
+ 6. | | |<------200+answer------|
+ | | | |
+ 7. | | (SBC allocates 203.0.113.9:36010 |
+ | | for inbound RTP from Alice) |
+ | | | |
+ 8. |<-200+answer,c=203.0.113.9:36010--| c=198.51.100.33 |
+ | | | |
+ 9. |------------ACK------------------>| |
+ 10. | | |----------ACK--------->|
+ | | | |
+ 11. |=====RTP,dest=203.0.113.9:36010==>| |
+ | | | |
+ 12. | | (SBC latches to |
+ | | source IP address and |
+ | | port seen at (11)) |
+ | | | |
+ 13. | | |<======= RTP ==========|
+ | | |dest:198.51.100.2:22007|
+ 14. |<=====RTP, to latched address=====| |
+ | | | |
+
+
+ Figure 2: Latching by a SIP SBC across Two Interfaces
+
+ While XMPP implementations often rely on ICE to handle NAT traversal,
+ there are some that also support a non-ICE transport called XMPP
+ Jingle Raw UDP Transport Method [XEP-0177]. Figure 3 describes how
+ latching occurs for one such XMPP implementation where HNT is
+ provided by an XMPP server on the public Internet.
+
+
+
+
+
+Ivov, et al. Informational [Page 8]
+
+RFC 7362 Hosted NAT Traversal for Media in RTC September 2014
+
+
+ 192.0.2.1 192.0.2.9/203.0.113.4 203.0.113.9 198.51.100.8
+ Romeo NAT XMPP Server Juliet
+ ----- --- --- -----
+ | | | |
+ 1. |----session-initiate cand=192.0.2.1--->| |
+ | | | |
+ 2. |<------------ack-----------------------| |
+ | | | |
+ 3. | | (Server allocates 203.0.113.9:2200 |
+ | | for inbound RTP from Juliet) |
+ | | | |
+ 4. | | |--session-initiate-->|
+ | | |cand=203.0.113.9:2200|
+ | | | |
+ 5. | | |<--------ack---------|
+ | | | |
+ | | | |
+ 6. | | |<---session-accept---|
+ | | | cand=198.51.100.8 |
+ | | | |
+ 7. | | |---------ack-------->|
+ | | | |
+ 8. | | (Server allocates 203.0.113.9:3300 |
+ | | for inbound RTP from Romeo) |
+ | | | |
+ 9. |<-session-accept cand=203.0.113.9:3300-| |
+ | | | |
+ 10. |-----------------ack------------------>| |
+ | | | |
+ | | | |
+ 11. |======RTP, dest=203.0.113.9:3300======>| |
+ | | | |
+ 12. | | (XMPP server latches to |
+ | | src IP 203.0.113.4 and |
+ | | src port seen at (11)) |
+ | | | |
+ 13. | | |<======= RTP ========|
+ | | |dest=203.0.113.9:2200|
+ 14. |<======RTP, to latched address=========| |
+ | | | |
+
+
+ Figure 3: Latching by an XMPP Server across Two Interfaces
+
+ The above is a general description, and some details vary between
+ implementations or configuration settings. For example, some
+ intermediaries perform additional logic before latching on received
+
+
+
+
+Ivov, et al. Informational [Page 9]
+
+RFC 7362 Hosted NAT Traversal for Media in RTC September 2014
+
+
+ packet source information to prevent malicious attacks or latching
+ erroneously to previous media senders -- often called "rogue-rtp" in
+ the industry.
+
+ It is worth pointing out that latching is not exclusively a "server
+ affair", and some clients may also use it in cases where they are
+ configured with a public IP address and are contacted by a NATed
+ client with no other NAT traversal means.
+
+ In order for latching to function correctly, the UA behind the NAT
+ needs to support symmetric RTP. That is, it needs to use the same
+ ports for sending data as the ones it listens on for inbound packets.
+ Today, this is the case with almost all SIP and XMPP clients. Also,
+ UAs need to make sure they can begin sending media packets
+ independently without waiting for packets to arrive first. In
+ theory, it is possible that some UAs would not send packets out
+ first, for example, if a SIP session begins in 'inactive' or
+ 'recvonly' SDP mode from the UA behind the NAT. In practice,
+ however, SIP sessions from regular UAs (the kind that one could find
+ behind a NAT) virtually never begin in 'inactive' or 'recvonly' mode,
+ for obvious reasons. The media direction would also be problematic
+ if the SBC side indicated 'inactive' or 'sendonly' modes when it sent
+ SDP to the UA. However, SBCs providing HNT would always be
+ configured to avoid this.
+
+ Given that, in order for latching to work properly, media relays need
+ to begin receiving media before they start sending, it is possible
+ for deadlocks to occur. This can happen when the UAC and the UAS in
+ a session are connected to different signaling intermediaries that
+ both provide HNT. In this case, the media relays controlled by the
+ signaling servers could end up each waiting upon the other to
+ initiate the streaming. To prevent this, relays would often attempt
+ to start streaming toward the address:port tuples provided in the
+ offer/answer even before receiving any inbound traffic. If the
+ entity they are streaming to is another HNT performing server, it
+ would have provided its relay's public address and ports, and the
+ early stream would find its target.
+
+ Although many SBCs only support UDP-based media latching (in
+ particular, RTP/RTCP), many SBCs support TCP-based media latching as
+ well. TCP-based latching is more complicated; it involves forcing
+ the UA behind the NAT to be the TCP client and sending the initial
+ SYN-flagged TCP packet to the SBC (i.e., be the 'active' mode side of
+ a TCP-based media session). If both UAs of a TCP-based media session
+ are behind NATs, then SBCs typically force both UAs to be the TCP
+ clients, and the SBC splices the TCP connections together. TCP
+ splicing is a well-known technique, as described in [TCP-SPLICING].
+
+
+
+
+Ivov, et al. Informational [Page 10]
+
+RFC 7362 Hosted NAT Traversal for Media in RTC September 2014
+
+
+ HNT and latching, in particular, are generally found to work
+ reliably, but they do have obvious caveats. The first one usually
+ raised by IETF participants is that UAs are not aware of it
+ occurring. This makes it impossible for the mechanism to be used
+ with protocols such as ICE that try various traversal techniques in
+ an effort to choose the one that best suits a particular situation.
+ Overwriting address information in offers and answers may actually
+ completely prevent UAs from using ICE because of the ice-mismatch
+ rules described in [RFC5245].
+
+ The second issue raised by IETF participants is that it causes media
+ to go through a relay instead of directly over the IP-routed path
+ between the two participating UAs. While this adds obvious drawbacks
+ such as reduced scalability and increased latency, it is also
+ considered a benefit by SBC administrators: if a customer pays for
+ "phone" service, for example, the media is what is truly being paid
+ for, and the administrators usually like to be able to detect that
+ the media is flowing correctly, evaluate its quality, know if and why
+ it failed, etc. Also, in some cases, routing media through operator
+ controlled relays may route media over paths explicitly optimized for
+ media and hence offer better performance than regular Internet
+ routing.
+
+5. Security Considerations
+
+ A common concern is that an SBC (or an XMPP server -- all security
+ considerations apply to both) that implements HNT may latch to
+ incorrect and possibly malicious sources. The ICE [RFC5245]
+ protocol, for example, provides authentication tokens (conveyed in
+ the ice-ufrag and ice-pwd attributes) that allow the identity of a
+ peer to be confirmed before engaging in media exchange with her.
+ Without such authentication, a malicious source could attempt a
+ resource exhaustion attack by flooding all possible media-latching
+ UDP ports on the SBC in order to prevent calls from succeeding. SBCs
+ have various mechanisms to prevent this from happening or to alert an
+ administrator when it does. Still, a sufficiently sophisticated
+ attacker may be able to bypass them for some time. The most common
+ example is typically referred to as "restricted-latching", whereby
+ the SBC will not latch to any packets from a source public IP address
+ other than the one the SIP UA uses for SIP signaling. This way, the
+ SBC simply ignores and does not latch onto packets coming from the
+ attacker. In some cases, the limitation may be loosened to allow
+ media from a range of IP addresses belonging to the same network in
+ order to allow for use cases such as decomposed UAs and various forms
+ of third-party call control. However, since relaxing the
+ restrictions in such a way may provide attackers with a larger attack
+
+
+
+
+
+Ivov, et al. Informational [Page 11]
+
+RFC 7362 Hosted NAT Traversal for Media in RTC September 2014
+
+
+ surface, such configurations are generally performed only on a case-
+ by-case basis so that the specifics of individual deployments can be
+ taken into account.
+
+ All of the above problems would still arise if the attacker knows the
+ public source IP of the UA that is actually making the call. This
+ would allow attackers to still flood all of the SBC's public IP
+ addresses and ports with packets spoofing that SIP UA's public source
+ IP address. However, this would only impact media from that IP (or
+ range of IP addresses) rather than all calls that the SBC is
+ servicing.
+
+ A malicious source could send media packets to an SBC media-latching
+ UDP port in the hopes of being latched to for the purpose of
+ receiving media for a given SIP session. SBCs have various
+ mechanisms to prevent this as well. Restricted latching, for
+ example, would also help in this case because the attacker can't make
+ the SBC send media packets back to themselves since the SBC will not
+ latch onto the attacker's media packets, not having seen the
+ corresponding signaling packets first. There could still be an issue
+ if the attacker happens to be either (1) in the IP routing path where
+ it can thus spoof the same IP as the real UA and get the media coming
+ back, in which case the attacker hardly needs to attack at all to
+ begin with, or (2) behind the same NAT as the legitimate SIP UA, in
+ which case the attacker's packets will be latched to by the SBC and
+ the SBC will send media back to the attacker. In the latter case,
+ which may be of particular concern with Carrier-Grade NATs, the
+ legitimate SIP UA will likely end the call anyway when a human user
+ who does not hear anything hangs up. In the case of a non-human call
+ participant, such as an answering machine, this may not happen
+ (although many such automated UAs would also hang up when they do not
+ receive any media). The attacker could also redirect all media to
+ the real SIP UA after receiving it, in which case the attack would
+ likely remain undetected and succeed. Again, this would be of
+ particular concern with larger-scale NATs serving many different
+ endpoints, such as Carrier-Grade NATs. The larger the number of
+ devices fronted by a NAT is, the more use cases would vary, and the
+ more the number of possible attack vectors would grow.
+
+ Naturally, Secure RTP (SRTP) [RFC3711] would help mitigate such
+ threats and, if used with the appropriate key negotiation mechanisms,
+ would protect the media from monitoring while in transit. It should
+ therefore be used independently of HNT. Section 26 of [RFC3261]
+ provides an overview of additional threats and solutions on
+ monitoring and session interception.
+
+
+
+
+
+
+Ivov, et al. Informational [Page 12]
+
+RFC 7362 Hosted NAT Traversal for Media in RTC September 2014
+
+
+ With SRTP, if the SBC that performs the latching is actually
+ participating in the SRTP key exchange, then it would simply refuse
+ to latch onto a source unless it can authenticate it. Failing to
+ implement and use SRTP would represent a serious threat to users
+ connecting from behind Carrier-Grade NATs [RFC6888] and is considered
+ a harmful practice.
+
+ For SIP clients, HNT is usually transparent in the sense that the SIP
+ UA does not know it occurs. In certain cases, it may be detectable,
+ such as when ICE is supported by the SIP UA and the SBC modifies the
+ default connection address and media port numbers in SDP, thereby
+ disabling ICE due to the mismatch condition. Even in that case,
+ however, the SIP UA only knows that a middlebox is relaying media but
+ not necessarily that it is performing latching/HNT.
+
+ In order to perform HNT, the SBC has to modify SDP to and from the
+ SIP UA behind a NAT; thus, the SIP UA cannot use S/MIME [RFC5751],
+ and it cannot sign a sending request, or verify a received request
+ using the SIP Identity mechanism [RFC4474] unless the SBC re-signs
+ the request. However, neither S/MIME nor SIP Identity are widely
+ deployed; thus, not being able to sign/verify requests appears not to
+ be a concern at this time.
+
+ From a privacy perspective, media relaying is sometimes seen as a way
+ of protecting one's IP address and not revealing it to the remote
+ party. That kind of IP address masking is often perceived as
+ important. However, this is no longer an exclusive advantage of HNT
+ since it can also be accomplished by client-controlled relaying
+ mechanisms such as TURN [RFC5766] if the client explicitly wishes to
+ do so.
+
+6. Acknowledgements
+
+ The authors would like to thank Flemming Andreasen, Miguel A.
+ Garcia, Alissa Cooper, Vijay K. Gurbani, Ari Keranen, and Paul
+ Kyzivat for their reviews and suggestions on improving this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ivov, et al. Informational [Page 13]
+
+RFC 7362 Hosted NAT Traversal for Media in RTC September 2014
+
+
+7. References
+
+7.1. Normative References
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002.
+
+ [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+ with Session Description Protocol (SDP)", RFC 3264, June
+ 2002.
+
+ [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+ Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+ RFC 3711, March 2004.
+
+ [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+ Description Protocol", RFC 4566, July 2006.
+
+ [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
+ (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+ RFC 4787, January 2007.
+
+ [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
+ A., and M. Bhatia, "Requirements from Session Initiation
+ Protocol (SIP) Session Border Control (SBC) Deployments",
+ RFC 5853, April 2010.
+
+ [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
+ Protocol (XMPP): Core", RFC 6120, March 2011.
+
+ [XEP-0177]
+ Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan,
+ "XEP-0177: Jingle Raw UDP Transport Method", XSF XEP 0177,
+ December 2009.
+
+7.2. Informative References
+
+ [H.323] International Telecommunication Union, "Packet-based
+ multimedia communication systems", ITU-T Recommendation
+ H.323, December 2009.
+
+ [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
+ Self-Address Fixing (UNSAF) Across Network Address
+ Translation", RFC 3424, November 2002.
+
+
+
+
+
+Ivov, et al. Informational [Page 14]
+
+RFC 7362 Hosted NAT Traversal for Media in RTC September 2014
+
+
+ [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control
+ Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
+
+ [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
+ "STUN - Simple Traversal of User Datagram Protocol (UDP)
+ Through Network Address Translators (NATs)", RFC 3489,
+ March 2003.
+
+ [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
+ Authenticated Identity Management in the Session
+ Initiation Protocol (SIP)", RFC 4474, August 2006.
+
+ [RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic",
+ RFC 5125, February 2008.
+
+ [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
+ (ICE): A Protocol for Network Address Translator (NAT)
+ Traversal for Offer/Answer Protocols", RFC 5245, April
+ 2010.
+
+ [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+ "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+ October 2008.
+
+ [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
+ Mail Extensions (S/MIME) Version 3.2 Message
+ Specification", RFC 5751, January 2010.
+
+ [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
+ Relays around NAT (TURN): Relay Extensions to Session
+ Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
+
+ [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
+ and H. Ashida, "Common Requirements for Carrier-Grade NATs
+ (CGNs)", BCP 127, RFC 6888, April 2013.
+
+ [TCP-SPLICING]
+ Maltz, D. and P. Bhagwat, "TCP Splice for application
+ layer proxy performance", Journal of High Speed Networks
+ Vol. 8, No. 3, 1999, pp. 225-240, March 1999.
+
+
+
+
+
+
+
+
+
+
+
+Ivov, et al. Informational [Page 15]
+
+RFC 7362 Hosted NAT Traversal for Media in RTC September 2014
+
+
+Authors' Addresses
+
+ Emil Ivov
+ Jitsi
+ Strasbourg 67000
+ France
+
+ EMail: emcho@jitsi.org
+
+
+ Hadriel Kaplan
+ Oracle
+ 100 Crosby Drive
+ Bedford, MA 01730
+ USA
+
+ EMail: hadrielk@yahoo.com
+
+
+ Dan Wing
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134
+ USA
+
+ EMail: dwing@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ivov, et al. Informational [Page 16]
+