Implementation of Virtual Firewall Function in SDN

2017 9th IEEE-GCC Conference and Exhibition (GCCCE)

Implementation of Virtual Firewall Function in SDN (Software Defined Networks) M. Saad Waheed, M. Al Mufarrej, M. Sobhieh, A. Al Barrak, A. Baig, A. Al Mazyad College of Computer and Information Systems Al Yamamah University Riyadh, Saudi Arabia {201211034, 201211118, 201111171, 201211147, a_baig, a_almazyad}@yu.edu.sa

Abstract— With the overhauls and increase in network size, it becomes harder to practice maintainability along with security. In recent years, software-defined networking (SDN) has evolved to replace the traditional design of the current network, and with such evolution, raises issues in the firewall. Firewalls are one of the most important components used in networks, and new challenges have been driven by the software-defined networks in implementing firewalls. The main issue of the firewall is its speed. The speed of the firewall is a hindrance; often firewall’s link speeds are slower than the supported network interface and can cause the traffic burst from the host to be buffered until packets are processed. To overcome these issues, the aim of our project is to solve by implementing duplicate instances of the firewall. By designing two topologies, a single and multiple controllers, and implementing them in a simulated environment the resulting studies show that multiple controllers in a network environment tend to show an improved performance in the network than in a single controller network. Keywords— Software Defined Networking, Floodlight, Open vSwitch, Mininet, OpenFlow

I.

Firewall,

INTRODUCTION

Daily, thousands and thousands of non-ethical hackers are trying to steal, eavesdrop, or destroy valuable data belonging to organizations or individuals. Firewall, a software program or piece of hardware that helps screen out worms, viruses, and hackers that try to reach your computer over the internet [1], are now insufficient to stop these attacks as they increase and evolve every day [2]. With the increased number of attacks, firewalls are also becoming slower and more vulnerable to lags and firewall explosions. With the evolution of SoftwareDefined Networking (SDN), it has become difficult to implement network components including firewalls in traditional networks. That is why an upgrade is necessary to adapt to new changes. Software firewall components configured from a single controller is very beneficial, making it easy to set rules around the network. Imagine that rules are set from one point in the network instead of having to set them on every hop or every node or router. Traffic routes and related information is

978-1-5386-2756-3/17/$31.00 ©2017 IEEE

valuable for network administrators, using this new standard of networking administrators can easily control the traffic, shape, and filter accordingly as all the traffic is passing through the single point according to the rules applied. Currently, firewalls are vulnerable to many issues; one of these issues is that the firewall’s performance is becoming slower by the second as intrusions become more dangerous and hard to stop. This creates a Denial of Service (DoS) attack [3] which occurs when the intruder sends an enormous amount of packets for the firewall to process, and with the limited processing capacity the firewall stops responding. Second major problem is the buffer overload. This happens when the number of incoming packets exceeds the number of processed packets. The packets wait in the buffer until they are ready to be processed. Once the buffer is full, the packets are dropped. The third problem is the firewall explosion. Unlike the previous two issues, this one is caused by the user. This happens when the user keeps updating his firewall rules. The user keeps adding rules until the firewall is full, that it cannot process any more packets. In this case, the firewall lags and packets start entering the system without being checked. The things that drive this trend is the use of mobile devices and cloud services. These are the major components that drive the networking industry forward and asks to reexamine the traditional architecture. [4]. In order to solve these firewall issues and increase the performance of the network overall, we propose to virtualize the network components and introduce multiple firewalls on a software defined network, From here on the paper is organized in four sections as follows, Section II presents the background on SDN and its terms. Section III touches upon the SDN testbed architecture and the simulated tests whereas Section IV discusses the results and the performance of the network. Lastly Section V concludes this paper and refers to future work.

2017 9th IEEE-GCC Conference and Exhibition (GCCCE)

II.

BACKGROUND AND RELATED WORK

In this section, we will describe the SDN and Firewall architectures for building the SDN-based firewall test bed. SDN architecture consists of three layers; infrastructure, control, and application layer. An overview of the architecture is shown in Figure 1[5]. The infrastructure layer (Data Plane) consists of all the network elements such as routers, switches, and hosts connected together. The capabilities of elements in infrastructure plane are forwarded to the control layer using a southbound interface such as OpenFlow. The SDN Controller is located at the control layer (Controller Plane), its function is to receive the instructions from the application layer and relay it to the network elements. The controller is also responsible for extracting information about the network elements and passing it back to the SDN applications. Application Layer (Application Plane) has the SDN applications; these are programs that convey their network requirements using Northbound Interfaces such as REST to the controller. [6]

