NANOG36-NOTES 2006.02.14 talk 4 Flooding via routing loops

Tue Feb 14 20:07:37 UTC 2006

2006.02.14 talk 4 Flooding attacks

Jianhong Xia

A new talk added right before lunch by
Randy Bush will push us to 12:25.

Two talks coming up about DoS attacks
against control information

Flooding Attacks by exploiting persistent
forwarding loops.

Introduction: routing determines forwarding path.

Transient forwarding loops happen all the time
during convergence; that's normal.  But this
focuses on persistent fowarding loops.

why would persistent loops exist?

Example on neglecting pull-up routes.
Router announces 18.0/16 to internet
router A has default pointing to B
router A uses 18.0.0/24 only
Any traffic to 18.0.1.0-18.0.255.255
will enter the forwarding loop between
A and B

Risk of persistent forwarding loops can
amplify based on ttl of packets injected into
the looping pair of routers.
Can create a denial of service by flooding the
upstream links between routers in front of host
they want to knock off.
any other hosts behind that link are "imperiled
addresses"

Measurement Design:
balancing granularity and overhead
samples 2 addresses in each /24 IP block
Addresses space collection
 addresses covered by RouteView table
 de-aggregate prefixes into /24 prefixes
  fine-grained prefixes
data traces
 traceroute to 5.5 million fine-grained prefixes
 measurement lasts for 3 weeks in sept 2005

Almost 2.5% of routable addresses have persistent
forwarding loops
Almost .8% of routable addresses are imperiled addresses.

Validating these persistent forwarding loops
from multiple places
 from asia, europe, west and east cost of US
 90% of shadowed prefixes consistently have persistent
 forwading loops
Validation to multiple addresses in shadowed prefixes
 sampling 50 addresses in each shadowed prefix
 68% of shadowed prefixes shows that...

Properties of the loops
How long are the loops?
 86.6% of loops are 2 hops long
 0.4% are more than 10 hops long
  some are more than 15 hops
location
 82.2% of persistent loops happen within destination
  domain
implications
 significantly amplify attacking traffic
 can be exploited from different places.

(oops.  Matt gets paged out to deal with issue, so no
 more notes for a while).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20060214/73f318b2/attachment.html>