Network Sec Roadmap

1. 1
Network Security Roadmap
Praveen Kumar
F
1 ABSTRACT
Users may already have some perception of provided secu-
rity based on experience with earlier generations. To main-
tain the stability and coherent integration of 5G services, it
is imperative that security and privacy features prevalent in
earlier generations are also present in 5G. However, it is not
sufficient just to provide the same security features as in the
legacy systems due to the new threat model introduced by
the integration of new technologies like SDN, virtualization
and SBA. 5G systems are expected to be more service-
oriented. This suggests there will be an additional emphasis
on security and privacy requirements that spawn from the
new dimension of service-oriented security architecture.
2 INTRODUCTION
The fifth generation network, popularly referred to as
5G, has the potential of enabling multiple vertical indus-
tries [1, 2] like vehicle networks [3, 4], IoT [5, 2], VR/AR [6],
smart cities [7, 8, 9] and smart healthcare [10, 11, 12].
The millimeter wave technology that 5G employs offers
100x lower latency and 100x more bandwidth [13] than
the existing 4G technology. As a result of this, real-time
security requirement is a prime concern for the deployment
of 5G applications. When it comes to networks involving the
Internet of Things (IoT), multiple layers of the stack are vul-
nerable as potential targets of security attacks [14], including
the service and application layer, nodes, platforms, and the
network/transport layer. For example, a unified framework
of vulnerability detection in an IoT system is described in
[9]. The increased speed and bandwidth enabled by 5G
will eventually lead to new threat vectors and increased
sophistication of cyber attacks.
Another growing concern is the acceleration of existing
cyber attacks in the 5G framework. Today’s cyber attacks
have already targeted networks’ security: both at the IP
layer and signalling layer. Thus, simply making legacy
security mechanisms operate faster is not an adequate
measure. The Service Based Architecture (SBA) of the core
5G network provides multiple access points to third-party
service providers, thus expanding the attack surface. Legacy
approaches that depend on disparate security elements will
neither scale nor will be able to adequately prevent suc-
cessful attacks across the SBA of 5G networks [15]. New
encryption schemes and authentication protocols like 5G
AKA [16] are being designed for this purpose. System
designs composed of individually secure subsystems are
not provably secure. 5G radio network deployments in-
clude substantial augmentations of small cells connecting
over insecure networks, edge communications, and edge
nodes communicating with multiple cells concurrently [17].
Moreover, 5G comes with its new authentication protocols
and encryption primitives, which have not received a suffi-
cient amount of cryptanalysts’ scrutiny yet. This evolution
broadens the threat landscape by expanding the number of
intrusion points. With billions of connected devices and crit-
ical enterprise applications relying on 5G networks, network
operators and applications should preemptively defend
against possible security breaches. Some effective measures
for ensuring comprehensive end-to-end (E2E) security in the
5G framework may include:
• Multiple factors of mutual authentication across all
layers of the network including application, control
and data planes [18, 15, 19].
• Cloud-based threat analysis and vulnerability man-
agement, enabled by machine learning(ML) algo-
rithms, can be used across multiple platforms to
provide immediate response to known and unknown
threats in real time [20, 21, 22].
• The explosion in the number of end devices re-
quires real-time quarantining of infected devices us-
ing data-driven approaches.
• Multi-layered encryption of software-defined net-
work (SDN) data planes, enabled by data classifi-
cation is required for confidentiality and integrity
protection.
A primary reason for the necessity of stricter security
measures in emerging networks is the change of the trust
model as depicted in Fig. 1.
Security for 5G should be taken into consideration at
the initial stages of the system design (Security by Design
approach). Augmenting security features at a later stage
is less efficient and often more expensive in the long run.
In long term, security is a driving factor for service and
network evolution.
3 BACKGROUND
We provide a brief background on relevant prior work in
this field.
3.1 5G Network Security
Unlike previous generations of communication, the security
vulnerabilities in the 5G infrastructure are manifold. This is
arXiv:2211.05278v1
[cs.CR]
10
Nov
2022

2. 2
Fig. 1. Evolved trust model in 5G [23]
due to the integration of multiple 5G enabling technologies
that alter the traditional architecture of 4G networks [17, 24].
The enhanced mobile broadband and high reliability come
with the introduction of flexible mobility and networks.
Programmable networks, network function virtualization
(NFV) and network slicing are some of the technologies
that make the 5G dream possible [25, 26]. However, the
integration of these features increase the attack surface.
The SBA of 5G has multiple third-party service providers
sharing resources for efficient functioning of the network.
This makes every entity a potential point of attack, unlike
the existing systems where most services are provided by
the network provider. Hence, 5G security is not just an
extension of the current security measures.
The primary changes in the 5G Core from the existing
4G Evolved Packet Core manifest in the form of NFV,
Multi-access Edge Computing (MEC) [27, 28], Radio Access
Network (RAN) [29] and SDN [30, 31, 32]. NFV decou-
ples software from hardware by replacing various network
functions such as firewalls, load balancers and routers with
virtualized instances. Network slicing enables the imple-
mentation of NFV by allowing multiple logical networks
to run on top of a shared physical resource. This provides
increased flexibility across networks. SDN is a complimen-
tary technology to NFV for achieving a unified network
abstraction to expand data flow control in the form of virtual
switches [33].
4 PROPOSED WORK
There have been preliminary studies on the emerging vul-
nerabilities in the individual components of the 5G net-
work [34, 14, 35, 36, 37]. However, there has not been
a comprehensive analysis of the vulnerabilities emerging
due to integration of these various components yet. We
aim to study such vulnerabilities. There are some attack
classes that can be more effectively defended against in the
5G framework. We wish to study such scenarios as well.
We also aim to study system level (OS and kernel) and
application level vulnerabilities, their correlation to network
vulnerabilities as well as the emergence of new threats using
artificial intelligence methods.
4.1 Pillars of the methodology
Newer technologies integrated in 5G require the formula-
tion of:
• New stream ciphers: As mentioned earlier, the 5G
ecosystem will enable multiple vertical industries
like IoT. This involves the existence of a heteroge-
neous amalgamation of resource-constrained edge
devices. More energy-efficient encryption algorithms
and authentication methods are required for effi-
ciency of these devices. Some good candidates for ef-
ficient 5G radio communications with constrained re-
sources are mentioned in [38, 19]. However, in-depth
cryptanalysis is yet to demonstrate the strength of
such ciphers.
• New security protocols: Due to the change in the
architecture of existing 4G networks, new protocols
have been designed for better attack resistance of
5G radio access networks. Random access procedure
based on tunable puzzles is an example introducing
generalization and improved usability in existing
security puzzles [39, 40].
On another hand, 5G network is composed of many
subsystems functioning together. The security of each of
these subsystems as stand-alone disparate systems is nec-
essary but not sufficient to ensure the security of the overall
system. The study of the security challenges arising due
to the integration of the following subsystems is still in its
infancy. Some of the major 5G security subsystems are:
1) Application layer security: Application layer secu-
rity refers to ways of protecting the application layer
from malicious attacks and the exploit of inherent
software vulnerabilities. Application layer provides
the largest threat surface to the attackers due to
accessibility and the huge diversity and minimal
abstraction from the user. Application layer vul-
nerabilities may lead to performance and stability
degradation, loss of privacy, and the network being
taken down [41]. Application layer threats include
buffer overflows, race conditions, SQL injections
and privilege escalation, amongst others.
2) Edge security: The edge of the network generally
comprises the computing nodes, like smartphones,
sensors, RFID tags and smart controllers. Edge de-
vices often process and store confidential informa-
tion which must be protected. In a smart system like
an autonomous vehicle or an IoT ecosystem [42, 5],
an edge device (namely the microcode, kernel and
operating system layers) are prone to security ex-

