Post on 22-Dec-2015
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)
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
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)
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
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
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]
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
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
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
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