PaperlayerView exact revision on arXiv

Source-linked AI summary

A New Approach to DDoS Defense using SDN and NFV

Seyed K. Fayaz, Yoshiaki Tobioka, Vyas Sekar, Michael Bailey

arXiv:1506.08501v3cs.NI

TL;DR

DDoS defense relies on expensive, proprietary appliances fixed in placement, functionality, and capacity. Bohatei uses SDN/NFV to provide a flexible, elastic defense, and real-testbed evaluations report scalability, rapid response, and resilience to dynamic adversaries.

  • Problem

    DDoS defense relies on expensive, proprietary appliances fixed in placement, functionality, and capacity, while flexible placement and elastic defenses are desired.

    Source: §1 · p. 1

  • Method

    The paper designs Bohatei, an elastic, flexible DDoS defense system drawing on SDN/NFV opportunities.

    Source: §1 · pp. 1–2

  • Results

    On a real testbed, Bohatei scaled and responded rapidly, outperformed naive SDN implementations that do not address control/data-plane bottlenecks, and enabled defenses resilient to dynamic adversaries.

    Source: §10 · p. 14

  • Takeaways & Limitations

    The authors suggest Bohatei’s design principles may also apply to other aspects of network security.

    Source: §10 · p. 14

    The ILP-based resource-management solution takes several hours, so the attack mix may change radically before it computes a solution.

    Source: Fine-grained scaling · p. 6

Abstract

from arXiv · show

Networks today rely on expensive and proprietary hard- ware appliances, which are deployed at fixed locations, for DDoS defense. This introduces key limitations with respect to flexibility (e.g., complex routing to get traffic to these "chokepoints") and elasticity in handling changing attack patterns. We observe an opportunity to ad- dress these limitations using new networking paradigms such as software-defined networking (SDN) and network functions virtualization (NFV). Based on this observation, we design and implement of Bohatei, an elastic and flexible DDoS defense system. In designing Bohatei, we address key challenges of scalability, responsive- ness, and adversary-resilience. We have implemented defenses for several well-known DDoS attacks in Bohatei. Our evaluations show that Bohatei is scalable (handling 500 Gbps attacks), responsive (mitigating attacks within one minute), and resilient to dynamic adversaries.

∗CMU †UIUC · 1 Introduction

Bohatei uses SDN and NFV to provide flexible, elastic DDoS defense in place of fixed hardware appliances. The introduction presents contributions in resource management, orchestration, and adapting to changing attacks.

1 Introduction

  • Over 20,000 DDoS attacks occur per day, peak volumes reach 0.5 Tbps, and new attack vectors and variants continue to emerge [37, 55].Attacks also cause monetary losses and loss of customer trust.Source: §1 · p. 1
  • Fixed-function, fixed-capacity hardware at fixed network locations forces operators to overprovision or route traffic through central scrubbing centers, risking underprovisioning, latency, and complex routing.Handling larger volumes or new attack types typically requires purchasing and deploying more hardware.Source: §1 · p. 1
  • Bohatei combines NFV to vary defense VM scale and type with SDN to steer suspicious traffic through those VMs while minimizing user-perceived latency and network congestion.The paper motivates these paradigms as enabling flexible placement and elastic deployment of defenses.Source: §1 · pp. 1–2
  • Bohatei addresses resource placement that is NP-hard and takes hours to solve, per-flow SDN orchestration unsuitable for DDoS defense, and adversaries that change attack patterns.Its stated contributions include identifying opportunities and challenges in applying SDN/NFV and an adaptation strategy for changing attack mixes.Source: §1 · p. 2
  • Bohatei defends against several DDoS attack types, scales to 500 Gbps attacks and ISPs with about 200 backbone routers, and copes with dynamic adversaries.The evaluation used a real testbed and simulations.Source: §1 · p. 2
  • The proof-of-concept uses OpenDaylight and open-source defense modules including OpenvSwitch, Snort, Bro, and iptables to handle several known DDoS attack types.The controller is implemented on an industry-grade SDN platform.Source: §1 · p. 2
  • Bohatei’s resource management algorithm is 4-5 orders of magnitude faster than state-of-the-art solvers.The algorithm is designed to respond quickly to resource-management needs.Source: §1 · p. 2
  • Bohatei’s proactive tag-based forwarding provides a practical, scalable orchestration mechanism that avoids the pitfalls of existing SDN solutions.Existing solutions can introduce attack avenues because switches contact a controller for each new flow.Source: §1 · p. 2

