Cross-Domain Joint DDoS Detection in Multi-Controller SDN via Confidence-Based Entropy Fusion

TO APPEAR IN IEEE GLOBAL COMMUNICATIONS CONFERENCE, MACAU S.A.R., CHINA, 7 – 11 DECEMBER, 2026

Cross-Domain Joint DDoS Detection in Multi-Controller SDN via Confidence-Based Entropy Fusion Zhaoyang Zhang, Shen Wang, and Xiaofeng Tao

arXiv:2608.17507v1 [cs.CR] 18 Aug 2026

National Engineering Research Center for Mobile Network Technologies, Beijing University of Posts and Telecommunications, Beijing, China, 100876 Email: {zhangzhaoyang, shen.wang, taoxf}@bupt.edu.cn Abstract—In multi-controller Software-Defined Networking (SDN), Distributed Denial-of-Service (DDoS) attacks exhibit a “dispersed source, concentrated target” pattern across domains, i.e., attack traffic originates from multiple edge-controller domains but converges on a victim in a single aggregation controller domain. While entropy-based DDoS detectors are effective in single-controller settings, their direct application in multi-controller SDN reveals a previously overlooked anomaly. Through systematic experiments, we identify an aggregation bias: during the post-attack transition phase, the aggregation controller continues to generate excessive false positives, while edge controllers have already returned to normal. We attribute this phenomenon to the coupled effects of OpenFlow statistics lag and unconstrained dynamic-threshold drift. To address this issue, we propose a cross-domain confidence-fusion framework that leverages lightweight edge-side messages to calibrate aggregation-controller decisions without sharing raw traffic data. The framework is non-intrusive, communicationefficient, and incrementally deployable. Experiments on a threecontroller linear Mininet testbed with 24 hosts over 10 runs show that the method preserves edge-controller performance while reducing the aggregation false positive rate from 8.87% to 1.96% and increasing the F1 score from 89.04% to 96.89%. Index Terms—DDoS detection, multi-controller SDN, crossdomain fusion, confidence, information entropy.

I. I NTRODUCTION Software-Defined Networking (SDN) has become a cornerstone of modern network infrastructure, owing to its decoupling of control and data planes and its global programmability [1]. To overcome the scalability bottlenecks of singlecontroller architectures, distributed multi-controller deployments have become the mainstream solution [2], partitioning the network into multiple control domains. However, this decentralization also poses new challenges to network security. Distributed Denial-of-Service (DDoS) attacks [3] are typically characterized by a “highly dispersed source, concentrated target” pattern: attack traffic, generated by multiple compromised hosts (bots), is dispersed across multiple control domains and converges in the aggregation domain hosting the victim (see Fig. 1). For exposition, we call controllers whose domains attach these attack-source This work is supported by the National Natural Science Foundations of China under Grants 62203062 and 61932005, and partly by the Fundamental Research Funds for the Central Universities under Grant 2242022k60006. Corresponding author: Shen Wang (e-mail: shen.wang@bupt.edu.cn).

hosts edge controllers, and those attaching the victim aggregation controllers; prior works use near-synonyms such as “source/destination” [4] or “local/central” [5]. Domain 1

Edge Controller 1

Aggregation Controller 2

RAN

Bots RAN

DDoS Attack

Domain 3

SDN controller Switch

Domain 2 RAN

Victim

Edge Controller 3

Massive traffic flows converge on and directly hit the victim

SDN-based Core Network

Traffic dispersion with subtle anomalies

Traffic aggregation with delayed response

Fig. 1. Cross-domain DDoS attack scenario. Attack traffic is dispersed in edge domains and converges at the victim within the aggregation domain.

Entropy-based DDoS detection achieves favorable performance in single-controller settings, owing to its low overhead and strong interpretability [6], [7]. A natural engineering intuition is that deploying such a detector independently on every controller such as edge and aggregation controllers in Fig. 1 should leverage richer distributed observations and thus further improve effectiveness. However, our systematic experiments reveal a counterintuitive phenomenon: when such detectors are directly reused, the aggregation controller’s performance degrades rather than improves, with three salient features: (i) spatially, the detection bias concentrates on the aggregation controller, while edge controllers remain essentially unaffected; (ii) temporally, it concentrates in the post-attack transition phase, with in-attack detection being almost perfect; and (iii) within the same windows, edge controllers correctly return to normal state while the aggregation controller still alarms. We term this systematic detection bias the aggregation bias. The central question is: without sharing raw traffic data, how can we exploit limited cross-domain information to eliminate this bias and achieve consistent, robust global DDoS detection? Existing SDN DDoS detection studies fall into three categories. (i) Statistics- and entropy-based detection [6]–[8] characterizes anomalies via Shannon entropy, generalized entropy, or information distance; lightweight and interpretable, but assumes a single observation point with a globally consistent view. (ii) Machine-learning-based detection trains classifiers over flow-level features but requires large labeled

