GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7362

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7362.txt · Last modified: 2014/09/12 21:00 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki