detection and mitigation of an abnormal traffic behavior in...

Communication Networks Group

Udeh, Paschal Chigozie

Detection and Mitigation of an Abnormal TrafficBehavior in Software Defined Networking

Master Thesis in Communication and Signal Processing

Monday 13th January, 2020

Please cite as:Udeh, Paschal Chigozie, ”Detection and Mitigation of an Abnormal Traffic Behavior in Software Defined Networking”,Master Thesis (Masterarbeit), Technische Universität Ilmenau, Department of Electrical Engineering and InformationTechnology, January 2020.

Technische Universität IlmenauDepartment of Electrical Engineering and Information Technology

Communication Network Group

Helmholtzplatz 2 · 98693 Ilmenau · Germanyhttp://www.tu-ilmenau.de/kn

http://www.tu-ilmenau.de/kn

Detection and Mitigation of an AbnormalTraffic Behavior in Software Defined Networking

Master Thesis in Communication and Signal Processing

submitted by

Udeh, Paschal Chigozie

in the

Communication Networks Group

Department of Electrical Engineeringand Information Technology

Technische Universität Ilmenau

Advisors: Prof. Dr. rer. nat. Jochen SeitzM. Sc. Alshra’a Abdullah Soli-man

Submission Date: Monday 13th January, 2020

Abstract

The exponential growth in online services as well as the volume of data that is beingtransferred over the internet arose the need for a change from the use of traditionalnetworks to a form of network that can adapt to the current demands from end users.For instance, Quality of Service, speed of packet delivery and high network efficiencyare some basic requirements needed by every user and traditional networks fall short inproviding these essential requirements because it cannot keep up with how technologyis advancing yearly. Software Defined Networking provides a solution to these issuesdue to the nature of its architecture. The architecture brings about flexibility on howessential network functionalities are included in an open and programmable manner.However, this form of architecture also leads to various security challenges and one ofthem is the Distributed Denial of Service attack. This work thus considers an approachto detect different abnormalities relating to Distributed Denial of Service attack thatcan occur in the network. The important building block for the attack detection consistsof an Intrusion Detection System (SNORT) that is used to detect the attack and acontroller (Ryu) that is used to send blocking instructions to forwarding devices oncethe attack is detected. From the simulation and results, the work shows that differentforms of attack can be detected and mitigated in a very short time and this furtherprevents the exhaustion of the network resources.

Master Thesis Udeh, Paschal Chigozie ii

Kurzfassung

Das exponentielle Wachstum von Online-Dienstleistungen sowie die Menge der Daten,die über das Internet übertragen werden, erforderten einen Wechsel von der Nutzungtraditioneller Netzwerke zu einer Form von Netzwerk, die sich an die aktuellen An-forderungen der Nutzer anpassen kann. So sind zum Beispliel Qualität der Dienstleis-tung, Geschwindigkeit der Paketzustellung und hohe Netzwerkeffizienz sind einigeGrundbedurfnisse, die von jedem Nutzer benötigt werden, aber die traditionellen Netzeerfüllen diese grundlegenden Anforderungen nicht, da sie mit der sich ständig weiter-entwickelnden Technologie nicht Schritt halten können. Aufgrund seiner Architektur,‘Software Defined Networking’ bietet eine Lösung für diese Probleme. Die Architekturbringt Flexibilität in Bezug auf die Art und Weise mit sich, wie wesentliche Netzwerk-funktionalitäten auf offene und programmierbare Weise einbezogen werden. Diese Formder Architektur führt jedoch auch zu verschiedenen Sicherheitsprobleme , eine davon istder ‘Distributed Denial of Service attack’. Diese Arbeit betrachtet daher einen Ansatzzur Erkennung verschiedener Abweichungen im Zusammenhang mit dem ‘DistributedDenial of Service attack’, die im Netzwerk auftreten können. Der wichtige Baustein fürdie Angriffserkennung besteht aus einem Intrusion Detection System (SNORT), das zurErkennung des Angriffs benutzt wird, und einem Controller (Ryu), der nach der Erken-nung des Angriffs Sperrbefehle an Weiterleitungsgeräte sendet. Aus der Simulation undden Ergebnissen der Arbeit geht hervor, dass verschiedene Formen von Angriffen in sehrkurzer Zeit erkannt und abgemildert werden können, was auch die Netzwerkressourcenvon Verbrauchung verhindert.

Master Thesis Udeh, Paschal Chigozie iii

Acknowledgement

I would like to thank my supervisor MSc. Alshra’a, Abdullah Soliman for his time,support, guidance and suggestions that aided in the successful completion of this project.

My profound gratitude goes to Prof. Jochen Seitz for giving me the privilege of workingwith him. His expertise in transferring knowledge to his students has groomed meacademically and prepared me for the industry. It was an honor to work with him.

I am thankful to my lovely parents Sir & Lady Felix Udeh and my wonderful sistersIfeoma, Patricia and Queeneth for their encouragement and unconditional support.

I dedicate this thesis firstly to the Almighty God and secondly to my amazing brotherKingsley Uchenna who has been a strong pillar all through my career and has alwaysensured that I achieve greater heights. I cannot that him enough.

Lastly, I wish to express my sincere gratitude to my friend Bilal Ahmad and my otherfriends of TU Ilmenau that have been there for me.

Master Thesis Udeh, Paschal Chigozie iv

Contents

Abstract ii

Kurzfassung iii

Acknowledgement iv

1. Introduction 1

2. Software Defined Network (SDN) 42.1. Software Defined Network (SDN) Overview . . . . . . . . . . . . . . . . 42.2. Benefits of SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3. SDN Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1. Application Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.3. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4. SDN Application Programming Interfaces . . . . . . . . . . . . . . . . . 122.5. SDN Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.1. OpenFlow Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 142.6. OpenFlow Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.6.1. OpenFlow 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.6.2. OpenFlow 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.6.3. OpenFlow 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.6.4. OpenFlow 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.7. SDN Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.7.1. Ryu Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.7.2. OpenFlow Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.7.2.1. OpenFlow Channel (Secured Chanel) . . . . . . . . . . 272.7.2.2. Flow Tables . . . . . . . . . . . . . . . . . . . . . . . . 282.7.2.3. Group Tables . . . . . . . . . . . . . . . . . . . . . . . . 29

Master Thesis Udeh, Paschal Chigozie v

Contents

2.7.2.4. Meter Table . . . . . . . . . . . . . . . . . . . . . . . . 30

3. Security in SDN 313.1. Security Threats in SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1.1. Security Advantages of SDN to Combat DDoS Attacks . . . . . . 333.2. State of the Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3. Network Abnormalities and DDoS Attacks in SDN . . . . . . . . . . . . 36

3.3.1. Volume Base Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 373.3.2. Protocol Based Attacks . . . . . . . . . . . . . . . . . . . . . . . 383.3.3. Application Based Attacks . . . . . . . . . . . . . . . . . . . . . 40

4. Simulation Environmental Setup 444.1. Mininet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2. Ryu Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3. Snort IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3.1. Snort Components . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3.2. Snort Configuration and Setup . . . . . . . . . . . . . . . . . . . 47

5. Simulation 515.1. Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2. System Design and Implementation . . . . . . . . . . . . . . . . . . . . . 525.3. Algorithm Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3.1. Start Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.3.2. Decision Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . 555.3.3. Ryu Alert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.5. Comparison and Improvements from previous works . . . . . . . . . . . 66

6. Conclusion and Future Work 69

Appendix 73

A. Code Implementation 73A.1. Topology used for simulation . . . . . . . . . . . . . . . . . . . . . . . . 73A.2. Snort local rules for DDoS attack detection . . . . . . . . . . . . . . . . 74

Bibliography 79

Master Thesis Udeh, Paschal Chigozie vi

Chapter 1

Introduction

Software Defined Networking has become the growing trend in the field of networking [1].This is due to the flexibility of its architecture as compared to traditional networks. Fortraditional networks, the network architecture comprises of both the control plane anddata plane embedded as one entity. This form of architecture brings various challengesand drawbacks to network administrators and network planning in general. Firstly, fornetwork environments having a great number of nodes, incorporating network rules orconfiguring of network policies can be very challenging. This is due to the fact that all thenodes will have to be configured individually for the entire network, thus, the speed andefficiency of traditional networks is very low. A solution to this was the introduction ofSoftware Defined Networking (SDN) [1] where the control and data plane are separated.The separation of the planes makes the system more flexible because it makes it openand programmable in a way that the rules and policies required for network functionalityare installed seamlessly. For an SDN architecture, the detached control plane servesas the central intelligence of the network where the rules are installed while the dataplane serves as the forwarding plane where the rules sent from the control plane are ex-ecuted. The communication between the decoupled planes is made possible via differentprotocols and one of such protocol that can be used for this purpose is the OpenFlowprotocol. Thus, SDN architecture generally consists of forwarding nodes (e.g. switch androuters) and controllers (e.g. POX, Floodlight, RYU) that can support the OpenFlowprotocol. The switch also have flow tables that contain addresses like Medium AccessControl (MAC) and Internet Protocol (IP) addresses of source and destination as well asforwarding instructions that match the addresses as defined by the controller. Althoughthe invention of SDN makes a network system dynamic, it also comes with certain risksas it is usually prone to a single point of failure, network manipulation, traffic diversion,

Master Thesis Udeh, Paschal Chigozie 1

1. Introduction

side channel attack, application manipulation, Application Programming Interface (API)exploitation, traffic sniffing, distributed denial of service attack and the DistributedDenial of Service (DDoS) attack is one of the most common and challenging problemsin SDN [2]. In a nutshell, the attack depletes the network resources by overloading itwith huge traffic at a time thereby making it unavailable for legitimate users. The SDNarchitecture fully consists of three planes which are the application plane control planeand data plane and this attack can be done at any of these planes as described by [1].At the application plane of the network, the attack aims at exhausting the resources ofthe interactive software, thus preventing further request for services by the end user.At the data plane, the attack can exhaust the flow table space of the switches becausethe switches have limited spaces to store data. The control plane is the most importantplane of the architecture and an attack on it can bring the network down totally becausethe exhaustion of the controller’s resources will prevent communication between thecontroller and switches in the network as well as the controller and applications at theapplication plane. SDN is more vulnerable and easily affected by DDoS attack due to thenature of how the attack is implemented. Some attacks in SDN involves compromisingthe controller which can be done only by breaching some installed security features beforeexecution but the DDOS attack can be easily implemented because breaching of the con-troller is not required, all that is needed is for the attacker to constantly inject unwantedpackets to the network until it goes down due to overload. For a successful transfer ofmessage from source to destination, certain messages are first sent via the OpenFlowchannel between the controller and the switch. Examples of these messages are; Pack-etIn message which tells the switch about flow instructions,OFPT_FEATURES_REQUEST,OFPT_FEATURES_REPLY,OFPT_STATUS_REQUEST and OFPT_STATUS_REPLY which givesimportant information like datapath ID, flow statistics, flow tables etc. The problemhere is that there is no mechanism to check the authenticity of the device from whichthese messages originate. Thus, if a device is not detected as a malicious one and stoppedsubsequently, flooding of the network with unwanted packets will be inevitable. Theaim of this work is therefore to develop an approach that can detect and mitigate aDDoS attack. To achieve this, firstly, a comprehensive study of SDN architecture andits security issues was done, with more emphasis on DDoS attack and a mechanism forthe detection and mitigation was proposed. The detection of this attack was done usingSNORT. SNORT [3] is an Intrusion Detection System (IDS) which can be used to detectany form of abnormality in a network. It involves the incorporation of certain rules in itthat can provide an alert to the central entity (controller) in situations where there is adeviation of network traffic from the usual operation. To test the functionality of theproposed method, simulation was done on a network environment mininet and the data


1. Introduction

obtained from the implementation was used for an evaluation of the usefulness of theapproach. The rest of the work is organized as follows; chapter 2 gives a full overview ofthe concept behind the SDN environment. It contains exclusive information about theSDN architecture, interfaces, protocols and benefits of the system. In chapter 3, differentSDN security threats and solutions in line with the state of the art and also differentforms of DDoS related network abnormalities were presented. Chapter 4 contains theIDS and approach used in the DDoS detection and mitigation while chapter 5 containsthe simulation and results. Finally, the conclusion and suggestion for future work waspresented in chapter 6


Chapter 2

Software Defined Network (SDN)

2.1 Software Defined Network (SDN) Overview

The main goal of Software Defined Networking is to make the network open andprogrammable [4] and it is made possible due to the separation of the control plane anddata plane. This is in contrast to traditional networks where the control plane and dataplane are embedded as a single entity. Traditional network architecture however possesscertain issues and setbacks like lack of speed and high operational efficiency [5]. Aninstance can be seen in network topologies having millions of network nodes around theworld. For this scenario, if a new network rule is required to be installed or a change isneeded to be configured in the system, network administrators will find it tasking as theywill be expected to configure all nodes individually or install all rules at every point of thenetwork. This thus reduces the speed and efficiency of the network operation, however,this challenge has been mitigated by the introduction of SDN which has a flexible andopen control and data plane. The benefits of having a system like SDN where the controland data plane are decoupled is that it ensures seamless integration of network rulesand policies and it also makes the implementation of different applications easy. Anorganization that decides to incorporate a specific behavior or application into an existingnetwork can simply develop and install it as required. Example of these applicationscan be network functions like Quality of Service (QoS) , virtualization, load balancing,traffic engineering, security, etc. [6]. Therefore, the speed of rules implementation forlarge data centers like Google, YouTube, and Facebook [1] is one of the benefits of SDN.Various reasons also prompted the decision for the introduction of SDN to replace theold tradition networks. Some of these reasons are based on new computing trends asdescribed by [7] which are;


2. Software Defined Network (SDN)

• Big data Management: As the number of internet users increases daily, storingand processing of user data becomes even more challenging. Huge amount of datais being generated from various online applications like social media platformssuch as Facebook, YouTube, Google, Twitter and on daily basis, the volume ofdata increases exponentially not only for these social media platforms but forother applications in organizations offering services like finance, logistics, healthcare, etc. Storing and processing of these data requires a lot of parallel processingwithin a short time to be done on servers that are interconnected for this purposeand this is impossible using traditional networks. However, the SDN architecturemakes this possible because it gives room for the connection of multiple controllerswithin a single network, thus providing load balancing in situations like this whenit is necessary for parallel processing within a very short time.

• Dynamic Network Traffic: Previous traditional networks can easily deal with trafficpatterns involving just communication between one client and one server which wasmajorly the case in old times when lots of devices where not used over the internetand lots of computing were not also required. However, in recent times, the patternof traffic is more dynamic, involving different client-server connections which in turninvolves the use of different servers and database connections as well as machineto machine communications. SDN can easily handle this form of computationalcomplexity because of machine to machine communication (controller to controllercommunication via the east-west protocols) before data is sent to the user at theapplication plane through the Northbound API.

• Cloud Computing: High processing power, storage and advancement in technologyhas accounted for the need for cloud computing service. This form of service allowsfor swift computing in networks by providing on-demand services, easy networkaccess, scalability and also efficient sharing of network resources by multiple clients.Traditional networks cannot keep up with such advancements because it will involvea lot of hardware configuration which in turn can create complexities, but in SDN,these services can be easily deployed and the computation can be made easilyand spontaneously, because in SDN, the control plane which is programmable andlogically connected can be expanded effortlessly to accommodate more clients,thereby providing more computing power instantly. Cloud computing is thus oneof the most important applications of SDN.



2.2 Benefits of SDN

The separation of the control plane and data plane in SDN comes with lots of advantagesand benefits. This is due to the nature of the data driven services offered in present daynetworks. Some of the specific advantages of SDN as stated by [8] and [9] are explainedbelow;

• Virtualization: Virtualization is one of the key benefits of SDN and it goes hand inhand with big data. In the presence of big data, virtualization of network is adoptedand SDN provides a means by which these big data traffic are easily handledby virtual machines. Virtualization thus enables the ease of data managementbecause it gives network administrators the ability to access and manage storeddata from any point of the network they decide to. Virtualization also makes asystem more agile because virtualized components can be easily moved aroundwhich further improves the ability for networks to quickly respond to the needs ofusers. Virtual systems are also highly scalable, making them cost efficient becausefor situations where there is need to expand the network, a lot of money will notbe needed for hardware purposes or building of new infrastructure.

