Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6314

NAT Traversal Practices for Client-Server SIP

Pages: 60
Informational
Part 1 of 4 – Pages 1 to 12
None   None   Next

Top   ToC   RFC6314 - Page 1
Internet Engineering Task Force (IETF)                        C. Boulton
Request for Comments: 6314                               NS-Technologies
Category: Informational                                     J. Rosenberg
ISSN: 2070-1721                                                    Skype
                                                            G. Camarillo
                                                                Ericsson
                                                                F. Audet
                                                                   Skype
                                                               July 2011


             NAT Traversal Practices for Client-Server SIP

Abstract

Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NATs) is a complex problem. Currently, there are many deployment scenarios and traversal mechanisms for media traffic. This document provides concrete recommendations and a unified method for NAT traversal as well as documents corresponding flows. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6314. Copyright Notice Copyright (c) 2011 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
Top   ToC   RFC6314 - Page 2
   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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Solution Technology Outline Description . . . . . . . . . . . 8 4.1. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Symmetric Response . . . . . . . . . . . . . . . . . . 8 4.1.2. Client-Initiated Connections . . . . . . . . . . . . . 9 4.2. Media Traversal . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . 10 4.2.2. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.3. STUN/TURN/ICE . . . . . . . . . . . . . . . . . . . . 11 5. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 12 5.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 12 5.1.1. Registration (Registrar/Edge Proxy Co-Located) . . . . 12 5.1.2. Registration(Registrar/Edge Proxy Not Co-Located) . . 16 5.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 19 5.1.4. Receiving an Invitation to a Session . . . . . . . . . 22 5.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 27 5.2.1. Endpoint-Independent NAT . . . . . . . . . . . . . . . 28 5.2.2. Address/Port-Dependent NAT . . . . . . . . . . . . . . 48 6. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . . . 57 6.1. IPv4-IPv6 Transition for SIP Signaling . . . . . . . . . . 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 57 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 9.1. Normative References . . . . . . . . . . . . . . . . . . . 58 9.2. Informative References . . . . . . . . . . . . . . . . . . 59
Top   ToC   RFC6314 - Page 3

1. Introduction

NAT (Network Address Translator) traversal has long been identified as a complex problem when considered in the context of the Session Initiation Protocol (SIP) [RFC3261] and its associated media such as the Real-time Transport Protocol (RTP) [RFC3550]. The problem is exacerbated by the variety of NATs that are available in the marketplace today and the large number of potential deployment scenarios. Details of different NATs behavior can be found in "NAT Behavioral Requirements for Unicast UDP" [RFC4787]. The IETF has been active on many specifications for the traversal of NATs, including Session Traversal Utilities for NAT (STUN) [RFC5389], Interactive Connectivity Establishment (ICE) [RFC5245], symmetric response [RFC3581], symmetric RTP [RFC4961], Traversal Using Relay NAT (TURN) [RFC5766], SIP Outbound [RFC5626], the Session Description Protocol (SDP) attribute for RTP Control Protocol (RTCP) [RFC3605], "Multiplexing RTP Data and Control Packets on a Single Port" [RFC5761], and others. Each of these represents a part of the solution, but none of them gives the overall context for how the NAT traversal problem is decomposed and solved through this collection of specifications. This document serves to meet that need. It should be noted that this document intentionally does not invoke 'Best Current Practice' machinery as defined in RFC 2026 [RFC2026]. The document is split into two distinct sections as follows: o Section 4 provides a definitive set of best common practices to demonstrate the traversal of SIP and its associated media through NAT devices. o Section 5 provides non-normative examples representing interactions of SIP using various NAT type deployments. The document does not propose any new functionality but does draw on existing solutions for both core SIP signaling and media traversal (as defined in Section 4). The best practices described in this document are for traditional "client-server"-style SIP. This term refers to the traditional use of the SIP protocol where User Agents talk to a series of intermediaries on a path to connect to a remote User Agent. It seems likely that other groups using SIP, for example, peer-to-peer SIP (P2PSIP), will recommend these same practices between a P2PSIP client and a P2PSIP peer, but will recommend different practices for use between peers in a peer-to-peer network.
Top   ToC   RFC6314 - Page 4

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 RFC 2119 [RFC2119]. It should be noted that the use of the term 'Endpoint-Independent NAT' in this document refers to a NAT that is both Endpoint- Independent Filtering and Endpoint-Independent Mapping per the definitions in RFC 4787 [RFC4787].

