Zanna

A Multi-Layer Approach to Preventing Wireless
Network Impersonation Attacks
A thesis submitted in fulfilment of the requirements for the degree of Doctor of Philosophy
Paul Zanna
School of Engineering
College of Science, Technology, Engineering and Maths
RMIT University
December 2022
Declaration
I certify that except where due acknowledgement has been made, this research is that of the
author alone; the content of this research submission is the result of work which has been
carried out since the official commencement date of the approved research program; any
editorial work, paid or unpaid, carried out by a third party is acknowledged; and, ethics
procedures and guidelines have been followed.
In addition, I certify that this submission contains no material previously submitted for award
of any qualification at any other university or institution, unless approved for a joint-award
with another institution, and acknowledge that no part of this work will, in the future, be used
in a submission in my name, for any other qualification in any university or other tertiary
institution without the prior approval of the University, and where applicable, any partner
institution responsible for the joint-award of this degree.
I acknowledge that copyright of any published works contained within this thesis resides with
the copyright holder(s) of those works.
I give permission for the digital version of my research submission to be made available on the
web, via the University’s digital research repository, unless permission has been granted by the
University to restrict access for a period of time.
I acknowledge the support I have received for my research through the provision of an
Australian Government Research Training Program Scholarship.
Paul Zanna
14th December 2022
i
Acknowledgements
I wish to acknowledge and express my sincere appreciation to those that have provided support,
guidance, and the opportunity to undertake my PhD at RMIT University.
Firstly, I would like to express my sincere gratitude to my supervisor, mentor and friend, Dr
P.J Radcliffe, without whom none of this would have been possible. His tireless support of my
candidature and belief in my abilities, when others did not, is a debt I can never repay.
To Professor Dinesh Kumar, whose passion for research and exploring the unknown were a
guiding light and a constant reminder of how research should be done.
Thank you to Dr Samuel Ippolito, Dr Glenn Matthews and Dr Karina Gomez-Chavel for their
guidance and support. To my fellow PhD candidates at RMIT with whom I shared this journey,
thank you for allowing me to be a part of such an enjoyable and fulfilling experience.
Finally, and most importantly, to my family, thank you for your understanding, patience, and
support.
Please Note: An editor has NOT been used in the construction of this thesis.
ii
Table of Contents
DECLARATION .................................................................................................................................................... I
ACKNOWLEDGEMENTS..................................................................................................................................II
TABLE OF CONTENTS.................................................................................................................................... III
LIST OF FIGURES ...........................................................................................................................................VII
LIST OF TABLES .............................................................................................................................................. IX
LIST OF ABBREVIATIONS............................................................................................................................... X
ABSTRACT ............................................................................................................................................................1
CHAPTER 1. INTRODUCTION .........................................................................................................................3
1.1 BACKGROUND ....................................................................................................................................................3

1.2 RESEARCH MOTIVATION ......................................................................................................................................4
1.3 RESEARCH OBJECTIVES.........................................................................................................................................7
1.4 RESEARCH HYPOTHESIS ........................................................................................................................................7
1.5 RESEARCH QUESTIONS.........................................................................................................................................8
1.6 RESEARCH METHODOLOGY ...................................................................................................................................9
1.6.1 Literature Review Methodology ............................................................................................................9
1.7 INVESTIGATION METHODOLOGY ..........................................................................................................................10
1.7.1 Methodology for RQ1 ..........................................................................................................................10
1.8 THESIS STRUCTURE ...........................................................................................................................................11
CHAPTER 2. LITERATURE REVIEW ...........................................................................................................14
2.1 INTRODUCTION ................................................................................................................................................14

2.2 ACCESSING WIRELESS DATA ...............................................................................................................................15
2.2.1 Layer 1 (PHY)........................................................................................................................................16
2.2.2 Software Defined Radio .......................................................................................................................18
2.2.3 Layer 2 (MAC) ......................................................................................................................................21
2.2.4 Monitor Mode and Probes...................................................................................................................23
2.2.5 Wireless Driver Integration ..................................................................................................................25
2.2.6 Software Defined Networking .............................................................................................................26
2.3 WIRELESS DEVICE IDENTIFICATION .......................................................................................................................29
2.3.1 MAC Layer Device Identification ..........................................................................................................31
2.3.2 Radio Frequency Fingerprinting...........................................................................................................32
2.3.3 Classification Algorithms and Methodologies .....................................................................................37
iii
2.4 IEEE 802.11 IMPERSONATION ATTACKS ..............................................................................................................39
2.4.1 Impersonation Attack Detection..........................................................................................................41
2.4.2 Impersonation Attack Defences...........................................................................................................45
2.5 DEFENSIVE TACTICS AND STRATEGY......................................................................................................................46
2.6 REVIEW SUMMARY ...........................................................................................................................................49
2.6.1 Wireless Data Access ...........................................................................................................................50
2.6.2 Software Defined Networking .............................................................................................................50
2.6.3 Wireless Device Identification..............................................................................................................51
2.6.4 IEEE 802.11 Impersonation Attacks .....................................................................................................51
2.6.5 Defence Tactics and Strategies ............................................................................................................52
2.6.6 Conclusion ............................................................................................................................................53
CHAPTER 3. AN SDN IEEE 802.11 FRAME PROCESSING PIPELINE ...................................................54
3.1 INTRODUCTION ................................................................................................................................................54

3.2 COMPARING OPENFLOW AND P4 ........................................................................................................................55
3.2.1 Overview ..............................................................................................................................................55
3.2.2 Common Evaluation Platform .............................................................................................................56
3.2.3 P4 Compiler Design ..............................................................................................................................57
3.2.4 Performance Comparison ....................................................................................................................58
3.2.5 SDN Model Evaluation Summary .........................................................................................................61
3.3 INTEGRATING P4 INTO THE IEEE 802.11 DATA PLANE............................................................................................61
3.3.1 Overview ..............................................................................................................................................61
3.3.2 Existing Wireless SDN Methods ...........................................................................................................61
3.3.3 Creating a Linux Kernel Module...........................................................................................................63
3.3.4 P4 Parser Code .....................................................................................................................................65
3.3.5 Evaluation ............................................................................................................................................66
3.4 CHAPTER SUMMARY..........................................................................................................................................68
CHAPTER 4. INCORPORATING PHY LAYER FEATURES......................................................................71
4.1 INTRODUCTION ................................................................................................................................................71

4.2 DEVELOPMENT PLATFORM ARCHITECTURE ............................................................................................................73
4.3 RF FEATURES INCOMPATIBLE WITH AN SDR OR WAP .............................................................................................74
4.4 RF FEATURE EXTRACTION...................................................................................................................................76
4.4.1 Carrier Phase Offset .............................................................................................................................77
4.4.2 Channel Gain........................................................................................................................................78
4.4.3 Pilot Sub-carrier Offset ........................................................................................................................78
4.5 P4 INTERFACE ..................................................................................................................................................79
4.6 FEATURE EVALUATION .......................................................................................................................................81
4.7 CHAPTER SUMMARY..........................................................................................................................................83
iv
CHAPTER 5. WIRELESS DEVICE IDENTIFICATION...............................................................................85
5.1 INTRODUCTION ................................................................................................................................................85

5.1.1 Algorithm Comparison .........................................................................................................................86
5.1.2 P4 Device Identification Architecture ..................................................................................................87
5.1.3 Rule-Based Machine Learning .............................................................................................................87
5.1.4 One-Class Classification .......................................................................................................................88
5.1.5 Multiplexed One-Class Classification ...................................................................................................89
5.2 TRAINING THE ALGORITHM .................................................................................................................................90
5.2.1 Classifier Rulesets ................................................................................................................................91
5.2.2 Covering ...............................................................................................................................................93
5.2.3 Genetic Algorithm ................................................................................................................................93
5.2.4 Rule Deletion ........................................................................................................................................94
5.2.5 Option and Parameters .......................................................................................................................95
5.3 PREDICTION ALGORITHM ...................................................................................................................................95
5.3.1 Time Series Errors ................................................................................................................................96
5.4 EVALUATION ....................................................................................................................................................96
5.4.1 Simulation Results................................................................................................................................96
5.4.2 Real time WAP Results .......................................................................................................................102
5.5 CHAPTER SUMMARY........................................................................................................................................105
CHAPTER 6. DEFENDING AGAINST IMPERSONATION ATTACKS ..................................................108
6.1 INTRODUCTION ..............................................................................................................................................108

6.2 ATTACK DETECTION ALGORITHM .......................................................................................................................109
6.2.1 OODA Loops .......................................................................................................................................110
6.2.2 Kill Chain State Machine ....................................................................................................................112
6.2.3 P4 Support API Functions ...................................................................................................................113
6.2.4 Countermeasures ...............................................................................................................................114
6.3 EVALUATION ..................................................................................................................................................115
6.3.1 Deauthentication / Disassociation DoS Attacks ................................................................................115
6.3.2 Credential Cracking............................................................................................................................116
6.3.3 Evil Twin / Rogue Access Point ..........................................................................................................117
6.3.4 Authentication / Association Flood Attacks.......................................................................................118
6.4 CHAPTER SUMMARY........................................................................................................................................118
CHAPTER 7. CONCLUSION AND FUTURE WORK .................................................................................120
7.1 CONCLUSION .................................................................................................................................................120

7.1.1 Contribution 1 ....................................................................................................................................120
7.1.2 Contribution 2 ....................................................................................................................................121
7.1.3 Contribution 3 ....................................................................................................................................121
v
7.1.4 Contribution 4 ....................................................................................................................................122
7.2 LIMITATIONS ..................................................................................................................................................122
7.3 FUTURE WORK...............................................................................................................................................122
REFERENCES ...................................................................................................................................................124
APPENDIX A – PUBLICATIONS ...................................................................................................................144
APPENDIX B – P4 SOURCE CODE ...............................................................................................................145
vi
List of Figures
FIGURE 1.1: DEAUTHENTICATION ATTACK MESSAGE FLOW ...................................................................................................5

FIGURE 1.2: VARIOUS COMMERCIALLY AVAILABLE DE-AUTHENTICATOR DEVICES .......................................................................6
FIGURE 1.3: PUBLICATION YEAR OF CITED LITERATURE .......................................................................................................10
FIGURE 2.1: INTERFRAME SPACING RELATIONSHIPS ...........................................................................................................19
FIGURE 2.2:FIELDS IN AN IEEE 802.11 DATA FRAME .......................................................................................................22
FIGURE 2.3: IEEE 802.11 MANAGEMENT FRAME INFORMATION ELEMENT..........................................................................23
FIGURE 2.4: SYMBOLIC RF TRANSMITTER CHAIN REPRESENTATION ......................................................................................33
FIGURE 2.5: COMPONENTS OF JOHN BOYD'S OODA LOOP ................................................................................................48
FIGURE 2.6: A COMPARISON OF OODA LOOP AND NIST 800-39 CONCEPTS ........................................................................49
FIGURE 3.1: THE ZODIAC FX SDN SWITCH HARDWARE .....................................................................................................56
FIGURE 3.2: MAJOR COMPONENTS OF THE P4 COMPILER ARCHITECTURE..............................................................................58
FIGURE 3.3: PERFORMANCE COMPARISON OF THE UDP PROTOCOL .....................................................................................59
FIGURE 3.4: PERFORMANCE COMPARISON OF THE TCP PROTOCOL ......................................................................................60
FIGURE 3.5: THE OVS INTEGRATION ARCHITECTURE .........................................................................................................62
FIGURE 3.6: THE WIRELESS P4 INTEGRATION IN THE LINUX NETWORK PATH ..........................................................................64
FIGURE 3.7: WIRELESS P4 HEADER BLOCK PROVIDES THE IEEE 802.11 FIELD DEFINITIONS. .....................................................65
FIGURE 3.8: WP4 CALL DURATION WITH DIFFERENT FRAME SIZES ........................................................................................67
FIGURE 4.1: PROPOSED SYSTEM ARCHITECTURE WITH COMPONENT INTERACTIONS .................................................................72
FIGURE 4.2: ANALOG DEVICES ADRV9361-Z7035 HARDWARE .......................................................................................73
FIGURE 4.3: ANALOG DEVICES ADRV9361-Z7035 HARDWARE BLOCK DIAGRAM..................................................................74
FIGURE 4.4: SYMBOLIC REPRESENTATION OF THE OFDM DEMODULATION PROCESS ...............................................................76
FIGURE 4.5: THE IEEE 802.11A DATA FRAME STRUCTURE ................................................................................................77
FIGURE 4.6: INTEGRATION OF THE P4 DATA PLANE MODULE ..............................................................................................79
FIGURE 4.7: WIRELESS P4 HEADER BLOCK DEFINITION WITH RF FEATURES ............................................................................80
FIGURE 4.8: COMPARISON OF THE CARRIER PHASE OFFSET FROM VARIOUS DEVICES ...............................................................81
FIGURE 4.9: COMPARISON OF THE VECTOR MAGNITUDE FROM VARIOUS DEVICES ..................................................................82
FIGURE 4.10: COMPARISON OF THE PILOT SUB-CARRIER OFFSET FROM VARIOUS DEVICES .......................................................82
FIGURE 4.11: COMPARISON OF THE VECTOR MAGNITUDE TO PILOT OFFSET FROM VARIOUS DEVICES ........................................82
FIGURE 4.12: COMPARISON OF THE VECTOR MAGNITUDE TO PHASE OFFSET FROM VARIOUS DEVICES .......................................82
FIGURE 5.1: THE MOCC DEVICE IDENTIFICATION ARCHITECTURE .........................................................................................87
FIGURE 5.2: COMPONENT LEVEL REPRESENTATION OF THE MULTIPLEX ONE-CLASS CLASSIFIER SYSTEM ......................................88
FIGURE 5.3: PILOT OFFSET VALUES OF KNOWN (POSITIVE) AND UNKNOWN (NEGATIVE) DEVICES. ..............................................98
FIGURE 5.4: PHASE OFFSETS VALUES OF KNOWN (POSITIVE) AND UNKNOWN (NEGATIVE) DEVICES.............................................98
FIGURE 5.5: MAGNITUDE SQUARED VALUES OF KNOWN (POSITIVE) AND UNKNOWN (NEGATIVE) DEVICES. ..................................99
FIGURE 5.6: RSSI VALUES OF KNOWN (POSITIVE) AND UNKNOWN (NEGATIVE) DEVICES. ..........................................................99
vii
FIGURE 5.7: COMPARISON OF RSSI AND MAGNITUDE SQUARED VALUES OF KNOWN (POSITIVE) AND UNKNOWN (NEGATIVE) DEVICES.
....................................................................................................................................................................101
FIGURE 5.8: ROC OF DEVICE PROBABILITY THRESHOLD. ...................................................................................................102
FIGURE 5.9: MOCC LEARNING CURVE DURING THE FIRST 2000 IEEE 802.11 FRAMES. ........................................................103
FIGURE 5.10: VARIATION IN ACCURACY DURING MOVEMENT. ...........................................................................................104
FIGURE 6.1: SYMBOLIC REPRESENTATION OF THE WIDD ARCHITECTURE .............................................................................108
FIGURE 6.2: WIDD FLOW DIAGRAM IMPLEMENTED IN P4................................................................................................109
FIGURE 6.3: MAPPING OF THE OODA LOOP STAGES TO WIDD FUNCTIONS. .......................................................................111
FIGURE 6.4: DEAUTHENTICATION KCSM STATE DIAGRAM................................................................................................113
FIGURE 6.5: DISASSOCIATION KCSM STATE DIAGRAM.....................................................................................................113
FIGURE 6.6: AUTHENTICATION FLOOD KCSM STATE DIAGRAM .........................................................................................113
FIGURE 6.7: ASSOCIATION FLOOD KCSM STATE DIAGRAM ...............................................................................................113
viii
List of Tables
TABLE 1.1: LITERATURE SOURCES AND USAGE ....................................................................................................................9

TABLE 2.1: WIRELESS DEVICE IDENTIFYING FEATURES THAT HAVE PREVIOUSLY BEEN IDENTIFIED IN THE LITERATURE ......................31
TABLE 2.2: RF IDENTIFICATION ALGORITHMS DISCUSSED IN THE LITERATURE ..........................................................................38
TABLE 2.3: WIRELESS NETWORK ATTACK METHODS...........................................................................................................40
TABLE 3.1: PERCENT OF PACKETS LOST WHEN USING THE TCP PROTOCOL .............................................................................60
TABLE 3.2: THE IMPACT OF LINUX KERNEL PERFORMANCE WHEN USING THE WP4 KERNEL MODULE ..........................................66
TABLE 3.3: THE NETWORK THROUGHPUT IMPACT WHEN USING THE WP4 KERNEL MODULE .....................................................67
TABLE 4.1: TYPE II ERROR SCORES OF EACH RF FEATURE USING ONLY POSITIVE INSTANCES .......................................................83
TABLE 5.1: COMMON CLASSIFICATION ALGORITHM ACCURACY COMPARISON .........................................................................86
TABLE 5.2: INDIVIDUAL VALUE IN THE MOCC RULE METADATA ...........................................................................................92
TABLE 5.3: MOCC CONFIGURATION PARAMETERS............................................................................................................94
TABLE 5.4: CONFUSION MATRIX, P > 55% ....................................................................................................................100
TABLE 5.5: TYPE I & II ERROR SCORES USING BOTH POSITIVE AND NEGATIVE INSTANCES .........................................................100
TABLE 6.1: STATE MACHINE INPUTS.............................................................................................................................111
TABLE 6.2: STATE MACHINE OUTPUTS ..........................................................................................................................112
TABLE 6.3: SUCCESS RATE OF DEVICE IDENTIFICATION PROCESS .........................................................................................116
ix
List of Abbreviations
ADC Analog to Digital Conversion

AES Advanced Encryption Standard
AGC Automatic Gain Control
AXI Advanced Extensible Interface
BIP Broadcast/Multicast Integrity Protocol
BSS Basic Service Set
BSSID Basic Service Set Identifier
CCMP CCM Mode Protocol
CFR Channel Frequency Response
CIR Channel Impulse Response
CKC Cyber Kill Chain
CRC Cyclic Redundancy Check
CSI Channel State Information
CTS Clear to Send
DAC Digital to Analog Converter
DHCP Dynamic Host Configuration Protocol
DoS Denial-of-Service
ESS Extended Service Set
ESSID Extended Service Set Identifier
FFT Fast Fourier Transform
FPGA Field Programmable Gate Array
IDS Intrusion Detection System
IE Information Element
IEEE Institute of Electrical and Electronics Engineers
IGTK Integrity Group Temporal Key
IoT Internet of Things
KNN K Nearest Neighbour
LKM Linux Kernel Module
LNA Low Noise Amplifier
LPWAN Low Power Wide Area Network
MAC Media Access Control
MCC Matthews Correlation Coefficient
MIMO Multiple Input Multiple Output
MITM Man-in-the-Middle
ML Machine Learning
MOCC Multiplexed One-Class Classifier
NIC Network Interface Card
NIDS Network Intrusion Detection System
x
NIST National Institute of Standards and Technology
NN Neural Network
OFDM Orthogonal Frequency Division Multiplexing
OOB Out of Band
OODA Observe-Orient-Decide-Act
OSI Open Systems Interconnection
OUI Organisationally Unique Identifier
PA Power Amplifier
PLCP Physical Layer Convergence Procedure
PMD Physical Medium Dependent
PMF Protected Management Frames
PNL Preferred Network List
PPDU PLCP Protocol Data Unit
PSK Pre-Shared Key
RFO Radio Frequency Oscillator
RNN Recurrent Neural Networks
RSSI Received Signal Strength Indicator
RTS Ready to Send
SDN Software Defined Network
SDR Software Defined Radio
SFD Start Frame Delimiter
SIFS Short Inter-Frame Spacing
SNR Signal to Noise Ratio
SoC System-on-a-Chip
SSID Service Set Identifier
SVM Support Vector Machine
TKIP Temporal Key Integrity Protocol
USRP Universal Software Radio Peripheral
VCO Voltage-controlled Oscillator
WAP Wireless Access Point
WEP Wired Equivalent Privacy
WAN Wide Area Network
WLAN Wireless Local Area Network
WP4 Wireless P4
WPA Wi-Fi Protected Access
xi
Abstract
Complex and challenging to secure, IEEE 802.11 networks have become indispensable to
modern communications. However, continuous security threats, large data volumes, and ever-
increasing availability requirements have created an ongoing burden for network operators.
Various security enhancements have been made since the release of the original IEEE 802.11
standard in 1997, and these have considerably improved the effectiveness of the authentication
and encryption methods. Nevertheless, due to the broadcast nature of the medium, these
changes have not diminished the simplicity of monitoring data. This concern is unique to
wireless networks because control messages are generally visible. These management frames
often become the target of Denial-of-Service (DoS) attacks. This situation, unfortunately, has
left network operators in an impossible position. However, as this research demonstrates, this
need not always be the case.
This thesis’s original contribution to knowledge is a novel system for preventing IEEE 802.11
impersonation attacks. The key findings are that by correctly identifying devices and applying
behavioural models, Denial-of-Service attacks can be pre-empted and neutralised. Using an
optimised combination of radio frequency characteristics, Media Access Control (MAC) layer
parameters and probed responses show that device identification can be as high as 99%. This
input combination utilises a new algorithm that determines the features to be evaluated from
the multiple layers of an IEEE 802.11 frame. Building upon a reliable device identity, a novel
algorithm has also been developed for mitigating Denial-of-Service attacks using behavioural
analytics and defensive countermeasures based on cybersecurity operations strategy to evaluate
attacker actions and analyse evolving situations in real time.
A common approach is to start with the MAC layer of an IEEE 802.11 frame, containing the
device-specific capability and identification information. However, the MAC layer alone is not
enough to identify easily forged IEEE 802.11 frames. That is not to say that the MAC layer
cannot contribute to device identification, just that it should not be trusted in isolation.
Additionally, the MAC layer provides information about the device vendor and the chipset
model, which can also help to detect a mismatch with the information extracted from the
physical layer.
While the broadcast nature of wireless networking creates numerous challenges, it also
provides some unique benefits. Radio frequency signals vary from device to device and are
impacted significantly by the environment. Such variations present an opportunity for
1
“fingerprinting” individual devices. This thesis shows that such distinctions can become an
accurate and reliable identification method when combined with other attributes. The difficulty,
however, has been accessing the raw radio frequency information within a Wireless Access
Point (WAP). The baseband processing of the radio frequency signal is locked deep within the
wireless networking chip and unavailable to outside processes. By implementing the baseband
logic in a Field Programmable Gate Array (FPGA), it is possible to extract radio frequency
information for upstream processing. As demonstrated, combining this radio frequency data
with MAC layer elements allows the combined evaluation of several data points.
A Denial-of-Service attack impacts all parties in a wireless network and, by its very nature, is
a malicious undertaking. Because of this, one may believe they would be simple to detect.
However, wireless Denial-of-Service attack detection is difficult because they commonly
abuse legitimate functions. Therefore, it is not enough to base decisions independently on
identity or behaviour. Numerous variables must be evaluated in real time to detect and mitigate
an IEEE 802.11 Denial-of-Service attack effectively.
Using a variant of the Observe-Orient-Decide-Act (OODA) loop, the Wireless Access Point
can evaluate its surroundings incorporating all visible devices, associated or not, to maintain a
real time threat matrix. In addition to passive sampling, which evaluates data from all devices
in the broadcast range, this novel approach detects changes using active and pre-emptive
methods by assessing prompts issued by an attacker reconnaissance algorithm. Finally,
countermeasures act to neutralise attacks. This multi-tier approach provides a powerful
technique for protecting the Wireless Access Point’s network stack, thereby defending against
various Denial-of-Service attacks.
In summary, this thesis presents a clear and definitive research outcome that advances the
understanding of IEEE 802.11 impersonation attacks and delivers a set of original mechanisms
for effectively mitigating them. It also offers newfound knowledge of the device identification
methods currently employed and how these compare to the new techniques. These new
algorithms also have the potential to extend far beyond IEEE 802.11 networks to other wireless
technologies such as Bluetooth, LoRa and 5G. Finally, it provides new tools and techniques to
aid future research in this area significantly and, by doing so, assist in developing more reliable,
secure, and efficient wireless networks.
2
Chapter 1.
Introduction
1.1 Background
The IEEE 802.11 group of standards [1] has become the most common method for wireless
connectivity, with an estimated one billion access points and almost one hundred billion client
devices [2]. First released in 1997, there have been numerous revisions to improve
performance, reliability, and security. This technology, more commonly known by the
trademark name Wi-Fi®, allows devices to interact with the outside world in a way that would
not have been possible without it.
An obvious benefit of wireless networking is mobility. The desire to be untethered is why many
of today's Internet connected devices do not even provide wired network connectivity options.
It is impossible to see innovations, such as the smartphone, becoming possible without the
IEEE 802.11 wireless technologies.
In addition to mobility, the reduction in infrastructure costs has made wireless networking an
attractive option for domestic and enterprise users by negating the need for Ethernet switches
and complex cabling. Furthermore, providing Internet access to customers in public spaces
such as restaurants and cafés has been a value-add for businesses. A customer who spends more
time in-store has the potential to purchase more, so such services have become a simple, low-
cost option for improving revenue. Such services would be untenable if a physical cable were
required, nor would it have been an attractive option before the recent advances in
miniaturisation.
As with many technological innovations, advancements in miniaturisation, volume-based

pricing and socioeconomic trends often drive adoption. The availability of small, low-powered
wireless transceivers has led to a proliferation of connected devices. These devices commonly
employ tiny all-in-one microchips, such as the ESP8266 System-on-a-Chip (SoC) [3],
providing connectivity to stand-alone products. One group of devices, commonly known as the
Internet of Things (IoT), would not have been possible without wireless networks [4].
The introduction of the smartphone and IoT has revolutionised human interactivity, not only
in connectivity but the evolution of Homo Digitalis [5]. Our desire for instant access goes
3
beyond that of ourselves. This need expands to that of our possessions; it is our fridges and air
conditioning, our light bulbs, televisions, and even our bodies. While technologies like
Bluetooth® [6] may play an essential role for bound devices, like speakers, IEEE 802.11
networking is the backbone of our homes and office communications.
1.2 Research Motivation

Our reliance on wireless networking in our everyday lives is becoming more apparent as we
discover various security, performance, and reliability issues [7]. We now transmit some of our
most guarded secrets, such as medical data, financial transactions, and corporate intellectual
property, accepting certain risks to our online privacy to make our life more convenient [8].
Unfortunately, wireless networks are under constant threat of Denial-of-Service (DoS),
eavesdropping, spoofing, message falsification, injection, and Man-In-The-Middle (MITM)
attacks [9]. The ability to construct and broadcast false messages effortlessly makes an IEEE
802.11 wireless network exceptionally vulnerable [10].
Impersonating a legitimate wireless client primarily involves mimicking its Media Access
Control (MAC) address, a unique identifier assigned to network interfaces for communications
on the physical network segment. By monitoring the network, the attacker can capture the
MAC addresses of the wireless clients and the Wireless Access Point (WAP). Each packet sent
over the network includes the MAC address of the sending device and the intended recipient,
so this information is readily available to anyone who can capture the packets. Once the attacker
has a target MAC address, they can configure their network adapter to use that MAC address
instead of its own. This effectively makes the attacker's device appear to be the target device.
False frame generation then allows the attacker's machine to impersonate the authorised user
and issue commands that impact that user’s network connection.
Such attacks are insidious as they use legitimate functions that cannot be disabled. While it is
possible to include more advanced security features in high-end devices, most IoT devices do
not have the capacity for such security controls. Due to limited battery power, these devices
cannot withstand resource-targeted attacks, such as battery depletion attacks [11].
Unfortunately, such attacks happen alarmingly regularly, and the tools used by hackers are
simple and readily available [12].
It is a common misconception that “Hacking” or security attacks are the domain of elite,
technically advanced criminals, but this is not the case. The tools and techniques required to
4
perform such attacks are abundant due to the Internet. Entire operating systems, such as Kali
Linux [13], have been created as dedicated, turn-key security testing platforms. The general
availability has enabled a new cohort of individuals with the means to inflict significant harm,
whether intentionally or not. This group, often referred to as “Script Kiddies" [14], lacks the
understanding and technical abilities to comprehend the hazardous nature of such powerful
tools.
The impersonation based DoS attack aimed at the IEEE 802.11 protocol is of particular interest
because of the unique characteristics of the wireless medium. The purpose of a DoS attack, as
defined by the National Institute of Standards and Technology (NIST), is the prevention of
authorised access to resources or the delay of time-critical operations. However, wireless DoS
attacks are different, unlike the more common transport-based DoS attacks, whose goal is to
exhaust resources and make a service unusable. A wireless DoS attack inhibits connectivity
while leaving the service intact. The server side, which in this case is a WAP, remains fully
functional and open to new connections, but existing clients are instructed that the service is
no longer required. The WAP does not know that it is not an actual client requesting to
disconnect but, instead, a third party impersonating the client. One of the most common attacks
of this type is the deauthentication attack.
Attacker Client WAP
Authentication Request
Authentication Response
Association Request
Association Response
Data
Deauthentication Request
Deauthentication Response
Figure 1.1: Deauthentication attack message flow
A deauthentication attack sees an attacker impersonate connected clients, advising that they no
longer require the current connection. As shown in Figure 1.1, sending deauthentication
requests on behalf of the client, the WAP will forcibly disconnect a client, which is in line with
the IEEE 802.11 standard. If such an attack is directed at all clients, the entire network becomes
unusable, as legitimate clients will continue to be disconnected. Such attacks have become so
5
simple and effective that it is possible to download pre-configured deauthentication software
or purchase commercial hardware (Figure 1.2), thereby requiring little to no technical skills
[15]. This ability to target any wireless network and render it useless relatively quickly is of
significant concern.
Image Removed
Figure 1.2: Various commercially available De-authenticator devices
Additionally, given our increased reliance on wireless network access for commercial
purposes, large-scale disruptions could substantially affect the economy. Wireless networking
for Point of Sale (POS), Automatic Teller Machines (ATM) and payment terminal equates to
a real financial impact for such an attack. However, the impact goes beyond just economic
consequences. It can also impact our health and safety.
The deliberate disruption of network connectivity can potentially have a life-threatening impact
on the users of healthcare devices, vehicle systems, and safety equipment. As we become more
connected, we rely on such devices for convenience and wellbeing. The addition of wireless
connectivity to healthcare devices in hospitals and clinics has increased concern. Innovations
such as vital sign monitoring, insulin pumps, and compliance monitoring may have improved
patient care, but they have also created a new attack surface [16]. This attack vector, if
exploited, can mean the difference between life and death. To that end, for wireless network
security to be adequate, it must be transparent to the user, require minimal configuration, and
be adaptive to change. It must also be intelligent, able to recognise normal user behaviour, and
capable of defending itself from attack.
Research on the IEEE 802.11 network security has been extensive, and the improvements have
been substantial. However, significant gaps in this area of knowledge remain. For example,
methods for collecting Layer 1 and Layer 2 wireless data are complex and require dedicated
equipment, making them incompatible with use on a WAP. Moreover, this inability to collect
6
the necessary information on low-end devices, together with ineffectual algorithms for device
identification, inhibits the detection of device impersonation. This technique is a common
precursor in many wireless network attacks.
Finally, understanding how to detect and defend against IEEE 802.11 attacks remains an area
of ongoing interest. As the Department of Homeland Security highlighted [17], “Wi-Fi
infrastructure attacks had the highest level of severity and the lowest time to invest for the
attacker”. These gaps in knowledge have prompted the objective and research questions in the
following sections.
1.3 Research Objectives

This research investigates the concept of impersonation based attacks on IEEE 802.11 networks
and proposes novel solutions to defend against them. Therefore, the objectives of this research
are:
• Perform a thorough review of the existing literature and identify knowledge gaps.
• Propose a novel approach suitable for use as a self-contained system on a commercial
WAP or domestic wireless router.
• Develop a solution within the confines of the technologies and limitations of these
devices, providing the ability to operate in real time, without user intervention, and be
of low cost.
• Test and validate the proposed solution using industry-standard tools and processes to
ensure viability.
• Contribute to the body of knowledge by publishing the output and findings from this
project.
1.4 Research Hypothesis

This research proposes that negating an attacker's ability to send nefarious commands on behalf
of legitimate users would significantly reduce the threat of impersonation attacks. This
capability would require a WAP to correctly recognise individual devices even when being
forged by an attacker. Additionally, it must differentiate between valid and invalid commands
by accurately identifying devices. Finally, to be suitable for small deployments such as home
networks, the device should be capable of actively defending itself against such attacks without
7
external infrastructure or user intervention. Such capabilities would require an entirely new
wireless data processing architecture.
The Software Defined Networking (SDN) paradigm, which has been a successful model for
securing wired networks [18], may provide a similar outcome for a wireless network. However,
this strategy would require a novel approach to SDN packet handling and an innovative
wireless data plane integration method. Additionally, an evaluation method for the different
SDN technologies and associated performance would be essential. Developing a novel
identification algorithm and countermeasures package for use on WAP is also necessary.
Since wireless device identification techniques are generally complex and resource intensive
[19], a new self-contained method with a low processing overhead is a prerequisite. Such a
technique would also necessitate integration with the SDN framework, a combination not found
in the existing literature. An option that could be suitable is using the SDN flow table concept
with a rule-based classification algorithm, thereby providing a more coherent and efficient
solution.
Furthermore, there are various advanced tactics used by cybersecurity professionals and
defence practitioners that, if efficiently developed into algorithms, could materially change the
defensibility of these devices.
1.5 Research Questions

The following research questions were devised based on the proposed approach and the
knowledge gaps applicable to this research.
1. Can SDN be used as an IEEE 802.11 frame processing method to access the data in
multiple OSI layers, and if so, which SDN approach is the most suitable?
2. Given the low sample rates on a WAP, which Radio Frequency (RF) characteristics can
contribute to device identification, and how can the SDN paradigm process them?
3. Device impersonation is a serious threat to wireless security, and existing approaches
work at one layer of the OSI model. What novel combination of physical and behavioural
device characteristics can identify a wireless device in real time with no user-initiated
training?
4. Real-world defence tactics and strategies, such as Observe-Orient-Decide-Act (OODA)
loops and Kill Chains, are effective in cybersecurity. Can these tactics be the basis for
8
novel algorithms suitable for use on a WAP, making it capable of defending itself against
DoS attacks?
1.6 Research Methodology

Based on the research questions and the problem defined, the ability of attackers to masquerade
as legitimate users is the root cause that facilitates impersonation based DoS attacks. Therefore,
the proposal must produce a novel device fingerprinting technique and behavioural algorithms
that impede an attacker’s ability to execute such attacks. Furthermore, the development of an
experimental WAP to validate the hypothesis and achieve this objective was required.
Therefore, the following methodology was applied to answer the research questions and
confirm the proposed hypothesis.
1.6.1 Literature Review Methodology
A systematic literature review using five primary sources was performed to determine the
current state of the art. Additionally, understanding current methods and tools used to attack
wireless networks was essential to assimilating the underlying principles and the technologies
employed. Table 1.1 lists locations and resources used to gather references, tools and
methodologies required for this project. As a multi-year project, the literature was re-evaluated
continuously to ensure that it accurately represents the knowledge frontier upon completion.
Table 1.1: Literature sources and usage
Source Usage
Google Scholar The primary source of reference searches. Search terms included:
“Software Defined Networking”, “SDN”, “SDN wireless”, “P4”,
“Wireless security”, “Wireless DoS attacks”, “IEEE 802.11
attacks”, “IEEE 802.11 security”, “deauthentication attacks”,
“Wireless attack countermeasures”, and “802.11 vulnerabilities.”
Google.com General information on attack tools and methods, such as “Wi-Fi
hacking tools”, “Wi-Fi attack tools”, “Wi-Fi credential cracking”
GitHub.com Tools and example code.
Wikipedia.org Background information on standards and technologies.
Connected Papers Works related to previously selected references.
9
The cited literature includes pioneering research beginning in the 1990s through to the latest
knowledge published prior to submission.
Figure 1.3: Publication year of cited literature
A temporal distribution shown in Figure 1.3 illustrates that while historical research is
discussed within the review, the majority of the cited literature is new knowledge published in
the last five years.
1.7 Investigation Methodology

To correctly frame and organise this project, evaluating each research question enabled the
creation of a delivery plan and set of tasks required to deliver a comprehensive and rigorous
scientific outcome.
1.7.1 Methodology for RQ1
• Investigate the most suitable SDN approach to accessing raw (layer 2) IEEE 802.11
frames and compare performance and usability metrics.
• Formulate a novel SDN method for extracting IEEE 802.11 frames appropriate for use
later in the project.
• Consider possible test platforms capable of accurately comparing and evaluating the
possible options.
• Develop the software components required to execute and assess the test outcomes.
10
• Evaluate suitable options and build an experimental WAP platform capable of RF, IEEE
802.11 fingerprinting and algorithm development.
• Install and configure Linux and openwifi [20] on the development platform.
• Modify the baseband code in the openwifi FPGA implementation to add functions for
extracting RF characteristics and processing with the MAC layer of the IEEE 802.11
frame.
• Alter and re-evaluate the SDN processing model developed for RQ 1 to include the
additional RF information.
• Create a data processing engine using the SDN model from RQ1 and RQ2, which is
suitable for algorithm development.
• Implement the devised framework on the experimental hardware platform.
• Investigate client device taxonomy of domestic wireless networks.
• Develop and evaluate a novel algorithm for identifying devices using information from
multiple OSI layers combined with behavioural characteristics.
• Develop a novel algorithm for identifying DoS attacks, interpreting information, and
behavioural cues. This algorithm should include passive and active detection methods and
active countermeasures for defence.
• Evaluate the accuracy and performance of the new model using commonly used and
readily available wireless attack tools, Aircrack-ng [21] and Fluxion [22].
1.8 Thesis Structure

Chapter 1 – Introduction
Provides the required foundational information and explains the significance of the research.
Therefore, Chapter 1 comprises the necessary background, including the objectives,
motivation, research questions, and methodologies required to position the study.
11
Chapter 2 – Literature Review
In Chapter 2, the literature on the following topics has been reviewed, critically assessed, and
discussed to provide context and relevance within the existing body of knowledge:
• Wireless data extraction and processing methods, including the SDN technologies
OpenFlow and P4.
• Hardware and Software platforms/techniques used in IEEE 802.11 and RF research.
• Device identification of IEEE 802.11 devices using MAC layer information.
• Device identification of IEEE 802.11 devices using physical layer information.
• The research frontier on detecting device impersonation.
• Existing approaches to identifying and defending against IEEE 802.11 DoS attacks.
• Cybersecurity tactics such as Cyber Kill Chains (CKC) and Observe-Orient-Decide-
Action (OODA) loops.
Chapter 3 – SDN Frame Processing Pipeline
Chapter 3 details a novel mechanism for accessing the required IEEE 802.11 frames. A new
method has been developed for processing wireless data for various OSI layers using an SDN-
based framework and a custom compiler extension for the P4 programming language, thereby
answering RQ 1. Furthermore, this chapter compares the new approach's performance,
reliability, and useability to existing methods before detailing the optimal solution and its real-
world implementation.
Chapter 4 – RF feature processing
Chapter 4 evaluates four RF features for their ability to contribute to device identification,
given the low sample rates available on an SDR-based WAP. The baseband processing within
the FPGA is modified to gather an optimal set of RF features, and an innovative technique
provides an answer to RQ 2. The method demonstrated in this chapter also facilitates the
consumption of these features by the P4 interface developed in Chapter 3. The need for real
time processing and limited opportunity for training is a crucial aspect of WAP functionality
and, therefore, a vital attribute of this contribution.
12
Chapter 5 – Wireless Device Identification
Chapter 5 examines the various MAC layer fields and the preliminary device identification
methods, including evaluating multiple attribute combinations and comparing results.
Additionally, an investigation of client device taxonomy used in domestic networks to
understand available datasets. Also included is a novel baseline for identifying individual
devices using a unique set of characteristics and a novel classification algorithm. Next,
improvements to the MAC layer identification model include physical layer attributes based
on RF features discovered in Chapter 4. The identifying algorithm is now modified to include
the new RF information in addition to a demonstrated improvement in accuracy to answer RQ
3.
Chapter 6 - Defending Against Denial-of-Service Attacks
With the innovations realised in the previous chapters, these novel elements were combined in
Chapter 6 to complete the approach and answer RQ 4. Using battlefield-tested tactics and
analytical models, an additional behavioural dimension enhances the newfound identification
accuracy. This novel detection algorithm utilises preconfigured and learnt behaviours, thereby
allowing the detection of actions outside typical network etiquette. Finally, in this chapter,
testing the overall model using various advanced, industry-standard RED team penetration
testing methods based on readily available tools is used to evaluate the solution's effectiveness.
Chapter 7 – Conclusion and Future Work
Chapter 7 concludes the thesis by assessing the overall outcome of the research. It evaluates
the outputs in relation to the aim and original hypothesis. Additionally, this chapter examines
the work in the context of the field and its applicability to real-world applications. Lastly, a
discussion of limitations, future work and the possible application of these outcomes to other
areas finalise this thesis.
13
Chapter 2.
Literature Review
2.1 Introduction
Network communications are the foundation of our connected world. Therefore, the need for
applications to provide fast, reliable access to data and back-end functionality has been the
focus of ongoing research. In particular, security, performance, and availability have garnered
considerable attention as the world becomes more dependent on the Internet for everyday tasks.
However, as most commercial technologies mature, so do the sophistication and abilities of
those seeking to exploit any security weaknesses [23]. This review critically assesses the
existing literature on the various techniques for analysing data in wireless networks, device
identification techniques, and the detection and mitigation of IEEE 802.11 impersonation and
DoS attacks.
This chapter begins by examining the current methods of accessing and analysing wireless
network data. It investigates the current methods for extracting Layer 1 (PHY) and Layer 2
(MAC) information and discusses the applicability to a WAP. Regrettably, Layer 1 baseband
processing in hardware is predominately restricted due to performance and intellectual property
protection. Therefore, gaining access to the raw RF signal is complex, and specialist equipment
is often required. Fortunately, Layer 2 information is more readily available, and the literature
describes various methods. One approach of particular interest is SDN and, more importantly,
how it affects wireless networks. Therefore, the review summarises the history of SDN, its
origins, and the inadequacy of the existing networking approaches that led to its development.
It then presents the evolution of the OpenFlow protocol [24], including its applications and
perceived shortcomings. It also examines P4 and its relationship to OpenFlow, particularly the
effect of the two approaches in the context of a wireless network.
Next, the review examines various wireless device identification techniques. It considers the
multiple approaches to analysing IEEE 802.11 data and reviews efforts made to accurately
identify wireless devices that may become possible methods of detecting device impersonation.
Understanding the complexity of feature selection is vitally important to accurate device
identification. Therefore, results from various experimental studies are used to establish a
baseline for further investigation into the suitability as a component of DoS attack detection.
14
An investigation into the current state of research on the susceptibility of impersonation and
flood-based DoS attacks in IEEE 802.11 wireless networks is then performed. There is a
growing body of literature on the impact of wireless network DoS attacks that propose solutions
with varying capabilities. However, the research has focused on alternatives that either impact
usability or are untenable in small-scale deployments such as home environments. Therefore,
alternative methods of addressing the issue will also be explored.
Finally, the literature review examines various strategies and tactics commonly employed in
cybersecurity and defence scenarios. The purpose is to consider using such approaches as the
basis of an algorithm for attack detection and defence. Drawing inspiration from decades of
knowledge on engaging human foes in a defensive situation, it is envisioned that incorporating
such insights from cybersecurity will assist in recognising and protecting against wireless
attacks.
2.2 Accessing Wireless Data

Various components make up a wireless network, which differs significantly based on different
architectures. Additionally, the architecture varies based on the overall purpose of the network,
connectivity patterns, the number of clients, existing infrastructure, and data volumes.
However, the most common element of any wireless network is the clients, commonly referred
to as stations.
The station represents the core use case, and in most circumstances, a wireless network's
primary purpose is to transfer data between stations and wired infrastructure. A station can be
various devices such as mobile phones, computers, sensors, and data displays. In fact, any
device which generates or consumes data and uses wireless connectivity. The fundamental
element of an IEEE 802.11 network is the Basic Service Set (BSS), which consists of a group
of stations communicating with each other. There are, however, two types of BSS -
Independent or Infrastructure.
An independent BSS (IBSS) consists of a group of stations communicating directly with each
other. Therefore, the smallest possible IEEE 802.11 IBSS is that of two stations. This type of
network tends to be short-lived; because of this, they are often referred to as ad hoc networks,
unlike Infrastructure networks that provide more robust, long-term arrangements.
15
The principal factor in an infrastructure network is a Wireless Access Point (WAP). A WAP is
responsible for all communications within an Infrastructure network, including communication
between stations. Therefore, the distance between stations is irrelevant. However, all stations
must remain within the radio range of the WAP to participate. Additionally, it is common for
the WAP to provide uplink capabilities to a Wide Area Network (WAN) or, in domestic
deployments, the Internet.
Various methods for accessing the raw data within a wireless network vary in complexity,
accuracy, and usability [19]. However, this research is gaining access to data from OSI Layer
1 (PHY) and Layer 2 (MAC), which is of paramount importance as these are unique to an IEEE
802.11 network and not ordinarily available. Therefore, it will be retrieving data from these
layers that will be the focus of this section. Additionally, as the scope of this thesis is
infrastructure networks, the investigation will be focused on methods suitable for use on a
WAP. Furthermore, this section will examine a range of existing approaches that may not
typically be considered for this scenario to determine whether they could be suitable for use on
a WAP.
2.2.1 Layer 1 (PHY)
The capturing of RF transmission for identification has been a research topic since military
aircraft in the 1960s first tried to differentiate between friendly and enemy radar [25]. However,
the investigation of RF fingerprinting [26] domestic devices did not begin until the late 1990s
with the advent of technologies such as wireless networking. Some of the earliest works, such
as Toonstra and Kinsner [27], utilised relatively rudimentary methods, such as using ham radio
receivers and digitising the received signal using a 16-bit PC sound card. Though crude, this
original work showed significant promise and led the way for the numerous studies that
followed. The use of stand-alone RF receivers continued for over 20 years enabling sampling
methods to improve with the help of digital oscilloscopes that provided computer interfaces.
In 2007, Ureten and Serinken [28] utilised the Watkins-Johnson model WJ-8633 receiver tuned
to IEEE 802.11b channel 1 in the 2.4GHz ISM band for their experiments. The receiver was,
in turn, connected to a Tektronix TDS3054 digital oscilloscope providing Ethernet connectivity
to a PC. The authors collected 100 transmissions from eight different Wi-Fi devices at a 5Gsp/s
sample rate. The use of high-end equipment provided the authors with samples of a high
enough quality to achieve their goals of capturing the transient RF signal before a steady state.
However, these results required large, expensive, complicated equipment in a highly controlled
16
environment. It was a standard capture method for years as researchers experimented with
different classification techniques.
One of the most extensive experiments to use this capture model was that of Brik et al. [29],
who developed the PARADIS test platform in 2008. PARADIS utilised the slightly more
advanced method, optimising the two-step capture process by employing a Vector Signal
Analyser (VSA). Utilising an Agilent 89641S VSA, 6dBi omnidirectional antenna, and an 18
dB LNA the authors collected samples from 138 identical Wi-Fi cards. Unfortunately, the
authors did not report the signal sample rate used; however, the 89641S can sample rates up to
10Gsp/s. While the authors do not describe the processing method post the capture stage, it can
be inferred from the evaluation that it was a multi-device arrangement operating in an offline
mode. Additionally, like many endeavours of the same type, this research focuses more on
accuracy and less on throughput or time to result.
High-end oscilloscopes continued to produce impressive identification accuracy at varying

sample rates. Danev and Capkun [30] examined transient waveforms using an oscilloscope
with a 1 GHz bandwidth and a sample rate of 4Gsp/s, reporting a 3.2% classification error rate.
The authors would follow up on their approach by testing its effectiveness against
impersonation attacks [31]. This time they increased the sample rate considerably to 20Gsp/s
using the more capable Agilent DSO90804A oscilloscope. As before, it was processed offline
using Matchwork’s Matlab software. The trend of increasing sample rates to improve accuracy
continued with Polak et al. [32], who raised the sample rate significantly to 50Gsp/s. While
accuracy was the goal and the results impressive overall, such an approach runs counter to the
pursuit of real time capture and computation. However, such a sample rate would produce
400,000 vector points from a single 8us IEEE 802.11 short training sequence, which is not
something an ARM-based WAP would be capable of processing.
The use of RF fingerprinting is discussed further in the sections on feature selection, as they
offer valuable insights into waveform structure. However, it is essential to emphasise further
that while these works are significant in establishing context, the relative success of these
experiments came at a cost. In addition to the financial overhead of high-end equipment, almost
all are impossible to replicate outside of a well-equipped lab, nor are they suitable for a real
time application. Meanwhile, the use of Software Defined Radio (SDR) [33] hardware, which
allowed software-driven waveform capture at a fraction of the cost, was gaining popularity.
17
2.2.2 Software Defined Radio
The predominant digital baseband signal processing hardware design is implemented as

Application Specific Integrated Circuits (ASIC). In contrast, an SDR allows various
communication methods based on the software configuration [34]. An SDR device facilitates
the capture and digitisation of an RF signal into a digital version that faithfully describes the
original signal. Protocols, encoding and modulations can be developed and tested in software
with no hardware changes. The introduction of free software such as GNU Radio [35] enabled
experimentation with many different protocols and standards.
Though well-received, the lack of affordable SDR hardware hampered the appeal of GNU
Radio. This need motivated Matt Ettus in 2003 to develop the Universal Software Radio
Peripheral (USRP), an open-source SDR platform, which would become the flagship product
of Ettus Research [36]. The combination of USRP and GNU Radio would soon become a
common platform for RF research. It would also become the basis of complete, software-based
baseband processing implementations. For instance, Bloessl et al. [37] developed a complete
IEEE 802.11 a/g/p OFDM receiver based on GNU Radio and the Ettus USRP N210. This
platform, supporting a bandwidth of 20 MHz, was capable of decoding and extracting IEEE
802.11 a/g Layer 2 MAC payloads entirely in software. However, not only baseband
processing, but also RF fingerprinting research benefited from such an approach.
Patel et al. [38] investigated the RF fingerprinting performance of a low-cost SDR receiver
compared to dedicated, high-cost receivers. He had found previously that most RF
fingerprinting methods utilised large, expensive receivers such as the Agilent E3238S or even
high-speed oscilloscopes. However, more recent research had successfully used low-cost
USRP receivers, but Petal et al. found no formal comparison of the two approaches. Therefore,
using the NI PXIe-1085 and NI USRP-2921 receivers, both at a 20 Msp/s sample rate, a total
of 600 transmission preambles were collected and analysed. They varied the Signal to Noise
Ratio (SNR) in 2dB increments by adding Additive White Gaussian Noise to the collected
signal to determine the SNR impact on each receiver. Using a Random Forest classifier to
compare amplitude, phase, and frequency features, they discovered that the high-cost receiver
only identified approximately 10% more devices than the low-cost receiver. What emerged
from the results was the suggestion that low-cost SDR receivers can provide a suitable capture
performance for RF fingerprinting signals.
18
Motivated by the prospect of using low-cost SDR devices, Peng et al. [39] constructed a testbed
platform using the USRP X310 to investigate if low-cost equipment would reduce
classification performance. Their work aimed to determine if the low SNR on commodity
devices would impact RF fingerprinting accuracy. The capture of four modulation features
from ZigBee nodes was used as part of an RF fingerprinting process. These features included
a differential constellation trace figure, the Carrier Frequency Offset (CFO), modulation vector
offset, and the I/Q origin offset extracted from the constellation trace figure. However, while
the baseband capture was real time on the USRP SDR, it was transferred to a PC and analysed
offline as there are no processing capabilities on the device itself. Their results indicated that
combining various features could provide the required accuracy and compensate for the lower
quality signal capture. Furthermore, the authors speculated that the method should work with
other network standards, such as IEEE 802.11 a/g/n/ac.
While SDRs provided a low-cost method for capturing RF signals, a computer was still
required to process and analyse the information. Unfortunately, due to the latency produced by
transferring the data and the inefficiencies of demodulation in software, real time processing
was not possible. Due to the latency between an SDR and the baseband processing on a PC, it
becomes difficult to implement the Short Inter-Frame Spacing (SIFS) timing that is required
for IEEE 802.11, as shown in Figure 2.1 [1]. However, the introduction of the FPGA to the
pipeline provided a new capability, real time integrated baseband processing.
Image Removed
Figure 2.1: Interframe Spacing relationships
Considering these limitations, one of the early implementations of the SDR/FPGA combination
was the Wireless Open-Access Research Platform (WARP) [40]. The authors created an
integrated PHY/MAC research platform using a Xilinx Virtex-II Pro FPGA board [41] and a
19
custom-designed radio module. The WARP system divides the processing of these two layers
between native FPGA operations for the PHY layer, while the low-level MAC functions use a
MicroBlaze soft processor implementation. While the platform only provides basic PHY and
MAC layer functionality, it does include Ethernet encapsulation/de-encapsulation and,
therefore, can be connected to external devices via Ethernet. Thus, the overall WARP system
performed like an open-source Network Interface Card (NIC) with HardMAC capabilities.
More recently, Wu et al. developed the Tick [42] research platform, which provides a full-stack
implementation of the IEEE 802.11ac standard. Tick utilises a hybrid approach, implementing
PHY and low-level MAC layer processing on the FPGA board and the remaining pipeline on
a host PC connected via USB 3. The design of the Tick solution was to provide a middle ground
between low latency, effective PHY timing, and the programmability needed for a good
research platform. To improve PHY processing performance, Wu et al. implemented various
features, such as a Multi-Clock Domain Pipeline (MCDP), which provide varying, optimised
clock frequencies to different pipeline parts. This technique reduces latency that would
otherwise limit non-bottleneck sections of the pipeline by a lower clock frequency.
Additionally, the authors designed a modular code base they refer to as “a graph of elements”.
These elements can be arranged into a flowchart-like structure to facilitate various experiments.
The Tick platform now provides researchers, at least those with access to the source code, a
framework for further study of PHY layer properties. One such group, led by Xiaoguang Li,
would do just that by extending the Tick platform to create TickSEC [43]. The TickSEC
researchers modified the Tick PHY layer FPGA implementation to extract various RF
attributes, possibly allowing applications to perform PHY layer authentication. These RF
characteristics included the received frames' Received Signal Strength Indicator (RSSI),
Channel State Information (CSI), and the CFO. The implementation also utilises the soft
processor via the existing Advanced Extensible Interface (AXI) bus, allowing the user to
configure the PHY and retrieve information from it. While extracting the data from the PHY
layer appeared straightforward, other than managing performance impact, aligning the
information with the received frame proved more challenging.
As the PHY layer extraction process in TickSEC had been implemented asynchronously, they
faced the challenge of ensuring that the RF information collected corresponded to the current
frame and not the previous one. To overcome this problem, the authors designed a component
they refer to as an information collection module cache that temporarily stored the information,
allowing the other PHY layer modules to continue processing the next frame. The PHY
20
information collected can then be transferred to the host PC via the AXI registers using the
device’s USB connection. The device presents a group of 32 AXI registers, both read and write,
allowing users to provide configuration information. Based on the author's description, this
method also provides the ability to extend the interface to include other fields if required. While
both Tick and TickSEC provide encouraging results, neither project has released source code
and cannot be verified or extended.
Fortunately, following a similar methodology to that used for Tick, Jiao et al. also developed a
full-stack IEEE 802.11 research platform called openwifi [20]. They created an all-in-one WAP
device using an optimised combination of an SDR and SoC processor. This unique approach
centres around the SoC, which includes an FPGA and ARM processor on a single chip.
Therefore, such a device can provide baseband / PHY layer processing in the FPGA and a
Linux-based MAC layer implementation on one device. Furthermore, the Linux operating
system facilitates a full WAP implementation using hostapd [44], commonly used to manage
wireless clients on Linux based WAPs and domestic wireless routers. Moreover, openwifi is
free of any license costs, wholly open-sourced, and completely extensible. Therefore, the
openwifi framework enables researchers to test and develop a variety of IEEE 802.11 solutions.
As seen in the later chapters, it is to become the platform upon which this research will be built.
Getting access to the PHY layer data, for the most part, is not feasible on commercial IEEE
802.11 devices due to the enclosed nature of the hardware. Additionally, strict timing
requirements for baseband processing make real time external execution in software
problematic. However, recent work such as Tick and TickSEC has provided a starting point for
developing new methods for extracting RF information that would not have been previously
possible. While TickSEC shows promise, the lack of source code makes verifying or
reproducing the results impossible. Furthermore, it only provides commonly used RF
characteristics delivered by a PC-based API interface. Alternatively, openwifi provides a fully
open-source implementation but lacks RF evaluation features. In conclusion, the literature
offers numerous interesting approaches; however, none provide the type of RF data required
in a way that would be plausible for use on a WAP.
2.2.3 Layer 2 (MAC)
Though perhaps not as challenging as extracting RF information, gaining access to IEEE

802.11 MAC layer information still presents various challenges. IEEE 802.11 frames include
large amounts of information specific to the wireless medium, which is of no use further up the
21
networking stack. For this reason, after the device driver consumes wireless information, it is
removed, and the data payload becomes a generic Ethernet frame. Therefore, it must be
accessed via the device driver or before to capture the raw MAC layer frame.
The IEEE 802.11 standard defines three distinct frame types: Data, Control, and Management.
Each of these frame types provides different functions during the lifetime of a client
connection. Data frames are the workhorse of the IEEE 802.11 standard and represent the most
significant volume in both number and size. The total number of fields, shown in Figure 2.2,
in the data frame varies based on if it is in a contention-based or a contention-free service.
2 2 6 6 6 2 6 0 - 2312 4
Frame Duration Address 1 Address 2 Address 3 Seq Address 4 Frame FCS

Control ID (Receiver) (Sender) (Filter) Control (Optional) Body
Figure 2.2:Fields in an IEEE 802.11 Data Frame
As it is the data frame that carries the actual user's payload, the frame body is encrypted using
the Temporal Key Integrity Protocol (TKIP) or Advanced Encryption Standard (AES). Data
frames require a regulation mechanism to ensure orderly flow in a shared medium. This task is
the role of the Control frame.
The Control frame is an unencrypted frame responsible for managing the transmission of data
between devices, which is particularly important when multiple clients share a common range
of RF bands. By controlling access to the wireless medium using directives such as Ready to
Send (RTS), Clear to Send (CTS) and Acknowledgement (ACK), the control frame provides
significant improvements in MAC layer reliability. While it is the Control frames that manage
the flow of frames between devices, it is the management frames that control a client’s session
state.
The Management frame provides the mechanism by which a client establishes a connection,
terminates, maintains, and broadcasts the presence of available networks. The management
frames are most commonly targeted and, therefore, of particular interest in security attacks
[45]. Management frames are normally unencrypted (see section 2.4) and crucial to client
connectivity, making them a typical attack vector due to the importance of the information the
frame conveys and the significance of this information in connection management. Moreover,
Management frames also carry information valuable to determine a wireless client's identity,
such as Information Elements (IE).
22
An Information Element shown in Figure 2.3 is a variable-length field, in addition to the
mandatory fixed-length fields, used to provide additional status and capability information
between wireless devices. An example of using IEs can be found in the work of Gentry and
Pennarun [46], where they were used to differentiate between a range of device types.
1 1 Length (bytes)
Element ID Length Data
Figure 2.3: IEEE 802.11 Management Frame Information Element
By examining the IE fields in probe and association frames, the authors extracted information
such as the device manufacturer of the wireless subsystem hardware, supported modulation
schemes, and bitrates. By looking for specific combinations of these elements, the authors
could differentiate and identify a variety of client devices. While various device vendors have
now introduced MAC randomisation as a method of mitigating device tracking, IEs must
remain accurate to ensure compatibility and continue to be a practical identification method
using capability data correlation.
Robyns et al. [47] demonstrate that monitoring IEs can be a useful reference point for device
identification. They worked extensively with IEs to investigate non-cooperative device
identification and tracking scenarios. In non-cooperative identification and tracking systems,
the mobile devices are unaware of the monitoring process and, therefore, do not provide any
additional information other than that required for standard IEEE 802.11 compliance.
Therefore, non-cooperative systems must rely on the information already included in the MAC
layer frame, and as Robyns et al. found, IEs can be a reliable source of such information.
However, IEs are easily forged, so their use is limited. This finding is consistent with various
other works, as seen in the following sections.
2.2.4 Monitor Mode and Probes
An alternate, less intrusive method for accessing IEEE 802.11 data is via monitor mode.
Monitor mode, one of the eight standard wireless operating modes, is a feature available on
many wireless network cards that allows the creation of a network interface designed
specifically for viewing the raw IEEE 802.11 frames promiscuously. This function enables the
interface to receive all wireless traffic, even those frames not addressed to the network card
itself. While monitor mode provides complete access to these frames, the data is read-only,
23
providing no facility for dropping and modifying frame data. Nevertheless, monitor mode can
be invaluable in device identification and traffic logging.
A well-known example of such an approach would be that of Franklin et al. [48], which used
monitor mode to collect data for a passive device fingerprinting experiment. Using monitor
mode allowed authors to eavesdrop on management frames and, in particular, client probe
requests. While discussion of their fingerprinting methodology is in later sections, the work is
a fitting illustration of the practicality of monitor mode. Another example is the study by
Robyns et al. [47], in which the use of monitor mode to capture management frame probe
requests to identify and track mobile devices were employed. MikroTik RB912UAG-2HPnD
wireless router boards that feature the Qualcomm Atheros AR9342 SoC enabled the authors to
build small, low-cost monitoring stations. After replacing the stock firmware with OpenWRT
[49], the authors developed a custom application using the libpcap library to capture frames
from the monitor mode interface.
An example of utilising monitor mode is capturing traffic as a precursor to a wireless attack.

As Aung and Thant [50] described, using a monitor interface is a standard method for capturing
wireless traffic for reconnaissance before an attack. Similarly, Amoordon et al. [51] utilised
monitor mode to detect rogue access points in a Network Intrusion Detection System (NIDS).
Utilities such as airmon-ng create a monitoring interface by enabling the inbuilt monitor mode
function on a wireless NIC. Various tasks, such as capturing authentication handshakes, are
possible upon creating the monitor interface, which can later provide offline brute force
credential cracking operations. Additionally, frames captured using monitor mode can create a
catalogue of connected client MAC addresses for use in DoS attacks, as described by Bellardo
and Savage [52].
A literature review shows the widespread use of the wireless driver monitor mode interface to
capture IEEE 802.11 traffic passively. While the approach only provides access to MAC layer
data in a read-only manner, it does simplify access to this type of information. Of specific
importance is the ability to access management frames that would otherwise be unavailable
and, with them IEs. The literature also shows that this collection method is a practical approach
for fingerprinting, tracking and utilisation experiments in low-trust environments. While it is
suitable for use where the participants are not actively trying to avoid detection, it should not
be relied upon in situations where security is a consideration.
24
2.2.5 Wireless Driver Integration
The processing of MAC layer frames can occur in one of two locations. It can be conducted
internally within the wireless hardware, often referred to as a HardMAC. HardMAC
functionality is more prevalent in systems with limited processing power, such as IoT devices.
Alternatively, where more processing power is available, MAC layer packets can be managed
in software by the device driver, a method known as SoftMAC. An example of a SoftMAC
implementation is the Linux MAC80211 driver, which handles all the MAC layer functions,
such as authentication, association, and probe requests.
A wireless device driver acts as a bridge between the wireless network device and the operating
systems network stack and performs tasks such as authentication and routing. By modifying
these drivers, it is possible to extract additional information about the device and the data it
processes. One could also manipulate the data in transit by adding supplementary logic or
external functions. A notable example of wireless driver integration is demonstrated by Liu et
al. [53] using the Linux 802.11n CSI tool [54]. The CSI tool uses a customised version of the
closed source firmware for Intel’s WiFi Link 5300 to measure the channel state for each packet
during the preamble. By installing the CSI tool and the modified driver on a PC configured to
run in infrastructure mode, the author could use the CSI values as the basis for PHY layer
device fingerprinting.
As Wellnitz and Wolf [55] demonstrated, they collected low-level data not ordinarily available
by modifying the now-defunct Madwifi [56] driver for wireless NICs with the Atheros chipsets.
Information such as timestamps, signal strength, data rates, and retries provide the authors with
a significantly more accurate view of the impact of wireless transmission latency. Furthermore,
access to the Hardware Abstraction Layer (HAL) queueing events and the transmission success
confirmations provided a more in-depth view of medium delays. The availability of such
information was invaluable in the outcome of their work and the conclusions of transmission
retry optimisation.
The abundance of open-source wireless NIC drivers not only provides a greater understanding
of the internal mechanics of a wireless system but also allows researchers to create a range of
modifications to gather data not readily available. Additionally, it provides a means which
enables the development of supplementary behaviours. As will be seen in later chapters, the
ability to not only consume this data but to influence a wireless pipeline is a compelling
capability.
25
2.2.6 Software Defined Networking
Benson et al. [57] conducted interviews with various network operators from universities and
enterprises and found that the ability to manage an extensive network effectively decreases
significantly as the complexity increases. They also found that it causes significant manual
intervention that often leads to configuration errors responsible for a substantial fraction of
network outages. To compound the challenges of maintaining a stable, resilient network, the
constant threat of security breaches and attacks has only increased the complexity. Adding
Router ACLs, firewalls, NATs, VLANs, and numerous middleboxes have created change
processes and support methodologies that reduce an organisation’s agility and increase
operational costs. These mechanisms require a substantial amount of configuration, and
supervision [58] which are often inefficient and produce complex and brittle environments
[59]. Furthermore, many of these techniques end up creating an inferior outcome. Over time
new technologies become available; however, the evolution is slow, the changes difficult, and
the cost high. Due to this slow rate of change, the design, testing, and deployment of a new
routing protocol can take 5 - 10 years [60]. Various studies have investigated a new approach
to the Internet [61]–[63]. However, significant changes to the underlying networking principles
were considered impractical. These complexities led to Stanford University’s Clean Slate
program [64] and, ultimately, the concept of Software Defined Networking.
One of the first outputs of the Clean Slate program was that of Casado et al. in 2006, titled
“Secure Architecture for the Networked Enterprise (SANE)” [65]. Using techniques similar to
those proposed by Weaver et al. [66], including fine-grained host-level controls and augmented
coarse-grain methods, such as firewalls and intrusion detection. At the core of the SANE
architecture was providing centralised control using what the authors referred to as a Domain
Controller. The Domain Controller offers services such as authentication, a Network Directory
Service (NDS), and the Protection Layer Controller (PLC). The NDS provides a single,
centralised view of every network node but, more importantly, maintains a single source of
truth for access control and service capabilities. Using a centralised directory also overcomes
a number of the scalability issues of ARP broadcasts associated with large networks. A
directory model, also proposed by Myers et al. [67], provides additional security benefits and
allows routes to be updated faster in the event of failures. This centralised controller model
would later become the cornerstone of the Ethane [68] architecture, however, at the time,
papers such as “A clean slate 4D approach to network control and management” [69], used
concepts considered controversial and polarised researchers [70]. The Ethane project extended
26
the capabilities of the separate control/data plane model, thereby introducing the concept of a
flow table and the policy language “POL-ETH”, which would become the precursor to the
OpenFlow protocol.
In 2008 McKeown et al. [24] postulated that there is almost no practical way to realistically
experiment with new network protocols to gain the confidence needed for their widespread
deployment. He surmised that this would be possible only if network switches could allow
high-performance / low-cost deployments, support a broad range of research options, and
isolate production and non-production traffic. More importantly, it would still allow vendors
to maintain a closed platform and protect their intellectual property. The proposed solution was
the OpenFlow switch. The OpenFlow protocol enables the programming of a flow table to
direct network traffic based on a match-action paradigm. Matching employs predetermined
header values ranging from Ethernet MAC addresses, MPLS, and VLANs to higher-level
protocols such as TCP. From a research perspective, it also allows network administrators to
partition traffic into production and research segments, facilitating the development of new
routing methods, security models, and addressing schemes. The OpenFlow protocol slowly
matured, and as it did, the number of supported match fields increased from 12 in version 1.0
to 44 in OpenFlow version 1.5.1 [71]. However, as each version of the OpenFlow standard
became more complex and the demands for more compatibility increased, the Open
Networking Foundation proposed that instead of extending the OpenFlow protocol match list,
it required a new approach, that of a programmable data plane.
The notion of a programmable parser was initially introduced in Kangaroo [72] to improve the
performance of forwarding planes. Additionally, Song investigated Protocol-Oblivious
Forwarding (POF) [73] to remove the dependency on fixed forwarding planes and allow more
flexibility. Alternatively, Shi et al. proposed a Wi-Fi specific version of the POF architecture
titled Po-Fi [74]. However, the introduction of the P4 programming language [75] promised a
fully programmable, platform-independent data plane model. P4 is a domain-specific language
(DSL) designed to be architecture agnostic so that the same program is suitable for FPGAs,
Network Processing Units (NPU), software switches, and packet filters [76]. However, there
has been a disproportionate focus on hardware-based applications such as Barefoot’s Tofino
chip [77] and P4FPGA [78]. A speciality compiler [79] is required to use P4, specifically
written for the target platform, which due to its complexity, has limited the number of
compatible devices currently available. As P4 is a data plane specific language and most
OpenFlow research tends to be controller focused, there has been minimal exploration that
27
overlaps the two approaches. In 2016 the PISCES project [80] did create a P4-enabled software
switch based on Open vSwitch (OVS) [81] and found when comparing the performance of P4
and the native OVS data planes that the performance of the two approaches was very similar
when optimised.
A 2013 technical report [82] published by the Open Networking Foundation (ONF) described
the challenges of mobile and wireless networks' scalability, management, flexibility and cost.
The ONF report also discussed how SDN solutions could address these issues and provided a
few specific examples. However, most of these examples were related to the traffic
management of backhaul and core networks, not the wireless networks. Another wireless
OpenFlow testbed, OpenRoads [83], used the SDN paradigm within a wireless network. The
OpenRoads model used the NOX [84] OpenFlow controller to manage IP address allocation
via DHCP, allowing different network paths in addition to network monitoring.
Similarly, Yap et al. proposed a “Blueprint for Introducing Innovation into Wireless Mobile
Networks” [85] in which OpenFlow can be used to provide a standardised model for wireless
network deployments. This architecture, like many others that have considered a wireless SDN
approach, only applies SDN functionality where it is compatible with the existing match fields
defined in the OpenFlow protocol [86], [87]. Others, such as Ethanol [88], have used an SDN
model but devised a custom agent and API to improve functionality. However, where this may
add value in large corporate deployments with a large number of WAPs and sophisticated
distribution networks, it does not provide any benefit for home or small business networks with
only a single device and limited budgets due to the need for separate controller infrastructure.
The RADIator architecture [89] developed by Cwalinski and Koenig utilises the SDN paradigm
of separate control and data planes by using a custom agent installed on what they refer to as a
“thin” Access Point. Though the approach uses the plane separation model and rule-based
filtering, it does not employ conventional SDN technologies such as OpenFlow or P4. It
appears more like a variation of a Wireless Access Controller (WAC) deployment than an SDN
solution. Using a similar approach, the SDWN for ONOS/LEDE [90] project uses an ONOS
[91] controller and an agent installed on a WAP. Installed on LEDE, which is now part of
OpenWRT, is the WLANflow agent that uses the Linux Netlink interface to retrieve wireless
configuration information and the OpenWRT ubus interface to receive notifications about
incoming EEE 802.11 management frames. Finally, Engelhard et al. [92] utilised P4’s
customisability to aggregate notifications from a sensor network.
28
A literature review of SDN in wireless networking found a predominant focus on using Open
vSwitch (OVS) installed on a WAP. Furthermore, OVS is integrated at the network interface
level on the WAP or utilises an external OpenFlow switch and Ethernet protocols. While
Scheibe et al. [93] did investigate the use of P4 for managing Low Power Wide Area Networks
(LPWAN), it was performed using BMv2 [94] and Mininet [95] in a purely simulated
environment.
Additionally, there has been minimal comparison of OpenFlow and P4 dataplanes, and no
direct comparisons on a common hardware platform were found in the literature. However,
there have been numerous comparison studies on the performance of different OpenFlow
switches [96]–[98]. Many of these investigations, which included processing packets in a
match/action pipeline, found that reading and writing to memory contribute significantly to
network performance issues [99]. Finally, little research has been found on using the P4
programming language in a wireless data plane. Therefore, further investigation is required in
these areas to effectively evaluate SDN as a possible wireless data capture mechanism.
SDN represents a significant shift in the design and management of networks, introducing a
framework that also offers valuable opportunities for researchers and network operators.
However, it highlights several issues inherent in the model, particularly the conflict between
standardisation and innovation. The OpenFlow protocol required an agreed set of specifications
to ensure compatibility between vendors and devices, such as the predefined match headers.
This immutability reduces OpenFlow’s ability to be applied to scenarios outside of those it was
initially intended for, which in the research related to this proposal is the IEEE 802.11 wireless
standard. Since the same limitations do not restrict the P4 programming model as they do
OpenFlow, it facilitates the customisation of the header fields. This model allows it to create
data planes capable of processing IEEE 802.11 frames and, in doing so, assist in extracting
device data from multiple OSI layers. The intersection of these three deficiencies opens a new
area of research in wireless network security.
2.3 Wireless Device Identification

Each device must be uniquely identifiable for a wireless network to operate correctly and
securely. In the same way that telephone numbers route and identify calls, IEEE 802.11
networks use a MAC address as the primary means of identifying devices. While payload
encryption and user authentication usually provide adequate privacy and access controls,
29
device identification is less reliable. A MAC address is stored in a section of Read-Only
Memory (ROM) on the device, provisioned during manufacture from an address space pool
issued to the vendor by the IEEE standards association. Each address is unique, consisting of
an Organisationally Unique Identifier (OUI) and NIC specific ID. However, although they
should remain static, many devices allow a MAC address to be changed. Additionally, it is
possible to generate wireless frames in software with any MAC address, which is why device
impersonation is a relatively simple exercise. Nevertheless, MAC layer data can still provide
helpful information, as discussed below; however, the reliability is limited for identity
verification.
As briefly discussed in section 2.1, an area of research referred to as device fingerprinting has
emerged to help combat the ease of modification that MAC and higher layer identifiers provide.
Researchers have developed alternative verification methods to reduce reliance on easily
modifiable device identifiers. By examining the RF waveform and modulation characteristics
of the transmitting device, it has proven possible to identify individual devices with accuracies
of up to 99%. The methods and techniques vary significantly amongst the numerous
approaches, as do the complexity and applicability to real-world scenarios. However, all
models follow a standard acquisition, feature selection, and classification methodology.
The data acquisition method is relatively straightforward, consisting of a receiver and digital
conversion mechanism. Devices such as spectrum analysers and digital oscilloscopes are
common platforms. While these devices are large, expensive, and complicated, they offer the
highest accuracy due to their high sample rates, sometimes over 90Gsp/s, in the case of the
Agilent E3238S [100]. A low-cost alternative to dedicated hardware is the use of SDRs. An
SDR typically consists of an RF frontend, an Analog to Digital Conversion (ADC) section and
a data transfer interface to an external device such as a PC. Additionally, an SDR system may
include an FPGA that could allow further processing, such as modulation and decoding. Upon
the digital capture of a signal, the next task is to extract features suitable for fingerprinting.
Features appropriate for wireless device identification can be extracted from practically all
network stack layers. However, the most common elements for identifying wireless devices
are those of the MAC and PHY layers. These features can be used individually or in
combination to create what is referred to as “fingerprints”. As the name suggests, a device
fingerprint is a unique set of attributes specific to a vendor, model or individual device. As
shown in Table 2.1, numerous features and methodologies are available for fingerprinting
wireless devices, many of which will be examined in more detail in the following sections.
30
Given the project constraints detailed in section 1.3, a column has been included in Table 2.1
to indicate if an approach is suitable for low RF sample rates and limited processing capabilities
of an SDR or consumer-grade WAP.
Table 2.1: Wireless Device Identifying Features that have previously been identified in the literature
Feature References Layer RF Domain RF State WAP

RF Oscillator Imperfections [101] PHY Waveform Steady No
Power Amplifier Linearity [32], [102] PHY Waveform Steady No
Power-up Ramp [28], [30], [31], [103]–[106] PHY Waveform Transient No
RSSI [107], [108] PHY Waveform Steady Yes
Channel State Information [53], [109] PHY Channel Steady Yes
Channel Frequency Response [110], [111] PHY Channel Steady Yes
Channel Impulse Response [112] PHY Channel Steady Yes
Carrier Frequency Amplitude [113]–[115] PHY Modulation Steady Yes
Carrier Frequency Offset [29], [114]–[117] PHY Modulation Steady Yes
Carrier Phase Offset [29], [100], [113]–[117] PHY Modulation Steady Yes
I/Q Origin Offset [29] PHY Modulation Steady Yes
MLME Information Elements [46] MAC - - Yes
Clock Skew / Drift [118]–[120] MAC - - Yes
Frame Inter-arrival Time [121], [122] MAC - - Yes
Interestingly a common theme in the reviewed literature is to focus on accuracy by using offline
processing. While this approach seems intuitive and rewarding, it limits practicality. Capturing
at high sample rates, triaging data, and classifying offline on powerful hardware offers
impressive results. However, it also leaves opportunities for advancement in novel algorithms
and processing optimisation. Conversely, as discussed in later sections, acquisition at lower
sample rates, like those available on SDRs and WAPs, does limit the use of transient features
such as transmitter turn-on ramps.
2.3.1 MAC Layer Device Identification
The building block of IEEE 802.11 communications is the frame, a discrete unit of information
that carries data between devices. Each frame consists of several fields that include information
about the sender, receiver, and the type of frame in addition to the actual data payload.
However, not all these frames serve the same purpose, nor are they processed similarly. A strict
addressing scheme based on a MAC address is common to all frame types, ensuring the correct
delivery of data between devices.
31
A MAC address is a 48-bit primary device identifier used by IEEE 802.11 in the same way as
Ethernet and other members of the IEEE 802 family. MAC addresses are globally unique and
allocated from a single pool managed by the IEEE Standards Association (IEEE-SA). Each
device on the network must have an individual MAC address because, like Ethernet, wireless
is a shared access medium supporting unicast and multicast transmissions. For multicast
broadcasts, the destination address is a masked MAC address.
The ease of impersonating wireless devices has prompted numerous investigations into
methods for accurately identifying fraudulent devices. Though efforts to identify a wireless
device using MAC layer information are relatively straightforward, MAC headers are easily
forged and therefore lack trustworthiness. Additionally, the information contained in the MAC
header is only considered suitable for vendor-level identification, as explained by Xu et al.
[123]. However, Lanze et al. [118] and Jana et al. [120] did examine utilising timestamp clock
skew to identify rogue WAP with limited success. IEs within management frames can still be
a valuable collational point when used with other methods. Gentry and Pennariun [46]
demonstrated the value IEs in conjunction with Dynamic Host Configuration Protocol (DHCP)
in non-adversarial scenarios to highlight the importance of multi-layer correlation.
In addition to MAC headers, the transmission time is another possible approach with standard
wireless hardware. Based on Neumann et al. [121] analysis, overall transmission time may give
better accuracy in a controlled environment; the frame inter-arrival time appears to provide
more consistent results. This feature was further investigated by Dalai et al. [122], which
showed promising results when simulated using CRAWDAD [124] data.
2.3.2 Radio Frequency Fingerprinting
The journey of a received IEEE 802.11 frame begins as a raw RF signal received by the device's
antenna as a weak, modulated carrier signal. This signal is then boosted by a Low-Noise
Amplifier (LNA) in the RF amplification stage of the device. Depending on the standard, this
may be in one or both of the 2.4GHz or 5GHz bands. Additionally, where space and power
consumption are essential, the entire RF frontend of the device may be integrated internally
within the wireless chip. It is then up to the Physical Layer (PHY), which provides the
demodulation and decoding of the radio signal into frames. It is a process highly dependent on
accurate timing and performed in hardware.
The PHY consists of two sublayers, the Physical Medium Dependent (PMD) and the Physical
Layer Convergence Procedure (PLCP). The PMD provides a serial bit stream from a chain of
32
functions, including I/Q demodulation, guard interval removal, Fast Fourier Transform (FFT),
and decoding. The output of the PMD is a PLCP Protocol Data Unit (PPDU) which includes a
PLCP header at the beginning of the frame, together with a synchronising preamble used for
training and signal lock. The device can decide the appropriate modulation required to decode
the frame body by reading the PLCP header. Once decoding the PHY layer frames is complete,
they are now available for MAC layer processing.
As the data moves through the PHY transmission pipeline, it begins to inherit the idiosyncrasies
of the underlying hardware. Timing variances, amplifier anomalies, doppler shifts, and
modulation errors leave their mark on the final signal. It is detecting and identifying these
inconsistencies that are the basis of RF fingerprinting. Current RF fingerprint identification
methods are grouped into three primary categories: transmitter imperfections, transient
changes, and modulation-based techniques. Each of these will be discussed in turn, beginning
with transmitter imperfections.
Manufacturing RF components and equipment is a high-precision exercise requiring strictly

maintained materials, environments, and techniques. The mass production and constant drive
for smaller and cheaper devices have contributed to minor but measurable imperfections. While
these devices operate within acceptable tolerances, these variations can be reliably measured.
These variations are at the centre of a field of fingerprinting research aiming to identify
individual devices based on imperfections in the RF chain of transmitters. Researchers Polak,
Dolatshahi, and Goeckel have investigated several of these anomalies, including those found
in Digital to Analog Converters (DAC), Power Amplifiers (PA) and RF Oscillators (RFO). The
early work of Polak et al. [32] focused on the nonlinear characteristics of the PA and DAC, as
shown in their transmitter chain in Figure 2.4 [32]. It was also noted that they were ignoring
the RFO because they believed that CFO was not a result of hardware imperfections.
Image Removed
Figure 2.4: Symbolic RF Transmitter Chain representation
When a DAC converts a digital bitstream into an analog signal, there is a measurable difference
between the ideal output value and the actual value output by a given DAC. This variance,
known as Integral Nonlinearity (INL), is commonly caused by variances in the manufacturing
33
process. Based on the premise that once decoded, the digital input of the transmitters is known,
the authors proposed that the INL of a given transmitter can be determined.
In the same way, Polak et al. also argued, using a Volterra series, that the relationship between
the input and output of a PA could also be determined, a variation on their previous PA work
[102]. To validate their hypophysis, the author evaluated the I/O characteristics of various sets
of PA chips used on WLAN transmitters using a 2.45Ghz sinusoidal signal measured on an
oscilloscope at 50Gsp/s. The authors assert that they achieved 100% accuracy (no identification
errors) across 5000 trials when comparing 8 IEEE 802.11b compliant PAs from the same
manufacturer. However, the authors stipulate that their work is model-based and, therefore, not
easily compared to the strictly experimental results of Brik et al. [29]. Continuing their
investigation of DAC and PA imperfections, the authors later considered the role of RFOs in
device identification.
Extending the model-based approach, Polak et al. also investigated the use of RFO
imperfections as the third principal component of the transmitter chain. This work was
motivated by the RFO being power independent due to their location before the PA in the RF
chain. Additionally, they claim that RFO fingerprinting may be a more reliable alternative to
their previous model, which could be circumvented by maintaining transmission power within
a PA’s linear region. They assert that an RFO model is not susceptible to the same thwarting
method. As per their previous work, the authors follow a limited experiment method utilising
individual components in isolation, in this case, ADF4360-1 voltage-controlled oscillators
(VCO) operating at 2.4Ghz. The output of the VCOs was captured over the wire, not over the
air, at 65Msp/s for 200ms each. As in their previous work, the authors describe the difficulty
in comparing their outcomes to previous research, namely that of Hall et al. [115] and Brik et
al., due to the unique nature of their work. They do, however, state that the motivation is the
fallibility of the Brik et al. approach using carrier frequency adjustments, as found by Danev
et al. [31], from which this approach does not suffer. The final results from their work are
ambiguous as they state that while the results outperform previous efforts, this cannot be
verified due to the different experimental approaches.
Before discussing the individual works, and that of others in similar areas, an overview of turn-
on transients is warranted. Transient fingerprinting examines the power-on transition of a
transmitter signal before data transmission. Depending on the hardware and maximum power
levels, this period can be extremely short. For example, the IEEE 802.11 PHY standard requires
a transmitter to achieve a power-on ramp from 10% - 90% of maximum power in less than 2us,
34
leaving only a tiny window for the transition sampling. Due to the short period and minimum
sample rates dictated by the Nyquist–Shannon theorem, detecting such changes requires high
sample rates, particularly for transmissions in the GHz range, and accurate transitional change
detection. The approach aims to identify devices by differentiating variances in these
transitions caused by variances in the manufacturing process of transmitter RF frontends.
Some early research on transient wave fingerprinting was that of Ureten and Serinken, which
investigated Bayesian change point detection to identify individual transmitters [125]. While it
is noted that this work is quite outdated and the details vague, it represents the start of a
significant body of work, not only for Ureten and Serinken but for transient fingerprinting. The
author's early work was on VHF radio transmissions using crude capture technologies such as
PC sounds cards with a digitisation rate of only 44Ksp/s. Over the coming years, the
frequencies under test and capture rates increased, with their investigations on IEEE 802.11
beginning in 2005 [104]. Applying the Bayesian detection techniques from their previous work,
the authors investigate the turn-on transients of numerous Wi-Fi devices. Using a dedicated
receiver and oscilloscope with a sample rate of 5 Gps/s, the same setup used later in their
expanded work, the authors captured samples from nine different IEEE 802.11b devices. While
they demonstrated the ability to accurately detect transitions using their Bayesian method, its
applicability to fingerprinting was overlooked until two years later.
Following the previous work, Ureten and Serinken expanded their detection methods to the
fingerprint identification of IEEE 802.11 devices [28] in 2007. Using the same equipment
employed previously, the authors collected one hundred samples from eight IEEE 802.11
devices. Captured data was pre-processed using a Hilbert transformation to provide
instantaneous amplitude and phase. The authors found that amplitude offered a far more
significant point of device differentiation than a phase, achieving an identification error rate of
2%. Additionally, it was noted that the ramp-up duration was also an essential identifying factor
between devices. These outcomes were later advanced by some of the most impactful research
in the area, including that of Brik et al. [29] and Danev et al. [30], and continue to be a source
of inspiration for many of the more recent advances in RF fingerprinting [126], [127] including
that in the modulation domain.
The investigation of RF features in the modulation domain became widespread following the
PARADIS study, which utilised several attributes, including magnitude, phase errors and I/Q
origin offset. Their implementation showed accuracy rates of up to 99% on a limited set of
devices. However, as Nguyen et al. highlighted [116], this approach requires a training phase
35
to collect and extract fingerprints of known devices. In addition, as with many experiments of
this type, the author's employed high-end receivers with sample rates far beyond those of a
WAP or SDR and processed data offline. However, Abbas et al. [128] demonstrated using an
SDR to identify preambles on 4G-LTE networks, reporting an accuracy of 95.5%.
Another modulation approach, similar to the PA, RFO and other models above, uses RF
imperfections caused by variations in the manufacturing process of transmitter frontends. Lui
et al. [53] investigated using phase errors derived from CSI to improve accuracy, reporting up
to 96% based on pre-trained samples. However, as the authors noted, RSSI and CSI are more
effective for location and human activity tracking due to their sensitivity to environmental
changes. In fact, CSI is so sensitive to environmental changes that it has even been used to
measure breathing rates [129]. Therefore, these features are only reliable as an identity
mechanism in a static, human-free environment, which is rarely found outside the laboratory.
Lui et al. first measured phase offset with the devices directly connected to the receiver to
overcome these external influences. Other channel-based features of a similar nature, such as
Channel Frequency Response (CFR), were investigated by Xiao et al. [111], who reported user
identification rates of 99%. Alternatively, Lui et al. [112] argue that Channel Impulse Response
(CIR) methods are superior to CFR due to complexity and the lack of spatial information.
Though not directly related to IEEE 802.11, Ramsey et al.'s work evaluating the RF
fingerprinting of Zigbee (IEEE 802.15.4) devices is worth noting. These works have been
included in the review due to a novel approach applicable to Zigbee and Wi-Fi operating in the
2.4GHz band. Early work [113] designed to protect against the Killerbee toolset [130], a
python-based Zigbee attack suite, focused on the collections of down-converted near-baseband
samples stored as complex I/Q components. Based on statistical analysis, the authors argue that
accurately and reliably identified (> 90%) using only time-domain RF statistical features
derived from preambles. In doing so, the authors propose that this level of accuracy, while not
as high as some others, is only a component of a multi-factor security approach and, therefore,
sufficient given the additional measures. The authors continued their simplified approach
[100], delivering constant accuracy using only phase offset while investigating different
classification algorithms and low-cost platforms such as SDRs.
Upon concluding their previous work, Ramsey et al. [113] noted that spectral density features
underperformed compared to time-based features, therefore the authors turned their attention
to SDRs. Using a relatively low sample rate of 25Msp/s [114], the authors reported up to 100%
accuracy in high Signal-to-Noise Ratio (SNR) conditions. While an impressive though
36
questionable result given the small sample size, the experiment consisted of only 6 Zigbee
devices and would require additional verification to validate these results, particularly in
scenarios with poor reception. Results like these showcase the usability of SDRs and the
possibility of using low sample rates and time-domain only features; however, it is missing a
real time capability. Captured RF signals still required offline processing, in this case using
MATLAB, which leaves the question of if such a model can perform in real time on a WAP.
Finally, while not considered a reliable feature in isolation due to environmental effects, the
use of RSSI can still be included as a secondary element in a feature group methodology. While
Madani and Vlajic [108] propose that RSSI identification can be an accurate classification
method, their opinion is not always shared by others, such as Xu et al. [123]. As Li and
Bharanidharan [107] report, using RSSI to differentiate devices does hold some merit for
localisation. However, as will be highlighted during the review of DoS techniques, some
deauthentication attack devices deliberately vary signal strength to make it appear that the
attacks originate from different locations.
2.3.3 Classification Algorithms and Methodologies
The final step in the fingerprinting process is classification and correlation. Classification
algorithms and approaches vary from simple state machines to complex neural networks. The
use of Machine Learning is becoming more widespread in cybersecurity and has shown better
results in detecting specific security threats than conventional methods [131]. Additionally,
applying multidimensionality, rule mining, and associative classification contribute to effective
outcomes. Table 2.2 shows the different techniques and algorithms employed to differentiate
and identify RF devices.
As early as 1996, researchers such as Toonstra and Kinser [27] employed complex Neural
Networks (NN) to classify transient signals from VHF radios. The authors begin by utilising a
Genetic Algorithm (GA) to select critical features from a pre-selected section of the transient
signal into wavelets. A GA mimics the process of natural selection in nature using crossover,
mutation and selection functions to select the most critical feature in each transient. Each
wavelet coefficient is then classified using a multilayer feed forward NN consisting of 129
neurons across four layers. The authors reported a classification confidence level of up to
98.9% and 100% accuracy from a backpropagated NN. While the use of NNs did remain of
constant interest, it has become more of a focus in recent years as understanding and computing
power have become more available.
37
Table 2.2: RF identification algorithms discussed in the literature
Author Classification Algorithm Domain

Toonstra and Kinser [27] Neural Network Transient
Wu et al. [117] Recurrent Neutral Network Transient
Gopalakrishnan et al. [132] Neural Network Modulation
Restuccia et al. [133] Convolutional Neural Network Modulation
Merchant et al. [127] Convolutional Neural Network Modulation
Ureten et al. [106] Probabilistic Neural Network Transient
Hall et al. [115] Kalman and Bayesian Filters Transient
Xiao et al. [110] Ray-traced Propagation Channel
Xiao et al. [111] Neyman-Pearson Channel
Lui et al. [112] Binary Hypothesis Testing Channel
Polak et al. [32] Brownian Bridge / Likelihood Ratio Test Waveform
Brik et al. [29] k-Nearest-Neighbour / Support Vector Machines Modulation
Ramsey et al. [113] Multiple Discriminant Analysis / Maximum Likelihood Modulation
Li and Bharanidharan [107] k-Nearest-Neighbour Waveform
Nguyen et al. [116] Nonparametric Bayesian Model Modulation
Danev et al. [31] Linear Discriminant Analysis / Mahalanobis Distance Modulation
The ongoing interest in NN is readily seen in the work of Wu et al. [117], who
investigated Recurrent Neural Networks (RNN), which use cycles within the network to
capture long context windows. The authors reported an accuracy of over 95 % for 1000 samples
and 99% for 6000 samples. Points of interest in their work include the fact that they notice little
difference in performance between using in-phase (I) or Quadrature (Q) data. Additionally,
USRP-2900 SDRs were used for the experiment suggesting a low sample rate; however, the
actual rate was not documented. Other work of interest using NNs includes Gopalakrishnan et
al. [132], who based a NN on complex values captured from IEEE 802.11 a/g devices with
99.53% accuracy and without channel distortion. Merchant et al. [127] were able to
demonstrate 92% identification accuracy using a convolutional NN on ZigBee devices on
2.4Ghz using MATLAB. Restuccia et al. [133], with their DeepRadioID system, purported to
improve the accuracy of other methods by 35% - 58% and of course, the work of Ureten et al.
[106] as previously discussed. However, while NNs can provide impressive results, they are
complex and often require extended learning times. Additionally, Hall et al. [115] argued that
the scalability of NNs prohibits their use in real time systems, proposing the use of statistical
classifiers as a viable alternative.
Statistical classifiers have widespread fingerprint use due to the lower complexity and
computational overheads than those required by Machine Learning (ML). Using a Bayesian
38
filter and a modified Kalman filter for classification, Hall et al. demonstrated a device
identification accuracy of 94% - 100% in their IDS experiment. While a model of this type
still requires that each device under test has a pre-generated profile, it demonstrated the
usability of a statistical approach. Another statistical method that Nguyen et al. [116] used is
a nonparametric Bayesian model to classify features. The use of the Bayes theory can be found
extensively in RF fingerprinting literature, though it is predominately a method for detecting
transient thresholds. However, in this example, the authors use Dirichlet distribution and Gibbs
sampling to enable a multi-variable distribution, a model that does not require devices to be
pre-registered. As a model, this method focuses on anomaly detection instead of identifying
each unique device. It, therefore, appears to be more suitable in a DoS scenario than in an
authentication requirement.
The use of machine learning in IDS introduces several challenges, as Ahmad et al. [134]
described in their study of machine learning approaches in intrusion detection. The
unavailability of up-to-date and relevant data for training and testing results is poorly designed
and validated models. Additionally, the lack of real-world testing further reduces the quality of
many systems. However, two more significant issues are the imbalanced dataset and
computational performance. These issues are to be the focus of this thesis and the core issues
that it looks to resolve.
2.4 IEEE 802.11 Impersonation Attacks

There are numerous vectors for performing impersonation based attacks on a wireless network;
however, this review focuses on the literature discussing impersonation and flood-type attacks.
The complexity of defending a wireless network comes from the fact that such attacks exploit
features inherent to the ongoing management [45] of a network session. Management frames
are used to establish and terminate client connections in addition to managing authentication,
thereby making them a prime target for attackers. The susceptibility of management frames to
attack is due to all versions prior to WPA3 being unauthenticated and unencrypted. The
inherent lack of management frame security enables attackers to masquerade as legitimate
clients, disrupting connectivity. Unfortunately, the latest version of the wireless standard
WPA3, which mandates Protected Management Frames (PMF), cannot even resolve this issue
[135], [136]. Additionally, WPA3’s backward compatibility with the previous weaker versions
[137] and its inherent vulnerabilities to DoS attacks [138] results in minimal improvement. As
39
is the case with methods that attempt to counteract attacks on a standards-based service, the
difficulty is to create an effective solution while remaining compliant with those standards.
Attacks specific to wireless networks are focused on the PHY and MAC layers of the network
stack and usually fall into one of three types. Firstly, a denial-of-service attack, which can target
either OSI layer, is designed to overwhelm a particular client or an entire network. Secondly,
attacks targeting credentials or encryption keys can also use techniques from other attack types
as a precursor. Finally, those designed for eavesdropping on user traffic may overlap with
credential attacks. While attacks on wireless networks are abundant and varied, as shown in
Table 2.3, many share a common underlying mechanism.
Table 2.3: Wireless network attack methods
Wireless Attack Type Vector Layer Target

Frequency Offset [139] DoS Impersonation PHY WAP
Preamble SYNC [140] DoS Impersonation PHY WAP
RF Jammer [140] DoS RF PHY WAP / Client
Start Frame Delimiter [140] DoS Modulation PHY WAP / Client
Symbol [141] DoS Modulation PHY WAP / Client
Network Monopolising [141] DoS Modulation PHY WAP / Client
RTS / CTS [142], [143] DoS Flow Control MAC Ad-hoc
Power Saving Mode [52], [144] DoS Power Management MAC WAP / Client
IEEE 802.11w Deadlock [145] DoS Authentication MAC WAP
Deauthentication [52] DoS Authentication MAC WAP / Client
Disassociation [52] DoS Association MAC WAP / Client
Sybil [146] DoS Impersonation MAC WAP / Client
Evil Twin [147] Impersonation MITM MAC Client
Rogue Access Point [51] Impersonation MITM MAC Client
Cafe Latte [50] Credential ARP MAC Client
KRACK [148] Credential MITM MAC WAP / Client
KARMA [149] Impersonation Preferred Network List (PNL) MAC Client
Dragon Blood [137] Credential Side Channel MAC WAP / Client
The IEEE 802.11w amendment to the standard in 2009 [150] introduced the concept of PMF
by defining a group of Robust Management Frames. This group is comprised of several post-
authentication frames, such as Deauthentication, Disassociation and Control frames, which are
the most vulnerable to attack. This amendment, which provides authentication of management
frames, protects against a number of the attacks described. However, its implementation is
complex due to the lack of support amongst current generation devices, in addition to having
its own vulnerabilities [136]. Additionally, the 802.11w standard cannot protect open networks
40
such as those commonly used in public networks, which commonly use captive portals and
MAC filtering in lieu of standard IEEE 802.11 authentication schemes.
The ability to detect and prevent an impersonation attack relies on two capabilities. A device
must determine the difference between legitimate and nefarious commands. Additionally, the
device must be able to absorb, deflect or neutralise such an attack. While incorporating both
features would provide a holistic solution, these features are often implemented separately.
Detection functionality can be provided independently by standalone sensors or integrated
directly into the wireless infrastructure as a detective control. In comparison, preventive
controls such as defensive functionality must be implemented at the point of frame processing.
2.4.1 Impersonation Attack Detection
Detecting impersonation attacks within a wireless network is complex; therefore, the advantage
is with the attacker due to the simplicity of launching such attacks [151]. As discussed, the
difficulty in detecting and preventing impersonation attacks is that many are based on the abuse
of authorised commands within the IEEE 802.11 standard. Moreover, these standards do not
implement rate limiting, meaning they do not differentiate between a command issued once or
hundreds of times in rapid succession. Therefore, this situation presents the challenge of
continuing to offer the services within the applicable standards while being able to determine
what the appropriate and inappropriate behaviours are.
One of the most common attacks is a Deauthentication attack. This attack is designed to
disconnect a client from a WAP and, if continued repeatedly, can render a network unusable
for one or all devices. The interactions between a client, WAP and attacker, as shown in Figure
1.1, demonstrate how an attacker can disrupt connectivity between the client and WAP by
falsely signalling that the client wishes to end the session. A Deauthentication request is a valid
command sent from either a client to a WAP or vice versa, used to advise the other party that
the session is no longer required. From an attack vector, it can be utilised in numerous ways. It
can disconnect a client, forcing them to reauthenticate, allowing an attacker to capture the
authentication handshake for an offline compromise. Alternatively, it can be used as a pure
DoS attack against one or more clients connected to a WAP by repeatedly issuing the command
each time a client reconnects [52]. Such attacks can be detected in various ways, both actively
and passively.
As Manjunath et al. propose in their patent [152], it may be possible to trick an attacker into
sending deauthentication requests from a MAC address that is known to be false. By having a
41
WAP transmit probe requests with random MAC addresses and triggering an alert when
receiving a deauthentication request from one of these random addresses. While the
effectiveness of such an approach has not been published, it does appear plausible though easily
circumvented. An attacker needs only verify a MAC address to be authentic by using MAC
addresses from data frames that are part of a two-way exchange, not single probe requests,
thereby ensuring they are part of a valid, authenticated session. Within the same patent, the
authors also outline the use of RSSI values to correlate the sender of a deauthentication request
with the actual client. However, these values can vary considerably with movement and
environmental changes; therefore, this method would be ineffective unless the client is
stationary. One option is to use a multi-node, MAC layer spoofing approach, such as the one
proposed by Sheng et al. [153], which may overcome the movement aspect. However, most
deauthentication attackers vary the signal strength so that requests do not appear to come from
the same device. Additionally, using a Gaussian Mixture Model from over twenty sensors as
proposed by Sheng et al. may improve detectability in large environments, it is not viable for
small deployments.
While merely counting deauthentication requests as proposed by Baharudin et al. [154] may
detect rudimentary brute force style attacks, they may miss carefully crafted credential capture
attacks that often resemble normal behaviour. The use of the SDN paradigm as a DoS attack
detection solution proposed by Cwalinski and Koenig [155] utilises an approach based on their
“RADIator” framework [89]. This system uses the Channel State Information (CSI) to help
identify clients based on proximity in a similar way to [109] and [156]. However, as discussed
in section 2.3.2, location-based solutions are subject to several issues, such as small-scale
fading due to movement [123]. While the work proposes a DoS attack detection solution, it
contains very little information on using a location-based fingerprinting solution to detect
impersonation attacks. Similarly, Nagarajan et al. [157] explains a method for varying the client
transmission power to known levels to identify MAC address spoofing.
Incidentally, the target under attack need not always be the WAP, as deauthentication attacks
can also be directed at a wireless client. The patent lodged by Sundaram et al. [158] describes
a method for detecting deauthentication attacks on a client by monitoring the requests sent to a
client and reconciling those with commands issued directly from the WAP. The patent also
describes the option of identifying attacking devices using fingerprinting and then blocking all
traffic from that device, in addition to alerting administrators of the device's possible location
based on the signal strength and triangulation information from multiple WAPs. As with most
42
patents, the authors provide no information on the effectiveness of such an approach, nor its
useability in a real-world environment.
The use of an active validation method, as described by Tamhane et al. [159], employs the Fine
Time Measurement (FTM) function to confirm a deauthentication request that a client has
issued. The FTM feature was introduced in the IEEE 802.11mc update to the standard in 2016
and has since become a common method for range evaluations [160]–[162]. The authors state
that it is possible upon receiving a deauthentication request to validate that command by
sending an FTM request from a wireless controller to the client. If two or more responses are
received, it indicates that another device is impersonating that client. Upon receiving more than
a single reply, the wireless controller is said to determine the actual client based on the time
intervals of the round-trip response. Undoubtedly, the model has some merit though it relies
on a newer standard, which is not supported on many low-end devices. Additionally, it leaves
many scenarios unaccounted for, such as purpose-built deauthentication devices that do not
respond to the false MAC addresses they impersonate. Furthermore, the possible impact of
message floods and the resources required to validate each one may cause resource exhaustion
and further exacerbate the problem.
Detecting other types of impersonation attacks follows a similar methodology; the goal is to
differentiate the real devices from the impersonators. For example, a Sybil attack is achieved
by an individual device taking on multiple identities. While these attacks are more common in
ad-hoc networks, the literature on detection is similar to many other wireless DoS attacks.
Consequently, Wang et al. [163] employed a method to detect Sybil attacks using CSI to
improve previous RSSI-only methods thereby determining the forged devices based on
location and movement. While the detection algorithm the authors employed showed an
accuracy of over 98% under ideal conditions, the authors reported flaws in the method when
people without wireless were moving around within the environment. The impact of the human
body on radio propagation has been shown to have an effect on CSI values to the extent that it
has been utilised as an environmental tracking method [164].
Rogue access points and Evil Twin attacks are also common IEEE 802.11 attacks [147]. Such
attacks are designed to mimic a WAP instead of a client. Tools such as Fluxion [22] simplify
such attacks by providing the entire kill chain from deauthentication to the captive portal. For
a rogue access point to entrap an unsuspecting client, it must broadcast beacon frames to
announce its presence. Beacon frames are transmitted every 102.4ms as per the IEEE 802.11
standard. If the broadcast intervals are shorter, Amoordon et al. [51] prosed that this may
43
signify the presence of multiple access points broadcasting the same SSID. The approach,
which the authors demonstrated as effective in limited tests, also required an auxiliary device
running in monitor mode to act as a NIDS as it was not a function the WAP was capable of
executing itself. Amoordon et al. then extended their NIDS method [165] by evaluating seven
ML algorithms to determine if the RSSI values of the beacon frames could be used as an
additional feature. They argued that no other holistic approach (single tool) could detect rogue
access points, jamming and deauthentication attacks simultaneously. However, their NIDS
could do so using a combination of beacon frame interval, RSSI, Sequence number gaps, and
management frames.
Attack detection methods that utilise machine learning at a protocol layer, such as Doshi et al.
[166], demonstrate the use of lightweight anomaly detection algorithms in IoT networks. The
authors evaluated various machine learning models to determine when a DoS attack was
underway. While performance and accuracy varied across the different models, it highlighted
the significant effort required to differentiate an attack from regular traffic. Elmrabit et al. [167]
also compared twelve ML models to evaluate their performance in anomaly detection using
the same Scikit-learn Python library [168] as Doshi et al. They determined that the Random
Forest algorithm achieves the best performance. Liu et al. [169] performed experiments to
identify IoT devices using Deep Neural Networks on the signals transmitted by commercial
aircraft to broadcast their en-route information to air traffic control periodically. However, they
only achieved 83.5% accuracy. Li et al. also used several TCP/IP features of IoT devices [170],
together with five different machine learning algorithms, with varying results. Chatzoglou et
al. [7] investigated using IEEE 802.11 together with seventeen non-802.11 features,
including ARP, IP, TCP, and UDP to improve the detection of application level attacks. A more
relevant work was that of Alipour et al. [171], which used IEEE 802.11 MAC-layer behaviour
analysis to implement a Wireless Intrusion Detection System (WIDS) that monitored device
authentication state transitions.
Unfortunately, the disadvantage of most DoS prevention techniques is their passivity; most
operate in a standalone monitor fashion. If deployed in line with traffic processing pipeline
they commonly employ a simple pass if GOOD, drop if BAD methodology. For this reason, it
appears a more dynamic approach to prevent and neutralise wireless attacks by using active
countermeasures is required.
44
2.4.2 Impersonation Attack Defences
For a wireless defence system to be effective, it must not only detect incoming attacks but
possess the capability to defend against them. Initial approaches to defending against
deauthentication attacks, such as that suggested by Bellardo and Savage [52], proposed
delaying the processing of deauthentication requests by ten seconds. While this may reduce the
impact of deauthentication attacks, it could also introduce a new set of problems. They
described how waiting an appropriate amount of time for additional frames to be sent by the
client, which, if received, would signal they had no intention of ending the session and indicate
the possibility of a third party. Though such an approach is simple and may reduce some
fraudulent requests' impact, it introduces a new issue with session handoff (roaming) when
multiple access points are in use. Additionally, the overhead of maintaining a state for
numerous clients could become a new point of exhaustion attack.
Disregarding the constraint of maintaining compliance with the IEEE 802.11 standard would
enable solutions to change the underlying protocol mechanics. They include the work of
Ananay Arora [172] and Noman et al. [173], who propose adding a unique ID to
deauthentication frames to verify authenticity. Likewise, Nguyen et al. [174] developed a letter-
envelope protocol to add signing capabilities to the deauthentication frames, while Malekzadeh
et al. [175] proposed including a keyed message authentication code. Unfortunately, all these
proposed solutions require not only a deviation from the IEEE 802.11 standard but also a client-
side modification. While such approaches may appear complex, they do illustrate the option of
using a bespoke method instead of PMF. Additionally, the difference in processing overhead
compared to PMF is an unanswered question. The nature of connectivity and data requirements
of the client device also adds another variable for consideration.
It is common for wireless devices to maintain a long-term connection to a WAP; however, this
is not always the case. Due to power limitations and irregular data patterns, many IoT devices
may only connect to a WAP when they have data to transmit. The simplicity, low computing
capabilities and power constraints of IoT devices make security a problematic task. Butun et
al. [176] stated, “IDS techniques become more important for IoT systems, as some of them are
even efficient against zero-day-attacks. If the necessary IDS techniques require high
processing power, gateway devices can be employed for this purpose.”. While using IDS is an
option, it often comes with high complexity and cost. The presence of rogue devices continues
to be a significant risk in IoT networks so the ability to correctly identify devices is paramount
[177].
45
Such concerns motivated Raghuprasad et al. [178] to investigate a MAC randomisation
method. As the first step in a large-scale wireless DoS attack is gathering a list of the MAC
addresses of the connected client devices so they can be spoofed in deauthentication or
disassociation messages. The authors propose that the IoT device uses a random MAC address
each time it connects to upload data. Therefore, any DoS attacks will use a previous MAC
address and not affect the current connection. While possibly an effective solution in limited
scenarios, it requires client-side functionality. It would also create a significant performance
impact for continually connected devices to repeatedly reconnect, in addition to the possibility
of MAC address clashes.
2.5 Defensive Tactics and Strategy

In the context of cybersecurity, a wireless network can be likened to a battlefield. Consisting
of known and unknown actors, lines of supply and subversive attacks, therefore, it seems fitting
to consider battlefield tactics as a source of inspiration. Indeed, the use of military tactics is
becoming widespread in the area of cybersecurity [179]. For example, one such military
concept commonly used by cybersecurity professionals is that of a Cyber Kill Chain (CKC)
[180], [181]. The idea was later extended by Wilkens et al. [182], who demonstrated the
approach using a Kill Chain State Machine (KCSM). A CKC defines the order of tasks used
by a third party to execute an attack. The original military use of a kill chain model consisted
of the following steps – Find, Fix, Track, Target, Engage, and Assess (F2T2EA). While in the
cybersecurity world, these steps have been appropriately adjusted to Reconnaissance,
Weaponisation, Delivery, Exploit, Installation, Command/Control and Actions. It is proposed
that the attacker can be defeated if one can break this chain. However, to do so, one requires
knowledge of the current threat conditions.
The concept of Situation Awareness (SA), defined as the understanding of current threat and
attack status, was described by Barford et al. [183] as having at least seven aspects.
• Be aware of the situation.

