RPKI vs BGP security
BGP exchanges routes; RPKI supplies evidence for checking their origins. Understand what that check protects, what it leaves open, and who controls the evidence.
A network says it can reach a block of Internet addresses. Should other networks believe it? That question sits behind the comparison between BGP and RPKI. They do different jobs: one exchanges routes, while the other supplies evidence that can help assess a route's claimed origin.
The route and the evidence beside it
BGP is how independently operated networks exchange reachability information. A block of addresses is called an IP prefix; a network participating in this exchange is identified by an autonomous system number, or ASN. Operators use announcements and their own policies to select routes. RFC 4271 defines that exchange.
A received announcement does not, by itself, prove that its stated origin was authorized by the address holder. An incorrect origin can come from a configuration mistake or an attempted hijack. The practical cost can be a service that people suddenly cannot reach, even though its servers are running.
RPKI adds a certificate and signed-record system. A route origin authorization, or ROA, identifies an ASN permitted to originate routes for specified prefixes. Validation software checks the signed material and makes usable authorization data available to routers. Route origin validation, or ROV, compares announcements with that data.
A check with a specific scope
The comparison asks whether the origin ASN and announced prefix length match a covering authorization. It does not inspect the content of the traffic or authenticate every network in the advertised path. A route can pass the origin check and still be propagated where it should not go.
RFC 6811 defines three results. Valid means a matching authorization exists. Invalid means covering data exists but none permits that origin and prefix length. NotFound means there is no covering authorization in the data being used. These are evidence states, not a complete verdict that a route is safe or malicious.
What happens next depends on the receiving operator's configured policy. A network can reject Invalid announcements; publishing a ROA alone does not force every other network to perform that check. BGP remains the route exchange mechanism.
Why the distinction matters during an outage
Imagine moving a service to a new originating ASN while an authorization still names only the old one. The new announcement may become Invalid. The fix begins by comparing the intended announcement, the authorization data actually in use and the policy that rejected it. Buying a different router or assuming that the cable is broken misses the cause.
Operators still need appropriate filters, reliable validation software, monitoring and coordinated changes. Origin validation is one useful check in that work; treating it as an all-purpose security seal hides the remaining dependencies.
Who controls the evidence?
Lu Heng's Note 28 draws a boundary between maintaining records and using them to punish participants. A recordkeeper can influence working networks when others rely on its records. That influence does not itself confer a mandate to govern everyone affected across countries.
His Note 64 proposes shared rules limited to what uniqueness, interoperability and security require, with local verification and voluntary adoption of later changes. The ambition is to make trustworthy coordination replaceable, rather than make one administrator permanently indispensable.
For an operator, the immediate question is practical: can your team trace a route from its authorization to the decision made by a receiving network? Start there, then read how to prepare and maintain an origin authorization. It is easier to establish those relationships while the service still works.