Summary

  • ASPA verification returns Valid, Unknown or Invalid from signed provider sets, the observed AS_PATH and a locally selected upstream or downstream algorithm; the label is bounded evidence, not a verdict on route selection, forwarding or culpability.
  • Revision 28 recommends equal preference for Unknown and Valid, makes Invalid ineligible and retains it for re-evaluation. Operators therefore need receipts for object version, local role, algorithm inputs, policy action and traffic outcome.

Two routes, one preference class

An edge router receives two paths. Every customer-to-provider pair in the first can be checked against a cryptographically valid ASPA. One pair in the second has no usable attestation. Neither path contains a known contradiction.

The first can be Valid. The second is Unknown. Under the mitigation policy recommended by revision 28 of BGP AS_PATH Verification Based on Autonomous System Provider Authorization Objects, both should receive the same preference level.

That sentence can be read too quickly. It does not say that Unknown is a weaker spelling of Valid. It says that incomplete deployment should not, by itself, demote a route. The operator keeps reachability while the evidence system fills in. Ordinary BGP attributes and local policy still decide which eligible path wins.

Revision 28 was published on 24 August 2026 and expires on 25 February 2027. Datatracker lists it as an active SIDROPS working-group Internet-Draft intended for Proposed Standard, at WG Consensus: Waiting for Write-Up; its IESG state is I-D Exists. That is meaningful progress, but it is not an RFC, IESG approval, global deployment or measured protection.

The object authorizes a relationship claim

The companion ASPA profile defines a signed RPKI object. The holder of a Customer AS identifier lists the Provider AS numbers authorized to provide transit. The set includes a non-transparent route-server AS when that server places itself in AS_PATH. A customer is expected to keep one object containing every provider.

The object is deliberately asymmetric. AS 64500 saying “64510 is my provider” is not equivalent to AS 64510 saying “64500 is my customer,” and it is not a public copy of the commercial agreement. The RPKI chain lets a relying party verify that the holder of the customer ASN made the attestation. It does not reveal settlement terms, address-family restrictions, temporary traffic-engineering exceptions or whether a BGP session is up now.

If more than one cryptographically valid ASPA exists for a customer, verification uses the union of their provider sets. This prevents a transient duplicate object from discarding a listed provider, but it also enlarges the accepted set. The draft recommends one object partly to avoid update races.

An AS0 ASPA makes a different bounded statement: the customer has no transit providers and is not a client of a non-transparent route server. It still does not prove the AS is reachable, that it announces no routes, that a transparent route server is absent, or that traffic arrived.

Three answers, not a binary certificate

For each ordered pair (x, y), the provider-authorization function asks whether AS y is an attested provider of customer AS x.

It returns Provider+ when the customer's valid provider set contains y. It returns Not Provider+ when a valid set exists but omits y. It returns No Attestation when no ASPA was retrieved or none is cryptographically valid.

The difference is the design. Not Provider+ is a contradiction against a purportedly complete signed list. No Attestation is a hole in the evidence. Converting both into “false” would make partial deployment look like a negative assertion and would create avoidable outages.

Revision 28 compresses consecutive duplicate AS numbers, then tests whether the path can be covered by customer-to-provider ramps. An up-ramp starts at the origin side. A down-ramp starts at the receiving side. Provider+ extends a confirmed minimum. No Attestation stops the minimum while leaving a larger maximum possible. Not Provider+ bounds the maximum.

If even the maximum ramps cannot cover the path, the result is Invalid. If the maximum can cover it but missing attestations stop the minimum, the result is Unknown. If the minimum covers it, the result is Valid. The calculation establishes one structural property under the available objects. It does not replay how the UPDATE actually traveled.

Direction is a local input

The same sequence of AS numbers is not evaluated in a vacuum. A route received from a Customer or Peer uses the upstream algorithm, which expects only an up-ramp. A route received from a Provider uses the downstream algorithm, which permits an up-ramp and a down-ramp.

The verifier must therefore know the local relationship with its neighbor. RFC 9234 BGP Roles can encode and cross-check that relationship during OPEN negotiation, and revision 28 recommends using them to select the algorithm. Yet the role remains configuration at the participating routers. It is not inferred from the ASPA object and is not a universal statement about every prefix exchanged on the session.

Complex relationships make the boundary visible. Two networks may be provider and customer for one set of prefixes and peers for another. The draft prefers separate sessions or per-prefix algorithm choice. If that cannot be done, it permits the more accommodating downstream algorithm to avoid false positives. That fallback is an operating policy under ambiguity. It is not proof that the relationship has one direction.

Before either algorithm runs, the router also needs the ordinary BGP prerequisites. AS_SET is subject to treat-as-withdraw under RFC 9774. The most recently added AS normally must match the neighbor ASN, with the route-server exception. A dashboard that records only the final ASPA state can hide whether the failure came from malformed path structure, neighbor mismatch or a provider-set contradiction.

Unknown and Valid share treatment, not provenance

The recommended mitigation has two branches. Invalid routes should be ineligible for route selection and must remain in Adj-RIB-In for possible re-evaluation. Unknown routes should receive the same preference level as Valid routes.

