draft-ietf-mmusic-latching-02.txt   draft-ietf-mmusic-latching-03.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: December 12, 2013 Acme Packet Expires: January 16, 2014 Oracle
D. Wing D. Wing
Cisco Cisco
June 10, 2013 July 15, 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-02 draft-ietf-mmusic-latching-03
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. This document is
non-normative, and is only written to explain HNT in order to provide non-normative, and is only written to explain HNT in order to provide
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 December 12, 2013. This Internet-Draft will expire on January 16, 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 . . . . . . . . . . . . . . . . . . . . . 5 3. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 4
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
consumers and organizations. Although specific NAT behaviors vary, consumers and organizations. Although specific NAT behaviors vary,
this document uses the term "NAT" for devices that map any IPv4 or this document uses the term "NAT" for devices that map any IPv4 or
IPv6 address and transport port number to another IPv4 or IPv6 IPv6 address and transport port number to another IPv4 or IPv6
address and transport port number. This includes consumer NATs, address and transport port number. This includes consumer NATs,
Firewall-NATs, IPv4-IPv6 NATs, Carrier-Grade NATs, etc. Firewall-NATs, IPv4-IPv6 NATs, Carrier-Grade NATs (CGNs) [RFC6888],
etc.
Protocols like SIP [RFC3261], and others that try to use a more Protocols like SIP [RFC3261], and others that try to use a more
direct path for media than with signalling, are difficult to use direct path for media than with signalling, are difficult to use
across NATs. They use IP addresses and transport port numbers across NATs. They use IP addresses and transport port numbers
encoded in bodies such as SDP [RFC4566] as well as, in the case of encoded in bodies such as SDP [RFC4566] as well as, in the case of
SIP, various header fields. Such addresses and ports are unusable SIP, various header fields. Such addresses and ports are unusable
unless all peers in a session are located behind the same NAT. unless all peers in a session are located behind the same NAT.
Mechanisms such as Session Traversal Utilities for NAT (STUN) Mechanisms such as Session Traversal Utilities for NAT (STUN)
[RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and
skipping to change at page 3, line 44 skipping to change at page 3, line 34
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 The mechanisms described here, popular as they may be, are not
necessarily considered best practice or recommended operation. considered best practice or recommended operation and should hence be
avoided when possible.
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.
skipping to change at page 11, line 37 skipping to change at page 11, line 22
mechanisms to prevent this as well. Restricted latching for example mechanisms to prevent this as well. Restricted latching for example
would also help in this case since the attacker can't make the SBC 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 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 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 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 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, 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, 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 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 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 case, which may be of particular concern with Carrier-Grade NATs, the
legitimate SIP UA will end the call anyway, because a human user 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 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 call participant, such as an answering machine, this may not happen
(although many such automated UAs would also hang up when they do not (although many such automated UAs would also hang up when they do not
receive any media). The attacker could also redirect all media to receive any media). The attacker could also redirect all media to
the real SIP UA after receiving it, in which case the attack would the real SIP UA after receiving it, in which case the attack would
likely remain undetected and succeed. Again, this would be of likely remain undetected and succeed. Again, this would be of
particular concern with larger scale NATs serving many different particular concern with larger scale NATs serving many different
endpoints serving many different endpoints such as carrier grade endpoints such as Carrier-Grade NATs. The larger the number of
NATs. The larger the number of devices fronted by a NAT is, the more devices fronted by a NAT is, the more use cases would vary and the
use cases would vary and the more the number of possible attack more the number of possible attack vectors would grow.
vectors would grow.
Naturally, SRTP [RFC3711] would help mitigate such threats and should Naturally, SRTP [RFC3711] would help mitigate such threats and should
be used independently of HNT. For example, in cases where end-to-end 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 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 hijack a session despite the use of SRTP and perform a denial of
service attack. However, media integrity would not be compromised. service attack. However, media integrity would not be compromised.
Additionally if the SBC that performs the latching is actually Additionally, if the SBC that performs the latching is actually
participating in the SRTP key exchange then it would simply refuse to participating in the SRTP key exchange, then it would simply refuse
latch onto a source unless it can authenticate it. to latch onto a source unless it can authenticate it. Failing to
implement this would represent а 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 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, 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 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 default connection address and media port numbers in SDP, thereby
disabling ICE due to the mismatch condition. Even in that case, disabling ICE due to the mismatch condition. Even in that case,
however, the SIP UA only knows a middle box is relaying media, but however, the SIP UA only knows a middle box is relaying media, but
not necessarily that it is performing latching/HNT. not necessarily that it is performing latching/HNT.
In order to perform HNT, the SBC has to modify SDP to and from the In order to perform HNT, the SBC has to modify SDP to and from the
skipping to change at page 14, line 25 skipping to change at page 14, line 13
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
A., and M. Bhatia, "Requirements from Session Initiation A., and M. Bhatia, "Requirements from Session Initiation
Protocol (SIP) Session Border Control (SBC) Deployments", Protocol (SIP) Session Border Control (SBC) Deployments",
RFC 5853, April 2010. RFC 5853, April 2010.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011. 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] [XEP-0177]
Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan, Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan,
"XEP-0177: Jingle Raw UDP Transport Method", XEP XEP-0177, "XEP-0177: Jingle Raw UDP Transport Method", XEP XEP-0177,
December 2009. December 2009.
Authors' Addresses Authors' Addresses
Emil Ivov Emil Ivov
Jitsi Jitsi
Strasbourg 67000 Strasbourg 67000
France France
Email: emcho@jitsi.org Email: emcho@jitsi.org
Hadriel Kaplan Hadriel Kaplan
Acme Packet Oracle
100 Crosby Drive 100 Crosby Drive
Bedford, MA 01730 Bedford, MA 01730
USA USA
Email: hkaplan@acmepacket.com Email: hadriel.kaplan@oracle.com
Dan Wing Dan Wing
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: dwing@cisco.com Email: dwing@cisco.com
 End of changes. 13 change blocks. 
17 lines changed or deleted 26 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/