Securing the SDN Data Plane in Emerging Technology Domains: A Review

Abstract

Over the last decade, Software-Defined Networking (SDN) has garnered increasing research interest for networking and security. This interest stems from the programmability and dynamicity offered by SDN, as well as the growing importance of SDN as a foundational technology of future telecommunications networks and the greater Internet. However, research into SDN security has focused disproportionately on the security of the control plane, resulting in the relative trivialization of data plane security methods and a corresponding lack of appreciation of the data plane in SDN security discourse. To remedy this, this paper provides a comprehensive review of SDN data plane security research, classified into three primary research domains and several sub-domains. The three primary research domains are as follows: security capabilities within the data plane, security of the SDN infrastructure, and dynamic routing within the data plane. Our work resulted in the identification of specific strengths and weaknesses in existing research, as well as promising future directions, based on novelty and overlap with emerging technology domains. The most striking future directions are the use of hybrid SDN architectures leveraging a programmable data plane, SDN for heterogeneous network security, and the development of trust-based methods for SDN management and security, including trust-based routing.

1. Introduction

Software-Defined Networking (SDN) is an approach to computer networking that divorces the control and data planes of a system, investing network intelligence in a centralized controller [1]. The controller directly manages network infrastructure through the definition of traffic forwarding rules that are typically based on the logical connections between nodes and are enforced network wide. The logic that the controller applies in defining these rules is entirely configurable by the network operator, affording significant flexibility in how networking is performed.

The programmability and flexibility of SDN, combined with the global view of the controller, creates the opportunity for novel approaches to routing for enhanced network security. This is keenly reflected in the diversity and depth of academic discourse in the last decade, investigating various applications of SDN in cyber security. However, SDN security research to date has focused disproportionately on the security of the control plane, and specifically of controllers. This trend is reflective of the apparent criticality of the controller, as the failure or compromise of the controller may pose a threat to the entire system.

Yet this focus on the security of the control plane has resulted in the relative trivialization and a corresponding lack of awareness of research into SDN data plane security. This gap is further made problematic by growing data plane heterogeneity and functionality in modern networks. This is reflected by an increasing number of physical and softwarized communications media, devices, protocols, middleboxes, and middleware, and a clear move towards reintroducing statefulness and adding capability into the softwarized data plane. Together, these trends represent an increase in data plane complexity that poses new security and performance challenges that warrant greater investigation.

As a contribution to remedying the above issues, this paper provides an in-depth review of existing literature in SDN data plane security with a focus on emerging technologies. We highlight that there is already a body of high-quality research in SDN data plane security that exists and continues to grow. Additionally, we show that data plane security research has promising synergies with novel research in related technology domains, especially hybrid SDN, heterogeneous SDN (including Software Defined Wireless Networking (SDWN)), Internet of Things (IoT), and programmable data planes. These complementary technologies are foundational to the future of telecommunications and the Internet, adding substantial novelty and weight to our findings.

The structure of the paper is outlined in Figure 1 (below). Firstly, we describe the motivations for our research and the original contributions of this review. Then the paper provides a background to SDN and security for SDN as it is understood at the time of writing. This background includes a lightweight threat model for the SDN data plane to illustrate the current threat landscape. Our methodology is then outlined, including identification of the four research questions that we pose and answer in this work. Following this, an analysis of previous reviews on SDN security is provided, followed by a comprehensive literature review. Our review is structured according to the three primary domains of research that we identified: security capabilities within the data plane, security of the data plane infrastructure and dynamic routing within the data plane. These primary domains are then classified further into several sub-domains that relate to the specific themes identified in related security research. The paper then closes with a summary of our findings and discussion of directions for future research based on the findings of our review, with a brief conclusion.

2. Motivation and Contributions

This section addresses the motivations for this review and the contributions of this review to the state of the art for SDN security. Addressing our motivations highlights the relevance of the subject matter and the evident gaps in the discourse to date, which this review addresses. Furthermore, addressing our contributions identifies the specific original contributions that this review provides that are not addressed in the current discourse.

The motivation for this review stems from two important observations. The first observation is that the security of the SDN data plane has been the subject of diverse investigations for specific applications. These applications include novel security capabilities and the extension of SDN to emerging technology domains. The second observation is that existing SDN security research has failed to articulate the diversity of SDN data plane security methods and applications. These facts have resulted in the relative trivialization of SDN data plane security research, especially in contrast to SDN control plane security research. Importantly, to date there have been no comprehensive reviews of SDN data plane security, and therefore our review provides the first review of this type.

The contributions of this review are as follows:

• We provide the first in-depth review of existing literature in SDN data plane security, encompassing over 300 relevant and high-quality sources.
• We provide a detailed review of existing reviews, surveys, and equivalents into SDN security, classifying them based on the depth of their examination of SDN data plane security.
• We provide a classification of existing SDN data plane security research into three (3) primary research domains and eleven (11) sub-domains.
• For each domain and sub-domain, we identify research strengths and weaknesses, including gaps.
• We provide a holistic analysis of the body of research to identify promising future directions for research.
• Lastly, we identify and discuss the role of SDN in managing and securing the data planes of emerging technologies.

3. The Software-Defined Networking Data Plane

3.1. Software-Defined Networking

SDN is an approach to computer networking that separates the control and data planes of networks. By separating these planes and introducing a centralized controller, SDN achieves greater programmability and dynamism than traditional networks. Figure 2 shows the principle architectural planes of an SDN and its main interfaces. The operation of SDN is contingent on three elements: a controller, SDN infrastructure, and supported endpoints (e.g., servers, hosts). The former is the chief element of the SDN control plane. It orchestrates the operation of networks and network segments through interaction with the SDN infrastructure resident within the data plane. All forwarding rules in an SDN are defined by the controller, or in some instances by a network operator directly (e.g., pre-configured rules). The logic that the controller applies in this process is fully programmable by the network operator. This is performed using two interfaces: a Northbound Interface (NBI) connecting applications and supporting modules to the controller, and a Southbound Interface (SBI) connecting the controller to the SDN-enabled infrastructure by means of communication protocols such as OpenFlow [2,3]. This programmability (over the NBI) and subsequent configurability (over the SBI) is essential to the flexibility and decision-making power of SDN.

The SDN-enabled infrastructure refers to the switches and other network devices enforcing the forwarding rules defined by the controller. These elements are predominantly reserved for the movement of data around the network and hence they exist within (and enable) the data plane. This separation of functions is critical to the operation of SDN and enables sophisticated analysis and management of network traffic at the controller and the data plane infrastructure.

The final elements in an SDN are the endpoints, which may include servers, hosts, and any network node subject to the orchestration of the controller via forwarding rules at their supporting infrastructure (e.g., the switch an endpoint is associated with). For the purposes of this paper, endpoints and their links are incorporated into the data plane.

This model of SDN and the associated division of functions have both largely remained unchallenged in the literature, with the balance of new research focusing on evolution through innovative application (e.g., in network security and performance), rather than revolution of the model itself. The most fundamental changes to this model have emerged through data plane statefulness and programmability, as evidenced in projects such as the Programming Protocol-Independent Packet Processor (P4) language (see Bosshart et al. [4] for the original proposal and P4 Language Consortium [5] for the current project).

3.2. Data Plane Threats

Although the first specification for SDN stems from more than 15 years ago, the security threats to it are still being identified, mitigated, and discussed. Therefore, a current threat model for the SDN data plane is required to provide the necessary context for this review. In this context, a threat model is a generalized description of the types of threats that exist for current, OpenFlow-based SDN. This model can be extended to any system utilizing SDN infrastructure and is therefore also applicable to both hybrid networks (employing both SDN and traditional networking) and heterogeneous SDN in a shared data plane.

Table 1. Threats to the SDN data plane [6,7].

Plane Component	Threats	Mitigations
Southbound Interface	Side-channel vulnerabilities	Monitoring and logging
	Data spill (data leak)	Monitoring and logging; data loss prevention; traffic filtering (firewall, intrusion detection, and prevention)
	Malicious software (malware)	Monitoring and logging
	Eavesdropping	Traffic encryption; secure routing
	Man-in-the-middle	Traffic encryption; secure routing
	Replay attacks	Session and token management; monitoring and logging; traffic filtering (firewall, intrusion detection, and prevention)
Switch Software	Side-channel vulnerabilities	Monitoring and logging
	Data spill (data leak)	Secure programming; patching; adherence to standards; monitoring and logging
	Malicious software (malware)	Monitoring and logging
Switch Firmware	Side-channel vulnerabilities	Monitoring and logging
	Malicious software (malware)	Forwarding anomaly detection; exclusionary routing for malicious or compromised nodes
Switches	Malicious infrastructure	Forwarding anomaly detection; exclusionary routing for malicious or compromised nodes; authentication; network access control
	Side-channel vulnerabilities	Monitoring and logging
	Poisoned forwarding rules	Forwarding rule auditing; forwarding anomaly detection
	Denial-of-service/Distributed denial-of-service	Exclusionary routing for malicious or compromised nodes; traffic filtering (firewall, intrusion detection, and prevention)
Communications Links	Man-in-the-middle	Traffic encryption; forwarding anomaly detection; secure routing
	Eavesdropping	Traffic encryption; secure routing
	Replay attacks	Session and token management; monitoring and logging; traffic filtering (firewall, intrusion detection, and prevention)
Endpoints	Malicious infrastructure	Forwarding anomaly detection; exclusionary routing for malicious or compromised nodes; authentication; network access control
	Denial-of-service/Distributed denial-of-service	Exclusionary routing for malicious or compromised nodes; traffic filtering (firewall, intrusion detection, and prevention)

summarizes the threats to OpenFlow-based SDN that are currently known to exist for the components of the data plane, including switches, switch firmware, switch software, endpoints, and communication links. This summary is based on the work described in two seminal papers (see Rahouti et al. [6], Gao et al. [7]). It should be noted that these papers do not provide any consideration to differences in threats given the physical medium for communications links, for instance regarding wired, wireless, or heterogeneous SDN. We believe that this is largely due to current implementations of SDN using only wired connections, and security researchers typically being computer scientists rather than network engineers.

4. Methodology

4.1. Research Questions

Four Research Questions (RQs) have been defined to support the structure of this review and the discussion provided. The RQs are the specific questions this review addresses, and they support identification of the relative strengths and weaknesses of existing research, as well as the opportunities for future research. The RQs of this review are as follows:

• RQ1. How may existing research into the security of SDN data planes be classified?
• RQ2. Based on this classification, what are the strengths of this research?
• RQ3. Based on this classification, what are the weaknesses of this research?
• RQ4. Based on the identified strengths and weaknesses, what are promising future directions for research?

For convenience, the literature review (Section 5, Section 6, Section 7 and Section 8) is structured according to the classification framework we have developed for answering RQ1. Additionally, the research strengths (RQ2) and weaknesses (RQ3) are summarized at the end of each section of the review. For numbering the research strengths and weaknesses we use the notation RSTR and RWKN, respectively.

4.2. Paper Selection

Relevant literature was identified using a keyword search performed on online journal databases. The process for paper selection is summarized in Figure 3 below. As shown in Figure 3, databases and keywords were pre-selected. The chosen databases were IEEE Xplore, ACM Digital Library, and the academic search engine Google Scholar. A keyword search was used to identify relevant papers based on permutations of three keywords: SDN, security, and data plane (e.g., SDN security, SDN data plane, data plane security). The papers returned by this keyword search were then filtered based on their apparent relevance to the subject matter of this paper. Finally, the selected papers were reviewed in detail, and their references (reference lists) were also examined to identify other relevant papers.

As per RQ1, the review of the selected papers included a qualitative analysis to support classification of the papers based on their research themes. This classification yielded the three primary research domains that are employed in this paper: security capabilities within the data plane (Section 6), security of the data plane infrastructure (Section 7), and dynamic routing within the data plane (Section 8). Each of these domains is further classified into sub-domains that closely reflect the research themes of the original reviewed papers and seek to further classify them according to their applications. The domains and sub-domains will be discussed in further detail in the next section, which considers the structure of the review.

This paper provides the first comprehensive review of SDN data plane security research to date. To achieve this, the paper first considers existing relevant reviews. The relevance of reviews was determined based on three factors: their focus on SDN security, how the authors chose to characterize their research, and a determination of the degree to which the research addresses SDN data plane security. Following a survey of previous reviews, the paper will then examine research according to the three research domains identified, as shown in Figure 4. Each domain is further decomposed into sub-domains that classify the research based on their specific foci. In summary, the primary research domains and sub-domains provide the classification framework per RQ1.

5. Previous Reviews

5.1. Overview

The historical bias of SDN security research towards security of the control plane has resulted in the inadvertent neglect of novel security research for (and using) the SDN data plane. In this section, existing relevant reviews are identified and discussed. As such, we demonstrate that a comprehensive view of data plane security as we are providing in this paper is novel.

Table 2. Previous reviews.

Reference	Year	Topic	Data Plane Security
[8]	2025	Data plane security	●
[9]	2017	Stateful data plane security	◉
[10]	2020	Stateful data plane security	◉
[11]	2021	Stateful data plane	◉
[12]	2021	P4 security	◉
[13]	2022	P4 security	◉
[14]	2023	P4	◉
[15]	2019	Programmable data planes	◉
[16]	2021	Programmable data planes	◉
[17]	2021	P4 switches	◉
[18]	2023	P4 applications	○
[19,20,21]	2015	SDN security	◉
[22,23]	2016	SDN security	◉
[24,25]	2019	SDN security	◉
[26,27]	2020	SDN security	◉
[28]	2021	SDN security	◉
[29]	2021	SDN security	◉
[6]	2022	SDN security	◉
[30]	2022	SDN security	◉
[31]	2024	SDN security	◉
[32]	2023	SDN security	◉
[33]	2024	SDN security	◉
[34]	2023	SDN security and privacy	◉
[35]	2017	SDN security architecture	◉
[36]	2018	SDN security architecture	◉
[37]	2020	SDN security architecture	◉
[38]	2020	SDN security architecture	◉
[39]	2013	SDN	◉
[40,41]	2014	SDN	◉
[42,43]	2015	SDN	◉
[44]	2016	SDN	◉
[45]	2020	SDN for resilient networking	○
[46]	2022	SDN for resilient networking	○
[47]	2017	Heterogeneous SDN	◉
[48]	2020	Heterogeneous SDN	○
[49]	2019	ML applications in SDN	○
[50]	2019	ML applications in SDN	◉
[51]	2023	ML applications in SDN	◉
[52]	2025	AI, ML and blockchain in SDN	○
[53]	2024	AI for programmable data planes	◉
[54]	2015	SDN-NFV	◉
[55,56]	2019	SDN-NFV	◉
[57]	2020	MTD	◉
[58]	2015	Programmable networks	◉
[59]	2022	Denial-of-service attacks	◉
[60]	2023	In-band control for SDN	◉