• Be aware of the impact of an attack.
• Be aware of how situations evolve.
• Be aware of actor (adversary) behaviour.
• Be aware of why and how the current situation is caused.
• Be aware of the quality (trustworthiness of information).
46
• Assess plausible future states.
The authors later consolidated these seven levels into three phases: Perception, Comprehension
and Projection. The authors describe what they refer to as the “dream” system that can
determine its situational awareness and protect itself when under attack without human
intervention. However, they state that such a system is far from what is possible with current
technologies. Andrade and Yoo [184] demonstrated that the same three phases were to align
with another military model, which appears particularly suited to this research: the OODA loop.
Developed by the United States Air Force Colonel John Boyd, the Observe-Orient-Decide-Act
(OODA) loop is an operational tactic designed to improve agility against an opponent, which
he based on his “Destruction and Creation” concept [185]. This approach is employed
extensively in cybersecurity and is also commonly used in business, law enforcement and even
sports.
The tenant behind the OODA loop is that if one can complete an OODA loop faster than the
opponent, one can be prevented from gaining superiority in combat. In the same way, if a
defender can act more quickly than an attacker in a cybersecurity conflict, they can achieve
“cyber superiority” [186]. As Dykstra and Orr describe in comparison to their Cynefin model
[187], “the OODA loop encourages agility and speed to react to our opponents.” Additionally,
by inserting oneself into an attacker’s OODA loop, it is possible to discover a tactical advantage
by learning intent and the individual steps in their CKC. It also enables an opportunity to
provide false or contradictory information to disrupt or “poison” their orientational beliefs,
thereby leading them to make wrong or suboptimal decisions.
Firstly, consider each step in turn and deconstruct the OODA process within the context of
cybersecurity. Figure 2.5 [188] illustrates the interaction between the four core areas, each
providing feedforward and feedback as new information becomes available, allowing the best
possible decisions.
47
Figure 2.5: Components of John Boyd's OODA Loop
Observe: The primary source of incoming information in a cyber-attack is often assumed to

be that contained within the incoming packets or frames at the time of the attack. However,
there are numerous other vectors of information that can be beneficial to the effectiveness of
the overall solution. Overall situational awareness is essential in understanding the threat
landscape and determining changes that may be precursors to an attack.
Orient: Analysing incoming data and placing it within a set of learnt or predetermined rules
allows the model to differentiate and organise information in a way that enables the system to
develop a hypothesis. This hypothesis becomes the basis of the decision process in the next
step.
Decide: Once the system has formed a hypothesis on an adversary's intentions, a decision needs
to be made on how the model will react. Additionally, the system can feed this into the
observation step to further reinforce or challenge future observations.
Act: Actions may include tests of the hypothesis, producing further feedback, or standalone
responses based on preconfigured reactions.
The OODA loop is analogous to other cybersecurity models, as demonstrated in the technical
report by Gray et al. [189]. In this report, the authors present a logical mapping between the
OODA loop and the cybersecurity principles set out by NIST in the information risk
publication 800-39 [190]. The alignment shown in Figure 2.6 proposes that the tenets of NIST
800-39 can be categorised into the four core tenants of the OODA loop, however, the NIST
model does not follow a sequential process like the OODA loop. Both are equally appropriate
48
models for managing organisational responses to cybersecurity, though Gray et al. argue that
the OODA loop is particularly well suited to adoption as an algorithm.
OODA LOOP Observe Orient Decide Act
NIST 800-39 Monitor Frame Assess Respond
Figure 2.6: A comparison of OODA Loop and NIST 800-39 concepts
The sequential nature of the OODA loop, together with the sectional feedback mechanism,
could be categorised as a state machine. This observation will be discussed in greater detail in
later sections of this thesis.
2.6 Review Summary

Accurate and timely wireless data is of the utmost importance for optimisation, security, and
capacity research. As shown in the preceding sections, several methods for accessing IEEE
802.11 data are possible, with each approach providing different opportunities and
complexities. In later chapters, many will be considered for further investigation and new
methods will be discussed. However, to summarise the insights gained from this section, it
needs to be placed in the context and scope of this thesis.
While the ability to reliably access PHY layer data in real time is often limited by the
commercial nature of the IEEE 802.11 devices currently available, open-source work on SDR
and FPGA implementations does show significant promise. That is not to say the architecture
is without its challenges, such as the difficulty of strict SIFS timing requirements and the
complexity of providing a usable application interface. However, the model is a substantial
stepping stone for the data access requirement of this research. What is missing from the SDR
and FPGA literature is the analysis of modulation and encoding anomalies which were common
within the experiments involving high-end receivers and offline processing. On the other hand,
accessing MAC layer data appears to be an area of continued interest among researchers.
49
2.6.1 Wireless Data Access
While extensive, the literature involving MAC layer data does contain a limited set of
methodologies. Firstly, monitor mode and its associated interface is a simple, efficient
approach. However, while monitor mode offers simplicity, it lacks control due to the read-only
nature of the interface. While this may not present a problem for simple data analysis
applications, it does prove challenging in scenarios where the goal is to limit or modify the
traffic under test. Furthermore, placing a NIC into monitor mode restricts its use in other
wireless modes, such as the infrastructure mode required in a WAP. Therefore, a method for
dedicated monitoring stations, like those used in Intrusion Detection Systems (IDS) and mobile
device tracking, is not suitable for domestic situations. While the literature on low-level data
access is reasonably robust, the pipeline processing of that data is less so. This gap prompted
the investigation into SDN literature to find a viable alternative.
2.6.2 Software Defined Networking
The concept of SDN has its pedigree in wired network security which is evident not only in the
literature but also from its real-world deployments. While one of SDN’s most recognised
protocols, OpenFlow, does enable rudimentary control for wireless networks by governing
traffic at a network interface level, its effectiveness is limited. The OpenFlow standard has no
provisions for any of the IEEE 802.11 frame formats as it is very much ingrained in the IEEE
803.2 Ethernet standard. However, the introduction of the P4 programming language does offer
a ray of hope as it allows user-defined data formats and therefore provides the possibility of
creating a pipeline compatible with the IEEE 802.11 MAC layer frame. Notwithstanding its
flexibility, it does lack a mechanism for integration into the wireless networking stack. This
lack of wireless integration capability is again due to the SDN heritage as a wired network
architecture, as P4 is also designed as a data plane programming language for Ethernet
switches.
Overall, the SDN literature review has found assorted options for accessing both PHY and
MAC layer data; however, the methods discussed tend to be specific to the task at hand and
therefore lack the extensibility that an SDN option would offer. Additionally, the literature
shows that the vast majority of work in this area is not suitable for use on a WAP either due to
the requirement for specialist equipment or the closed nature of IEEE 802.11 hardware. These
gaps in the literature confirm there is little existing knowledge on the use of SDN as an IEEE
50
802.11 frame processing method capable of providing access to the data in all OSI layers, hence
Research Question 1.
2.6.3 Wireless Device Identification
The fingerprinting of IEEE 802.11 devices is shown to have been of considerable interest to
researchers for many years. While a range of features are available for fingerprinting and the
collection methods vary, it is essential to understand that a significant proportion of the
literature reviewed takes place under controlled conditions. Furthermore, the devices used for
testing are commonly stationary, unencumbered by environmental factors and operating within
optimal parameters. Therefore, it would be fair to say that if performed in real-world scenarios
where, for instance, the user’s device is in their pocket while they walk between rooms in a
building, the result would be significantly different. Combining these environmental variances
with the limited capabilities of a WAP and many current methods would not produce results
close to those observed in the literature. There is also a lot to be said for simplicity and the
ability to implement a solution with limited resources.
As Ramsey et al. [113] demonstrated, fingerprinting can be utilised as a part of a multi-pronged

approach to device identification. Given this argument, one could also reason that
fingerprinting, when used this way, may not require the high levels of accuracy purported by
various researchers. These results are often delivered under perfect conditions, using high-end
lab equipment and post-processed offline using powerful computing resources. Additionally,
their results were achieved using only steady-state amplitude, phase and frequency conditions,
which require considerably fewer computational resources to process than rapidly changing
signals.
The fingerprinting literature highlights little existing knowledge to confirm whether the low
RF sample rates on a wireless access point can contribute to accurate device identification in
real time, hence Research Question 2. Furthermore, the possibility of lower accuracy due to
the technology limitation of a wireless access point combined with the uncertainty of real-
world conditions also remains unspecified. Finally, the ability of behavioural inputs to improve
accuracy has also not been addressed, reinforcing the need for Research Question 3.
2.6.4 IEEE 802.11 Impersonation Attacks
The ease at which IEEE 802.11 attacks are executed is almost always due to the exposed nature
of management frames. Neither authenticated nor encrypted frames form the basis of an
51
impersonation attack, an issue that has been evident for many years. While there was an attempt
to address it in the IEEE 802.11w revision, it continues to leave the architecture vulnerable.
While Protected Management Frames (PMF) in the IEEE 802.11w update provide improved
security, it has had little impact as very few hardware manufacturers have implemented it. The
reasons are threefold, cost, complexity and performance. While various WAP manufacturers
support the standard on their devices, the clients omit these functions because many do not
have the computing capacity to support them.
Furthermore, it is common for IoT devices to only include the bare essentials to reduce cost,
as most equipment in this genre requires minimal functionality. Given these constraints,
researchers have looked to other options to fill the security void of such an omission.
Consequently, researchers have turned to device differentiation to mitigate this shortcoming.
The need to differentiate between an attacker and a legitimate client is a common thread in
impersonation attack literature. Such an approach is understandable given that impersonation
attacks use valid commands which are part of the IEEE 802.11 standard and, therefore, cannot
be ignored. A constraint such as this leaves only one path. If one cannot identify the command,
then it must identify the sender. Unfortunately, many approaches implement only basic
fingerprinting features, such as CSI or RSSI, both unreliable in real-world scenarios and easily
falsified by an attacker. This again reinforces the need to answer Research Question 3, which
would provide some much-needed accuracy to the identity deficiency and provide an extensible
framework for a more sophisticated defence strategy.
2.6.5 Defence Tactics and Strategies
While the review of the impersonation attack literature was specific to a subset of the many
IEEE 802.11 attack types, it does highlight the varied and widespread nature of the security
problems inherent in the medium. It also emphasises the similarity of the current approaches
in the existing body of literature, with many utilising the same methods as non-wireless DoS
attack detection algorithms, namely volume thresholds. Such techniques are known to not only
produce false positives but also miss more subtle attacks [191]. Therefore, it would be
appropriate to say that many of the impersonation attack detection techniques currently
employed in IEEE 802.11 networks lack maturity, thereby warranting a new approach.
Additionally, the research is heavily skewed towards detection and lacks depth in defence
techniques, far from the “dream” system Barford et al. envisioned. Therefore, this thesis
52
considers a new direction as a tactical advantage gained by understanding behaviour and the
events preceding an attack.
The tactics used to defend technology systems within cybersecurity have been a natural
progression from centuries of human warfare. Undoubtedly, the weapons may be new;
however, the motivations, techniques and goals remain the same. As John Boyd demonstrated
with OODA loops, the ability to out-think an opponent by understanding each action and the
determining logic between that decision is the key to victory. After all, it is still a human
adversary with a known goal, and that goal can be understood if one knows what to look for.
Therefore, the distillation of that understanding will answer Research Question 4, which is
lacking in the current literature. The need to move away from a purely reactive methodology
and embrace an offensive strategy may be the only way to remain ahead of an unrelenting
onslaught of new attacks.
2.6.6 Conclusion
In conclusion, this literature review has examined the current state of research on the origin
and evolution of the SDN paradigm, the need for a new approach to wireless device
identification and the inefficiencies of IEEE 802.11 impersonation attack detection and
prevention. The broad range of topics investigated highlights the complexity of solving the
problem of impersonation attacks while operating in a real-world environment under
unpredictable conditions. Additionally, it is very challenging to combine multiple technologies
outside a lab environment in a way that does not introduce an unwarranted level of complexity.
53
Chapter 3.
An SDN IEEE 802.11 Frame Processing Pipeline
3.1 Introduction
The development of Software Defined Networking enabled independent, user-programmable
controls to an otherwise static network. At the core of the SDN architecture is the separation
of the control and data planes, which allows a centralised control model. This paradigm shift
has attracted considerable research interest. Specialised controller software delivers the control
plane functionality, commonly residing on dedicated server infrastructure. Several SDN
controller platforms are available as commercial and open-source software offerings.
SDN controllers often utilise the OpenFlow protocol to provide instructions for managing
“flows” on the data plane of compatible switches. Until recently, the data plane functionality
of these devices has been relatively fixed based on the OpenFlow protocol specifications. These
restrictive standards, designed specifically for Ethernet switches, provide only a fixed set of
supported header types. While it could be possible to modify the OpenFlow header format, it
would require significant modifications to the data plane, the OpenFlow network protocol, and
the OpenFlow controller. Such changes would also ensure that these modifications would no
longer be compatible with any standard OpenFlow hardware or software. These header
restrictions prompted the development of the P4 data plane programming language.
P4 is a high-level, domain-specific language designed for programming network data planes

that enable network operators to create custom functionality. Its strength lies in protocol
independence, enabling header fields to be defined by the end user. Unlike OpenFlow, in which
the fields are predefined. The user's ability to process custom protocols and create algorithms
without input from the device manufacturer enables them to maintain complete control of their
intellectual property. The capability to define custom packet headers can allow the application
of SDN functionality to wireless protocols such as IEEE 802.11, which was not previously
possible with OpenFlow. In this manner, the application of P4 provides a range of new research
opportunities for wireless networks, predominately in security and device management.
OpenFlow and P4 each have their strengths, weaknesses, and differences in functionality.
However, based on the literature, there have been limited direct comparisons between
OpenFlow and P4. Therefore, the first task required to answer RQ 1 was understanding how
54
these two approaches compare in performance and functionality. Once a review of the most
suitable SDN model is conducted, an original method for integrating the chosen system into
the wireless data plane is investigated in section 3.3. The novel outputs of this chapter generated
two conference papers [192], [193]. The source code, readily available on GitHub [194], is
being utilised by other researchers to investigate using the P4 programming language.
This chapter makes the following specific contributions:
• A custom P4 compiler extension that produces firmware for the Zodiac FX SDN
switch hardware, allowing it to run P4 applications natively.
• A method for comparing the functionality and performance of Open Flow and P4.
• A second P4 compiler extension to enable the generation of a P4 data plane, which
integrates directly into the Linux wireless driver. This unique model allows a P4
application to process IEEE 802.11 directly without hardware modifications.
3.2 Comparing OpenFlow and P4
3.2.1 Overview
OpenFlow has significantly impacted computer networking and ushered in the Software
Defined Networking (SDN) age. Now the P4 programming language promises to drive this
innovation even further by allowing the unparalleled customisability of network devices. Even
though they have different capabilities and goals, there is still an overlap in functionality
between OpenFlow and P4. This commonality, predominately in how packets are processed,
has not been compared and therefore remains a question that could impact the research
outcome. Thus, the first stage in answering RQ1 is determining the most suitable SDN
technique by performing a non-biased comparison of OpenFlow and P4.
The primary reason for the absence of comparison data lies in the physical deployment model
of these technologies. The inability to isolate pipeline processing and perform a comparison
based on identical functionality and hardware without the external influence of auxiliary
functions has made this measurement difficult [80]. As discussed in section 2.2.6, PISCES, a
software switch derived from OVS, is the closest solution where an existing OpenFlow switch
was retrofitted with P4, and a comparison was performed. However, it did not consider the
effect of the underlying Linux operating system. Therefore, it is essential to remove any
external variations that will affect the comparison, including differences in hardware
55
architecture, operating system or multitasking overhead and external software dependencies.
This is only possible by performing a comparison on the same hardware with no operating
system interference.
3.2.2 Common Evaluation Platform
Due to the architectural differences between OpenFlow and P4, it can be challenging to perform
a direct comparison. The predominant focus of OpenFlow research has been the protocol and,
by extension, the control plane applications. Therefore, little research has investigated the data
plane aspects of the implementation. This is predominately due to hardware vendors creating
ASIC implementations of the OpenFlow API, so the source code is usually protected. Software
switches such as OVS are open-source, and the code is readily available; however, significant
code changes are required to replace OpenFlow completely and cleanly and core switching
functionality, as seen in PISCES. The Zodiac FX switch, shown in Figure 3.1, was designed
and first manufactured by the author of this thesis in 2015 and sold commercially for over four
years. This small, affordable USB-powered device, used primarily for research and teaching,
has been featured in more than 30 peer-reviewed papers.
Figure 3.1: The Zodiac FX SDN Switch hardware
It uses low-cost, off-the-shelf components such as an Atmel (now Microchip) ARM processor
and a Microchip Ethernet switch chip. Even though the Zodiac FX incorporates hardware Layer
2 switching, it is primarily a software switch by design, with all the packet forwarding decisions
made by the MPU. This architecture allows the device to become an experimental networking
56
platform, enabling complete control of packet processing. To this end, it became a suitable
choice for a comparison testbed.
This device is based on the Microchip KSZ8795CLX [195], a 5-port, layer-2 managed Ethernet
switch chip. It is used primarily as a layer-1 Ethernet interface providing physical transceivers.
However, some minor layer-2 functions are utilised, such as counters and VLAN management.
As packets enter the KSZ8795CLX, they are redirected to the CPU using the 802.1x
authentication feature, thereby ensuring that the CPU processes all packets. VLANs are
typically used to separate client and controller traffic when operating as an OpenFlow switch
to allow the controller to run in an Out-of-Band (OOB) model. As the P4 implementation does
not utilise a controller, all ports are part of a single VLAN.
The OpenFlow code in the Zodiac FX firmware can now be considered a mature product as it
has received over 80 updates in the past four years from the manufacturer and numerous outside
contributions. Therefore, it is assumed that the OpenFlow pipeline performance is in an
optimised state suitable for use as a baseline. For the OpenFlow portion of the test, version 0.86
of the Zodiac FX firmware was used.
3.2.3 P4 Compiler Design
To allow code written in the P4 language to be executed on a target, P4 must first be compiled
into a format that that device can understand. This output may be in various forms, such as C
source code, JSON, and binary executables. Converting the human readable P4 language into
a platform format requires using a compiler, as most high-level programming languages do.
The P4 compiler described by Henning Stubbe [79] is an extensible, architecture-independent,
open-sourced implementation that consists of three distinct sections, as shown in Figure 3.2
[196].
The front-end, mid-end, and back-end sections can be customised and modified to suit the
target device’s requirements. All three compiler sections are required to complete
implementation; however, the back-end explicitly provides the platform-specific code. The
front-end and mid-end are responsible for enforcing the P4 syntax, structure, and internal
dependencies. The P4 program structure and syntax are standard among all target platforms.
57
Figure 3.2: Major components of the P4 Compiler architecture
Therefore, a library of pre-built passes is used to create the front-end and mid-end sections.
The front-end passes are fixed; however, the mid-end passes are combined differently
depending on the target platform’s requirements. Each of these sections has unique
functionality and can be described as follows:
Front-end: The compiler’s front-end performs several distinct passes to validate and type-
check the P4 program for compliance with the P14 or P16 language standards. This compiler
implementation leaves this section unchanged.
Mid-end: These components create action and table statements and perform various
architecture-independent optimisations. As the compiler version used in these initial
experiments does not currently support tables, only the P4 optimisation libraries are used.
Back-end: Back-ends are explicitly written for the target platform to create the final device-
readable output. In the case of this thesis, an entirely new back-end module was developed to
generate code for Microchip Studio [197], in architecture compatible C code, that can be
integrated directly into the Zodiac FX firmware. In addition to Atmel-specific types, all new
interfaces for external libraries, module entry points, header parsing/de-parsing and memory
management functions have also been developed specifically for this implementation.
3.2.4 Performance Comparison
Overall functionality must be considered equivalent to ensure a realistic comparison of the P4

program and an OpenFlow match/action pipeline. Therefore, it is only the data plane aspects
of the two models that are being evaluated. Using an approach similar to that of Costa et al.
[98], two preliminary tests were conducted, the first with UDP packets of varying sizes and the
second using TCP packets of varying sizes. The iPerf3 [198] measurement tool was used for
58
both generating client packets and server-side bandwidth utilisation measurements. Tests were
performed using UDP and TCP packets with payload sizes ranging from 64 to 4096 bytes, with
each variation executed ten times, and the results averaged. A bandwidth limit of 100Mbps was
also defined, as this is the maximum throughput of the Zodiac FX Ethernet ports.
Firstly, tests were performed on the device with no firmware installed, so all packet processing
was done entirely by the Microchip KSZ8795CLX to provide a baseline. Packets were
generated by an iPerf3 test client connected to Port 1 of the Zodiac FX with the iPerf3
measurement server connected to Port 2. For the OpenFlow tests, an RYU [199] OpenFlow
controller was connected to Port 4, thereby allowing the installation of the required flows using
version 1.3 of the OpenFlow specification.
The P4 program used in these tests was written to send the packet out to a predefined output
port based on the port from which the packet was received. In a similar approach, the OpenFlow
tests only require installing two flows with matches based on the input port and a single
Packet_out action to the specified port with no controller interaction. The P4 and OpenFlow
performance when processing UDP packets of varying sizes exhibited little statistical
difference, as seen in Figure 3.3.
Figure 3.3: Performance Comparison of the UDP protocol
Other packet size measurements remained similar despite a 23% throughput improvement by
P4 for the 64-byte packets. Also, the UDP packet loss due to the Ethernet buffers’ backpressure
was comparable in both circumstances, showing a minimal performance variation to that of the
59
hardware only tests. The results from the tests involving TCP packets began with determining
maximum throughput based on packet loss, as shown in Table 3.1.
The high loss rate with small payload sizes indicates a packet per second (PPS) limitation of
the hardware. This is caused by the hardware not being able to process the large volume of
small frames resulting in a higher loss rate when there is no software processing involved.
However, this phenomenon significantly reduces as the frames approach the KSZ8795CLX
maximum size of 1518 bytes.
Table 3.1: Percent of packets lost when using the TCP protocol
Payload Size (bytes) Hardware Only P4 OpenFlow

256 85% 83% 82%
512 35% 41% 39%
1024 7.7% 0.88% 0.58%
2048 1.4% 1.7% 1.6%
4096 2.2% 3.3% 3.0%
At this point (>2048 bytes), the packet loss rate diverges between the three approaches due to
the CPU’s software processing overhead. This explanation also correlates with the result shown
in Figure 3.4, with the device reaching a saturation point at packet sizes of 1024 bytes.
Figure 3.4: Performance Comparison of the TCP protocol
However, OpenFlow did not achieve maximum throughput until a packet size of 4096 bytes
indicating a compound performance impact of resending dropped packets.
60
3.2.5 SDN Model Evaluation Summary
This section evaluated the performance and customisation benefits of P4 over OpenFlow by
utilising a common execution platform. The predominant argument for using P4 is the ability
to deploy only the required functionality, thereby increasing throughput by removing the
redundant features that may reduce packet processing performance. Based on these tests, it was
found that there is minimal difference in performance between the optimised OpenFlow
firmware and the P4 packet processor on the Zodiac FX. However, this significant reduction
in the size of the P4 firmware binary and the OpenFlow version contributed to the hypothesis
that substantial code reductions are possible with P4. This attribute is essential when
considering the use of a WAP. These results also align with those of the PISCES experiments,
which concluded that other than code size, there is little difference in performance overhead.
3.3 Integrating P4 into the IEEE 802.11 Data Plane
3.3.1 Overview
While the SDN model has made significant inroads in wired networks, the impact has not been
as notable in the wireless networking space. One reason is that the existing SDN approach,
predominately OpenFlow, is restricted to the network interface level as their match-action
pipelines are only capable of processing Ethernet frames and cannot address the underlying
wireless elements. The introduction of the P4 programming language allows developers to
create custom data planes, including definable packet parsers. This functionality enables the
construction of data planes that may be capable of parsing IEEE 802.11 wireless frames.
In this section, a new and novel P4 compiler extension was developed to enable the generation
of a custom P4 data plane, which is accessible by a Linux wireless driver. It allows the
processing of previously inaccessible management frames such as beacons, probes, and
deauthentication requests. This method of creating packet header parsers for wireless protocols,
such as IEEE 802.11, was not previously possible with the OpenFlow protocol.
3.3.2 Existing Wireless SDN Methods
Based on one of two conventional approaches, the prior applications of SDN in wireless
networks are either via an externally connected OpenFlow switch or an OpenFlow installation
inside the Wireless Access Point (WAP). Each approach offers varying functionality, flexibility
and cost and therefore requires independent consideration.
61
A standard method of implementing SDN in a wireless network is installing OVS directly onto
the WAP. The open-source router software OpenWRT [49] makes this relatively
straightforward by providing a packaged OVS build for the platform. There are, however,
various limitations to this approach.
Figure 3.5: The OVS integration architecture
Firstly, as OVS operates at the network interface level, as shown in Figure 3.5, all wireless
clients share a single ingress port, limiting the ability to differentiate them by an OpenFlow in-
port. Additionally, there is no facility to capture or control packets transmitted between
wireless devices connected to the same wireless interface, negating the ability to control and
investigate the interaction between devices. Finally, there is the added complexity of compiling
and configuring a custom firmware that will only execute on hardware devices supported by
OpenWRT.
The second alternative to deploying SDN in a wireless network is at the distribution switch
level. Connecting existing WAPs to an OpenFlow compatible hardware switch allows flows to
be applied to the traffic moving between the wired and wireless networks. Connecting devices
in this way also allows traffic entering the OpenFlow switch from the WAP to be redirected
back to the same WAP, sometimes to a different wireless client.
62
Advantages of this approach include using any WAP without modification, reducing
complexity, setup effort and cost. However, the method does limit the depth of control by
aggregating all traffic into a single logical OpenFlow port, thereby limiting controllability.
While this deployment model could utilise a P4-enabled switch it would still not provide access
to the IEEE 802.11 frames. Additionally, the literature review found no published research
using a P4 switch in this way.
3.3.3 Creating a Linux Kernel Module
The compiler back-end created for this implementation, called Wireless P4 (WP4), outputs
Linux Kernel Module (LKM) source code. The compiler is also responsible for constructing
the required kernel module framework. Therefore, in addition to defining the standard kernel
module_init and module_exit functions, it creates a single WP4 method entry point that can be
called by the Linux networking stack. The kernel module exports this WP4 entry function as
wp4_packet_in, which can then be referenced as an extern by any other kernel module. The
entry point accepts a pointer to the raw packet buffer in addition to an input port value. The C
source code generated by the WP4 compiler can then be built either independently, as a
standalone kernel module, or as part of the overall Linux kernel build. The kernel module’s
loading is the same as any Linux kernel module, using the insmod command, and has no
external dependencies.
The successful integration of a P4 application relies on the ability to receive raw wireless
network frames to process. As discussed, previous implementations of an SDN approach on a
WAP have used OVS and network interfaces, a model unsuitable for deep frame processing.
For the P4 application to receive the raw wireless frames, it needs to access the data during the
wireless frames’ processing and, therefore, must be integrated directly with the Linux wireless
subsystem.
The Raspberry Pi (RPi) [200] platform was chosen to minimise complexity and cost when first
evaluating the P4 to Linux wireless networking integration. When examining the Linux
wireless implementation on the RPi, the most suitable place to create the integration was
directly from within the receive frame function of the wireless device driver LKM. In the test
platform, the Realtek rtl8812a module is responsible for processing the IEEE 802.11 frames
from the wireless hardware, which in this case, is a TPLink Archer T4U USB adaptor. The
rtl8812a is a software-based MAC driver (SoftMAC) providing all the MAC layer functions
such as authentication, association, and probe requests.
63
Figure 3.6: The Wireless P4 integration in the Linux network path
The diagram in Figure 3.6 provides a high-level view of the significant components and the
interconnectivity within the test system.
The current architecture is limited to the flow of wireless frames in one direction, from the
rtl8812a driver to the kernel module. There is currently no facility for generating or transmitting
frames created with the module. While such an approach allows processing received frames, it
limits the creation of custom frames by the data plane. Additionally, a controller’s more
traditional packet_out type function is not required at this stage. Packets are buffered in the
data plane and released or discarded based on the control plane’s response to future packet_in
functionality. This method is a similar approach to the way OpenFlow uses a buffer_id value,
which allows only the headers to be sent to the control plane, reducing the amount of data to
be transferred. In the context of security-based P4 applications, the ability to create and transmit
custom frames is not required at this stage, though it will be in later chapters.
Wireless frames are validated within the rtl8812a LKM, and management frames are processed
before being sent to the network interface and then the core networking stack. The integration
point in the rtl8812a module is from the validate_recv_frame() function from the module’s
rtw_recv.c source file. Calling the WP4 entry point directly from within this function allows
access to all wireless frame types, including management frames. This method also facilitates
the novel addition of other data, such as RF information to be appended to the frame and parsed
in the same way as the other frame header contents.
64
3.3.4 P4 Parser Code
The flexibility of P4 allows the IEEE 802.11 header to be defined independently, as the
following code fragment in Figure 3.7 demonstrates.
Figure 3.7: Wireless P4 header block provides the IEEE 802.11 field definitions.
P4 allows a user to define the frame header structure in a manner that allows only the fields of
interest to be extracted, down to the bit level if required. The Parser Block section is responsible
for extracting the header information from the frame, and the Control Block section of the P4
program provides the ability to modify and manipulate that header information. Additionally,
within the Control Block, a table construct can enable the commonly known SDN match-action
paradigm to be performed based on a key and corresponding action. Such actions may include
modifying the frame contents, passing it to an external controller or even dropping the frame
entirely.
The final section of the P4 program is the Deparser Block, in which any modifications to the
header values made by the Control Block can be inserted back into the frame before being
released. At this point, packets would typically be returned to hardware for physical layer
processing using the P4 emit function. However, in the WP4 architecture, buffers are owned
by the rtl8812a module allowing the new deparser to update these values directly before
returning control to the Linux wireless networking stack with a PASS or DROP value. As a
65
result, this approach creates a novel method for filtering frames in a WAP, which was not
previously possible.
3.3.5 Evaluation
A test P4 program using the new WP4 compiler extension was created to evaluate this unique
wireless architecture. The resulting C source code was then compiled independently of the
Linux kernel source tree, and the Linux build configuration was modified to incorporate the
new LKM. A custom WP4 patch was also developed and applied to the existing Linux rtl8812a
device driver module to create a hook for the WP4 module’s function call. This additional
function call passes the IEEE 802.11 frame buffer pointer to the WP4 entry point. The rtl8812a
kernel module was then compiled in the usual manner and was loaded on an RPi configured as
a wireless access point using hostapd. Additionally, various kernel logging points were created
to assist in debugging.
Two performance measures were taken to determine the processing impact of the new WP4
module. Firstly, the execution time of the WP4 entry point was measured using clock samples
taken within the rtl8812a module before and after functions call to WP4. Secondly, the network
throughput was measured with and without the call to WP4 to determine the network
performance impact of the additional P4 processing. As shown in Table 3.2, the results provide
details on the average per frame duration of a call to the WP4 module. The sample WP4 module
under test was based on a P4 program featuring a parser previously shown in Figure 3.7,
together with a simple Control Block to match the header values, and a Deparser Block.
Table 3.2: The impact of Linux kernel performance when using the WP4 kernel module
Frame Type Avg. Frame Size (bytes) Avg. WP4 Call Duration (ns)
Management 212 998
Control 20 781
Data 1163 317
Once the header fields have been defined, it is then possible for the Parser Block to extract the
required information. While in the Parser Block, the P4 program utilises the packet.extract
function to isolate the wireless frame type field, thereby allowing the program to transition
based on the value. It then performs a conditional branch determined by the type of IEEE
802.11 frames. A management frame state function extracts the subtype field from the frame
header. Parsing is now complete, with the headers transferred to the Control Block of the P4
66
program for further processing. Call duration for frame sizes larger than 64 bytes is relatively
similar, as shown in Figure 3.8, while the WP4 call duration for small frames (< 64 bytes) is
disproportionally longer. Frames of this size are predominately DATA NULL and DATA QoS
NULL frames and therefore contain no payload.
Figure 3.8: WP4 call duration with different frame sizes
Furthermore, network throughput was evaluated to understand the overall impact of using the
WP4 module. As the bandwidth results in Table 3.3 outline, the effect on network performance
of the WP4 module indicates a reduction in average data throughput for TCP and UDP packets
at < 4% and < 9%, respectively (n=600).
Table 3.3: The network throughput impact when using the WP4 kernel module
Packet Type Without WP4 Module (Mb/s) WP4 Module (Mb/s)

TCP 108.9 104.9
UDP 114.1 105.5
In addition to the performance evaluation, the effectiveness of the WP4 model as a security
research tool was also investigated. As many wireless network attacks take advantage of
unencrypted and unauthenticated management frames, the visibility that a P4 parser offers can
67
be of significant use. In fact, a novel method of detecting such attacks is investigated in Chapter
6. However, the test P4 application in this chapter included a prototype check for the
deauthentication subtype and dropped the frame to validate our WP4 approach’s capabilities
in such a scenario. To drop such a frame, the WP4 kernel module produces a DROP flag, a
return value of -1, and the wireless driver discards the frame and clears the skb allocation.
In a typical wireless deauthentication attack, the attacker sends client deauthentication frames
that include the connected clients’ MAC addresses. Upon receiving those requests, a WAP will,
per the IEEE 802.11 standards, disconnect those clients to release the allocated resources. If an
attacker continues to send these deauthentication frames, the clients will be disconnected again
as soon as they reconnect, effectively rendering the wireless network unusable. As the test
application drops these frames, the WAP is no longer susceptible to such an attack. Though
dropping all deauthentication frames is not suitable for production deployments as they need
to honour valid requests, it does demonstrate a capability not possible with OpenFlow. More
complex algorithms that suit production deployment will be developed in Chapter 6. However,
this chapter has proved that P4 can provide previously unavailable wireless information.
The focus of this section is predominately P4, and it only briefly discusses other areas of SDN
research, such as the interactions and additional functions that a centralised controller can
provide. This section’s scope has been entirely at the data plane level of P4, and unlike
OpenFlow, it does not require a separate controller to function. Therefore, essential
functionality that would typically be offloaded to an OpenFlow controller can be provided
directly by a P4 program. Though the P4 programming language is suitable for general
conditional processing, allowing a controller to provide the pattern matching and traffic
decision process may be advantageous. This approach also allows the packets to be processed
asynchronously, reducing latency in the data plane. Additionally, P4 does not mandate a fixed
table format to which a controller must adhere. The table construction is left entirely to the
developer, allowing maximum flexibility.
3.4 Chapter Summary

