Skip to main content

Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication
draft-ietf-mmusic-latching-05

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7362.
Authors Emil Ivov , Hadriel Kaplan , Dan Wing
Last updated 2014-05-28 (Latest revision 2014-05-06)
Replaces draft-ivov-mmusic-latching
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Ari Keränen
Shepherd write-up Show Last changed 2014-02-11
IESG IESG state Became RFC 7362 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Needs a YES.
Responsible AD Alissa Cooper
Send notices to mmusic-chairs@tools.ietf.org, draft-ietf-mmusic-latching@tools.ietf.org
IANA IANA review state IANA OK - No Actions Needed
draft-ietf-mmusic-latching-05
Network Working Group                                            E. Ivov
Internet-Draft                                                     Jitsi
Intended status: Informational                                 H. Kaplan
Expires: November 7, 2014                                         Oracle
                                                                 D. Wing
                                                                   Cisco
                                                             May 6, 2014

      Latching: Hosted NAT Traversal (HNT) for Media in Real-Time
                             Communication
                     draft-ietf-mmusic-latching-05

Abstract

   This document describes behavior of signalling 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 IETF community, as well as an
   informative description to manufacturers, and users.

   Latching, which is one of the components 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 this mechanism over the
   Internet and recommends other solutions such as the Interactive
   Connectivity Establishment (ICE) protocol.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Ivov, et al.            Expires November 7, 2014                [Page 1]
Internet-Draft    Hosted NAT Traversal for Media in RTC         May 2014

   This Internet-Draft will expire on November 7, 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, Latching  . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

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.

   Protocols like SIP [RFC3261], and others that try to use a more
   direct path for media than with signalling, are difficult to use
   across NATs.  They use IP addresses and transport port numbers
   encoded in bodies such as SDP [RFC4566] as well as, 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