• Centralized Resource Allocation: SDN is highly known for having a controlleras the central entity that has a global view of the network. This further makesthe allocation of network resources more reliable and flexible, thus increasing thespeed of the network. For instance in a situation where many switches in thenetwork are requesting for resources from the controller, the controller can assignresources based on priority or some switch parameters since it can clearly see allthe connections and activities in the network from its global view.

• Improved Security: Since user data continuously flows through a network andusers are concerned about how secure their data is over the internet, it is highlyparamount that every network infrastructure should be highly secured. Althoughwith the presence of centralized systems comes the problem of single point offailure or a central attack on the system, SDN can also effortlessly defeat andmitigate these attacks because of its global view, therefore, it can quickly noticewhere attacks to the system originate and take action immediately.

• Quality of Service: Every user needs a certain QoS for certain applications. Appli-cations like gaming and Voice over Internet Protocol (VoIP) requires high QoSto ensure low delay and guaranteed content delivery. This can also be easilyimplemented in SDN because the network is open and programmable.



2.3 SDN Architecture

According to the Open Networking Foundation Open Networking Foundation (ONF)[10], the SDN framework has a three-layer (plane) architectural system consisting ofthe Application layer, Control layer and Data layer. The application plane as shown inFigure 2.1 is at the top most layer of the architecture and it is at this plane that end useractivities are handled. Below this plane is the control plane. The control plane is themost important plane of the architecture because it houses the network operating system(controller) which is the central intelligence of the system. It is the central intelligencebecause it is at this plane that instructions and decisions on how an incoming packetwould be treated is installed. The plane is also responsible for constantly updating theforwarding table in the switches located at the data plane. Below the control plane(at the lowest level of the architecture) is the data plane. The data plane containsforwarding nodes that are responsible for forwarding packets from one plane to anotherbased on the rules defined by the controller at the control plane. Figure 2.1 below showsthe three-layer architectural system of SDN.

Figure 2.1. – Three layer SDN architecture

2.3.1 Application Plane

The application plane is at the topmost level of the SDN architecture. This layerinteracts with the control plane to provide end-users with various applications. Accordingto the authors in [6], some of these applications include; Traffic Engineering andNetwork management, Load Balancing for application servers, Security and NetworkAccess Control, Network Virtualization. The authors in [11] further distinguished theseapplications into two specific network functions which are SDN Applications (applications



that interact with the controller to actualize a specific network functionality) as describedby [6] and SDN User-Cases Applications which are simply applications that are deployedfor specific use cases in any environment. Examples of these use cases applicationsinclude; Cloud computing, Network Function Virtualization (NFV) , Mobile Networksand Information Content Networking (ICN). The applications according to the authorsin [11] are described below;

• Traffic Engineering and Network Management: Traffic Engineering involves thecontrol of network traffic with the aim of optimizing the performance of theentire network. This form of management involves a dynamic analysis, regulationand prediction of the way data flows in the network. For traditional networks,traffic engineering is very challenging because to make it work effectively, it willrequire the deployment of different infrastructures, but for SDN, implementationof traffic engineering is much easier since we can program the network and makethe forwarding rules more dynamic. Thus, we can choose the best path of data flowfrom source to destination and also take positive actions to relieve the networkwhen it is overloaded with high traffic. With traffic engineering also, networkperformance requirements like packet delay, packet loss, throughput and latencycan be swiftly achieved so as to facilitate reliable operation of the network.

• Load Balancing for Application Servers: Load balancing involves the use of multipleservers in a network that can work together to reduce the increased amount of loadon a particular server. This can be done efficiently by evenly distributing theseloads or client requests across the servers. However, in load balancing, these clientrequests are processed independently by each server in the network, therefore,they are not suitable for applications that require a change or update of data likein messaging or database services but they are suitable for read-only data wherechanges do not occur frequently like firewall and proxy services. The advantage ofload balancing is that it can cope in situations where server failure occur. If oneserver goes down for instance, redistribution of the load is done between otheractive servers, thus, the problem of single point of failure is easily handled. It alsoenhances scalability as more servers can be added where there is an increasingdemand of services or reduced when few network services are needed.

• Security and Network Access Control: Every network entity requires a form ofsecurity in order to prevent hackers from taking down the system. For traditionalnetworks, security management is very challenging because it will require configura-tion across all the routers and switches in the network. However, at the applicationplane of SDN, these security management can be easily implemented due to the



flexibility of the different planes in the architecture. Network operators can simplyconfigure and update any security policy they require in a programmable waywhich will easily cut across the entire network.

• NFV: Just like in SDN, NFV uses network abstraction. In NFV, different networkfunctions like Domain Name System (DNS), Network Address Translation (NAT),encryption, etc. are decoupled from the hardware which they run on top. Theadvantage of having such applications is that it allows for scalability such that thesenetwork services can be increased or reduced based on need or requirement fromclients. There is also the flexibility of creating different or more virtual applicationsto fit into the system. For traditional networks, running this form of applicationcan be very expensive because for every network function needed, a new hardwareinstallation will be required. In contrast, SDN provides a perfect framework wherethese functions can be deployed because as these network functions are abstracted,SDN can easily control and coordinate them for their use. The functions can alsobe programmed and configured swiftly without incurring any additional expense.

• Mobile Networks: There has been increasing amount of mobile devices over theglobe and it has also led to an exponential increase in mobile traffic. Regardless,mobile users still require the introduction of new services with high quality as wellas efficient delivery irrespective of their location. High reliable and low latency hasalways been an issue related with mobile and wireless communication, however,authors in [12] sought a way of solving this challenge using the SDN environmentin such a way that network operators will have control over their environmentby having base stations with enabled SDN cellular networks so that they canoffer services at the very best. Nevertheless, this application is still under researchbecause it involves a lot of issues like high security and inter-operation betweendifferent SDN domains.

• ICN: As described by authors in [13], ICN will play a major role in the internetin future because it has some major features like the ability to cache contents onrouters for efficient content delivery, high data security and mobility management.The advantage of having such an application is that it can meet up with highdemand of efficient content delivery arising from the different forms of applicationslike video streaming, gaming, etc. which are rapid in present day internet. However,the deployment of this form of application on traditional network is also challengingbecause it will require an upgrade or the installation of equipment with ICNfeatures but for SDN, the application can be easily integrated due to the openand programmable architecture of the system.



2.3.2 Control Plane

The control plane is the most important plane of SDN architecture because it houses thesoftware based controller which acts as the central intelligence of the network. At thisplane, all forwarding rules are installed, all security measures can be implemented andall possible threats on the system can be averted because the controller on this planehas a global view and entire knowledge of the network. There are two different forms ofSDN controller configuration by which the logical connection between the control planeand data plane can be done. They are the centralized and distributed configuration[14]. For the centralized configuration, there is the presence of only one controller in thenetwork that acts as the central entity and intelligence of the system. Figure 2.2 belowshows a centralized connection between controllers and switches at the control and dataplane respectively.

Figure 2.2. – Centralized Configuration



Figure 2.3. – Distributed Configuration

The disadvantage of having such system is that it is prone to attacks, particularly singlepoint of failure which can also lead to an entire crash of the system because if thecontroller goes down, the entire network also goes down. Another form of configuration isthe distributed system as shown in Figure 2.3. This form of configuration is more robustas compared to the centralized configuration because it consists of multiple controllers,thus, it can combat the issue of single point of failure experienced in the centralizedsystem. As seen from Figure 2.3 above, various controllers are present in a single networkand the controllers are mapped to different switches. Therefore if one controller goesdown, the entire network does not go down because other controllers and switches in thenetwork remain active. There is also the possibility whereby two controllers can serve asingle switch (as in the case where controllers C0 and C1 are connected to switch S1) inthe figure above. For this scenario, one controller can serve as the master or primarycontroller which has the full responsibility for switch S1 while the other controller C1 canserve as a slave or secondary controller which is called upon for backup when controllerC0 is down. For both the centralized and distributed configuration, communicationbetween the SDN planes is made possible via the southbound interface (which allowscommunication between control and data plane) and the east/west bound interface(which allows communication between two different control planes). These interfacesincluding the northbound interface that allows interaction between the control planeand application plane will be discussed in section 2.4.

2.3.3 Data Plane

The data plane is the part of the SDN architecture that carries data traffic from onepoint to another within the network. It is the forwarding plane of the SDN, therefore, it



consists of forwarding elements like physical and virtual switches. Some examples ofphysical switches are Pronto 3290 and 3780, IBM Rackswitch G8264, Juniper MX-Series,etc. while virtual switches include Open vSwitch, Pica 8, Nettle, Panton, Indigo etc. [15].These forwarding devices do not take forwarding decisions on their own, rather, theyrely on the instructions that are installed in them from the controller at the controlplane. Therefore, when a new packet comes into the network from a host, the switchfirsts interacts with the control plane to obtain forwarding rules for the packet. Theserules are then installed in the switch for the forwarding of subsequent packets fromsame host.

2.4 SDN Application Programming Interfaces

The interfaces that makes communication possible between the different SDN planes arethe Northbound Interface, Southbound Interface and the East/West bound Interface.Figure 2.4 below shows the SDN architecture with all interfaces and the protocols whichthey use.

Figure 2.4. – SDN architecture with all interfaces and protocols [11]

• Northbound API: The Northbound API is located between the application planeand control plane. It is a bidirectional link therefore it supports communication fromthe control plane to the application plane and vice versa. In one direction (fromcontrol plane to application plane), the controller uses the API to communicatewith direct applications about the state of services in the network. For example, itcan request the applications to process services as required for situations wherethe entire network service is unavailable. At the other direction (from applicationplane to control plane), applications can communicate with the controller via the



API to request for different changes in the services provided by the network basedon information from end users. According to authors in [6], the northbound APIis not standardized, therefore, it is more controller specific, meaning that differentapplications are written for specific controllers to perform different functions likesecurity, billing, business, etc.

• Southbound API: The Southbound API is located between the control plane anddata plane. It is the most important API in the SDN architecture because itis through it that control in the network is done. It also allows for changes tobe made dynamically within the network based on different demands. Just likethe northbound API, this API is also bidirectional. In one direction (from dataplane to control plane), forwarding devices like a switch can communicate withthe controller to provide essential information like the current states of links orswitches present in the network. For instance, if a switch goes down, an alert canbe sent to the controller via this interface so that the necessary adjustments canbe made. At the other direction (from control plane to data plane), the controllercan send rules and policies to the switches, telling them what to do based ondifferent scenarios.

• East/West API: The East/West API is located specifically at the control planeof the architecture. It enhances communication between controllers in a networkhaving multiple controllers and it can also support connections between twocontrollers that are working at different networks. It is a bidirectional link just likethe northbound and southbound API, therefore, all controllers within or outside anetwork can send information between each other in both directions. This interfaceis useful for instance in situations where only one controller cannot be enough toserve a certain purpose. As identified by [16], an example of such application is inthe Byzantine Fault Tolerant System that involves the reaching of an agreementbetween multiple controllers on where a packet is to be sent before it is sent.Another application is for a situation where a backup controller is needed toprevent total shutdown of the network due to single point of failure. Using thisinterface in practice can lead to two different controller configurations which are;controllers having equal rights or a master and slave configuration where the slavecontroller is called upon for operation only when needed.

Among all these interfaces, the most widely used is the Northbound and SouthboundAPIs due to the fact that major applications require just one controller to function,thus, only communication from application plane down to the data plane and vice versais what is needed. A scenario involving this flow of communication can be seen in a



security service offered by a system. For instance, a security application is operatingat the application plane with the duty of preventing malicious traffic with a certainIP address from accessing the network. Once the application detects the IP addresstrying to access the network, it immediately sends information to the controller viathe Northbound API to inform the controller about the potential threat and furtherrequests that the device from which the IP originated should be blocked. Furthermore,the controller sends information as rules to the switch to block all the traffic originatingfrom such IP address. Once the rule is executed, the switch reports to the controllerand the controller further reports back to the application to indicate a completed task.

2.5 SDN Protocols

There are various protocols used at the Northbound and Southbound interfaces. Althoughthe northbound interface is not standardized as stated by [6], examples of protocolsused are REST, REST-CONF, JAVA API, etc. At the southbound interface, variousstandardized protocols exists like OpenFlow, NetFlow, IPFIX, SNMP, NETCONF,PCEP, ForCES, etc. Among all these protocols, the most widely used and well knownprotocol is the OpenFlow protocol which will be extensively discussed below.

2.5.1 OpenFlow Protocol

The OpenFlow protocol is the key to the entire SDN technology. This is because itdefines the way the communication between the controller and switches at the controland data plane respectively is done. With this protocol, several rules and instructionscan be added or removed from the flow table of the switched at the data plane whichwill make the network more dynamic and responsive to real time changes and trafficdemands. As shown in Figure 2.5, the protocol basically consists of three functionalelements which are; an OpenFlow controller, OpenFlow switch and a secured channelthrough which the controller and the switch communicates.



Figure 2.5. – OpenFlow functional elements

This protocol thus makes the abstraction of the control plane from the data planepossible. Through the secured channel, the switch at the data plane can give importantinformation like port statistics and flow rule statistics to the controller. The flow rulestatistics are contained in the flow table of the switches and the minimum set of flowentries in a flow table are the source and destination MAC addresses, source anddestination IP addresses which make up the match field corresponding to a certainaction as defined by the controller.

MAC SRC MAC DST IP SRC IP DST Action00:00:00:00:00:03 00:00:00:00:00:02 10.0.0.3 10.0.0.2 Output: 200:00:00:00:00:01 00:00:00:00:00:06 10.0.0.1 10.0.0.6 Drop

Table 2.1. – Minimum set of entries in a flow table of an OpenFlow switch

For every traffic that comes into the SDN environment, the addresses are matchedagainst a certain action. In situations where no match exists, the packets are forwardedto the controller as PacketIn messages so that the controller can decide what to do withthe packet. The flow of packets involving the switch and controller is shown in the flowchart below



Figure 2.6. – Packet flow in an SDN

From the flow chart above, when a packet is received by the switch in the network, itfirst analyses the header fields in order to obtain the components which will be usedfor a match in the flow table of the switch. If the entries are found in the flow table, amatch will occur and an action corresponding to the match will be carried out. Someactions could be to forward the packets to a certain port, drop the packets or even floodit to all ports in the network. This actions depend solely on what was installed by thecontroller in the switch. There is also the situation where several entries can occur ata time. In this case, prioritized packets are forwarded first. However, if no match isfound in the flow table, the switch sends this packet to the controller as a PacketInmessage for further evaluation. The controller then decides the best action for the packetand sends this information to the switch as a PacketOut message. Furthermore, thisinstruction is installed in the flow table of the switch in order to look out for subsequentpackets that will originate from the same device with the same field sets. OpenFlowprotocol supports three types of messages which are; controller-to-switch, asynchronousand symmetric messages [17].

1. Controller-to-Switch Message:This form of message originates from the controller and then sent to the switch.The message can be used to give instructions to the switch to obtain the currentstatus of the switch. Some of these messages like the configuration and featuresmessage require response from the switch back to the controller. Other controller-to-switch messages are; Modify-State, Barrier, Role-Request, Read-State, etc. Allmessages that fall under the controller-to-switch category are further explainedbelow for clarity.

• Features Message: Upon the establishment of the OpenFlow channel betweenthe controller and the switch, the controller sends an OFPT_FEATURES_REQUEST

message to the switch. This request is used to obtain certain information likeflow statistics, flow tables, port statistics, datapath ID, etc. of the switch andthe switch replies using the OFPT_FEATURES_REPLY.



• PacketOut Message: The PacketOut messages are issued by the controllerto the switch when a switch sends a PacketIn message to the controller toinquire about an action to be carried out on a packet whose flow entries aremissing. The PacketOut messages is thus sent to a particular port of a switchand it must contain a corresponding action which the switch is expected totake on the packet.

• Modifiy-State Message: The flow entries in the flow table of the switches aredynamically changed to respond to different network scenarios and this ismade possible via the modify-state message. This message is used to modifyflow entries and also to add or remove flow entries from the flow table of theswitches. It can also be used to modify the properties of the switch’s port.

• Barrier: For every operation carried out in the network, the controller sendsbarrier requests to ask for notifications of completed operations. The switchin turn replies using the barrier reply message.

• Role-Request Message: The role-request message is used in scenarios where asingle switch is connected to multiple controllers. In this case, this requestis used by the controller to set the role of the OpenFlow channel that bothdevices are using for communication at that moment.