2 Background and Motivation

SDN separates programmable network control from packet forwarding, while NFV replaces specialized network-function hardware with virtual functions on commodity servers. Together, they offer lower-cost, faster-to-deploy, elastic, and more flexible DDoS defenses with more efficient routing.

2.1 New network management trends

  • SDN centrally programs network behavior by decoupling control from forwarding, while NFV runs virtual network functions on general-purpose servers to reduce cost and enable elastic scaling.Recent advances support software packet processing at line rate (10–40 Gbps), easing NFV performance concerns.Source: §2.1 · p. 2

2.2 New opportunities in DDoS defense

  • A 10 Gbps DDoS appliance costs ≈$128,000 versus about $3,000 for a 10 Gbps NIC, suggesting 1–2 orders of magnitude lower capital expense on commodity hardware.The comparison ignores software and development costs; operational expenses are harder to compare because public data are lacking.Source: §2.2 · pp. 2–3
  • SDN and NFV make it trivial to launch a VM for a new attack type or add VMs for larger attacks, unlike purchasing and integrating more capable appliances.The passage characterizes appliance expansion as expensive and tedious.Source: §2.2 · p. 3
  • Elastic scaling cuts the example SYN-flood defense footprint from 240 Gbps to 130 Gbps, a 45% reduction, compared with provisioning for peak demand.The example uses projected resource footprints of 40, 80, and 10 Gbps across three time intervals; traffic volume proxies for processing resources.Source: §2.2 · p. 3
  • Launching only the defense VMs needed for SYN-flood and DNS-amplification attacks reduces the example hardware footprint by 40%, from 480 to 270.The example contrasts attack-specific VMs with monolithic appliances that handle both attack types.Source: §2.2 · p. 3
  • SDN/NFV lets operators mix best-of-breed defenses across vendors, avoiding hardware-driven vendor lock-in and combining detection and blocking capabilities.For example, operators could use one vendor’s stronger detection with another’s more effective blocking algorithm.Source: §2.2 · p. 3
  • Placing defense VMs near current need and routing traffic through them reduces the example path from 3 hops to 2, a 33% decrease in traffic footprint.This avoids complex routing hacks for fixed-location appliances and reduces the additional latency they cause.Source: §2.2 · p. 3, Figure 1 · p. 3

3 System Overview

Bohatei is framed as an ISP-run DDoS defense service that orchestrates virtualized defenses against attacks whose type, mix, and ingress locations can change. Its design combines hierarchical resource optimization, proactive tag-based forwarding, and online adaptation.

3.1 Problem scope

  • The deployment assumes an ISP offers DDoS defense as a service using datacenters with commodity servers running virtualized network functions; the ideas also extend to CDN and cloud deployments.The ISP service could replace customer hardware or provide cloudbursting when attacks exceed on-premises capacity.Source: §3.1 · pp. 3–4
  • The threat model gives an adversary a fixed maximum attack-traffic budget but control over attack type and mix and ISP ingress locations, considering SYN floods, UDP floods, DNS amplification, and elephant flows.The presentation focuses on one customer, with extension to multiple customers described as straightforward.Source: §3.1 · p. 4
  • A predefined library maps each attack type to a multi-stage defense DAG; Bohatei focuses on orchestration rather than developing new defense algorithms.The DAGs are assumed to be supplied by domain experts, vendors, or best practices.Source: §3.1 · p. 4

