Keeping Public BGP Routing in Check with IRR and RPSL

BGP is the unsung hero (or villain, depending on the day) of the internet and is a bit like that coworker who typically kicks ass but occasionally causes some office drama no one wants to deal with. Most of the time, it keeps our packets flowing from source to destination across the internet, but when things go sideways, the results initiate a Reason for Outage (RFO) and spawns countless meetings about "how we prevent this from ever happening again". Blackholes? Route leaks? Hijacks? These things happen every day, far more than most are aware. The goal of this article is to shed some light on what maintaining responsible routing policy looks like with BGP and helping keep you away from being on the hook for said RFOs or painful meetings.

So where does one start to keep their BGP routing policy in check and be a good internet citizen? There are two interrelated technologies we will cover here: Internet Routing Registries (IRRs) and Routing Policy Specification Language (RPSL), some important checks and balances that help make for sane internet routing policy. Let's break down what they are and why they're important.

IRRs are the hall monitors of the internet, keeping track of who's allowed to advertise which IP prefixes (aka routes) to which peers. These public resources are where network operators voluntarily register their routing policies and is sort of like a global honor system for internet routing. The catch? For IRRs to really work well, everyone needs to participate.

For those that have some experience with this, you might you have your prefixes and ASN objects in an IRR which you manage or maybe your service provider added them to their IRR for you. All done, right? Not so fast. You likely want to make sure your BGP policies reflect the actual routing policy you want. This is where understanding RPSL and how it applies in an IRR comes in. This structured language lets you codify your routing intentions in a clear, machine-readable format that makes it's way into accurate, secure route filters.

When used together, IRRs and well crafted RPSL form a powerful shield against BGP's more dramatic tendencies. By the objects and policy in IRR data, your routers and the routers of other networks can automatically filter out sketchy announcements. This helps prevent route hijacks, where an AS claims to originate a prefix it doesn't own, and route leaks, where an AS accidentally propagates routes it shouldn't.

But IRRs and RPSL aren't just about defense, they can also grease the wheels of peering negotiations. When you approach a potential BGP peer with your IRR and RPSL ducks in a row, it demonstrates a level of sophistication and ability to properly manage your routing policy. Interconnection specialists love when they see clean routing policy via IRR. Trust is established, awkward back and forth over what you are trying to accomplish is avoided and you can get down to the business of exchanging routes. Folks responsible for interconnection have to be very cautions about who and how they connect to make sure they aren't on the hot seat, having to be involved with their own RFO or outage prevention meetings.

Of course, no system is perfect and IRRs and RPSL have their challenges. The biggest one is keeping your IRR data accurate and up-to-date. Stale RPSL objects are useless at best, harmful at worst. For example, if you used to advertise a prefix for a downstream customer that is long gone or perhaps you gave a borrowed prefix back to a provider but that prefix is not removed from your IRR policy, you might inadvertently end up being transit for the prefix. This means you announce to a provider that you have the prefix downstream, but you don't anymore. Instead, you're just passing the traffic off to another transit or peer. This adds traffic to your network that doesn't belong there, probably adds needless latency and could cause a lot of issues that can be difficult to unwind for those using that particular network. There are also times when opposing policy is declared within multiple IRRs, causing confusion on which one is correct to use. IRR Explorer is a great tool to see what routing policy looks like for a prefix or ASN and detail you things you need to address.

Despite these hurdles, the benefits of IRRs and RPSL are hard to ignore. Industry groups and best practices like MANRS (Mutually Agreed Norms for Routing Security) heavily emphasize their use. It's not just a "nice to have"—it's more like wearing pants to work. You could skip it, but don't be surprised when you get some funny looks if you do.

If you are responsible for BGP peering and interconnection at the edge of your public autonomous system, hopefully you are already aware of much of this and it is review for you. Maybe this is just a handy reminder to double check your policy. If this is new, be sure to set things up with a reputable IRR (APNIC, ARIN, RADB, RIPE, etc) to register objects like ASN and prefixes then think through and define your routing policy. Here's a fantastic "Quick Start" resource from FCIX on what the different objects are and what you need to do to get started. Once all set up, keep your records updated like it's your job (because it kind of is) and sleep better at night knowing you played your part in helping prevent bad things from happening to routing on the internet. It's important that we as network engineering professionals who have influence on internet routing take responsibility to keep things safe and performant. While IRRs and RPSL are crucial foundational steps, there's even more we can do to secure internet routing. Once you get your routing policy in check, RPKI is imperative to explore as well but that's a topic for another article.

If you have more questions about this, I'm here to help! Reach out to me on LinkedIn or ping me if you have my contact into. I've managed routing policy for service providers and enterprises alike for over 25 years. I'm happy to help you craft something that works for you or just act as a second set of eyes on what you already have!