Implementing to manage the packets. Also, in traditional

Implementing Firewall for Floodlight Controller


Navinder Kaur Brar

Jaspreet Singh

Harkishan Singh

Department of Systems and Computer Engineering

Department of Systems and Computer Engineering

Department of Systems and Computer Engineering

Carleton University

Carleton University

Carleton University

Student No. 101026788

Student No.

Student No.

[email protected]




Group Number: 16

This report was prepared for Professor Ahmed Karmouch in partial fulfillment of the requirements for the course ELG-7187A



               Abstract – Software Defined Networking which opened many doors of possibilities for the future of the network in which the network logic operations are detached from the limitations of the underlying hardware. This new approach in the networking also possess many threats towards the security. There are possibilities of the compromise in the channel design and organization as well as controller Denial-of-Service attacks. This paper describes the Floodlight Controller and its applications and implementing Firewall application on it. Firewall application has been implemented as a Floodlight module that imposes ACL rules. We use the REST API to develop the application which was accessed using Curl. This paper also provides the information about how Firewall implementation is tested by filtering the ICMP and TCP packets.

Keywords- Software Defined Network, Firewall, Floodlight, ACL, REST API


I.  Introduction

               Software Defined Networking one of the hot topics and a major breakthrough in the world of networking. Traditional networks consist of the devices which consists of control plane and data plane where control plane gives the information with the help of which forwarding table is constructed. This forwarding table is used in order to make decisions of routing and data plane uses the forwarding table to manage the packets. Also, in traditional networks both of these planes lie directly on the network devices. In the case of Software Defined Networking (SDN) there is the physical separation of the network control plane and forwarding plane or in the other words it abstracts the control plane. The control plane is taken care by SDN controller which communicates with data plane with the OpenFlow protocols. SDN is considered ideal for today’s applications which require high-bandwidth and are more dynamic as it can be managed easily and is more cost effective. As the architecture of SDN abstracts the control and the forwarding functions which leads the network control to be programmed directly. For various SDN solutions OpenFlow protocol is one of the fundamental elements. The characteristics of the SDN that the network control is directly programmable makes it hit in the open networking area. It is based on the open standards and does not depend on a specific vendor. New developers and talent can work and experiment on top it which makes it more prone to development. Also, the switches used could be physical and virtual and provides network as a service in the hands of the users.

The controller in the SDN are centralized instead of distributed and it have a global view of the network and the network administrators can adjust the traffic flows all over the network if there is need of some change. SDN is also described as a model which represents a client-server relationship with the controller. In SDN the service customer can send or receive the data with the help of the network resources and the network services can be managed by the controller. The responsibilities of the service provider include virtualization and orchestration of the resources which could be used by the customers. One of the main problem to be solved in most of the network areas is security. For SDN the security should be in the basic architecture also it should be provided as a service to the users in order to shield the privacy and the integrity of the information flowing. In the SDN architecture we can secure the network in various ways such as by controlling the SDN controller in very tight manner. In case of any attack where the SDN controller and the network goes down there is need to maintain the accessibility of the controller. The operation on the controller or on the whole network should operate as they should as the communication in the whole network is prone to attacks from some network intruders. Other focus is how this security should be deployed in SDN environment as there are various solutions proposed such as the security should be embedded in the networks itself while other solutions say it works best if it is embedded within the servers or on the computing devices. But we need an environment which is more secure, more efficient as well as scalable and proves to be an edging technology in all the ways.

(Sergey Morzhov) The mean of security in SDN should be in such a way that mostly all of the underlying components which includes the controller, applications, the switches and the communication channel between the switches and controller. Also, there is need to secure the endpoints and the other basic components of the network architecture. It is felt that with the commencement of the new approaches in the field of networking which includes the virtualization and the use of mobile devices which is growing in large numbers and the change in the patterns of traffic gives us a hint toward new steps to be followed in the case of security. Changing the requirements such as security as an application which is familiar with the processes happing in the application at any time. Also, the security in the network should have protection in the internal segments and on the servers and nodes.

