BGP: To filter or not to filter by network size. That is the question

Introduction

In order to write these post the R+D team and the WARP team joint together after analyzing some security incidents related with BGP, network accessibility, network hijacks and network visibilities.

As you probably know, in the BGP world, there are dozen of ways to filter prefixes. The goal of this post is to show some recommendations in order to have a more stable network, keep the visibility of your prefixes as much as possible and of course reduce the calls to the NOC.

We write this article after an in-depth situation analysis based on several cases that we have received from the LACNIC community.

Scenario

Many ISPs around the world can not (or do not wish) to receive the full routing table (DFZ) which by the time of writing this text is about 700.000 prefixes (IPv4)

The above description could be due to some -not limited- of the following causes:

  • The routers does not have enough RAM to learn all the prefixes (please also note that there could be also several BGP session at the same time)
  • The network admin wants to save CPU cycles in their devices
  • The upstream providers is not announcing the full routing table
  • The network admin wishes to keep his network simple and easy

Anyhow, in the end of the story, the router is not learning the full routing table.

Problem

Not learning the full routing table can bring many partial inconveniences that in the end brings connectivity problems, users complaints, issues accessing some web sites and more.

Why?

Please try to imagine the following case

  1. I have a router (property of EXAMPLE) in Internet that is ONLY learning a partial DFZ.
  2. The routers mentioned in “1” is only learning “big network”, over /20. I mean, the router learns /20, /19, /18, etc. (of course, we are talking about IPv4)
  3. Based in the configuration indicated in number “2”, the router is not going to learn prefixes such as /21, /22, /23 nor /24
  4. So far so good. However, somewhere in Internet, some people hijacked an /21 to the company ACME (hijack, bad configuration, whatever)
  5. ACME decides to perform more specific prefix advertisements, so, he takes his /21 and announces 8 /24 prefixes to the DFZ
  6. Because of the filters configured by EXAMPLE, he will never learn the legitimate /24 prefixes advertised by ACME
  7. EXAMPLE will keep learning the hijacked /21 which obviously will bring connectivity problems aim to the legitimate owner of the network

Topology

The following diagram represents the hypothesis presented in the previous point in a graphic manner to facilitate its understanding.

Recommendation

The following recommendations only for networks that CAN NOT LEARN the full DFZ. One more time, they were found after studying many cases of connectivity problem and network hijacks:

  1. Do not filter more specific network,. We mean, it’s better to learn more specific networks such as: /24, /23, /22 (IPv4 world)
  2. Filter using AS_PATH (like, 2,3 or 4 deep ASs)
  3. Please create your ROS and use RPKI

Some examples (Cisco like)

1. Learning only /22, /23 or /24

router bgp 65002
neighbor 10.0.0.1 remote-as 65001
neighbor 10.0.0.1 route-map FILTRO-IN in
!
ip prefix-list REDESCHICAS seq 5 permit 0.0.0.0/0 ge 22 le 24
!
route-map FILTRO-IN permit 10
match ip address prefix-list REDESCHICAS
!

2. Only learning two AS beyond us

router bgp 65001
neighbor 10.0.0.2 remote-as 65002
neighbor 10.0.0.2 route-map ASFILTER-IN in
!
ip as-path access-list 5 permit ^[0-9]+_$
ip as-path access-list 5 permit ^[0-9]+ [0-9]+_$
!
route-map ASFILTER-IN permit 10
match as-path 5
!

More information