DDoS Defense Strategy Based on Blockchain and Unsupervised Learning Techniques in SDN

Abstract

With the rapid development of technologies such as cloud computing, big data, and the Internet of Things (IoT), Software-Defined Networking (SDN) is emerging as a new network architecture for the modern Internet. SDN separates the control plane from the data plane, allowing a central controller, the SDN controller, to quickly direct the routing devices within the topology to forward data packets, thus providing flexible traffic management for communication between information sources. However, traditional Distributed Denial of Service (DDoS) attacks still significantly impact SDN systems. This paper proposes a novel dual-layer strategy capable of detecting and mitigating DDoS attacks in an SDN network environment. The first layer of the strategy enhances security by using blockchain technology to replace the SDN flow table storage container in the northbound interface of the SDN controller. Smart contracts are then used to process the stored flow table information. We employ the time window algorithm and the token bucket algorithm to construct the first layer strategy to defend against obvious DDoS attacks. To detect and mitigate less obvious DDoS attacks, we design a second-layer strategy that uses a composite data feature correlation coefficient calculation method and the Isolation Forest algorithm from unsupervised learning techniques to perform binary classification, thereby identifying abnormal traffic. We conduct experimental validation using the publicly available DDoS dataset CIC-DDoS2019. The results show that using this strategy in the SDN network reduces the average deviation of round-trip time (RTT) by approximately 38.86% compared with the original SDN network without this strategy. Furthermore, the accuracy of DDoS attack detection reaches 97.66% and an F1 score of 92.2%. Compared with other similar methods, under comparable detection accuracy, the deployment of our strategy in small-scale SDN network topologies provides faster detection speeds for DDoS attacks and exhibits less fluctuation in detection time. This indicates that implementing this strategy can effectively identify DDoS attacks without affecting the stability of data transmission in the SDN network environment.

1. Introduction

In today’s rapidly evolving landscape of internet technology, the demand for flexibility and efficiency in network architecture is becoming increasingly prominent. As a significant transformation in the field of networking, Software-Defined Networking (SDN) [1] has emerged. This network architecture is designed based on the separation of the data forwarding plane and the control plane. This separation expands the possibilities for network design and management, consolidating the myriad operations required for network control into a software component known as the SDN controller. By employing centralized control, SDN significantly simplifies the execution of new services, the selection of management policies, and the reconfiguration of networks from a software perspective. Within the SDN network topology, the control plane is connected to the SDN controller through the northbound interface. Upper-layer applications in the control plane can send commands and requests to the SDN controller. The SDN controller, in turn, communicates with the data plane via the southbound interface, sending control commands to network devices within the plane and receiving various status information from them. This network architecture, built by SDN, is a programmable network [2]. Currently, there are many mature network protocols developed based on SDN, with the OpenFlow protocol being one of the most common [3].

Distributed Denial of Service (DDoS) attacks disrupt legitimate user access by sending a large volume of malicious data packets and depleting available resources across compromised nodes [4]. Research has shown that the decoupled control model of SDN allows users and upper-layer applications greater control over the network [5], but it still faces significant threats from DDoS attacks. DDoS attacks target SDN networks by exhausting the flow table caches of switches, depleting controller resources, or blocking link bandwidth within the SDN topology. The increasing threat of DDoS attacks to network operators and internet service providers highlights its status as one of the most challenging issues in the field of network security, with no perfect solution currently available [6]. Particularly with the development of the 5G era, the exponential growth in the number of devices in the network poses a substantial threat to DDoS defense. Therefore, researching how to defend against DDoS in SDN is of great significance.

This paper builds upon our earlier work presented in [7], where we initially introduced a dual-layer DDoS defense strategy leveraging blockchain technology to enhance the security of SDN. While the paper established the feasibility of integrating blockchain and machine learning algorithms in SDN network topologies, it lacked a detailed investigation into the scalability of SDN networks, focusing solely on accuracy as a research metric, which made the evaluation somewhat limited. Furthermore, the original smart contract design exhibited efficiency bottlenecks under high-load scenarios, which affected system performance. In this paper, we further discuss the aforementioned issues, conduct a comparative analysis of our approach with similar algorithms and related strategies, and perform an in-depth study incorporating the latest developments in the field.

Existing SDN DDoS defense technologies have inherent limitations, highlighting the urgent need for new methods to combat DDoS attacks. With the development of new technologies, the widespread application of blockchain technology offers new perspectives for inter-domain collaboration in SDN network topologies [8]. Blockchain technology [9], which integrates a series of existing technologies such as cryptography, Merkle trees, and consensus mechanisms, provides a robust foundation for collaborative defense against DDoS attacks due to its decentralization, data security protection, data sharing capabilities, and distributed nature [10]. Its basic principle is as shown in Figure 1. As shown in the figure, a blockchain is composed of a series of linked blocks, each consisting of a block header and a block body. The block header includes the hash of the previous block, a timestamp, a nonce, and the Merkle root of the transactions. This structure ensures data integrity, traceability, and efficient verification of transactions through the Merkle tree. It enables the automated, distributed sharing of data, facilitating data sharing in trustless networks. Blockchain technology addresses the challenges of data sharing and trust issues among multiple domains [11]. Smart contracts [12] are used to define “protocols executed by various parties”, converting agreements among contract participants into rules written in code. They are reusable, modular, and automatically executed scripts running on the blockchain. Blockchain can leverage smart contracts and its inherent consensus mechanisms to solve cross-domain information exchange challenges and has proven effective in providing decentralized collaboration in trustless network environments. Blockchain technologies, such as Bitcoin, Ethereum, and distributed ledgers, have demonstrated high levels of security and transparency across various fields, and their application in SDN networks for DDoS defense holds significant potential for development [13].

In the field of DDoS defense for SDN network topologies, existing works mainly focus on two key aspects: (i) ensuring the security of network information storage, and (ii) detecting suspicious attack sources. Among these, the detection of suspicious attack sources often employs learning algorithms, including unsupervised learning and deep learning algorithms. By analyzing datasets, these methods identify suspicious attack addresses for defense, resulting in diverse approaches due to the different algorithms used. For the security of network information storage, unlike traditional information storage approaches, the recent development of blockchain technology has led to attempts to leverage its high-security attributes to address the shortcomings of conventional network information storage solutions [14]. Blockchain is often used to store blacklists and whitelists of attack source addresses. While this method can effectively prevent the forwarding of attack source data, it may still present issues of subjective settings. Therefore, this work proposes a dual-layered strategy combining blockchain and unsupervised learning algorithms. This approach not only ensures security but also proactively detects suspected attack sources. The contributions of this work are as follows:

• To address DDoS attacks, we propose utilizing the high-performance consortium blockchain FISCO BCOS as a container for storing SDN flow tables at the northbound interface of Pox-based SDN switches. We design a cross-domain data flow transmission scheme based on smart contracts, which enhances the security of flow table storage while satisfying the high-frequency access requirements of the SDN controller. This approach ensures that data storage security becomes an integral part of our DDoS attack defense strategy, under the premise of minimizing the impact on the flow table forwarding efficiency within the SDN network topology.
• We consider DDoS attack detection as a binary classification problem, categorizing data transmissions in SDN networks into two classes: benign network flows and malicious network flows. To simulate real-world scenarios as closely as possible, we use the public DDoS dataset CIC-DDoS2019 as data support for attack source data. This dataset contains 77 statistical features based on network flows from 11 different types of DDoS attacks. We propose a composite feature selection method that utilizes Recursive Feature Elimination, Random Forest, and Mutual Information to calculate correlation coefficients and perform correlation ranking on the data. This method determines seven highly correlated data features within a data flow for attack source detection.
• Malicious network flows are divided into two categories: easily detectable and difficult-to-detect. A two-tier defense method is proposed to address both types. The first tier combines time series analysis and the token bucket algorithm to monitor the frequency of network flow access, thereby defending against easily detectable attacks. The second tier employs the Isolation Forest algorithm, an unsupervised machine learning technique, to calculate anomalies based on seven highly correlated data features identified in the data flows stored on the blockchain, thus detecting difficult-to-detect attacks. Compared with similar defense strategies, the proposed method ensures high accuracy while reducing detection time.