© 2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.

datasets and adopts a single-controller perspective without modeling inter-controller fusion. (iii) Multi-controller cooperative detection [4], [5], [9]–[11] explores cooperative flowstatistics sampling, distributed entropy detection, two-stage edge–center coordination, rule sharing, and cross-domain protection. These works focus on how to share information among multiple controllers and assume comparable observation quality at every controller; they neither characterize the spatial asymmetry of the “dispersed source, concentrated target” pattern, nor identify the systematic aggregation-side bias caused by statistics lag and threshold drift. Building on a mechanism-level analysis of the aggregation bias, this paper proposes a lightweight, incrementally deployable cross-domain confidence-fusion framework that, without sharing raw traffic, leverages edge-side information to constrain and calibrate the aggregation controller’s decisions. The main contributions of this paper are as follows: • This paper identifies a previously overlooked phenomenon, termed aggregation bias, when entropy-based DDoS detection method is deployed directly on each individual controller in an SDN multi-controller setup, and explains it through two coupled root causes, which are interpreted as the interaction between local observation distortion and the lack of cross-domain calibration. • A cross-domain confidence-fusion joint detection method is proposed. Built on a confidence metric and per-source edge consensus, the aggregation controller’s decision is upgraded from a purely local binary judgment to a reliable inference calibrated by cross-domain information. • This paper develops a non-intrusive deployment mechanism with robust fallback capability. The method relies only on lightweight scalar messages from edge controllers and degrades to local detection when reports are absent. Experiments show that the aggregation false positive rate drops from 8.87% to 1.96% while edgecontroller performance is unchanged. The rest of this manuscript is organized as follows. System overview and problem formulation is presented in Section II. Section III presents aggregation-bias phenomenon and analyzes bias mechanisms. A cross-domain confidence-fusion joint detection method is proposed in Section IV. Section V illustrates main results via experiments. Section VI concludes. II. S YSTEM OVERVIEW AND P ROBLEM F ORMULATION A. System Architecture and Assumptions To validate the proposed cross-domain joint DDoS detection framework, we adopt the three-controller topology shown in Fig. 2, which abstracts the cross-domain attack scenario in Fig. 1. Edge controllers c1 and c3 , together with the aggregation controller c2 , manage a linear switch chain s1 –s2 –s3 , with 24 hosts evenly distributed across the three domains (i.e., 8 per domain). Compromised hosts (bots) h1 in the c1 domain and h8 in the c3 domain act as attack sources, targeting the victim

h5 in the c2 domain. All cross-domain traffic is forwarded via switch s2 . Each controller periodically collects intradomain flow statistics through OpenFlow and executes a local entropy-based detector. In addition, the aggregation controller c2 performs cross-domain confidence fusion and outputs the global decision ŷ. Edge controllers transmit only distilled scalar metrics (without raw traffic) to c2 through edge-to-aggregation application-layer reports over TCP, while c2 sends no application-layer report back. Bots

Victim

Edge Controller

Aggregation Controller

Edge Controller

User

Switch 1 (

)

Switch 2

(

)

Switch 3 (

)

ℎ8

Fig. 2. Three-controller SDN testbed topology. Controllers c1 and c3 act as edge controllers, while c2 serves as the aggregation controller. Compromised hosts (bots) h1 and h8 generate DDoS traffic targeting the victim h5 .

We assume: (A1) only distilled scalar metrics are shared edge-to-aggregation, which limits communication overhead and avoids privacy issues of raw-traffic exchange; (A2) intercontroller links are reliable with latency much smaller than the 1-s OpenFlow polling period—this holds in local data-center environments; (A3) the attack path traverses at least one edge and one aggregation domain (canonical cross-domain DDoS); (A4) controllers themselves are trusted. Compromised controllers, tampered, replayed, or reordered reports, and inter-controller delays violating assumption (A2) are outside the current model. B. Formal Model Consider a distributed SDN governed by M controllers C = {c1 , . . . , cM }, where each ci governs a domain Si of OpenFlow switches with Si ∩ Sj = ∅ for i ̸= j. Under the “dispersed source, concentrated target” DDoS attack pattern, C is partitioned into edge controllers Cedge ⊂ C (domains attaching attack-source hosts) and aggregation controllers Cagg ⊂ C (domains attaching the victim), with Cedge ∪ Cagg = C and Cedge ∩ Cagg = ∅. In our testbed (see Fig. 2), Cedge = {c1 , c3 } and Cagg = {c2 }. Each controller ci ∈ Cedge ∪ Cagg uses a sliding window of N packets, indexed by n = 1, 2, . . . in chronological order, and outputs a normalized entropy metric Hi (n) ∈ [0, 1] derived from the Shannon entropy [12] of discriminative traffic attributes (e.g., destination IP/port) [6], [7]; that is, the full construction follows a single-controller entropybased detector [6], [13] to detect DDoS attack. Ideally, entropy metric Hi (n) should faithfully reflect the ground truth state s(n) ∈ {0, 1} (0: normal, 1: attack) from traffic generator, but in multi-controller settings polling latency and feature-selection mismatches induce a role-dependent distortion Hi (n) = H̃i (n) + εi (n), where H̃i (n) is an unbiased ideal entropy observation, and εi (n) is modeled as a zeromean but role-dependent stochastic distortion/bias between

