Secure BGP with ASPA: Preventing and Fixing Route Leaks

2026年8月22日 LOG admin

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.

For most of BGP's history the only defence was operator discipline: prefix filters, max-prefix limits, and manual coordination between network operations centres. Those controls remain necessary, but they are local. They protect the edge of one network and do nothing about a correctly configured router in a neighbouring AS that re-advertises a route it should never have accepted. Cryptographic validation changes the question from "do we trust the operator?" to "can we verify the claim?". This article covers both halves of that transition: the in-protocol, distributed prevention that BGP Roles provide, and the signed, out-of-band proof that RPKI ROA and ASPA provide.

The Valley-Free Model and How Route Leaks Happen

To see why a leak is a protocol violation and not merely a configuration error, it helps to be explicit about the economic model underneath BGP. Every session between two autonomous systems is one of three relationship types: customer-to-provider, where the customer pays for transit and the provider carries the customer's prefixes toward the rest of the Internet; peer-to-peer, where two networks exchange traffic for their own customers and prefixes free of charge; and sibling-to-sibling, where both networks share a common administration.

A well-behaved AS PATH is valley-free. Read from the origin at the left toward the destination at the right, the relationship sequence climbs the provider chain, crosses at most one peering or sibling link, and then descends the provider chain. You never climb, cross, and climb again, and you never descend and then climb back up.

A route leak is any advertisement whose path breaks that shape. A textbook example: a multi-homed customer has two providers, A and B. The customer learns a route from provider A and, because it does not filter its exports toward B, forwards it to B. Provider B now sees a path that reads … customer → A → … and, if B prefers it, B may forward that same path back toward A. Traffic destined to A's customer now traverses B and the leaking customer, neither of which is supposed to carry that traffic. When the leaked path is a full table, the leaker's links saturate and a large fraction of the Internet notices within minutes.

A hijack is the same failure with intent: an AS originates a prefix it does not own. The signature of a hijack is an origin problem — the wrong AS appears at the right-hand end of the path. The signature of a leak is a path problem — the origin is correct but the shape is wrong. That distinction maps directly onto the two validation mechanisms below: ROA validates the origin, and ASPA validates the shape.

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.

Route origin validation answers one narrow question: does the rightmost AS in the AS PATH have a signed authorisation to originate this prefix? It does not care how the path got to you. A prefix with a perfectly valid ROA can still arrive over a leak, and a prefix with no ROA at all can arrive over a completely legitimate path. That is the gap that BGP Roles and ASPA exist to fill.

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. RFC 9234 defines the mechanism: a speaker that declares the provider role will reject any route carrying the OTC attribute, because that attribute signals "this path was learned from a customer or a peer and must not be sent to a provider". The leak is therefore caught not only at the source but at every downstream provider along the path, which is what makes the OTC attribute effective even when the leaking network never implements it.

BGP Roles and the OTC Attribute in Practice

Deploying roles is deliberately incremental. A network can start by configuring roles on its own sessions without touching the routes: until the OTC attribute appears, the capability only records the relationship. Enable it in three steps:

Configure the local role on every external session and let the sessions re-establish. Verification is a capability negotiation, so nothing else changes.
Turn on OTC generation toward peers and providers for routes learned from customers and peers. Now a leak injected by a downstream customer is tagged and killed at the next provider hop.
Add the "strict" keyword once you have confirmed that all your neighbours negotiate the capability, so a non-conforming neighbour cannot silently bypass the protection.

The value compounds with reach: the more of your providers that implement OTC rejection, the more likely it is that someone else's leak dies before it reaches you. Combined with RPKI route origin validation and a disciplined peering-security baseline, roles give you the first layer of defence against path manipulation.

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

ROA validation, already deployed at scale, catches the hijack case. It is far weaker against leaks, because the leaking AS often has a valid ROA for the prefixes it is leaking; the origin is genuine, only the path is not. ASPA closes that hole by letting an AS publish a signed set of the networks that are authorised to be its providers. A validating router can then walk the AS PATH from the origin outward and check that every step is a legitimate customer-provider relationship in the direction the path claims.