3. Problem Statement

The traversal of SIP through NATs can be split into two categories that both require attention: the core SIP signaling and associated media traversal. This document assumes NATs that do not contain SIP- aware Application Layer Gateways (ALGs), which makes much of the issues discussed in the document not applicable. ALGs have limitations (as per RFC 4787 [RFC4787] Section 7, RFC 3424 [RFC3424], and [RFC5245] Section 18.6), and experience shows they can have an adverse impact on the functionality of SIP. This includes problems such as requiring the media and signaling to traverse the same device and not working with encrypted signaling and/or payload. The use of non-TURN-based media intermediaries is not considered in this document. More information can be obtained from [RFC5853] and [MIDDLEBOXES]. The core SIP signaling has a number of issues when traversing through NATs. SIP response routing over UDP as defined in RFC 3261 [RFC3261] without extensions causes the response to be delivered to the source IP address specified in the topmost Via header, or the 'received' parameter of the topmost 'Via' header. The port is extracted from the SIP 'Via' header to complete the IP address/port combination for returning the SIP response. While the destination for the response is correct, the port contained in the SIP 'Via' header represents the listening port of the originating client and not the port representing the open pinhole on the NAT. This results in responses being sent back to the NAT but to a port that is likely not open for SIP traffic. The SIP response will then be dropped at the NAT. This is illustrated in Figure 1, which depicts a SIP response being returned to port 5060.
Top   ToC   RFC6314 - Page 5
     Private                       NAT                         Public
     Network                        |                          Network
                                    |
                                    |
     --------     SIP Request       |open port 10923           --------
    |        |-------------------->--->-----------------------|        |
    |        |                      |                         |        |
    | Client |                      |port 5060   SIP Response | Proxy  |
    |        |                      x<------------------------|        |
    |        |                      |                         |        |
     --------                       |                          --------
                                    |
                                    |
                                    |

                         Figure 1: Failed Response

   Secondly, there are two cases where new requests reuse existing
   connections.  The first is when using a reliable, connection-oriented
   transport protocol such as TCP, SIP has an inherent mechanism that
   results in SIP responses reusing the connection that was created/used
   for the corresponding transactional request.  The SIP protocol does
   not provide a mechanism that allows new requests generated in the
   reverse direction of the originating client to use, for example, the
   existing TCP connection created between the client and the server
   during registration.  This results in the registered contact address
   not being bound to the "connection" in the case of TCP.  Requests are
   then blocked at the NAT, as illustrated in Figure 2.  The second case
   is when using an unreliable transport protocol such as UDP where
   external NAT mappings need to be reused to reach a SIP entity on the
   private side of the network.

     Private                       NAT                         Public
     Network                        |                          Network
                                    |
                                    |
     -------- (UAC 8023)    REGISTER/Response       (UAS 5060) --------
    |        |-------------------->---<-----------------------|        |
    |        |                      |                         |        |
    | Client |                      |5060  INVITE   (UAC 8015)| Proxy  |
    |        |                      x<------------------------|        |
    |        |                      |                         |        |
     --------                       |                          --------
                                    |
                                    |
                                    |

                         Figure 2: Failed Request
