RPKI: Securing BGP with Route Origin Validation

The BGP Hijacking Problem

BGP was designed in an era of implicit trust. Any AS can announce any prefix, and neighboring routers accept it by default. This has led to:

• Pakistan Telecom hijacking YouTube (2008) — AS 17557 announced YouTube's prefix, taking it offline globally.
• Amazon Route 53 hijack (2018) — Attackers rerouted cryptocurrency traffic through a BGP hijack.
• Thousands of smaller incidents — Route hijacks happen daily, most going unnoticed.

What Is RPKI?

RPKI (Resource Public Key Infrastructure) is a framework that lets resource holders (RIRs, ISPs) cryptographically attest to the relationship between IP prefixes and the ASes authorized to originate them.

The key building block is the ROA (Route Origin Authorization):

Normal:    203.0.113.0/24 originated by AS 64512 (legitimate owner)
Hijacked:  203.0.113.0/24 originated by AS 99999 (attacker)

Result: Some or all internet traffic for 203.0.113.0/24
        is routed to AS 99999 instead of AS 64512.

How ROV Works

Route Origin Validation (ROV) is the process of checking received BGP routes against published ROAs:

ROA: {
  Prefix: 203.0.113.0/24
  MaxLength: /24
  Origin AS: 64512
}

Creating ROAs

ROAs are created through your Regional Internet Registry (RIR):

• ARIN — rpki-dashboard.arin.net
• RIPE NCC — my.ripe.net → "Create ROA"
• APNIC — myapnic.net → RPKI
• LACNIC — milacnic.lacnic.net
• AFRINIC — my.afrinic.net

Running a Validator

To validate routes, your router needs access to an RPKI validator:

# RPSL route object
route:   203.0.113.0/24
origin:  AS64512
mnt-by:  MAINT-AS64512

Configuring Your Router

wzxhzdk:3

Current Adoption

As of 2026, RPKI adoption has crossed critical mass:

• 70%+ of IPv4 space is covered by ROAs.
• Major networks (Cloudflare, Google, AWS, NTT) reject RPKI-invalid routes.
• If you have not created ROAs for your prefixes, you are at risk of having your routes rejected.