PaperlayerView exact revision on arXiv

Source-linked AI summary

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

Dominik Scholz, Sebastian Gallenmüller, Henning Stubbe, Bassam Jaber, Minoo Rouhi, Georg Carle

arXiv:2003.03221v1cs.NIcs.CRcs.PF

TL;DR

SYN floods exploit the asymmetric cost of TCP connection setup, while end-host defenses struggle to protect services at scale. The paper evaluates SYN cookies and SYN authentication on software and programmable hardware data planes, finding that proxy deployments scale to 10 GbE line-rate and that hardware targets can process up to 14 Mpps with Authfull. It concludes that programmable data planes enable effective mitigation, with SYN authentication recommended for simpler implementation.

  • Problem

    The paper investigates how to defend entire networks against SYN floods when end hosts face costly connection-state and computation demands.

    Source: §I · p. 1

  • Method

    The authors implement and evaluate SYN cookies and SYN authentication using libmoon/DPDK and P4 across software and hardware data-plane targets.

    Source: A. Realized Programs and Targets · p. 8, A. Metrics · p. 9

  • Results

    Proxy implementations scale to 10 GbE line-rate, while hardware P4 targets process up to 14 Mpps of SYN flood traffic with Authfull.

    Source: D. Processed SYN Flood · p. 9, §VIII · p. 11

  • Takeaways & Limitations

    Effective SYN flood mitigation is possible on modern data planes, with SYN authentication recommended because it is simpler to implement when both strategies perform equally.

    Source: §VIII · p. 12

Abstract

from arXiv · show

The SYN flood attack is a common attack strategy on the Internet, which tries to overload services with requests leading to a Denial-of-Service (DoS). Highly asymmetric costs for connection setup - putting the main burden on the attackee - make SYN flooding an efficient and popular DoS attack strategy. Abusing the widely used TCP as an attack vector complicates the detection of malicious traffic and its prevention utilizing naive connection blocking strategies. Modern programmable data plane devices are capable of handling traffic in the 10 Gbit/s range without overloading. We discuss how we can harness their performance to defend entire networks against SYN flood attacks. Therefore, we analyze different defense strategies, SYN authentication and SYN cookie, and discuss implementation difficulties when ported to different target data planes: software, network processors, and FPGAs. We provide prototype implementations and performance figures for all three platforms. Further, we fully disclose the artifacts leading to the experiments described in this work.

I. INTRODUCTION

SYN flooding exploits TCP connection-state allocation to exhaust server backlogs, motivating defenses that authenticate clients before costly state creation. The paper surveys SYN cookies and SYN authentication and investigates programmable data planes for scalable mitigation.

I. INTRODUCTION

  • SYN floods exhaust server backlogs by forcing state allocation for spoofed connection attempts, preventing legitimate TCP connections.Each SYN requires a server-side TCB entry; when the backlog fills, legitimate SYNs are dropped or existing state is evicted.Source: §I · p. 1
  • SYN flood traffic reached up to 84% of large-scale DDoS traffic from 2017 to 2019, making it a prominent attack vector [33].Source: §I · p. 1
  • The paper asks why end hosts struggle against SYN floods, how available defenses affect TCP, and how programmable data planes can provide flexible, scalable mitigation.Source: §I · p. 1

A. Mitigation at Node Level

  • Increasing backlogs or replacing entries only marginally delays attacks, with legitimate connections evicted at rates above 500 SYNs per second with high probability.Larger backlogs consume more memory, while shorter timeouts can reject legitimate high-RTT connections.Source: A. Mitigation at Node Level · p. 2
  • SYN cookies encode connection state in the sequence number and create server state only after a valid acknowledgment is received.The layout uses timestamp, MSS, and a cryptographic hash of the connection four-tuple.Source: A. Mitigation at Node Level · p. 2
  • Node-level defenses trade resources or incur protocol costs: SYN cookies shift pressure from memory to CPU, while authentication can add delay and remains vulnerable if an attacker is whitelisted.SYN cookies also have restricted TCP-option support, and authentication can interrupt normal protocol flow.Source: A. Mitigation at Node Level · p. 2
  • SYN authentication challenges clients and whitelists them after an expected response, potentially storing only one bit per flow, source address, or subnet.Variants validate a final ACK, higher-layer request, fingerprint, or cookie-enhanced response.Source: A. Mitigation at Node Level · p. 2

B. Case Study: SYN Cookies in Linux

Linux SYN cookies prevent backlog-based state exhaustion but remain limited by host CPU processing under SYN floods. The case study therefore motivates moving mitigation before the network stack for larger-scale defense.

B. Case Study: SYN Cookies in Linux

  • Without SYN cookies, Linux processes only up to 250 SYN packets per second and serves no HTTP requests because backlog capacity is limiting.Source: B. Case Study: SYN Cookies in Linux · p. 3
  • Linux with SYN cookies processes up to 0.4 Mpps of SYN flood while serving all HTTP requests up to that rate.Beyond this rate, the probability of successfully serving legitimate requests approaches zero.Source: B. Case Study: SYN Cookies in Linux · p. 3
  • CPU utilization becomes the limiting factor with SYN cookies; SHA1 consumes up to 15% of cycles for cookie calculation, compared with 2.5% for SipHash.The study attributes Linux 4.19’s lower-than-expected performance to other networking changes outside its scope.Source: B. Case Study: SYN Cookies in Linux · p. 3
  • Linux should not be used to mitigate large-scale SYN floods because its general-purpose stack prioritizes protocol support and robustness over raw performance.Filtering before the stack, such as with eBPF-programmable XDP, is identified as one optimization direction.Source: B. Case Study: SYN Cookies in Linux · p. 3
  • Linux’s best-case SYN-cookie defense handles 0.4 Mpps and protects only applications on the local node, requiring separate mitigation and CPU expenditure across a cluster.Source: B. Case Study: SYN Cookies in Linux · p. 3

C. Mitigation at Network Level

Network-level mitigation can move SYN flood handling away from individual servers, but available strategies trade resource use, transparency, and classification robustness. The paper focuses on SYN proxies and compares their protection scope with host-based and alternative approaches.

C. Mitigation at Network Level

  • SYN flood attacks can be detected through elevated SYN volumes at the network edge and then throttled or blocked before reaching the target server.The text mentions traffic monitoring, machine learning, and CUSUM as detection approaches.Source: C. Mitigation at Network Level · p. 3
  • A dedicated SYN proxy can protect multiple servers while keeping mitigation resources off the servers by intercepting SYNs and forwarding only legitimate packets.Traffic may be rerouted through the proxy when monitoring detects an attack.Source: C. Mitigation at Network Level · p. 3
  • A spoofed-ACK proxy frees server backlog space but still exposes the server to the SYN flood and many tentatively established TCP connections.The proxy later sends RST segments for malicious SYNs after a timeout.Source: C. Mitigation at Network Level · pp. 3–4

D. Comparison

  • SYN cookies shift pressure toward CPU use, while SYN authentication generally avoids extensive memory and CPU use but can sacrifice transparency or require cryptographic hashing.AuthTTL requires stored TTL values, and Authcookie requires cookie hashes.Source: D. Comparison · p. 4, Table I · p. 4
  • No listed strategy reliably shuts down the attack, and the methods trade efficiency against correct classification while providing best-effort service during severe load.The comparison assumes only a small fraction of traffic is legitimate during an attack.Source: D. Comparison · p. 4

III. SYN PROXY CONCEPT

The paper proposes a SYN proxy as an efficient way to protect multiple servers without consuming their resources. Its requirements emphasize attack filtering, 10 GbE line-rate performance, service quality, portability, and extensibility.

III. SYN PROXY CONCEPT

  • The authors identify a SYN proxy as the most efficient and effective way to protect a multitude of servers without using those servers’ resources.The concept intercepts potentially harmful traffic before it reaches protected servers.Source: §III · p. 4

A. Requirements

  • The proxy must filter malicious SYN floods while detecting and forwarding legitimate connection attempts without allowing malicious traffic to reach protected servers.This is the central SYN flood mitigation requirement.Source: A. Requirements · p. 5
  • The design target is 14.88 Mpps at 10 GbE, with scalability toward higher rates such as 100 GbE.The requirement is stated as line-rate processing of SYN flood traffic.Source: A. Requirements · p. 5
  • Service quality is defined as keeping proxied services reachable for as many legitimate clients as possible during an attack using a best-effort approach.Higher delay or minor connection disruptions are accepted under attack conditions.Source: A. Requirements · p. 5
  • Portability requires platform independence and fine-grained configurability, while extensibility should support additional SYN and other DoS mitigation strategies.The stated examples include UDP and DNS floods.Source: A. Requirements · p. 5
  • The proxy is designed for attack periods in which more than 90% of received traffic is malicious, leaving only a minority of traffic legitimate.The proxy should nevertheless perform well without malicious traffic.Source: A. Requirements · p. 5

