Summary

  • RFC 9582 requires the ROA end-entity certificate to contain the authorized IP resources, forbids inherit, and requires the AS Identifier Delegation extension to be absent.
  • The origin AS number is the signed payload's asID. A valid ROA therefore proves a bounded authorization from address-space authority, not the identity of the AS operator, a live route or non-repudiation.
  • Object validation, VRP derivation, route observation, router receipt, local policy, path selection and packet delivery need separate receipts.

The missing extension was not missing evidence

Imagine a certificate inspector showing a green path, the expected prefix and no AS-resource extension. A reviewer calls the object incomplete: how can it authorize AS 65536 if the certificate does not certify AS 65536?

RFC 9582 answers by making the absence mandatory. The end-entity certificate inside a ROA must contain an RFC 3779 IP Address Delegation extension. Every prefix in the payload must fall within that set, and the extension must not contain inherit. But the RFC 3779 Autonomous System Identifier Delegation extension is not used for ROAs and must not be present.

The AS number is elsewhere. The signed RouteOriginAttestation payload carries one asID and one or two address-family blocks. The certificate establishes the signer's right over the address space. The signed payload records which AS that authority permits to originate the listed prefixes. Adding the AS extension would not complete the intended proof; it would violate the profile.

That design prevents a seductive category error. Certificate validity is not a certificate of the AS operator's identity. RFC 9582 says the RPKI used for ROA validation provides authorization, not explicit authentication, and the signed object is not intended to convey non-repudiation.

One object, one AS, several bounded prefixes

A ROA authorizes a single AS. When the same address holder wants two ASes to originate the same prefixes, it issues two ROAs. This matters in incident response: merging those grants into a dashboard row may be convenient, but it erases which signed object supplied which authority.

Inside each address-family block, every entry contains a prefix and may contain maxLength. With no maxLength, the grant covers only the exact prefix. With one, the AS may originate more-specifics no longer than that value. A /24 with maxLength 26 covers the /24, its /25s and /26s, but not a /27.

RFC 9319 explains why this shorthand deserves restraint. A broad maxLength can authorize routes the holder never meant to originate. Yet that operational concern is separate from the central identity boundary. Narrow or broad, the field describes the scope of a routing authorization. It does not say who controls the AS, whether the route exists or whether traffic is safe.

Canonical form removes ambiguity, not uncertainty

ASN.1 permits more than one encoding of semantically equivalent address information. RFC 9582 therefore maps every entry to four integers—address family, first address, prefix length and effective maximum length—and specifies an ascending order. Identical tuples are duplicates. Certification authorities are told to expect relying parties to become stricter about canonical form.

This gives implementations a stable comparison surface. It does not turn canonical bytes into current network state. A perfectly sorted object may be stale at a repository, absent from a validator, delayed on a cache-to-router session or superseded after a router's last update. Conversely, an operational disagreement may originate outside object encoding entirely.

The order of proof matters. First validate the RPKI signed object under RFC 6488. Then apply the ROA-specific checks: resource containment, no inherit, no AS extension and conforming content. Any failure invalidates the entire ROA. Only a valid object can produce a validated ROA payload, or VRP, for comparison with a route.

The route is a second object

RFC 6811 compares a received route against VRPs. The route contributes a prefix, prefix length and origin AS. The validator-derived data contributes authorized prefixes, maximum lengths and AS numbers. Their comparison yields Valid, Invalid or NotFound.

Those labels do not flow backward. A Valid route does not authenticate the organisation behind the AS. An Invalid route does not prove malice, and NotFound is not the same as invalidity. The result is path- and time-dependent because repositories, validators, router sessions and observed BGP views can differ.

It also does not flow automatically into forwarding. RFC 8210 covers delivery of validated cache data to routers. RFC 7115 and RFC 8893 place import and export behavior in local policy. A router can receive a VRP, compute an origin-validation state, prefer or reject a route, select another path, or retain an exception. Each step needs its own record.

A green ROA ends earlier than most dashboards admit

The strongest faithful statement is precise: at a stated time, under a stated trust anchor and repository/validator snapshot, a particular signed object passed the applicable profile and authorized one AS number to originate a defined prefix set.

It does not say that the AS originated anything. It does not say a particular router received the VRP. It does not say local policy rejected alternatives, that the route won best-path selection, that other networks propagated it, that packets reached the prefix or that an application answered.

Heng Lu's running-code discipline makes this boundary practical. The shared specification defines the smallest interoperable assertion. Operators keep authority over local policy and must observe the executing system. Reality layers remain separate: registry and cryptographic symbols can constrain a decision without becoming the route, the packet or the service.

Sources