● Addresses data plane security. ◉ Partially addresses data plane security. ○ Does not address data plane security.

summarizes existing relevant reviews and equivalents we have surveyed. Reviews are ordered firstly by the topic of their review (Topic), which is our categorization of the primary research domain of the paper and may vary to the self-description provided by the authors. Secondly, reviews are ordered by year of publication (Year). For each review, the degree to which they have addressed data plane security is identified. Papers that specifically address data plane security are identified with a full circle (●). Papers that partially or briefly address data plane security are identified with a partially filled circle (◉). Lastly, papers that do not meaningfully address data plane security are identified with an empty circle (○). The latter are included to highlight research gaps, especially in otherwise relevant reviews that address SDN, programmable data planes, and related technologies.

5.2. Data Plane Security

The authors of [8] present the first attempt at providing a general review of SDN data plane security. They appropriately characterize the diversity of data plane research and consider threats and attacks on the softwarized data plane, spanning SDN, stateful data plane, and programmable data plane. Their review is structured following the STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege) threat model and consider Confidentiality, Integrity, and Availability (CIA) and Authorization, Authentication, and Accountability (AAA) as attributes of the data plane which are impacted by attacks. This approach is limiting, as STRIDE is a reductive threat model and this results in a narrow review, with notable gaps. Specifically, from our understanding of the literature, we believe that the proposed future research directions in [8] have already been realized.

5.3. Stateful Data Plane

Other authors have examined the closely related topic of stateful data plane. Stateful data plane refers to the introduction of state awareness and broadly speaking, intelligence, into the data plane. This contrasts with the classical view of SDN, which employs a stateless data plane. Refs. [9,10] provide detailed reviews of stateful data plane security, with the authors in [9] contending that stateful data plane does not contradict the principles of SDN and is complementary from both a performance and security perspective. Finally, ref. [11] provides a recent and detailed review of stateful data plane. They consider the introduction of security capabilities into the data plane to both mitigate SDN security issues and extend the functionality of the SDN data plane.

Relatedly, in [12,13,14,15,16,17,18,53] the authors provide reviews of the security applications of P4. As a programmable data plane technology, P4 offers flexibility in the definition and implementation of data plane security functions. Ref. [12] provides a detailed review of security applications published to date, focusing on access control, privacy and encryption, availability, and integrated defense. A comparable review is provided in [13], with the addition of a STRIDE-based threat model. Ref. [14] provides a review on the evolution and challenges of both SDN and P4, identifying a range of security-specific challenges, including a lack of physical evaluation in the literature, low-rate attacks, and hybrid SDN architectures utilizing programmable data planes (see Figure 5). The latter is topical and will be revisited in this review. Refs. [15,16] provide reviews of programmable data planes generally. Ref. [15] considers performance, QoS, monitoring, reliability, and security. Ref. [16] examines new architectures for programmable data planes. Ref. [17] provides a detailed review of P4-based programmable data planes, focusing on programmable switches. Lastly, ref. [18] considers applications of P4, spanning networking and, briefly, security.

5.4. SDN Security

A range of reviews exist for cross-plane SDN security. Ref. [19] provides an early review of SDN security, focusing on OpenFlow. They identify several data plane threats and, interestingly, they characterize controller hijacking and controller compromise as data plane threats. Another early security examination of SDN is provided in [20]. They examine the advantages and disadvantages of SDN for security, identifying both threats and countermeasures, including for the data plane. A similar review is provided in [21], incorporating a STRIDE-based threat modeling exercise and identification of threats, attacks, and controls. Ref. [22] provides a general review of SDN security from an academic and industry perspective, identifying a range of potential attacks on SDNs and their mitigations. A narrow review is provided in [23], focusing on DDoS attacks in SDN. Another brief review of SDN security is provided in [24], summarizing critical SDN security issues and approaches to their mitigation.

Other general reviews are provided in [25,26,27,28,29]. Ref. [25] provides a general SDN security review, notably including significant consideration of SDWN. Ref. [26] provides a review of methods for the management, performance, and security of SDN flow tables in OpenFlow, especially for IoT. Ref. [27] is a general review of SDN security, focusing on both the control and data planes, incorporating a focus on SDN-based Network Function Virtualization (SDN-NFV). Another general review is provided in [28], with a useful view on threats to the SBI. A broad review is provided in [29], benefiting from a focus on both stateless and stateful data planes.

Recent reviews of SDN security are provided in [6,30,31,32,33,34]. Ref. [6] provides a detailed review of SDN security with a focus on addressing challenges in securing SDN communications and solutions. Ref. [30] examines security issues in SDN, considering the attack surface of the SDN architecture. Ref. [31] examines traditional security approaches, artificial intelligence (AI)-based approaches, and Moving Target Defense (MTD)-based approaches. Ref. [32] provides a review of the security of the SDN control plane, with a useful examination of threats to the SBI. Ref. [33] provides a brief review of SDN security, although they take a narrow view of the data plane. Lastly, ref. [34] provides a general review of security and privacy issues in SDN, the latter being comparably niche.

The flexible architecture of SDN has also attracted significant interest. Refs. [35,36,37,38] all provide reviews of SDN architecture. Refs. [35,36] examine cross-plane threats in SDN and consider how SDN may be architected to address those threats. Refs. [37,38] provide a limited view of security in the context of broader reviews of SDN architecture. All four reviews are apparently focused more on the control plane than the data plane, with relatively few data plane threats considered.

5.5. SDN

General reviews on SDN are provided in [39,40,41,42,43,44,45,46]. Ref. [39] focuses on SDN for carrier grade networking, considering network performance, scalability, interoperability, and security. Ref. [40] examines the history of programmable networking (up to 2014), with a focus on SDN and modest consideration of security. Ref. [41] provides an early and detailed review of SDN. A similar review is provided in [42], with additional detail on data plane devices, including switch types, open network hardware, and implementation of SDN on vendor switches. In contrast, ref. [43] does not consider the data plane in detail, despite following a ‘bottom up’ structure. Ref. [44] examines data planes and data plane security in detail, considering in-band and out-of-band SBI communication, network resilience, and a range of security threats. Lastly, refs. [45,46] provide reviews for SDN, focusing on networking and resilience.

As highlighted already, heterogeneous SDN is a topic of growing interest. A data plane that is some combination of wired and wireless communications is inherently more complex, presenting a broader attack surface and exhibiting a greater range of vulnerabilities (see Figure 6). As discussed already, ref. [26] examines the performance and security challenges of OpenFlow-based IoT. Ref. [47] presents a domain-specific review for SDN in Wireless Sensor Networking (WSN). Lastly, ref. [48] examines SDN applications in IoT; however, they also incorporate Edge Computing (EC), describing this new domain as SDIoT-Edge.

The programmability of SDN also provides the opportunity for greater application plane support in networking and security. Ref. [49] examines the network and security applications of ML in SDN, especially the detection and prevention of attacks on heterogeneous networks. A comparable review on ML applications in SDN is provided in [50]. Despite both reviews being relatively recent (2019), they do not examine stateful data planes or P4. Ref. [51] examines deep learning applications for SDN security, including a threat model and consideration of various data plane threats. Ref. [52] provides a curious review spanning traditional, AI/ML, and blockchain-based approaches to SDN security, although the breadth of the review limits insights for the SDN data plane. Lastly, ref. [53] provides an overview of AI-based security solutions in programmable networks, including IoT.

Finally, several other relevant reviews have been published, with varying examinations of data plane security. Refs. [54,55,56] all consider SDN-NFV. Ref. [54] provides a general review of SDN-NFV, primarily from a service and performance perspective. Refs. [55,56] consider placement of Virtual Network Functions (VNFs) in SDN, with security policies acting as inputs for optimal VNF placement. Ref. [57] also considers the application of NFV for security SDN, focused on MTD. Ref. [58] provides a broad review of trends in programmable networking and considers applications of programmable networking in underrepresented domains, such as Operational Technology (OT). Ref. [59] provides a detailed review and classification approach for Denial-of-Service (DoS) and Distributed DoS (DDoS), spanning traditional networks, SDN, and virtual networks (predominantly NFV and SDN-NFV). Ref. [60] provides a review of a relatively niche domain: in-band control for SDN. In-band control refers to SDN deployment where the control and data planes share the same physical network.

5.6. Summary

In summary, it is evident that no comprehensive reviews of SDN data plane security have been conducted to date. Existing reviews have tended to be domain-specific (e.g., stateful data planes), evidenced notable gaps (as per

Table 3. Research strengths and weaknesses of existing reviews.

Identifier	Summary	References
RSTR-1	P4 security applications have been subject to significant investigation.	[12,13,14,15,16,17,18,53]
RSTR-2	Cross-plane security for SDN has been subject to significant investigation.	[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,61]
RWKN-1	No comprehensive review exists for SDN data plane security research.	[8]
RWKN-2	Security of the P4 architecture is underinvestigated.	[9,10]
RWKN-3	Heterogeneous SDN is underinvestigated.	[26,47,48]

), or generalized to SDN holistically, which has resulted in a bias towards the security of the control plane, as previously noted.

Our review addresses the need for a comprehensive review of SDN data plane security. Per RQ1, we achieve this by classifying existing research into three research domains: security capabilities within the data plane (Section 6), security of the data plane infrastructure (Section 7), and dynamic routing within the data plane (Section 8). These domains are intentionally broad to provide an encompassing and accurate view of the current state of the art for SDN data plane security. The domains are further divided into sub-domains which represent the specific themes in the discourse and provide the opportunity for detailed examination of reviewed papers. In these respects, our review provides a detailed view of the security of the SDN data plane that has not previously existed.

6. Security Capabilities Within the Data Plane

6.1. Overview

The first of the three research domains to be discussed is security capabilities within the data plane. This domain relates to the introduction of new security capabilities to the SDN data plane that are enabled by the SDN construct or which build upon the capabilities offered by SDN; for example, as implemented in OpenFlow. This domain is further classified into three sub-domains that describe intra-data plane capabilities that have been applied to data plane security. The three sub-domains are: programmable data plane (including P4), NFV, and traditional security controls, as implemented in the softwarized data plane (i.e., SDN).

The classical SDN construct as defined in OpenFlow offers a stateless data plane. A stateless data plane lacks intelligence, lacks decision-making ability, and is limited in capability to a small set of forwarding functions; hence, it is sometimes referred to as the forwarding plane. Early in the history of OpenFlow, researchers recognized that introducing a higher degree of statefulness into the SDN data plane had potential for networking and security applications, hence the emergence of stateful data planes. Over time, the concept of stateful data planes has been subsumed into programmable data planes, encompassing the addition of greater capability into the data plane, including, but not limited to, statefulness. For convenience, the remainder of this review will use the more general term programmable data plane.

6.2. Programmable Data Plane

As noted, programmable data planes have already been the subject of substantial research interest and have previously been reviewed in [9,10,11] and to a lesser extent in [29,31]. Consistent themes emerge across these reviews. Firstly, there is a trend towards statefulness, intelligence, and greater programmability within the SDN data plane. These enhanced capabilities support reduction in the computational burden on the controller and reduce the performance overhead of SDN by reducing the north–south communication over the SBI. Secondly, greater statefulness, intelligence, and programmability lend themselves to the implementation of novel security capabilities intra-data plane. In this section, existing programmable data plane implementations are reviewed, and security applications of programmable data planes are also examined.

In

Table 4. Programmable data plane implementations and applications.

Reference	Year	Implementation	Application
[4]	2014	P4	Novel language and compiler
[62]	2014	FAST	Novel architecture
[63]	2014	OpenState (OpenFlow)	Novel architecture
[64]	2017	SDPA (OpenFlow)	Novel architecture
[65,66,67,68,69,70,71,72]	2020	P4	DoS mitigation
[73,74]	2021	P4	DoS mitigation
[75,76]	2019	P4	DoS mitigation
[77]	2021	P4	DoS mitigation
[78]	2022	P4	DoS mitigation
[79]	2017	P4	Heavy-hitter detection
[80]	2018	P4	Telephony DoS mitigation
[81]	2019	P4	Telephony DoS mitigation
[82]	2019	P4	ML-based DoS mitigation
[83]	2021	P4	ML-based DoS mitigation
[84,85]	2020	P4	ML-based DoS mitigation
[86]	2023	P4	ML-based DoS mitigation
[87]	2018	OpenFlow, P4	Intrusion detection
[88]	2019	P4	Intrusion detection
[89]	2021	P4	Intrusion detection
[90]	2023	P4	Intrusion detection
[91]	2024	P4	Intrusion detection
[92]	2021	P4	Anomaly detection
[93]	2020	P4	ML-based intrusion detection
[94]	2021	P4	ML-based intrusion detection
[95,96]	2024	P4	ML-based intrusion detection
[97,98]	2025	P4	ML-based intrusion detection
[99]	2024	OpenFlow	ML-based network monitoring
[100]	2024	P4	ML-based traffic classification
[101]	2017	P4	Deep packet inspection
[102]	2020	P4	Deep packet inspection
[103]	2022	P4	Deep packet inspection
[104]	2023	P4	Deep packet inspection
[105]	2016	P4	Firewall
[106]	2018	Novel (CoFilter)	Packet filtering
[107]	2018	P4	Firewall
[108]	2019	P4	5G firewall
[109]	2017	OpenFlow, P4	Anti-spoofing
[110,111]	2020	P4	Anti-spoofing
[112]	2019	P4	Anti-spoofing
[113]	2019	P4	Anti-eavesdropping
[114]	2019	OpenFlow, P4	Anti-eavesdropping
[115,116]	2020	P4	Anti-eavesdropping
[117]	2021	P4	Anti-eavesdropping
[118]	2018	P4	Topology obfuscation
[119,120]	2019	P4	Network anonymity
[121]	2019	P4	Data plane authentication
[122]	2021	P4	Data plane edge authentication
[123]	2020	P4	Data plane authentication
[124]	2020	OpenFlow, P4	Encryption
[125]	2020	P4	Encryption
[126]	2021	P4	Encryption
[127]	2020	P4	MACsec
[128]	2020	P4	IPsec
[129]	2019	P4	Cryptographic hashing
[130,131,132,133]	2019	P4	Network defense
[134]	2023	P4	Network defense
[135]	2022	P4	Network defense
[136,137,138]	2023	P4	Network defense
[139]	2019	P4	Edge network defense
[140]	2018	OpenFlow, P4	Security framework
[141]	2018	P4	Application layer security
[142]	2020	P4	BYOD
[143]	2020	P4	P4 performance
[144]	2020	P4	Covert channel defense
[145]	2020	P4	Explicit congestion notification
[146]	2021	P4	ML-based network defense
[147]	2022	P4	OS fingerprinting
[148]	2020	P4	Blockchain
[149]	2021	OpenFlow, P4	Distributed network functions