Top   ToC   RFC6314 - Page 6
   In Figure 2, the original REGISTER request is sent from the client on
   port 8023 and received by the proxy on port 5060, establishing a
   connection and opening a pinhole in the NAT.  The generation of a new
   request from the proxy results in a request destined for the
   registered entity (contact IP address) that is not reachable from the
   public network.  This results in the new SIP request attempting to
   create a connection to a private network address.  This problem would
   be solved if the original connection were reused.  While this problem
   has been discussed in the context of connection-oriented protocols
   such as TCP, the problem exists for SIP signaling using any transport
   protocol.  The impact of connection reuse of connection-oriented
   transports (TCP, TLS, etc.) is discussed in more detail in the
   connection reuse specification [RFC5923].  The approach proposed for
   this problem in Section 4 of this document is relevant for all SIP
   signaling in conjunction with connection reuse, regardless of the
   transport protocol.

   NAT policy can dictate that connections should be closed after a
   period of inactivity.  This period of inactivity may vary from a
   number of seconds to hours.  SIP signaling cannot be relied upon to
   keep connections alive for the following two reasons.  Firstly, SIP
   entities can sometimes have no signaling traffic for long periods of
   time, which has the potential to exceed the inactivity timer, and
   this can lead to problems where endpoints are not available to
   receive incoming requests as the connection has been closed.
   Secondly, if a low inactivity timer is specified, SIP signaling is
   not appropriate as a keep-alive mechanism as it has the potential to
   add a large amount of traffic to the network, which uses up valuable
   resources and also requires processing at a SIP stack, which is also
   a waste of processing resources.

   Media associated with SIP calls also has problems traversing NAT.
   RTP [RFC3550] runs over UDP and is one of the most common media
   transport types used in SIP signaling.  Negotiation of RTP occurs
   with a SIP session establishment using the Session Description
   Protocol (SDP) [RFC4566] and a SIP offer/answer exchange [RFC3264].
   During a SIP offer/answer exchange, an IP address and port
   combination are specified by each client in a session as a means of
   receiving media such as RTP.  The problem arises when a client
   advertises its address to receive media and it exists in a private
   network that is not accessible from outside the NAT.  Figure 3
   illustrates this problem.
Top   ToC   RFC6314 - Page 7
                 NAT             Public Network           NAT
                  |                                        |
                  |                                        |
                  |                                        |
     --------     |            SIP Signaling Session       |   --------
    |        |---------------------->Proxy<-------------------|        |
    |        |    |                                        |  |        |
    | Client |    |                                        |  | Client |
    |   A    |>=====>RTP>==Unknown Address==>X             |  |   B    |
    |        |    |             X<==Unknown Address==<RTP<===<|        |
     --------     |                                        |   --------
                  |                                        |
                  |                                        |
                  |                                        |

                          Figure 3: Failed Media

   The connection addresses of the clients behind the NATs will
   nominally contain a private IPv4 address that is not routable across
   the public Internet.  Exacerbating matters even more would be the
   tendency of Client A to send media to a destination address it
   received in the signaling confirmation message -- an address that may
   actually correspond to a host within the private network who is
   suddenly faced with incoming RTP packets (likewise, Client B may send
   media to a host within its private network who did not solicit these
   packets).  Finally, to complicate the problem even further, a number
   of different NAT topologies with different default behaviors
   increases the difficulty of arriving at a unified approach.  This
   problem exists for all media transport protocols that might be NATted
   (e.g., TCP, UDP, the Stream Control Transmission Protocol (SCTP), the
   Datagram Congestion Control Protocol (DCCP)).

   In general, the problems associated with NAT traversal can be
   categorized as follows.

   For signaling:

   o  Responses do not reuse the NAT mapping and filtering entries
      created by the request.

   o  Inbound requests are filtered out by the NAT because there is no
      long-term connection between the client and the proxy.
Top   ToC   RFC6314 - Page 8
   For media:

   o  Each endpoint has a variety of addresses that can be used to reach
      it (e.g., native interface address, public NATted address).  In
      different situations, a different pair of (local endpoint, remote
      endpoint) addresses should be used, and it is not clear when to
      use which pair.

   o  Many NATs filter inbound packets if the local endpoint has not
      recently sent an outbound packet to the sender.

   o  Classic RTCP usage is to run RTCP on the next highest port.
      However, NATs do not necessarily preserve port adjacency.

   o  Classic RTP and RTCP usage is to use different 5-tuples for
      traffic in each direction.  Though not really a problem, doing
      this through NATs is more work than using the same 5-tuple in both
      directions.

4. Solution Technology Outline Description

As mentioned previously, the traversal of SIP through existing NATs can be divided into two discrete problem areas: getting the SIP signaling across NATs and enabling media as specified by SDP in a SIP offer/answer exchange to flow between endpoints.

4.1. SIP Signaling