B. Mitigation Strategies

The paper selects SYN cookies and SYN authentication for proxy-based mitigation, highlighting their different transparency, state, and processing requirements. SYN cookies preserve the handshake but create proxy translation and latency challenges, while SYN authentication can use simpler whitelisting.

B. Mitigation Strategies

  • The prototype focuses on SYN cookies and several SYN authentication variants because these strategies provide the selected basis for proxy mitigation.SYN cookies are transparent to client and server but offer limited support for important TCP options.Source: B. Mitigation Strategies · p. 5, 1) SYN Cookies · p. 5

1) SYN Cookies:

  • A SYN-cookie proxy must establish a second server connection and translate sequence and acknowledgment numbers for subsequent segments.The server chooses a different sequence number, so the proxy stores the difference between the two connections.Source: 1) SYN Cookies · p. 5
  • Because client data can arrive before the proxy completes the server handshake, forwarding the first data segment may be delayed until a retransmission after a common 200 ms timeout.The proxy can instead store the segment, resend SYN/ACK, or advertise a zero window until the second handshake completes.Source: 1) SYN Cookies · pp. 5–6
  • SYN authentication interrupts the first connection attempt and whitelists later attempts, avoiding a separate server connection, sequence translation, and per-flow state in the basic case.A simple bitmap can represent the whitelist unless AuthTTL is used.Source: 2) SYN Authentication · p. 6

2) SYN Authentication:

SYN authentication variants require whitelist checks and differ in state and cryptographic processing, while the software prototype uses DPDK-based packet processing and SipHash. The P4 implementations retain a common core but require target-specific changes.

2) SYN Authentication:

  • SYN authentication requires checking every segment against a whitelist because established ACKs cannot be distinguished from handshake ACKs.For non-whitelisted origins, Authcookie verifies the cookie hash.Source: 2) SYN Authentication · p. 6
  • Authfull and Authcookie are evaluated to measure the performance impact of calculating cookie values.Authcookie adds cryptographic hashing to the authentication path.Source: 2) SYN Authentication · p. 6, 3) Comparison · p. 6
  • Compared with SYN cookies, SYN authentication can reduce state to one or two bits per whitelist entry rather than storing a sequence-number difference per flow.The required state depends on the whitelisting granularity, such as flows or full subnets.Source: 3) Comparison · p. 6

IV. SOFTWARE PACKET PROCESSING PROTOTYPE

  • The software prototype uses libmoon on top of DPDK and implements TCP handshake handling in user space because libmoon does not provide a TCP stack.Packets are processed in batches and responses are crafted according to the mitigation strategy and TCP flags.Source: §IV · p. 6

A. Hash Function

  • The implementations use SipHash for cookie and hashmap-key values because it is optimized for short inputs and has been integrated with programmable software and hardware data planes.The paper treats cookie calculation as a performance-relevant operation.Source: A. Hash Function · pp. 6–7

B. Connection State Tracking

The proxy tracks TCP connection state while using strategy-specific data structures for SYN authentication and SYN cookies. It also optimizes packet handling through templated responses, selective buffer allocation, and batching constraints.

B. Connection State Tracking

  • Connection state can be removed actively after FIN/RST completion or passively through second-chance garbage collection, with each approach trading precision against implementation complexity or timeout delay.Active tracking risks premature or missed deletion under reordering, loss, retransmissions, and timeouts; Linux inactive-connection timeouts are at least 10 min.Source: B. Connection State Tracking · p. 7

C. SYN Authentication

  • SYN authentication uses a fixed-size bitmap with two bits per entry, requiring approximately 1 GB to whitelist the complete IPv4 address space by source address.IPv6 requires subnet-based whitelisting or a hash-based structure.Source: C. SYN Authentication · p. 7