ASPA: What It Validates and How It Differs from ROA

The two mechanisms answer different questions and are complementary, not alternatives:

ROA — "Is the rightmost AS authorised to originate this prefix?" One signed object per prefix (or prefix/AS pair). Protects against origin hijacks.
ASPA — "Are the AS-to-AS adjacencies along this path consistent with each AS's declared provider set?" One signed object per AS, listing its provider ASNs. Protects against leaks and against forged paths, because an attacker cannot manufacture a valley-free path that also satisfies every AS's ASPA.

Because ASPA objects attach to the AS, not to prefixes, the data footprint is tiny — a reported global object set in the low thousands, versus roughly three quarters of a million ROA IPv4 prefixes. That small, slowly changing set makes ASPA cheap to validate at line rate, and it is the reason validation is practical on current-generation routers.

Configuration: Deploying ASPA Validation

An ASPA deployment has an out-of-band half and an in-band half. The out-of-band half is the signed ASPA object, published through the RPKI and distributed by the same cache validator that already delivers ROAs over RPKI-RTR. The in-band half is the router policy that acts on the validation state. A representative Junos validation policy:

# Import ASPA-relevant data alongside ROAs from the cache validator
set routing-options validation group rpki-rtr session 10.0.0.9
set routing-options validation group rpki-rtr refresh-time 600

# Validation policy: reject leaks, flag the rest for telemetry
set policy-options policy-statement ASPA-IMPORT term origin-invalid from validation-database invalid
set policy-options policy-statement ASPA-IMPORT term origin-invalid then reject
set policy-options policy-statement ASPA-IMPORT term aspa-invalid from aspa-validation invalid
set policy-options policy-statement ASPA-IMPORT term aspa-invalid then community add ASPA-INVALID
set policy-options policy-statement ASPA-IMPORT term aspa-invalid then preference 60
set policy-options policy-statement ASPA-IMPORT term accept then accept

The exact statement names vary by platform and release, but the shape does not: query the validation database, decide per prefix, and prefer to add a community and lower preference before you start discarding routes outright. A prefix with a genuinely bad path is worth dropping; a prefix whose ASPA data is merely incomplete is worth keeping with a marker so you can measure before you enforce.

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

Streaming this state over gNMI is what turns ASPA from a configuration checkbox into an operational metric. Watch three series: the count of prefixes with an ASPA-invalid path, the count of sessions not negotiating the OTC capability, and the cache-validator record counts. A sudden jump in ASPA-invalid routes usually means a cache validator is stale or a large network published a new object — not that the Internet broke.

A Migration Checklist for Operators

Rolling these controls out together avoids the classic trap of enforcing before you can measure:

Filter what you export, not just what you import. Most leaks are export errors by the leaking AS; you cannot fix someone else's router, but you can make sure yours never leaks.
Deploy RPKI ROV in monitor mode first, then move "invalid" routes to a lower preference, then drop them. See the dedicated RPKI ROV deployment walkthrough for the monitor-first sequence.
Add BGP Roles on every external session and enable OTC generation toward peers and providers.
Enable ASPA validation in monitor mode and build the telemetry before you enforce.
Use an RPL prefix-set or an equivalent route-policy to bound what you accept from each neighbour, so a stale validator cannot cause a self-inflicted outage.

Troubleshooting and Common Pitfalls

Three problems account for most of the surprise in an ASPA or Roles rollout. First, an ASPA-invalid route that turns out to be correct almost always signals incomplete deployment data: the upstream AS has not published its provider set yet, so a legitimate path looks unauthorised. Monitor mode catches this before enforcement does. Second, a session that refuses to come up after "strict" is added usually means the neighbour simply does not negotiate the capability; removing strict temporarily restores it, and the OTC attribute still protects you. Third, remember that neither mechanism is a substitute for inbound prefix filtering — the strongest single control remains a tight filtering policy at your own edge.

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. The mature posture is defence in depth: export filters you control, OTC rejection you participate in, and RPKI validation you can measure.