Fundamental Limits
on Blocking
Self-Propagating Code
|
|
|
Preliminary work with |
|
David Moore, Colleen Shannon, |
|
Geoff Voelker and Stefan Savage |
|
|
|
March 6th, 2002 - CSTB Internet under
Crisis Workshop |
|
info @ caida.org |
|
www.caida.org |
Key Questions
|
|
|
Are there fundamental limits on
controlling the spread of Internet worms (or other self-propagating code)? |
|
|
|
How effective are optimal reactive
blocking strategies at controlling the spread? |
|
|
|
How well can we do if only a portion of
ISPs participate? How protected are
the participating ISPs vs. the non-participating? |
Outline
|
|
|
Background and Terminology |
|
Fundamental limits for optimal reactive
defense |
|
More realistic scenarios on Internet
topology |
|
Conclusions |
|
|
Background & Terminology
|
|
|
CodeRed v2 (Jun. 19), Nimda (Sep. 18),
etc… |
|
|
|
What if there was an automated system
to block either infected hosts (source) or worm payload (content)? |
|
|
|
ISPs and organizations participate by
blocking traffic based on source or content (e.g., at their borders). |
|
|
|
|
|
|
Terminology
|
|
|
|
Reaction time includes time to detect
the activity, propagate information to participants, and activate
blocking. (Note: any particular
detection technique is beyond the scope of this work.) |
|
|
|
Success metrics (taken at end of 24
hours): |
|
global - fraction of vulnerable hosts
infected |
|
local - fraction infected only within
participating ASes |
|
24 hours taken as a reasonable estimate
for wide-scale human response |
|
|
|
|
|
|
|
|
Fundamental limits
for
optimal reactive defense
|
|
|
|
Every host participates in the blocking
strategy. This is the best-case
scenario; lower bound on reality |
|
|
|
Success metric is % of hosts infected
at 24 hours. |
|
|
|
Simulations based on 360,000 victims. |
|
worm rate (probes/sec) and reaction
time parameters |
|
100 runs of each scenario |
|
|
|
Note: The success metric for other
numbers of victims can be found by scaling the rate. (e.g., for 3.6M victims,
multiply rate by 10). |
|
|
|
|
|
|
Reaction times
Probe rates
Using Internet topology (1)
|
|
|
|
Only some ASes participate in blocking,
rather than every host. |
|
|
|
Simulation based on: |
|
359,000 IP addresses of CodeRed v2
victims July 19th |
|
AS routing topology derived from
RouteViews July 19th |
|
100 runs of each scenario |
|
|
|
AS routing paths derived from: |
|
shortest paths on AS adjacencies graph |
|
ties for equal-cost paths broken by
total outdegree on path |
|
|
|
|
|
|
|
|
|
|
Using Internet topology (2)
|
|
|
|
|
|
Worm probe rate of 10 probes/sec. (CRv2
was 11.) |
|
|
|
Reaction times determined by 1%
infection rate in optimal scenario. |
|
source blocking - 20 minutes |
|
content blocking - 2 hours |
|
|
Using Internet topology (3)
Using Internet topology (4)
Breadth of deployment
Global vs. Local protection
Conclusions (Pessimistic/Neutral)
|
|
|
Required reaction times required are
short; automated techniques are necessary. |
|
|
|
Future worms can easily spread at rates
which require reaction times shorter than are feasible. |
|
|
|
Content blocking is an order of
magnitude better than source blocking; but may be more difficult to do? |
|
|
|
Transit blocking is necessary for
global health. |
Conclusions (Neutral/Optimistic)
|
|
|
Participating ISPs may be able to save
themselves even if rest of Internet fails. |
|
|
|
Proactive content blocking could be
highly successful. Content filters
may be installed before any code implementation appears in the wild. |
|
|
|
Inability to stop self-propagating code
has positive implications for the potential resilience of overlay &
peer-to-peer networks and the inability of ISPs to censor of content. |