3.2 Bohatei workflow and challenges

  • Bohatei’s four-stage workflow detects suspicious traffic, estimates each attack type’s volume at each ingress, allocates defense VMs, and installs forwarding rules to steer traffic to them.Detection is assumed to come from an out-of-band technique and is outside the paper’s scope.Source: §3.2 · p. 4
  • The design must place VMs responsively while limiting legitimate-traffic latency, scale orchestration beyond vulnerable per-flow rules, and avoid overprovisioning or missing defenses as attacks change.VM placement is NP-hard and may take hours with state-of-the-art solvers, despite a target response time of tens of seconds; per-flow rules risk control-plane overload and TCAM exhaustion.Source: §3.2 · p. 5

3.3 High-level approach

  • Hierarchical optimization divides resource placement between an ISP-wide controller that assigns VM types and counts to datacenters and local controllers that select specific servers.The global stage uses coarse-grained capacity information; each local stage uses finer-grained information such as available server locations.Source: §3.3 · p. 5
  • Proactive per-VM tag-based forwarding reduces switch-table size, while preconfiguring rules avoids frequent switch–control-plane interactions.This addresses the limitations of reactive per-flow forwarding for DDoS defense.Source: §3.3 · p. 5
  • Online adaptation inspired by regret-minimization algorithms is designed to handle adversaries that change the attack mix.The changing mix can include attack type, volume, and ingress point.Source: §3.3 · p. 5, §3.2 · p. 5

4 Resource Manager

Bohatei’s resource manager must allocate network and compute resources quickly enough to analyze suspicious traffic and respond before adversaries can nullify defenses by changing attack characteristics. It uses annotated attack-strategy graphs and ISP resource and cost parameters to map logical modules onto VMs.

4 Resource Manager

  • The resource manager seeks responsive allocation of network and compute resources, and the section presents a scalable heuristic intended to achieve near-optimal results.A slow algorithm could let adversaries nullify the defense by rapidly changing attack characteristics.Source: §4 · p. 5

4.1 Problem inputs

  • ISP inputs include edge PoPs and datacenters with pre-provisioned uplink and compute capacities, the latter expressed as VM slots with specified capacity.The processing requirements depend on the strategy graph for each attack type.Source: §4.1 · p. 5
  • Annotated strategy graphs encode expected traffic fractions on edges and suspicious traffic volumes arriving at each edge PoP; edge weights are derived from monitoring data and the adaptation module.The graph weights indicate the fraction of input traffic expected to traverse each edge.Source: §4.1 · p. 6
  • Resource inputs also include each logical module’s per-VM traffic-processing capacity and network transfer costs between ingress and datacenters and within datacenters.Intra-rack and inter-rack traffic have separate unit costs; the passage gives latency as an example cost.Source: §4.1 · p. 6

4.2 Problem statement

  • The problem translates an annotated graph into a physical graph by realizing each logical module as one or more VMs.Source: §4.2 · p. 6

Fine-grained scaling:

Bohatei independently scales logical modules, then decomposes resource allocation into global datacenter selection and local server selection. Its design targets low legitimate-traffic latency and a small suspicious-traffic footprint while respecting infrastructure constraints.

Fine-grained scaling:

  • When module C is the bottleneck, scaling its VM independently avoids scaling the entire A–B–C graph and improves resource efficiency.The monolithic alternative scales all modules together; Figure 5 illustrates the independent-scaling approach.Source: Fine-grained scaling · p. 6, Figure 5 · p. 6
  • The resource-management objective minimizes expected legitimate-traffic latency and suspicious-traffic footprint while assigning traffic fractions to datacenters and VM counts to servers under bandwidth and compute constraints.The decisions specify the fraction of traffic sent to each datacenter and the number of each VM type run on each server.Source: Fine-grained scaling · p. 6
  • The ILP formulation is optimal but takes several hours, leaving attack-mix changes time to undermine its solution.The paper identifies this delay as a vulnerability to an adversary that can radically change the attack mix before computation finishes.Source: Fine-grained scaling · p. 6

