The SIP-Based System Used in Connection with a Firewall

Transcription

1 The SIP-Based System Used in Connection with a Firewall Peter Koski, Jorma Ylinen, Pekka Loula Tampere University of Technology, Pori Pohjoisranta 11 A, P.O.Box 300, FIN Pori,Finland peter.koski@tut.fi, jorma.ylinen@tut.fi, pekka.loula@tut.fi Abstract Different methods, such as ALG, STUN, TURN and FCP have been proposed for using SIP together with firewalls and NAT. The most suitable solution has to be determined in every situation. Some of these methods cause more network traffic and capacity requirements, while others require support from the clients being used in the network. In this paper a system which makes it possible to offer SIP service to customers behind NAT without making any changes to firewalls is presented. The system is based on an RTP proxy and a SIP server, which modifies SIP messages. 1. Introduction SIP is an application layer control protocol which is used to establish, modify and terminate multimedia sessions [1]. The sessions can contain various forms of real-time data such as voice, video or instant messages. SIP is a simple text-based protocol used only for signaling, actual data is transferred using Real Time Protocol (RTP) [2]. The usage of NATs causes problems for many applications. How applications can be designed to be NAT friendly is described in [3]. One of the most important things is that used IP addresses and port numbers are not transferred inside the application layer. SIP, however breaks this rule. A system based on SIP protocol transfers related parameters such as network addresses and port numbers at the application level connection. Extra problems occur because of separate media transport. In [ 4 ] possible solutions to the problems caused by NATs are discussed. 2. Methods and Systems 2.1. NAT types There are four different types of NAT, based on port mapping according to [5]. A full cone NAT is one where all requests from the same internal IP address and port number are mapped to the same external IP address and port number. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address and port number. A restricted cone NAT maps all requests from the same internal IP address and port number to the same external IP address and port number. To make a distinction from a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X. A port restricted cone NAT is like a restricted cone NAT, but the restriction concerns port numbers in addition to IP addresses. An external host can send a packet, with the source IP address X and source port number P, to the internal host only if the internal host had previously sent a packet to IP address X and port number P. A symmetric NAT is the most restrictive NAT. All requests from the same internal IP address and port number, to a specific destination IP address and port number, are mapped to the same external IP address and port number. If the same host sends a packet with the same source address and port number, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host SIP SIP is an individual component in a SIP-based system working together with other protocols, like RTP and Session Description Protocol (SDP) [6]. RTP

2 media is used to transfer real-time media and SDP is a description language used for describing the connection parameters. A SDP message consists of several lines of text, formed type=value. The operation of SIP is based on requests and responses. User agent servers (UAS) respond to requests created by user agent clients (UAC). UACs create the requests and UASes respond. According to [1] there are six methods; more methods may be defined by SIP extensions. The original six methods are described in Table 1. SIP request INVITE ACK OPTIONS BYE CANCEL REGISTER 2.3. SIP Components Table 1. SIP requests Description Session setup Acknowledgement of final response to INVITE Query of options and capabilities Session termination Pending session cancellation Registration of a user s URL The primary SIP components are user agents (UA), servers and location services [1,7,8]. User agents are end devices and they are divided into two logical parts: user agent clients (UAC) and user agent servers (UAS). A UA can also be a gateway to another network, for example Public Switched Telephone Network (PSTN). A registrar accepts REGISTER requests and updates the information received in those requests into a location service. A registrar server accepts only REGISTER requests; all other requests are responded to by a 501 Not Implemented response. In a registration request, the To header contains the name of the resource being registered, and the Contact headers contain the alternative addresses or aliases. A SIP proxy receives a SIP request from a user agent or another proxy and forwards or proxies the request to another location. Primarily a proxy server is used for routing; its commission is to ensure that a request is sent to another entity closer to the targeted user. SIP proxies can be either stateful or stateless; a stateful proxy is a logical entity that maintains information about requests and responses received in the past. The stored information is used in processing future requests and responses. A stateless proxy server processes all the SIP requests and individually based responses purely on the message contents. There is no information stored in a server. A stateless proxy has no memory of any requests or responses it has sent or received. A redirect server receives a request, but instead of forwarding requests, a 3xx response is returned to the originator of the request provided the request is other than CANCEL. The 3xx response includes an alternative address or addresses for user location gathered from the location service. After receiving a 3xx response the originator will make a new request based on the addresses in the received 3xx response SIP, NAT and Firewalls Below is an example of an INVITE message sent behind the NAT. The fields containing unroutable addresses are in bold text. Via: SIP/2.0/UDP :5060 From: <sip:9003@ ;user=phone>;tag= To: <sip:9002@ ;user=phone> Call-ID: @ CSeq: 1 INVITE Contact: <sip:9003@ :5060;user=phone;transport=udp> Content-Length: 282 Content-Type: application/sdp v=0 o= IN IP s=cisco 7905 SIP Call c=in IP m=audio RTP/AVP a=rtpmap:0 PCMU/8000/1 The first problem occurs when trying to send a response back to the originator. The response is sent to the private address included in the Via header. The response cannot be routed in a public network because of the private network address. This problem can be solved directly with SIP protocol. According to [1] a server must check the uppermost address in the Via header. If the address differs from the packet source address or there is a domain name, the server must insert the source of the packet into the Via header using a received parameter. Below are two examples about the usage of a received parameter. The first example represents a message sent behind a NAT. In the second example the message after the server has inserted a received parameter to the INVITE message is illustrated. Via: SIP/2.0/UDP :5060 Via: SIP/2.0/UDP :5060;received=