D. SYN Cookies

  • Swap-out hash maps combine immediate active-state updates with delayed cleanup by alternating active and history maps instead of traversing a concurrent hash map.Lookups promote history entries into the active map, while inactive history entries are deleted at the next swap.Source: D. SYN Cookies · p. 7
  • The SYN cookie implementation assumes only a small fraction of traffic is verified, making sparse hash maps suitable for thousands of inactive entries with limited memory impact.Each value object is approximately 40 bit, and long timeout intervals reduce swap and copy-up overhead.Source: D. SYN Cookies · p. 7
  • Storing initial TCP data increases per-connection storage to up to 1500 B and becomes infeasible with multiple or out-of-order segments, whereas both tested strategies reduce latency to 10 ms or lower.Active notification avoids buffering the complete initial request and is evaluated alongside the storage approach.Source: D. SYN Cookies · p. 7

E. Optimizations

  • The packet-processing design avoids buffer reuse for most replies, copying forwarded packets and allocating templated transmission buffers on demand to reduce unused-buffer overhead.Buffer reuse is limited because most attack traffic receives templated responses and buffers cannot be reused across ports.Source: E. Optimizations · pp. 7–8

V. PROGRAMMABLE DATA PLANE PROTOTYPE

The prototype ports SYN authentication and SYN cookies across software, SmartNIC, and FPGA data planes using P4, while retaining a common program core and adapting target-specific interfaces. P4 simplifies portability but constrains packet manipulation, cryptographic support, whitelisting, and buffering.

A. Realized Programs and Targets

  • P4 implementations of SYN authentication and SYN cookies were tested on bmv2 and ported to t4p4s, the NFP-4000 SmartNIC, and NetFPGA SUME.The core P4 program remains the same, but architecture models and extern interfaces require small target-specific modifications.Source: A. Realized Programs and Targets · p. 8

B. Program Core

  • P4 parses packets through TCP, applies match-action forwarding and state lookups, modifies strategy-specific fields, and updates the TCP checksum before transmission.Whitelist or sequence-number-difference state is maintained in match-action tables, requiring one lookup per segment.Source: B. Program Core · p. 8

C. Cookie Calculation

  • SYN cookie calculation requires timestamping and hashing support, implemented with SipHash externs on software and NFP targets because the available NFP SHA accelerators were unavailable.The authors report no known P4 ASIC supporting cryptographic functions.Source: C. Cookie Calculation · p. 8

D. Whitelisting

  • A control-plane-managed match-action table provides P4 whitelisting through digest messages from the data plane, while register-based bloom filters avoid the control plane at higher complexity and resource cost.Bloom-filter state is also difficult to maintain because outdated entries must be evicted.Source: D. Whitelisting · p. 8

E. Buffering Packets

P4 cannot buffer complete initial TCP data at line rate, so the prototype omits a slow-path storage server and relies on TCP zero windows or active notification. Evaluation measures processed SYN flood, HTTP service, and latency under controlled mixed traffic.

E. Buffering Packets

  • P4 cannot stall initial TCP data by writing complete packets to memory, and the required memory capacity and bandwidth are unlikely for programmable line-rate targets.A secondary COTS storage server could provide a slow path, but it would add hardware and controller complexity; the authors therefore did not implement it.Source: E. Buffering Packets · pp. 8–9

A. Metrics

  • The evaluation treats processed SYN flood as the primary metric and also measures HTTP requests served without loss and latency under low, middle, and overload attack loads.The middle scenario uses 50% of total processed SYN flood.Source: A. Metrics · p. 9

B. Measurement Setup

  • Traffic generation mixes malicious SYN flood and legitimate HTTP traffic at the same DuT ingress port, with 30-second runs supporting latency measurements through the 99.999 %-ile.Moongen generates the flood and wrk2 generates constant HTTP queries.Source: B. Measurement Setup · p. 9
  • The COTS, SmartNIC, and FPGA experiments use distinct DuT configurations, while COTS tests pin traffic to one CPU core and serve a 1 kB static website with one nginx worker.Linux places the webserver on the same node because it cannot be configured as a SYN proxy; other proxy scenarios forward legitimate traffic to a separate host.Source: B. Measurement Setup · p. 9

C. Webserver Overload

The evaluation controls webserver load to avoid measuring unrelated overload artifacts, then compares SYN-flood processing across implementations, batching choices, and multicore scaling. Hardware P4 targets provide the highest reported throughput for the simpler authentication strategy.