SIP signaling has two areas that result in transactional failure when traversing through NATs, as described in Section 3 of this document. The remaining sub-sections describe appropriate solutions that result in SIP signaling traversal through NATs, regardless of transport protocol. It is advised that SIP-compliant entities follow the guidelines presented in this section to enable traversal of SIP signaling through NATs.

4.1.1. Symmetric Response

As described in Section 3 of this document, when using an unreliable transport protocol such as UDP, SIP responses are sent to the IP address and port combination contained in the SIP 'Via' header field (or default port for the appropriate transport protocol if not present). Figure 4 illustrates the response traversal through the open pinhole using Symmetric techniques defined in RFC 3581 [RFC3581].
Top   ToC   RFC6314 - Page 9
     Private                        NAT                       Public
     Network                         |                        Network
                                     |
                                     |
     --------                        |                        --------
    |        |                       |                       |        |
    |        |send request---------------------------------->|        |
    | Client |<---------------------------------send response|  SIP   |
    |   A    |                       |                       | Proxy  |
    |        |                       |                       |        |
     --------                        |                        --------
                                     |
                                     |
                                     |

                       Figure 4: Symmetric Response

   The outgoing request from Client A opens a pinhole in the NAT.  The
   SIP Proxy would normally respond to the port available in the SIP
   'Via' header, as illustrated in Figure 1.  The SIP Proxy honors the
   'rport' parameter in the SIP 'Via' header and routes the response to
   the port from which it was sent.  The exact functionality for this
   method of response traversal is called 'Symmetric Response', and the
   details are documented in RFC 3581 [RFC3581].  Additional
   requirements are imposed on SIP entities in RFC 3581 [RFC3581] such
   as listening and sending SIP requests/responses from the same port.

4.1.2. Client-Initiated Connections

The second problem with SIP signaling, as defined in Section 3 and illustrated in Figure 2, is to allow incoming requests to be properly routed. Guidelines for devices such as User Agents that can only generate outbound connections through NATs are documented in "Managing Client- Initiated Connections in the Session Initiation Protocol (SIP)" [RFC5626]. The document provides techniques that use a unique User Agent instance identifier (instance-id) in association with a flow identifier (reg-id). The combination of the two identifiers provides a key to a particular connection (both UDP and TCP) that is stored in association with registration bindings. On receiving an incoming request to a SIP Address-Of-Record (AOR), a proxy/registrar routes to the associated flow created by the registration and thus a route through NATs. It also provides a keep-alive mechanism for clients to keep NAT bindings alive. This is achieved by multiplexing a ping- pong mechanism over the SIP signaling connection (STUN for UDP and
Top   ToC   RFC6314 - Page 10
   CRLF/operating system keepalive for reliable transports like TCP).
   Usage of [RFC5626] is RECOMMENDED.  This mechanism is not transport
   specific and should be used for any transport protocol.

   Even if the SIP Outbound mechanism is not used, clients generating
   SIP requests SHOULD use the same IP address and port (i.e., socket)
   for both transmission and receipt of SIP messages.  Doing so allows
   for the vast majority of industry provided solutions to properly
   function (e.g., NAT traversal that is Session Border Control (SBC)
   hosted).  Deployments should also consider the mechanism described in
   the Connection Reuse [RFC5923] specification for routing
   bidirectional messages securely between trusted SIP Proxy servers.

4.2. Media Traversal

The issues of media traversal through NATs is not straightforward and requires the combination of a number of traversal methodologies. The technologies outlined in the remainder of this section provide the required solution set.

4.2.1. Symmetric RTP/RTCP

The primary problem identified in Section 3 of this document is that internal IP address/port combinations cannot be reached from the public side of NATs. In the case of media such as RTP, this will result in no audio traversing NATs (as illustrated in Figure 3). To overcome this problem, a technique called 'Symmetric RTP/RTCP' [RFC4961] can be used. This involves a SIP endpoint both sending and receiving RTP/RTCP traffic from the same IP address/port combination. When operating behind a NAT and using the 'latching' technique described in [MIDDLEBOXES], SIP User Agents MUST implement Symmetric RTP/RTCP. This allows traversal of RTP across the NAT.