3 The received parameter makes it possible to insert only an IP address but no port number. In the case of Network Address Port Translation (NAPT), the port number used by NAT in a public network also has to be known. There is an extension called rport for indicating a source port [9]. Below is an example of using a rport parameter together with a received parameter. Via: SIP/2.0/UDP :5060;received= ;rport=8529 An address in the Contact header is used for subsequent requests [1]. The private network address causes the request not to be routed correctly. This problem can be solved using a permanent TCP connection instead of the Contact header [7]. The third problem occurs when sending RTP packets to a client behind a NAT device. The earlier INVITE example includes a SDP message containing connection information for the RTP media transport. A private network address in the c field causes RTP media packets not to be routed from a public network to the private network. One possible solution to this problem is symmetric media. Symmetric media will work only when one party is behind NAT and the other is in a public network. The operating principle is as follows: the RTP media packets are sent back to the originator using the same address and port number as were received, instead of the connection information contained in a SDP message. If an RTP packet was received in the public network with address X and port P, then RTP packets can be sent to the private network using address X and port P as a packet destination. Clients must ignore the connection information included in the SDP message. Most of the SIP clients nowadays support symmetric media. Symmetric media does not work when both parties are behind different NAT. The reason for that is simple: clients cannot reach each other, because there are no bindings between a private and public network in the NAT and so it is impossible to send packets from the public network to the private network. While both clients are behind different NATs, an RTP proxy outside both NATs must be used. Different methods have been developed to get SIP working in connection with firewalls and NATs. An Application Layer Gateway (ALG) is a SIP and RTP proxy trusted by a firewall [7]. An ALG can be connected, for example, to the De-Militarized Zone (DMZ). The firewall will pass only the SIP and RTP traffic from and to the address of an ALG; all other SIP and RTP packets are abandoned. An ALG is capable of modifying packets, including private network addresses, to be routable in a public network. All SIP related traffic, including RTP media, must be transferred via ALG to make a call possible. An alternative for an ALG is a Firewall Control Proxy (FCP), which communicates with the firewall or NAT [7]. An FCP reads the IP addresses and port numbers used in transferring RTP media between clients from SIP messages. An FCP asks the firewall to change the firewall rules to allow the RTP transmission between the clients. After that an FCP will maintain NAT bindings and modify SDP messages so, that it is possible to transfer the RTP media directly between two clients. After sending the BYE message the opened ports are closed and NAT bindings are removed. Simple Traversal of UDP through NATs (STUN) is a simple text based protocol used to discover the NAT type and the IP addresses and ports used by NAT in the public network [5]. STUN requires support from clients. The operation of STUN is shown in Figure 1. STUN clients in a private network discover the NAT presence and being in a public network type from the STUN server. The STUN server responds with the IP address and port used in the public network by NAT. The SIP user agent supporting STUN includes the IP address and port notified by STUN server. Private address :5060 SIP client with STUN support :5060 NAT bindings Public address :12765 NAT Destination : :5060 BindingRequest Binding Response Register 200 OK Figure 1. STUN operation STUN server :3478 SIP server :5060 STUN assumes that all the packets coming from the same private IP address and port are mapped to the same public IP address. In the case of symmetric NAT the bindings are dependent on destination addresses and ports and that causes STUN not to work with symmetric NAT. Traversal Using Relay NAT (TURN) [10] has been developed for solving the problems that occurred with STUN in connection with symmetric NAT. The operation principle of TURN is shown in Figure 2.