• Read-State Message: The read-state message is used to obtain the switch’sstates information like the statistics, the configuration or its current capacity.

2. Asynchronous Message:This form of message do not require a request from the controller before they aresent. They are sent spontaneously based on the activity of the network at anygiven time. The various types of asynchronous messages are; PacketIn, Port status,Flow-Removed and Error message.

• PacketIn Message: When a packet enters the network and goes to the switch,the switch checks the flow entries in the flow table to match it against anaction instructed by the controller. If the entries are not found, it is recordedas a table miss which then results in the generation of the PacketIn eventsent to the controller to inquire about the action to be taken on the packet.

• Port-Status: Sometimes, changes may occur on the port of a switch and thecontroller is able to know about these changes from the port-status messagesent by the switch. This message is therefore sent during situations wherethe port configuration or state of the port on a switch has changed.



• Flow-Removed: The controller can instruct a switch to remove certain flows inits flow table or most times, the flow rules in the table have certain timeoutsand are removed when these timeouts are overreached. For both cases, theswitch will send the flow-removed message to the controller to inform it aboutthe change done in the flow table.

• Error Message: The OFPT_ERROR message is used to inform the controllerabout errors or problems in the network.

3. Symmetric Messages:The symmetric messages are sent in both directions (from controller to switchand vice versa) without the need for any request from either the switch or thecontroller. Examples of symmetric messages are; Hello and Echo messages.

• Hello Message: The hello messages are initiated and exchanged between theswitch and the controller when a connection is established. When this con-nection establishment is done, both entities send the OFPT_HELLO messages.

• Echo Message: The Echo message is used to verify if a connection betweenboth entities (controller and switch) is still active. They can originate fromeither the switch or the controller. Any entity that originates the messagesends an echo request while the other entity gives response with an echoreply.

2.6 OpenFlow Specifications

Various OpenFlow specifications have been developed by the ONF since 2009 and whatmakes each specification different from another is the type of match fields. For every newspecification developed, a different match field is added. The specifications developedso far are OpenFlow 1.0, 1.1, 1.2, 1.3, 1.4 and 1.5. Among all these, it is only the 1.0specification that uses a single flow table, others support multiple tables and pipelineprocessing.

2.6.1 OpenFlow 1.0

The OpenFlow 1.0 protocol was released by the ONF [10] in December 2009. For anOpenFlow switch using this protocol, three entries define the full functionality of theprotocol and they are; the flow table which is used to perform matching of incomingpackets, a controller and a secured channel that enhances communication between the



switch and the controller [18]. Figure 2.7 below shows the internal structure of a switchthat operates on the OpenFlow 1.0 protocol specification.

Figure 2.7. – OpenFlow 1.0 switch structure [18]

The flow table consist of flow entries which are characterized by headers, counters andactions. The header fields are used to perform matching of incoming packets to rulesor actions specified by the controller. The counters are used to store the number ofpackets that are received as well as the duration of flow. Therefore, all flow statistics arecollected using the counter. Furthermore, the action field defines what is to be done on apacket based on the information extracted from the header. An example of an action isto send the packet through a specific port, flood the packet through all ports or modifysome fields in the packet. Examples of the modify field action which is done only onIPv4 packets are; modify source and destination address, modify Type of Service (ToS)bits. The transport source and destination ports can also be modified on TransmissionControl Protocol (TCP) and User Datagram Protocol (UDP) packets. Generally, thedefault action on packets is to drop the packet if no rule was defined.

2.6.2 OpenFlow 1.1

OpenFlow 1.1 protocol specification [19] was also released by the ONF in February 2011.Just as in OpenFlow 1.0, the controller, secured channel and flow table define the fullfunctionality of the protocol. However, in the 1.1 specification, there is the presence ofmultiple tables. Figure 2.8 shows the internal structure of an OpenFlow switch thatsupports the OpenFlow 1.1 protocol.



Figure 2.8. – OpenFlow 1.1 switch structure [19]

The major difference therefore between the 1.0 and 1.1 specification is that the laterhas multiple flow tables and a group, therefore, it supports pipeline processing. Theconcepts of group table and pipeline processing will be further discussed in section 2.7.The flow table also contains flow entries that are characterized by match fields, countersand instructions. The match fields are used to match against incoming packets and itbasically consists of packet headers, ingress ports and metadata value [6]. Just like inprotocol 1.0, when a new packet comes into the network, the contents of the packetheader are extracted and matched against what is stored in the flow table of the switch.If a match is found, the instruction specified for such match is applied but in case of atable miss, the packet is forwarded to the controller or dropped by the switch basedon the specified action. Due to the fact that this protocol supports the use of multipletables and pipeline processing, the metadata value present in the match field is thereforeused to transfer information from one table to another. The function of the counter isjust the same as in the OpenFlow 1.0 protocol. The presence of multiple tables and agroup table also brought a little change in the way instructions are executed in thisprotocol as compared to the previous. The instructions thus contain a set of actionsthat can be added to an action set. An action set is a set of rule that is associated to apacket when it is processed at different tables and are applied to the packet at the endof the pipeline processing when the packet finally leaves the last table. The differenttypes of instructions that exits in this protocol are; Apply-Actions, Clear-Actions, Write-Actions, Write-Metadata, and Goto-Table [19]. For the Apply-Actions, the specifiedactions are carried out immediately on the packet without the need to modify the actionset contained in the pipeline. The actions carried out in this form are specified in anaction list which are like the same set of actions like in protocol 1.0. The Clear-Actions



instruction is used to clear all the actions that are present in an action set. Therecould also be the need for adding new actions to the action set and the Write-Actionsinstruction is used to make this achievable. It is thus used to add new actions into anexisting action set but for a situation where the new action is same as what is present inthe action set, an overwrite is done. The Write-Metadata instruction is used to updatethe metadata field while the Goto-Table instruction is used to indicate the next tablethe packet will be forwarded to in the pipeline. With the Goto-Table instruction, a tableID is an important element used to ensure that the packet arrives at the right table.

2.6.3 OpenFlow 1.2

OpenFlow 1.2 protocol specification [20] was released by the ONF in December 2012.The internal structure of a switch that supports this protocol is just like in Figure 2.8having a secure channel for communication with the controller, multiple flow tablesfor pipeline processing and a group table. This protocol supports IPv4 just like thepreviously described protocols but one new feature introduced was also the ability tosupport IPv6. Therefore, it can perform matching against IPv6 matrices like source anddestination addresses, protocol number, flow label, traffic class, etc. [6] . The protocolalso offers flexibility such that network providers have the liberty of including any othermatching possibility which they require and this is made possible via the OpenflowExtensible Match (OXM) feature the protocol possess. Another interesting featurepresent in the protocol is that it gives the switch using it the possibility of connecting tomultiple controllers. This was not possible in the 1.0 and 1.1 protocol. Thus, while using1.2 protocol, switches can be configured to connect and communicate with multiplecontrollers at the same time and in such scenarios, one controller will serve as the primaryor master controller while the others will serve as the secondary or slave controllers.

2.6.4 OpenFlow 1.3

OpenFlow 1.3 protocol specification [21] was released in June 2012 by the ONF. A switchrunning this protocol also has the same internal structure having a secure channel, one ormore flow tables and a group table as described previously in 1.1 and 1.2 specifications.A major introduction to this protocol was the addition of QoS feature. This was madepossible due to the introduction of meter table that is attached to every flow entry so asto measure the rate of incoming packets. The meter table contains three entries whichare; meter identifier, meter bands and counters [6]. The meter identifier is specificallyused for attaching a meter to a flow entry while the meter bands is used to limit the rateof packets that are flowing through the switch. Therefore, to enhance QoS, packets caneasily be dropped whenever they exceed a certain specified rate. OpenFlow 1.2 protocol



supported switch connection with multiple controllers and this is also possible in the 1.3protocol. However, for the 1.2 protocol, only fault management like the prevention ofsingle point of failure was mainly considered for the master/slave configuration but forthe 1.3 protocol, extended functionalities like the implementing of load balancing is alsopossible. Thus, the main feature that distinguishes 1.3 and 1.2 protocol specifications isthat the later supports monitoring, Operation and Management (OAM) while the formerdoes not. Table 2.2 shows the various match fields for all the protocol specificationsdiscussed above.

OpenFlow Protocol Specification Match Fields

Version 1.0

Ingress PortIPv4: Src IP, dst IP, proto, ToS bits

Ethernet: src, dstVLAN: ID, priority

Version 1.1

IPv4: src IP, dst IP, proto, ToS bitsEthernet: src, dst

MPLS: Label, Traffic ClassVLAN: ID, priority

TCP: src port, dst portUDP: src port, dst portIngress port, Metadata

Version 1.2 IPv6: src IP, dst IP, flow labelICMPv6

Version 1.3 IPv6 Extension headers

Table 2.2. – Match fields for different protocol specifications [22]

2.7 SDN Components

The main components that are present in the SDN framework are the controllers andswitches. The controller is the central intelligence of the system because it is in chargeof installing forwarding rules in the switches or instructing the switch on what to do toincoming packets during different network scenarios. Thus, the switches are dumb devicesthat just forwards packets based on the instructions from the controllers. Table 2.3shows a list of some SDN controllers and the languages which they support.



SDN Controllers Programming Language usedBeacon JavaDISCO Java

Floodlight JavaNOX Python, C++Onix Python, CONOS Java

OpenDaylight JavaPOX PythonRyu PythnnSNAC C++

Table 2.3. – SDN controllers and the language they support [11]

Ryu controller was used for this project and a brief description about the controller isdiscussed in the section below.

2.7.1 Ryu Controller

Ryu controller is an open sourced Network Operating System (NOS) licenced underApache License v2 [23]. It consists of a control interface that is programmable and canlogically connect to multiple OpenFlow switches. The programmable network interfacepermits network administrators to create applications that control and perform networkfunctions on the Ryu framework. The language used for this purpose is python, justas seen in Table 2.3 above. Ryu [24] is also a component-based framework because ithas various templates and pre-defined structures that can be reused or modified tocustomize network functions to meet various requirements. Some of the components thatthe Ryu framework possess are REST API, Topology Viewer, Firewall, L2 switch, snort,etc. The L2 switch component is an important component in the framework becauseit serves as a benchmark for implementing a learning switch which is the standardoperation of an OpenFlow switch and OpenFlow protocol. Snort also, which is an IDSthat is used in traditional network is embedded in the Ryu framework and with thiscomponents, network operators and vendors can easily implement different securityfeatures in the network without overburdening the controller with a lot of activities at atime. The concept of snort operation for network security was used for this project andwill further be discussed in chapter 4. For the logical connection between the controllerand the switch, Ryu also supports both centralized and distributed form of connection.For the centralized configuration, a single Ryu controller is used to serve all switches



in the network. This form of connection is prone to single point of failure as statedearlier. However, it can be mitigated using the distributed approach where multipleRyu controllers are connected to a single switch as primary and backup controllers.For advanced network functions, Ryu controller also supports load balancing whichinvolves the connection of multiple Ryu controllers to each other via the East/WestAPI as discussed in section 2.4. Different protocols like NetConf and OF-Config isalso supported by Ryu controller and most importantly, different specifications of theOpenFlow protocol (1.0, 1.1, 1.2, 1.3, 1.4 and 1.5) can also be used by Ryu. Some otherimportant components of Ryu are the Executables, the Base Components, OpenFlowController, Ryu applications and Libraries which will be explained below [24].

1. Executables:The executable file enables Ryu to be able to run on a local machine. The mainexecutable file in Ryu controller is the bin/ryu-manager.

2. Base Components:The base component present in Ryu is the ryu.base.app-manager. The functionof this manager is to load Ryu applications, ensure messages are routed properlyamong Ryu applications and it also provides different contexts to Ryu applications.

3. OpenFlow Controller:This component contains various features which enable the optimum operation ofthe OpenFlow protocol. The features are defined below.

• ryu.controller.controller: This is the main component of the OpenFlow con-troller that handles connections from switches and also generates and routesevents to specific Ryu applications.

• ryu.controller.dpset: This feature performs switch management functions.

• ryu.controller.ofp-event: Various events like packet flow or port statistics re-quest/reply are triggered during initial connection or communication betweenthe Ryu controller and the switch and this feature defines how these eventsoccur.

• ryu.controller.ofp-handler: It defines basic OpenFlow functions like connectionnegotiation.

4. Ryu Applications:Ryu controller have some embedded applications in its framework and they include;ryu.app.cbench, ryu.app.simple_switch and ryu.topology.



• ryu.app.cbench: This application operates only with the OpenFlow 1.0 pro-tocol. It is used as a responder for benchmarking the Ryu controller.

• ryu.app.simple_switch: This application is used for learning a switch thatis connected to the SDN framework. It also operates on the OpenFlow1.0 protocol. However, an advanced application like simple_switch13 cansupport the OpenFlow 1.3 protocol.

• ryu.topology: It is used for switch and link discovery.

5. Libraries:Ryu also has different libraries that contain resources used for effective softwaredevelopment. The libraries contain some configuration data, codes and specifi-cations that aid in the efficient operation of created applications. Some of thelibraries are;

• ryu.lib.ovs: This library supports control and management of Open vSwitchand ovsdb-server. It also aids in performing switch configuration like creating,deleting or modifying of ports and interfaces. In a nutshell, it contains anOpenFlow configuration protocol that is used to manage Open vSwitch.

• ryu.lib.packet: It is a Ryu packet library that makes the implementation ofprotocols like TCP/IP possible.

• Ryu.lib.xflow: The library has two components which are sFlow and NetFlow.These components can be used to perform traffic analysis on packets thatflow through the network.

• ryu.lib.of-config: The library is used for the implementation of the OF-Configprotocol.

• ryu.lib.netconf: NETCONF is also a protocol supported by Ryu controllerand this is made possible with this library. The library therefore providesdefinitions used by the ryu/lib/of-config extension.

2.7.2 OpenFlow Switch

An OpenFlow switch is also an important component that make up the SDN framework.The main features that make up the switch as defined by [10] are one or more flowtables (for switches running on OpenFlow 1.1 and above), group table, meter table,physical and logical ports and also a secured channel used for communication between



the control plane and data plane. The switch also supports 3 types of ports namely;physical port, logical port and reserved port.

• Physical Ports: Communication between different hosts in a network is done viadifferent types of ports and the physical port is the most widely used port becauseit is associated with the hardware interface of the switch. Thus, a physical portcan exist only a physical switch. It is also known as the Ethernet interface of theswitch.

• In contrast to physical ports, the logical ports of an OpenFlow switch are notassociated with the hardware interface of the switch. They are abstracted ports andare used for connecting applications that mainly run on TCP/IP protocols. In theOpenFlow environment, the main difference between the physical and logical portsis that packets corresponding to logical ports have Tunnel ID as an extra metadatafield [21] . This tunnel ID aids in tunneling packets from source to destination fordifferent types of applications. Just like in traditional networks, some well-knownlogical ports are port 80 for Hyper Text Transfer Protocol (HTTP), port 23 forTelnet, port 53 for DNS, port 25 for Simple Mail Transfer Protocol (SMTP), etc.

• Reserved Ports: In SDN, reserved ports are used to specify different controllerforwarding actions. Some of these actions supported by the OpenFlow switchesare; forwarding a specific packet to the controller, flooding of packets through allports or sending packets to different tables in the case of pipeline processing. Thediagram showing the full features of an OpenFlow switch is shown in Figure 2.9.

Figure 2.9. – Internal structure of an OpenFlow switch [25]



2.7.2.1 OpenFlow Channel (Secured Chanel)

A secured channel for communication between the switch and controller is maintainedusing the Transport Layer Security (TLS) protocol [26]. The main idea behind the TLSprotocol is to ensure that the controller and switch communicate in a secured mannerwith the aid of some sort of encryption. Therefore, through the protocol connection, bothparties (controller and switch) negotiate on what key to be used for the encryption anddecryption of message that is shared between them and that way, full trust is establishedbetween both devices. This form of security prevents attackers from modifying oreavesdropping on the content of data that is being shared between the switch and thecontroller. Generally, the TLS connection establishment begins with the TLS handshakeas described by [27]. The first step involves the sending of the ClientHello message fromthe client to the server as seen in Figure 2.10 below.

Figure 2.10. – TLS handshake procedure

