Ideas Challenges

Implementation Responsiveness Key Results

Bohatei: Flexible and Elastic DDoS Defense Seyed K. Fayaz*, Yoshiaki Tobioka*, Vyas Sekar*, Michael Baileyu

*Carnegie Mellon University, uUniversity of Illinois at Urbana-Champaign

Adversary resilience

Fixed location

•  Flexibility in traffic steering using SDN •  Elasticity in defense deployment using NFV

DDoS attacks are increasing in number, volume, and diversity.

Motivation

Vision: Enabling Flexible and Elastic Defense using Bohatei

Bit Rate Price 1Gbps $11,000-$38,000 4Gbps $68,000 12Gbps $128,000

Price of DDoS Defense Appliances

Scalability

DDoS defense today relies on proprietary hardware appliances deployed at fixed locations.

Fixed capacity

Fixed functionality High capital cost

Can we build a flexible and elastic DDoS defense platform that can handle attacks with varying type, volume, and location?

Bohatei envisions a four-step workflow: 1.  Attack detection (using existing methods) 2.  Estimation of volume of attack traffic 3.  Resource management 4.  Network orchestration

Bohatei Key Ideas

1- Responsive resource management: Optimal decision making about the number and type of defense VMs takes hours.

2- Scalable network orchestration: The existing SDN approach to set up switch forwarding rules in a per-flow and reactive manner swamps the SDN controller.

3- Coping with dynamic adversaries that may quickly change the type, volume, and ingress of attack.

1- Hierarchical optimization decomposition: •  The ISP-wide controller determines how many and what types of

VMs to run in each datacenter •  Each per-datacenter controller determines the specific server on

which each defense VM will run. 2- Proactive tag-based forwarding: •  Forwarding rules based on per-VM tags •  Pro-active switch configuration

3- Online adaptation: A defense strategy adaptation approach inspired by online algorithms for minimizing regret (i.e., how much better we could have done in retrospect)

Today: Hardware appliance res. footprint=240Gbps

Ideal: Elastic scaling res. footprint=130Gbps

t1 t2 t3 time

40

80

10

attack vol. (Gbps)

Today: hardware appliance res. footprint=420Gbps

Ideal: elastic scaling res. footprint=250Gbps

t1 t2 t3 time

60 60

10

attack vol. (Gbps)

SYN flood DNS amp.

20 20

80

A C

B

DDoS defense appliance flow1

flow2

Today: traffic footprint given hardware

appliance=3 hops

Ideal: traffic footprint given elastic scaling=2 hops

A C

B

VM VM VM

VM VM VM

flow1

flow2

Fundamental limitations of the current approach:

1.  High capital cost 2.  Fixed capacity 3.  Fixed functionality 4.  Fixed location

2.Strategy

legit.traffic

trafficpathsetup

ISP

a3acktraffic

project homepage

DC2DC1

customer

defensepolicylibrary

3.Resourcemanagement

es@ma@onofvolumeofsuspicioustrafficofeacha3acktypeateachingress

4.Orchestra6on

quan@tyandloca@onofVMs

• VM • VM VM

1.Detec@onmechanismprovidessuspicious

trafficspecifica@on

<A1, Defense Graph1> …

<An, Defense Graphn>

legit.traffic

• VM • VM VM

BohateiglobalSDNcontrollerBohateilocalSDNcontroller

Bohatei Workflow

•  Implementation of a Bohatei controller using OpenDaylight

•  Use of open source tools (e.g., OpenvSwitch, Snort, Bro, iptables) as defense modules

•  Evaluation on a real testbed as well as using simulations

•  Code is made available

26

10

0 20 40 60 80 100 120 140

Be

nig

n t

raff

icth

rou

gh

pu

t (G

bp

s)

Time (s)

attack starts

SYN floodDNS amp.

Elephant flowUDP flood

Bohatei responds rapidly (<1 min) to diverse attacks.

10

1,000

100,000

10e+06

100 200 300 400 500Ma

x r

eq

uire

d n

um

be

ro

f ru

les o

n a

sw

itch

Attack traffic volume (Gbps)

Bohateiper-flow rules

Handling ~1Tbps attacks requires <1K rules on a

switch

0

10

20

30

40

50

60

RandIngress

RandAttack

RandHybrid

SteadyFlipPrevEpoch

Re

gre

t w

.r.t

. vo

lum

eo

f su

cce

ssfu

l a

tta

cks (

%)

UniformPrevEpoch

Bohatei

Bohatei’s online adaptation achieves low

regret

checkUDPcountofsrc

fwdlog

ratelimit

traffic

Sample defense graph

http://silver.web.unc.edu Cloud Security Horizons Summit, March 2016