the ideal entropy observation H̃i (n) and the measured value Hi (n). Each SDN controller ci ∈ Cedge ∪ Cagg in a domain then compares Hi (n) against a dynamic threshold Hithd (n), Exponentially Weighted Moving Average (EWMA-) tracked over slow variations of background traffic [6], [13], and outputs a binary local detection decision ( 1, Hi (n) < Hithd (n), yi (n) = (1) 0, Hi (n) ≥ Hithd (n). 1) Aggregation bias: In the post-attack transition phase (i.e., s(n) = 0), if

P yj (n) = 1 | s(n) = 0 ≫ P yi (n) = 1 | s(n) = 0 , (2) ∀cj ∈ Cagg , ci ∈ Cedge , we say the system exhibits an aggregation bias, meaning that aggregation controllers are significantly more likely than edge controllers to raise false attack alarms after the attack has already ceased. Empirically, aggregation domains exhibit larger distortion magnitudes, i.e.,|εj (n)| > |εi (n)|, j ∈ Cagg , i ∈ Cedge mainly due to delayed flow-statistics updates. This distorted observation is further amplified by the EWMA threshold self-update, causing persistent false positives at aggregation controllers. Section III quantifies this effect and traces it to two coupled root causes. 2) Cross-domain fusion problem: To mitigate the bias, the aggregation controller cj receives lightweight reports mi (n) from each i ∈ Cedge and produces a fused DDoS detection decision
(3) ŷ(n) = F Hj (n), Hj (n)thd , {mi (n)}ci ∈Cedge , subject to: (i) mi (n) is low-dimensional scalar metrics/information; (ii) edge-controller logic is unchanged (zero intrusion); and (iii) cross-domain fusion design F degrades to the local decision when reports are absent. Section IV proposes the key mi (n) and F. III. AGGREGATION B IAS : P HENOMENON AND M ECHANISM A. Baseline Observation To illustrate the aggregation bias phenomenon, we evaluate the local DDoS detector (Equation (1)) independently on all three controllers by replaying the raw packet windows from 10 testbed trials (Fig. 2) without cross-domain information or active cross-domain rules. Although the aggregation controller c2 operates at the cross-domain forwarding hub, its observations are still limited to local statistics within S2 . Table I summarizes the averaged results. Three key phenomena are observed. (i) Spatially, the bias is concentrated at the aggregation controller c2 , whose false positive rate (FPR) reaches 8.87%, i.e., approximately 3–10 times higher than those of the edge controllers c1 and c3 . (ii) Temporally, c2 achieves a recall of 99.79% during the attack, while nearly all of its 57.4 false-positive (FP) windows are clustered within a few consecutive windows after the attack terminates. (iii) Cross-controller inconsistency, during

these same intervals, edge controllers c1 and c3 have already correctly reverted to the normal state, while the aggregation controller c2 continues to raise alarms. These results indicate that the bias is not due to random fluctuations, but rather a systematic effect induced by the aggregation controller’s distinct observation conditions. TABLE I BASELINE DD O S DETECTION RESULTS ( LOCAL DETECTOR REPLAY ON THE SAME 10 TRIALS ). Controllers

Accuracy

F1

FPR

Avg. FP

c1 (edge) c2 (aggregation) c3 (edge)

98.84% 93.46% 98.40%

98.84% 89.04% 98.53%

0.93% 8.87% 3.33%

1.7 57.4 5.8

