New Detection Mechanism for Distributed Denial of Service Attacks in Software Defined Networks

New Detection Mechanism for Distributed Denial of Service Attacks in Software Defined Networks

Khalid Mohamed Hosny, Ameer El-Sayed Gouda, Ehab Rushdy Mohamed
Copyright: © 2020 |Pages: 30
DOI: 10.4018/IJSKD.2020040101
OnDemand:
(Individual Articles)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

Software defined networks (SDN) are a recently developed form for controlling network management by providing centralized control unit called the Controller. This master Controller is a great power point but at the same time it is unfortunately a failure point and a serious loophole if it is targeted and dropped by attacks. One of the most serious types of attacks is the inability to access the Controller, which is known as the distributed denial of service (DDoS) attack. This research shows how DDoS attack can deplete the resources of the Controller and proposes a lightweight mechanism, which works at the Controller and detects a DDoS attack in the early stages. The proposed mechanism can not only detect the attack, but also identify attack paths and initiate a mitigation process to provide some degree of protection to network devices immediately after the attack is detected. The proposed mechanism depends on a hybrid technique that merges between the average flow initiation rate, and the flow specification of the coming traffic to the network.
Article Preview
Top

1. Introduction

SDN provides a different approach for network design and management (Zhang & Fu, 2019). The SDN structure consists of OpenFlow enabled switches, a Controller and a secure channel between the Controller and switches. This structure facilitates network administration by isolating the data plane from control plane. This isolation process is done by restructuring the network so that the switches will receive instructions for forwarding instead of using their resources for processing the incoming packets. Switches contain tables with direction-oriented streams. OpenFlow is the protocol that coordinates the SDN structure (Ali, 2019). The nature of traditional networks is fixed, and even minor changes in network conditions will cost a high cost to reconfigure a large number of switches, routers and other network resources. As shown in Figure 1 (a), the operation of the network node in a traditional network depends on the interaction between data and control planes. The control plane is responsible for calculating the paths across the network and pushing it to the data level to enable data redirection. Therefore, after setting the flow policy in most cases, any policy changes will require changing configurations on each device. In large networks, this may mean that network operators will need to spend a lot of time routinely reconfiguring devices to adapt to changing traffic requirements and network conditions (Vani et al., 2019).

Figure 1.

Comparison between traditional networks and SDN

IJSKD.2020040101.f01

The main concept of SDN is the separation of control and data planes as shown in Fig. 1 (b). In the SDN, the control plane is no longer distributed between the nodes of the network, as in the traditional network, but instead is located in the Controller, which is connected to the network nodes to prepare the data plane through the southbound SDN protocol (Vladyko et al., 2016). OpenFlow is a standard southbound SDN protocol used to support communication between the Controller and the network nodes. Figure 2 shows the connection path between the application, control and data layers. Control level applications such as load balancing in the SDN application layer interact with the data plane level through application programming interfaces (APIs). Application and control layers are on the Controller while the distributed data layer is implemented by network devices such as routers and switches. APIs are used to implement different network services depending on the application layer requirements (QoS, access control, bandwidth management, power management, etc.) (Tang et al., 2019).

Figure 2.

SDN operational structure

IJSKD.2020040101.f02

1.1. Traffic Flow in SDN Environment

According to the Openflow description v1.5.1, the processing of the incoming packets is not a function of the switches, it is one of the basic functions of the Controller (Benabbou et al., 2019). Because the Controller acquires a complete view of the entire network, it can manage the different changes based on the traffic situation. This approach greatly simplifies the implementation of some network functions (Dang et al., 2019).

As shown in Figure 3, once the first packet reaches the switch, the flow table is scanned for a matching flow rule. If a match is found, the flow actions specified by the flow rule will be executed and flow statistics will be updated otherwise the packet header will be routed to the Controller via a secure channel. The Controller processes the packet and determines the actions to be taken by the switches along the path chosen between the source and the destination (Minh et al., 2019). The new flow rule will be sent to the switches in the path to be installed in their flow tables. The switch will begin executing appropriate actions on the coming data packets based on the new flow rule. If a matching flow entry is not found on the Controller, packets will be dropped (Assefa et al., 2018).

Figure 3.

Traffic flow process in SDN environment

IJSKD.2020040101.f03

Complete Article List

Search this Journal:
Reset
Volume 16: 1 Issue (2024)
Volume 15: 1 Issue (2023)
Volume 14: 4 Issues (2022): 2 Released, 2 Forthcoming
Volume 13: 4 Issues (2021)
Volume 12: 4 Issues (2020)
Volume 11: 4 Issues (2019)
Volume 10: 4 Issues (2018)
Volume 9: 4 Issues (2017)
Volume 8: 4 Issues (2016)
Volume 7: 4 Issues (2015)
Volume 6: 4 Issues (2014)
Volume 5: 4 Issues (2013)
Volume 4: 4 Issues (2012)
Volume 3: 4 Issues (2011)
Volume 2: 4 Issues (2010)
Volume 1: 4 Issues (2009)
View Complete Journal Contents Listing