4 Private network TURN supporting SIP UA FW/NAT Public network TURN Server Figure 2. TURN SIP UA SIP Server TURN RTP SIP TURN causes more network traffic because all traffic is transferred via a single point. Interactive Connectivity Establishment (ICE) [11] uses several methods, such as STUN and TURN, to make NAT traversal possible. ICE chooses the most suitable method in different NAT scenarios. In [12] is represented Triggering Address Bindings on NAT (TAB). ICE uses TURN is some situations not necessarily needed. TAB is experimented to establish the shortest paths between SIP clients without modifying the existing NAT devices. PSTN with ISDN PRI and to the public network with a network connection. The hardware based SIP phones are Cisco CP-7960G desk telephones and portable ZyXEL Prestige 2000W wireless phones based on WLAN technique. Ahead SIPPS client working in Windows operating systems is used as a software based user agent. The public network is separated into two private networks using NAT. A computer with two network cards acts as a firewall. Two different NAT scenarios were tested with this computer. Port restricted NAT was configured by Suse Linux 9.1 and Linux iptables. Packet Filter (PF) installed on FreeBSD 5.4 was used as a symmetric NAT. IP addresses are shared using Dynamic Host Configuration Protocol (DHCP). Another private network is constituted of a Wireless Local Area Network (WLAN) Access Point, which is configured to use NAT and DHCP. The NAT type is Full Cone NAT. The wireless phones use b network encrypted by Wired Equivalent Privacy (WEP). PSTN 3. Results Differences between methods used in NAT traversal are presented in Table 2. Performance requirements on ICE and TAB are dependent on NAT type. SIP/PSTN Gateway SIP server MySQL SER RTP proxy Cisco SIP Supported PC Public network WLAN Access Point Firewall Table 2. Different methods to pass NATs Performance Requirements NAT types requirements ALG Firewall All High FCP Firewall All Small ICE Client All Small/High RTP proxy STUN None All High Client Symmetric NAT not supported Small TAB Client All Small/High TURN Client All High In the project a possible solution to problems caused by NATs was demonstrated with a piloting environment. SIP Express Router (SER) is used as a SIP server, which is open-source software developed by Iptel.org community. SER makes it possible for firewalls and NATs to work together using a nathelper module and RTPproxy. In Figure 3 is a representation of the system architecture. A Cisco 2651 XM router, used as a SIP/PSTN gateway, is connected to the Zyxel b Zyxel 3.1. SIP server Cisco Cisco Private network Figure 3. System architecture The SIP server is a normal PC computer equipped with FreeBSD 6.0. In Table 3 the server applications installed to the computer acting as a SIP server are introduced. Table 3. Server applications installed on the SIP server Database MySQL v SIP server SIP Express Router (SER) v RTP proxy PortaOne RTPproxy v1.28 The MySQL database is used as a location service, including the location information of the users. The

5 1 2 3 database also includes user names and passwords required by the authentication done during registration. SER acts as a SIP server, which contains both registrar and redirect servers and SIP proxy. It is also possible to use SER as an ALG using the RTP proxy together with SER. PortaOne RTPproxy acts as a RTP proxy. The requirement for usage of RTPproxy is a SIP server capable of rewriting SIP messages. Communication with SER is carried out with UNIX sockets. SER modifies the SIP messages using the nathelper module, which can be installed during the basic installation of SER. The Nathelper module makes it possible to check if the request sent by the UAC is sent behind NAT by comparing the source address and port to the address and port seen in the Via header. If the addresses are different, the caller is behind NAT. Another way to verify the presence of NAT is by looking at the Contact header. A private network address means NAT is in attendance. The users must register themselves on the SER by sending a REGISTER request before making any calls. SER examines the user name and password from the location service. After successful authentication the presence of NAT is discovered. In the case of NAT, information concerning this is saved to the location service. Instead of the address in the Contact header the address in the request message is notified to the location service. In Table 4 a location table from the database is shown. The number 1 in the Flags field indicates the user client is behind NAT is in the public network but 9005 is behind a NAT. Table 4. Location table username contact flags 9002 sip:9002@ : sip:9005@ : There is an example of registrar in Figure 4. When sending a REGISTER request to the SIP server, NAT creates a binding between a private and public network. It is possible to send a response message from the public network to the private network using the address :1163. In that situation NAT can route the message from the public network to the private network based on the information in the NAT table. As seen in Table 4 the address used in the public network by NAT has been saved to the database as a contact address. SIP UA Private address :5060 Register 200 OK NAT table Public address :1163 NAT Destination address :5060 Register 200 OK Figure 4. Registering SER NAT keeps the bindings only as long as there is traffic between the SIP UA and SER regularly. The bindings are kept opened by sending small data packets to the client behind the NAT regularly Operation during call An example of a call created from the private network is in Figure 5. The caller in the private network makes a call to the public network. Below is the INVITE request sent by a caller behind the NAT. The SIP server compares the addresses in the Via header and the source address and port of request. The request is routed through the NAT. To make a call the RTP proxy must be used. INVITE sip: @ SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bK58659f1f From: " " <sip: @ >;tag=00115c40752 To: <sip: @ > Call-ID: 00115c40-752@ CSeq: 101 INVITE Contact: <sip: @ :5060> Content-Type: application/sdp Content-Length: 247 v=0 o=cisco-sipua IN IP s=sip Call c=in IP m=audio RTP/AVP a=rtpmap:0 PCMU/ NAT bindings Private address Public address : :1162 NAT SER, RTPproxy SIP signaling RTP Figure 5. SIP call from private network

