Luận văn thạc sĩ Khoa học máy tính: Building a framework for secured openflow switch based on FPGA

The architecture is a combination of OpenFlow Pro-cessing that routes packets according to the OpenFlow protocol and SecurityProcessing that defends against network attacks.. By applying

Problem overview

Figure 1.1: The increasing of internet users through the last decade tecture, network control includescontrollersprogrammed by network administrators through software interfaces Each controller is responsible for handling a number of forwarding devices that process forwarding functions Those forwarding devices route network packets from source nodes to destination nodes according to network configuration.

One of the most famous and useful SDN instances is the OpenFlow network [McK- eown et al.,2008] which is a quite popular in not only academia but also industry [Gelberger et al.,2013], so-called OpenFlow protocol Based on the SDN architecture, the OpenFlow network architecture also decouples network control from forwarding functions Therefore, the OpenFlow network takes all the advantages of the SDN paradigm Moreover, by optimizing elements such as controllers and forwarding devices, the OpenFlow network can be implemented as software programs or be developed using hardware platforms.

Although SDN has many advantages compared to traditional network approaches,several security issues are existing in both the architectures of SDN and Open-Flow Much research in the literature analysed vulnerabilities of both SDN andOpenFlow [Farhady et al.,2015;Hu et al.,2014;Kreutz et al.,2013;Nunes et al.,2014] The survey in [Hu et al., 2014] discussed seven threats in an SDN system which can be exploited There are many efforts to overcome these problems [Shin et al.,2014;Tootoonchian and Ganjali,2010] According to the specification of OpenFlow, a cyber-attacker can apply many attack types (e.g a flood-

1.1.PROBLEM OVERVIEW 3 ing attack technique - a type of DDoS) to forwarding devices (switches) which are working in a reactive mode Attackers can force all forwarding devices simultaneously to send a lot of packets to the corresponding controller (switches in an OpenFlow network is associated with a controller) to make the controller overloading and freezing Because of the logically centralized feature of controllers, research in the literature has focused mainly on how to make controllers be more efficient, robust, and reliable It means that the dependable capacity of a forwarding device is still open.

With the fast increasing the number of network attacks, a hardware-based network protection system plays an important role in a successful cyber-security strategy According to reports from Akamai [Akamai,2016], the number of DDoS attacks hit the new record in the second quarter of 2016 Moreover, the trend of DDoS attacks is increasing the attack size Figure1.2 shows a survey of peak attack size during the last decade [Arbor-Network,2016] Compared to software- based network protection systems, the hardware one provides much more performance Moreover, hardware-based systems can allow multiple network protection mechanisms to be executed in parallel Thus, in turn, improves the dependable capacity of the systems.

Worldwide Infrastr ucture Security Report

The largest attack reported by a respondent this year was 500 Gbps, with other respondents reporting attacks of 450 Gbps, 425 Gbps and 337 Gbps This continues the trend of significant growth in the top-end size of DDoS attacks year-over-year Last year, we highlighted that 20 percent of respondents reported attacks over 50 Gbps In contrast, this year nearly one-quarter of respondents report peak attack sizes over 100 Gbps, emphasizing the scale of the DDoS problem Customers remain the number one target for DDoS attacks, with over two-thirds of attacks targeting them Again this year, the proportion of respondents seeing attacks targeting cloud-based services has grown, up from 19 percent two years ago, to 29 percent last year and now 33 percent this year — a clear trend

This year, attackers have continued the 2014 trend of using reflection/amplification techniques to exploit vulnerabilities in NTP, SSDP and other protocols The largest attack reported by a respondent this year was 500 Gbps, with other respondents reporting attacks of 450 Gbps, 425 Gbps, and 337 Gbps (Figure 14) Another five respondents reported events at 200+ Gbps This continues the trend of significant growth in the top-end size of DDoS attacks year-over-year

Last year, 20 percent of respondents reported attacks over 50 Gbps This year’s survey results indicate a sharp uptick, with nearly 25 percent of respondents seeing peak attack sizes over 100 Gbps In general, peak attack sizes and large attack frequency seem to have increased dramatically over last year The record number of 100 Gbps+ attacks tracked by the Arbor ATLAS system during 2015 confirms this; please see the ATLAS attack sizes section for further details

Survey Peak Attack Size Year Over Year

Figure 14 Source: Arbor Networks, Inc

Survey Peak Attack Size Year Over Year

Figure 1.2: Survey Peak Attack Size Year Over Year Source: Arbor Network, Inc.

To protect an OpenFlow-based network, in particular against DDoS attacks,a network security system needs to be deployed at forwarding devices so that attacking packets are removed from the network In other words, by classifying and deleting attacking packets at forwarding devices, controllers are protected from network attacks There is no any OpenFlow-based network switch in both the literature and industry integrating hardware security engines although there exists

Thesis challenges

some forwarding devices including security functions executed on embedded general purpose processors (GPP) such as Avant-GAURD and OFX [Shin et al., 2013;Sonchack et al.,2016].

Moreover, a network system usually suffers from multiple attacks in different types at a time Therefore, software-based usually cannot prevent all simulta- neous attacks scenarios This shortcoming makes existing OpenFlow-based network switches not efficient enough, especially when we are entering into the big data era where more and more data needs to be transferred and processed by network systems.

To cope with the issues presented in the previous section, hardware-based security systems that can protect forwarding devices of an OpenFlow-based network is an essential demand One possible approach is to design and implement a dedicated hardware-based network protection system to scan incoming network packets before sending them to forwarding devices However, this approach introduces much operational overhead because the protection system requires a separated management.

The more efficient approach is to integrate hardware-based security modules into forwarding devices so that these modules are managed using the OpenFlow protocol Compared to the previous approach, operation cost is lower This approach has been taken into consideration by many researches in the literature such as OFX and Avant-GAURD as mentioned above However, a software-based network protection is not sufficient enough for high-speed networks We therefore explore the following research questions in this thesis.

Question 1 Is it possible to build an OpenFlow-based network switch with an integrated reconfigurable hardware-based network protection module?

One of the most advantages of software-based protection system is the reconfiguration ability The implemented security mechanisms can be quickly updated or changed to prevent attacks from the systems With the current trend in information technology development, more and more attacking techniques can be deployed to attack a system Therefore, the hardware-based network protection module in the proposed OpenFlow-based network switch needs to have the reconfiguration ability The module also needs to be compatible with the Open-Flow protocol.

Contributions

Question 2 Does it pay off to build such an OpenFlow-based network switch?

To the best of our knowledge, there is no any OpenFlow switch with integrated hardware-based network protection engine Therefore, we need to exam if it pays off to build such a switch We need to take many aspects of the switch into ac- counts such as performance and throughput and packets processing time More- over, the reconfiguration ability of the protection engine is also analyzed.

Question 3 How can we build a framework that allows network administrators to configure/update the network protection module as well as manage/control the proposed switch?

One of the key factor when integrating hardware-based protection engine into an OpenFlow switch is to keep the OpenFlow protocol unchanged However, as a network protection engine, the switch needs to interact with network administrators to get control instruction as well as show status information An another important requirement is that the switch can be reconfigured not only according to the OpenFlow protocol but also updating the protection engine Therefore, we try to develop a framework working on a host processor so that network administrators can handle the switch.

Based on the research challenges identified in the previous section, we have been working on design and implement an OpenFlow switch with an integrated hardware-based network security module using reconfigurable hardware We focus on reconfigurable hardware so that the security module can be updated to more up-to-date and efficient network protection mechanisms The main contributions of this thesis can be summarized as follows:

Contribution 1 We propose an OpenFlow switch architecture with integrated hardware-based security functions.

To the best of our knowledge, this is the first OpenFlow switch that not only can route network packets according to the OpenFlow protocol but also can defend against network attacks The proposed architecture separate the OpenFlow processing part from security processing part This approach allow different security functions to be deployed for different systems and purposes.

Thesis organization

Contribution 2 We demonstrate our proposed OpenFlow switch using FPGA technology to verify the benefit of the proposed architecture.

Our prototype secured OpenFlow-based switch using the NetFPGA-10G board which is integrated two different DDoS defense mechanisms, the Hop-Count Fil- tering and the Port Ingress/Egress Filtering The switch prototype can work at up to≈80 MHz and achieve a 100% detection rate This prototype version can be a baseline system to compare other similar systems in future work.

Contribution 3 We propose and implement a framework to allow users/researchers to configure and manage forwarding devices in an OpenFlow network.

The proposed framework consists of three different layers the GUI layer, the SDK layer, and the Plugins layer With the three layers architecture, the framework is suitable for handling and monitoring different forwarding devices in an Open- Flow network The proposed framework is developed with the QT5.7 environment so that the framework can work with multiple platforms.

Contribution 4 We published two scientific papers at international conferences.

1 Bao Ho, Quoc Nguyen, Cuong Pham-Quoc and Tran Ngoc Thinh, “Secured-

OFS: A Novel OpenFlow Switch Architecture with Integrated Security Func- tions”, The Advanced of International Conference on Advances in Informa- tion and Communication Technology (ICTA2016), 12-13 December, 2016, Thai Nguyen, Vietnam.

2 Bao Ho, Cuong Pham-Quoc, Tran Ngoc Thinh and Nam Thoai, “A Secured

OpenFlow-based Switch Architecture”, International Conference on Advanced Computing and Applications (ACOMP 2016), 23-25 November, 2016, Can Tho, Vietnam.

The work in this thesis is organized in 7 chapters Chapter2gives an overview of the SDN as well as FPGA technology A survey of OpenFlow switch with integrated security functions is also presented Finally, an overview of the NetFPGA-10G board, which we use to implement our first prototype OpenFlow switch, is introduced in this chapter.

Summary

Chapter3presents our proposed OpenFlow switch with integrated security functions We explain, in detail, the purpose of each component and how the OpenFlow protocol can cooperate with security mechanisms to process incoming network packets The proposed architecture can be implemented using many reconfigurable hardware technologies and families.

Chapter 4 shows our first prototype OpenFlow switch using the NetFPGA- 10G board The board includes one Xilinx Virtex-5 xc5vtx240t device This chapter also gives hardware resources usage information for the switch Although we build the first prototype switch using the Virtex-5 FPGA device, the architecture and the implementation can be synthesized and ported into different FPGA families and technologies because we use hardware description language to build the switch.

We introduce our framework in Chapter5 The main purpose of the framework is to used to control and test the switch It also shows network attacking statistic for research and management purpose.

We deploy many test-cases to validate both the OpenFlow-based switching mechanisms as well as network security ability of the switch The experimental results are shown in Chapter6 This chapter also analyses the switch throughput and the accuracy of security functions.

Finally, Chapter7concludes this thesis and introduces some open issues for future research.

In this first chapter, we introduce current open issues with OpenFlow-based switches.

Based on these research challenges, our work focuses on proposing an Open- Flow switch architecture with integrated security functions so that the switch can function as not only an OpenFlow switch but also a network protection system.

We have two different contributions for the scientific world This chapter also summarizes contents and organization of this thesis.

In this chapter, we give an overview of the SDN as well as FPGA technology A survey of OpenFlow switch with integrated security functions is also presented.

Finally, an overview of the NetFPGA-10G board, which we use to implement our first prototype OpenFlow switch, is introduced in this chapter.

Software Defined Network: an overview

Software Defined Network (SDN) [Goransson and Black,2014] has been considered as an emerging alternative approach for traditional networks whose devices (e.g routers, switches, firewalls, ) must be separated, hardly configured and managed Compared to traditional networks, SDN offers more benefits such as providing centralization control and monitoring, simplifying hardware devices, and furnishing a capacity of virtualization and automation at the network level To provide such advantages, a SDN architecture partition the network logic model into three planes,management plane,control plane anddata plane Fig- ure2.1illustrates the logical model of SDN Following this architecture, the SDN architecture decouples network control from forwarding functions so that network control becomes programmable In the SDN architecture, network control includes controllers programmed by network administrators through software interfaces Each controller is responsible for handling a number offorwarding devices that process forwarding functions Those forwarding devices route network packets from source nodes to destination nodes according to network configuration.

Forwarding Device Network Service Open northbound API

Figure 2.1: Layered view of networking functionality

One of the most popular and successful SDN versions is the OpenFlow network [McKeown et al., 2008] which not only is quite popular in academia but also is an industry standard [Gelberger et al.,2013], so-called OpenFlow protocol Based on the SDN architecture, the OpenFlow network architecture also decouples network control from forwarding functions Therefore, the OpenFlow network takes all the advantages of the SDN paradigm Moreover, by optimizing elements such as controllers and forwarding devices, the OpenFlow network can be implemented as software programs or be developed using hardware platforms.

However, there are several security issues existing in both the architectures of SDN and OpenFlow Much research in the literature analysed vulnerabilities of both SDN and OpenFlow [Hu et al.,2014;Kreutz et al., 2013;Scott-Hayward et al.,2016] The survey of [Scott-Hayward et al.,2016] discussed seven attacks and vulnerabilities in an SDN system which can be exploited These attacks and vulnerability are at many levels, from control plane to data plane and even the communication between controller and forwarding devices Two of these threats are likely from the traditional network and reside in the data plane of SDN architecture Although the two of threats are not a specific of SDN, they still exist and seem to be exploited to attack network For instance, a cyber can fake traffic flows in the data plane to attack controllers or forwarding devices Besides, a simple forwarding device without any potential security can be a wide entrance for an attacker to do dangerous activities.

According to the specification of the OpenFlow protocol, Figure2.2presents three major weakness which can be exploited by attackers Here, we summarize the three weak points:

1 Forwarding devices (or switches), we call “forwarding device weakness”, are the starting points for all attacks, especially in active mode (active mode means that the switches can self-learn strange/new flows) Attackers can simultaneously flood network packets with differentmatching_field values so that the switches needs to encapsulate and send these packets to the corresponding controller to get exact behaviors for these packets With these flooding packets, the communication channel between the controller and forwarding devices becomes congestion The combination of one cen- tral controller and separation of the control and data plane is the core weakness in SDN architecture The controller can become frozen along with an overflow at theflow table in the switches due to a large number of packets requiring a flow rule decision.

2 Channel for communication between forwarding devices and the associated controller is a place where seems to be attacked According to the SND and OpenFlow protocol, this channel should be implemented using Secured Socket Layer (SSL) However, there exist a lot of commercial Open- Flow networks which do not follow this requirement Therefore, the channel can be hijack to take over the controller [Benton et al.,2013;Shin and Gu,2013;Wasserman and Hartman,2013].

3 When a controller is taken over by attackers, the whole associated data plane (all forwarding devices in this data plane) is under controlled by attackers because centralized management is conducted at the controller.

Although there exists three different weakness in an OpenFlow network, to hijack the communication channel or the controller, attackers need to send attacking packets to forwarding devices at first For example, attackers can apply many attack types (e.g a flooding attack technique - a type of DDoS) to forwarding devices (switches) which are working in a reactive mode Attackers then can force all forwarding devices simultaneously to send a lot of packets to the corresponding controller to make the controller overloading and freezing.

There are many efforts to overcome these security problems [Shin et al.,2014;

Tootoonchian and Ganjali,2010] Because of the logically centralized feature of controllers, research in the literature has focused mainly on how to make controllers be more efficient, robust, and reliable There exist some approaches that integrate security functions into forwarding devices so that incoming packets are scanned before processed further at the associated controller to prevent such at-

Security approaches for OpenFlow network

In fras tructu re La yer

Figure 2.2: Three major security problems of OpenFlow network tacks as mentioned in the previous paragraphs The next section shows a survey of these approaches in the literature.

2.2 S ECURITY APPROACHES FOR O PEN F LOW NETWORK

Although there exists three different weakness in an OpenFlow network, to hijack the communication channel or the controller, attackers need to send attacking packets to forwarding devices at first For example, attackers can apply many attack types (e.g a flooding attack technique - a type of DDoS) to forwarding devices (switches) which are working in a reactive mode Attackers then can force all forwarding devices simultaneously to send a lot of packets to the corresponding controller to make it overloading and freezing.

There are many efforts to overcome these security problems [Shin et al.,2014;

Tootoonchian and Ganjali,2010] Because of the logically centralised feature of controllers, research in the literature has focused mainly on how to make them more efficient, robust, and reliable There exist some approaches that integrate security functions into forwarding devices so that incoming packets are scanned before processed further at the associated controller to prevent such attacks as mentioned in the previous paragraphs The next section shows a survey of these approaches in the literature.

AVANT-GUARD [Shin et al.,2013] extends forwarding devices in the data plane by adding two new module: (1) a connection migration module to handle the threats of saturation attack; (2) anactual trigger moduleto address the respon-

2.2.SECURITY APPROACHES FOR OPENFLOW NETWORK 12 siveness challenge by providing condition triggered push capability in SDN devices.

With the two new added modules, the forwarding devices are able to in- crease the resilience of the data-plane-to-control-plane interaction to anoma- lous control-plane floods However, the two modules are implemented by a general purpose processor instead of hardware as our work.

AuthFlow [Ferrazani Mattos and Duarte,2016] is an authentication and access control mechanism for SDN The main idea in this proposal is to deploy an Authenticator and a RADIUS server to allow or deny network traffic at data plane layer The Extensible Authentication Protocol (EAP) is used for communication among the OpenFlow controller, the Authenticator, and the RADIUS servers Both the servers are built in personal computers.

Virtual Source Address Validation Edge (VAVE) [Yao et al.,2011] is a solution with OpenFlow/NOX architecture to improve the source address validation standard (SAVI) In this work, some OpenFlow devices are used to form a protective perimeter Whenever there exists a packet coming from outside perimeter, its source address needs to be validated by a validation module However, the paper did not provide any detail of this validation module.

OFX (OpenFlow Extension Framework) [Sonchack et al.,2016] allows Open- Flow switches to be extended with custom functionality In this approach, OFX extension modules are built in OpenFlow switches using existing general purpose processors These extension modules allow the switches to classify incoming packets based on different mechanisms installed by the associated controller.

