Extensible Security Services on the CROSS/Linux Programmable Router

David K. Y. YauDepartment of Computer SciencesPurdue Universityyau@cs.purdue.edu

Motivations

Internet is an open and democratic environment– increasingly used for mission-critical work

Many security threats are present or appearing– need effective and flexible defenses to

detect/trace/counter attacks– protect innocent users, prosecute

criminals

Routing Infrastructure Router software critical to network health

– patches for security bugs– new defenses against new attacks

Scalable distribution of router software to many routing points– minimal disruptions to existing services– little human intervention

Exploit software-programmable router technology (CROSS platform)

Existing Networks

client

router: simpleforwarding

ISP server

CROSS Network Architecture

client

router: processing +forwarding

Web code server

Denial-of-service defense

Intelligentcongestion control

ISP

Cross Forwarding Paths

Resourceallocationmanager

Functiondispatcher

Cut-through

subscribe

dispatch

Active packet

send

Per-flowprocessing

Outputnetworkqueues

Inputqueues

Packet classifier

Example Security Problem: Network Denial-of-service Attacks Some attacks quite subtle

– at routing infrastructure, malicious dropping of packets, etc

– securing protocols and intrusion detection Others by brute force: flooding attacks

– cripples victim; precludes any sophisticated defense at point under attack

– viewed as resource management problem

Flooding Attack

Server

Server-centric Router Throttle Installed by server when under stress,

at a set deployment routers– can be sent by multicast

Specifies leaky bucket rate at which router can forward traffic to the server– aggressive traffic for server dropped

before reaching server– rate determined by a control algorithm

To S

Router Throttle

Aggressive flow

Throttlefor S’

To S’

Throttlefor S

Securely installed by S

Deployment router

Key Design Problems Resource allocation: who is entitled to

what?– need to keep server operating within load

limits– notion of fairness, and how to achieve it?

• Need global, rather than router-local, fairness

How to respond to network and user dynamics?– Feedback control strategy needed

What is being fair? Baseline approach of dropping a fraction

f of traffic for each flow won’t work well– a flow can cause more damage to other

flows simply by being more aggressive! Rather, no flow should get a higher rate

than another flow that has unmet demands– this way, we penalize aggressive flows only,

but protect the well-behaving ones

Level-k Deployment Points

Deployment points parameterized by an integer k

R(k) -- set of routers that are either k hops away from server S or less than k hops away from S but are directly connected to a host

Fairness across global routing points R(k)

Level-3 Deployment

Server

Feedback Control Strategy

Hysteresis control – high and low water marks for server load,

to strengthen or relax router throttle Additive increase/multiplicative

decrease rate adjustment– increases when server load exceeds US, and

decreases when server load falls below LS

– throttle removed when a relaxed rate does not result in significant server load increase

Fairness Definition

A resource control algorithm achieves level-k max-min fairness among the routers R(k) if the allowed forwarding rate of traffic for S at each router is the router’s max-min fair share of some rate r satisfying LS r US

Fair Throttle Algorithm

Example Max-min Rates (L=18, H=22)

Server

18.236.65

14.1

0.01

1.40

0.22

17.73

0.610.95

6.25

6.25

6.2520.53

24.88

15.51

17.73

0.22

0.61

0.95

59.9

Interesting Questions

Can we preferentially drop attacker traffic over good user traffic?

Can we successfully keep server operating within design limits, so that good user traffic that makes it gets acceptable service?– How stable is such a control

algorithm? How does it converge?

Algorithm Evaluation

Control-theoretic analysis– algorithm stability and convergence

under different system parameters Packet network simulations

– good user protection under both UDP and TCP traffic

System implementation– deployment costs

Control-theoretic Model

Throttle Rate (L=900; U=1100)

Server Load (L = 900; U = 1100)

Throttle Rate (U = 1100)

Server Load (U = 1100)

Throttle Rate (L=1050;U=1100)

Server Load (L=1050; U=1100)

UDP Simulation Experiments Global network topology reconstructed

from real traceroute data – AT&T Internet mapping project: 709,310 traceroute

paths, single source to 103,402 other destinations– randomly select 5,000 paths, with 135,821 nodes of

which 3879 are hosts

Randomly select x% of hosts to be attackers– good users send at rate [0,r], attackers at rate [0,R]

20% Evenly Distributed Aggressive (10:1) Attackers

40% Evenly Distributed Aggressive (5:1) Attackers

Evenly Distributed “meek” Attackers

Deployment Extent

TCP Simulation Experiment Clients access web server via HTTP 1.0

over TCP Reno Simulated network subset of AT&T

traceroute topology – 85 hosts, 20% attackers

Web clients make request probabilistically with empirical document size and inter-request time distributions

Web Server Protection

Web Server Traffic Control

System Implementation

On CROSS/Linux router – as Click element kernel service (loadable

kernel module)– code can be remotely downloaded

through anetd daemon Deployment platform

– Pentium III/864 MHz PC– multiple 10/100 Mb/s ethernet interfaces

Module Load Overhead

Memory and Delay Results

Memory overhead– 7.5 bytes of memory per throttle

Delay through throttle element about 200 ns– independent of number of throttles

installed

Throughput Result

Future Work

Offered load-aware control algorithm for computing throttle rate– impact on convergence and stability

Policy-based notion of fairness– heterogeneous network regions, by size,

susceptibility to attacks, tariff payment Selective deployment issues Impact on real user applications

Conclusions Extensible routers can help improve

network health Presented a server-centric router throttle

mechanism for DDoS flooding attacks– can better protect good user traffic from

aggressive attacker traffic– can keep server operational under an

ongoing attack– has efficient implementation

Acknowledgements

CROSS Implementation– Prem Gopalan, Seung Chul Han,

Xuxian Jiang, Puneet Zaroo Funding has been provided by

– NSF, CERIAS, Purdue Research Foundation