SIP: NAT and FIREWALL TRAVERSAL Amit Bir Singh Department of Electrical Engineering George Washington University ABSTRACT The growth of market for real-time IP communications is a big wave prevalent in industry. Voice over Internet Protocols (VoIP) is a group of technologies and protocols that allow voice communication over the Internet. This technology has gained popularity in recent years but still it has several problems associated with the traversal across the network. Session Initiation Protocol (SIP) is one of the most accepted signaling protocols for VoIP technologies. Traversal of SIP through NAT and Firewall is a challenge being faced. In this paper, I have discussed issues concerning such traversal along with various solutions available for successful SIP deployment in today s network. I have discussed feasibility of such techniques, their limitations and positioning in network. I. INTRODUCTION Voice over IP is an amazing technology for today s industry and home customers because of low price, easy installation and maintenance as compared to the old telephone system. It increases the efficiency already existing IP network which is used to carry voice communication. At the same time, there are several issue related to successful deployment of VoIP such as security. Also, VoIP needs to establish successful connection through SIP to begin exchange of media. Traversal of SIP through Network Address Translators (NAT) is a hindrance for SIP deployment. Also when we use VoIP in home networks which are commonly protected by Firewall, it causes a serious problem for SIP based VoIP. In short, these problems are discussed in following main parts: NAT problem for SIP, NAT problem for media and the Firewall problem for SIP signaling. Several solutions have been proposed to solve these prevalent problems. These solutions have limitations attached to them. Some of them are provider-centric and others are not sufficient to resolve these issues effectively. I have presented many of these solutions in this paper, their limitations and relevant positioning in the network. This paper is structured as follows: In the next section I have explained basics of SIP, VoIP and its deployment. In the third section I have discussed the Firewall and different types of NATs. In the fourth section, I have explained NAT and Firewall traversal issues for SIP. In fifth section, I have discussed most of the mechanisms deployed for traversal issues. In sixth section, I have discussed positioning of various solutions in a network and in the last section I have discussed my conclusion based on study of these topics.
II. SIP and VoIP DEPLOYMENT Session Initiation Protocol (SIP) [2] is a signaling protocol used for establishing sessions in an IP network. Over last couple of years, VoIP communication systems have adopted SIP as a choice for signaling over H.323. SIP is designed in such a way that it is compatible with pre existing Internet protocols and it offers great amount of flexibility. The path between SIP clients is managed by SIP proxy/registrar servers. SIP does not build whole communication system itself, whereas it s a component which works with other protocols to support complete architecture. Other protocols include Real-time Transport protocol (RTP) for transmission of media across Internet Protocols, Session Description Protocols (SDP) for describing sessions and various other protocols. SIP provides interoperability by binding SIP functions to existing protocols. SIP has 3 elements: User Agents (UA) which is VoIP endpoints, Registrars are servers that keep track of users and SIP proxy servers are routers that forward SIP requests and responses across the network. SIP session needs an INVITE request to be sent by a user agent. This is shown in fig 1. There are two possible deployment scenarios for SIP proxy servers Private and Public. In private scenario as shown in figure 3, SIP proxy server resides in the private network and is separated from the public network by a NAT/Firewall. Such scenario is used mostly in home and small enterprises. In public scenario as shown in figure 4, SIP proxy server is deployed in the public network. III. NATs AND FIREWALLS Network Address Translation (NAT) is a method of mapping private IP addresses to the public IP addresses in order to route packets between two realms of addresses. NATs are functional at routers and they create two spaces Inside (private) and Outside (public). All packets which are traversing between these spaces have to pass through NATs. They have the ability to make changes in packets before forwarding it to other side of network. Routers can route the traffic between private workstations inside any organization but when we need to access resources those are present on Internet we need to have a public address because private addresses are not routable outside to the public addresses. A Firewall is a device which acts as a packet filtering agent. It protects private network from the public network. It consists of set of rules that define the access between private (inside) and public (outside) network. It denies unwanted transmissions between these two network spaces and allows the desirable packets to flow freely which have been allowed by firewall rules. We can modify these rules as per our requirements. Figure 1: SIP INVITE request [9]
NAT Description When a packet goes from inside network to outside network, NAT router changes the source IP address with the public address and for an incoming packet from the public network, as the packet passes through the NAT router, destination IP address is changed from public IP address to Private IP Address of a local machine. This phenomenon is dependent on bindings which are created when packets from private network go towards public network, a public IP address is mapped dynamically from the IP address pool which acts as a source IP address. These mapping entries are stored in a table. These entries are used for allowing packets coming from public network towards private network. NAT are classified into four types: Symmetric (S), Full Cone (FC), Restricted Cone (RC) and Port restricted cone (PRC). They are shown in figure 2. Source IP address and port number are S (ip) and S (p) respectively, Destination IP address and port number are D (ip) and D (p) respectively. NAT router public IP address and port numbers are N (ip) and N (p). Once a Source S sends a packet to Destination, S (ip) and S (p) are mapped to N (ip) and N (p). [4] if S has already sent packet to B (ip) and B (p). Symmetric NAT (S): Only Incoming packet only from D (ip) and D (p) destined for N (ip) and N (p) will be forwarded to S (ip) and S (p). Full cone NAT (FC): Any incoming packet from any public address destined for N (ip) and N (p) is routed to S (ip) and S (p). Restricted Cone NAT (RC): Incoming packet from D (ip) destined to N (ip) and N (p) is forwarded to S (ip) and S (p). Other external host may be B (ip) can forward packet same way if S (ip) and S (p) have forwarded packet to B (ip) already. Port of D and B can be any. Port Restricted Cone (PRC): Incoming packet only from D (ip) and D (p) destined for N (ip) and N (p) will be forwarded to S (ip) and S (p). It is also possible for another host B but Figure 2: NAT classification [11] If Source sends another packet to B (ip) and B(p), NAT router will map it to different port number N (p) instead of N (p) and packets from
Destination D (ip) and D (p) have to be addressed to N (ip) and N (p) in order to be routed to S (ip) and S (p). IV. NAT AND FIREWALL HINDRANCES FOR SIP Incoming traffic from public network: SIP is a request response phenomenon. In case of public deployment of SIP, when the SIP proxy server is on public domain and User agent is in private network space, signaling message response coming from server to the client will be blocked by the NAT. SIP Registration Issue [4]: In private VoIP deployment as shown in figure 3, when UA 2 and UA 3 tries to register themselves with the SIP proxy server which is in private domain network, the request is sent to the private network from outside public network. This request will be blocked by the firewall and hence UA 2 and UA 3 won t be able to register themselves unless some NAT/Firewall traversal mechanism is deployed. SIP Session Establishment Issue [4]: Invite request is sent between user agents to establish a session between them. Via header as shown in figure 1 is used to indicate the intermediate protocols and recipients between user agents and the proxy servers. If UA 1 tries to establish connection between UA 2, it sends its own IP address in the via header to the server, to which SIP proxy server also adds its own private IP address on top of it. This request reaches the UA 2. When a response is sent back to UA 1, it uses the private IP address in via header, so this response reaches proxy server and not UA 1. So, as a result session is not established between UA 1 and UA2. Also in public deployment of SIP as shown in figure 4, session establishment requests cannot reach user agents in the private network because of the NAT/Firewall. SIP real time media issue: Once a SIP connection has been established between user agents, they began to exchange real time media through RTP. The user agents who are inside a private network send their private IP address in the Invite requests because they do not know that they have been associated with a public IP address. So the media that is flowing from UA 1 (private network) to UA 2 (public network) reaches UA 2 but media from UA 2 does not reach UA 1 because it will be sent directly to private IP address of UA 1. This results in simplex mode of communication. Figure 3: VoIP private scenario deployment
Figure 4: VoIP public scenario deployment V. NAT/FIREWALL TRAVERSAL SOLUTIONS APPLICATION LAYER GATEWAY (ALG s) Application layer gateways are components that customize NAT traversal filters for address and port translation in a NAT or a Firewall. In order to establish SIP connection successfully, [6] ALG s modify the affected fields of the SIP message. When UA 1 tries to establish a connection between UA 2, it sends an INVITE request as shown in figure 1. In this request, INVITE, via, from, to and contact are directly affected fields whereas call id and content length are indirectly affected fields. ALG translates the direct affected fields which are address related fields according to basic NAT rules. It maps private addresses and ports to the public ones by overriding the NAT policy. This mapping is a critical step and varies for different SIP messages as it depends upon the number of times a particular SIP message traverse NAT. The disadvantage of this technique is that it is less scalable and NAT rules need to be added through the NAT whenever necessary. It reduces the speed of the network. UNIVERSAL PLUG AND PLAY (UPnP) This is a protocol designed by Microsoft for home and small offices use for [5] control of devices in a network. If we use UPnP as a SIP traversal mechanism, SIP user agents get control of the NAT/Firewall device to control the mapping between private-public addresses and port numbers. The disadvantage of this technique is that it is vulnerable to security threats in a network as it exposes the network to public domain as NAT and Firewall is controlled by the application users/clients. Also many user agents do not support this protocol. So mainly due to security threats this protocol could not be deployed in enterprises. SIMPLE TRAVERSAL OF UDP THROUGH NAT (STUN) Simple Traversal of UDP through NAT (STUN) [1] is a protocol which is used by devices behind the NAT or Firewall for successful routing of packets. STUN has two elements: STUN client and a STUN server as shown in figure 5 [8]. UDP requests are sent by the STUN client to the STUN server to get its public address mapped with its private IP address. STUN server is usually on the public network side. When the UDP request reaches the STUN server [12], the STUN server stores the source IP address of the message as it will be the mapped public address for the private IP address of the STUN client. The STUN server sends this information about the source IP
address and port number to the STUN client. If this IP address is different from the local IP address of the STUN client, this implies that the client is behind the NAT and client uses several more STUN requests to other STUN servers to gather information about the type of NAT. The disadvantage of this mechanism is that it does not works with Symmetric NAT (S) which creates different mappings for different VoIP end devices and as incoming traffic to client is allowed by the NAT/Firewall, it exposes the STUN client to the attacks from the public network. TRAVERSAL USING RELAY NAT (TURN) Traversal using Relay NAT (TURN) [3], [4] was proposed to allow SIP data to flow even across the symmetric NAT. It connects the SIP client to a peer beyond the TURN server. This mechanism provides a public IP address which acts as a relay between two interacting SIP endpoints. When a TURN client sends a request to TURN server, it remembers the source IP address and port number and returns a public IP address to the client. Now in response, client requests the other peer to send real time data to be sent on this new public IP address and port. The incoming RTP data from second peer passes through the TURN server and this server records the source IP address of the RTP data. This way, TURN server has the source IP addresses and port numbers for both of the VoIP endpoints. The chief disadvantage of this mechanism is that it consumes lot of bandwidth due to data being transmitted over same link. It also has scalability problem and also affects real time media quality by introducing long delays in transmission. Figure 5: The STUN server model [12] SESSION BORDER CONTROLLER (SBC) Session Border Controller (SBC) [10] is a device that enables SIP signaling and SIP media to flow between private and public network in a VoIP deployment. [5] SBC signaling and SIP media servers are inserted between signaling data and media path. They just affect the data for particular SIP connection and not other data flowing through the NAT. SIP signaling server modifies the header information in order to have successful connection between user agents and proxy servers. They also establish successful mapping between private and public addresses. SBC have several advantages as they provide security features [7] to the network by encrypting signaling data and media. It also provides Quality of Service [7]. Moreover SBC s can provide communication between various signaling standards and also different codec in case of transmission of real time media. At the same time, SBC s have some disadvantages. Some SBC s increase the path of media length even in case of devices present in same sub network. Also SBC s provide a provider-centric solution for NAT traversal which is not always desirable.
SIP PROXY BASED FIREWALLS This technique adds high level of security against attacks to the voice communication. It does not keep the ports opened for transmission of media whereas it does so dynamically. This provides much more security as ports are closed as soon the transmission is complete. This technique also provides encryption to media. VI. POSITIONING OF SOLUTIONS It is a crucial decision for deployment of NAT traversal mechanism in your network. It depends upon the security and flexibility level we demand from our network [13]. If we want a network with highest level of security like in an enterprise can be obtained by using SIP proxy based firewalls which protects the signaling data as well as media content of the VoIP communication. If we need a little lower security than an enterprise, we may deploy Session Border Controller (SBC s) which is a provider centric solution. If we have least security concerns about our network and we are willing to risk our network, we may deploy STUN, TURN or UPnP in our home or small office network. VII. CONCLUSION In this paper, I have discussed basic types of NAT and the issues which NAT and Firewall introduces in successful traversal of SIP signaling and media. Then, I moved ahead with discussing the solutions adopted at different levels for NAT and Firewall traversal of SIP. Several solutions exist today and they have a place at some level of network setup depending upon the security concerns and flexibility demands of the network. The choice is of the organization or an individual who wish to use SIP based VoIP communication techniques. In case of an enterprise where security cannot be compromised, SIP proxy based firewall replaces STUN, TURN and UPnP. VIII. REFERENCES [1] J. Rosenberg et al,. STUN Simple Traversal of User Datagram Protocol through Network Address Translators (NAT s), RFC 3489, March 2003. [2] M. Handley et al,. SIP: Session Initiation Protocol, RFC 3261, June 2002. [3] J. Rosenberg, Traversal using Relay NAT (TURN), Sept 2005. [4] Hechmi Khlifi, Jean-Charles Gregoire and James Phillips, VoIP and NAT/Firewalls: Issues, Traversal Techniques, and a Real-World Solution Universite du Quebec, July 2006 IEEE Communication Magazine. [5]Mihai Aurel Constantinescu, Doina Oana Cernaianu and Victor Croitoru, NAT/Firewall Traversal for SIP: Issues and Solutions, 2005 IEEE. [6] Peng Xuena, SUN Jinshan, ZHAO Hong, LI Dapeng, WEN Yingyou, An ALG-based NAT Traversal Solution for SIP-based VoIP 2009 IEEE. [7]SessionBorderController http://en.wikipedia.or g/wiki/session_border_controller [8] http://www.voip-info.org/wiki/view/stun [9] SIP Header, http://sipandvoip.com/voipprotocols/sip-protocol/sip-header/ [10]SBC shttp://en.wikipedia.org/wiki/session_ border_controller [11]NAThttp://en.wikipedia.org/wiki/Network_ address_translation [12]STUN-serverhttp://msdn.microsoft.com/enus/library/ee480411(v=winembedded.60).aspx [13] Solving the Firewall/NAT Traversal Issue of SIP: Who Should Control Your Security Infrastructure? Ingate Systems