Three different deployed security applications are DDoS Detection, Network Taint- Tracking Declassifier, and Botnet Detection This approach shares the same idea with our work However, instead of using a general purpose processor to deploy different security mechanisms we develop dedicated reconfigurable hardware modules for security mechanisms.

The authors of DevoFlow [Curtis et al.,2011] introduce two new mechanisms to transfer control to an OpenFlow switch, rule cloning and local actions The rule cloning mechanism implemented in the switch uses an additional flag, called CLONE flag, to avoid invoking the controller Meanwhile, the local actions mechanism implements a small set of possible “local routing actions” so that the switch can process new flows if possible without sending requests to the controller.

However, the authors have implemented the approach yet It can be taken into account for the next generation of switches.

2.2.SECURITY APPROACHES FOR OPENFLOW NETWORK 13

DIFANE˜citepYu:2010:SFN:2043164.1851224 is a scalable and efficient proposal that routes all traffic through a predefined path of forwarding devices, that store the necessary rules The associated controller is responsible for partitioning rules over the switches However, due to the multi-hop path, the delay time of network packets is increased Moreover, the approach can not be applied for scanning packets to recognize attacks such as DDoS.

A DoS Attack Prevention Extension in Software-Defined Networks, so-called FloodGaurd [Wang et al.,2015], is a solution for the data-to-control plane saturation attack The solution contains two new techniques/modules: proactive flow rule analyser and packet migration The proactive flow rule analyser combines symbolic execution and dynamic application tracking to derive proactive flow rules in runtime while the packet migration module migrates, caches, and processes packets without existing associated rules in the flow table by using rate limiting and round robin scheduling However, the modules are implemented inside the controller instead of forwarding devices.

A denial of service defense system for software defined networking, FlowFence, is introduced in [Piedrahita et al.,2015] Network routers in the FlowFence architecture run a special service to monitor the average occupation of their interfaces to detect congestion conditions The associated controller bases on this detection to coordinate bandwidth assignment of controlled links Using such approach, the controller can limit the flow transmission rate from data plane to prevent the links from saturation The mitigation procedure of starvation state allocates an average bandwidth, while flows exceeding the mean are penalised.

This approach is only simulated and evaluated with a simulation tool.

LineSwitch [Ambrosin et al.,2015] is an efficient and effective solution against control plane saturation attack It combines SYN flooding defense technique and probabilistic blacklisting technique for switches at data plane This combination results in an efficient LineSwitch against the control plane saturation attack.

However, the proposal is simulated using a network simulator only.

The authors in [Park et al., 2016] proposed a Union of Security Actions forSoftware Switches, called UNISAFE The proposed switches employ two software functions running in the kernel space of the switches, the UNISAFE main controller and Security actions The authors implement a prototype version with three different security functions: DDoS detector, scan detector, and deep packet inspection However, the proposal is implemented as software modules instead of dedicated hardware as our approach.

Field Programmable Gate Array

There exist many studies in the literature that introduce different solutions to protect an OpenFlow network at different level such as ROSEMARRY [Shin et al.,2014] protecting controllers only or PermOF [Wen et al., 2013] to protect the application layer only Such those approaches are totally different from ours because our ultimate goal is to protect the network against attacks as soon as possible In other words, we implement security functions at forwarding devices of an OpenFlow network.

Here, we already analyze research in the literature that proposed solutions to protect data plane against attacks However, all the above approaches are implemented as software functions in a general purpose processor or are simulated by a network simulator only To the best of our knowledge, our proposed approach is the first hardware-based implementation.

As mentioned above, our ultimate goal is to implement security functions for forward devices in an OpenFlow network as dedicated hardware modules The main obstacle to this approach is updating and changing hardware modules Updat- ing and changing security functions in a network protection system is an essential demand because attacks can be deployed with modern techniques at higher performance Therefore, in this work, we target our work on reconfigurable hardware technology, i.e Field Programmable Gate Array technology so that the reconfigurable requirement can be satisfied This section introduces an overview of this technology.

Field Programmable Gate Array (FPGA) is a dominant technology for building high-performance computing applications and reconfigurable computing systems Compared to general purpose processor, FPGAs have benefits in performance while compared to Application Specific Integrated Circuits (ASIC), FPGAs allow hardware circuits to be reconfigured Applied to two characteristics, FPGAs are widely used in both academic research and industry products Some well- known commercial FPGA-based high-performance computing platforms can be counted such as Micron [Micron,2012] (former Convey) and Maxeler [Pell and Mencer,2011].

Although there exist many FPGA producers, they share the same basic architecture An FPGA device is a semiconductor device that includes a matrix of configurable logic blocks (CLB) connected through programmable interconnects [Xilinx,2016] The Figure2.3shows basic components of an FPGA device.

Three main components of FPGA include:

• Logic blocks: A logic block is also known as CLB A CLB includes lookup ta- bles (LUT) to implement combinational logic, registers for sequential circuits, and some additional logic elements such as multiplexers or buffers.

Each LUT has multiple inputs to function as a multiple inputs combinational logic The number of inputs for each LUT depends on the architecture and generation of FPGA devices It is about 4 to 6 input for modern FPGA devices Figure2.4shows a sample CLB in a modern FPGA architecture.

• Input/Output blocks: These blocks are responsible for connecting and com- municating with external components or devices.

• Interconnection switch: These switches can be programmed to connect or disconnect CLBs, IO blocks and other components.

FPGA may contain other blocks such as memory, clock distribution, digital signal processor (DSP), embedded microprocessors/microcontrollers, high-speed serial transceivers.

Programmable Interconnect Input/Output Blocks

Figure 2.3: The basic architecture of an FPGA device

FPGA is more flexible than application-specific integrated circuit (ASIC) Both of them are programmable While FPGA is programmable after manufacturing

Programmable Interconnect Input/Output Blocks

Figure 2.4: A configurable logic block in a modern FPGA architecture by users, ASIC is programmed by experts from a manufacturer and can not be re- programmed after manufacturing FPGA not only takes advantage of hardware- based high-speed parallel processing but also the flexibility of software-based programmability They are designed and programmed using hardware description language (HDL) such as Verilog, very high speed integrated circuit (VHSIC) HDL (VHDL).

An FPGA device is configured by loading an application-specific configuration data, named bitstream, into internal configuration memory Partial reconfiguration (PR) is the modification of an operating FPGA configuration memory by loading a partial configuration file With the rapid development of technology,FPGAs allow dynamic partial reconfiguration (DPR) It means that some parts of an FPGA device can be reconfigured at runtime while other parts are still working This runtime reconfiguration helps systems be updated while still operat-

The NetFPGA platforms

ing The design flow of DPR partitions configuration memory into static logic and reconfigurable logic [Xilinx,2012] In DPR process, the static logic remains functioning while the reconfigurable logic is modified by the partial configuration file In this research, DPR is applied to change and update DDoS countering mechanism to adapt security challenges in the future.

NetFPGA [NetFPGA, 2014] is an open-source hardware and software platform designed for research and teaching It allows researchers, developers, and stu- dents to build prototypes of high-speed, hardware-accelerated networking systems based on its supported platforms Its platforms, which is named NetFPGA platform, are built upon FPGA technology supported by the manufacturer There are several NetFPGA platforms such as NetFPGA 1G, NetFPGA CML, NetFPGA 10G and NetFPGA SUME In this work, we use the NetFPGA-10G platform (Fig- ure2.5) to build our prototype OpenFlow switch.

The NetFPGA-10G board includes four SFP+ ports and one Xilinx Virtex-5TX240T FPGA device Four SFP+ ports are suitable to build high-speed network applications Besides, Xilinx Virtex-5 TX240T provides powerful hardware resources to handle massive traffic on a network We use Hardware DescriptionLanguage (HDL) to develop all modules in the three most important components More details about the board are shown in Table2.1.

Summary

Maximum Distributed RAM (Kbits) 2,400 Block RAM/FIFO v/ECC (36Kbits each) 324

Phase Locked Loop (PPL)/PMCD 6

10/100/1000 Ethernet MAC Blocks 4 Configuration Memory (MBits) 65.8

In this section, we introduce the SND and OpenFlow networks as well as security issues of both the networks A survey of solutions to protect OpenFlow networks at data plane levels is given in this chapter In this work, we aim to create an OpenFlow-based switch with hardware-based security functions Therefore,we present an overview of FPGA technology that we use to build our prototype switch Finally, we discuss the NetFPGA platform which is used as our experimental platform.

In this section, we present our proposed OpenFlow-based switch architecture.

The switch can function as not only an OpenFlow protocol-based switch but also a security system to defend against network attacks Our ultimate goal is that the switch can be implemented by different hardware technology such as ASIC or FPGA Therefore, we propose the architecture that is independent of technology.

Figure3.1shows our proposed switch architecture The proposed architecture consists of three different components named Ingress, Egress, andEngine.

The Ingress component is responsible for receiving incoming packets from input ports, both data packets and control packets, and forwarding to the Engine component for processing The Engine component is the main component of the proposed switch All incoming packets are analysed and processed in this component according to both the OpenFlow protocol and implemented security functions Finally, these packets are routed to corresponding output ports of theEgress component Here, we present the components in details.