4.2.2. RTCP

Normal practice when selecting a port for defining RTP Control Protocol (RTCP) [RFC3550] is for consecutive-order numbering (i.e., select an incremented port for RTCP from that used for RTP). This assumption causes RTCP traffic to break when traversing certain types of NATs due to various reasons (e.g., already allocated port, randomized port allocation). To combat this problem, a specific address and port need to be specified in the SDP rather than relying on such assumptions. RFC 3605 [RFC3605] defines an SDP attribute that is included to explicitly specify transport connection information for RTCP so a separate, explicit NAT binding can be set up for the purpose. The address details can be obtained using any appropriate method including those detailed in this section (e.g., STUN, TURN, ICE).
Top   ToC   RFC6314 - Page 11
   A further enhancement to RFC 3605 [RFC3605] is defined in [RFC5761],
   which specifies 'muxing' both RTP and RTCP on the same IP/PORT
   combination.

4.2.3. STUN/TURN/ICE

ICE, STUN, and TURN are a suite of 3 inter-related protocols that combine to provide a complete media traversal solution for NATs. The following sections provide details of each component part.
4.2.3.1. STUN
Session Traversal Utilities for NAT or STUN is defined in RFC 5389> [RFC5389]. STUN is a lightweight tool kit and protocol that provides details of the external IP address/port combination used by the NAT device to represent the internal entity on the public facing side of NATs. On learning of such an external representation, a client can use it accordingly as the connection address in SDP to provide NAT traversal. Using terminology defined in "NAT Behavioral Requirements for Unicast UDP" [RFC4787], STUN does work with Endpoint-Independent Mapping but does not work with either Address-Dependent Mapping or Address and Port-Dependent Mapping type NATs. Using STUN with either of the previous two NAT mappings to probe for the external IP address/port representation will provide a different result to that required for traversal by an alternative SIP entity. The IP address/ port combination deduced for the STUN server would be blocked for RTP packets from the remote SIP User Agent. As mentioned in Section 4.1.2, STUN is also used as a client-to- server keep-alive mechanism to refresh NAT bindings.
4.2.3.2. TURN
As described in Section 4.2.3.1, the STUN protocol does not work for UDP traversal through certain identified NAT mappings. 'Traversal Using Relays around NAT' is a usage of the STUN protocol for deriving (from a TURN server) an address that will be used to relay packets towards a client. TURN provides an external address (globally routable) at a TURN server that will act as a media relay that attempts to allow traffic to reach the associated internal address. The full details of the TURN specification are defined in [RFC5766]. A TURN service will almost always provide media traffic to a SIP entity, but it is RECOMMENDED that this method would only be used as a last resort and not as a general mechanism for NAT traversal. This is because using TURN has high performance costs when relaying media traffic and can lead to unwanted latency.
Top   ToC   RFC6314 - Page 12
4.2.3.3. ICE
Interactive Connectivity Establishment (ICE) is the RECOMMENDED method for traversal of existing NATs if Symmetric RTP and media latching are not sufficient. ICE is a methodology for using existing technologies such as STUN, TURN, and any other protocol compliant with Unilateral Self-Address Fixing (NSAF) [RFC3424] to provide a unified solution. This is achieved by obtaining as many representative IP address/port combinations as possible using technologies such as STUN/TURN (note: an ICE endpoint can also use other mechanisms (e.g., the NAT Port Mapping Protocol [NAT-PMP], Universal Plug and Play Internet Gateway Device [UPnP-IGD]) to learn public IP addresses and ports, and populate a=candidate lines with that information). Once the addresses are accumulated, they are all included in the SDP exchange in a new media attribute called 'candidate'. Each candidate SDP attribute entry has detailed connection information including a media address, priority, and transport protocol. The appropriate IP address/port combinations are used in the order specified by the priority. A client compliant to the ICE specification will then locally run STUN servers on all addresses being advertised using ICE. Each instance will undertake connectivity checks to ensure that a client can successfully receive media on the advertised address. Only connections that pass the relevant connectivity checks are used for media exchange. The full details of the ICE methodology are in [RFC5245].


(page 12 continued on part 2)

Next Section