BGP RPKI Route Origin Authorization (ROA) & Hijack Defense Studio

The Border Gateway Protocol (BGP) was designed in 1989 on implicit trust: any Autonomous System (AS) can announce any IP address prefix to the global routing table without cryptographic proof of ownership. In a BGP hijack, an attacker (or misconfigured ISP) announces an IP prefix belonging to another organization. Because BGP routing algorithms prioritize the "longest-prefix match" (e.g. a /24 announcement wins over a legitimate /20 announcement) or shorter AS_PATH lengths, global Internet routers will divert traffic to the illegitimate destination, enabling traffic interception, eavesdropping, and total denial of service.

RPKI creates a hierarchical Public Key Infrastructure rooted in the five Regional Internet Registries (RIRs: ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC). Certified IP address holders sign Route Origin Authorizations (ROAs)—cryptographic objects specifying the authorized Origin Autonomous System Number (ASN) and the maximum allowed prefix length (MaxLength). Border routers run Route Origin Validation (ROV): when receiving an incoming BGP route announcement, the router queries an RPKI cache over the RTR protocol (RFC 8210) and marks the route as Valid, Invalid, or NotFound. If the route is marked Invalid, modern network policy automatically drops the announcement.

When an organization creates a ROA for a /20 prefix, setting MaxLength to /24 gives operational agility (allowing the network to announce sixteen /24 subnets for traffic engineering without updating the ROA). However, this creates a major vulnerability: an attacker can announce a forged-origin /24 using the legitimate ASN in the AS_PATH. Because the announcement matches the ROA ASN and does not exceed MaxLength, ROV evaluates it as Valid! Security best practice (RFC 9319) recommends matching the prefix length exactly (e.g. /20 without a loose MaxLength) and generating separate ROAs for specific subnets.

Border routers lack the computational CPU and memory required to download and cryptographically verify gigabytes of X.509 RPKI certificates, manifests, and CRLs across the global Internet. Instead, dedicated RPKI validating daemons (such as Routinator, StayRTR, or OctoRPKI) perform the cryptographic verification out-of-band and distill the cryptographic state into a simple table of (ASN, Prefix, MaxLength) tuples. The validator then synchronizes this clean table with border routers over a lightweight binary TCP session called the RPKI-to-Router (RTR) protocol.