This chapter demonstrates a novel architecture that allows the P4 data plane language to access
wireless network data at a fundamental level. Such an architecture gives network designers an
unprecedented way to access all wireless frames and, in doing so, implement features that
would be impossible using OpenFlow. Developing the WP4 compiler extension demonstrates
68
that this novel design is feasible and effective while exhibiting minimal implementation
overhead. Furthermore, it illustrates how this approach can process data from various OSI
layers in an IEEE 802.11 frame within a P4 application.
The SDN concept has its pedigree in wired network security, which is evident in the literature
and real-world deployments. While one of SDN's most recognised protocols, OpenFlow, does
enable rudimentary control for wireless networks by governing traffic at a network interface
level, its effectiveness is limited. Consequently, the OpenFlow standard has no provisions for
the IEEE 802.11 frame format or fields as it was designed for the IEEE 803.2 Ethernet standard.
However, the introduction of the P4 programming language has offered a ray of hope as it
allows user-defined data formats and therefore provides the possibility of creating a pipeline
compatible with the IEEE 802.11 MAC layer frame. Notwithstanding its flexibility, it does
lack a direct mechanism for integration into the wireless networking stack. This lack of wireless
integration capability is again due to the SDN heritage as a wired network model and P4 being
a data plane programming language for physical Ethernet switches.
OpenFlow and P4 have overlapping functionality, and while it is possible to use them together
to provide a single architecture, they are predominately utilised independently of each other.
While OpenFlow provides a fixed data plane with a programmable control plane and P4, a
programmable data plane with an integrated control plane, the outcome is the same. That
outcome is customisable packet forwarding; however, there was no understanding of how these
two approaches compared. This chapter has demonstrated a minimal difference in performance
between OpenFlow and P4 data planes executing the same functionality by performing an
equivalent comparison on a common hardware platform. However, the memory usage and
compiled code size of a P4 application can be considerably smaller due to the OpenFlow data
plane’s generic nature needing to support possibly redundant features.
The SDN model previously had limited applicability to wireless networking due to its packet
processors’ fixed nature. The OpenFlow protocol enforced a strict set of packet header fields,
all of which were from the IEEE 803.2 Ethernet standard. Thus, any usage within wireless
networking is at the trunk level and not at the IEEE 802.11 frame level. Consequently, the SDN
paradigm could not contribute to solving the numerous issues or enhance the management of
wireless networks the way it has in data centres. It is that shortcoming that this chapter has
addressed in a novel way, a method that also facilitates several new areas of research into SDN
and wireless networking. The novelty of these new methods has been further validated by
69
publishing two recent peer-reviewed articles [192], [193] and other researchers' interest in the
open-source P4 compiler code [194].
The newfound ability to monitor and regulate wireless frames in P4 demonstrated herein can
become the framework for developing original control algorithms to defend against
impersonation attacks. While P4 offers an extensive library of functionality, it also provides
the ability to call external, custom functionality. Commonly used for functions such as Cyclic
Redundancy Checking (CRC) and compression, it also offers the ability to extend the WP4
module capabilities further. Such capabilities will become essential to answering RQ 3 and RQ
4 and achieving the ultimate objective of this research project. In summary, the key
contributions to the field of this chapter are a new understanding of OpenFlow compared to P4
and a novel method for accessing wireless data by a P4 program.
70
Chapter 4.
Incorporating PHY Layer Features
4.1 Introduction
The core principles behind many impersonation attacks are anonymity and the abuse of
legitimate functionality. Therefore, it seems logical that it is possible to neutralise attacks of
this type by removing these attributes. The ability to accurately identify a wireless device is a
topic of considerable research, as was demonstrated in the literature review. Unfortunately, the
literature review also revealed that many of the existing methods are not compatible with the
limited capabilities of a WAP. While platforms such as PARADIS did utilise an SDR, it also
required an external server for fingerprint storage and identity processing. As Jiang et al. [201]
concluded, many transmitter identification approaches utilise high-end equipment, offline
processing, and extensive training, all incompatible with a real time requirement. Therefore,
RF features requiring high sample rates are not of interest here, nor are those requiring
significant external processing power.
Capturing PHY layer features and processing them in real time using a programmable data
plane within a WAP equivalent device would significantly improve security. Given that the
fundamental principles behind many wireless attacks are impersonation, it seems logical that
it is possible to neutralise this type of attack by addressing the inability to differentiate the real
device from an impersonator. However, due to complexity and processing requirements,
previous research has focused on using auxiliary services, such as Intrusion Detection Systems
(IDS). Such approaches do not offer real time protection, nor are they suitable for domestic or
small business scenarios due to the cost and operation requirements of supporting several
systems simultaneously. Therefore, this work aims to investigate the possibility of an approach
that enables impersonation detection capabilities in real time that is integrated directly into a
WAP, thereby requiring no external equipment or processing.
This project’s chosen platform is a Xilinx Zynq SoC that combines an ARM processor and
FPGA on a single chip. Coupled with an Analog Devices SDR, the platform replicates the
overall functionality of a WAP. Such a model also reproduces WAP's hardware and software
performance limitations, forcing an outcome within those constraints. Additionally, the
platform employs a standard Linux operating system and wireless subsystem, the same as
71
numerous domestic and commercial WAPs. To provide the base IEEE 802.11 functionality is
the openwifi project [20], an open-source implementation of an FPGA based IEEE 802.11
baseband processor and associated drivers. As commercial IEEE 802.11 chips are closed
sourced and IP protected, using openwifi will enable the modifications and new components
shown in Figure 4.1 that are required to access the RF processing pipeline and develop the
essential functions needed to extract the necessary data.
Figure 4.1: Proposed system architecture with component interactions
The RF processing in a WAP, and similarly with openwifi, is specifically designed for the
IEEE 802.11 standard and therefore omits any functionality not required to satisfy this task.
Unlike the high-end laboratory receivers discussed previously, a WAP cannot sample raw RF
transmissions. In this project’s case, the RF front end within the SDR separates the carrier’s
baseband signal before the Analog to Digital Conversion (ADC) stage. Consequently,
evaluating any transient or carrier frequency level features, such as turn-on transitions or power
ramp-up, was impossible. Even if these transceivers were capable of sampling at carrier level
frequencies, the CPU would be unable to process the volume of data in real time, making such
a capability redundant. While this approach focuses on modulation features alone, processing
these measurements in real time is a significant task. As Li et al. [43] argue, processing such
low-level information requires substantial computational resources that typically impede such
a model’s practical use.
72
The novel method for transferring data to the P4 kernel module, developed in the previous
chapter, has been extended using an innovative approach to utilise the newly acquired RF
information. Therefore, the goal was to create a single, real time interface between the SDR
hardware and the P4 program.
• A novel method for extracting, consolidating, and interfacing the available RF data
for analysis in the P4 program, thereby answering RQ2.
• An original approach that allows a P4 program to use IEEE 802.11 RF information to
create more advanced, targeted algorithms for the first time.
• An outcome that facilitated the publication of another peer-reviewed article and an
open-source code release.
4.2 Development Platform Architecture

Selecting a test platform that replicated the performance and functionality equivalent to that of
a WAP was essential in ensuring an accurate evaluation of WAP capabilities. For this purpose,
the Analog Devices ADRV9361-Z7035 [202], shown in Figure 4.2, was chosen as it
encompasses all the required functionality and capacity requirements for supporting the
openwifi framework. As shown in Figure 4.3, the device consists of a Xilinx Zynq 7035-2L
SoC consisting of a Dual-core ARM Cortex-A9 processor operating at 800 MHz and a 275K
logic cell, Kintex-7 FPGA. Combined with 1 GB DDR3 RAM, 256 Mb of flash memory,
Gigabit Ethernet, USB2 and UART interfaces, the device is equivalent to a mid-range domestic
wireless router.
Figure 4.2: Analog Devices ADRV9361-Z7035 Hardware
73
The platform’s RF section is built around the Analog Device AD9361, a 2x2 transceiver IC
delivering a tunable frequency range of 70 MHz to 6 GHz. The AD9361 features 12-bit ADC
and DACs with Automatic Gain Control (AGC), DC offset correction and digital filtering.
While the device is capable of an I/Q sample rate of 61.44 Msp/s, it is configured to 40 Msp/s,
which is later decimated to 20 Msp/s in the rx_intf module on the FPGA.
Figure 4.3: Analog Devices ADRV9361-Z7035 hardware block diagram
The module runs a Xilinx version of the Linux operating system with custom drivers for the
AD9361 SDR. Again, using a Linux operating system allows the platform to employ the same
WAP functions and features found in domestic wireless routers, such as hostapd, which utilise
a similar embedded version of Linux. Additionally, such an approach simplified transferring
the WP4 compiler developed in the previous chapter from the Raspberry Pi to this platform.
Therefore, this platform will be used exclusively for the remainder of the thesis.
4.3 RF Features incompatible with an SDR or WAP

Before discussing the inclusion of specific RF features in this implementation, it would be
advantageous to consider those unsuitable features. The limitations of a WAP are the core
reason for excluding several features found in the literature, and therefore, this chapter must
present a novel approach. While an SDR exposes several functions inaccessible to a
commercial WAP, it has a specific use case that does not offer access to the entire RF
processing chain. One such limitation is the inability to directly sample the raw carrier wave,
thereby excluding the analysis of transient features.
74
Transient features such as carrier wave power ramp-up are featured extensively in the
fingerprinting literature. Indeed, it was one of the first extensively investigated methods which
delivered accurate and reproducible results. However, this method requires the ability to
sample the raw incoming signal at several Giga-samples per second. A sample rate of this
magnitude is far beyond the capabilities of the ADC within an SDR. Additionally, the ADC
placement in an SDR is after separating the baseband from the carrier. This design also
excludes the analysis of other fingerprinting methods, such as transmitter imperfections.
Another fingerprinting method requiring high raw carrier signal sample rates is examining RF
frontend imperfections. Similar to identifying transient features, the effect of variations in local
oscillator output has been shown in the literature to be an effective identification method.
Additionally, RF amplifier imperfections have also been shown to produce unique features that
can be classified and used for identification. While these attributes are also excluded, it is not
only just sampling and signal processing inadequacies that limit the inclusion within the
proposed method. Data sizes and processing overheads also create bottlenecks and interface
issues that warrant the exclusion of more common characteristics such as CSI.
CSI for the wireless device characteristics analysis is a practical, widespread approach for non-
identity based solutions, requiring rudimentary functionality [29], [117]. Moreover, CSI
capabilities have been included in the side channel functionality of openwifi since October
2020. However, in addition to its limited useability as an identifying feature, it also presents
several difficulties that make its use troublesome in a real time P4 implementation. Several
such issues were outlined by the authors of TickSEC, who developed a convoluted buffering
pipeline to align the CSI data with the actual wireless frame. While the authors reported having
overcome the timing issue, it will be the data volume that proposes a more significant problem
for a P4 interface. Firstly, the wireless P4 integration model presented in section 3.3 uses the
standard P4 model of consuming frame headers with a P4 parser. Such a model does not lend
itself to ingesting large blocks of unstructured data such as CSI. Secondly, the side channel
module within openwifi utilises an entirely different kernel module than the one that exposes
the wireless frames and, therefore, would require multiple P4 applications with a complex
shared memory process. Therefore, only RF features that afford outputs compatible with the
proven P4 interface model are evaluated to provide a more consistent approach. Consequently,
if CSI information is to be included, the data volume issue and limitations as an identifying
feature would need to be overcome.
75
4.4 RF Feature Extraction
When investigating the RF features to include, it was found that those internal calculations
requiring compensation due to client device or environmental factors are often the best
candidates. For example, Carrier Frequency Offset (CFO) has been shown to be a reliable
identifier [29] caused by differences or errors in local oscillator frequencies. Such features
show strong deferential values and therefore facilitate the ability to extrapolate individual
devices or behaviours.
While only modulation features are available, there is the entire demodulation pipeline to
consider, from sample decimation to modulation decoding. Figure 4.4 shows how AD9361
provides the OFDM module with a 32-bit serial I/Q data stream composed of 16-bit in-phase
(I) and 16-bit quadrature (Q) samples.
Figure 4.4: Symbolic representation of the OFDM demodulation process
OpenOFDM [203] provides some fundamental values in a raw format, such as RSSI and
timestamps, other features required the addition of novel extraction and computation methods.
Parts of this new functionality will be added as Verilog code in the FPGA and the rest in the
SDR kernel module. The capabilities of each component were used to determine where the
new code would reside. For example, functions requiring complex mathematics are more suited
to C code in the driver, while timing-specific functions may only be possible in the FPGA.
However, the occasional compromise will be required, such as the inability to calculate floating
point numbers within a kernel module resulting in scaled values. Each RF feature extracted in
this project, the computation and interface technique method, will be discussed in the following
sections.
In addition to the data payload, a standard IEEE 802.11 frame, shown in Figure 4.5, includes
two training fields, the Short Training Field (STF) and the Long Training Field (LTF). These
76
training fields use several synchronisations and frequency offset calculations to ensure the
frame’s reliable demodulation. The STF consists of 10 identical repetitions, each containing
16 complex values for frame synchronisation, Automatic Gain Control (AGC), and coarse CFO
estimation. Simultaneously, the LTF comprises two repetitions of 64 complex valued samples
used for Channel estimation and fine CFO correction.
Figure 4.5: The IEEE 802.11a Data Frame structure
The RF features used herein are modified versions of existing adjustment and error correction
algorithms currently used in OpenOFDM, which was originally based on the work of Essam et
al. [204]
4.4.1 Carrier Phase Offset
Carrier Phase Offset (CPO) is the first calculation in a series of procedures used to compute
the course CFO based on the STF. Oscillator variations cause diff due to manufacturing
tolerances, temperature changes and the Doppler effect due to device movement.
The received frame at frequency 𝑓𝑐 is down-converted to baseband and sampled at 𝑆𝑅 ,

producing 160 samples. The last five repetitions (80 samples) are used for frequency offset
estimation, denoted as 𝑆𝑚 where m = 0 - 79. The phase difference between 𝑆𝑚 and 𝑆𝑚+16
represents the CFO over a 16 sample sliding window [204]. Therefore the coarse CPO estimate
of α𝑆𝑇 is produced by:
63
∗
α𝑆𝑇 = ∠ ( ∑ 𝑆𝑚 𝑆𝑚+16 ) , (1)
𝑚=0
Normally a division by 16 is performed to calculate the offset of a single sample within the
FPGA by using a shift of four bits to the left before output to the SDR kernel module. However,
doing so produces a significant loss of accuracy due to rounding. Therefore, a novel approach
of removing the division function from the FPGA resulted in the output being the phase shift
across the entire STF. Additionally, performing division within the kernel module will not
77
produce any further accuracy as it is impossible to perform floating-point calculations in a
Linux kernel module. Therefore, as a 16-sample CFO is required in the WP4 control plane, so
it is possible to calculate the value by:
α𝑆𝑇
𝑆𝑅 . ( 16 )
(2)
𝜀= ,
2𝜋
Where 𝑆𝑅 equals a sample rate of 20 Msp/s, and the CPO of the entire STF is divided by 16 to
equal a single symbol CPO.
4.4.2 Channel Gain
Due to several environmental effects, each sub-carrier will exhibit different magnitudes, which
require normalisation before decoding. To compensate for these variations, the mean of the
two LTFs is calculated by:
1
𝐻𝑖 = (𝐿𝑇𝐹𝑖 + 𝐿𝑇𝐹𝑖′ . 𝐿𝑖 ), 𝑖 ∈ (−26,26) , (3)
2
Where 𝐿𝑖 is the polarity of the LTF sequence at sub-carrier 𝑖 as per the IEEE 802.11 standard.
Each sub-carrier 𝑋𝑖 is then normalised by:
𝑋𝑖
𝑌𝑖 = , 𝑖 ∈ (−26,26) , (4)
𝐻𝑖
The FPGA was modified in a novel way so the mean value 𝐻𝑖 is extracted and sent to the SDR
driver as Vector Magnitude.
4.4.3 Pilot Sub-carrier Offset
In addition to course CPO adjustment, there is also a further fine-grained correction [204] using
the pilot sub-carriers ∈ (−21, −7,7,21), which is estimated by:
𝜃𝑛 = ∠ ( ∑ 𝑋𝑖𝑛 . 𝑃𝑖𝑛 . 𝐻𝑖 ) (5)
𝑖∈(−21,−7,7,21)
Where 𝑃𝑛 is the polarity of the pilot sub-carrier at symbol n.
78
The FPGA was again modified in a novel way so 𝜃𝑛 of the last symbol is extracted and sent to
the SDR driver as the Pilot Offset.
4.5 P4 Interface
The openwifi implementation uses the Xilinx Advanced Extensible Interface (AXI) to transfer
data between the FPGA and the Linux kernel module. There are two AXI interconnects
currently in use, one for frame data and the other for side-channel information such as CSI. As
described earlier, attempting to use data from both interfaces simultaneously would create
undue complexity; therefore, the additional RF information will be added to the existing frame
interface. In specific features, raw data was transferred to the kernel module via the AXI
interconnect and subsequently processed further before being managed by the P4 application.
Two options were considered to make these new values available to the wireless P4 interface,
function parameters or frame headers. As the RF feature values are not part of the IEEE 802.11
frame, it could be considered acceptable to maintain the frame’s separation from any additional
data. However, doing so would circumvent the inherent value of P4, that of the customisable
header paradigm. Therefore, new RF values are added to the beginning of the IEEE 802.11
frame before being passed to the P4 interface.
The novel system architecture shown in Figure 4.6 highlights the overall flexibility of such an
approach which provides multiple customisation opportunities.
Figure 4.6: Integration of the P4 Data Plane module
79
While the WP4 module can be modified using the P4 programming language, the control plane
interface facilitates advanced algorithms such as machine learning. For example, the rule or
“flow” table function standard in the SDN model lends itself quite elegantly to a Learning
Classifier System (LCS). Such a methodology is also well suited to a device fingerprinting
solution, which parenthetically is the archetype’s genesis. This approach allows the P4
application to consume the new RF information using the native header definition method, as
shown in Figure 4.7, without recombining data separately in the P4 program.
Figure 4.7: Wireless P4 header block definition with RF Features
In certain RF features, raw values were transferred to the kernel module via these headers and
subsequently processed further in the kernel module before being passed to the P4 application.
80
4.6 Feature Evaluation
IEEE 802.11 data frames from several device categories were captured to evaluate the
architecture processing capabilities and RF feature suitability. These frames were then analysed
and reported by the P4 application to demonstrate useability as possible fingerprinting vectors.
The first of the evaluated RF features was the CPO calculated using the frame’s STF (see
section 4.4.1). The CPO is the primary input and the sample rate used to calculate CFO. As
discussed, the sum of phase offsets across all 16 STF symbols is used instead of truncating the
value by calculating the mean within the FPGA, as is the usual practice, hence the more
extensive range. As the graph in Figure 4.8 demonstrates, there are measurable variations
between devices and noticeable banding within a range.
Figure 4.8: Comparison of the Carrier Phase Offset from various devices
The next RF feature to be evaluated by the P4 program was the vector magnitude variation of
the constellation points. The feature is calculated within the FPGA using an average of the two
LTS (see section 4.4.2) and is predominately used to normalise sub-carrier gain. Figure 4.9
81
highlights that the vector magnitude also displays noticeable variation between devices.
However, this association does not appear to be as tightly contained as the CPO.
While the Pilot Offset’s visible banding in Figure 4.10 is not as pronounced as the Phase Offset,
it still provides a differentiation level suitable for a secondary reference point. Indeed, while
each RF feature displays characteristics that an identification algorithm can utilise, combining
these features shows even more promise.
Figure 4.9: Comparison of the Vector Magnitude from Figure 4.10: Comparison of the Pilot Sub-Carrier Offset
various devices from various devices
Figure 4.11 and Figure 4.12 show a combination of Pilot Offset and Vector Magnitude, which
shows strong visual clustering. This highlights the possible application of algorithms such as
K-means or density clustering. Furthermore, the number of outliers in the combined output is
relatively low, thereby improving cluster density.
Figure 4.11: Comparison of the Vector Magnitude to Pilot Figure 4.12: Comparison of the Vector Magnitude to Phase
Offset from various devices Offset from various devices
82
To validate the feature useability, a Leave-One-Out (LOO) cross-validation of each feature
using the wrapper method [205] with a single forward and backward step was used to evaluate
the features’ utility. Using the wrapper method, a forward step is when only this feature is used,
and a backwards step is when only this feature is excluded. A dataset consisting of 3000
positive-only data frames captured from known devices was used to test each feature’s Type II
error rate using the MOCC algorithm described in Chapter 5. Table 4.1 shows the outcome of
these tests compared to the error score of 0.83% when all features are used. The cut-off point
for a False Negative (FN) was triggered when the evaluated probability of the correct device
label was less than 50%. While Madani and Vlaajic [108] demonstrated RSSI-based
identification can be an accurate classification method, it is important to ensure the classifier
was not overly dependent on this feature, as all the devices under test were the same distance
from the receiver. While the results in Table 4.1 support this view for the FN rate, RSSI
performed poorly with a larger, more complex dataset, as discussed in Chapter 5.
Table 4.1: Type II error scores of each RF feature using only positive instances
RF Feature Forward Backward

RSSI 0.01% 3.97%
Phase Offset 0.54% 0.03%
Pilot Offset 1.13% 0.37%
Magnitude 0.60% 0.40%
4.7 Chapter Summary

As demonstrated work by authors such as Rehman et al. [206], high-end receivers consistently
outperform low-end devices, such as SDRs, in the task of RF fingerprinting. While receiver
sensitivity and experimental design play a direct role in the poor outcomes, more fundamental
capabilities such as sample rate also contribute to the overall deficiency. However, this does
not rule out SDRs as a suitable approach if proper thought is given to the limitations.
SDR, which allows software-driven waveform capture at a fraction of the cost of a Vector
Signal Analyser (VSA), has started to gain popularity. While SDRs provided a low-cost method
for capturing RF signals, a separate computer was still required to process and analyse the
information. Therefore, real time processing was impossible due to the latency produced by
transferring the data and the inefficiencies of demodulation in software. However, the
83
introduction of the FPGA to the pipeline has provided a new capability, that of real time
integrated baseband processing.
The novel solution in this chapter provides a newfound ability for SDN applications to interact
with RF modulation in an IEEE 802.11 frame in the same way it would for higher OSI layer
attributes. In answering RQ 2, this chapter has demonstrated that even though a WAP type
platform lacks the receiver capabilities and sample rate required for transient RF features,
several useful PHY layer modulation features are readily available without the high cost of a
VSA. These new features contribute to a device's overall capability as a low-cost IEEE 802.11
research platform and development framework to aid wireless security research. Additionally,
incorporating an innovative method of integrating the FPGA processing with a P4 application
interface has enabled all OSI layers of an IEEE 802.11 frame to be utilised by an SDN
application. In doing so, it provides wireless SDN integration capabilities not previously
available with platforms such as TickSec [43].
The output of this chapter has also produced a peer-review journal paper [207]. Similarly, as
in previous chapters, the outputs have been provided to other researchers as open-source code
so that they may develop new and innovative SDN models. Therefore, this chapter’s main
contributions come from combining a low-cost experimental RF platform, a novel SDN
processing method, and unique architecture that has resulted in a framework that will enable
advanced IEEE 802.11 security research at a significantly lower cost.
84
Chapter 5.
Wireless Device Identification
5.1 Introduction
An old business maxim states, "what can be measured can be managed." While such a
statement seems logical, its application is anything but simple. In the same way, merely reading
values from a wireless device can not accurately identify it. Many MAC layer fields in an IEEE
802.11 frame are easily forged, making them unsuitable for accurate identification. Building
upon the previous chapter's work, it is now possible to employ these newly discovered RF
features and develop a novel method for identifying device impersonation.
This chapter examines the relationship between various device identification features. It
develops a novel approach to accurately identify devices in real time while operating within
the limited processing capabilities of a WAP. Considering each data type's suitability for the
different learning tasks is essential when evaluating the available data. A wireless client and
WAP's typical interaction consist of authenticated and unauthenticated frames, creating
different trust levels based on the session state. Authenticated data frames are highly trusted,
making them well suited as a training data set for a supervised machine learning approach.
This chapter demonstrates a new method for detecting device impersonation that delivers real
time functionality on WAP equivalent hardware and software. To ensure that the system is
suitable for real-world scenarios, the method was evaluated for static and moving known
devices, with the unknown devices representing adversaries at random distances. The use of
such a varied testing approach is rarely found in the literature, as many of the techniques
previously presented lack the robustness to be effective in changing environments.
The SDN paradigm employs a data plane model that utilises "flows", a multifaceted match-
action rule set based on frame header field values. For example, a flow may contain fields
corresponding to a MAC address, a TCP packet type, and an ingress port number mapped to a
DROP action, thereby instructing the data plane to disregard the frame if it meets these criteria.
Such an approach is very similar to a Rule-Based Machine Learning (RBML) model, which
uses a comparable rule set style based on an {IF: THEN} archetype. The Control Plane
maintains the flow table by adding, removing, and modifying the rule set as required. Entries
85
in the flow table can change due to requirements such as pre-configured design features,
network topology changes, or even responses to security threats.
• A novel Multiplexed One-Class Classifier (MOCC) that outputs the probability of a frame
originating from a known source.
• An off-host simulation tool that utilises captured frames to experiment with and optimise
the above algorithm.
• A real time, lightweight processing method that utilises Software Defined Networking
(SDN) and the P4 language to detect forged management frames that is suitable for use
on a WAP.
5.1.1 Algorithm Comparison
Machine learning (ML) requires processing power and memory, a commodity that is in short
supply within a WAP. This is one of the reasons that Soltanieh et al. [19] described it as “the
most challenging work in the practical deployment of RF fingerprinting is to use low-end
devices instead of high-end devices”. Soltanieh et al. also discuss some of the more common
approaches, such as K Nearest Neighbours (KNN), as “very simple and computationally
efficient in the training phase, but the classification phase could be computationally intensive”.
ML is also complex, often necessitating additional libraries and support functions.
The RBML system was selected due to its similarity to flow tables and that it is a novel
approach not previously considered. However, as several other approaches have previously
been evaluated for device identification, as described in section 2.3.3, a baseline comparison
was performed. Table 5.1 details the outcome of several tests that were executed using Scikit-
learn [168] of the previously evaluated algorithms found in device identification literature.
Table 5.1: Common classification algorithm accuracy comparison
Algorithm Known Devices Unknown Devices

Random Forest (RF) 99.70% 83.40%
K Nearest Neighbour (KNN) 99.25% 87.68%
Multi-layer Perceptron Neural Network (MLP-NN) 98.85% 84.35%
Support Vector Machine (SVM) 98.20% 93.53%
Gaussian Naive Bayesian (GNB) 95.50% 83.90%
86
These tests were performed utilising the same RF dataset as in section 5.4.1 with all 20,000
samples and a 90/10 training/test split.
The result demonstrated that all algorithms, apart from GNB, were able to identify a known
device over 98% of the time. However, other than SVM, these algorithms identified an
unknown device less than 88% of the time. Therefore, all tested poorly at recognising device
impersonation using the RF features provided. The results aligned with Elmrabit et al. [167],
who also found that a Random Forest algorithm provides the best accuracy in general multi-
class anomaly detection.
5.1.2 P4 Device Identification Architecture
An extension to the architecture in the previous chapter provides full control plane
functionality, as shown in Figure 5.1. Several new capabilities have been implemented in
addition to the LCS functions described below. These enhancements include debugging
operations, table visualisation tools and an off-host simulation application.
ADC Data RF Signal

FPGA SDR RF Frontend
RF + Raw IEEE
802.11 Frames via
AXI Interface
RF + Frame
Packet In
Frames
SDR Kernel Module WP4 Data Plane WP4 Control Plane
Response
Approved IEEE
802.11 Frames Rule Lookup
Rule Updates
Linux Network Stack Rule Table
Figure 5.1: The MOCC device identification architecture
5.1.3 Rule-Based Machine Learning
Rule-based machine learning (RBML) is a method that can identify and learn by refining an
identity model based on a set of evolving rules. A Learning Classifier System (LCS) is a subset
of this approach that include various components, shown in Figure 5.2, to discover and refine
a ruleset based on features from a training data environment. These components include:
1. Environment: The dataset used for training the model.
87
2. Processing: Algorithm that processed the dataset.
3. Match Set: The items that match the existing ruleset.
4. Correct / Incorrect Match Set: Items from the match set that are either correct or
incorrectly matched.
5. Covering: Algorithm used to initialise the ruleset with rules based on data set values.
6. Metadata updates: Updates to rule scores, such as accuracy and match count.
7. Subsumption: Consolidation of overlapping or redundant rules.
8. Rule Discovery: New rules creation based on methods such as Genetic Algorithms (GA).
9. Deletion: Removal of incorrect or poorly performing rules.
DELETION DATA SET
GENETIC
COVERING RULE SET ALGORITHM
METADATA
CORRECT
PREDICTION MATCH SET
INCORRECT
Figure 5.2: Component level representation of the Multiplex One-Class Classifier system
5.1.4 One-Class Classification
Multi-class classification is a common methodology for identification, one of the many

methods used for wireless device identification. However, the problem of detecting device
impersonation differs from identification by the class label. Impersonation is a One-Class
Classification (OCC) [208] problem characterised by the absence of negative classes. Negative
classes in this search space are previously unseen attacker devices and therefore constitute an
88
unlabelled class as they are not included in the training data. Attacker devices are not within
the training data because the training data is created from authenticated frames that only contain
known and validated class labels. This creates an unbalanced classification problem where the
rare class, impersonating devices, becomes the class of interest [209]. As discussed earlier and
highlighted by Ahmad et al. [134], this type of detection problem has a significant impact on
detection performance. While this may be considered an outlier or anomaly detection scenario,
that is also not the case. Multiple valid devices simultaneously must be considered, and not
simply a single normal or abnormal state. Therefore, each valid user device becomes a separate
OCC with its own classifier model, contained within a superset of all known devices. Given
this, the algorithm’s output is no longer a binary result but a probability of the device's RF
fingerprint matching the class label, in our case, the MAC address, that is encompassed within
the IEEE 802.11 frame.
5.1.5 Multiplexed One-Class Classification
The Multiplexed One-Class Classifier (MOCC) is an innovative algorithm based on the

Michigan-style Learning Classifier System (LCS), a form of machine learning that leverages
supervised learning to generate a collection of rules. This resulting rule set forms a
classification model. In traditional LCSs, these systems are multi-class, meaning they output
classifications that distinguish between learned classes. In contrast, the MOCC algorithm is
designed to produce a unique One-Class Classifier (OCC) for each device under consideration.
This distinction means that instead of having a single rule table used to create various
classification outputs, the MOCC-based table houses multiple classification models
concurrently. The main motivation behind this development is to cater to the distinct contexts
of training and testing samples.
For the MOCC, training samples are derived from IEEE 802.11 data frames of authenticated
devices. These are devices that are known to the system and therefore are viewed as trusted
entities. Meanwhile, the samples utilized for prediction are unauthenticated IEEE 802.11
management frames. Given their unknown status, they are labelled as untrusted or
unrecognized.
The MOCC algorithm was consciously created to be lightweight and low complexity, hence
reducing its demand on computational resources. One of its standout features is its
independence from any third-party libraries. This makes the algorithm versatile and decreases
its dependency on external resources. The MOCC is written entirely in the C programming
89
language, which gives it the advantage of speed and efficiency. It was developed and compiled
utilizing existing Linux system tools, therefore leveraging the robustness and versatility of the
Linux operating system.
The core component of the algorithm is a single executable, which adds to its efficiency and
ease of use. This executable can be compiled directly on the Wireless Access Point (WAP),
which simplifies the deployment process and improves performance by reducing the data
transmission load. This results in an agile, resource-friendly algorithm that is perfectly suited
for network analysis and prediction in environments with a multitude of devices.
5.2 Training the Algorithm

During the initial development, training was done offline, with the training data read from a
CSV file consisting of samples captured by the WP4 control plane. As the file only contained
samples from IEEE 802.11 data frames from validated devices, unlabelled samples were added
to the training data to represent unknown or adversarial devices.
Without the addition of these instances, the training data would be extremely unbalanced and
unable to evaluate the Type I error rate due to the lack of false positive or true negative results.
In the later real-world testing scenarios, data frames were taken directly from the WP4 frame
buffer for online training, using memory mapping to transfer the frames between the kernel
module and the user-space control plane.
Algorithm 1: MOCC training process pseudo code
Load new data instance;

/* Covering */
If (number of rules < min_rule)
Add minmax_offest percentage to each feature of the data instance to create max value;
Subtract minmax_offest percentage from each feature of the data instance to create min value;
Randomize scope flag to create wildcard fields;
Add a new rule to the rule population;
End
/* Rule Evaluation */
If (instance MAC address == rule MAC address)
If instance values are > min or < max or wild
True positive + 1;
Else
False Negative +1;
End
/* Update classifier metadata */
Update rule’s sensitivity, specificity, accuracy, f-score and MCC;
90
End
/* Genetic Algorithm */
If (matches > 10 and rule for this class < max_class_rules)
Select two random parent rules with accuracy > min_correct_acc AND experience > min_del_exp;
/* Perform Crossover */
Combine RSSI and Phase Offset from parent one and Pilot Offset and Magnitude from parent two to
create child one;
Combine RSSI and Phase Offset from parent two and Pilot Offset and Magnitude from parent one to
create child two;
/* Perform Mutation */
Randomize scope values of children features to create random wildcard features;
Initialize children metadata;
Add children to rule population;
End
/* Rule Compaction */
If (rule accuracy < min_correct_acc AND experience > min_del_exp)
delete rule;
End
It is essential to monitor the changes to the environment over time, which is the main reason
online training has been included in this method. This continuous, evolving process produces
a model that adapts to changes in real time. New rules are automatically added as devices move
or signals are affected by environmental factors. Older rules are deleted when they fall below
thresholds and are replaced by new ones to ensure high accuracy. As Algorithm 1 shows,
several steps are performed for each new data instance; each is described in further detail
below.
5.2.1 Classifier Rulesets
Classifier rulesets are stored within the P4 table, defined in the P4 application code table
section. Keys are defined per the WP4 model as either exact, min or max, allowing for discrete
(integers) and continuous (absolute number ranges) values, a novel variation to the Attribute
List Knowledge Representation (ALKR) [210]. Due to the limited P4 match types, new types
were added in the WP4 compiler extension to allow for more complex scenarios. Consequently,
the extension provides separate table lookup functions for conventional OSI layer 3/4 and LCS
control plane models.
The P4 table uses the Linux debugfs and memory mapping to create a single array shared
between the P4 compiled kernel module and the user-space control plane application. While
the control plane can read and write to the table, the P4 data plane can only read from the rule
table as per the standard SDN conventions. Additionally, restrictions common to established
91
SDN flow tables, such as mutually exclusive, where rules do not overlap, have been excluded.
Similarly, rule priority or hierarchy is not required in an LCS ruleset as all rules are equally
important.
OpenFlow and the custom P4 rule tables provide metadata for rules such as counters and
meters. In the same way, MOCC includes extensive data for rule evaluation, as shown in Table
5.2. Metadata is updated after each training sample to maintain real time measures of rule
performance, and therefore each rule/metadata set becomes an individual classifier.
Table 5.2: Individual value in the MOCC rule metadata
Value Description
mac80211.Addr2_class MAC address / Class ID
rfFeatures.magSq_max The maximum magnitude squared value to be considered a match.
rfFeatures.magSq_min The minimum magnitude squared value to be considered a match.
rfFeatures.pilotOffset_max The maximum pilot offset value to be considered a match.
rfFeatures.pilotOffset_min The minimum pilot offset value to be considered a match.
rfFeatures.phaseOffset_max The maximum phase offset value to be considered a match.
fFeatures.phaseOffset_min The minimum phase offset value to be considered a match.
rfFeatures.rssi_max The maximum RSSI squared value to be considered a match.
rfFeatures.rssi_min The minimum RSSI value to be considered a match.
rfFeatures.rate_idx_exact Unused for classification.
Time Time the rule was added to the rule population.
Last Match Time the rule was last in a match set.
Experience The number of times the rule has been evaluated.
Source Rule source: 0 = Covering, 1 = Genetic Algorithm.
True Positives (TP) The number of times a rule has correctly matched.
True Negatives (TN) The number of times a rule has correctly NOT matched.
False Positives (FP) The number of times a rule has incorrectly matched.
False Negatives (FN) The number of times a rule has incorrectly NOT matched.
Sensitivity TP
(6)
TP + FN
Specificity TN
(7)
TN + FP
Accuracy TP + TN
(8)
TP + TN + FP + FN
F-Score 𝑇𝑃
(9)
𝑇𝑃 + 0.5(𝐹𝑃 + 𝐹𝑁)
Matthews Correlation Coefficient (MCC) (𝑇𝑃 × 𝑇𝑁) − (𝐹𝑃 × 𝐹𝑁)
(10)
√(𝑇𝑃 + 𝐹𝑃) ∗ (𝑇𝑃 + 𝐹𝑁) ∗ (𝑇𝑁 + 𝐹𝑃) ∗ (𝑇𝑁 + 𝐹𝑁)
While LCR rulesets and P4 tables use the IF/THEN model, they differ in many ways. Due to
these dissimilarities, several architectural alterations were required to ensure compatibility,
92
beginning with separate lookup functions for P4 and LCS tables. Core differences between the
P4 and LCS models include that LCS rules are cumulative, so matching rules are added to a
match-set and totalled. Whereas P4 may match multiple rules, however, it is only the rule with
the highest priority that becomes the final match. Additionally, P4 typically only supports
exact, ternary and lpm match types for table lookups. So to support RF features, new match
types have been added to the WP4 compiler extension. These new types include maximum and
minimum to allow real value rangers and the class type that allows switching between the
generic P4 lookup model and the MOCC model.
The primary reason for this modification is that the P4 match/action paradigm is not the same
as an LCS IF/THEN, as P4 expects an action, not a class value.
5.2.2 Covering
Covering is designed to initialise the rule population and provide a base for learning. A
covering rule is added when the total number of rules is below the min_rule threshold or below
min_correct_match for the given class. Covering rule values are created using the following
method:
• Min values are the training instance value minus minmax_offset as a percentage of the
feature’s potential range.
• Max values are the training instance value plus minmax_offset as a percentage of the
feature’s potential range.
• A wild card or “do not care” values are randomly generated and stored in the scope field.
• Any rules where every field is marked are wild cards are not added to the rule population.
5.2.3 Genetic Algorithm
A Genetic Algorithm (GA) is a computational method inspired by the mechanics of natural

selection and genetics. The Genetic Algorithm plays a significant role in optimizing the rule
base by adopting an evolutionary approach to learning. Thereby contributing to the discovery,
refinement, diversity, and dynamic adaptability of the rules, enabling the system to learn and
improve its performance over time. The main purpose of a Genetic Algorithm includes:
• Contributing to the 'exploration' aspect of the learning process by generating new

rules, which may not be derived directly from the input data but instead result from
combining existing rules in novel ways.
93
• Through mutation and crossover operations, it maintains diversity within the rule
population, ensuring that the system doesn't get stuck in local optima and continues to
explore the solution space.
• The continual application of selection, crossover, mutation, and deletion operations,
GA allows the MOCC to adapt dynamically to changes in the problem space.
The GA implementation in the MOCC uses a tournament selection method to select two parents
from the rule population and applies cross-over and mutation. A group of rules from each class
is chosen randomly, and the two with the highest accuracy become parents. Offspring one is
created using the RSSI and Carrier Phase Offset from parent one, while Pilot Sub-Carrier Offset
and VMS are sourced from parent two; offspring two is the reverse. A mutation is then applied
by randomly toggling scope flags and flipping values to or from wild cards. Metadata is then
initialised, and the new offspring rules are added to the rule population.
Table 5.3: MOCC configuration parameters
Parameter Description Default

