Summary

  • APNIC told the APNIC 62 Routing Security SIG that its hosted ASPA interface suggests providers from RIPE RIS. The suggestions are probabilistic, require review and are more likely to include too much than too little.
  • The interface also checks a proposed provider-set change against observed BGP paths. That is a useful test of the present, not a rehearsal of every future path.
  • The current IETF verification draft recommends adding standby or emergency providers to the ASPA before activation, so publication does not race route propagation. A dormant provider should have no live path for the checker to observe.
  • APNIC should preserve a provenance-and-scenario receipt that separates observed suggestions, human declarations, rejected candidates, current-path checks and unexercised failover cases. The receipt documents a decision without exposing commercial contracts or commanding a router.

The quiet row in an otherwise helpful editor

An ASPA editor begins with a list. For one customer ASN, it records the autonomous systems permitted to act as upstream providers. The list is cryptographically signed and distributed through the Resource Public Key Infrastructure. Its apparent simplicity hides a difficult question: how does the person holding the ASN know that the list is complete and correctly classified?

APNIC's answer includes two practical aids. In the RPKI update presented at APNIC 62, the organization said its hosted interface offers suggestions based on the RIPE Routing Information Service. It uses the RIPEstat asn-neighbours endpoint, much as APNIC's route-management tools already offer route suggestions. APNIC described these ASPA suggestions with unusual and welcome precision: they are probabilistic, they must be reviewed, and they are more likely to be over-inclusive than under-inclusive.

The second aid is a change check. Before accepting an edit, the interface examines how observed BGP paths would be affected. A person who removes a provider that appears in current paths can be warned before turning a presently usable path into an ASPA conflict. The same process can make a surprising suggestion visible for review rather than silently signing it.

This is good product design. It puts measurement next to authorization without pretending that measurement is the authorization. It also reveals the boundary of the design. The provider most likely to be absent from a current observation is the provider that has been deliberately kept in reserve.

An emergency transit arrangement may remain dark until a cable cut, denial-of-service attack or regional isolation changes the network. A DDoS mitigation provider may not appear in ordinary paths. A link prepared to reconnect an isolated segment may be exercised only during a failure. If its ASN is visible in day-to-day BGP, it is not fully dormant. If it is truly dormant, a live-path checker has no positive path to test.

The blank row is not a software bug. It is a different evidence class.

A neighbour observation is deliberately weaker than a provider declaration

RIPEstat's documentation is careful about what the source produces. Its ASN Neighbours endpoint returns autonomous systems observed next to a queried ASN in RIS data. Depending on the version and requested detail, the response can include whether the neighbour appeared on the left or right of the ASN, how many paths contained the pair, how many full-table peers saw it and the time for which the result is valid. A neighbour seen as a direct peer of a RIS collector can be marked uncertain, because the collector relationship itself can influence the observation.

Those fields make the suggestion auditable. They do not make it a provider contract. An adjacent ASN in an AS path can be a customer, provider, lateral peer, non-transparent route server or part of a relationship whose role varies by address family, geography or prefix. RIS sees paths available to its collectors. It cannot see a private service agreement that has not yet produced a route, and it should not be asked to infer one.

This explains why an over-inclusive suggestion set can be the safer starting point. Missing a currently active provider may produce a destructive omission. Showing an extra candidate makes the operator perform a classification. But “more likely over-inclusive” is a property of the observed suggestion method, not a guarantee that every genuine provider will be present. No observation system can include a future relationship solely because the operator intends to activate it next month.

The correct workflow therefore has at least two inputs. One comes from measurement: these ASNs appeared next to the customer ASN in a declared RIS observation window. The other comes from accountable human knowledge: these ASNs are authorized providers, including arrangements that may be inactive today. Mixing the two into an undifferentiated checklist would discard the strongest fact each source can contribute.

The standard's timing advice creates the missing test

The current IETF documents sharpen the problem. Revision 29 of the ASPA profile describes one ASPA object for a Customer AS containing all providers, including applicable non-transparent route-server ASes. Keeping one complete object is intended to avoid races during updates that might affect BGP propagation.

Revision 28 of the AS_PATH verification draft is even more explicit. An AS may maintain standby providers for particular operating scenarios. It names temporary DDoS mitigation and an emergency provider used to bridge isolated segments. The draft recommends adding those providers to the ASPA in advance. The reason is temporal: if a network begins propagating a route before the changed object has reached relying parties, a legitimate failover can look inconsistent with the authorization set.

That recommendation creates a test which current BGP cannot perform. Before activation, there is no emergency path. After activation, the race may already have begun. The decision must be made during the interval in which authorization exists but observation does not.

