Last month we attended Netnod Tech Meeting 2021, a one-day event filled with a range of technical talks selected to interest both network operators as well as the broader Internet community. We particularly enjoyed a presentation by Carl Fredrik Lagerfeldt, Global Peering Manager at Telia Carrier.
Carl’s presentation was about using the router infrastructure that is already present for RPKI/ROAs for dynamically configuring custom prefix filters. This topic had been on our minds recently so we wanted to share what we learned from him.
Carl kicked off his presentation by comparing BGP (border gateway protocol) and the global default freeze zone table to a large spaghetti junction — many cars, connections, highways and smaller, local roads in the surrounding area. He posed the question: can you trust all of these to run smoothly all the time? We all know from our experiences in traffic that the answer is no.
Prefix Filters
So how can we control how traffic is routed through BGP? By filtering connections. Currently, there are two main ways to filter connections: blocklists and allowlists. Blocklists have a documentation prefix that rejects specified items and allows everything else through. Allowlists have a documentation prefix that accepts only specified destinations and rejects everything else.
But right now, it is nearly impossible to exact match. More specifics must be included to avoid dropping almost the entire internet table. Carl explained, “this can become a problem when you have a smaller subnet that has been delegated out of PA other space out of a larger supernet which might be announced by a big ISP”.
The issue with prefix filters is that we are only filtering on prefixes and can only check one thing at a time. There is no check for the originated send, so it is possible that our neighbor could announce this from any AS path. The enforce neighbor ASN could be used on the neighbor statement to make sure the BGP neighbor can only announce prefixes behind the ASN that the connection is set up toward. But it can still be set to look like it was announced by Google or Amazon if desired.
Carl discussed how the router lists the services in Los Angeles are 748,000 lines long. To get all the routers running the most recent prefix lists, they set up daily scheduled tasks. Some vendors have solved this by allowing them to store previous lists outside of the main configuration file, making managing routers much easier.
Filtering Using ROAs
A ROA is a tuple that contains a prefix, a max-length and a written ASN. It can be configured statically and can be used to filter. AS neighbors are validated in the policy and are either accepted or dropped. An AS-path filter can be added, but it can be messy for larger customers with many downstreams. It can also be very CPU intensive because there’s no way for the router to compile it into an efficient list to check. So while the filter works, it’s not optimal.
New Concepts
Carl and his team wanted RPKI validation at the same time, so they began exploring how to make that possible. He filled us in on some new concepts that they worked on with vendors in their network.
One of these concepts is multiple ROA tables which is a way to have an independent validation state for the global RPKI table and “fake ROA” which is populated internally. The benefit of multiple ROA tables is the static route which is normally populated using RTR (router to router) protocol. This allows Carl and his team to use multiple row tables. So they can have a table for RPKI and a separate table for “fake ROA”. The “fake ROA” table can be populated using RTR from independent validation. From the existing IRR data, a json file can be generated for the “fake ROA”s which can be served to a router using something like RTR.
AS-set lists (not part of an AS path) is another new concept. AS-set lists are formulated to solve the problem with AS path filters being regex based or the need to specify all ASNs as check functions. This new concept produces a radix tree for quick lookup of ASNs.
A benefit of using ROA is that the protocol allows for multiple concurrent ROAs from different ASNs. Similar to IR, you can have a prefix allowed from multiple originations at the same time. AS-set lists are also a more specific match-based system.
But AS-set has some problems as well. It requires a stable “fake ROA” table. The example Carl provided was configured locally on the router, and while you could do that, pushing it out quickly and automatically will require different caching options. Carl expressed his hopefulness that some of the components of AS-set and ROA will be used in the future.
Vendor Support
Cisco and Arista have committed to support multiple ROA tables and AS-set lists. Cisco has already supported AS-set lists since IOS-XR 7.3.1. Arista is currently working toward AS-set list and multiple ROA tables releases in Tokyo by the end of 2021. Cisco is working toward an AS-set list release in IOS-XR sometime in 2022.
Carl Fredrik Lagerfeldt’s entire presentation at Netnod 2021 can be found here.