In the case of SDN, the server could be the controller while the client could be the switchthat wishes to exchange information upon initial connection to the controller in thenetwork. The ClientHello message contains various information like the TLS version theclient is operating on, the type of compression methods it uses as well as the cryptographicalgorithms that it can support. Upon the reception of this ClientHello message, thecontroller responds with a ServerHello message which contains a cryptographic agreement(the cryptographic algorithm chosen by the controller from the list of algorithms providedby the switch), session ID, digital certificate and a public key. The public key sent by thecontroller is used by the switch to encrypt data that will be sent back to the controller.As a third step, after the reception of the ServerHello message from the controller,the switch verifies the controller’s digital certificate so as to ascertain its authenticity.



Once this is done and trust has been established between both devices, the ClientKeyExchange is done whereby the switch shares a secret key to be used for the data exchange.The final step of the handshake process includes the sending of the Finished message byboth the client and server to indicate the completion of the handshake by both parties.After the entire handshake process is complete, data exchange can then be done securelyusing the shared secret key.

2.7.2.2 Flow Tables

The flow table is an essential feature present in the switch because it contains rulesand instructions as to how a packet received by the switch is handled. Every flow tablecontains flow entries and the minimum set of entries that can be contained in a flow tableare the MAC address of source and destination, IP address of source and destinationas well as an action that corresponds to these addresses. However, based on certainapplications, there can also be the presence of other entries like Ethernet type, VirtualLocal Area Network (VLAN) tags, port statistics etc. Switches operating on OpenFlow1.1 and above can have more than one flow table, depending on the type of applicationrequired. The presence of these multiple flow tables brings about the possibility ofpipeline processing that will be discussed below.

• Pipeline Processing: Pipeline processing [19] involves the execution of multipleactions on a packet through different tables. The pipeline thus determines theflow of packet from one table to another within a single switch. All tables in thepipeline are labeled sequentially with an ID and the first table always begins withthe ID number 0. Figure 2.11 shows the pipeline process flow of a packet in anOpenFlow switch.

Figure 2.11. – Pipeline processing [20]



The flow of packet starts at table 0 and at this state, the metadata value will be empty.As discussed in section 2.6, the metadata value is used to carry information from onetable to the next table, therefore, when the “Goto” instruction is used to refer a packetto the next table for further processing, the metadata value is also updated at the nexttable and also during the entire pipeline flow. It is important to note that pipelineprocessing only happens in the forward direction, therefore, the next table where thepacket is sent for further processing must have an ID number that is greater than theprevious table. Also, the last table on the pipeline do not have the “Goto” instructiondue to the fact that there will be no other table in the forward direction to send thepacket to and the pipeline does not operate in reverse direction. The pipeline processautomatically ends when there is no “Goto” instruction and at the end of the pipeline,the action set corresponding to the packet involved is executed.

2.7.2.3 Group Tables

The features of a group entry that make up a group table are the Group Identifier,Group Type, Counters and Action Buckets [20]. The processing of a packet comes intoaction when an entry in a flow table refers a packet to a group using the group identifier.Therefore, the group identifier is a unique number used to identify a certain group thatserves as a reference to which a packet can be directed to for further processing. Thegroup type is concerned mainly with the set of action buckets that will be executed on apacket. As described by [6], the four different group types are; All, Select, Indirect andFast Failover. The group type “All” is used when all the buckets in the group are to beexecuted. This works perfectly in scenarios where there is need to send a multicast orbroadcast message. In contrast, the “Select” group type is used in situations where oneaction bucket is to be executed. That is, only a single bucket in the group is used toprocess the packet. The “Indirect” group type is also used to execute a single bucketjust like the “Select”. The “Fast Failover” is a more dynamic group type that is usedfor the purpose of setting up backup routes for processed packets. That is, it is used tore-route packets from their initial route. Take for instance a group table contains twoaction buckets in its entry with the first action having an instruction to forward thepacket through port 1 of a certain switch and the second instruction is to forward itthrough port 2 of the same switch. The initial route here is port 1 while the backuproute is port 2. When port 1 is up and running, all packets are forwarded through itbut when it eventually goes down, the packets will then be re-routed through port 2.This “Fast Failover” group type thus helps reduce controller workload when configuredespecially for urgent situations because the switch will not need to contact the controllerto inquire the path to take due to the breakdown of port 1. As described in previous



sections also, the counters present in the group entry of a group table are used to obtainthe statistics of the packets that are processed in a particular group. The final entrywhich is the Action Bucket has the various actions that is required to be executed on apacket depending on the group type that was also previously discussed.

2.7.2.4 Meter Table

The meter table comes into action mostly when there is need to implement QoS in thenetwork because it contains a meter that is used to measure and control the rate of flowof packets. The entries that make up the meter table are; Meter Identifier, Meter Bandsand Counters [21]. The Meter Identifier is a unique number that is used to identify aparticular meter. The Meter Band contains further entries which are; Band Type, Rate,Counters and Type Specific Arguments [21]. The Band Type is used to define how apacket will be processed. The “Rate” specifies the extent at which a particular bandwill operate while the counters are used for statistics implementation and are alwaysupdated after the processing of a packet by a meter band. The last feature which is the“Type of Argument” field specifies what should be done to a packet when the rate isexceeded. An example of “Type of Argument” action is drop or discard packet.


Chapter 3

Security in SDN

3.1 Security Threats in SDN

Software Defined Networking is the latest trend in the area of networking [6] due tothe operational flexibility it possess. This flexibility is as a result of the nature ofthe architecture having control plane and data plane separated to perform functionsin a programmable manner. However, the nature of the architecture makes it proneto different forms of security issues like unauthorized access, data leakage, flow rulemodification, malicious application implementation, etc. [15]. Also, as described by [28],the security threats that can potentially occur in SDN are; forged or fake traffic flows,control plane communication link attack, compromising of switches and controllers,unauthorized communication between application plane and control plane and attackson administrative stations. However, among all forms of attacks that can occur in SDN,the most common of all is the DDoS attack and this is because of how easy it is for itto be implemented and how difficult some varieties of it is challenging to detect andmitigate. DDoS is a form of attack on a server or device where multiple packets are sentat an instant to the server with the aim of deteriorating the server and preventing itsusage by legitimate users [29]. Thus, the main aim of DDoS is to make the networkunreachable. To make this possible, an attacker can make use of spoofed IP or MACaddress to attack the system by sending a huge traffic from multiple sources [30] andthis is a huge problem in SDN due to the nature of how the OpenFlow protocol operates.As discussed in chapter 2, a new IP or MAC address of a host attached to the networkwill create a table miss in the flow table of the switch during the first instance of packettransfer from source to destination, thus, for a spoofed IP or MAC address, these newpackets will constantly be sent to the controller which can lead to negative effects on


3. Security in SDN

the entire system like exhaustion of the controller’s resources, bandwidth exhaustion,application usage prevention, host unreachability or flow table overload. All these effectscan further lead to a significant drop in the performance of the entire network due tothe sudden increase in traffic. DDoS can also be accomplished using botnets and in thiscase, the entire process consists of three entities which are; the attacker, the botnets(zombie systems) and the victim. Generally, botnets are created by installing of malwareon the computers through processes like phishing, reception of spam messages, accessingof corrupted web link, downloads from malicious web pages, USB drive or any otherform by which the pathway to the victim’s computer can be accessed [29]. Figure 3.1shows the execution of DDoS attack using botnets.

Figure 3.1. – DDoS attack using botnets [31]

To effectively carry out the attack, the attacker will first select the zombie systemsto use and then set up the attack mechanism in them by installing the malwareapplications. Once this is done, the attack can easily be launched by the attacker bysending commands to the zombie systems through a secured channel. Since they aredifferent systems (multiple zombie systems), there will be the presence of different IPand MAC addresses on the headers of every packet going into the system, thus, a tablemiss will always occur, making the switch to send all packets to the controller whichin turn will lead to the exhaustion of the controller’s resources and a breakdown ofthe entire system. DDoS can occur at all layers of an SDN system, therefore, it can beclassified in three sections which are application layer attacks, control layer attacks anddata layer attacks [15].

• Application Layer Attacks: The application layer of the network contains varioususer applications like e-mail, web services, VoIP services, etc. An attack on this


3. Security in SDN

layer can be done on any of these applications in such a way that the attacker willsend multiple packets to crash the server and make it inaccessible for the user. Theapplication plane of the SDN architecture can also be attacked by compromisingthe northbound interface which is the communication link between the applicationplane and control plane [25].

• Control Layer Attacks: Being that the control layer is the central intelligence ofthe system and houses the device (controller) that passes important rules andinstructions for all network operations, it is more prone and a major target forthe DDoS attack. The attack on this plane can be done either at the northboundinterface, the southbound interface (which is the communication link between thecontrol plane and data plane), the East/Westbound interface (communication linkbetween two different control planes) or an attack on the controller itself. Theattack on the controller is the most common form of DDoS attack because it justinvolves flooding the controller with multiple packets from the data plane whichcan lead to resource exhaustion and bandwidth consumption. The control planeis thus prone to single point of failure although this problem can be resolved bydeploying multiple controllers in the network such that other controllers can serveas backup when one goes down due to the attack.

• Data Layer Attack: At the data link layer, the switch is the primary target forthe attack. Although attack can also be done at the southbound interface so as toprevent communication between the switch and controller. The switches at thedata plane have the Ternary Content Addressable Memory (TCAM) [32] that isused for the storing of flow tables that contain the flow entries and this memory islimited in size. This therefore makes it vulnerable to attacks as DDoS attackers canexploit the limited memory space by sending millions of packets to the switch untilit gets full and breakdown, thereby preventing legitimate packets from coming in.

3.1.1 Security Advantages of SDN to Combat DDoS Attacks

Although the SDN architecture is prone to DDoS attack easily, the centralized nature ofthe control plane makes it advantageous in combating the attack [105] and the followingreasons makes it beneficial;

1. The controller has a global view of the network therefore it can analyze andmonitor the entire traffic flow in the network. This makes it easy for it to installproper security policies as well as prevent potential threats from occurring.


3. Security in SDN

2. Based on the traffic analysis, the controller can also deal with affected hosts andswitches in the network. For instance, the controller can easily block a host fromwhich an attack was initiated. It can also remove flow rules from switches insituation where the switch was compromised.

3. Due to the fact that the SDN architecture is open and programmable, the controlplane can quickly respond to attacks and resolve them easily at any point of thenetwork and at any time of occurrence.

3.2 State of the Art

Distributed Denial of Service (DDoS) attack has been a major concern in the field ofnetworking, particularly in Software Defined Networking and although there are stillmajor concerns on how to effectively mitigate the attack, various authors have proposedsome methods that have so far proven to be reliable. The authors in [33] proposed thatfor better security, the attack detection should be done at the switches in the networkbecause there are more switches than controllers in an SDN architecture. They thereforesuggested that the switch does a pre-processing of the received flow which will generatea summarized statistics that has information about changes in flow rate and it willbe sent to the controller. To achieve this, they first considered the DDoS to be of twoforms which are; Route Spoofing and Resource Exhaustion and they proposed countermeasures for both forms of the attack. For the route spoofing, selective blocking wasdone in such a way that incoming packets are checked against a set of security policiesthat were installed on the switches. Suspected messages will then be forwarded to thecontroller to take further actions. In this way, adversary nodes will be stopped frommaliciously using the active communication routes of legitimate users. For the secondattack case which is resource exhaustion, periodic monitoring was done which detectsadversary nodes based on the traffic analysis statistics that was gathered within a timewindow. The periodic monitoring had two phases for the attack detection which are;“Entropy based” and “New low traffic flow based”. The entropy based also had twosub-components which are window size and entropy threshold value. The aim of theused methods was to reduce bandwidth consumption and processing delay as well asto increase packet delivery rate. The detection was done both for the cases of IP andMAC spoofing. However, the method was not focused on identifying or distinguishingmalicious hosts from benign hosts. It only focused on how to maximize bandwidth. Thepolicies were also installed on the switches which can cause memory exhaustion. [34]provided a means of protecting the controller and detecting DDoS attack by deployingmultiple controllers at the control plane such that one controller is the main controller


3. Security in SDN

which is responsible for processing flows while others are slave controllers that actas backup and remain idle under normal conditions but are active during the DDoSdetection. The multiple deployed controllers were capable of detecting the attack usingtwo methods which they called Anomaly Traffic Detection and Controller DynamicDefense. The anomaly traffic detection was done at the data plane with the functionof distinguishing forged flows from legitimate ones. Similarly, the controller dynamicdefense was done at the control plane with the function of remapping an overloadedcontroller to a new controller as well as sending access control messages to the switches.The authors combined two methods; Traffic Analysis which involved flow filtering toseparate legitimate packets from malicious ones based on some filter parameters andSelf-organized SDN controller cluster by multi-controller which involved using multiplecontrollers to increase the capacity of controller at the control plane during the attack.Their system design had four states which are initial state, detection state, defense stateand safe state. Also, the controller mapping had three phases which are; the identifyingstate where the controller affected by DDoS attack is first recognized, the election phasewhere a target control from the controller clustering is selected to serve as backup for theoverloaded controller and finally the composition phase which involves the establishmentof connection between the newly mapped controller and other switches. The schemeused by these authors is effective because it can checkmate major issues in the SDNenvironment, however, it involves the use of multiple controllers at a time. This thereforeentails that it cannot work in networks having just a single controller. Also, there isthe possibility of an attack on the backup controller, thus, there is no guarantee offull DDoS attack prevention using this method. The authors in [35] also proposed theuse of a mechanism called DoSDefender. The DoSDefender serves like an extensionmodule for the control plane and it performs the function of filtering malicious packetsfrom legitimate ones at the data plane. For effective operation, they proposed that theDoSDefender should have three modules which are; port management, attack detectionand flow rule installing. The port management just performs the function of recognizingthe presence of a PacketIn message and sending it to the attack detection module forfurther processing. When the packet arrives at this module, the validity of the packet isverified and in the case were the result is false, the third module which is the flow ruleinstalling is triggered for operation. This third module also consists of three categorieswhich are; construction of data structures, maintenance of mapping table and algorithmof attack detection. For the flow rule installing module also, once a malicious host hasbeen discovered, a drop action is installed in the switch connected to the responsiblehost. The problem with the mode of detection is that it involves a lot of processingwhich can increase overhead and also cause a delay in the round trip time for the flow of


3. Security in SDN

packet in the network. The use of entropy for an attack detection was also proposed byauthors [36] and [37]. For this method, the level of randomness in the network was thekey used in effectively detecting the attack. The authors made use of a threshold whichserved as a baseline to tolerate the amount of packets that can flow in the network.The use of entropy was not only based on a threshold but also on window size and theauthors decided that either a certain time frame or the number of packets can be usedfor the window size. To select an optimal threshold, they performed several experimentsso as to determine which value is best. To calculate the entropy as well, the authorsused the destination IP address and they stated that the entropy will be at maximumwhen each packet is sent to only one host at a time while the minimum entropy willoccur when all packets within the window size is sent to a single host. In this case, theentropy value will be lower than the threshold which will be detected as an attack. Theuse of entropy therefore requires that several experiments will be performed in order todecide the best value which is time consuming. Also, it was required that the windowsize should be set at a value which is less than or equal to the number of hosts in thenetwork so that a positive result will be achieved. Therefore, wrong choice of windowsize can greatly affect the result. Authors in [5] also used a defense mechanism calledPacket Checker. The Packet Checker filters the PacketIn messages according to theheader fields of the packets before messages are processed by the controller. It comparesthe MAC, Datapath Identifier (DPID) and In-port information to distinguish betweenlegitimate and malicious traffic. To verify legitimacy, they proposed to bind the switchport with host’s MAC address in the SDN controller based on the fact that the host’sMAC address doesn’t change. Packet Checker also sets up a mapping table for the MACaddress and switch port and the legitimacy of PacketIn messages is done by queryingthe mapping table. The problem with this scheme is that they assumed the case of astatic MAC address. The system fails if the attack comes from different host (whichwill definitely have different MAC addresses)

3.3 Network Abnormalities and DDoS Attacks in SDN

There are various forms of network abnormalities that occur in SDN, particularly relatingto DDoS and according to [38], these attacks can be grouped into 3 categories whichare; volume based attacks, protocol based attacks and application layer attacks. Thesedifferent categories of attack will be discussed extensively below.


