Securing BGP with RPKI Using Routinator, FORT and Cisco IOS-XR – Part 1/3

This blog is part of the VTPP (VNET Threat Perception Platform) project, a three-year programme co-funded by the European Commission under the DIGITAL-ECCC-2022-CYBER-03 call. The project covers DDoS mitigation with FastNetMon, vulnerability scanning with OpenVAS, custom AI/ML detection plugins for Zeek, HSM-backed key management, RPKI validation and a Krill CA, and a full-scale deployment of Security Onion as the IDS/SIEM/NSM backbone.

Part 1: The Architecture of Route Origin Validation (ROV)

Historically, the Border Gateway Protocol (BGP) was built on absolute trust. When an autonomous system (AS) advertised a route, the rest of the Internet inherently trusted that the AS had the authority to do so. This design flaw has led to massive, sometimes global, internet outages and security breaches known as BGP Hijacking -whether caused by malicious actors rerouting traffic or „fat-finger“ typos from network engineers.

Route Origin Validation (ROV) using RPKI (Resource Public Key Infrastructure) changes this paradigm by introducing cryptographic proof to BGP announcements.

Before building our architecture, we must understand the data pipeline:

1. Trust Anchor Locators (TALs): The root of trust. These are the public keys of the five Regional Internet Registries (RIRs: ARIN, RIPE, APNIC, LACNIC, AFRINIC).
2. Route Origin Authorization (ROA): A cryptographically signed object stored in the RIR databases. A ROA explicitly states: „AS 65000 is authorized to originate 192.0.2.0/24, up to a maximum prefix length of /24.“
3. Validated ROA Payload (VRP): Routers do not perform cryptography—they are built to forward packets. Therefore, a Relying Party (RP) server downloads the ROAs, verifies the cryptographic signatures, and extracts a simplified „clean“ list called VRPs (Prefix, Max Length, Origin ASN).
4. RPKI-to-Router (RTR) Protocol: The lightweight protocol used to transport the VRPs from the RP servers directly to the edge routers‘ memory.

The Resilient Topology

Cryptographic validation introduces a new critical dependency. If your routers lose connection to the validation servers, they may fall back to trusting all routes, effectively disabling your security. To prevent this, we are building a multi-vendor, multi-OS Relying Party architecture.

• Diversity in OS: We use Rocky Linux (RHEL-derivative) and Alma Linux.
• Diversity in Software: We use Routinator (written in Rust) and FORT (written in C). If a malformed ROA causes a parsing bug or crash in one software stack, the other will likely remain unaffected, ensuring continuous VRP delivery to our routers.

Technical Concept: The RPKI Chain of Trust

RPKI uses X.509 certificates with extensions for IP addresses and AS numbers (RFC 3779). The hierarchy follows the administrative allocation of IP space:

• IANA → RIRs (ARIN, RIPE, etc.) → LIRs (ISPs/Orgs).
• The final product is a ROA (Route Origin Authorization), a signed object containing an (ASN, Prefix, Max-Length) tuple.

The Protocol Deep Dive: RRDP vs. Rsync

In our setup, the Relying Parties (Routinator and FORT) must synchronize with the global repositories.

• Rsync: The legacy method. It is inefficient for global scaling as it requires a full directory crawl and high server-side overhead.
• RRDP (RFC 8182): The modern standard used by our validators. It uses HTTPS and XML „Delta“ files. By downloading only the changes (deltas) since the last serial number rather than the whole database, we reduce synchronization time from minutes to seconds and lower the risk of „connection reset“ errors common in Rsync.

Why Multi-OS and Multi-Vendor?

We are deploying Routinator (Rust) on Rocky Linux and FORT (C) on Alma Linux.

• Memory Safety: Routinator’s Rust codebase prevents common vulnerabilities like buffer overflows.
• Resource Efficiency: FORT’s C implementation is extremely „tight,“ making it ideal for high-performance validation with minimal RAM overhead.

Operational Resilience: If a specific RIR publishes a malformed ROA that triggers a logic bug in Routinator, your FORT instances (running different code logic) act as a circuit breaker, ensuring your routers still receive a valid VRP stream.

Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre. Neither the European Union nor the granting authority can be held responsible for them.