The Ingress component

The Ingress component includes one Packet Input Queue, multiple data input ports (Data InPort i), and one control input port (Control InPort) The number of data input ports depends on hardware resources available of the platform which is used to implement the switch All incoming network packets arriving data input ports are collected and stored into buffers inside these ports Packet Input

The Egress component

Flow of extracted features Flow of instructions

Incoming Packet Pr ocessi ng

Secured Core i Secured Core m Classifier

Figure 3.1: The proposed switch architecture

Queue sequentially selects a packet from a buffer and forwards to the Engine component for processing Packet Input Queue can be configured on the fly so that packets from buffers are selected based on a specific strategy such as Round Robin or based on a priority of each data input port While Data InPort is responsible for receiving network packets, OpenFlow-based configuration data is transferred to the switch through Control InPort.

Control InPort is the mean for communication between the associated controller and the OpenFlow-based switch according to the OpenFlow protocol In other words, the corresponding controller sends configuration data through this port to handle the switch following the protocol Configuration data is usually information used to update the Flow Table Configuration data is encoded into network packets so that Packet Input Queue can process them without any ex- ception However, compared to data input ports, this Control InPort has a higher priority, i.e., Packet Input Queue selects a packet from this port to send to the En- gine component whenever there exists any packet in the buffer of Control InPort regardless strategies used to select packets at Packet Input Queue.

If the Ingress component can be considered as the main entrance of the switch,the Egress component can be seen as the main exit of the switch where network

The Engine component

Incoming Packet Processing

The major function of the Incoming Packet Processing block is to decode an incoming packet into different fields such as header field and payload field De-

3.3.THEENGINE COMPONENT 22 pending on the type of the input port from which packets come (data port or control port), Incoming Packet Processing processes incoming packets in two different scenarios In the first scenario, when packets come through the control port, these packets are forwarded to the OpenFlow Processing block without any processing at the Incoming Packet Processing block because these packets are generated by the associated controller to update or handle the switch These packets are not examined by the security mechanisms because we assume that the communication link between the controller and the switch is secured More- over, in our work, this link is implemented as internal and private infrastructure such PCIe or buses In other words, the link is isolated from external networks.

In the second scenario, when packets arrive through data input ports, Incom- ing Packet Processing analyses and decodes these packets first Both the Open- Flow Processing and Security Processing blocks are carried out simultaneously to process these packets in parallel The header fields of these packets are transferred to OpenFlow Processing so that corresponding actions for each packet can be retrieved Meanwhile, depending on which network security mechanisms are used in Security Processing, different fields of packets are required so that these packets can be scanned to guarantee that these are legitimate network packets.

These fields are forwarded to the Security Processing block This scenario may result in different behaviors such as attacking packet is dropped, it is forwarded to a destination data output port or it needs to be forwarded the controller.

Due to processing at both the OpenFlow Processing block and the SecurityProcessing block take time, the Engine component needs to work in a pipeline mode Therefore, the Incoming Packet Processing block needs to store raw packets into the Packet FIFO block in parallel with forwarding packet’s fields to Open-Flow Processing and Security Processing While the OpenFlow Processing andSecurity Processing blocks are processed one packet, the Incoming Packet Pro- cessing block can analyze and decode another packet This approach helps improve system performance so that the switch could be suitable for high-speed networks.

OpenFlow Processing

The block consists of aOpenFlow Host Agent module, aFlow Table, and two interfaces to communicate with both the Incoming Packet Processing and Outgo- ing Packet Processing blocks When packets come to the switch through Con- trol InPort, these packets are generated by the associated controller to update or

3.3.THEENGINE COMPONENT 23 handle the switch These packets contain instructions that the controller uses to handle the switch such as updating Flow Table or modifying a packet header.

The OpenFlow Host Agent module is responsible for receiving control packets, executing instructions, and sending feedback to the controller if required when control packets come to the switch.

When data packets arrive the switch, they are examined by the Security Pro- cessing block to defend against network attacks and processed by this Open- Flow Processing according to the OpenFlow protocol The OpenFlow Host Agent module analyses data packets and retrieves actions for each packet from Flow Table If actions for a particular packet can be found, they are returned to the Outgoing Packet Processing block through theAction Out interface Otherwise, when actions for a specific packet cannot be found in the Flow Table, OpenFlow Processing requests Outgoing Packet Processing to send the packet to the associated controller so that the controller can decide appropriate actions for the packet However, in both the cases, the behavior of the Outgoing Packet Process- ing depends on classification information from the Security Processing block If the packet is recognized as an illegitimate packet, it is removed from the switch regardless actions from the OpenFlow Processing block Otherwise, when the packet is classified as a legitimate packet, actions from the OpenFlow Processing block are processed by the Outgoing Packet Processing block.

To support the OpenFlow protocol, Flow Table is needed to store OpenFlow- based actions [Suh et al.,2014] such as dropping, updating the header field, or forwarding a packet to a destination output port Figure3.2illustrates a segment of Flow Table Each entry of the table consists of fields, Matching Field and Ac- tion Based on header fields of a packet, the OpenFlow Host Agent module find an entry whose matching field matches with the information in the headers of the packet If such the entry can be found, the value in the corresponding action field is extracted to the Action Out interface Otherwise, routing information for the packet does not exist The OpenFlow Host Agent requires sending the packet to the controller.

Packet FIFO

When an incoming data packet is being processed by both OpenFlow Process- ing and Security Processing, other packets can arrive Incoming Packet Process- ing Therefore, the whole packet that is being processed needs to be stored inPacket FIFO to wait for decisions from both OpenFlow Processing and Security

Figure 3.2: The Flow Table architecture

Processing The size of this buffer depends on the hardware resources available in the hardware platforms that are used to build the switch The larger the Packet FIFO, the higher throughput of incoming packets can be accepted In the case of incoming throughput is much higher than processing throughput, this Packet FIFO could become overflow When Packet FIFO is overflow, no any incoming packet is collected by Incoming Packet Processing.

In this prototype versions, Packet FIFO can be implemented by on-chip or off-chip memory On-chip memory allows a faster accessing while suffering from a small size While offering large size, off-chip memory requires long accessing time and complicated interconnect In the general architecture, we do not need this trade-off into account.

Security Processing

The block is mainly responsible for guaranteeing that incoming packets do not belong to network attacks Security Processing includes a number of Secured Coresand two interfaces to communicate with Incoming Packet Processing and Outgoing Packet Processing The number of Secured Cores is defined by developers based on the sensitivity of protected networks and, of course, hardware resources of the developed platforms.

Each Secured Core implements a particular network defense mechanism to defend against a specific type of network attacks such as Anti-DDoS and Anti-Virus Depending on characteristics of networks where the switch is deployed and how sensitive networks are, different security functions are selected to implement in this Security Processing block by Secured Cores In other words, the

3.4.SUMMARY 25 functionality of Security Processing will be different from a switch to switch.

In this work, we aim to develop a system with high-performance protection ability Therefore, Secured Cores need to built with dedicated hardware circuits.

However, our goal is to have a flexible switch in which different security functions can be deployed and changed Hence, the create Secured Cores with the same interface so that the cores can be updated and changed at both at runtime by using the dynamic reconfiguration technique and at configuration time.

Because each Secured Core performs a particular security function, a packet is considered as an illegal packet if it is classified as an illegal packet by at least one core In this case, a DROP signal is issued to Outgoing Packet Processing.

When all Secured Cores vote that a packet is legal, aPASSsignal is sent to Outgo- ing Packet Processing.

Outgoing Packet Processing

This block is responsible for applying a decision to a packet based-one information from both the OpenFlow Processing block and the Security Processing block.

The Outgoing Packet Processing block starts processing a packet when receiving final decisions from both OpenFlow Processing and Security Processing If Secu- rity Processing recognizes that the packet does not belong to any network attack, actions taken from Flow Table are applied to the packet Otherwise, the packet is destroyed immediately.

In the case when the packet is classified as legitimate packet but OpenFlow- based actions for this particular packet cannot be found in Flow Table, i.e., theOpenFlow Processing requests to send the packet to the associated controller,Outgoing Packet Processing forwards this packet to the controller through Con- trol OutPort Because the forwarding time of this block is usually less time processing time of the OpenFlow Processing and Security Processing blocks, no any internal buffer is required for this block Figure3.3summarizes the flow for processing an incoming network packet.

Summary

functionality of Security Processing will be different from a switch to switch.

In this work, we aim to develop a system with high-performance protection ability Therefore, Secured Cores need to built with dedicated hardware circuits.

However, our goal is to have a flexible switch in which different security functions can be deployed and changed Hence, the create Secured Cores with the same interface so that the cores can be updated and changed at both at runtime by using the dynamic reconfiguration technique and at configuration time.

Because each Secured Core performs a particular security function, a packet is considered as an illegal packet if it is classified as an illegal packet by at least one core In this case, a DROP signal is issued to Outgoing Packet Processing.

When all Secured Cores vote that a packet is legal, aPASSsignal is sent to Outgo- ing Packet Processing.

This block is responsible for applying a decision to a packet based-one information from both the OpenFlow Processing block and the Security Processing block.

