Skip to content

Archive

Routing Security

4 articles
Cybersecurity 23 Sep 2026 5 min read

RPKI Origin Validation Checks BGP Prefix Authority

BGP announces reachability, but a route advertisement by itself does not prove that the originating Autonomous System is authorized to originate the prefix. Resource Public Key Infrastructure, or RPKI, adds signed resource authorization data that can be converted into records a router uses for origin validation. The resulting check is deliberately narrow. It compares the route prefix and origin AS with validated ROA payloads, commonly called VRPs. The result can feed routing policy, but it does not authenticate every AS in AS_PATH and does not turn BGP into a path-validation protocol.

Cybersecurity 23 Sep 2026 5 min read

RPKI ASPA Authorizes Transit Relationships for AS_PATH Checks

A valid route origin says little about the relationships represented by the rest of an AS_PATH. A prefix can originate from an authorized AS and still travel through a sequence that conflicts with expected customer-to-provider structure. Autonomous System Provider Authorization, or ASPA, adds a signed RPKI object for that second problem. As of September 2026, ASPA is still specified in active IETF Internet-Drafts rather than a published RFC. The current ASPA profile draft defines the signed object, while the current verification draft defines procedures for applying validated ASPA data to BGP AS_PATHs. That status matters operationally: fields and procedures remain subject to change until the specifications complete the standards process.

Cybersecurity 23 Sep 2026 5 min read

BGPsec Signs the AS Path Hop by Hop

BGP route origin authorization protects one narrow statement: which AS may originate a prefix. It does not cryptographically protect every AS hop that appears after the origin. BGPsec, standardized in RFC 8205, addresses that separate boundary by carrying signed path information in BGP UPDATE messages. The mechanism changes more than the validation rule. A BGPsec UPDATE uses BGPsec_PATH instead of the conventional AS_PATH, and participating ASes extend a chain of Secure_Path and Signature Segments as the route moves between BGPsec-capable external peers.

Cybersecurity 23 Sep 2026 4 min read

BGP Roles and OTC Constrain Route Leak Propagation

A BGP route can carry a valid origin and still travel beyond the scope intended by the networks that exchanged it. That distinction matters because origin authorization and route-leak control address different properties. RFC 7908 defines a route leak as propagation of routing announcements beyond their intended scope, commonly in conflict with policies tied to customer, provider, or peer relationships. RFC 9234 adds protocol machinery for that relationship context. BGP Roles identify the relationship at an eBGP session, while the Only to Customer attribute, abbreviated OTC, marks routes whose subsequent propagation is constrained. The mechanism targets route propagation policy; it does not turn BGP into a cryptographically authenticated path protocol.