B. Two Coupled Root Causes 1) Root Cause I: entropy distortion under statistics lag: The local entropy detector relies on a rate-triggered dynamic feature-selection mechanism [13]: when the observed packet rate exceeds a preset threshold θthd , an anomaly-oriented feature-selection procedure is activated. Because s2 carries all cross-domain traffic and OpenFlow statistics are polled at ∼1 s, after the attack stops the queued packets cause the observed rate to decay in stages (a typical sequence: 16,520 → 10,978 → 5,703 → 3,520 pps), keeping the rate above θthd for several consecutive windows. The featureselection procedure is then mistakenly applied to traffic that has already returned to normal, depressing the entropy from a normal level of ∼0.7 down to 0.10–0.29 and producing immediate false alarms. In single-controller topologies the same effect spans only 1–2 windows; the aggregation switch’s heavier queue accumulation amplifies both the count and the intensity of affected windows. 2) Root Cause II: unconstrained EWMA threshold drift: EWMA-based dynamic thresholding, a widely adopted adaptive mechanism in entropy-based DDoS detection [13], follows slow background variations through a self-loop on the controller’s own historical entropy. In multi-controller settings this design exhibits a generic degenerate behavior. When an early attack window falls into EWMA’s low-rate branch, its low entropy is absorbed into the update and the threshold enters a sustained decay sequence (e.g., 0.6 → 0.54 → 0.49 → · · · ); subsequent normal windows are misclassified, while the traffic-adaptive freezing constraint blocks recovery, forming a vicious cycle in which the threshold can collapse to near zero. Root Cause II couples temporally with Root Cause I: Root Cause I depresses entropy after the attack, then Root Cause II locks the threshold low, jointly sustaining persistent false alarms during the transition phase. In essence, both causes reflect the same tension—the aggregation controller’s local view is distorted during the transition phase, yet its EWMA threshold has no external calibrator. Edge controllers c1 , c3 , free of queue accumulation, recover promptly and provide exactly the two complementary pieces of information c2 lacks: whether the attack has ended, and at

what level the normal-traffic entropy should sit. This information complementarity motivates the cross-domain fusion design in Section IV. IV. C ROSS -D OMAIN C ONFIDENCE -F USION M ETHOD We instantiate the cross-domain fusion design Equation F in (3) via four coupled components, all running on the aggregation controller and leaving edge-controller logic untouched: (i) edge-to-aggregation application-layer reporting and a local confidence metric; (ii) per-source edge-report tracking and consensus aggregation; (iii) consensus-referenced crossdomain fusion; and (iv) the joint-detection algorithm. A. Edge-to-Aggregation Reporting and Confidence Metric In the proposed method, every ci ∈ Cedge sends the lowdimensional message mi (n) in Equation (3) to cj ∈ Cagg over a TCP socket at the end of each detection window; cj sends no application-layer report back. The message carries two scalars: the local threshold Hithd (n) and a continuous detection confidence αi (n) introduced next. The measured communication and processing overhead is reported in Section V-D. Reporting only the binary decision yi [4], [5], [9]–[11] cannot distinguish high-confidence attacks from boundary noise. We therefore lift yi into a continuous detection confidence αi ∈ [0, 1]. When yi (n) = 0, we set αi (n) = 0; when yi (n) = 1, we define "  λ # Hi (n) 1 · 1− , (4) αi (n) = 1 + e−γs δi Hithd (n) | {z } | {z } saturation factor

boundary-suppression factor

where δi = Hithd (n) − Hi (n), γs controls saturation steepness, and λ controls boundary suppression. The saturation factor outputs ∼0.5 at δi ≈ 0 and saturates toward 1 as δi grows; the boundary-suppression factor tends to 0 as the entropy/threshold ratio approaches 1 and to 1 otherwise. Their product yields a double-suppression effect in the boundary region, driving the confidence to ∼10−3 , while genuine DDoS windows (Hi (n) ≈ 0.1, Hithd (n) ≈ 0.6) yield values approaching 1. We set γs = 20, λ = 10 in Table II. The reporting interface, per-source tracking, and consensus-suppression logic could be adapted to other detectors. For an ML/DL classifier, a calibrated attack probability or decision margin could serve as αi (n). However, Equation (4), the mean-threshold reference, and the threshold-recovery and floor rules rely on lower entropy indicating stronger attack evidence and must be redesigned. B. Per-Source Tracking and Consensus Aggregation The aggregation controller maintains an edge-report registry RE keyed by edge-controller IP, storing each edge controller’s latest (α(n), H thd (n), t). Per-source storage prevents the information loss that a single-scalar aggregation (e.g., averaging) would incur. Before each fused decision, Algorithm 1 computes the consensus pair (αE (n), H̄Ethd (n)), where αE (n) is the maximum confidence over valid entries (i.e., logical-OR

Algorithm 1: Edge-report consensus aggregation algorithm Input: edge-report registry RE , expiration time τexp Output: edge confidence αE (n), edge threshold H̄Ethd (n) valid 1 RE ← {r ∈ RE | tnow − tr ≤ τexp } valid 2 if RE = ∅ then return 0.0, 0.0 3 αE (n) ← maxr∈Rvalid αr (n) E P thd thd 1 4 H̄E (n) ← r∈Rvalid Hr |Rvalid | E

5

E

return αE (n), H̄Ethd (n)

semantics: any active edge alert keeps the global alert active); H̄Ethd (n) is the mean of valid thresholds, acting as a crossdomain normal baseline. If all entries expire the algorithm returns (0, 0), disabling the cross-domain branches. Note that entries older than τexp = 10 s are first dropped. If an edge controller stops reporting, its latest entry remains eligible until τexp , allowing fusion to continue across transient reporting gaps; after expiration, it is discarded and the summary uses any remaining valid sources. C. Consensus-Referenced Cross-Domain Fusion Given the local observation (Hj (n), Hjthd (n), αj (n)) and the consensus pair (αE (n), H̄Ethd (n)) in each detection window, the aggregation controller produces the final decision through the following three complementary rules, which respectively address the root causes identified in Section III-B. 1) Rule 1: Cross-domain consensus suppression (addressing Root Cause I): When the aggregation controller’s preliminary local decision is yj (n) = 1 and all of the following hold simultaneously, (C1) H̄Ethd (n) > 0 (a valid edge report exists); (C2) αE (n) = 0 (no edge controller is alarming); (C3) αj (n) < γ (the local confidence is below the suppression threshold γ), the decision is flipped to ŷ(n) = 0. This rule precisely targets Root Cause I: the attack has ended and edge controllers have recovered, but the aggregation controller produces a lowconfidence local alarm due to OpenFlow statistics lag. We set γ = 0.15, exploiting the ∼10−3 depression that Equation (4) produces in the boundary region. 2) Rule 2: Proactive threshold recovery (a weak version rule addressing Root Cause II): When the edge consensus satisfies H̄Ethd (n) > 0 and αE (n) = 0, the aggregation controller’s EWMA is allowed to update with the current entropy value, even when the local decision remains yj (n) = 1. This “controlled unlocking” breaks the “threshold locked at a low level” deadlock, allowing the threshold to recover gradually toward the normal level. 3) Rule 3: Edge-aware threshold-floor protection (a strong version rule addressing Root Cause II): To prevent the EWMA threshold from collapsing at its source, an edge-aware dynamic floor is imposed after the threshold computation but before the traffic-adaptive freezing constraint:
Hjthd (n) ← max Hjthd (n), min(H̄Ethd , ϕ) , (5)

