Summary

  • ARIN gives each Customer ASN a unique ASPA and lets the resource holder modify its set of Provider ASes. The operating action is therefore a replacement of a complete set, even when the human intention is merely to add or remove one upstream.
  • ARIN distinguishes immediate effect in its RPKI database, appearance in the public repository within 24 hours, repository updates every few minutes and verification through an independent validator. Those are separate states, not one moment called “success”.
  • The active IETF drafts say the set should contain the union of all providers, including non-transparent route servers, and distinguish No Attestation from a provider that is absent from a usable set. An omission can matter without proving that every affected route is automatically invalid.
  • A privacy-safe diff receipt should bind the authorised before-set, complete submitted after-set, atomic transaction outcome, issued object, public observation and validator view. It should expose state conflict without publishing contracts or private topology.

The dangerous word in an ASPA change is “one”. One new transit provider. One route server. One standby link. One ASN removed after a contract ends. The ticket sounds atomic because the commercial event is atomic. The signed object is not. It expresses the provider set of a Customer ASN, and changing one member requires submitting the set that should remain true after the change.

That difference turns a routine edit into a state decision. If the authorised set was {A, B} and the intended set is {B, C}, the useful evidence is not simply that C was added. It is that A was removed, B survived, C appeared, and the person or automation making the change had seen the same before-state that the system was about to replace. Without that lineage, a green transaction result proves too little.

ARIN’s implementation makes the state model unusually visible. Its guidance says a unique ASPA object must be created for each Customer ASN. In ARIN Online, a holder modifies the set of Provider ASes attached to that object. The REST interface likewise describes ASPA deletion and addition elements carrying a Customer ASN and providerAsIds. It can combine ASPA and ROA operations in one transaction, with every element succeeding or failing together.

Atomicity is valuable. It prevents half of a submitted bundle from becoming registry state while the other half fails. But it answers a narrow question: did ARIN accept this requested bundle as a unit? It does not tell an operator whether the request was based on the latest authorised set, whether the issued object was visible in the public repository at a particular time, or whether a relying party had fetched and interpreted it.

These are not theoretical distinctions invented outside the service. ARIN’s own ASPA page separates them. It says changes take effect immediately in the RPKI database and appear in the public repository within 24 hours. It also says the repository is updated every few minutes and advises operators to use an RPKI validator to verify that the ASPA is active. A database commit, a repository object and a validator observation are three points on one chain.

A list can hide the fact that it is a set

Most interfaces make sets look like lists. They display one ASN per line, accept additions and deletions, and return a confirmation. That presentation encourages users to think in deltas. The cryptographic statement that relying parties consume is a state.

The active ASPA profile draft says all Provider ASes should be listed, including non-transparent route-server ASes. Where several valid ASPA objects exist for the same Customer ASN, relying parties construct a union. The draft nevertheless recommends avoiding multiple objects because their validity intervals can introduce race conditions. The companion verification draft also frames the customer’s SPAS as the union of all providers and recommends one ASPA object.

The editorial caution here matters: these are Internet-Drafts, not final RFCs. Their versioned text may change. They are still the best current description of the semantics being implemented and tested, and they show why an edit cannot safely be understood as an isolated checkbox.

Suppose an operator has two ordinary transit providers and a non-transparent route server. A change manager adds a third transit provider from a screen based on yesterday’s state, while a network engineer has already added the route server from another session. If both submit complete replacement sets and the system accepts them in sequence, the later transaction can erase the earlier member without either transaction being malformed. Each actor may truthfully say “my change succeeded”. The resulting set may still be wrong.

This is a lost-update problem with routing consequences. It cannot be solved by recording only the requested addition. The service must know what prior state the requester authorised, or at least its canonical digest. A compare-and-set precondition can then reject a request made against stale state. The rejection does not decide which provider relationship is real. It forces the humans or automation to reconcile that decision before a new signed object is issued.

No Attestation is not the same as Not Provider+

The verification draft gives the set boundary operational meaning. When no usable ASPA entry exists for a customer, the provider-authorization result is No Attestation. When the provider is present in the usable provider set, the result is Provider+. When the customer has a usable set but the provider is absent, the result is Not Provider+.

Those labels must not be flattened into “valid” and “invalid” without context. Full AS-path verification evaluates directions, path segments and the available authorizations. An absent provider can contribute to a route later becoming falsely ASPA Invalid, as the draft warns, but it is not accurate to claim that every route using an omitted ASN is automatically invalid everywhere. The relevant point is sharper: deleting the object and accidentally omitting one member from a non-empty object are semantically different acts.

That difference is why a receipt needs the whole before-and-after set. A record that says “removed provider A” cannot establish whether the resulting state was No Attestation or {B, C}. A record that says “added C” cannot show whether B was preserved. A screen capture can show what one browser rendered, but not necessarily the canonical request bytes, authenticated transaction, issued object or relying-party observation.

Standby links make the timing problem harder. The verification draft recommends registering standby or emergency providers in advance. That advice follows the logic of failover: the authorization should be available before traffic moves onto the contingency path. If the provider is added only after a failure begins, registry acceptance, repository publication and validator refresh become part of the recovery clock. A receipt should make those clocks measurable without promising that all relying parties converge at once.

