Internet Engineering Task Force SIP WG Internet Draft J.Rosenberg,J.Weinberger,H.Schulzrinne draft-ietf-sip-nat-01.txt dynamicsoft,Columbia U. November 21, 2001 Expires: May 2002 SIP Extensions for NAT Traversal STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract In this draft, we discuss how SIP can traverse existing, non-SIP aware NATs. Our approach is to make SIP "NAT friendly" with two minor extensions. The first allows for responses to UDP requests to go back to the source port of the request. The second allows a registrar to use the source IP address and port instead of the Contact in a REGIS- TER. 1 Introduction The problem of getting applications through NATs has received a lot of attention [1]. Getting SIP [2] through NATs is particularly trou- blesome. There are several ways to solve the problem. One of these is to embed an ALG in all NATs. However, this has not happened. The top commercial NAT products continue to be SIP-unaware. Even if SIP ALG J.Rosenberg,J.Weinberger,H.Schulzrinne [Page 1]
Internet Draft sip-nat November 21, 2001 support were added tomorrow, there is still a huge installed based of NATs that do not understand SIP. As a result, there is going to be a long period of time during which users will be behind NATs that are ignorant of SIP, probably at least two to three years. The SIP com- munity cannot wait for ubiquituous deployment of SIP aware NATs. Another solution is to ubiquitously deploy IPv6, in the expectation that this will eliminate the need for NATs. Whether this expectation is realistic or not is one question, but the timeframes for such deployment are long. Yet another solution is to use midcom [3], with a user agent or proxy controlling the firewall. This solution is, architecturally, much better than usage of ALGs, but will take even longer to ubiquitously deploy. Therefore, the approach taken is to make SIP "NAT Friendly" through some backwards compatible extensions. These extensions generally operate by informing a server to ignore an IP address present in the SIP message, and instead use the source IP address and port. This follows the recommendations of [4]. Of course, the harder problem is the traversal of the media streams through NAT. That problem is covered separately. 2 Reference Architecture Consider the standard SIP "trapezoid" of Figure 1. The client UA 1, is behind a NAT, NAT 1. It sends all requests to local outbound proxy 1. Those requests are forwarded to terminating proxy 2, which then sends them to the called party, UA 2, who is also behind a NAT. Getting SIP through in this configuration involves two parts. The first is getting the request from UA 1 to Proxy 1, and the response back. The second is getting the INVITE from Proxy 2 to UA 2, and the response back. The solution for the first problem is "Via Received Ports". This solution follows the usage of the received parameter in the Via header (which handles IP addresses), but for ports. The solu- tion for the second problem is the new Translate header, which allows a client to tell a registrar to ignore the Contact header, and instead register an address obtained from the IP address and port from the REGISTER request. The sections below describe these extensions in more detail. 3 Via Ports J.Rosenberg,J.Weinberger,H.Schulzrinne [Page 2]
Internet Draft sip-nat November 21, 2001 +-------+ +-------+ | | | | | Proxy |------------- | Proxy | | 1 | | 2 | | | | | / +-------+ +-------+ / \ / \ +------------------+ +------------------------+ .....+------------------+... ..+------------------------+.. . / NAT 1 . . NAT 2 \ . . / . . \ . . / . . \ . . +-------+ . . +-------+ . . | | . . | | . . | | . . | | . . | UA 1 | . . | UA 2 | . . | | . . | | . . +-------+ . . +-------+ . . Domain A . . Domain B . ............................ .............................. Figure 1: Reference Configuration The first problem with SIP traversal through NATs is sending a request from a client behind a NAT to a server on the outside (UA 1 to proxy 1). SIP specifies that for UDP, the response is sent to the port number in the Via header and the IP address the request came from. However, J.Rosenberg,J.Weinberger,H.Schulzrinne [Page 3]
Internet Draft sip-nat November 21, 2001 due to NAT, the port number in the Via header will be wrong. This means that the response will not be sent to the proper location. How- ever, with TCP, responses are sent over the connection the INVITE arrived on. This means that a response sent over the TCP connection will be received properly by a caller behind a NAT. Therefore, one solution for traversal of requests from inside to outside is to use persistent TCP connections. However, many VoIP endpoints do not sup- port TCP, so a UDP based solution is desirable. Our approach is to define a new Via header parameter, called the response port, encoded as "rport". This parameter is inserted by clients (which can be proxies or UACs) when they wish for the response to be sent to the IP address and port the request was sent from. The parameter is inserted with no value to flag this feature. When received at a server which understands this extension, the server (which can be a proxy or UAS) MUST insert the port the request was received from as the value of this parameter. If the Via maddr parameter is not present, that port MUST be used to send the response, instead of the port in the sent-by field. If the maddr Via parameter is present, the rport parameter is ignored for sending the response, and the procedures defined in [2] are used. response-port = ``rport'' [``='' 1*DIGIT] A client inserting the rport into the Via header MUST wait for responses on the socket the request is sent on, and MUST also list, in the sent-by field, the local port of that socket the request was sent from. The latter is mandatory for backwards compatibility. Consider an example. A client sends an INVITE which looks like: INVITE sip:user@domain SIP/2.0 Via: SIP/2.0/UDP 10.1.1.1:4540;rport This INVITE is sent with a source port of 4540 and source IP of 10.1.1.1. The request is natted, so that the source IP appears as 68.44.20.1 and the source port as 9988. This is received at a proxy. The proxy forwards the request, but not before appending a value to the rport parameter in the proxied request: INVITE sip:user@domain2 SIP/2.0 J.Rosenberg,J.Weinberger,H.Schulzrinne [Page 4]
Internet Draft sip-nat November 21, 2001 Via: SIP/2.0/UDP proxy.domain.com Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988 This request generates a response, which arrives at the proxy: SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.domain.com Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988 The proxy strips its top Via, and then examines the next one. It con- tains both a received param, and an rport. The result is that the follow response is sent to IP address 68.44.20.1, port 9988: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988 The NAT rewrites the destination address of this packet back to IP 10.1.1.1, port 4540, and is received by the client. This works fine when the server supports this extension, so long as there are no nats between the client and server. Consider a server that does not understand it. In this case, it will ignore the rport parameter, and send the following response to IP 10.1.1.1, port 4540: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.1.1.1:4540;rport As specified by SIP, this response is sent to the source IP of the request, and the port in the Via header. Since the client is listen- ing on 4540, the response is received correctly. In the case where the server does not support the extension, but there is a nat between the client and the server, the response is sent to the source IP and port in the Via, which will be dropped by the nat. This is the same behavior exhibited by SIP today. As a result, our extension is backwards compatible, in the sense that it always works at least as well as baseline SIP. When both sides J.Rosenberg,J.Weinberger,H.Schulzrinne [Page 5]
Internet Draft sip-nat November 21, 2001 support it, and there is a nat in the middle, traversal works correctly. For the response to always be received, the NAT binding must remain in existence for the duration of the transaction. Most UDP NAT bind- ings appear to have a timeout of one minute. Therefore, non-INVITE transactions will have no problem. For INVITE transactions, the client may need to retransmit its INVITE every 20 seconds or so, even after receiving a provisional response, in order to keep the binding open to receive the final response. Because of the increased network traffic generated to keep the UDP bindings active, it is RECOMMENDED that TCP be used instead, as it generates much less data. 4 Contact Translation The received port parameter will allow requests initiated from inside the NAT (and their responses), to work. However, getting requests from a proxy outside the NAT, to a host inside, is a different story. The problem has to do with registrations. In Figure 1, the callee, UA 2, will receive requests at that UA because it had previously sent a REGISTER request to the registrar, which is co-located with proxy 2. This registration contains a Contact header which lists the address where the incoming requests should be sent to. However, in the case of NAT, this address will be wrong. It will contain a domain name or IP address that is within the private space of domain B. Thus, the REGISTER might look like: REGISTER sip:B.com SIP/2.0 From: sip:ua2B.com To: sip:ua2B.com Contact: sip:ua2@10.0.1.100 This address is not reachable by the proxy. To solve this problem, we need two things. First, we need a per- sistent "connection" to be established from UA 2 to proxy 2. Secondly, we need a way for incoming requests destined for UA 2 to be routed over this connection. To address this first problem, clients have to send REGISTER requests over a TCP or TLS connection, or use UDP along with the response port parameter in the Via header. If TCP is used, this connection is kept J.Rosenberg,J.Weinberger,H.Schulzrinne [Page 6]
Internet Draft sip-nat November 21, 2001 open indefinitely. We further recommend that the proxy/registrar hold this connection in a table, where the table is indexed by the remote side of the transport connection. For UDP, the client holds on to the socket, and uses it for REGISTER refreshes and to receive incoming calls. The server also holds on to the "connection". In the case of UDP, that means that server stores the local IP/port that the request was received on, and indexes it by the source IP and port the request was sent from. When the proxy wishes to send a packet to some server at IP address M, port N, transport O, it looks up the tuple (M,N,O) in the table to see if a connection already exists, and then uses it. The NAT bindings are kept fresh through REGISTER refreshes (see Sec- tion 4.1). Now, a connection is available for contacting the user. However, this connection must be associated with sip:ua2@B.com. Unfortunately, it is not. Calls for sip:ua2@B.com are translated to sip:ua2@10.0.1.100, which does not correspond to the remote side connection used to send the REGISTER, as seen by the proxy. Thats because of NAT, which will make the remote side appear to be a publically routable address. To handle this problem, the proxy could, in principal, record the IP address and port from the remote side of the connection used to send a REGISTER. Then, it can create a Contact entry of the form sip:bob@[ip-addr]:[port], where [ip-addr] and [port] are the IP address and port of the remote side of the connection. However, this is assuming that the registration is for the purposes of connecting the address in the To field with the machine the connection is coming from. That may not be the intent of the registration. The registra- tion may be used to set up a call forwarding service, for example. As a result, it is our proposal that clients be allowed to explicitly ask a proxy to create a Contact entry corresponding to the machine a REGISTER is sent from. To do that, the UA inserts a Translate header into the request. This header contains the URL (which MUST be one of the Contact URLs) that is to be translated, along with a parameter that indicates the type of NAT the client is behind. translate-header = ``Translate'' ``:'' ``<'' addr-spec ``>'' [``;'' ``nat'' ``='' nat-types] nat-types = ``sym'' | ``cone'' If a registrar receives a REGISTER request with a translate header, it MUST find the matching Contact header (using standard URL matching rules [2]) in the REGISTER request, and MUST replace the host value J.Rosenberg,J.Weinberger,H.Schulzrinne [Page 7]
Internet Draft sip-nat November 21, 2001 with the IP address in the received parameter of the bottom-most Via, if present, else the host from the Via sent-by field. The port of the Contact MUST be replaced with the rport parameter from the bottom- most Via, if present, else the value from the sent-by field, if present, else 5060. This is the actual Contact stored in the regis- tration database, and returned to the client in the response. Using the bottom-most Via to obtain the source IP and source port of the client allows for the case where the registrar and the outbound proxy are not co-located. If no matching Contact was found in the REGISTER, the Translate header is ignored. The nat-type parameter is an optional parameter that tells the regis- trar what type of NAT the client is behind. This information is very helpful for some faul tolerance and scalability scenarios, described below. The means by which the client can determine which type of nat it is behind are outside the scope of this specification. Any 2xx response to a request that contained a Translate header, and resulted in a translation (because there was a matching Contact), MUST include a Translate header in the response. This header MUST contain the translated URL. Of course, the same URL will also appear amongst the Contacts in the 2xx. The Translate header in the 2xx is needed so that a UAC can determine the value of the translated Con- tact when there are more than one registered contacts. Consider once more the architecture of Figure 1. The callee has an IP address of 10.0.1.100. It sends a REGISTER from port 2234 to port 5060 on the proxy. This connection goes through the NAT, and the source address is rewritten to 77.2.3.88, and the source port to 2937. The registration looks like: REGISTER sip:ua2@Y.com SIP/2.0 From: sip:ua2@Y.com To: sip:ua2@Y.com Via: SIP/2.0/UDP 10.0.1.100;rport Translate: sip:ua2@10.0.1.100:2234 Contact: sip:ua2@10.0.1.100:2234 The proxy Y then stores the socket the request was received on into a table, indexed by the source port: (77.2.3.88,2397,UDP) -> [reference to UDP socket] J.Rosenberg,J.Weinberger,H.Schulzrinne [Page 8]
Internet Draft sip-nat November 21, 2001 It fills in the rport parameter, and adds the received parameter, to the top Via. It also translates the Contact header to sip:ua2@77.2.3.88:2397, and stores that in the registration database. It then responds to the REGISTER: SIP/2.0 200 OK From: sip:ua2@Y.com To: sip:ua2@Y.com Via: SIP/2.0/UDP 10.0.1.100;rport=2397;received=77.2.3.88 Translate: sip:ua2@77.2.3.88:2397 Contact: sip:ua2@77.2.3.88:2397 This response is sent to 77.2.3.88:2397 because of the rport. The NAT translates this to 10.0.1.00:2234, which is then received by the client. Now, when an INVITE arrives for sip:ua2@Y.com, it is looked up in the registration database. The contact is extracted, and the proxy tries to send the request to that address. To do so, it checks its connec- tion table to an open connection to the IP address, port and tran- sport where the request is destined. In this case, such a connection is available, and the request is forwarded over it. Because it is over a connection with an existing NAT binding, it is properly routed through the NAT. The response from the callee is also routed over the same connection. If the UA is behind a symmetric NAT, the proxy that the user is con- nected to needs to record route incoming and outgoing INVITE requests. 4.1 Refresh Interval Since the connection used for the registrations is held persistently in order to receive incoming calls, the NAT binding must be main- tained. To avoid timeout, data must traverse the NAT over that con- nection with some minimum period. When UDP is used, registrations will need to be refreshed at least once every minute. The clients SHOULD include an Expires header or parameter with this value. For TCP, a longer interval can be used. 10 minutes is RECOMMENDED. To test whether the interval is short enough, proxy servers MAY attempt to send OPTIONS requests to the client shortly before the registration expires. If the OPTIONS requests generates no response at all, the server SHOULD lower the value of the Expires header in the next registration. Servers SHOULD cache and reuse the largest J.Rosenberg,J.Weinberger,H.Schulzrinne [Page 9]
Internet Draft sip-nat November 21, 2001 successful refresh interval that they discover for a given Contact value. 4.2 Routing to the Ingress Proxy A complication arises when a domain supports multiple proxy servers. Consider the scenario shown in Figure 2 A user joe in domain.com is behind a NAT. In DNS, domain.com contains an SRV entry that points to three servers, 1.domain.com, 2.domain.com and 3.domain.com. When the user registers, they will resolve domain.com to one of these. Assume its 1.domain.com. As a result of this, the connection state is stored proxy 1. In the case of TCP, this connection state is important. Unless calls for joe@domain.com arrive to proxy 1, they won't be routable to the UA. In the case of UDP, whether it is important or not depends on the type of NAT the user is behind. One type of NAT, which we call "sym- metric", treats UDP much like TCP. When A sends a request from inside to B on the outside, UDP messages back to A must come from B, with a source port equal to the destination port of messages from A to B. In the other case, which we call "cone", which is described in [5], UDP messages back to A can have any source port and IP address. If the user is behind a NAT that operates in cone mode, any of the proxies in the proxy farm will be able to reach the customer through the NAT. All will send requests to the public IP address and port binding created by the NAT, but with different source IP addresses and ports. Since source addressing doesn't matter, things work well. In this case, the proxy need not even store connection state as described in Section 4. If the user is behind a NAT that operates in symmetric mode, calls to the user must come in through the proxy that the user registered to. In order to enable this, we recommend that the location server data- base store not only the contact, but the proxy that the user con- nected to. When a call comes in for that user, the proxy receiving the INVITE looks up the user in the database. The database entry indicates the proxy the user is connected to (call this the connected proxy). If the connected proxy is not the proxy which received the INVITE, the proxy that received the INVITE uses a route header to force the call through the connected proxy. In the case where joe registered at proxy1, and the incoming INVITE arrived at proxy 2, the request sent by proxy 2 would look like: INVITE sip:proxy1.domain.com SIP/2.0 J.Rosenberg,J.Weinberger,H.Schulzrinne [Page 10]
Internet Draft sip-nat November 21, 2001 -- // \\ / \ | DB | | | \ / \\ // -- +-----+ +-----+ +-----+ | | | | | | domain.com |Proxy| |Proxy| |Proxy| | 1 | | 2 | | 3 | +-----+ +-----+ +-----+ +-------------------------+ | NAT | +-------------------------+ +-----+ | | |UA | | | +-----+ Figure 2: Multiple Proxy Configuration J.Rosenberg,J.Weinberger,H.Schulzrinne [Page 11]
Internet Draft sip-nat November 21, 2001 Route: sip:joe@22.1.20.3:3038 This request will first go to proxy1, and from there, over the exist- ing connection to joe. An alternate approach, instead of Route headers, is to simply have the proxy which received the request forward it to the one that the user registered with, without modifying the request URI. This will cause the receiving proxy to perform the location server lookup a second time, which is inefficient. However, it does not rely on the usage of pre-loaded routes. The differing proxy behaviors for symmetric and cone NATs explains the presence of the nat-type attribute in the Translate header. Assuming the client can determine which type it is behind it can sim- ply inform the proxy, allowing it to take the proper action. 4.3 INVITE Usage The 200 OK response to the REGISTER request contains the SIP URL that the registrar placed into the database. This address has the impor- tant property that it is routable to the client from the proxy on the public side of the NAT. As a result, the client needs to place this URL as the Contact header in its INVITE requests and 2xx responses to INVITE, so that it can be reached from the proxy on the outside. 5 Security Considerations Arguably, the usage of receive ports and the Translate header improve security. In normal SIP usage, a rogue UA or proxy can send registra- tions that contain Contacts that point to a different phone. Or, they can send an INVITE with a Via header that contains the echo port, or some other port, on the machine. These can be used to launch attacks. The receive port and Translate header insure that only the entity that sent the requet, is the one to receive further messages. 6 Acknowledgements The authors would like to thank Rohan Mahy for his comments and con- tributions to this work. 7 Changes since draft-ietf-sip-nat-00 o Described resolution of conflict between rport and maddr parameter. J.Rosenberg,J.Weinberger,H.Schulzrinne [Page 12]
Internet Draft sip-nat November 21, 2001 o Specified that the registrar use the bottom-most Via rport and received parameter to obtain the source IP and port. o Specified that the Translate header needs to appear in 2xx REGISTER responses. 8 Changes since draft-rosenberg-sip-entfw-02 o Split entfw into three. This is piece 1, which covers the pure SIP extensions. o Changed syntax of Translate header. Allow any URL type, and require usage of angle brackets to distinguish URL from header parameters. o Clarified that record-routing of INVITE at the proxy is not needed if UDP is used and the client is behind a full cone NAT. Full Copyright Statement Copyright (c) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 9 Author's Addresses J.Rosenberg,J.Weinberger,H.Schulzrinne [Page 13]
Internet Draft sip-nat November 21, 2001 Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: jdrosen@dynamicsoft.com Joel Weinberger dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: jweinberger@dynamicsoft.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 email: schulzrinne@cs.columbia.edu 10 Bibliography [1] M. Holdrege and P. Srisuresh, "Protocol complications with the IP network address translator (NAT)," Internet Draft, Internet Engineer- ing Task Force, Oct. 2000. Work in progress. [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. [3] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. Rayhan, "Middlebox communication architecture and framework," Internet Draft, Internet Engineering Task Force, Oct. 2001. Work in progress. [4] D. Senie, "NAT friendly application design guidelines," Internet Draft, Internet Engineering Task Force, Mar. 2001. Work in progress. [5] J. Rosenberg, R. Mahy, and C. Huitema, "Traversal using nat relay (turn)," Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. J.Rosenberg,J.Weinberger,H.Schulzrinne [Page 14]