The Outgoing Packet Processing block starts processing a packet when receiving final decisions from both OpenFlow Processing and Security Processing If Secu- rity Processing recognizes that the packet does not belong to any network attack, actions taken from Flow Table are applied to the packet Otherwise, the packet is destroyed immediately.

In the case when the packet is classified as legitimate packet but OpenFlow- based actions for this particular packet cannot be found in Flow Table, i.e., the OpenFlow Processing requests to send the packet to the associated controller, Outgoing Packet Processing forwards this packet to the controller through Con- trol OutPort Because the forwarding time of this block is usually less time processing time of the OpenFlow Processing and Security Processing blocks, no any internal buffer is required for this block Figure3.3summarizes the flow for processing an incoming network packet.

In this chapter, we present our proposed OpenFlow-based switch architecture with integrated security functions The proposed architecture switch can function as not only an OpenFlow-based forwarding device but also a network protection system The proposed architecture consists of three main components the Ingress, Engine, and Egress components Network protection mechanisms

Packet In Queue Packet Out Queue

De q u eu e P ac ke t E xt ra ct Fe at u re s P ro ce ss O p e n Fl o w & Se cu rit y fu n ct io n A p p ly A C TI O N fo r p ro ce ss e d p ac ke t START

FORWARD Packet to Specific PORT

Figure 3.3: The flow for processing an incoming network packet in our architecture can be implemented as hardware modules in Secured Cores.

The cores communicate with other modules through a standard interface There- fore, protection mechanisms can be updated or changed The proposed architecture is technology-independent Therefore, it can be deployed using different platforms.

The previous section shows the architecture of our proposed switch The architecture can be developed using many different technologies such as FPGA or ASIC The proposed architecture also can be deployed using multicore systems where each block in the Engine component can be implemented by a computing core In this section, we present our prototype switch implemented on an FPGA device using the proposed architecture Compared to ASIC, FPGA technology is suitable to build prototype systems so that secured cores can be updated to adapt to different attack types This ability makes the system more powerful and more flexible Therefore, we decide to use FPGA technology to quickly develop our prototype switch More precisely, we implement the first prototype OpenFlow- based switch on the Xilinx Virtex-5 xc5vtx240t FPGA device.

Except for the Security Processing block where different security functions can be deployed by Secured Cores, all other blocks in the Engine component and the two rest components are developed as described in the previous section.

Therefore, we only highlight implementation of the Security Processing block in this section.

Security Processing

Hop-Count filtering

The Hop-Count Filtering core comprises four main modules calledHop-CountCalculating,Hop-Count Records,IP Address Records, andComparator Figure4.1 presents the architecture of the Hop-Count Filtering secured core implemented in this work When the core receives source IP address and its final Time-To-Live(TTL) value from Incoming Packet Processing through the interface of the Se- curity Processing block, Hop-Count Calculating computes the Hop-Count value for the packet The Comparator module, then, look-ups IP address and stored hop-count value for the packet using both the Hop-Count Records and IP Ad- dress Record module If the calculated Hop-Count value is matched to the storedHop-Count value, the packet is considered as the legitimate packet In this case,aPASSED signal is returned to the Classifier for making the final security decision In the case of the calculated Hop-Count value is different from the storedHop-Count value, the packet belongs to a DDoS attack A DROPPED signal is issued to the Classifier to alert the Output Packet Processing When this is the first time a packet coming from this source IP has come to the switch, its IP address and Hop-Count value are stored into Hop-Count Records and IP AddressRecords module This is the main drawback of the Hop-Count Filtering mechanisms because IP address and Hop-Count values of a packet can be modified illegally when the packet is travelling in a network Therefore, in this work, we consider integrating multiple DDoS countermeasure techniques into a hardware system to improve both protection efficiency and system performance.

IP Address Records Classifier Outgoing Packet Pr ocessing

Figure 4.1: The Hop-Count Filtering Core architecture

Port Ingress/Egress filtering

Figure 4.2depicts the architecture for the Port Ingress/Egress filtering core implemented in this research As shown in the figure, the Port Ingress/Egress filtering core contains aRegister Table module and aComparator module Regis- ter Table stores special IP address blocks that are not allowed to appear in networks [Cotton and Vegoda, 2010] The Comparator module compares IP addresses of incoming packets with stored IP addresses in Register Table When the packet source IP address is sent to Port Ingress/Egress Filtering core, Port In- gress/Egress Filtering searches the address in Register Table If a MISSsignal is returned (i.e., no record was found in Register Table), the packet is legitimate.

Otherwise, the packet is illegitimate (i.e., a HIT signal is returned) Based on this HIT or MISS signal, the Port Ingress/Egress filtering core sends a PASSED orDROPPEDsignal to the Classifier as the Hop-Count Filtering core Table4.1 shows part of Register Table content.

Figure 4.2: The Port Ingress/Egress Filtering Core architecture

Table 4.1: Prohibited IP addresses in a network [Cotton and Vegoda, 2010]

169.254.0.0/16 Link Local 172.16.0.0/12 Private-Use Networks

192.88.99.0/24 6to4 Relay Anycast 192.168.0.0/16 Private-Use Networks

198.18.0.0/15 IP Benchmark Testing 198.51.100.0/24 TEST-NET-2

240.0.0.0/4 Reserved for Future Use255.255.255.255/32 Limited Broadcast

SYN Defender core

The purpose of SYN Defender core is protecting the system from SYN flood attack technique Firstly, we describe a brief description of SYN flood attack mechanism In this attack technique, attackers try to send a mass of SYN packets to a victim host to exhaust the resource of a system so that it cannot serve any legitimate user The SYN flood attack technique exploits a vulnerability of three way handshaking in Transmission Control Protocol(TCP) When a client needs to transmit data to a server, it has to send a SYN packet to the server for asking a connection The server replies a SYN/ACK packet to the client for acceptant and making a connection request The client must send an ACK packet to the server for confirming that this request is approved At this time, the connection between client and server is established, and data transferring is started How- ever, what happens if the client does not send the last ACK packet? In this case, the server will try to re-send SYN/ACK packet many times before ignoring that client Thus, the server exhausts its limitation resources to serve an illegal client, and runs out of possible resources for legitimate one.

Figure4.3describes the SYN Defender core which is integrated as a SecuredCore to prevent a host from SYN flood attack The SYN Defender core com-

MSS,Src IP,Dst IP, Src Port, Dst Port

Figure 4.3: The SYN Defender Core architecture prisesHash Calculator,Valid SYN Records,SYN Cookie Generator, andCompara- tormodule The operation of SYN Defender is layout in Figure4.4 In the case of the system receives a SYN packet, the Hash Calculator module calculates a hash value to retrieve a flag in the Valid SYN Records module If the flag is set, means that the SYN packet comes from an authenticated client, the SYN packet is by- passed to the destination and the flag is clear Otherwise, if the flag is not set, the SYN Cookie Generator module yields a SYN/ACK packet with a special sequence number base on SYN packet information to identify the client Packet fields are used to generate the sequence number includingMaximum Segment Size (MSS), Source IP Address (Src IP), Destination IP Address (Dst IP), TCP Source Port (Src Port), and TCP Destination Port (Dst Port) The generated SYN/ACK packet is sent back to the client immediately without saving any information about this client in this system When the client sends a ACK packet to the system, a client can be authenticated to legal or not based on the value of ACK number of the incoming packet In the case the client is authenticated successfully, a flat is set and stored in the Valid SYN Records module to marks that the pair of this client and server is legal After that, the system also sends a RESET packet to the client to force the client to reconnect to the server Since the flag is set already, the SYN packet of this connection time is forwarded to the host to perform athree way handshakingnormally.

Hardware resources usage

Hash(SrcIP, DstIP) Lookup SYN Records SYN Cookie Generator S2

Validate S2 Hash(SrcIP, DstIP) Update SYN Records RESET

Figure 4.4: The SYN Defender operation

As stated above, we use FPGA technology to quickly develop the prototype switch.

Therefore, the proposed architecture with two DDoS countermeasure mechanisms is built in a single FPGA chip Hence, all the inter-components, as well as intra-component interconnects are implemented as on-chip point-to-point and bus-based interconnects The point-to-point interconnect is very suitable for FPGA implementation because FPGA includes many wires for interconnect.

Moreover, the most advantage of the point-to-point interconnect is high performance because there is no any competition for communication through the point-to-point interconnect Meanwhile, the bus-based interconnect is low la- tency and area efficiency However, bus-based interconnect suffers from low overall communication performance.

We use embedded on-chip memory (Block RAM - BRAM) to buildFlow Table, Register Table in Port Ingress/Egress filtering secured core, and both IP Address RecordsandHop-Count Recordsin the Hop-Count Filtering secured core BRAM allows memory accessed to be done within exactly one cycle so that system performance can be improved because of frequently Flow Table accessing However, BRAM still comprises a disadvantage that is the limitation of usable resources To overcome this disadvantage, the external memory chip can be used for the prototype of the next version We use Verilog-HDL to develop modules in the switch.

The full system is synthesized with Xilinx ISE 13.4 without any manual optimiza- tion.