In contrast, by leveraging blockchain’s immutability and the automated execution capabilities of smart contracts, we ensure that once a flow record or detection result is written to the blockchain, it cannot be arbitrarily modified, deleted, or canceled by any untrusted management party, including malicious entities or compromised system components. Smart contracts also enable automated responses—such as triggering alerts or updating access policies—based on detection outcomes without human intervention. These capabilities are critical to ensuring the reliability, traceability, and responsiveness of our proposed dual-layer DDoS defense system. Therefore, blockchain is not merely a supplementary technology in our design, but a foundational element for achieving trustworthy and verifiable network security in SDN environments.

2. Related Work

In this section, we present the existing works on DDoS attack defense in SDN networks. Amezcua Valdovinos et al. [15] summarized the SDN network architecture and provided an overview of the research work and challenges in addressing DDoS attacks within the SDN domain. From this review, it is evident that the DDoS defense strategies in SDN networks, inheriting the approaches from traditional DDoS attack defenses, also encompass multiple angles. Here, we categorize them into two main parts: the security of network information storage and the detection of suspicious attack sources.

In enhancing the security of network data storage, blockchain technology has been rapidly developed and integrated to extend traditional network information storage methods. Gao et al. [16] proposed a blockchain-based data sharing framework that combines SDN and proxy re-encryption (PRE) technology to address data security and privacy issues in DDoS attacks. Núñez-Gómez et al. [17] introduced an enhanced distributed resource allocation and access control framework called S-HIDRA, which ensures the integrity and security of data exchange processes by integrating blockchain technology, thereby improving resource management efficiency in distributed systems. Zeng et al. [18] utilized blockchain to establish global trust relationships and proposed a reputation evaluation mechanism to ensure secure routing, though the definition of reputation values may involve some subjectivity. Regarding the detection of suspicious attack sources, Ma et al. [19] proposed a DDoS attack detection algorithm that uses heterogeneous integrated feature selection and Random Forest algorithms. However, the Random Forest algorithm, as a supervised learning algorithm in machine learning, demands significant computational resources. Marvi et al. [20] proposed a method that combines feature selection and extraction using unsupervised machine learning techniques to detect various types of DDoS attacks.

Additionally, considering the attempt to integrate both aspects, Lian et al. [21] proposed FRChain, a blockchain-based SDN data forwarding security scheme that ensures the security of SDN data forwarding by storing flow rules in the blockchain. This scheme uses a voting mechanism among nodes to detect suspicious nodes in the network; however, the voting process is time-consuming and cannot respond to attacks in real time. Jian et al. [22] proposed an information-theoretic DDoS detection method that utilizes smart contracts in the blockchain, where the blockchain serves to record blacklists and whitelists, which may involve some subjective settings. Li et al. [23] introduced the blockCSDN framework for information management and intrusion detection in SDN networks, with the blockchain also playing a role in maintaining blacklists and whitelists, again involving some degree of subjective settings.

Overall, current defenses against DDoS attacks in SDN networks tend to treat data storage security and attack source detection as separate concerns. Existing approaches that attempt to integrate the two are still in preliminary stages and lack detailed explanations on how to overcome the inherent limitations of blockchain technology, such as low read-write efficiency. In light of the current research status, we directly introduce blockchain to store network flow table information in SDN networks and integrate machine learning algorithms for proactive attack source detection. A comparison of related works is given in

Table 1. Comprehensive comparison of DDoS defense strategies in SDN.

Literature	Security of Storage	Active Detection	ML/DL	Methodology
Gao et al. [16]	√	−	−	Blockchain and proxy encryption
Núñez-Gómez et al. [17]	√	−	−	BS-HIDRA blockchain architecture
Zeng et al. [18]	√	−	−	Blockchain-based secure routing
Ma et al. [19]	−	√	√	Heterogeneous feature selection + RF
Marvi et al. [20]	−	√	√	Augmented K-means clustering
Lian et al. [21]	√	√	−	FRChain with voting mechanism
Jian et al. [22]	√	√	−	Hybrid entropy and blockchain
Li et al. [23]	√	√	−	BlockCSDN framework
Hassan et al. [24]	−	√	√	Entropy-based detection with ML
Saiyed and Al-Anbagi [25]	−	√	√	Genetic algorithm with t-test
Ma et al. [19]	−	√	√	Edge computing with Random Forest
Arvind and Radhika [26]	−	√	√	XGBoost-based detection
Hamarshe et al. [27]	−	√	√	Multiple ML models comparison
Butt et al. [28]	−	√	√	Ensemble RF + XGBoost
Our proposed	√	√	√	Dual-layer: blockchain + Isolation Forest

.

3. System Model and Problem Formulation

In this section, we describe the problem, introduce the system model, symbols, and concepts used in this paper, and formally define the problem. For ease of reference, the symbols used in the paper are summarized in

Table 2. Summary of notations.

Notation	Definition
$MA{C}_i$	Source MAC address
t	Timestamp
T	Time window length
$f(MA{C}_i,t)$	Frequency of $MA{C}_i$ at time t
$\theta$	Anomaly threshold
$B_t$	Number of tokens in the bucket at time t
R	Token generation rate
$D_i$	Number of data packets to be forwarded by $MA{C}_i$
$\mathbf{F}$	Feature set
$X_{\mathrm{score}}$	Feature importance score
$w_i$	Weight of the i-th feature selection method
$S_i\left(f\right)$	Importance score of feature f from the i-th feature selection method
$d_i$	i-th data point
$h\left(d_i\right)$	Average path length of sample $d_i$
$s\left(d_i\right)$	Isolation score of sample $d_i$
$\tau$	Isolation score threshold
$\theta$	Classification threshold
$c\left(m\right)$	Normalization constant
$H\left(i\right)$	i-th harmonic number
$\gamma$	Euler constant

.

3.1. Problem Description

The SDN network environment is susceptible to DDoS attacks, which include not only easily detectable attacks like flooding attacks but also more subtle ones. These attacks can occupy resources with malicious packets, disrupt access for legitimate users, exhaust switch flow table caches, deplete controller resources, or congest link bandwidth, posing significant threats to the network’s stability and security. Traditional defense methods still exhibit various shortcomings in addressing the complexity and variability of DDoS attacks. To overcome these challenges, it is crucial to develop a new defense mechanism capable of effectively detecting and mitigating DDoS attacks while ensuring the stability and efficiency of the SDN network. Therefore, a novel double-layered defense strategy integrating blockchain technology and unsupervised learning algorithms is proposed, leveraging the prominent security features and rapid development of blockchain technology.

3.2. System Model

Our proposed strategy for mitigating DDoS attacks is divided into two main parts: (1) the processing of flow table data using blockchain technology, and (2) the DDoS detection strategy. The detection in the second part relies on the storage and processing of data information in the first part. Together, these components form the overall double-layered defense strategy. The structure is illustrated in Figure 2. Both the blockchain and detection algorithm are implemented at the northbound interface of the SDN controller. The SDN controller invokes them to transmit data packets to the switches in the data plane.

3.2.1. The Processing of Flow Table Data Using Blockchain Technology

The northbound interface of the SDN controller interacts with the blockchain. As shown in Figure 2, this interaction through blockchain APIs allows the SDN controller to securely store and manage flow tables. Each SDN controller’s topology is represented as a blockchain, where each node in the blockchain corresponds to a switch in the topology. Smart contracts are deployed on the blockchain to manage the flow tables, ensuring the secure and transparent storage of flow rules. These smart contracts perform several functions, including authorizing the SDN controller, updating local flow table information, and verifying participant access permissions. The decentralized nature of the blockchain provides a secure environment for flow table data, preventing unauthorized access and tampering, thereby enhancing the overall security and reliability of the SDN network. We chose the FISCO BCOS blockchain due to its efficient transaction processing, low latency, high security, and strong support for consortium-based deployments.

Furthermore, the immutability of the blockchain ensures that once flow table entries are recorded, they cannot be tampered with or deleted, effectively preventing malicious modifications or unauthorized overwrites. This property directly enhances the stability and reliability of the SDN control plane, as the controller can always retrieve consistent and verifiable flow rule data even in the event of component failures or malicious attacks.

3.2.2. The DDoS Detection Strategy

