Content uploaded by Gajanand Sharma
Author content
All content in this area was uploaded by Gajanand Sharma on Jun 24, 2022
Content may be subject to copyright.
Full Terms & Conditions of access and use can be found at
https://www.tandfonline.com/action/journalInformation?journalCode=tdmc20
Journal of Discrete Mathematical Sciences and
Cryptography
ISSN: (Print) (Online) Journal homepage: https://www.tandfonline.com/loi/tdmc20
Self-healing topology for DDoS attack
identification & discovery protocol in software-
defined networks
Gajanand Sharma, Himanshu Sharma, Rajneesh Pareek, Nidhi Gour, Ravi
Shanker Sharma & Ashutosh Kumar
To cite this article: Gajanand Sharma, Himanshu Sharma, Rajneesh Pareek, Nidhi Gour, Ravi
Shanker Sharma & Ashutosh Kumar (2021) Self-healing topology for DDoS attack identification &
discovery protocol in software-defined networks, Journal of Discrete Mathematical Sciences and
Cryptography, 24:8, 2221-2232, DOI: 10.1080/09720529.2021.2009192
To link to this article: https://doi.org/10.1080/09720529.2021.2009192
Published online: 27 Dec 2021.
Submit your article to this journal
Article views: 2
View related articles
View Crossmark data
©
Self-healing topology for DDoS attack identification & discovery
protocol in software-defined networks
Gajanand Sharma †
Himanshu Sharma §
Rajneesh Pareek ‡
Nidhi Gour @
Ravi Shanker Sharma #
Ashutosh Kumar *
Department of Computer Science & Engineering
JECRC University
Jaipur 303905
Rajasthan
India
Abstract
Software defined networking is an emerging network architecture that separates the
control plane from the data plane of network devices and places the control plane on one or
more control servers capable of managing the rules traffic forwarding of all communication
devices under your domain. This article describes the architecture, different modules, and
event sequences of the HyPASS for real-time protection from address-forged attacks with
proactive host discovery and address validation. Such attacks cause the wastage of network
bandwidth, processing power, and network resources available to the user. We performed
the latency, throughput, and attack prevention tests using POX & RYU controllers on the
Mininet network simulator with and without HyPASS. The system performance is analyzed
for accuracy and efficiency in four different SDN scenarios categorized as fully OpenFlow
enabled and Hybrid. The proposed system discovers all the live hosts in the network, updates
Host Table at the handshaking between controller and OpenFlow switches. Experiments
show that the system prevented all the address-forged attacks by validating the source
† E-mail: gajanan.sharma@gmail.com
§ E-mail: himanshu.manu.sharma@gmail.com
‡ E-mail: rajneeshpareekjaipur@gmail.com
@ E-mail: gournidhi165@gmail.com
# E-mail: er.ravishankarsharma@gmail.com
* E-mail: ashucse007@gmail.com (Corresponding Author)
Journal of Discrete Mathematical Sciences & Cr yptography
ISSN 0972-0529 (Print), ISSN 2169-0065 (Online)
Vol. 24 (2021), No. 8, pp. 2221–2232
DOI : 10.1080/09720529.2021.2009192
2222
G. SHARMA, H. SHARMA, R. PAREEK, N. GOUR, R. S. SHARMA AND A. KUMAR
address in different SDN environments. It achieves a 99.99% filtering accuracy level in a fully
OpenFlow-enabled setup.
Subject Classification: 17B15.
Keywords: SDN, Dos attack, Open flow, Accuracy, HyPASS. POX & RYU.
1. Introduction
A business campus environment is made up of a set of interconnected
buildings through guided and unguided transmission media that link the
communication devices of the network and allow the transport of user
traffic. In a traditional business campus, the control plane is distributed
among all the devices on the network and requires their coordination to
decide how to treat the packets that enter their ports. This distributed
nature of the control plane forces network administrators to configure all
network devices each time a new application or policy is added to the
network, slowing provisioning and scalability of services in high-device
environments. In an SDN environment [1], one or more controllers are
responsible for operating and managing network traffic from a central
logical node. The SDN controller instructs the SDN devices the rules to
apply to packets circulating on the network based on the policies of an
organization. The deployment of SDN networks requires the application
of best practices and design principles that satisfy the design requirements
of organizations.
The definition of SDN is ‘unmounting control and packet transmission
planes in the network.’ It enables networks, through application
programming interfaces (APIs), to connect directly to applications, to
improve application performance and security and to provide a flexible,
dynamic network architecture that can be modified if desired. It is likely
that SDN is utilized as the most common form of application deployment,
so that companies may deploy their applications faster and reduce total
deployment and running expenses. IT administrators employing SDN
can centrally control and provide their network services. SDN uses open
APIs to maintain network monitoring, a network paradigm that provides
programmatic administration and control, and optimization of network
resources. This network control is generated when SDN disconnects the
network set-up and traffic engineering and separates it from the basic
hardware infrastructure. This division enables OpenFlow [2] and other
open protocols to be used. These open protocols can access network
SELF-HEALING TOPOLOGY FOR DDOS ATTACK IDENTIFICATION
2223
switches and routers that employ proprietary, otherwise locked firmware
on the periphery of the network using globally Knowledgeable control
of software. SDN allows users to virtualize their hardware and work to
construct a computer network by dividing the network into distinct plans:
the control plane and the data plane and early SDN deployment.
1.1
Traditional Network
Traditional networks are composed of static and various fixed
functions in the form of switches routers and other networking devices.
These devices are limited to per- form only specific functions in which
they are coded. If anyone wishes to change or alter their root configuration,
they cannot do that because of inflexibility and there- fore it is causing a
hurdle in the innovation. Traditional networks are making use of dedicated
hardware. Basically, the intelligence of the network (code and traffic trans-
mission rules) along with the underlying network infrastructure used
is encapsulated within the dedicated hardware. Fig. 1 is showing the
architectural view of traditional networks. In this architecture, it can be
seen that various network switches are comprised of control plane and data
plane. It is very difficult to configure every networking
device from different
vendors having varied configurations. Traditional network devices
such as
Network Address Translation (NAT)[3], load balancer, firewalls, switches,
routers, etc. are a vendor-specific and perform only dedicated functions, the
code these devices carry is very complex and hard to reconfigure. As far as
concerned with the configuration of these devices it is usually done by the
corresponding network administrators whereas the different interfaces are
provided by the multiple vendors.
2. Literature review
The Objective of software-defined networks is based on the removal
of the control avion from the data plane of the network. By abstracting
application control, network operation may be optimized by establishing
a programmable network. The control plane and the data plane are both
located in the conventional networks within the network device itself,
and in this case, it is up to the control plane of each node to know what
measures to take upon receiving a specific data transmission flow. The
IoT [4] changes everyone’s lives with capabilities like as managing and
monitoring connected intelligent products. IoT applications encompass
a wide range of services including clever towns, houses, vehicles,
2224
G. SHARMA, H. SHARMA, R. PAREEK, N. GOUR, R. S. SHARMA AND A. KUMAR
manufacturing, e-health, smart systems. The popularity of these devices
is growing quickly and a substantial amount of data for processing and
analysis has been created. Thus, these gadgets are not only susceptible to
different hazards and safety concerns and thus worry themselves not only
with their acceptance in sensitive settings such as e-home, smart house,
etc., but also present risks for the growth of IoT in the future days. This
study analyzes the dangers, safety demands, issues and attack vectors
of IoT networks in detail. On the basis of research, a new paradigm is
given, integrated by software networked IoT architectural use (SDN).
This paper provides an overview of SDN and an exhaustive examination
of centralized and decentralized IoT deployment techniques based on
SDN. In order to give a comprehensive overview of SDSec technology, we
have created further IoT security solutions based on SDN. Moreover, the
literature emphasizes basic problems that are key barriers to integrating
all IoT stakeholders on a single platform and few findings concentrating
on a network-based IoT security solution. Finally, there are some future
research opportunities for SDN-based IoT security systems.
With the growth and complexity of networks, administrative and
management difficulties are increasing. Software-defined networks
(SDNs) offer a possible solution to tackle some of these problems. In
this paper, Author [5] proposes a policy-based security architecture to
protect end-to-end services over various SDN domains. We propose a
language mechanism for defining security policies relating to the supply
and communication of SDN services. We describe the policies and their
application in the implementation of security policies in a multi-domain
SDN in order to govern the flow of information. The defined fine-grained
security policies are shown using a number of attributes, such as user and
device/switch parameters, context information such as the location and
routing of data, services used by the SDN, and security attributes linked to
switch and control domains. The ability to lay down road and flow-based
safety standards for safe end-to-end services in SDNs is a fundamental
element of our architecture. We assess the performance properties of our
design and discuss how our architecture might combat security risks. This
study adds to the dynamic approach of security policy and the intelligent
distribution of security capabilities as a layer for service, which allows
flow-based security enforcement and the protection of a wide variety of
network devices against attacks.
SELF-HEALING TOPOLOGY FOR DDOS ATTACK IDENTIFICATION
2225
3. Proposed Work
3.1 Software-Defined Network
The new architecture of the Software-Defined Network (SDN) is in the
limelight. It has diminished the advantages of traditional networks. The
separation of the control plane from the data plane has produced multiple
advantages and research directions. With the help of SDN, it has opened
up many advantages and functionalities. Network administrators [8] and
developers can easily configure existing applications such as firewalls, load
balances, etc. No more dedicated hardware dependency is there now. To
diminish the vendor specificity SDN has made use of OpenFlow switches
[9] and with the help of the same code and configuration, one can easily
manage the whole network.
3.2 DDoS Attack in SDN
All three layers of SDN architecture are vulnerable to DDoS attacks
[10]. There are many attacking points in it as shown in Fig. 1. The
following are the target points in SDN networks. OpenFlow switches: In
SDN OpenFlow switches are used to forward the traffic from source to
destination. It maintains a flow table in which the entry of various network
packets resides. When a new packet arrives SDN switch checks the entry
of the newly arrived packet in its flow table if the entry if found it directly
Figure 1
DDoS Attack in SDN
2226
G. SHARMA, H. SHARMA, R. PAREEK, N. GOUR, R. S. SHARMA AND A. KUMAR
sends the packet to the defined destination on the other hand if the entry
is not found in the flow table of SDN switch it initiates the packet_in event
and sends a request to the SDN controller to determine the route of the
corresponding packet .
The memory size of these flow tables of SDN switches is limited
Ternary Content-Addressable Memory (TCAM). If in a case, DDoS attacks
happen and OpenFlow switches are flooded with the number of new
packet entries due to the limited size the transmission will be delayed and
hence causing a big concern for security.
3.3 Attack Models:
This section uses the host detection system proposed in as IDH-SDN
and modified it as per HyPASS design requirements. We offer a proactive
host detection module for SDN setup and use SARP messages with hashed
MAC addresses to detect hosts in the network [13].
Algorithm 1: Host Detector
Implementation at: Switch Feature Event & Port Status Event
Input: Switch ID, Switch Port ID, ip Range with event message
procedure HOSTDETECTOR
if SwitchFeature or PortStatusNew or PortStatus Modity then
for j=1 to ipRange do // perform for IP range
Generate SARP-Request messages with DstMAC = Broadcast
MAC address, SrcMAC = Hashed MAC, SrcIP= “0.0.0.0” // source
address of SARP request packet
end for // end of switch ports range
else if PortStatusDelete then
delete from HostTable with SwichID, SwitchPortID
FLOWENTRYMANAGER (SwichID, SwitchPortID, DELETE)
end if
end procedure
The procedure HOSTDETECTOR of Algorithm 1 offers the discovery
of hosts’ details by implementing at a SwitchFeature & PortStatus[14]
events and taking inputs Switch ID & Port, ipRange, and event message.
The output of the algorithm is the generation of SARP-request messages
into setup. It helps to detect the host whenever we add a new host or switch
port, or switch to the network. It also works at a change of status of the
SELF-HEALING TOPOLOGY FOR DDOS ATTACK IDENTIFICATION
2227
switch port. HostDetector removes host details from the HostTable when a
host is leaving the network.
4. Result & Analysis
IP Spoofing: In Fig.2 & 3, the attacker host 10.0.0.2 (H2) pretends to be
the host 10.0.0.1(H1) or 10.0.0.4 (H4) and conducts an IP spoofing attack
to victim host 10.0.0.3(H3). If the network does not have any anti-spoofing
measure deployed, the H1 attacker could harm both the H3 destination
host & the H1 pretending host. In Fig.2, the attacker host 10.0.0.3 (H3) is
connected with a legacy switch, and it uses IP of H1 (10.0.0.1) or H2 (10.0.0.2)
to conduct an attack on the victim host H4 (10.0.0.4). In this way, the attacker
initiates the DoS attacks and harms the network services. MAC Spoofing:
These are also known as ARP spoofing attacks. In Fig. 2 & 3, the attacker
Figure 2
Attacker with OpenFlow switch in Fully SDN Scenario
Figure 3
Attacker with Open Flow switch in Hybrid SDN Scenario
2228
G. SHARMA, H. SHARMA, R. PAREEK, N. GOUR, R. S. SHARMA AND A. KUMAR
host H2 (IP:10.0.0.2 & MAC:00:00:00:00:02) pretends to be the host H2
(IP:10.0.0.1 & MAC:00:00:00:00:02) and conducts an ARP Request attack to
victim host H3 (IP:10.0.0.3 & MAC:00:00:00:00:03). The H1 attacker could
generate huge traffic of such packets and harm both the H3 destination
host & the H1 pretending host [15].
In Fig.4, the attacker host H3 (IP:10.0.0.3 & MAC:00:00:00:00:03) uses
MAC & IP of H1 (IP:10.0.0.1 & MAC:00:00:00:00:02) and conducts an attack
on victim host H4
(IP:10.0.0.4 & MAC:00:00:00:00:04). In this way, the attacker
initiates the DoS attacks
and harms the network services. The attacker also
conducts attacks by replying falsely with their own MAC and IP to other
host’s ARP requests and tries to gain illegitimate access to the data packets
of two host’s connection. This type of attack is called Man in the Middle
(MitM).
Host Detection: During testing of HyPASS, it detects connected hosts
of a selected network scenario and records host details in the HostTable.
Table 1 shows the sample data of the recognized hosts. We have verified
the HostTable data with the output of Wireshark. The result indicates
that HyPASS is discovering all the hosts and updating the HostTable. The
Hybrid SDN network shown in Fig. 4 has S3 and S8 legacy switches. The S3
has three hosts, i.e., H7 to H9, and S8 has H22 to H24. The S3 & S9 legacy
switches are connected through S2 & S9 SDN switches, respectively. In
italics, Table 1 shows the HostTable entries of the hosts connected with
legacy switches.
Filtering Accuracy: We use Scapy to generate several types & quantum
of traffic along with a specific rate of address forging packets. The security
controls developed for SDN are applied directly on the OFSwitches but
not on legacy switches (non- SDN Switches). Fig. 5 shows the filtering
Figure 4
Attacker with the non-SDN switch in Hybrid SDN Scenario
SELF-HEALING TOPOLOGY FOR DDOS ATTACK IDENTIFICATION
2229
accuracy of the system with POX and RYU controllers using four network
scenarios. It indicates that HyPASS’s filtering accuracy is 99.99% with both
the controllers. These network scenarios have all the OFSwitches.
S3 and S8 are legacy switches in the ‘Hybrid’ network scenario. The
address forged attack filtering accuracy in such hybrid topologies varies
because the SDN security policies are not applicable on legacy switches.
The SDN controller does not control the host’s traffic connected with
the host’s legacy switch, which may be linked with the same switch. If
an attacker (ex. H7) and victim hosts (ex. H8 & H9) are connected with
the same legacy switch, HyPASS does not detect and filter such attacks.
However, the attacker or victim or both are connected with OFSwitch in
Table 1
Host Table Data Sample of Network Scenario 4: Hybrid.
OpenFlow
Switch ID
OpenFlow Switch
Port ID Host MAC Host IP
S1
2 00:00:00:00:00:01 10.0.0.1
3 00:00:00:00:00:02 10.0.0.2
4 00:00:00:00:00:03 10.0.0.3
S2 2 00:00:00:00:00:04 10.0.0.4
3 00:00:00:00:00:05 10.0.0.5
4 00:00:00:00:00:06 10.0.0.6
5 00:00:00:00:00:07 10.0.0.7
00:00:00:00:00:08 10.0.0.8
00:00:00:00:00:09 10.0.0.9
…. …. …. ….
…. …. …. ….
S9 5 00:00:00:00:00:16 10.0.0.22
00:00:00:00:00:17 10.0.0.23
00:00:00:00:00:18 10.0.0.24
2 00:00:00:00:00:19 10.0.0.25
3 00:00:00:00:00:1a 10.0.0.26
4 00:00:00:00:00:1b 10.0.0.27
S10
2 00:00:00:00:00:1c 10.0.0.28
3 00:00:00:00:00:1d 10.0.0.29
4 00:00:00:00:00:1e 10.0.0.30
2230
G. SHARMA, H. SHARMA, R. PAREEK, N. GOUR, R. S. SHARMA AND A. KUMAR
a hybrid topology, then our technique detects & filters address forged
packets. Fig. 5 shows that attacker/victim/both are connected with
OFSwitch, then filtering accuracy for ‘Hybrid’ topology is 99.99%. In other
cases, it depends on the number of hosts connected with the legacy switch
and the number of spoofed packets created by the attacker for the victim
hosts connected on the same switch. In this mix mode test, our system
achieves more than 80% filtering accuracy.
Conclusion
This research describes the main components of an SDN architecture
including hardware components, software and protocols and design
considerations for deploying SDN networks in the enterprise campus
environment. Enterprise campus networks are limited to a set of buildings
or floors of a building interconnected by Ethernet networks. The discovery
process of HyPASS works with static IP addressing methods. The system
extracts host details from DHCP-Request and stores them into the binding
HostTable. On receiving the DHCP-Ack, it updates the IP detail in the
HostTable of related MAC address and installs necessary flow entry with
host details for successive DHCP-Request, DHCP-Release & DHCP-Ack.
Result Show That shows that attacker/victim/both are connected with
OFSwitch, then filtering accuracy for ‘Hybrid’ topology is 99.99%. In other
cases, it depends on the number of hosts connected with the legacy switch
Figure 5
SDN Deployment & Flow Generation Ratio
SELF-HEALING TOPOLOGY FOR DDOS ATTACK IDENTIFICATION
2231
and the number of spoofed packets created by the attacker for the victim
hosts connected on the same switch. In this mix mode test, our system
achieves more than 80% filtering accuracy.
References
[1] G. Chen, G. Hu, Y. Jiang, and C. Zhang, “SAVSH: IP source address
validation for SDN hybrid networks,” in 2016 IEEE Symposium on
Computers and Communication (ISCC), 2016, pp. 409–414.
[2] C. Zhang et al., “Towards a SDN-Based Integrated Architecture for
Mitigating IP Spoofing Attack,” IEEE Access, vol. 6, pp. 22764–22777,
2017.
[3] S. Deng, X. Gao, Z. Lu, and X. Gao, “Packet injection attack and its
defense in software-defined networks,” IEEE Trans. Inf. Forensics
Secur., vol. 13, no. 3, pp. 695–705, 2018.
[4] Arora, Amandeep Singh, Barkha Bahl, and Linesh Raja. “Diverse
real-time attack traffic forecasting for cloud platforms.” Journal of
Discrete Mathematical Sciences and Cryptography 22.4 (2019): 541-555..
[5] A. S. Alshra’a and J. Seitz, “Using INSPECTOR Device to Stop Packet
Injection Attack in SDN,” IEEE Commun. Lett., vol. 23, no. 7, pp. 1174–
1177, 2019.
[6] B. Liu, J. Bi, and Y. Zhou, “Source address validation in software
defined networks,” in SIGCOMM 2016 - Proceedings of the 2016 ACM
Conference on Special Interest Group on Data Communication, 2016, no.
Dc, pp. 595–596.
[7] R. C. Meena, M. Nawal, and M. M. Bundele, “SIPAV-SDN: Source
internet protocol address validation for software defined network,”
Int. J. Innov. Technol. Explor. Eng., vol. 8, no. 12, 2019.
[8] Kumar, Ankit, et al. “An improved quantum key distribution
protocol for verification.” Journal of Discrete Mathematical Sciences and
Cryptography 22.4 (2019): 491-498.
[9] P. Manzanares-Lopez, J. P. Muñoz-Gea, F. M. Delicado-Martinez, J.
Malgosa-Sanahuja, and A. F. De La Cruz, “Host discovery solution:
An enhancement of topology discovery in OpenFlow based SDN
networks,” in ICETE 2016 - Proceedings of the 13th International Joint
Conference on e-Business and Telecommunications, 2016, vol. 1, no. Icete,
pp. 80–88.
2232
G. SHARMA, H. SHARMA, R. PAREEK, N. GOUR, R. S. SHARMA AND A. KUMAR
[10] R. C. Meena, M. Nawal, and M. Bundele, “Instant detection of host in
SDN (IDH-SDN),” Int. J. Recent Technol. Eng., vol. 8, no. 3, pp. 5603–
5608, Sep. 2019.
[11] F. Pakzad, M. Portmann, W. L. Tan, and J. Indulska, “Efficient topology
discovery in OpenFlow-based Software Defined Networks,” Comput.
Commun., vol. 77, pp. 52–61, 2016.
[12] G. Tarnaras, E. Haleplidis, and S. Denazis, “SDN and ForCES based
optimal network topology discovery,” in 1st IEEE Conference on
Network Softwarization: Software-Defined Infrastructures for
Networks, Clouds, IoT and Services, NETSOFT 2015, 2015.
[13] L. Ochoa-Aday, C. Cervello-Pastor, and A. Fernandez-Fernandez,
“Self-healing topology discovery protocol for software-defined
networks,” IEEE Commun. Lett., vol. 22, no. 5, pp. 1070–1073, 2018.
[14] Y. Jiménez, C. Cervelló-Pastor, and A. García, “Dynamic resource
discovery protocol for software defined networks,” IEEE Commun.
Lett., vol. 19, no. 5, pp. 743–746, 2015.