Because of the limitation of hardware resource, we separate secured cores

Summary

Table 4.2: The hardware resource utilization of the system

Frequency 57.634M H z 79.675M H z 73.292M H z implementation into two scenarios The first scenario deploys two secured cores including Hop-Count Filtering and Port Ingress/Egress Filtering The second scenario is combination of Port Ingress/Egress Filtering and SYN Defender core.

Table4.2summarizes hardware resources usage and synthesis frequency of two implementation scenarios and a comparing with original implementation [Yabe, Yabe] without security function Due to the fact that we use BRAM to implement Flow Table in OpenFlow Processing, IP Address Records and Hop-Count Records in the Hop-Count Filtering core, Valid SYN Records of the SYN Defender core, and Register Table in the Port Ingress/Egress core, the switch consumes much more BRAM resource than other types The first prototype version of our switch can work at up to 79.675MHz AppendixApresents the simulation waveform to process first packet incoming the system in each implementation scenario.

In this section, we present our prototype version of the proposed OpenFlow switch architecture The prototype version is integrated with two well-known DDoS protection mechanisms, the Hop-count filtering and the Port Ingress/Egress filtering mechanisms We build the prototype version on a Xilinx Virtex 5 xc5vtx240tFPGA device The two DDoS protection mechanisms and all the rest modules are developed by using Verilog HDL Synthesis results show that our prototype switch can function at≈80MHz Currently, we only use up to 39% and 41% logic elements resource to implement the first scenario and the second scenario respectively In both cases, the resource utilization is less than the original implementation in which the OpenFlow switch has not security function Therefore,there are more available hardware resources to build more security functions.

T HE O PEN F LOW - BASED N ETWORK

As stated about, forwarding devices in the data plane of an OpenFlow network need to be associated with a controller running on a host to handle these devices In this work, to control the prototype switch implemented in the previous section, a controller needs to be built to test the switch However, instead of building a simple controller to validate the proposed switch, we aim to develop a framework so that researcher can implement a more powerful tool with many functionalities as their desires In this chapter, we present our OpenFlow-basedNetwork Framework.

The architecture of the framework

The graphic user interface layer

The primary purpose of this layer is to give users/researchers a friendly interface to interacting with the proposed switch Users can use the functions from the GUI to retrieve statistics of OpenFlow network such as throughput or current

5.1.THE ARCHITECTURE OF THE FRAMEWORK 35

APIs Flow Control Interface Other Control

Figure 5.1: The architecture of the proposed OpenFlow-based Network Framework status of forwarding devices Moreover, this GUI also shows statistics of attacked packets dropped by the implemented secure cores The GUI also allows users to get the Flow Table statistic of a switch for monitoring the status of a system.

Beside those presented functions, as stated above, we aim to provide a flexible framework that allows users/researchers to develop their owned management tool with different functionality Therefore, this GUI can be considered as an example application so that user can be familiar with using provided API to build such applications In both the cases, the GUI calls these API functions offered by SDK to communicate with a forwarding device at the hardware level for collecting the statistic information or controlling required behaviours.

The software development layer (SDK)

As aforementioned, we aim to not only provide users/researchers with a dedicated tool to test or operate the proposed OpenFlow switch for an OpenFlow network under a set of predefined behaviours but also provide them with a number of API to communicate to hardware device viaPlugins Therefore, users/researcher can develop or customize their owned applications with different GUIs.

Moreover, our ultimate goal is to allow developed friendly controllers to be used for academic to research OpenFlow-based switches Therefore, in our frame-

5.1.THE ARCHITECTURE OF THE FRAMEWORK 36 work, we design the SDK layer that consists of a set of API functions for building multi-purposes controllers.

This set of API functions is available for the higher level layer, the GUI layer, so that they can be called by application layer (GUIs) The set of API functions directly interacts and handle switches through device handler at the Plugins layer.

Whenever there is a new switch is installed into the system, the switch can be accessed via the API functions of SDK through the functions offered by the Plugins.

Table 5.1 presents some simple example API functions that the SDK in our framework provides:

Table 5.1: List of some APIs of SDK

Functions Sort description int sdkDeviceScan(); Scan NetFPGA device int sdkDeviceOpen(int DeviceId); Open NetFPGA via DeviceId int sdkDeviceClose(int DeviceId); Close NetFPGA via DeviceId int sdkDeviceGetStatus(int DeviceId, DeviceStatus* pDevStatus); Get device status int sdkDeviceClearCounter(int DeviceId, int CounterId); Clear device status

The functionsdkDeviceGetStatus()offers entrance for getting the status of a Open- Flow switch by given it the DeviceId associated with the switch This function return the statistic via a data structure namedDeviceStatus Listing5.1describes detail ofDeviceStatusdata structure. typedef struct 1

3 // Get the statistic of NIC

5 // Return the bandwith of NIC

7 // Count the number of flow entry in FlowTable

10 // Total packet in Security Processing

12 // Total packet was dropped by Secured Processing u_int32_t sec_pkts_drop ; 13

14 // Total packet dropped by Hop - Count filter

15 u_int32_t sec_pkts_drop_hc ;

16 // Total packet dropped by Port Ingress / Edgress filter

17 u_int32_t sec_pkts_drop_ie ;

19 // Count the hit times of exact matching rules u_int32_t ofs_exact_hits ; 20

21 // Count the miss times of exact matching rules u_int32_t ofs_exact_miss ; 22

23 // Count the hit times of wildcard rules

25 // Count the miss times of wildcard rules

Listing 5.1: Structure of Device Status

The plugin layer

The Plugins layer manages several forwarding devices (device handlers) that allow those devices to be accessed and handled Plugins layer accesses directly to device driver of the Operation System (OS) to interactive with hardware device.

The Plugins manages these installed forwarding device in an array and mapping the device handle to a index calledDeviceId By transferring the DeviceId to the

Plugins, SDK can access to corresponding hardware device accurately Plugins can offer more abstract level to make it easier to understand All complexity system called is wrapped by this layer so that programmers just call the functions for their purposes such as getting device statistic, updating Flow Table inside forwarding devices or collecting other status information provided by hardware device to show at the GUI layer However, in this first released framework, we only support the NetFPGA-10 platform due to the limitation in developing time.

Listing5.2shows some of major functions for higher layer accessing. int SecureOFS_Plugin :: readReg ( int DeviceId , uint32_t addr , uint32_t * 1 val)

4 if ( m_devList [ DeviceId ] reg_rd (addr , &v)== NF10_DEV_RET_OK )

*val = v; return PLUGIN_RET_OK ; 7

11 12 int SecureOFS_Plugin :: writeReg ( int DeviceId , uint32_t addr , uint32_t val)

