EMISTEMISTDDoS Experimental MethodologyDDoS Experimental Methodology

Alefiya HussainJanuary 31, 2006

OutlineOutline

• Sparta effort on methodology • Xiaowei Yang at UCI • Tool Internals – Brett Wilson • Purdue – Sonia Fahmy

SPARTA Team ParticipantsSPARTA Team Participants

• DETER– Steve Schwab, Ron Ostrenga, Brad Harris, David

Balenson• EMIST DDoS

– Steve Schwab, Brett Wilson, Ron Ostrenga, Alefiya Hussain, Calvin Ko, Roshan Thomas, Brad Harris

ObjectivesObjectives

A methodology should provide a sequence of well-defined steps whichcan guide an experimenter in defining and conducting their evaluation

• Define a canonical DDoS experiment• Provide a set of resources• Detail the process of conducting comparable DDoS experiments• Make it relatively easy to create a DDoS experiment scenario• Create a notational short-hand for describing and comparing

experiments • Archive several experiment descriptions along with data and results

to seed the process• Identify limitations of simulation and emulation, and the effect of

scale on experimental results

Canonical Experiment SetupCanonical Experiment Setup

Attack Traffic:FLOOD | STARVATION | EXPLOITS |

ROUTING | FUTURE

Background Traffic:REPLAY | HARPOON | DRIVE HARPOON WITH REAL TRACES

Topology:CANONICAL | INTERNET SCALE

Defense Mechanisms:FLOODWATCH | DWARD | COSSACK | PUSHBACK | RED-PD

Devices:CLOUDSHIELD | JUNIPER ROUTERS

Measurements:HOST STATISTICS | PACKET TRACES

Metrics & Visualization:EXTRINSIC NETWORK STATE | INTRINSIC DEFENSE STATE

Defense Mechanisms Defense Mechanisms

Floodwatch

Router based detection of

anomalies

DWARD

Source-end detection of abnormal

TCP behavior

COSSACK

Collaborative detection of volume anomalies

Pushback

Router based detection of

congestion

CloudShield RED-PD

• CloudShield IXP2800 Appliance– Available on DETER as an experimental

device• Emulate a router line-card

– RED Queue Implementation– 4 ports x 1 Gigabit Ethernet

• Augment with RED-PD DDoS Defense– Identify misbehaving TCP flows or

aggregates– Create building blocks suitable for

exploring design space of DDoS defenses augmenting line-cards

RED-PD DDoS DefenseRED-PD DDoS DefenseCloudShield ImplementationCloudShield Implementation

Pre-filter

RED Queue

AttackDetector

AttackIdentifier

ClassifierOUT

IN

FromOn the Robustness Of Router Based DDoS DefenseXu and Guerin, Computer CommunicationsReview, July 2005

Measurements and MetricsMeasurements and Metrics

GoodputRatio of attack to background trafficLink utilization

Attack rate

Victim/Server

Average server response timeAverage server-side application throughput

Connection completion timeRate of failed connectionsThroughput per flowloss per flow

TCP Flow

-decrease in goodput

- increased aggregate attack rate

- degraded server response time- decreased server-side application throughput

- increased connection completion time- increased rate of failed connections- increased loss per flow

Topology ScalingTopology Scaling

• Evaluate defense systems in larger, realistic network topologies

• AS level topologies consist of 300+ nodes

• Prune dormant nodes to create smaller topology

• Size of topology determined by density of attackers and background traffic sources

A

d1

d2

s1

V

s2

A

Xiaowei Yang UCI

Overview of the Traffic Validation ArchitectureOverview of the Traffic Validation Architecture

1. Source requests permission to send.2. Destination authorizes source for limited transfer, e.g, 32KB in 10 secs

• A capability is the proof of a destination’s authorization.3. Source places capabilities on packets and sends them.4. Network filters packets based on capabilities.

cap

Deter Test PlanDeter Test Plan

• Implement TVA on the click router platform

• Router implemented as a collection of elements

• Test on Deter• TVA router graph

• Tool Internals