Summary

  • RIPE NCC's current guide tells an AS holder to include every upstream provider, provider-role neighbour and non-transparent route server in one signed ASPA, but says its RPKI Dashboard gives no hint or guidance about providers seen in BGP.
  • The 2026 Activity Plan points toward suggestions based on whom RIPE NCC thinks are upstreams. That wording properly describes an inference, not a relationship decision, and the plan states no feature delivery date.
  • A useful suggestion must arrive as dated, explainable evidence that the operator can accept, reject or classify. The public ASPA remains the authorisation; the dashboard must not silently convert a route observation into one.

An operator can now sign an answer before RIPE NCC shows the question it thinks the network is asking.

The answer is an Autonomous System Provider Authorization, or ASPA: a cryptographically verifiable statement by an AS holder naming the AS numbers permitted to act as its transit providers. The question is less tidy. Which neighbours really belong in that provider set today? Which appear only during failover? Which route server exposes its own ASN in the path? Which commercial counterparty plays provider on one session and peer on another?

RIPE NCC's public guidance puts the responsibility squarely on the signer. Include all upstream providers. Include a neighbour with a complex relationship when provider is one of its roles. Include a non-transparent Internet exchange route server. Do not include lateral peers or customers. Keep the object current in lockstep with changes in the upstream blend. Forget one provider and routes sent through it may be rejected.

Then comes the operational admission: the RPKI Dashboard gives no hints or guidance about which providers it sees for the AS in BGP. The operator must ensure the list.

That is a sharper boundary than a missing convenience. RIPE NCC supplies the signing surface and publishes the object, but the signer arrives at it without an inventory assembled from the BGP evidence available to the registry. The cryptographic act is simple. The classification behind it is not.

The dangerous field is the provider list

A ROA answers whether an AS may originate a prefix. An ASPA addresses the relationships inside an AS path. The distinction changes the cost of a bad entry.

The current IETF profile says that a Customer AS using multiple providers is to list all of them, including non-transparent route-server ASes. It recommends maintaining one object containing the complete provider set. The accompanying verification draft describes the two error directions. Add a provider erroneously and route-leak detection becomes weaker. Omit a provider and legitimate routes may later be judged ASPA Invalid.

One error spends protection; the other can spend reachability. Neither is fixed by making the form easier to submit.

Completeness is especially difficult because the quiet provider is often the one that matters during stress. A backup transit may be absent from a short observation window precisely because the primary path is healthy. Maintenance can expose a relationship that ordinary traffic engineering conceals. An acquisition may leave sessions and contracts moving on different clocks. A route server can be transparent in one design and visible in another. Multi-role relationships resist the neat labels a dropdown wants to impose.

This is why “seen next to your ASN” cannot mean “authorised provider.” BGP exposes paths, not invoices, letters of authorisation or intended business roles. Even a perfect record of adjacency would still need interpretation.

Observation has a vantage point

Every routing observation carries a place and a time. A public collector sees the routes exported toward its peers, after decisions elsewhere have already shaped them. One collector may see an adjacency that another never receives. IPv4 and IPv6 can follow different paths. A regional backup may appear for minutes. A route leak or configuration error can briefly place two ASNs together without creating any legitimate relationship between them.

An operator's own pre-policy BMP stream is richer. It can show what each router received from each neighbour before local filtering. But richness is not authority. Telemetry can reveal a recurring adjacency, a cold path that suddenly became active, or a provider present in IPv6 but not IPv4. It still cannot prove what the parties agreed or whether a multi-role neighbour should be authorised as a provider.

The correct division of labour is therefore straightforward. Routing data finds candidates. Session inventory, contracts and network design classify them. The AS holder decides. RIPE NCC signs and publishes the submitted object. Validators and routers later consume it under an evolving standard and local routing policy.

When those layers are collapsed, a helpful hint becomes a shadow decision. When they remain separate, a hint becomes an auditable question.

RIPE NCC has already described the bridge

The absence of provider hints need not be permanent. RIPE NCC's 2026 Activity Plan and Budget says the organisation will improve BGP information for ROA and ASPA management. For ROAs, it describes getting closer to real-time BGP information. For ASPA, it describes similar suggestions based on whom it thinks are the operator's upstreams.

The sentence is carefully framed. “Who we think” is the language of evidence and inference. It is not a claim that the registry owns the relationship or that the observed set can be signed without review.

It is also not a delivery promise with a date. The captured Q3 2026 RPKI planning page, last updated on 11 June, names four current items: implementing automatic revocation for persistently non-functional delegated certification authorities, replacing RPKI API keys with OpenID Connect-based keys, compliance work, and possible API support for Resource Signed Checklists. The upstream-suggestion feature is not named there. That absence shows only that it is not one of the four published current-quarter items. It does not prove that the Activity Plan commitment has been abandoned or missed.