13 { if ( m_devList [ DeviceId ] reg_wr (addr , val)== NF10_DEV_RET_OK ) return 14 PLUGIN_RET_OK ;

17 18 int SecureOFS_Plugin :: openDevice ( int DeviceId , const char * dev_name )

20 if ( m_devList [ DeviceId ] dev_open ( dev_name )== NF10_DEV_RET_OK ) return

23 24 int SecureOFS_Plugin :: closeDevice ( int DeviceId )

25 { if ( m_devList [ DeviceId ] dev_close () == NF10_DEV_RET_OK ) return 26 PLUGIN_RET_OK ;

31 { int count = 0; 32 for ( int i=0;i< MAX_DEVICES_NUM ;i++) 33

34 { if ( m_devList [i] dev_open (( const char *) "/ dev/ nf10 ") != 35

NF10_DEV_RET_OK ) break ;

Listing 5.2: Some sample functions of Plugins

Framework implementation

Base on the NOX Controller [NOX,2015], we implement a framework follow our design as describing The proposed framework can be deployed on multiple platforms such as Linux or Window systems Therefore, the proposed framework needs to be a cross-platform framework The framework is developed using QT5.7 Integrated Development Environment (IDE) [QT,2016], an open source IDE; that is suitable for working on both Window or Linux systems Figure5.2 illustrate our first released framework.

Figure 5.2: The first released OpenFlow-based Network Framework

Summary

In this chapter, we introduce our OpenFlow-based Network Framework to allow users/researchers to develop their owned controllers quickly The proposed framework consists of three different layers the GUI layer, the SDK layer, and the plugin layer With the three layers architecture, the framework is suitable and easy for expanding the application as well as handling errors while developing.

The proposed framework is implemented with the QT5.7 environment so that it can work with multiple platforms.

In this chapter, we present our experiments with the prototype switch using the proposed architecture in an FPGA device The experiments are conducted to validate and estimate system performance The proposed framework is also validated by associating with the NOX controller to control and monitor the proposed switch.

Experimental setup

To validate the proposed switch we need to prove the system works not only as an OpenFlow forwarding device but also as a security device We employ two NetFPGA-10GNetFPGA[2014] boards to build a testing system.

• The first NetFPGA-10G board is used as our proposed secured OpenFlow- based switch including four data ports using SFP+ (Small Form-Factor Plug- gable) interface The PCI Express connector of the board functions as control ports (Control InPort and Control OutPort) to communicate with associated controller software running on a host.

• The second NetFPGA-10G board is configured as aTest Agentin which we port the Generator and Monitor cores of the Open Source Network Test (OSNT)OSNT [2016] framework The Generator is used to generate not only legitimate packets but also attacking packets at the line rate (≈10Gbp- s/port) to send data packets to input ports of the proposed secured switch.

Experiment Results

Figure6.1illustrates our testing model The model comprises three hosts named PC1, PC2 and PC3 Detail responsibility of each hosts as following.

• PC1: working as a test agent which is running OSNT Generator and Mon- itor application There is a NetFPGA-10G board was installed and loaded the OSNT core.

• PC2: working as proposed switch It communicates to NOX OpenFlow controller via ETH0 port This host has plugged another NetFPGA-10G board in which secured OpenFlow switch core was loaded This host also runs the proposed framework to control and monitor the status of the switch from the hardware level.

• PC3: working as OpenFlow controller We install the NOX controller to PC3 to control the secured OpenFlow switch in PC2 viaETH0port.

Figure6.2presents the detail of the connections between secured OpenFlow switch with Test Agent As configured on the switch via controller tool, all legitimate packets are going to be switched to one of three output ports of the switch fromSFP+Port0-Out toSFP+Port3-Out depending on actions in FlowTable that is handled by the controller.

In our experiments, we conduct several test cases with different packets in term of size, header, and payload data We measure and calculate the interval to process thefirst-packet coming from a specific source and the switching time of non-first-packet to validate the OpenFlow operation of the proposed switch.

When the first packet coming from a specific source, the matching fields of this packet does not match any exact matching entry in Flow Table According to the OpenFlow protocol, the switch needs to forward this packet to the associated controller In this case, a wildcard matching entry is hit, and the packet is forward to the controller via PCIe interface We also collect data from the report of OSNT Monitor software in which all packets are classified to check the accuracy of the security function of the secured cores such as detection rate, false positive rate, and false negative rate Finally, we use several packet sizes to evaluate overall throughput of the proposed switch.

In performance evaluation experiments, the sizes of generated packets belong to one of six types 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes, and

Figure 6.1: The testing model of proposed switch

1500 bytes The range from 64 bytes to 1500 bytes is valid for an Ethernet packet.

We use these packets to test the OpenFlow protocol function of the switch in both half-duplex and full-duplex modes The results of performance evaluation experiments are shown in Figure6.3 In this chart, the horizontal axis indicates the

Packet sizeinbyteswhile the vertical axis showsThroughput (in Gbps) for each packet type In each type of packet, the first column presents OSNT packet generator speed The second column shows system throughput in half-duplex mode.

Finally, the last column depicts throughput in full-duplex mode According to these experimental results, our first prototype system can achieve throughput by up to 9.87 Gbps in half-duplex mode and up to 19.74 Gbps in full-duplex mode.

In the switching time experiments, each frame in a packet (a packet is di-

OSNT User Interface Receiving packets Sending packets

SFP+ Port3-In SFP+ Port2-In SFP+ Port1-In SFP+ Port0-In

SFP+ Port3-Out SFP+ Port2-Out SFP+ Port1-Out SFP+ Port0-Out

SFP+ Port3-In PCI Express

Figure 6.2: Connection of proposed switch and test agent vided into many fixed-size frame - 32 bytes frame size) requires 16 cycles to be processed Therefore, total forwarding time for a packet depends on the packet size Table6.1presents processing time for each packet type A 64-byte packet consumes 0.2048às while a 1500-byte packet requires 0.4928às to be processed.

The proposed secured OpenFlow switch is also validated in the case of the first packet coming from a particular source arriving the switch The first packet of flow must be sent to the controller for checking and writing a rule corresponding the setting of an administrator Therefore, first packet processing takes more long time and depends on the status of the controller In our testing model, in the case of the controller is running on the same host (PC2), it takes 491.15às and 466.42às to forward the 64-byte and the 1500-byte first packet respectively to the controller and then the controller update the rule into the Flow Table Otherwise, if the controller is running on PC3, 1500-byte first packet is delayed 898.02às.

Table 6.1: First packet processing timing of proposed switch in the first scenario

Packet Size Forwarding Time 1 st Packet Delay 1 st Packet Delay

(bytes) (às) Loopback Controller (às) LAN Controller (às)

OSNT Generator Half-duplex Full-duplex

Figure 6.3: Performance testing of the proposed switch

Finally, we conduct multiple tests to verify DDoS protection ability of the switch Table 6.2 shows detection rates, false positive rates, and false negative rates according to the packet sizes Detection rates, false negative rates, and false positive rates are almost stable when the sizes of packets are changed According to the table, the switch can recognize all attacking packets although a 0% false negative rate (legitimate packets are classified as attacking packets) occurs during the test.

Table 6.2: Detection rate of the proposed switch(in %)

Type 64 (bytes) 128 (bytes) 256 (bytes) 512 (bytes) 1024 (bytes) 1500 (bytes)

In spite of Zero-False Positive rate, the proposed switch still yields a small dropped packet rateso that the system dropped several legitimate packets How- ever, this issue does not come from the wrong classification of the Security Pro- cessing but the limitation of the FIFO in each data port Table6.2 presents the number of dropped packet corresponding to the packet size in the full speed op-

Summary

Table 6.3: Dropped packet rate of the proposed switch(in %)

Packet Size Send Pkts No Send Speed Recevie Pkts No Dropped Pkts No Dropped

(bytes) (packet) (Gbps) (packet) (packet) (%)

In the second scenario, the SYN Defender core can prevent the SYN flooding packet up to 4.0 Gbps In the case of attack packet rate exceeds this threshold, flow of attacking packets reach the controller and force the controller to forward them to the destination host This is a major limitation of the system How- ever, the problem isn’t caused by the logic design but the implementation tool.

The experimental result shows that the system still works normally at the slow speed Thus, this issue can be solved by applying manual optimize in thePlace and Routeprocedure of the synthesis tool.

In this chapter, we present our experiment results with the prototype OpenFlow switch The switch can function as a forwarding device in an OpenFlow network as well as a network security system to protect the network from forwarding devices Experimental results show that our proposed switch can achieve throughput by up to 9.869 Gbps in half-duplex mode and up to 19.738 Gbps in full-duplex mode with the very smalldropped packet rate (0.001%) in the case of combination the Hop-Count filtering and the Port Ingress/Egress filtering In the scenario of SYN Defender security core, the switch can only prevent SYN flood attacking at 4.0 Gbps from the system.

In this thesis, we address the challenges of integrating security functions into an OpenFlow switch to protect the network at forwarding devices level In this chapter, we summarise our contribution in this thesis We also introduce some open issues for future research in this topic.

Summary

The work in this thesis is divided into the following chapters:

In Chapter1, we introduce an overview of the challenges that we address in this thesis Three different research questions are presented in this chapter, in addition to a list of our contributions.

Chapter2gives an overview of the SDN as well as FPGA technology A survey of OpenFlow switch with integrated security functions is also presented Finally, an overview of the NetFPGA-10G board, which we use to implement our first prototype OpenFlow switch, is introduced in this chapter

Chapter3presents our proposed OpenFlow switch with integrated security functions We explain, in detail, the purpose of each component and how the OpenFlow protocol can cooperate with security mechanisms to process incoming network packets The proposed architecture can be implemented using many reconfigurable hardware technologies and families.

Chpater 4 shows our first prototype OpenFlow switch using the NetFPGA- 10G board The board includes one Xilinx Virtex-5 xc5vtx240t device This chapter also gives hardware resources usage information for the switch Although we

Contributions

build the first prototype switch using the Virtex-5 FPGA device, the architecture and the implementation can be synthesized and ported into different FPGA families and technologies because we use hardware description language to build the switch.

We introduce our framework in Chapter5 The main purpose of the framework is to used to control and test the switch It also shows network attacking statistic for research and management purpose.

We deploy many test cases to validate both the OpenFlow-based switching mechanisms as well as network security ability of the switch The experimental results are shown in Chapter6 This chapter also analyses the switch throughput and the accuracy of security functions.

Based on the three research questions defined in Chapter 1, we do research on this topic and have four different contributions The individual contributions are summarized as follows.

Contribution 1 We propose an OpenFlow switch architecture with integrated hardware-based security functions.

To the best of our knowledge, this is the first OpenFlow switch that not only can route network packets according to the OpenFlow protocol but also can defend against network attacks The proposed architecture separate the OpenFlow processing part from security processing part This approach allows different security functions to be deployed for different systems and purposes.

Contribution 2 We demonstrate our proposed OpenFlow switch using FPGA technology to verify the benefit of the proposed architecture.

Our prototype secured OpenFlow-based switch using the NetFPGA-10G board which is integrated two different DDoS defense mechanisms, the Hop-Count Fil- tering and the Port Ingress/Egress Filtering The switch prototype can work at up to≈80 MHz and achieve a 100% detection rate This prototype version can be a baseline system to compare other similar systems in future work.

Contribution 3 We propose and implement a framework to allow users/researchers to control and monitor the forwarding devices in an OpenFlow network.

Future work

Architecture open issues

In Chapter3, we presented the OpenFlow-based switch architecture for forwarding devices protection only The first open issue is to study and propose switch architectures that can protect the network at different levels such as the whole data plane, the controller, and the application layers It means that a network security device can be combined secure functions from hardware level, firmware level or software level Such the switch architectures can provide much more security protection ability than our switch.

The second open issue is to have an extended version of the proposed switch so that multiple engine components can work together to process incoming packets Although our proposed switch can function at a throughput by up to 19.74Gbps in full duplex mode, this throughput maybe is not sufficient enough for ultra-high-speed networks Therefore, future research should take parallel processing at the engine components into consideration.

Prototype switch open issues

In Chapter4, we presented our first prototype switch based on the proposed architecture The prototype version is implemented on a Virtex 5 FPGA device in the NetFPGA-10G framework One of the modern technology this FPGA family supports is dynamic reconfiguration Therefore, the next version of the switch should apply the technique to adapt and change the security functions on-the-fly quickly Due to the fact the DDoS attacks and other attack types can be deployed

7.3.FUTURE WORK 49 using different techniques and quickly changed, runtime immediately dynamic update ability is one of the essential demands for hardware-based security systems.

The second open issue for the next generation switch based on our architecture is to build the Packet FIFO and Flow Table on a larger memory system.

Currently, we are using on-chip BlockRAM to form the Packet FIFO as well as theFlow Table However, the amount of on-chip memory is so limited that the size ofFlow Table and Packet FIFO is not very sufficient Hence, the next version of the switch should take this open issue into account However, the most challenge issue with off-chip memory is the accessing time.

First packet processing waveform of the first scenario

A.1 F IRST PACKET PROCESSING WAVEFORM OF THE FIRST SCE -

Figure A.1: First packet processing waveform of the first scenario: HCF & PIEF

First packet processing waveform of the second scenario

A.2 F IRST PACKET PROCESSING WAVEFORM OF THE SECOND

Figure A.2: First packet processing waveform of the second scenario: PIEF & SYN Defender

Secured-OFS: A Novel OpenFlow Switch Architecture with Inte-

TURE WITH I NTEGRATED S ECURITY F UNCTIONS

• Paper name: Secured-OFS: A Novel OpenFlow Switch Architecture with Integrated Security Functions

• Authors: Bao Ho, Quoc Nguyen, Cuong Pham-Quoc and Tran Ngoc Thinh

• Conference: The Advanced of International Conference on Advances in Information and Communication Technology (ICTA2016)

Secured-OFS: A Novel OpenFlow Switch Architecture with Integrated Security Functions

Bao Ho ( B), Quoc Nguyen, Cuong Pham-Quoc, and Tran Ngoc Thinh

Ho Chi Minh City University of Technology, Vietnam National University - HCMC,

Ho Chi Minh City, Vietnam {7140219,51102795,cuongpham,tnthinh}@hcmut.edu.vn

Abstract Although OpenFlow network protocol is a promising network approach with many advantages compared to traditional network approaches, it still suﬀers from network attacks In this paper, we propose a novel architecture for an OpenFlow-based switch with associated multiple network security techniques, so-called Secured-OFS The proposed Secured-OFS can not only function as a switch following the OpenFlow protocol but also help protect a network against many attack types.

We implement the first FPGA-based prototype version of our proposed Secured-OFS using a Xilinx Virtex 5 xc5vtx240t device In this first prototype version, we integrate two different DDoS defense techniques, Hop-Count Filtering and Port Ingress/Egress Filtering The experimental results show that the switch not only fulfills the OpenFlow protocol but also be able to defense against DDoS attacks The system achieves a maximum throughput at 19.729 Gbps while a 100 % DDoS attack detection rate is obtained AQ1

Keywords: Software deﬁned networking ã OpenFlow network ã Net- work security

In the last decades, SDN [1] has been considered as a promising paradigm to manage and configure computer networks through a high-level abstraction Com- pared to the traditional approach where computer networks are configured man- ually, the SDN approach has many benefits such as centralization control and monitoring, simple hardware devices, and high virtualization The SDN architecture decouples network control from forwarding functions so that network control becomes programmable The network control includes controllers programmed by network administrators through software interfaces Each controller is responsible for handling several forwarding devices behaving forwarding functions Those forwarding devices route network packets from a source node to a particular destination node according to network configuration.

As the most well-known instance of SDN, OpenFlow [2] is not only a quite popular implementation in academia but also an industry standard of SDN [3]. c Springer International Publishing AG 2017 M Akagi et al (eds.), Advances in Information and Communication Technology, Advances in Intelligent Systems and Computing 538, DOI 10.1007/978-3-319-49073-1 57

Based on the architecture of SDN, the OpenFlow network architecture also decouples network control function from the forwarding functions Therefore, the OpenFlow network takes all the advantages of the SDN paradigm More- over, by optimizing elements such as controllers and forwarding devices, the OpenFlow network can be implemented as a software program or used as hardware platforms.

However, many security issues exist in both the SDN and OpenFlow network architectures Research in [4] presents seven diﬀerent threats in a SDN network which attackers can exploit to attack the network OpenFlow networks also have some security threats that should be considered carefully In the literature, there are some proposals to defend against possible attacks [5–7] However, these approaches are only deployed as software programs Moreover, research in the literature mainly focuses on optimizing controllers in OpenFlow networks [8,9].

There are still many open issues with forwarding devices With the rapid progress in network services and network speed, high-performance and secure forwarding devices in OpenFlows networks is an essential demand.

With the fast increasing in the number of network attacks, hardware-based network defense plays an important role of a successful cyber-security strategy In this paper, we propose a Secured-OpenFlow switch (Secured-OFS) with associated security functions These Secured-OFSes can operate as forwarding devices in OpenFlow networks We implement the ﬁrst prototype version of Secured-OFS on the NetFGPA-10G [10] board which contains a Xilinx Virtex 5 xc5vtx240t FPGA device The experimental results show that the system achieves high accuracy forwarding with nearly 100 % while the detection rate reaches to 100 % for two cases of IP Spooﬁng Besides, the forwarding services time is 0.36às and 9.36às for the minimum and maximum packet respectively That leads to the performance of total system reaching 9.859 Gbps in half-duplex and 19.718 Gbps in full-duplex mode The main contributions of our paper can be summarized as follow.

– We propose a Secured-OFS with integrated security functions To the best of our knowledge, this is the ﬁrst OpenFlow switch that can not only route network packets according to the OpenFlow protocol but also defend against network attacks.

– We present our first prototype Secured-OFS using the NetFPGA-10G board which integrates two different DDoS defense mechanisms including Hop-Count Filtering and Port Ingress/Egress Filtering The first prototype can work at up to 108.711 MHz and achieves a 99.1 % detection rate.

The rest of the paper is organized as follow Section2 presents the proposed architecture of Secured-OFS Section3 introduces our FPGA-based ﬁrst prototype version of the proposed Secured-OFS We analyze our experiments in Sect.4 Finally, Sect.5 concludes the paper and introduces future work.

Secured-OFS: A Novel OpenFlow Switch Architecture 3

In this section, we present our proposed Secured-OFS architecture Our Secured- OFS can not only operate as an OpenFlow protocol-based switch but also a security device to defense against network attacks.

Figure1 illustrates our proposed Secured-OFS architecture The proposed Secured-OFS consists of three diﬀerent components named Ingress, Egress, and Engine The Ingress component is responsible for receiving incoming packets from input ports and forwarding to the Engine component for processing Finally, those packets are routed to corresponding output ports of the Egress component.

The Ingress component includes one input queue, multiple data input ports (InPort i), and one control input port (S2C-InPort) All incoming packets from these input ports are collected and stored into buffers Input Queue sequentially selects a packet from the buffer and forwards to the Engine component for processing Input Queue can be configured on the fly so that packets from buffers are selected based on a specific strategy such as Round Robin or input port priorities Configuration data is sent to Input Queue through the S2C-InPort.

S2C-InPort is the means of communication between a controller and the Secured-OFS In other words, the corresponding controller sends conﬁguration data through this port to handle the Secured-OFS according to the OpenFlow protocol Compared to data input ports, this S2C-InPort has a higher priority, i.e., Input Queue selects packets coming from this port to send to the Engine component whenever there is any existence packet in the buﬀer of S2C-InPort regardless strategies used to select packets at Input Queue.

In contrast to the Ingress component, Egress consists of an output queue, several data output ports (OutPort i), and one control output port (S2C-OutPort).

A packet after being processed by the Engine component is forwarded to the Output Queue Regarding to routing information of the packet, Output Queue

First packet processing waveform of the first scenario: HCF & PIEF 56

A.1 F IRST PACKET PROCESSING WAVEFORM OF THE FIRST SCE -

Figure A.1: First packet processing waveform of the first scenario: HCF & PIEF

First packet processing waveform of the second scenario: PIEF &

A.2 F IRST PACKET PROCESSING WAVEFORM OF THE SECOND

Figure A.2: First packet processing waveform of the second scenario: PIEF & SYN Defender

B.1 S ECURED -OFS: A N OVEL O PEN F LOW S WITCH A RCHITEC -