Appendix 3 – BGP Black Hole Guideline¶
Understanding of RTBH using Wanguard¶
To simplify, we will start from the following scenario: an attack is detected by Wanguard Sensor (hereby referred simply as Sensor) that decides to react by using the BGP black hole approach rather than diverting traffic for scrubbing by Wanguard Filter.
In RTBH setup, Sensor would play the role of Trigger. After an attack is detected, Sensor signals the IBR (Internet Border Router) via BGP that all traffic destined to IPv4-Victim has to be dropped. In more details:
● Sensor advertises via BGP an IPv4-Victim/32 prefix with a specific community to be identified as a Black Hole announcement● The IBR receives the announcement and it inserts the route in its routing table as IPv4-Victim/32 with next-hop Null0.● Furthermore, the IBR advertises this route to its upstream providers (ISPs) changing at the same time the community used for internal purposes, to a community which is relevant to the correspondent ISP.
Black-holing on upstream¶
The principle of DDoS mitigation using black hole BGP advertisements is to propagate the BH-prefix from the destination of the attack closest as possible to the source. Most ISPs have defined a public community, based on which their IBRs take the decision to black hole the traffic destined to the victim by routing it to Null0. In comparison to redirect announcements, the black-holing announcements have to be advertised to upstream ISPs.
In order to black hole the attack on the upstream provider, the black hole route must be tagged/marked with an appropriate BGP standard community. This community is provider-specific and has to be requested by each customer to the provider, or it might be found on IRR ASN details (e.g. RIPE, APNIC, ARIN, etc.).
On IBR there shall be a routing-policy applied to the to-ISP-BGP neighbor (export-direction) which shall rewrite the internal BH-community to appropriate ISP’s BH-community.
From a BGP configuration point of view, the Sensor’s configuration is quite similar to Filter’s BGP configuration explained in Appendix 4, having one exception in regards to the BGP community that will be used to mark black hole routes. Considering this, only the IBR’s configuration will be further detailed.
IBR BGP Session with Wanguard Sensor – Cisco Router BGP Configuration¶
r7500(config)# ip bgp-community new-format
r7500(config)# ip community-list <Wanguard-Sensor-community-name> permit <BH-community> → e.g. 65000:66
r7500(config)# route-map Wanguard-Filter-in permit 10
r7500(config-route-map)# match community <Wanguard-Sensor-community-name>
r7500(config-route-map)# set local-preference 200 → it will assure a higher priority against redirect-route
r7500(config-route-map)# set ip next-hop 192.168.255.255 → this target-IP must not be used on your network
r7500(config-route-map)# exit
r7500(config)# route-map Wanguard-Sensor-out deny 10
r7500(config-route-map)# exit
r7500(config)# ip route 192.168.255.255 255.255.255.255 Null0 → BH route for target-IP
r7500(config)# router bgp <Router-AS-number>
r7500(config-router)# bgp log-neighbor-changes
r7500(config-router)# neighbor <Wanguard-Sensor-IP-address> remote-as <Wanguard-Sensor-AS-number>
r7500(config-router)# neighbor <Wanguard-Sensor-IP-address> description <description>
r7500(config-router)# neighbor <Wanguard-Sensor-IP-address> soft-reconfiguration-inbound
r7500(config-router)# neighbor <Wanguard-Sensor-IP-address> route-map Wanguard-Sensor-out out
r7500(config-router)# neighbor <Wanguard-Sensor-IP-address> route-map Wanguard-Sensor-in in
r7500(config-router)# no synchronization
r7500(config-router)# exit
BGP Session with Two ISPs – Cisco Router BGP Configuration¶
r7500(config)# route-map IBR-ISP1-out permit 5 → assumes that additional entries are defined and allow customer-routes
r7500(config-route-map)# match community <Wanguard-Sensor-community-name>
r7500(config-route-map)# set community <ISP1-BH-Community> → e.g.111:9999
r7500(config-route-map)# exit
r7500(config)# route-map IBR-ISP2-out permit 5 → assumes that additional entries are defined and allow customer-routes
r7500(config-route-map)# match community <Wanguard-Sensor-community-name>
r7500(config-route-map)# set community <ISP1-BH-Community> → e.g.222:9999
r7500(config-route-map)# exit
r7500(config)# router bgp <Router-AS-number>
r7500(config-router)# neighbor <IPS1-IP-address> remote-as <ISP1-AS-number>
r7500(config-router)# neighbor <IPS1-IP-address> route-map IBR-ISP1-out out
r7500(config-router)# neighbor <IPS2-IP-address> remote-as <ISP2-AS-number>
r7500(config-router)# neighbor <IPS2-IP-address> route-map IBR-ISP2-out out
r7500(config-router)# no synchronization
r7500(config-router)# exit
When multiple ISPs and IBRs exist, it makes sense to have different BH communities, one for each IBR. In this way you may isolate the source of the attack so that the whole traffic directed to the victim would not be black-holed.
Interaction with traffic diversion / Wanguard Filter¶
It might be the case when:
• Filter advertises redirect BGP route to IBR (initially)• Sensor advertises a black-hole BGP route to IBR (afterward)
The priority shall be on the black-hole advertisement, rather than redirect. This can be achieved easily by using a routing-policy which sets a higher priority on black hole route (e.g. set Local-Preference at 200 for BH-route).
The direction and place where BGP routing-policy has to be implemented are strongly dependent on:
• What role plays on the network the Sensor’s peer-router (e.g. IBR, Route-Reflector, etc.)• Type of BGP relation between Sensor and the peer-router (e.g. iBGP or eBGP)
In order to distinguish between a black hole and a redirect announcement, it is recommended to use different BGP communities on each type of announcement.
The action shall be like on the table below:
Type of BGP announcement (community) |
Route to (next-hop) |
Propagated to ISP |
Redirect (e.g. 65000:99) |
Wanguard Filter |
No |
Black-hole (e.g. 65000:66) |
Null0 |
Yes |
Table 1 – BGP Communities and actions
In the special case when the peer-router of Sensor is the Route-Reflector, then the black-hole action still has to be implemented on IBR. To achieve this, the above sample router configuration has to be adapted and applied to IBR BGP-import policy in relation to the Route-Reflector. No action has to be implemented on RR, while its purpose is route-signaling rather than routing traffic.