CONCEPT Cited by 1 source
Path validation (BGP)¶
Path validation is the class of mechanisms that validate not just the origin of a BGP route (what ROV does) but the entire AS path against the relationships it implicitly claims.
Origin validation answers "is the originator authorized to originate this prefix?" Path validation answers "is every transition in this AS path consistent with the declared customer-provider / peer-peer relationships?"
Why it's needed¶
Route leaks are path anomalies with a
correct origin: AS21980 is the rightful originator of its
prefixes, but the path 52320, 8048, 6762, ..., 21980
describes an invalid relationship (AS8048 should not be
transiting between its providers). ROV cannot detect this.
Absent path validation, an AS receiving a route has no protocol-level way to know whether the path describes an allowed sequence of relationships.
The two standards in flight¶
- ASPA (Autonomous System Provider Authorization) — an IETF SIDROPS draft. Each AS publishes an RPKI-signed ASPA object listing its authorized upstream providers. Verifiers reject paths whose transitions contradict the declared upstream set. Tier-1 networks use the special AS0 member to declare "I have no upstream providers."
- RFC 9234 BGP Roles / OTC — negotiates roles (Provider / Customer / Peer / Route-Server / Route-Server-Client) at BGP session setup and attaches an Only-To-Customer attribute to routes on non-customer sessions. Simpler than ASPA but requires vendor implementation in the BGP stack, not just a side-channel validator.
The two are complementary: ASPA is RPKI-backed and can be validated globally from signed data; OTC is session-local and protects incrementally as peer pairs upgrade.
Seen in¶
- sources/2026-01-08-cloudflare-a-closer-look-at-a-bgp-anomaly-in-venezuela — the post's conclusion: the missing discipline is path validation, not origin validation.