, we summarize research investigating implementations and applications of programmable data planes for security. For papers reviewed, their application (Application), year of publication (Year), and technology of implementation (Implementation) are noted. Papers are ordered firstly by Application and secondly by Year.

In the literature, four programmable data plane implementations are commonly referred to: FAST [62], OpenState [63], the Stateful Data Plane Architecture (SDPA) [64], and P4 [4]. Each implementation performs state definition, state storage, and state transitions (including removal) differently.

FAST and OpenState both utilize hash tables for state storage, although their methods of state transition and state removal vary. SDPA utilizes a set of three tables: a state table, a state transition table, and an action table, supported by a Forwarding Processor (FP). In SDPA, the FP maintains the state of flows and processes packets according to knowledge of current states and state transition policies defined by the network operator.

In contrast to the others, P4 is a high-level programming language for configuring data plane devices and is target-independent, requiring no knowledge of the forwarding device or its capabilities. P4 provides a flexible parser, match-action pipeline, and deparser for granularly configuring how data plane devices process packets (see Figure 7). Of the four programmable data plane implementations discussed, P4 has held the most enduring interest in programmable network security research and in programmable networking generally. However, none of the four implementations were designed with security as an explicit objective, and it has largely fallen to other researchers to build security applications atop the flexible data plane provided by these implementations.

P4 has attracted significant research interest for DoS/DDoS mitigation due to the programmability and performance it supports. Importantly, in the context of DoS/DDoS attacks, P4 switches support line rate packet processing, meaning it is feasible for a P4 switch to detect and block network attacks with manageable impact to benign network traffic. This presents the opportunity to perform DoS/DDoS defense in-network and in a distributed fashion. P4-based DoS/DDoS mitigation is examined in [65,66,67,68,69,70,71,72,73,74,75,76,77]. In [65,66], the authors propose three methods for P4-based mitigation of Transmission Control Protocol (TCP) Synchronization (SYN) floods in programmable data planes. Their methods are SYN cookies, SYN authentication, and SYN proxying. A similar solution is provided in [67], with added defense against Address Resolution Protocol (ARP) spoofing.

Moving away from TCP, ref. [68] proposes a DoS/DDoS mitigation for User Datagram Protocol (UDP) attacks, specifically Amplified Reflection DDoS (AR-DDoS) attacks. Ref. [69] present a unified DoS/DDoS attack detection scheme for TCP, UDP, and Internet Control Message Protocol (ICMP). Their solution provides real-time mitigation at line rate, QoS, and efficient flow table and control channel (SBI) utilization. A similar approach is presented in [70]. In contrast, ref. [71] presents a novel DDoS attack detection scheme based on P4-enabled SmartNICs (programmable NICs). Their scheme uses a cross-plane architecture, with detection, metadata, and feature extraction in the data plane.

Refs. [72,73] present solutions for mitigating volumetric DDoS attacks. Ref. [72] provides primitives that can be customized for the target network and extended to include new defenses. As per [72], the solution proposed in [73] is resource efficient and modular, utilizing mitigation building blocks and a flexible API to support defense strategies in the data plane. A comparable solution is proposed in [74], although focused on Link Flooding Attacks (LFAs).

A novel hybrid architecture is proposed in [75] for mitigating amplification DDoS attacks. Their architecture utilizes a software controller that provides instructions to data plane devices, and employs FPGAs for accelerated processing. The management of a programmable data plane by a centralized controller is curiously underinvestigated in the literature, but as demonstrated in [75], it can be employed to successfully manage a distributed security solution built atop a programmable data plane. A counterpoint is provided in [76], in which the authors provide a detailed analysis on DoS/DDoS mitigation using P4. They are critical of the long control loop of OpenFlow, citing the need for a strict time budget and switch memory efficiency in mitigating such attacks.

Ref. [77] presents a novel sketch data structure for programmable switches and implements it as part of an in-network DDoS victim identification strategy. Ref. [78] explores DDoS attack detection in programmable data planes. They present two strategies for flow cardinality and normalized network traffic entropy estimation implemented on P4 switches. Finally, ref. [79] examines the related issue of heavy-hitter detection. They identify several issues in managing heavy hitters and propose a heavy-hitter mitigation algorithm for P4 switches.

The programmable data plane DoS/DDoS research discussed thus far has considered IP networks generally. However, these attacks are often domain-specific, taking advantage of protocol or operational weaknesses to degrade availability. A stark example of this is Telephony DoS (TDoS) and Telephony DDoS (TDDoS). In [80,81], the authors examine P4-based mitigation of Session Initialization Protocol (SIP) INVITE flooding, a telephony-specific DoS/DDoS attack. Their solution is proposed in [80] and built upon in [81], providing in-network mitigation of SIP INVITE floods using P4 switches and centrally managed by a software controller added in [81].

As discussed, programmable networking enables the integration of greater support from the application plane than is possible in a traditional network [49,50]. This holds true in programmable data planes, and authors have proposed various ML-based security applications, including for anti-DoS/DDoS. Refs. [82,83] examine ML-based pushback methods for DDoS mitigation. Pushback describes a method for throttling and filtering malicious traffic during a DDoS attack as close as possible to the source of the attack. Reference [84] proposes a DoS detection scheme that extracts relevant features from flow tables and uses a Back Propagation (BP) neural network to construct a classifier.

Conversely, ref. [85] provides a broader analysis and considers three scenarios: packet mirroring, header mirroring, and P4 metadata extraction, comparing the performance of different ML algorithms across the scenarios. Lastly, ref. [86] proposes a solution for detecting and defending against attacks on the programmable data plane, using attention mechanisms to enhance traffic processing and suspicious lists for source addresses of potential attackers. The processed data is then fed into a Convolutional Neural Network (CNN) to determine whether it constitutes attack traffic.

While DoS/DDoS attack identification and mitigation has attracted the most significant interest in the literature, authors have proposed general purpose Intrusion Detection Systems (IDS) and Intrusion Detection and Prevention Systems (IDPS) based on programmable data planes.

Ref. [87] proposes a hybrid IDS architecture for Industrial Control Systems (ICS) based on OpenFlow and P4. Their architecture is hybrid, using a P4 data plane and an SDN controller for orchestration. Ref. [88] presents a stateful and stateless IDPS based on a P4 data plane and the open source IDPS Snort. Ref. [89] proposes an IDS for detecting intra-data plane reconnaissance by attackers. Their solution takes inspiration from the algorithm proposed in [79] for improved hash tables and lookups. Ref. [90] implements a cross-plane solution for collaborative intrusion detection, running a classification model within the programmable data plane on P4 switches and using the P4Runtime API for integration to the control plane. Ref. [91] examines the problem of balancing network data compression and granular packet analysis for intrusion detection, proposing a P4-based packet-level feature extraction and pre-processing solution. Ref. [92] presents an anomaly detection method, implemented in P4. Their solution establishes a network baseline and periodically assesses actual behavior versus the baseline, raising alerts for violations.

ML-based IDS implementations using P4 switches are provided in [93,94]. Ref. [92] proposes the use of Binarized Neural Networks (BNN) for traffic classification and defense of the network edge, while ref. [94] proposes offloading of ML algorithms to the data plane to support different stages of intrusion detection (see Figure 8). In [95,96], the authors propose an AI/ML-based IDS using P4 which supports limited autonomy of network devices and both in-band and out-of-band analysis, using ML modules for confident classification. Refs. [97,98] examine intrusion detection and prevention in the programmable data plane for 6G. Ref. [97] highlights the ultra-low latency, high bandwidth, and dense device connectivity requirements of 6G, proposing a ML framework for real time threat detection and mitigation built on a hybrid SDN architecture with a P4 data plane. Ref. [98] proposes a distributed IDPS paradigm based on ML and implemented in a programmable data plane. Ref. [99] proposes a distributed monitoring solution for the programmable data plane. Their solution extracts statistics from the data plane and performs ML-based monitoring and classification. Lastly, ref. [100] examines the problem of traffic classification for encrypted traffic and implements a two-phase traffic classification scheme using a combination of ML models.

Complementary to the security capabilities discussed so far, authors have also sought to implement DPI in the programmable data plane, taking advantage of the ability of programmable data plane technologies to perform granular operations at line rate. Ref. [101] examines traffic offloading, classification, and DPI using programmable data plane. Ref. [102] introduces a method for performing efficient regular expression matching on payloads using network processors. Their solution provides flow-based DPI and packet accounting. Ref. [103] provides a P4-based DPI solution that extracts domain information from Domain Name System (DNS) queries and applies security policies on domains. Lastly, ref. [104] provides a novel approach to DPI, implementing URL filtering in P4 using a packet recirculation process.

Along with IDPS, authors have implemented packet filtering in the programmable data plane for both stateless and stateful packet filtering [105,106,107,108]. Ref. [105] provides an early investigation of security middleware programmed using P4. The authors propose a Layer 3 firewall, implemented in P4. The authors in [106] propose a novel stateful packet filter for efficient packet filtering of large flows and hash-based. Ref. [107] proposes a P4-based firewall that utilizes SDN for management, including firewall placement. Finally, ref. [108] proposes a firewall for 5G based on P4 and NetFPGA hardware.

Authors have also proposed proactive defensive measures using programmable data planes. Refs. [109,110,111,112] examine anti-spoofing and implementation of Anti-Spoofing Mechanisms (ASMs) using OpenFlow and P4. Ref. [109] proposes a hybrid SDN architecture for anti-spoofing and anti-DoS/DDoS. Ref. [110] provides a comparative analysis of six IP address ASMs and implements them using P4 on NetFPGA SUME hardware Network Interface Cards (NICs). A novel ASM is proposed in [111], although it is explicitly focused on supplementing the weaknesses of the Duplicate Address Detection (DAD) protocol, part of the IPv6 Neighbor Discovery Protocol (NDP). Ref. [112] proposes a novel method based on hop count filtering using P4.

Anti-eavesdropping is investigated in [113,114,115,116]. Eavesdropping is a significant data plane threat that is traditionally mitigated through encryption. However, a programmable data plane offers the opportunity for adaptive methods in mitigating eavesdropping. Ref. [113] examines IP address obfuscation for anti-eavesdropping in a shared data plane, implemented in P4. Another anti-eavesdropping approach is provided in [114], utilizing the long prefix of IPv6 and encryption of the originating IPv4 address, implemented in P4 with an SDN controller for orchestration. Ref. [115] proposes an anti-eavesdropping method for the QUIC protocol, implemented in P4. QUIC is an encrypted-by-default transport protocol developed by Google and standardized in [150]. Lastly, refs. [116,117] implement eavesdropping protection based on multi-path forwarding, encryption, of header metadata and existing encryption methods.

Another proactive technique that has been implemented using programmable data planes is topology obfuscation (network anonymity). Ref. [118] presents a P4-based topology obfuscation method designed to mitigate DoS/DDoS attacks and specifically LFAs. They frame topology obfuscation as an optimization problem, allowing a tradeoff between security and usability (of the network). Ref. [119] provides P4-based network anonymity for in-network defense and eavesdropping protection based on source address transformation and path confusion using hop-by-hop routing.

Another network anonymity method is provided in [120], although in contrast to [119] their solution is policy-driven and provides an abstraction that the network operator uses to define anonymity policies.

The programmable data plane has also seen investigation of implementation of authentication methods, predominantly for network access control. Ref. [121] implements port knocking in P4. Port knocking refers to sending messages to a pre-agreed sequence of ports in order to authenticate. They built upon their work in [122], investigating both port knocking and the use of a One-Time Password (OTP) for lightweight edge authentication, implemented in P4. Ref. [123] also investigates port knocking based on P4, although their solution is hybrid and recruits the support of a Python 3-based controller.

Layer 2–4 encryption for the programmable data plane has seen some investigation in the literature. Ref. [124] proposes a flexible encryption system for reliable transmission in the data plane. Their solution employs a hybrid architecture, with an SDN controller for policy definition and network management and a P4 data plane. Ref. [125] also implements encryption in P4 switches, although they focus exclusively on the Advanced Encryption Standard (AES) and seek to provide security for in-network applications, which they argue is a weakness in earlier proposals. Ref. [126] implements Diffie–Hellman (DH) and AES on P4 switches to establish secure data plane communications.

Refs. [127,128] present related research from the same authors: the implementation of Media Access Control (MAC) Security (MACsec) in P4 and IP Security (IPsec) in P4, respectively. In both papers, the authors demonstrate the flexibility of P4 for supporting the extension of existing security protocols in a programmable data plane. Finally, ref. [129] implements cryptographic hashing using P4, proposing an extension of the P4 Portable Switch Architecture for three different data plane target platforms (CPU, NPU, and FPGA). They note the lack of support for both concurrent efficient processing of payload and cryptographic hash functions in P4.

In addition to the discrete security functions described already, authors have investigated the programmable data plane for holistic network defense. Ref. [130] examines attacks on the data plane, focusing on Domain Host Control Protocol (DHCP) starvation and spoofing, IP address spoofing, and ARP spoofing and poisoned routing. For each vulnerability, they provide a set of mitigations using P4. Ref. [131] implements a multi-faceted network defense based on a hybrid SDN architecture, including ML support to decision-making about network state, stateful encryption based on intent, and application-awareness. Ref. [132] proposes a multimodal network defense strategy that uses a hybrid architecture combining an SDN controller and P4 switches.

Monitoring of programmable data planes is examined in [133,134]. Ref. [133] proposes efficient monitoring of the programmable data plane using P4. Their system offloads tasks from the control to the data plane and performs monitoring in-network. Another approach for monitoring is provided in [134] based on attack graphs. Their solution generates attack graphs in the control plane, which are then translated into network rules using P4.

