Automated Controller Placement for Software-Defined Networks to Resist DDoS Attacks

: In software-defined networks (SDNs), controller placement is a critical factor in the design and planning for the future Internet of Things (IoT), telecommunication, and satellite communication systems. Existing research has concentrated largely on factors such as reliability, latency, controller capacity, propagation delay, and energy consumption. However, the model is useful in planning for SDN reliability in the presence of DDoS attacks while managing the overall cost.


Introduction
Software-defined networking (SDN) has gained prominence around the world because it is a programmable [1], cost-effective, agile, and centralized networking architecture compared to traditional systems that are more complicated and difficult to manage. The core of the SDN architecture is the primary controller that mediates between clients and resources to deliver services [2,3]. A generic depiction of the structure with connections between switches and primary controllers is shown in Fig. 1, with packets traveling from laptop A to laptop B. For example, a packet from laptop A will travel through OpenFlow switch 1 if the packet matches the predetermined flow table in switch 1 and, subsequently, through OpenFlow switches 2 and 3 until it reaches laptop B (route 4).  [4] However, if the packet does not match the flow table at switch 1, the switch will then trigger the centralized primary controller (route 2) to update the flow table of that switch (route 3 in the figure). The same operational processes will be applied to the other OpenFlow switches 2 and 3.
The shortcoming of this structure is that the centralized primary controller is vulnerable to an attacker generating spoofed packets to infiltrate the primary controller. These hoax packets then spread to the other switches during flow table updates. This vicious cycle continues until the operation of the network comes to a halt, interrupting service as a result. Among all attacks, distributed denial of service (DDoS) attacks are among the most serious, generating huge amounts of artificial traffic to the SDN primary controller [5] and hampering its ability to provide services to legitimate clients. In OpenFlow [6], a switch requests new flow rules [7] from the primary controller if the switch experiences difficulty in forwarding data. The primary controller has the processing capability and responsibility for directing the flow of data packets. By sending massive numbers of spoofed packets not found in current flow tables, the DDoS attacker can overload the primary controller, which is unable to cope with the sudden influx of excessive fake packets, resulting in primary controller malfunction [8].
If the primary controller becomes the victim of a DDoS attack, all switches connected to that primary controller will malfunction and disrupt SDN services for legitimate users. Thus, DDoS attacks are serious threats for SDNs. Hence, we propose using multiple backup primary controllers to provide uninterrupted services for primary controllers under DDoS attack.
Network availability is a key quality indicator of network planning design and planning [9]. Tab. 1 lists various availability requirements based on the priority of services demanded by clients. Military defense systems have the most stringent requirements among many network applications, requiring 99.9999% network availability, corresponding to a maximum of 31.5 s of downtime per year. Carrier-grade telephony, health, and banking systems are also demanding, requiring 99.999% availability, or a maximum outage time of 5 min and 15 s per year. Datacenters and high-end business systems require 99.99% uptime, allowing up to 52 min and 33 s of downtime per year. Currently, there is no single SDN primary controller that can provide adequate delivery security, reliability, and resiliency simultaneously [10][11][12][13]. Datacenters or high-end business system 99.99 52 min 33 s SDN frameworks encounter many security threats, such as unauthorized primary controller access [14], corrupted or poisoned flow rules and forwarding policy discovery, primary controller-switch communication floods, and the DDoS-based switch flow table floods mentioned already [15]. The financial services industry was the third-most targeted industry by DDoS attacks in Q2 2019, as shown in Fig. 2 with gaming and high tech the best-known targets.  [16] Worse, the frequency of DDoS attacks has been increasing dramatically as shown in Fig. 3 [17], with 58.3% of networks having been attacked more than once, 34.0% suffering 25 attacks, 11.2% encountering 6-10 attacks, and 13.1% experiencing more than 10 attacks in Q1 2017.  [18] In Q1 2019, 40% of network experienced a single attack, 34% experienced 2-5 attacks, 7% experienced 6-9 attacks, and fully 19% experienced 10 or more attacks, as shown in Fig. 4.  [19] It is alarming that one company in the gaming industry experienced 558 attacks during the second quarter of 2017. By industry, 82% of gaming, 5% internet and telecom, 4% financial services, 42% software and technology, 2% media and entertainment, 1% retail and consumer goods, and 2% of education networks were repeatedly hit by DDoS attacks throughout the year 2017.
Multiple attacks have become more frequent as shown in Fig. 5. The average number of DDoS attacks per target was 30% in Q4 of 2016 and rose to 32% in Q2 of 2017. The duration of the attack needed to break the network has also been falling noticeably, thanks to sophisticated attack tools. In Q1 2017, the longest DDoS attack lasted around 204 h, a sharp decrease from the longest attack of 700 h in Q4 2016 and 483 hours in Q3 2016 [20]. Modern attack tools are causing primary controllers to fail in a shorter time.
Others have reported as shown in Fig. 6 that coercion in the form of threatened DDoS and ransom denial of service (RDoS) attacks have been made by an attacker claiming to attack for the sake of "Lazarus," compromising the victim's network if payment was not made within six days. Once the attack began, the attacker required an installment of 30 bitcoin (approx. $1500K) to stop it, with an extra 10 bitcoin ($500K) required for every day the payment remained unpaid [21].  Thus, protecting SDN networks is turning out to be increasingly significant [22]. SDN provides rich network functions, the organization's utilization effectiveness is improved but SDNs have big security challenges simultaneously [23]: DDoS attacks, network interference, switch information spillage, and information confidentiality, along with traditional network attacks [24].
In this paper, we propose a new integer linear programming (ILP) mathematical model for planning the use of SDN smart backup controllers (SBCs) to resist DDoS attacks. The goal is to minimize the total cost of the SDN network during planning while determining the number and location of backup controllers to secure the network. We formulate the model using the occurrences and frequencies of DDoS attacks on the SDN primary controller.
We organize the rest of our paper as follows. In Section 2, we present related work. Section 3 presents our proposed smart backup controller placement mathematical model and formulation. Section 4 presents our experimental results and evaluation of the proposed model under various scenarios. We present our conclusions in Section 5.