This is the inverse of a familiar caution about ASPA. A signed provider list does not prove that transit is currently being delivered. Here, a missing observed path does not prove that the provider should be absent from the signed list. Authorization and observation are different in both directions.

The APNIC presentation does not claim otherwise. It says the suggestions need review and asks for feedback on the suggestion and validation functions. Nor does the public deck reveal every private field the interface may retain. The defensible conclusion is narrow: its described BGP check can test observed paths, while the standards-track work-in-progress recommends a class of authorization whose defining path may be unobserved.

“No current conflict” is not “failover passed”

A useful interface should preserve that sentence exactly in meaning, even if its display language varies. Suppose a customer ASN normally uses providers A and B and has an agreement with provider C for emergency mitigation. RIS sees A and B. The editor suggests A, B and perhaps a neighbouring peer D. The operator removes D and manually adds C.

The current-path checker can answer several valuable questions. Would removing A make a visible path contain a provider pair that the new ASPA does not attest? Does B appear only in IPv6 observations? Did D arrive from an uncertain collector adjacency? Are there currently observed paths affected by the proposed set?

It cannot show that C will announce the intended prefixes, preserve the required AS path, carry sufficient traffic, respect the activation policy or become visible only after the new ASPA has propagated. Even a laboratory route may not reproduce the emergency. The most the editor can honestly say from its live data is that no conflict was found in the observed path set, and that C was not exercised there.

That is not a weak result. It is a well-bounded result. The danger begins when a green icon erases the boundary and travels into a change ticket as “ASPA validated.” One engineer may read that phrase as “the final object is syntactically and cryptographically valid.” Another may read it as “today's paths remain acceptable.” A manager may read it as “the failover has been tested.” All three claims require different evidence.

APNIC's own separation between suggestions and BGP validation is a good foundation. The next step is to make the negative space portable.

A receipt for the path that does not exist yet

The receipt need not publish a network's confidential contracts, circuit identifiers or DDoS playbook. It can remain inside MyAPNIC or a Member's change record. It needs to preserve roles and clocks rather than secrets.

For every candidate provider, record its source. Was it suggested from RIS, added manually as active, added manually as standby, added as an emergency provider or identified as a non-transparent route server? For a suggestion, preserve the query time, endpoint version or response digest, observed position, uncertainty flag, path count and peer count used in the review. For a rejected suggestion, retain a bounded disposition such as peer, customer, transparent route server, observation artefact or unresolved. The public RPKI object need not reveal that internal reason.

For every manually added dormant provider, record the activation class, the address families considered, the responsible role, the last tabletop or laboratory check and the next review date. “DDoS mitigation” or “isolated-segment bridge” is enough as a class; the receipt does not need commercial price, credentials or topology.

For the current-path check, record the observation window, a digest of the examined path set, the proposed provider set and the result. Most importantly, state which declared providers were not observed and therefore not exercised. That single list prevents “no conflict in current paths” from becoming “all scenarios passed.”

Finally, join the edit to publication. Preserve the final provider set, user confirmation time, ASPA record identity, repository publication time and a later relying-party visibility check. If an emergency begins before the object is visible, the record should say so rather than retroactively moving the authorization clock.

The check should end where operator authority begins

ASPA verification itself has bounded outcomes. The current IETF draft defines a provider authorization function over ordered ASN pairs. Where a valid ASPA exists, a listed provider produces a positive attestation and an unlisted provider produces a negative result. Where no valid object exists, the result is no attestation. Those states feed an AS_PATH verification procedure; they do not prove who owns a router or what contract applies.

The draft also leaves mitigation to the network operator. It recommends making an Invalid path ineligible for route selection and treating Unknown at the same preference as Valid, but the operator configures the actual policy. APNIC's pre-publication check can warn. The ASN holder authorizes. The repository distributes. A relying party validates. The receiving network decides.

Keeping those verbs separate matters most in an emergency. An operator under attack may choose to activate a mitigation path, wait for publication, prefer another path or accept a temporary risk. A registry interface should make the evidence and timing visible without becoming the hidden owner of that choice.

The APNIC 62 deck shows that the product is still young enough for this distinction to be designed in. It recorded first real Member objects on 25 June and a snapshot of 293 APNIC ASPAs, 257 hosted and 36 delegated. Those counts measure creation, not complete provider sets, exercised standby plans or networks enforcing validation. DASH now gives Members an ASPA status view, which can become the natural place to show whether an object is published, observed, scenario-reviewed and due for reconsideration without pretending that one badge covers them all.

Sources