Route leaks or even hijacks are one of the biggest flaws in global routing.
If a customer or a peer sends routes outside their scope and a provider accepts them, we call these events route leaks — they are prefixes announced accidentally due to wrongly configured import/export filters or those filters not existing.
Route leaks are referred to more as accidental events, while hijacks are an illegitimate takeover of IP addresses by corrupting routing tables. In such a case, scammers can route the traffic as they wish. To avoid the above-mentioned events, providers MUST implement strict filters on what to accept from peers and customers.
Below is a table of the most known filters, noting their pros and cons:
| Filter type | Easy to implement | Major vendors | Pros | Cons |
| RPKI | ✓ | X | Accepts valid prefixes from peers and customers. No need to define any prefix-lists and other ACLs. | Requires external validators. Takes more time for peers to implement. Not precise currently because peers do not update ROA records properly. |
| prefix-list | X | X | Accepts only defined ranges of prefixes. Allows specifying a dynamic prefix mask (ge, le). | Can’t filter out prefixes by AS-PATH. |
| distribute-list | X | X | Same as prefix-list but less mature. | Can’t filter out prefixes by AS-PATH. Cannot assign dynamic prefix mask as prefix-list does. |
| as-path access-lists | X | X | Filter routes by AS-PATH only. | Cannot filter routes by prefixes. |
| maximum-prefix | X | X | Set maximum prefix number for a peer or a customer to avoid overfilling the Adj-RIBs-In. | This is too aggressive if one side decides to restart the session under some circumstances. |
| Whois database filtering | ✓ | ✓ | Accept prefixes only defined in the whois database. This is more accurate at the moment comparing with RPKI. | Takes more time to converge. Changes are visible typically in 24 hours. Requires external services to update the control plane. |
| RFC 8212 | X | ✓ | Accept and/or announce prefixes only if one of the above mentioned filtering techniques is applied. This is bidirectional forwarding due to filtering in both directions. | Major router operating systems still do not support RFC 8212. |
Another interesting approach I found is implementing roles where each neighbor defines the role: customer, peer, internal, and provider. This approach adds to BGP Open message to establish an agreement of the relationship of two neighbors. Propagated routes are then marked with the IOTC (Internal Only To Customer) attribute according to the agreed relationship allowing prevention of route leaks.
We’ve discussed this draft in short in the IETF FRRouting group but, currently, there is nothing to implement until the release of an RFC — there is still much work to be done. It’s absolutely fine if you use only FRRouting daemons but what about a vendor-agnostic solution?
Instead of using roles in updates and open messages, I found RFC 8212 reasonable to implement. The RFC defines that both peering sides require import/exporter filters explicitly defined. What does this mean? By default, all vendors do not require route-map to be configured for a neighbor.
The snippet below will announce everything it has in its Adj-RIB-Out for neighbor 192.168.3.1.
router bgp 65031 neighbor 192.168.3.1 remote-as 65032 ! address-family ipv4 unicast redistribute connected exit-address-family !
Here we have a new BGP knob bgp ebgp-requires-policy that requires filters (filter-list, distribute-list, prefix-list or route-map defined) for every eBGP session.
router bgp 65031 bgp ebgp-requires-policy neighbor 192.168.3.1 remote-as 65032 ! address-family ipv4 unicast redistribute connected neighbor 192.168.3.1 prefix-list exit4-in in neighbor 192.168.3.1 route-map exit4-out out exit-address-family ! ip prefix-list exit4-in permit 10.0.0.0/24 ! route-map exit4-out permit 10 !
To clarify, if we remove the inbound prefix-list from this neighbor, we will receive zero prefixes due to default behaviour.
router bgp 65031 bgp ebgp-requires-policy neighbor 192.168.3.1 remote-as 65032 ! address-family ipv4 unicast redistribute connected neighbor 192.168.3.1 route-map exit4-out out exit-address-family ! route-map exit4-out permit 10 !
Adj-RIB-In table for neighbor 192.168.3.1 will be equal to zero prefixes. It prevents accepting any prefixes if the policy is forgotten to be defined explicitly.
Even though we see an informational warning that Inbound updates discarded due to missing policy under show bgp neighbors 192.168.3.1.
Hence, instead of just reading the documentation, it’s more fun to play archaeologist and try to implement this into real-life examples.
Adapted from original post which appeared on Donatas’ Blog.
Donatas Abraitis is a systems engineer at Hostinger.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.