Remotely Triggered Black Hole Filtering as Service

Remotely triggered black hole (RTBH) filtering is a technique that provides the ability to drop undesirable traffic before it enters a protected network. It is commonly used for the mitigation of distributed-denial-of-service (DDoS) and DoS attacks.

We have covered a configuration of source and destination RTBH for Cisco IOS-XR in a previous tutorial. A trigger router (usually in the NOC) talks iBGP with the rest of the backbone (typically as a client to route-reflectors in the core) is used to trigger a blackhole route activity for any address under attack, as requested by a customer.   Depending on the configured RTBH type, either attacker's IP (source RTBH) or victim's IP (destination RTBH) have been filtered in our lab network.

This tutorial goes further and explain configuration of both source and destination RTBH as a service offered for customers. It is a job of customer to trigger announcement of address that is being attacked by BGP to upstream provider. Prefix is tagged with a special community. Upstream provider sees the special community from their customer. This flags their BGP speaking routers to set the next-hop to the Null interface. All traffic to the customer address is discarded.

How Destination RTBH is Working?
Destination RTBH applied in our lab network is depicted on the Picture 1. Once the DoS/DDoS attack from the IP address 150.160.0.1 (PC1) is launched and detected, Customer1 (AS54501) configures a static route matching the IP under attack that should be filtered in ISP's network. This is the IP address 195.165.0.1/32 of the host Server1. The static route is created with a particular tag, e.g. 666. The route is redistributed into BGP based on the matched tag and advertised with the special BGP community to eBGP neighbor PE1. The BGP community signalizes provider ISP1 (AS64500) that a prefix with attached community should be filtered. Based on the matched community, PE1 router changes a next-hop to 192.0.2.1 that is configured with null0 as a an outgoing interface. The prefix is sent to iBGP peer PE2 with community set to no-export to prevent leaking the route out of the local AS. The iBGP peer PE2 installs a route with the next-ho IP address 192.0.2.1. As a result DoS attack is stopped as traffic is forwarded to Null0 on PE2 router and dropped.

Picture 1 -  Destination RTBH for Mitigation of DoS Attack

1. Configuration Prior Attack

1.1 CE1

The router CE1 is running Cisco vIOS-L2 15.2 with 512MB RAM. However, you can use any L3 image. I have intentionally used the L2 image to place both servers into the same broadcast domain.

interface GigabitEthernet0/1
 no switchport
 ip address 12.0.0.1 255.255.255.252

interface Vlan1
 ip address 195.165.0.254 255.255.255.0

Set BGP community 64500:666 for routes with attached tag 666. In case you want to pass other static routes that are not tagged with 666, add entry 20 with permit statement .

route-map rm-static-to-bgp permit 10
 match tag 666
 set community 64500:666

ip bgp-community new-format

Redistribute static routes into BGP with a route-map rm-static-to-bgp.

router bgp 64501
 bgp router-id 4.4.4.4
 bgp log-neighbor-changes
 neighbor 12.0.0.2 remote-as 64500

Many routers do not automatically propagate communities. On a Cisco router, we will have to enable this explicitly for a BGP neighbor with the send-community command.

 address-family ipv4
  network 195.165.0.0
  redistribute static route-map rm-static-to-bgp
  neighbor 12.0.0.2 activate
  neighbor 12.0.0.2 send-community both
 exit-address-family

Picture 2 - BGP Table of CE1 Prior to Attack

1.2 PE1

The router PE1 is running Cisco IOS XR Software, Version 6.1.3 and has allocated 2048 MB RAM.

interface Null0
 ipv4 icmp unreachables disable

interface GigabitEthernet0/0/0/0
 ipv4 address 10.0.0.1 255.255.255.252

interface GigabitEthernet0/0/0/1
 ipv4 address 12.0.0.2 255.255.255.252

community-set no-export
 no-export
end-set

community-set black-hole
 64500:666
end-set

The route-policy PASS passes all routes. The policy is required by IOS-XR to accept and sent routes from/to eBGP neighbors.

route-policy PASS
 pass
end-policy

The route-policy rpl-as64501-in sets a next-hop to 192.0.2.1, local pref to 200 and community no-export for prefixes with the attached community black-hole. All other prefixes are passed.

route-policy rpl-as64501-in
 if community matches-any black-hole then
  set next-hop 192.0.2.1
  set local-preference 200
  set community no-export
 endif
 pass
end-policy

We need a static route 192.0.2.1/32 to Null interface. The IP address 192.0.2.1/24 is the IP from the block address 192.0.2.0/24. This block is assigned as "TEST-NET-1" for use in documentation and example code (RFC5735).

router static
 address-family ipv4 unicast
  11.0.0.0/30 10.0.0.2
  192.0.2.1/32 Null0

The route-policy rpl-as64501-in is configured for inbound routes from the eBGP neighbor CE1.

