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 used for the mitigation of distributed-denial-of-service (DDoS) and DoS attacks. We will show configuration of destination and source RTBH for Cisco IOS-XR in a network depicted on the Picture 1.
The AS64500 has two customers - AS64502 and AS64501. The PC1 (150.160.0.1/24) is connected to the router CE1 and it will be used to launch DDoS attack against the host Server1 (195.165.0.1/24). The both PE routers are running Cisco IOS XRv 6.1.3 and and the router CE2 is are running Cisco vIOS L3 15.6(2)T. The device CE1 is running vIOS L2 15.2. The router PE will be used to sent updates toward PE1 to trigger discarding certain prefixe based on our needs.
Picture 1 - Network Topology For Source and Destination RTBH Testing
1. PE1 Configuration Prior to Attack
Create a static null route on both PE routers that discard packets sent to 192.0.2.1.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
192.0.2.1/32 Null0
Disable sending ICMP unreachable messages to attacker.
interface Null0
ipv4 icmp unreachables disable
Create community no-export.
community-set no-export
no-export
end-set
Create a route-policy rpl-static-to-bgp that matches only routes with the tag 666. We will set a next-hop 192.0.2.1, increase a local preference and attach community no-export to these prefixes.
route-policy rpl-static-to-bgp
if tag is 666 then
set next-hop 192.0.2.1
set local-preference 200
set community no-export
pass
endif
end-policy
Create a route-policy rpl-nh-peer that changes a next-hop to next-hop self for all routes, except the routes with the next-hop 192.0.2.1. Routes with the next-hop 192.0.2.1 will pass without change. Why do we need this policy if we can configure next-hop-self command for neighbor 10.0.0.2 without any route-policy? The command next-hop-self configured for iBGP peer would replace next-hop with the own IP 10.0.0.1 for all routes. This is undesired action as we need to send blackhole route (with tag 666) to iBGP peers with the next-hop set to 192.0.2.1.
route-policy rpl-nh-peer
if not next-hop in (192.0.2.1) then
set next-hop self
endif
pass
end-policy
Create a route-policy PASS that pass all routes. The policy is required by IOS-XR to accept and sent routes from/to eBGP neighbors.
route-policy PASS
pass
end-policy
Configure BGP. Thanks to route-policy rpl-static-to-bgp only static routes tagged with 666 will be injected into BGP. The outbound route-policy rpl-nh-peer for iBGP peer PE2 changes a next hop to the next-hop-self (10.0.0.1) if prefix has not set next-hop 192.0.2.1. It ensures that a route 195.165.0.0/24 will be sent with the next-hop IP 10.0.0.1 to PE2 while the black-holed route with the tag 666 will be sent with the next-hop 192.2.0.1.
router bgp 64500
bgp router-id 2.2.2.2
address-family ipv4 unicast
redistribute static route-policy rpl-static-to-bgp
neighbor 10.0.0.2
remote-as 64500
description Router PE2
address-family ipv4 unicast
route-policy rpl-nh-peer out
neighbor 12.0.0.1
remote-as 64501
description Router CE1
address-family ipv4 unicast
route-policy PASS in
route-policy PASS out
3. PE2 Configuration Prior to Attack
Create a sttaic null route on both PE routers that discard packets sent to 192.0.2.1.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
192.0.2.1/32 Null0
Disable sending ICMP unreachable messages to attacker.
interface Null0
ipv4 icmp unreachables disable
Create community no-export.
community-set no-export
no-export
end-set
Create a route-policy rpl-static-to-bgp that matches only routes with the tag 666. We will set a next-hop 192.0.2.1, increase a local preference and attach community no-export to these prefixes.
route-policy rpl-static-to-bgp
if tag is 666 then
set next-hop 192.0.2.1
set local-preference 200
set community no-export
pass
endif
end-policy
Create a route-policy rpl-nh-peer that changes a next-hop to next-hop self for all routes, except the routes with the next-hop 192.0.2.1. Routes with the next-hop 192.0.2.1 will pass without change. Why do we need this policy if we can configure next-hop-self command for neighbor 10.0.0.2 without any route-policy? The command next-hop-self configured for iBGP peer would replace next-hop with the own IP 10.0.0.1 for all routes. This is undesired action as we need to send blackhole route (with tag 666) to iBGP peers with the next-hop set to 192.0.2.1.
route-policy rpl-nh-peer
if not next-hop in (192.0.2.1) then
set next-hop self
endif
pass
end-policy
Create a route-policy PASS that pass all routes. The policy is required by IOS-XR to accept and sent routes from/to eBGP neighbors.
route-policy PASS
pass
end-policy
BGP configuration for PE2 is similar to PE1.
router bgp 64500
bgp router-id 1.1.1.1
address-family ipv4 unicast
redistribute static route-policy rpl-static-to-bgp
neighbor 10.0.0.1
remote-as 64500
description Router PE1
address-family ipv4 unicast
route-policy rpl-nh-peer out
neighbor 11.0.0.1
remote-as 64502
description Router CE2
address-family ipv4 unicast
route-policy PASS in
route-policy PASS out
Configure uRPF loose mode on the interface Gi0/0/0/1. On the border interfaces, configure uRPF loose mode. Unicast RPF in loose mode, the source address must appear in the routing table and the source is reachable through at least one real interface.
interface GigabitEthernet0/0/0/1
ipv4 address 11.0.0.2 255.255.255.252
ipv4 verify unicast source reachable-via any
3. Checking BGP Tables Prior to Attack
Now check the BGP Table of PE1 (Picture 2). There are routes 150.160.0.0/24 received from iBGP peer PE2 (10.0.0.2) and 195.165.0.0/24 received from eBGP peer CE1 (12.0.0.1).
Picture 2 - BGP Table of PE1 Before Attack
The BGP table of PE2 is depicted on the Picture 3. There are routes 150.160.0.0/24 received from eBGP peer CE2 (11.0.0.1) and 195.165.0.0/24 received from iBGP peer PE1 (10.0.0.1).
Picture 3 - BGP Table of PE2 Before Attack
In order to check connectivity between Attacker PC and Server1 issue ping command from Attacker PC.
Picture 4 - Checking Connectivity between Attacker and Server1
4. Launching DDoS/Dos Attacks
Attacker is launching attack DDoS attack from PC Attacker1 (150.160.0.1/24) against Server1 (195.165.0.1/24).
4.1 Destination RTBH
Once DDoS attack is noticed, a network operator creates a static route 195.165.0.1/32 with the tag 666 on PE1 that is matching the IP address of the server under attack.
router static
address-family ipv4 unicast
195.165.0.1/32 Null0 tag 666
As soon as a network operator creates the static route with tag 666 on PE1 and BGP redistribute the route to PE2 attack will stop. The host Server1 is unreachable (Picture 5). However, as the black-holed subnet contains only a single IP 195.165.0.1 (Server1), the attacker can still reach the server2 (Picture 2) that is not under attack.
Picture 5 - Testing connectivity Between Attacker, Server1 and Server2
Below is a BGP table of P1 router after configuration of static route 195.165.0.1/32 pointing to Null interface on PE1, with the tag 666. The route 195.165.0.1/32 is a local route (Weight is 32768).
Picture 6 - BGP Table of PE1 After Configuration of Static Route 195.165.0.1/32 to Null0 Tag 666
BGP table of PE2 contains a route 195.165.0.1/32 received from iBGP peer 10.0.0.1 with the next-hop set to 192.0.2.1 (Picture 7 and 8).
Picture 7 - BGP Table of PE2 After Receiving BGP Prefix 195.165.0.1/32 with Next-Hop 192.0.2.1
Picture 8 - Prefix 195.165.0.1/32 with Next-Hop 192.0.2.1 in BGP Table of PE2
4.2 Source RTBH
In destination RTBH, prefix of the victim under attack is distributed with the next-hop pointing to a null interface. Once the route is installed, all packets sent to the victim IP are discarded on PE routers. This countermeasure is appropriate in case of heavy DDoS trafic, where victim is attacked from many host at the same time.
In case of DoS traffic, it is more convenient to discard traffic based on the source address - attacker IP. As a result, the victim's IP is reachable for other hosts while attacker's traffic is blocked. This can be easily done by setting a static route pointing to a null interface and attaching a tag 666. Remove a static route 195.165.0.1/32 and add the route 150.160.0.1/32 instead.
router static
address-family ipv4 unicast
150.160.0.1/32 Null0 tag 666
Below is a BGP table of PE2 (Picture 9).
Picture 9 - BGP Table of PE2 After Receiving BGP Prefix 150.160.0.1/32 with Next-Hop 192.0.2.1
End.