This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:
2. BGP Customer triggered black holing
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.
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
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.
Latest posts by Pier Carlo Chiodi (see all)
- Route server feature-rich and automatic configuration - 13 February 2017
- Large BGP Communities playground - 15 September 2016
- RFC7050 (DNS64 prefix via ipv4only.arpa) on RIPE Atlas probes - 9 March 2016