This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:

1. Remote Triggered Black Holing

2. BGP Customer triggered black holing

3. BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB

4. Source-based RTBH with Unicast Reverse Path Forwarding (uRPF)

Stay tuned! 😉

In this post I’ll show you how to let your customers to trigger black holing for their prefixes. What I will write is based on my previous post GNS3 Lab: Remote Triggered Black Holing: same scenario, same startup config (the final one of that post).

What is customer triggered blackholing?

Suppose a customer notices one of its hosts is under attack; using customer triggered black holing he can stop malicious traffic toward the attacked host at the ISP edge, and he can do this without the need to ask the provider’s NOC to run RTBH.

While the customer’s staff is analyzing the attack, other hosts remain reachable from the outside, because just the attacked host has been black-holed. Furthermore, all RTBH features can be used: if the customer knows the attack is coming into ISP network from a specific upstream provider, he can just black-hole the attacked prefix on the ISP edge routers facing this specific provider, maintaining full service for networks behind other upstream providers. Of course, when the attack is over, he can resume the prefix and the regular traffic toward it, always avoiding to ask provider’s NOC.

Customer-triggered blackholing let our customers to lower their response time against attacks and it also lower work load and liability of our NOC.

How does it work?

To let our customers to activate RTBH we just need them to announce prefixes they want to black-hole using the specific BGP community. For example, if customer 10 (AS 65310) wants to black-hole 192.168.10.20/32 toward ISP2 (AS 200) he just has to announce that prefix with community 300:102.

As we already did in the Core router, our customers will trigger RTBH just adding a tagged static route toward the prefix they want to blackhole.

Configuration

On the customers routers we need to add the send-community keyword to the neighbor, in order to let them to send communities to our Edge router:

Cust10(config)#router bgp 65310
Cust10(config-router)#neighbor 192.168.0.1 send-community

Cust20(config)#router bgp 65320
Cust20(config-router)#neighbor 192.168.0.5 send-community

We need to set send-community in our Edge router too, so that it could send communities to our RR:

Edge3(config)#router bgp 300
Edge3(config-router)#neighbor 192.168.255.0 send-community

Our RR router already has the send-community keyword, so it already sends communities to other peers (RR clients):

Core#sh run | sec bgp
router bgp 300
 no synchronization
 bgp log-neighbor-changes
 redistribute static route-map RTBH
 neighbor Edge peer-group
 neighbor Edge remote-as 300
 neighbor Edge update-source Loopback0
 neighbor Edge route-reflector-client
 neighbor Edge send-community
 neighbor Edge soft-reconfiguration inbound
 neighbor 192.168.1.2 peer-group Edge
 neighbor 192.168.2.2 peer-group Edge
 neighbor 192.168.3.2 peer-group Edge
 no auto-summary

(look at the neighbor Edge send-community line)

Now, we need to add the RTBH route-map to our customers routers; we will match static route tags in order to add the AS300 RTBH community to prefixes:

route-map RTBH permit 10
 match tag 100
 set community 19660900
route-map RTBH permit 20
 match tag 101
 set community 19660901
route-map RTBH permit 30
 match tag 102
 set community 19660902
route-map RTBH permit 40
 match tag 199
 set community 19660999
route-map RTBH deny 1000

As opposed to the Core router’s RTBH route-map, here we have to remove the no-export community from the set community statements, otherwise black-holed prefixes will not cross the customer’s AS borders.

Now we just have to redistribute static routes into BGP using the route-map:

Cust10(config)#router bgp 65310
Cust10(config-router)#redistribute static route-map RTBH

Cust20(config)#router bgp 65320
Cust20(config-router)#redistribute static route-map RTBH

Testing

At this point, customers just have to add static routes for their attacked prefixes to black-hole traffic at AS300 edges:

Cust10(config)#ip route 192.168.10.20 255.255.255.255 fa1/0 tag 100

In the example, Cust10 announces 192.168.10.20/32 prefix to our Edge3 router with community 300:100 (19660900):

Edge3#sh ip bgp 192.168.10.20
BGP routing table entry for 192.168.10.20/32, version 19
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
     1          2
  65310
    192.168.0.2 from 192.168.0.2 (192.168.10.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 19660900

Edge3 sends it to our RR wich, in turn, reflects it to Edge1 and Edge2 routers:

Edge1#sh ip bgp
BGP table version is 3, local router ID is 192.168.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i192.168.10.0     192.168.0.2              0    100      0 65310 i
*>i192.168.10.20/32 192.0.2.1                0    100      0 65310 ?

Edge1#sh ip bgp 192.168.10.20
BGP routing table entry for 192.168.10.20/32, version 3
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to any peer)
Flag: 0x820
  Not advertised to any peer
  65310
    192.0.2.1 from 192.168.255.0 (192.168.255.0)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Community: no-export no-advertise
      Originator: 192.168.3.2, Cluster list: 192.168.255.0

Edge1#sh ip cef 192.168.10.20
192.168.10.20/32, version 22, epoch 0
0 packets, 0 bytes
  via 192.0.2.1, 0 dependencies, recursive
    next hop 192.0.2.1, Null0 via 192.0.2.1/32
    valid null adjacency

Edge2#sh ip cef 192.168.10.20
192.168.10.20/32, version 22, epoch 0
0 packets, 0 bytes
  via 192.0.2.1, 0 dependencies, recursive
    next hop 192.0.2.1, Null0 via 192.0.2.1/32
    valid null adjacency

Of course we need strong policy enforcement on the customers facing edge router (Edge3) in order to avoid customers to announce prefixes assigned to other customers, or to use unproper communities.

In this post what I missed to implement is customer triggered blackholing on the same Edge3 router. Indeed there is not a route-map which sets next-hop to null0 for blackholed prefixes. This solution works fine for global and ISP-specific blackholing, but not for customers blackholing. To achieve this goal more work is needed, maybe I will write another post about this! 😉

Download the lab

You can download the GNS3 Lab here. Within the .zip file, in the config directory, you can find the previous post configurations and the new “4. Customer trigger blackholing” subdirectory containing the final config.

The following two tabs change content below.

• Bio
• Latest Posts

Pier Carlo Chiodi

Italian, born in 1980, I started working in the IT/telecommunications industry in the late '90s; I'm now a system and network engineer with a deep knowledge of the global Internet and its core architectures, and a strong focus on network automation.

Latest posts by Pier Carlo Chiodi (see all)

• Good MANRS for IXPs route servers made easier - 11 December 2020
• Route server feature-rich and automatic configuration - 13 February 2017
• Large BGP Communities playground - 15 September 2016