where ϕ is a preset upper limit that prevents the floor from being so high as to harm sensitivity. Since H̄Ethd reflects the entropy level under normal network conditions (typically 0.6 ∼ 0.7), it serves as a dynamically updated healthy baseline. We set ϕ = 0.5, so that typical DDoS entropy values (0.05 ∼ 0.30) remain well below the floor and reliably trigger detection. D. Joint Detection: The Complete Algorithm Algorithm 2 integrates all the components above. A key design choice is that all cross-domain branches are gated by the unified cross-domain branch enabling condition H̄Ethd (n) > 0. Since edge controllers do not receive reports from any other controller, their edge-report registry RE is always empty and αE (n) = H̄Ethd (n) = 0, so the cross-domain branches are naturally disabled. What remains on an edge controller is exactly the unmodified local detection logic, yielding a fully backward-compatible incremental deployment. Table II summarizes the configuration parameters used throughout. Algorithm 2: Aggregation-controller joint detection algorithm Input: current-window data, an edge-report registry RE , parameters γs , λ, γ, ϕ, θthd , τexp Output: DDoS detection decision ŷ(n) ∈ {0, 1} thd 1 Obtain (αE (n), H̄E (n)) by Algorithm 1 2 Compute the current-window entropy Hj (n) and base threshold Hjthd (n) as in Equation (1) thd // threshold-floor 3 if H̄E (n) > 0 then protection 4 Hjthd (n) ← max(Hjthd (n), min(H̄Ethd (n), ϕ)) 5 end thd 6 if Hj (n) < Hj (n) then 7 Compute αj via Equation (4) 8 ŷ ← 1 9 if H̄Ethd (n) > 0 and αE = 0 and αj < γ then // cross-domain consensus suppression 10 ŷ ← 0 11 end 12 else 13 ŷ ← 0 14 end thd 15 if H̄E (n) > 0 and αE (n) = 0 then // proactive threshold recovery 16 Update the EWMA using the current Hj (n) 17 end 18 return ŷ

TABLE II C ONFIGURATION PARAMETERS OF THE JOINT DETECTOR . Parameter θthd γs λ γ τexp ϕ

Description

Value

Dynamic feature-selection activation rate (pps) Sigmoid steepness Power-suppression exponent Cross-domain suppression threshold Edge-report expiration time (s) Threshold-floor cap on cj

15,000 20 10 0.15 10 0.5

