Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication
RFC 7362

 
Document Type RFC - Informational (September 2014; No errata)
Last updated 2014-09-12
Replaces draft-ivov-mmusic-latching
Stream IETF
Formats plain text pdf html
Stream WG state Submitted to IESG for Publication Nov 2013
Consensus Yes
Document shepherd Ari Keranen
Shepherd write-up Show (last changed 2014-02-11)
IESG IESG state RFC 7362 (Informational)
Telechat date
Responsible AD Alissa Cooper
Send notices to mmusic-chairs@ietf.org, draft-ietf-mmusic-latching@ietf.org
IANA IANA review state Version Changed - Review Needed
IANA action state No IC
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
Show full document text