Standards RPKI_ROA_EXPIRED

Route Hijacking Through Expired ROA Windows: The Cost of Forgotten Validations

Published August 29, 2026 Updated August 29, 2026

Route Hijacking Through Expired ROA Windows: The Cost of Forgotten Validations

Introduction

Resource Public Key Infrastructure (RPKI) was designed to solve one of BGP's foundational vulnerabilities: the ability to announce someone else's IP prefix to the internet. By requiring Route Origin Authorizations (ROAs), cryptographic statements that bind a prefix to an authorized Autonomous System Number (ASN), RPKI shifts route hijacking from trivial to cryptographically hard.

But like all security mechanisms, RPKI's effectiveness depends on active maintenance. Organizations that deploy ROAs and then forget about renewal deadlines create a dangerous window: a prefix that was once protected by cryptographic validation can suddenly become fair game for hijackers, all while appearing to operators as if protection was never there. This article explores how expired ROAs become attack surfaces, why they're so often overlooked, and how to prevent them.

The Vulnerability: ROA Expiration and Forgotten Renewals

A ROA is not a permanent object. Like certificates, ROAs have an expiration date (typically one to two years from issuance). This is intentional: RPKI's security model assumes that private keys are rotated regularly and old certificates are not re-issued indefinitely, and that operators will renew ROAs before expiry.

In practice, ROA renewal is a manual or semi-automated process. An operator must:

  1. Log into their RPKI Certificate Authority (CA)
  2. Identify which prefixes need renewal
  3. Issue new ROAs or extend existing ones
  4. Publish the updated ROAs to the repository

When a ROA expires, validators following strict RFC 6811 compliance treat it as no longer valid. To a strict RPKI validator, an expired ROA is equivalent to no ROA at all. The prefix reverts to an "unvalidated" state:

  • Any ASN can announce the prefix without cryptographic proof
  • Validators will mark the route as "not found" in the ROA set
  • The route still propagates through BGP but fails RPKI validation checks

The danger emerges when an attacker becomes aware of the expiration. Many organizations don't monitor their ROA validity dates closely. Some aren't even aware they have ROAs expiring. An attacker who watches for expired ROAs, or times an attack to coincide with a known renewal window, can hijack the prefix with zero cryptographic barriers.

Attack Mechanics: From Expiration to Hijack

Here's the sequence:

Day 1–365: Organization A has a valid ROA for 198.51.100.0/24, authorizing AS 64512 to announce it. The ROA expires in 30 days. No one notices because renewal is delegated to a contractor who left six months ago, and the process was never automated.

Day 365: The ROA expires silently. RPKI repositories still host the expired object, but strict validators discard it as stale.

Day 366: Attacker B, monitoring RPKI feeds or running BGP hijacking tools, detects that 198.51.100.0/24 no longer has a valid ROA. Attacker B checks the prefix's BGP history and sees it's valuable (associated with a mail provider or DNS resolver).

Day 367: Attacker B announces 198.51.100.0/24 from AS 64513, a peer AS that has connectivity to upstream providers. They use a legitimate BGP session or compromise a BGP-enabled device in an adjacent network.

Day 368: Traffic for 198.51.100.0/24 begins routing to Attacker B's infrastructure. Depending on route propagation and ISP filtering policies, this could capture:

  • Email traffic (if the prefix hosts mail servers)
  • DNS queries (if it hosts authoritative nameservers)
  • Web traffic (if it hosts web services)
  • VPN endpoints (if it hosts corporate access points)

The attack succeeds because:

  1. No ROA exists to cryptographically prove that AS 64512 (the legitimate owner) should announce the prefix
  2. No strict RPKI filtering blocks the announcement from AS 64513 (the attacker)
  3. No monitoring detected the ROA's expiration 30 days earlier

The entire hijack is made possible by a procedural failure (forgotten renewal), not a cryptographic weakness.

Real-World Cost and Impact

The consequences of a successful expired-ROA hijack are severe:

  • Interception of business-critical traffic: A hijacked mail prefix can capture business email for hours or days, enabling credential theft, fraud, and espionage.
  • DNS poisoning amplification: If the prefix hosts authoritative nameservers, an attacker can corrupt DNS records, redirect users to phishing sites, and trigger widespread downstream compromises.
  • Compliance violations: Many regulatory frameworks (HIPAA, PCI-DSS, SOX) require demonstrable control over network infrastructure. A hijack due to expired RPKI is classified as a material security failure.
  • Reputational damage: The public nature of BGP hijacks means the incident is immediately visible to threat researchers, competitors, and customers.
  • Recovery friction: Restoring legitimate ownership of the prefix can take hours or days, depending on how widely the hijack propagated and how aggressively ISPs applied RPKI filtering.

An SSL certificate that expires on a production web server doesn't lose cryptographic protection (it still works briefly), but it exposes the server to MITM attacks and validation failures. An expired ROA is similar but affects infrastructure-layer routing instead of application-layer encryption.

Detection and Monitoring: Catching Expiration Before Hijack