A. OpenFlow OpenFlow is a standardized interface, which allows users to freely and directly control how packets can be routed in a software defined network. OpenFlow is based on an Ethernet switch, though still maintaining an open protocol, which can be used to control the traffic between commercial Ethernet switches, routers, and wireless access points. OpenFlow works with three components, flow table, secure channel, and an OpenFlow protocol [6]. B. Mininet Mininet is a network emulator which runs on a Linuxbased operating system. The emulator creates a network of virtual hosts, switches, controllers, and links. It uses processbased virtualization to run many hosts and switches on a single OS kernel [7]. Mininet has a superior boot time, scales larger networks, and allows for more bandwidth usage. C. Open vSwitch (OVS) OVS is a multilayer OpenFlow software switch that functions best as a virtual switch. It is used to provide connectivity between physical interfaces and virtual machines. D. Floodlight Every software defined network needs a controller, and that is where Floodlight comes in. Floodlight is a java based controller, that uses the OpenFlow protocol to manage the traffic and is dynamic to both the virtual instances and the physical one, and is completely fit for an enterprise to run its network through. Floodlight controller already has a firewall and access control list built in it as modules. An overview of the Floodlight architecture is seen in Figure 2 [8].

Fig. 1. Software Defined Networking Architecture

The Firewall architecture in our scenario is implemented using two different approaches; single firewall or multi/parallel firewall. A single firewall approach contains just a single firewall controller on the network; the firewall is connected to the internal network and public internet. Rules and policies are implemented on the firewall to filter the incoming and outgoing traffic and secure the network from unauthorized access. Whereas multi/parallel firewall have two or more firewall controllers on the network. It divides the work based on the number of incoming and outgoing packets thus the rules and policies are implemented on both firewalls. Hence, packets that arrive are distributed between either firewall.

Fig. 2. Floodlight Architecture

III. PROPOSED TEST BED ARCHITECTURE The test bed that we propose includes three network elements, the SDN controller (Floodlight), OpenFlow switches

2017 9th IEEE-GCC Conference and Exhibition (GCCCE)

(Open vSwitch), and hosts. In our test bed, all the network elements are built in Mininet running on a virtual machine with a Linux based operating system. The controller itself is configured and installed in the Mininet. In this chapter, the network design, software architecture and methodology of the network elements are discussed. A. Network Design According to our specifications, we have two different topologies running on our network. The initial topology runs a

network with a single controller configured with firewall rules and policies. The Second topology contains multiple/parallel controllers running in conjunction with each other. Figure 3 shows the topology and the network elements in the initial test bed. It contains a single controller connected to six Open vSwitches, which further connected to twelve host devices.

Fig. 3. Single Controller Topology

Our second topology adds another controller to the network with further six switches. Three switches are connected to the first controller and the other three are connected to the remaining one. Backup connections are also

provided from each controller to other controller’s switches in case of any failures. These switches are then further connected to twelve host devices. Figure 4 shows an illustration of the topology.

Fig. 4. Multiple Controller Topology

The communication between the controller and the switch is achieved by OpenFlow Protocol running over a Secure Socket Layer (SSL). Once the controller specifies the proper event for the packet, it will send the command to

the switch hence, any application module can easily be implemented on any switch. This provides the ability to shape data traffic as desired.

2017 9th IEEE-GCC Conference and Exhibition (GCCCE)

B. Software Design 1) Traffic Design The traffic is generated using a tool called Ostinato (provides different packet characteristics). Ostinato is capable of capturing the generated traffic and display them in Wireshark (a packet analyzer). Therefore, a statistics analysis of the performance of the network is performed easily. 2) SDN Controller The SDN controller in our test bed as mentioned is Floodlight controller software. Floodlight is an open source controller that provides the ability to create application module or using existing ones (Floodlight uses Java language) and can handle many elements and equipment's while maintaining a greater level of service. 3) Floodlight Firewall The firewall module in floodlight controller is implemented with REST API service, while a simple Curl command manages it. The firewall by default blocks all packets from being transferred from host to host. Allow rules must be added in order to allow communication. The firewall can allow communication from a particular host, port, protocol, and switch. 4) Ostinato The software that was used and relied upon heavily in this project was the free-to-use and open source Ostinato, which is a traffic generator and performance tester. Ostinato does not use the actual topology, but rather copies it and runs tests on the copied version of the topology. Ostinato is easy to use and learn and filled with options on how to properly test, it allowed the freedom to test the topology in every situation that was chosen by the testers.

repeated but maintains a faster processing protocol. The cases run on our topologies are shown in Table 1. Packets per host mean that each host sends the desired amount of packets and the packets per second is a number of packets the link allows to pass through per second. TABLE I.

Case # 1 2 3

TEST CASES

Packets per host 50,000 50,000 50,000

Packets per second 50,000 70,000 90,000

The UDP traffic generated was repeated three times for each case and the results averaged, to remove any anomalies from the results. The resulting data/packets were captured using Wireshark; it gave us a detailed analysis on how long the packets arrival time is delayed. In both the topologies, the cases were run at the same machine state and were run twice, first with firewall disabled and then enabled for the next test. IV.

PERFORMANCE EVALUATION

