RTBH - Remote Triggered Black Hole Filtering

  1. What is RTBH?

  2. Source-based vs destination-based?

  3. What are the pros and cons?

1. What is RTBH?

Simply put, RTBH is a networking technique that allows undesirable traffic to be dropped before it enters the network.  This technique is used to mitigate DDoS attacks from the network layer (layer 3 of the OSI model). There are other ways of getting protection against DDoS attacks that are based different layers, such as the application layer and there are cloud based solutions. RTBH is a technique that would be more commonly used by an ISP, whereas the latter two categories are more relevant to enterprise customers. RTBH might be used versus other network layer mitigation methods, such as ACLS or network IP filtering, because the other techniques may not scale as fast. If an attacker is using proxy addresses and is constantly changing IP addresses, then the edge router might still accept this traffic. RTBH provides a black hole on the edge of the network that drops all traffic, based on either source or destination IP addresses.

2. Source-based vs Destination-based?

There are two methods that RTBH could be implemented in the event of an attack: source-based and destination-based. All dropped traffic is redirected to a null0 interface. Null0 interface is always up and open, but it does not have the ability to receive or forward traffic. When it receives traffic that packet would essentially get dropped in error. 

Destination-based

This method will mitigate the damaging effects of such an attack by dropping traffic destined to the IP address or addresses being attacked and to filter the infected host traffic at the edge of the network closest to the source of the attack. Destination-based IP black hole filtering with remote triggering allows a network-wide destination-based black hole to be propagated by adding a simple static route to the triggering device (trigger). The trigger sends a routing update for the static route using iBGP to the other edge routers configured for black hole filtering. This routing update sets the next hop IP address to another preconfigured static route pointing to the null interface. The steps for this technique are: 

a. The setup

A trigger is a special device that is installed at the NOC exclusively for the purpose of triggering a black hole. The trigger must have an iBGP peering relationship with all the edge routers, or, if using route reflectors, it must have an iBGP relationship with the route reflectors in every cluster. The trigger is also configured to redistribute static routes to its iBGP peers. It sends the static route by means of an iBGP routing update. The Provider Edges (PEs) must have a static route for an unused IP address space. For example, 192.0.2.1/32 is set to Null0. The IP address 192.0.2.1 is reserved for use in test networks and is not used as a deployed IP address.

b. The trigger

An administrator adds a static route to the trigger, which redistributes the route by sending a BGP update to all its iBGP peers, setting the next hop to the target destination address under attack as 192.0.2.1 in the current example. The PEs receive their iBGP update and set their next hop to the target to the unused IP address space 192.0.2.1. The route to this address is set to null0 in the PE, using a static routing entry in the router configuration. The next hop entry in the forwarding information base (FIB) for the destination IP (target) is now updated to null0. All traffic to the target will now be forwarded to Null0 at the edge and dropped.

c. The withdrawal

Once the trigger is in place, all traffic to the target destination is dropped at the PEs. When the threat no longer exists, the administrator must manually remove the static route from the trigger, which sends a BGP route withdrawal to its iBGP peers. This prompts the edge routers to remove the existing route for the target that is pointed to 192.0.2.1 and to install a new route based on the IGP routing information base (RIB).

Source-based 

This technique drops traffic based on a source address or a range of source addresses. Source-based would allow legitimate traffic, whereas destination based RTBH will also drop legitimate traffic. Source-based implementation depends on Unicast Reverse Path Forwarding (URPF), most often loose mode URPF. Loose URPF checks the packet and forwards it if there is a route entry for the source IP of the incoming packet in the router FIB. If the router does not have an FIB entry for the source IP address, or if the entry points to Null0, the Reverse Path Forwarding check fails, and the packet is dropped. Steps that need to be taken are: 

a. The setup

The trigger must have an iBGP peering relationship with all the edge routers or, if using route reflectors, must have an iBGP peer relationship with all the route reflectors in every cluster. The trigger must also be configured to redistribute static routes to its iBGP peers. The PEs must have a static route for an unused IP address space (for example, 192.0.2.1/32) set to Null0. Loose URPF must be configured on all external facing interfaces at the edges (PEs).

b. The trigger

An administrator adds a static route to the trigger. The trigger redistributes the route by sending a BGP update to all its iBGP peers, which sets the next hop to the source IP of the attacker (as 192.0.2.1 in the current example). Each PE receives an iBGP update and sets its next hop to the source IP to the unused IP address space 192.0.2.1. The next hop to this address is set to Null0 using a static routing entry in the router configuration. The next hop entry in the FIB for the source IP address is now updated to Null0. All traffic from the source IP will fail the loose URPF check at the PEs and as a consequence will be dropped.

c. The withdrawal

Once the trigger is in place, all traffic from the source IP addresses will be dropped at the PEs. When the threat no longer exists, the administrator must manually remove the static route from the triggering device, which sends a BGP route withdrawal to its iBGP peers. This prompts the edge routers to remove the existing route for the source IP that points to 192.0.2.1 and to install a new route in the FIB based on the IGP RIB. If this new route is successful, loose URPF checks will pass, and traffic from the blocked source will be forwarded normally.

3. Pros and Cons?

RTBH is just one of many techniques used to help fortify your network security. 

The pros are that it effectively mitigates DDoS and worm attacks, has the ability to quarantine all traffic destined for the target under attack, and it enforces blacklist filtering. While source-based RTBH is more targeted and allows for legitimate traffic to come through, if the attacker is constantly changing and spoofing IP addresses, then it becomes really difficult to keep playing cat and mouse. Imagine an attacker that is able to spoof the address that it wants to shut down and the ISP black holes that source IP. Additionally, When RTBH has to be deployed by manually entering the static route, then a time delay is introduced into the process. 

In order to let legit traffic go through, an alternative could be to forward the packets to a packet scrubber, which will redirect the traffic into the network.

Here is a source for a more detailed explanation: 

200 Security Interview Questions - Cryptography

GRE Tunneling vs IPSEC