6 Below is the INVITE request after modification. The modified headers are in bold text. The Contact header now contains the address and port used by NAT in the public network. There are also some modifications done in the SDP fields. Instead of the address , it includes the address The port reserved by the RTPproxy is 35080, which can be seen in the m field of the SDP message. In this way it is possible to transfer the RTP media through RTP proxy. INVITE sip: @ :5060 SIP/2.0 Record-Route: <sip: @ ;ftag=00115c40752;lr=on> Via: SIP/2.0/UDP Via: SIP/2.0/UDP :5060;rport=1162;received= From: " " <sip: @ >;tag=00115c40752 To: <sip: @ > Call-ID: 00115c40-752@ CSeq: 101 INVITE Contact: <sip: @ :1162> Content-Type: application/sdp Content-Length: 286 v=0 o=cisco-sipua IN IP s=sip Call c=in IP m=audio RTP/AVP a=rtpmap:0 PCMU/8000 When both SIP UAs are in the public network, a SIP server works like a normal SIP server. In this situation only signaling is completed through a SIP server and the RTP media is transferred directly between the SIP UAs. 4. Conclusion A SIP server with an RTP proxy is the most usable solution when SIP clients are behind NATs which cannot be modified or updated. STUN and TURN require client support and this may be a problem in some cases. A symmetric NAT causes problems for STUN and it also requires support from clients. TURN can be used with a symmetric NAT, but few clients support TURN. The usage of ALG or FCP requires modifications to firewalls and this can be done only by network administrators. A drawback is that RTP traffic must be transferred via a single point when SIP UAs are behind a NAT. RTP media traffic causes network traffic depending on the codec being used. The differences between codecs can be illustrated with an example of about one hundred full duplex calls with G.711a and G.729 codecs. A 12,8 Mbps bandwidth with G.711a codec is required whereas G.729 codec needs only 1,6 Mbps. G.729 requires less bandwidth but more processing power. Both processing and network bandwidth requirements can be solved by using load balancing. 5. References [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Spars, M. Handley, and E. Scooler, SIP: Session Initiation Protocol, IETF RFC 3261, June 2002 [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: A Transport Protocol for Real-Time Applications, IETF RFC 1889, January 1996 [3] D. Senie, Network Address Translator (NAT)-Friendly Application Design Guidelines, IETF RFC 3235, January 2002 [4] V. Paulsamy, and S. Chatterjee, Network Convergence and the NAT/Firewall Problems, Proceeding of the 36 th Hawaii International Conference on System Sciences, 2002 [5] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs), IETF RFC 3489, March 2003 [6] M. Handley, and V. Jacobson, SDP: Session Description Protocol, IETF RFC 2327, April 1998 [7] Sinnreich, H., and A. B. Johnston Internet Communications Using SIP, John Wiley & Sons Inc, 2001 [8] Johnston, A. B., SIP Understanding the Session Initiation Protocol, Artech House, 2001 [9] J. Rosenberg, and H. Schulzrinne, An extension to the Session Initition Protocol (SIP) for symmetric Response Routing, IETF RFC 3581, August 2003 [10] J. Rosenberg, R. Mahy, and C. Huitema, Traversal Using Relay NAT (TURN), Internet Draft, IETF, September 2005, Work in progress. [11] J. Rosenberg, Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols, Internet Draft, IETF, October 2005, Work in progress [12] Yun-Shuai Yu, Ce-Kuen Shieh, Wen-Shyang Hwang,Chien-Chan Hsu, Che-Shiun Ho, and Ji-Feng Chiu, An Efficient NAT Traversal for SIP and Its Associated Media sessions, International Computer Symposium, Taipei, Taiwan, 2004.