Equal preference is a reachability decision. It prevents early adopters from turning every missing customer ASPA into a routing penalty. It also means an operator cannot use “accepted under ASPA policy” as shorthand for “all relationships were attested.” A path may remain eligible precisely because the system declined to convert absence into contradiction.

Nor does equal preference imply equal outcome. BGP selection can still choose between the two paths using local preference, AS_PATH length, origin, MED and other policy. The winner may enter Loc-RIB. A separate process may program a next hop into the FIB. Packets may follow that next hop, encounter a different failure, or never arrive. The ASPA label proves none of those later steps.

Invalid is also narrower than it sounds. Revision 28 recommends logging the hops that produced Not Provider+, but says the logging router cannot necessarily identify the AS that caused the leak. The first visible contradiction may be downstream of the configuration error, stale object or path manipulation. “Invalid at pair x–y” is a diagnostic receipt, not an accusation.

Publication and propagation run on different clocks

ASPA data changes independently of BGP UPDATEs. A customer can add a DDoS mitigation provider, migrate between CAs or remove a former transit. Repositories publish objects; relying parties retrieve and validate them; caches send validated payloads to routers; routers re-run policy. Meanwhile the route may already be propagating.

Revision 28 recommends listing standby or emergency providers before they are used. Otherwise a legitimate failover path may become falsely Invalid at networks that saw the route before the new ASPA. During a CA transition, corresponding objects should remain identical. These rules acknowledge that a correct intended state is not the same as a globally observed state at one moment.

The asymmetry of mistakes matters. An erroneously included provider makes verification more permissive and reduces detection. A missing legitimate provider can reject a real route. The operator needs change receipts for both directions, not a generic “object valid” light.

Invalid routes remain in Adj-RIB-In for the same reason. When a new ASPA arrives, a router should be able to re-evaluate the stored path without waiting for its neighbor to advertise it again. RFC 9324 documents the analogous operational lesson for RPKI-based policy: validation data can change independently from the BGP feed.

One provider union covers two address families

The U-SPAS applies to both IPv4 and IPv6 unicast. If a customer uses a provider only for IPv4, the listed authorization also makes the IPv6 calculation permissive. Revision 28 calls this a reasonable compromise: it simplifies registration and avoids false Invalid results.

The compromise narrows what Valid can mean. It cannot, by itself, prove that the particular customer-provider relationship applies to the address family of the route. An operator that needs that distinction must retain local relationship and session evidence outside the ASPA object.

This is not a defect hidden by the specification. It is an explicit choice to prefer availability and operational simplicity over a finer signed schema. The right audit question is not whether the label sounds strong. It is which uncertainty the data model intentionally leaves unresolved.

Valid does not close the path

The security considerations preserve further limits. A provider may forge an origin or path segment involving its customers in ways ASPA does not detect. The algorithm cannot detect adding or removing repeated AS numbers, though the draft says that manipulation alone does not impair its route-leak detection objective. Complex relationships can create other blind spots; OTC is recommended as a complement.

ROA, ASPA, BGPsec and OTC answer different questions. A ROA authorizes an AS to originate a prefix. ASPA attests customer-to-provider relations used to test path shape. BGPsec supplies cryptographic evidence that an UPDATE traveled the signed path but does not itself catch valley-free violations. OTC carries a propagation constraint that can stop a local leak ASPA inspection of prior segments might miss.

No single green state absorbs the others. A route can have a Valid origin and an Unknown ASPA path. It can pass ASPA while lacking BGPsec signatures. It can pass both origin and relationship checks yet violate a local export policy not represented in either object. It can be selected and still fail in forwarding.

The receipt chain operators actually need

A defensible claim begins with the exact draft and object profile. It records the ASPA payload, customer ASN, full provider set, certificate chain, manifest and revocation state, and the object hash. It then records the repository snapshot, relying-party version, validation time, router-cache transfer and router import time.

At the session layer, it preserves neighbor identity, local BGP Role, route-server behavior, address family and prefix-specific exceptions. At the path layer, it stores the raw and reconstructed AS_PATH, compression step, neighbor-AS check and AS_SET handling. At the algorithm layer, it records every pair result, ramp bounds, selected upstream or downstream procedure and final Valid, Unknown or Invalid state.

Only then come the operator's actions: retention, eligibility, preference, route selection and Loc-RIB result. FIB state, packet capture, loss, latency and application observation are later receipts again.

Heng Lu's running-code discipline applies cleanly here. The signed coordination object should be authoritative for the bounded assertion it can support. The router's executed policy should be authoritative for what that router did. Neither is entitled to borrow the other's claim, and neither proves what packets or users experienced.

What the sources do not prove

The frozen sources establish the proposed object semantics, verification algorithms, policy recommendations and stated limitations. They list implementation work, but they do not prove that a named release conforms, that a production network applies the recommended policy, that a particular leak was stopped, or that global deployment has reached any threshold.

This Article does not accuse an AS, reconstruct an incident or estimate adoption. Its conclusion is narrower: ASPA creates valuable, machine-verifiable evidence about provider relationships and path shape, while deliberately preserving an Unknown state and local policy authority. That boundary is a feature only if operators keep it visible.

Sources