Ref. [135] provides an ML-based approach for attack detection and mitigation in programmable data planes. They use decision trees and logistic regression to identify decision boundaries at the controller site, which are then used to develop range compressed match-action table rules. Ref. [136] notes the emergence of topology poisoning attacks on SDN and P4. To address this, they propose a lightweight in-network solution that verifies source address details contained within protocol headers and uses a novel variance-based anomaly detection method. Ref. [137] discusses the premise of Intelligent Data Plane (IDP), referring to the deployment of AI and ML directly on data plane devices. Their solution uses data plane-aware model design and efficient model deployment in-network, running on P4 switches. Related work is provided by the authors of [138], who note limitations in P4 that make it difficult to implement ML models in-network. They propose a hybrid SDN solution that supports two layers of ML classification for attack detection in the data and control planes.

Ref. [139] proposes a hybrid architecture using an OpenFlow controller and a P4-based edge node for packet-over-optical network aggregation. Their solution provides traffic engineering, network security, precise forwarding, advanced network monitoring, and packet header customization for service differentiation. Ref. [140] provides a novel security framework and hybrid architecture based on OpenFlow with P4 switches.

Finally, a range of niche security applications have been proposed for or use the programmable data plane. Ref. [141] proposes a host-based agent to alert P4 switches to implement exclusionary routing rules. Ref. [142] proposes a security policy language for Bring-Your-Own-Device (BYOD) scenarios using hybrid SDN, enabling network operators to define security policies that are then compiled into P4 for implementation. The authors in [143] propose a solution for improving flow table look-up time in P4 switches with multiple forwarding tables. Their solution has evident utility in networks at risk of DoS/DDoS attacks. Ref. [144] examines covert channel defense in programmable data planes. Their solution preserves TCP performance while detecting and mitigating covert channels. Ref. [145] provides a method for modeling Explicit Congestion Notification (ECN) in the programmable data plane using P4. Their model supports stateful security monitoring and mitigation in the data plane using P4. Ref. [146] examines flow classification for ML-based security appliances. Ref. [147] proposes a novel Operating System (OS) fingerprinting method using P4. Their solution can fingerprint host OS types and react in real-time at line rate. Ref. [148] examines the security of file transfers in the data plane. Their solution is a novel packet parser architecture utilizing blockchain and implemented in P4. Finally, ref. [149] discusses the problem of heterogeneity in network resources as exposed by network devices. They present a framework for the deployment of disaggregated and decomposed network functions, implemented in a hybrid SDN.

6.3. Network Function Virtualization

NFV is conceptually related to SDN but refers specifically to the softwarization of network and security functions into software-defined middleboxes (sometimes referred to as Network Functions (NFs) or virtual network functions (VNFs)). Being software-defined, the middleboxes are flexible in their definition and deployment. In the data plane, NFV supports the deployment of in-network capabilities that provide portable network and security functions. Despite the apparent flexibility it offers, NFV requires orchestration and over the last decade authors have increasingly viewed SDN-based NFV (SDN-NFV) as a promising union of the two technologies. In this section, SDN-NFV implementations and applications for data plane security are reviewed.

In

Table 5. SDN-NFV implementations and applications.

Reference	Year	Implementation	Application
[151]	2013	OpenFlow	Cost-based placement
[152]	2014	OpenFlow	Secure routing
[153]	2015	OpenFlow	Intrusion detection
[154]	2017	OpenFlow	Adaptive routing
[155]	2017	Novel (OpenSDWN)	SDWN
[156]	2018	Novel (OpenFunction)	Middleboxes
[157]	2019	OpenFlow	Data plane functions
[158]	2023	OpenFlow	Data plane functions
[159]	2015	Novel (VNGuard)	Firewall management
[160]	2020	OpenFlow	Network deception
[161]	2021	OpenFlow, P4	Programmable edge networking in 5G
[162]	2023	OpenFlow	Blockchain in 5G

, we summarize research investigating applications of SDN-NFV for security. As per earlier tables, application (Application), year of publication (Year), and technology of implementation (Implementation) are noted. Papers are ordered firstly by Application and secondly by Year.

The flexibility of the SDN-NFV construct has garnered interest for network management, performance, and security applications (see Figure 9 for a generalized view of the SDN-NFV architecture). Ref. [151] examines the problem of cost-based placement for SDN-NFV functions for DPI. Their solution deploys DPI engines as VNFs in the data plane. Ref. [152] examines SDN-NFV for user-specified secure routing. In their solution, users define their desired network functions and store them in a network service graph, with network path configuration using dynamic flow rule installation. In [153], the authors propose a network intrusion prevention solution based on SDN-NFV which provides two-layer traffic classification and DPI in the data plane, extended OpenFlow protocol messaging, and service chaining. Ref. [154] provides adaptive routing based on SDN-NFV. Their solution enables customization of routing services for different applications.

A comparable approach to [154] is presented in [155], focusing on SDWN. They provide service differentiation using transmission control and enable network operators and users to specify application and flow priorities. The authors argue their solution is appealing for securing hotspot architectures through the splitting of functions.

Deployment and management of middleware and softwarized middleboxes using SDN-NFV has also attracted substantial research interest. This reflects the portability of NFV as discrete functions based on the software and the orchestration possibilities enabled by SDN, which are informed by its global view. Ref. [156] presents a novel data plane abstraction for Software-Defined Middleboxes (SDM). A similar approach is presented in [157,158], although implemented in OpenFlow. Their solution is a novel architecture that supports security services as a set of abstract actions which are translated into OpenFlow forwarding rules.

Refs. [159,160] examine SDN-NFV as security middleware for firewall and network deception (honeypots), respectively. Ref. [159] provides an NFV-based framework for firewall management in SDN. Their solution defines a high-level firewall policy language, determines optimal placement for the virtual firewalls, and then adapts virtual firewalls to changes in the VN. Ref. [160] examines SDN-NFV for network intrusion detection using efficient NFV-based honeypots, managed by the controller.

Lastly, recent research has investigated SDN-NFV applications in cellular communications. Ref. [161] examines the application of SDN-NFV using P4 for 5G networks. They consider traffic engineering, security, multi-tenancy, offloading, and telemetry implemented using VNFs and deployed in a hybrid architecture. In contrast, ref. [162] proposes a blockchain-based SDN framework for securing network transactions using SDN-NFV. Their solution aims to address the risk of man-in-the-middle (MITM) attacks between the control and data planes in SDN.

6.4. Post-Quantum Security

SDN has attracted recent and significant attention for quantum security methods, specifically the implementation of quantum cryptographic capabilities using SDN. This research interest reflects the flexibility and programmability that SDN affords, especially when paired with complementary technologies like NFV and programmable data plane. Quantum cryptographic capabilities provide resiliency to the quantum cryptanalysis that is enabled by quantum computers.

Ref. [163] provides the first example of a Quantum Key Distribution (QKD) solution implemented in SDN, specifically utilizing SDN-NFV for a secure optical network use case. Their SDN-QKD architecture supports time-sharing, with an SDN controller managing a set of QKD nodes that each run a (cryptographic) key server and QKD application. The authors built on their work in [164,165], although their solution did not change substantially. Another SDN-QKD solution is proposed in [166], specifically designed to secure the SBI against the threat of eavesdropping and MITM attacks.

Ref. [167] employs SDN-QKD to secure a fiber telecommunication network related to the work in [163,164,165]. Their implementation was based on a physical network spanning a several-kilometer area and demonstrates the effectiveness of SDN-QKD for establishing a quantum-secure channel between remote sites. They build on their solution in [168], which is implemented per the European Telecommunications Standards Institute (ETSI) Group Specification (GS) Quantum Key Distribution 015 (ETSI-GS-015) standard. Ref. [169] implements an SDN-QKD solution for real-time monitoring and controlling of a quantum-secure network, which takes advantage of hardware encryptors for performant and on-demand encryption and decryption. Refs. [170,171] also examine implementation of hardware encryptors for SDN-QKD use cases. Interestingly, they also note that the addition of encryption and decryption as implemented did not meaningfully impact latency during experimentation.

Ref. [172] examines SDN-QKD for 5G, utilizing a hybrid approach that uses classical and quantum key distribution to provide flexible security depending on computational complexity and relevant physical properties. Ref. [173] proposes an SDN-QKD architecture based on the ETSI GS QKD 014 standard, implementing SDN controllers and agents as Secure Application Entities (SAEs) per the standard. Another SDN-QKD architecture is proposed in [174], utilizing an application plane orchestrator integrated with an SDN controller. Lastly, ref. [175] presents another SDN-QKD solution based on the BB84 protocol. Their solution provides confidentiality, integrity, efficient key distribution, and network orchestration via the SDN controller. They also posit a ‘quantum layer’ in the SDN architecture.

6.5. Traditional Security Capabilities

The final family of intra-data plane capabilities that will be discussed is traditional security capabilities implemented in SDN. For the purposes of this paper, a traditional security capability is any detective, preventative, or mitigative security control or security function that is not based on NFV or a programmable data plane. Compared to programmable data planes and SDN-NFV, this is a comparatively niche subject and has been the subject of decreasing security research over time as NFV and programmable data plane technologies like P4 have gained popularity. However, SDN is a convenient method for managing distributed security capabilities in the data plane, and over the last decade researchers have examined how SDN can extend traditional security capabilities by taking advantage of the appealing features of SDN, including but not limited to the global view of the controller, dynamic management of forwarding tables, and well-defined APIs for programmatic network management.

In

Table 6. Traditional security capabilities in the SDN data plane.

Reference	Year	Implementation	Application
[176]	2016	OpenFlow	Firewall
[177]	2020	OpenFlow	Firewall
[178]	2017	OpenFlow	Deep packet inspection
[179]	2018	OpenFlow	Deep packet inspection
[180]	2021	OpenFlow	Deep packet inspection
[181]	2020	OpenFlow	Deep packet inspection
[182]	2016	OpenFlow	DoS mitigation
[183,184]	2017	OpenFlow	DoS mitigation
[185]	2017	OpenFlow	Entropy-based DoS mitigation
[186]	2020	OpenFlow	Entropy-based DoS mitigation
[187]	2021	OpenFlow	Entropy-based DoS mitigation
[188]	2020	OpenFlow	Entropy-based DoS mitigation
[189]	2019	OpenFlow	DoS mitigation
[190]	2018	OpenFlow	DoS mitigation
[191]	2019	OpenFlow	DoS mitigation
[192,193]	2020	OpenFlow	DoS mitigation
[194]	2023	OpenFlow	DoS mitigation
[195]	2016	OpenFlow	ML-based DoS mitigation
[196]	2017	OpenFlow	ML-based DoS mitigation
[197]	2018	OpenFlow	ML-based DoS mitigation
[198,199]	2019	OpenFlow	ML-based DoS mitigation
[200]	2018	OpenFlow	ML-based DoS mitigation
[201,202]	2020	OpenFlow	ML-based DoS mitigation
[203,204]	2021	OpenFlow	ML-based DoS mitigation
[205,206]	2021	OpenFlow	ML-based DoS mitigation
[207]	2022	OpenFlow	ML-based DoS mitigation
[208]	2024	OpenFlow	ML-based DoS mitigation
[209]	2018	OpenFlow	Low-rate DoS mitigation
[210,211,212,213]	2023	OpenFlow	Low-rate DoS mitigation
[214,215,216,217]	2024	OpenFlow	Low-rate DoS mitigation
[218]	2025	OpenFlow	Low-rate DoS mitigation
[219]	2015	Novel (EmPOWER)	Wireless monitoring
[220]	2019	OpenFlow	Intrusion detection
[221]	2020	OpenFlow	Intrusion detection
[222]	2023	OpenFlow	Intrusion detection
[223]	2018	OpenFlow	Traffic classification
[224]	2020	OpenFlow	Traffic classification
[203]	2021	OpenFlow	Traffic classification
[225]	2024	OpenFlow	Traffic classification
[226]	2016	OpenFlow	Network access control
[227]	2021	OpenFlow	Device-to-device
[228]	2021	OpenFlow	Network defense
[229,230]	2024	OpenFlow	Network defense
[231]	2021	OpenFlow	Moving target defense
[232]	2016	OpenFlow	Encryption
[233]	2022	OpenFlow	Encryption
[234]	2022	OpenFlow	Anti-spoofing
[235]	2022	OpenFlow	Blockchain

, we summarize research investigating traditional security capabilities implemented in the SDN data plane. As per earlier tables, application (Application), year of publication (Year), and technology of implementation (Implementation) are noted. Papers are ordered firstly by Application and secondly by Year.

Software-Defined Firewall (SDF) is the implementation of a firewall in SDN. A simple packet-filtering firewall is relatively trivial in SDN, as the controller must decide on all mismatched packets. However, extending SDF introduces challenges related to performance and responsiveness.

Refs. [176,177] both investigate the feasibility of SDF. Ref. [176] configures OpenFlow switches to act as a distributed Layer 2/3 firewall by mapping addresses to ports and filtering traffic according to the flow rules defined. In [177], the authors propose an application-aware firewall as an extension to OpenFlow.

Relatedly, authors have examined SDN for novel approaches to DPI. DPI is challenging in SDN, as the network must preserve performance amid the introduction of any new security capabilities, which is complicated by the control loop of SDN and the limited functionality of the traditional (stateless) SDN data plane. Ref. [178] proposes a novel solution for DPI using in-network DPI proxy nodes, implemented in both hardware and software, for proxy selection and route planning.

In [179], the authors propose a QoS-aware traffic classification scheme using OpenFlow, providing both DPI and semi-supervised ML for traffic classification. Another ML-based approach is presented in [180] for DPI in OpenFlow SDN. Their solution performs early detection at flow level granularity and DPI at packet-level granularity for both encrypted and unencrypted traffic. In contrast, ref. [181] discusses SDN-based DPI for ICS use cases. They utilize an isolated SDN controller to perform DPI out-of-band.

DDoS mitigation has been broadly investigated using SDN, with both detection and enforcement typically being performed in the data plane. The former relies on parsing incoming network traffic and referring suspicious flows to the controller or a security solution. The latter is typically the routine match-action operation of the SDN but extended through dynamic rule definition. A key challenge in both cases is the ability of the SDN to perform these operations at line rate and without saturating the SBI or controller.