The first layer strategy utilizes time series analysis and the token bucket algorithm to detect and mitigate obvious DDoS attacks. This algorithm sets thresholds based on the frequency of certain features (such as source MAC addresses) forwarded within a specified time period, limiting the data forwarding rate from suspicious sources. By continuously reading network flow data stored in the blockchain over a period of time, the frequency of certain features is analyzed to identify potential DDoS attack sources. The token bucket algorithm is then applied to limit the data volume generated by these suspicious sources, ensuring that normal data flow remains unaffected.

Obvious DDoS attacks typically exhibit high traffic volumes and frequent repeated requests from specific sources within a short time frame, making them relatively easy to identify through threshold-based methods. These attacks often rely on overwhelming the network bandwidth or controller processing capacity, resulting in significant and abrupt changes in traffic patterns. In contrast, stealthy or subtle DDoS attacks are characterized by low-rate, distributed, and camouflaged traffic that closely resembles legitimate behavior. These attacks are harder to detect using simple statistical methods and require deeper analysis of flow features and behavioral patterns. To effectively defend against both types of threats, our system adopts a two-layer detection strategy tailored to their respective characteristics.

The second-layer strategy employs a composite feature selection approach composed of the Mutual Information algorithm, Random Forest algorithm, and Recursive Feature Elimination method to preprocess the stored flow information. This process determines the optimal number of data feature values and detection sequence. It then uses the Isolation Forest algorithm, an unsupervised machine learning technique, to detect subtle DDoS attacks. Finally, the token bucket algorithm is applied again to suppress data forwarding from the detected attack source addresses.

3.2.3. Verification System

In this subsection, the validation and evaluation of this strategy are divided into two parts: deployment stability and detection performance. The following sections will define and elaborate on each of these aspects separately.

Deployment Stability of the Strategy: Ensuring the stability of strategy deployment is crucial to prevent interference with the normal operation of the SDN network. We measure this stability using the mean deviation (mdev) of the round-trip time (RTT) of packets. A lower deviation indicates higher stability. The mdev value represents the average deviation of the packet round-trip times. This value is calculated by collecting RTT samples $RT{T}_i$, computing their average, $\overline{RTT}$, determining the absolute deviation of each sample from the average, $\left|RT{T}_i-\overline{RTT}\right|$, and then computing the mean of all absolute deviations to obtain the mdev. The calculation formula for this metric is

$$\mathrm{mdev}={\displaystyle \frac{1}{N}}\sum _{i=1}^N\left|RT{T}_i-\overline{RTT}\right|$$

(1)

In terms of scalability, we also tested the stability of strategy deployment. We incrementally increased the number of switches in the SDN network topology, as well as the number of hosts connected to each switch. After each topology change, we recorded the time taken by the SDN controller using our strategy to regulate data transmission within the topology. We used the time required for a ping_all operation as the evaluation metric. The calculation formula for this metric is

$$T_{\mathrm{ping}\_\mathrm{all}}=\sum _{i=1}^N\sum _{\begin{array}{c}j=1\\ j\ne i\end{array}}^N{T}_{\mathrm{ping}}(h_i,h_j)$$

(2)

Here, $T_{\mathrm{ping}\_\mathrm{all}}$ represents the total time required for all hosts to ping each other, N is the total number of hosts, and $T_{\mathrm{ping}}(h_i,h_j)$ is the time taken for host $h_i$ to successfully ping host $h_j$. By measuring $T_{\mathrm{ping}\_\mathrm{all}}$, we can assess the efficiency and scalability of data transmission regulation by the SDN controller under our strategy. A shorter $T_{\mathrm{ping}\_\mathrm{all}}$ indicates a more stable system.

$$\mathrm{F}1=2·{\displaystyle \frac{\mathrm{Pre}·\mathrm{Rec}}{\mathrm{Pre}+\mathrm{Rec}}}$$

(3)

In Equation (3), $Pre$ is precision. It represents the proportion of instances identified as positive that are actually positive. A higher precision indicates fewer normal traffic instances are misclassified as abnormal, thereby reducing unnecessary interference. Its calculation formula is

$$\mathrm{Pre}={\displaystyle \frac{TP}{TP+FP}}$$

(4)

$Rec$ in Equation (3) is recall. It measures the proportion of positive instances that are correctly identified as positive. Recall is used to evaluate the comprehensiveness of the classification model. A higher recall indicates fewer abnormal traffic instances are missed, thereby enhancing the reliability and security of the defense system. Its calculation formula is

$$\mathrm{Rec}={\displaystyle \frac{TP}{TP+FN}}$$

(5)

The aforementioned validation system clearly measures the usability of the proposed strategy. The detailed validation process is specifically described in the Experimental Results and Discussion section.

3.3. Problem Formulation

This subsection elucidates the dual-layer DDoS detection strategy involved in this paper, providing clear mathematical definitions.

3.3.1. The First-Layer Defense Strategy

The first-layer defense strategy includes the time window algorithm and the token bucket algorithm, which are used to detect and suppress easily detectable attacks. Initially, data modeling involves extracting network traffic features. Suppose we have a flow table dataset containing network traffic information, where each row represents a network flow record. We extract the following features: source MAC address ($MA{C}_i$) and timestamp (t).

The time window algorithm is used to analyze the frequency of specific features in network traffic. Within a time window, the algorithm calculates the occurrence frequency of each source MAC address. Define the time window length as T. For the i-th source MAC address ($MA{C}_i$), the frequency of $MA{C}_i$ at time t is denoted as $f(MA{C}_i,t)$. Within the time window T, the frequency $f(MA{C}_i,t)$ is calculated, and the frequency values are accumulated to obtain the total frequency $F\left(MA{C}_i\right)$ of the time window. The calculation formula for the frequency $f(MA{C}_i,t)$ is

$$f(MA{C}_i,t)={\displaystyle \frac{N_i\left(t\right)}{N\left(t\right)}}$$

(6)

In this context, $N_i\left(t\right)$ represents the number of packets from $MA{C}_i$ at time t, and $N\left(t\right)$ represents the total number of packets at time t. After accumulating the frequency values, the total frequency within the time window is obtained:

$$F\left(MA{C}_i\right)=\sum _{t=t_0}^{t_0+T}f(MA{C}_i,t)$$

(7)

For any time t, calculate the occurrence frequency $F\left(MA{C}_i\right)$ of the source MAC address within the time window $[t-\Delta t,t]$. Set an anomaly threshold value $\theta$ for the network environment of the SDN topology. If $F\left(MA{C}_i\right)>\theta$, the packet is considered to originate from a DDoS attack source.

The token bucket algorithm is used to limit the data volume generated by these suspicious attack sources, ensuring that the forwarding of normal data flow is not affected. Define the number of tokens in the bucket at the current time t as $B_t$, the number of tokens in the bucket at the previous time $t-1$ as $B_{t-1}$, the token generation rate (number of tokens generated per second) as R, the time interval between the current time and the last token bucket update as $\Delta t$, and the number of data packets to be forwarded by a certain attack source $MA{C}_i$ as $D_i$. The number of tokens in the token bucket increases over time:

$$B_t=B_{t-1}+R\times \Delta t$$

(8)

If the number of data packets $D_i$ that need to be forwarded by a certain attack source $MA{C}_i$ exceeds the current number of tokens in the token bucket $B_t$, then some data packets are discarded to ensure that the forwarded data volume does not exceed the number of tokens in the token bucket, such that $D_i\le B_t$.

3.3.2. The Second-Layer Defense Strategy

The second-layer defense strategy combines a composite feature selection algorithm and the Isolation Forest algorithm to detect less identifiable DDoS attacks. First, the composite feature selection algorithm preprocesses the network flow information stored in the blockchain to determine the optimal number of data feature values and their detection order. Let the feature set be $\mathbf{F}$$= \{f_1,f_2,\dots ,f_n\}$, where $f_i$ represents the i-th feature. The composite feature selection algorithm calculates the feature importance scores:

$$X_{\mathrm{score}}=\sum _{i=1}^n{w}_i·S_i\left(f\right)$$

(9)

Here, $w_i$ represents the weight of the i-th feature selection method, and $S_i\left(f\right)$ represents the importance score of feature f according to the i-th feature selection method. To avoid excessive subjectivity in the selection of $w_i$, a normalization process is used for adjustment. The calculation for the normalized feature value coefficient is