3. 3
ploits. It is essential to detect such exploits in real-
time. Edge security poses many different threats, a
major one being a DDoS attack launched by hijacked
edge nodes.
3) Cloud RAN (C-RAN) security: C-RAN is a central-
ized cloud-based radio access network architecture
that has multiple advantages over traditional radio
access networks. C-RAN has been adopted by mul-
tiple operators for the 5G infrastructure [43]. Due
to its widespread integration, C-RAN security has
received a lot of attention recently. The traditional C-
RAN threat vectors include eavesdropping attacks,
impersonation attacks, jamming attacks, primary
user emulation attacks and wireless channel attacks.
Most of these attacks can be evaded using existing
cybersecurity measures but the potential emergence
of novel threat vectors due to its integration to the
disparate new technologies have not been explored
yet [44, 45].
4) SDN security: Traditionally, network components
like routers and switches have the rules for packet
forwarding hard-coded into the devices. This in-
hibits the flexibility of the devices and may lead
to inefficient packet routes. SDN separates the con-
trol plane and the data plane, allowing a soft-
ware defined controller to dynamically determine
the packet forwarding routes. This increases effi-
ciency. Many 5G operators are looking forward to
integrate SDN in the 5G framework. However, the
SDN controllers are stand-alone components which
need to be protected from attackers [46, 47]. Other
security aspects includes establishing trust between
SDN controllers and the data plane (via authen-
tication), creating a robust policy framework and
conducting forensic tests to detect and remediate
a compromised controller. Various attacks include
DoS attacks on the controller and the data planes,
topology poisoning attacks and man-in-the-middle
(MiTM) attacks. These attacks are described in detail
in section 4.2.2.
5) Proactive security analysis: The 5G infrastructure
is a service based architecture. Such an architecture
is controlled by smart controllers. Hence, future
updates in 5G will be software updates. Because
of the cyber vulnerabilities of software, we need
a proactive real-time security analyzer to detect
and alleviate the threats before an attacker exploits
it [48, 49].
The dramatic increase in bandwidth in 5G gives rise
to additional attack vectors. Short range, small-cell
antennae physically deployed all across the country
become the new entry-points for attackers, expand-
ing the attack surface. Functionally, these antennae
will use 5G’s Dynamic Spectrum Sharing capability
in which multiple streams of information share the
bandwidth in so-called “slices”—each slice with its
own varying degree of cyber risk. Such dynamic
modes of operation require dynamic cybersecurity
solutions, rather than uniform rigid defences.
6) Hypervisor security: Hypervisors enable the map-
ping of various network functions to underlying
logical instances and hardware in a virtualized
5G network. A hypervisor can create and execute
multiple guest operating systems and performs the
necessary resource allocation for those systems. This
makes the hypervisor a potential point of entry to
multiple networks. Hypervisors are susceptible to
DoS attacks on virtual machines (VMs), VM hop-
ping attacks and network slice attacks via host op-
erating systems. Some common hypervisor vulner-
abilities include software bugs and network attacks
like network intrusion and DoS attacks.
7) Faster authentication: With the facilitation of multi-
ple vertical industries like autonomous vehicles, IoT
and smart healthcare, the number of edge devices
will face an exponential growth. The number of
virtual machines will also increase due to the inte-
gration of services like SDN and NFV. All these indi-
vidual components need to authenticate themselves
to one another to ensure secure interaction between
them [50, 51]. Faster and reliable authentication
mechanisms and policies are required for effective
operation of the 5G infrastructure.
8) NFV security: NFV utilizes virtualization to allow
multiple networks to run on shared resources. NFV
is an integral part of the 5G ecosystem and se-
curing it is a fundamental concern. While some of
the issues related to NFV security like hypervisor
security and SDN security have been discussed be-
fore, there are certain unique threats to NFV which
must be considered during secure 5G system design
[52, 53, 54, 55]. These vulnerabilities include soft-
ware bugs, insider attacks (like Trojans), outsider
attacks (like malicious third-party operator) and
attacks on shared resources (like cache poisoning
attacks) [56].
An advantage of NFV is that it allows the virtual-
ization of network security functions like intrusion
detection systems. This enables security-as-a-service
infrastructure, which is integral to the service based
architecture of 5G.
4.2 Preliminary Evaluation
4.2.1 Results on WhatsApp
We consider WhatsApp as our secure chat, voice and video
application running on a 5G network for our security eval-
uations. We propose to apply cyber-analysis to WhatsApp
as a standalone application which implements several in-
transit and at-rest security countermeasures. We will also
analyze WhatsApp in the context of 5G networks.
WhatsApp is a secure instant messaging application
with over 1.5 billion users in over 180 countries. The What-
sApp messenger uses XMPP protocol and enforces E2E
encryption. E2E encryption claims that no one other than the
end users can decrypt messages in transit (including proxy
and authentication servers). WhatApp E2E encryption is
built on top of the security protocol used by the highly
secure messaging application Signal. However, there are
certain security measures that have been omitted by What-
sApp for higher efficiency. As a stand-alone application,