Ref. [182] provides an investigation into DDoS attacks on the SDN data plane, examining flow table sizes and table miss rates to demonstrate that attackers can maximize degradation and minimize attack rate, thereby reducing the likelihood of detection and mitigation. Ref. [183] examines attacks that rely on SBI congestion and proposes a statistical detection approach with lightweight mitigations (see Figure 10). A similar investigation is provided in [184], focusing on attacks that exploit table miss packets. Their solution is positioned between the controller and other control plane applications to protect both control and data plane resources.

Ref. [185] examines DDoS attacks in SDN using source IP address and various TCP attributes for mitigation of volumetric and application-based attacks. They use Shannon’s Entropy to calculate entropy in a fixed time window to identify anomalous traffic. A comparable method is provided in [186] for an Internet of Multimedia Things (IoMT) use case, with incorporation of a classification model for further analysis. Ref. [187] combines multiple entropy-based methods and performs data plane data collection using an open-source signature-based IDS to reduce network overhead. Analysis and detection improvement are performed using DL models.

A recent entropy-based method is also presented in [188]. The authors use a combination of source IP and specific TCP flags to calculate entropy for detecting traffic associated with volumetric and low-rate Layer 7 DDoS attacks. Another entropy-based DDoS detection mechanism is proposed in [189], focusing on TCP-SYN flood attacks.

In contrast to the above, ref. [190] proposes a general control and data plane DoS attack detection solution. Their implementation contains a monitoring function based on PACKET_IN messages, a detection and localization function, a host defending function, and a switch defending function. In [191], the authors propose the use of deeply programmable packet-switching nodes to implement DoS mitigation. They implement three modes: DoS traffic filtering on the output interface, DoS traffic filtering on the input interface, and DoS attack redirection to a honeypot. A similar approach is provided in [192], in which the authors extend the functionality of the SDN data plane with modules for analyzing packets, performing traffic classification, and implementation of DoS countermeasures.

Ref. [193] proposes two DoS attack detection mechanisms. One mechanism is entropy-based, while the other is chi-square-based. In both instances, they rely on OpenFlow switch statistics to distinguish benign from malicious traffic. Ref. [194] proposes a novel table overflow attack for SDN, which exploits flow entry eviction mechanisms to pre-empt the flow entries of normal applications, resulting in performance degradation. To address this, they propose mitigation using table segmentation, a score-based eviction algorithm, and concept drift-based detection.

In addition to the above, a range of ML-based DoS and DDoS attack detection methods have been proposed, using SDN. A DL-based method for DDoS detection is proposed in [195]. Their solution is largely control plane-based, only performing traffic collection and flow installation in the data plane. Ref. [196] examines two novel DDoS attacks targeting SDN. They propose a solution that collects network statistics from the data plane and performs ML-based classification in the control plane. They also implement honey pots in the data plane for redirecting attack traffic. Ref. [197] considers DDoS mitigation using data plane data sampling and ML support at the controller for classifying the sampled data.

Ref. [198] proposes a cross-plane security framework for OpenFlow SDN. They perform coarse-grained monitoring in the data plane for rapid anomaly detection and fine-grained hybrid DL-based classification in the control plane. Ref. [199] provides a general discussion of SDN-based approaches to DDoS mitigation and classifies approaches into statistical and policy-based defense, machine-learning based defense, and application-specific defense. Ref. [200] proposes a multifaceted method for detecting DoS attacks in the SDN data plane. Their solution extracts relevant features from flow information and they provide a performance comparison of three algorithms, SVM, neural network, and Naïve Bayes, with the latter two demonstrating the greatest accuracy.

Ref. [201] presents a comprehensive evaluation of several ML techniques for the mitigation of DDoS attacks in SDN and SDN in 5G. Based on classical ML performance measures, SVM performed best. Another DL-based method for DDoS detection in SDN is proposed in [202]. Particle Swarm Optimization (PSO) is used for feature selection, with optimal features given as inputs to the DNN to perform classification. A DL-based method for detecting attacks in the data plane is proposed in [203]. They perform pre-processing of the dataset prior to classification to improve performance and increase accuracy.

In [204], the authors propose a source-IP-agnostic DDoS traffic classification and filtering scheme. Their solution identifies packet signatures via supervised ML and then generates signature-based filtering rules. Ref. [205] proposes a hybrid DDoS attack detection scheme. Their scheme is cooperative and cross-plane, using a coarse-grained entropy-based detection module deployed on edge switches and a precise attack detection module deployed at the controller. Ref. [206] provides a hybrid statistical method for DDoS attack detection using second order correlation coefficient techniques based on entropy. Ref. [207] proposes a two-level DDoS attack detection method based on information entropy and DL. Lastly, another DL-based method is proposed in [208], although it is focused on attacks on both the control and data planes. For the control plane, they use a DL model with features extracted from traffic statistics. For the data plane, they use a combination of traffic metadata and switch statistics.

There has been recent and growing interest in low-rate DoS and DDoS attacks on the SDN data plane. These attacks are domain-specific in that they take advantage of knowledge of the operation of the SDN, especially the OpenFlow protocol.

In [209], the authors propose a low-rate DoS attack that computes the lower bound of attack rates to overflow flow tables based on inferred network configurations. Their attack uses a probing phase to learn the network configuration and an attacking phase to install malicious rules on target switches. The authors expanded on their work in [210] with additional evaluation.

Ref. [211] proposes a mitigation for low-rate DoS attacks targeting TCAM in SDN switches. Their solution has three modules: a monitor, a ranker, and a mitigator. The authors published comparable solutions in [212,213,214,215]. Ref. [212] proposes a low-rate DoS attack mitigation scheme based on ML, with attack detection, feature extraction, and mitigation. Ref. [213] is similar, with the addition of a rule-prediction module for monitoring rule numbers in tables and making real-time predictions for threshold-based detection of attacks. Refs. [214,215] examine the same problem, utilizing novel methods based on different ML models for attack classification and mitigation (Random Forest and LightGBM-LR, respectively).

Ref. [216] proposes an ML-based mitigation method for low-rate DoS attacks, specifically table overflow attacks. Their method uses a detection module that monitors flow properties, identifies malicious flows, and then backlists malicious addresses. Another ML-based approach is presented in [217]. Their solution extracts flow features from flow information in the data plane and aggregates them into a current time graph model. They then utilize graph neural networks to perform graph anomaly detection and flow entry classification. Mitigation is performed by deleting malicious flows and blocking attackers. Lastly, ref. [218] proposes an ensemble learning-based ML method for detecting and mitigating low-rate DoS attacks in SDN.

With obvious complementarity to SDF and SDN-based DoS/DDoS mitigation, SDN-based intrusion detection and prevention has attracted research interest. Ref. [219] proposes a set of programmable abstractions for the SDWN data plane, which model the fundamental aspects of wireless networks and, most relevantly, provide abstractions for network monitoring and network reconfiguration. Their solution relies on agents distributed throughout the data plane on centrally managed APs.

Refs. [220,221] examine IDPS for wired SDN. Ref. [220] investigates data plane security using DNN-based network intrusion detection. They implement an SDN-based IDPS for performing early mitigation of DoS/DDoS attacks and other attacks based on timely anomaly detection and mitigation within the data plane. In contrast, the authors in [221] consider the efficacy of cloud-based IDPS using a combination of ML methods with an in-network IDS performing anomaly detection and the routing of suspicious flows back to a secondary IDS for deeper analysis using a signature-based method. Lastly, ref. [222] proposes a real-time anomaly detection architecture using Security Information Event Management (SIEM) and ML for traffic classification.

Relatedly, authors have implemented novel methods for traffic classification in SDN. Ref. [223] proposes a DL-based traffic classification solution for home gateways. Their solution supports management of distributed devices and supporting controllers in the core network, providing QoS based on traffic monitoring and resource allocation. Another DL-based traffic classification solution is proposed in [224]. The authors note that the increase in Internet traffic complexity is challenging to current port-based and DPI approaches. Their solution uses a cross-plane SDN approach, with extraction of traffic information from the data plane and monitoring, classification, and other functions in the control plane. Lastly, ref. [225] investigates ML-based traffic classification for SDN, primarily for QoS and network performance.

In addition to firewall, DoS/DDoS mitigation, and IDPS, researchers have implemented a range of other traditional security capabilities using SDN, although the level of research interest has been modest in comparison to the former. Ref. [226] presents a novel OpenFlow-based approach for Virtual Local Area Network (VLAN) tagging. The authors provide both the architecture and implementation of their solution for a heterogeneous SDN. While OpenFlow has VLAN support, SDN-based VLAN for data plane security is underinvestigated in the literature. Ref. [227] examines privacy preservation for Device-to-Device (D2D) communication and caching strategies for maintenance of QoS/QoE. Their SDN-based solution calculates node importance according to information requests and encounters collected by SDN switches, which enables base stations to make decisions based on historical information. Lastly, ref. [228] focuses on mitigating fingerprinting attacks in SDN. The authors propose a probabilistic scrambling strategy to mitigate fingerprinting attacks by hiding network and node information.

Ref. [229] provides a general study of threats and attacks in SDN. They examine defenses of SDN and posit the main techniques as access control, traffic monitoring, key management, identity authentication, and others. Ref. [230] examines the application of Federated Learning (FL) in multi-controller SDN. They consider FL for addressing data plane vulnerabilities, including misuse and malicious activities.

Ref. [231] introduces the concept of shadow controllers for cross-plane security. The shadow controller responds to malicious probing in place of the actual controller and their framework adopts both reactive and proactive approaches, leveraging MTD through IP and port shuffling.

In [232], the authors examine Identity-Based Cryptography (IBC) for security in SDN. They propose the use of IBC for securing both east–west (inter-controller) and SBI communication. Noting this, their solution is multi-domain capable and supports multi-controller architectures. Another SDN-based encryption technique is proposed in [233], who posit the use of ECDH and AES encryption for SDN to prevent eavesdropping and MITM.

Ref. [234] examines ARP spoofing in OpenFlow-based SDN. They propose an anti-ARP spoofing solution implemented solely in the data plane through an extendable and customizable software architecture. Finally, ref. [235] proposes a security framework for SDN based on blockchain. They adopt a multi-controller architecture that uses LLDP to obtain link state information which is used to establish a Merkle tree. Signatures are generated for each link and network changes are recorded on the blockchain, providing consistency among controllers.

6.6. Summary

The programmability of the SDN data plane supports a range of security capabilities, both novel and inherited from traditional networks. As demonstrated, there is a focus on availability, which is reflective of the criticality of the control plane and the perception of the controller as a single point of failure. This also correlates with a focus on DoS and DDoS attacks as the (perceived) chief threat to SDN. These attacks take advantage of SDN’s dependence on the controller and specific technical limitations of SDN, such as the long control loop.

With the emergence of programmable data planes, various authors have posited the relative advantages of stateful and programmable data plane infrastructure, which can implement performant primitives to realize security capabilities at line rate and without dependence on a controller for decision-making. This growing interest is associated with a strong critique of the centralized model of SDN. However, there are also disadvantages to the decentralized model offered by programmable data planes, such as the lack of a global view, the loss of central programmability, the loss of well-defined cross-plane interfaces, and the lack of convenient network orchestration. Recently, researchers have recognized the value of hybrid SDN architectures, combining the functionality of a programmable data plane with central management and orchestration by an SDN controller. This hybrid approach is a promising future direction for SDN security research.

Finally, other notable gaps remain for this domain (see

Table 7. Research strengths and weaknesses for security capabilities within the data plane.

Identifier	Summary	References
RSTR-3	A range of security applications have been implemented using a programmable data plane.	[12,13,14,15,16,17,18,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149]
RSTR-4	Programmable data planes may support mitigation of DoS and DDoS attacks at line rate.	[69]
RWKN-4	There is a disproportionate focus on availability in SDN security.	[65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218]
RWKN-5	There is disproportionate focus on DoS and DDoS attacks on SDN.	[182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218]
RWKN-6	Weaknesses of the decentralized model in programmable data planes are underinvestigated.	Nil
RWKN-7	Hybrid SDN is underinvestigated.	[75,87,97,109,123]
RWKN-8	In-network (in-band) control is underinvestigated.	[60]
RWKN-9	Novel attacks on P4 switches are underinvestigated.	Nil
RWKN-10	Software security for SDN and programmable data planes is underinvestigated.	Nil

). They include security for in-network controllers (especially in multi-controller architectures), attacks on P4 switches, and software security for SDN (especially in a programmable data plane).

7. Security of the Data Plane Infrastructure

7.1. Overview

The second of the three research domains to be discussed is security of the data plane infrastructure. This domain concerns research that seeks to secure the components of the SDN data plane, including forwarding devices (routers and switches), communications links, and participating hosts (refer to Table 1). Research in this domain is further classified into the following sub-domains: device compromise, forwarding anomaly detection, and secure southbound communication (i.e., security of the SBI).

With the strong separation of planes introduced in SDN, the data plane may superficially appear to become a less appealing target for attackers in favor of the control plane. However, as will be demonstrated in this section, compromise of the data plane is equally dangerous as compromise of the control plane. This is because a compromise of the data plane may be opaque to the controller and the network operator, especially in the absence of a specialized security control or other mechanism to detect violations of network and security policy in the data plane. Additionally, an attacker that has insight into the SDN protocol(s) in use may exploit or fabricate southbound messaging to obfuscate their actions in the data plane and establish persistence. This section will show, through a detailed review of relevant literature, that security of the data plane is essential to the security of SDNs but is complicated by advanced domain-specific threats.

7.2. Device Compromise

While SDN limits the capabilities of the data plane predominantly to forwarding and interaction with the controller, it also introduces new primitives and other vectors that may exhibit vulnerability or be the target of attack. For the purposes of this paper, this is broadly described as device compromise and relates to the compromise of forwarding devices, specifically SDN-enabled routers, and switches. The risk of device compromise is arguably expounded by the lack of ‘intelligence’ in the stateless data plane of classical SDN, due to the inability of the data plane to inherently detect anomalies, and authors have proposed various methods to both detect device compromise in the data plane and increase the resiliency of the data plane itself, the latter being well-reflected in the literature reviewed in the previous section (see Section 5).

In

Table 8. Device compromise in the SDN data plane.

Reference	Year	Implementation	Application
[236]	2015	OpenFlow	Compromise detection
[237]	2016	OpenFlow	Compromise detection
[238,239,240,241]	2017	OpenFlow	Compromise detection
[242]	2019	OpenFlow	Compromise detection
[243]	2020	OpenFlow	Compromise detection
[244]	2021	OpenFlow	Compromise detection
[245]	2024	P4	Compromise detection
[246]	2018	OpenFlow	Anti-packet injection
[247]	2019	OpenFlow	Anti-packet injection
[248]	2014	OpenFlow	Novel attacks
[249]	2018	OpenFlow	Novel attacks