V. E XPERIMENTAL E VALUATION A. Setup and Controlled-Experiment Design The testbed runs on an Intel Core i9-12900K (16 cores, 128 GB RAM) under Ubuntu 20.04, with Mininet v2.3.0 [14] realizing the topology of Fig. 2 and three independent Ryu v4.30 [15] instances acting as c1 , c2 , and c3 over TCP sockets. Non-attacking hosts maintain dual-channel TCP/UDP background traffic; h1 in c1 domain and h8 in c3 domain launch high-rate SYN/ACK/UDP flooding against the victim h5 in c2 aggregation domain. Each detection window contains N = 400 packets, and OpenFlow statistics are polled every 1 s. Each run covers normal, attack, and post-attack transition phases; we perform 10 independent runs. We design a paired controlled comparison on the same raw packet windows and ground-truth labels from all 10 runs. (i) Baseline—the legacy local DDoS detector (1) is deterministically replayed without cross-domain information or active cross-domain rules (Table I); (ii) Joint detection— c1 and c3 run the unmodified local detector and report mi (n) to c2 , which executes Algorithm 2. The replayed joint predictions exactly match the online records. Ground-truth labels are aligned to detection windows (labeled positive when the attack fraction ≥ 0.25); we report accuracy, precision, recall, F1 score, and FPR. B. Detection Performance on the Aggregation Controller Table III reports the per-run performance of c2 under joint detection, and Table IV quantifies the gains over the paired baseline. The FPR drops from 8.87% to 1.96% (a 77.9% relative reduction), precision and F1 score improve by 14.40 and 7.85 percentage points, respectively, while recall decreases by only 0.69 percentage points—a favourable tradeoff, since excessive false alarms cause alert fatigue and erode analysts’ trust. TABLE III AGGREGATION CONTROLLER c2 UNDER JOINT DETECTION : 10 INDEPENDENT RUNS . #

Accuracy

Precision

Recall

F1

FPR

1 2 3 4 5 6 7 8 9 10

.9813 .9720 .9839 .9831 .9862 .9893 .9868 .9764 .9945 .9787

.9470 .8970 .9471 .9555 .9701 .9667 .9624 .9116 .9847 .9389

.9881 1.0000 .9908 .9833 .9784 .9902 .9922 .9949 .9961 .9966

.9671 .9457 .9685 .9692 .9742 .9783 .9771 .9515 .9904 .9669

.0214 .0371 .0183 .0170 .0110 .0109 .0154 .0291 .0062 .0294

Mean

.9832

.9481

.9911

.9689

.0196

Fig. 3 further shows, for one typical run, the temporal evolution of the local entropy and dynamic threshold on c2 . In the post-attack transition phase, an unconstrained EWMA threshold keeps decaying as low entropy values are absorbed into the update; once the edge-aware floor is enabled, the

TABLE IV PAIRED LOCAL BASELINE AND JOINT DETECTION ON c2 ( MEAN OF THE SAME 10 RUNS ). Metric

Before / Baseline

After / Joint

Improvement

Accuracy Precision Recall F1 FPR

93.46% 80.41% 99.79% 89.04% 8.87%

98.32% 94.81% 99.11% 96.89% 1.96%

+4.87 pp +14.40 pp −0.69 pp +7.85 pp −77.9%

threshold is anchored near the edge-consensus level, avoiding the threshold collapse identified in Root Cause II— mechanistically consistent with the FPR reduction in Table IV.

TABLE V A PPLICATION - LAYER AND CONTROLLER - SIDE OVERHEAD ( MEAN ± SAMPLE STANDARD DEVIATION OF 10 RUN - LEVEL MEANS ). Metric

Mean ± SD

Unit

Communication Framed report size Edge serialization Reporting rate per edge Aggregate application-layer data rate

53.13 ± 0.32 16.26 ± 0.41 3.40 ± 0.28 2.89 ± 0.24

B/report µs/report msg/s kb/s

Processing at c2 Report handling Consensus and fusion-rule processing Amortized collaboration processing

2,332.73 ± 330.39 µs/report 14.38 ± 2.39 µs/window 1,977.46 ± 297.45 µs/window

269.58 µs and its 95th percentile is 7.61 ms, showing that thread-dispatch delay creates a right-skewed tail. Consensus and fusion rules require only 14.38 ± 2.39 µs per window. For each run, dividing the sum of all measured reporthandling and fusion-processing time by the number of c2 fusion windows gives an amortized cost of 1.98 ± 0.30 ms per window; the campaign contains 0.84 ± 0.03 successfully received reports per fusion window. Fig. 3. Temporal evolution of the local entropy and dynamic threshold on aggregation controller c2 . The edge-aware threshold floor prevents threshold collapse after the attack ends.

C. Zero-Impact Verification on Edge Controllers The proposed method does not alter the local entropy, dynamic-threshold, or decision computations at c1 and c3 : the edge controllers only compute and report confidence and threshold values to c2 , while all cross-domain rules execute at c2 . Consistent with this design, the 10-run paired replay leaves their Accuracy, F1, and FPR unchanged (c1 : 98.84%, 98.84%, and 0.93%; c3 : 98.40%, 98.53%, and 3.33%, respectively), confirming that the improvement is confined to aggregationside detection.