4.3 Hierarchical decomposition

  • A global controller selects datacenters through the DSP, then local controllers solve independent SSPs to assign servers, making the decomposition scalable.The paper says its practical greedy heuristics yield close-to-optimal solutions.Source: §4.3 · p. 6
  • The DSP greedily sorts suspicious traffic volumes in decreasing order, assigns each to the least-cost datacenter, and outputs steering fractions and the physical graph to deploy.The steering fractions are used by network orchestration to route traffic to the selected datacenters.Source: §4.3 · p. 7
  • The SSP preserves locality by placing higher-capacity physical-graph nodes with their predecessors on the same server or rack whenever possible.Its assignments are made greedily within each selected datacenter.Source: §4.3 · p. 7

5 Network Orchestration

Bohatei proactively configures tag-based forwarding, dividing network orchestration into wide-area routing to datacenters and intra-datacenter routing to defense VMs. Its design uses existing backbone tunneling and packet tags to scale forwarding and VM load balancing without per-flow reactive control.

5.1 High-level idea

  • Orchestration separates wide-area routing to datacenters from intra-datacenter routing to VM instances, using MPLS-style routing and SDN respectively.Forwarding rules are installed proactively using per-VM tags rather than reactive per-flow rules.Source: §5.1 · p. 7, §5 · p. 7

5.2 Wide-area orchestration

  • Static MPLS or IP tunnels connect each edge PoP to each datacenter, and the global controller configures traffic splits according to resource-management decisions.This reuses traditional backbone tunneling mechanisms to avoid a forklift upgrade; the design is not tied to a specific tunneling scheme.Source: §5.2 · p. 7

5.3 Intra-datacenter orchestration

  • VMs encode processing context in packet-header tags for switch forwarding, while each VM distributes traffic across instances of the next logical node to avoid a centralized load-balancer bottleneck.This supports context-dependent routing and elastic scale-out without a controller tracking each flow; tag selection can follow the intended load-balancing scheme.Source: §5.3 · pp. 7–8
  • Tag-based forwarding replaces 1,000 per-flow rules with only two rules while preserving the same forwarding behavior.VMs and switches are configured proactively after the local controller solves the SSP, before flows arrive.Source: §5.3 · p. 8
  • Across evaluation experiments, Bohatei required at most 800 tag values, encodable in 10 bits.The passage states datacenter-grade networking platforms have extensible header fields that can accommodate this tag space.Source: §5.3 · p. 8
  • For bidirectional modules such as DNS amplification defense, edge switches use outgoing-traffic tags to return incoming traffic to the datacenter and VM that processed the outgoing traffic.The passage contrasts this with UDP flood defense, for which bidirectional processing is not required.Source: §5.3 · p. 8

6 Strategy Layer

Bohatei’s strategy layer estimates the next-epoch attack mix despite delayed ISP response and an adversary that can change attack types and ingress locations. It shows simple provisioning heuristics can fail and uses randomized online adaptation to target low regret against the best static hindsight solution.

Interaction model

  • Bohatei’s ISP responds one epoch after an adversary changes the attack scenario because detection, resource management, and orchestration take time.The epoch duration is the sum of the time to detect an attack, run the resource manager, and execute network orchestration; these operations can be made faster but still have non-zero delays.Source: §6 · p. 9

Objectives and threat model

  • With a fixed total attack-volume budget apportioned across attack types and ingress points, an adversary seeks costly defense overprovisioning (G1) and attack delivery through missing defenses (G2).The ISP aims to minimize both objectives; the discussion omits collateral damage because the optimization places defenses close to ISP ingress points to reduce its impact on legitimate traffic.Source: §6 · p. 9

