draft-ietf-mmusic-latching-06.txt   draft-ietf-mmusic-latching-07.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: November 30, 2014 Oracle Expires: December 3, 2014 Oracle
D. Wing D. Wing
Cisco Cisco
May 29, 2014 June 1, 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-06 draft-ietf-mmusic-latching-07
Abstract Abstract
This document describes behavior of signalling intermediaries in This document describes behavior of signaling intermediaries in Real-
Real-Time Communication (RTC) deployments, sometimes referred to as 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
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 30, 2014. This Internet-Draft will expire on December 3, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 2, line 46 skipping to change at page 2, line 46
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.
The Session Initiation Protocol (SIP) [RFC3261], and others that try The Session Initiation Protocol (SIP) [RFC3261], and others that try
to use a more direct path for media than with signalling, are to use a more direct path for media than with signaling, are
difficult to use across NATs. These protocols use IP addresses and difficult to use across NATs. These protocols use IP addresses and
transport port numbers encoded in bodies such as the Session transport port numbers encoded in bodies such as the Session
Description Protocol (SDP) [RFC4566] and, in the case of SIP, various Description Protocol (SDP) [RFC4566] and, in the case of SIP, various
header fields. Such addresses and ports are unusable unless all header fields. Such addresses and ports are unusable unless all
peers in a session are located behind the same NAT. 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
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
skipping to change at page 3, line 33 skipping to change at page 3, line 33
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.
As of this document's creation time, a vast majority of SIP domains As of this document's creation time, a vast majority of SIP domains
use HNT to enable SIP devices to communicate across NATs, despite the use HNT to enable SIP devices to communicate across NATs, despite the
publication of ICE. There are many reasons for this, but those publication of ICE. There are many reasons for this, but those
reasons are not relevant to this document's purpose and will not be reasons are not relevant to this document's purpose and will not be
discussed. It is however worth pointing out that the current discussed. It is however worth pointing out that the current
deployment levels of HNT and NATs themselves make an exclusive deployment levels of HNT and NATs make the complete extinction of
adoption of ICE highly unlikely in the foreseeable future. this practice highly unlikely in the foreseeable future.
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 well known in the community, publication in an IETF used in HNT are well known in the community, publication in an IETF
document is useful as a means of providing common terminology and a document is useful as a means of providing common terminology and a
reference for related documents. reference for related documents.
This document does not attempt to make a case for HNT or present it This document does not attempt 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.
skipping to change at page 5, line 21 skipping to change at page 5, line 21
+-----+ +-----+ +-----+ +-----+
|NAT-A| |NAT-B| |NAT-A| |NAT-B|
+-----+ +-----+ +-----+ +-----+
/ \ / \
/ Private Net Private Net \ / Private Net Private Net \
/ \ / \
+------+ +------+ +------+ +------+
| UA-A | | UA-B | | UA-A | | UA-B |
+------+ +------+ +------+ +------+
Figure 1: Common Deployment Scenarios Figure 1: Signaling and Media Flows in a Common Deployment Scenario
3. Impact on Signaling 3. Impact on Signaling
Along with codec and other media-layer information, session Along with codec and other media-layer information, session
establishment signaling also conveys, potentially private and non- establishment signaling also conveys, potentially private and non-
globally routable addressing information. Signaling intermediaries globally routable addressing information. Signaling intermediaries
would hence modify such information so that peer UAs are given the would hence modify such information so that peer UAs are given the
(public) addressing information of a media relay controlled by the (public) addressing information of a media relay controlled by the
intermediary. intermediary.
While this is not necessary for HNT to work, quite often, the IP While this is not necessary for HNT to work, quite often, the IP
address of that media relay may be the same as that of the signaling address of that media relay may be the same as that of the signaling
intermediary (i.e. the SIP SBC and media relay are co-located on the intermediary (i.e., the SIP SBC and media relay are co-located on the
same host). Also, in almost all cases, the address of the media same host). Also, in almost all cases, the address of the media
relay would belong to the same IP address family as the one used for relay would belong to the same IP address family as the one used for
signaling, as it is known to work for that UA. signaling, as it is known to work for that UA.
The port numbers introduced in the signaling by the intermediary are The port numbers introduced in the signaling by the intermediary are
typically allocated dynamically. Allocation strategies are entirely typically allocated dynamically. Allocation strategies are entirely
implementation dependent and they often vary from one product to the implementation dependent and they often vary from one product to the
next. next.
The offer/answer media negotiation model [RFC3264] is such that once The offer/answer media negotiation model [RFC3264] is such that once
skipping to change at page 6, line 18 skipping to change at page 6, line 18
fraud). fraud).
4. Media Behavior, Latching 4. Media Behavior, Latching
An UA that is behind a NAT would stream media from an address and a An UA that is behind a NAT would stream media from an address and a
port number (an address:port couple) that are only valid in its local port number (an address:port couple) that are only valid in its local
network. Once packets cross the NAT, that address:port couple will network. Once packets cross the NAT, that address:port couple will
be mapped to a public one. The UA however is not typically aware of be mapped to a public one. The UA however is not typically aware of
the public mapping and would often advertise the private address:port the public mapping and would often advertise the private address:port
couple in signaling. This way, while a session is still being setup, couple in signaling. This way, while a session is still being setup,
the signalling intermediary is not yet aware what addresses and ports the signaling intermediary is not yet aware what addresses and ports
the caller and the callee would end up using for media traffic: it the caller and the callee would end up using for media traffic: it
has only seen them advertise the private addresses they use behind has only seen them advertise the private addresses they use behind
their respective NATs. Therefore media relays used in HNT would their respective NATs. Therefore media relays used in HNT would
often use a mechanism called "latching". often use a mechanism called "latching".
Historically, "latching" only referred to the process by which SBCs Historically, "latching" only referred to the process by which SBCs
"latch" onto UDP packets from a given UA for security purposes, and "latch" onto UDP packets from a given UA for security purposes, and
"symmetric-latching" is when the latched address:port couples are "symmetric-latching" is when the latched address:port couples are
used to send media back to the UA. Today most people talk about them used to send media back to the UA. Today most people talk about them
both as "latching", and thus this document does as well. both as "latching", and thus this document does as well.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
device standing between the SBC and the UA. More advanced SBCs device standing between the SBC and the UA. More advanced SBCs
may therefore allow some level of flexibility on the re-latching may therefore allow some level of flexibility on the re-latching
restrictions while carefully considering the potential security restrictions while carefully considering the potential security
implications of doing so. implications of doing so.
Figure 2 describes how latching occurs for SIP where HNT is provided Figure 2 describes how latching occurs for SIP where HNT is provided
by an SBC connected to two networks: 203.0.113/24 facing towards the by an SBC connected to two networks: 203.0.113/24 facing towards the
User Agent Client (UAC) network and 198.51.100/24 facing towards the User Agent Client (UAC) network and 198.51.100/24 facing towards the
User Agent Server (UAS) network. User Agent Server (UAS) network.
192.0.2.1 198.51.100.33 192.0.2.1 192.0.2.9/203.0.113.4 198.51.100.33
Alice NAT 203.0.113.0/24-SBC-198.51.100.0/24 Bob Alice NAT 203.0.113.9-SBC-198.51.100.2 Bob
------- --- --- ------- ------- --- --- -------
| | | | | | | |
1. |--SIP INVITE+offer c=192.0.2.1--->| | 1. |--SIP INVITE+offer c=192.0.2.1--->| |
| | | | | | | |
2. | | (SBC allocates 198.51.100.2:22007 | 2. | | (SBC allocates 198.51.100.2:22007 |
| | for inbound RTP from Bob) | | | for inbound RTP from Bob) |
| | | | | | | |
3. | | |-----INVITE+offer----->| 3. | | |-----INVITE+offer----->|
| | | c=198.51.100.2:22007 | | | | c=198.51.100.2:22007 |
| | | | | | | |
4. | | |<------180 Ringing-----| 4. | | |<------180 Ringing-----|
| | | | | | | |
| | | | | | | |
5. |<------180 Ringing----------------| | 5. |<------180 Ringing----------------| |
| | | | | | | |
6. | | |<------200+answer------| 6. | | |<------200+answer------|
| | | | | | | |
7. | | (SBC allocates 203.0.113.4:36010 | 7. | | (SBC allocates 203.0.113.9:36010 |
| | for inbound RTP from Alice) | | | for inbound RTP from Alice) |
| | | | | | | |
8. |<-200+answer,c=203.0.113.4:36010--| c=198.51.100.33 | 8. |<-200+answer,c=203.0.113.9:36010--| c=198.51.100.33 |
| | | | | | | |
9. |------------ACK------------------>| | 9. |------------ACK------------------>| |
10. | | |----------ACK--------->| 10. | | |----------ACK--------->|
| | | | | | | |
11. |=====RTP,dest=203.0.113.4:36010==>| | 11. |=====RTP,dest=203.0.113.9:36010==>| |
| | | | | | | |
12. | | (SBC latches to | 12. | | (SBC latches to |
| | source IP address and | | | source IP address and |
| | port seen at (11)) | | | port seen at (11)) |
| | | | | | | |
13. | | |<======= RTP ==========| 13. | | |<======= RTP ==========|
| | |dest:198.51.100.2:22007| | | |dest:198.51.100.2:22007|
14. |<=====RTP, to latched address=====| | 14. |<=====RTP, to latched address=====| |
| | | | | | | |
Figure 2: Latching by a SIP SBC across two interfaces Figure 2: Latching by a SIP SBC across two interfaces
While XMPP implementations often rely on ICE to handle NAT traversal, While XMPP implementations often rely on ICE to handle NAT traversal,
there are some that also support a non-ICE transport called XMPP there are some that also support a non-ICE transport called XMPP
Jingle Raw UDP Transport Method [XEP-0177]. Figure 3 describes how Jingle Raw UDP Transport Method [XEP-0177]. Figure 3 describes how
latching occurs for one such XMPP implementation where HNT is latching occurs for one such XMPP implementation where HNT is
provided by an XMPP server on the public internet. provided by an XMPP server on the public internet.
192.0.2.1 192.0.2.9/203.0.113.4 203.0.113.9 198.51.100.8 192.0.2.1 192.0.2.9/203.0.113.4 203.0.113.9 198.51.100.8
skipping to change at page 10, line 31 skipping to change at page 10, line 31
however, SIP sessions from regular UAs (the kind that one could find however, SIP sessions from regular UAs (the kind that one could find
behind a NAT) virtually never begin an inactive or 'recvonly' mode, behind a NAT) virtually never begin an inactive or 'recvonly' mode,
for obvious reasons. The media direction would also be problematic for obvious reasons. The media direction would also be problematic
if the SBC side indicated 'inactive' or 'sendonly' modes when it sent if the SBC side indicated 'inactive' or 'sendonly' modes when it sent
SDP to the UA. However SBCs providing HNT would always be configured SDP to the UA. However SBCs providing HNT would always be configured
to avoid this. to avoid this.
Given that, in order for latching to work properly, media relays need Given that, in order for latching to work properly, media relays need
to begin receiving media before they start sending, it is possible to begin receiving media before they start sending, it is possible
for deadlocks to occur. This can happen when the UAC and the UAS in for deadlocks to occur. This can happen when the UAC and the UAS in
a session are connected to different signalling intermediaries that a session are connected to different signaling intermediaries that
both provide HNT. In this case the media relays controlled by the both provide HNT. In this case the media relays controlled by the
signalling servers could end up each waiting upon the other to signaling servers could end up each waiting upon the other to
initiate the streaming. To prevent this relays would often attempt initiate the streaming. To prevent this relays would often attempt
to start streaming toward the address:port sets provided in the to start streaming toward the address:port sets provided in the
offer/answer even before receiving any inbound traffic. If the offer/answer even before receiving any inbound traffic. If the
entity they are streaming to is another HNT performing server it entity they are streaming to is another HNT performing server it
would have provided its relay's public address and ports and the would have provided its relay's public address and ports and the
early stream would find its target. early stream would find its target.
Although many SBCs only support UDP-based media latching, and in Although many SBCs only support UDP-based media latching, and in
particular RTP/RTCP, many SBCs support TCP-based media latching as particular RTP/RTCP, many SBCs support TCP-based media latching as
well. TCP-based latching is more complicated, and involves forcing well. TCP-based latching is more complicated, and involves forcing
skipping to change at page 11, line 34 skipping to change at page 11, line 34
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
A common concern is that an SBC (or an XMPP server, all security A common concern is that an SBC (or an XMPP server, all security
considerations apply to both) that implements HNT may latch to considerations apply to both) that implements HNT may latch to
incorrect and possibly malicious sources. The ICE [RFC5245] protocol incorrect and possibly malicious sources. The ICE [RFC5245] protocol
for example, provides authentication tokens (conveyed in the ice- for example, provides authentication tokens (conveyed in the ice-
ufrag and ice-pwd attributes) that allow confirming the identity of a ufrag and ice-pwd attributes) that allow the identity of a peer to be
peer before engaging in media exchange with her. Without such confirmed before engaging in media exchange with her. Without such
authentication, a malicious source could, for example, attempt a authentication, a malicious source could, for example, attempt a
resource exhaustion attack by flooding all possible media-latching resource exhaustion attack by flooding all possible media-latching
UDP ports on the SBC in order to prevent calls from succeeding. SBCs UDP ports on the SBC in order to prevent calls from succeeding. SBCs
have various mechanisms to prevent this from happening, or alert an have various mechanisms to prevent this from happening, or alert an
administrator when it does. Still, a sufficiently sophisticated administrator when it does. Still, a sufficiently sophisticated
attacker may be able to bypass them for some time. The most common attacker may be able to bypass them for some time. The most common
example is typically referred to as "restricted-latching", whereby example is typically referred to as "restricted-latching", whereby
the SBC will not latch to any packets from a source public IP address the SBC will not latch to any packets from a source public IP address
other than the one the SIP UA uses for SIP signaling. This way the other than the one the SIP UA uses for SIP signaling. This way the
SBC simply ignores and does not latch onto packets coming from the SBC simply ignores and does not latch onto packets coming from the
skipping to change at page 12, line 42 skipping to change at page 12, line 42
participant, such as an answering machine, this may not happen 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 such as Carrier-Grade NATs. The larger the number of endpoints such as Carrier-Grade NATs. The larger the number of
devices fronted by a NAT is, the more use cases would vary and the devices fronted by a NAT is, the more use cases would vary and the
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, if
be used independently of HNT. For example, in cases where end-to-end used with the appropriate key negotiation mechanisms, would protect
encryption is used it would still be possible for an attacker to the media from monitoring while in transit. It should therefore be
hijack a session despite the use of SRTP and perform a denial of used independently of HNT. [RFC3261] Section 26 provides an overview
service attack. However, media integrity would not be compromised. of additional threats and solutions on monitoring and session
Additionally, if the SBC that performs the latching is actually interception.
With SRTP, 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 and use SRTP would represent a serious threat to users implement and use SRTP would represent a serious threat to users
connecting from behind Carrier-Grade NATs [RFC6888] and is considered connecting from behind Carrier-Grade NATs [RFC6888] and is considered
a harmful practice. 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
SIP UA behind a NAT, and thus the SIP UA cannot use S/MIME [RFC5751], SIP UA behind a NAT, and thus the SIP UA cannot use S/MIME [RFC5751],
and it cannot sign a sending request or verify a received request and it cannot sign a sending request or verify a received request
using [RFC4474] unless the SBC re-signs the request. However, using [RFC4474] unless the SBC re-signs the request. This inability
neither S/MIME or [RFC4474] are widely deployed, thus not being able to However, neither S/MIME or [RFC4474] are widely deployed, thus not
to sign/verify requests appear not to be a concern at this time. being able to sign/verify requests appear not to be a concern at this
time.
From a privacy perspective, media relaying is sometimes seen as a way From a privacy perspective, media relaying is sometimes seen as a way
of protecting one's IP address and not revealing it to the remote of protecting one's IP address and not revealing it to the remote
party. That kind of IP address masking is often perceived as party. That kind of IP address masking is often perceived as
important. However, this is no longer an exclusive advantage of HNT important. However, this is no longer an exclusive advantage of HNT
since it can also be accomplished by client-controlled relaying since it can also be accomplished by client-controlled relaying
mechanisms such as TURN [RFC5766], if the client explicitly wishes to mechanisms such as TURN [RFC5766], if the client explicitly wishes to
do so. do so.
6. IANA Considerations 6. IANA Considerations
 End of changes. 20 change blocks. 
58 lines changed or deleted 61 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/