file_capture Capture frames to CSV file. Off
1
file_read Read frames to CSV file. On
table_size The maximum number of rules. 65535
1
tCount The number of frames to be used for training. 3000
1
val_method Method of Cross-Validation. LOO
min_rule Add a covering rule if the total number of rules is below this value. 0
min_correct_match Add a covering rule if the number of matching rules is below this value. 20
max_class_rules The maximum number of rules per class (device). 50
min_del_exp The Minimum experience count before a rule can be deleted. 200
min_match_exp The Minimum experience for a rule to be a valid match. 200
minmax_offset Percentage feature value offset. 10
min_del_acc Rules are deleted if accuracy is below this value when Exp > min_del_exp. 0.9
min_del_fs Rules are deleted if F-Score is below this value when Exp > min_del_exp. 0.1
1
min_correct_acc Minimum probability percentage to be considered the correct class. 50
1 Offline processing/simulation only.
5.2.4 Rule Deletion
Classifiers with an experience value, the number of times a rule has been evaluated, higher than
min_del_exp, and an accuracy value below min_del_acc, or an F-score below min_del_fs are
deleted. The MOCC does not support subsumption; therefore, rules can form a subset of other
rules, thereby reducing generalisation pressure. Additionally, rules are not actively deleted
94
when the rule population is above table_size; however, new rules are no longer added. The
experience-based deletion algorithm ensures that the population size is maintained.
5.2.5 Option and Parameters
The MOCC provides various tunable parameters, both on the WAP and the offline simulator,
as shown in Table 5.3. These have been implemented via configuration file and command line
parameters, allowing command-line scripted testing of value ranges.
5.3 Prediction Algorithm

The prediction algorithm shown in Algorithm 2 takes a testing instance i and evaluates it
exclusively against the rules of the same class x.
Algorithm 2: MOCC prediction process pseudo code
Load new data instance

If (instance MAC address == rule MAC address)
If (instance features == rule features AND experience > min_del_exp)
TP Count + 1;
Update TP scores;
Else
FN Count + 1;
Update FN scores;
End
End
Calculate overall instance accuracy score;
If (accuracy score > min_correct_acc)
TP Score + 1;
Else
FN Score + 1;
End
However, the algorithm does not output a binary result; instead, it returns the probability p
given the test instance (i) has the correct label, as shown in equation 11.
𝑓(𝑥) = p(𝑥|𝑖) (11)
Each rule that matches the testing instance has its F-scores added to the TP score, and each rule
that does not match, yet is the same class, has its F-score added to the FN score. After all rules
with a matching class are evaluated, the probability is calculated using equation 12.
95
∑𝑖 𝐹𝑇𝑃
p(𝑥|𝑖) = × 100
∑𝑖 𝐹𝑇𝑃 + ∑𝑖 𝐹𝐹𝑁 (12)
While online training and prediction only receive positive class instances, which cause TN and
FP to remain at zero, testing offline allows for the evaluation of unlabelled negative classes
and, therefore, a complete confusion matrix. Probability for offline testing prediction is
therefore evaluated using equation 13.
∑𝑖 𝐹𝑇𝑃 + ∑𝑖 𝐹𝑇𝑁
p(𝑥|𝑖) = × 100 (13)
∑𝑖 𝐹𝑇𝑃 + ∑𝑖 𝐹𝑇𝑁 + ∑𝑖 𝐹𝐹𝑃 + ∑𝑖 𝐹𝐹𝑁
5.3.1 Time Series Errors
Device frames must be interleaved because learning one class at a time causes previously learnt
rules to reduce in accuracy and subsequently be deleted. As values vary over time, they must
be kept in capture sequence to ensure accurate transitions. This method is of particular
importance when devices are moving. During testing individual device captures were done in
series, so the time stamps of each device are realigned to produce a parallel capture stream.
5.4 Evaluation
5.4.1 Simulation Results
Frames were captured from the ADRV9361-Z7035 in CSV format and transferred to a PC to
perform the initial testing of the MOCC. Training and test data consisted of 20,000 data frames
from 10 authenticated device, therefore becoming positive instances. Additionally, 500 probe
request frames captured from 500 random client devices were used as unlabelled negative
instances to complete the dataset. Authenticated devices were placed 1 meter from the
ADRV9361-Z7035, and unknown devices were at random distances, basically any device that
transmitted probe requests within range of the receiver. Only the frames from the authenticated
devices were used for training, with negative instances added to the test population to calculate
Type I and II errors. Testing was performed using LOO cross-validation across the entire
sample space. Only a single frame from each simulated adversarial device was used to
reproduce the real-world scenario where an attacker sends a forged frame, such as a
deauthentication request. While this may appear to be an unbalanced data set, which it is, it
more accurately represents the situation where an authorised device provides thousands of
96
frames for training throughout an average usage period; however, an impersonation attack may
only consist of a single frame from a previously unknown device that requires reliable
detection.
Using LOO CV, a single training/test cycle takes approximately 554 minutes to complete on
an Apple M1 processor running as a single thread on a performance core using the default
settings in Table 5.3. Each LOO evaluation cycle consists of 409,980,000 iterations comprising
20,000 positive (known) and 500 negative (unknown) frames applied against all 19,999
positive instances. The MOCC is based on an OCC model, and therefore, the performance was
evaluated using receiver operating characteristics (ROC) and the area under the curve (AUC).
As discussed in section 4.6, each of the features selected provides a unique perspective on the
identity of a wireless device. The features were chosen by examining the variance between six
known devices; however, it was not until a range of unknown devices were also compared that
this differentiation became unmistakable. In Figure 5.3, the visual closeness of the pilot offset
between the known devices and the high level of variability between the values of the unknown
devices is visually evident. This is attributable to various environmental factors common to
CPO, such as distance, reflections, and movement [211]. However, as Figure 5.4 shows, the
variance in the pilot symbols is considerably more significant than that of the CPO. Both Figure
5.3 and Figure 5.4 also illustrate the pilot and phase offset measurement stability by the distinct
value banding for each of the ten known devices. Additionally, Figure 5.5 and Figure 5.6
illustrate the Magnitude Squared and the RSSI of known and unknown devices, further
highlighting the differentiation.
97
Figure 5.3: Pilot Offset values of known (positive) and unknown (negative) devices.
Figure 5.4: Phase Offsets values of known (positive) and unknown (negative) devices.
98
Figure 5.5: Magnitude Squared values of known (positive) and unknown (negative) devices.
Figure 5.6: RSSI values of known (positive) and unknown (negative) devices.
99
The significant separation between the known and unknown devices for magnitude squared, as
shown in Figure 5.5, also suggests a bias towards this feature. This difference is assumed to be
due to the distance differential of the known (positive) and unknown (negative) instances.
Table 5.4: Confusion Matrix, p > 55%
n = 20,500 Predicted: Positive Predicted: Negative Sum
19,675 (98.38%) 325 (1.62%)

Actual: Positive 20,000
TP FN (Type II)
8 (1.60%) 492 (98.40%)
Actual: Negative 500
FP (Type I) TN
Sum 19,683 817 20,500
A confusion matrix, Table 5.4, was created using a probability cut-off value of 55%, which
was found to be the optimal balance of TP and FP error rates based on the ROC in Figure 5.8.
The MOCC had an identification rate (sensitivity) of 98.38% for known devices and a rate of
98.40% for detecting device impersonation (specificity). This results in an overall accuracy of
98.39% and an F-score of 0.9937.
Utilising the same method used to produce the results in Table 4.1, a second feature evaluation
was performed to ensure that the differences in devices’ distance from the receiver between the
positive and negative instances did not impact the result. The dataset now consisted of all
20,500 positive and negative instances using offline evaluation. Table 5.5 shows the outcome
of these tests compared to the overall Type I & II error rates in Table 5.4, of 1.60% and 1.62%,
respectively. The cut-off point was set at a probability > 55%.
Table 5.5: Type I & II error scores using both positive and negative instances
RF Feature Forward Backward

Type I Type II Type I Type II
RSSI 65.80% 0.18% 1.00% 3.13%

Phase Offset 56.00% 1.08% 15.00% 0.75%
Pilot Offset 50.60% 1.28% 5.60% 0.78%
Magnitude Sq. 26.00% 0.63% 12.80% 0.85%
100
Table 5.5 highlights that the Type II error rate improves marginally for each feature in isolation.
However, the Type I error rate is significantly higher, in most cases, worse than random when
measured individually. Additionally, removing each feature illustrates an expectedly
proportional increase in the Type I error rate. This result demonstrates that no individual
features dominate the outcome and that combining these features provides a more robust result.
It also provides insight into which features are the strongest, Phase Offset and Magnitude
Square performing better and RSSI and Pilot Offset performing more poorly. However, as
shown, the FP rate of the magnitude squared is 26.00% with the only feature, increasing the
overall FP rate by only 11.60% when left out. In contrast, the RSSI values in Figure 5.6 show
a minor variation yet have a 65.80% FP rate when used in isolation and improve the overall
accuracy by 0.60% when left out. Additionally, when RSSI and Magnitude Squared are
displayed together, as shown in Figure 5.7, a robust visual grouping may demonstrate the
usefulness of using these two values in tandem.
Figure 5.7: Comparison of RSSI and Magnitude Squared values of known (positive) and unknown (negative) devices.
Consider the ROC curve in Figure 5.8, which depicts the True Positive Rate (Sensitivity) and
False Positive Rate (1-Specificity) across the probability threshold range of 1-100%. The area
under the ROC is 0.94, which illustrates a solid verification performance.
101
AUC = 0.94
Figure 5.8: ROC of device probability threshold.
5.4.2 Real time WAP Results
The MOCC learning algorithm was installed on the test platform as a user-space control plane
application and called via the P4 CPU_action function to verify the performance in a real-
world scenario. The prediction algorithm is implemented as a separate control plane API
function dev_ident in the WP4 helper code via the table lookup function.
Algorithm 3: P4 application control block logic pseudo code
/* If it is a deauthentication or disassociation management frame call the Identification API, otherwise

send the data frame headers to the CPU for training. */
apply {
if (headers.frameCtrl.frameType == 0x0 &&
(headers.frameCtrl.subType == 0xA || headers.frameCtrl.subType == 0xC))
{
lookup_tbl.apply();
} else if (headers.frameCtrl.frameType == 0x2) {
CPU_action();
}
}
102
The P4 component is then responsible for directing the different frame types to the algorithms,
as shown in Algorithm 3. This approach sends only deauthentication and disassociation frames
to the prediction algorithm, while data frames are sent to the training algorithm.
The user-space control plane has a minimal memory footprint consuming only 1.968 MB of
RAM and less than 0.9% CPU capacity with five clients connected and logging disabled. The
control plane application binary is only 34,971 bytes and is therefore, suitable for embedded
systems with minimal flash memory. The evaluation device was configured with 1024 rules
due to limited stack memory; however, larger rule population sizes are possible if rule table
memory is allocated from heap memory. Additionally, a 65KB memory-mapped FIFO frame
buffer is used by the WP4 kernel module to enable the transfer of frame headers to user space
for the CPU_action function.
When client devices are connected to the WAP for the first time, the MOCC training algorithm
begins learning the device’s unique identity by building the rule population. As more rules are
added, the accuracy improves. The learning curve shown in Figure 5.9 demonstrates this
behaviour over the first 2000 frames. The MOCC algorithm typically reaches 90% accuracy in
less than 600 frames and 98% in under 1000 frames.
Figure 5.9: MOCC learning curve during the first 2000 IEEE 802.11 frames.
103
Measurements were taken on a moving device to further understand the MOCC's adaptability
to environmental changes. An iPhone 12 not previously known to the algorithm was connected
to the WAP at a distance of one meter. Once the device’s identity was above 98%, it was moved
at a uniform speed of approximately one meter per second away from the WAP until it reached
a twenty-meter distance. The measurements shown in Figure 5.10 provide insight into the
variance in accuracy during the journey.
Figure 5.10: Variation in accuracy during movement.
The average accuracy was 97.24%, with a standard deviation of 9.2. It was also found that the
parameter which defines the minimum experience for deletion (min_del_exp) plays an essential
role in the algorithm’s ability to adapt to changes. In this scenario, the parameter was set to 100
cycles. Therefore, a rule is deleted from the rule population if it has not reached an accuracy
value greater than 90% after evaluation against 100 frames. Additionally, it was found that a
limit of 200 rules per device allows the rule population sufficient coverage of the search space
while mitigating individual rule dominance.
104
5.5 Chapter Summary
This chapter has shown that a rule-based classifier using modulation-based RF features can
provide a reliable method for IEEE 802.11 device identification when implemented on a WAP.
While the ability to accurately identify a wireless device based on RF features is a topic of
considerable research, that focus has not been on identifying impersonation; instead, it has
focused on individual device identification. It also provides numerous tunable parameters
enabling use in diverse contexts such as intrusion detection, authentication, or access control.
This method achieves an average accuracy of 97.24% in real-world conditions, with the
capability of rapidly learning new devices and adjusting to changes over time. Additionally,
these results outperform all of the algorithms evaluated in section 5.1.1 by a considerable
margin.
Alternatively, openwifi provides a fully open-source implementation and basic RF measures

such as CSI and RSSI via a side-channel API. While such a model may be suitable for offline
analysis, what is missing is a single, unified data plane interface that exposes multiple OSI
layers simultaneously. Therefore, a new real time method of extracting and processing this data
is required.
Shi et al. recently developed Po-Fi [74], an architecture that uses OpenFlow metadata fields to
carry IEEE 802.11 MAC (L2) information to an SDN controller, such as frame type. While
such an approach is feasible, it is inefficient as the new data must be evaluated independently
of the packet processing pipeline. An area that has not been investigated until now is the
processing of IEEE 802.11 Layer 1 RF or OFDM modulation information and layer 2 data by
a single algorithm. The novel implementation of a custom P4 compiler that converts P4 code
into a Linux kernel module enables it to be used in line with the IEEE 802.11 frame path,
thereby allowing P4 to manage traffic based on identification intelligently.
Some devices, designed explicitly for impersonation, such as de-authenticators, vary signal
strength to simulate the appearance of the frames from different devices. This limitation to
RSSI-only identification was also highlighted by Madani and Vlajic [108]. However, as Figure
5.6 shows, this scenario has been considered by ensuring the testing instances have a sufficient
variety of RSSI values and that RSSI is not used as the predominant feature. Table 5.5
highlights that RSSI performance alone is inferior, even when devices are stationary. This
limitation was also highlighted by Xu et al. [123]. They stated that RSSI could not be used on
its own as fingerprints as they are susceptible to mobility and environmental changes. These
105
views are in direct contrast to the RSSI-based spoofing work of Madani and Vlajic [108], who
reported high levels of accuracy using RSSI alone. They state that the ability to overcome
variances in RSSI due to either movement or environment is due to the efficiency of their
algorithm.
There have been various machine learning algorithms applied to the task of wireless device
identification, including neural networks [132], K-Nearest Neighbour [107] and Bayesian
[104], [116], to name a few. However, little work has focused entirely on using a rule-based
Learning Classifier System (LCS). Given the results of this evaluation, using an LCS appears
comparable to that of the previous methods, all of which reported accuracy values above 98%.
However, most of the previous work, other than TickSEC, did not provide results using real-
world scenarios on a device like a WAP.
While using machine learning can be subject to adversarial inputs during training and
prediction [212], using RF features makes such perturbations significantly more complex. The
reason for this is twofold. Firstly, all training data is from authenticated clients, reducing the
risk of training data poisoning. Secondly, RF feature variations are due to hardware
dissimilarities and environmental factors, making them unpredictable and less susceptible to
inference attacks.
The advantage of implementing such a method directly onto a WAP is that it can be used for
prevention and detection. Many systems utilise a passive approach to impersonation discovery,
such as Intrusion Detection Systems (IDS) [121]. These systems often use off-the-shelf
network devices running in monitoring mode to passively listen to the traffic around them.
While these are capable of accurate detection, the novelty in the method herein is that it can
dynamically adapt, with the ability to both alert and prevent such behaviours.
Even though a typical WAP platform lacks the sample rate required for transient RF features,
several valuable PHY layer modulation features are readily available without the high cost of
a VSA like those previously demonstrated. These features significantly contribute to the
device’s overall capability as a low-cost, highly reliable IEEE 802.11 identification method.
Additionally, incorporating an innovative approach of integrating the FPGA processing with a
P4 application interface has enabled all OSI layers of an IEEE 802.11 frame to be utilised by
an SDN control plane. In doing so, it provides wireless SDN integration capabilities not
previously available with platforms such as TickSEC.
106
Previous research has aimed to differentiate between known devices, typically a multi-class
classification problem. However, differentiating between known and unknown devices
becomes a one-class classification problem. To address the difference, the main contribution
of this chapter is an original method of using the RF information from the previous chapter in
a novel Learning Classifier algorithm controlled by a P4 application. Together with the support
framework, which has demonstrated the suitability of such an approach, it is now possible for
future researchers to examine an entirely new way of identifying wireless devices. In common
with all other contributions in this thesis, these novel methods, algorithms, and source code
[213] are readily available, together with another journal paper which has been accepted for
publication.
107
Chapter 6.
Defending Against Impersonation Attacks
6.1 Introduction
Impersonation attacks are easy to launch and can significantly impact network security. Such
attacks are often the first step in more sophisticated strikes, such as man-in-the-middle (MITM)
or credential theft. The detection of impersonation attacks remains a challenging task due to its
use of often legitimate functions.
This chapter presents a novel method called Wireless Impersonation Detection and Defence
(WIDD), an overview of which is shown in Figure 6.1. It is capable of not only detecting but
passively and actively defending against a range of IEEE 802.11 attack types. Based on the
OODA loop and CKCs, WIDD uses a systematic approach to detect, evaluate, and respond to
threats that are transparent to the user.
Figure 6.1: Symbolic representation of the WIDD architecture
• Incorporating the Multiplexed One-Class Classifier from the previous chapter that utilises
RF modulation features to detect impersonation based on the signature of known client
devices.
108
• A novel method for detecting and defending a WAP from impersonation-based attacks
using the P4 programming language.
• A novel algorithm capable of defending against simultaneous attacks of different types on
a per-client basis.
• An innovative real-world evaluation method for validating this new defence method
utilising commonly used attack tools, including Aircrack-ng and Fluxion.
6.2 Attack Detection Algorithm

The WIDD architecture consists of three key components: a Kill Chain State Machine, P4
helper APIs, and active countermeasures. An OODA loop algorithm controls each component,
shown in Figure 6.2, created using the P4 programming language. It is this algorithm that
determines the appropriate Kill Chain logic to apply. The IEEE 802.11 frames are forwarded
from a customised version of the openwifi FPGA implementation, which has been modified to
capture the RF features used by the MOCC.
Current State
RX Frame
Y Data
CPU_action
Frame?
N
Y Control
Return OK Return OK
Frame?
N
N
N N N N
Auth. Assoc. Deauth. Disassoc. Beacon
Frame? Frame? Frame? Frame? Frame?
Y Y Y Y Y
Dev_ident
SSID_Check
N
Return DROP p > 55?
Y
Y N
Same
SSID?
Data Plane
Control Plane
State
Machine
Deauth. N Auth. N Evil N

Attack? Flood? Twin?
Y Y Y
Authentication Client N
ALERT ALERT
Inject Connected?
Deauth.
ALERT
Client
Figure 6.2: WIDD flow diagram implemented in P4
109
The frame and RF feature set are sent to the P4 packet parser stage, which determines the frame
type. Control frames are returned to the wireless driver, whereas data frames, which are
authenticated and thus not from an attacker, are directed to the MOCC for training using the
P4 CPU_action call. The MOCC uses these data frames to create a set of classifier rules to
build a device signature. Management frames which are the basis for most IEEE 802.11 attacks
are processed differently.
Management frames used for authentication and association can form part of a flood-type
attack designed to overwhelm the WAP and impact network performance. Therefore, when
either of these frames is received, the algorithm updates the flood attack KCSM. The WAP
drivers have also been modified to capture the beacon frames transmitted by other WAPs,
which are then sent to an SSID_check API to determine if any other WAPs are broadcasting
the same SSID. Rogue access points broadcast false SSID beacons to entice legitimate clients
to connect, capturing their login credentials or providing network connectivity that can be used
for eavesdropping. Again, the KCSM is updated to provide real time responses. Finally,
deauthentication frames, used in one of the most common DoS attacks, are checked against the
classifier model of known clients using the Dev_ident API. Those frames that return probability
below the determined threshold (initially p < 55%) are dropped. Those above are processed
normally with the KCSM updated to track multi-frame or multi-client attacks.
Based on the KCSM output, and a set of Kill Chain triggers, the P4 logic delivers appropriate
countermeasures. For deauthentication attacks, false authentication frames are transmitted as
attackers commonly force re-authentication using deauthentication frames to capture the login
handshake. Authentication and association flood attacks trigger an alert in addition to dropping
the illegitimate frames. Finally, where evil twin or rogue access points have been detected, a
warning is generated, and periodic deauthentication frames are transmitted using the legitimate
client and rogue WAP’s MAC addresses to reduce the likelihood of eavesdropping.
6.2.1 OODA Loops
Creating the best OODA loop requires each step to be as accurate and reliable as possible.
Gathering observations quickly, applying a ruleset, deciding on a response, and rendering the
correct action are paramount. While maintaining a fast and effective OODA loop is important,
either slowing or disrupting the attacker’s OODA loop is also a valuable strategy. As discussed
in the following sections, misinformation and countermeasures feeding an attacker false or
misleading information allow one to reduce the impact of such attacks. Additionally, it is
110
possible to have an attacker reveal their intentions without realising it, thereby providing a time
advantage.
The OODA loop implementation in Figure 6.3 is a series of steps divided between P4
conditional logic and WP4 [213] helper code API functions. Each stage is executed
sequentially upon receiving a frame from the openwifi SDR driver. The “Observe” stage
receives the frame via the P4 interface and, using the header fields, determines the frame type:
Data, Control or Management.
Frame RX O MOCC Training
Identify O Check APIs
Attack Type D State Machine
Filtering A Counter Measures
Figure 6.3: Mapping of the OODA Loop stages to WIDD functions.
Data frames are sent to the MOCC training algorithm via the CPU_action API. Control frames
are not utilised and therefore returned to the SDR driver for processing in the usual manner.
Management frames, the primary means of initiating attacks, are sent to the “Orientate” stage.
Table 6.1: State Machine inputs
Inputs 𝑸𝒂 𝑸𝒃 𝑸𝒄 𝑸𝒅
Data Frame 0 0 0 x
Authentication (11) 0 0 1 x
Deauthentication (12) 0 1 0 1
Deauthentication (12) 0 1 0 0
Evil Twin Beacon (8) 0 1 1 x
Association (0) 1 0 0 x
Disassociation (10) 1 0 1 1
Disassociation (10) 1 0 1 0
111
The Orientate stage determines the management frame type and decides which support API
function to enlist. The output of these support functions is then combined with frame-type logic
to produce an input to the “Decide” stage. The decide stage is a set of state machines that keep
inter-frame states, allowing the WAP to determine the correct type of action. The state machine
accepts the input shown in Table 6.1, which is produced as an outcome of the orientate stage
of the OODA loop logic. These state machine inputs are also shown in Figure 6.2 as outputs of
the data plane logic.
Table 6.2: State Machine outputs
Outputs 𝑲𝒂 𝑲𝒃 𝑲𝒄
No Attack 0 0 0
Deauthentication Attack 0 0 1
Disassociation Attack 0 1 0
Evil Twin 0 1 1
Credential Attack 1 0 0
Authentication Flood 1 0 1
Association Flood 1 1 0
The final stage of the OODA loop is the action stage, where two possible countermeasure
options can be executed. The action taken is determined by the output of the state machine, as
shown in Table 6.2. Countermeasures may include dropping frames, forwarding frames, or
injecting new frames to neutralise attacks. Once the action stage is complete, the cycle restarts
upon receiving a new frame.
6.2.2 Kill Chain State Machine
For each attack method, it must be understood what information an attacker needs before and
during an attack and investigate ways to provide false information. By utilising a Kill Chain
State Machine, it is possible to map out an attack scenario step by step. The KCSM is a series
of parallel state machines implemented based on predetermined attack techniques to maintain
the current phase of a Kill Chain. While Wilkens et al. [182] applied the model at a broad
network level, this approach refines and extends the concept in addition to operating at the
individual frame level, which allows for a real time response.
112
Deauthentication KCSM Disassociation KCSM
0101 / 100 1001 / 000

0101 / 100 1001 / 000
0100 / 100 1000 / 000
TIMEOUT TIMEOUT TIMEOUT TIMEOUT

000x / 000 0000 0001 0010 0011 000x / 000 1100 1101 1110 1111
0100 / 000 0100 / 100 1000 / 000 1000 / 000
Association Flood KCSM

xxxx / 001 xxxx / 010
Authentication Flood KCSM
Figure 6.4: Deauthentication KCSM state diagram Figure 6.5: Disassociation KCSM state diagram
xxxx / 101 xxxx / 110
TIMEOUT TIMEOUT TIMEOUT TIMEOUT
000x / 000 0100 0101 0110 0111 000x / 000 1000 1001 1010 1011
001x / 000 001x / 100 001x / 100 100x / 000 100x / 000 100x / 000
Figure 6.6: Authentication Flood KCSM state diagram Figure 6.7: Association Flood KCSM state diagram
The sequence and status of each attack kill chain are stored in a set of state machines, shown
in Figures 6.4 – 6.7, accessed via a P4 support API function. The state of each attack is stored
on a per-client basis allowing the processing of concurrent attack phases. This method enables
the WAP to track and counteract multiple attacks of different types or even attacks that may
simultaneously target some or all client devices. This algorithm synchronises each wireless
client’s state to detect coordinated attacks intelligently. Each state sequence is based upon a
kill chain model of the attack sequence and customised to allow for timing between states and
variations due to wireless anomalies such as dropped or corrupt frames. As each kill chain is
different, the state model will be explained in further detail in the evaluation section below.
6.2.3 P4 Support API Functions
Data frame headers which can only be from an authenticated device, use the CPU_action API
to ensure the MOCC algorithm’s successful training. The four RF characteristics RSSI, Phase
Offset, Pilot Offset and Magnitude Squared are included with the header to build a fingerprint
of each known device. These headers are sent to the control plane via a FIFO frame buffer for
use by the learning algorithm. It was previously found that 600-1000 frames are required to
produce a fingerprint with an identification accuracy greater than 98%. The time to reach this
frame count varies significantly based on the device’s type and usage profile. For example,
113
computers and smartphones streaming video could achieve this volume in minutes, whereas an
IoT device that only sends periodic updates could take days.
The Dev_ident function is the prediction component of the MOCC and is used to calculate a
device identity probability based on the classifier rules created by the learning algorithm.
Again, from the previous testing, it was found that p > 55% certainty is the optimal cutoff point
based on sensitivity and specificity and therefore used to determine the identity flag in the
decision stage of the OODA loop.
The SSID_check API is then used to determine the SSID contained within any received beacon
frames. While beacon frames from other WAPs are typically ignored, the FPGA and driver
were modified to allow these frames to be received and processed by the P4 code. As P4
contains no string evaluation functionality, this feature requires an external API-based
capability. The SSID is extracted from the beacon frame’s Information Element (IE) and then
compared to the SSID of the WAP. If the SSID values match, yet the BSSID is different,
another WAP is broadcasting the same wireless network name and more than likely part of the
Evil Twin or MITM attack.
The State_update API provides the OODA loop’s Observe and Orientate logic and returns an
action. The function also receives the client’s MAC address to enable separate states to be
maintained per device. A state update message is loaded into the frame buffer used by the
CPU_action API to transfer frame headers to the control plane, thereby sharing a single
integration point between data and control planes.
6.2.4 Countermeasures
Countermeasure actions are initiated based on the State Machine output shown in Table 6.2.
These actions protect WAP availability and credential security or prevent clients from falling
victim to MITM attacks. While nearly all the solutions described in the discussion section
employ various passive measures for minimising attacks, two novel active countermeasures
that defend against attacks and disable the attacker’s ability to perform such attacks have been
implemented. These countermeasures include disconnecting known clients that have been
tricked into connecting to a rogue WAP that is broadcasting false SSIDs. Also, sending false
authentication handshake messages after deauthentication attacks to disrupt possible credential
cracking kill chains.
114
6.3 Evaluation
Evaluating the proposed solution in a way that provides a representative use case requires using
WAP equivalent hardware and real-world attack methods. Therefore, to demonstrate the
effectiveness of the WIDD algorithm, a series of attacks were performed against the WAP test
hardware, running our modified version of openwifi [20]. The test hardware is the Analog
Devices ADRV9361-Z7035 [202] which includes all the required functionality and suitable
capacity requirements of the openwifi software. This device consists of a dual-core ARM
Cortex-A9 SoC running at 800MHz, making it the hardware equivalent of a mid-range
domestic wireless router. The instance of openwifi used had been previously extended to
include MOCC, which uses a specially developed rule-based classifier, a P4 application
interface, and a customized Orthogonal Frequency Division Multiplex (OFDM) library to
facilitate the use of various RF features for identification and behavioural analysis.
Five devices were on the client side of the testbed, including laptops, smartphones, and IoT
devices. Each device was connected to the WAP on 5Ghz, on channel 44, using 802.11a,
though the 2.4Ghz band functionality is equivalent. After authentication, a minimum of 5000
data frames were collected to create a usable ruleset for the classifier. Attacks were generated
from a single laptop using two different USB WIFI dongles with chipsets from Realtek and
Broadcom (TP-Link WDN3200), thereby providing a variety of RF signatures for comparison.
The attack device was running Kali Linux, and the Aircrack suite of tools was used to create
the DoS attacks. This approach is the easiest and most common method of attack and, therefore,
the same method used by real-world attackers. Fluxion was also used as an alternate method
of performing Evil Twin and MITM attacks.
6.3.1 Deauthentication / Disassociation DoS Attacks
Deauthentication attacks are relatively simple to perform using a tool such as Aireply-ng,
which produces various customisable management frames. The command “aireplay-ng -0 1 -
c FF:EE:DD:CC:BB:AA1 -a 66:55:44:33:22:111 wlan0” was used to transmit a group of 64
deauthentication frames, instructing the evaluation WAP to deauthenticate the client with the
specified MAC address. Five commonly used wireless clients and an Acer laptop with two
wireless dongles as a simulated attacker were used in this study, shown in Table 6.3. The
success rate of detecting false deauthentication frames shows a high accuracy rate apart from
the MacBook Air and Realtek combination. For this reason, detection is a two-part process;
identification is only the first part of the detection algorithm.
1
MAC addresses omitted for security reasons.
115
Table 6.3: Success rate of device identification process
Attacker TP-Link Generic

Client WDN3200 Realtek 8812BU
iPhone 12 (2021) 100% 84.4%
MacBook Pro (2013) 100% 100%
HP TPN-C126 Laptop (2017) 100% 98.4%
MacBook Air (2020) 100% 7.8%
Samsung Galaxy 10e (2019) 87.5% 95.3%
Average 97.5% 77.2%
The second part of the detection process is provided by the KCSM, as shown in Figure 6.4 and
Figure 6.5. The attack state is updated based on the number of valid or false deauthentication
frames. Under normal circumstances, a client will transmit a single deauthentication frame
when disconnecting from a WAP. Therefore, the receipt of more than one frame could be
considered to constitute an attack. However, to reduce the risk of false negatives, either two
false deauthentication frames or three total deauthentication frames received within two
seconds are required to complete the state transitions and trigger an attack state. The window
of two seconds was chosen based on the hostapd deauthentication timeout value [135]. This
approach also compensates for any poor device identification results, an example of which can
be seen in Table 6.3, with the Realtek and MacBook Air combination. While it is possible for
a client to be erroneously disconnected due to an incorrectly identified deauthentication frame,
the continued receipt of these frames will trigger an attack state allowing the client to reconnect
and stay connected, thereby mitigating a DoS outcome.
6.3.2 Credential Cracking
The next attack type, Credential Cracking, requires performing a password dictionary attack
[214]. However, the attacker must first capture the four-way authentication handshake to
compare the key to a rainbow table or password list. This handshake can be captured during
standard client authentication; however, this may take some time, so most attackers first force
a reauthentication using a deauthentication attack. Airodump-ng is commonly used to capture
the handshake before passing it to Aircrack-ng for cracking. The WIDD uses a novel approach
that transmits a false four-way handshake whenever an impersonated deauthentication request
is received. Doing so causes the attacker to capture an invalid handshake without knowing the
difference, concluding the attack on the belief that they have the necessary key information.
116
Additionally, the handshake frames are transmitted twice to improve reliability and allow for
the possibility of any of the handshake frames being lost.
To evaluate the effectiveness of this concept, an attack was performed on a client connected to
the evaluation WAP. Using Airodump-ng and Aireplay-ng in the same manner as an attacker,
a deauthentication attack was performed, and transmission of the four-way handshake was
monitored. The handshake was passed to Aircrack-ng and compared to a password list
containing only the correct WAP password to validate that the invalid handshake was indeed
the one the attacker received. Aircrack-ng failed to determine the password in all tests where
the countermeasure was enabled; however, when the countermeasure was disabled, the
password was always decrypted correctly.
6.3.3 Evil Twin / Rogue Access Point
The first part of the testing for an Evil Twin or Rogue Access Point attack [214] was the
detection of false beacons. As previously described, the frame filtering has been modified to
receive beacons from other WAPs, a capability usually only available when a wireless adaptor
is in monitor mode. The first test used Airbase-ng to simulate a rogue AP which broadcasts the
legitimate SSID with the BSSID, which is the MAC address of the attacker’s wireless network
interface. The evaluation platform detected the false SSID / BSSID combination during all
tests.
The second part of the test used the Fluxion tool, an automated MITM attack platform. Fluxion
uses a series of steps to scan for SSIDs, capture authentication handshakes, and launch a captive
portal complete with a web server and DNS redirect. Fluxion does not do a brute force crack
of the handshake key; instead, it tricks the user into thinking they are being prompted for their
credentials by using the captive portal. When the user enters their password, it is compared to
the captured handshake key, and if it matches, it is logged. The user is then disconnected and
redirected back to their legitimate WAP without realising they have just given away their
password.
When Fluxion was started, it scanned for SSIDs, returning a list that included the SSID of the
evaluation platform. Once the evaluation SSID was selected and Fluxion began broadcasting
the false beacon, it was detected, and an alert was raised by the WIDD. While this would
usually be the end of such an attack, the warning was ignored so the attack could continue
allowing later stages of the WIDD to be tested. The next step is to capture a four-way
handshake. Fluxion uses the same approach as the credential crack above, sending
117
deauthentication frames to disconnect the client and logging the handshake when the client
reconnects. Accordingly, the WIDD detected the false deauthentication frame and transmitted
the invalid handshake frames causing Fluxion to log incorrect credentials. Therefore, even
when false SSID detection was disabled and the client connected to Fluxion by entering the
correct password, it did not match, stopping Fluxion from validating the password.
Additionally, Fluxion was executed with the two different wireless adaptor types, both of which
produced the same outcome, a complete failure of the attack. Finally, to ensure an effective test
setup, Fluxion was run against the evaluation platform with the WIDD features disabled, where
it had no trouble comprising a user's credentials successfully.
6.3.4 Authentication / Association Flood Attacks
An authentication flood is another simple yet effective DoS attack that requires little knowledge
on behalf of the attacker. This time using the Aireply-ng tool with the authentication frame
command, “aireplay-ng -1 0 -e openwifi -h FF:EE:DD:CC:BB:AA1 -a 66:55:44:33:22:11
wlan0”, which transmits a continuous stream of false authentication frames. While a relatively
simple attack to detect once underway, genuine authentication requests can be challenging to
differentiate from malicious ones. Flood attacks were performed using all client and attacker
device combinations, shown in Table 6.3, and were successfully detected and mitigated.
6.4 Chapter Summary