Limitations of strawman solutions

  • 0,0,20 units of wastage and 10,10,30 units of evasion show PrevEpoch’s failure in a three-epoch, 30-unit example.Starting from (0,0), PrevEpoch overfits to the previous measurement; Uniform provisioning of 15 units per attack type and fixed γ > 1 overprovisioning are also described as not competitive.Source: §6 · p. 9

Online adaptation

  • Bohatei estimates next-epoch attack traffic with follow-the-perturbed-leader (FPL), combining past observations with randomized perturbation so the adversary cannot predict the ISP’s estimates.The strategy targets low regret against the best static solution computed in hindsight; the perturbation is drawn uniformly from [0, 2×B nextEpoch×|E|×|A|], assuming a total defense budget of 2 × B.Source: §6 · p. 9

7 Implementation

Bohatei implements modular analysis and response defenses for several known DDoS attacks on an SDN/NFV platform. Its components support different attack-specific analyses and responses.

7.1 DDoS defense modules

  • Inspired by Click and Bro, Bohatei composes modular analysis (A) and response (R) components for best-of-breed defenses and finer-grained scaling.Analysis modules process suspicious flows and tag packets to steer them to later modules; response modules can forward, log, drop, or rate-limit traffic.Source: §7.1 · pp. 9–10
  • For SYN floods, it tracks per-source SYN/ACK completion and applies SYN-Proxy in gray cases; for DNS amplification, it checks whether customer IPs queried the server and separates fast header from slower payload analysis.Responses include logging, dropping, or basic forwarding.Source: §7.1 · p. 10
  • For UDP floods, A_UDP flags anomalously high per-source packet rates; for elephant flows, analysis flags abnormally large legitimate flows and randomly drops packets.UDP attack packets are directed to logging, while benign packets are forwarded to the next defense node.Source: §7.1 · p. 10

7.2 SDN/NFV platform

  • OpenDayLight plugins implement control modules, OpenFlow configures switches, and KVM VMs, FlowTags, OpenvSwitch, and custom Go support data-plane modules and DSP/SSP.OpenvSwitch emulates datacenter and ISP-backbone switches on the testbed; its use and OpenFlow were chosen for prototyping ease.Source: §7.2 · pp. 10–11

8 Evaluation

Bohatei scales to hundreds of Gbps of DDoS traffic, restores legitimate-flow performance within one minute across diverse attacks, and adapts with low regret to dynamic adversaries. Its evaluation also reports reduced switch-rule requirements, hardware costs, and traffic latency.

8.1 Bohatei scalability

  • The ILP algorithm takes tens of minutes to hours, while Bohatei’s DSP and SSP take milliseconds with an optimality gap of ≤0.04%.The comparison covers three ISP topologies of different sizes and supports rapid response to changing traffic patterns.Source: §8.1 · p. 11, Table 2 · p. 11
  • Bohatei incurs zero rule-setup latency, while reactive SDN per-flow setup latency deteriorates rapidly as DNS-amplification attack flows increase.The paper notes that 200K flows roughly correspond to a 1 Gbps attack and that switch flow setup typically takes a few milliseconds.Source: §8.1 · pp. 11–12, Figure 10 · p. 11
  • Bohatei can handle hundreds of Gbps of attack traffic, while tag-based forwarding reduces switch rule space by four orders of magnitude.A 1 Tbps attack requires fewer than 1K rules on a switch, whereas per-flow rules do not suffice beyond 10 Gbps given typical switch capacity.Source: §8.1 · p. 12, Figure 11 · p. 12

8.2 Bohatei end-to-end effectiveness

  • Bohatei responds to diverse DDoS attacks within one minute and restores legitimate-flow performance.In the reported tests, attack traffic was sufficient to reduce benign throughput to zero; UDP benign traffic recovered even faster than TCP.Source: §8.2 · p. 12, Figure 12 · p. 12
  • Fine-grained modular scaling reduces hardware cost by 2.1–5.4× versus monolithic VMs for 100 Gbps attacks.The reported cost is less than about $32,000 for Bohatei, versus about $160,000 for monolithic VMs; larger attacks require a linear increase in VMs.Source: §8.2 · p. 12, Table 3 · p. 12
  • Bohatei reduces traffic latency by 20% to 65% across the evaluated routing scenarios.The comparison uses equivalently provisioned scenarios with defense at the highest-betweenness node or Bohatei, against shortest-path routing without attacks.Source: §8.2 · pp. 12–13, Figure 13 · p. 13

