selective blackholing: implementation, usage & effectiveness

Dear fellow networkers,

Through this tutorial-styled email I'd like to introduce the concept,
usage and implementation of "selective blackholing" through the BGP
protocol to the community. This email contains some python code, example
router configurations references to RIPE Atlas data to demonstrate

Selective Blackholing is a DDoS damage control mechanism which is
(compared to scrubbing or conventional blackholing) cheaper and more
effective from the perspective of both the Service Provider and the

In today's internet DDoS attacks are common-place, and the balance is
not particularly fair: very expensive on the receiver-side and very
cheap for the evil-doer (think DNS-, NTP- and SNMP-amplification
attacks). I propose a method which is effective for businesses with a
scoped radius of interaction with their customers.

To elaborate on what 'scoped' (read: selective) means: a Dutch
herring-shop owner will see most legitimate visitors come from within
the Netherlands; a Dallas, TX based Automotive Bulletin Board will see
most conversions from visitor to part-buyer come from visitors within
the United States.

If we look at today's DDoS mitigation solutions (scrubbers: expensive
hardware or subscription services, or BGP blackhole: all or nothing
reachability)... it seems intuitive that a lot of business-owners would
care more about traffic from visitors in the surrounding 1000 kilometers
(or from the same country), than say (for the duration of the attack)
traffic sourced from other continents.

In this document we sequentially number any line of router config or
python code, to allow for easy references.

Let's focus on the implementation following four features:

* discard traffic sourced outside 'this' country (5580:664)
* discard traffic sourced outside 'this' continent (5580:660)
* discard traffic sourced outside a 1000 km radius from 'here' (5580:663)
* discard traffic sourced outside a 2500 km radius from 'here' (5580:662)

The 'this' and 'here' designators refer to the point of interconnection
with any given customer: 'this' and 'here' for a customer connecting to
AS5580 in Amsterdam, would respectable be "Netherlands, Europe, 'most of
West Europe', 'most of West + Central Europe'". It is important to
understand that all proposed mechanisms are designed to perform
uniformly in terms of intended usage regardless of location of
interconnection, so for a Dutch customer 5580:664 means 'discard any
traffic for my prefix received on PEs outside the Netherlands' but
for an Dallas, TX based customer BGP community '5580:663' would mean
'discard traffic destined to my prefix on routers located outside a 1000
km radius around Dallas'.

The 1000 km and 2500 km distances referenced throughout this document
mean the distance between AS 5580 network devices as calculated with a
haversine formula with the GPS coordinates of devices as input. The
haversine formula is an equation giving great-circle distances between
two points on a sphere from their longitudes and latitudes. Actual
length of datapath or optical paths is not taken into consideration, nor
is a peering partner's home country a factor.

To create the above described features we need a simplistic CMDB
database, some python code, static inbound iBGP route-map and
semi-dynamic customer facing inbound route-map. For illustration
purposes we assume a fictional ISP with a POP in the following cities:
Tokyo, San Jose, Dallas, New York, London, Amsterdam and Stockholm.