EdgePoW: Adaptive Ingress-Aware Defense with Non-Interactive PoW Against Volumetric SYN Floods

arXiv:2603.06668 · cs.NI, cs.CR · Submitted 2026-03-02 · Read on arXiv

Listen

Transcript

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: Today's paper: "EdgePoW: Adaptive Ingress-Aware Defense with Non-Interactive PoW Against Volumetric SYN Floods".

Elias: SDN-SYN PoW presents an ingress-aware defense architecture that integrates non-interactive Proof of Work with an SDN control plane to mitigate large volumetric TCP SYN floods.

Nadia: First, who's behind it and why it matters.

Paper summary: Elias: So, looking at "EdgePoW: Adaptive Ingress-Aware Defense with Non-Interactive PoW Against Volumetric SYN Floods," the authors have proposed an ingress-aware defense architecture that marries non-interactive Proof of Work with an SDN control plane to manage large volumetric TCP SYN floods <ref:2603.06668#pg0>.

Nadia: They claim this system is significant because it shifts the computational burden from the victims onto the attackers and allows proactive filtering deep inside the network fabric, providing adaptive response when needed <ref:2603.06668#pg0>.

Priya: In simple terms, what does this mean for how we think about defending internet services against these high-volume connection attacks? Does it suggest a fundamental shift in where we should be focusing our security efforts?

Elias: It suggests that defense shouldn't just be at the edges anymore; instead, you need intelligence embedded within the network fabric to react dynamically to real-time traffic pressure, which is what this paper is demonstrating <ref:2603.06668#pg2>.

Nadia: Exactly, and the implications are that we might see defenses become much more granular and responsive on a per-ingress basis rather than applying one static rule across the board <ref:2603.06668#pg1>.

Priya: And from a measurement standpoint, the results show that when traffic sources are stable, this adaptive approach can actually improve benign client throughput by eleven point seven percent compared to using only ingress-only enforcement <ref:2603.06668#pg1>. That is a concrete performance metric we can track <ref:2603.06668#pg1>.

Elias: It moves the problem from simply absorbing the attack bandwidth to intelligently filtering and applying minimal computational cost only when and where the threat dictates it <ref:2603.06668#pg1>.

Nadia: The authors also developed a conservative Difficulty Discovery Protocol that allows clients to learn these dynamic difficulty settings transparently via TCP retransmission, which is a neat way to manage client adaptation without adding significant overhead <ref:2603.06668#pg2>.

Priya: Ultimately, the paper presents a framework where non-interactive PoW combined with SDN control offers a tunable mechanism for managing network stability during high-volume connection floods <ref:2603.06668#pg1>.

Elias: It’s an interesting combination of cryptographic cost imposition and network orchestration that addresses the state exhaustion issues inherent in TCP floods by making the cost manageable for normal operations <ref:2603.06668#pg1>.

Conclusion: Nadia: So we've been diving deep into the technical details of EdgePoW, and now it's time to wrap up this segment by focusing on what this paper actually means in the bigger picture.

Elias: I agree, Nadia, we need to get a handle on the core concept of this work and who put it out there.

Nadia: Right. We're talking about "EdgePoW" and the authors are presenting a method using non-interactive Proof of Work to fight those massive TCP SYN floods that can take down services.

Priya: From my side, I’m keen to hear how they simplify this complex defense mechanism into something we can actually understand for the privacy and measurement researchers out there.

Elias: Exactly, Priya; from a cryptographic standpoint, I want to focus on the parameters they assume are secure and what might break that non-interactive PoW setup.

Nadia: And I want to ask who's actually going to be trying this stuff in the real world and what kind of exploitation we're talking about here.

Priya: It really comes down to how effective this adaptive filtering is; I want to know if those measured results hold up when you look at actual traffic patterns over time.

Elias: That's a fair point, Priya; we have to consider that the system relies on specific hash functions, so we need clarity on that assumption.

Nadia: So, putting it together, the big implication here is moving defense from a static perimeter check to something that actually reacts intelligently within the network itself.

Elias: It’s about tuning computational cost dynamically based on real-time ingress conditions, which is a significant architectural move for handling volumetric load.

Priya: And I think what's most compelling is that it shows how you can maintain performance for legitimate traffic while effectively managing malicious noise without crushing the user experience.

Nadia: So, we’re looking at a system that balances security against throughput through this sophisticated, SDN-driven approach.

Elias: It’s definitely a paper worth scrutinizing because it tackles the resource exhaustion problem head-on with a novel mechanism.

Priya: Next up, I want to explore the practical limitations they mentioned and where this defense might fall short in a real deployment scenario.

