Summary

  • A ROA’s maxLength says how specific an authorized origin may be; it does not say which more-specific routes the operator intends to announce.
  • Exact authorization can make an unprepared emergency deaggregation Invalid, while a loose authorization can make an unplanned more-specific appear Valid.
  • The useful control is an origin-intent register that joins each prefix to its purpose, ASN, activation window, ROA change, observation, withdrawal owner and rollback deadline.

At 09:00 a network originates its normal aggregate, 203.0.0.0/16, from AS 64496. Its ROA authorizes that exact prefix. At 09:12 an incident team announces 203.0.113.0/24 to steer a service through a mitigation provider. The BGP change is deliberate, but the authorization was not staged. Networks performing route-origin validation can now classify the /24 as Invalid because it is more specific than the ROA permits.

The tempting repair is to replace the exact authorization with 203.0.0.0/16, maxLength 24. The immediate /24 can then validate. So can every other /24 beneath the /16 when originated by the named AS—256 possible /24 blocks, whether or not the operator has approved, configured or monitored them. One operational mistake has been answered with a much larger cryptographic permission.

RFC 9582 makes the semantics narrow and precise. A ROA identifies an AS that may originate listed address prefixes. When maxLength is present, it sets the longest covered prefix that the AS is authorized to originate. When it is absent, only the listed prefix length is authorized. The field does not encode a traffic-engineering plan, incident ticket, customer instruction, change window or withdrawal time.

That distinction matters because route-origin validation asks a limited question. RFC 6811 relates a received route to covering validated ROA payloads, the origin AS and the authorized maximum length. The result can be Valid, Invalid or NotFound. A Valid result does not prove that the route was requested, that its path is legitimate, that packets reach the intended service or that the announcement should remain active.

Minimal authorization keeps intent legible

RFC 9319 recommends minimal ROAs whenever possible: authorize prefixes actually originated in BGP and no others. It generally advises against maxLength, while allowing that some specific operating cases may justify it. The point is not that the optional field is defective. The point is that shorthand authorization can silently exceed actual origin intent.

Suppose the /16 is normally announced and only four named /24s are used for regional ingress. Four exact entries disclose that plan. A /16 with maxLength 24 authorizes the same four, but it also covers 252 other /24s at that length. The RPKI can no longer distinguish the intended set from the unused set. A forged-origin route that places the authorized AS at the end of a false path may exploit an unused authorized more-specific; origin validation does not authenticate the whole AS path.

Exact objects impose a different cost. Every planned new origin must be reflected in the authorization set before or with the BGP change. That demands coordination between address-resource custodians, routing engineers, security teams and any mitigation provider. Yet that coordination is not administrative waste. It is the process that makes a new origin deliberate, attributable and reversible.

Emergency flexibility needs ordering, not standing overbreadth

DDoS mitigation is the hard case. A provider may require a more-specific route, a different origin ASN or a destination-based discard route. RFC 9319 treats these cases explicitly rather than pretending one configuration suits every response. The operator needs the provider’s exact prefix and origin requirements before the incident, plus a tested sequence for changing authorization and announcing the route.

The sequence should have visible checkpoints. Confirm the approved prefix and origin. Create or replace the ROA. Wait until independent validators expose the intended validated payload. Announce the route in a controlled scope. Observe origin-validation state and propagation. Expand only after the route behaves as expected. When the event ends, withdraw the BGP route first, confirm disappearance, then remove a temporary authorization according to the agreed rollback plan.

Ordering cannot eliminate every race. RPKI repositories, validators, routers and BGP propagation operate on different clocks. Nor do the public RFCs establish how any particular network treats Invalid routes. RFC 7115 therefore approaches origin validation as an operational policy deployment: observe effects, understand local exceptions and introduce routing consequences carefully.

Sources