, we summarize research investigating device compromise in the SDN data plane. As per earlier tables, application (Application), year of publication (Year), and technology of implementation (Implementation) are noted. Papers are ordered firstly by Application and secondly by Year.

OpenFlow natively lacks security features, and arguably the most detrimental among these are methods for attesting to appropriate switch behavior and switch security or trustworthiness. An unmodified OpenFlow SDN has no method for detecting malicious switch behavior and therefore the ability to implement detection for switch compromise is essential. This has manifested in several novel methods for identifying, preventing, and mitigating switch compromise [236,237,238,239,240,241,242,243,245].

In [236], the authors provide a classification of attacks on SDN switches. They consider the potential malicious actions possible through a compromised switch, such as incorrect forwarding, duplicated forwarding, packet manipulation, and malicious weight adjustment (see Figure 11). To address these attacks, the authors propose an anomalous forwarding detection method and weighting detection to identify unexpected ratios in dispatched packets. The problem of compromised switch detection is also explored in [237], with an added focus on localization and mitigation. They propose three complementary techniques: active probing, statistical checking, and packet obfuscation.

Out-of-band audit methods have been proposed in [238,239]. In [238], the solution employs a multi-controller architecture with a secondary controller that performs audits of network update events. In [239], the authors propose a novel attack based on manipulating flow-table timeout values and a detection method using a global flow table for audit purposes. Ref. [240] investigates DoS/DDoS attacks in SDN, with the authors demonstrating that by manipulating the timeout values of flows on SDN switches, an attacker can prompt spurious messages over the SBI, resulting in resource exhaustion.

An IPS for the SDN data plane is proposed in [241]. The authors highlight detection and mitigation of device compromise as research gaps. To address this, they propose their IPS, which uses an unsupervised trajectory-based sampling mechanism that computes expected versus actual packet trajectories and identifies anomalous forwarding devices.

Methods for real-time detection of compromised SDN switches are proposed in [242,243]. Ref. [242] proposes a method using predictive analysis to perform accurate classification of anomalous SDN switch behavior. Building on their work in [242], the authors in [243] propose a stochastic Recurrent Neural Network (RNN) variant of multivariate time-series-based anomaly detection for detection of compromised switches.

Ref. [244] proposes a novel method for the detection of flow table integrity violation in OpenFlow, including localization of compromised switches. Their solution includes detection of the unauthorized addition, modification, and removal of forwarding rules, utilizing a cookie field in the OpenFlow protocol to place a digest value for each flow table entry.

In contrast, ref. [245] examines P4 switch compromise. The authors provide a novel threat model focused on flow table modification in P4 data planes and examine the manipulation of flow rules via switch compromise. To mitigate the threat of flow table manipulation, they propose a detection framework that utilizes backtracking of flows, as well as defining a fuzzy rule-based mitigation. Curiously, the security of P4 switches is underinvestigated in the current literature.

A related area of research is packet injection in the data plane. Packet injection is a significant threat, as OpenFlow does not provide any inherent security against malicious OpenFlow messages.

Packet injection is investigated in [246,247]. In [246], the authors posit a novel packet injection attack. By inserting spurious packet header information in PACKET_IN OpenFlow messages, an attacker can force a victim controller to generate a ‘ghost topology’ of non-existent devices. To mitigate this attack, the authors propose a method for inspecting and filtering PACKET_IN messages. Another mitigation for packet injection attacks is proposed in [247], focusing on packet injection attacks launched from a compromised data plane. Their solution inspects PACKET_IN messages on the SBI and retains a database to store host and switch information.

Finally, novel attacks on SDN are presented in [248,249]. Ref. [248] examines advanced attacks on SDN utilizing compromised switches. The attacks considered include flow table modification, control channel hijacking, eavesdropping on control plane communications, state spoofing, topology spoofing, and DoS. The authors posit defenses for each attack. Ref. [249] examines poisoning attacks in the SDN data plane and proposes a novel attack that takes advantage of a weakness in OpenFlow in which flow table capacity exhaustion forces the controller to begin inserting and deleting flow entries, degrading network performance. The authors propose two defense mechanisms for this type of attack: compression of flow table entries, and implementation of larger flow tables.

7.3. Forwarding Anomaly Detection

A forwarding anomaly refers to when the behavior of a forwarding device is non-compliant. Typically, this means a packet is handled anomalously, such as being forwarded, dropped, or modified in a manner that violates the forwarding rules provided by the controller or the conventions of the SDN protocol in use.

In OpenFlow-based SDN, forwarding anomalies are conceptually simple, but with the growing interest in programmable data planes and hybrid SDN the potential for complex forwarding behaviors will also grow accordingly. As a result, there is a need for efficient and flexible forwarding anomaly detection solutions. Fortunately, there has been research interest in designing and implementing forwarding anomaly detection since the early 2010s and this research interest has persisted. This section will review this research, highlighting proposed solutions and characterizing trends where relevant.

In

Table 9. Forwarding anomaly detection.

Reference	Year	Implementation	Application
[250]	2015	OpenFlow	Forwarding anomaly detection
[251]	2016	OpenFlow	Forwarding anomaly detection
[252]	2021	OpenFlow	Forwarding anomaly detection
[253]	2017	OpenFlow	Forwarding anomaly detection
[254,255]	2018	OpenFlow	Forwarding anomaly detection
[256]	2021	OpenFlow	Forwarding anomaly detection
[257]	2019	OpenFlow	Forwarding anomaly detection
[258]	2021	OpenFlow	Forwarding anomaly detection
[259]	2022	OpenFlow	Forwarding anomaly detection
[260]	2020	OpenFlow, P4	Forwarding anomaly detection
[261]	2023	P4	Forwarding anomaly detection
[262]	2018	OpenFlow	ML-based forwarding anomaly detection
[263,264]	2019	OpenFlow	ML-based forwarding anomaly detection
[265]	2020	OpenFlow	ML-based forwarding anomaly detection
[266]	2012	OpenFlow	Network invariant detection
[267]	2015	OpenFlow	Network defense
[268]	2019	OpenFlow	Load optimization and anomaly detection

, we summarize research investigating forwarding anomaly detection in SDN. As per earlier tables, application (Application), year of publication (Year), and technology of implementation (Implementation) are noted. Papers are ordered firstly by Application and secondly by Year.

Detection and mitigation of forwarding anomalies has attracted significant research interest over the last decade [250,251,252,253,254,255,256,257,258,259,260,261,262,263,264,265]. Ref. [250] proposes a lightweight architecture for detecting anomalies in the SDN data plane, including forwarding anomalies. Their architecture uses a data collector, a feature selection module, and a classification module collocated with the controller, operating on inputs from the data plane. Ref. [251] proposes a similar solution for anomaly detection, with added data plane localization. They built upon their work in [252] to further enhance localization and to optimize the placement of monitoring positions along network paths.

Ref. [253] proposes a formal approach for predicting a packet path inside an SDN. Their solution relies on generating queries that contain all possible packets that could pass through the network from all ingress switches to detect possible policy conflicts. The same authors proposed an incremental approach for detecting potential anomalies in an SDN policy in [254].

In [255,256], the authors propose a forwarding anomaly detection method for OpenFlow-based SDN that uses a flow conservation principle for checking behaviors of all flows in a network simultaneously. Their solution works by modeling the controller’s global view in a flow counter matrix and capturing flow rules and flow statistics from the data plane. In [256], they build on their previous work by adding localization to identify the compromised switch.

Ref. [257] proposes a real-time packet forwarding verification method for OpenFlow (see Figure 12). Their solution uses both packet forwarding and forwarding statistics to detect forwarding anomalies and violations of packet integrity with dynamic sampling. Ref. [258] proposes a traffic anomaly detection and mitigation solution. Their solution is essentially a signature-based IDS that collaborates with the SDN controller using an external application, with the controller performing mitigation upon anomaly detection. Lastly, in [259], the authors propose a scheme for mitigating forwarding anomalies in real time. Their solution uses tags to disambiguate dependent rules and remove forwarding ambiguity.

P4-based approaches for forwarding anomaly detection are investigated in [260,261]. In [260], the authors examine forwarding anomaly detection in a hybrid SDN architecture. P4 switches are enrolled into the network to perform network traffic sampling. The sampled packets are referred to the OpenFlow controller for verification. Ref. [261] proposes methods for real-time packet verification to defend against hijacking and new stream attacks. For hijacking attacks, they use a comparison of P4 metadata and register contents. For new stream attacks, their solution uses an exception window for initial detection and computation of information entropy.

ML-based methods for forwarding anomaly detection are proposed in [262,263,264,265]. Ref. [262] proposes a DNN-based anomaly detection method for SDN. Their solution is a network IDS (NIDS) that utilizes Gated Recurrent Unit Long Short Term Memory (GRU-LSTM). To improve classifier performance, the authors employ a combination of feature selection methods. In [263], the authors use the DBSCAN algorithm to identify anomalous rules and controller behavior using the IP address, action on rule match, rule duration, and link utilization as features.

Ref. [264] proposes both a flow-based and packet-based Multilayer Perceptron (MLP) DL method for detecting anomalies in high-traffic and high-performance networks. In contrast, ref. [265] proposes a multi-faceted solution that uses deep RL to learn traffic flow matching strategies to maximize traffic flow granularity while protecting the SDN. Their solution has two components, a DL-based matching control component and an anomaly detection and classification component. Mitigation is performed by implementing attack mitigation policies.

Other solutions for forwarding anomaly detection are proposed in [266,267,268]. In [266], the authors propose a novel solution for real-time verification of network invariants. Their solution provides proactive anomalous forwarding mitigation by leveraging the controller to access the global view and validating the rules that are generated. In [267], the authors propose a solution for detecting cross-plane attacks that works by dynamically learning the topology and network behavior by intercepting OpenFlow messages, building a flow graph and validating network behavior. Finally, in [268], the authors propose a solution for load optimization and anomaly detection in OpenFlow-based SDN with a multi-controller architecture. Enforcement of anomaly mitigation is provided using access control policies that are implemented as flow rules intra-data plane.

7.4. Heterogeneous SDN

For the purposes of this review, heterogeneous SDN is SDN utilizing diverse communications media in the data plane. In simple terms, this can be thought of as SDN utilizing a mix of wired and wireless communications. This is a broad definition and naturally encompasses SDN applications in 5G and IoT. However, it is also a valuable domain of research, as network heterogeneity is generally increasing (e.g., 6G), resulting in greater network complexity and an attack surface that is more difficult to secure, warranting novel methods for network security.

In heterogeneous SDN, confidentiality and integrity are of greater concern than in a traditional (wired) SDN, as the wireless medium is susceptible to eavesdropping and more advanced attacks that may exploit the readily available signal of the wireless data plane.

In

Table 10. Heterogeneous SDN.

Reference	Year	Implementation	Application
[269]	2015	OpenFlow	IoT and ad hoc networks
[270,271]	2020	OpenFlow	IoT
[272]	2016	OpenFlow	Big Data
[273]	2019	OpenFlow	5G

, we summarize research investigating security of heterogeneous SDN. As per earlier tables, application (Application), year of publication (Year), and technology of implementation (Implementation) are noted. Papers are ordered firstly by Application and secondly by Year.

Security for IoT is an enduring challenge and SDN has seen investigation for both the introduction of new security capabilities (see [26] for a relevant review) and for how SDN-IoT itself may be secured. Ref. [269] investigates security for IoT and ad hoc networks, providing a new SDN architecture for wired, wireless, and heterogeneous use cases. They examine security policy definition and enforcement for monolithic and multi-controller architectures and introduce the concept of ‘border controllers’ for joining SDN domains.

SDN-IoT is also discussed in [270,271]. Ref. [270] examines SDN-IoT based on P4, utilizing in-network firewall and routing implemented on P4 switches with referral to the control plane for new and unknown packets, per the traditional SDN model. They also utilize a learning algorithm to support effective traffic classification. Similarly, ref. [271] examines SDN-IoT for QoS and security-aware routing. Their solution is deep RL-based, extracting knowledge from historical traffic and optimizing routing policies for secure delivery.

In contrast, ref. [272] examines SDN for Big Data for a range of use cases, including data processing in cloud data centers, data delivery, joint optimization, and scheduling. Importantly, they also demonstrate that Big Data may support SDN performance and security through integration with the control and application planes, with benefit to the data plane. Lastly, ref. [273] examines heterogeneity in 5G networks and argues that SDN can support security and performance in 5G. They discuss security challenges of SDN-based 5G and provide a robust security architecture, with cryptographic authentication and implementation of security gateways for cross-plane communication.

7.5. Secure Southbound Communication

The SBI is a critical component of SDNs, supporting the transfer of protocol messaging between the control and data planes. However, native OpenFlow does not provide any security features and instead relies on existing security methods to protect the components of an SDN, including the SBI. These facts make security research into the SBI appealing and potentially productive, yet to date it has remained relatively niche in contrast to the dominant topics of SDN security research (predominantly the security of the control plane and controllers specifically). Regardless, some novel research exists, and authors have posited diverse methods for assuring the security of the SBI.

In

Table 11. Secure southbound communication.

Reference	Year	Implementation	Application
[274]	2018	OpenFlow	Cross-plane defense
[275]	2020	OpenFlow	IPsec for SDN security
[276]	2022	OpenFlow	Trust-aware security
[277]	2022	OpenFlow	MITM mitigation

, we summarize research investigating secure southbound communication in SDN. As per earlier tables, application (Application), year of publication (Year), and technology of implementation (Implementation) are noted. Papers are ordered firstly by Application and secondly by Year.

Ref. [274] proposes a solution for cross-plane DoS/DDoS attack defense in SDN (see [239,240] for example attacks). The authors discuss the shortcomings of existing methods for SBI security and propose their solution, which employs collaborative cross-plane intelligence, providing attack detection, mitigation, cross-plane offloading, and localization of attackers within a botnet.

In contrast, ref. [275] considers the confidentiality and integrity of the SBI. The authors examine the implementation of IPsec in SDN for providing southbound security. They propose an evaluation model to find an effective trade-off between communication performance and link security. Ref. [276] examines the problem of cross-plane communication security between the control and data planes. They present a trust-based framework for the wireless data plane and classify attacks according to the planes and components they affect.

