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.
BGPsec_PATH carries path state and signatures
BGPsec_PATH is an optional non-transitive path attribute. Its Secure_Path portion contains one segment for each AS represented in the secured path. A normal segment contains an AS number, a pCount, and flags. pCount permits repeated AS-path semantics without requiring a separate signature for every repeated copy of an ASN.
The attribute also carries one or two Signature Blocks. A Signature Block contains a Signature Segment corresponding to each Secure_Path Segment. The Subject Key Identifier in a Signature Segment selects the router certificate public key used during verification.
A simplified shape is:
BGPsec_PATH
├── Secure_Path
│ ├── AS 64500
│ ├── AS 64510
│ └── AS 64520
└── Signature_Block
├── signature for AS 64500
├── signature for AS 64510
└── signature for AS 64520The representation is ordered. The relationship between path segments and signature segments is part of the validation procedure, not merely presentation metadata.
Each external propagation adds a signed statement
When a BGPsec speaker propagates a secured route to another external BGPsec peer, it prepends its Secure_Path Segment and a corresponding Signature Segment. The signed input includes path material already accumulated, the address-family and prefix information, and the target AS number of the peer receiving the UPDATE.
Binding the target AS is significant. The same outgoing signed UPDATE is not simply copied to peers in different ASes. RFC 8205 requires a separate BGPsec UPDATE for each unique peer AS because that peer AS number participates in the signed data.
The prefix is also part of the protected input. A signature therefore cannot be treated as a detachable endorsement of an ASN sequence that can be moved freely to another prefix.
BGPsec UPDATEs advertise a single prefix and encode it through MP_REACH_NLRI. This constraint follows from the signature construction: a downstream speaker must be able to extend the secured advertisement without inheriting signatures over an inseparable bundle of unrelated prefixes.
Router certificates connect signatures to AS numbers
BGPsec signatures rely on RPKI router certificates rather than Route Origin Authorizations. The AS number in a Secure_Path Segment must correspond to the AS number represented by the router certificate used for that signature.
During validation, a receiver uses the AS number and Subject Key Identifier to locate an applicable public key from valid RPKI router-certificate data. It then reconstructs the data covered by the signature and verifies the signature with the algorithm suite identified by the Signature Block.
This makes router-key lifecycle part of path validation. If relevant RPKI router-certificate data changes, RFC 8205 requires affected stored BGPsec UPDATEs to be reassessed. A certificate expiration or revocation can therefore change the validation state of routes already present in the Adj-RIB-In.
Validation is performed across the signature chain
Before cryptographic checks, a receiver performs structural checks on the BGPsec_PATH. Among them, the most recently added Secure_Path ASN must match the external peer ASN at ingress, Signature Blocks must contain the expected number of Signature Segments, and the UPDATE must not also carry an AS_PATH attribute.
For a supported algorithm suite, validation then walks the Signature Segments and verifies each signature with the corresponding router public key. A failure can make that Signature Block not valid. If an UPDATE contains multiple Signature Blocks during an algorithm transition, their validation states are considered according to the protocol procedure.
The result does not mean every routing decision along the path was desirable. A valid BGPsec signature chain establishes properties of the secured advertisement and its propagation chain. It does not prove business relationships, routing-policy intent, physical packet forwarding, or the absence of all route leaks.
BGPsec and ASPA protect different routing statements
BGPsec and ASPA both use RPKI infrastructure, but their signed assertions differ substantially.
ASPA lets a Customer AS publish a signed set of authorized Provider ASes. A verifier can compare an ordinary AS path against those relationship attestations. BGPsec instead has participating routers create signatures as the UPDATE propagates, producing cryptographic protection tied directly to the secured path and destination peer AS.
That distinction affects deployment. ASPA validation can derive information from published provider attestations even when a particular UPDATE was not signed hop by hop. BGPsec path protection depends on BGPsec-capable propagation and the associated router keys and signatures.
Route Origin Validation is separate again. A ROA states which AS may originate a prefix. BGPsec uses origin-validation information as part of its processing model, but path signatures do not turn router certificates into prefix-origin authorizations.
Compatibility creates a boundary in the secured path
BGPsec is negotiated as a BGP capability. A BGPsec speaker may need to advertise a route to a peer that does not support BGPsec. In that case, the secured representation cannot simply be consumed as though the peer supported BGPsec_PATH; RFC 8205 defines procedures for reconstructing ordinary AS-path information when crossing that capability boundary.
This matters for security interpretation. Cryptographic protection is strongest where the advertisement remains inside the BGPsec processing model. Once a route is propagated as a traditional unsigned BGP UPDATE, downstream systems do not receive the same signature chain as evidence for that segment of propagation.
BGPsec therefore does not convert the global routing system into a universally signed graph merely because one AS supports it. Its assurance follows the actual secured UPDATE, the valid router-key material, the verified signatures, and the local policy that decides how validation results affect route selection.