3. Security in SDN

3.3.1 Volume Base Attacks

The main goal of the volume based attack is to exhaust the entire bandwidth of thenetwork or to make a host unreachable. It does this by sending huge amount of trafficat a time. Attacks that fall under this category are the UDP flood and Internet ControlMessage Protocol (ICMP) flood attacks

• UDP Flood Attack: The UDP flood attack is the most common form of DDoSattack that is being experienced in the network. It is very difficult to detectand mitigate due to the fact that it is connectionless and stateless protocol [39].Since it is connectionless, it does not require a connection setup or three-wayhandshake before data is exchanged between the client and server just like in TCP.To this effect, attackers can exploit the weakness of this protocol to execute aDDoS attack in the network. For the UDP flood to occur, the attacker will sendhigh amount of UDP packets at a very fast rate to random ports of the target.When the target receives these packets, it checks for services or applications thatare listening at these random ports or applications that are associated with thereceived packets but it would not find any one, thus, it sends a reply with thedescription “destination unreachable”. The key to make this form of attack moreeffective is by using a spoofed IP address. Figure 3.2 below shows an execution ofa UDP flood attack.

Figure 3.2. – UDP flood attack [42]

Without using a spoofed IP address, the ICMP reply sent by the target will bedirected back to the attacker which can also cause a flood on the attacker but withthe use of spoofed IPs or botnets as shown in Figure 3.2 above, all replies will besent back to these different IP addresses. Constant injection of these packets will


3. Security in SDN

lead to constant ICMP reply which will further lead to the exhaustion of resourcesof the host, making it unavailable for the flow of legitimate traffic.

• ICMP Flood Attack: ICMP is also a connectionless protocol just like the UDP.Due to this nature, it can also be used for volumetric form of attack at a very highspeed because a connection setup is not needed between the two entities involvedbefore data is being sent. ICMP is also known as ping and it is used to check forconnectivity between two devices that are connected in a network [40]. However,attackers can use it as a medium to make a certain host unreachable. To performan ICMP attack, an attacker sends huge amount of ICMP echo request otherwiseknown as ping to the victim. Every ICMP echo request requires an ICMP echoreply in turn, therefore, when sent at a very high speed and at large quantity, thevictim will not be able to reply all requests at a time which will further lead to itsunavailability to process legitimate traffic. IP spoofing can also be used for thisform of attack and in all cases, the entire bandwidth of the victim will be depleted,leading to its unavailability because the victim will not be able to process all therequests at a time to provide a response.

3.3.2 Protocol Based Attacks

The protocol based attacks is mainly targeted on exhausting the actual resources of theserver or to exhaust the resources of intermediate communication equipment like loadbalancers and firewalls [41]. DDoS attacks that fall under this category are the TCPSYN flood and IP Null attack.

• TCP SYN Flood: Every TCP packet contains a SYN that is used for connectionestablishment. This is important because for data exchange to occur betweentwo devices that uses TCP, connection establishment must occur via a three-wayhandshake. The TCP connection sequence between a client and a server is shownin Figure 3.3 and it involves three steps [42];


3. Security in SDN

Figure 3.3. – TCP 3-way handshake

1. Firstly, the client requests for connection by sending a SYN message to theserver.

2. The server receives the SYN message and replies with a Synchronous Ac-knowledgment (SYN-ACK) back to the client.

3. Lastly, the client confirms the SYN-ACK and opens full connection by replyingwith an Acknowledgment (ACK).

This process is done completely before data is exchanged between the two devicesand it’s important because it is used to ensure the authenticity between the clientand the server [41]. Attackers therefore exploit this connection establishmentprocedure in order to perform an attack on the system. This form of attack donot consume the memory or bandwidth of the target but its resources and abilityto make connections. For the attack to happen, the attacker sends multiple SYNrequests to the target without sending back an ACK for the received SYN-ACK.In this way, connection between the attacker and host will be half way open andonce the host reaches its limit of what it can process, it will not be able to processany other request particularly from legitimate sources due to the exhaustion of itsresources. A more dangerous way of performing the attack is by using a spoofed IPaddress. The attacker in this case will send multiple SYN requests using differentIP addresses. The host will in turn reply with a SYN-ACK to all these addresseswhich do not exist, therefore, an ACK for the SYN-ACK will never be gotten,resulting in a half-opened connection. Although this connection setup has sometimeout and will expire after the timeout which will make the TCP port available


3. Security in SDN

again for legitimate connection to occur but the speed at which the request comesmakes the host to run out of resources and be unavailable before the timeout.

• IP Null Attack: IP packets contain headers that carry information about the typeof Protocol e.g. TCP or UDP that will be used for processing at higher layers.This protocol field helps to successfully match each application to their requiredport or also provide some form of security checks but an attack on this protocolfield can prevent such network functions from actualizing. For this form of attack,attackers will set this protocol field on the packet header to be null, thereby makingit possible for the packets to bypass security mechanisms that were installed toscan the protocols (TCP or UDP). Due to the fact that these packets come in aflood pattern, the server will exhaust its resources because it will constantly tryto process the packets but not succeed because the protocol field of the packet isnull.

3.3.3 Application Based Attacks

The application based attack occur when a web page or any form of SDN applicationis affected. The goal of this attack is to crash the application and make it unavailablefor legitimate users. Attacks that are under this category are; HTTP Flood (GET orPOST), DNS Flood, DNS Reflection and Slowloris.

• HTTP Flood (GET or POST) Attack: The Hyper Text Transfer Protocol (HTTP)is used by the World Wide Web (WWW) for communication between two entities,usually a client and a server and it works as a request-response protocol betweenthe both of them [43]. Take for instance, a client wishes to access a web page, theclient from the browser will send a request to the server and the server will inturn give a response that contains the content that was requested for by the client.HTTP generally have various methods through which the protocol functions andthese methods are; GET, POST, PUT, HEAD, DELETE, PATCH and OPTIONS[44]. However, for the purpose of this work, the two main methods to take intoconsideration are the GET and POST methods. The GET method is used by theclient to request data or web pages from the server. In order words, it is used toretrieve information from the server. To do this, the client will just be required toenter the Universal Resource Locator (URL) of the web page because the URLpoints to the data that is being requested. On the other hand, the POST methodis used to send data or a piece of information to the server for processing. ThePOST method include some parameters like names, numbers, etc. that are gottenfrom text boxes or input fields on a web page. Therefore, the POST method is used


3. Security in SDN

mainly when a form on a web page is filled by a client and sent to the server forstorage or further processing of the input details. These two methods are usuallyexploited by attackers in such a way that the attacker sends large HTTP GETor POST requests to the server so as to deplete its resources which in turn willlead to the crashing of the server. This form of attack is more effective whenthe attacker forces the application at the client side to make requests for largeresources required for just little or a single request. In this way, the server willbe forced to use its maximum resources to serve the single request which willeventually lead to its collapse. The attack is easy to implement because if does notneed IP spoofing. A single IP address can thus perform the attack and it is alsodifficult to detect and counter because these multiple requests or traffic patterngenerated by the attacker looks like the normal traffic pattern which is generatedby legitimate users. For the GET method, an attacker can send multiple requestsfor images or files present on a server or with the use of botnets, the attacker candownload large files at a time which will consume the entire bandwidth and preventthe server from processing normal requests. The POST method is more complexthan the GET method because the former has to do with filling, submitting andprocessing of forms which further involves the querying of databases. The processof executing database commands and also handling data from forms is usuallyrigorous therefore, multiple POSTs especially from botnets can easily bring downthe server within a very short time.

• DNS Flood Attack: Before looking into how the DNS flood attack works, it isimportant to take a brief look at how the DNS operates. DNS is the backboneof the internet technology because it is responsible for translating the names ofdevices to numbers which can be easily understood online [45]. Computer andmobile devices used for communicating online are able to interact with each otherover the network only through the use of IP addresses which is given to themby the DNS. Similarly, there are millions of web pages that are running todayand each of these pages are associated with an IP address. Memorizing all thesenumbers (IP addresses) is impossible but with the aid of DNS, these numbers canbe represented with names (web addresses) which can easily be remembered byeveryone. Therefore, URLs that are entered by clients willing to access a certainweb page are also translated to IP addresses. Thus, DNS also performs the functionof resolving domain names to IP addresses which can be understood easily bycomputers and electronic devices. Most times, DNS is referred to as the phonebook of the internet [45] because it has a database that contains all web pages andIP addresses that are associated to each web page. For DNS to perform perfectly,


3. Security in SDN

there are basically four servers that are involved in the name to number translation.These servers are; Resolver Server, Root Server, Top Level Domain (TLD) Serverand Authoritative Name Server (ANS) [45]. When a client inputs a web page atthe URL bar on a web browser and sends it to the server, the web page is firstchecked at the cache memory of the browser. If the browser cannot find it, itsends a query to the first server which is the resolver server. The resolver server isalso known to be the Internet Service Provider (ISP) of the client. The resolverfurther sends another query to the root server in situations where the URL isnot found in its cache. The TLD is the next in hierarchy and it stores addressesof web pages for top level domains like .COM, .NET, .ORG, etc. Thus, the rootserver queries the TLD for the URL resolution if the IP address associated withthe URL is not also found in the cache memory of the root server. If it is notalso found in the TLD, the final server to contact is the ANS. The ANS knowseverything about any domain name. It has the IP addresses for all registereddomain names, thus, it gives a reply to the resolver server which then presents itto the client that requested for it. The IP address is further stored in the cachememory of the resolver server in case of next time. Some web pages like Google,Amazon, Facebook, YouTube, etc. are very large, highly secured and can dealwith very high load of traffic, giving them the ability to withstand any form ofDDoS attack, therefore, instead of attacking such web pages, attackers will focuson attacking the DNS server that works with the web page with the aim of bringit down so that users will find difficulty in accessing the web page. DNS serversare made solely for name to number translations and cannot handle huge trafficloads therefore, attackers can decide to flood a particular domain’s DNS serverwith multiple number of DNS request in such a way that the DNS server will beunable to handle or respond to all the requests at a time which will eventuallylead to breakdown and inability to serve legitimate users. As expected also, withthe use of botnets, the attack will be more pronounced and the DNS server willbe brought down quickly.

• DNS Reflection Attack: Another form of attack on DNS server is the DNS reflectionattack. This form of attack is not directed to the DNS server but to a host or atarget network with the aim of congesting the bandwidth of the victim therebypreventing normal flow of legitimate traffic. To perform this attack, the attackerneeds to know the IP address of the victim. This victim’s IP address is stored inthe packet header of the attacker at the field designated for the source IP address.When this is done, the attacker then sends forged DNS request in a spoofed wayto the DNS server and this will make the server to think that all requests are


3. Security in SDN

from the victim. All request are therefore directed to the target which will end upconsuming the victim’s bandwidth.

• Slowloris Attack: Other forms of attack that has been previously discussed requirethe use of one tool or the other for execution but slowloris is more deadly becauseit does not need such tools, it just uses normal authentic connection. This formof attack involves the sending of multiple half requests to a server to open halfconnections which will eventually lead to the exhaustion of the resources of theserver. Slowloris attack works hand in hand with the HTTP GET method thathas been discussed earlier. Normally, HTTP operation requires the sending of aGET request at one instance from client to server but while executing slowloris,these GET requests are sent at a very slow rate so as to keep connections openwith the server. This makes the attack more difficult to detect because the GETrequests from the attacker are valid requests and look like the normal HTTPrequests but the only difference is that they are sent very slowly. Although everyrequest has a time out, it is still difficult to fight against because the attackerperforms the attack in such a way that just when the server thinks that the requesthas been timed out, a little chuck of another request is sent again so as to keepthe connection open. In that way, the server will just think that the user hasbad network connection not knowing that is actually an attack on the system. InSDN, compromised application layer can send slow HTTP GET request to thecontrol layer for the transfer of data, making the controller saturated with multiplehalf-opened connections. This will make the connection limit of the controller to bereached and further connections especially from legitimate users will not be takenagain by the controller. Imagine using botnets of about 500 devices to performthis attack. When these 500 half-opened connections are done, the controller willthink it is serving 500 people whereas it is just one person with 500 half-openconnections. Therefore, when a normal user tries to connect to the controller byrequesting for a web page from the application layer, it will keep seeing a ”waiting”message. The connection will never occur unless maybe one half-open connectionis dropped. However, if the half connection is not dropped, then the user willfinally get a “no response” from the controller because there are no resources leftso serve the user. The mitigation of all these network abnormalities discussed inthis chapter will done in chapter4 using a well-known IDS called SNORT.


Chapter 4

Simulation Environmental Setup

For the design and simulation of the project, some prerequisites were needed to beinstalled on the local machine and they include; mininet, Ryu controller, and snort. Adetailed installation process and environmental setup is explained in the sections below.

4.1 Mininet

Mininet [46] is an emulator used in a networking environment for the creation of virtualhosts, switches, controllers and links for simulation purposes. The emulator is capableof running directly on both Windows and Linux operating systems and there is also thepossibility of installing it on a virtual machine. Basically, there are three ways by whichmininet can be installed and they are [47];

• Installation of the mininet virtual machine

• Installation from the native source

• Installation from packages.

The first option is the easiest option and usually recommended because the virtualmachine has mininet pre-installed in it. For this process, the following steps are required;

1. Firstly, download and install a virtual machine (virtual box) which can been foundat [48]

2. Download the virtual machine image for mininet (mininet VM image) which canalso be located at [49].

3. Load the mininet VM image into the virtual box via the settings section.


4. Simulation Environmental Setup

The second option which involves the installation from the native source can be doneusing the command;

• git clone git://github.com/mininet/mininet

This method is used when a virtual machine is not needed. For this project, theinstallation was done using the third option (installation from packages). The processinvolves some steps;

1. A virtual machine was first downloaded from [48].

2. On the virtual box, a Linux OS was also created as shown in the screenshot below.

Figure 4.1. – Virtual box used for simulation

The Linux OS (Ubuntu) that was created is a 64 bit Ubuntu 16.04 with a memorysize of 1024MB.

3. Once the Ubuntu setup is complete, the final step involved the installation ofmininet package using the command;

• sudo apt-get install mininet

4.2 Ryu Framework

The Ryu controller is very essential for the execution of the project because it is thecentral intelligence of the system and it also contains snort which is the IDS used in thedetection and mitigation of the DDoS attacks discussed in chapter 3. Installing Ryu canbe done on the Ubuntu machine either by obtaining it directly from github using thefollowing command;



• sudo pip install ryu

Once this is done, all ryu dependencies, components and libraries will be installed onthe local machine. Figure 4.2 shows all the components and libraries that comes withthe installation of Ryu.

Figure 4.2. – Ryu’s framework [50]

The most important library needed for this project is the OF-Config library. This libraryhelps in the functioning of the OpenFlow protocol which was discussed in chapter 2.Another important feature in the Ryu’s framework is the snort component. The snortcomponent was used in providing protection to the SDN environment from DDoS attack.A brief look into snort and some configuration requirements is shown in section 4.3below.

4.3 Snort IDS

Snort is a software based network IDS that is capable of performing real-time trafficanalysis on packets that are flowing in a network [50]. It also has the ability of detectingand resolving different forms of abnormalities that occur in a network and this is verybeneficial because in a business or a global network environment for instance, thereis high probability that there will be different types of traffic that will flow throughthe network which in turn will eventually lead to different forms of attacks like thosedescribed in chapter 3. Snort is therefore important to use in identifying and checkmatingdifferent forms of attack that can occur in a network based on the following reasons;

1. It has simple rules for detection that can easily be written.



2. It does not also require using up any memory space at the data or control planeas it is a stand-alone entity.

3. It is easy to deploy.

4. It can be used to monitor and report other irregular network activities asidesDDoS.

4.3.1 Snort Components

The components of snort that enhance the effective functionality as described by [51]are; Packet Decoder, Pre-processors and Detection Engine.

• Packet Decoder: Packets can be received from different interfaces like point-to-point or Ethernet interfaces, thus, it is the function of the packet decoder to receivethe packets from any of the interfaces and prepare them for pre-processing whichwill further be transferred to the detection engine.

• Pre-processors: There is the possibility that an intruder can modify a packet sothat it will be able to bypass abnormality detection at the detection engine butwith the presence of the pre-processor, any modified packet will be brought backto its normal form before it is further processed at the detection engine. Thepre-processor is therefore a very critical component of snort because it is capableof performing deep packet inspection on packet headers and possibly generatingalerts or re-modifying the packets and preparing them for security check at thedetection engine.