E. Parameter Sensitivity We evaluate parameter sensitivity by deterministic one-ata-time replay of the 10 current c2 traces. The replay preserves the observed window and report order, and the default configuration reproduces the online predictions exactly. We vary sigmoid steepness γs ∈ {10, 20, 30}, power exponent λ ∈ {5, 10, 15}, suppression threshold γ ∈ {0.10, 0.15, 0.20}, and threshold-floor cap ϕ ∈ {0.4, 0.5, 0.6} while holding all other parameters fixed. Table VI reports the mean and sample standard deviation across runs. TABLE VI O NE - AT- A - TIME SENSITIVITY ON c2 ( MEAN ± SAMPLE SD OVER 10 RUNS ; ∗ DENOTES THE DEFAULT ).

D. Communication and Processing Overhead We quantify overhead over the same 10 current jointdetection runs. A framed report comprises the compact JSON payload and its 4-byte length header. Edge-side instrumentation records serialization cost and application-layer throughput. At c2 , report handling includes accept-to-handler dispatch, JSON decoding, and per-source registry update, while socket receive waiting is excluded; consensus and fusionrule time is measured once per detection window. Each event metric is first averaged within a run and then reported as the mean ± sample standard deviation of the 10 run-level means. The results are limited to application-layer communication and controller-side processing rather than wire-level TCP/IP bandwidth. As shown in Table V, the framed report size is 53.13 ± 0.32 B and each edge sends 3.40 ± 0.28 reports/s, for an aggregate application-layer rate of 2.89 ± 0.24 kb/s. Edge serialization requires 16.26 ± 0.41 µs per report. At c2 , report handling averages 2.33 ms per report; its pooled median is

Parameter

Value(s)

Recall

F1

FPR

γs λ γ ϕ ϕ ϕ

10, 20∗ , 30 5, 10∗ , 15 0.10, 0.15∗ , 0.20 0.4 0.5∗ 0.6

.9911 ± .0065 .9911 ± .0065 .9911 ± .0065 .9872 ± .0174 .9911 ± .0065 .9954 ± .0043

.9689 ± .0129 .9689 ± .0129 .9689 ± .0129 .9671 ± .0133 .9689 ± .0129 .9699 ± .0135

.0196 ± .0097 .0196 ± .0097 .0196 ± .0097 .0194 ± .0099 .0196 ± .0097 .0205 ± .0097

The confidence-shaping parameters γs and λ alter continuous confidence values but do not change a prediction in this cohort; varying γ is likewise decision-invariant. Diagnostic replay shows that the consensus-suppression and proactiverecovery conditions are not activated in these traces, so this invariance should be interpreted as conditional branch inactivity rather than global insensitivity. In contrast, ϕ directly changes the threshold trajectory: values 0.4 and 0.6 alter 10 and 16 of the 8,833 evaluated decisions, respectively. Increasing ϕ from 0.5 to 0.6 raises recall from 99.11% to 99.54%, with FPR increasing from 1.96% to 2.05%; the default ϕ = 0.5 provides a balanced operating point.

R EFERENCES

F. Residual FPs, Positioning, and Limitations The current joint cohort retains 12.7 false-positive windows per run on average. Two mechanisms can contribute to these residual errors: boundary windows in which attack and normal traffic coexist below the 0.25 labeling threshold, and postattack high-rate windows in which dynamic feature selection remains active after traffic has begun to recover. Raising θthd can reduce the latter at the cost of delayed early-attack adaptation. Existing multi-controller schemes [4], [5], [9]–[11] focus on information sharing across controllers; our problem is the aggregation-side bias itself. Table VII positions our work and clarifies the research gap rather than implying superiority. TABLE VII M ETHODOLOGICAL POSITIONING OF MULTI - CONTROLLER COOPERATIVE DD O S DETECTION . Scheme

Information / app. direction

Bias♯

Edge§

Giotis [9] Wang [10] Yu [4] Tayfour [5] This paper

Flow stats / bi-dir. Entropy / bi-dir. Coarse alarm / bi-dir. Rule msg / broadcast Conf. + thd. / edge→agg.

No No No No Yes

Mod. Mod. Mod. Mod. Untouched

Bias♯ : explicitly models aggregation-side bias. Edge§ : edge-controller is modified (Mod.) or untouched.

