How to Allow Customers to Blackhole their own traffic

First, of course, thanks for help on this should go to the following individuals and groups:

The UUNET AS702 Access and Backbone Networks Team
The UUNET AS701 Tactical Engineering Team
The UUNET Network Engineering Team
Bogdan Surdu of RDSNET in Romania
Barry Greene of Cisco Systems

Without the help of the teams above this would not have been accomplished in as simple or effective manner as it has been.

Purpose:

There is a single purpose to this paper:

To outline a simple and effective configuration for customers to be enabled to blackhole their own traffic if it suits them.

Prerequisites

There are two basic prerequisites necessary to accomplish this task:

Blackhole route server
Backbone config requirements for the blackhole route server

Strictly speaking the Blackhole Route Server isn't REQUIRED, but it sure is helpful for other things. The config on all backbone equipment to support it is required, however.

Discussion of Methods:

Customers will need to, at times, drop traffic at their ISP's edge. Normally this is accomplished by contacting their ISP and perhaps requesting the ip in question be require an access-list to filter attack traffic toward it or perhaps null route the ip if afilter will not work. This could be a very time consuming process. Enabling the customer to drop that traffic on their own would certainly help them out in instances like this.

If the customer is already a bgp peer of the ISP there exists a relatively safe and secure method to allow the customer to accomplish this task in a quick and non-interactive manner with the ISP. Some simple extra config on the existing customer bgp setup will allow the customer to accomplish this task.

To accomplish this we require the customer to send a prefix to the ISP tagged with a special community. When the ISP edge router sees this new announcement it will simply change the next-hop to some 'known' address that is routed to Null0/discard on all routers in the ISP network.

Config Parts:

An example config for customers in this scenario would be something like this (Cisco then Juniper):

Cisco	! ! jump into the bgp router config ! router bgp 31337 ! ! set the static redistribution to include a route-map so we can filter ! the routes somewhat... or atleast manipulate them ! redistribute static route-map static-to-bgp ! ! Setup the neighbor to actually send-community ! Cisco won't send community by default, so... ! neighbor < transit-provider > send-community ! ! add a stanza to the route-map to set our special community to send ! along to the ISP ! route-map static-to-bgp permit 5 match tag 12345 set community additive XXX:12345 ! ! Route the attacked ip to Null0 and tag it for the route-map's use. ! ip route 192.168.0.1 255.255.255.255 Null0 tag 12345 !

Juniper	# # Allow the special tag routes to get into bgp # set protocols bgp group XXX export BlackHoleRoutes # # Add the community-list so we can add and blackhole # set policy-options community BlackHole members [ XXX:12345 ] # # Add the policy # set policy-options policy-statement BlackHoleRoutes term match-tag12345 from protocol static tag 12345 set policy-options policy-statement BlackHoleRoutes term match-tag12345 then origin igp set policy-options policy-statement BlackHoleRoutes term match-tag12345 then community set BlackHole set policy-options policy-statement BlackHoleRoutes term match-tag12345 then accept # # Route the attacked ip to discard and tag it for the route-map/policy # set routing-options static route 192.168.0.1/32 discard tag 12345

This assumes the customer is redistributing static routes into bgp, that they are a bgp peer and that they can determine the attack target.

For the ISP side of the bgp peer the following needs to be done on a Cisco and a Juniper

Cisco	! ! Filter the customer's session, you already do this, eh? ! router bgp XXX ! ! Route-map to massage their route announcements ! neighbor < customer-ip > route-map in-customer in ! ! Presumably you are prefix filtering your customer, you may have to ! allow your customer to send /32 prefixes to you also... ! neighbor < customer-ip > prefix-list < listnumber > in ! ! This is required to manipulate the next-hop correctly. ! without the ebgp multi-hop the edge device will announce then withdraw ! the announcment repeatedly. This is bad news. ! neighbor < customer-ip > ebgp multi-hop 2 ! ! Add in the special handling for the in-customer route-map ! route-map in-customer permit 5 match ip community XXX:12345 set ip next-hop < blackhole ip> set community additive no-export !

Juniper	# # Filter on the customer bgp session # set protocols bgp group <customer> import in-customer # # Setup the filter for the customer session # set policy-options policy-statement in-customer term cust-blackhole from protocol bgp set policy-options policy-statement in-customer term cust-blackhole from community cust-blackhole set policy-options policy-statement in-customer term cust-blackhole then next-hop < blackhole ip > set policy-options policy-statement in-customer term cust-blackhole then set community no-export

Operational use

So, a simple attack scenario goes like this:

Attack starts
Customer identifies host under attack

Customer static routes the ip on their border router to propogate out in BGP:

Cisco: ip route host.under.attack 255.255.255.255 Null0 tag 12345
Juniper: set routing-options static route host.under.attack/32 discard tag 12345

BGP pushes out the community tagged route to the ISP
Traffic is dropped at the ISP edge, saving the customer

Really, there isn't much magic here and the scenario is quite simple to concieve

Care of Chris Morrow: chris@uu.net
and Brian Gemberling: brian@uu.net