• Detection Engine: The detection engine is the most important snort componentbecause it is at the engine that the different rules and policies which will be usedto match against attacks is located. As discussed in the previous chapter, differentattacks relating to volumetric, protocol and application layer can occur anytimeduring network function and in accordance, rules and policies can be written bynetwork administrators to combat the attacks and this is made possible by thepresence of the detection engine.

4.3.2 Snort Configuration and Setup

There are basically three modes by which snort can be configured [50] and they are; asa packet sniffer, packet logger and as an IDS. As a packet sniffer, snort will performthe function of just looking up the header details of the packet and displaying it ona console. As a packet logger, snort will keep the packet for future use. Thus in this



mode, a directory is created where the required files to be logged are kept. This modeof configuration is used where a network admin intends to store / log packets for futureuse in applications. When configured as an IDS, snort checks packets against differentrules and policies. Therefore, it monitors, analyzes and take actions on packets based onthe rules that are predefined in the network. Configuring snort as an IDS can also bedone in two ways; either using the network based approach or the host based approach.For the network based approach, snort will be placed on the network or at the ingressswitch so that it will be able to capture virtually all packets or traffic that flows throughthe network. The host based approach is used in situations where an admin wishes tomonitor the activities on a certain host or all hosts in the network. Take for instance, anetwork admin installs some permanent security features on a host like passwords orcertain confidential or configuration files and he wishes to know when there is an attemptof modification on the files. With the host based approach running, snort will send analert immediately to the admin once the security features on the host is tampered with.Thus, for the host based approach, snort will be needed to be placed on every host inthe network and not just at a single point like in the network based approach. Thisapproach is highly effective because it will be able to capture all traffic flow on the hostand in the network as well but it is disadvantageous because it is more labor intensiveand complex to deploy. The network based approach was used for this project and toensure proper functioning, some important configurations were done as shown below;

Firstly, snort was installed using the command;

• sudo apt-get install snort

With snort installed, it was required that the configuration file be accessed for validitypurposes. To do this, the command below was used

• sudo vi /etc/snort/snort.conf

The main configuration file of snort is located at the snort.conf file and as shown in thefigure below. This configuration file contains 9 specific requirements which should befollowed to create a custom configuration.



Figure 4.3. – Snort configuration setup procedure

Most importantly, there is the possibility of not using the default rules that are presentin the configuration file but writing your own rules (number 7 in the figure above) andto do this, it was required that the local rules option located in the snort.conf file isenabled. Enabling the local rules enhances flexibility such that an admin can then writewhatever rules needed to be checked against in the network. Since we are writing ourown rules, enabling only the local rules file was done by commenting other rules andleaving just the setup relating to the local rules as shown in Figure 4.4 below.

Figure 4.4. – Enabling snort local rules

It is important to note that enabling other snort default rules will not have any effecton the functioning of your personal rules but it will have a negative effect on the generalperformance of snort. It will basically slow down the functionality of snort because if allrules are enabled, snort will continuously check for network activities relating to them



whereas they are not needed. Therefore, it is important to enable only the rules requiredfor the specific security check you want and disable others and in our situation, only thelocal rules file is needed. Once the entire process was done, the configuration validitywas checked and confirmed using the command below;

• sudo snort –T –c /etc/snort/snort.conf –i

If snort was configured properly, once the above validation command is executed, anotification will show with the information “snort successfully validated. As mininet,Ryu and snort has been installed and properly configured, the environment setup wascomplete and the detection and mitigation of the different abnormalities discussedin chapter 3 was ready to be done. The system design, algorithm implementation,simulation and results will be discussed in the next chapter.


Chapter 5

Simulation

In chapter 3, we have looked at different forms of DDoS attacks that can occur in SDN.However, the main point of interest is how to provide a defense mechanism to protect theSDN environment against all these forms of attacks. This chapter provides the meansby which the network Intrusion Detection System (IDS) snort discussed in chapter 4was used for the attack detection and mitigation.

5.1 Problem Description

Although DDoS attack can be easily checked against in SDN due to the centralized place-ment of the controller, it is also very easy to execute because of the way it is implemented.Various forms of attacks in SDN require the compromising of the central intelligence (thecontroller) but for DDoS attack, compromising the controller is not necessarily needed.All that is required from the attacker is to constantly inject packets from any origin intothe network until all resources of the network is exhausted which will further lead to itsbreakdown. Due to the way the OpenFlow protocol operates, some important messagesbetween the switch and controller are needed to ensure perfect synchronization or flow ofpackets from source to destination once the network is set up. These messages are; OFPT_-

Status_Request /Reply, OFPT_Features_Request /Reply and the PacketIn/PacketOutmessage. The OFPT_Features_Request and OFPT_Status_Request are mainly usedfor configuration purposes and they originate from the controller when the controllerwants to obtain switch information like flow statistics, datapath ID, attached hosts in thenetwork, port statistics etc. while the OFPT_Features_Reply and OFPT_Status_Reply

originate from the switch to the controller in response to the OFPT_Features_Request

and OFPT_Status_REquest. The PacketOut message also originates from the controller


5. Simulation

to the switch in response to the PacketIn message which comes from the switch tothe controller when a switch needs instructions on how to handle a packet for the firsttime when it enters the network. The DDoS problem lies mainly with this PacketInmessage. Due to the separation of both planes (control and data plane), every newpacket that gets into the switch will be directed to the controller for instruction decisionand there is no means or mechanism installed in the controller to limit the amount ofPacketIn messages it receives. Therefore, every new packet in the network produces atable miss entry in the switch which will always lead to triggering the PacketIn event tothe controller and in the situation of an attack like DDoS flooding, all packets will beredirected to the controller at a very high speed which will lead to resource exhaustionand breakdown eventually because the controller will try to serve all packets which willbe impossible because of its limited capacity. Thus, it is very necessary to ensure thatthe number of incoming packets to the controller is limited so that the network will bekept alive to serve its purpose.

5.2 System Design and Implementation

The design of the system for the attack mitigation basically involves two main entitiesthat are embedded within the SDN architecture and they are; the IDS and Ryu controller.The IDS is used for monitoring all the traffic that flows in the network and it sends analert to the controller once any network abnormality is found. The controller which isthe central intelligence of the entire system is used to insert forwarding rules to theswitches in the network and it also reacts and sends blocking rules to the switches onceit receives a threat alert from the IDS. The design of the network consist of 1 remotecontroller, 3 switches and 8 hosts as shown in Figure 5.1 below

Figure 5.1. – Topology design


5. Simulation

Generally, snort detection and traffic monitoring is done in such a way that packets thatflow in the network are mirrored to the port of the switch the snort is placed for furtherprocessing and check against network abnormalities and it is effective if it is placed atthe port where it can capture all the packets that flows in the network, so in all cases,it is the job of the network administrator to decide the best port to place the snort formonitoring. The same idea was used in the design of the topology and as shown fromFigure 5.1. Hosts 1 to 6 are connected to switch 3 and they represent the client sidewhere a potential DDoS attack can originate from while hosts 7and 8 represents theserver side that can be a victim to the attack. The link capacity for communicationbetween S1 and S2 as well as switches S1 and S3 was kept at 10Mbps. Similarly, allthe communication paths between the hosts and switches in the network had a linkcapacity of 10Mbps but at port 3 of switch 1 where snort was connected, there wasan allowable bandwidth of 100Mbps. The reason for having this large capacity was sothat snort will be able to accommodate as much traffic as possible which can originatesimultaneously from different hosts at the client side. In real world deployment, snortcan be best placed at the ingress port of the switch where all packets from externalsources enters the network. Placing snort just as seen from the network topology or atthe ingress switch serves two purposes;

1. It ensures that all traffic in the network is captured.

2. It ensures that DDoS attack is brought closer to the point of origin so that it willbe quickly prevented from crashing the network.

The design of the system had the following goals in mind;

1. All packets entering the network is always mirrored to snort.

2. Snort constantly monitors these packets, checks against abnormalities and thensends alert to the controller in situations where an attack is detected.

3. The controller periodically updates rules and blocking instructions to switches toprevent packet flow and network activities from hosts that initiate attack.

5.3 Algorithm Design

The detection and mitigation of DDoS attack was done in such a way that at constantinterval (every 10 seconds), the controller requests the port statistics of the switchin the network where the snort is installed. These statistics is used to calculate thetotal bandwidth that has been consumed and when the consumed bandwidth exceeds


5. Simulation

certain values, different actions are being carried out. Firstly, upon the start of thenetwork, all hosts and switches are logically connected to the controller and for completeconfiguration, the controller triggers the Switch_Features_Handler_Event to requestfor the states of the switches. Once the initial configuration setup is done, the controllerbegins to listen for PacketIn message from the switch because a table miss entry willdefinitely occur for the first packet that enters the network. Similarly, snort also beginsto monitor the flow of packets in the network to be able to report to the controller inextreme cases of bandwidth overuse. The entire network operation and DDoS detectionand mitigation is shown in the flow chart.

Figure 5.2. – Flow chart showing network operation

The essential parts of the flow chart are the start process, the point of decision boundariesand when Ryu is alerted of an attack by snort which also triggers a reload of snort.These most important sections are discussed extensively in the sub sections below.


5. Simulation

5.3.1 Start Process

1. There is a possibility that snort could be running already on a different port of thelocal machine and if two snorts are running, there will be conflict in processingboth snort IDs. Therefore, it was necessary to first kill all existing snorts thatcould be running using the command;

• sudo service snort stop

2. Start the network topology

• sudo python topology.py

3. Start snort

• sudo snort -i s1-eth3 -A unsock -l /tmp -c /etc/snort/snort.conf

The above command for starting snort shows that snort is running on Ethernet 3of switch 1 (S1). It was hard-coded and it can be changed depending on whereyou want snort to be installed.

4. The Ryu application was then started using the command;

• sudo ryu-manager –config-file params.conf snortddos.py

The params.conf file in the application startup line above contains the tolerable linkbandwidth in the network (which was set at 10Mbps). The project was designed to suitany network scenario, therefore, if deployed to any network, all that is required is for thetolerable bandwidth to be changed in the params.conf file and the threshold detectionwhich will be discussed subsequently will be calculated based on the link bandwidththat was defined. Each command was also proceeded with the word “sudo” becauserunning and reloading snort in real-time always requires root access. With these processrunning, the network was then able to check against possible DDoS attacks.

5.3.2 Decision Boundaries

This section of the network operation is responsible for ensuring that the resources ofthe network is not exhausted due to bandwidth consumption. Firstly, before the decisionboundary is executed, the port statistics is calculated in order to know the total amountof bandwidth that has been consumed. To do this, a dictionary called PORT_STATS_DB

was first created. This dictionary was used to store all the details about the statistics ofthe switch which was obtained from the reply given by the switch in response to theport statistics that was requested for. At every 10 seconds interval, the port statistic is


5. Simulation

collected and the bandwidth consumed is calculated which will be used to decide if anupdate on the snort rules will be done or not. As seen from the code below, the functionconstantly checks for the percentage of bandwidth that has been consumed and forscenarios where 25% , 50% and 75% of the bandwidth has been consumed, the thresh-old in the snort rules will dynamically change which will also trigger the reloading of snort.

1 def get_new_threshold (self):2 current_bw_used = PORT_STATS_DB [1][1] + PORT_STATS_DB [1][2]3

4 # calculate link utilizattion as percentage5

6 bw_util_percent = ( current_bw_used * 100) / ↘self. LINK_BANDWIDTH

7 self. logger .info(" current bw %d in percentage %d", ↘current_bw_used , bw_util_percent )

8 if bw_util_percent <= 25 :9 threshold = 100

10 elif bw_util_percent <=50 and bw_util_percent >25:11 threshold = 7512 elif bw_util_percent <=75 and bw_util_percent >50:13 threshold = 5014 else:15 threshold = 116 if threshold != self. CURRENT_THRESHOLD :17 self. NEW_THRESHOLD = threshold18 print(’threshold ’, threshold , ’current threshold ’, ↘

self. CURRENT_THRESHOLD , ’new threshold ’, ↘self. NEW_THRESHOLD )

The reloading of snort is initiated by the SIGHUP signal. Once this signal is passed,snort will reload the configuration from the configuration file to finalize the process.This is also made possible by first obtaining the snort process ID and as explainedpreviously, it is important to ensure that only one snort is running at a time during thenetwork operation because if more than one snort is running, at this point of reload,there will be a conflict of process as it will be impossible to reload both process IDs atthe same time. The code below also shows the function that deals with the reload of snort.

1 def reload_snort ():


5. Simulation

2

3 # reload snort process4

5 snort_pid = int( check_output (["pidof", "snort"]))6 print("snort process id", snort_pid )7 if snort_pid :8 os.kill(snort_pid , signal . SIGHUP )9 else:

10 print("snort not running ")11

12 if __name__ == ’__main__ ’:13 modify_rule (3, 120, 220)14 reload_snort ()

5.3.3 Ryu Alert

This process is initiated only in situations of DDoS attack i.e. when the threshold ofpacket flow is exceeded or when there is flooding of packets in the network. The codebelow shows the function that executes this operation.

1 @set_ev_cls ( snortlib .EventAlert , MAIN_DISPATCHER )2 def _dump_alert (self , ev):3 msg = ev.msg4

5 #print(’alertmsg : %s’ % ’’.join(msg. alertmsg ))6 self. logger .info(msg. alertmsg )7 #self. packet_print (msg.pkt)8

9 pkt = packet . Packet (array.array(’B’, msg.pkt))10 eth = pkt. get_protocol ( ethernet . ethernet )11 dst = eth.dst12 src = eth.src13 self. logger .info("src %s dst %s", src , dst)14 if eth. ethertype == ether_types . ETH_TYPE_IP :15 ip = pkt. get_protocol (ipv4.ipv4)16 srcip = ip.src17 dstip = ip.dst18 self. logger .info("src %s dst %s", srcip , dstip)19

20 for datapath in self. datapaths . values ():21 match = ↘

datapath . ofproto_parser . OFPMatch ( eth_type = ether_types . ETH_TYPE_IP ,


5. Simulation

22 ipv4_src =srcip ,)23 self. add_flow (datapath , 100, match , actions =[], ↘

idle_t =0, hard_t =0)

This process is a report from snort to the controller once an attack is initiated in thenetwork and as seen from the code, due to the fact that we need to ensure detectionfrom the point where the attack originated the match field is the source IP and the flowhas a high priority of 100 (which is higher than other flow priorities in the network),therefore, once the attack is detected and an alert is received by Ryu, the drop flowis immediately inserted in the flow table of the switch. By default, an empty action(action = [ ]) means drop. Also, an idle and hard timeout was set to 0 to ensure that theattacker will not be allowed again to gain access to the network once blocked. However,there could be instances where an attack can be mistakenly originated by a legitimatehost in the network, therefore, these timeouts can be adjusted to a certain value sothat after the specified time, the host can access the network again, thereby ensuring aself-healing process. It all depends on the decision of the network administrator.

5.4 Results

The scope of the project covered the prevention of bandwidth exhaustion using snortas well as the detection and mitigation of abnormalities that occur in the network.The tests and simulation results for this process which corresponds to the flow chartoperation in Figure 5.2 is also explained in detail below.

Once the start process as explained in section 5.3.1 is initiated and the topology isrunning, we first test connectivity between the client side and the server side using aping. For this test, the ping was done between h1 (client) and h8 (server) and as seenfrom Figure 5.3, the action required was to send the packet through two ports (ports 2and port 3). The first output which is port 2 is the main path through which host 1 cancommunicate to host 8 while the output through port 3 is due to the presence of snort.Thus, a copy of the packet is mirrored to snort via port 3 for the purpose of evaluationand DDoS detection as seen in the flow chart.


5. Simulation

Figure 5.3. – Packet flow between the host and the server in the network

To then test for different forms of attack, after executing the start process in section5.3.1 up to step 4, we then start up an iperf server on any of the hosts located at theserver side (host 7 or host 8). The server was started up using the command;

• h8 iperf –u –s &

With the server up and running, the attack was then detected and mitigated for all thenetwork abnormalities discussed in chapter 3.

1. ICMP Flood: The snort rules for ICMP flood attack detection is given by;