In this paper, we will discuss about the implementation of such a security i.e. firewall on one of the SDN controllers which is Floodlight. This paper describes the implementation of Firewall application as a module with the help of REST API by using Access Control List rules and by taking the advantage of programmability in SDN. The paper is divided into various parts where we will discuss first the Objective of this project in which we will discuss what we are performing in this project and what are the needs of security or Firewall then in Section III i.e. Background we will provide the information about the SDN controller (Floodlight), its characteristics, architecture, the ACL rules and how we are using REST API in implementing the Firewall. In Section IV we will describe the methodology used to implement this project with the help of screen shots and various steps to be performed to implement Firewall. We will be discussing some other approaches put forward by other researches in Section V, Related Work. At the end, we will write the summary or conclusion in Section VI.


The main objective of guaranteeing security in Software Defined Networking can be explained in two ways. First, the security of the main components which consists of the actual network infrastructure that includes the controller and the several applications, communication channel between SDN controller and switches. Second way in which we can secure SDN is by taking care of the storage systems, endpoints as well as the servers. “A firewall is a network security system that monitors incoming and outgoing network traffic and decides whether to allow or block specific traffic based on a defined set of security rules”. To secure the SDN we implement Firewall using Floodlight controller. Firewall in Floodlight is programmable controller module in which we can add, delete or update the firewall rules.



Floodlight is an Apache licenced Java based OpenFlow Controller which is supported by large number of developers. It is developed by open community developers which is easy to use because of its GUI and is tested as well as supported by community of developers. Floodlight follows the OpenFlow Standards and can easily work even if the number of the switches, virtual switches, routers which are supported by OpenFlow are increased. Various features of Floodlight are that it is drafted to provide the high performance, it is merely easy to set up with minimal dependencies. As already discussed Floodlight supports wide range of physical as well as virtual OpenFlow Switches. Floodlight supports OpenStack cloud orchestration platform (“Orchestration is the process of using the SDN controller’s resources to simultaneously satisfy service demands from all of its clients according to an optimization policy.”)

Being an OpenFlow Controller        Floodlight also consists various number of the applications which are built on the top of it. Floodlight achieve some common set of components to control and take care OpenFlow network whereas applications which are built on top of it are used to solve different needs w.r.t different features which are needed over network. Figure1 shows the Floodlight Controller and various applications which are built on top of it as Java modules and using Floodlight REST API. Java module applications and the controller starts running as we run the Floodlight and the REST API are available by all the modules running via specified REST port. ACK which uses stateless firewall is one of the applications of Floodlight that we are implementing in this project which uses various ACL rules. ACL rules contains a set conditions according to which the flow of the traffic is allowed or denied. There are different URIs with REST methods just as GET, PUT, POST, DELETE to add various rules for the firewall. Every time any rule is created it generates a rule_id which is random number. In order to perform DELETE method or to delete any rule we can do it by mentioning the rule_id.


Figure1. Floodlight Architecture


To attach the running Floodlight with OpenFlow network we can use Mininet which is a network simulation tool. Also, to analyse the packet or to filter the packets we use Wireshark. Floodlight also come with web based Graphical User Interface which can be detected with the help of REST API in Floodlight. It consists of OpenFlow statistics which are easy to read as they are shown in tabular manner and also shows the status of various applications and we can tell if Firewall is working or not. GUI can be accessed by following URL:





Here is the IP address of the machine on which controller is running. With the help of GUI, we can modify the network state as it provides the read and write access to Floodlight controller.




Floodlight contains ACL (Access Control List) that works in a reactive way to allow of stop movement of packets according to the rules defined. The floodlight controller monitors the rules enforced by ACL and pushes only the relevant entries. In a proactive way, the switches can allow the rules without the request to avoid delays. The ACL parses user’s Representational state transfer(REST) to update ACL and makes a static flow entry to proactively monitor Packet in messages. It removes the filter as soon as the rule is removed from ACL. The application maps the ACL rule and flow entries. It makes use of the IDeviceService in floodlight to monitor if any device is added. If user adds a rule of “Deny flow” giving the source IP the application inserts a static entry to deny the packets from that IP. Now we will discuss the implementation steps we took to implement the firewall in floodlight using ACL:

Step 1: Build and Run floodlight- In order to build and run floodlight controller we need to write the following commands:

cd floodlight


java -jar target/floodlight.jar

Figure 2 shows the result of running these commands.

Figure 2. Building and Running Floodlight

Step 2: In this step, we open the web GUI to visualize the structure of the network for better understanding. At current state, the GUI is empty as no network definition has been provided. In order to open the web GUI, we type in the default address


Step 3: In this step, we start Wireshark. Wireshark is a tool to monitor the movement of packets in a network. We need ot to monitor the movement of the packet the network that we are going to define in the upcoming steps


