Summary

  • ARIN’s current ROA guide says a Route Origin Authorization can include an optional name, while ARIN Online search is documented for a prefix or ASN.
  • ACSP Suggestion 2024.14 asked for name search; ARIN called it useful in August 2024, placed it among RPKI improvements awaiting prioritisation, and the suggestion remains Open.
  • The RPKI REST interface already carries the name in create and list payloads, so an authorised operator can fetch an organisation’s list and filter it locally.
  • Name search should remain private and subordinate to a stable ROA handle. A label can help find a record; it must never become routing authority.

A label goes in, but the documented search path stops short

The awkward part of ARIN’s ROA interface is not hidden in a routing protocol. It sits in the ordinary life of a field.

ARIN’s current guide describes a ROA as an Origin AS, a prefix with a maximum length, and an optional ROA name. A name is the one part of that set written for an operator’s memory rather than for route-origin authorisation. It can stand for a customer, a migration, a product, a region or a change programme. The prefix and ASN say what the object authorises. The name can say why the organisation created it.

The same guide tells users that ARIN Online can search the organisation’s ROAs for a specific prefix or ASN. It does not list the name as a search key. ACSP Suggestion 2024.14 isolates precisely this gap. Submitted on 23 August 2024, it asked ARIN to let users search by ROA name as well as prefix or ASN, so records belonging to a client or project could be found together.

ARIN’s response on 28 August, five days later, did not reject the premise. It said the addition would usefully expand the current search options, put the request on a list of RPKI improvements pending prioritisation, and said the suggestion would remain open until the functionality was developed and deployed. The captured suggestion page and the current ACSP index still report the item as Open.

That is the public record. It does not prove that an undocumented or newly deployed capability is absent from every authenticated ARIN Online account. No such account was tested for this article. Nor does an Open suggestion establish a missed deadline: ARIN published no date. What the record does establish is a mismatch between an accepted field and the public discovery contract documented for it.

The API makes the gap narrower, not imaginary

ARIN’s RPKI REST documentation supplies the strongest practical objection. Its create example includes a name element. Its ROA Spec Payload also returns the name. The documented organisation-list operation retrieves the ROAs associated with an organisation handle. An authorised team can therefore fetch that list and filter the returned names in its own code.

For some organisations, that is enough. Prefix and ASN are the coordinates that ultimately matter. They are less ambiguous than a project nickname, and they force the person preparing a change to inspect the authorisation itself. A team already using the API may consider local filtering trivial. Adding fuzzy search to a web interface can introduce new ambiguity: two records may share a label; spelling may drift; Unicode may be normalised differently; a renamed project may leave operators searching for yesterday’s name.

Privacy is another reason not to treat the suggestion casually. A label might contain a client name, an internal programme or a commercially sensitive geography. A badly scoped index could disclose more than the signed route-authorisation object was ever designed to say. Prefix-and-ASN search is not defective merely because it refuses that semantic layer.

But a workaround is not the same as an interface contract. The public API guide documents a full organisation-scoped list; it does not document a server-side name-filter parameter on that operation. Requiring every operator to export and filter moves the retrieval rule into local scripts, spreadsheets or memory. It also creates two management experiences: the interface accepts a name, while only separately built tooling can reliably use it as an index.

The claim should remain proportionate. There is no evidence here of an outage, invalid ROA, hijack or customer error. The cost is operational friction and a larger selection surface. If one project spans several prefixes or origin ASNs, the label exists precisely because the network coordinates do not express that grouping. An operator who cannot retrieve by it must remember those coordinates, scan the organisation’s inventory, or reconstruct the grouping elsewhere. The failure mode is choosing or omitting the wrong management record before a change—not changing the mathematics of validation.

A management name is not part of the signed authority

The boundary matters because “ROA” can refer to several connected things.

There is the record an authorised user manages in ARIN’s service. There is the signed object defined by RFC 6482. There is publication in an RPKI repository. There is the validator’s view of that repository. There is an observed BGP announcement, and finally there is the policy by which a network accepts or rejects a route.

RFC 6482’s RouteOriginAttestation syntax contains a version, an AS identifier and IP address blocks. It does not contain a descriptive management name. ARIN likewise says that checking active ROA state requires an RPKI validator and its repository. Finding a record called “client-red-migration” in a management screen would not prove that its signed object is published, that a validator sees it, that a matching route is announced or that any network accepts the route.

That separation is useful, not inconvenient. It lets ARIN improve human retrieval without changing route-origin semantics. The name can remain private, mutable and organisation-scoped. The authorisation coordinates can remain explicit. The only design mistake would be letting a convenient label masquerade as the identity or authority of the underlying object.

Search needs a stable handle and a small receipt

A bounded implementation would begin with scope. Name search should run only inside the authenticated organisation whose ROAs the user is already entitled to manage. It should define whether the match is exact, prefix-based or substring-based; how case and Unicode are normalised; how empty names and duplicate names behave; and whether a renamed record remains discoverable through an audit history.

Results should always return a stable ROA handle alongside the label, Origin AS, prefix, maximum length and state. Modification or deletion should require confirmation against that handle and the network coordinates, not against the mutable name alone. A label is an index. The handle is the durable reference. The prefix and ASN remain the substance of the authorisation.

Pagination and snapshot behaviour also deserve definition. A search result can become unsafe if page two is calculated after the inventory changes, or if a name edit silently swaps which object appears under a familiar label. A minimal query receipt could record the authenticated organisation scope, a digest of the normalised query rather than the sensitive query text, the match mode, snapshot time, result count, returned stable handles and next-page cursor. It need not publish any label.

Such a receipt would make the feature testable without turning it into surveillance. ARIN could show that a given query was evaluated under a known rule against a known inventory state. An operator could show which stable objects were presented before a consequential edit. Neither party would need to expose a client or project name to the public.

The point of ACSP 2024.14 is therefore larger than an extra search box and smaller than a routing-security reform. It asks whether an input field has a complete operational life. ARIN already accepts the name and returns it. The remaining question is whether the normal management surface will let the authorised person retrieve by it under rules precise enough to trust.

Sources