REMOTELY TRIGGERED BLACK HOLE FILTERING—DESTINATION BASED AND SOURCE BASED
Destination-Based Remotely Triggered Black Hole Filtering
With a denial-of-service (DoS) attack, in addition to service degradation of the target, there is possible collateral damage such as bandwidth
consumption, processor utilization, and potential service loss elsewhere in the network. One method to mitigate the damaging effects of such
an attack is to black hole (drop) 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.
The challenge is to find a way to quickly drop the offending traffic at the network edge, document and track the black holed destination addresses,
and promptly return these addresses to service once the threat disappears.
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. This process is illustrated in Figure 1.
Figure 1. Destination-Based Black Hole Filtering with Remote Triggering
The three steps in destination-based black hole filtering are summarized below.
Step 1. The setup (preparation)
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.
Step 2. 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.
Step 3. 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).
With a denial-of-service (DoS) attack, in addition to service degradation of the target, there is possible collateral damage such as bandwidth
consumption, processor utilization, and potential service loss elsewhere in the network. One method to mitigate the damaging effects of such
an attack is to black hole (drop) 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.
The challenge is to find a way to quickly drop the offending traffic at the network edge, document and track the black holed destination addresses,
and promptly return these addresses to service once the threat disappears.
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. This process is illustrated in Figure 1.
Figure 1. Destination-Based Black Hole Filtering with Remote Triggering
The three steps in destination-based black hole filtering are summarized below.
Step 1. The setup (preparation)
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.
Step 2. 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.
Step 3. 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).
Comments