1 alert icmp any any <> any any (itype :8; msg:" Volume Attack - ↘ICMP Flood ..";dsize: >100; detection_filter :track ↘by_src ,count 100, seconds 1; sid :1000004;)

The rule states that if an ICMP attack originates from “any” source to “any”destination, an alert should be sent to the controller. Generally, ICMP has differentcodes for various request types like code 0 for Echo reply or 3 for destinationunreachable. Therefore, the type 8 in the rule (itype 8) indicates a rule for ICMPEcho request. The rule also shows a check on the size of packets that flows in thenetwork as well as the number of packets received per second. Thus, “>100; count100, seconds 1” simply means an attack alert is sent to Ryu controller when thenetwork receives more than 100 packets in one second and with a size also greaterthan 100 bytes. These rules can be adjusted to any value wanted, depending onwhat suits the network. Also, because we intend to block the source from which


5. Simulation

the packet originated, the rule stated that we track the attack from the source(i.e. track by_src). The test on the functionality of the rule was done using thefollowing command;

• h1 ping –s 1400 –f h8

• h1 hping3 –flood –icmp –d 1400 h8

The number 1400 represents a packet size of 1400 bytes which is against whatwas defined in the rules. Hping3 is a tool that is capable of generating multiplepackets at a time and at a very fast rate. This was used to test the response of thenetwork to detecting the attack when the number of packets received per secondis greater than 100 as defined in the rules. Other arguments and their descriptionsis shown in Table 5.1

Hping3 Arguments Meaning-s It is used to set the packet size to a certain value

-f (–flood) Sends packets to victim at a very fast rate within a very short time-d Defines the packet size

Table 5.1. – Hping3 arguments for ICMP attack

The snort rules for all other attacks is shown in Appendix A

As seen from Figure 5.4, once the flood attack is executed, an alert is sent to Ryuand the host involved in the attack is blocked.

Figure 5.4. – ICMP flood attack detection


5. Simulation

Similarly, the flow rule that was initially inserted in the flow table of S1 will beerased. Figure 5.4 also shows the flow table once the attack is detected and asseen from the figure, the action has been set to “drop”. Meaning that all packetsoriginating from h1 will further be blocked. To view the flow table, the commandbelow was used;

• ovs-ofctl dump-flows s1

To further test for the dynamic update of the snort rules, we originated multiplepackets from all hosts at the client side such that the consumed bandwidth willincrease gradually up to the different points of check (25%, 50% and 75%). To dothis, the command below was used;

• h1 iperft –u –c 10.0.0.8 –b 1M –t 300 &

The command generates 1Mbps of traffic from h1 at the client side to h8 at theserver side. The same command was used for both h2, h3, h4, h5 and h6. Thepurpose of doing this was to ensure that the bandwidth increased gradually sothat we can test for the effectiveness in detecting the points where the snort reloadand rules update were needed. At points where the consumed bandwidth increasedup to 25%, 50% and 75%, the threshold was changed dynamically and snort wasreloaded. The figure below shows the output of the process

Figure 5.5. – Snort dynamic threshold update

2. UDP Flood Attack: The same process was tested for UDP attack detection.However, the hping3 command used for the UDP test was different from that ofICMP. Basically, UDP has different port numbers and an attack can happen atany port, at any time and for any application, therefore, it was required that we


5. Simulation

simulate the scenario where the port number stays constant and when it also vary.The command for the attack used for the different scenarios are;

a) For changing destination port while keeping the source port fixed;

• h3 hping3 –flood –udp -d 1400 -k -s 53 h7

b) For changing source port while keeping destination port fixed;

• h3 hping3 –flood –udp -d 1400 -p 80 -s 53 h7

c) For changing source port and changing destination port;

• h3 hping3 –flood –udp -d 1400 -p ++80 -s 53 h7

The snort rules to detect the attack is shown in Appendix A For all three instances,snort was able to detect the UDP attack and an alert was sent to Ryu for furthersecurity implementation.

Figure 5.6. – UDP flood attack

Host 3 that originated the attack will be blocked from further access to the network,therefore, the flow table with an empty action will be the same as in Figure 5.4

The arguments for hping3 command is given in Table 5.2 below


5. Simulation

Hping3 Arguments Meaning-k Keeps source port as the same number during attack-d Defines the packet size-s Source port number-p Defines destination port

Table 5.2. – Hping3 arguments for UDP attack

3. TCP SYN Attack: Similarly, the test for TCP SYN attack under different andsame source port and destination port was done.

a) Different source port and same destination port

• h4 hping3 –flood -S -p 80 h8

b) Different source port and different destination port

• h4 hping3 –flood -S -p ++80 h8

The attacked was launched between host 4 at the client side and host 8 at theserver side. The figure below also shows the detection and mitigation of the attackby snort and Ryu controller.

Figure 5.7. – TCP SYN Protocol attack

4. IP Null Attack: Usually, protocols have specific valid numbers e.g. the protocolnumber for TCP is 6, ICMP is 1, UDP is 17, etc. which can be identified frompacket headers during deep packet inspection. The purpose of the IP Null attackis to make this protocol number void so that the packet will be able to bypass


5. Simulation

security checks. Therefore, to test for this attack detection, we used a randomprotocol number which does not exist. Any of the two commands below can beused to execute the IP Null attack;

• h1 hping3 –flood –rawip –ipproto 65000 h8

• h1 hping3 –flood –rawip –ipproto 65000 -d 1400 h8

The ipproto 65000 means a protocol number of 65000 which does not exist inreality. Once the command is executed, snort will detect the value as null andsend an alert to the controller. The response will be the same just like for theprevious attacks simulated but the description will be “IP Null Attack”.

5. HTTP Flood: To execute the HTTP flood attack, we first needed a file that cangenerate multiple HTTP request. The file used can be located at;

• https://github.com/D4Vinci/PyFlooder/blob/master/pyflooder.py

The pyflooder is the python file that was used to generate the multiple HTTPrequest. Firstly, the sleep time in the file was adjusted to a very short time (0.1milliseconds) so that it will generate lots of packets quickly. The steps in testingthe detection of the attack are;

a) A web server was first started at the victim (the server) using the command;

• xterm h8

• Python –m SimpleHTTPServer 80

b) The pyflooder was then loaded from the attack origin (client side)

• h1 python /home/paschal/pyflood.py h8 80 1000000

The number 80 represents the port number (HTTP) while 100000 represents thenumber of HTTP requests that will be generated.

6. Slowloris Attack: As discussed in chapter 3, the aim of slowloris attack is to exhaustthe connection possibilities of the server. To execute the attack, slowloris wasneeded to be installed at the attack origin. A web server was first started usingthe command;

• xterm h7

• python -m SimpleHTTPServer 80


5. Simulation

The slowloris was installed at the attacker host and then ran using the command;

• pip install slowloris

• slowloris -p 80 10.0.0.7

The snort rules for the slowloris detection is also included at Appendix A. TheRyu console display as well as the flow table rules after attack detection will besimilar to what was obtained from previous tests.

Figure 5.8 below shows the graph of the total bandwidth consumed at different timeintervals. This graph corresponds to the threshold change with respect to the totalbandwidth consumed as displayed in Figure 5.5 and it was obtained real time.

Figure 5.8. – Graph showing bandwidth utilization

Initially at the start of the network, the bandwidth consumed stayed at zero but whentraffic flow was initiated from the client side to the server side, the total consumedbandwidth increased gradually up to the different points that triggered the snort rulesupdate and reload (i.e. 25%, 50% and 75% respectively). The sharp peak on the graphindicates the point where the threshold which was set by snort was violated and thisimplies that an attack was attempted in the network. When this happened, an alert wassent from snort to Ryu, the host involved in the attack was blocked and the bandwidthlevel was restored back to normal. When the network activity reduced, the total consumedbandwidth also reduced gradually until it returned back to zero level just like whenthe network started. At this point also, the tolerable packet flow also went back to thedefault value set by snort at the start of the network.


5. Simulation

5.5 Comparison and Improvements from previous works

The use of snort in the detection and mitigation of DDoS attack was also used by theauthors in [52]. However, the approach used in this project was flexible and it provideda better result as compared to what the previous authors used. The improvement fromthe previous work can be noticed specifically in two areas which are;

• The dynamic update of the snort rules for attack detection in order to suit allnetwork conditions

• The speed of DDoS attack detection and mitigation

As discussed in section 5.3.2, there are different boundaries that are checked during thenetwork operation to decide when the snort rules for the attack detection will be updatedand this decision is done based on the percentage of bandwidth that has been consumedat any given time. This decision also go hand in hand with the tolerable bandwidth thatwas provided in the configuration file (params.config) that was mentioned in section 5.3.1.This approach shows scalability because the scheme can be deployed in any networkenvironment, all that is required is for the tolerable bandwidth to be provided by thenetwork administrator then the threshold, decision boundaries and dynamic rules updatewill be carried out based on what was provided. This is in contrast to what was done bythe authors in [52] because they used a static threshold in the snort rules, therefore, forsmaller networks having a small bandwidth for operation, the entire network resourcescan easily be exhausted before the attack will be detected or for larger networks havinga larger bandwidth, the packet flow rate set in the rules might be insignificant to causean attack on the network but an alert will still be sent to the controller indicating anattack on the system which is a false positive result.

The speed of attack detection and mitigation is also very important because the fasterthe detection, the more protective the network will be from resource exhaustion. Theauthors in [53] proposed the use of a flow analyzer to detect the attack and with theirmethod, the attack was detected and mitigated approximately after 10 seconds. Similarly,the authors in [52] that previously used snort performed tests under different scenariosand averagely, their detection and mitigation time was at 3.07 seconds. Figure 5.9 belowshows the result that was extracted from [52] to show the mitigation time when theirsystem was under attack.


5. Simulation

Figure 5.9. – Detection and mitigation time of attack [52]

To retrieve the DDoS attack detection and mitigation time of our system, wiresharkwas used to capture the traffic flow in the network and the wireshark I/O graph wasused to plot the result. Figure 5.10 shows the output of the graph

Figure 5.10. – Detection and mitigation time of our proposed system

From the graph, it can be seen that the network operation was normal from the start ofthe network at time 0 up to at about 64 secs when the attack was launched and it tookapproximately 2 secs for the attack to be mitigated and for the system to be restoredback to normal condition. This was due to the dynamic approach used in the attackdetection because our proposed system was able to adjust to the present situation of thenetwork, thereby making it quick to respond to a change in the network behavior. Oursystem thus provided a faster response time as compared to what was obtained fromprevious authors. Generally, our deployed system is very efficient in detecting various


5. Simulation

DDoS abnormalities that can occur in a network, it is scalable and it is highly responsiveto attack detection as compared to previous works.


Chapter 6

Conclusion and Future Work

Software Defined Networking (SDN) has a very flexible 3-way architecture that makes iteasy for network administrators to configure and maintain the network in a programmableway. This is advantageous because it provides network efficiency and operability especiallyin this era where technology usage is on the rise. However, the architecture is alsodisadvantageous because it makes it prone and vulnerable to different forms of attack,particularly Distributed Denial of Service (DDoS) attack which was the subject ofdiscussion in this work. Although SDN is susceptible to DDoS attack, its architecturealso makes it easy to detect and mitigate the attack because the centralized controllercan view the entire network, thus, it can easily spot where the attack originates from.Nevertheless, there can be situations where the controller can be overloaded or wherethe controller (particularly in networks that have just one controller) cannot withstandthe occurrence of an attack, thereby leading to its failure and possible shutdown of thenetwork. Therefore, it is important to ensure that all forms of attack to the networkis kept as far from the controller as possible or a device can be introduced to supportthe controller and improve its security abilities just as suggested by the author in [54].Thus, this study involved choosing a good means to stop different forms of attack fromoccurring in the network and snort which is an IDS was chosen for this purpose due toits flexibility and versatility.The results from the simulation carried out showed that snort was capable of detectingand mitigating different abnormal behavior in the network within a very short time.The method of snort deployment in this work also ensured scalability, therefore, it canbe extended to larger networks or it can be deployed in any form of network, all thatwill be required is for the network administrator to provide the tolerable bandwidthconsumption the network can withstand and also to decide the best place to install the


6. Conclusion and Future Work

snort for monitoring which is usually best to install at the point of entry of the networkso that it will be able to capture all the traffic that enters the network.Although this work provided a solution that is highly efficient in security and highlyscalable, a more advanced means which can be deployed in future can involve theintroduction of machine learning. Using machine learning for DDoS detection will alsobe effective and efficient but there are many things to consider while using it. Firstly,machine learning consumes time and resources because a lot of time will be needed forthe algorithm to learn the network which might not be a luxury for network operators. Italso requires high computation power which a lot of machines might not possess. Thereare also different machine learning algorithms that exists so choosing the best algorithmis also very important in order to avoid getting results that have false positives andfalse negatives. Since the deployment of snort also has some negativity like the littleoverhead that occur due to packet mirroring and also choosing the best place whereit will be installed, a future work can involve the combination of snort and machinelearning so that the efficiency will be increased and overhead is reduced. Generally, itall depends on what can be compromised.


List of Acronyms

SDN Software Defined Networking

API Application Programming Interface

DDoS Distributed Denial of Service

MAC Medium Access Control

IP Internet Protocol

QoS Quality of Service

VoIP Voice over Internet Protocol

ONF Open Networking Foundation

NFV Network Function Virtualization

DNS Domain Name System

NAT Network Address Translation

ICN Information Content Networking

ToS Type of Service

TCP Transmission Control Protocol

UDP User Datagram Protocol

OXM Openflow Extensible Match

OAM Operation and Management

NOS Network Operating System

HTTP Hyper Text Transfer Protocol


6. Conclusion and Future Work

DNS Domain Name System

SMTP Simple Mail Transfer Protocol

TLS Transport Layer Security

VLAN Virtual Local Area Network

TCAM Ternary Content Addressable Memory

DPID Datapath Identifier

ICMP Internet Control Message Protocol

SYN-ACK Synchronous Acknowledgment

ACK Acknowledgment

WWW World Wide Web

URL Universal Resource Locator

TLD Top Level Domain

ANS Authoritative Name Server

ISP Internet Service Provider


Appendix A

Code Implementation

A.1 Topology used for simulation

1 from mininet .topo import Topo2 from mininet .net import Mininet , Host3 from mininet .log import setLogLevel4 from mininet .cli import CLI5 from mininet .node import OVSSwitch , Controller , RemoteController6 from mininet .link import TCLink7 from time import sleep8 from mininet .node import CPULimitedHost9

10

11 class SingleSwitchTopo (Topo):12 " Single switch connected to hosts."13 def build(self):14 s1 = self. addSwitch (’s1’)15 s2 = self. addSwitch (’s2’)16 s3 = self. addSwitch (’s3’)17 h1 = self. addHost (’h1’, mac=" 00:00:00:00:00:01 ")18 h2 = self. addHost (’h2’, mac=" 00:00:00:00:00:02 ")19 h3 = self. addHost (’h3’, mac=" 00:00:00:00:00:03 ")20 h4 = self. addHost (’h4’, mac=" 00:00:00:00:00:04 ")21 h5 = self. addHost (’h5’, mac=" 00:00:00:00:00:05 ")22 h6 = self. addHost (’h6’, mac=" 00:00:00:00:00:06 ")23 h7 = self. addHost (’h7’, mac=" 00:00:00:00:00:07 ")24 h8 = self. addHost (’h8’, mac=" 00:00:00:00:00:08 ")25

26

27 snort = self. addHost (’snort ’, mac=" 00:00:00:00:10:00 ")


A. Code Implementation

28

29 self. addLink (h1 , s2 , cls=TCLink , bw =10)30 self. addLink (h2 , s2 , cls=TCLink , bw =10)31 self. addLink (h3 , s2 , cls=TCLink , bw =10)32 self. addLink (h4 , s2 , cls=TCLink , bw =10)33 self. addLink (h5 , s2 , cls=TCLink , bw =10)34 self. addLink (h6 , s2 , cls=TCLink , bw =10)35

36 self. addLink (h7 , s3 , cls=TCLink , bw =10)37 self. addLink (h8 , s3 , cls=TCLink , bw =10)38

39

40 self. addLink (s1 , s2 , cls=TCLink , bw =10)41 self. addLink (s1 , s3 , cls=TCLink , bw =10)42 self. addLink (snort , s1 , cls=TCLink , bw =100)43

