Summary

  • A query for 190.147.255.0 returned the parent block 190.144.0.0/14 and two aut-num values, AS14080 and AS10620. That is a useful projection, not a live route observation.
  • The contemporaneous RPKI evidence contained four covering VRPs, while RIPE RIS observed AS10620 as the origin of 190.147.255.0/24; that particular route was ROV Valid. An origin-projection receipt would keep those states separate and reproducible.

A field that improved, and a question it opened

LACNIC policy section 3.4 is unusually direct. When the information is available, LACNIC is to include the origin ASN of queried prefixes in WHOIS responses. The text added by implemented proposal LAC-2021-1 also says the origin ASN may be extracted from the RPKI repository, taking the origin named in a ROA.

That change removed a maintenance problem described in the proposal: a member-supplied descriptive value could drift away from an updated ROA. It also changed the nature of the field. Once a WHOIS answer can be projected from RPKI, the reader is no longer looking only at a registration attribute. The reader is looking at a compact view of a time-dependent authorization set.

Compact views can be perfectly accurate and still need a boundary. The key question is not whether the displayed ASN looks plausible. It is whether another operator can reconstruct which authorizations made it appear.

One query, two ASNs and four authorizations

At 21:59:47 UTC on 19 September 2026, a direct query to whois.lacnic.net for 190.147.255.0 returned the allocated parent object 190.144.0.0/14. The response contained two lines:

  • aut-num: AS14080
  • aut-num: AS10620

The response therefore did not collapse this case to one origin. That matters. It would be wrong to describe current LACNIC behavior as necessarily selecting a single ASN, and equally wrong to treat the first line as the unique authorized origin.

Seven minutes earlier, LACNIC’s Routinator view for the routed prefix 190.147.255.0/24 exposed the larger structure behind those two values. Its generated-at time was 21:52:52 UTC, and it contained four covering Validated ROA Payloads:

VRP prefix maxLength Authorized origin
190.147.0.0/16 24 AS10620
190.147.0.0/16 24 AS14080
190.144.0.0/14 24 AS10620
190.144.0.0/14 24 AS14080

Each row also had its own ROA object URI and validity interval. None of those prefix, maxLength, source-object or snapshot details appeared beside the WHOIS aut-num lines.

This is not evidence that the WHOIS answer was wrong. The two displayed ASNs were compatible with the two authorized origins in the covering set. The limitation is explanatory: the flat list did not say that both a /16 and a /14 covered the queried /24, that both permitted more-specifics through /24, or that two different ROAs were required to authorize the two origins.

Authorization is not observation

RPKI origin validation needs a route as well as a VRP set. RFC 6811 describes a VRP with a prefix, a maximum length and an origin ASN. A route is Valid if at least one covering VRP also matches the route length and origin. RFC 9582 makes the multiple-origin case explicit at the object layer: one ROA identifies one authorized AS, so authorizing multiple ASes requires multiple ROAs.

The live BGP snapshot supplied the missing route side of the comparison. A RIPEstat BGP-state response captured at 21:59 UTC contained 327 observed paths for 190.147.255.0/24. Every path ended in AS10620. For that observed route, the two AS10620 VRPs matched; the two AS14080 VRPs still covered the prefix but did not match its origin. LACNIC Routinator therefore returned Valid.

If the same /24 had instead been observed with AS14080 at the origin, the same snapshot would also have returned Valid: the matched and unmatched-AS groups would simply reverse. That does not mean both ASNs originated the route at the captured time. It means both were authorized possibilities, while only AS10620 was observed in that RIPE RIS snapshot.

The distinction can be stated cleanly:

  1. WHOIS displayed two ASN values on a registration object.
  2. The validator held four covering prefix/maxLength/ASN tuples.
  3. The route collectors observed one origin for one /24 at one time.
  4. ROV compared that route with the complete VRP set and produced Valid.

Skipping any line changes the meaning of the next one.

The missing object is a projection receipt

WHOIS does not need to become a route monitor. Nor does LACNIC need to publish an operator’s routing decision. A small evidence receipt beside the projection would be enough.

For each query, the receipt should identify the queried address or normalized prefix, the registration object returned, and the rule used to select covering RPKI authorizations. It should then list every contributing tuple: VRP prefix, maxLength and origin ASN. It should bind that set to the validator and generated-at time, a cache session or comparable snapshot identity, and a digest of the authorization set. Where practical, it should include a stable ROA object URI or digest.

The state also needs a type. An answer can be empty, single, multiple, partial or stale. A next-refresh expectation or expiry prevents a value from acquiring an indefinite life after its source authorization changes. A supersession reference lets a later receipt replace the earlier one without rewriting history.

Finally, the receipt should say what it is not: it is not a BGP observation, not proof that every authorized ASN is currently announcing, not a route preference, and not an instruction to accept traffic. Actual route origin and the resulting ROV state belong in a separate comparison.

A receipt makes a good projection safer to use

LACNIC’s present answer already demonstrates an important strength: it can show more than one origin ASN. The next improvement is not to choose one of them. It is to preserve the evidence that made the plural answer correct.

For the tested prefix, the result can be reconstructed only by combining three services: WHOIS for the projected values, Routinator for the covering authorizations, and a route collector for the observed origin. An origin-projection receipt would not eliminate those systems. It would give them a shared join key and time boundary.

That is the difference between a helpful field and an auditable statement. The field says AS14080 and AS10620. The receipt explains the two covering prefix levels, the common maxLength 24, the snapshot that contained them, and the rule that produced the list. The route evidence then says which ASN actually appeared, and ROV says whether that route matched at least one authorization. Each layer remains useful precisely because none is asked to impersonate the others.

Sources