Secure BGP with ASPA: Preventing and Fixing Route Leaks

By Anton Elita — Juniper TechPost (posted 2026-07-13)

BGP runs on trust, and route leaks and hijacks are what happen when that trust is misplaced. This article shows how three complementary mechanisms close the gap: BGP Roles with the Only-To-Customer attribute prevent and detect leaks several hops from the source, and — if the leak already happened — RPKI Route Origin Authorization (ROA) helps validate the origin AS, and Autonomous System Provider Authorization (ASPA) confirms the full AS PATH is valley-free.

Introduction

Any BGP speaker can advertise a syntactically valid route for almost any prefix. Commercial relationships between autonomous systems — customer, provider, and peer — are supposed to constrain BGP prefix advertisements. When those relationships are violated, by mistake or by intent, the result is a route leak or hijack, and many related outages have been observed on the Internet. RFC 7908 provides a taxonomy and classification of route leaks based on these relationships.

Where Filtering Stands Today

Since 2012, Junos has supported RPKI route origin validation. The process can be summarized as follows:

• Network operators create cryptographically signed objects within RPKI repositories that prove the origin AS for a prefix.
• Users of RPKI ROA can run RPKI cache validators to download the verified ROA objects via RRDP or rsync.
• Routers use the RPKI-RTR protocol to download the data from cache validators.
• Every prefix can be evaluated in the BGP ingress policy for validity: valid, invalid, or NotFound.
• The policy may specify an action based on the validation result: accept, reject, modify the preference, attach community, and so on.

Preventing Route Leaks: BGP Roles

Roles formalize relationships as negotiated BGP capabilities. Each session side declares its local role:

set protocols bgp group X neighbor Y otc-local-role [ customer | peer | provider ] [ strict ]

The keyword strict should be used when you do not want a BGP session to come up if the remote speaker is not trying to negotiate this capability. BGP Roles with the Only-To-Customer (OTC) attribute prevent and detect leaks several hops from the source.

Fixing Route Leaks: ROA and ASPA

If a leak has already happened, RPKI Route Origin Authorization (ROA) helps validate the origin AS, and Autonomous System Provider Authorization (ASPA) confirms the full AS PATH is valley-free. Example route check on a Tier-1 router:

aelita@tier-1# run show route 130.55.0.0/16 detail next-hop 11.3.4.2
130.55.0.0/16 (2 entries, 1 announced)
        BGP    Preference: 170/-101
               Next hop type: Router, Next hop index: 623
               Source: 11.3.4.2
               Next hop: 11.3.4.2 via ge-0/0/3.0, selected

ASPA: Operational and Monitoring Aspects

The RPKI-RTR protocol version now includes support for RFC 8210bis, which introduced ASPA data retrieval. Operational output of an RPKI cache validator session shows ASPA records being received:

Serial (Full Update): 1176
Serial (Incremental Update): 1182
Session flaps: 2
Session uptime: 01:10:03
IPv4 prefix count: 707324
IPv6 prefix count: 216444
ASPA record count: 2034

Validation state can also be verified programmatically, for example:

juniper:state/routing-instances/routing-instance[name=DEFAULT]/protocols/bgp/rib/afi-safis/afi-safi[name=ipv4-unicast]/ipv4-unicast/loc-rib/routes/route[path-id=0][prefix=193.0.24.0/21][origin=11.3.4.2]/origin-validation-state: rpki-validation-valid

These mechanisms work together: BGP Roles stop leaks at the source and a few hops away, while ROA and ASPA validate the origin and the AS path after the fact, making BGP security verifiable rather than dependent on operator discipline alone.

原文链接：https://community.juniper.net/blogs/anton-elita/2026/07/13/secure-bgp-aspa-preventing-and-fixing-route-leak