44

45 if __name__ == ’__main__ ’:46 setLogLevel (’info ’)47 topo = SingleSwitchTopo ()48 c1 = RemoteController (’c1’, ip=’127.0.0.1 ’)49 net = Mininet (topo=topo , host= CPULimitedHost , controller =c1)50 net.start ()51 #sleep (5)52 #net. pingAll ()53 h7 = net.get(’h7’)54 h7.cmd(’iperf -u -s &’)55 h8 = net.get(’h8’)56 h8.cmd(’iperf -u -s &’)57

58 CLI(net)59 net.stop ()

A.2 Snort local rules for DDoS attack detection

1 # Volume Based Attack2 # ICMP Attack3 alert icmp any any -> any any (msg:"DDos Attack - ICMP ↘

Flood .."; detection_filter :track by_src ,count 100, seconds ↘1; sid :1000003;)

4 alert icmp any any <> any any (itype :8; msg:" Volume Attack - ICMP ↘Flood ..";dsize: >100; detection_filter :track by_src ,count 100, ↘seconds 1; sid :1000004;)

5 # UDP Attack


A. Code Implementation

6 alert udp any any <> any any (msg:" Volume Attack - UDP ↘Flood ..";dsize: >100; detection_filter :track by_src ,count 100, ↘seconds 1; sid :1000005;)

7 # Protocol Based Attack (TCP SYN)8 #same src IP9 alert tcp any any <> any any (msg:"TCP SYN Protocol Attack "; ↘

flow: stateless ; flags:S ,12; detection_filter :track by_src ,count ↘100, seconds 1; sid :1000006;)

10 #same dst11 alert tcp any any <> any any (msg:"TCP SYN Protocol Attack "; ↘

flow: stateless ; flags:S ,12; detection_filter :track by_dst ,count ↘100, seconds 1; sid :1000007;)

12 # Application Based Attack13 # HTTP Attack14 alert tcp any 80 <> any 80 (msg:"Http flood Attack "; ↘

flow: stateless ; detection_filter :track by_src ,count 100, ↘seconds 1; sid :1000008;)

15 # Slowloris Attack16 alert tcp any any -> any 80 (msg:" SlowLoris .py DoS attempt "; \ ↘

flow: established ,to_server , no_stream ; content :"X-a:"; ↘dsize : <15; \ detection_filter :track by_dst , count 3, seconds ↘30; \ classtype :denial -of - service ; sid :1; rev :1;)

17 # DNS Flood18 alert udp any 53 <> any 53 (msg:"DNS Attack .";flow: stateless ; ↘

detection_filter :track by_src ,count 50, seconds 1; sid :1000009;)19 # DNS Reflection20 alert udp any 53 <> any 53 (msg:"DNS ripe.net UDP"; content :"|01 ↘

04 72 69 70 65 03 6e 65 74 ↘00|"; classtype :attempted -dos;sid :4000003;)

21 alert udp any 53 <> any 53 (msg:"DNS isc.org UDP"; content :"|01 03 ↘69 73 63 03 6f 72 67|"; classtype :attempted -dos;sid :4000004;)


List of Figures

2.1. Three layer SDN architecture . . . . . . . . . . . . . . . . . . . . . . . . 72.2. Centralized Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3. Distributed Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4. SDN architecture with all interfaces and protocols [11] . . . . . . . . . . 122.5. OpenFlow functional elements . . . . . . . . . . . . . . . . . . . . . . . . 152.6. Packet flow in an SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.7. OpenFlow 1.0 switch structure [18] . . . . . . . . . . . . . . . . . . . . . 192.8. OpenFlow 1.1 switch structure [19] . . . . . . . . . . . . . . . . . . . . . 202.9. Internal structure of an OpenFlow switch [25] . . . . . . . . . . . . . . . 262.10. TLS handshake procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 272.11. Pipeline processing [20] . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1. DDoS attack using botnets [31] . . . . . . . . . . . . . . . . . . . . . . . 323.2. UDP flood attack [42] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3. TCP 3-way handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1. Virtual box used for simulation . . . . . . . . . . . . . . . . . . . . . . . 454.2. Ryu’s framework [50] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3. Snort configuration setup procedure . . . . . . . . . . . . . . . . . . . . 494.4. Enabling snort local rules . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1. Topology design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.2. Flow chart showing network operation . . . . . . . . . . . . . . . . . . . 545.3. Packet flow between the host and the server in the network . . . . . . . 595.4. ICMP flood attack detection . . . . . . . . . . . . . . . . . . . . . . . . 605.5. Snort dynamic threshold update . . . . . . . . . . . . . . . . . . . . . . 615.6. UDP flood attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.7. TCP SYN Protocol attack . . . . . . . . . . . . . . . . . . . . . . . . . . 635.8. Graph showing bandwidth utilization . . . . . . . . . . . . . . . . . . . 65


List of Figures

5.9. Detection and mitigation time of attack [52] . . . . . . . . . . . . . . . . 675.10. Detection and mitigation time of our proposed system . . . . . . . . . . 67


List of Tables

2.1. Minimum set of entries in a flow table of an OpenFlow switch . . . . . . 152.2. Match fields for different protocol specifications [22] . . . . . . . . . . . 222.3. SDN controllers and the language they support [11] . . . . . . . . . . . . 23

5.1. Hping3 arguments for ICMP attack . . . . . . . . . . . . . . . . . . . . . 605.2. Hping3 arguments for UDP attack . . . . . . . . . . . . . . . . . . . . . 63


Bibliography

[1] B. Yaun, et a. H. Jin J. H. Jin: A Practical ByzantineBased Approach for FaultyTolerance in Software-Defined Networks. In: IEEE Transactions on Network andService Management 15 (2018), S. 825–839

[2] A. Rai, D. Prakash et a.: Distributed DoS Attack Detection and Mitigation inSoftware Defined Netwok (SDN). In: International conference on “Recent Advancesin Interdisciplinary Trends in Engineering and Applications 15 (2018), S. 825–839

[3] https://www.snort.org/

[4] N. Feamster, E. Z. J. Rexford R. J. Rexford: The road to SDN: an intellectualhistory of programmable networks. In: ACM SIGCOMM Computer CommunicationReview 44 (2014), S. 87–98

[5] S. Deng, Z. Lu et a. X. Gao G. X. Gao: Packet Injection and Its Defense inSoftware-Define Networks. In: IEEE Transactions of Information Forensics andSecurity 13 (2018), S. 695–705

[6] Braun, Wolfgang ; Menth, Michael: Software-defined networking using OpenFlow:Protocols, applications and architectural design choices. In: Future Internet 6(2014), Nr. 2, S. 302–336

[7] https://en.wikipedia.org/wiki/Software-defined_networking

[8] Brown, G: 7 Advantages of Software Defined Network-ing. http://www.ingrammicroadvisor.com/data-center/

7-advantages-of-software-defined-networkingR

[9] Yegulalp, S: Five SDN benefits enterprises should consider. In: NewtworkComputing (2013)

[10] Open Networking Foundation. https://www.opennetworking.org/


https://www.snort.org/

https://en.wikipedia.org/wiki/Software-defined_networking

http://www.ingrammicroadvisor.com/data-center/7-advantages-of-software-defined-networkingR

http://www.ingrammicroadvisor.com/data-center/7-advantages-of-software-defined-networkingR

https://www.opennetworking.org/

BIBLIOGRAPHY

[11] Jarraya, Yosr ; Madi, Taous ; Debbabi, Mourad: A survey and a layered taxonomyof software-defined networking. In: IEEE communications surveys & tutorials 16(2014), Nr. 4, S. 1955–1980

[12] Li, Li E. ; Mao, Z M. ; Rexford, Jennifer: Toward software-defined cellularnetworks. In: 2012 European Workshop on Software Defined Networking IEEE,2012, S. 7–12

[13] Veltri, Luca ; Morabito, Giacomo ; Salsano, Stefano ; Blefari-Melazzi,Nicola ; Detti, Andrea: Supporting information-centric functionality in softwaredefined networks. In: 2012 IEEE International Conference on Communications(ICC) IEEE, 2012, S. 6645–6650

[14] Nkosi, Mpho ; Lysko, Albert ; Ravhuanzwo, Lusani ; Nandeni, Thulani ;Engelberencht, Andries: Classification of SDN distributed controller approaches:a brief overview. In: 2016 International Conference on Advances in Computing andCommunication Engineering (ICACCE) IEEE, 2016, S. 342–344

[15] Yan, Qiao ; Yu, F R.: Distributed denial of service attacks in software-definednetworking with cloud computing. In: IEEE Communications Magazine 53 (2015),Nr. 4, S. 52–59

[16] ElDefrawy, Karim ; Kaczmarek, Tyler: Byzantine fault tolerant software-defined networking (SDN) controllers. In: 2016 IEEE 40th Annual ComputerSoftware and Applications Conference (COMPSAC) Bd. 2 IEEE, 2016, S. 208–213

[17] Fernandez, Carlos ; Munoz, Jose L.: Software Defined Networking (SDN) withOpenFlow 1.3 Open vSwitch and Ryu. In: UPC Telematics Department_PhDThesis (2015)

[18] OpenFlow Switch Consortium and Others. OpenFlow Switch Specification Version1.0.0. 2009. https://www.opennetworking.org/images/stories/downloads/

sdn-resources/onf-specifications/openflow/openflow-spec-v1.0.0.pdf






https://www.opennetworking.org/images/stories/downloads/sdn-resources/ onf-specifications/openflow/openflow-spec-v1.0.0.pdf






BIBLIOGRAPHY



[22] Kreutz, Diego ; Ramos, Fernando ; Verissimo, Paulo ; Rothenberg, Chris-tian E. ; Azodolmolky, Siamak ; Uhlig, Steve: Software-defined networking: Acomprehensive survey. In: arXiv preprint arXiv:1406.0440 (2014)

[23] NTT, NTT Laboratories OSRG Group. http://osrg.github.com/ryu/

[24] Ryu SDN Framework. https://osrg.github.io/ryu/

[25] Bhushan, Kriti ; Gupta, Brij B.: Distributed denial of service (DDoS) attackmitigation in software defined network (SDN)-based cloud computing environment.In: Journal of Ambient Intelligence and Humanized Computing 10 (2019), Nr. 5, S.1985–1997

[26] Samociuk, Dominik: Secure communication between OpenFlow switches andcontrollers. In: AFIN 2015 39 (2015)

[27] https://en.wikipedia.org/wiki/Transport_Layer_Security

[28] Kreutz, Diego ; Ramos, Fernando ; Verissimo, Paulo: Towards secure and de-pendable software-defined networks. In: Proceedings of the second ACM SIGCOMMworkshop on Hot topics in software defined networking ACM, 2013, S. 55–60

[29] Smith-perrone, Jeanette ; Sims, Jeremy: Securing cloud, SDN and large datanetwork environments from emerging DDoS attacks. In: 2017 7th InternationalConference on Cloud Computing, Data Science & Engineering-Confluence IEEE,2017, S. 466–469

[30] Haque, Muhammad R. ; Ali, Sameer ; Tan, Saw C. ; Yusoff, Zulfadzli ; Kwang,Lee C. ; Kaspin, Ir R. ; Ziri, Salvatore R.: Motivation of ddos attack-aware insoftware defined networking controller placement. In: 2017 International Conferenceon Computer and Applications (ICCA) IEEE, 2017, S. 36–42

[31] https://www.crackitdown.com/2017/11/what-is-ddos-attack.html

[32] Chen, Kuan-yin ; Junuthula, Anudeep R. ; Siddhrau, Ishant K. ; Xu, Yang; Chao, H J.: SDNShield: Towards more comprehensive defense against DDoSattacks on SDN control plane. In: 2016 IEEE Conference on Communications andNetwork Security (CNS) IEEE, 2016, S. 28–36




http://osrg.github.com/ryu/

https://osrg.github.io/ryu/

https://en.wikipedia.org/wiki/Transport_Layer_Security

https://www.crackitdown.com/2017/11/what-is-ddos-attack.html

BIBLIOGRAPHY

[33] Conti, Mauro ; Lal, Chhagan ; Mohammadi, Reza ; Rawat, Umashankar:Lightweight solutions to counter DDoS attacks in software defined networking. In:Wireless Networks 25 (2019), Nr. 5, S. 2751–2768

[34] Wang, Yang ; Hu, Tao ; Tang, Guangming ; Xie, Jichao ; Lu, Jie: SGS: Safe-GuardScheme for Protecting Control Plane Against DDoS Attacks in Software-DefinedNetworking. In: IEEE Access 7 (2019), S. 34699–34710

[35] Deng, Shuhua ; Gao, Xing ; Lu, Zebin ; Li, Zhengfa ; Gao, Xieping: DoSvulnerabilities and mitigation strategies in software-defined networks. In: Journalof Network and Computer Applications 125 (2019), S. 209–219

[36] Mousavi, Seyed M. ; St-Hilaire, Marc: Early detection of ddos attacks againstsoftware defined network controllers. In: Journal of Network and Systems Manage-ment 26 (2018), Nr. 3, S. 573–591

[37] Rai, Ankita ; D Vyavahare, Prakash ; Jain, Anjana: Distributed DoS Attack De-tection and Mitigation in Software Defined Network (SDN). In: Anjana, DistributedDoS Attack Detection and Mitigation in Software Defined Network (SDN)(April 1,2019) (2019)

[38] https://www.imperva.com/learn/application-security/ddos-attacks/

[39] Wei, Hung-Chuan ; Tung, Yung-Hao ; Yu, Chia-Mu: Counteracting UDP floodingattacks in SDN. In: 2016 IEEE NetSoft Conference and Workshops (NetSoft) IEEE,2016, S. 367–371

[40] https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

[41] https://www.netscout.com/what-is-ddos/syn-flood-attacks

[42] https://en.wikipedia.org/wiki/Transmission_Control_Protocol

[43] https://en.wikipedia.org/wiki/POST_(HTTP)

[44] https://www.w3schools.com/tags/ref_httpmethods.asp

[45] https://computer.howstuffworks.com/dns.htm

[46] http://mininet.org/

[47] http://mininet.org/download/

[48] https://www.virtualbox.org/wiki/Downloads


https://www.imperva.com/learn/application-security/ddos-attacks/

https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

https://www.netscout.com/what-is-ddos/syn-flood-attacks

https://en.wikipedia.org/wiki/Transmission_Control_Protocol

https://en.wikipedia.org/wiki/POST_(HTTP)

https://www.w3schools.com/tags/ref_httpmethods.asp

https://computer.howstuffworks.com/dns.htm

http://mininet.org/

http://mininet.org/download/

https://www.virtualbox.org/wiki/Downloads

BIBLIOGRAPHY

[49] https://github.com/mininet/mininet/wiki/Mininet-VM-Images

[50] https://osrg.github.io/ryu/slides/ONS2013-april-ryu-intro.pdf

[51] Olanrewaju, Rashidah F. ; Khan, Burhan Ul I. ; Najeeb, Athaur R. ; Zahir,KN ; Hussain, S: Snort-based smart and swift intrusion detection system. In:Indian Journal of Science and Technology 8 (2018), Nr. 1, S. 1–9

[52] Manso, Pedro ; Moura, José ; Serrão, Carlos: SDN-Based Intrusion DetectionSystem for Early Detection and Mitigation of DDoS Attacks. In: Information 10(2019), Nr. 3, S. 106

[53] Lawal, Babatunde H. ; Nuray, AT: Real-time detection and mitigation ofdistributed denial of service (DDoS) attacks in software defined networking (SDN).In: 2018 26th Signal Processing and Communications Applications Conference(SIU) IEEE, 2018, S. 1–4

[54] Alshra’a, Abdullah S. ; Seitz, Jochen: Using inspector device to stop packetinjection attack in SDN. In: IEEE Communications Letters (2019)


https://github.com/mininet/mininet/wiki/Mininet-VM-Images

https://osrg.github.io/ryu/slides/ONS2013-april-ryu-intro.pdf

Declaration

I declare that the work is entirely my own and was produced with no assistance fromthird parties.I certify that the work has not been submitted in the same or any similar form forassessment to any other examining body and all references, direct and indirect, areindicated as such and have been cited accordingly.

(Udeh, Paschal Chigozie)Ilmenau, Monday 13th January, 2020

detection and mitigation of an abnormal traffic behavior in...

Documents