The timeline still matters. RIPE NCC's 2025 Annual Report records that ASPA support in the Dashboard launched on 26 November 2025. The power to create the signed object therefore preceded the evidence aid described in the next year's plan. That sequencing is defensible for a cautious launch, but it places the inventory burden on early signers.

The strongest defence is restraint

There is a good reason not to guess on an operator's behalf.

RIPE NCC cannot see every transit contract, private interconnection, backup arrangement or route-server setting. It cannot know from a path alone whether an ASN is a provider, a peer, a customer or several of those things in different contexts. An interface that confidently pre-populates the provider set could make a weak inference look like registry knowledge. The signer might accept it because it appears inside an authoritative RPKI service.

The current guide avoids that trap. It states the classification rules, warns about omission and leaves the assertion to the resource holder. In a security system, an honest blank can be safer than an unexplained recommendation.

But the choice is not blank form or automated authority. RIPE NCC can show the evidence it has without deciding what it means. The Activity Plan's own word—suggestions—allows exactly that design.

A suggestion should carry its own receipt

The dashboard should not display a bare list of “likely providers.” It should give every candidate an evidence card.

That card should identify the dataset and vantage family behind the observation. It should record the first and last time the adjacency was seen, the snapshot time and the window used. It should say whether the path was IPv4 or IPv6, where the candidate appeared, how often it appeared, and whether the evidence came from a broad set of vantage points or a narrow corner of the routing system.

It should surface exceptions. Was the ASN seen only during an outage or maintenance window? Does public information indicate a route server, and if so, does it appear transparent or non-transparent? Is the candidate present in one address family only? Does an existing ASPA omit a frequently observed neighbour, or retain a provider that has not appeared for months?

Most importantly, the card should state what the evidence cannot establish. An observed adjacency does not prove provider status, a contract, permission or completeness. A confidence score should describe the strength of the observation, not the truth of the commercial relationship. The rule or model version that produced the suggestion should be visible.

The operator then needs a real disposition, not a single accept button: accept as provider; reject as peer or customer; mark as multi-role; identify as a temporary or backup arrangement; or defer pending review. A confidential local note can point to the session inventory or contract without publishing that material in RPKI.

At signing, the service should preserve the proposed set, the operator's decisions, the before-and-after diff, the accountable user, the time, and the resulting object hash. If the classification later changes, the next receipt should link to the previous one.

The signed ASPA remains the public authorisation. The receipt records how evidence was converted—or refused conversion—into that authorisation.

Visibility after signing does not replace evidence before it

A RIPE Labs community contribution published on 29 June 2026 describes another side of the same problem. Its authors argue that operators lack a convenient way to see what ASPA does against their actual routing tables. They built RAVEN to combine BMP routing telemetry with RTR v2 RPKI data, annotate routes, and explore what-if outcomes.

That work should be read for what it is: a community-contributor account hosted by RIPE Labs, not a RIPE NCC product commitment. It nevertheless identifies a useful feedback loop. Operators need to see both what they are about to assert and what the resulting assertion would do.

The two views answer different questions. Pre-signing evidence asks, “Have I named the right providers?” Post-signing analysis asks, “How would paths be classified if this object were used?” A mature authoring flow should join them without pretending that either can replace human knowledge of the relationship.

A candidate provider can look convincing in observed paths and still be the wrong role. A locally confirmed provider can be nearly invisible in normal telemetry and still be essential during failover. A what-if result can show a route becoming Invalid but cannot decide whether the ASPA or the route is wrong. The operator needs all three views: observation, declared intent and simulated consequence.

The omission hides until the network changes

The current no-hints design concentrates work at the least visible moment. A signer who has a clean commercial inventory may produce a complete object. A signer who relies on memory may omit the rare path. Nothing necessarily fails on publication. The defect waits.

Then a circuit fails, traffic shifts, a backup announces, or a route server changes behaviour. The unlisted provider becomes operational precisely when redundancy is needed. Depending on deployment and policy, paths may later be classified as ASPA Invalid. The article does not claim that this has happened to a particular RIPE NCC member, or that any router currently enforces such a result. The IETF drafts remain works in progress, and operators retain local routing-policy control.

The point is structural. The cost of finding an omission rises after the object has been signed and the quiet relationship becomes active. A dated evidence receipt moves discovery forward, while correction is still an administrative decision rather than an incident task.

RIPE NCC should therefore finish the bridge its Activity Plan sketches. Show the signer which ASNs appear to be upstreams, how the system reached that view, and where the view is incomplete. Make every suggestion rejectable. Record the operator's classification and the final diff. Never let the interface imply that BGP has already decided the relationship.

The registry can see paths. The operator knows the bargain. An ASPA is trustworthy only when the service preserves the distance between the two.

Sources