draft-ietf-mmusic-latching-07.txt   draft-ietf-mmusic-latching-08.txt 
Network Working Group E. Ivov Network Working Group E. Ivov
Internet-Draft Jitsi Internet-Draft Jitsi
Intended status: Informational H. Kaplan Intended status: Informational H. Kaplan
Expires: December 3, 2014 Oracle Expires: December 19, 2014 Oracle
D. Wing D. Wing
Cisco Cisco
June 1, 2014 June 17, 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-07 draft-ietf-mmusic-latching-08
Abstract Abstract
This document describes behavior of signaling intermediaries in Real- This document describes behavior of signaling intermediaries in Real-
Time Communication (RTC) deployments, sometimes referred to as Time Communication (RTC) deployments, sometimes referred to as
Session Border Controllers (SBCs), when performing Hosted NAT Session Border Controllers (SBCs), when performing Hosted NAT
Traversal (HNT). HNT is a set of mechanisms, such as media relaying Traversal (HNT). HNT is a set of mechanisms, such as media relaying
and latching, that such intermediaries use to enable other RTC and latching, that such intermediaries use to enable other RTC
devices behind NATs to communicate with each other. devices behind NATs to communicate with each other.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 3, 2014. This Internet-Draft will expire on December 19, 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 4, line 8 skipping to change at page 4, line 8
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 SIP uses numerous expressive primitives for message routing. As a
for various ways for addressing NAT traversal. As a result, the HNT result, the HNT component for SIP is typically more implementation-
component for SIP is typically more implementation-specific and specific and deployment-specific than the SDP and media components.
deployment-specific than the SDP and media components. For the For the purposes of this document it is hence assumed that signaling
purposes of this document it is hence assumed that signaling
intermediaries handle traffic in a way that allows protocols such as intermediaries handle traffic in a way that allows protocols such as
SIP to function correctly across the NATs. SIP to function correctly across the NATs.
The rest of this document is going to focus primarily on use of HNT The rest of this document is going to focus primarily on use of HNT
for SIP. However, the mechanisms described here are relatively for SIP. However, the mechanisms described here are relatively
generic and are often used with other protocols, such as XMPP generic and are often used with other protocols, such as XMPP
[RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], H.248/ [RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], H.248/
MEGACO [RFC5125], and H.323 [H.323]. MEGACO [RFC5125], and H.323 [H.323].
2. Background 2. Background
skipping to change at page 5, line 32 skipping to change at page 5, line 32
3. Impact on Signaling 3. Impact on Signaling
Along with codec and other media-layer information, session Along with codec and other media-layer information, session
establishment signaling also conveys, potentially private and non- establishment signaling also conveys, potentially private and non-
globally routable addressing information. Signaling intermediaries globally routable addressing information. Signaling intermediaries
would hence modify such information so that peer UAs are given the would hence modify such information so that peer UAs are given the
(public) addressing information of a media relay controlled by the (public) addressing information of a media relay controlled by the
intermediary. intermediary.
While this is not necessary for HNT to work, quite often, the IP In typical deployments, the media relay and signaling intermediary
address of that media relay may be the same as that of the signaling (i.e., the SBC) are co-located, thereby sharing the same IP address.
intermediary (i.e., the SIP SBC and media relay are co-located on the Also, the address of the media relay would typically belong to the
same host). Also, in almost all cases, the address of the media same IP address family as the one used for signaling, as it is known
relay would belong to the same IP address family as the one used for to work for that UA. In other words, signalling and media would
signaling, as it is known to work for that UA. either both travel over IPv4 or IPv6.
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
skipping to change at page 6, line 13 skipping to change at page 6, line 13
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, for policy reasons, not to send media to that customer UA decide, for policy reasons, not to send media to that customer UA
until a SIP 200 response has been received (e.g., to prevent toll- until a SIP 200 response has been received (e.g., to prevent toll-
fraud). fraud).
4. Media Behavior, Latching 4. Media Behavior, Latching
An UA that is behind a NAT would stream media from an address and a An UA that is behind a NAT would stream media from an address and a
port number (an address:port couple) that are only valid in its local port number (an address:port tuple) that are only valid in its local
network. Once packets cross the NAT, that address:port couple will network. Once packets cross the NAT, that address:port tuple will be
be mapped to a public one. The UA however is not typically aware of mapped to a public one. The UA however is not typically aware of the
the public mapping and would often advertise the private address:port public mapping and would often advertise the private address:port
couple in signaling. This way, while a session is still being setup, tuple in signaling. This way, while a session is still being setup,
the signaling intermediary is not yet aware what addresses and ports the signaling intermediary is not yet aware what addresses and ports
the caller and the callee would end up using for media traffic: it the caller and the callee would end up using for media traffic: it
has only seen them advertise the private addresses they use behind has only seen them advertise the private addresses they use behind
their respective NATs. Therefore media relays used in HNT would their respective NATs. Therefore media relays used in HNT would
often use a mechanism called "latching". often use a mechanism called "latching".
Historically, "latching" only referred to the process by which SBCs Historically, "latching" only referred to the process by which SBCs
"latch" onto UDP packets from a given UA for security purposes, and "latch" onto UDP packets from a given UA for security purposes, and
"symmetric-latching" is when the latched address:port couples are "symmetric-latching" is when the latched address:port tuples are used
used to send media back to the UA. Today most people talk about them to send media back to the UA. Today most people talk about them both
both as "latching", and thus this document does as well. 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 Alice (UAC located behind a NAT), a
intermediary located on the public Internet would allocate a set signaling intermediary located on the public Internet would
of IP address:port couples on a media relay. The set would then allocate a set of IP address:port tuples on a media relay. The
be advertised to the remote party so that it would use those set would then be advertised to Bob (UAS) so that he would use
media relay address:port couples for all media it wished to send those media relay address:port tuples for all media it wished to
toward the UA. send toward Alice (UAC).
2. Next, after receiving an answer to its offer, the signaling 2. Next, after receiving from Bob (UAS) an answer to its offer, the
server would allocate a second address:port set on the media signaling server would allocate a second address:port set on the
relay. It would advertise this second set in the answer to the media relay. In it's the answer to Alice (UAC) the SBC will
UA. The UA will then send to this media relay address:port. replace Bob's address:port with this second set. This way Alice
will send media 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 respective source address:ports as a
for all media bound in the opposite direction. In other words, destination for all media bound in the opposite direction. In
it "latches" or locks on these source address:port set. other words, it "latches" or locks on these source address:port
tuple.
4. This way all media streamed by the UA would be received on the 4. This way, when Alice (UAC) streams media toward the media relay,
second address:port set. The source addresses and ports of the it would be received on the second address:port tuple. The
traffic would belong to the public interface of the NAT in front source address:port of her traffic would belong to the public
of the UA and anything that the relay sends there would find its interface of Alice's NAT and anything that the relay sends back
way to it. to that address:port, would find its way to Alice.
5. Similarly the source of the stream originating at the remote 5. Similarly the source of the media packets that Bob (UAS) is
party would be latched upon and used for media going in that sending 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 exchanged (e.g., in a subsequent call or after a SIP peer has
gone on and off hold). The reasons for such restrictions are gone on and off hold). The reasons for such restrictions are
mostly related to security: once a session has started a user mostly related to security: once a session has started a user
agent is not expected to suddenly start streaming from a agent is not expected to suddenly start streaming from a
different port without sending a new offer first. A change may different port without sending a new offer first. A change may
indicate an attempt to hijack the session. In some cases indicate an attempt to hijack the session. In some cases
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 signaling intermediaries that a session are connected to different signaling intermediaries that
both provide HNT. In this case the media relays controlled by the both provide HNT. In this case the media relays controlled by the
signaling servers could end up each waiting upon the other to signaling servers could end up each waiting upon the other to
initiate the streaming. To prevent this relays would often attempt initiate the streaming. To prevent this relays would often attempt
to start streaming toward the address:port sets provided in the to start streaming toward the address:port tuples provided in the
offer/answer even before receiving any inbound traffic. If the offer/answer even before receiving any inbound traffic. If the
entity they are streaming to is another HNT performing server it entity they are streaming to is another HNT performing server it
would have provided its relay's public address and ports and the would have provided its relay's public address and ports and the
early stream would find its target. early stream would find its target.
Although many SBCs only support UDP-based media latching, and in Although many SBCs only support UDP-based media latching, and in
particular RTP/RTCP, many SBCs support TCP-based media latching as particular RTP/RTCP, many SBCs support TCP-based media latching as
well. TCP-based latching is more complicated, and involves forcing well. TCP-based latching is more complicated, and involves forcing
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
skipping to change at page 11, line 50 skipping to change at page 11, line 50
administrator when it does. Still, a sufficiently sophisticated administrator when it does. Still, a sufficiently sophisticated
attacker may be able to bypass them for some time. The most common attacker may be able to bypass them for some time. The most common
example is typically referred to as "restricted-latching", whereby example is typically referred to as "restricted-latching", whereby
the SBC will not latch to any packets from a source public IP address the SBC will not latch to any packets from a source public IP address
other than the one the SIP UA uses for SIP signaling. This way the other than the one the SIP UA uses for SIP signaling. This way the
SBC simply ignores and does not latch onto packets coming from the SBC simply ignores and does not latch onto packets coming from the
attacker. In some cases the limitation may be loosened to allow attacker. In some cases the limitation may be loosened to allow
media from a range of IP addresses belonging to the same network in media from a range of IP addresses belonging to the same network in
order to allow for use cases such as decomposed UAs and various forms order to allow for use cases such as decomposed UAs and various forms
of third party call control. However, since relaxing the of third party call control. However, since relaxing the
restrictions in such a way may widen the gap for potential attackers, restrictions in such a way may provide attackers with a larger attack
such configurations are generally performed only on a case-by-case surface, such configurations are generally performed only on a case-
basis so that the specifics of individual deployments would be taken by-case basis so that the specifics of individual deployments would
into account. be taken into account.
All of the above problems would still arise if the attacker knows the All of the above problems would still arise if the attacker knows the
public source IP of the UA that is actually making the call. This public source IP of the UA that is actually making the call. This
would allow them to still flood all of the SBC's public IP addresses would allow them to still flood all of the SBC's public IP addresses
and ports with packets spoofing that SIP UA's public source IP and ports with packets spoofing that SIP UA's public source IP
address. However, this would only impact 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
skipping to change at page 13, line 19 skipping to change at page 13, line 19
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. This inability using [RFC4474] unless the SBC re-signs the request. However,
to However, neither S/MIME or [RFC4474] are widely deployed, thus not neither S/MIME or [RFC4474] are widely deployed, thus not being able
being able to sign/verify requests appear not to be a concern at this to sign/verify requests appear not to be a concern at this time.
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 Keranen and Paul Kyzivat for their reviews and Garcia, Alissa Cooper, Vijay K. Gurbani, Ari Keranen and Paul
suggestions on improving this document. Kyzivat for their reviews and suggestions on improving this document.
8. References 8. References
8.1. Key References 8.1. Key References
[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.
 End of changes. 17 change blocks. 
54 lines changed or deleted 54 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/