Related Work
Before the existence of SDNs, several researchers had considered the goal of a networking system capable of fast, programmable data handling [25][26][27][28][29][30][31]. One proposal determined SDN primary controller placement using the k-median, and the k-center and their related optimization problem heuristic algorithms [32]. However, this proposal focused on the primary controller's latency, i.e., the primary controller's response time, and did not address primary controller placement with DDoS attacks. Others created a rule framework to adjust the links between the primary controller and switches based on the behavior of the primary controller placement problem [33]. Another proposal maximized the reliability of the SDN primary controllers using heuristic algorithms and brute force [34]. Others addressed the primary controller placement problem in reducing the worst latency of the control paths while satisfying the load constraints of the SDN primary controllers [35]. Without mentioning DDoS attacks, one author introduced an enhanced model for placing the SDN primary controller, switches, and links in the SDN [36]. Showing the vulnerability of SDN to DDoS attacks in cloud computing, researchers investigated the characteristics of DDoS attacks in cloud computing environments and gave a number of protective mechanisms for SDNs [37]. One proposal introduced a DDoS attack defense using a blocking system built upon the OpenFlow interface [38]. Another method used promptness, versatility, and accuracy to detect DDoS attacks [39]. For primary controller placement, one multiple-queue SDN primary controller scheduling algorithm used a time slice allocation strategy [40]. Others have used attack traffic, attack scale, and timelines to detect DDoS attacks in cloud services [41], but this method only detects attacks causing actual malfunctions and service disruptions.
pSMART is a lightweight and security-aware service function chain orchestration in network functions virtualization (NFV)/SDN situation. But it is incapable of supporting huge volumes of DDoS attack traffic [42]. Other proposed algorithms for precise and heuristic examinations which was created in the Matlab-based system for Pareto-based Optimal Controller placement [43]. However, it does not offer assistance during DDoS attacks. Other authors proposed a multiple objective ILP formulation to deduce primary controller placement, but this method does not consider security threats like DDoS attacks [44]. The Parameter Optimization Model (POM) for heuristic calculations has also been applied to controller placement problem (CPP) [45]. The heuristic algorithm adequately unravels the CPP by applying the advanced boundaries acquired in the POM, but the authors present no mechanism to protect the SDN primary controller and infrastructure. Another proposal used a hypothetical concept of smart controller placement for SDNs [46].

