Summary

  • Randy Bush’s RFC 7115 tells an operator to account for sub-allocations announced by other ASes before issuing a ROA for the covering super-block. Customer routes lacking their own correct ROAs can then validate as Invalid.
  • The warning sits in an operational chain: validated ROA data reaches routers through caches, routers classify origins, and each network applies its own routing policy. Bush also recommends redundant caches and timely synchronization.

The parent block has customers downstairs

Imagine the holder of a large address block finishing a respectable security chore: publish a Route Origin Authorization, or ROA, for the whole block. Somewhere inside it, a customer announces a smaller allocation from its own AS. The parent’s new signature reaches an RPKI cache, then a router. The customer route is still there. Its validation label can now read Invalid. The switch was thrown by the party upstairs.

Randy Bush puts this exact preflight in RFC 7115, his January 2014 Best Current Practice guide to operating RPKI-based origin validation. Before a ROA covers a super-block, the document requires the operator to make sure sub-allocations announced by other ASes, including customers, have correct ROAs. Otherwise those announcements with no matching customer ROAs will be classified Invalid. Bush even offers a bridge for the awkward interval: use live BGP data to populate ROAs as a proxy while recipients register their own. The practical instruction is brisk: count the tenants before locking the front door.

The label comes from a particular calculation. RFC 6811 describes origin validation as a comparison among the announced prefix, the origin AS and validated ROA data. The result is Valid, NotFound or Invalid. A covering ROA can change a more specific customer announcement from the absence of authorisation data to a conflicting one when its origin or permitted length does not match. An operator then uses that state in local routing policy. A network that rejects Invalid routes gives the upstream paperwork immediate operational weight.

Bush’s warning reaches past the ROA form. RFC 6810, which Bush wrote with Rob Austein, defines the cache-to-router protocol that delivers validated origin data. RFC 7115 recommends more than one cache for a router, including a local one; it also says local caches used for routing decisions should synchronize with one another at least every four to six hours. A recipient using an upstream’s cache should re-validate what it receives. Signatures, cache freshness and router policy all sit between the parent’s action and the customer’s route.

The RIPE NCC biography of Randy Bush describes decades of work on routing security, including RPKI and Route Origin Validation design. That history explains the tone of his RFC: it spends as much energy on the operator’s sequence as on the cryptography. The named RIPE NCC headshot grounds this article’s editorial portrait; the two router cabinets behind him are imagined.

The surprisingly human object in this technical story is the customer allocation list. It must be complete enough to catch every smaller block announced by another AS before the parent ROA goes live. One missed line can alter a validation result at routers that have never heard the customer’s name. Bush made that line item a control, not a courtesy.