A
BGP route hijack occurs when an
Autonomous System (AS) maliciously or accidentally announces IP address prefixes it is not authorized to control, and
RPKI prevents it by cryptographically validating the authenticity of these route announcements.
The core problem is that BGP, the internet's routing protocol, inherently trusts that an AS announcing a
prefix is authorized to do so. RPKI (Resource
Public Key Infrastructure) adds a layer of verification. It works by allowing IP address holders (e.g., your company) to create cryptographically signed Route Origin Authorizations (ROAs). A ROA is a statement that specifies which AS is permitted to originate BGP routes for a specific prefix. Network operators then configure their routers to perform Route Origin Validation (ROV) by checking incoming BGP announcements against a global database of these ROAs. If an announcement contradicts a valid ROA (e.g., a hijacker's AS announces your prefix), the router can reject it.
Implementation involves two steps. First, the prefix holder creates a ROA in their
registry" class="link-accent" data-mention="glossary">Regional Internet Registry's (RIR) portal, signing the association between their
ASN and IP prefix. Second, network operators configure their routers to fetch the RPKI data and validate routes. For example, on Juniper, you would enable validation:
routing-options {
validation {
group rpki-validators {
session 192.0.2.10 {
refresh-time 30;
hold-time 30;
}
}
}
}
protocols bgp {
group external-peers {
import VALIDATION_POLICY;
}
}
The underlying concept is shifting BGP from a trust-based model to a verification-based model, where the cryptographic proof of authorization contained in a ROA is the ultimate source of truth for route legitimacy.