Attackers can easily compromise IEEE 802.11 wireless networks using readily available tools
and minimal skills. While the literature provides diverse approaches to addressing these
attacks, many are complex and require processing beyond the capabilities of most WAPs and
home routers. This overhead considerably restricts the usability and, in turn, the breadth of
deployment options. Given that the attacks described herein could impact all IEEE 802.11
devices, large and small, the goal is to support the lowest possible requirements while still
being compliant with IEEE 802.11 standards. Doing so would increase the protection footprint
significantly.
This chapter presents a novel impersonation attack detection and defence methodology
incorporating a behavioural algorithm derived from the OODA loop and CKC strategies. This
model is combined with an RF device identification function and integrated into an access point
with domestic grade specifications. This approach creates an automated, zero-touch solution to
protect a wireless network against the most common impersonation attacks. The method
1
MAC addresses omitted for security reasons.
118
overcomes the previous techniques' high-end or external equipment requirements.
Additionally, the approach requires no client modification and remains within the IEEE 802.1
standard. This conformity to universally agreed standards allows the demonstrated solution to
protect even the most rudimentary clients, such as IoT devices, without changing their
compatibility. Finally, using the P4 programming language allows further enhancement
directly compatible with other P4 devices, supporting endless extensibility and reusability. The
results show the effectiveness of this technique in detecting and preventing such attacks in real
time. The novel methods, algorithm and outcomes of this chapter also resulted in a published
journal paper [215].
119
Chapter 7.
Conclusion and Future Work
7.1 Conclusion
This chapter concludes the thesis by summarising the research findings relative to the aims and
research questions while highlighting its value and contributions to the field. It will also
consider the limitations of the work and areas where the work could be extended or enhanced
in the future.
It was the aim of this study to determine if commercial WAPs, or even domestic wireless
routers, could be equipped with the capability to defend themselves and the networks they
provide against impersonation attacks without the need for external devices or support. It was
then hypothesised that by enabling a WAP to identify its clients accurately, it would be possible
to differentiate between valid and invalid frames. This study has determined that it is indeed
possible for a device equivalent to a domestic wireless router to identify known or unknown
clients accurately and use this information as the basis for defending against impersonation
attacks.
A research study of this nature requires the application of several technologies and disciplines,
including several programming languages, a deep understanding of IEEE 802.11 standards, RF
design principles, data modulation and complex number theory, advanced probability models,
cyber-defence methodologies, FPGA development, Linux administration and Software
Defined Networking. This multi-disciplinary approach has enabled the research to provide a
fundamentally different method of defending against wireless impersonation attacks.
Therefore, this thesis's original contribution to knowledge is a collection of novel methods,
tools and algorithms that not only produce a compelling, original SDN approach to protecting
IEEE 802.11 networks but also offer new research directions in networking and security.
7.1.1 Contribution 1
The first research question to be answered by this study was, “Can SDN be used as an IEEE
802.11 frame processing method to access the data in multiple OSI layers, and if so, which
SDN approach is the most suitable?”. After considering and comparing the two common SDN
approaches of OpenFlow and P4, the study confirmed that OpenFlow lacks the customisability
120
required to implement the IEEE 802.11 protocol. At the same time, P4's programmable parser
allows the IEEE 802.11 fields to be processed natively. Both approaches were found to have
equivalent throughput and packet loss performance when processing identical traffic on the
same hardware, a comparison not previously performed. A key output from this section was a
new P4 compiler extension that produces firmware for the Zodiac FX SDN switch hardware,
allowing researchers to run OpenFlow or P4 on the same physical hardware for the first time.
The publication of two conference papers [192], [193] also resulted from answering this
research question.
The second research question was, “Given the low sample rates on a WAP, which RF
characteristics can contribute to device identification, and how can the SDN paradigm process
them?”. Several RF metrics, such as RSSI, Carrier Phase Offset, Pilot Sub-Carrier Offset, and
Vector Magnitude Squared, were captured during the OFDM decoding process with enough
precision to provide accurate device identification. By novelly embedding RF values directly
into the IEEE 802.11 frames, these features can be captured by the P4 parser, thereby allowing
processing by the P4 pipeline. The development of another new P4 compiler extension allows
native P4 to be compiled into a Linux kernel module with direct integration into the Linux
MAC80211 wireless subsystem and process IEEE 802.11 frames directly. Answering this
research question also resulted in the publication of a journal paper [207].
The third research question was, “Device impersonation is a serious threat to wireless security,
and existing approaches work at one layer of the OSI model. What novel combination of
physical and behavioural device characteristics can identify a wireless device in real time with
no user-initiated training?”. The study demonstrates a novel method of combining OSI layers
1 and 2 in a rule-based classifier which was implemented using the P4 flow table model,
thereby providing a lightweight supervised learning model that requires no user interaction or
external infrastructure. This technique demonstrated a highly accurate device identification
outcome of 97.24% in real-world conditions, with minimal processing overhead. This approach
highlights the flexibility of the P4 flow table model, capable of processing values other than
the standard network protocol fields. Key outputs include an enhanced P4 compiler module
that supports identity lookup APIs, a novel device identification algorithm within a Linux
kernel module and a WAP-based control plane application to provide customisation and
121
management. The publication of a journal paper, accepted but not yet published, was also
produced by answering this research question.
The fourth research question asked was, “Several real-world defence tactics and strategies,
such as OODA loops and Kill Chains, are effective in cybersecurity. Can these tactics be the
basis for a novel algorithm suitable for use on a WAP, making it capable of defending itself
against DoS attacks?”. The study illustrated that a novel P4-driven OODA loop, Kill Chain
State Machine, and the device identification algorithm could protect against the four most
common types of impersonation attacks with a high degree of success. The system also
successfully reduced or neutralised the attacker's effectiveness using active countermeasures
such as false authentication handshakes to negate credential cracking. Finally, the addition of
a novel false beacon detection algorithm was shown to minimise evil twin and man-in-the-
middle attacks by alerting clients to the presence of rogue WAPs. Additionally, a journal paper
was published [215] with results from answering this research question.
7.2 Limitations
While the specific aim of this study was to implement the solution on a platform equivalent to
a WAP or domestic router, an accomplished goal, it is not a solution that can be retrofitted to
any generic off-the-shelf device. This is due to the requirement for the FPGA aspects of the
solution, namely the modifications to the OFDM decoding, which would require commercial
transceiver chip vendors to implement these modifications into their products or use an SDR-
based platform. However, all other software components, methods and algorithms are readily
implementable on any Linux-based IEEE 802.11 device.
7.3 Future Work

This thesis has generated numerous code and algorithmic outputs in addition to advancing
knowledge of IEEE 802.11 security. From the beginning, there was a decision that all assets
generated would be open source and freely available to those who would like to reuse or extend
this work in the future. Tasks that could expand and build upon this study include:
122
• The wireless P4 compiler extension could be enhanced to implement additional
functionality to build upon the P4 logic features and allow the OODA loop to address
other security threats.
• Continue to tune and improve the MOCC algorithm or evaluate different features.
There is also the opportunity to investigate the use of the MOCC in different contexts
or scenarios.
• Investigate the use of commercial wireless chipsets which may allow firmware
modifications to provide the RF feature values in an off-the-shelf WAP.
123
References
[1] IEEE Standard for Information Technology--Telecommunications and information exchange

between systems Local and metropolitan area networks--Specific requirements Part 11: Wireless
LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications," in IEEE Std
802.11-2012 (Revision of IEEE Std 802.11-2007), 29 March 2012, doi:
10.1109/IEEESTD.2012.6178212.
[2] K. Pahlavan and P. Krishnamurthy, “Evolution and Impact of Wi-Fi Technology and
Applications: A Historical Perspective,” Int J Wirel Inf Netw, vol. 28, no. 1, pp. 3–19, 2021, doi:
10.1007/s10776-020-00501-8.
[3] Espressif Systems, “ESP8266 SoC,” 2022.

https://www.espressif.com/en/products/socs/esp8266 (accessed Jul. 22, 2021).
[4] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, “Internet of Things (IoT): A vision,
architectural elements, and future directions,” Future Generation Computer Systems, vol. 29,
no. 7, pp. 1645–1660, 2013, doi: 10.1016/j.future.2013.01.010.
[5] C. Montag and S. Diefenbach, “Towards homo digitalis: Important research issues for
psychology and the neurosciences at the dawn of the Internet of Things and the digital society,”
Sustainability (Switzerland), vol. 10, no. 2, 2018, doi: 10.3390/su10020415.
[6] Bluetooth SIG, “Bluetooth 5.2,” Bluetooth SIG Working Group, 2019.
https://www.bluetooth.com/specifications/bluetooth-core-specification/ (accessed Jan. 04,
2020).
[7] E. Chatzoglou, G. Kambourakis, C. Smiliotopoulos, and C. Kolias, “Best of Both Worlds:

Detecting Application Layer Attacks through 802.11 and Non-802.11 Features,” Sensors
(Basel), vol. 22, no. 15, pp. 1–19, 2022, doi: 10.3390/s22155633.
[8] The Harris Poll, “Norton LifeLock Cyber Safety Insights Report,” 2018.
https://au.norton.com/cyber-security-insights-2018 (accessed May 08, 2019).
[9] R. S. Singh, A. Prasad, R. M. Moven, and H. K. Deva Sarma, “Denial of service attack in
wireless data network: A survey,” in Proceedings of 2nd International Conference on 2017
Devices for Integrated Circuit, DevIC 2017, 2017, pp. 354–359. doi:
10.1109/DEVIC.2017.8073968.
[10] Z. Akram, M. A. Saeed, and M. Daud, “Real time exploitation of security mechanisms of
residential WLAN access points,” International Conference on Computing, Mathematics and
124
Engineering Technologies, vol. Jan. IEEE, pp. 1–5, 2018. doi:
10.1109/ICOMET.2018.8346378.
[11] M. Vanhoef, P. Adhikari, and C. Pöpper, “Protecting wi-fi beacons from outsider forgeries,” in
WiSec 2020 - Proceedings of the 13th ACM Conference on Security and Privacy in Wireless and
Mobile Networks, 2020, pp. 155–160. doi: 10.1145/3395351.3399442.
[12] S. C. Sethuraman, S. Dhamodara, and V. Vijayakumar, “Intrusion detection system for detecting
wireless attacks in IEEE 802.11 networks,” IET Networks, vol. 8, no. 4, pp. 219–232, 2019, doi:
10.1049/iet-net.2018.5050.
[13] Offensive Security, “Kali Linux,” 2022. https://www.kali.org (accessed Oct. 22, 2022).
[14] R. A. Maalem Lahcen, B. Caulkins, R. Mohapatra, and M. Kumar, “Review and insight on the
behavioral aspects of cybersecurity,” Cybersecurity, vol. 3, no. 1, 2020, doi: 10.1186/s42400-
020-00050-w.
[15] T. Lin, “DSTIKE Deauthentication Devices,” 2022.

https://dstike.com/collections/all/deauther#MainContent (accessed May 12, 2022).
[16] A. Sivanathan, D. Sherratt, H. H. Gharakheili, V. Sivaraman, and A. Vishwanath, “Low-cost

flow-based security solutions for smart-home IoT devices,” 2016 IEEE International
Conference on Advanced Networks and Telecommunications Systems, ANTS 2016, 2017, doi:
10.1109/ANTS.2016.7947781.
[17] Department of Homeland Security, “A Guide to Securing Networks for Wi-Fi (IEEE 802.11
Family),” 2017. [Online]. Available: https://www.us-
cert.gov/sites/default/files/publications/A_Guide_to_Securing_Networks_for_Wi-Fi.pdf
[18] O. Yurekten and M. Demirci, “SDN-based cyber defense: A survey,” Future Generation
Computer Systems, vol. 115, pp. 126–149, 2021, doi: 10.1016/j.future.2020.09.006.
[19] N. Soltanieh, Y. Norouzi, Y. Yang, S. Member, N. C. Karmakar, and S. Member, “A Review of

Radio Frequency Fingerprinting Techniques,” IEEE Journal of Radio Frequency Identification,
vol. 4, no. 3, pp. 222–233, 2020.
[20] X. Jiao, W. Liu, M. Mehari, M. Aslam, and I. Moerman, “openwifi: A free and open-source
IEEE802. 11 SDR implementation on SoC,” in IEEE VTC2020, the 91st Vehicular Technology
Conference, 2020, pp. 1–2.
[21] T. d’Otreppe de Bouvette, “Aircrack-ng,” 2022. http://www.aircrack-ng.org (accessed Feb. 09,

2021).
125
[22] Deltaflux, “Fluxion,” 2018. https://github.com/FluxionNetwork/fluxion (accessed Aug. 23,
2022).
[23] R. U. Rahman and D. S. Tomar, “Security attacks on wireless networks and their detection
techniques,” Emerging Wireless Communication and Network Technologies: Principle,
Paradigm and Performance, pp. 241–270, 2018, doi: 10.1007/978-981-13-0396-8_13.
[24] Nick McKeown et al., “OpenFlow : Enabling Innovation in Campus Networks,” ACM
SIGCOMM Computer Communication Review, vol. 38, no. 2, pp. 69–74, 2008.
[25] K. Talbot, P. Duley, and M. Hyatt, “Specific emitter identification and verification,” Technology
Review Journal, vol. Spring/Sum, pp. 113–133, 2003.
[26] S. U. Rehman, K. W. Sowerby, S. Alam, and I. Ardekani, “Radio frequency fingerprinting and
its challenges,” 2014 IEEE Conference on Communications and Network Security. IEEE, pp.
496–497, 2014. doi: 10.1109/CNS.2014.6997522.
[27] J. Toonstra and W. Kinsner, “A Radio Transmitter Fingerprinting System ODO-1,” in

Proceedings of 1996 Canadian Conference on Electrical and Computer Engineering, Calgary,
Alberta: IEEE, 1996, pp. 1–4. doi: 10.1109/CCECE.1996.548038.
[28] O. Ureten and N. Serinken, “Wireless security through RF fingerprinting,” Canadian Journal of
Electrical and Computer Engineering, vol. 32, no. 1, pp. 27–33, 2007, doi:
10.1109/CJECE.2007.364330.
[29] V. Brik, S. Banerjee, M. Gruteser, and S. Oh, “Wireless device identification with radiometric
signatures,” in Proceedings of the Annual International Conference on Mobile Computing and
Networking, MOBICOM, 2008, pp. 116–127. doi: 10.1145/1409944.1409959.
[30] B. Danev and S. Capkun, “Transient-based identification of wireless sensor nodes,” in 2009
International Conference on Information Processing in Sensor Networks, IPSN 2009, IEEE,
2009, pp. 25–36.
[31] B. Danev, H. Luecken, S. Capkun, and K. el Defrawy, “Attacks on Physical-layer

Identification,” in Proceedings of the third ACM conference on Wireless network security, 2011,
pp. 89–98. doi: 10.1145/1741866.1741882.
[32] A. C. Polak, S. Dolatshahi, and D. Goeckel, “Identifying wireless users via transmitter
imperfections,” IEEE Journal on Selected Areas in Communications, vol. 29, no. 7, pp. 1469–
1479, 2011, doi: 10.1109/JSAC.2011.110812.
[33] M. N. O. Sadiku and C. M. Akujuobi, “Software-defined radio: A brief overview,” IEEE

Potentials, vol. 23, no. 4, pp. 14–15, 2004, doi: 10.1109/MP.2004.1343223.
126
[34] W. Wolf, “Building the software radio,” Computer (Long Beach Calif), vol. 38, no. 3, pp. 87–
89, 2005, doi: 10.1109/mc.2005.82.
[35] E. Blossom, “GNU Radio: tools for exploring the radio frequency spectrum.,” Linux Journal,
2004. https://www.linuxjournal.com/article/7319 (accessed Mar. 19, 2020).
[36] M. Ettus, “Ettus Research,” 2022. https://www.ettus.com (accessed Apr. 22, 2021).
[37] B. Bloessl, M. Segata, C. Sommer, and F. Dressler, “An IEEE 802.11a/g/p OFDM Receiver for
GNU Radio,” in Proceedings of the Second Workshop on Software Radio Implementation
Forum, 2013, pp. 9–16. doi: 10.1145/2491246.2491248.
[38] H. Patel, M. A. Temple, and B. W. Ramsey, “Comparison of high-end and low-end receivers
for RF-DNA fingerprinting,” Proceedings - IEEE Military Communications Conference
MILCOM, pp. 24–29, 2014, doi: 10.1109/MILCOM.2014.13.
[39] L. Peng, A. Hu, J. Zhang, Y. Jiang, J. Yu, and Y. Yan, “Design of a Hybrid RF Fingerprint
Extraction and Device Classification Scheme,” IEEE Internet Things J, vol. 6, no. 1, pp. 349–
360, 2019, doi: 10.1109/JIOT.2018.2838071.
[40] P. Murphy, A. Sabharwal, and B. Aazhang, “Design of WARP: A wireless open-access research
platform,” in European Signal Processing Conference, Florence, Italy: IEEE, 2006, pp. 0–4.
[41] P. Murphy, “WARP FPGA Board v1.2,” 2006.

http://warpproject.org/trac/wiki/HardwareUsersGuides/FPGABoard_v1.2 (accessed Jun. 24,
2023).
[42] H. Wu, T. Wang, Z. Yuan, C. Peng, Z. Li, Z. Tan, B. Ding, X. Li, Y. Li, J. Liu, S. Lu, “The Tick
Programmable Low-Latency SDR System,” in Proceedings of the 23rd Annual International
Conference on Mobile Computing and Networking, 2017, pp. 101–113. doi:
10.1145/3117811.3117834.
[43] X. Li, J. Liu, B. Ding, Z. Li, H. Wu, and T. Wang, “TickSEC: A novel reconfigurable platform
for wifi physical layer security,” in Proceedings - 2018 International Conference on Networking
and Network Applications, NaNA 2018, IEEE, 2019, pp. 237–244. doi:
10.1109/NANA.2018.8648715.
[44] J. Malinen, “hostapd.” https://w1.fi/hostapd/ (accessed Jun. 18, 2021).
[45] J. Kaur, “Mac layer management frame denial of service attacks,” in Proceedings - 2016
International Conference on Micro-Electronics and Telecommunication Engineering, ICMETE
2016, IEEE, 2016, pp. 155–160. doi: 10.1109/ICMETE.2016.83.
127
[46] D. Gentry and A. Pennarun, “Passive Taxonomy of Wifi Clients using MLME Frame Contents,”
CoRR, vol. abs/1608.0, 2016, doi: 10.48550/arXiv.1608.01725.
[47] P. Robyns, B. Bonné, P. Quax, and W. Lamotte, “Noncooperative 802.11 MAC Layer
Fingerprinting and Tracking of Mobile Devices,” Security and Communication Networks, vol.
2017, 2017, doi: 10.1155/2017/6235484.
[48] J. Franklin, D. McCoy, and P. Tabriz, “Passive data link layer 802.11 wireless device driver
fingerprinting,” in 15th USENIX Security Symposium, 2006, pp. 16–89.
[49] OpenWrt Project, “OpenWRT,” 2022. https://openwrt.org (accessed Mar. 22, 2022).
[50] M. A. C. Aung and K. P. Thant, “IEEE 802 . 11 Attacks and Defenses,” in Seventeenth
International Conference on Computer Applications (ICCA 2019), 2019, pp. 186–191.
[51] A. Amoordon, V. Deniau, C. Gransart, A. Fleury, and J. Villain, “A Threshold-Based Detection

Approach To Detect Fake Access Points and Jamming Attacks on IEEE 802.11 Networks:
Implementation, Results and Limitations,” in 2022 3rd URSI Atlantic and Asia Pacific Radio
Science Meeting, AT-AP-RASC 2022, URSI, 2022, pp. 2–5. doi: 10.23919/AT-AP-
RASC54737.2022.9814377.
[52] J. Bellardo and S. Savage, “802.11 Denial-of-Service Attacks: Real Vulnerabilities and Practical
Solutions.,” in 12th conference on USENIX Security Symposium, 2003, pp. 15–28.
[53] P. Liu, P. Yang, W. Z. Song, Y. Yan, and X. Y. Li, “Real-time Identification of Rogue WiFi
Connections Using Environment-Independent Physical Features,” in Proceedings - IEEE
INFOCOM, IEEE, 2019, pp. 190–198. doi: 10.1109/INFOCOM.2019.8737455.
[54] D. Halperin, W. Hu, A. Sheth, and D. Wetherall, “Tool release: Gathering 802.11n traces with
channel state information,” ACM SIGCOMM Computer Communication Review, vol. 41, no. 1,
p. 53, 2011, doi: 10.1145/1925861.1925870.
[55] O. Wellnitz and L. Wolf, “On latency in IEEE 802.11-based wireless ad-hoc networks,” ISWPC
2010 - IEEE 5th International Symposium on Wireless Pervasive Computing 2010, pp. 261–266,
2010, doi: 10.1109/ISWPC.2010.5483719.
[56] M. Renzmann, “MadWifi,” 2008. http://madwifi-project.org (accessed Dec. 19, 2020).
[57] T. Benson, A. Akella, and D. Maltz, “Unraveling the complexity of network management,” 6th
USENIX Symposium on Networked Systems Design and Implementation, pp. 335–348, 2009,
[Online]. Available: http://dl.acm.org/citation.cfm?id=1558977.1559000
128
[58] T. Roscoe, S. Hand, R. Isaacs, R. Mortier, and P. Jardetzky, “Predicate routing: Enabling
controlled networking,” Computer Communication Review, vol. 33, no. 1, pp. 65–70, 2003, doi:
10.1145/774763.774773.
[59] G. Xie, J. Zhan, D. A. Maltz, H. Zhang, A. Greenberg, and G. Hjálmtýsson, “Routing design in
operational networks,” ACM SIGCOMM Computer Communication Review, vol. 34, no. 4, p.
27, 2004, doi: 10.1145/1030194.1015472.
[60] D. Kreutz, F. M. V. Ramos, P. E. Verissimo, C. E. Rothenberg, S. Azodolmolky, and S. Uhlig,

“Software-defined networking: A comprehensive survey,” Proceedings of the IEEE, vol. 103,
no. 1, pp. 14–76, 2015, doi: 10.1109/JPROC.2014.2371999.
[61] B. Raghavan, T. Koponen, and A. Ghodsi, “Making the Internet More Evolvable,” 2012.
[Online]. Available: http://www.icsi.berkeley.edu/pubs/techreports/ICSI_TR-12-011.pdf
[62] B. Raghavan, T. Koponen, A. Ghodsi, M. Casado, S. Ratnasamy, and S. Shenker, “Software-

defined internet architecture: Decoupling architecture from infrastructure,” Proceedings of the
11th ACM Workshop on Hot Topics in Networks, HotNets-11, pp. 43–48, 2012, doi:
10.1145/2390231.2390239.
[63] A. Ghodsi, P. B. Godfrey, N. Mckeown, G. Parulkar, B. Raghavan, and G. Tech, “Architecting

for Innovation,” Computer Communication Review, vol. 41, no. 3, pp. 24–36, 2011.
[64] D. Boneh, D. Mazieres, M. Rosenblum, A. Akella, and N. McKeown, “Designing Secure

Networks from the Ground-Up,” NSF NeTS FIND Initiative, 2006.
[65] M. Casado et al., “SANE: a protection architecture for enterprise networks,” in 15th USENIX
Security Symposium, USENIX Association, Aug. 2006, pp. 137–151.
[66] N. Weaver, D. Ellis, S. Staniford, and V. Paxson, “Worms vs. perimeters: The case for Hard-
LANs,” Proceedings - 12th Annual IEEE Symposium on High Performance Interconnects, Hot
Interconnects, pp. 70–76, 2004, doi: 10.1109/CONECT.2004.1375206.
[67] A. Myers, E. Ng, and H. Zhang, “Rethinking the service model: Scaling Ethernet to a million
nodes,” Proc. HotNets, no. 003604, 2004, doi: 10.1.1.99.7216.
[68] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown, and S. Shenker, “Ethane: Taking
control of the enterprise,” in ACM SIGCOMM, in SIGCOMM ’07. Acm, 2007, pp. 1–12.
[69] A. Greenberg et al., “A clean slate 4D approach to network control and management,” ACM
SIGCOMM Computer Communication Review, vol. 35, no. 3, p. 41, Oct. 2005, doi:
10.1145/1096536.1096541.
129
[70] B. Heller, R. Sherwood, and N. McKeown, “The controller placement problem,” ACM
SIGCOMM Computer Communication Review, vol. 42, no. 4, p. 473, Sep. 2012, doi:
10.1145/2377677.2377767.
[71] “Open Networking Foundation,” 2022. https://www.opennetworking.org (accessed May 22,

2022).
[72] C. Kozanitis, J. Huber, S. Singh, and G. Varghese, “Leaping multiple headers in a single bound:
Wire-speed parsing using the Kangaroo system,” Proceedings - IEEE INFOCOM, pp. 1–9,
2010, doi: 10.1109/INFCOM.2010.5462139.
[73] H. Song, “Protocol-oblivious forwarding: unleash the power of SDN through a future-proof
forwarding plane,” in Proceedings of the second ACM SIGCOMM workshop on Hot topics in
software defined networking, 2013, p. 127. doi: 10.1145/2491185.2491190.
[74] Z. Shi, Y. Tian, X. Wang, J. Pan, and X. Zhang, “Po-Fi: Facilitating innovations on WiFi
networks with an SDN approach,” Computer Networks, vol. 187, no. November 2020, p.
107781, 2021, doi: 10.1016/j.comnet.2020.107781.
[75] P. Bosshart et al., “P4: Programming protocol-independent packet processors,” ACM

SIGCOMM Computer Communication Review, vol. 44, no. 3, pp. 87–95, 2014, doi:
10.1145/2656877.2656890.
[76] W. Tu and F. Ruffy, “Linux Network Programming with P4,” Proceedings of the 2018 Linux
Plumbers Conference, pp. 1–10, 2018.
[77] Barefoot Networks, “Barefoot Tofino,” 2022.

https://www.barefootnetworks.com/products/brief-tofino/ (accessed Nov. 18, 2020).
[78] H. Wang et al., “P4FPGA : A rapid prototyping framework for P4,” SOSR 2017 - Proceedings
of the 2017 Symposium on SDN Research, pp. 122–135, 2017, doi: 10.1145/3050220.3050234.
[79] H. Stubbe, “P4 Compiler & Interpreter: A Survey,” Future Internet (FI) and Innovative Internet
Technologies and Mobile Communication (IITM), no. May, pp. 47–52, 2017.
[80] M. Shahbaz et al., “PISCES: A programmable, protocol-independent software switch,”

SIGCOMM 2016 - Proceedings of the 2016 ACM Conference on Special Interest Group on Data
Communication, pp. 525–538, 2016, doi: 10.1145/2934872.2934886.
[81] B. Pfaff et al., “The Design and Implementation of Open vSwitch,” in 12th USENIX symposium
on networked systems design and implementation, 2015, pp. 117–130.
130
[82] C. Kolias, S. Ahlawat, C. Ashton, M. Cohn, S. Manning, and S. Nathan, “OpenFlow - Enabled
Mobile and Wireless Networks,” Open Networking Foundation, 2013. [Online]. Available:
https://www.opennetworking.org/wp-content/uploads/2013/03/sb-wireless-mobile.pdf
[83] K. K. Yap, M. Kobayashi, D. Underhill, S. Seetharaman, P. Kazemian, and N. McKeown, “The

Stanford Openroads deployment,” in WiNTECH’09 - Proc. 4th ACM International Workshop
on Wireless Network Testbeds, Experimental Evaluation and Characterization, 2009, pp. 59–
66. doi: 10.1145/1614293.1614304.
[84] N. Gude, T. Koponen, J. Pettit, and B. Pfaff, “NOX: towards an operating system for networks,”
ACM SIGCOMM Computer Communication Review, vol. 38, no. 3, pp. 105–110, 2008.
[85] K. K. Yap et al., “Blueprint for introducing innovation into wireless mobile networks,”
Proceedings of the 2nd ACM SIGCOMM Workshop on Virtualized Infrastructure Systems and
Architectures, VISA ’10, Co-located with SIGCOMM 2010, pp. 25–32, 2010, doi:
10.1145/1851399.1851404.
[86] S. Hätönen, P. Savolainen, A. Rao, H. Flinck, and S. Tarkoma, “Off-the-Shelf Software-defined

Wi-Fi Networks,” in 2016 ACM SIGCOMM Conference, 2016, pp. 609–610.
[87] M. Rademacher, F. Siebertz, M. Schlebusch, and K. Jonas, “Experiments with OpenFlow and
IEEE802.11 Point-to-Point Links in a WMN,” in ICWMC 2016 - Twelfth Int. Conf. Wirel. Mob.
Commun., 2016, pp. 99–105.
[88] H. Moura, A. R. Alves, J. R. A. Borges, D. F. Macedo, and M. A. M. Vieira, “Ethanol: A

Software-Defined Wireless Networking architecture for IEEE 802.11 networks,” Comput
Commun, vol. 149, pp. 176–188, 2020, doi: 10.1016/j.comcom.2019.10.010.
[89] R. Cwalinski and H. Koenig, “RADIator - An approach for controllable wireless networks,” in
IEEE NETSOFT 2016 - 2016 IEEE NetSoft Conference and Workshops: Software-Defined
Infrastructure for Networks, Clouds, IoT and Services, IEEE, 2016, pp. 260–268. doi:
10.1109/NETSOFT.2016.7502421.
[90] A. Kappen, “SDWN for ONOS/LEDE,” 2017. https://berlin-open-wireless-

lab.github.io/GSoC2017_SDWN_OpenWifi/SDWN.html (accessed Oct. 15, 2021).
[91] P. Berde et al., “ONOS: Towards an Open, Distributed SDN OS,” in Proceedings of the third
workshop on Hot topics in software defined networking, 2014, pp. 1–6. doi:
10.1145/2620728.2620744.
[92] P. Engelhard, A. Zachlod, J. Schulz-Zander, and S. Du, “Toward scalable and virtualized
massive wireless sensor networks,” in Proceedings of the 2019 International Conference on
Networked Systems, NetSys 2019, IEEE, 2019. doi: 10.1109/NetSys.2019.8854518.
131
[93] A. Scheibe, L. P. Gaspary, and W. Cordeiro, “Managing Programmable Low-End Wireless
Networks through Distributed SDN Controllers,” in Proceedings of the 13th IFIP Wireless and
Mobile Networking Conference, WMNC 2021, IFIP, 2021, pp. 32–39. doi:
10.23919/WMNC53478.2021.9618890.
[94] P4 Language Consortium, “Behavioral Model (bmv2),” 2022.

https://github.com/p4lang/behavioral-model (accessed Nov. 19, 2020).
[95] B. Lantz, B. Heller, and N. McKeown, “A network in a laptop: rapid prototyping for software-
defined networks,” Hotnets-IX Proceedings of the 9th ACM SIGCOMM Workshop on Hot
Topics in Networks, pp. 1–6, 2010, Accessed: Nov. 03, 2013. [Online]. Available:
http://dl.acm.org/citation.cfm?id=1868466
[96] A. Bianco, R. Birke, L. Giraudo, and M. Palacin, “OpenFlow switching: Data plane
performance,” IEEE International Conference on Communications, pp. 1–5, 2010, doi:
10.1109/ICC.2010.5502016.
[97] M. Appelman and M. de Boer, “Performance Analysis of OpenFlow Hardware,” 2012.
[98] L. C. Costa et al., “Performance evaluation of OpenFlow data planes,” Proceedings of the IM
2017 - 2017 IFIP/IEEE International Symposium on Integrated Network and Service
Management, pp. 470–475, 2017, doi: 10.23919/INM.2017.7987314.
[99] P. Bosshart et al., “Forwarding metamorphosis: Fast programmable match-action processing in

hardware for SDN,” in SIGCOMM, 2013. doi: 10.1145/2534169.2486011.
[100] C. K. Dubendorfer, B. W. Ramsey, and M. A. Temple, “An RF-DNA verification process for
ZigBee networks,” in Proceedings - IEEE Military Communications Conference MILCOM,
IEEE, 2012, pp. 1–6. doi: 10.1109/MILCOM.2012.6415804.
[101] A. C. Polak and D. Goeckel, “Wireless Device Identification Based on RF Oscillator

Imperfections,” IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY,
vol. 10, no. 12, pp. 2492–2501, 2015.
[102] S. Dolatshahi, A. C. Polak, and D. Goeckel, “Identification of wireless users via power amplifier
imperfections,” in Conference Record - Asilomar Conference on Signals, Systems and
Computers, IEEE, 2010, pp. 1553–1557. doi: 10.1109/ACSSC.2010.5757798.
[103] O. Ureten and N. Serinken, “Bayesian detection of radio transmitter turn-on transients.,” in
Proceedings of the IEEE-EURASIP Workshop on Nonlinear Signal and Image Processing
(NSIP’99), 1999, pp. 830–834.
132
[104] O. Ureten and N. Serinken, “Bayesian detection of Wi-Fi transmitter RF fingerprints.,” Electron
Lett, vol. 41, no. 6, pp. 373–374, 2005, doi: 10.1049/el:20057769.
[105] O. Tekbas, O. Ureten, and N. Serinken, “Improvement of transmitter identification system for
low SNR transients,” Electron Lett, vol. 41, no. 2, pp. 40–41, 2005, doi: 10.1049/el:20040160.
[106] O. Üreten and N. Serinken, “Detection, Characterization and Classification of Radio Transmitter
Turn-On Transients,” in Multisensor Fusion, Springer Netherlands, 2002, pp. 611–616. doi:
10.1007/978-94-010-0556-2_29.
[107] X. J. Li and M. Bharanidharan, “RSSI Fingerprinting Based iPhone Indoor Localization

System,” Wirel Pers Commun, pp. 1–14, 2019, doi: 10.1007/s11277-019-07015-4.
[108] P. Madani and N. Vlajic, “RSSI-Based MAC-Layer Spoofing Detection: Deep Learning
Approach,” Journal of Cybersecurity and Privacy, vol. 1, no. 3, pp. 453–469, 2021, doi:
10.3390/jcp1030023.
[109] J. K. Tugnait and H. Kim, “A channel-based hypothesis testing approach to enhance user
authentication in wireless networks,” in 2010 2nd International Conference on COMmunication
Systems and NETworks, COMSNETS 2010, IEEE, 2010, pp. 1–9. doi:
10.1109/COMSNETS.2010.5432018.
[110] L. Xiao, L. Greenstein, N. Mandayam, and W. Trappe, “Fingerprints in the ether: Using the
physical layer for wireless authentication,” in IEEE International Conference on
Communications, 2007, pp. 4646–4651. doi: 10.1109/ICC.2007.767.
[111] L. Xiao, L. Greenstein, N. Mandayam, and W. Trappe, “A physical-layer technique to enhance

authentication for mobile terminals,” in IEEE International Conference on Communications,
2008, pp. 1520–1524. doi: 10.1109/ICC.2008.294.
[112] F. J. Liu, X. Wang, and S. L. Primak, “A two dimensional quantization algorithm for CIR-based
physical layer authentication,” in IEEE International Conference on Communications, IEEE,
2013, pp. 4724–4728. doi: 10.1109/ICC.2013.6655319.
[113] B. W. Ramsey, M. A. Temple, and B. E. Mullins, “PHY foundation for multi-factor ZigBee
node authentication,” in GLOBECOM - IEEE Global Telecommunications Conference, IEEE,
2012, pp. 795–800. doi: 10.1109/GLOCOM.2012.6503210.
[114] B. W. Ramsey, T. D. Stubbs, B. E. Mullins, M. A. Temple, and M. A. Buckner, “Wireless

infrastructure protection using low-cost radio frequency fingerprinting receivers,” International
Journal of Critical Infrastructure Protection, vol. 8, pp. 27–39, 2015, doi:
10.1016/j.ijcip.2014.11.002.
133
[115] J. Hall, M. Barbeau, and E. Kranakis, “Enhancing intrusion detection in wireless networks using
radio frequency fingerprinting,” in Proceedings of the Third IASTED International Conference
on Communications, Internet, and Information Technology, 2004, pp. 201–206.
[116] N. T. Nguyen, G. Zheng, Z. Han, and R. Zheng, “Device fingerprinting to enhance wireless
security using nonparametric Bayesian method,” in Proceedings - IEEE INFOCOM, IEEE,
2011, pp. 1404–1412. doi: 10.1109/INFCOM.2011.5934926.
[117] Q. Wu et al., “Deep learning based RF fingerprinting for device identification and wireless
security,” Electron Lett, vol. 54, no. 24, pp. 1405–1407, 2018, doi: 10.1049/el.2018.6404.
[118] F. Lanze, A. Panchenko, B. Braatz, and A. Zinnen, “Clock skew based remote device
fingerprinting demystified,” in GLOBECOM - IEEE Global Telecommunications Conference,
IEEE, 2012, pp. 813–819. doi: 10.1109/GLOCOM.2012.6503213.
[119] R. Krishna and C. Hoene, “Calculating relative clock drifts using IEEE 802.11 beacons,” in
Proceedings of INDICON 2009 - An IEEE India Council Conference, 2009. doi:
10.1109/INDCON.2009.5409348.
[120] S. Jana and S. K. Kasera, “On fast and accurate detection of unauthorized wireless access points
using clock skews,” IEEE Trans Mob Comput, vol. 9, no. 3, pp. 449–462, 2010, doi:
10.1109/TMC.2009.145.
[121] C. Neumann, O. Heen, and S. Onno, “An empirical study of passive 802.11 device
fingerprinting,” in Proceedings - 32nd IEEE International Conference on Distributed
Computing Systems Workshops, ICDCSW 2012, IEEE, 2012, pp. 593–602. doi:
10.1109/ICDCSW.2012.8.
[122] A. K. Dalai et al., “A fingerprinting technique for identification of wireless devices,” in CITS
2018 - 2018 International Conference on Computer, Information and Telecommunication
Systems, IEEE, 2018, pp. 1–5. doi: 10.1109/CITS.2018.8440151.
[123] Q. Xu, R. Zheng, W. Saad, and Z. Han, “Device fingerprinting in wireless networks: Challenges
and opportunities,” IEEE Communications Surveys and Tutorials, vol. 18, no. 1, pp. 94–104,
2016, doi: 10.1109/COMST.2015.2476338.
[124] Dartmouth University, “CRAWDAD Wireless Data Archive,” 2022. http://crawdad.org

