Securing BGP with RPKI Using Routinator, FORT and Cisco IOS-XR – Part 3/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 3: Cisco IOS-XR Configuration and Route Policies

With the cryptographic heavy lifting handled by our Linux VMs, our edge routers can focus on routing. The routers will pull the VRP table via RTR (Secured by SSH Tunneling over TCP port 22) and hold it in memory, comparing every incoming BGP UPDATE message against this table.

1. Understanding Validation States

When a router receives a BGP prefix, it compares the prefix, subnet mask, and origin ASN against its VRP table. IOS-XR assigns one of three states:

• Valid: The prefix matches a known ROA, the origin AS matches, and the prefix length is less than or equal to the ROA’s max-length attribute.
• Invalid: A ROA exists for this prefix, BUT either the origin ASN is wrong (a hijack), or the prefix length exceeds the max-length (e.g., the ROA allows up to /24, but the router receives a /25. This is often a traffic-engineering misconfiguration).
• Not-Found: No ROA exists for this prefix in the global database.

2. Connecting to the RTR Servers

We configure IOS-XR to maintain persistent TCP sessions with our four RP servers. If a connection drops, IOS-XR simply relies on the others.

router bgp 65000
 ! Connect to the Routinator/Alma/Rocky Linux instances
 rpki server 10.0.0.11
  password encrypted <redacted>
  username vnetrpki
  transport tcp port 22
 !
 rpki server 10.0.0.12
  password encrypted <redacted>
  username vnetrpki
  transport tcp port 22
 !
 ! Connect to the FORT/Alma/Rocky Linux instances
 rpki server 10.0.0.21
  password encrypted <redacted>
  username vnetrpki
  transport tcp port 22
 !
 rpki server 10.0.0.22
  password encrypted <redacted>
  username vnetrpki
  transport tcp port 22
 !

3. Creating the Route Policy (RPL)

Fetching VRPs does not inherently change routing; we must enforce it via policy.

CRITICAL RULE: We must allow not-found routes. Currently, around 40-50% of the internet has not yet published ROAs. If you drop not-found, you will disconnect your network from half of the global internet. We only drop explicit invalid routes.

We also use BGP Local Preference (local-preference) to mathematically prefer cryptographically valid routes over not-found routes.

route-policy RPKI-VALIDATION-IN
  ! Drop malicious or misconfigured routes
  if validation-database invalid then
    drop
  ! Prefer valid routes with a higher local preference
  elseif validation-database valid then
    set local-preference 150
    pass
  ! Allow standard routes to pass normally
  elseif validation-database not-found then
    set local-preference 100
    pass
  else
    pass
  endif
end-policy

4. Applying and Verifying

Apply the policy to your transit providers and peerings, for example:

router bgp 65000
 neighbor 192.0.2.1
  remote-as 65200
  description TRANSIT-PROVIDER-A
  address-family ipv4 unicast
   route-policy RPKI-VALIDATION-IN in
   route-policy DEFAULT-OUT out
  !

Finally, to verify the technical mechanics are working inside the IOS-XR environment, use the following operational commands:

! Verify TCP sessions to Routinator and FORT. Look for 'ESTAB' state.
show bgp rpki server summary

! See the total count of VRPs loaded into router memory (typically > 600,000 today)
show bgp rpki summary

! Deep dive into a specific prefix to see its ROA evaluation
! Look for the line indicating: "RPKI state is valid"
show bgp ipv4 unicast 8.8.8.0/24

By separating the cryptographic validation from the routing plane, and utilizing diverse software and operating systems, we’ve built an enterprise-grade RPKI deployment capable of protecting a tier-2 core network from modern BGP vulnerabilities.

Cisco IOS-XR (running on ASR 9000 and NCS 5500) handles RPKI via a dedicated process. It doesn’t just „learn“ routes; it „scores“ them.

Technical Concept: The Validation State Machine

When a BGP update arrives, the IOS-XR BGP process queries the RPKI cache. The result is one of three states:

1. Valid ($V$): At least one VRP matches the prefix, origin ASN, and the prefix length is within the max-length boundary.
2. Invalid ($I$): A VRP exists for the prefix, but either the ASN is wrong or the prefix is too specific (e.g., received a /25 when the ROA says max-length /24).
3. Not-Found ($N$): No ROA exists. The route is „unvalidated“ but not necessarily „bad.“

Summary

By deploying Routinator and FORT across Rocky and Alma Linux, we have eliminated software and OS monocultures. Connecting these to Cisco IOS-XR creates a „defense-in-depth“ routing architecture that protects your customers from the most common and damaging BGP routing threats.

The Border Gateway Protocol (BGP) inherently lacks mechanisms to verify the authenticity of routing announcements, leaving the global internet vulnerable to accidental route leaks and malicious hijacking. Implementing Resource Public Key Infrastructure (RPKI) addresses this by introducing a cryptographically verifiable chain of trust. To prevent the validation infrastructure from becoming a single point of failure, this design employs a multi-vendor, multi-OS, defense-in-depth architecture feeding into Cisco IOS-XR edge routers.

By deploying this architecture, network operators achieve three critical objectives:

• Automated Security: The network automatically discards illegitimate routing announcements without requiring manual intervention or static prefix-list updates.
• High Availability: The IOS-XR control plane maintains simultaneous connections to four distinct validator instances, ensuring the RPKI cache is never orphaned.
• Forwarding Performance: Because the heavy cryptographic calculations (X.509 validation) are offloaded to external Linux VMs, the Cisco routers dedicate all their CPU and ASIC resources to BGP convergence and packet forwarding.

---

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.