Strengthening the Backbone: How ByzRP Secures Global Internet Routing

Introduction

The Border Gateway Protocol (BGP) is often described as the 'glue' that holds the internet together. Developed in an era when trust was high and the number of network participants was low, BGP was built for speed and scalability, not security. Decades later, this lack of security has made BGP hijacking a common and costly occurrence. While the Resource Public Key Infrastructure (RPKI) was introduced to mitigate these risks, it has proven to be a double-edged sword: a security protocol that is itself vulnerable to exploitation.

In a groundbreaking presentation at Black Hat, researchers from TU Darmstadt and ATHENE introduced ByzRP (Byzantine RPKI). This solution addresses the fragility of the current RPKI ecosystem by introducing a Byzantine fault-tolerant operational shield. In this post, we will explore why RPKI is failing and how ByzRP provides the robust, distributed architecture needed to secure the global routing table.

The Fragility of Current RPKI Deployments

RPKI works by allowing network owners to sign Route Origin Authorizations (ROAs), which link their IP prefixes to their Autonomous System Number (ASN). Relaying Parties (RPs)—specialized validator software—download these records from global Publication Points (PPs) to provide routers with a 'ground truth' for BGP announcements.

However, research has revealed that this infrastructure is remarkably fragile. Many RPs lack security monitoring and are susceptible to:

1. Stalling Attacks: Malicious repositories can slow down the RP's download process, causing validated data to expire and fall out of the cache, effectively 'downgrading' the router's security.
2. DoS Crashes: Protocol loopholes and processing errors in RP software allow malicious Publication Points to crash validators.
3. Network Instability: The output of RPs is often inconsistent due to transient network failures or repository 'flapping,' where data changes too rapidly for a single validator to maintain a stable view.

Technical Deep Dive into ByzRP

ByzRP transforms the RPKI validator from a single point of failure into a resilient, distributed service. It achieves this through two innovative mechanisms: the Watchdog and the Consensus Network.

The Watchdog Mechanism

The Watchdog is a separate monitoring process that wraps around the Relaying Party software. Its job is to perform the security monitoring that standard RPs neglect.

• Health Monitoring: It tracks whether the RP is processing data or has hung.
• Adaptive Skip-Listing: When a crash or stall occurs, the Watchdog correlates the failure to the specific connection with a Publication Point.
• Automated Recovery: It adds the offending PP to a 'skip list' and immediately reboots the RP.

This ensures that a malicious actor can only disrupt the system for seconds before being blacklisted, rather than hours or days.

Byzantine Fault-Tolerant Consensus

The real power of ByzRP lies in its distributed nature. Instead of relying on a single node, ByzRP uses a network of nodes that communicate via mutual TLS (mTLS). These nodes independently validate RPKI data and then participate in a consensus algorithm.

• Majority Voting: ByzRP uses a 'K-out-of-N' voting system. For a piece of routing data (a VRP) to be considered valid, it must be seen and verified by a majority of the nodes in the network.
• Intersection Sets: By intersecting the outputs of multiple nodes, the system filters out 'noise' from transient network failures and prevents a compromised node from injecting false data into the global output.

Step-by-Step Implementation of ByzRP Logic

While full deployment involves complex networking, the core logic follows these steps:

1. Parallel Validation: N nodes independently fetch data from all global RPKI Publication Points in randomized orders to prevent synchronized attacks.
2. Local Watchdog Filtering: Each node's internal Watchdog filters out crashed or stalled PPs locally.
3. Asynchronous Polling: Nodes poll their peers via authenticated mTLS web servers to retrieve their validated datasets.
4. Consensus Calculation: Each node independently calculates the final output based on the agreed-upon threshold (e.g., a 2/3 majority).
5. Router Feeding: The final, stable, and unified output is fed to the border routers.

Mitigation & Defense

For network administrators, the takeaways are clear. Relying on a single, unmonitored RPKI validator is no longer sufficient for high-stakes environments.

• Diversification: If not using ByzRP, operators should at least run multiple different RP implementations (e.g., Routinator, Fort, and rpki-client) to avoid implementation-specific bugs.
• Monitoring: Implement external watchdogs or health checks that can detect when a validator's output drops significantly or when it stops updating its cache.
• Adoption of Services: The researchers suggest that RPKI-as-a-Service, powered by ByzRP, could reduce global traffic by 99%, making it easier for smaller ISPs to adopt RPKI without the overhead of managing complex, vulnerable infrastructure.

Conclusion & Key Takeaways

ByzRP represents a significant leap forward in internet routing security. By moving from a centralized, fragile model to a distributed, Byzantine fault-tolerant one, it provides the 'operational shield' necessary for RPKI to truly fulfill its promise.

Key Takeaways:

• RPKI is not 'secure by design': Its infrastructure can be used to launch DoS attacks against validators.
• Consensus is Critical: Distributed validation prevents transient network issues from causing routing instabilities.
• Efficiency Matters: A centralized service model for RPKI validation can reduce internet traffic and allow for 10x faster security updates.

For those interested in the implementation, the ByzRP source code is available on GitHub, and the full research paper can be found in the proceedings of CCS 2024.