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

The information below is for an old version of the document
Document Type Active Internet-Draft (mmusic WG)
Last updated 2014-03-12 (latest revision 2013-10-07)
Replaces draft-ivov-mmusic-latching
Stream IETF
Intended RFC status Informational
Formats plain text pdf html
Stream WG state Submitted to IESG for Publication Nov 2013
Document shepherd Ari Keranen
Shepherd write-up Show (last changed 2014-02-11)
IESG IESG state AD Evaluation
Telechat date
Responsible AD Alissa Cooper
Send notices to mmusic-chairs@tools.ietf.org, draft-ietf-mmusic-latching@tools.ietf.org
Network Working Group                                            E. Ivov
Internet-Draft                                                     Jitsi
Intended status: Informational                                 H. Kaplan
Expires: April 11, 2014                                           Oracle
                                                                 D. Wing
                                                                   Cisco
                                                        October 08, 2013

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

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, 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."

   This Internet-Draft will expire on April 11, 2014.

Ivov, et al.             Expires April 11, 2014                 [Page 1]
Internet-Draft    Hosted NAT Traversal for Media in RTC     October 2013

Copyright Notice

   Copyright (c) 2013 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  . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  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.

   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
Show full document text