4. 4
WhatsApp is highly secure. Morever, security vulnerabili-
ties at different layers like the network, IP or transport layer
can be exploited to compromise the security of WhatsApp.
We aggregate all the known attack vectors on WhatsApp
across the application layer, network layer, authentication
interfaces and the edge device [57, 58]. Till now, we have
constructed a DAG of 5 classes of vulnerabilities. The DAG
consists of 23 nodes currently. We will keep on augmenting
our DAG as new vulnerabilities are exposed. The various
threat vectors are:
1) Image file-jacking: This attack vector is launched by
a malware or rootkit on the smartphone which has
access to the shared memory. Sandboxing allows ap-
plications like WhatsApp to store its messages in a
secure partition of the memory which is inaccessible
to any other third-party application. However, the
images and other media contents received via the
messenger are stored in the shared external memory
(/storage/emulated/0/Whatsapp/media). There is
usually a delay between receiving the media file in
memory and loading it in the chat user interface.
The malware can potentially alter the media file dur-
ing this time and the attack will go undetected. This
is also known as the Man-in-the-Disk attack and can
be used to manipulate images, payment information
and audio files. The Control Flow Graph (CFG) of
this attack is shown in Fig. 2.
2) Insecure storage of keys: The WhatsApp encryp-
tion keys are stored on the device in clear text.
It is assumed that sandboxing prevents any other
application from accessing it [58]. However, root
access to the phone and memory corruption attacks,
enables access to key chains and renders encryption
keys vulnerable to confidentiality and integrity at-
tacks respectively. Besides these, there are methods
to decrypt messages on an older smartphone after
migrating to an existing WhatsApp account on a
new device. These methods can be exploited to
extract the private key.
3) SS7 network protocol exploit: WhatsApp verifies
a user’s identity with a one-factor authentication,
namely the phone number used for registration, by
calling the user’s registered phone number or by
sending him/her a verification code via SMS. The
network protocol Signalling System 7 (SS7), which
is used for communication by a large number of
providers, is vulnerable and prone to session hijack-
ing. A malicious adversary can hijack the authenti-
cation call (or SMS) and verify himself as the user,
thus impersonating the user in future conversations.
The CFG of this attack is shown in Fig. 3.
4) Voicemail exploit: As mentioned before, WhatsApp
uses voice calls to verify a new account. If the user
doesn’t receive the verification call, the verification
code is sent to the user’s voicemail. Voicemail ac-
counts can be hacked easily with brute-force attacks
on voicemail account passcodes. Hacking the voice-
mail gives access to the verification code which can
be exploited by the attacker to impersonate the user
in future conversations. The CFG of the voicemail
exploit is depicted in Fig. 4.
5) Insecurity of messages blocked in transit: This
security feature is intentionally disabled by What-
sApp as a trade-off for higher efficiency. The attack
scenario involves Alice sending a message to Bob.
Bob doesn’t receive the message immediately be-
cause he is offline. In the meantime, the adversary
Eve steals Bob’s SIM card and uses it to verify her-
self as Bob on another device. Now, Eve receives the
message from Alice which was meant for Bob [59].
The CFG of this attack is shown in Fig. 5.
These attack vectors demonstrate that, although What-
sApp is highly secure as a stand-alone application, multiple
implementation mechanisms on different platforms make it
vulnerable to various attacks.
4.2.2 Attacks on SDN framework
The SDN stack in the 5G network architecture has intro-
duced an entirely new attack surface with numerous threat
vectors. The role of SDNs in virtualizing the network func-
tions for greater flexibility and performance is pivotal for the
realization of the promises made by 5G developers. Even at
its nascent stage, it has already been adopted in multiple
real-world systems like the Google datacenters.
Multiple network operating systems (NOS), also referred
to as controllers, are available for the implementation of
a SDN framework. The most popular amongst them are
OpenDaylight [60], Floodlight [61] and POX [62]. All of
them implement the most widely used OpenFlow [63] pro-
tocol for SDN communication. It has been shown that these
NOSs are vulnerable to multiple classes of attacks [64]. A
major concern is the absence of encryption of the messages
exchanged between the controller and network switches.
We have considered the existing vulnerabilities of SDN
and constructed an attack DAG that includes the CFGs of
all such attacks. Then we implement cyber-analysis on this
DAG to obtain new attacks on the SDN framework. The
attacks that comprise the SDN attack DAG are:
1) Packet-In flooding: The network hosts and switches
send PacketIn messages to the controller when it
encounters a packet with unknown flow (a flow is
the rule which instructs the switch where to forward
the packet). The controller then sends an appropri-
ate flow to the switch and the switch follows the
specified flow rule in the future.
If compromised switches send multiple PacketIn
messages to the controller, the controller may ex-
haust all its resources in catering to them. This
would lead the controller to an unpredictable state
which may cause the network to fail. This is a classic
DoS attack on the SDN controller. The CFG of this
attack is shown in Fig. 6.
2) Switch table flooding: This is a DoS attack targetted
towards exhausting the memory resources of the
controller. The controller (or NOS) has a switch table
which stores the information about all the switches
present in the network. In the Floodlight controller,
it is observed that modifying the features-reply mes-
sage of the SDN OpenFlow protocol with a unique
datapacket ID (DPID) causes the controller to add

5. 5
Access to
shared
memory
Detect arrival of
media file on disk
Modify the file
immediately
Fig. 2. CFG of image file jacking
Launch SS7
attack
Identify IMSI
number of victim
Request
reassignment of
victim to attack
terminal
Get subscriber profile
details of VLR and
HLR databases of
SS7 network
Complete
reassignment of
victim's profile
Spoof victim's
phone; Receive
verification SMS
Impersonate
victim
Fig. 3. CFG of SS7 vulnerability exploit
Gain access to
victim's voicemail
account by brute-
forcing passcodes
Ensure that victim
doesn't receive
verification call
Jam victim's
network
Switch off
victim' phone
Engage victim
in another call
Hypernode
Request WhatsApp
password reset with
victim's phone number
Select voice call
as verification
mechanism
Obtain
verification code
from victim's
voicemail
Impersonate
victim
Fig. 4. CFG of voicemail exploit
Migrate victim's
SIM card to
another device
Verify victim's
WhatsApp account
on new device
Server sends message
back to sender for re-
encryption
Receive message
encrypted with key
of new device
Fig. 5. CFG of blocked messages in-transit exploit
Send flows to
switches
Switches send lots of
packetIn messages
Overload control
plane
Drop legitimate
messages
Delayed response
Fig. 6. CFG of packet-In flooding attack on control plane of SDN
a new entry to its switch table. Sending numer-
ous maliciously-crafted messages can exhaust the
switch table of the controller, causing the controller
to disconnect the legitimate switches of the network.