ICN Lab, Peking University · Tencent

cs.NI, cs.CR

Submitted: 2026-03-02

Updated: 2026-10-02

Comments: APNet 2026: The 10th Asia-Pacific Workshop on Networking , Singapore Singapore, August 6 - 7, 2026

Journal ref: APNet2026: The 10th Asia-Pacific Workshop on Networking

DOI: 10.1145/3820441.3820455

Code: https://github.com/jgamblin/Mirai-Source-Code

License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/

Importance score: 87/100

The gist: SDN-SYN PoW presents an ingress-aware defense architecture that integrates non-interactive Proof of Work with an SDN control plane to mitigate large volumetric TCP SYN floods.

Key concepts

Client-Side PoW Generation: This involves a client hashing parts of the TCP header, including source/destination IPs, ports, and a nonce. The client must repeatedly perform this hashing until the resulting hash meets a specific difficulty target. This process adds computational work for every connection attempt, making it expensive for attackers to launch high-volume floods.
SDN Controller Logic: The SDN controller monitors SYN traffic at network edges and uses Algorithm 1 to decide on defense. It dynamically adjusts the Proof of Work difficulty based on detected floods. If a flood is found, it increases the required difficulty for that specific ingress point, enabling targeted defense.
Client Difficulty Discovery Protocol (DDP): DDP allows clients to learn the current PoW difficulty transparently using TCP's SYN retransmission mechanism. Clients tentatively increase their difficulty upon timeout and confirm a new level only after a successful connection attempt. This ensures clients adapt quickly without causing unnecessary failures.
Prefix Refinement: When stable source prefixes are identified, the system refines its defense from an ingress-wide rule to one specific to the dominant source prefix. This allows legitimate traffic from known sources to bypass high PoW difficulty, improving throughput for benign clients.

Terminology

Verification — 17× in this paper · explained in 2 episodes
Elias — 9× in this paper · explained in 2 episodes
Nadia — 9× in this paper · explained in 2 episodes
Core — 8× in this paper · explained in 2 episodes
Robustness — 4× in this paper · explained in 5 episodes
Adaptation — 3× in this paper · explained in 1 episode
Adaptive Response — 3× in this paper · explained in 1 episode
Verifier — 3× in this paper · explained in 2 episodes
Client Difficulty Discovery Protocol — 2× in this paper
Adversarial Robustness — 1× in this paper · explained in 3 episodes
Heterogeneous Graph — 1× in this paper · explained in 2 episodes
Hysteresis — 1× in this paper · explained in 3 episodes
Transmission Control Protocol — 1× in this paper

Summary

SDN-SYN PoW presents an ingress-aware defense architecture that integrates non-interactive Proof of Work with an SDN control plane to mitigate large volumetric TCP SYN floods. This system is significant because it shifts computational burden from victims to attackers, enables proactive filtering deep within the network fabric, and provides adaptive response by applying stringent validation only when and where needed.

The gist

SDN-SYN PoW restores application QoS during spoofed SYN floods while prefix refinement improves benign-client throughput by 11.7% over ingress-only enforcement.

How it works

The system operates with two main components: client-side PoW generation within the TCP stack and network-side verification managed by an SDN controller. The controller reasons over policy domains—an ingress edge or an (ingress, src prefix) pair—through three phases: (1) monitoring per-ingress SYN counters; (2) detection via Algorithm 1; and (3) enforcement of elevated PoW rules. During peacetime, the default difficulty is minimal or zero, imposing no perceptible cost on legitimate connections. When a volumetric SYN flood is detected at an ingress, the controller raises the difficulty for that ingress.

Client-Side PoW Generation involves hashing TCP header fields (source/destination addresses, ports, and a nonce) until the resulting hash meets the configured difficulty. The required number of iterations to find a valid nonce is defined as k = 2(d/H), where d is the required number of leading zero bits in the hash output. To ensure integrity and per-connection uniqueness, the hash input binds source/destination IP addresses, source/destination TCP ports, and the nonce.

The SDN Controller: Dynamic and Targeted Defense

The controller continuously monitors per-ingress SYN rates and maintains peringress baselines for each ingress. It manages a global default difficulty (e.g., d = 0) for peacetime and an elevated dattack (e.g., d = 16) during floods. The system employs Algorithm 1 to dynamically adjust difficulty and choose the narrowest safe policy domain based on real-time traffic conditions:

If a flood is detected at ingress e, the controller installs an ingress-wide rule: Match: match (ingress = e, tcp.flags = SYN), Action: verify pow(dattack).
If a stable dominant prefix S is observed (high ρ(e) and persistent excess from S), the controller refines to: Match: match (ingress = e, ip.src = S, tcp.flags = SYN), Action: verify pow(dattack).

