Summary

  • RIPE NCC’s published RIPE 93 RPKI update abstract says its early analysis finds up to 10% of provider ASNs omitted from ASPA objects. Overlooked upstreams and neighbours mistaken for peers are among the causes it names.
  • RIPE NCC’s ASPA guide says a signed object missing a real provider can cause routes through that provider to be rejected. Its dashboard currently offers no BGP-derived provider suggestions.

The list is signed; the gap travels with it

An ASPA object is an AS holder’s signed account of which other ASNs may act as its upstream providers. RIPE NCC’s RIPE 93 RPKI update abstract puts a sharp number beside the housekeeping: initial analysis indicates that up to 10% of provider ASNs are missing from ASPA objects. The registry names two routes into the gap. Operators overlook an upstream, or call a neighbour a peer when it also acts as a provider.

The signature verifies who made the declaration. It also preserves every omission with cryptographic precision. An operator can publish an object, see a successful RPKI validation, and still have written down an incomplete map of the network’s business relationships. The interesting error is not a broken key. It is an accurate signature on an inaccurate list.

RIPE NCC’s ASPA guide draws the line around role, not the nickname in a contact book. Upstream transit providers belong in the object. So does a neighbour with mixed peering and provider roles; so does a non-transparent route server that appears in the path as a provider. Lateral peers and customers stay out. The awkward neighbour is exactly where an operator’s internal label can collide with what its routes actually do.

One missing name changes the verdict

The guide gives a plain test. Where an AS has signed an ASPA, a provider ASN listed in it yields Provider. A provider ASN absent from that same signed list yields Not Provider. With no ASPA from the customer AS, the result is No Attestation. These are different signals. A half-complete signed list can give a verifier stronger negative evidence than silence would have supplied.

That is why RIPE NCC warns that forgetting a provider can lead to rejection of routes sent through it. The outcome depends on the path and on a receiving network’s ASPA verification and filtering. RIPE’s abstract reports missing entries, not measured route drops or outages. The immediate operating decision is smaller and sharper: compare every provider named in the signed object with actual transit, mixed-role peering and route-server arrangements before a verifier treats absence as evidence.

The current dashboard leaves that comparison to the operator. RIPE NCC says the RPKI update will discuss better ASPA suggestions, while its published guide says the dashboard presently gives no BGP-derived provider hints. A hint can point to a suspicious omission; the holder must settle the relationship. BGP adjacency alone cannot sign a contract for a network.

The number needs its denominator

RIPE NCC’s abstract gives no sample size, observation window or method behind “up to 10%”. A dated measurement report with the numerator and denominator would show how broadly the estimate applies. For now, the finding is a direct warning to holders whose signed list has never been checked against their running network.

The registry’s next useful move is to show why a provider is suspected: which path, when it appeared and which role produced the signal. The operator’s next move is to inspect its signed object before the missing name turns into a “Not Provider” result. A green signature is a receipt for authorship. The upstream list still needs an audit.

Sources: RIPE 93 RPKI update abstract; RIPE NCC ASPA guide; IETF ASPA verification draft, revision 29.