6. 6
The CFG of this attack is shown in Fig. 7.
3) Switch identification spoofing: Due to weak au-
thentication of the switches in the SDN protocol, a
malicious switch may pose as a legitimate switch
and request connection access with the controller.
This causes the controller to disconnect the legiti-
mate switch and connect with the malicious switch.
The CFG of this attack is shown in Fig. 8.
4) Malformed control message injection: OpenFlow
messages between the switches and the controller
contains a header. An adversary can modify the
contents of the header or the message itself to crash
the SDN controller. In such a scenario, the controller
might disconnect the switch. The CFG of this attack
is shown in Fig. 9.
5) System time manipulation: Many SDN applica-
tions depend on the system time and other system
variables. Modifying the system time may lead to
disconnection of the switch which tries to perform
time-sensitive operations. The CFG of this attack is
shown in Fig. 10.
6) Topology poisoning: In order to achieve superior
performance to traditional networks, an overall
view of the entire network is available to the con-
troller for efficient routing. The overall configura-
tion of the network is implemented via host tracking
services and link discovery services. These services
can be exploited by multiple techniques (like node
spoofing)to alter the topology of the network in the
controller database. This lead to various attacks like
eavesdropping attack and MiTM attack. The CFG of
this attack is shown in Fig. 11.
7) Arbitrary system termination: A malicious SDN
application can call the system exit function. This
will lead to the termination of the entire controller.
All applications will be killed and all entries of the
switch table will be lost. This shall be devastating
for the data plane elements like the switches and
hosts. The CFG of this attack is shown in Fig. 12.
8) System resource exhaustion: A malicious SDN ap-
plication may utilize all of the resources of the host
machine of the controller. This results in a DoS
attack on the entire network. The CFG of this attack
is shown in Fig. 13.
9) Message delivery obstruction 1: Lack of authoriza-
tion of applications allows SDN malwares to alter
the list of subscribers to packetIn messages. For
example, App1 and App2 are subscribed to packetIn
messages to the controller. A malware can alter the
subscriber list by remove App2. This prevents App2
from receiving subsequent packetIn messages, thus
hindering its proper functionality. The CFG of this
attack is shown in 14.
10) Message delivery obstruction 2: Applications run-
ning on the SDN controller generally occurs sequen-
tially in a chain. A malicious SDN application in
the chain can drop a packet that was supposed
to be forwarded to an application. This causes a
misconfiguration in the network. The CFG of this
attack is shown in 15.
11) Service chain jamming: Similar to the previous
attack, a malicious application can go into an infinite
loop. This causes the subsequent applications in its
control flow to be halted and the network comes to
a standstill. The CFG of this attack is shown in 16.
12) Unauthorized application management: SDN ap-
plications with maximal authorization provides
maximal network programmability but introduces
new attack vectors. Such applications can cause the
termination of other applications. Such operations
can cripple the network if a critical application like
routing or packet forwarding is terminated. It may
also produce various security threats if a security
function like IDS or firewall is terminated. The CFG
of this attack is shown in 17.
13) Flow rule modification: The primary task of the
controller is to generate flow rules. A malicious SDN
application can modify the flow rules of a controller,
leading to various attacks like MiTM and network
failures. The CFG of this attack is shown in 18.
14) Flow table flushing: A malicious SDN application
can flush all the flow table entries of the switch.
This would cause the switch to issue a packetIn
message for every incoming packet, thus leading to
a degradation in network performance. The CFG of
this attack is shown in 19.
15) Unauthorized network view manipulation: An ad-
vantage of the SDN architecture is that it offers an
overall view of the network topology. Most SDN
controllers lack authorization of applications trying
to modify internal storage. A SDN malware can alter
the network topology stored in the controller, thus
launching a topology poisoning attack. This affects
all the other applications that make decisions based
on this information. The CFG of this attack is shown
in 20.
16) Eavesdropping: The control messages between the
controller and the switches are unencrypted on
most NOSs. Eavesdropping on the messages of the
control channel can reveal information about the
network topology.
17) MiTM on the control channel: A MiTM attacker
can actively modify the flow rules from ”Forward”
to ”Drop” causing the switch to drop desired mes-
sages. The CFG of this attack is shown in 21.
18) Flow-rule flooding: A malicious SDN application
can continuously generate flow rules till the mem-
ory of the switch is filled. Now, the switch cannot
accept any new legitimate flow rules, thus failing
the network. This is an instance of a DoS attack. The
CFG of this attack is shown in 22.
19) Switch firmware abuse: Most OpenFlow switches
run custom firmware implementation s with differ-
ent capabilities. This spawns a new attack where the
a particular flow may be forced to be processed in
the software instead of the hardware by specifying
the source and destination MAC addresses in the
flow. Processing in software is much slower than
hardware processing, thus leading to a degradation
i network performance. The CFG of this attack is
shown in 23.
20) Malformed control message injection: Manipu-

7. 7
Malicious switch
Connect legitimately
to controller
Send Features-reply
message with
different DPIDs
Delayed response
Fig. 7. CFG of switch-table flooding attack on control plane of SDN
Malicious switch
Connection request
with DPID of target
switch
Disconnect target
switch
Fig. 8. CFG of switch-id spoofing attack on SDN
Malicious SDN
application
Send malformed
control message
Degrade
performance
Fig. 9. CFG of various malformed message attacks on SDN
Manipulate system
time
Disconnect legitimate
switches
Fig. 10. CFG of system time manipulation attack on SDN
Spoof packets to
have target's MAC
and IP address
Switch issues
packetIn messages
to controller
HTS table updates
Disconnect legitimate
switches
Fig. 11. CFG of topology poisoning attack on SDN
Malicious SDN app
Calls system exit
function
Controller crashes
Fig. 12. CFG of arbitrary system termination attack on SDN
Malicious SDN app
Allocate infinite
memory to a process
Crashes controller
Fig. 13. CFG of system resource exhaustion attack on SDN
Malicious SDN app
Access list of
packetIn subscribers
Unsubscribe target
app
Target application
crashes
Fig. 14. CFG of a message delivery obstruction attack on SDN
Malicious SDN app
Drops packet without
forwarding
No reply received by
switch
Communication stops
Fig. 15. CFG of another message delivery obstruction attack on SDN
Malicious SDN app
Drops packet without
forwarding
Communication stops
Fig. 16. CFG of service chain jamming attack on SDN
lated control messages may be sent to the switches
to cause the switch to end up in an unpredictable
state, thus rendering it nonoperational. The CFG of
this attack is shown in 24.
21) Data leakage: SDN data plane elements are vulner-
able to side-channel attacks like timing attacks. Such