C. Webserver Overload

  • The webserver can process up to 30000 HTTP requests per second, but measurements are restricted to 100 parallel connections and 100 or 1000 requests per second to avoid webserver overload artifacts.Higher parallelism or request rates increase latency or reduce success probability even without the intended proxy overload.Source: C. Webserver Overload · p. 9

D. Processed SYN Flood

  • Up to 14 Mpps of SYN flood traffic is processed by hardware P4 targets using Authfull, while libmoon achieves up to 50% better performance than t4p4s.Cryptographic hashing limits every implementation and reduces maximum processed SYN flood by up to 50%.Source: D. Processed SYN Flood · p. 9
  • Batching substantially affects software performance because libmoon computes cookie values across batches, whereas t4p4s processes packets individually through its P4 pipeline.The selected optimal batch sizes are 64 for libmoon and 32 for t4p4s.Source: D. Processed SYN Flood · pp. 9–10, Figure 9 · p. 10
  • COTS proxy implementations scale linearly with CPU cores through receive-side flow assignment, reaching close to line rate even when cookies are calculated.The implementations avoid sharing state between cores.Source: D. Processed SYN Flood · p. 10, Figure 10 · p. 10

E. Quality of HTTP Requests

HTTP service quality remains perfect up to overload for 100 requests per second, while higher request rates and SYN cookies expose throughput and latency limitations. The NetFPGA implementation maintains low latency under overload and uses only part of the available hardware resources.

E. Quality of HTTP Requests

  • 100 HTTP requests per second achieve 100% success probability until overload for all implemented solutions.After overload, proxy processing limits the probability of forwarding legitimate traffic.Source: E. Quality of HTTP Requests · p. 10
  • Higher request rates reduce success probability during overload, while increasing parallel connections reduces the impact of individual connection timeouts.Source: E. Quality of HTTP Requests · p. 10
  • SYN cookies cannot process increased HTTP traffic even under low SYN-flood load because persistent state complicates rapid port reuse.Authcookie variants have a similar overload slope to Authfull but reach reduced maximum SYN-flood rates.Source: E. Quality of HTTP Requests · p. 10
  • The NFP maintains 1–4 ms latency without outliers under overload, unlike COTS implementations that develop long-tail latency reaching up to one second at the 90th percentile.The 1000-request-per-second, 100-parallel-connection overload case is the exception with median latency above one second for the broader set of scenarios.Source: E. Quality of HTTP Requests · p. 10

F. Resource Consumption

VII. RELATED WORK

Related work spans operating-system SYN cookies, SYN proxies, high-performance software packet processing, and alternative mitigation techniques. The paper concludes that dedicated programmable data planes can provide scalable SYN-flood defense, with platform-specific trade-offs and cryptographic hashing as a hardware constraint.

VII. RELATED WORK

  • Linux SYNPROXY forwards only verified traffic to the kernel and mitigated a 2 Mpps SYN flood using 7% CPU on an eight-core system.The proxy intercepts the initial SYN, calculates a cookie, and completes a second handshake with the original destination.Source: §VII · p. 11
  • Other techniques achieve below 1 Mpps, break TCP, require specialized clients, or work only in particular deployment scenarios.High-performance software frameworks instead use kernel bypass, pre-allocation, parallelization, and batching to exceed 10 Gbit/s on commodity hardware.Source: §VII · p. 11

VIII. CONCLUSION

  • The paper finds that SYN cookie and SYN authentication scale to mitigate SYN flooding at 10 GbE line-rate when deployed in a dedicated proxy.libmoon supports complex packet processing, whereas P4 is easier to port across software and hardware targets with lower latency and fewer outliers.Source: §VIII · p. 11
  • Both mitigation strategies perform equally, so the paper recommends SYN authentication as simpler to implement; suitable cryptographic hashing remains the key hardware limitation.The authors argue that efficient hardware cryptographic hashing could enable powerful data-plane SYN-flood mitigation.Source: §VIII · p. 12
  • The implementations are released as source code for libmoon and P4 targets to support repeatable and reproducible network research.The repository contains the SYN proxy implementations used for the study.Source: §VIII · p. 12

Related papers

Loading 2003.03221v1…