NAT/Firewall traversal:issues and solutions Fakher Atout Helsinki University of Technology fakher@cc.hut.fi Abstract Network Address Translators (NATs) and Firewalls are increasingly used in all type of networks because of various reasons. However, NATs and firewalls are limiting some kind of communications and they are known to cause problems for applications that carry IP addresses in the payload which are mainly related to multimedia communications and Voice over IP. Nowadays there are many techniques and solutions are used to allow those increasingly popular applications to work through NATs and Firewalls. Examples of such applications are NAT/Firewall NSLP, STUN, Application Level Gateways, CODO, etc. In this paper, we will take a look on a few exscinding and proposed solutions and study their features, advantages and shotrcomes. Special focus will be given to NSLP. KEYWORDS:NAT, Firewall, NSIS, NSLP, STUN 1 Introduction NATs and firewalls have become important elements in today s networks. They are providing solutions for many challenges such as IPv4 addresses. shortage and to protect networks security. To do so firewalls are checking all IP packets and based on preconfigured settings it may allow or drop those packets. In addition to that NAT is also changing the IP address/port and hides the private network topology. However, nothing comes without an expense. For example, NATs and Firewalls cause significant connectivity problems between nodes separated by NATs/Firewalls and preventing them form communicating with each other [6]. These connectivity problems are more severe in complex protocols that negotiate secondary flows of data on the application layer. This type of communication is found in many protocols such as SIP, H.323, etc. used in peer-to-peer applications [2]. To overcome this problem there are many approaches and solutions exist, some of those focus on Firewalls/NATs, others focus on applications themselves while others mix both. Most of the existing solutions are application specific or work for some type of protocols but not for others. However, there are some new approaches try to tackle the problem for all IP communications. But because these challenges are quite new, the standardization is still in the first phases. NAT/Firewall NSLP is one of the solutions that will be studies in this paper, it is developed based on Next Step In Signaling (NSIS) task force recommendations. 2 NAT/Firewall overview 2.1 Firewalls Firewalls can be defined as "a collection of components placed between two networks that collectively have the following properties: All traffic from inside to outside, and vice versa, must pass through the firewall. Only authorized traffic, as defined by the local security policy, will be allowed to pass. The firewall itself is immune to penetration."[1] Firewalls main role is to protect its "privater" network security by granting only the needed access based on preconfigured polices. They usually allow outbound traffic but block all inbound traffic except what the configured rules allow. Firewalls rules mainly are set based on source/destination IP/port addresses. In other words, Firewall may allow all outbound traffic except for some application; this means to add a deny rule on that destination port number. Another example it to block all inbound traffic except from some trusted host, so an allow policy will be added to the source IP address. Firewalls check each IP packet source/destination address as well as its source/destination port and then decide to allow or deny the packet. 2.2 Network Address Translatros (NAT) "Network Address Translation is a method by which IP addresses are mapped from one realm to another, in an attempt to provide transparent routing to hosts. Traditionally, NAT devices are used to connect an isolated address realm with private unregistered address to an external realm with globally unique registered addresses."[3] NAT was designed as short term solution for the IPv4 address exhaustion to allow multiple hosts in a "private" network to share public IP addresses while a more permanent solution is being developed. Because of its intended temporary nature it has been designed to cause minimal network changes and without making any changes to hosts or other routers. [8] NATs usually found on the edge of network as a functional unit of a router or gateway. NATs divide the network into "inside" and "outside" and they operate in a very simple way. NATs intercept each IP packet, examine it and then decide what to do with it. NATs might discard the packet or forward it as it is or alter its IP address and checksums. They either alter the source or destination IP address based
the direction i.e. from inside to outside or the opposite direction. There are also another variant on NATs which is port translating NAT or NATP, they work in a similar way but the mapping is done for the IP address and the port as a pair which allows even more sufficient usage of the public IP addresses. However, in this paper we will use NAT to refer to both NATs and NAPTs. [3][8] NATs can be divided in four types based on how binding is done, the four types are:[3] Symmetric: In which the mapping of private IP/port to public IP/port remains the same until the connection is closed. However a new private/public mapping is done for each new connection. Full-cone: In which the mapping of private IP/port to public IP/port remains the same which enables any outside host to send packet to the internal host using this IP/port. Restricted-cone: It uses the same mapping as in Fullcone but it allows the outside host to send packets to inside host only if the inside host has sent packets to the outside one before. Port-restricted-cone: It also uses the same mapping as in Full-cone but it only allow outside host to send packets to the same IP/port that has been used by the inside host before. 3 Problem description (traversality) Because of the services the NATs and Firewalls offer they become important elements of today.s networks which have changed the internet address architecture to be a collection of private address realms connected by NATs to the global address realm in which every device has a global unique address. Figure 1 shows how public and private domains in today s networks.[10]] But this was not without a price, Firewalls and NATs break the IP connectivity model by preventing hosts residing in "outside" networks from initiating a connection with host residing in the "inside" network[5]. This behavior is more obvious in connection oriented protocols such as TCP, for example many Firewalls are configured to allow connection only if they are imitated by internal hosts. To do so Firewalls drop inbound SYN packets making it impossible for any external host to initiate a connection with internal one. If both hosts A and B are behind Firewalls then it will be impossible for them establish a connection although the connection itself do not violate the firewall policy.[5] such configuration is reasonable to limit access to the internal network, however this cause a severe problem for peer to peer communication (P2P). The nature of P2P communications which based on incoming calls from unknown/untrusted hosts limits the possibility to solve the problem by pre-configuring the Firewall.[9] Many multimedia and P2P protocols negotiate secondary flows in the application level. Session Initiation Protocol (SIP) for example, sends an IP address and port to the other party where the audio should be sent. As a result this audio stream will be dropped at Firewall. If the host is behind Figure 1: Public and private IP address domains[10] a NAT and is using a private IP address SIP will eventually send this IP address to the other party, but all packets that will be sent to this IP address will be dropped because it is unroutable. Altough NATs alter the IP packets and replace the private IP addresses but it has no way to change or read the data in application layer.[2] 4 Solutions To solve the NAT/Firewall traversality many solutions have been developed, one of those is Application Layer Gatways (ALGs) which are an extra functionality in NATs that are application "aware". ALGs may override NAT policies or alter application layer messages and replace the IP addresses in them. [3] However, ALGs have many limitations such as scalability, reliability and the speed of deployment.[11] ALGs is a protocol specific and require upgrades and changed for each modification in the protocol.[3]to overcome some of ALGs limitations a Middlebox Communication (MIDCOM) protocol was developed which managed to overcome some of them, however, it still requires an upgrade of the existing NATs/Firewalls and application components.[11] Anther solution which is developed by Microsoft for home users is Universal Plug and Play (UPnP) but it is limited to home users and suffer form a major security problem which is putting the NAT under the control of the applications.[3] There are also some other solutions exist but in this paper we will study the following 3 solutions: 4.1 STUN "Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a light weight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet".[11] STUN is a client-server protocol in which the server must be in the public side of NAT and has two global IP addresses and the client might be behind
a NAT. The client send a simple UDP message to the server that contains its IP address and the port in the payload, the server examines the message and reply to the client with IP address and port that have been used in the header. [8][9] The client - which usually embedded in an application that need to acquire a public IP address and port to receive data on them- check the IP address it gets from the STUN server. If the IP address is the same that it has then there is no NAT in the path between the client and STUN server. If the IP address is different then the client starts to send another type of messages to the STUN server in order to learn the NAT behavior and type. After this discovery process the application can use the public IP address and port that the other end should send the data to them.[8] Figure 2 shows how SIP is using STUN for NAT traversal, for more details please check [13]. Figure 2: STUN operation[13] STUN has many advantages such as its simplicity and compatibility with many types on NATs. However it suffers from many disadvantages, the most serious one is not being able to work with symmetric NATs which are typically found in corporate networks. Because STUN client establish totally independent connection with STUN server then it will work only with cone NATS which use the same mapping for all traffic. To overcome this problem a new protocol has been developed which is Traversal Using Relay NAT (TURN). STUN also suffers from another major drawback which is the lack of support to TCP based connections and applications. But there are an extention to STUN that support TCP which is Smart Tunnel Union for NAT Traversal (STUNTS). 4.2 CODO Cooperative On-Demand Opening (CODO) is a middleware NAT/Firewall traversal system that dynamically configures NATs/Firewalls and open holes in them so the authorized application can communicate. CODO allows only authorized applications to open narrow holes in Firewalls when needed. When the application do not need to the hole it can be closed.[6] CODO uses extensive cooperation between firewalls and application. To do that a CODO-enabled firewall will have a firewall agent (FA) that will communicate with client libraries (CLs). Figure 3 shows CODO topology.[6] In CODO, there is no need to add static rules to allow application to traverse the Firewall since the FA functionality which embedded with the Firewall adds and deletes the rules dynamically. FA also keeps a list of applications that can Figure 3: CODO topology [6] traverse the Firewall and do not allow any other application traverse it. When an authorized application need to open a hole in the firewall, the CL establish a secure TCP connection to the FA and informs FA of application s need to open a certain hole, FA then modify the rules to allow such an activity. CL also informs FA with the status of the connection and when the connection is closed be the application FA modifies the rules to close the hole. CODO also address NAT traversal using similar approach, CL make a TCP connection to FA which reserve a public IP address to be used. Then client FA will ask the server FA to allow the connection for that IP address.[6] As we can see CODO can work with the most restricted Firewalls and NATS and it allow only narrow and short Firewall openings. In addition to that CODO controls both inbound and outbound traffic. Another important advantage of CODO is its application authorization capability which makes it very suitable for high secure systems. However, CODO is not backward compatible and it is necessary to update the existing NATs and Firewalls to enable CODO to work. But, at application level only CL libraries are needed with a possibility of re-linking. [6] 4.3 NSLP "NAT/Firewall NSIS Signaling Layer Protocol (NAT/FW NSLP) is a path-coupled signaling protocol for NAT and Firewall configuration within the NSIS (Next Step In Signaling) framework."[7] But before we can talk about NAT/FW NSLP we will discuss NSIS briefly. The efforts of NSIS work group (NSIS WG) to have a new protocol suite that take care of new signaling needs resulted in the developments of an extensible IP signaling architecture which referred to as NSIS. [15] NSIS enables different signaling applications to install and manipulate states in the network along the data path; this concept is called pathcoupled. NSIS Entity (NE ) is a network element ( mainly router) that is NSIS-enabled, which means that it can understand NSIS signals. For a certain data flow states are installed or manipulated in each NE that resides in the path. However, not all the nodes in the path should be NEs. Figure 4 shows NSIS signaling example. NE can be NSIS initiator (NI) which initiates the signaling, NSIS Forwarder (NF) which intercept and then forwards the signaling message and finally NSIS Responder NR which terminate the signaling. NSIS protocol has two layers which are:
Figure 4: NSIS Signaling and data flow Example [7] NSIS Transport Layer Protocol (NTLP) which is responsible for transporting signaling layer messages between NEs, the currently used protocol is General Internet Signaling Transport (GIST). This protocol is application independent and it runs over TCP or UDP.[7] The NSIS Signaling Layer Protocol (NSLP) which is application specific and it implements application signaling functionality. NAT FW NSLP is one example on NSLP. In order to make NAT FW NSLP works it is necessary that the NAT/Firewall can accept NSLP messages and process them and then it is dynamically alter it policies to allow the needed connection. All NSLP-aware nodes in the path should do so, however, it is not necessary for all nodes to be NSLP-aware.[7] Figure 5 shows how NAT/FW NSLP works, when needed NI sends an NSLP signaling message to NR to create a.hole". All NF in the path process the message and alter their rules to allow the connection to be established.[7] it has a high security features but this requires changes or replacement of the existing Firewalls/NATs. Finally, NSLP has many advantages such as it can be deployed gradually and it can be utilized by any application and it support both TCP and UDP. NSLP also a part of standardized two level protocols which allow each application to set up its own security standard. Although NSLP has some limitation such as need to update existing NATs, Firewalls but we think it could be the best solution because of the features it has and being a part of a wider protocol suite. References [1] Bellovin, S.M.and Cheswick, W.R. Network firewalls. In Communications Magazine, IEEE Volume 32, Issue 9, Sept. 1994 Page(s):50-57 [2] Martin, M., Brunner, M., Stiemerling, M., and Fessi, A. Path-coupled signaling for NAT/firewall traversal. High Performance Switching and Routing, 2005. HPSR. 2005 Workshop on, 12-14 May 2005 Page(s):231-235 [3] Aurel Constantinescu M., Croitoru, V., and Oana Cernaianu, D. NAT/Firewall traversal for SIP: issues and solutions Signals, Circuits and Systems, 2005. ISSCS 2005. International Symposium on, Volume 2, 14-15 July 2005 Page(s):521-524 Vol. 2 [4] Aoun, C., Stiemerling, M., Davies, E.,and Tschofenig, H. Path-directed signaling usage in the Internet IP Operations and Management, 2004. Proceedings IEEE Workshop on,11-13 Oct. 2004 Page(s):205-213 [5] Saikat Guha and Paul Francis Characterization and Measurement of TCP Traversal through NATs and Firewalls Source: 2005, Usenix Figure 5: Firewall traversal scenario[7] Although this protocol requires some changes in NATs and Firewalls but it is feasible because the changes can be used by a range of applications. The most important one is Quality of Service (QoS). Reference [7] shows that the protocol is implemental and the performance figures are acceptable. 5 Conclusion As we can see there are many solutions exist to solve the Firewall/NAT traversal problem. From the ones we have studied we can see that STUN which used by Skype is a very simple solution and it is backward compatible. But it suffers form many limitations such as incompatibility with some Firewalls and supporting UDP only, STUN also require that each service provider allocate their own STUN servers. It also considered causing a security threat. [6] Another solution which is CODO is solving the problem by allowing the application to communicate with Firewalls/NATs, [6] Sechang Son, Allcock, B., and Livny, M. CODO: firewall traversal by cooperative on-demand opening High Performance Distributed Computing, 2005. HPDC-14. Proceedings. 14th IEEE International Symposium on, 24-27 July 2005 Page(s):233-242 [7] Steinleitner, N., Peters, H., and Xiaoming Fu Implementation and Performance Study of a New NAT/Firewall Signaling Protocol Distributed Computing Systems Workshops, 2006. ICDCS Workshops 2006. 26th IEEE International Conference on,04-07 July 2006 Page(s):8-8 [8] cicso systems http://www.cisco.com/web/about/ac123/ac147/archive 3/anatomy.html [9] Solving the Firewall and NAT Traversal Issues for MoIP http://www.newport-networks.com/custdocs/33-nat-traversal.pdf [10] Ford Bryan, Srisuresh Pyda, and Kegel Dan Peer-topeer communication across network address translators In USENIX Annual Technical Conference, 2005
[11] Rosenberg J., Weinberger J.,Huitema C., and Mahy R. STUN: Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) RFC 3489, IETF, Mar. 2003 [12] Salman A. Baset and Henning Schulzrinne An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol IEEE Infocom 2006. [13] Koski P., Ylinen J., and Loula P. The SIP-Based System Used in Connection with a Firewall International Conference on Internet and Web Applications and Services/Advanced International Conference on Telecommunications 2006 Vol. Issue, p203 [14] http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslpnatfw-13.txt [15] Xiaoming Fu; Schulzrinne, H.; Bader, A.; Hogrefe, D.; Kappler, C.; Karagiannis, G.; Tschofenig, H.; Van den Bosch, S. NSIS: a new extensible IP signaling protocol suite Communications Magazine, IEEE Volume 43, Issue 10, Oct. 2005 Page(s):133-141