--- 1/draft-ietf-mmusic-latching-01.txt 2013-06-10 16:14:20.483278162 +0100 +++ 2/draft-ietf-mmusic-latching-02.txt 2013-06-10 16:14:20.519279084 +0100 @@ -1,22 +1,22 @@ Network Working Group E. Ivov Internet-Draft Jitsi Intended status: Informational H. Kaplan -Expires: November 08, 2013 Acme Packet +Expires: December 12, 2013 Acme Packet D. Wing Cisco - May 07, 2013 + June 10, 2013 Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication - draft-ietf-mmusic-latching-01 + draft-ietf-mmusic-latching-02 Abstract This document describes behavior of signalling intermediaries in Real-Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other. This document is non-normative, and is only written to explain HNT in order to provide @@ -31,49 +31,47 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 08, 2013. + This Internet-Draft will expire on December 12, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 4 + 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 5 4. Media Behavior, Latching . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 - 8.2. Informative References . . . . . . . . . . . . . . . . . 12 + 8. Informative References . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction Network Address Translators (NATs) are widely used in the Internet by consumers and organizations. Although specific NAT behaviors vary, this document uses the term "NAT" for devices that map any IPv4 or IPv6 address and transport port number to another IPv4 or IPv6 address and transport port number. This includes consumer NATs, Firewall-NATs, IPv4-IPv6 NATs, Carrier-Grade NATs, etc. @@ -81,25 +79,28 @@ Protocols like SIP [RFC3261], and others that try to use a more direct path for media than with signalling, are difficult to use across NATs. They use IP addresses and transport port numbers encoded in bodies such as SDP [RFC4566] as well as, in the case of SIP, various 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) [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and Interactive Connectivity Establishment (ICE) [RFC5245] did not exist - 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 - the NATs. + when protocols like SIP began being deployed. Some mechanisms, such + as the early versions of STUN [RFC3489], had started appearing but + they were unreliable and suffered a number of issues typical for + UNilateral Self-Address Fixing (UNSAF) and described in [RFC3424]. + For these and other reasons, 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 the NATs. The term often used for this behavior is Hosted NAT Traversal (HNT), although some manufacturers sometimes use other names such as "Far- end NAT Traversal" or "NAT assist" instead. The systems which perform HNT are frequently SBCs as described in [RFC5853], although other systems such as media gateways and "media proxies" sometimes perform the same role. For the purposes of this document, all such systems are referred to as SBCs, and the NAT traversal behavior is called HNT. @@ -129,21 +130,21 @@ The SIP signaling-layer component of HNT is typically more implementation-specific and deployment-specific than the SDP and media components. For the purposes of this document it is hence assumed that signaling intermediaries handle traffic in 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 for SIP. However, the mechanisms described here are relatively generic and are often used with other protocols, such as XMPP [RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], H.248/ - MEGACO [RFC3015], and H.323 [H.323]. + MEGACO [RFC5125], and H.323 [H.323]. 2. Background The general problems with NAT traversal for protocols such as SIP are: 1. The addresses and port numbers encoded in SDP bodies (or their equivalents) by NATed User Agents (UAs) are not usable across the Internet, because they represent the private network addressing information of the UA rather than the addresses/ports that will @@ -255,31 +255,31 @@ 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 way to it. 5. Similarly the source of the stream originating at the remote party would be latched upon and used for media going in that direction. 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 - exchanged (e.g. in a subsequent call or after a SIP peer has - gone on and off hold). The reasons for such restrictions are - mostly related to security: once a session has started a user - agent is not expected to suddenly start streaming from a - different port without sending a new offer first. A change may - indicate an attempt to hijack the session. In some cases - however, a port change may be caused by a re-mapping in a NAT - device standing between the SBC and the UA. More advanced SBCs - may therefore allow some level of flexibility on the re-latching - restrictions while carefully considering the potential security - implications of doing so. + exchanged (e.g. in a subsequent call or after a SIP peer has gone + on and off hold). The reasons for such restrictions are mostly + related to security: once a session has started a user agent is + not expected to suddenly start streaming from a different port + without sending a new offer first. A change may indicate an + attempt to hijack the session. In some cases however, a port + change may be caused by a re-mapping in a NAT device standing + between the SBC and the UA. More advanced SBCs may therefore + allow some level of flexibility on the re-latching restrictions + while carefully considering the potential security implications + of doing so. 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 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 Alice NAT 203.0.113.0/24-SBC-198.51.100.0/24 Bob ------- --- --- ------- | | | | @@ -320,21 +320,21 @@ Figure 2: Latching by a SIP SBC across two interfaces While XMPP implementations often rely on ICE to handle NAT traversal, there are some that also support a non-ICE transport called XMPP Jingle Raw UDP Transport Method [XEP-0177]. Figure 3 describes how latching occurs for one such XMPP implementation where HNT is 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 XMPP Client1 NAT XMPP Server XMPP Client2 - ------- --- --- ------- + ----- --- --- ----- | | | | 1. |----session-initiate cand=192.0.2.1--->| | | | | | 2. |<------------ack-----------------------| | | | | | 3. | | (Server allocates 203.0.113.9:2200 | | | for inbound RTP from Client2) | | | | | 4. | | |--session-initiate->| | | cand=203.0.113.9:2200| @@ -537,64 +538,65 @@ Note to the RFC-Editor: please remove this section prior to publication as an RFC. 7. Acknowledgements The authors would like to thank Flemming Andreasen, Miguel A. Garcia, Ari Keraenen and Paul Kyzivat for their reviews and suggestions on improving this document. -8. References - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - -8.2. Informative References +8. 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, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. + [RFC3424] Daigle, L. IAB, "IAB Considerations for UNilateral Self- + Address Fixing (UNSAF) Across Network Address + Translation", RFC 3424, November 2002. + [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003. + [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, + "STUN - Simple Traversal of User Datagram Protocol (UDP) + Through Network Address Translators (NATs)", RFC 3489, + 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 Authenticated Identity Management in the Session 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", + RFC 5125, February 2008. + [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet