If bird bgp has a /32 black hole route, it will cause add_fib_entry to fail
ShawnLeung87 opened this issue · 3 comments
[2023-06-25 17:08:28] DYC/3: check_longer_prefixes(45.195.205.0/24): adding the IPv4 rule with action 0 would add a security hole since there already exists an entry of 32 length with action 2
How to solve this problem, it is impossible for me to filter the /32 black hole route and not pass it to bird. We need to black hole routing for isp operators.
As a reference for others reading this thread, the reasoning behind this safeguard in Gatekeeper has been presented here.
The log entry reports that you are asking a Gatekeeper server to protect the prefix 45.195.205.0/24, but there is a sub-prefix of the /24 prefix that is /32 long and bypasses the protection (i.e. action 2 == GK_FWD_GATEWAY_BACK_NET). If the /32 prefix were a black hole route (i.e. action GK_DROP), adding the prefix 45.195.205.0/24 would go fine. Where's the /32 coming from (e.g. a BPG peer)? Who is injecting that route (i.e. your client)? How do they do it (e.g. a control panel)? Why are they adding a /32 prefix to bypass the protection? There are two conflicting requests in the routing table, so a solution is to identify the source of the conflict and to address it there.
If your Gatekeeper server connects to a single gateway, another solution is to take your Gatekeeper server out of the BGP communication by using a default route. Therefore, your Gatekeeper would not be aware of what's going on through BGP. This approach was introduced in version 1.1. You find more information about it here.
The /32 blackhole route is passed from the downstream client to the bird routing table through the BGP community attribute. For example, when bird has a black hole route of 45.195.205.1/32. It will affect 45.195.205.0/24 Add action 'GK_FWD_GRANTOR ' via add_fib_entry and forward it to grantor.
Gatekeeper is receiving 45.195.205.1/32 as a regular route. Could you verify how these blackhole routes are listed on your routers? For example, what are their gateways?
I don't have enough BGP knowledge to advise you, but I know that BGP can identify these blackhole routes as such. When Bird sees these blackhole routes properly identified as such, Bird passes that information to Gatekeeper (or the Linux kernel) through the type RTN_BLACKHOLE. You can verify this by searching for RTN_BLACKHOLE in the file dependencies/bird/sysdep/linux/netlink.c. If you can change the type of these routes in your BGP sessions, Gatekeeper will know that there's no security violation and allow the coexistence of blackhole routes and GK_FWD_GRANTOR entries.