Extensible Security Services on the CROSS/Linux Programmable Router David K. Y. Yau Department of Computer Sciences Purdue University

Motivations n Internet is an open and democratic environment –increasingly used for mission-critical work n Many security threats are present or appearing –need effective and flexible defenses to detect/trace/counter attacks –protect innocent users, prosecute criminals

Routing Infrastructure n Router software critical to network health –patches for security bugs –new defenses against new attacks n Scalable distribution of router software to many routing points –minimal disruptions to existing services –little human intervention n Exploit software-programmable router technology (CROSS platform)

Existing Networks client router: simple forwarding ISP server

CROSS Network Architecture client router: processing + forwarding Web code server Denial-of-service defense Intelligent congestion control ISP

Cross Forwarding Paths Resource allocation manager Function dispatcher Cut- through subscribe dispatch Active packet send Per-flow processing Output network queues Input queues Packet classifier

Example Security Problem: Network Denial-of-service Attacks n Some attacks quite subtle –at routing infrastructure, malicious dropping of packets, etc –securing protocols and intrusion detection n 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 n Installed by server when under stress, at a set deployment routers –can be sent by multicast n 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 Throttle for S’ To S’ Throttle for S Securely installed by S Deployment router

Key Design Problems n 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 n How to respond to network and user dynamics? –Feedback control strategy needed

What is being fair? n 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! n 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

Fairness Notion n Since we proactively drop packets ahead of congestion point, we need a global fairness notion –router-local max-min at destination, and push back to upper levels (Mahajan et al) –max-min fairness among level-k routing points, R(k), I.e., routers about k hops away from destination

Level-k Deployment Points n Deployment points parameterized by an integer k n 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 n Fairness across global routing points R(k)

Level-3 Deployment Server

Feedback Control Strategy n Hysteresis control –high and low water marks for server load, to strengthen or relax router throttle n Additive increase/multiplicative decrease rate adjustment –increases when server load exceeds U S, and decreases when server load falls below L S –throttle removed when a relaxed rate does not result in significant server load increase

Fairness Definition n 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 L S r U S

Fair Throttle Algorithm

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

Interesting Questions n Can we preferentially drop attacker traffic over good user traffic? n 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 n Control-theoretic analysis –algorithm stability and convergence under different system parameters n Packet network simulations –good user protection under both UDP and TCP traffic n 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 n 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 n 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 n Clients access web server via HTTP 1.0 over TCP Reno n Simulated network subset of AT&T traceroute topology –85 hosts, 20% attackers n Web clients make request probabilistically with empirical document size and inter- request time distributions

Web Server Protection

Web Server Traffic Control

System Implementation n On CROSS/Linux router –as Click element kernel service (loadable kernel module) –code can be remotely downloaded through anetd daemon n Deployment platform –Pentium III/864 MHz PC –multiple 10/100 Mb/s ethernet interfaces

Module Load Overhead

Memory and Delay Results n Memory overhead –7.5 bytes of memory per throttle n Delay through throttle element about 200 ns –independent of number of throttles installed

Throughput Result

Future Work n Offered load-aware control algorithm for computing throttle rate –impact on convergence and stability n Policy-based notion of fairness –heterogeneous network regions, by size, susceptibility to attacks, tariff payment n Selective deployment issues n Impact on real user applications

Conclusions n Extensible routers can help improve network health n 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 n CROSS Implementation –Prem Gopalan, Seung Chul Han, Xuxian Jiang, Puneet Zaroo n Funding has been provided by –NSF, CERIAS, Purdue Research Foundation