Finally, in [277] the authors discuss secure southbound communication and the threat of MITM attacks. To mitigate MITM, they propose a security framework that reduces the Time-To-Live (TTL) delay in which attacks can occur by defining a security policy which accepts new nodes only during specific periods and they allocate a TTL timer to the new node trying to join the network to detect any abnormal behavior in the network. They extended their framework using the Random Forest (RF) algorithm to improve accuracy and performance.

7.6. Summary

Research investigating the security of data plane infrastructure has highlighted the general vulnerability of the SDN data plane. This is primarily due to the lack of inherent security in OpenFlow, especially regarding encryption, authentication, network access control, validation of messages, audit, and switch security. We also demonstrated the lack of portable and mature security capabilities that can be deployed to protect SDN switches. This relates to the lack of native security within OpenFlow and the failure of industry and academia to develop and adopt any widely accepted security frameworks for SDN. Finally, there is a lack of convenient methods for domain-specific monitoring and insights. This means that researchers are independently implementing monitoring and extracting insights that relate to their specific applications.

Various gaps remain in this domain (see

Table 12. Research strengths and weaknesses for security of the data plane infrastructure.

Identifier	Summary	References
RSTR-5	Device compromise in SDN has been the subject of significant investigation.	[236,237,238,239,240,241,242,243,244,245,246,247,248,249]
RSTR-6	Forwarding anomaly detection in SDN has been the subject of significant investigation.	[250,251,252,253,254,255,256,257,258,259,260,261,262,263,264,265,266,267,268]
RWKN-11	Security of the SBI is underinvestigated.	[274,275,276,277]
RWKN-12	There are no widely accepted security frameworks for the SDN data plane.	Nil
RWKN-13	There is a lack of SDN mechanisms for data plane monitoring and observability.	Nil
RWKN-14	SDN-based MTD is underinvestigated.	[31,57,231]
RWKN-15	Trust management for SDN data plane devices is underinvestigated.	[276]

). Firstly, SDN-based MTD is underinvestigated despite the obvious appeal of SDN and especially programmable data planes for implementation. Secondly, despite the threat of device compromise and anomalous forwarding, there has been modest investigation of trust management and trust-based approaches using SDN. The latter issue is further discussed in the following section.

8. Dynamic Routing Within the Data Plane

8.1. Overview

The last of the three primary research domains to be discussed is dynamic routing within the data plane. This domain is concerned with dynamic and resilient routing methods within the data plane that are possible using SDN. These methods capitalize on the global view of the controller and programmability to proactively and reactively modify data plane forwarding to support network security and performance.

From a data plane security perspective, SDN enables flexible forwarding that can associate traffic security requirements with appropriate paths throughout the data plane to improve delivery, minimize opportunities for eavesdropping, and reduce the likelihood of more complex attacks. However, of the three primary research domains, this domain is the most nascent, with research tending to be more recent and exhibiting the most unresolved research opportunities. To support analysis, the research in this domain has been further classified into multi-path routing, resilient routing, and trust-based routing, with each term defined accordingly.

8.2. Multi-Path Routing

Multi-path routing is the concurrent utilization of multiple network paths for flows. Multi-path routing is commonly associated with load balancing and datacenter networking, but this section will demonstrate that multi-path routing has broader application in the SDN data plane for secure and performant delivery of traffic. While the security emphasis of the selected papers varies, the utility of multi-path routing for improving security is apparent. Multi-path routing confounds eavesdropping, MITM, and similar attacks by splitting a given flow across multiple paths and forwarding simultaneously along those paths, with reconstruction at the endpoint. It also improves the resilience of a network under DoS/DDoS attack by employing multiple paths to improve the likelihood of successful packet delivery, even with degraded availability. These features make multi-path routing a powerful and proactive defensive technique to support security within the SDN data plane, and this is reflected in the diversity of research in SDN-based multi-path routing.

In

Table 13. Multi-path routing.

Reference	Year	Implementation	Application
[278]	2015	OpenFlow	Multi-path routing
[279]	2018	OpenFlow	Multi-path routing
[280]	2019	OpenFlow	Multi-path routing
[281]	2020	OpenFlow	ML-based multi-path routing
[282]	2022	OpenFlow	ML-based multi-path routing
[283]	2023	OpenFlow	ML-based multi-path routing
[284]	2025	OpenFlow	ML-based multi-path routing
[285,286]	2018	OpenFlow	Multi-path routing using SDN-NFV
[287]	2019	OpenFlow	Multi-path scheduling
[288]	2021	P4	Multi-path scheduling
[289]	2022	OpenFlow	Multi-path for satellite networks
[290]	2024	OpenFlow	Multi-path for satellite networks
[291]	2020	OpenFlow	Multi-path routing for datacenters
[292]	2020	OpenFlow	Multi-path hop-by-hop forwarding

, we summarize research investigating multi-path routing in SDN. As per earlier tables, application (Application), year of publication (Year), and technology of implementation (Implementation) are noted. Papers are ordered firstly by Application and secondly by Year.

Research into SDN-based multi-path routing has been diverse, with authors focusing on various methods that capitalize on the global view, flexibility, and dynamism of SDN. In [278], the authors implement multi-path routing using OpenFlow for a Supervisory Control And Data Acquisition (SCADA) use case. They implement multi-path routing to increase the difficulty of eavesdropping using a control plane application and a secure channel for managing forwarding rules in the data plane.

In [279], the authors highlight the inherent lack of security in OpenFlow and examine multi-path routing for network security and resilience. Their solution uses Erasure Resilient Coding (ERC) for data fragmentation and performs distribution across multiple paths concurrently, orchestrated by the SDN controller (see Figure 13).

Ref. [280] considers the problem of efficient multi-path routing that can provide disjoint end-to-end paths satisfying specific operational goals without overwhelming the data plane with excessive forwarding-state information. This problem is central to the feasibility of multi-path in SDN, and the authors demonstrate both that the underlying problem is NP-complete and that it is possible to closely attain the optimal path length.

ML-based approaches for multi-path in SDN are investigated in [281,282,283,284]. Ref. [281] proposes an RL-based multi-path method for QoS-aware multi-path using OpenFlow-based SDN. The authors critique existing methods for multi-path and argue that they do not consider QoS. To address this, they propose an RL-based multi-path scheme that uses RL to find multiple forwarding paths for flows based on their characteristics. Relatedly, ref. [282] examines RL for service-oriented multi-path routing. Their solution implements a custom protocol for obtaining network state, a DL-based traffic classification model to identify network services, and a differentiated reward scheme for service types.

Ref. [283] proposes a deep RL multi-path scheme for SDN, focusing particularly on countering DoS attacks. Their method uses trust values and node diversity to mitigate issues such as network fluctuations, low robustness, and congestion, with path selection incorporating security, network delay, and variations in multi-path delay.

Lastly, ref. [284] proposes a QoS and congestion-aware deep RL approach. Their solution learns and optimizes routing decisions through trial and error based on a congestion severity index, which aims to minimize delay, packet loss, and packet drops while maximizing bandwidth utilization.

Authors have also proposed SDN-NFV-based multi-path routing [285,286]. Ref. [285] examines multi-path routing implemented using SDN-NFV for survivable networking. They propose a scheme that employs multi-path provisioning implemented in SDN-NFV for survivable optical networking for any given number of network failures. Ref. [286] also examines SDN-NFV for multi-path routing, providing a complete SDN-NFV architecture. Network monitoring, path selection, and network resource management are performed in the control plane, while the data plane provides flow splitting, route mapping, flow execution, and reconstruction.

Scheduling is a key issue in multi-path routing, as out-of-order packet arrival may impact flow reconstruction. Authors have investigated SDN for implementing scheduling mechanisms. Ref. [287] provides an OpenFlow-based scheduling method that includes efficient load balancing and path optimization for datacenter networks. Their solution uses SDN for load monitoring and path optimization based on global load awareness. In contrast, ref. [288] provides a P4-based multi-path scheduling method that provides both network path selection and packet scheduling.

Authors have investigated a range of other niche use cases. The authors of [289] highlight the unique challenges of satellite networks and propose a multi-path routing strategy based on SDN that uses a combination of delay, bandwidth, and node load to adjust the route for end-to-end transmission. Ref. [290] proposes an SDN-based multi-path scheme for satellite networks that uses QUIC and a multi-objective optimization strategy to improve throughput.

Ref. [291] implements OpenFlow-based multi-path routing for a datacenter use case. Their solution incorporates network heterogeneity to optimize the transmission time of flow groups (a group of flows that have the same source edge switch and the same destination edge switch). They use control plane modules to extract information from the data plane and a forwarding manager to develop rules based on the instructions of a multi-path scheduler module.

Finally, in [292], the authors propose a hop-by-hop method for forwarding on multiple paths. This is novel, as previous methods have all considered end-to-end path selection. They propose a method that ensures convergence and provides loop-free multi-path forwarding.

8.3. Trust-Based Routing

SDN provides the capability to dynamically route network traffic according to the security requirements of the traffic (e.g., the requirements of the sender, the sensitivity of the payload) and the trustworthiness of nodes and links along available paths. In this review, this is referred to as trust-based routing, although there is no consistent nomenclature in the literature, as this is an emerging domain of research. Additionally, there is no consensus on what constitutes trust or trustworthiness in a network security context, although authors have offered various definitions and have typically equated trust with security as a state (i.e., the state of being secure at a point-in-time). Regardless of how authors choose to define trust, it is apparent that it is an appealing paradigm for intuitive and explainable security that has attracted significant research interest.

In

Table 14. Trust-based routing.

Reference	Year	Implementation	Application
[293]	2014	OpenFlow	Trust-based routing for cloud
[294]	2015	OpenFlow	Multi-controller trust-based routing
[295]	2016	OpenFlow	Trust-based routing for multi-domain networks
[296]	2022	OpenFlow	Trust-based routing
[297]	2020	OpenFlow	Trust-based clustering in IoT
[298]	2023	OpenFlow	Trust-based cooperative system for Wi-Fi
[299]	2024	OpenFlow	Trust-based routing for heterogeneous networks
[300]	2013	Nil	Trust management
[301]	2015	OpenFlow	Security framework
[302]	2019	OpenFlow	Trust management
[303]	2016	OpenFlow	Trust management for heterogeneous networks
[304]	2021	OpenFlow	Trust management for VANETs
[305]	2016	OpenFlow	Trust for virtualized and software-defined networks
[306]	2023	OpenFlow	Trust-aware switching framework
[307]	2022	OpenFlow	Segment routing
[308]	2024	OpenFlow	Zero-trust-based trust and traffic engineering

, we summarize research investigating trust-based routing in SDN. As per earlier tables, application (Application), year of publication (Year), and technology of implementation (Implementation) are noted. Papers are ordered firstly by Application and secondly by Year.

Trust-based routing methods using SDN are proposed in [293,294,295,296]. Ref. [293] examines the protection of data in the cloud by controlling the paths used in data transfer. They propose an OpenFlow-based approach that enables network operators to enforce trust-based routing based on policies defined by the network operator (see Figure 14).

Ref. [294] proposes a trust-based routing method using a multi-controller architecture, with the controllers operating in different execution environments and leveraging hardware-based trusted computing technologies (e.g., Trusted Platform Modules). Another multi-controller approach is provided in [295]. Their focus is multi-domain routing across domains with specific security and regulatory requirements. Their solution relies on a cooperating SDN controller deployed to each domain along the path to establish a trusted end-to-end path.

Lastly, a trust-based routing method for OpenFlow focusing on the trust of SDN switches is presented in [296]. They provide a trust management system for assessing switch trust values over time and detecting compromised switches.

Trust-based routing for wireless and heterogeneous SDN is investigated in [297,298,299]. Ref. [297] provides a secure clustering model for SDN-based IoT. Their solution supports cluster-based communication using SDN, providing both the clustering method and a trust management system for electing cluster heads. Ref. [298] proposes a trust-based cooperative system for efficient Wi-Fi Radio Access Networks (RANs) using SDWN. The proposed architecture uses both a conventional Wireless Local Area Network (WLAN) and a blockchain-based network in the data plane, managed by a SDWN controller. In [299], the authors of this review examine trust-based routing for heterogeneous SDN. We demonstrate the learning and matching of traffic security requirements to the trustworthiness of available paths.

Closely related to trust-based routing is the premise of trust management. In [300], the authors provide a position paper arguing for secure and dependable SDN by design, incorporating trust and trust management. The trust management components relate primarily to whitelisting of trusted devices and blocking of malicious or anomalous devices. Relatedly, ref. [301] provides an experimental framework for SDN security, incorporating trust zones. Upon joining the network, devices are placed in trust zones automatically, requiring no intervention from the network operator and enabling management of devices based on their assessed trustworthiness.

Ref. [302] proposes a distributed trust framework for SDN. Their framework is closely modeled on classical Public Key Infrastructure (PKI) but supports distributed implementation and verification to reduce application overhead. In [303], the authors examine trust management for the data plane of ad hoc networks. They propose trust management using fuzzy logic to formulate imprecise empirical knowledge for formulating trusted paths. Ref. [304] examines trust management for the Internet of Vehicles (IoVs), specifically VANETs. They propose a multi-faceted SDN solution that includes the evaluation of vehicles within range of Roadside Units (RSU), a distributed trust evaluation method for vehicles outside the range of the RSU, and inter-vehicular trust evaluation.

In addition to the above, authors have proposed trust-based routing for other applications. Ref. [305] examines the problem of security and trust for softwarized networks, focusing on 5G. Their solution is effectively SDN-NFV, defining a Root Trusted Module (RTM) for ensuring components built upon it are trustworthy, and then a set of VNFs provide security and trust functions.

Another trust-based framework using SDN-NFV is proposed in [306], in which the authors introduce trust-awareness for SDN switches. Their framework uses subjective logic-based techniques to derive the trust levels of switching devices at runtime, which are then used to inform service provisioning.

Ref. [307] considers trust-based routing in the context of Segment Routing (SR). Their solution uses a trust verification mechanism with a custom Authentication Header (AH) and four trust management mechanisms, including initial trust value assignment, trust evaluation, trust renewal, and trust inheritance.

Lastly, ref. [308] proposes a zero trust-based trust management and traffic engineering system for supporting the security of critical nodes in SDN-based IoT networks. Their solution evaluates the risk of nodes based on multiple factors and performs trust evaluation between nodes. Using these evaluations, they dynamically adjust security and routing.

8.4. Resilient Routing