8.3 Dynamic DDoS attacks

  • Bohatei’s online adaptation achieves low regret across the tested adversarial strategies relative to uniform estimates and previous-measurement estimates.The evaluation reports normalized regret against the best static decision in hindsight for goals of minimizing VM count and successful attack volume.Source: §8.3 · p. 13, Figure 14 · p. 13

9 Related Work

The section compares Bohatei with DDoS detection, resilient-architecture, overlay, and SDN/NFV security work; attack taxonomies are left to surveys [41], and relevant SDN/NFV work was discussed earlier.

DDoS-resilient Internet architectures

  • Existing resilient-Internet architectures use capabilities, inter-domain routing, inter-AS collaboration, packet marking, or traceback, but lack an immediate deployment path for current networks.Bohatei instead targets a practical single-ISP context aligned with ISP and customer economic incentives.Source: §9 · p. 13

Overlay-based solutions

  • Overlay-based solutions place a buffer zone between attack sources and targets, and Bohatei’s design contributions can also be applied to them.Source: §9 · p. 13

SDN/NFV-based security

  • SDN solutions such as FRESCO and AvantGuard face new DDoS avenues from per-flow reactive operation, while Bohatei uses proactive tag-based forwarding rules to avoid those pitfalls.Resolving the control bottleneck requires stateful SDN-switch hardware modifications that vendors are unlikely to support soon.Source: §9 · p. 13

10 Conclusions

Bohatei brings SDN and NFV flexibility and elasticity to DDoS defense while addressing practical resource-management and control/data-plane bottlenecks.

10 Conclusions

  • Bohatei addresses practical challenges in resource-management algorithms and control/data-plane mechanisms to prevent them from becoming DDoS-defense bottlenecks.It combines the flexibility and elasticity of SDN and NFV with these design choices.Source: §10 · pp. 13–14
  • Real-testbed evaluations show Bohatei scales, responds rapidly to attacks, outperforms naive SDN implementations with control/data-plane bottlenecks, and enables resilient defenses against dynamic adversaries.The paper suggests these design principles may also apply to other aspects of network security.Source: §10 · p. 14
  • The authors implemented a full-featured Bohatei prototype using industry-standard SDN control platforms and commodity network appliances.Source: §10 · p. 14

A ILP Formulation · B DSP and SSP Algorithms

The appendix presents an ILP for optimal resource management and explains that its impractical solve time motivates DSP and SSP heuristics. The global controller assigns suspicious traffic to datacenters, and local controllers assign servers to VMs.

A ILP Formulation

  • The ILP’s key decisions are the fraction of each attack’s traffic sent to each datacenter and the number of each VM type placed on each server.Its binary q variable represents unit traffic sent between VMs on servers in a datacenter.Source: A ILP Formulation · pp. 14–15
  • The objective combines inter-datacenter and intra-datacenter costs, with α setting their relative importance.The ILP formulation for optimal resource management is shown in Figure 15.Source: A ILP Formulation · pp. 14–15, Figure 15 · p. 15
  • Constraints route all suspicious traffic to datacenters, limit datacenter bandwidth, provide sufficient VM types, and enforce server compute and VM processing capacities.The formulation also accounts for intra-rack and inter-rack costs.Source: A ILP Formulation · p. 15
  • Flow conservation is enforced, and ISP backbone links are kept below a fixed fraction β of maximum capacity using paths from a precomputed set.The ILP’s decision variables are given in equation (15).Source: A ILP Formulation · p. 15

B DSP and SSP Algorithms

Loading 1506.08501v3…