This work has several limitations. The current evaluation focuses on a three-controller chain topology, high-rate SYN/ACK/UDP flooding, and inter-controller links satisfying assumption (A2). The current traces do not activate the suppression and proactive-recovery branches, so the observed decision invariance for γs , λ, and γ is specific to this traffic cohort. Larger or non-chain topologies, low-rate attacks, and partial or delayed report delivery are left for future evaluation. The current design assumes trusted controllers; extending the maximum-confidence and mean-threshold rules to malicious reports would require Byzantine-robust aggregation and authenticated reporting with integrity and freshness checks. These extensions are left for future work. VI. C ONCLUSION This paper characterized the systematic false-positive problem of an entropy-based detector deployed on the aggregation controller of a multi-controller SDN as an aggregation bias caused by OpenFlow statistics lag and unconstrained EWMA threshold drift, and proposed a crossdomain confidence-fusion joint-detection method comprising a nonlinear confidence metric, per-source edge consensus, consensus-referenced fusion, and an edge-aware threshold floor. On a three-controller, 24-host Mininet testbed, the method reduces the aggregation FPR from 8.87% to 1.96% and raises F1 from 89.04% to 96.89%, with edge-controller performance unchanged. Controller-side measurements further show an application-layer reporting rate of 2.89 kb/s and an amortized aggregation overhead of 1.98 ms per window.

[1] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, “Openflow: enabling innovation in campus networks,” ACM SIGCOMM Computer Communication Review, vol. 38, no. 2, pp. 69–74, 2008. [2] F. Bannour, S. Souihi, and A. Mellouk, “Distributed SDN control: Survey, taxonomy, and challenges,” IEEE Communications Surveys & Tutorials, vol. 20, no. 1, pp. 333–354, 2018. [3] J. K. Chahal, A. Bhandari, and S. Behal, “Ddos attacks & defense mechanisms in sdn-enabled cloud: Taxonomy, review and research challenges,” Computer Science Review, vol. 53, p. 100644, 2024. [4] S. Yu, J. Zhang, J. Liu, X. Zhang, Y. Li, and T. Xu, “A cooperative DDoS attack detection scheme based on entropy and ensemble learning in SDN,” EURASIP Journal on Wireless Communications and Networking, vol. 2021, no. 1, p. 90, 2021. [5] O. E. Tayfour and M. N. Marsono, “Collaborative detection and mitigation of DDoS in software-defined networks,” The Journal of Supercomputing, vol. 77, no. 11, pp. 13 166–13 190, 2021. [6] K. Kalkan, L. Altay, G. Gür, and F. Alagöz, “Jess: Joint entropybased ddos defense scheme in sdn,” IEEE Journal on Selected Areas in Communications, vol. 36, no. 10, pp. 2358–2372, 2018. [7] L. D. Tsobdjou, S. Pierre, and A. Quintero, “An online entropy-based ddos flooding attack detection system with dynamic threshold,” IEEE Transactions on Network and Service Management, vol. 19, no. 2, pp. 1679–1689, 2022. [8] K. S. Sahoo, D. Puthal, M. Tiwary, J. J. Rodrigues, B. Sahoo, and R. Dash, “An early detection of low rate ddos attack to sdn based data center networks using information distance metrics,” Future Generation Computer Systems, vol. 89, pp. 685–697, 2018. [9] K. Giotis, G. Androulidakis, and V. Maglaris, “Leveraging SDN for efficient anomaly detection and mitigation on legacy networks,” in 2014 Third European Workshop on Software Defined Networks. IEEE, 2014, pp. 85–90. [10] R. Wang, Z. Jia, and L. Ju, “An entropy-based distributed ddos detection mechanism in software-defined networking,” in 2015 IEEE Trustcom/BigDataSE/ISPA, vol. 1, 2015, pp. 310–317. [11] J. Wang, L. Wang, and R. Wang, “A method of DDoS attack detection and mitigation for the comprehensive coordinated protection of SDN controllers,” Entropy, vol. 25, no. 8, p. 1210, 2023. [12] C. E. Shannon, “A mathematical theory of communication,” The Bell system technical journal, vol. 27, no. 3, pp. 379–423, 1948. [13] Z. Zhang, S. Wang, A. Taha, E. Bou-Harb, and X. Tao, “When time meets space: Entropy integration and dynamic threshold for adaptive ddos detection in sdn,” 2026. [Online]. Available: https://arxiv.org/abs/2608.15642 [14] Mininet, “Mininet: An Instant Virtual Network on Your Laptop (or other PC),” 2022. [Online]. Available: https://mininet.org/ [15] R. P. Team et al., “Ryu sdn framework,” 2014. [Online]. Available: https://book.ryu-sdn.org/en/Ryubook.pdf

Related documents

• Intelligent Detection and Mitigation of Carpet-Bombing DDoS Attacks in SDN Using Retrieval-Augmented Generation and Large Language Models#229447
• Detecting DDoS attacks using a hybrid model#343591
• A unified cross-domain framework for DDoS detection across IoT, cloud, and SDN networks#228816
• From Noise to Signal: Improving Security Log Anomaly Detection Using LLMs with Endpoint-Specific Logs#471185
• Extracting inter-arrival time based behaviour from honeypot traffic using cliques#647862