Figure 4. Starting Wireshark for Floodlight


Figure 5. Wireshark GUI


Step 4: Create a network topology. In this step, we create the network topology using mininet. After the nodes are made we ping them to make sure that the connection to all the nodes are working. We enter the following command:


sudo mn –topo=tree,3 –mac –switch ovsk –controller=remote, ip=, port=6653


This command defines a tree network of depth 3, switch type ovsk, remote controller at a specified IP and port. The IP chosen is the default i.e. and the port chosen is the default for floodlight i.e. 6653.


Figure 6. Creating Topology using Mininet


The network topology created can visualized using the Graphical User Interface of Floodlight.


Figure 7: Topology formalized as in Floodlight GUI


Step 5: In this step, we use curl to access the REST API. The following command in the floodlight controller allows us to do that:


sudo apt-get install curl


Step 6: Now we check the firewall status. If it is enabled we don’t change anything else if it is disabled we enable it. We use the following command:


curl http://localhost:8080/wm/firewall/module/status/json


Figure 8. Checking Firewall Status


Step 7: Now we enable the firewall if the status is disabled. This step is not required if the status of the firewall is already enable. We run the following command and the we got the result that the Firewall is enabled. Figure 9 showing the results of Firewall when enabled in Wireshark, thus pingall command showing no response found.


curl http://localhost:8080/wm/firewall/module/enable/json -X PUT


Figure 9: Firewall Enabled

Step 8: Adding rule to Switch. In this step, we add a new rule to the switch to filter packets through it. The following commands will do the process and add the new rule to the switch number 3.


curl -X POST -d ‘{“switchid”:”00:00:00:00:00:00:00:03″}’


Step 9: Add DENY rule between hosts. In this step, we add a deny request to the host so that we can separate ICMP packets from TCP packets. This is accomplished using the following commands:


curl -X POST -d ‘{“src-ip: “″,”dst-ip”:”″,”nw-proto”:”ICMP”, “action: “DENY”}’ http://localhost:8080/wm/firewall/rules/json


We can send a “pingall” command to mininet to see if the packet flow is moving in the correct way. In order to monitor the packet, flow we can use Wireshark. The figure below shows how Wireshark is used to see the movement of packets.

Figure 10. Wireshark showing the results.




In 1 we see the implementation of a general idea of the SDN controller along with explanation of Floodlight controller and reasons to choose Floodlight controller. It also explains some of the key concepts of network security implementation in floodlight. The implementation is done as basic network mechanism.

In 2 they discuss the rules that match to describe network packages. In 3 the authors have discussed about modification to the rules such as disjoint, exactly matching, inclusively matching and correlated.

Our approach focussed on the ACL and definition of simple rules. These approaches discussed here can be further implemented in future.



In conclusion, we can see that we use the ACL for controlling the forwarding of packets. We defined the network topology using mininet. As we make the network we can see the network on the web GUI and make changes as required. Once we have established the network we can define the rules using curl to allow or deny the packets that get transferred. The rules are defined in ACL using curl. We can also use python for future to make it more flexible. In our project, we have defined ACL rules to deny ICMP packets and allow TCP packets. The tree network with 7 switches and 8 hosts shows a positive response to the ping of the networks, it blocked all the ICMP packets and allowed only TCP packets through switch number 3.



1   M. King, B. Zhu, and S. Tang, “Optimal path planning,” Mobile Robots, vol. 8, no. 2, pp. 520-531, March 2001.

2   H. Simpson, Dumb Robots, 3rd ed., Springfield: UOS Press, 2004, pp.6-9.

3   M. King and B. Zhu, “Gaming strategies,” in Path Planning to the West, vol. II, S. Tang and M. King, Eds. Xian: Jiaoda Press, 1998, pp. 158-176.

4   B. Simpson, et al, “Title of paper goes here if known,” unpublished.

5   J.-G. Lu, “Title of paper with only the first word capitalized,” J. Name Stand. Abbrev., in press.

6   Y. Yorozu, M. Hirano, K. Oka, and Y. Tagawa, “Electron spectroscopy studies on magneto-optical media and plastic substrate interface,” IEEE Translated J. Magn. Japan, vol. 2, pp. 740-741, August 1987 Digest 9th Annual Conf. Magnetics Japan, p. 301, 1982.

7   M. Young, The Technical Writer’s Handbook, Mill Valley, CA: University Science, 1989.