$$w_i={\displaystyle \frac{S_i\left(f\right)-S_{\min }}{S_{\max }-S_{\min }}}$$

(10)

where $S_{\max }$ and $S_{\min }$ represent the maximum and minimum scores of the feature selection methods, respectively.

The final normalized feature importance scores calculated by the composite feature selection algorithm are

$$X_{\mathrm{score}}=\sum _{i=1}^n{\displaystyle \frac{S_i\left(f\right)-S_{\min }}{S_{\max }-S_{\min }}}·S_i\left(f\right)$$

(11)

The Isolation Forest algorithm is used for anomaly detection. Its basic idea is that anomalies are easier to isolate. The Isolation Forest algorithm constructs multiple random trees (Isolation Trees) to recursively partition the data and compute an isolation score for each sample.

Let the dataset be $\mathbf{D}=\{d_1,d_2,\dots ,d_m\}$, where $d_i$ represents the i-th data point. The number of trees is t, the average path length of sample $d_i$ is $h\left(d_i\right)$, the isolation score of sample $d_i$ is $s\left(d_i\right)$, and the isolation score threshold is $\tau$. The algorithm trains on the dataset $\mathbf{D}$ using t trees. Each tree randomly selects features and thresholds to recursively partition the dataset. The average path length $h\left(d_i\right)$ for each sample $d_i$ is then calculated, representing the number of steps needed to reach a leaf node from the root node. Finally, the isolation score $s\left(d_i\right)$ is derived using

$$s\left(d_i\right)=2^{-{\displaystyle \frac{h\left(d_i\right)}{c\left(m\right)}}}$$

(12)

where $c\left(m\right)$ is a normalization constant determined by the dataset size m:

$$c\left(m\right)=2H(m-1)-\left({\displaystyle \frac{2(m-1)}{m}}\right)$$

(13)

$H\left(i\right)$ represents the i-th harmonic number:

$$H\left(i\right)=ln\left(i\right)+\gamma$$

(14)

where $\gamma$ is the Euler constant, approximately 0.577. If $s\left(d_i\right)$ exceeds the set threshold $\tau$, $d_i$ is considered an anomaly.

Define the classification threshold $\theta$. When the isolation score $s\left(d_i\right)$ exceeds the threshold $\theta$, the sample $d_i$ is considered an anomaly; otherwise, it is considered normal:

$${\widehat{y}}_i=\left\{\begin{array}{cc}1\hfill & \mathrm{if}s\left(d_i\right)>\theta \hfill \\ 0\hfill & \mathrm{if}s\left(d_i\right)\le \theta \hfill \end{array}\right.$$

(15)

The classification threshold $\theta$ is determined by calculating the F1 score. First, the Precision and Recall curves are plotted against different threshold values. Then, using the F1 score formula (Equation (3)), the F1 score is calculated for each threshold by iterating through different threshold values. The threshold that corresponds to the highest F1 score is selected as the final classification threshold $\theta$.

4. Detailed Methodology

This section will provide a detailed overview of the proposed strategy for mitigating DDoS attacks, which is mainly divided into two parts: the handling of flow table data by blockchain and DDoS detection algorithms.Complete workflow of the dual-layer defense mechanism is illustrated in Figure 3.

At the northbound interface of SDN, we deploy the FISCO BCOS consortium blockchain. Inter-domain smart contracts are utilized to collect relevant information about data within periodic intervals. Intra-domain, the first layer of mitigation strategy, detects obvious flood-type DDoS attacks. The second layer of mitigation strategy, incorporating the Isolation Forest algorithm, is used to detect less perceptible DDoS attacks.

4.1. Flow Table Data Processing

Similar to the traditional routing and forwarding process, in SDN network topology, when the data plane sends forwarding data requests to the SDN controller through the southbound interface, the SDN controller also needs to access the flow table to accurately control the data plane to complete a forwarding action. In this work, we deploy the FISCO BCOS [29] consortium blockchain and deploy contracts to it. Then, specific SDN controllers are authorized and authenticated within the blockchain. After successful authentication, the authorized SDN controllers interact with the FISCO BCOS client through blockchain APIs at the northbound interface to store flow table information. The utilization of blockchain in the collaboration process enables transparency and openness. In summary, smart contracts [30] should fulfill the following functions:

• The owner of the smart contract needs to possess the capability to determine whether a participant is authorized to access the blockchain.
• Authorized participants of the contract can update local flow table information.

This work proposes a specific smart contract design. Smart contracts are implemented using the Solidity programming language.

Table 3. Variables in the smart contract.

Variables	Explanation
user	Types of accounts for external participants
collaboratorsAddr	Addresses of collaborative strategy participants
collaborators	The set of mappings from the addresses of collaborating participants to the corresponding structures
data	A network data message
index	Refers to the serial number of the target object
values	An array to store all string values
fixedLength	The fixed length of the input value for comparison
storedValue	A value from the array to be compared with the input value
prefix	The extracted part of the stored value for comparison

lists variables that can only be contracted and their corresponding explanations.

IsCollaborator(user): The main role of this function takes the account of an external participant (i.e., user) as input to determine whether the external account is authorized and verified. If the participant’s account exists in the smart collaboration contract, it returns true; otherwise, it returns false. This function’s algorithm can be found in Algorithm 1.

Algorithm 1 IsCollaborator—Collaborator Verification Function.

Input: user—External participant’s account address Output: Boolean—true if authorized, false otherwise Function: Validates external account’s blockchain access permission 1: if $\mathrm{length}\left(\mathrm{caddr}\right)==0$ then 2:     return False 3: else 4:    if $\mathrm{caddr}\left[\mathrm{co}\left[\mathrm{user}\right].\mathrm{index}\right]==\mathrm{user}$ then 5:        return True 6:    else 7:        return False 8:    end if 9: end if

In the blockchain, data is stored in string format, with each storage entry represented as a string. The smart contract contains an array to store all these string values. The initial value “0,0” represents the default placeholder for various flow table entry attributes, such as the MAC address and timestamp.

GetKeyOrValue(parameter): This function serves both to retrieve data entries from the storage array at a specified index and to find the index position corresponding to a given value in the storage array of the blockchain. The method accepts a single input parameter, which can be either an unsigned integer or a string. When this method is called, it first checks the type of the input parameter. If the parameter is of type unsigned integer, it checks whether the provided index is within the valid range of the array. If the index is valid, it returns the data entry at the corresponding position in the storage array values. If the index is out of range, it returns an error message indicating that the index is out of range. If the parameter is of type string, the method traverses the storage array values and compares the prefix part of each stored value with the input value. It calculates the fixed length of the input value and then compares it with the prefix part of each stored value. If a match is found, it returns the corresponding index position. If the entire array is traversed without finding a matching value, it returns an error message indicating that the value was not found. Through this combined approach, the function ensures accurate data retrieval and localization in the blockchain, enhancing flexibility in managing data entries. This function’s algorithm can be found in Algorithm 2.

Algorithm 2 GetKeyOrValue—Bidirectional Data Retrieval Function.

Input: queryType (string), key (uint) or value (string) Output: Query result—corresponding value or key, error message if not found Function: Enables bidirectional lookup in blockchain storage 1: if  $\mathrm{queryType}==“\mathrm{key}-\mathrm{to}-\mathrm{value}”$  then 2:    if $\mathrm{key}<\mathrm{length}\left(\mathrm{values}\right)$ then 3:      $\mathrm{result}\leftarrow \mathrm{values}\left[\mathrm{key}\right]$ 4:    else 5:      $\mathrm{result}\leftarrow “\mathrm{Key}\mathrm{does}\mathrm{not}\mathrm{exist}”$ 6:    end if 7: else if $\mathrm{queryType}==“\mathrm{value}-\mathrm{to}-\mathrm{key}”$ then 8:    $\mathrm{fixedLength}\leftarrow \mathrm{byte}\mathrm{length}\mathrm{of}\mathrm{value}$ 9:    $\mathrm{result}\leftarrow “\mathrm{Value}\mathrm{not}\mathrm{found}”$ 10:    for $i\leftarrow 0$ to $\mathrm{length}\left(\mathrm{values}\right)-1$ do 11:      $\mathrm{storedValue}\leftarrow \mathrm{values}\left[\mathrm{i}\right]$ 12:      $\mathrm{storedValueBytes}\leftarrow \mathrm{bytes}\left(\mathrm{storedValue}\right)$ 13:      if $\mathrm{length}\left(\mathrm{storedValueBytes}\right)<\mathrm{fixedLength}$ then 14:         continue 15:      end if 16:      $\mathrm{prefix}\leftarrow \mathrm{first}\mathrm{fixedLength}\mathrm{bytes}\mathrm{of}\mathrm{storedValue}$ 17:      if $\mathrm{keccak}256\left(\mathrm{prefix}\right)==\mathrm{keccak}256\left(\mathrm{value}\right)$ then 18:         $\mathrm{result}\leftarrow i$ 19:         break 20:      end if 21:    end for 22: else 23:    $\mathrm{result}\leftarrow “\mathrm{Invalid}\mathrm{query}\mathrm{type}”$ 24: end if 25: return result

SetOrUpdateString(index, value): This function serves both to update existing data entries and to add new data entries to the storage array in the blockchain. The method accepts two input parameters: an unsigned integer index, representing the position of the data entry to be updated or where the new data entry should be added, and a string value, representing the new data value. When this method is called, it first checks whether the provided index is within the valid range of the array. If the index is valid, it updates the data entry at the corresponding position in the storage array values with the new value. If the index is out of range, the method adds the new data value to the end of the storage array values. By combining the functionalities of updating and adding data entries, this method ensures that specific data entries stored in the blockchain can be flexibly updated or expanded. This approach maintains data consistency and accuracy, while also simplifying the management of the storage array. The function’s algorithm can be found in Algorithm 3.

Algorithm 3 SetOrUpdateString—Dynamic Storage Management Function.

Input: operationType (string), index (uint), newValue (string) Output: Operation result—success or failure message Function: Updates existing entries or appends new data 1: if  $\mathrm{operationType}==“\mathrm{set}”$  then 2:    append newValue to values 3:    $\mathrm{result}\leftarrow “\mathrm{Set}\mathrm{successful}”$ 4: else if $\mathrm{operationType}==“\mathrm{update}”$ then 5:    if $\mathrm{index}\ge \mathrm{length}\left(\mathrm{values}\right)$ then 6:        $\mathrm{result}\leftarrow “\mathrm{Index}\mathrm{out}\mathrm{of}\mathrm{range}”$ 7:    else 8:        $\mathrm{values}\left[\mathrm{index}\right]\leftarrow \mathrm{newValue}$ 9:        $\mathrm{result}\leftarrow “\mathrm{Update}\mathrm{successful}”$ 10:    end if 11: else 12:    $\mathrm{result}\leftarrow “\mathrm{Invalid}\mathrm{operation}\mathrm{type}”$ 13: end if 14: return result

DeleteStringOrClearAll(index, clearAll): This function serves both to delete a specific data entry at a given index and to clear all data entries in the storage array of the blockchain, reinitializing it with a default value. The method accepts two input parameters: an unsigned integer index, representing the position of the data entry to be deleted, and a Boolean clearAll, indicating whether to clear all entries. When this method is called, it first checks the value of clearAll. If clearAll is true, it deletes all entries in the storage array values and reinitializes it with the default value “0,0”. This ensures that the storage array is effectively reset, facilitating scenarios where data clearing and initialization are required. If clearAll is false, the method checks whether the provided index is within the valid range of the array. If the index is valid, it replaces the data entry at the corresponding position with the last element of the array and reduces the array’s length by one, thereby deleting the data entry at the specified index position. Additionally, it triggers a DeleteString event to record the deletion operation. If the index is out of range, it returns an error message indicating that the index is out of bounds. Through this combined approach, the function ensures flexible and efficient management of data entries stored in the blockchain, maintaining data integrity and supporting both targeted deletion and complete reinitialization. This function’s algorithm can be found in Algorithm 4.

Algorithm 4 DeleteStringOrClearAll—Flexible Data Removal Function.

Input: index (uint), clearAll (Boolean) Output: Operation result—success or failure message Function: Removes specific entries or reinitializes storage 1: if  $\mathrm{clearAll}==\mathrm{true}$  then 2:    delete all entries in values 3:    reinitialize values with default “0,0” 4:    $\mathrm{result}\leftarrow “\mathrm{Storage}\mathrm{array}\mathrm{cleared}”$ 5: else 6:    if $\mathrm{index}\ge \mathrm{length}\left(\mathrm{values}\right)$ then 7:        $\mathrm{result}\leftarrow “\mathrm{Delete}\mathrm{failed}\text{:}\mathrm{index}\mathrm{out}\mathrm{of}\mathrm{range}”$ 8:    else 9:         $\mathrm{values}\left[\mathrm{index}\right]\leftarrow \mathrm{values}\left[\mathrm{length}\right(\mathrm{values})\text{-}1]$ 10:        $\mathrm{length}\left(\mathrm{values}\right)\leftarrow \mathrm{length}\left(\mathrm{values}\right)\text{-}1$ 11:        $\mathrm{result}\leftarrow “\mathrm{Delete}\mathrm{successful}”$ 12:    end if 13: end if 14: return result

4.2. Detection Strategy

The first-layer defense strategy: The first layer targets easily detectable DDoS attacks by continuously reading network flow data stored in the blockchain over a period and analyzing the frequency of certain features to determine whether to classify a source as a DDoS attack origin. In this work, the source MAC address and the timestamp stored in the blockchain are used as the data features for analysis. Using a time series algorithm, it is determined whether each data’s timestamp falls within a predefined time interval. The source MAC addresses of the data within this interval are read, and if the occurrence of a specific source MAC address within the same interval exceeds the threshold set according to the network environment of the topology, it is considered a suspected DDoS attack source.

The token bucket algorithm is then used to limit the data generated by this attack source by setting the total number of tokens in the bucket and the token issuance rate (one token allows the attack source to forward one piece of data). This ensures that the normal data flow is not affected. The updating principle for the number of tokens in the token bucket is shown in Equation (8). The number of tokens $B\left(t\right)$ in the token bucket increases each second according to the generation rate R and decreases as data is forwarded. The current token count depends on the token count from the previous second $B_{t-1}$ and the number of new tokens generated during that period. When data needs to be forwarded, if the current token count is sufficient, forwarding is allowed; otherwise, forwarding is restricted to prevent DDoS attacks.

The composite feature selection method: The second-layer strategy targets difficult-to-detect DDoS attacks. To enhance the practicality of our approach, we utilize the CIC-DDoS2019 dataset [31] to support the Isolation Forest algorithm [32] used in the second layer, where binary classification is performed on network flow data. This dataset contains 77 statistical features derived from 11 types of DDoS attacks.

Due to limited computational resources, and considering that the proposed method adopts unsupervised learning to identify anomalous behavioral patterns, we focus on SYN-type attacks as a representative subset for modeling. Since different types of DDoS attacks primarily manifest as variations in the feature space, it is not necessary to design distinct detection mechanisms for each attack type. Therefore, the proposed strategy inherently possesses generalization capability across various forms of DDoS attacks, while maintaining algorithm feasibility and alignment with real-world scenarios.

To reduce the time required for binary classification using the Isolation Forest algorithm and to improve detection accuracy, it is essential to determine which data features should be selected during pre-training with the CIC-DDoS2019 dataset. Here, we propose a composite feature selection method that integrates multiple feature selection algorithms. This method aims to enhance both the robustness and the precision of feature selection by leveraging the strengths of different algorithms. We use three algorithms (see

Table 4. Composite feature selection strategy.

Algorithm	Definition
Mutual Information	Reciprocal information measures how much information the presence/absence of a feature has to make a correct prediction for Y.
Random Forest	The generalization of the model is improved by constructing multiple decision trees to reduce the risk of overfitting a single decision tree.
Recursive Feature Elimination	By recursively training the model and removing unimportant features, the optimal subset of features is selected.

): Mutual Information (MI) [33], Random Forest (RF) [34], and Recursive Feature Elimination (RFE) [35]. The first two are employed to calculate the feature importance scores.

Let $\mathbf{F}=\{f_1,f_2,\dots ,f_n\}$ represent the set of features, where $f_i$ is the i-th feature. The importance score for each feature using MI is calculated as

$$S_{\mathrm{MI}}\left(f_i\right)=I(X;Y)=\sum _{x\in X}\sum _{y\in Y}p(x,y)log\left({\displaystyle \frac{p(x,y)}{p\left(x\right)p\left(y\right)}}\right)$$

(16)

where X represents the feature and Y represents the class labels, and $p(x,y)$ is the joint probability distribution of X and Y. The importance score for each feature using RF is determined by the decrease in node impurity weighted by the probability of reaching that node. For a feature $f_i$, the importance score is calculated as

$$S_{\mathrm{RF}}\left(f_i\right)={\displaystyle \frac{1}{T}}\sum _{t=1}^T\sum _{n\in N_t}{I}_n·p\left(n\right)$$

(17)

where T is the number of trees in the forest, $N_t$ is the set of nodes in tree t that split on feature $f_i$, $I_n$ is the impurity decrease at node n, and $p\left(n\right)$ is the proportion of samples reaching node n.

The RFE method works by recursively removing the least correlated feature and applying the Isolation Forest algorithm for binary classification. Afterward, we test the accuracy of identifying whether each data flow in the training set is an attack source. Ultimately, the set of data features that yields the highest accuracy using the Isolation Forest algorithm will be selected as the detection features for real-time attack identification. The process can be described as follows:

• Calculate the importance score $S_{\mathrm{model}}\left(f_i\right)$ with MI and RF for each feature $f_i$ in $\mathbf{F}$.
• Train a model on the current set of features $\mathbf{F}$.
• Remove the feature $f_j$ with the lowest importance score: $\mathbf{F}\leftarrow \mathbf{F}\setminus \left\{f_j\right\}$.
• Repeat steps 2 to 3 until the desired number of features is reached.

To ensure the comparability of importance scores from different algorithms, we normalize the scores using min-max normalization. The specific calculations are provided in Equations (9)–(11). We obtain the composite importance score for a feature f by combining the normalized scores from MI and RF algorithms. We assign weights to each algorithm. Let $w_{\mathrm{MI}}$ and $w_{\mathrm{RF}}$ be the weights assigned to the MI and RF algorithms, respectively. The composite importance score $S_{\mathrm{com}}\left(f\right)$ is calculated as follows:

$$S_{\mathrm{com}}\left(f\right)=w_{\mathrm{MI}}·S_{\mathrm{MI},\mathrm{norm}}\left(f\right)+w_{\mathrm{RF}}·S_{\mathrm{RF},\mathrm{norm}}\left(f\right)$$

(18)

Based on the composite importance scores, we use the RFE method to recursively remove the least important features, retaining the top k features that yield the highest binary classification accuracy of the Isolation Forest algorithm on the test set after training. The selected feature set ${\mathbf{F}}_{\mathrm{sel}}$ is given by

$${\mathbf{F}}_{\mathrm{sel}}=\{f\in \mathbf{F}\mid S_{\mathrm{com}}\left(f\right)\}$$

(19)

where ${\mathbf{F}}_{\mathrm{sel}}$ represents the top k features with the highest scores. This composite feature selection method ensures that the most relevant features are chosen for DDoS attack detection, enhancing the overall accuracy and robustness of the detection algorithm.

The second-layer defense strategy: After the feature selection algorithms have identified the specific features of a flow table entry that need to be analyzed by the Isolation Forest algorithm, during the operation of the SDN network topology, the SDN controller accesses the flow table information stored on the blockchain at specified intervals. This approach aims to minimize the impact of the flow table evaluation process on the normal forwarding efficiency. The flow table information retrieved from the blockchain at each interval is treated as a new test set, and an anomaly score is calculated for each flow table entry.

Since the Isolation Forest algorithm cannot directly perform binary classification, we need to partition the calculated anomaly scores using a threshold. To this end, during the training phase, in addition to using the composite feature selection algorithm to determine which flow data features the Isolation Forest should use for training, we also established the anomaly score threshold calculated by the Isolation Forest algorithm. Scores higher than the threshold are considered normal traffic, while those lower than the threshold are deemed abnormal traffic (since the training set contains only normal traffic). Specifically, this threshold is determined using the precision–recall (PR) curve by calculating the F1 score as a metric to balance precision and recall, thereby evaluating the classification performance under different thresholds. Finally, we select the threshold that maximizes the F1 score as the optimal threshold for dividing anomaly scores into normal and abnormal traffic.

5. Experimental Results and Discussion

In this section, we set up an SDN topology and monitor the ping connectivity between hosts to evaluate the impact of our defense strategy on SDN switch performance. For DDoS attack detection, the first layer of defense can effectively identify flooding attacks that exceed predefined thresholds. To assess the effectiveness of the second-layer defense against more subtle and difficult-to-detect attacks, we simulate these using the CIC-DDoS2019 dataset. Specifically, 70% of the dataset is used for training the detection algorithm employed in the second-layer defense, while the remaining 30% serves as the test set. The test set is stored in batches on the SDN controller’s blockchain to emulate flow table entries within the network topology.

This 70/30 split, commonly adopted in machine learning, provides a balanced trade-off between sufficient training data for robust model learning and adequate testing data for objective evaluation of generalization performance. Within our framework, this setup enables the Isolation Forest algorithm to learn normal traffic patterns effectively, while the test data ensures realistic evaluation under SDN operational conditions. This methodology allows us to assess whether the controller, through the second-layer defense mechanism, can accurately detect anomalous network flows in real time.

5.1. Simulation Environment and Network Topology

This study is conducted on the Ubuntu 20.04 system, using Mininet 2.3.0 [36] as the environment simulation tool for building network topologies. We chose the Pox [37] as the controller for SDN and use Scapy as the traffic generation tool to simulate hosts in the SDN network. In Figure 4, our topology consists of 1 FISCO BCOS blockchain, one Pox controller, 3 OpenvSwitch switches, and 6 hosts. Each switch and 2 hosts form an SDN subnet. The SDN controller serves as a node of the FISCO BCOS blockchain, which is built using Python 3.8.10, deploys smart contracts through the WeBASE component, and compiles them using the Solidity languages [38] to form corresponding application ports. When the SDN topology runs for the first time, switches perform broadcast addressing, and the SDN controller records the flow data sent by switches through their ports (including their original MAC addresses, etc.). This information is stored in the blockchain as flow table information. Subsequent data forwarding prioritizes sending requests to the SDN controller to obtain flow table information in order to complete forwarding actions.

5.2. Comparison of Flow Table Data Forwarding with the Original Controller

In this work, we propose a detection and mitigation strategy for DDoS attacks, which mainly affects the normal forwarding process of the controller in the network flow table storage. To assess the extent of this impact, we compare the stability of SDN controllers using our proposed strategy (i.e., the Pox controller integrated with FISCO BCOS blockchain-based flow table storage structure at the northbound interface of the SDN controller) with the original Pox controller that does not use our strategy.

We use the mdev value, representing the mean deviation of round-trip time (RTT) when transmitting data between hosts, as a stability indicator. In the experiments, we conduct 10 sets of comparisons by pinging between two hosts, H1S1 (the host H1 under switch S1) and H2S3 (the host H2 under switch S3), in the same network topology environment. We collect the mdev values from 10 consecutive ping connections between the hosts in each set, resulting in a total of 10 sets of comparisons, and generate a comparison line chart as shown in Figure 5. It is evident that the mdev value of the Pox controller, using blockchain as the flow table storage container, for controlling data transmission in the network topology is generally lower than that of the original Pox controller. The mean mdev value is 0.1122 ms, which is lower than the original Pox’s mean mdev value of 0.1835 ms. The former’s numerical decrease is approximately 38.86% compared with the latter. This is because the strategy employs a consortium blockchain, which is inherently suitable for handling massive data and emphasizes transaction stability. Additionally, our design smart contracts efficiently handle data processing. Therefore, when the SDN controller accesses the blockchain via northbound interfaces, stable access is consistently maintained. As a result, implementing this strategy does not affect normal data forwarding within the topology and may even enhance the stability of network flow transmission to some extent.

5.3. Scalability Testing of SDN Network Topology

In practical application scenarios, the SDN network topology often changes continuously according to user requirements. This necessitates that the defense strategies we deploy on the SDN controller maintain operational stability as much as possible. To detect whether our deployed dual-layer defense strategy affects normal flow table forwarding in network topologies of different scales, we use the time required to complete a ping_all command as the evaluation metric. We conducted experiments by incrementally increasing the number of switches and the number of hosts connected to each switch within the network topology. For each configuration change, we measured the time taken by the SDN controller, equipped with our dual-layer defense strategy, to execute the ping_all command. A shorter ping_all time suggests that the defense strategy does not significantly interfere with normal data transmission.

Our experimental setup involved creating linear topologies with varying sizes using Mininet. We systematically increased the number of switches from $S=1$ to $S=9$ and varied the number of hosts per switch from $H=1$ to $H=5$. For each topology, we compared the ping_all execution time of our modified SDN controller against that of the original controller without any defense mechanisms.

As illustrated in Figure 6, when the number of switches increases from 1 to 3 and the number of hosts connected to each switch also grows, the time taken by the SDN controller deploying our strategy to execute a ping_all operation remains within 3% of that taken by the original Pox controller. The difference is minimal. In the experimental scenario with three switches, a slight decrease in the average one-hop Ping latency was observed when the number of hosts increased from 10 to 12, which deviates from the general trend of increasing latency with a growing number of hosts in other configurations. This anomaly can be primarily attributed to the flow table learning and caching mechanisms of the SDN controller. As the number of communicating host pairs increases, the controller incrementally installs flow entries, leading to a higher flow table hit rate and thus reducing the frequency of subsequent Packet-In requests and overall forwarding latency. Moreover, given the relatively small topology and absence of network congestion at this stage, the system may have entered a transient performance optimization state. It is worth noting that this phenomenon is likely incidental rather than universal, and further studies are needed to assess its consistency and applicability. As the primary purpose of this experiment is to compare forwarding performance with the original controller, an in-depth investigation is beyond the scope of this work.

As illustrated in Figure 7, when the number of switches increases from 4 to 6, even though the number of hosts under each switch continues to rise, the SDN controller with our strategy maintains good forwarding performance. Due to the stable read characteristics of the blockchain, it even outperforms the original POX controller to some extent, effectively managing up to 30 hosts.

As illustrated in Figure 8, when the number of switches increases from 7 to 9, starting from 8 switches, the time required by our strategy-deployed controller to execute the ping_all operation begins to exceed that of the original POX controller.

In summary, scalability testing leads to the following conclusions: in small- to medium-scale SDN network topologies, the blockchain-based flow table protection architecture can maintain high forwarding efficiency and system stability, in some cases even outperforming traditional controller-based approaches. However, in large-scale network topologies, while blockchain storage offers enhanced data security and transparency, its performance may be affected as the topology size increases—particularly when the number of switches ranges from one to seven—due to increased access latency and storage bottlenecks. Therefore, for large-scale SDN deployments, it is necessary to further optimize the blockchain storage architecture by adopting more efficient blockchain technologies or integrating additional optimization strategies to ensure stable system performance under large-scale conditions.

5.4. DDoS Attack Detection Accuracy

Before detecting the accuracy, it is crucial to set certain parameters in our algorithm to ensure that the binary classification performed by the entire algorithm model on the dataset achieves optimal results. The primary parameters include the number of trees in the Isolation Forest algorithm and the data features required for training the algorithm. The number of trees (n_estimators) determines the number of isolation trees in the model. A higher number of trees can enhance the model’s stability and accuracy as they more comprehensively capture the anomaly patterns in the data. Data features are meaningful information extracted from network traffic, which help the model distinguish between normal and anomalous traffic. Selecting appropriate features can significantly improve the model’s performance.

Initially, we removed data with a large number of missing values that could significantly impact the training results, reducing the number of features in the dataset to 63. Then, we used a composite feature selection algorithm to calculate the correlation coefficient values for each feature in the dataset. These features were then ordered in descending order based on their coefficient values. The Isolation Forest was trained sequentially according to this order, and in each iteration, the feature with the lowest coefficient value was removed. After each round of training, the accuracy was tested using a test set. The set of feature values and the number of trees corresponding to the highest accuracy constitute the optimal parameters required for our model.

As shown in Figure 9, the X-axis represents the number of top features (i.e., the number of data features arranged in descending order of their correlation coefficients). When the number of trees is set to 184, and the top 7 features are selected, our strategy achieves optimal performance. Therefore, we choose this set of values as the parameters for our strategy model (the data in the figure only includes the portion of the chart containing the optimal data; in the actual data, the number of trees was incremented by a step size of 1, but due to the large scale of the data, a step size of 23 was used for plotting).

By applying our composite feature selection algorithm to the dataset, we obtained seven highly correlated features listed in

Table 5. Features selected by the proposed method.

Feature	Role
ACK Flag Count	ACK (Acknowledgment) flag count.
Avg Packet Size	The average size of packets in a flow.
Subflow Fwd Bytes	The number of bytes forwarded in subflows.
Total Backward Packets	Number of packets per second in the flow.
Idle Mean	Indicates the average idle time between packets.
Flow Packets/s	Measures packet transmission rate.
Packet Length Mean	Number of packets per second in the flow.

, in sequential order. Since CIC-DDoS2019 is a publicly available dataset that closely mimics real-world scenarios, the significant features derived from this dataset will substantially aid in identifying network traffic patterns in real-world situations. The first column of the table lists the feature names, while the second column describes the role of each feature.

The features include the ACK Flag Count, which indicates the stability of connections by counting the number of packets with the ACK flag set; the Avg Packet Size, representing the average size of packets in a flow and helping to identify unusual patterns; the Subflow Fwd Bytes, measuring the total bytes forwarded in subflows from client to server; the Total Backward Packets, counting the number of packets sent from server to client to assess communication balance; the Idle Mean, indicating the average idle time between packets and reflecting network activity sparsity; the Flow Packets/s, measuring the number of packets transmitted per second to detect high-frequency communication; and the Packet Length Mean, representing the average length of packets and distinguishing different communication patterns. Together, these features enhance the detection and analysis of network traffic, providing a robust mechanism for identifying benign and malicious activities.

In pattern recognition and information retrieval, binary classification metrics based on true positives (TP), true negatives (TN), false positives (FP), and false negatives (FN) help measure system performance. In our study on DDoS attack detection, we utilized the SYN subset of the CIC-DDoS2019 public dataset. We trained our model on 70,336 instances of normal traffic and tested it on 907 instances of mixed normal and abnormal traffic. These metrics are crucial for evaluating our model’s performance in correctly identifying DDoS attacks. TP represents correctly identified normal traffic, while TN represents correctly identified anomalous traffic, FP represents normal traffic wrongly identified as anomalous, while FN represents anomalous traffic wrongly identified as normal. These parameters are used to calculate accuracy (ACC), a key metric for performance evaluation. The accuracy of correctly detecting attacks is defined as follows:

$$\mathrm{ACC}={\displaystyle \frac{TP+TN}{TP+TN+FP+FN}}$$

(20)

Based on Equation (20), we separately calculate and compare the accuracy of the final DDoS detection strategy after employing Pearson’s correlation coefficient, kernel methods, distance correlation, Spearman’s correlation coefficient, Lasso technique.

The Pearson correlation coefficient $r_{xy}$ measures the linear relationship between two variables x and y. It is defined as

$$X_{\mathrm{score}}=\left|{\displaystyle \frac{{\sum }_{i=1}^n(x_i-\overline{x})(y_i-\overline{y})}{\sqrt{{\sum }_{i=1}^n{(x_i-\overline{x})}^2{\sum }_{i=1}^n{(y_i-\overline{y})}^2}}}\right|$$

(21)

In this formula, $x_i$ and $y_i$ represent individual sample points, $\overline{x}$ and $\overline{y}$ are the mean values of the samples, and n is the number of observations. The absolute value is taken to ensure the score is non-negative.

Kernel methods, such as the Radial Basis Function (RBF) kernel, project data into a higher-dimensional space to facilitate classification. The RBF kernel is defined as

$$X_{\mathrm{score}}=\sum _{i=1}^{n}exp\left(-{\displaystyle \frac{\parallel x_i-x_i^{\prime }{\parallel }^2}{2{\sigma }^2}}\right)$$

(22)

In Equation (22), $x_i$ and $x_i^{\prime }$ are data points, and $\sigma$ is a parameter that determines the width of the kernel. The score is the sum of the kernel similarities across all data points.

Distance correlation $dCor$ measures both linear and nonlinear associations between two variables. It is given by

$$X_{\mathrm{score}}=\left|{\displaystyle \frac{dCov(X,Y)}{\sqrt{dCov(X,X)·dCov(Y,Y)}}}\right|$$

(23)

In Equation (23), $dCov$ represents the distance covariance between the variables X and Y, which captures the extent of dependency between them. The absolute value is taken to ensure that the score is non-negative.

The Spearman correlation coefficient $\rho$ is a measure of rank correlation, assessing how well the relationship between two variables can be described by a monotonic function. It is calculated as

$$X_{\mathrm{score}}=\left|1-{\displaystyle \frac{6\sum d_i^2}{n(n^2-1)}}\right|$$

(24)

In Equation (24), $d_i$ is the difference between the ranks of corresponding values, and n is the number of observations. The absolute value is taken to ensure the score is non-negative.

The Lasso (Least Absolute Shrinkage and Selection Operator) technique is used for regression and feature selection. The objective function for Lasso regression is

$$X_{\mathrm{score}}=arg\underset{\beta }{min}\left(\sum _{i=1}^n{(y_i-{\beta }_0-{\beta }^T{x}_i)}^2+\lambda {\parallel \beta \parallel }_1\right)$$

(25)

In Equation (25), $y_i$ is the response variable, $x_i$ is the vector of predictor variables, $\beta$ represents the coefficient vector, $\lambda$ is the regularization parameter, and n is the number of observations. The score is obtained by minimizing the loss function, which consists of the residual sum of squares and an $L_1$ norm regularization term to control model complexity and prevent overfitting. The coefficients are estimated using the Lasso technique.

Our composite feature selection algorithm as data preprocessing steps, as shown in

Table 6. Comparison of prediction accuracy under different feature selection algorithms.

Feature Filtering Algorithm	Prediction Accuracy (%)
Proposed method	97.66
Lasso	89.63
Pearson	88.74
Spearman	87.55
Kernel	86.12
Distance corr	85.22

. From the table, it is evident that the composite feature selection algorithm used in this strategy achieves a final accuracy of 97.66%, significantly ensuring the accuracy of DDoS detection in the final strategy. This is attributed to the strategies proposed in this work, especially the effective feature selection of composite feature values utilized in detecting network flow data in the second-tier strategy, as well as the Isolation Forest algorithm’s effective binary classification of data.

In addition to accuracy, inspired by the paper in [39], we further compare the recall, precision, and F1 scores of various feature selection algorithms to comprehensively evaluate their performance in detecting DDoS attacks.

Precision: We evaluate the precision of our proposed composite feature selection method compared with other feature selection algorithms. Precision measures the proportion of true positive predictions among all positive predictions. It is an important metric in the context of DDoS attack detection, as it reflects the algorithm’s ability to accurately identify DDoS attack instances without falsely classifying normal instances as attacks.

The precision values for each method are as shown in Figure 10: our proposed method achieves a precision of 0.9766, while Lasso, Pearson, Spearman, Kernel, and Distance correlations achieve precisions of 0.892, 0.880, 0.857, 0.823, and 0.777, respectively. Our proposed method’s precision is notably higher than the other methods, demonstrating its strong ability to accurately identify DDoS attack instances while minimizing false positives.

Recall: We evaluate the recall of our proposed composite feature selection method compared with other feature selection algorithms. Recall, also known as sensitivity or true positive rate, measures the proportion of actual positives that are correctly identified. It is a critical metric in the context of DDoS attack detection, as it reflects the algorithm’s ability to correctly identify DDoS attack instances among all actual attack instances.

The recall values for each method are as shown in Figure 11: our proposed method achieves a recall of 0.873, while Lasso, Pearson, Spearman, Kernel, and Distance correlations achieve recalls of 0.883, 0.875, 0.872, 0.873, and 0.909, respectively. Although our proposed method’s recall is slightly lower than some of the other methods, it demonstrates a strong ability to correctly identify a significant proportion of DDoS attack instances, reflecting its robustness in real-world scenarios. This slight decrease in recall is primarily due to the conservative nature of the Isolation Forest algorithm used in the second-layer defense strategy. Since the model is trained exclusively on normal traffic to simulate unsupervised conditions, it prioritizes minimizing false positives to maintain high precision, which can occasionally lead to a small number of false negatives. Additionally, to avoid performance overhead in real-time SDN environments, our detection threshold is calibrated to favor stability and general applicability over overly aggressive detection. This trade-off ensures that the defense system remains reliable and efficient under practical network conditions.

F1 score: The final metric we evaluate is the F1 score, which is the harmonic mean of precision and recall. The F1 score is an important measure because it balances the trade-off between precision and recall, providing a single metric that accounts for both false positives and false negatives. This is particularly crucial in DDoS attack detection, where both accurately identifying attacks (high recall) and avoiding false alarms (high precision) are important.

The F1 scores for each method are as shown in Figure 12: our proposed method achieves an F1 score of 0.922, while Lasso, Pearson, Spearman, Kernel, and Distance correlations achieve F1 scores of 0.886, 0.877, 0.865, 0.846, and 0.838, respectively. Our proposed method’s F1 score is the highest, indicating that it provides the best balance between precision and recall compared with the other methods.

5.5. Comparison of Anomalous Network Flow Determination Time with Similar Defense Strategies

Following the preceding discussions, we have detailed the fundamental architecture of our defense strategy, the stability of its deployment, the selection of data features for anomaly detection, the determination of algorithm parameters, and the accuracy of detection. Building on this foundation, this subsection presents a comparative analysis of the analysis time for anomalous values of our dual-layer defense strategy against other similar defense strategies referenced in this paper. Specifically, we compare our approach with two DDoS defense strategies that employ machine learning or deep learning techniques: Real-time Detection [19] and an Augmented k-means Clustering Approach [20].

To ensure the fairness of the experimental results, we uniformly utilize the SDN network topology developed in this study and employ the CIC-DDoS2019 dataset as the data support for simulating real network traffic. During the data preprocessing phase, we apply our composite feature selection method to calculate the correlation coefficients of all data features. The dataset is then divided into training and testing sets, and the three strategies are trained and tested over multiple iterations. In each training round, the number of selected features is progressively reduced, starting with those having the lowest correlation coefficients. This approach minimizes potential discrepancies caused by the differing feature selection methods of the three strategies. Finally, we compare the time consumed by each strategy for determining the same test set after training with the same number of selected data features.

As illustrated in Figure 13, the Real-time Detection strategy employing the Random Forest algorithm generally incurs longer processing times than the other two strategies. In contrast, our dual-layer defense strategy exhibits processing times that are comparable to the defense strategy utilizing the k-means algorithm. However, our defense strategy demonstrates greater stability in anomaly determination times, with fewer significant fluctuations observed. Consequently, when detection accuracies are similar, our strategy requires less determination time compared with similar strategies and offers enhanced stability. This effectively highlights the superior defensive performance of our strategy within small-scale SDN network topologies.

6. Conclusions

This research proposes a dual-layer defense mechanism that integrates blockchain technology and unsupervised learning techniques to mitigate DDoS attacks in Software-Defined Networking (SDN) environments. The strategy is designed to simultaneously address two critical aspects of SDN security: reliable flow table management and accurate anomaly detection. On one hand, blockchain and smart contracts are employed to securely manage the storage and access of flow table entries, ensuring integrity, traceability, and protection against tampering or unauthorized modifications. On the other hand, a dual-layer detection framework based on unsupervised learning—featuring composite feature selection and the Isolation Forest algorithm—enables timely and accurate identification of both obvious and subtle DDoS attack patterns. Experimental results demonstrate that the proposed strategy achieves high detection accuracy while maintaining network stability under various traffic loads and attack intensities. Future research will explore lightweight blockchain mechanisms and sharding to improve storage efficiency, as well as incorporate federated or reinforcement learning to further enhance detection performance and scalability in real-world SDN deployments. Additionally, more diverse DDoS datasets beyond CIC-DDoS2019 will be introduced to validate the robustness and generalizability of the proposed strategy across different network environments.