Summary

  • Number Resource Society guidance says a ROA binds a prefix to an authorized origin ASN, may constrain more-specific announcements through maxLength, and should be changed through a controlled process.
  • A validator’s Valid, Invalid or NotFound result is an observation of current route-origin state. It does not by itself prove who requested or approved a change, which values were intended, or whether withdrawal and rollback finished.
  • A versioned authorization-and-withdrawal ledger can join human authority to RIR publication, validator observations and routing acknowledgements without pretending that a dashboard color proves intent.

A valid route is not a complete change record

The Number Resource Society’s RPKI guidance begins with a useful operational fact: Resource Public Key Infrastructure cryptographically binds Internet number resources to their legitimate holders, and a Route Origin Authorization identifies an AS allowed to originate a prefix. A ROA can also include maxLength, determining how far more-specific announcements remain authorized. RIR-hosted systems may handle certification and publication, while delegated models let a resource holder operate its own certification authority.

That machinery answers an important question: does the observed route origin match a published authorization? It does not answer every governance question around the authorization itself. A present-time result cannot reconstruct who asked for a new origin ASN, who approved a wider maxLength, what change window applied, whether the old authorization was deliberately withdrawn, or which evidence justified an emergency rollback.

NRS’s audit guidance makes the operational stakes concrete. It recommends checking whether a ROA exists, whether the origin ASN and prefix are correct, whether maxLength is appropriate, and whether a route is Valid, Invalid or NotFound. It also asks who can create, change or remove ROAs. An overly broad maxLength can authorize more-specific routes than operations require; an overly restrictive one can make legitimate announcements Invalid.

These are source-backed facts. The ledger proposed here is an editorial inference from them, not a claim that NRS has adopted such a system or that any live ROA is defective.

Treat the change as a versioned authorization

The unit of control should be the change, not the final status. Give it a stable identifier and record the before-and-after prefix, origin ASN and maxLength. Add the accountable resource holder, requester, approver, approval time, intended window and reason. If an emergency procedure shortens normal approval, name the rule used and the person accountable for invoking it.

The record should distinguish authority from execution. A requester may propose a route-origin change but lack authority to approve it. An approver may authorize publication but not touch the RIR portal. A network operator may activate the route but not change the ROA. Conflating those roles makes a clean-looking end state difficult to audit.

The authorization should also state what it does not cover. A change for one prefix should not silently authorize another. Permission to change an origin ASN should not imply permission to widen maxLength. A migration window should not become indefinite authority after the old path has been retired.

A hash of the approved change object can bind the decision to the values later submitted. The hash does not prove that the decision was wise or legally effective. It proves the narrower point that the published evidence can be compared with the version the approver saw.

Publication and validation are separate observations

After approval, the ledger should record the publication action and an authoritative RIR reference at an observed time. NRS’s audit article recommends retaining dated authoritative RIR records as evidence. That snapshot is stronger than a memory that “the portal was green,” yet it still describes what an observer saw rather than why the change was authorized.

Independent validator observations should be stored separately, with timestamp, vantage point and software or service identity. One validator may see the new ROA before another because repositories, caches and refresh cycles differ. A temporary disagreement is evidence to investigate; it is not automatically proof that publication failed or that a route operator acted wrongly.

The ledger should therefore avoid collapsing several states into one checkbox. Useful states include requested, approved, submitted, published-observed, validator-observed, route-activated, withdrawal-requested, withdrawn-observed, rolled-back and superseded. Each transition needs its own timestamp and actor or observer.

This separation also preserves the meaning of NotFound. It reports that the validating view found no covering ROA for the route; it does not reveal whether the absence was intentional, delayed, mistaken or outside the change’s scope. Likewise, Valid confirms a match under the validator’s view, not the continuing business authority of the person who initiated the change.

Migration requires an ordered withdrawal path

NRS says that during migration, new authorization should normally be established and validated before the old route is withdrawn or the old ROA is removed. A change ledger turns that sequencing principle into evidence.

Before execution, the record should define the prerequisite: which new ROA must be observed, from which validator vantage points, and what route check must pass. It should then identify who may activate the new origin, who may withdraw the old route, who may remove or narrow the old ROA, and which acknowledgements close each step.

Withdrawal is not deletion of history. The ledger keeps the earlier authorization, records why it ended, and links the ending event to the replacement or rollback. That protects both operational recovery and accountability. If a change is reversed, later readers can see that the original publication was authorized at the time, when the rollback trigger fired, and which state was restored.

Rollback must be designed before the window opens. The record should name measurable triggers: unexpected Invalid states, missing propagation beyond an agreed interval, route reachability loss, mismatch between submitted and observed values, or inability to confirm the responsible operator. It should also specify the safe order of actions. “Undo it” is not a rollback plan when ROA publication and BGP withdrawal propagate on different clocks.

Keep observation, inference and unknowns apart

The evidence chain should never manufacture certainty. The two NRS sources support the mechanics of ROAs, maxLength, route-origin states, controlled change, audit checks and migration ordering. They do not identify a deficient operator, a compromised account, a disputed route, or a failed RIR process.

The proposed ledger fields are a governance recommendation. It is reasonable to infer that joining approval, publication, validation and withdrawal will make a change easier to reconstruct. It would be wrong to infer that NRS or any named organization lacks these controls merely because its public article does not describe them.

Important facts remain unknown until a specific change produces evidence: who actually holds authority, which platform or delegated CA was used, how quickly each validator refreshed, whether a routing action reached every intended network, and what legal or contractual effect the authorization had. The ledger should record those unknowns rather than fill them with assumptions.

That restraint is the point. Route-origin security is strengthened when a cryptographic authorization is accompanied by a humanly accountable change trail. The result is not more ceremony around RPKI. It is a way to prove which decision produced which object, which observers saw it, and how the organization can end it safely.

Sources