The four clocks behind a green result

The first clock is authorisation. It begins when a resource holder or delegated automation decides what the complete provider set should be. Its evidence is the prior set seen, the after-set approved and the identity class or role permitted to make the decision. Named staff need not appear in a public record.

The second clock is the transaction. ARIN can record request receipt, authentication, validation and atomic acceptance. If a request contains both ROA and ASPA elements, the transaction identifier should bind them while still allowing a receipt to redact unrelated operational details. A failure should leave the prior state intact; a success should identify the issued-state digest.

The third clock is publication. ARIN says its database changes immediately and public repository appearance can take up to 24 hours, while ordinary repository updates occur every few minutes. The outer bound is not evidence that normal publication takes a day. It is a reason to record the actual first observation of the object, its hash and the relevant manifest or repository reference.

The fourth clock is consumption. A validator must fetch the repository material, validate the chain and construct the usable provider set. The observation belongs to a named vantage and software build at a stated time. It does not prove universal convergence, because other relying parties may refresh on different schedules, reject a chain for a local reason or run different code.

When these clocks are collapsed into one “updated” timestamp, an incident review cannot locate the boundary. The submitted state may be wrong; the transaction may have failed; the object may not yet have been observed; or a validator may be stale. Each condition calls for a different response. One status light cannot distinguish them.

What a diff receipt should contain

The receipt begins with the Customer ASN and the issuing certificate or CA context. It records the canonical prior provider set, or a digest with a durable reference to the prior signed object. It records the complete submitted after-set in a stable sorted order. From those two states it derives added, removed and unchanged ASNs. The diff is evidence, not the source of truth; the complete sets are.

It should identify non-transparent route servers and optionally label standby or emergency roles where the operator has chosen to maintain that operational metadata. Such labels need not enter the ASPA payload. They explain why a member was included and help change managers avoid removing a path that is quiet precisely because it is reserved for failure.

The transaction section should carry a request identifier, authenticated actor class, submitted-set hash, compare-and-set precondition, acceptance time and result. If the operation was part of a mixed ROA-and-ASPA transaction, the receipt can state that relationship and the all-or-nothing result without disclosing unrelated prefixes to a public audience.

The publication section should identify the issued ASPA object hash, the repository or manifest reference and the first observation time from a defined monitor. The validator section should name the vantage, validator software and version, retrieval time, observed usable provider set and any tested transition between No Attestation, Provider+ and Not Provider+.

Finally, the receipt needs lifecycle links of its own: superseded by, corrected by, expired at and rolled back to. A rollback is another complete-set decision, not an erasure of history. If the wrong provider was removed, the evidence should show both the faulty state and the corrected one, with access controls appropriate to the audience.

This record can be compact. Most fields are hashes, identifiers, timestamps and small ASN sets. It does not require a narrative after every edit. It requires a machine-readable chain from intent to observation, plus a human summary that says what changed and what remains unverified.

Privacy is not an excuse for missing lineage

Provider ASNs in an ASPA are intended for public consumption through RPKI. That does not make every fact about the relationship public. Contracts, price, traffic volume, contact names, maintenance windows, credentials and internal topology can remain private. A public receipt can show the signed set, state digests, broad actor role and observation evidence. A richer member-visible view can preserve internal approvals.

The same proportionality applies to validators. Publishing “observed by monitor X using version Y at time Z” makes the test reproducible. Publishing an assertion that “the Internet has converged” would exceed the evidence. The service can offer several independent observations, but each remains a vantage, not an oracle.

A time boundary is also a privacy and operational safeguard. Receipts need durable integrity, yet detailed actor and workflow metadata need not remain publicly exposed forever. A long-lived public layer can retain the cryptographic chain and state transitions; restricted records can follow the organisation’s retention rules.

This is a control proposal, not an allegation

ARIN announced that ASPA was fully available in ARIN Online in March 2026. Availability says the service can be used. It does not establish adoption, prove an error or transfer the deployment decision from operators to the registry.

ARIN’s own public discussion kept that boundary clear. At ARIN 57, John Curran described a role for implementing and explaining ASPA while saying it was not ARIN’s job to tell operators that they should deploy it. A diff receipt fits that limited role. It does not decide whether an ASN needs an ASPA or which provider belongs in it. It makes an authorised decision inspectable after the fact.

There is no evidence here that ARIN has lost or mispublished a provider set. No route is alleged to have become ASPA Invalid. The 24-hour statement is not treated as observed delay. The argument comes from the service’s documented state transitions and the drafts’ complete-set semantics.

That is enough. Controls should often be designed before a public failure supplies the anecdote. The cheap moment to preserve the before-state is when the edit is made. Reconstructing it later means finding browser histories, API logs, old repository objects and validator caches that were never designed to form one record.

An ASPA edit can be small in commercial intent and large in semantic scope. The operator thinks in one provider; the relying party consumes the whole set. ARIN can close that gap with a receipt that names both states and follows the decision until an independent validator sees it.

The green confirmation should be the beginning of the evidence, not its end.

Sources