Preventing expired-ROA hijacks requires proactive monitoring of ROA validity dates and RPKI repository state.

Essential Monitoring Strategies

1. ROA Inventory and Expiration Tracking

Maintain a continuous audit of all ROAs your organization has issued. Export the list from your RPKI CA with issue and expiration dates:

Prefix              | ASN    | Issued   | Expires    | Days Until Expiry
198.51.100.0/24     | 64512  | 2025-08  | 2026-08    | 365
203.0.113.0/25      | 64512  | 2025-06  | 2026-06    | 335
192.0.2.0/24        | 64512  | 2024-12  | 2025-12    | 485

2. Automated Alerts

Set alerts for ROAs expiring within 30, 14, and 7 days. Many RPKI CAs (Krill, RIPE NCC RPKI services) provide email notifications, but automation via API polling is more reliable:

# Pseudocode for daily ROA expiration check
for each ROA in inventory:
  days_until_expiry = (roa.expiration_date - today).days
  if days_until_expiry <= 30:
    alert("ROA expiring soon", roa, days_until_expiry)
  if days_until_expiry <= 0:
    critical_alert("ROA expired", roa)

3. RPKI Repository Monitoring

Query the RPKI repository directly to verify that your ROAs are present and valid:

# Fetch and verify ROA objects from the RPKI repository
rpki-client -t all -v
# Pipe to JSON output and check for expired objects

4. BGP Hijack Detection

Deploy network monitoring that watches for unexpected origin ASNs announcing your prefixes. Tools like ExaBGP, RIPE NCC Stat, and BGPStream can alert you if an unknown ASN starts announcing your space.

Mitigation and Implementation

Short-Term: Immediate Actions

1. Audit Existing ROAs

Generate a report of all active ROAs and their expiration dates immediately. Contact your RPKI CA provider for a detailed export.

2. Set Up Renewal Calendar

Create a shared calendar reminder (via your RPKI CA, or manually) for ROA renewals 60 days before expiry. Assign clear ownership.

3. Enable RPKI Strict Validation

On your own routers and security appliances, enable RPKI validity checking for incoming routes:

! Cisco IOS Example
bgp rpki server <rpki-server> port 8282
bgp rpki refresh 3600
!
route-policy rpki-filter
  if validation-state is valid then
    pass
  else
    drop
  endif
end-policy

neighbor <peer-ip> route-policy rpki-filter in

Medium-Term: Automation and Process

1. Automate ROA Renewal

If your RPKI CA supports API-based ROA management (such as Krill), automate renewal 60 days before expiry:

# Pseudocode: Automated ROA renewal
import rpki_ca_api

for roa in roa_inventory:
  if (roa.expiration_date - today).days == 60:
    rpki_ca_api.renew_roa(roa.prefix, roa.asn)
    log(f"Renewed ROA for {roa.prefix}")

2. Centralized Monitoring Dashboard

Aggregate ROA expiration data into a single operational dashboard. Include:

  • ROA validity status (valid, expired, approaching expiry)
  • Origin ASN and prefix
  • Days until renewal required
  • Last renewal date

3. Incident Response Runbook

Document steps to take if a ROA is detected as expired or if a hijack is suspected:

  1. Contact RPKI CA provider immediately
  2. Issue a new ROA with extended validity
  3. Alert all BGP peers and upstream ISPs
  4. Monitor BGP feeds for rogue announcements
  5. Document incident timeline for compliance audits

Long-Term: Architecture

1. Multi-Tier ROA Strategy

Issue ROAs with staggered expiration dates. If one ROA expires, a secondary ROA still provides protection:

Primary ROA:   198.51.100.0/24 → AS 64512 (expires 2026-08-29)
Secondary ROA: 198.51.100.0/24 → AS 64513 (expires 2027-02-28)
Tertiary ROA:  198.51.100.0/24 → AS 64514 (expires 2027-08-29)

2. Continuous RPKI Validation

Integrate CompliSight's RPKI validation module into your continuous compliance pipeline. Generate weekly or daily validation reports showing:

  • Percentage of prefixes with valid ROAs
  • ROAs expiring within 30 days
  • Any detected rogue announcements

Key Takeaways

  1. ROA expiration is a silent vulnerability. An expired ROA provides zero protection but may appear to operators as "not needed" rather than "vulnerable."

  2. Monitoring and renewal are operational, not cryptographic. RPKI's strongest link is automation; its weakest is human workflow. Automate renewal where possible.

  3. An expired ROA is an open door. Attackers actively scan for expired ROAs. If you issue a ROA, commit to renewing it or explicitly revoking it. Never let it expire silently.

  4. Detection is fast but recovery is slow. A hijack can propagate globally in minutes; reclaiming a prefix can take hours. Monitoring is your best defense.

  5. CompliSight's RPKI module must include expiration tracking. Any organization using RPKI should integrate continuous validation checks that flag expiring ROAs and unrenewed routes. This is not optional. It's the difference between a working security mechanism and a false sense of protection.