draft-ietf-mmusic-latching-04.txt   draft-ietf-mmusic-latching-05.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: April 11, 2014 Oracle Expires: November 7, 2014 Oracle
D. Wing D. Wing
Cisco Cisco
October 08, 2013 May 6, 2014
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-04 draft-ietf-mmusic-latching-05
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. devices behind NATs to communicate with each other.
This document is non-normative, and is only written to explain HNT in 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 order to provide a reference to the IETF community, as well as an
informative description to manufacturers, and users. informative description to manufacturers, and users.
Latching, which is one of the components of the HNT components, has a Latching, which is one of the components of the HNT components, has a
number of security issues covered here. Because of those, the IETF number of security issues covered here. Because of those, and unless
advises against use of this mechanism over the Internet and all security considerations explained here are taken into account and
recommends other solutions such as the Interactive Connectivity solved, the IETF advises against use of this mechanism over the
Establishment (ICE) protocol. 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 November 7, 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) 2014 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 . . . . . . . . . . . . . . . . . . . . . 5
4. Media Behavior, Latching . . . . . . . . . . . . . . . . . . 5 4. Media Behavior, Latching . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. Informative References . . . . . . . . . . . . . . . . . . . 12 8. Informative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 (CGNs) [RFC6888], Firewall-NATs, IPv4-IPv6 NATs, Carrier-Grade NATs (CGNs) [RFC6888],
etc. etc.
skipping to change at page 3, line 10 skipping to change at page 3, line 12
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
Interactive Connectivity Establishment (ICE) [RFC5245] did not exist Interactive Connectivity Establishment (ICE) [RFC5245] did not exist
when protocols like SIP began being deployed. Some mechanisms, such when protocols like SIP began being deployed. Some mechanisms, such
as the early versions of STUN [RFC3489], had started appearing but as the early versions of STUN [RFC3489], had started appearing but
they were unreliable and suffered a number of issues typical for they were unreliable and suffered a number of issues typical for
UNilateral Self-Address Fixing (UNSAF) and described in [RFC3424]. UNilateral Self-Address Fixing (UNSAF) and described in [RFC3424].
For these and other reasons, Session Border Controllers (SBCs) that For these and other reasons, Session Border Controllers (SBCs) that
were already being used by SIP domains for other SIP and media- were already being used by SIP domains for other SIP and media-
related purposes began to use proprietary mechanisms to enable SIP related purposes began to use proprietary mechanisms to enable SIP
devices behind NATs to communicate across the NATs. 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), The term often used for this behavior is Hosted NAT Traversal (HNT),
although some manufacturers sometimes use other names such as "Far- although some manufacturers sometimes use other names such as "Far-
end NAT Traversal" or "NAT assist" instead. The systems which end NAT Traversal" or "NAT assist" instead. The systems which
perform HNT are frequently SBCs as described in [RFC5853], although perform HNT are frequently SBCs as described in [RFC5853], although
other systems such as media gateways and "media proxies" sometimes other systems such as media gateways and "media proxies" sometimes
perform the same role. For the purposes of this document, all such perform the same role. For the purposes of this document, all such
systems are referred to as SBCs, and the NAT traversal behavior is systems are referred to as SBCs, and the NAT traversal behavior is
called HNT. called HNT.
skipping to change at page 4, line 8 skipping to change at page 4, line 4
Due to the security issues presented in Section 5, the latching Due to the security issues presented in Section 5, the latching
mechanism is considered inappropriate for general use on the Internet mechanism is considered inappropriate for general use on the Internet
unless all security considerations are taken into account and solved. unless all security considerations are taken into account and solved.
The IETF is instead advising for the use of the Interactive The IETF is instead advising for the use of the Interactive
Connectivity Establishment [RFC5245] and Traversal Using Relays Connectivity Establishment [RFC5245] and Traversal Using Relays
around NAT (TURN) [RFC5766] protocols. 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 a way that
allows protocols such as SIP to function correctly across the NATs. 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 The rest of this document is going to focus primarily on use of HNT
for SIP. However, the mechanisms described here are relatively for SIP. However, the mechanisms described here are relatively
generic and are often used with other protocols, such as XMPP generic and are often used with other protocols, such as XMPP
[RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], H.248/ [RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], H.248/
MEGACO [RFC5125], and H.323 [H.323]. MEGACO [RFC5125], and H.323 [H.323].
2. Background 2. Background
skipping to change at page 4, line 33 skipping to change at page 4, line 30
are: are:
1. The addresses and port numbers encoded in SDP bodies (or their 1. The addresses and port numbers encoded in SDP bodies (or their
equivalents) by NATed User Agents (UAs) are not usable across the equivalents) by NATed User Agents (UAs) are not usable across the
Internet, because they represent the private network addressing Internet, because they represent the private network addressing
information of the UA rather than the addresses/ports that will information of the UA rather than the addresses/ports that will
be mapped to/from by the NAT. be mapped to/from by the NAT.
2. The policies inherent in NATs, and explicit in Firewalls, are 2. The policies inherent in NATs, and explicit in Firewalls, are
such that packets from outside the NAT cannot reach the UA until such that packets from outside the NAT cannot reach the UA until
the UA sends packet out first. the UA sends packets out first.
3. Some NATs apply endpoint dependent filtering on incoming packets, 3. Some NATs apply endpoint dependent filtering on incoming packets,
as described in [RFC4787] and thus a UA may only be able to 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 receive packets from the same remote peer IP:port as it sends
packets out to. packets out to.
In order to overcome these issues, signaling intermediaries such as In order to overcome these issues, signaling intermediaries such as
SIP SBCs on the public side of the NATs perform HNT for both 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 signaling and media. An example deployment model of HNT and SBCs is
shown in Figure 1. shown in Figure 1.
skipping to change at page 10, line 21 skipping to change at page 11, line 7
well. TCP-based latching is more complicated, and involves forcing well. TCP-based latching is more complicated, and involves forcing
the UA behind the NAT to be the TCP client and sending the initial 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 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 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 are behind NATs, then SBCs typically force both UAs to be the TCP
clients, and the SBC splices the TCP connections together. TCP clients, and the SBC splices the TCP connections together. TCP
splicing is a well-known technique, and described in [tcp-splicing]. splicing is a well-known technique, and described in [tcp-splicing].
HNT and latching in particular are generally found to be working HNT and latching in particular are generally found to be working
reliably but they do have obvious caveats. The first one usually reliably but they do have obvious caveats. The first one usually
raised by IETF members is that UAs are not aware of it occurring. raised by IETF participants is that UAs are not aware of it
This makes it impossible for the mechanism to be used with protocols occurring. This makes it impossible for the mechanism to be used
such as ICE that try various traversal techniques in an effort to with protocols such as ICE that try various traversal techniques in
choose the one the best suits a particular situation. Overwriting an effort to choose the one that best suits a particular situation.
address information in in offers and answers may actually completely Overwriting address information in offers and answers may actually
prevent UAs from using ICE because of the ice-mismatch rules completely prevent UAs from using ICE because of the ice-mismatch
described in [RFC5245] rules described in [RFC5245]
The second issue raised by IETF members is that it causes media to go The second issue raised by IETF participants is that it causes media
through a relay instead of directly over the IP-routed path between to go through a relay instead of directly over the IP-routed path
the two participating UAs. While this adds obvious drawbacks such as between the two participating UAs. While this adds obvious drawbacks
reduced scalability and often increased latency, it is also such as reduced scalability and often increased latency, it is also
considered a benefit by SBC administrators: if a customer pays for considered a benefit by SBC administrators: if a customer pays for
"phone" service, for example, the media is what is truly being paid "phone" service, for example, the media is what is truly being paid
for, and the administrators usually like to be able to detect that for, and the administrators usually like to be able to detect that
media is flowing correctly, evaluate its quality, know if and why it media is flowing correctly, evaluate its quality, know if and why it
failed, etc. Also in some cases routing media through operator failed, etc. Also in some cases routing media through operator
controlled relays may route media over paths explicitly optimized for controlled relays may route media over paths explicitly optimized for
media and hence offer better performance than regular Internet media and hence offer better performance than regular Internet
routing. routing.
5. Security Considerations 5. Security Considerations
skipping to change at page 12, line 10 skipping to change at page 12, line 43
more the number of possible attack vectors would grow. more the number of possible attack 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 participating in the SRTP key exchange, then it would simply refuse
to latch onto a source unless it can authenticate it. Failing to to latch onto a source unless it can authenticate it. Failing to
implement this would represent а serious threat to users implement this would represent a serious threat to users connecting
connecting from behind Carrier-Grade NATs [RFC6888] and is considered from behind Carrier-Grade NATs [RFC6888] and is considered a harmful
a harmful practice. 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 13, line 5 skipping to change at page 13, line 37
publication as an RFC. publication as an RFC.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Flemming Andreasen, Miguel A. The authors would like to thank Flemming Andreasen, Miguel A.
Garcia, Ari Keraenen and Paul Kyzivat for their reviews and Garcia, Ari Keraenen and Paul Kyzivat for their reviews and
suggestions on improving this document. suggestions on improving this document.
8. Informative References 8. Informative References
[H.323] International Telecommunication Union , "Packet Based [H.323] International Telecommunication Union, "Packet Based
Multimedia Communication Systems", Recommendation H.323, Multimedia Communication Systems", Recommendation H.323,
July 2003. July 2003.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264, June
2002. 2002.
[RFC3424] Daigle, L. IAB, "IAB Considerations for UNilateral Self- [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control
Protocol (MGCP) Version 1.0", RFC 3435, January 2003. Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
skipping to change at page 14, line 34 skipping to change at page 15, line 22
[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common Requirements for Carrier-Grade NATs and H. Ashida, "Common Requirements for Carrier-Grade NATs
(CGNs)", BCP 127, RFC 6888, April 2013. (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.
[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 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
 End of changes. 17 change blocks. 
36 lines changed or deleted 44 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/