8. 8
Malicious SDN app
Terminate another
application running
on controller
Fig. 17. CFG of unauthorized application management attack on SDN
Malicious SDN app
Issue a crafted flow
rule
Override flow table
entry
Terminate another
application running
on controller
Fig. 18. CFG of a flow rule modification attack on SDN
Malicious SDN app
Issue control
message to clear all
flow table entries
Mismatch for every
switch entry
Degrade
performance
Fig. 19. CFG of a flow table flush attack on SDN
Malicious SDN app
Modify critical system
variables, tables,
network information
Legitimate
applications crash
Fig. 20. CFG of unauthorized network view manipulation attack on SDN
Receive another
switch's flow rules
from controller
Modify the flow rules
Legitimate
applications crash
Fig. 21. CFG of MiTM attack on control channel of SDN
Malicious SDN
application
Continuously issue
flow rules
Fill flow table of
switch
Degrade
performance
Fig. 22. CFG of flow rule flooding attack on data plane of SDN
Malicious SDN
application
Issue crafted flow
rule
Network flow
processed in
software
Degrade
performance
Fig. 23. CFG of switch firmware abuse attack on SDN
Malicious SDN
application
Send malformed
control message
Degrade
performance
Fig. 24. CFG of malformed message injection attack on SDN
attacks can lead to fingerprinting attacks to compro-
mise privacy. Side-channel attacks can also lead to
loss of sensitive information like access control rules
in the controller.
Combining all the CFGs mentioned above, we construct
an attack CFG for SDN as shown in Fig. 25.
4.3 Future Work
Using ML on the system level operations has showed signif-
icant preliminary success [65, 2]. We plan on extending this
methodology to various other platforms and applications.
4.3.1 Representation of attacks
We will delve deep into each of the security categories
mentioned above (along with other categories) and doc-
ument all the possible attacks in each category. Then we
decompose each attack into its constituent assembly-level
instructions [2]. These assembly-level instructions are repre-
sented in the form of a CFG. We merge the CFGs of all the
categories to form a unified DAG which encompasses all the
known threats in the 5G ecosystem. Some of the detailed
threats in 5G are documented in Tables 1, 2. Similar tables
can be constructed for RAN, SDN and NFV security.

9. 9
Malicious SDN app
Puts control in infinite
loop
Communication
stopped
Drops packet without
forwarding
No reply received by
switch
Issue control
message to clear all
flow table entries
Mismatch for every
entry
Degrade
performance
Disable
important
apps like
packet
forwarding
Calls system exit
function
Crash controller
Allocate infinite
memory to a process
Out of memory error
Modify internal
system variables,
tables, network info
Crash legitimate
apps
Access list of
packetIn subscribers
Unsubscribe target
app
Crash target app
Disable security
critical apps like
firewall, IDS
Issue crafted flow
rule
Override flow table
entry
Existing connection
disallowed
Send malformed
control message
Fill flow table of
switch
Controller passes
packetIn to apps Network flow
processed in
software
Spoof packets to
have target's MAC &
IP addr
Switch issues
packetIn messages
to controller
HTS table updates
All of target's traffic is
routed to attacker
(MiTM)
Alter header of OF
packetIn message
Disconnect legitimate
switches
Connect with
controller
Spoof target switch
(DPID)
Manipulate system
time
Announce OF
version during
handshake
Send incorrect OF
version in packetIn
message
Put incorrect protocol
type in Ethernet
frame
Send malformed OF
message type
Malicious switch
Connect legitimately
to controller
Send
"Features_Reply"
message with
different DPID
Connection request
with DPID of another
legitimate switch
Delayed respponse
Overload control
plane
Switches send lots of
packetIn messages
Send flows to
switches
Drop legitimate
packetIn messages
MiTM: Receive
another switch's
message from
controller
Send modified
message to switch
Fig. 25. Attack DAG on SDN
4.3.2 Machine learning on DAG
After the construction of the DAG, we characterize each
node of the DAG with multiple binary-valued features. We
train multiple ML models like SVM, K-nearest neighbors
and decision trees with the node features. The ML model is
trained to predict new possible branches in the DAG, giving
rise to new attacks. Deep learning methods cannot be used
in this scenario due to the insufficient data.
4.3.3 Implementation on different frameworks
This framework is a general approach which can be exe-
cuted on any application. The algorithm remains the same
but the DAG changes depending on the features and spec-
ifications of the framework. Our immediate focus is to
implement this on a secure instant messaging application,
like Signal or Whatsapp. We aim to test its effectiveness on
different platforms like Android, iOS, Unix, etc. This anal-
ysis will help to comprehend the underlying dependencies
of application layer security on the network and hardware
stacks.
4.3.4 Evaluation of the 5G stack
5G network security is a challenging research problem as
its infrastructure is entirely different from its predecessor.
Many unknown vulnerabilities potentially exist across mul-
tiple levels in the hardware, software and network stacks of