SDN Smart Backup Controller Placement and Problem Formulation
In this section, we introduce the problem of DDoS attack-aware controller placement using extra smart backup controllers to prevent service disruptions for legitimate users. Generally, primary controllers are connected to switches via a link, as shown in Fig. 7a.
We propose adding an extra controller, known as a smart backup controller, via a dynamic link [63], as illustrated in Fig. 7b. Our proposal activates the backup controller only when an original controller fails to function due to a DDoS attack. We build on earlier work on IP aliasing technique, which allocates multiple IP addresses to a single network interface, to create a unique dynamic switch to primary controller connection strategy [64,65]. By using this technique, the switch can statically connect to a single SDN primary controller at any given time while enabling reconnection to another primary controller dynamically and without reconfiguration [66].

Parameters
Our method uses five important parameters: • The number of primary controllers (c ∈ C) each of which may have a number of smart backup controllers (b ∈ B) based on the attack frequency DDoS η . • The maximum number of packet requests that primary controller μ c or smart backup controller μ b can handle per second; • The distance Range ab and the bandwidth ψ l /Mbps availability for each link type connected between the primary controllers and the switches; • The quantity of traffic φ s to be sent from a switch to the primary controller; and • The maximum latency for wireless ν (WirelessCom) and wired communications ν (CopperWireCom) .
We also make use of several notations in formulating our model. These are described below.

Sets of the Model
Symbol of sets of the model are listed in Tab. 2. The number of ports of the smart backup controller (b ∈ B). μ b The processing power of the smart backup controller of type (b ∈ B). γ b The processing power of the smart backup controller (b ∈ B). ρ b Different types of the available backup controller (b ∈ B) to install.
The set of primary controllers (c ∈ C) that will be installed in SDN with the property, such as port, processing power, cost, and availability. λ c The number of ports for each primary controller (c ∈ C). μ c The processing power of each primary controller (c ∈ C). γ c Cost of the primary controller (c ∈ C). ρ c Different types of available primary controller (c ∈ C) to install.
The set of switches of type (s ∈ δ) that will be connected to the primary controller. φ s The number of available packets that does not have a match in the switch's (s ∈ δ) flow table and that is sent to the installed primary controller to process. ζ = {l1, l2, l3, . . .}, The set of link types (l ∈ ζ ) that connect primary controllers and switches. ψ l /Mbps The bandwidth of the link type (l ∈ ζ ) in the byte. ω l /meter The cost of the link of type (l ∈ ζ ) based on the bandwidth type. The cost is expressed in US$ per meter. η = {n1, n2, n3, n4, n5, . . .}, The set of the given nodes where primary controllers are placed.
The set of possible attacks on the installed primary controller on a node (n ∈ η). The defined frequency of DDoS attacks ranges from 0 to 3 where 0 represents no attack, increasing to 3 for high frequency of attack. The model generates more smart backup controllers in the following scenarios: i) Network operations that require high availability such as military, health care, banking, and datacenters. ii) Those nodes that experience a higher-frequency of attack.

Constants
Several constants are used by our model. These are listed in Tab. 3.

Decision Variables of the SDN Model Under DDoS Attack
Several variables control the decisions made by our model. These are listed in Tab. 4. Packet size in bytes to be processed by a primary controller type of (c ∈ C) or a smart backup controller type of (b ∈ B). ξ Speed of light to calculate the latency in wireless communication.