(accessed May 09, 2021).
[125] O. Ureten and N. Serinken, “Detection of radio transmitter turn-on transients.,” Electron Lett,
vol. 35, no. 23, pp. 1996–1997, 1999, doi: 10.1049/el:19991369.
134
[126] M. Miettinen, S. Marchal, I. Hafeez, N. Asokan, A. R. Sadeghi, and S. Tarkoma, “IoT
SENTINEL: Automated Device-Type Identification for Security Enforcement in IoT,” in
Proceedings - International Conference on Distributed Computing Systems, IEEE, 2017, pp.
2177–2184. doi: 10.1109/ICDCS.2017.283.
[127] K. Merchant, S. Revay, G. Stantchev, and B. Nousain, “Deep Learning for RF Device
Fingerprinting in Cognitive Communication Networks,” IEEE Journal on Selected Topics in
Signal Processing, vol. 12, no. 1, pp. 160–167, 2018, doi: 10.1109/JSTSP.2018.2796446.
[128] S. Abbas et al., “Improving security of the Internet of Things via RF fingerprinting based device
identification system,” Neural Comput Appl, vol. 33, no. 21, pp. 14753–14769, 2021, doi:
10.1007/s00521-021-06115-2.
[129] H. Abdelnasser, K. A. Harras, and M. Youssef, “UbiBreathe: A ubiquitous non-invasive wifi-

based breathing estimator,” Proceedings of the International Symposium on Mobile Ad Hoc
Networking and Computing (MobiHoc), vol. June, pp. 277–286, 2015, doi:
10.1145/2746285.2755969.
[130] J. Wright, R. Speers, and R. Melgares, “KillerBee: A Framework and Tools for Testing &
Auditing ZigBee and IEEE 802.15.4 Networks.” 2009. [Online]. Available:
https://github.com/riverloopsec/killerbee
[131] K. Shaukat et al., “Performance comparison and current challenges of using machine learning
techniques in cybersecurity,” Energies (Basel), vol. 13, no. 10, 2020, doi: 10.3390/en13102509.
[132] S. Gopalakrishnan, M. Cekic, and U. Madhow, “Robust Wireless Fingerprinting via Complex-
Valued Neural Networks,” in IEEE Global Communications Conference, 2019.
[133] F. Restuccia et al., “Deepradioid: Real-time channel-resilient optimization of deep learning-

based radio fingerprinting algorithms,” Proceedings of the International Symposium on Mobile
Ad Hoc Networking and Computing (MobiHoc), pp. 51–60, 2019, doi:
10.1145/3323679.3326503.
[134] Z. Ahmad, A. Shahid Khan, C. Wai Shiang, J. Abdullah, and F. Ahmad, “Network intrusion
detection system: A systematic study of machine learning and deep learning approaches,”
Transactions on Emerging Telecommunications Technologies, vol. 32, no. 1, pp. 1–29, 2021,
doi: 10.1002/ett.4150.
[135] D. Schepers, A. Ranganathan, and M. Vanhoef, On the Robustness of Wi-Fi Deauthentication

Countermeasures, vol. 1, no. 1. Association for Computing Machinery, 2022. doi:
10.1145/3507657.3528548.
135
[136] E. Chatzoglou, G. Kambourakis, and C. Kolias, “Empirical Evaluation of Attacks against IEEE
802.11 Enterprise Networks: The AWID3 Dataset,” IEEE Access, vol. 9, pp. 34188–34205,
2021, doi: 10.1109/ACCESS.2021.3061609.
[137] M. Vanhoef and E. Ronen, “Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and
EAP-pwd,” in IEEE Symposium on Security and Privacy, 2020.
[138] N. Dalal, N. Akhtar, A. Gupta, N. Karamchandani, G. S. Kasbekar, and J. Parekh, “A Wireless

Intrusion Detection System for 802.11 WPA3 Networks,” in 2022 14th International
Conference on COMmunication Systems & NETworkS (COMSNETS), IEEE, 2022, pp. 384–
392. doi: 10.1109/comsnets53615.2022.9668542.
[139] H. Rahbari, M. Krunz, and L. Lazos, “Security vulnerability and countermeasures of frequency
offset correction in 802.11a systems,” in Proceedings - IEEE INFOCOM, 2014, pp. 1015–1023.
doi: 10.1109/INFOCOM.2014.6848031.
[140] R. Gummadi, D. Wetherall, B. Greenstein, and S. Seshan, “Understanding and mitigating the
impact of RF interference on 802.11 networks,” in ACM SIGCOMM 2007: Conference on
Computer Communications, 2007, pp. 385–396. doi: 10.1145/1282380.1282424.
[141] K. Bicakci and B. Tavli, “Denial-of-Service attacks and countermeasures in IEEE 802.11
wireless networks,” Comput Stand Interfaces, vol. 31, no. 5, pp. 931–941, 2009, doi:
10.1016/j.csi.2008.09.038.
[142] T. Jamal, M. Alam, and M. M. Umair, “Detection and prevention against RTS attacks in wireless
LANs,” Proceedings of 2017 International Conference on Communication, Computing and
Digital Systems, C-CODE 2017, pp. 152–156, 2017, doi: 10.1109/C-CODE.2017.7918920.
[143] S. Ray, J. B. Carruthers, and D. Starobinski, “RTS/CTS-induced congestion in ad hoc wireless

LANs,” in IEEE Wireless Communications and Networking Conference, WCNC, IEEE, 2003,
pp. 1516–1521. doi: 10.1109/WCNC.2003.1200611.
[144] I.-G. Lee, K. Go, and J. H. Lee, “Battery Draining Attack and Defense against Power Saving
Wireless LAN Devices,” Sensors, vol. 7, pp. 1–13, 2020.
[145] M. Eian and S. F. Mjølsnes, “A formal analysis of IEEE 802.11w deadlock vulnerabilities,”
Proceedings - IEEE INFOCOM, pp. 918–926, 2012, doi: 10.1109/INFCOM.2012.6195841.
[146] A. Arshad, Z. M. Hanapi, S. Subramaniam, and R. Latip, “A survey of Sybil attack

countermeasures in IoT-based wireless sensor networks,” PeerJ Comput Sci, vol. 7, pp. 1–33,
2021, doi: 10.7717/peerj-cs.673.
136
[147] A. Bartoli, E. Medvet, and F. Onesti, “Evil twins and WPA2 Enterprise: A coming security
disaster?,” Comput Secur, vol. 74, pp. 1–11, 2018, doi: 10.1016/j.cose.2017.12.011.
[148] Y. Li, M. Serrano, T. Chin, K. Xiong, and J. Lin, “A software-defined networking-based

detection and mitigation approach against KRACK,” in ICETE 2019 - Proceedings of the 16th
International Joint Conference on e-Business and Telecommunications, 2019, pp. 244–251. doi:
10.5220/0007926202440251.
[149] J. Martin et al., “A Study of MAC Address Randomization in Mobile Devices and When it
Fails,” Proceedings on Privacy Enhancing Technologies, vol. 2017, no. 4, pp. 365–383, 2017,
doi: 10.1515/popets-2017-0054.
[150] IEEE Std 802.11w-2009, “Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specifications. Amendment 4: Protected ManagementFrames. IEEE Std. 802.11w-
2009,” Amendment to IEEE Std 802.11-2007, pp. 1–111, 2009.
[151] R. Regan and J. M. L. Manickam, “A Survey on Impersonation Attack in Wireless Networks

R.,” International Journal of Security and Its Applications, vol. 19, no. 5, pp. 39–48, 2017, doi:
10.14257/ijsia.2017.11.5.04 A.
[152] N. Manjunath, S. PalChaudhuri, and D. Avalur, “Detecting Deauthentication and Disassociation

Attack in Wireless Local Area Networks,” 2019
[153] Y. Sheng, K. Tan, G. Chen, D. Kotz, and A. Campbell, “Detecting 802.11 MAC layer spoofing
using received signal strength,” Proceedings - IEEE INFOCOM, pp. 2441–2449, 2008, doi:
10.1109/INFOCOM.2007.239.
[154] N. Baharudin, F. H. M. Ali, M. Y. Darus, and N. Awang, “Wireless intruder detection system
(WIDS) in detecting de-authentication and disassociation attacks in IEEE 802.11,” in 5th
International Conference on IT Convergence and Security, ICITCS 2015 - Proceedings, IEEE,
2015, pp. 1–5. doi: 10.1109/ICITCS.2015.7293037.
[155] R. Cwalinski and H. Koenig, “SDN-based Attack Detection in Wireless Local Area Networks,”
in 4th IEEE Conference on Network Softwarization and Workshops, IEEE, 2018, pp. 187–191.
doi: 10.1109/NETSOFT.2018.8460121.
[156] J. K. Tugnait, “Wireless user authentication via comparison of power spectral densities,” IEEE
Journal on Selected Areas in Communications, vol. 31, no. 9, pp. 1791–1802, 2013, doi:
10.1109/JSAC.2013.130912.
[157] V. Nagarajan, V. Arasan, and D. Huang, “Using power hopping to counter MAC spoof attacks
in WLAN,” 2010 7th IEEE Consumer Communications and Networking Conference, CCNC
2010, pp. 1–5, 2010, doi: 10.1109/CCNC.2010.5421588.
137
[158] R. M. Sundaram, B. McCorkendale, J. Harmon, and S. Chillappa, “Systems and Methods for
Managing Wireless - Network Deauthentication Attacks,” 2019
[159] S. A. Tamhane, N. D. Gaywala, S. R. Liwen Chu, H. Zhang, and H.-L. Lou, “Validating De-
authentication Requests,” United States Patent US01077149, Sep. 8 , 2020.
[160] M. Ibrahim et al., “Verification：Accuracy Evaluation of WiFi FineTime Measurements on an

Open Platform,” in MobiCom, 2018, pp. 417–427. doi: 10.1145/3241539.3241555.
[161] W. Shao, H. Luo, F. Zhao, H. Tian, S. Yan, and A. Crivello, “Accurate Indoor Positioning Using
Temporal-Spatial Constraints Based on Wi-Fi Fine Time Measurements,” IEEE Internet Things
J, vol. 4662, no. c, pp. 1–1, 2020, doi: 10.1109/jiot.2020.2992069.
[162] A. Kulkarni and A. Lim, “Preliminary study on indoor localization using smartphone-based
IEEE 802.11mc,” in CoNEXT 2019 Companion - Proceedings of the 15th International
Conference on Emerging Networking EXperiments and Technologies, Part of CoNEXT 2019,
2019, pp. 43–44. doi: 10.1145/3360468.3368171.
[163] C. Wang et al., “Accurate sybil attack detection based on fine-grained physical channel
information,” Sensors (Switzerland), vol. 18, no. 3, pp. 1–23, 2018, doi: 10.3390/s18030878.
[164] W. Wang, A. X. Liu, M. Shahzad, K. Ling, and S. Lu, “Device-Free Human Activity
Recognition Using Commercial WiFi Devices,” IEEE Journal on Selected Areas in
Communications, vol. 35, no. 5, pp. 1118–1131, 2017, doi: 10.1109/JSAC.2017.2679658.
[165] A. Amoordon, V. Deniau, A. Fleury, and C. Gransart, “A single supervised learning model to
detect fake access points, frequency sweeping jamming and deauthentication attacks in IEEE
802.11 networks,” Machine Learning with Applications, vol. 10, no. July, p. 100389, 2022, doi:
10.1016/j.mlwa.2022.100389.
[166] R. Doshi, N. Apthorpe, and N. Feamster, “Machine learning DDoS detection for consumer
internet of things devices,” in 2018 IEEE Symposium on Security and Privacy Workshops, IEEE,
2018, pp. 29–35. doi: 10.1109/SPW.2018.00013.
[167] N. Elmrabit, F. Zhou, F. Li, and H. Zhou, “Evaluation of Machine Learning Algorithms for
Anomaly Detection,” in International Conference on Cyber Security and Protection of Digital
Services, Cyber Security 2020, 2020. doi: 10.1109/CyberSecurity49315.2020.9138871.
[168] F. Pedregosa et al., “Scikit-learn: Machine Learning in Python,” Journal of Machine Learning
Research, vol. 12, pp. 2825–2830, 2011.
138
[169] Y. Liu, J. Wang, J. Li, S. Niu, and H. Song, “Class-Incremental Learning for Wireless Device
Identification in IoT,” IEEE Internet Things J, vol. 8, no. 23, pp. 17227–17235, 2021, doi:
10.1109/JIOT.2021.3078407.
[170] T. Li, Z. Hong, and L. Yu, “Machine Learning-based Intrusion Detection for IoT Devices in
Smart Home,” in IEEE International Conference on Control and Automation, ICCA, 2020, pp.
277–282. doi: 10.1109/ICCA51439.2020.9264406.
[171] H. Alipour, Y. B. Al-Nashif, P. Satam, and S. Hariri, “Wireless Anomaly Detection Based on
IEEE 802.11 Behavior Analysis,” IEEE Transactions on Information Forensics and Security,
vol. 10, no. 10, pp. 2158–2170, 2015, doi: 10.1109/TIFS.2015.2433898.
[172] A. Arora, “Preventing wireless deauthentication attacks over 802.11 Networks,” arXiv preprint
arXiv:1901.07301, 2018, [Online]. Available: http://arxiv.org/abs/1901.07301
[173] H. A. Noman, S. M. Abdullah, N. Kama, and S. A. Noman, “A Lightweight Scheme to Mitigate

Deauthentication and Disassociation DoS Attacks in Wireless 802.11 Networks,” International
Journal of Video&Image Processing and Network Security IJVIPNS-IJENS, vol. 16, no. 01,
2016.
[174] T. D. Nguyen, D. H. M. Nguyen, B. N. Tran, H. Vu, and N. Mittal, “A lightweight solution for
defending against deauthentication/ disassociation attacks on 802.11 networks,” Proceedings -
International Conference on Computer Communications and Networks, ICCCN, pp. 185–190,
2008, doi: 10.1109/ICCCN.2008.ECP.51.
[175] M. Malekzadeh, A. A. A. Ghani, Z. A. Zulkarnain, and Z. Muda, “Security Improvement for

Management Frames in IEEE 802 . 11 Wireless Networks,” International Journal of Computer
Science and 276 Network Security, vol. 7, no. 6, pp. 276–284, 2007.
[176] I. Butun, P. Osterberg, and H. Song, “Security of the Internet of Things: Vulnerabilities, Attacks,
and Countermeasures,” IEEE Communications Surveys and Tutorials, vol. 22, no. 1, pp. 616–
644, 2020, doi: 10.1109/COMST.2019.2953364.
[177] Y. Liu, J. Wang, J. Li, S. Niu, and H. Song, “Machine Learning for the Detection and
Identification of Internet of Things Devices: A Survey,” IEEE Internet Things J, vol. 9, no. 1,
pp. 298–320, 2022, doi: 10.1109/JIOT.2021.3099028.
[178] A. Raghuprasad, S. Padmanabhan, M. Arjun Babu, and P. K. Binu, “Security Analysis and
Prevention of Attacks on IoT Devices,” in International Conference on Communication and
Signal Processing (ICCSP), 2020, pp. 876–880. doi: 10.1109/iccsp48568.2020.9182055.
[179] J. Andress and S. Winterfeld, Cyber Warfare: Techniques, Tactics and Tools for Security
Practitioners, 1st ed. Syngress Publishing, 2011.
139
[180] I.-C. MIHAI, Ștefan PRUNĂ, and I.-D. BARBU, “Cyber Kill Chain Analysis,” International
Journal of Information Security and Cybercrime, vol. 3, no. 2, pp. 37–42, 2014, doi:
10.19107/ijisc.2014.02.04.
[181] P. N. Bahrami, A. Dehghantanha, T. Dargahi, R. M. Parizi, K. K. R. Choo, and H. H. S. Javadi,

“Cyber kill chain-based taxonomy of advanced persistent threat actors: Analogy of tactics,
techniques, and procedures,” Journal of Information Processing Systems, vol. 15, no. 4, pp. 865–
889, 2019, doi: 10.3745/JIPS.03.0126.
[182] F. Wilkens, F. Ortmann, S. Haas, M. Vallentin, and M. Fischer, “Multi-Stage Attack Detection
via Kill Chain State Machines,” in CYSARM 2021 - Proceedings of the 3rd Workshop on Cyber-
Security Arms Race, co-located with CCS 2021, Association for Computing Machinery, 2021,
pp. 13–24. doi: 10.1145/3474374.3486918.
[183] P. Barford et al., “Cyber situational awareness: Issues and research,” in Cyber Situational
Awareness: Issues and Research, Springer US, 2010, pp. 3–13. doi: 10.1007/978-1-4419-0140-
8_1.
[184] R. O. Andrade and S. G. Yoo, “Cognitive security: A comprehensive study of cognitive science
in cybersecurity,” Journal of Information Security and Applications, vol. 48, 2019, doi:
10.1016/j.jisa.2019.06.008.
[185] J. Boyd, “Destruction and Creation,” U.S. Army Command and General Staff College. pp. 1–9,
1976.
[186] K. Mepham, P. Louvieris, G. Ghinea, and N. Clewley, “Dynamic Cyber-Incident Response,” in

6th International Conference on Cyber Conflict, NATO CCD COE, 2014, pp. 121–136. doi:
10.1109/CYCON.2014.6916399.
[187] J. A. B. S. Dykstra and S. R. Orr, “Acting in the Unknown: The Cynefin Framework for
Managing Cybersecurity Risk in Dynamic Decision Making,” 2016 International Conference
on Cyber Conflict (CyCon US), 2016, doi: 10.1109/CYCONUS.2016.7836616.
[188] P. E. Moran, “OODA.Boyd.svg,” Wikipedia, 2008.

https://commons.wikimedia.org/wiki/File:OODA.Boyd.svg (accessed Oct. 24, 2022).
[189] D. Gray et al., “Improving Federal Cybersecurity Governance Through Data-Driven Decision
Making and Execution,” Carnegie Mellon University, CMU/SEI-2015-TR-011, Sept. 2015.
[190] R. Ross, G. Stoneburner, J. Fabius-Greene, and K. Dempsey, “Managing Information Security

Risk,” 2011. doi: 10.1108/k.2011.06740caa.012.
140
[191] W. Zhijun, L. Wenjing, L. Liang, and Y. Meng, “Low-Rate DoS Attacks, Detection, Defense,
and Challenges: A Survey,” IEEE Access, vol. 8, pp. 43920–43943, 2020, doi:
10.1109/ACCESS.2020.2976609.
[192] P. Zanna, P. Radcliffe, and K. G. Chavez, “A Method for Comparing OpenFlow and P4,” in
29th International Telecommunication Networks and Applications Conference (ITNAC),
Wellington, NZ, Nov. 2019, pp. 1–3. doi: 10.1109/itnac46935.2019.9077951.
[193] P. Zanna, P. Radcliffe, and D. Kumar, “WP4: A P4 Programmable IEEE 802.11 Data Plane,” in
30th International Telecommunication Networks and Applications Conference (ITNAC), 2020,
pp. 1–6. doi: 10.1109/ITNAC50341.2020.9315141.
[194] P. Zanna, “WP4 Compiler extension,” Github, 2020. https://github.com/pzanna/p4c-wp4

(accessed Sep. 09, 2022).
[195] Microchip Technology, “KSZ8795CLX 5-Port 10/100 Managed Ethernet Switch with Gigabit
Uplink,” 2022. https://www.microchip.com/wwwproducts/en/KSZ8795 (accessed Mar. 02,
2021).
[196] M. Budiu, “P4 Compiler Design,” Github, 2021.

https://github.com/p4lang/p4c/blob/main/docs/compiler-design.pptx (accessed Aug. 19, 2020).
[197] Microchip Technology, “Microchip Studio,” 2022. https://www.microchip.com/en-us/tools-

resources/develop/microchip-studio (accessed Mar. 17, 2020).
[198] ESnet, “iPerf3,” 2022. https://iperf.fr (accessed Oct. 11, 2020).
[199] Ryu SDN Framework Community, “RYU SDN Controller,” 2022. https://ryu-sdn.org (accessed
May 19, 2020).
[200] Raspberry Pi Foundation, “Raspberry Pi,” 2022. http://www.raspberrypi.org/
[201] Z. Jiang, K. Zhao, R. Li, J. Zhao, and J. Du, “PHYAlert: identity spoofing attack detection and
prevention for a wireless edge network,” Journal of Cloud Computing, vol. 9, no. 1, 2020, doi:
10.1186/s13677-020-0154-7.
[202] Analog Devices, “Analog Devices ADRV9361-Z7035,” 2022.

https://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-
boards-kits/ADRV9361-Z7035.html (accessed Jul. 14, 2021).
[203] J. Shi, “OpenOFDM,” 2017. https://openofdm.readthedocs.io/en/latest/index.html (accessed

May 02, 2022).
141
[204] E. Sourour, H. El-Ghoroury, and D. McNeill, “Frequency offset estimation and correction in the
IEEE 802.11a WLAN,” IEEE Vehicular Technology Conference, vol. 60, no. 7, pp. 4923–4927,
2004, doi: 10.1109/vetecf.2004.1405033.
[205] I. Guyon and A. Elisseeff, “An Introduction to Variable and Feature Selection Isabelle,” Journal
of Machine Learning Research, vol. 3, pp. 1157–1182, 2003, doi: 10.1016/j.aca.2011.07.027.
[206] S. U. Rehman, K. Sowerby, and C. Coghill, “Analysis of receiver front end on the performance
of RF fingerprinting,” in IEEE International Symposium on Personal, Indoor and Mobile Radio
Communications (PIMRC), IEEE, 2012, pp. 2494–2499. doi: 10.1109/PIMRC.2012.6362777.
[207] P. Zanna, D. Kumar, and P. J. Radcliffe, “A novel method for utilizing RF information from
IEEE 802.11 frames in Software Defined Networks,” MethodsX, vol. 8, no. October, p. 101544,
2021, doi: 10.1016/j.mex.2021.101544.
[208] S. S. Khan and M. G. Madden, “One-class classification: Taxonomy of study and review of
techniques,” Knowledge Engineering Review, vol. 29, no. 3, pp. 345–374, 2014, doi:
10.1017/S026988891300043X.
[209] C. Elkan and K. Noto, “Learning Classifiers from Only Positive and Unlabeled Data,” in
Proceedings of the 14th ACM SIGKDD international conference on Knowledge discovery and
data mining, 2008, pp. 213–220.
[210] J. Bacardit, E. K. Burke, and N. Krasnogor, “Improving the scalability of rule-based

evolutionary learning,” Memet Comput, vol. 1, no. 1, pp. 55–67, 2009, doi: 10.1007/s12293-
008-0005-4.
[211] K. J. Ellis and N. Serinken, “Characteristics of radio transmitter fingerprints,” Radio Sci, vol.
36, no. 4, pp. 585–597, 2001, doi: 10.1029/2000RS002345.
[212] B. Biggio and F. Roli, “Wild patterns: Ten years after the rise of adversarial machine learning,”
Pattern Recognit, vol. 84, pp. 317–331, 2018, doi: 10.1016/j.patcog.2018.07.023.
[213] P. Zanna, “WP4 Modified openwifi,” Github, 2022. https://github.com/pzanna/openwifi

(accessed Nov. 02, 2022).
[214] C. Kolias, G. Kambourakis, A. Stavrou, and S. Gritzalis, “Intrusion detection in 802.11

networks: Empirical evaluation of threats and a public dataset,” IEEE Communications Surveys
and Tutorials, vol. 18, no. 1, pp. 184–208, 2016, doi: 10.1109/COMST.2015.2402161.
[215] P. Zanna, P. Radcliffe, and D. Kumar, “Preventing Attacks on Wireless Networks Using SDN
Controlled OODA Loops and Cyber Kill Chains,” Sensors, vol. 22, no. 9481, 2022, doi:
10.3390/s22239481.
142
[216] P. Zanna, D. Kumar, and P. Radcliffe, “Detecting IEEE 802.11 Client Device Impersonation on
a Wireless Access Point,” Journal of Communications and Information Networks, vol. 7, no. 4,
pp. 408–420, 2022, doi: 10.23919/jcin.2022.10005218.
[217] S. Wang, K. Gomez, K. Sithamparanathan, and P. Zanna, “Software Defined Network Security
Framework for IoT based Smart Home and City Applications,” in 13th International Conference
on Signal Processing and Communication Systems, ICSPCS 2019 - Proceedings, Dec. 2019, pp.
1–8. doi: 10.1109/ICSPCS47537.2019.9008703.
[218] S. Wang, K. Gomez, K. Sithamparanathan, M. R. Asghar, G. Russello, and P. Zanna,

“Mitigating ddos attacks in sdn-based iot networks leveraging secure control and data plane
algorithm,” Applied Sciences (Switzerland), vol. 11, no. 3, pp. 1–27, 2021, doi:
10.3390/app11030929.
143
Appendix A – Publications
The author has published five refereed journal articles and conference papers, all as the first
author, based on the work herein during his candidature. Furthermore, the author has co-
authored an additional two articles during his candidature, which do not form part of this thesis;
however, they are listed below for completeness.
Journal Articles
• P. Zanna, D. Kumar, P. Radcliffe, “A novel method for utilizing RF information from

IEEE 802.11 frames in Software Defined Networks,” Methods X, 2021, p. 101544 [207]
• P. Zanna, D. Kumar, P. Radcliffe, “Detecting IEEE 802.11 device impersonation on a
wireless access point,” Journal of Communications and Information Networks (JCIN)
[216]
• P. Zanna, P. Radcliffe, D. Kumar, “Preventing Attacks on Wireless Networks using SDN
Controlled OODA Loops and Cyber Kill Chains,” Sensors, 2022, 22. [215]
Conference Papers
• P. Zanna, P. Radcliffe and K. Gomez Chavel, “A Method for Comparing OpenFlow and
P4,” 2019 International Telecommunication Networks and Applications Conference
(ITNAC), 2019, pp. 1-3. [192]
• P. Zanna, P. Radcliffe, D. Kumar, “WP4: A Programmable IEEE 802.11 Data Plane,”
2020 International Telecommunication Networks and Applications Conference (ITNAC),
2020, pp. 1-6 [193]
Other papers not included in the thesis
• S. Wang, K. Gomez, K. Sithamparanathan, P. Zanna, "Software Defined Network

Security Framework for IoT based Smart Home and City Applications," 2019 13th
International Conference on Signal Processing and Communication Systems (ICSPCS),
Gold Coast, Australia, 2019, pp. 1-8 [217]
• S. Wang, K. Gomez, K. Sithamparanathan, M. R. Asghar, G. Russello, P. Zanna,
“Mitigating DDoS Attacks in SDN-Based IoT Networks Leveraging Secure Control and
Data Plane Algorithm,” Applied Sciences, vol. 11, no. 3, p. 929, Jan. 2021. [218]
144
Appendix B – P4 Source Code
/* -*- P4_16 -*- */

#include <core.p4>
#include <wp4_model.p4>
/*************************************************************************
*********************** H E A D E R S ***********************************
*************************************************************************/
typedef bit<9> egressSpec_t;

typedef bit<8> state_input_t; // State machine input
typedef bit<8> state_output_t; // State machine output
typedef bit<1> ssid_t; // State machine output
typedef bit<1> idok_t; // ID check output
typedef bit<48> macAddr_t; // MAC Address
// State machine input values

#define DATA 0 // (0000)
#define VALID_ID 1 // (xxx1)
#define AUTH 2 // (001x)
#define DEAUTH 4 // (010x)
#define BEACON 6 // (011x)
#define ASSOC 8 // (010x)
#define DISASSOC 10 // (101x)
#define ETAUTH 12 // (110x)
#define ETASSOC 14 // (111x)
// State machine output values

#define NO_ATK 0 // (0000)
#define DEAUTH_ATK 1 // (0001)
#define DISASSOC_ATK 2 // (0010)
#define ET_ATK 3 // (0011)
#define CRED_ATK 4 // (0100)
#define AU_FL_ATK 5 // (0101)
#define AS_FL_ATK 6 // (0110)
// Signed (int) header values will not be converted from network to host byte order
header rfFeatures_t {
int<64> timestamp; // Frame Timestamp
int<16> rssi; // RSSI (dB)
int<16> blank; // Unused
int<16> len; // Length
int<16> rate_idx; // Rate Index
int<32> phaseOffset; // Phase Offset
int<32> pilotOffset; // Pilot Offset
int<32> magSq; // Magnitude Squared
int<32> aux_4; // AUX 4
}
header frameCtrl_t {
bit<2> protoVer; // Protocol Version
bit<2> frameType; // Frame Type
bit<4> subType; // Frame Subtype
bit<1> toDS; // To Dist. System
bit<1> fromDS; // From Dist. System
bit<1> moreFrag; // More Fragments
bit<1> retry; // Retransmission
bit<1> pwrMgmt; // Power Management
bit<1> moreData; // More Data
bit<1> protFrame; // Protected Frame
bit<1> order; // Order Bit
}
header mac80211_t {
bit<16> durID; // Duration ID
macAddr_t Addr1; // MAC Address 1
bit<16> seqCtrl; // Sequence Control
}
struct Headers_t {
rfFeatures_t rfFeatures; // RF Features
frameCtrl_t frameCtrl;
mac80211_t mac80211;
}
/** Declaration of the wp4_runtime extern function. */

extern void to_cpu(in Headers_t headers);
extern ssid_t ssid_check(in Headers_t headers);
extern state_output_t state_update(in state_input_t state_input);
extern state_input_t state_read();
145
/*************************************************************************
*********************** P A R S E R *************************************
*************************************************************************/
parser prs(packet_in p, out Headers_t headers) {
state start {
p.extract(headers.rfFeatures);
transition select(headers.rfFeatures.phaseOffset) {
default : prot_ver;
}
}
state prot_ver {
p.extract(headers.frameCtrl);
transition select(headers.frameCtrl.protoVer) {
0x00 : mac80211;
default : reject;
}
}
state mac80211 {
p.extract(headers.mac80211);
transition select(headers.mac80211.Addr2) {
default : accept;
}
}
}
control swtch(inout Headers_t headers, in wp4_input wp4in, out wp4_output wp4out){
state_output_t state_output;
state_input_t state_input;
ssid_t ssid;
idok_t ID_ok;
action Drop_action() {
wp4out.output_action = wp4_action.DROP;
}
action Pass_action() {
wp4out.output_action = wp4_action.PASS;
}
action CPU_action() {
wp4out.output_action = wp4_action.CPU;
to_cpu(headers);
}
action ID_GOOD_action() {
wp4out.output_action = wp4_action.PASS;
ID_ok = 1;
}
action ID_BAD_action() {
wp4out.output_action = wp4_action.DROP;
ID_ok = 0;
}
table lookup_tbl {
key = {
headers.mac80211.Addr2 : class;
headers.frameCtrl.frameType : exact;
headers.frameCtrl.subType : exact;
headers.rfFeatures.rate_idx : exact;
headers.rfFeatures.rssi : min;
headers.rfFeatures.rssi : max;
headers.rfFeatures.phaseOffset : min;
headers.rfFeatures.phaseOffset : max;
headers.rfFeatures.pilotOffset : min;
headers.rfFeatures.pilotOffset : max;
headers.rfFeatures.magSq : min;
headers.rfFeatures.magSq : max;
}
actions = {
ID_BAD_action;
ID_GOOD_action;
}
default_action = ID_BAD_action;
}
146
apply {
state_input = state_read();
if (headers.frameCtrl.frameType == 0x0) // Management frame

{
if (headers.frameCtrl.subType == 0xB) state_output = state_update(AUTH); // Authentication frame.
if (headers.frameCtrl.subType == 0x0) state_output = state_update(ASSOC); // Assocition frame.
// De-authentication Frame
if (headers.frameCtrl.subType == 0xC)
{
lookup_tbl.apply();
// Deauthentication frame from a known device.

if (ID_ok == 1) state_output = state_update(DEAUTH + VALID_ID);
// Deauthentication frame from an unknown device.

if (ID_ok == 0)
{
state_output = state_update(DEAUTH);
Drop_action();
}
}
// Disassociation Frame
if (headers.frameCtrl.subType == 0xA)
{
lookup_tbl.apply();
// Disassociation frame from a known device.

if (ID_ok == 1) state_output = state_update(DISASSOC + VALID_ID);
// Disassociation frame from an unknown device.

if (ID_ok == 0)
{
state_output = state_update(DISASSOC);
Drop_action();
}
}
// Beacon Frame
if (headers.frameCtrl.subType == 0x8)
{
ssid = ssid_check(headers);
// Beacon frame with same SSID but different BSSID - Evil Twin!!
if (ssid == 1) state_output = state_update(BEACON);
// Beacon frame with different SSID - another WAP in range, ignore.

Pass_action();
}
}
if (headers.frameCtrl.frameType == 0x1) // Control frame.

{
Pass_action(); // Pass the frame.
}
if (headers.frameCtrl.frameType == 0x2 && state_input == 0x0) // Data frame.

{
CPU_action(); // Send to learning algorithm via CPU action.
state_output = state_update(DATA);
}
}
}
control deprs(in Headers_t headers, packet_out p, in wp4_output wp4out){

apply {
p.emit(headers.frameCtrl);
p.emit(headers.mac80211);
}
}
WP4Switch(prs(), swtch(), deprs())main;
147

Zanna

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Zanna

Uploaded by

Copyright:

Available Formats

A Multi-Layer Approach to Preventing Wireless

Network Impersonation Attacks

College of Science, Technology, Engineering and Maths

TABLE OF CONTENTS.................................................................................................................................... III

LIST OF FIGURES ...........................................................................................................................................VII

LIST OF TABLES .............................................................................................................................................. IX

CHAPTER 1. INTRODUCTION .........................................................................................................................3

1.1 BACKGROUND ....................................................................................................................................................3

CHAPTER 2. LITERATURE REVIEW ...........................................................................................................14

2.1 INTRODUCTION ................................................................................................................................................14

CHAPTER 3. AN SDN IEEE 802.11 FRAME PROCESSING PIPELINE ...................................................54

3.1 INTRODUCTION ................................................................................................................................................54

CHAPTER 4. INCORPORATING PHY LAYER FEATURES......................................................................71

4.1 INTRODUCTION ................................................................................................................................................71

5.1 INTRODUCTION ................................................................................................................................................85

CHAPTER 6. DEFENDING AGAINST IMPERSONATION ATTACKS ..................................................108

6.1 INTRODUCTION ..............................................................................................................................................108

CHAPTER 7. CONCLUSION AND FUTURE WORK .................................................................................120

7.1 CONCLUSION .................................................................................................................................................120

APPENDIX A – PUBLICATIONS ...................................................................................................................144

APPENDIX B – P4 SOURCE CODE ...............................................................................................................145

FIGURE 1.1: DEAUTHENTICATION ATTACK MESSAGE FLOW ...................................................................................................5

TABLE 1.1: LITERATURE SOURCES AND USAGE ....................................................................................................................9

ADC Analog to Digital Conversion

As with many technological innovations, advancements in miniaturisation, volume-based

1.2 Research Motivation

Attacker Client WAP

Figure 1.1: Deauthentication attack message flow

Figure 1.2: Various commercially available De-authenticator devices

1.3 Research Objectives

1.4 Research Hypothesis

1.5 Research Questions

1.6 Research Methodology

1.6.1 Literature Review Methodology

Table 1.1: Literature sources and usage

Figure 1.3: Publication year of cited literature

1.7 Investigation Methodology

1.7.1 Methodology for RQ1

1.7.3 Methodology for RQ3

1.7.4 Methodology for RQ4

1.8 Thesis Structure

Chapter 3 – SDN Frame Processing Pipeline

Chapter 4 – RF feature processing

Chapter 6 - Defending Against Denial-of-Service Attacks

Chapter 7 – Conclusion and Future Work

2.2 Accessing Wireless Data

2.2.1 Layer 1 (PHY)

High-end oscilloscopes continued to produce impressive identification accuracy at varying

The predominant digital baseband signal processing hardware design is implemented as

Figure 2.1: Interframe Spacing relationships

2.2.3 Layer 2 (MAC)

Though perhaps not as challenging as extracting RF information, gaining access to IEEE

Frame Duration Address 1 Address 2 Address 3 Seq Address 4 Frame FCS

Figure 2.2:Fields in an IEEE 802.11 Data Frame

Element ID Length Data

Figure 2.3: IEEE 802.11 Management Frame Information Element

2.2.4 Monitor Mode and Probes

An example of utilising monitor mode is capturing traffic as a precursor to a wireless attack.

2.3 Wireless Device Identification

Feature References Layer RF Domain RF State WAP

2.3.1 MAC Layer Device Identification

2.3.2 Radio Frequency Fingerprinting

Manufacturing RF components and equipment is a high-precision exercise requiring strictly

Figure 2.4: Symbolic RF Transmitter Chain representation