10. 10
TABLE 1
Mobile network security: Evolved Packet Core threats and challenges
Category Threat Description
Availability Flooding an interface Attackers flood an interface resulting in DoS condition (DNS lookup, etc.)
Availability Crashing a network ele-
ment
Attackers crash a network element by sending malformed packets
Confidentiality Eavesdropping Attackers eavesdrop on sensitive data on control and user plane
Confidentiality Data Leakage Unauthorized access to sensitive data on the server
Integrity Traffic modification Attackers modify information during transit (DNS redirection, etc.)
Integrity Data modification Attackers modify data on network element (change the network element configurations)
Control Control the network Attackers control the network via protocol or implementation flaw
Control Compromise of
network element
Attackers compromise of network element via management interface
Malicious insider Insider attacks Insiders make data modification on network elements, make unauthorized changes to network element
configuration, etc.
Theft of service Service free of charge Attackers exploits a flaw to use services without being charged
TABLE 2
Threats and challenges in IP Multimedia Subsystems
Category Threat Description
Availability Flooding an interface Distributed DoS (DDoS)/Telephony DoS (TDoS) via mobile end-points)
Availability Crashing a network element DoS/TDoS via rogue media streams and malformed packets
Confidentiality Eavesdropping Eavesdropping via sniffing the SGi(Gm) interface
Confidentiality Data Leakage Unauthorized access to sensitive data on the IMS Home Subscriber Server (HSS)
Integrity Traffic modification MiTM attack on SGi(Gm) interface
Integrity Data modification Session Initiation Protocol (SIP) messaging impersonation via spoofed SIP messages
Control Control the network Spam over Internet Telephony / unsolicited voice calls resulting in Voice-SPAM/TDoS
Control Compromise of network ele-
ment
Compromise of network element via attacks from external IP networks
Malicious insider Insider attacks Malicious Insider makes unauthorized changes to IMSHSS configurations
Theft of service Service free of charge Theft of Service via SIP messaging impersonation
implementation. We aim to discover these weaknesses using
our algorithm to make the 5G infrastructure safer and more
secure. There are certain classes of attacks that can be easily
evaded in 5G due to the separation of the data plane and
the control plane. Multiple attack and defence measures are
expected to be accelerated in the 5G ecosystem. We expect
to get novel insights into the overall security framework of
5G by probing into these intricacies with ML.
4.3.5 Reinforcement Learning for security
Reinforcement learning (RL) [66] can be utilized to provide
real-time defence solutions. Similarly, it can also be utilized
to come up with real-time attack vectors. We aim to use
RL to study the implications of real-time attack scenarios in
the 5G framework. A defensive or attacking agent can be
deployed in a real-world scenario to learn the inconsisten-
cies in the operations. Multi-agent RL may also prove to be
useful in such scenarios. Counterfactual regret (CFR) [67]
minimization games have shown better results than RL
in certain classes of games (where the environment is not
fully observable to the player) like poker. We would like to
investigate the potential impact of CFR minimization games
in 5G security.
5 EVALUATION PLAN
5.1 Year 1
• Develop a unified framework for analyzing the inter-
connected security vulnerabilities between the hard-
ware, software (microcode, kernel, OS and applica-
tion layers) and network (including, cryptographic
protocols, virtualization layers, and others) stacks
with 5G network architectures.
• Study the dependencies of application layer security
on the network layer security in the 5G framework.
• Analyze the security of cryptographic protocols and
primitives proposed as part of the 5G framework.
• Analyze the security of a mobile application (which
is secure at the application layer) running on 5G. This
will give a deeper insight into the applicability and
usability of the developed tool.
• Utilize deep learning techniques to analyze graphs
representing various attacks and threat models. Re-
cent graphical deep learning analysis tools like
Graph2Vec [68] enables us to use deep learning to
analyze graphs. This has a potential of generating
new methods of analyzing threat models.
5.2 Year 2
• Utilize the developed framework to analyze the
security of multiple 5G-specific applications like
autonomous vehicles, Internet-of-Things and smart
healthcare.
• Extend the existing framework to other broader areas
of security like application security, OS security, etc.

11. 11
5.3 Year 3
• Integrate state-of-the-art methods of ML like RL to
deploy real-time vulnerability detection systems.
• With the advent of 5G, the amount of data being
transferred will increase manifold. We wish to study
the implications of the magnanimous amount of data
transfer on user privacy.
REFERENCES
[1] R. Vannithamby and S. Talwar, Towards 5G: Applications,
requirements and candidate technologies. John Wiley &
Sons, 2017.
[2] T. Saha, N. Aaraj, N. Ajjarapu, and N. K. Jha, “Sharks:
Smart hacking approaches for risk scanning in internet-
of-things and cyber-physical systems based on machine
learning,” IEEE Transactions on Emerging Topics in Com-
puting, 2021.
[3] S. Chen, J. Hu, Y. Shi, Y. Peng, J. Fang, R. Zhao, and
L. Zhao, “Vehicle-to-everything (V2X) services sup-
ported by LTE-based systems and 5G,” IEEE Commu-
nications Standards Magazine, vol. 1, no. 2, pp. 70–76,
2017.
[4] R. Molina-Masegosa and J. Gozalvez, “LTE-V for
sidelink 5G V2X vehicular communications: A new
5G technology for short-range vehicle-to-everything
communications,” IEEE Vehicular Technology Magazine,
vol. 12, no. 4, pp. 30–39, 2017.
[5] C. X. Mavromoustakis, G. Mastorakis, and J. M.
Batalla, Internet of Things (IoT) in 5G mobile technologies.
Springer, 2016, vol. 8.
[6] M. Erol-Kantarci and S. Sukhmani, “Caching and com-
puting at the edge for mobile augmented reality and
virtual reality (AR/VR) in 5G,” in Ad Hoc Networks.
Springer, 2018, pp. 169–177.
[7] K. E. Skouby and P. Lynggaard, “Smart home and
smart city solutions enabled by 5G, IoT, AAI and CoT
services,” in 2014 International Conference on Contempo-
rary Computing and Informatics (IC3I). IEEE, 2014, pp.
874–878.
[8] J. Santos, T. Wauters, B. Volckaert, and F. De Turck,
“Fog computing: Enabling the management and or-
chestration of smart city applications in 5G networks,”
Entropy, vol. 20, no. 1, p. 4, 2018.
[9] J. Brown, T. Saha, and N. K. Jha, “Gravitas: Graphical
reticulated attack vectors for internet-of-things aggre-
gate security,” IEEE Transactions on Emerging Topics in
Computing, 2021.
[10] M. Chen, J. Yang, J. Zhou, Y. Hao, J. Zhang, and
C.-H. Youn, “5G-smart diabetes: Toward personalized
diabetes diagnosis with healthcare big data clouds,”
IEEE Communications Magazine, vol. 56, no. 4, pp. 16–
23, 2018.
[11] M. Chen, J. Yang, Y. Hao, S. Mao, and K. Hwang, “A 5G
cognitive system for healthcare,” Big Data and Cognitive
Computing, vol. 1, no. 1, p. 2, 2017.
[12] S. Latif, J. Qadir, S. Farooq, and M. Imran, “How 5G
wireless (and concomitant technologies) will revolu-
tionize healthcare?” Future Internet, vol. 9, no. 4, p. 93,
2017.
[13] R. Chávez-Santiago, M. Szydełko, A. Kliks, F. Foukalas,
Y. Haddad, K. E. Nolan, M. Y. Kelly, M. T. Masonta, and
I. Balasingham, “5G: The convergence of wireless com-
munications,” Wireless Personal Communications, vol. 83,
no. 3, pp. 1617–1642, 2015.
[14] I. Ahmad, T. Kumar, M. Liyanage, J. Okwuibe,
M. Ylianttila, and A. Gurtov, “5g security: Analysis
of threats and solutions,” in 2017 IEEE Conference on
Standards for Communications and Networking (CSCN).
IEEE, 2017, pp. 193–199.
[15] M. A. Ferrag, L. Maglaras, A. Argyriou, D. Kosmanos,
and H. Janicke, “Security for 4G and 5G cellular
networks: A survey of existing authentication and
privacy-preserving schemes,” Journal of Network and
Computer Applications, vol. 101, pp. 55–82, 2018.
[16] C. Cremers and M. Dehnel-Wild, “Component-based
formal analysis of 5G-AKA: Channel Assumptions and
Session Confusion,” 2019.
[17] B. Bangerter, S. Talwar, R. Arefi, and K. Stewart, “Net-
works and devices for the 5G era,” IEEE Communica-
tions Magazine, vol. 52, no. 2, pp. 90–96, 2014.
[18] J. Ni, X. Lin, and X. S. Shen, “Efficient and se-
cure service-oriented authentication supporting net-
work slicing for 5G-enabled IoT,” IEEE Journal on Se-
lected Areas in Communications, vol. 36, no. 3, pp. 644–
657, 2018.
[19] E. Dubrova, M. Näslund, and G. Selander, “CRC-based
message authentication for 5G mobile technology,” in
2015 IEEE Trustcom/BigDataSE/ISPA, vol. 1. IEEE, 2015,
pp. 1186–1191.
[20] H. Zhang, Y. Cole, L. Ge, S. Wei, W. Yu, C. Lu, G. Chen,
D. Shen, E. Blasch, and K. D. Pham, “ScanMe mobile: a
cloud-based android malware analysis service,” ACM
SIGAPP Applied Computing Review, vol. 16, no. 1, pp.
36–49, 2016.
[21] W. Yu, G. Xu, Z. Chen, and P. Moulema, “A cloud com-
puting based architecture for cyber security situation
awareness,” in 2013 IEEE Conference on Communications
and Network Security (CNS). IEEE, 2013, pp. 488–492.
[22] Z. Chen, G. Xu, V. Mahalingam, L. Ge, J. Nguyen,
W. Yu, and C. Lu, “A cloud computing based network
monitoring and threat detection system for critical in-
frastructures,” Big Data Research, vol. 3, pp. 10–23, 2016.
[23] “Security challenges in next gen-
eration 5G mobile networks,”
https://www.informationsecuritybuzz.com/articles/security-
challenges-next-generation-5G-mobile-networks/.
[24] S. Chen and J. Zhao, “The requirements, challenges,
and technologies for 5G of terrestrial mobile telecom-
munication,” IEEE communications magazine, vol. 52,
no. 5, pp. 36–43, 2014.
[25] F. Boccardi, R. W. Heath, A. Lozano, T. L. Marzetta, and
P. Popovski, “Five disruptive technology directions for
5G,” IEEE Communications Magazine, vol. 52, no. 2, pp.
74–80, 2014.
[26] C.-X. Wang, F. Haider, X. Gao, X.-H. You, Y. Yang,
D. Yuan, H. M. Aggoune, H. Haas, S. Fletcher, and
E. Hepsaydir, “Cellular architecture and key technolo-
gies for 5G wireless communication networks,” IEEE
communications magazine, vol. 52, no. 2, pp. 122–130,
2014.

