draft-ietf-mmusic-latching-05.txt   draft-ietf-mmusic-latching-06.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 7, 2014 Oracle Expires: November 30, 2014 Oracle
D. Wing D. Wing
Cisco Cisco
May 6, 2014 May 29, 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-05 draft-ietf-mmusic-latching-06
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, and unless number of security issues covered here. Because of those, and unless
all security considerations explained here are taken into account and all security considerations explained here are taken into account and
solved, the IETF advises against use of this mechanism over the solved, the IETF advises against use of latching mechanism over the
Internet and recommends other solutions such as the Interactive Internet and recommends other solutions such as the Interactive
Connectivity Establishment (ICE) protocol. 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 November 30, 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 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . . . 6 4. Media Behavior, Latching . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. Informative References . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Key References . . . . . . . . . . . . . . . . . . . . . 13
8.2. Additional References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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.
Protocols like SIP [RFC3261], and others that try to use a more The Session Initiation Protocol (SIP) [RFC3261], and others that try
direct path for media than with signalling, are difficult to use to use a more direct path for media than with signalling, are
across NATs. They use IP addresses and transport port numbers difficult to use across NATs. These protocols use IP addresses and
encoded in bodies such as SDP [RFC4566] as well as, in the case of transport port numbers encoded in bodies such as the Session
SIP, various header fields. Such addresses and ports are unusable Description Protocol (SDP) [RFC4566] and, in the case of SIP, various
unless all peers in a session are located behind the same NAT. 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) 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. These mechanisms devices behind NATs to communicate across the NATs. These mechanisms
are often transparent to endpoints and rely on a dynamic address and are often transparent to endpoints and rely on a dynamic address and
port discovery technique called "latching". 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 a number of manufacturers sometimes use other names such as
end NAT Traversal" or "NAT assist" instead. The systems which "Far-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.
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 themselves make an exclusive
adoption of ICE highly unlikely in the foreseeable future. adoption of ICE 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 not novel to experts, publication in an IETF document used in HNT are well known in the community, publication in an IETF
is useful as a means of providing common terminology and a reference document is useful as a means of providing common terminology and a
for related documents. reference for related documents.
In no way does this document try 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.
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.
SIP's many features in terms of controlling message routing provide
The SIP signaling-layer component of HNT is typically more for various ways for addressing NAT traversal. As a result, the HNT
implementation-specific and deployment-specific than the SDP and component for SIP is typically more implementation-specific and
media components. For the purposes of this document it is hence deployment-specific than the SDP and media components. For the
assumed that signaling intermediaries handle traffic in a way that purposes of this document it is hence assumed that signaling
allows protocols such as SIP to function correctly across the NATs. intermediaries handle traffic in a way that 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
The general problems with NAT traversal for protocols such as SIP The general problems with NAT traversal for protocols such as SIP
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: Logical Deployment Paths Figure 1: Common Deployment Scenarios
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.
Quite often, the IP address of the newly introduced media relay may While this is not necessary for HNT to work, quite often, the IP
be the same as that of the signaling intermediary (e.g. the SIP SBC) address of that media relay may be the same as that of the signaling
or it may be a completely different one. In almost all cases intermediary (i.e. the SIP SBC and media relay are co-located on the
however, the new address would belong to the same IP address family same host). Also, in almost all cases, the address of the media
as the one used for signaling, since it is known to work for that UA. relay would belong to the same IP address family as the one used for
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
an offer is sent, the generator of the offer needs to be prepared to an offer is sent, the generator of the offer needs to be prepared to
receive media on the advertised address/ports. In practice such receive media on the advertised address/ports. In practice such
media may or may not be received, depending on the implementations media may or may not be received, depending on the implementations
participating in a given session, local policies, and call scenario. participating in a given session, local policies, and call scenario.
For example if a SIP SDP Offer originally came from a UA behind a For example if a SIP SDP Offer originally came from a UA behind a
NAT, the SIP SBC cannot send media to it until an SDP Answer is given NAT, the SIP SBC cannot send media to it until an SDP Answer is given
to the UA and latching (Section 4) occurs. Another example is when a to the UA and latching (Section 4) occurs. Another example is when a
SIP SBC sends an SDP Offer in a SIP INVITE to a residential SIP SBC sends an SDP Offer in a SIP INVITE to a residential
customer's UA and receives back SDP in a 18x response, the SBC may customer's UA and receives back SDP in a 18x response, the SBC may
decide not to send media to that customer UA until a SIP 200 response decide, for policy reasons, not to send media to that customer UA
for policy reasons, to prevent toll-fraud. until a SIP 200 response has been received (e.g., to prevent toll-
fraud).
4. Media Behavior, Latching 4. Media Behavior, Latching
An UA behind a NAT streams media from a private address:port set that An UA that is behind a NAT would stream media from an address and a
once packets cross the NAT, will be mapped to a public set. The UA port number (an address:port couple) that are only valid in its local
however is not typically aware of the public mapping and would often network. Once packets cross the NAT, that address:port couple will
advertise the private address:port couple in signaling. This way, be mapped to a public one. The UA however is not typically aware of
when the signalling intermediary performing HNT receives private the public mapping and would often advertise the private address:port
addressing information from from a NATed UA it will not know what couple in signaling. This way, while a session is still being setup,
address/ports to send media to. Therefore media relays used in HNT the signalling intermediary is not yet aware what addresses and ports
would often use a mechanism called "latching". the caller and the callee would end up using for media traffic: it
has only seen them advertise the private addresses they use behind
their respective NATs. Therefore media relays used in HNT would
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:ports are used to "symmetric-latching" is when the latched address:port couples are
send media back to the UA. Today most people talk about them both as used to send media back to the UA. Today most people talk about them
"latching", and thus this document does as well. both as "latching", and thus this document does as well.
The latching mechanism works as follows: The latching mechanism works as follows:
1. After receiving an offer from a NATed UA, a signaling 1. After receiving an offer from a NATed UA, a signaling
intermediary located on the public Internet would allocate a set intermediary located on the public Internet would allocate a set
of IP address:ports on a media relay. The set would then be of IP address:port couples on a media relay. The set would then
advertised to the remote party so that it would use those media be advertised to the remote party so that it would use those
relay address:ports for all media it wished to send toward the media relay address:port couples for all media it wished to send
UA. toward the UA.
2. Next, after receiving an answer to its offer, the signaling 2. Next, after receiving an answer to its offer, the signaling
server would allocate a second address:port set on the media server would allocate a second address:port set on the media
relay. It would advertise this second set in the answer to the relay. It would advertise this second set in the answer to the
UA. The UA will then send to this media relay address:port. UA. The UA will then send to this media relay address:port.
3. The media relay receives the media packets on the allocated 3. The media relay receives the media packets on the allocated
ports, and uses their source address and port as a destination ports, and uses their source address and port as a destination
for all media bound in the opposite direction. In other words, for all media bound in the opposite direction. In other words,
it "latches" or locks on these source address:port set. it "latches" or locks on these source address:port set.
skipping to change at page 7, line 11 skipping to change at page 7, line 13
traffic would belong to the public interface of the NAT in front traffic would belong to the public interface of the NAT in front
of the UA and anything that the relay sends there would find its of the UA and anything that the relay sends there would find its
way to it. way to it.
5. Similarly the source of the stream originating at the remote 5. Similarly the source of the stream originating at the remote
party would be latched upon and used for media going in that party would be latched upon and used for media going in that
direction. direction.
6. Latching is usually done only once per peer and not allowed to 6. Latching is usually done only once per peer and not allowed to
change or cause a re-latching until a new offer and answer get change or cause a re-latching until a new offer and answer get
exchanged (e.g. in a subsequent call or after a SIP peer has gone exchanged (e.g., in a subsequent call or after a SIP peer has
on and off hold). The reasons for such restrictions are mostly gone on and off hold). The reasons for such restrictions are
related to security: once a session has started a user agent is mostly related to security: once a session has started a user
not expected to suddenly start streaming from a different port agent is not expected to suddenly start streaming from a
without sending a new offer first. A change may indicate an different port without sending a new offer first. A change may
attempt to hijack the session. In some cases however, a port indicate an attempt to hijack the session. In some cases
change may be caused by a re-mapping in a NAT device standing however, a port change may be caused by a re-mapping in a NAT
between the SBC and the UA. More advanced SBCs may therefore device standing between the SBC and the UA. More advanced SBCs
allow some level of flexibility on the re-latching restrictions may therefore allow some level of flexibility on the re-latching
while carefully considering the potential security implications restrictions while carefully considering the potential security
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 198.51.100.33
Alice NAT 203.0.113.0/24-SBC-198.51.100.0/24 Bob Alice NAT 203.0.113.0/24-SBC-198.51.100.0/24 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 UAS) | | | 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.4:36010 |
| | for inbound RTP from UAC) | | | 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.4: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.4:36010==>| |
| | | | | | | |
12. | | (SBC latches to | 12. | | (SBC latches to |
| | source IP address and | | | source IP address and |
| | port seen at (10)) | | | port seen at (11)) |
| | | | | | | |
13. | | |<====== RTP ========| 13. | | |<======= RTP ==========|
| | | | | | |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
XMPP Client1 NAT XMPP Server XMPP Client2 Romeo NAT XMPP Server Juliet
----- --- --- ----- ----- --- --- -----
| | | | | | | |
1. |----session-initiate cand=192.0.2.1--->| | 1. |----session-initiate cand=192.0.2.1--->| |
| | | | | | | |
2. |<------------ack-----------------------| | 2. |<------------ack-----------------------| |
| | | | | | | |
3. | | (Server allocates 203.0.113.9:2200 | 3. | | (Server allocates 203.0.113.9:2200 |
| | for inbound RTP from Client2) | | | for inbound RTP from Juliet) |
| | | | | | | |
4. | | |--session-initiate->| 4. | | |--session-initiate-->|
| | cand=203.0.113.9:2200| | | |cand=203.0.113.9:2200|
| | | | | | | |
5. | | |<-------ack---------| 5. | | |<--------ack---------|
| | | | | | | |
| | | | | | | |
6. | | |<--session-accept---| 6. | | |<---session-accept---|
| | | cand=198.51.100.8 | | | | cand=198.51.100.8 |
| | | | | | | |
7. | | |--------ack-------> | 7. | | |---------ack-------->|
| | | | | | | |
8. | | (Server allocates 203.0.113.9:3300 | 8. | | (Server allocates 203.0.113.9:3300 |
| | for inbound RTP from Client1) | | | for inbound RTP from Romeo) |
| | | | | | | |
9. |<-session-accept cand=203.0.113.9:3300-| | 9. |<-session-accept cand=203.0.113.9:3300-| |
| | | | | | | |
10. |-----------------ack------------------>| | 10. |-----------------ack------------------>| |
| | | | | | | |
| | | | | | | |
11. |======RTP, dest=203.0.113.9:3300======>| | 11. |======RTP, dest=203.0.113.9:3300======>| |
| | | | | | | |
12. | | (XMPP server latches to | 12. | | (XMPP server latches to |
| | src IP 203.0.113.4 and | | | src IP 203.0.113.4 and |
| | src port seen at (10)) | | | src port seen at (11)) |
| | | | | | | |
13. | | |<====== RTP ========| 13. | | |<======= RTP ========|
| | | | | | |dest=203.0.113.9:2200|
14. |<======RTP, to latched address=========| | 14. |<======RTP, to latched address=========| |
| | | | | | | |
Figure 3: Latching by a SIP SBC across two interfaces Figure 3: Latching by an XMPP server across two interfaces
The above is a general description, and some details vary between The above is a general description, and some details vary between
implementations or configuration settings. For example, some implementations or configuration settings. For example, some
intermediaries perform additional logic before latching on received intermediaries perform additional logic before latching on received
packet source information to prevent malicious attacks or latching packet source information to prevent malicious attacks or latching
erroneously to previous media senders - often called "rogue-rtp" in erroneously to previous media senders - often called "rogue-rtp" in
the industry. the industry.
It is worth pointing out that latching is not an exclusively "server It is worth pointing out that latching is not an exclusively "server
affair" and some clients may also use it in cases where they are affair" and some clients may also use it in cases where they are
skipping to change at page 10, line 35 skipping to change at page 10, line 35
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 signalling 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 signalling 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 offer to start streaming toward the address:port sets provided in the
/answer even before receiving any inbound traffic. If the entity offer/answer even before receiving any inbound traffic. If the
they are streaming to is another HNT performing server it would have entity they are streaming to is another HNT performing server it
provided its relay's public address and ports and the early stream would have provided its relay's public address and ports and the
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
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, as 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 participants is that UAs are not aware of it raised by IETF participants is that UAs are not aware of it
occurring. This makes it impossible for the mechanism to be used occurring. This makes it impossible for the mechanism to be used
with protocols such as ICE that try various traversal techniques in with protocols such as ICE that try various traversal techniques in
an effort to choose the one that best suits a particular situation. an effort to choose the one that best suits a particular situation.
Overwriting address information in offers and answers may actually Overwriting address information in offers and answers may actually
completely prevent UAs from using ICE because of the ice-mismatch completely prevent UAs from using ICE because of the ice-mismatch
rules described in [RFC5245] rules described in [RFC5245]
skipping to change at page 11, line 30 skipping to change at page 11, line 30
"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
A common concern is that an SBC that implements HNT may latch to A common concern is that an SBC (or an XMPP server, all security
incorrect and possibly malicious sources. A malicious source could, considerations apply to both) that implements HNT may latch to
for example, attempt a resource exhaustion attack by flooding all incorrect and possibly malicious sources. The ICE [RFC5245] protocol
possible media-latching UDP ports on the SBC in order to prevent for example, provides authentication tokens (conveyed in the ice-
calls from succeeding. SBCs have various mechanisms to prevent this ufrag and ice-pwd attributes) that allow confirming the identity of a
from happening, or alert an administrator when it does. Still, a peer before engaging in media exchange with her. Without such
sufficiently sophisticated attacker may be able to bypass them for authentication, a malicious source could, for example, attempt a
some time. The most common example is typically referred to as resource exhaustion attack by flooding all possible media-latching
"restricted-latching", whereby the SBC will not latch to any packets UDP ports on the SBC in order to prevent calls from succeeding. SBCs
from a source public IP address other than the one the SIP UA uses have various mechanisms to prevent this from happening, or alert an
for SIP signaling. This way the SBC simply ignores and does not administrator when it does. Still, a sufficiently sophisticated
latch onto packets coming from the attacker. In some cases the attacker may be able to bypass them for some time. The most common
limitation may be loosened to allow media from a range of IP example is typically referred to as "restricted-latching", whereby
addresses belonging to the same network in order to allow for use the SBC will not latch to any packets from a source public IP address
cases such as decomposed UAs and various forms of third party call other than the one the SIP UA uses for SIP signaling. This way the
control. However, since relaxing the restrictions in such a way may SBC simply ignores and does not latch onto packets coming from the
widen the gap for potential attackers, such configurations are attacker. In some cases the limitation may be loosened to allow
generally performed only on a case-by-case basis so that the media from a range of IP addresses belonging to the same network in
specifics of individual deployments would be taken into account. order to allow for use cases such as decomposed UAs and various forms
of third party call control. However, since relaxing the
restrictions in such a way may widen the gap for potential attackers,
such configurations are generally performed only on a case-by-case
basis so that the specifics of individual deployments would be taken
into account.
In all of the above problems would still arise if the attacker knows All of the above problems would still arise if the attacker knows the
the public source IP of the UA that is actually making the call. public source IP of the UA that is actually making the call. This
This would allow them to still flood all of the SBC's public IP would allow them to still flood all of the SBC's public IP addresses
addresses and ports with packets spoofing that SIP UA's public source and ports with packets spoofing that SIP UA's public source IP
IP address. However, this would only disturb media from that IP (or address. However, this would only impact media from that IP (or
range of IP addresses) rather than all calls that the SBC is range of IP addresses) rather than all calls that the SBC is
servicing. servicing.
A malicious source could send media packets to an SBC media-latching A malicious source could send media packets to an SBC media-latching
UDP port in the hopes of being latched-to for the purpose of UDP port in the hopes of being latched-to for the purpose of
receiving media for a given SIP session. SBCs have various receiving media for a given SIP session. SBCs have various
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 media packets, not having seen the corresponding
signaling packets first. 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 likely end the call anyway when a human user
would not hear anything and will hang up. In the case of a non-human who does not hear anything hangs up. In the case of a non-human call
call 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 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 a serious threat to users connecting implement and use SRTP would represent a serious threat to users
from behind Carrier-Grade NATs [RFC6888] and is considered a harmful connecting from behind Carrier-Grade NATs [RFC6888] and is considered
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 it is using [RFC4474] unless the SBC re-signs the request. However,
sometimes argued that, neither S/MIME nor [RFC4474] are widely neither S/MIME or [RFC4474] are widely deployed, thus not being able
deployed and that this may not be a real concern. 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
This document has no actions for IANA. This document has no actions for IANA.
Note to the RFC-Editor: please remove this section prior to Note to the RFC-Editor: please remove this section prior to
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 Keranen and Paul Kyzivat for their reviews and
suggestions on improving this document. suggestions on improving this document.
8. Informative References 8. References
[H.323] International Telecommunication Union, "Packet Based 8.1. Key References
Multimedia Communication Systems", Recommendation H.323,
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.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
A., and M. Bhatia, "Requirements from Session Initiation
Protocol (SIP) Session Border Control (SBC) Deployments",
RFC 5853, April 2010.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011.
[XEP-0177]
Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan,
"XEP-0177: Jingle Raw UDP Transport Method", XEP XEP-0177,
December 2009.
8.2. Additional References
[H.323] International Telecommunication Union, "Packet Based
Multimedia Communication Systems", Recommendation H.323,
July 2003.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-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.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", [RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic",
RFC 5125, February 2008. RFC 5125, February 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245, April
2010. 2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
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,
A., and M. Bhatia, "Requirements from Session Initiation
Protocol (SIP) Session Border Control (SBC) Deployments",
RFC 5853, April 2010.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011.
[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]
Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan,
"XEP-0177: Jingle Raw UDP Transport Method", XEP XEP-0177,
December 2009.
[tcp-splicing] [tcp-splicing]
Maltz, D. and P. Bhagwat, "TCP Splice for application Maltz, D. and P. Bhagwat, "TCP Splice for application
layer proxy performance", Journal of High Speed Networks layer proxy performance", Journal of High Speed Networks
vol. 8, no. 3, 1999, pp. 235-240, March 1999. vol. 8, no. 3, 1999, pp. 235-240, March 1999.
Authors' Addresses Authors' Addresses
Emil Ivov Emil Ivov
Jitsi Jitsi
Strasbourg 67000 Strasbourg 67000
 End of changes. 38 change blocks. 
200 lines changed or deleted 219 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/