Client Difficulty Discovery Protocol (DDP)

A key challenge addressed is enabling clients to learn the current PoW difficulty [4]. The DDP piggybacks on TCP’s SYN retransmission mechanism for transparent adaptation. In Phase 1 (Tentative Escalation), a client initiates at its last confirmed difficulty and, upon timeout, increments a connection-local trial difficulty by step Δ and retries up to Rmax times; this tentative state is discarded if the connection fails. In Phase 2 (Confirmed Caching), the new difficulty is written to cache only after a successful SYN-ACK. This ensures that stale high-difficulty entries remain safe as they satisfy any lower threshold, and failures never overwrite confirmed values.

Empirical Validation and Performance

Experiments conducted on a custom SDN testbed demonstrated strong positive efficacy. Under spoofed floods, the controller correctly retains the coarser ingress-wide rule because no single prefix dominates. When source concentration is stable, prefix refinement recovers an additional 4.9 TPS (+11.7%) and reduces median connection setup latency from 2.6 s to 1.7 s by exempting the benign /24 from elevated difficulty. The computational cost for a legitimate client solving d = 16 is approximately 0.3 ms, and DDP discovery converges within four retries (4 s) on the first connection after a policy change, with transient false escalations staying below 0.8% under 2% random loss.

Switch Verification Overhead

The switch-side PoW verification microbenchmarks show substantial headroom for larger deployments. A single core verifies 20.8 Mpps, which is far above the tested attack rate of 350 Kpps, indicating substantial headroom for larger-scale deployments. Furthermore, OVS forwarding throughput drops only 2.8% with PoW verification enabled on SYN packets because the verification cost is independent of difficulty d. The framework is hash-agnostic provided clients and verifiers use the same hash function H.

Conclusion

SDN-SYN PoW combines non-interactive Proof-of-Work with SDN-driven, ingress-aware detection to defend against volumetric TCP SYN floods.

Improvements for AI systems

Here are the specific improvements for AI systems derived from the SDN-SYN PoW architecture, along with what those improved systems could achieve:

The core improvement involves integrating a computational cost mechanism directly into network traffic handling, moving beyond purely software/application-layer defenses.
The improved AI system can perform real-time, adaptive resource management within programmable network fabrics (like P4 or SDN controllers) to proactively mitigate volumetric denial-of-service (DoS) attacks before they overwhelm application servers.
The system can implement an ingress-aware defense strategy that dynamically adjusts security granularity based on traffic source characteristics:
The improved AI system can execute a tiered enforcement policy: it applies aggressive, network-wide computational challenges (Proof of Work) when a flood is detected from unknown or spoofed sources, while selectively relaxing these requirements to benign source prefixes once stable traffic patterns are identified.
The system incorporates a Difficulty Discovery Protocol (DDP) that leverages existing TCP mechanisms (retransmissions) for lightweight, non-interactive client-side adaptation:
This allows the improved AI system to enable legitimate AI/ML clients to adapt their connection setup cost dynamically in response to network stress without requiring complex, stateful handshake modifications or external signaling—it learns the current required computational threshold transparently.
The system utilizes a centralized SDN control plane for continuous monitoring and policy enforcement:
This enables the AI system to function as a nervous system for network security, allowing it to instantly detect anomalies (e.g., abnormal SYN rates) at the ingress edge and immediately push tailored PoW rules, achieving proactive filtering deep within the network fabric.
The architecture allows for the separation of concerns between state exhaustion mitigation and bandwidth exhaustion mitigation:
The improved AI system can deploy a complementary defense stack where a mechanism like SYN Cookies handles traditional state exhaustion (server memory), while the SDN-SYN PoW handles bandwidth saturation (egress/ingress load) caused by massive connection attempts.
The system provides superior collateral damage control through Prefix Refinement:
The improved AI system can optimize network resources by applying stringent PoW rules only to the specific source prefixes identified as the attackers, thereby preserving high throughput for legitimate co-located clients that share the same ingress point but belong to stable source regions.
The system offers robust resilience against adversarial evasion techniques:
The improved AI system can be designed to maintain effectiveness even when attackers attempt traffic spreading across multiple prefixes (by maintaining ingress-wide rules) or use low-and-slow attacks by setting appropriate detection thresholds and confirmation windows (e.g., using conservative parameters like beta = 0.8 and tauclear = 10s).

Sources

Me Love (SYN-)Cookies: SYN Flood Mitigation in Programmable Data Planes