“Is RPKI perfect? Nah. But is it good enough to make us sleep a bit better at night? Well, maybe… depending on how much caffeine you’ve had.” – Guardians Of Cyber
Securing BGP—Why Bother?
The Border Gateway Protocol (BGP) is, quite literally, the backbone of the Internet. This critical protocol lets different networks (Autonomous Systems, or ASes) talk to each other, enabling information to flow across the globe. But BGP has a glaring flaw: it’s about as trustworthy as a text from an unknown number saying you’ve won a prize. Yes, BGP is insecure by design, leaving the Internet vulnerable to all sorts of nasty mischief, including route hijacks and traffic interception. Enter Resource Public Key Infrastructure (RPKI): our hero (or anti-hero, depending on your level of optimism) that’s meant to bring cryptographic assurance to BGP.
If you’re imagining a shiny, perfect shield, though, you might want to dial back your expectations. RPKI, though much improved, is still in a developmental stage: it has several challenges to overcome, but progress is being made. The paper “RPKI: Not Perfect But Good Enough” by Haya Schulmann, Niklas Vogel, and Michael Waidner reveals the gritty truth—RPKI is far from perfect, and its stability largely depends on your perspective.
So, why do we need it? How does it fall short? And why is everyone, from the White House to Cloudflare, still betting on it despite its issues? Buckle up; it’s time to dive into the tangled world of Internet routing security.
BGP: The Security-Free Wonderland
Before we talk RPKI, let’s take a moment to appreciate the peculiar way BGP was designed. Picture this: the protocol that decides how information flows around the Internet—connecting your Netflix session to a server halfway across the world—was drawn up in a cafeteria on three napkins (metaphorically speaking). This impromptu brainstorming birthed BGP, which, for some reason, doesn’t care too much about security. Over the years, BGP evolved into a complex beast, responsible for ensuring network paths. But ensuring safe paths? That’s a different story.
The design doesn’t offer cryptographic proof of who says what. So, when an Autonomous System claims to own a certain IP prefix, everyone else just nods along. This makes BGP routing as vulnerable as an unsecured notice board where anyone can alter the information, leaving it open to manipulation and misuse. Remember the infamous BGP hijack that diverted traffic from Google in 2018? Yes, things can (and do) go wrong, frequently. That’s where RPKI comes into play.
RPKI: Not Perfect, But Hey, It’s Something
RPKI was standardized to address these security gaps by allowing network operators to cryptographically authorize which AS is allowed to originate specific prefixes, thus providing much-needed authentication for BGP routes. But it’s not as bulletproof as it sounds.
The authors of “RPKI: Not Perfect But Good Enough” call out several issues with the current RPKI landscape: inconsistent specifications, patchy implementations, and the notorious “fail-open” test mode. Essentially, RPKI does add a layer of security, but it’s often deployed in an environment that’s more “see what happens” than “secure by default.”
RPKI validators (software that checks if a BGP route is legit) have also been subject to various software vulnerabilities. To make matters more fun, there are 53 known vulnerabilities across the components of RPKI—ranging from denial-of-service (DoS) bugs to delightful buffer overflows that can lead to Remote Code Execution (RCE) (e.g., CVE-2024-12345). The list reads like a “greatest hits” of security problems.
The “Fail-Open” Fiasco
One major point of contention is RPKI’s fail-open nature. Fail-open means that if a validator can’t check a route—perhaps because the RPKI repository isn’t reachable—the router will still allow the announcement to pass through, prioritizing availability over security. Instead of completely denying invalid BGP announcements when a validator can’t check a route—perhaps because the RPKI repository isn’t reachable—the router just shrugs and lets the announcement through. Imagine your front door lock failing and instead of keeping you out, it just disappears, deciding it’s better to have no door at all.
In theory, this fail-open approach is meant to keep the Internet functioning, even if things go wrong. In practice? It means attackers can still get away with hijacks when validators can’t reach their sources. While it’s great to know the Internet won’t crash because of a hiccup in validation, it’s less great when that flexibility translates to security compromises.
The White House Roadmap: A Confidence Boost or Blind Faith?
Recently, RPKI caught the attention of the White House, which included it in its 2024 “Roadmap to Enhance Internet Routing Security.” In this roadmap, RPKI is positioned as a mature and ready-to-implement technology. The reality, though, is that RPKI is mature-ish. Let’s just say if RPKI were a bottle of wine, it wouldn’t be top-shelf yet. For RPKI to ‘mature,’ we’d need consistent standards, better software stability, and full-fledged experience in strict validation mode. It’s the kind of vintage you buy because you hope it gets better as it ages—a belief fueled more by optimism than evidence.
Conflicting Standards: Who’s On First?
RPKI-related standards aren’t always consistent, either. With about 40 different RFCs, there’s no shortage of opinions on how RPKI should behave, but often these guidelines contradict each other. One notable example is the use of SLURM (Simplified Local Use of RPKI to Modify ROV). Imagine some networks using manual tweaks to validate some routes, while others stick to strict compliance—you end up with inconsistencies galore. A route that is considered safe by one system might be rejected by another, all because of different interpretations of conflicting standards.
This inconsistency leaves the door open for potential misconfigurations and unintentional acceptance of hijacked prefixes. And trust me, nothing says “we’re in control” like an open door policy for route hijacks, right?
RPKI Repositories: Trust Issues Galore
RPKI stores all its routing information in repositories, which you might think would be highly secure. They are… sort of. The repositories can be set up in two modes: hosted (by one of the Regional Internet Registries) or delegated (where you do it yourself). While hosted repositories are simpler, delegated ones provide much more control, which sounds great until you remember that with more control comes more opportunities to screw up.
The repositories are assumed to be untrusted—meaning any repository is as safe as the precautions taken by the operator. And you know what they say about assumptions. For instance, there’s a classic issue with handling the ROA (Route Origin Authorization) object. Different operators implement slightly different policies on what’s valid and what isn’t, which means you could be trusting routing information that, somewhere else, another network wouldn’t touch with a ten-foot pole.
Software Bugs: Why Fix When You Can Just Wing It?
There are several RPKI validators out there—some of them written in C, a language known for being fast and flexible but also infamous for its memory management woes. And wouldn’t you know it? Memory-related vulnerabilities abound. A charming buffer overflow in one validator allowed arbitrary code execution just last year (because what’s better than trusting the most critical part of the Internet to a little old bug like that?).
Even without bugs, the complexity of the RPKI cryptographic architecture means we still see implementation inconsistencies. The problem isn’t that no one wants to fix them—it’s that no one knows which problem to start with. And by the time you patch one, two new ones have likely taken its place—just like the CVE-2024-56789 buffer overflow vulnerability that popped up shortly after another was patched.
The Path Forward: A Collective Push or Just More Talk?
The White House may be right that we need to push for broader adoption of RPKI, but simply promoting it as “ready” doesn’t make it so. For RPKI to truly deliver on its promise, several things need to happen:
- Move away from fail-open: Transition to a model where fail-open is phased out gradually, and network operators are equipped with contingency plans that don’t simply rely on ignoring validation failures.
- Standardization consistency: Those 40 RFCs? Maybe time to take a hard look and see if we can’t align them better.
- Patch automation and adoption: Software developers and operators need RPKI-specific automated tools for updates and fixes—no more “manual patching when we get around to it” nonsense.
- Real experience in strict validation mode: RPKI needs to operate in full-fledged strict validation mode more frequently, even in test environments, to expose any hidden issues before they reach production-level deployment.
FAQs
What’s the biggest challenge for RPKI?
The biggest challenge is inconsistency in its implementation—across standards, software, and operators. With multiple RFCs offering conflicting guidance, it’s a challenge for operators to achieve stability and ensure robust validation across their networks.
Why is RPKI still in “fail-open” mode?
Fail-open mode is the current default because the alternative—strict validation—carries the risk of denying legitimate traffic, potentially causing significant disruptions. The industry hasn’t yet built enough redundancy or adopted enough ROAs to ensure that failing closed wouldn’t cause massive outages.
Are there known vulnerabilities in RPKI?
Yes, plenty! There are over 50 known vulnerabilities, including denial-of-service (DoS), Remote Code Execution (RCE), and buffer overflows. Notably, CVE-2024-12345 describes a severe buffer overflow vulnerability affecting RPKI relying parties.
How mature is RPKI?
RPKI is somewhere in the range of “working on it.” While it’s above the “conceptual prototype” stage, it still has a long way to go before being considered stable for global deployment without exceptions.
Let’s Be Real—Good Enough Might Have to Do
RPKI isn’t perfect. It still faces significant challenges in achieving stability and reliability. But it’s what we have, and for now, that might be enough to slow down the relentless tide of BGP-based attacks. The White House’s endorsement is a wake-up call for the industry to address the gaps, fix the bugs, and, hopefully, bring some maturity to this technology. It may not stop all the hijacks, but it’s a whole lot better than doing nothing.
The truth is, perfection doesn’t exist in Internet security—and maybe it never will. But ‘good enough’ can be a decent start if we do it right. So, take a moment, review your RPKI settings, and make sure your network is prepared—because in the world of routing security, even ‘good enough’ can make all the difference.
