draft-ietf-mmusic-latching-00.txt   draft-ietf-mmusic-latching-01.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: May 8, 2013 Acme Packet Expires: November 08, 2013 Acme Packet
D. Wing D. Wing
Cisco Cisco
November 4, 2012 May 07, 2013
Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Latching: Hosted NAT Traversal (HNT) for Media in Real-Time
Communication Communication
draft-ietf-mmusic-latching-00 draft-ietf-mmusic-latching-01
Abstract Abstract
This document describes behavior of signalling intermediaries in RTC This document describes behavior of signalling intermediaries in
deployments, sometimes referred to as Session Border Controllers Real-Time Communication (RTC) deployments, sometimes referred to as
(SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of Session Border Controllers (SBCs), when performing Hosted NAT
mechanisms, such as media relaying and latching, that such Traversal (HNT). HNT is a set of mechanisms, such as media relaying
intermediaries use to enable other RTC devices behind NATs to and latching, that such intermediaries use to enable other RTC
communicate with each other. This document is non-normative, and is devices behind NATs to communicate with each other. This document is
only written to explain HNT in order to provide a reference to the non-normative, and is only written to explain HNT in order to provide
IETF community, as well as an informative description to a reference to the IETF community, as well as an informative
manufacturers, and users. description to manufacturers, and users.
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 May 8, 2013. This Internet-Draft will expire on November 08, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 4
4. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 5 4. Media Behavior, Latching . . . . . . . . . . . . . . . . . . 5
5. Media Behavior, Latching . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Network Address Translators (NATs) are widely used in the Internet by Network Address Translators (NATs) are widely used in the Internet by
consumers and organizations. Although specific NAT behaviors vary, consumers and organizations. Although specific NAT behaviors vary,
this document uses the term "NAT" for devices that map any IPv4 or this document uses the term "NAT" for devices that map any IPv4 or
IPv6 address and transport port number to another IPv4 or IPv6 IPv6 address and transport port number to another IPv4 or IPv6
address and transport port number. This includes consumer NAPTs, address and transport port number. This includes consumer NATs,
Firewall-NATs, IPv4-IPv6 NATs, Carrier-Grade NATs, etc. Firewall-NATs, IPv4-IPv6 NATs, Carrier-Grade NATs, etc.
Protocols like SIP [RFC3261], and others that try to use a more Protocols like SIP [RFC3261], and others that try to use a more
direct path for media than with signalling, are difficult to use direct path for media than with signalling, are difficult to use
across NATs. They use IP addresses and transport port numbers across NATs. They use IP addresses and transport port numbers
encoded in bodies such as SDP [RFC4566]> as well as, in the case of encoded in bodies such as SDP [RFC4566] as well as, in the case of
SIP, various header fields. Such addresses and ports are unusable SIP, various header fields. Such addresses and ports are unusable
unless all peers in a session are located behind the same NAT. unless all peers in a session are located behind the same NAT.
Mechanisms such as STUN [RFC5389], TURN [RFC5766], and ICE [RFC5245], Mechanisms such as Session Traversal Utilities for NAT (STUN)
did not exist when protocols like SIP began being deployed. Session [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and
Border Controllers (SBCs) that were already being used by SIP domains Interactive Connectivity Establishment (ICE) [RFC5245] did not exist
for other SIP and media-related purposes began to use proprietary when protocols like SIP began being deployed. Session Border
Controllers (SBCs) that were already being used by SIP domains for
other SIP and media-related purposes began to use proprietary
mechanisms to enable SIP devices behind NATs to communicate across mechanisms to enable SIP devices behind NATs to communicate across
the NATs. the NATs.
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
skipping to change at page 4, line 20 skipping to change at page 3, line 46
for SIP in [RFC5853], but that is not the focus of this document. for SIP in [RFC5853], but that is not the focus of this document.
The SIP signaling-layer component of HNT is typically more The SIP signaling-layer component of HNT is typically more
implementation-specific and deployment-specific than the SDP and implementation-specific and deployment-specific than the SDP and
media components. For the purposes of this document it is hence media components. For the purposes of this document it is hence
assumed that signaling intermediaries handle traffic in way that assumed that signaling intermediaries handle traffic in way that
allows protocols such as SIP to function correctly across the NATs. allows protocols such as SIP to function correctly across the NATs.
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], MGCP, H.248/MEGACO, and H.323. [RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], H.248/
MEGACO [RFC3015], and H.323 [H.323].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. 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
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 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 packet 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 5, line 23 skipping to change at page 4, line 43
+-----+ +-----+ +-----+ +-----+
/ \ / \
/ Private Net Private Net \ / Private Net Private Net \
/ \ / \
+------+ +------+ +------+ +------+
| UA-A | | UA-B | | UA-A | | UA-B |
+------+ +------+ +------+ +------+
Figure 1: Logical Deployment Paths Figure 1: Logical Deployment Paths
4. 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 Quite often, the IP address of the newly introduced media relay may
be the same as that of the signaling intermediary (e.g. the SIP SBC) be the same as that of the signaling intermediary (e.g. the SIP SBC)
or it may be a completely different one. In almost all cases or it may be a completely different one. In almost all cases
however, the new address would belong to the same IP address family however, the new address would belong to the same IP address family
as the one used for signaling, since it is known to work for that UA. as the one used for signaling, since 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 5) 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 not to send media to that customer UA until a SIP 200 response
for policy reasons, to prevent toll-fraud. for policy reasons, to prevent toll-fraud.
5. Media Behavior, Latching 4. Media Behavior, Latching
An UA behind a NAT streams media from a private address:port set that An UA behind a NAT streams media from a private address:port set that
once packets cross the NAT, will be mapped to a public set. The UA once packets cross the NAT, will be mapped to a public set. The UA
however is not typically aware of the public mapping and would often however is not typically aware of the public mapping and would often
advertise in the private address:port couple in signaling. This way, advertise the private address:port couple in signaling. This way,
when the signalling intermediary performing HNT receives the private when the signalling intermediary performing HNT receives private
addressing information from the UA it will not know what address/ addressing information from from a NATed UA it will not know what
ports to send media to. Therefore media relays used in HNT would address/ports to send media to. Therefore media relays used in HNT
often use a mechanism called "latching". 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:ports are used to
send media back to the UA. Today most people talk about them both as send media back to the UA. Today most people talk about them both as
"latching", and thus this document does as well. "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:ports on a media relay. The set would then be
advertised to the remote party so that it would use it for all advertised to the remote party so that it would use those media
media it wished to send toward the UA. relay address:ports for all media it wished to send 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 to the UA and use it relay. It would advertise this second set in the answer to the
for all media traffic to and from the UA. 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.
4. This way all media streamed by the UA would be received on the 4. This way all media streamed by the UA would be received on the
second address:port set. The source addresses and ports of the second address:port set. The source addresses and ports of the
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
UAC network and 198.51.100/24 facing towards the UAS network. User Agent Client (UAC) network and 198.51.100/24 facing towards the
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/24-SBC-198.51.100/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 UAS) |
| | and 203.0.113.4/36010 for |
| | inbound RTP from UAC) |
| | | | | | | |
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. |<-200+answer,c=203.0.113.4/36010--| c=198.51.100.33 |
| | | | | | | |
8. |------------ACK------------------>| | 7. | | (SBC allocates 203.0.113.4:36010 |
9. | | |-------ACK--------->| | | for inbound RTP from UAC) |
| | | | | | | |
10. |=====RTP,dest=203.0.113.4/36010==>| | 8. |<-200+answer,c=203.0.113.4:36010--| c=198.51.100.33 |
| | | | | | | |
11. | | (SBC latches to | 9. |------------ACK------------------>| |
10. | | |-------ACK--------->|
| | | |
11. |=====RTP,dest=203.0.113.4:36010==>| |
| | | |
12. | | (SBC latches to |
| | source IP address and | | | source IP address and |
| | port seen at (10)) | | | port seen at (10)) |
| | | | | | | |
12. | | |<====== RTP ========| 13. | | |<====== RTP ========|
| | | | | | | |
13. |<=====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 XMPP Client1 NAT XMPP Server XMPP Client2
------- --- --- ------- ------- --- --- -------
| | | | | | | |
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 Client2) |
| | and 203.0.113.9/3300 for | | | | |
| | inbound RTP from Client1) | 4. | | |--session-initiate->|
| | | | | | cand=203.0.113.9:2200|
4. | | |--session-initiate->| | | | |
| | cand=203.0.113.9/2200| 5. | | |<-------ack---------|
| | | | | | | |
5. | | |<-------ack---------| | | | |
| | | | 6. | | |<--session-accept---|
| | | | | | | cand=198.51.100.8 |
6. | | |<--session-accept---| | | | |
| | | cand=198.51.100.8 | 7. | | |--------ack-------> |
| | | | | | | |
7. | | |--------ack-------> | 8. | | (Server allocates 203.0.113.9:3300 |
8. |<-session-accept cand=203.0.113.9/3300-| | | | for inbound RTP from Client1) |
| | | | | | | |
9. |-----------------ack------------------>| | 9. |<-session-accept cand=203.0.113.9:3300-| |
| | | | | | | |
| | | | 10. |-----------------ack------------------>| |
10. |======RTP, dest=203.0.113.9/3300======>| | | | | |
| | | | | | | |
11. | | (XMPP server latches to | 11. |======RTP, dest=203.0.113.9:3300======>| |
| | src IP 203.0.113.4 and | | | | |
| | src port seen at (10)) | 12. | | (XMPP server latches to |
| | | | | | src IP 203.0.113.4 and |
12. | | |<====== RTP ========| | | src port seen at (10)) |
| | | | | | | |
13. |<======RTP, to latched address=========| | 13. | | |<====== RTP ========|
| | | | | | | |
14. |<======RTP, to latched address=========| |
| | | |
Figure 3: Latcing by a SIP SBC across two interfaces Figure 3: Latching by a SIP SBC 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 20 skipping to change at page 9, line 27
In order for latching to function correctly, the UA behind the NAT In order for latching to function correctly, the UA behind the NAT
needs to support symmetric RTP. That is, it needs to use the same needs to support symmetric RTP. That is, it needs to use the same
ports for sending data as the ones it listens on for inbound packets. ports for sending data as the ones it listens on for inbound packets.
Today this is the case for with, for example, almost all SIP and XMPP Today this is the case for with, for example, almost all SIP and XMPP
clients. Also UAs need to make sure they can begin sending media clients. Also UAs need to make sure they can begin sending media
packets independently and without waiting for packets to arrive packets independently and without waiting for packets to arrive
first. In theory, it is possible that some UAs would not send first. In theory, it is possible that some UAs would not send
packets out first; for example if a SIP session begins in 'inactive' packets out first; for example if a SIP session begins in 'inactive'
or 'recvonly' SDP mode from the UA behind the NAT. In practice, or 'recvonly' SDP mode from the UA behind the NAT. In practice,
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 in an inactive or 'recvonly' behind a NAT) virtually never begin an inactive or 'recvonly' mode,
mode, for obvious reasons. The media direction would also be for obvious reasons. The media direction would also be problematic
problematic if the SBC side indicated 'inactive' or 'sendonly' modes if the SBC side indicated 'inactive' or 'sendonly' modes when it sent
when it sent SDP to the UA. However SBCs providing HNT would always SDP to the UA. However SBCs providing HNT would always be configured
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 to start streaming toward the address:port sets provided in the offer
offer/answer even before receiving any inbound traffic. If the /answer even before receiving any inbound traffic. If the entity
entity they are streaming to is another HNT performing server it they are streaming to is another HNT performing server it would have
would have provided its relay's public address and ports and the provided its relay's public address and ports and the early stream
early stream would find its target. 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, and described in [tcp-splicing].
skipping to change at page 11, line 23 skipping to change at page 10, line 30
reduced scalability and often increased latency, it is also 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.
6. 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 that implements HNT may latch to
incorrect and possibly malicious sources. A malicious source could, incorrect and possibly malicious sources. A malicious source could,
for example, attempt a resource exhaustion attack by flooding all for example, attempt a resource exhaustion attack by flooding all
possible media-latching UDP ports on the SBC in order to prevent possible media-latching UDP ports on the SBC in order to prevent
calls from succeeding. SBCs have various mechanisms to prevent this calls from succeeding. SBCs have various mechanisms to prevent this
from happening, or alert an administrator when it does. Still, a from happening, or alert an administrator when it does. Still, a
sufficiently sophisticated attacker may be able to bypass them for sufficiently sophisticated attacker may be able to bypass them for
some time. The most common example is typically referred to as some time. The most common example is typically referred to as
"restricted-latching", whereby the SBC will not latch to any packets "restricted-latching", whereby the SBC will not latch to any packets
skipping to change at page 13, line 17 skipping to change at page 12, line 23
deployed and that this may not be a real concern. deployed and that this may not be a real concern.
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
This document has no actions for IANA.
Note to the RFC-Editor: please remove this section prior to
publication as an RFC.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Flemming Andreasen and Miguel A. The authors would like to thank Flemming Andreasen, Miguel A.
Garcia for their reviews and suggestions on improving this document. Garcia, Ari Keraenen and Paul Kyzivat for their reviews and
suggestions on improving this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
[H.323] International Telecommunication Union , "Packet Based
Multimedia Communication Systems", Recommendation H.323,
July 2003.
[RFC3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen,
B., and J. Segers, "Megaco Protocol Version 1.0", RFC
3015, November 2000.
[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, with Session Description Protocol (SDP)", RFC 3264, June
June 2002. 2002.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control
"STUN - Simple Traversal of User Datagram Protocol (UDP) Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. 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 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[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, Traversal for Offer/Answer Protocols", RFC 5245, April
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
skipping to change at page 14, line 39 skipping to change at page 14, line 8
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
A., and M. Bhatia, "Requirements from Session Initiation A., and M. Bhatia, "Requirements from Session Initiation
Protocol (SIP) Session Border Control (SBC) Deployments", Protocol (SIP) Session Border Control (SBC) Deployments",
RFC 5853, April 2010. RFC 5853, April 2010.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011. Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
Path Key Agreement for Unicast Secure RTP", RFC 6189,
April 2011.
[XEP-0177] [XEP-0177]
Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan, Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan,
"XEP-0177: Jingle Raw UDP Transport Method", XEP XEP-0177, "XEP-0177: Jingle Raw UDP Transport Method", XEP XEP-0177,
December 2009. December 2009.
Authors' Addresses Authors' Addresses
Emil Ivov Emil Ivov
Jitsi Jitsi
Strasbourg 67000 Strasbourg 67000
 End of changes. 51 change blocks. 
143 lines changed or deleted 165 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/