Nibbles & Bits

Netnod 2021 Conference Recap – BGP Prefix Filters

by | November 3, 2021

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.

“We decided to move our rather complex IP address and DHCP management process to ProVision and it has worked out great for us!! The team at 6connect were very flexible and went above and beyond to accommodate our requirements and helped to make the migration as smooth and hitch free as possible. Kudos to the team @ 6connect!”

Premkumar Subramaniam
Head of R&D
viewquest

“We are excited to be partnering with 6connect to leverage their technology and talent. We particularly admire their long-standing IPv6 contributions and their ability to service and support customers in this area, some who are the largest service provider in the world. The 6connect executive leadership team and technical team are great to work with and we look forward to many partnered projects to help customers address their Cloud, IoT and Security needs with IPv6. Automation, workflow and orchestration are critical to the success of most of these projects and 6connect is well positioned to help our mutual customers in those areas.”

Ed Horley
Co-Founder & CEO
HexaBulid

“Enterprises can struggle managing purposefully segmented DDI architectures with any agility. Our partnership with 6connect empowers customers with complex infrastructures to move faster to service the business while consolidating visibility and control over their estate.”

Andrew Wertkin
Chief Strategy Officer,
BlueCat

“6connect’s approach to automation addresses quite a few challenges with physical and virtual networks – how to improve the agility of your current network infrastructure without sacrificing reliability and adoption of future network technologies.”

Pär Lange
Investment Director
SwissCom

“A customer is looking for an integrated solution from a single vendor for both IPAM and DNS. Through the 6connect reseller program, Secure64 is able to offer the most secure DNS solutions married to a unique combination of IPAM and resource provisioning that customers want. It’s a marriage made in heaven.”

Mark Beckett
VP of Marketing
Secure64

“A huge benefit of working with the 6connect team is that they devoted a lot of resources to get our products integrated so we had the turnkey solution that we could take to market. It was very easy to work with their team to get product integrated and successfully launched.”

Mark Beckett
VP of Marketing
Secure64

You have IPv6!

You’re on IPv4.

Explore ProVision Suite

Resource Controller

DNS/DNSSEC

IPAM

DHCP Controller

Peering Controller

REST API

Talk to one of our Engineers

6connect