Ivov, et al.            Expires November 7, 2014                [Page 2]
Internet-Draft    Hosted NAT Traversal for Media in RTC         May 2014

   Interactive Connectivity Establishment (ICE) [RFC5245] did not exist
   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) and 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),
   although some manufacturers sometimes use other names such as "Far-
   end NAT Traversal" or "NAT assist" instead.  The systems which
   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.

   As of this document's creation time, 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 themselves make an exclusive
   adoption of ICE 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 not novel to experts, publication in an IETF document
   is useful as a means of providing common terminology and a reference
   for related documents.

   In no way does this document try 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 [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.            Expires November 7, 2014                [Page 3]
Internet-Draft    Hosted NAT Traversal for Media in RTC         May 2014

   The SIP signaling-layer component of HNT 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 is going to focus primarily on use of HNT
   for SIP.  However, the mechanisms described here are relatively
   generic and are often used with other protocols, such as XMPP
   [RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], H.248/
   MEGACO [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] and 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.            Expires November 7, 2014                [Page 4]
Internet-Draft    Hosted NAT Traversal for Media in RTC         May 2014

                              +-----+       +-----+
                              | SBC |-------| SBC |
                              +-----+       +-----+
                               /                 \
                              /     Public Net    \
                             /                     \
                       +-----+                     +-----+
                       |NAT-A|                     |NAT-B|
                       +-----+                     +-----+
                         /                             \
                        / Private Net       Private Net \
                       /                                 \
                   +------+                            +------+
                   | UA-A |                            | UA-B |
                   +------+                            +------+

                    Figure 1: Logical Deployment Paths

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.

   Quite often, the IP address of the newly introduced media relay may
   be the same as that of the signaling intermediary (e.g. the SIP SBC)
   or it may be a completely different one.  In almost all cases
   however, the new address would belong to the same IP address family
   as the one used for signaling, since it is known to work for that UA.

   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 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 residential

Ivov, et al.            Expires November 7, 2014                [Page 5]
Internet-Draft    Hosted NAT Traversal for Media in RTC         May 2014

   customer's UA and receives back SDP in a 18x response, the SBC may
   decide not to send media to that customer UA until a SIP 200 response
   for policy reasons, to prevent toll-fraud.

4.  Media Behavior, Latching

   An UA behind a NAT streams media from a private address:port set that
   once packets cross the NAT, will be mapped to a public set.  The UA
   however is not typically aware of the public mapping and would often
   advertise the private address:port couple in signaling.  This way,
   when the signalling intermediary performing HNT receives private
   addressing information from from a NATed UA it will not know what
   address/ports to send media to.  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:ports are used to
   send media back to the UA.  Today most people talk about them both as
   "latching", and thus this document does as well.

   The latching mechanism works as follows:

   1.  After receiving an offer from a NATed UA, a signaling
       intermediary located on the public Internet would allocate a set
       of IP address:ports on a media relay.  The set would then be
       advertised to the remote party so that it would use those media
       relay address:ports for all media it wished to send toward the
       UA.

   2.  Next, after receiving an answer to its offer, the signaling
       server would allocate a second address:port set on the media
       relay.  It would advertise this second set in the answer to the
       UA.  The UA will then send to this media relay address:port.

   3.  The media relay receives the media packets on the allocated
       ports, and uses their source address and port as a destination
       for all media bound in the opposite direction.  In other words,
       it "latches" or locks on these source address:port set.

   4.  This way all media streamed by the UA would be received on the
       second address:port set.  The source addresses and ports of the
       traffic would belong to the public interface of the NAT in front
       of the UA and anything that the relay sends there would find its
       way to it.

Ivov, et al.            Expires November 7, 2014                [Page 6]
Internet-Draft    Hosted NAT Traversal for Media in RTC         May 2014

   5.  Similarly the source of the stream originating at the remote
       party 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
   User Agent Client (UAC) network and 198.51.100/24 facing towards the
   User Agent Server (UAS) network.

Ivov, et al.            Expires November 7, 2014                [Page 7]
Internet-Draft    Hosted NAT Traversal for Media in RTC         May 2014

     192.0.2.1                                         198.51.100.33
      Alice     NAT        203.0.113.0/24-SBC-198.51.100.0/24  Bob
     -------    ---                       ---                -------
        |        |                         |                    |
    1.  |--SIP INVITE+offer c=192.0.2.1--->|                    |
        |        |                         |                    |
    2.  |        |       (SBC allocates 198.51.100.2:22007      |
        |        |        for inbound RTP from UAS)             |
        |        |                         |                    |
    3.  |        |                         |---INVITE+offer---->|
        |        |                         |c=198.51.100.2:22007|
        |        |                         |                    |
    4.  |        |                         |<---180 Ringing-----|
        |        |                         |                    |
        |        |                         |                    |
    5.  |<------180 Ringing----------------|                    |
        |        |                         |                    |
    6.  |        |                         |<---200+answer------|
        |        |                         |                    |
    7.  |        |       (SBC allocates 203.0.113.4:36010       |
        |        |        for inbound RTP from UAC)             |
        |        |                         |                    |
    8.  |<-200+answer,c=203.0.113.4:36010--|  c=198.51.100.33   |
        |        |                         |                    |
    9.  |------------ACK------------------>|                    |
   10.  |        |                         |-------ACK--------->|
        |        |                         |                    |
   11.  |=====RTP,dest=203.0.113.4:36010==>|                    |
        |        |                         |                    |
   12.  |        |                    (SBC latches to           |
        |        |                   source IP address and      |
        |        |                   port seen at (10))         |
        |        |                         |                    |
   13.  |        |                         |<====== RTP ========|
        |        |                         |                    |
   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.            Expires November 7, 2014                [Page 8]
Internet-Draft    Hosted NAT Traversal for Media in RTC         May 2014

   192.0.2.1  192.0.2.9/203.0.113.4        203.0.113.9      198.51.100.8
   XMPP Client1       NAT                  XMPP Server      XMPP Client2
      -----           ---                      ---                 -----
        |              |                        |                    |
    1.  |----session-initiate cand=192.0.2.1--->|                    |
        |              |                        |                    |
    2.  |<------------ack-----------------------|                    |
        |              |                        |                    |
    3.  |              |      (Server allocates 203.0.113.9:2200     |
        |              |       for inbound RTP from Client2)         |
        |              |                        |                    |
    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 Client1)         |
        |              |                        |                    |
    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 (10))       |
        |              |                        |                    |
   13.  |              |                        |<====== RTP ========|
        |              |                        |                    |
   14.  |<======RTP, to latched address=========|                    |
        |              |                        |                    |

           Figure 3: Latching by a SIP SBC 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
   packet source information to prevent malicious attacks or latching

