Contents
Overview
Introduction
Technical Details
Sample Configurations
Conclusion
Acknowledgments
References and Resources
Overview
Remotely triggered black hole (RTBH) filtering is a technique that provides the ability to drop undesirable traffic before it enters a protected network. This document describes RTBH filtering in IP version 6 (IPv6) and provides sample router configurations for IOS, IOS XE, and IOS XR. This document describes the mitigation of distributed denial of service (DDoS) attacks within a single interior gateway protocol (IGP) domain. It does not describe how to use RTBH filtering for mitigating the attack across multiple providers.
Note: This document will not review all information in Remotely Triggered Black Hole Filtering. Basic RTBH concepts will be presented for completeness. For further details on RTBH uses, operational gains, applications, and deployment considerations, refer to Remotely Triggered Black Hole Filtering.
This document is intended for network design architects, support engineers, and marketing professionals who are responsible for planning, designing, implementing, and operating networks.
Introduction
Black holes, from a network security perspective, are placed in the network where traffic is forwarded and dropped. When an attack has been detected, black holing can be used to drop all attack traffic at the edge of an Internet service provider (ISP) network, based on either destination or source IP addresses. RTBH filtering is a technique that uses routing protocol updates to manipulate route tables at the network edge or anywhere else in the network to specifically drop undesirable traffic before it enters the service provider network.
RTBH filtering provides a method for quickly dropping undesirable traffic at the edge of the network, based on either source addresses or destination addresses, by forwarding it to a Null0 interface. Null0 is a pseudointerface that is always up and can never forward or receive traffic. Forwarding packets to Null0 is a common way to filter packets to a specific destination.
A typical deployment scenario for RTBH filtering would require running Internal Border Gateway Protocol (IBGP) at the access and aggregation points and configuring a separate device in the network operations center (NOC) to act as a trigger. The triggering device sends IBGP updates to the edge that cause undesirable traffic to be forwarded to a Null0 interface.
Destination-Based RTBH 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 when the threat disappears. Destination-based IP black hole filtering with remote triggering, as soon as an attack is identified, 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 of the edge, as shown in Figure 1.
Figure 1. Destination-Based Black Hole Filtering
Traffic destined to the target is then sent to the null interface, and thus it is dropped.
Source-Based RTBH Filtering
With destination-based black holing, all traffic to a specific destination is dropped after the black hole has been activated, regardless of where it is coming from. Obviously, this could include legitimate traffic destined for the target. Source-based black holes provide the ability to drop traffic at the network edge based on a specific source address or range of source addresses.
If the source address (or range of addresses) of the attack can be identified (spoofed or not), it would be better to drop all traffic at the edge based on the source address, regardless of the destination address. This would permit legitimate traffic from other sources to reach the target. Implementation of source-based black hole filtering depends on Unicast Reverse Path Forwarding (uRPF), most often loose mode uRPF.
Loose mode uRPF checks the packet and forwards it if there is a route entry for the source IP of the incoming packet in the router forwarding information base (FIB). If the router does not have an FIB entry for the source IP address, or if the entry points to a null interface, the Reverse Path Forwarding (RPF) check fails and the packet is dropped, as shown in Figure 2. Because uRPF validates a source IP address against its FIB entry, dropping traffic from specific source addresses is accomplished by configuring loose mode uRPF on the external interface and ensuring the RPF check fails by inserting a route to the source with a next hop of Null0. This can be done by using a trigger device to send IBGP updates. These updates set the next hop for the source IP to an unused IP address that has a static entry at the edge, setting it to null as shown in Figure 2.
Figure 2. Source-Based Black Hole Filtering
In this way, traffic that is entering the edge network sourced from a host that has a route pointing to null will result in a uRPF drop.
Technical Details
Building Blocks
Design Options
Building Blocks
This section briefly describes the components and nodes used in various scenarios of RTBH filtering. Some of these have already been mentioned in the introductory material.
Provider Edge
The Provider Edge (PE) routers essentially drop suspicious traffic by forwarding it to a Null0 interface. A static route is configured at the edge and the next hop is set to Null0. Null0 is an invalid interface in Cisco Express Forwarding tables, so all traffic forwarded to a null interface will be dropped by Cisco Express Forwarding and does not require process switching. When uRPF is enabled, traffic sourced from a host for which Cisco Express Forwarding has a route pointing to null will also be dropped. Therefore, using Null0 routes as a way to filter traffic based on source or destination adds minimal overhead to the edge routers.
To install the black hole route, the edge router receives IBGP route updates, which set the next hop of the black holed host to the preconfigured static route. All future traffic to or from the host (if uRPF is enabled) is dropped at the edge because the next hop is equated to Null0. The static route that is used should be for an address in a network that will never be used. Examples in this paper will use 2001:db8:0:ff::abcf.
Trigger
A trigger sends IBGP updates to its peers that need to drop malicious traffic, which set Border Gateway Protocol (BGP) attributes for a network or host to predetermined values. Based on these values, the PEs will drop traffic appropriately. The trigger can be any device that runs BGP and does not necessarily have to be a router. If an Arbor Networks Peakflow SP device is used for anomaly detection, it can also be used as a trigger. A UNIX workstation running BGP can also be used as a triggering device. In this scenario, the trigger (if no route reflector is used) has an IBGP peer relationship with all PEs, as shown in Figure 3.
Figure 3. Trigger
Route Reflector
Route reflectors (RRs) are used for scalability. They alleviate the need for a full-mesh BPG topology between the trigger router and the PE routers. With a network of hundreds of routers, it is not always practical for the trigger to be able to peer with all of them. An RR can peer with many routers at a time, and then the trigger can peer with the RRs to distribute the BGP routes to be dropped. The RRs will in turn distribute the BGP updates to the PEs that they peer with and the traffic will be dropped. In this case, the PEs are also RR clients. In the RR RTBH scenario, the trigger needs to have IBGP peer relationships with all RRs in the network and each PE needs to have at least one peering relationship with one RR, as shown in Figure 4.
Figure 4. Route Reflector
Sinkhole
A sinkhole is a multifaceted security tool—essentially, it is a portion of the network that is designed to accept and analyze attack traffic. Sinkholes were originally used by ISPs to engulf attack traffic, in many cases drawing attacks away from a customer or other target. In more recent times, sinkholes have been used in enterprise environments to monitor attacks, detect scanning activity from infected machines, and generally monitor for other malicious activity.
A sinkhole can be used to pull attack traffic away from the target. Although this technique does not restore connectivity for legitimate users, it can be used to alleviate the collateral damage to other resources at the same site that may have been disabled due to link congestion caused by the attack, as shown in Figure 5.
Figure 5. Sinkhole
A sinkhole is also a useful tool for analyzing an attack. The sinkhole device can be used to forward the attack traffic to a back-end switch where a network analyzer, such as a sniffer or Ethereal, can be used to look at the details of the attack. Additionally, a sinkhole can monitor the bogon and dark IP address space and detect worm or other usually malicious activity. Finally, backscatter traffic with unreachable destinations, including the router Null0 interface, can also be forwarded to the sinkhole for abnormal activity early identification.
The configuration examples in this document do not include a sinkhole, but they could easily be adjusted to forward malicious packets to a predefined destination instead of dropping them by forwarding to Null0.
Design Options
There are two methods for deploying RTBH filtering. The first, and easier, way is called the next hop method, in which the next hop attribute is set on the trigger and is sent in the route update to its IBGP peers at the edge. The second method is to use BGP communities. In the latter method, the trigger sets the BGP community for a route and sends it to the edge routers using IBGP. The edge routers use a route map to match this community and set attributes locally, such as next hop and other routing metrics. There is also an alternative to the community method in which the trigger sets the next hop attribute of the BGP update based on the black holed host. The edge routers receive the updates and install the black hole routes only for their preconfigured static route.
Next Hop Method (Global Black Hole)
The next hop method is also called the global black hole method because the next hop that the trigger sets is sent to all PEs. In the next hop method, the trigger device sets the next hop route for the destination IP address that is to be black holed and then uses IBGP route updates to propagate this route to all the edge routers (IBGP peers). The IBGP peers then set their next hop to the destination based on this update from the trigger or RR (if RRs are used). On every PE, there is a static route for this next hop set to interface Null0. Upon receiving a route update for the destination IP address, all edge routers set their next hop accordingly. The static route for the next hop effectively forwards all traffic for the black holed destination IP address to Null0.
In the following examples, traffic destined to target IPv6 address 2001:db8:3:3::3:3 is black holed. The IBGP updates from the trigger set the next hop for traffic destined to the target to2001:db8:0:ff::abcf. The PEs have a static route for 2001:db8:0:ff::abcf pointing to interface Null0. When they receive the IBGP update for 2001:db8:3:3::3:3 pointing to 2001:db8:0:ff::abcf, they install a route for 2001:db8:3:3::3:3 pointing to Null0. Therefore, all traffic destined to (or sourced from, if uRPF is used for source-based RTBH) 2001:db8:3:3::3:3 is black holed.
Figure 6. Next Hop
Community Method (Regionalized Black Hole)
The community method can also be called the regionalized black hole method because the PEs form regions. Based on the BGP update community attribute, the PEs install or disregard the update for the region. Community-based triggering allows for better control over the drop process. In this technique, the trigger router is used to set different BGP community values and then send these values to its IBGP peers (BGP send community) in its route updates. The edge routers have the flexibility to act or not act on updates based on the community values. So, the decision to act or change route attributes such as next hop is based on community values, and the decision-making process is pushed out to the edge of the network, making it a highly flexible solution that can be used to selectively drop traffic.
In the following example, traffic destined to 2001:db8:3:3::3:3 is black holed. Traffic destined to 2001:db8:4:4::4:4 will not be dropped. The trigger sends IBGP updates for traffic destined to2001:db8:3:3::3:3, with a community of <AS#>:222. The updates for traffic destined to 2001:db8:4:4::4:4 may have the community <AS#>:223. The PE routers have a static route for2001:db8:0:ff::abcf pointing to interface Null0. When they receive the IBGP updates, a route map is applied. IBGP learned routes with a community equal to <AS#>:222 only set the next hop of 2001:db8:0:ff::abcf. In this way, a new route is installed for community <AS#>:222 learned routes (target 2001:db8:3:3::3:3) pointing to Null0. The IBGP routes with other community values such as <AS#>:223 would not be installed because the route map does not set any next hop for these.
Figure 7. Communities
It is obvious that certain community IBGP updates can be selectively black holed based on the PE configuration. For example, a PE that belongs to another region can set the next hop for<AS#>:223 and thus black hole traffic destined to 2001:db8:4:4::4:4. Regionalized RTBH filtering delegates the filtering decision to the edge routers and does not have a central location to control black holed traffic as the global black hole method does.
Regional Next Hop Method (Regionalized Black Hole Alternative)
The regional next hop method can also be called the regionalized black hole alternative because it works similarly to the regionalized black hole method, but with a difference in trigger functionality. Regional next hop triggering delegates responsibility back to the trigger, but still allows for better control over the drop process at the edge. In this technique, the trigger is used to set different BGP next hops for different target destinations (or sources, if uRPF is used for source-based RTBH filtering) and then send these values in the route update to its IBGP peers. The edge routers that do not have a default route have the flexibility to act or not act on updates. If the PE has a static route for the next hop set in the IBGP update that points to Null0, it will install a new route for the target that black holes the traffic. If the IBGP update carries a next hop for which the PE does not have a Null0 static route, the traffic to that target will not be black holed. So, the decision-making process is pushed out to the PEs and their static routes, but the trigger is still responsible for the next hop routes that are pushed to the edge.
In the following example, traffic destined to 2001:db8:3:3::3:3 is black holed. Traffic destined to 2001:db8:4:4::4:4 will not be dropped. The trigger sends IBGP updates for traffic destined to2001:db8:3:3::3:3, with a next hop of 2001:db8:0:ff::abcf. The updates for traffic destined to 2001:db8:4:4::4:4 have a next hop equal to 2001:db8:1:ff::abcf. The PE routers have a static route for 2001:db8:0:ff::abcf pointing to interface Null0. When they receive the IBGP update for 2001:db8:3:3::3:3 pointing to 2001:db8:0:ff::abcf, they install a route for 2001:db8:3:3::3:3 pointing to Null0. In this way, all traffic destined to 2001:db8:3:3::3:3 is black holed. The IBGP routes with a next hop of 2001:db8:1:ff::abcf are not installed because the PE does not have a route for2001:db8:1:ff::abcf. So, traffic to 2001:db8:4:4::4:4 is not dropped. However, as mentioned earlier, this is possible only if the PE does not have a default route. If there is a default route, the route 2001:db8:4:4::4:4 will be installed because the BGP next hop check passes, and all traffic to 2001:db8:4:4::4:4 will be sent to the unknown destination 2001:db8:1:ff::abcf.
Figure 8. Regional Next Hop
It is obvious that, based on the next hop set by the trigger and the PE static routes, certain PEs can drop traffic to (or from, if uRPF is used for source-based RTBH filtering) certain hosts, and other PEs can drop traffic to different hosts. Note that the cooperation of both the trigger and the PE is what provides the granular result. The trigger alone does not decide what is black holed, which makes the regionalized black hole alternative method a flexible solution if there are no default routes installed on the PEs.
Further Information
For additional considerations regarding RTBH filtering, refer to the Remotely Triggered Black-Hole Filtering.
Sample Configurations
This section provides working and tested sample configurations for different IPv6 RTBH filtering implementations with Cisco IOS, IOS XE, and IOS XR routers acting as the trigger and the PE. For Cisco routers with the RR role, separate configurations are provided regardless of the RTBH method used (global, regionalized, regionalized alternative). It includes the following sections:
Configuration Notes
Global Black Hole
Regionalized Black Hole
Regionalized Black Hole Alternative
6PE Remotely Triggered Black Hole Filtering
Route Reflector Configurations
Configuration Notes
Sometimes ICMP unreachable messages generated by the interface that black holes the traffic (Null0) are useful for tracking the entry point of the attack. The source address of the attack traffic can be hijacked within the ISP domain by a sinkhole (mentioned previously) which collects ICMP unreachable messages sent from the router that drops the traffic. The entry point of the attack can be determined by the source IP address in the unreachable messages, which identifies the edge router that sent the message. By analyzing the sinkhole traffic in such scenarios, administrators can tell where the attacker resides and try to locate the attacker. In the sample configurations that follow, IPv6 ICMP unreachables are disabled on the Null0 interface using command no ipv6 unreachables for simplicity. If ICMP unreachable messages are not disabled, it is strongly recommended that they be rate limited using the command ipv6 icmp error-interval <ms> so they will not flood the network or add excessive load to the PE routers.
In the configuration samples in this section, the focus is on destination-based RTBH filtering. For source-based RTBH filtering, the configurations will be nearly identical, except that the trigger will need to redistribute routes for sources (not destinations) that will be black holed and uRPF will need to be enabled on the PE.
Specific caveats for RTBH filtering in 6PE implementations are briefly discussed in the section 6PE Remotely Triggered Black Hole Filtering.
Global Black Hole
This section will present configurations for the global black hole method. Figure 9 shows the network topology. A Cisco IOS, Cisco IOS XE, or Cisco IOS XR router will be the trigger of the RTBH. The PE could also be a Cisco IOS, Cisco IOS XE, or Cisco IOS XR router. The trigger and the PEs are performing BGP peering over their Loopback1 interfaces. Open Shortest Path First (OSPF) is used to route traffic between these loopback interfaces. The black holed host route will be toward 2001:db8:3:3::3:3.
Figure 9. Global Black Hole Topology
The following configuration is for a trigger running Cisco IOS Software or Cisco IOS XE Software. The route map called ipv6-rm is responsible for redistributing static routes to the PEs.send-community must be set for all the peers in the black-hole peer group so they receive the no-export community and respect it by not advertising this redistributed route to any of their external peers. Also, no auto-summary must be set so that specific host routes can be black holed. Otherwise, BGP will automatically summarize the route based on class boundaries. Static routes are then redistributed into BGP after applying the black hole ipv6-rm route map.
The route map matches the route tag 66 and sets the next hop to 2001:db8:0:ff::abcf. A higher value of local preference is desired for choosing a route, so it is set to 200, which is greater than the default value of 100. Also, to ensure that other static routes do not affect this route map, a deny statement is placed at the end.
| Global Black Hole Trigger Config (IOS, IOS XE) |
ipv6 unicast-routing ipv6 cef ! interface Null0 no ipv6 unreachables ! interface Gigabit0/2 ipv6 address 2001:db8:0:ab::1/64 ipv6 ospf 12 area 0 ! interface Loopback1 ipv6 address 2001:db8:0:fa::a:b:c/128 ! ipv6 router ospf 12 router-id 10.10.10.1 redistribute connected router bgp 65444 no synchronization no bgp default ipv4-unicast bgp router-id 10.10.10.1 neighbor black-hole peer-group neighbor black-hole remote-as 65444 neighbor black-hole update-source Loopback1 neighbor 2001:db8:0:fe::a:b:c remote-as 65444 neighbor 2001:db8:0:fe::a:b:c update-source Loopback1 neighbor 2001:db8:0:fb::a:b:c peer-group black-hole no auto-summary address-family ipv6 neighbor black-hole send-community neighbor 2001:db8:0:fb::a:b:c activate network 2001:db8:0:ff::/64 network 2001:db8:3:3::3:3/128 route-map ipv6-rm ! route-map ipv6-rm permit 10 match tag 66 set local-preference 200 set origin igp set community no-export set ipv6 next-hop 2001:db8:0:ff::abcf route-map ipv6-rm deny 20 ! ipv6 route 2001:db8:0:ff::abcf/128 Null0 |
Note that in the preceding configuration, the command network 2001:db8:3:3::3:3/128 route-map ipv6-rm could be replaced with redistribute static route-map ipv6-rm.
The following configuration is for a trigger running Cisco IOS XR Software. Note the syntax differences between Cisco IOS, Cisco IOS XE, and Cisco IOS XR Software. For example, a route map in Cisco IOS Software is now represented by a route policy: my-v6. The send-community option is not needed with Cisco IOS XR Software because the community attributes are, by default, sent to IBGP neighbors only. Route policy my-v6-all must be applied outbound for BGP updates to be sent outbound.
| Global Black Hole Trigger Config (IOS XR) |
|
Note that in the preceding configuration, the command network 2001:db8:3:3::3:3/128 route-policy my-v6 could be replaced with redistribute static route-policy my-v6.
The following is the PE1 configuration for Cisco IOS Software and Cisco IOS XE Software. A static route is set for 2001:db8:0:ff::abcf pointed to Null0. 2001:db8:0:ff::abcf is the next hop set by the trigger router to the black holed destination 2001:db8:3:3::3:3.
| Global Black Hole PE1 Config (IOS, IOS XE) |
ipv6 unicast-routing ! interface Null0 no ipv6 unreachables ! interface Gigabit0/0/1 ipv6 address 2001:db8:0:ab::2/64 ipv6 ospf 12 area 0 ! interface Loopback1 ipv6 address 2001:db8:0:fb::a:b:c/128 ! ipv6 router ospf 12 router-id 10.10.10.2 redistribute connected ! router bgp 65444 no synchronization no bgp default ipv4-unicast bgp router-id 10.10.10.2 neighbor 2001:db8:0:fa::a:b:c remote-as 65444 neighbor 2001:db8:0:fa::a:b:c update-source Loopback1 no auto-summary ! address-family ipv6 neighbor 2001:db8:0:fa::a:b:c activate ! ipv6 route 2001:db8:0:ff::abcf/128 Null0 |
To verify that the configuration works, try to black hole a test destination. Verification requires adding the static route at the trigger router and then observing that the route update is received at the edge and installed with the appropriate next hop in the routing table. The following command adds the static route to Cisco IOS Software and Cisco IOS XE Software:
ipv6 route 2001:db8:3:3::3:3/128 2001:db8:0:ff::abcf tag 66For Cisco IOS XR Software, the static route at the trigger is added using the following command:
router static address-family ipv6 unicast 2001:db8:3:3::3:3/128 2001:db8:0:ff::abcf tag 66
It is equally important to verify that the target can be put back into service by deleting the static route at the trigger router.
On the edge router, you can observe the update being received and the route to the target destination being inserted into the IP routing table with the next hop set to 2001:DB8:0:FF::ABCF. The following shows the sample output in Cisco IOS Software or Cisco IOS XE Software.
| Global Black Hole PE1 Debugs (IOS, IOS XE) |
|
The routing table of PE1 running Cisco IOS Software or Cisco IOS XE Software follows. As expected, the route to the target 2001:DB8:3:3::3:3 points to 2001:DB8:0:FF::ABCF and recursively to Null0.
| Global Black Hole PE1 Routes (IOS, IOS XE) |
|
If PE1 is a Cisco IOS XR router, its configuration changes syntax compared to Cisco IOS Software and Cisco IOS XE Software. Route policy my-v6 must be applied inbound for BGP updates to be received and processed from the trigger.
| Global Black Hole PE1 Config (IOS XR) |
interface Null 0 ipv6 unreachables disable ! interface Gigabit0/5/0/28 ipv6 address 2001:db8:0:ab::2/64 ! interface Loopback1 ipv6 address 2001:db8:0:fb::a:b:c/128 ! router ospfv3 12 router-id 10.10.10.3 redistribute connected area 0 interface GigabitEthernet0/5/0/28 ! ! router static address-family ipv6 unicast 2001:db8:0:ff::abcf/128 Null0 ! router bgp 65444 bgp router-id 10.10.10.3 address-family ipv6 unicast ! neighbor 2001:db8:0:fa:0:a:b:c remote-as 65444 update-source Loopback1 address-family ipv6 unicast route-policy my-v6 in ! route-policy my-v6 pass end-policy |
The following command adds the static route on a Cisco IOS and Cisco IOS XE trigger:
ipv6 route 2001:db8:3:3::3:3/128 2001:db8:0:ff::abcf tag 66The following command adds the static route on the Cisco IOS XR trigger.
router static
address-family ipv6 unicast
2001:db8:3:3::3:3/128 2001:db8:0:ff::abcf tag 66After you add the static route, you can verify the update on the edge router. The routing debugs are shown in the following illustration:
| Global Black Hole PE1 Debugs (IOS XR) |
RP/0/RSP0/CPU0:9010-b#debug routing ipv6 Thu Sep 15 17:20:00.829 EST RP/0/RSP0/CPU0:9010-b#debug bgp update ipv6 unicast in Thu Sep 15 17:20:02.718 EST RP/0/RSP0/CPU0:9010-b# Sep 20 12:32:44.288 : bgp[1047]: [rtr]: UPDATE from 2001:db8:0:fa:0:a:b:c contains nh 2001:db8:0:ff::abcf/128, gw_afi 5, flags 0x0, nlri_afi 5 RP/0/RSP0/CPU0:Sep 20 12:32:44.290 : bgp[1047]: [rtr]: NH-Validate-Create: addr=2001:db8:0:ff::abcf/128, len=16, nlriafi=5, nbr=2001:db8:0:fa:0:a:b:c, gwafi=5, gwlen=32, gwaddrlen=128::: nhout=0x506ec57c, validity=1, attrerror=0x0000 RP/0/RSP0/CPU0:Sep 20 12:32:44.290 : bgp[1047]: [rtr]: UPDATE from 2001:db8:0:fa:0:a:b:c contains NLRIs for IPv4-Unicast AF which is not configured globally RP/0/RSP0/CPU0:Sep 20 12:32:44.312 : bgp[1047]: [rtr] (ip6u): Received UPDATE from 2001:db8:0:fa:0:a:b:c with attributes: RP/0/RSP0/CPU0:Sep 20 12:32:44.325 : bgp[1047]: [rtr] (ip6u): nexthop 2001:db8:0:ff::abcf/128, origin i, localpref 200, metric 0, community no-export RP/0/RSP0/CPU0:Sep 20 12:32:44.325 : bgp[1047]: [rtr] (ip6u): Received prefix 2001:db8:3:3::3:3/128 (path ID: none) from 2001:db8:0:fa:0:a:b:c RP/0/RSP0/CPU0:Sep 20 12:32:44.329 : ipv6_rib[1128]: RIB Routing: Vrf: "default", Tbl: "default" IPv6 Unicast, Add active route 2001:db8:3:3::3:3/128 via 2001:db8:0:ff::abcf interface None, metric [200/0] (fl: 0x8/0x0) label None, by client bgp |
The routing table of PE1 running Cisco IOS XR Software follows. As expected, the route to the target 2001:DB8:3:3::3:3 points to 2001:DB8:0:FF::ABCF and recursively to Null0.
| Global Black Hole PE1 Routes (IOS XR) |
|
Note the IPv6 cef route for 2001:db8:3:3::3:3 points recursively to 2001:db8:0:ff::abcf and will finally resolve to Null0. The output is different from Cisco IOS Software and Cisco IOS XE Software output, where the recursive lookup is shown directly to Null0. However, the result will be black holed traffic toward the destination for Cisco IOS, Cisco IOS XE, and Cisco IOS XR PEs.
[Back to Sample Configurations]
Regionalized Black Hole
With a simple black hole, all traffic to the target is dropped at the edge of the network. The service provider may want to be able to control the application of the black holes and limit them to a predefined region of edge routers if they can determine that the attack is coming from a specific region. This would allow uninterrupted traffic from other regions of the network to the targeted host or network while mitigating the attack. This section provides sample configurations for such deployments.
As shown in the following figure, the set of four edge routers is divided into two regions. PE1 and PE2 belong to region 1, and PE3 and PE4 belong to region 2. To black hole a target in region 1, the tag 66 must be attached to the static route. If an edge router in region 2 is suspected (for example, from the sinkhole traffic analysis) to be forwarding attack traffic, the tag to be attached to the static route would be different.
Figure 10. Regionalized Black Hole Topology
The configuration of a trigger running Cisco IOS Software or Cisco IOS XE Software is presented in the following configuration. Based on the tag for each of the static routes, different communities are set using route map ipv6-rm on the trigger router. Route map ipv6-rm matches on IPv6 route tag 66 for the black holed destination 2001:db8:3:3::3:3 and sets the community attribute in the BGP updates to <AS>:222. Also, to ensure that other static routes are not affected by this route map, a deny statement is placed at the end. The trigger may need to set different community attributes for other PE regions and route tags. This functionality can be added by updating ipv6-rm accordingly. The route updates are sent to all IBGP peers in theblack-hole peer group. Each IBGP peer applies a route map on all incoming advertisements and either accepts or rejects the route after matching the community string.
| Regionalized Black Hole Trigger Config (IOS, IOS XE) |
ipv6 unicast-routing ipv6 cef ! interface Null0 no ipv6 unreachables interface Gigabit0/2 ipv6 address 2001:db8:0:ab::1/64 ipv6 ospf 12 area 0 interface Loopback1 ipv6 address 2001:db8:0:fa::a:b:c/128 ! ipv6 router ospf 12 router-id 10.10.10.1 redistribute connected ! router bgp 65444 no synchronization no bgp default ipv4-unicast bgp router-id 10.10.10.1 neighbor black-hole peer-group neighbor black-hole remote-as 65444 neighbor black-hole update-source Loopback1 neighbor 2001:db8:0:fe::a:b:c remote-as 65444 neighbor 2001:db8:0:fe::a:b:c update-source Loopback1 neighbor 2001:db8:0:fb::a:b:c peer-group black-hole no auto-summary address-family ipv6 neighbor black-hole send-community neighbor 2001:db8:0:fb::a:b:c activate network 2001:db8:0:ff::/64 network 2001:db8:3:3::3:3/128 route-map ipv6-rm ! route-map ipv6-rm permit 10 match tag 66 set local-preference 200 set origin igp set community 65444:222 no-export set ipv6 next-hop 2001:db8:0:ff::abcf !-- !-- Set other communities for different matched !-- tag values in different PE regions !-- route-map ipv6-rm deny 20 ! ipv6 route 2001:db8:0:ff::abcf/128 Null0 |
Note that in the preceding configuration, command 2001:db8:3:3::3:3/128 route-map ipv6-rm could be replaced with redistribute static route-map ipv6-rm.
The following configuration is for a trigger running Cisco IOS XR Software. Note the syntax differences between Cisco IOS, Cisco IOS XE, and Cisco IOS XR Software. For example, a route map in Cisco IOS Software is now represented by a route policy: my-v6. Route policy my-v6-all must be applied outbound for BGP updates to be sent outbound. send-community is not needed with Cisco IOS XR Software because the community attributes are always sent to an IBGP neighbor.
| Regionalized Black Hole Trigger Config (IOS XR) |
|
Note that in the preceding configuration, command network 2001:db8:3:3::3:3/128 route-policy my-v6 could be replaced with redistribute static route-policy my-v6.
In the following configuration, the PE1 running Cisco IOS Software or Cisco IOS XE Software is applying route map ipv6-reg-rm to filter between community attributes. For community<AS>:222, the route map sets the next hop to 2001:db8:0:ff::abcf, which has a static route that points to Null0. All other BGP updates are accepted by ipv6-reg-rm without further processing specifically for RTBH filtering. If PE1 only needed to accept <AS>:222 and reject other communities, or to reject specific communities, route map ipv6-reg-rm would need to be adjusted to permit or deny them. The community is reset by the PE to no-advertise to ensure that this route is never re-advertised using BGP. To avoid the possibility that externally generated routes could have the same community, only routes that are originated in the local AS are accepted.
| Regionalized Black Hole PE1 Config (IOS, IOS XE) |
ipv6 unicast-routing ! interface Null0 no ipv6 unreachables ! interface Gigabit0/0/1 ipv6 address 2001:db8:0:ab::2/64 ipv6 ospf 12 area 0 ! interface Loopback1 ipv6 address 2001:db8:0:fb::a:b:c/128 ! ipv6 router ospf 12 router-id 10.10.10.2 redistribute connected ! router bgp 65444 no synchronization no bgp default ipv4-unicast bgp router-id 10.10.10.2 neighbor 2001:db8:0:fa::a:b:c remote-as 65444 neighbor 2001:db8:0:fa::a:b:c update-source Loopback1 no auto-summary ! address-family ipv6 neighbor 2001:db8:0:fa::a:b:c activate neighbor 2001:db8:0:fa::a:b:c route-map ipv6-reg-rm in ! ! ip community-list 1 permit 65444:222 ip as-path access-list 1 permit ^$ ! route-map ipv6-reg-rm permit 10 match community 1 match as-path 1 set ipv6 next-hop 2001:db8:0:ff::abcf set community no-advertise !-- !-- Match on other community attributes !-- for other regions and permit or deny them !-- !-- Permit or deny all other BGP updates !-- They are permitted in this example. !-- route-map ipv6-reg-rm permit 20 ipv6 route 2001:db8:0:ff::abcf/128 Null0 |
To verify that the configuration works, try to black hole a test destination. Verification requires adding the static route at the trigger router and then observing that the route update is received at the edge and installed with the appropriate next hop in the routing table. The following command adds the static route to Cisco IOS Software and Cisco IOS XE Software:
ipv6 route 2001:db8:3:3::3:3/128 2001:db8:0:ff::abcf tag 66
For Cisco IOS XR Software, the static route at the trigger is added using the following command:
router static address-family ipv6 unicast 2001:db8:3:3::3:3/128 2001:db8:0:ff::abcf tag 66
On the edge router, you can observe the update being received and the route to the target destination being inserted into the IP routing table with the next hop set to 2001:DB8:0:FF::ABCFand thus recursively to Null0. The following shows the output for Cisco IOS Software or Cisco IOS XE Software.
| Regionalized Black Hole PE1 Debugs (IOS, IOS XE) |
|
If the PE1 is a Cisco IOS XR router, its configuration changes syntax compared to Cisco IOS Software and Cisco IOS XE Software. For example, a route map in Cisco IOS Software is now represented by a route policy: my-v6. If PE1 only needed to accept <AS>:222 and reject other communities, or to reject specific communities, route policy my-v6 would need to be adjusted to pass or drop them.
| Regionalized Black Hole PE1 Config (IOS XR) |
|
The following command adds the static route on a Cisco IOS and Cisco IOS XE trigger:
ipv6 route 2001:db8:3:3::3:3/128 2001:db8:0:ff::abcf tag 66
The following command adds the static route on the Cisco IOS XR trigger:
router static address-family ipv6 unicast 2001:db8:3:3::3:3/128 2001:db8:0:ff::abcf tag 66
After you add the static route, you can verify the update on the edge router. The output is shown in the following configuration.
| Regionalized Black Hole PE1 Debugs (IOS XR) |
|
Note the IPv6 cef route for 2001:db8:3:3::3:3 points recursively to 2001:db8:0:ff::abcf, which will finally resolve to Null0. The output is different from Cisco IOS Software and Cisco IOS XE Software output, where the recursive lookup is shown directly to Null0, but the result will be black holed traffic toward the destination for Cisco IOS, Cisco IOS XE, or Cisco IOS XR PEs.
If the attack is coming from all the edge routers or cannot be regionalized, the static route with an different tag (for example, 86) will drop all traffic destined to the target from all four edge routers. Although this is often common practice, it has been omitted from the preceding configuration example for brevity. To implement the different tag, you would use one more community sent in the trigger BGP updates for tag 86 that is matched and denied in all PEs' route maps (Cisco IOS Software, Cisco IOS XE Software) and route policies (Cisco IOS XR Software).
[Back to Sample Configurations]
Regionalized Black Hole Alternative
If the provider does not have default routes at the network edges, it is possible to regionalize the application of black hole triggers by using a different next hop on the trigger router for different tags. The edge router will black hole traffic to this destination, depending on whether it has a route to the next hop. If a BGP peer (PE) receives a route with the next hop set but does not have a route to the next hop, it will not install the route because the route fails the next hop test. Figure 11 illustrates the topology that resembles the regionalized black hole topology that was presented in the previous section.
Figure 11. Regionalized Black Hole Alternative Topology
The configuration of a trigger running Cisco IOS Software or Cisco IOS XE Software is shown in the following configuration. Based on the tag for each of the static routes, different next hops are set using route map ipv6-rm on the trigger router. Route map ipv6-rm matches on IPv6 route tag 66 and sets the next hop to 2001:db8:0:ff::abcf in the BGP updates to the PEs. For routes with tag 76, route map ipv6-rm sets the community to 2001:db8:1:ff::abcf. To ensure that other static routes do not affect this route map, a deny statement is placed at the end. The trigger may need to set different next hop attributes for other PE regions and route tags. This functionality can be added by updating ipv6-rm accordingly. send-community must be set for all the peers in the black-hole peer group so they receive the no-export community and respect it by not advertising this redistributed route to any of their external peers.
| Regionalized Black Hole Alternative Trigger Config (IOS, IOS XE) |
ipv6 unicast-routing ipv6 cef ! interface Null0 no ipv6 unreachables ! interface Gigabit0/2 ipv6 address 2001:db8:0:ab::1/64 ipv6 ospf 12 area 0 ! interface Loopback1 ipv6 address 2001:db8:0:fa::a:b:c/128 ! ipv6 router ospf 12 router-id 10.10.10.1 redistribute connected router bgp 65444 no synchronization no bgp default ipv4-unicast bgp router-id 10.10.10.1 neighbor black-hole peer-group neighbor black-hole remote-as 65444 neighbor black-hole update-source Loopback1 neighbor 2001:db8:0:fe::a:b:c remote-as 65444 neighbor 2001:db8:0:fe::a:b:c update-source Loopback1 neighbor 2001:db8:0:fb::a:b:c peer-group black-hole no auto-summary address-family ipv6 neighbor black-hole send-community neighbor 2001:db8:0:fb::a:b:c activate network 2001:db8:0:ff::/64 network 2001:db8:3:3::3:3/128 route-map ipv6-rm network 2001:db8:4:4::4:4/128 route-map ipv6-rm ! route-map ipv6-rm permit 10 match tag 66 set local-preference 200 set origin igp set community no-export set ipv6 next-hop 2001:db8:0:ff::abcf route-map ipv6-rm permit 20 match tag 76 set local-preference 200 set origin igp set community no-export set ipv6 next-hop 2001:db8:1:ff::abcf !-- !-- Set other next hops for different matched !-- tag values in different PE regions !-- route-map ipv6-rm deny 30 ! ipv6 route 2001:db8:0:ff::abcf/128 Null0 ipv6 route 2001:db8:1:ff::abcf/128 Null0 |
Note that in the preceding configuration, the following commands could be replaced with redistribute static route-map ipv6-rm.
network 2001:db8:3:3::3:3/128 route-map ipv6-rm network 2001:db8:4:4::4:4/128 route-map ipv6-rm
The following configuration is for a trigger running Cisco IOS XR Software. Note the syntax differences between Cisco IOS, Cisco IOS XE, and Cisco IOS XR Software. For example, a route map in Cisco IOS Software is now represented by a route policy: my-v6. Route policy my-v6-all must be applied outbound for BGP updates to be sent outbound. The send-communityoption is not needed in Cisco IOS XR Software because the community attributes are, by default, sent to IBGP neighbors only.
| Regionalized Black Hole Alternative Trigger Config (IOS XR) |
|
Note that in the preceding configuration, the following commands could be replaced with redistribute static route-policy my-v6.
network 2001:db8:3:3::3:3/128 route-policy my-v6 network 2001:db8:4:4::4:4/128 route-policy my-v6
The configuration for a PE1 running Cisco IOS Software or Cisco IOS XE Software follows. PE1 has a static route for 2001:db8:0:ff::abcf pointing to Null0, but no route for 2001:db8:1:ff::abcf. Therefore, when receiving an update that has a next hop of 2001:db8:0:ff::abcf, the route will be installed in the routing table, which will not be the case for updates with a next hop of2001:db8:1:ff::abcf.
| Regionalized Black Hole Alternative PE1 Config (IOS, IOS XE) |
ipv6 unicast-routing ! interface Null0 no ipv6 unreachables ! interface Gigabit0/0/1 ipv6 address 2001:db8:0:ab::2/64 ipv6 ospf 12 area 0 ! interface Loopback1 ipv6 address 2001:db8:0:fb::a:b:c/128 ! ipv6 router ospf 12 router-id 10.10.10.2 redistribute connected ! router bgp 65444 no synchronization no bgp default ipv4-unicast bgp router-id 10.10.10.2 neighbor 2001:db8:0:fa::a:b:c remote-as 65444 neighbor 2001:db8:0:fa::a:b:c update-source Loopback1 no auto-summary ! address-family ipv6 neighbor 2001:db8:0:fa::a:b:c activate ! !-- !-- Static routes for next hops of route !-- updates that need to be black holed !-- ipv6 route 2001:db8:0:ff::abcf/128 Null0 |
If PE1 is a Cisco IOS XR router, its configuration changes syntax compared to Cisco IOS Software and Cisco IOS XE Software, as shown in the following configuration:
| Regionalized Black Hole Alternative PE1 Config (IOS XR) |
interface Null 0 ipv6 unreachables disable ! interface Gigabit0/5/0/28 ipv6 address 2001:db8:0:ab::2/64 ! interface Loopback1 ipv6 address 2001:db8:0:fb::a:b:c/128 ! router ospfv3 12 router-id 10.10.10.3 redistribute connected area 0 interface GigabitEthernet0/5/0/28 ! ! router static ! !-- Static routes for next hops of route !-- updates that need to be black holed !-- address-family ipv6 unicast 2001:db8:0:ff::abcf/128 Null0 ! router bgp 65444 bgp router-id 10.10.10.3 address-family ipv6 unicast ! neighbor 2001:db8:0:fa:0:a:b:c remote-as 65444 update-source Loopback1 address-family ipv6 unicast route-policy my-v6 in ! route-policy my-v6 pass end-policy |
The following command adds the static route on a Cisco IOS and Cisco IOS XE trigger:
ipv6 route 2001:db8:3:3::3:3/128 2001:db8:0:ff::abcf tag 66
The following command adds the static route on the Cisco IOS XR trigger:
router static
address-family ipv6 unicast
2001:db8:3:3::3:3/128 2001:db8:0:ff::abcf tag 66After adding the static route, you can verify the update on the edge router. The route for 2001:db8:3:3::3:3 will be installed in PE1 and will be black holed.
On the other hand, the following route updates (for tag 76) would be received but would not be installed.
The following command adds the route to target 2001:db8:4:4::4:4 on the Cisco IOS and Cisco IOS XE trigger:
ipv6 route 2001:db8:4:4::4:4/128 2001:db8:1:ff::abcf tag 76
The following command adds the route to target 2001:db8:4:4::4:4 on the Cisco IOS XR trigger:
router static address-family ipv6 unicast 2001:db8:4:4::4:4/128 2001:db8:1:ff::abcf tag 76
When the preceding commands (for tag 76) are used, you would see that PE1 receives the route in the BGP updates but does not install it because it has no valid adjacency for2001:db8:1:ff::abcf. Therefore, based on which region a PE belongs to, equivalent static routes can be configured to drop traffic to specific destinations advertised in BGP next hops from the trigger.
If the attack is coming from all the edge routers or cannot be regionalized, the static route with an different tag (for example, 86) will drop all traffic destined to the target from all four edge routers. Although this is often common practice, it has been omitted from the preceding configuration example for brevity. To implement the different tag, you would use one more next hop set in the trigger's route map (Cisco IOS Software, Cisco IOS XE Software) and route policy (Cisco IOS XR Software) and a separate static route for that next hop pointing to Null0 on all PEs.
6PE Remotely Triggered Black Hole Filtering
For RTBH deployments using the Cisco IPv6 Provider Edge (6PE) Router, the 6PE routers that receive MP-BGP updates will install a route for the target pointing to an IPv6 address in the format of ::FFFF:<remote peer IPv4>. This behavior is driven by RFC 4798:
"The 6PE routers MUST exchange the IPv6 prefixes over MP-BGP sessions as per [RFC2545] running over IPv4. The MP-BGP Address Family Identifier (AFI) used MUST be IPv6 (value 2). In doing so, the 6PE routers convey their IPv4 address as the BGP Next Hop for the advertised IPv6 prefixes. The IPv4 address of the egress 6PE router MUST be encoded as an IPv4-mapped IPv6 address in the BGP Next Hop field. This encoding is consistent with the definition of an IPv4-mapped IPv6 address in [RFC4291] as an "address type used to represent the address of IPv4 nodes as IPv6 addresses". In addition, the 6PE MUST bind a label to the IPv6 prefix as per [RFC3107]. The Subsequence Address Family Identifier (SAFI) used in MP-BGP MUST be the "label" SAFI (value 4) as defined in [RFC3107]. Rationale for this and label allocation policies are discussed in Section 3."
In this way, the 6PE router that installs the route will use an IPv4-mapped IPv6 address as the next hop of the learned route from the trigger.
For 6PE RTBH filtering, it is good practice to use the same black holing IP address used for IPv4 traffic. If we assume the IP used is 192.168.2.3, the black holing next hop learned by the 6PE router for the target will be ::FFFF:192.168.2.3. Configuring on the 6PE router a static route for IPv4 192.168.2.3 and IPv6 ::FFFF:192.168.2.3 pointing to Null0 will black hole traffic to the target.
To deploy a regionalized black hole using the Cisco IOS XR 6PE Router, note that the 6PE router inbound route policy (my-v6 in the preceding examples) will need to set the next hop to the IPv4 address 192.168.2.3. The Cisco IOS XR 6PE Router will convert the next hop to ::FFFF:192.168.2.3 and traffic will be black holed. If the next hop is set by the policy to an IPv6 address with a format different from ::FFFF:<IPv4 address>, the 6PE router running Cisco IOS XR Software will ignore the next hop.
[Back to Sample Configurations]
Route Reflector Configurations
As explained previously, when RRs are used, they are deployed between the trigger and the PEs. Their role is to redistribute the BGP routes to their BGP peering PEs without having the trigger peer with all PEs in the AS. Thus, having a few RRs peer with many PEs provides scalability that one trigger could not provide for all the PEs. Figure 12 shows a typical RR deployment. The trigger peers with the RR that, in turn, has the PEs as its BGP peers.
Figure 12. Route Reflector Topology
When an RR is used, the trigger is no longer directly responsible for redistributing the static routes to the PEs. Instead, it redistributes the routes to the RRs. The RR replays the routes with the same IBGP attributes to the PEs, which will process them based on the RTBH method used (global, regionalized, or regionalized alternative). In this way, the trigger configurations shown in the preceding sections that are labeled as triggers will be relevant for the trigger in an RR scenario as well. However, the peers in the black-hole group will now be the RR IP addresses because these are the trigger's BGP peers.
As far as the PEs are concerned, their configurations do not change, either. Of course, the PEs will now need to peer BGP with the RRs instead of peering with the trigger. Otherwise, nothing will change in the PE configuration. The PEs will receive and process the BGP updates regardless of whether the updates originate from the trigger or the RRs.
The following BGP configuration lines are needed on the RR running Cisco IOS Software or Cisco IOS XE Software. These configurations enable the RR to peer BGP with the trigger and allow the PEs to receive the route updates from the trigger and then replay them to the PEs. Because the RR clients (PEs) are fully meshed with the RRs, client-to-client reflection can be disabled using no bgp client-to-client reflection. The command neighbor black-hole route-reflector-client configures the router as a BGP RR and the specified neighbors in the black-hole peer group (PEs) are configured as its clients. OSPFv3 and Layer 3 connectivity must exist for the RR to be able to peer with the trigger and the PEs.
| Route Reflector BGP Config (IOS, IOS XE) |
! !-- Assuming L3 connectivity between trigger and route !-- reflector is already established and OSPFv3 is !-- redistributing loopback subnets between them !-- router bgp 65444 no bgp client-to-client reflection !-- !-- BGP peer with the trigger and the PEs !-- 2001:db8:0:fa::a:b:c is the trigger !-- 2001:db8:0:fb::a:b:c is PE1 !-- bgp router-id 10.10.10.10 neighbor black-hole peer-group neighbor black-hole remote-as 65444 neighbor black-hole update-source Loopback1 neighbor 2001:db8:0:fb::a:b:c peer-group black-hole neighbor 2001:db8:0:fa::a:b:c remote-as 65444 neighbor 2001:db8:0:fa::a:b:c update-source Loopback1 no auto-summary address-family ipv6 neighbor black-hole route-reflector-client neighbor 2001:DB8:0:fa:0:A:B:C activate neighbor 2001:DB8:0:fb:0:A:B:C activate |
For Cisco IOS XR RRs, the BGP configuration is shown in the following configuration. There are syntax differences between Cisco IOS, Cisco IOS XE, and Cisco IOS XR Software.
| Route Reflector BGP Config (IOS XR) |
!-- !-- Assuming L3 connectivity between trigger and route !-- reflector is already established and OSPFv3 is !-- redistributing loopback subnets between them !-- router bgp 65444 bgp router-id 10.10.10.10 address-family ipv6 unicast bgp client-to-client reflection disable ! neighbor-group black-hole remote-as 65444 update-source Loopback1 address-family ipv6 unicast route-reflector-client route-policy my-v6-all out !-- !-- BGP peer with the trigger and the PEs !-- 2001:db8:0:fa::a:b:c is the trigger !-- 2001:db8:0:fb::a:b:c is PE1 !-- neighbor 2001:db8:0:fa:0:a:b:f remote-as 65444 update-source Loopback1 neighbor 2001:db8:0:fb:0:a:b:c use neighbor-group black-hole ! route-policy my-v6-all pass end-policy |
When a route is added on the trigger, the route will be redistributed to the RR and, in turn, make its way to the PEs.
To summarize, compared to the trigger-only configurations, the PE configuration will not change based on using the global, regionalized, or regionalized alternative RTBH methods. The change that does occur is that the PEs need to peer BGP with the RR. The trigger configuration changes based on which RTBH method is used, and the trigger peers BGP with the RRs. The RR configuration will not change based on the RTBH method; it will only peer BGP with the trigger and the PEs and carry the two RR-specific commands client-to-client reflection and bgp client-to-client reflection.
[Back to Sample Configurations]
Conclusion
In conclusion, RTBH filtering for IPv6 does not include functional or architectural changes. This document presented the RTBH fundamentals and provided sample configurations for the different RTBH implementation options for Cisco IOS, Cisco IOS XE, and Cisco IOS XR Software. For more details about RTBH operational gains, applications, and deployment considerations, please see Remotely Triggered Black Hole Filtering. Special caveats also exist in 6PE deployments; these were discussed briefly in this document. Leveraging the configurations and information in this document should help network administrators implement IPv6 RTBH filtering in their newly deployed IPv6 networks more easily.
Acknowledgments
Portions of this paper are taken from Remotely Triggered Black Hole Filtering. Parts are also taken from Worm Mitigation Technical Details.
Author: Panos Kampanakis (pkampana[at]cisco[dot]com) is a member of the Applied Intelligence team in the Security Intelligence Operations organization.
References and Resources
Remotely Triggered Black Hole Filtering
https://www.cisco.com/c/dam/en_us/about/security/intelligence/blackhole.pdf
Worm Mitigation Technical Details
//www.cisco.com/web/about/security/intelligence/worm-mitigation-whitepaper.html
RFC 5635: Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)
http://tools.ietf.org/html/rfc5635
Service Provider Infrastructure Security Techniques
//www.cisco.com/web/about/security/intelligence/sp_infrastruct_scty.html
This document is part of Cisco Security Intelligence Operations.
This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.