draft-ietf-mmusic-latching-03.txt   draft-ietf-mmusic-latching-04.txt 
Network Working Group E. Ivov Network Working Group E. Ivov
Internet-Draft Jitsi Internet-Draft Jitsi
Intended status: Informational H. Kaplan Intended status: Informational H. Kaplan
Expires: January 16, 2014 Oracle Expires: April 11, 2014 Oracle
D. Wing D. Wing
Cisco Cisco
July 15, 2013 October 08, 2013
Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Latching: Hosted NAT Traversal (HNT) for Media in Real-Time
Communication Communication
draft-ietf-mmusic-latching-03 draft-ietf-mmusic-latching-04
Abstract Abstract
This document describes behavior of signalling intermediaries in This document describes behavior of signalling intermediaries in
Real-Time Communication (RTC) deployments, sometimes referred to as Real-Time Communication (RTC) deployments, sometimes referred to as
Session Border Controllers (SBCs), when performing Hosted NAT Session Border Controllers (SBCs), when performing Hosted NAT
Traversal (HNT). HNT is a set of mechanisms, such as media relaying Traversal (HNT). HNT is a set of mechanisms, such as media relaying
and latching, that such intermediaries use to enable other RTC and latching, that such intermediaries use to enable other RTC
devices behind NATs to communicate with each other. This document is devices behind NATs to communicate with each other.
non-normative, and is only written to explain HNT in order to provide
a reference to the IETF community, as well as an informative This document is non-normative, and is only written to explain HNT in
description to manufacturers, and users. 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2014. This Internet-Draft will expire on April 11, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 4 3. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 5
4. Media Behavior, Latching . . . . . . . . . . . . . . . . . . 5 4. Media Behavior, Latching . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. Informative References . . . . . . . . . . . . . . . . . . . 12 8. Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Network Address Translators (NATs) are widely used in the Internet by Network Address Translators (NATs) are widely used in the Internet by
skipping to change at page 3, line 33 skipping to change at page 3, line 38
The purpose of this document is to describe the mechanisms often used 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 for HNT at the SDP and media layer, in order to aid understanding the
implications and limitations imposed by it. Although the mechanisms implications and limitations imposed by it. Although the mechanisms
used in HNT are not novel to experts, publication in an IETF document 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 is useful as a means of providing common terminology and a reference
for related documents. for related documents.
In no way does this document try to make a case for HNT or present it 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. as a solution that is somehow better than alternatives such as ICE.
The mechanisms described here, popular as they may be, are not Due to the security issues presented in Section 5, the latching
considered best practice or recommended operation and should hence be mechanism is considered inappropriate for general use on the Internet
avoided when possible. 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 It is also worth mentioning that there are purely signaling-layer
components of HNT as well. One such component is briefly described components of HNT as well. One such component is briefly described
for SIP in [RFC5853], but that is not the focus of this document. for SIP in [RFC5853], but that is not the focus of this document.
The SIP signaling-layer component of HNT is typically more The SIP signaling-layer component of HNT is typically more
implementation-specific and deployment-specific than the SDP and implementation-specific and deployment-specific than the SDP and
media components. For the purposes of this document it is hence media components. For the purposes of this document it is hence
assumed that signaling intermediaries handle traffic in way that assumed that signaling intermediaries handle traffic in way that
allows protocols such as SIP to function correctly across the NATs. allows protocols such as SIP to function correctly across the NATs.
 End of changes. 7 change blocks. 
12 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/