The final topic of this review is resilient routing in the SDN data plane. Resilient routing contrasts to multi-path routing in that it does not necessitate concurrent utilization of paths for traffic delivery, although it may involve optimal path selection and utilization of multiple paths over time. Additionally, resilient routing is distinct from trust-based routing as it does not involve the intentional incorporation of trust in routing decisions or employ a trust management system. For a working definition, resilient routing is an approach to routing in SDN that takes advantage of the dynamicity of SDN to support traffic delivery and improve security. This is the broadest class of dynamic routing, and this is reflected in a diversity of objectives and methods in the literature.

In

Table 15. Resilient routing.

Reference	Year	Implementation	Application
[309]	2011	OpenFlow	Source address validation
[310]	2017	OpenFlow	Random route mutation
[311]	2017	OpenFlow	Capability-based routing
[312]	2018	OpenFlow	Dynamic routing for VANETs
[313]	2022	OpenFlow	ML-based moving target defense
[314]	2017	OpenFlow	Fast failure recovery
[315]	2022	P4	Fast failure recovery
[316]	2023	OpenFlow	Optical transport networking
[317]	2023	OpenFlow	ML-based routing optimization

, we summarize research investigating multi-path routing in SDN. As per earlier tables, application (Application), year of publication (Year), and technology of implementation (Implementation) are noted. Papers are ordered firstly by Application and secondly by Year.

As noted, current applications for resilient routing are diverse. Ref. [309] examines source address validation for security. The authors argue that the existing frameworks are too limited and propose a novel scheme that provides on-demand filtering, tracking of flow table states using a NOX SDN controller, and utilization of OpenFlow devices as a de facto security perimeter. Ref. [310] proposes a novel random routing mutation architecture using SDN. Their approach takes advantage of the global view and centralized control in SDN to confound network reconnaissance and DoS attacks. Ref. [311] implements a novel routing method, capability-based routing. In capability-based routing, routing is security-oriented and accounts for the capabilities of nodes on available paths.

Ref. [312] proposes dynamic routing using SDN for Flying Ad Hoc Networks (FANETs). FANETs present a unique challenge, as the nodes are mobile and the topology is dynamic. To address these challenges, the authors propose a hybrid SDN model, providing topology discovery, statistics gathering, and route computation.

Ref. [313] implements ML-based MTD. Their solution uses route randomization based on up-to-date network information via real-time network telemetry, with the updated routes implemented in a programmable data plane.

A highly resilient routing design is provided in [314]. They propose a hybrid SDN architecture leveraging programmable data planes which provides failure detection and recovery using switch link probing and fast rerouting, incorporating failure detection, computation of new routes, and installation.

Another adaptive failure recovery solution is proposed in [315]. Their architecture is also hybrid, although focused explicitly on the failure of multiple links, as well as backup path computation and propagation using custom packet headers.

In [316], the authors propose a scheme for optical transport networking using SDN. Their proposed method uses the SDN controller to collect network resource information in real time and to dynamically change the weight of paths, which are then used for path calculation. Finally, ref. [317] proposes an ML-based routing optimization scheme based on the Multi-Armed Bandit Problem. They examine this problem in SDN from the perspective of seeking optimal end-to-end dynamic routing of data flows and posit that a centralized routing approach like SDN can solve routing issues more quickly than a distributed model.

8.5. Summary

Dynamic routing using SDN is the least researched of the three primary domains examined in this review. The domain is also diverse and exhibits breadth in methods, implementation and use cases. We have identified a growing interest in adaptive and resilient routing using SDN. These approaches take advantage of the global view and programmability of SDN to establish performant and secure end-to-end paths. This contrasts with the hop-by-hop forwarding of traditional networks, which are best effort by design and are unable to flexibly adapt to changing network conditions or security policies.

This domain exhibits a wide range of research gaps (see

Table 16. Research strengths and weaknesses for dynamic routing within the data plane.

Identifier	Summary	References
RSTR-7	Dynamic routing in SDN, including multi-path routing, has been the subject of significant investigation.	[278,279,280,281,282,283,284,285,286,287,288,289,290,291,292,309,310,311,312,313,314,315,316,317]
RWKN-16	Trust-based routing is underinvestigated.	[293,294,295,296,297,298,299,301,302,303,304]
RWKN-17	Dynamic routing in heterogeneous SDN is underinvestigated.	[26,47,48,299,303]
RWKN-18	Capability-based routing is underinvestigated.	Nil
RWKN-19	Time-sensitive routing is underinvestigated.	Nil

). They include extension of dynamic routing methods to heterogeneous SDN, greater incorporation of knowledge of node capabilities, performance, and trustworthiness in end-to-end-path computation, SDN-based time-sensitive routing (especially contrasted to best effort), and lastly, trust-based routing.

9. Discussion

9.1. Overview

The review of SDN data plane security research this paper has provided is illustrative of the diversity and depth in the discourse.

Table 17. Summary of research strengths identified in this review.

Identifier	Research Strengths
RSTR-1	P4 security applications have been subject to significant investigation.
RSTR-2	Cross-plane security for SDN has been subject to significant investigation.
RSTR-3	A range of security applications have been implemented using a programmable data plane.
RSTR-4	Programmable data planes may support mitigation of DoS and DDoS attacks at line rate.
RSTR-5	Device compromise in SDN has been the subject of significant investigation.
RSTR-6	Forwarding anomaly detection in SDN has been the subject of significant investigation.
RSTR-7	Dynamic routing in SDN, including multi-path routing, has been the subject of significant investigation.

and

Table 18. Summary of research weaknesses identified in this review.

Identifier	Research Weaknesses
RWKN-1	No comprehensive review exists for SDN data plane security research.
RWKN-2	Security of the P4 architecture is underinvestigated.
RWKN-3	Heterogeneous SDN is underinvestigated.
RWKN-4	There is a disproportionate focus on availability in SDN security.
RWKN-5	There is disproportionate focus on DoS and DDoS attacks on SDN.
RWKN-6	Weaknesses of the decentralized (control) model in programmable data planes are underinvestigated.
RWKN-7	Hybrid SDN is underinvestigated.
RWKN-8	In-network (in-band) control is underinvestigated.
RWKN-9	Novel attacks on P4 switches are underinvestigated.
RWKN-10	Software security for SDN and programmable data planes is underinvestigated.
RWKN-11	Security of the SBI is underinvestigated.
RWKN-12	There are no widely accepted security frameworks for the SDN data plane.
RWKN-13	There is a lack of SDN mechanisms for data plane monitoring and observability.
RWKN-14	SDN-based MTD is underinvestigated.
RWKN-15	Trust management for SDN data plane devices is underinvestigated.
RWKN-16	Trust-based routing is underinvestigated.
RWKN-17	Dynamic routing in heterogeneous SDN is underinvestigated.
RWKN-18	Capability-based routing is underinvestigated.
RWKN-19	Time-sensitive routing is underinvestigated.

below summarize the strengths and weaknesses of the SDN data plane security research that have been identified. In this section, the most promising future directions for SDN data plane security research will be discussed based on the research weaknesses, gaps, and opportunities that remain.

9.2. Hybrid SDN Security and Management

A frequent issue that has emerged in this paper is the fallacy that there is a linear progression in networking technology from SDN to programmable data planes, and especially from OpenFlow to P4. In providing the impetus for their work in P4, many authors cite the weaknesses of OpenFlow and pose P4 as a replacement for OpenFlow, rather than as a complement. This is a reductive view and is inconsistent with the purpose of P4 as provided by the creators of P4 themselves in the original proposal in 2014 [4]. While the authors of [4] highlight valid shortcomings of OpenFlow, they (and various subsequent authors) envision a “hybrid” SDN architecture that employs a central control protocol managing a programmable data plane.

This hybrid architecture provides the benefits of classical SDN, including a global view, well-defined interfaces, and a model for centralized control, in addition to the benefits of a programmable data plane that offers flexible header definition, granularity of operation, support for added primitives, and the potential to work at line rate. From a security perspective, such a hybrid SDN is challenging, as it adds complexity, imposes additional southbound communication, and further strains the resources of devices in the data plane. As hybrid SDN are the most promising future architecture for SDNs, their data plane security requires further research. This should take the form of a review of hybrid SDN architectures and the development of a detailed threat model to understand the security threats that exist for hybrid SDN. Additionally, with this new understanding, reference architectures should be developed to guide future implementations.

Relatedly, there is a trend towards decentralization in modern SDN architectures. This is evidently spurred by the growing popularity of the programmable data plane and the acknowledgement of the shortcomings of OpenFlow in the literature.

These decentralized approaches implement independent security capabilities in the data plane based on programmable data plane devices. They are appealing because they are not reliant on a controller, which is often perceived as a single point of failure, and they are performant, able to operate at line rate, and reduce network overhead (e.g., through reduction in SBI messaging). However, they also lose the advantages of classical SDN, notably central management, and are typically not scalable or portable. Furthermore, they are typically designed and implemented to meet a specific security application (e.g., DoS/DDoS mitigation, intrusion detection) and do not support other applications meaningfully, meaning they are essentially repurposing data plane devices as inflexible security middleware. Both centralized and decentralized SDN architectures come with security threats and opportunities, but the trade-off is still to be investigated.

9.3. Heterogeneous SDN Security

Another prominent theme that has emerged from the survey is the complexity of providing security for the data plane in heterogeneous networks (e.g., SDWN, SDN-based IoT). With the proliferation of softwarized networks as part of next-generation technologies (e.g., 6G), there is a clear need for robust SDN and other programmable network architectures. Yet, this is clearly an immature domain of research and existing proposals are disjointed and ad hoc. This provides the impetus for novel research into heterogeneous SDN.

The data plane of any heterogeneous system is inherently complex in terms of communications methods, protocols, mobility, and security requirements. From a security perspective, this complexity equates to a more diverse attack surface, which is difficult to secure and which may obfuscate malicious or otherwise anomalous behaviors. However, using SDN it is possible to implement secure end-to-end routing that incorporates an understanding of the security requirements of network participants (e.g., nodes, users), traffic sensitivity (e.g., traffic containing personally identifiable information), and, most importantly in the context of heterogeneous SDN, knowledge of available paths (e.g., wired links, wireless links, security capabilities of nodes). For these reasons, SDN is appealing for managing heterogeneous networks where the controller has global awareness and the decision-making ability to establish such end-to-end paths with security as an explicit objective.

However, as demonstrated in this review, this is an emerging domain of research and requires further investigation. A general review of heterogeneous SDN is required to understand the current state of the art. This review should consider the benefits and challenges of security for SDWN, as to date this has largely been limited to specific technology domains (e.g., IoT, WSN).

9.4. Trust-Based Methods

A third significant theme that has emerged through this review is trust. There is growing interest in trust as an intuitive and explainable framework for making networking and security decisions. Of relevance to this paper, trust has been applied to support adaptive routing that negotiates a secure end-to-end path based on the assessed trustworthiness of nodes and links along available paths. This is referred to in this paper as trust-based routing. It is a highly promising direction for future research, especially in heterogeneous SDN, where the paths between any two given endpoints may represent a diversity of communications media, supported protocols, and security challenges. Furthermore, trust-based routing provides a framework for realizing security requirements by mapping security requirements to decisions and actions based on trust and the assessed trustworthiness of nodes, links, and potentially whole domains and networks.

Unfortunately, there is no widely accepted definition of trust in security, and it is frequently conflated with security as a state (i.e., if something is secure it is trustworthy). Some researchers have provided complete trust frameworks for particular domains, such as IoT [318], but there remains potential for a complete, extensible, and scalable trust framework for heterogeneous SDN. We provide a rudimentary view of this in [299], albeit under limitations imposed by OpenFlow and the need for evaluation in simulation versus implementation. As a result, there is a need for a complete trust management framework for SDN and the implementation of a defensible trust management system based on said framework. This framework should include algorithms for trust assessment and the computation of secure end-to-end paths based on trust (i.e., trustworthy paths). Additionally, experimental validation should be provided using a proof-of-concept implementation.

9.5. Other Issues

Finally, several other issues in the existing research have been identified through this review. These issues provide the opportunity for future research that addresses a specific deficit in the current state of the art for SDN data plane security.

Firstly, there is a detrimental focus on availability and specifically on DoS/DDoS attacks in SDN security literature, including for the data plane. This is essentially a ‘low hanging fruit’ problem that manifests due to the lack of native security in OpenFlow. By default, OpenFlow supports no authentication of devices, provides no encryption, and, importantly for DoS/DDoS, provides no convenient method for rejecting malicious and non-compliant messages without processing. Future security research in SDN should assume that the industry will soon solve these issues in subsequent specifications of the OpenFlow or other southbound-interface protocols.

Secondly, monitoring and observability are notable issues for SDN and specifically for the SDN data plane. Currently, SDN security researchers inherit existing approaches to monitoring and observability from traditional networks, or, alternatively, they implement monitoring and observability specific to their application. Evidently, there is a gap in domain-specific monitoring and observability for SDN and SDN devices. Future research should address this gap by developing meaningful security and network events and metrics specific to SDN.

Thirdly, the security of P4 is underinvestigated. This is surprising, given the substantial research interest that P4 has attracted in the last decade. However, existing P4 security research has consistently been application-focused, rather than concerned with the security of the P4 architecture or P4 devices. A comprehensive threat model for P4 is required and novel attacks on P4 devices should be investigated to understand tactics, techniques, and procedures that may be effective against networks and systems utilizing P4.

Finally, software security for SDN is underinvestigated. To date, security researchers have implicitly adopted existing software security methodologies and practices for SDN [61]. However, the appropriateness of this has yet to be meaningfully investigated. An SDN-based view of the Software Development Lifecycle (SDLC) should be developed to define best practice for software development for SDN. A threat model for network software and firmware in SDN should be developed to understand the security threats that exist, as well as to act as an input to the SDN SDLC. Lastly, application security techniques and controls for SDN should be investigated.

10. Conclusions

Security of the SDN data plane has been the subject of growing research attention over the last decade. There is a clear impetus for detailed investigation into both the security of and security for the SDN data plane as a potential technology for supporting the increasingly complex enterprise and telecommunications networks of the future.

However, most work to date is focused just on the security capabilities within the data plane, the security of the data plane infrastructure, and dynamic routing within the data plane. This paper has demonstrated emerging trends that serve to highlight and expound under-investigated domains, including data plane security for hybrid SDN and heterogeneous SDN and trust-based methods for data plane security.