Summary

  • A ROA authorizes one AS to originate specified prefixes. Its optional maxLength can extend that authorization to a set of more-specific prefixes, but it does not describe which members of that set are actually intended for announcement.
  • RPKI origin validation compares a received route with validated prefix, maximum-length and origin-AS data. A Valid result is evidence that the route fits an authorization; it is not evidence of traffic-engineering intent, reachability or local preference.
  • Operators can reduce ambiguity and forged-origin exposure by using minimal ROAs where possible and by reconciling the authorized set with observed BGP and a versioned policy record whenever origination policy changes.

The crucial distinction is between a permitted set and an operating plan. RFC 9582 defines a Route Origin Authorization as a signed object through which an address-block holder authorizes an autonomous system to originate routes to one or more prefixes. Each ROA names one AS. If several ASes need authorization for the same address space, the holder issues separate ROAs.

Within each prefix entry, maxLength is optional. If it is absent, only the exact prefix is authorized. If it is present, the named AS may also originate covered more-specifics down to that length. A /20 with maxLength /24, for example, describes a potentially large authorization set. It does not contain a schedule of which /21, /22, /23 or /24 routes should appear, which sites should announce them, or under what network conditions.

That missing information is not a flaw in the ROA format. It is outside the object’s purpose. A ROA answers whether the address holder has granted origin authority within a defined prefix envelope. Traffic engineering answers different questions: which routes an operator will originate, where they will be exported, which attributes will accompany them, how failover changes the set, and when a temporary more-specific should be withdrawn.

RFC 6811 makes the validation boundary concrete. A router or validation system works with validated ROA payloads containing a prefix, prefix length, maximum length and origin AS. A received route can be Valid when its origin AS matches and its prefix length is admitted by a covering payload. It can be Invalid when a covering authorization exists but none matches the origin and length. It is NotFound when no validated payload covers it. These states classify the received route against available authorization data; they do not reconstruct the operator’s private change ticket or routing intent.

This is why a Valid more-specific can still deserve operational scrutiny. The validation result may be completely correct while the route is unexpected. A stale configuration, an unintended export, a forgotten mitigation announcement or a compromised device could all produce an announcement that remains inside a broad authorized envelope. The RFCs cited here do not establish that any such event occurred; they show why authorization alone cannot exclude those possibilities.

RFC 9319 approaches the same boundary through risk reduction. It recommends minimal ROAs: authorizations limited, where possible, to prefixes actually originated in BGP. It generally recommends avoiding maxLength because the shorthand often authorizes more-specifics that are not being announced, thereby enlarging the set available to a forged-origin attacker using the authorized AS number. The document allows limited exceptions, including cases where all admitted more-specifics are actually announced, but it makes operator judgement and repeated review part of the discipline.

Minimality is therefore not a one-time encoding preference. The authorized set and the operating set can drift. A new anycast site may require more-specific announcements. A DDoS mitigation arrangement may temporarily alter origination. A consolidation may retire them. RFC 9319 requires review of existing objects and repetition of that review when origination or routing policy changes. The practical control is a reconciliation process, not faith in an old maxLength value.

A useful evidence ledger preserves at least three planes. The authorization plane records each ROA’s prefix, origin AS, maxLength, certificate lineage and validity interval. The observation plane records which prefixes and origins were actually seen, where they were observed and when. The policy plane records the approved announcement set, its purpose, change owner, effective interval and withdrawal condition. Joining the three allows an operator to ask whether every observed route is authorized, whether every authorized more-specific is still needed, and whether every planned route is visible where expected.

Time matters throughout that join. A route observed at 10:00 should not be explained using only a ROA fetched later or a policy document revised after the event. Validation caches may not all hold identical data at the same instant, and BGP visibility depends on vantage point. Each row needs its own observation or effective time so that a later “Valid” state does not overwrite the evidence available when a route was accepted.

The same restraint applies to identity claims. RFC 9582 says RPKI validation establishes authorization through the resource PKI; it is not identity authentication or non-repudiation. A signed ROA supports a specific authorization conclusion. It does not reveal who within an organization approved a traffic-engineering change, whether the current NOC recognizes it, or whether a third party’s operational description is accurate.

The resulting rule is simple: do not read maxLength as compressed intent. It is a boundary on origin authorization. Operational assurance comes from comparing that boundary with current, time-stamped route observations and an independently maintained policy record.

Sources