Source-Based RTBH
Last updated
Last updated
Topology: bgp-mh-iol
All links are in the format 100.X.Y.X/24.
For example, the link between R4 and R7 is 100.4.7.0/24.
Lo0 is X.X.X.X/32 and is used for iBGP
Lo1 is <AS>.0.0.X/32 and is used as a public IP address that is pingable. The public Lo1 addresses are aggregated into a /8 at each edge router.
eBGP and iBGP is fully preconfigured.
Instructions:
Configure source-based RTBH for 10.0.0.1/32 within AS20.
R2 should drop traffic sourced from this IP at the edge.
Use the least restrictive method when dropping traffic inbound.
Use R4 as the blackhole trigger point, using nexthop to trigger the RTBH on PEs.
In this scenario, AS20 has been told that 10.0.0.1/32 is a bad actor. AS20 wishes to drop traffic sourced from this IP at the edge.
To do this, we configure the same dummy null0 route as before. This is used as a nexthop for prefixes we want to blackhole.
Next, on R4, we configure the same static to BGP redistribution that we saw before. In this scenario R4 should set nexthop to the blackhole dummy destination. If R4 sets nexthop-self, the uRPF check will still fail in strict mode, but not loose mode. For this reason, we create an IBGP_OUT route-map that only sets next-hop self if the prefix does not have the RTBH community attached.
Next, to implement source RTBH instead of destination RTBH, we use uRPF to our advantage. With uRPF configured on the edge interface, the router will inspect the source address. If the source address is not reachable via a route pointing out that interface (strict mode), or reachable via any route in the RIB (loose mode), the traffic is dropped. Loose mode does not allow a null0 route to be used to pass the check, so we can use loose mode to implement the least restrictive filtering, while still achieving source RTBH.
Finally, to trigger the blackhole, all we have to do is inject the static route on R4.
Try to ping and trace to 50.0.0.8 from R1’s Lo1 interface. The trace is dropped right at R2 because of the uRPF check.
We can check the uRPF drop statistics on R2 to confirm uRPF is working properly.
Note, you must make sure that R1 is preferring to route to 50/8 via R2 (AS20) and not via R3 (AS30).
Also, another way to verify is to use an ACL with the uRPF check. When an ACL is added, traffic that does not pass the initial uRPF check is check against the ACL. If it passes the ACL, the uRPF check passes. This provides for an “override” of the uRPF check. Since all we’re doing is logging the uRPF drops, we can use a deny any/any ACL.
Source-based RTBH allows an AS to drop traffic from a particular source at the edge. This is better than destination-based RTBH, which drops all traffic destined to the victim. In destination-based RTBH, the target is the victim. In source-based RTBH, the target is the bad actor. However, in the case of DDoS, a single bad source IP address might not be able to be identified.
Source-based RTBH works just like destination-based RTBH, except uRPF is implemented on the edge interfaces to drop traffic based on source address. Either loose or strict mode can be used, because a null0 route is not valid to pass the uRPF check in either mode.
Also note that source-based RTBH also implements destination-based RTBH for whatever prefix is being null-routed.