router bgp 64500
 bgp router-id 2.2.2.2
 address-family ipv4 unicast
 neighbor 10.0.0.2
  remote-as 64500
  description Router PE2
  address-family ipv4 unicast

 neighbor 12.0.0.1
  remote-as 64501
  description Router CE1
  address-family ipv4 unicast
   route-policy rpl-as64501-in in
   route-policy PASS out

Picture 3 - BGP Table of PE1 Prior to Attack

1.3 PE2

The router PE2 is running Cisco IOS XR Software, Version 6.1.3 and has allocated 2048 MB RAM.

interface GigabitEthernet0/0/0/0
 ipv4 address 10.0.0.2 255.255.255.252

On the PE interfaces, configure uRPF loose mode. When Unicast RPF is configured in loose mode, the source address must appear in the routing table and the source is reachable through at least one real interface. This configuration is required by source RTBH only.

interface GigabitEthernet0/0/0/1
 ipv4 address 11.0.0.2 255.255.255.252
 ipv4 verify unicast source reachable-via any

route-policy PASS
 pass
end-policy

router static
 address-family ipv4 unicast
  12.0.0.0/30 10.0.0.1
  192.0.2.1/32 Null0

router bgp 64500
 bgp router-id 1.1.1.1
 address-family ipv4 unicast

 neighbor 10.0.0.1
  remote-as 64500
  description Router PE1
  address-family ipv4 unicast

 neighbor 11.0.0.1
  remote-as 64502
  description Router CE2
  address-family ipv4 unicast
   route-policy PASS in
   route-policy PASS out

Picture 4 - BGP Table of PE2 Prior to Attack

1.4 CE2

The router CE1 is running Cisco vIOS-L3 15.6(2)T with 512MB RAM.

interface GigabitEthernet0/0
 ip address 150.160.0.254 255.255.255.0

interface GigabitEthernet0/1
 ip address 11.0.0.1 255.255.255.252

router bgp 64502
 bgp router-id 3.3.3.3
 bgp log-neighbor-changes
 neighbor 11.0.0.2 remote-as 64500

address-family ipv4
 network 150.160.0.0 mask 255.255.255.0
 neighbor 11.0.0.2 activate
exit-address-family

Picture 5 - BGP Table of CE2 Prior to Attack 

2. Testing

We are going to simulate DoS attack from PC1 (Attacker) IP address 150.160.0.1/32 launched against Server1, IP 195.165.0.1/24.

2.1 Destination RTBH as Service

Once attacker launches and attack, a network operator in Customer1 network (AS54501) will configure a static route on CE1 as trigger. The route is tagged with tag 666 (Picture 6). The route is redistributed into BGP with the community 64500:666 and announced to eBGP peer PE1.

Picture 6 - BGP Table of CE2 During Attack and Destination RTBH

CE1(config)# ip route 195.165.0.1 255.255.255.255 vlan1 tag 666

The prefix 195.165.0.1/32 is installed into the BGP table of PE1 with the next-hop 192.0.2.1 (Picture 7).

Picture 7 - BGP Table of PE1 During Attack with Destination RTBH

There is only a single route 195.165.0.1/32 with the community no-export in the BGP table of PE2 (Picture 8).  The next-hop for the route is 192.0.2.1.

Picture 8 -  Prefixes with Community No-Export in BGP Table of PE2 During Attack

BGP table of CE2 is depicted on the Picture 8. The route 195.165.0.1/32 is not exported outside of  AS64500.

Picture 9 -  BGP Table of CE2 During Attack with Destination RTBH

Connectivity between PC1 (Attacker) and Server1 (195.165.0.1/24) is not working as traffic destined to prefix 195.165.0.1/32 is filtered on PE2. Connectivity between PC 1 and Server1 is working as expected (Picture 10).

Picture 10 -  Testing Connectivity Between Attacker and Servers 

2.2 Source RTBH as Service

Delete a static route 195.165.0.1/32 from CE1 and configure the the route 150.160.0.1/32 with the tag 666.

CE1(config)# ip route 150.160.0.1 255.255.255.255 vlan1 tag 666

Check the BGP table of PE2 (Picture 11). The route 150.160.0.1/32 is sitting here with the next-ho 192.0.2.1.

Picture 11 -  BGP Table of PE2 During Attack with Source RTBH

Start pinging Server1 (195.165.0.1) and Server2 (195.165.0.2) from PC1. The both servers are unreachable for PC1 (Picture 12).

Picture 12 -  Testing Connectivity Between Attacker and Servers 

The screenshot from Wireshark installed on the link between routers PE2 and PE1 and filtered for ICMP traffic confirms that PE2 has successfully filtered attacker's traffic (Picture 13).

Picture 13 -  No ICMP traffic Between Routers PE2 and PE1

End.