Range ab
The range between two points a and b, expressing the distance between either two primary controllers or switches to the primary controller or backup controller to primary controller. π Function to convert the data packet size from Mbps or Gbps to the bytes. κ c and b Processing time for the primary and smart backup controllers. ν (WirelessCom) Maximum allowable latency using wireless communication.
Maximum allowable latency using copper wire communication. 1, if a backup controller of type (b ∈ B) is installed at node (n ∈ η), else 0. Z l sn : 1, if a link of type (l ∈ ζ ) is connected between switches type of (s ∈ δ) and primary controller installed on the node (n ∈ η), else 0. R l nm : 1, if a primary controller location (n ∈ η) is connected to a primary controller location (m ∈ η) with a link type (l ∈ ζ ), else 0. R l cb 1, if a primary controller (c ∈ C) is connected to the smart backup controller (b ∈ B) with a link type (l ∈ ζ ), else 0.

Cost Functions
The objective of this mathematical model is to minimize the total cost of an SDN under DDoS attack. Cost depends on the number and types of primary controllers (Cost c (T c )) installed in SDN; the smart backup controller placement with respect to the number and frequency of DDoS attacks (Cost b (T b )); and the type of links between primary controllers (Cost ζ (R)) between switches and primary controller (Cost ζ (Z)) and Cost ζ (R b ) and between primary and smart backup controllers.
Cost ζ (Z) = Range nb R l cb .

The SDN Model
The number of required smart backup controllers depends on the network availability requirements and the probabilities of the frequency of DDoS attacks on the SDN primary controller. We model our planning method as follows.
Objective Function : This constraint places single or multiple smart backup controllers based on the frequency of DDoS attacks.
One link from the primary controller to the smart backup controller provides communication during DDoS attacks.
The latency of the smart backup controller depends on whether wireless or wired communication is used. Latency also varies for the distance between nodes in the SDN. The maximum latency of the smart backup controller must be smaller than the required latency. To calculate the latency, we multiply the one-way latency by 2 to obtain the round-trip distance and packet size of the data packet from a switch to the smart backup controller and the smart backup controller to a switch. The maximum latency of the smart backup controller must be smaller than the required latency.
The number of smart backup controller placements cannot be more than the number of smart backup controllers in inventory.
This constraint checks the availability of backup controllers before placing them.
Only one primary controller will be installed in each node to optimize the total SDN cost.
l∈ζ n∈η Each primary controller is connected to a switch with only one link.
A fully connected network or complete topology will be the topology for this SDN, depending on the decision of the SDN planner.
This constraint ensures that the number of switches and primary controllers does not exceed the available ports on the primary controller.
The following constraint ensures that the number of switches and backup controllers does not exceed the available ports of the smart backup controller The bandwidth of the link must be sufficient to carry the traffic between the switch and primary controller. This constraint converts the data packets into bytes. l∈ζ s∈δ This constraint ensures that the processing power of the primary controller can support the data from the switches.
This constraint ensures that the processing power of the smart backup controller can support the data from the switches.
The values used in the computation are listed in Tabs. 5-8. The costs of the primary controllers, smart backup controllers, and bandwidth are hypothetical averages of current prices due to variations across providers.

Experimental Result and Evaluation
We implemented our proposed model using AMPL (A Mathematical Programming Language) [67] and IBM ILOG CPLEX [68]. Our test hardware was a system with an Intel Core i7-6700 CPU at 3.40 GHz, 8 GB of RAM, and virtual memory 128 GB machine, we created 128 GB storage of hard disk as artificial RAM. We evaluated our proposed model in several different scenarios for both of its major functions: Planning primary controller and node placement in view of anticipated traffic and determining smart backup controller placement to resist various levels of DDoS attacks.