After conducting all our tests on the SDN test bed we evaluated the result and analyzed the delay according to topologies. The first test was to compare the results between the two topologies with and without firewall rules. Figure 5 shows a graph for Single Controller topology, with and without firewall rules. And Figure 6 shows us the multiple controller topology, with and without firewall rules.

C. Methodology In order to compare our results from both topologies, we perform tests by first sending a load of generated traffic and manipulating controller load by increasing the packet per second rate. We used three different cases with increasing packets per second. UDP protocol is used in all our generated traffic cases in both topologies. With our scenario, we prefer using UDP packets rather than TCP. The three major reasons as to why we prefer UDP is processing overhead and speed. UDP doesn’t require much processing in the controller because it has a small processing overhead and gives a much higher throughput. UDP doesn't require an ACK packet once the data packet has been delivered, unlike TCP where in order to guarantee a reliable connection ACK packet is sent to sender once the packet is received on the other end. This is sometimes a disadvantage in the case of UDP protocol as packets might be duplicate or dropped without being

Fig. 5. Single Controller – Response Time

2017 9th IEEE-GCC Conference and Exhibition (GCCCE)

single controller. However, with firewall enabled the overall time has been increased but multiple firewalls still show better performance with the time taken for processing, as shown in Figure 8

Fig. 6. Multiple Controllers– Response Time

As seen, the changes in each case single or multiple controllers are very minimal and almost insignificant when firewall rules are enabled or disabled. But on comparing each and viewing which topology performs better, the single controller takes the lead. At 50,000 packets per second, it takes around 12.5 seconds for the single controller to process whereas it takes around 13.75 seconds to process in a multi-controller environment. At 70,000 and 90,000 packets per seconds it took 9 and 7 seconds respectively for a single controller and around 9.5 and 7.5 seconds respectively for multiple controllers. The reason why single controller topology performs better is because the packets are processed once at the firewall whereas in multiple controllers the packet first duplicates and is processed using the two firewall controllers.

Fig. 8. UDP with firewall – Response Time

The delay time also differs when using a single controller and multiple controllers with and without the firewall enabled as shown in Figure 9 and Figure 10.

Our next test was to determine the time taken to process the generated packets (UDP traffic) without firewall rules in both topologies, the tests are 50,000/70,000/90,000 packets transmitted at 50,000 packets per seconds. The results are shown in Figure 7. Fig. 9. UDP without firewall – Delay

Fig. 7. UDP without firewall – Response Time

With this test, multiple controllers have shown an improvement in the time taken to process the generated packets without a firewall being enabled over the single controller. The reason for this improvement is due to packets being processed by two controllers rather than a

Fig. 10. UDP with firewall – Delay

The delay statistics shows a very interesting graph. Multiple controller topology has a maximum of 0.75 seconds delay for the three cases 50,000, 70,000, and 90,000 packets per second for both with and without firewall rules enabled. Whereas for single controller topology the maximum delays go up to 1.75 seconds delay for the cases

2017 9th IEEE-GCC Conference and Exhibition (GCCCE)

50,000, 70,000 and 90,000 packets per seconds. The reason again is the same as mentioned that the packets as processed at almost double the rate in multiple controllers than in single controller. After testing all cases, we found out that multiple controllers are clearly better than single controller. As seen from the results, the graphs with multiple controllers over had a low and good response time and less delay than the single controller. V.

CONCLUSIONS & FUTURE WORKS

In this paper, redundancy has shown to be an important factor in improving a network's performance. There is always a clash between security and performance; one is compromised for the other. But, with implementing firewall functions in a software-defined network controller we were able to establish a high performing secure network. The result showed that with or without firewall the performance is improved when using the redundancy approach. In the future, more research will be implemented on this, using better resources, as well as, having the goal to improve such a project, as well as, using it as a base point in order to create derived projects that are linked to this. VI. [1] [2] [3] [4] [5] [6] [7] [8]

REFERENCES

Microsoft Corporation http://www.microsoft.com/security/pcsecurity/firewalls-whatis.aspx Common Threats. Retrieved from Getcybersafe.gc.c: Getcybersafe.gc.ca/cnt/rsks/cmmn-thrts-eng.aspx Farley, R. J. (2005). Parallel Firewall Designs For High-Speed Networks. North Carolina. 12 Days of Broadband is Software-Defined Networking. Retrieved from www.mcnc.org: https://www.mcnc.org/news/12days-ofbroadband-software-defined-networking Software-Defined Networking (SDN) Definition Retrieved from https://www.opennetworking.org/sdn-resources/sdn-definition Hyunmin Kim, Jaebeom Kim, Young-Bae Kao "Developing a CostEffective OpenFlow Test bed for Small-Scale Software Defined Networking". Ajou University, Korea Mininet Overview http://mininet.org/overview/ SDN Series Part Five: Floodlight, an OpenFlow Controller Retrieved from http://thenewstack.io/sdn-series-part-v-floodlight/