Ivov, et al.            Expires November 7, 2014                [Page 9]
Internet-Draft    Hosted NAT Traversal for Media in RTC         May 2014

   erroneously to previous media senders - often called "rogue-rtp" in
   the industry.

   It is worth pointing out that latching is not an exclusively "server
   affair" and some clients may also use it in cases where they are
   configured with a public IP address and they 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 for with, for example, almost all SIP and XMPP
   clients.  Also UAs need to make sure they can begin sending media
   packets independently and 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 an 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 signalling intermediaries that
   both provide HNT.  In this case the media relays controlled by the
   signalling 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 sets 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, and in
   particular RTP/RTCP, many SBCs support TCP-based media latching as
   well.  TCP-based latching is more complicated, and 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, and described in [tcp-splicing].

Ivov, et al.            Expires November 7, 2014               [Page 10]
Internet-Draft    Hosted NAT Traversal for Media in RTC         May 2014

   HNT and latching in particular are generally found to be working
   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 often 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
   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 that implements HNT may latch to
   incorrect and possibly malicious sources.  A malicious source could,
   for example, 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 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
   widen the gap for potential attackers, such configurations are
   generally performed only on a case-by-case basis so that the
   specifics of individual deployments would be taken into account.

   In 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 them to still flood all of the SBC's public IP

Ivov, et al.            Expires November 7, 2014               [Page 11]
Internet-Draft    Hosted NAT Traversal for Media in RTC         May 2014

   addresses and ports with packets spoofing that SIP UA's public source
   IP address.  However, this would only disturb 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 since the attacker can't make the SBC
   send media packets back to themselves since the SBC will not latch
   onto the attacker's packets.  There could still be an issue if the
   attacker happens to be either (1) in the IP routing path and thus can
   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) the attacker is 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 this latter
   case, which may be of particular concern with Carrier-Grade NATs, the
   legitimate SIP UA will end the call anyway, because a human user
   would not hear anything and will hang 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, SRTP [RFC3711] would help mitigate such threats and should
   be used independently of HNT.  For example, in cases where end-to-end
   encryption is used it would still be possible for an attacker to
   hijack a session despite the use of SRTP and perform a denial of
   service attack.  However, media integrity would not be compromised.
   Additionally, 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 this 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,

Ivov, et al.            Expires November 7, 2014               [Page 12]
Internet-Draft    Hosted NAT Traversal for Media in RTC         May 2014

   however, the SIP UA only knows a middle box 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, and thus the SIP UA cannot use S/MIME [RFC5751],
   and it cannot sign a sending request or verify a received request
   using [RFC4474] unless the SBC re-signs the request.  However it is
   sometimes argued that, neither S/MIME nor [RFC4474] are widely
   deployed and that this may not be a real concern.

   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.  IANA Considerations

   This document has no actions for IANA.

   Note to the RFC-Editor: please remove this section prior to
   publication as an RFC.

7.  Acknowledgements

   The authors would like to thank Flemming Andreasen, Miguel A.
   Garcia, Ari Keraenen and Paul Kyzivat for their reviews and
   suggestions on improving this document.

8.  Informative References

   [H.323]    International Telecommunication Union, "Packet Based
              Multimedia Communication Systems", Recommendation H.323,
              July 2003.

   [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.

Ivov, et al.            Expires November 7, 2014               [Page 13]
Internet-Draft    Hosted NAT Traversal for Media in RTC         May 2014

   [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral
              Self-Address Fixing (UNSAF) Across Network Address
              Translation", RFC 3424, November 2002.

   [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.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 4474, August 2006.

   [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.

   [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.

Ivov, et al.            Expires November 7, 2014               [Page 14]
Internet-Draft    Hosted NAT Traversal for Media in RTC         May 2014

   [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.

   [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.

   [XEP-0177]
              Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan,
              "XEP-0177: Jingle Raw UDP Transport Method", XEP XEP-0177,
              December 2009.

   [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. 235-240, March 1999.

Authors' Addresses

   Emil Ivov
   Jitsi
   Strasbourg  67000
   France

   Email: emcho@jitsi.org

   Hadriel Kaplan
   Oracle
   100 Crosby Drive
   Bedford, MA  01730
   USA

   Email: hadriel.kaplan@oracle.com

   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: dwing@cisco.com

Ivov, et al.            Expires November 7, 2014               [Page 15]