SDN Primary Controller Placement Without DDoS Attack
Tab. 9 presents a summary of the node and primary controller placement results of our model for five representative scenarios. In Scenario 1, the input node (Gη) was 9 (9 primary controllers deployed at 9 nodes). Our model proposed 2 nodes (η) with 2 primary controllers (C), 5 switches (δ), and 6 links (ζ ). This result saved 7 primary controllers and 7 nodes in total. The total available data packets per second were 12,600, within the abilities of 2 primary controllers.
In Scenario 2, the input node (Gη) value was 30 (30 primary controllers deployed at 30 nodes). Our model proposed 2 nodes (η) with 2 primary controllers (C), 5 switches (δ), and 11 links (ζ ). This result saved 29 primary controllers and 28 nodes in total. The total available data packets per second were 27,000. CPLEX took 7.8 s to reach this result.
In Scenario 4, the input node (Gη) value was 100 (100 primary controllers deployed at 100 nodes). Our model proposed 2 nodes (η) with 2 primary controllers (C), 5 switches (δ), and 6 links (ζ ). This result saved 98 primary controllers and 98 nodes in total. The total available data packets per second were 12,600. However, finding this result required 893.5 s due to the large number of inputs.
Finally, in Scenario 5, the input node (Gη) value was 7 (7 primary controllers deployed at 7 nodes). Our model proposed 4 nodes (η) with 4 primary controllers (C), 9 switches (δ), and 12 links (ζ ). This result saved 3 primary controllers and 3 nodes in total. The total available data packets per second were 29,200. Finding this result required 0.34375 s.
These results show that the total cost of an SDN depends on the capacity of each primary controller, expected volume of data packets, and the bandwidth of the links.

SDN Smart Backup Controller Placement Under Different Frequencies of DDoS Attacks
We further evaluated our proposed model in placing backup controllers to preserve services on various levels of DDoS attacks. Results for this test are given in Tab. 10 for 9 representative scenarios. In Scenario 1, our proposed model assigned no backup controllers because there was no attack on the primary controller, with a total cost of $23,950. This cost contains only the SDN setup cost.
In Scenario 2, only one smart backup controller was installed because only one DDoS attack was planned. The total cost was $25,150, representing the SDN setup with a single backup controller. Scenario 3 resulted in placing two backup controllers after detecting two planned DDoS attacks on two different primary controllers. The total cost increased to $26,350.
Scenario 4 included detection of medium (double) frequency of DDoS attacks on one primary controller. The medium attack represented two DDoS attacks on one primary controller. Our model recommended two backup controllers for uninterrupted SDN services.
In Scenario 5, our system considered two detected medium frequency DDoS attacks and recommended four different types of backup controllers, at a total cost of $31,350.
In Scenario 6, our method proposed six SBCs after detecting three medium frequencies of DDoS attacks with a total cost of $31,350. Scenario 7 introduced a high level of DDoS attacks, representing a triple DDoS attack on a single SDN primary controller. Our model recommended three backup controllers, for a total cost of $33,150.
In Scenario 8, our method recommended 6 SBCs after considering two high frequency of DDoS attacks.
Finally, in Scenario 9, our method considered three high-frequency DDoS attacks on three different SDN primary controllers. It recommended 9 SBCs, for a total cost of $51,550.
The results of these scenarios show that our model is capable of securing SDNs against DDoS attacks by using additional backup controllers in conjunction with the existing SDN controller.
The required cost to secure these networks is plotted in Fig. 8. The cost ranged from below $30,000 for no attack to around $50,000 for protecting against triple attacks. Clearly, less protection has a lower cost, and more protection has a higher cost.

Conclusions and Future Work
The purpose of our work has been to propose a model for securing a software-defined network against varying levels of DDoS attacks on its primary controller through the use of additional smart backup controllers (SBCs). We have defined our method to minimize the overall cost while providing the needed protection. Our simulation results demonstrate that our proposed model is able to counter DDoS attacks by careful placement of backup controllers and to preserve uninterrupted service for legitimate users. Our proposed model is robust and useful for planning SDNs, especially for critical applications such as military, health care, satellite, and financial services networks that require high network availability. In future work, we plan to extend our proposed model to the deployment of Next-Generation SDN (NG-SDN) and CORD hardware architecture environments. We also plan to implement our proposed model with additional parameters to support machine learning capabilities, Internet of Things (IoT) devices, UAV & EV connectivity through satellite links, cloud computing, and protect data losses.

Acknowledgement:
The authors would like to thank the editors of CMC and anonymous reviewers for their time and for reviewing this manuscript and Professor Dr. Yong-Jin Park (IEEE Life member and former Director IEEE Region 10) for his valuable comments and suggestions on improving the paper. Finally, special thanks to the LetPub editors for their great proofreading support.
Funding Statement: This research work was funded by TMR&D Sdn Bhd under project code RDTC160902.