12. 12
[27] S. Kekki, W. Featherstone, Y. Fang, P. Kuure, A. Li,
A. Ranjan, D. Purkayastha, F. Jiangping, D. Frydman,
G. Verin et al., “MEC in 5G networks,” ETSI white paper,
vol. 28, pp. 1–28, 2018.
[28] Y. C. Hu, M. Patel, D. Sabella, N. Sprecher, and
V. Young, “Mobile edge computing—a key technology
towards 5G,” ETSI white paper, vol. 11, no. 11, pp. 1–16,
2015.
[29] I. Parvez, A. Rahmati, I. Guvenc, A. I. Sarwat, and
H. Dai, “A survey on low latency towards 5G: Ran, core
network and caching solutions,” IEEE Communications
Surveys & Tutorials, vol. 20, no. 4, pp. 3098–3130, 2018.
[30] B. Blanco, J. O. Fajardo, I. Giannoulakis, E. Kafetzakis,
S. Peng, J. Pérez-Romero, I. Trajkovska, P. S. Kho-
dashenas, L. Goratti, M. Paolino et al., “Technology
pillars in the architecture of future 5G mobile networks:
NFV, MEC and SDN,” Computer Standards & Interfaces,
vol. 54, pp. 216–228, 2017.
[31] R. Trivisonno, R. Guerzoni, I. Vaishnavi, and D. Sol-
dani, “SDN-based 5G mobile networks: architecture,
functions, procedures and backward compatibility,”
Transactions on Emerging Telecommunications Technolo-
gies, vol. 26, no. 1, pp. 82–92, 2015.
[32] H.-H. Cho, C.-F. Lai, T. K. Shih, and H.-C. Chao, “Inte-
gration of SDR and SDN for 5G,” IEEE Access, vol. 2,
pp. 1196–1204, 2014.
[33] J. Ordonez-Lucena, P. Ameigeiras, D. Lopez, J. J.
Ramos-Munoz, J. Lorca, and J. Folgueira, “Network
slicing for 5G with SDN/NFV: Concepts, architec-
tures, and challenges,” IEEE Communications Magazine,
vol. 55, no. 5, pp. 80–87, 2017.
[34] M. Geller and P. Nair, “5G security innovation with
cisco,” Whitepaper Cisco Public, pp. 1–29, 2018.
[35] Z. Yan, P. Zhang, and A. V. Vasilakos, “A security and
trust framework for virtualized networks and software-
defined networking,” Security and communication net-
works, vol. 9, no. 16, pp. 3059–3069, 2016.
[36] V. G. Vassilakis, H. Mouratidis, E. Panaousis, I. D.
Moscholios, and M. D. Logothetis, “Security require-
ments modelling for virtualized 5G small cell net-
works,” in 2017 24th International Conference on Telecom-
munications (ICT). IEEE, 2017, pp. 1–5.
[37] A. Hussein, I. H. Elhajj, A. Chehab, and A. Kayssi,
“SDN VANETs in 5G: An architecture for resilient secu-
rity services,” in 2017 Fourth International Conference on
Software Defined Systems (SDS). IEEE, 2017, pp. 67–74.
[38] E. Dubrova and M. Hell, “Espresso: A stream cipher for
5g wireless communication systems,” Cryptography and
Communications, Mar 2017.
[39] T. Saha and V. Sehwag, “Tv-puf: A fast lightweight
aging-resistant threshold voltage puf,” Cryptology
ePrint Archive, 2016.
[40] V. Sehwag and T. Saha, “Tv-puf: a fast lightweight
analog physical unclonable function,” in 2016 IEEE In-
ternational Symposium on Nanoelectronic and Information
Systems (iNIS). IEEE, 2016, pp. 182–186.
[41] X. Zhang, A. Kunz, and S. Schröder, “Overview of 5G
security in 3gpp,” in 2017 IEEE Conference on Standards
for Communications and Networking (CSCN). IEEE, 2017,
pp. 181–186.
[42] K. Fan, Y. Gong, C. Liang, H. Li, and Y. Yang,
“Lightweight and ultralightweight RFID mutual au-
thentication protocol with cache in the reader for IoT in
5G,” Security and Communication Networks, vol. 9, no. 16,
pp. 3095–3104, 2016.
[43] D. Wubben, P. Rost, J. S. Bartelt, M. Lalam, V. Savin,
M. Gorgoglione, A. Dekorsy, and G. Fettweis, “Benefits
and impact of cloud computing on 5G signal process-
ing: Flexible centralization through cloud-RAN,” IEEE
signal processing magazine, vol. 31, no. 6, pp. 35–44, 2014.
[44] M. C. Parker, G. Koczian, F. Adeyemi-Ejeye, T. Quinlan,
S. D. Walker, A. Legarrea, M. S. Siddiqui, E. Escalona,
S. Spirou, D. Kritharidis et al., “Charisma: Converged
heterogeneous advanced 5G cloud-RAN architecture
for intelligent and secure media access,” in 2016 Eu-
ropean Conference on Networks and Communications (Eu-
CNC). IEEE, 2016, pp. 240–244.
[45] P. Demestichas, A. Georgakopoulos, D. Karvounas,
K. Tsagkaris, V. Stavroulaki, J. Lu, C. Xiong, and J. Yao,
“5G on the horizon: Key challenges for the radio-access
network,” IEEE vehicular technology magazine, vol. 8,
no. 3, pp. 47–53, 2013.
[46] X. Duan and X. Wang, “Authentication handover
and privacy protection in 5G hetnets using software-
defined networking,” IEEE Communications Magazine,
vol. 53, no. 4, pp. 28–35, 2015.
[47] ——, “Fast authentication in 5G hetnet through sdn
enabled weighted secure-context-information transfer,”
in 2016 IEEE International Conference on Communications
(ICC). IEEE, 2016, pp. 1–6.
[48] M. G. Pérez, A. H. Celdrán, F. Ippoliti, P. G. Giardina,
G. Bernini, R. M. Alaez, E. Chirivella-Perez, F. J. G.
Clemente, G. M. Pérez, E. Kraja et al., “Dynamic recon-
figuration in 5G mobile networks to proactively detect
and mitigate botnets,” IEEE Internet Computing, vol. 21,
no. 5, pp. 28–36, 2017.
[49] M. S. Siddiqui, E. Escalona, E. Trouva, M.-A. Kourtis,
D. Kritharidis, K. Katsaros, S. Spirou, C. Canales, and
M. Lorenzo, “Policy based virtualised security archi-
tecture for SDN/NFV enabled 5G access networks,” in
2016 IEEE Conference on Network Function Virtualization
and Software Defined Networks (NFV-SDN). IEEE, 2016,
pp. 44–49.
[50] K. Norrman, M. Näslund, and E. Dubrova, “Protecting
imsi and user privacy in 5G networks,” in Proceedings
of the 9th EAI International Conference on Mobile Multi-
media Communications. ICST (Institute for Computer
Sciences, Social-Informatics and . . . , 2016, pp. 159–166.
[51] D. Basin, J. Dreier, L. Hirschi, S. Radomirovic, R. Sasse,
and V. Stettler, “A formal analysis of 5G authentica-
tion,” in Proceedings of the 2018 ACM SIGSAC Conference
on Computer and Communications Security. ACM, 2018,
pp. 1383–1396.
[52] S. Lal, T. Taleb, and A. Dutta, “NFV: Security threats
and best practices,” IEEE Communications Magazine,
vol. 55, no. 8, pp. 211–217, 2017.
[53] W. Yang and C. Fung, “A survey on security in network
functions virtualization,” in 2016 IEEE NetSoft Confer-
ence and Workshops (NetSoft). IEEE, 2016, pp. 15–19.
[54] D. V. Bernardo and B. B. Chua, “Introduction and
analysis of SDN and NFV security architecture (SN-
SECA),” in 2015 IEEE 29th International Conference

13. 13
on Advanced Information Networking and Applications.
IEEE, 2015, pp. 796–801.
[55] M.-W. Shih, M. Kumar, T. Kim, and A. Gavrilovska, “S-
NFV: Securing NFV states by using sgx,” in Proceedings
of the 2016 ACM International Workshop on Security in
Software Defined Networks & Network Function Virtual-
ization. ACM, 2016, pp. 45–48.
[56] A. Aljuhani and T. Alharbi, “Virtualized network func-
tions security attacks and vulnerabilities,” in 2017 IEEE
7th Annual Computing and Communication Workshop and
Conference (CCWC). IEEE, 2017, pp. 1–4.
[57] T. Saha et al., “Machine learning-based efficient and
generalizable cybersecurity frameworks,” 2022.
[58] T. Saha, N. Aaraj, and N. K. Jha, “Machine learning
assisted security analysis of 5g-network-connected sys-
tems,” IEEE Transactions on Emerging Topics in Comput-
ing, 2022.
[59] T. Carpay and P. Lontorfos, “Whatsapp end-to-end
encryption: Are our messages private?” 2019.
[60] “A Linux Foundation Collaborative Project. OpenDay-
light SDN Controller,” https://www.opendaylight.org.
[61] “FloodLight Open SDN Controller,” https:
//floodlight.openflowhub.org/.
[62] NOX Repo, “The POX Controller.” https://github.
com/noxrepo/pox.
[63] N. McKeown, T. Anderson, H. Balakrishnan,
G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and
J. Turner, “Openflow: enabling innovation in campus
networks,” ACM SIGCOMM Computer Communication
Review, vol. 38, no. 2, pp. 69–74, 2008.
[64] C. Yoon, S. Lee, H. Kang, T. Park, S. Shin, V. Yeg-
neswaran, P. Porras, and G. Gu, “Flow wars: Sys-
temizing the attack surface and defenses in software-
defined networks,” IEEE/ACM Transactions on Network-
ing (TON), vol. 25, no. 6, pp. 3514–3530, 2017.
[65] T. Saha, N. Aaraj, and N. K. Jha, “System and method
for security in internet-of-things and cyber-physical
systems based on machine learning,” Jun. 23 2022, uS
Patent App. 17/603,453.
[66] R. S. Sutton, A. G. Barto et al., Introduction to Reinforce-
ment Learning. MIT press Cambridge, 1998, vol. 2.
[67] M. Zinkevich, M. Johanson, M. Bowling, and C. Pic-
cione, “Regret minimization in games with incomplete
information,” in Advances in neural information process-
ing systems, 2008, pp. 1729–1736.
[68] A. Narayanan, M. Chandramohan, R. Venkatesan,
L. Chen, Y. Liu, and S. Jaiswal, “graph2vec: Learning
distributed representations of graphs,” 2017.