MANRS Wants a ROA for Every Route. Legacy Networks Test the Rule

Summary

At RIPE 93, Andrei Robachevsky described a working-group proposal that would make Route Origin Validation a MUST and require a valid ROA for every prefix a MANRS participant announces.
Some networks cannot issue that proof on their own: uncontracted legacy holders in ARIN lack access to ARIN RPKI, while operators may announce customer-held prefixes whose owners have not created ROAs.

Analysis

The word “every” is the whole argument. A route-security baseline can ask operators to filter, coordinate and publish routing information. A rule that demands a valid Route Origin Authorization for every announced prefix asks a harder question: does the operator control the resource record needed to produce that proof?

At RIPE 93 on 27 October, Andrei Robachevsky laid out a proposal from the MANRS Network Operators Program Review Working Group. The group wanted to make its requirements easier to interpret and audit. It had split the material into a requirements document and implementation guidance, using IETF-style MUST and MUST NOT language. In the version he described, ROV would be a MUST and IRR registration a SHOULD. For routing information, the group had discussed 100% RPKI coverage: each prefix a participant announces should have a valid ROA.

Those were proposals under review, not revised MANRS rules. Robachevsky said the group expected an internal last call, then a wider community call for comments. The second round mattered because the target was consensus beyond the working group and current participants. The official RIPE transcript records both the requirements and the open questions.

MANRS has reason to sharpen its wording. Its March survey reported 38 responses, mostly from network operators, with priorities around clearer requirements and stronger auditability. Half of respondents ranked the Network Operators Program first for review. The results argue for precision; they do not supply a vote from every operator. The published page gives no number invited, so readers cannot calculate a response rate.

The RPKI gap is concrete. ARIN says legacy resource holders without an ARIN agreement cannot use its RPKI or IRR services. A holder who enters an agreement can. ARIN also says a ROA can be created only for resources covered by the holder’s resource certificate. A network operator that announces someone else’s prefix cannot simply sign the owner’s authorization from its own account.

Robachevsky named this problem directly: some legacy holders in ARIN lack access to RPKI, and operators may originate customer-leased prefixes whose customers have not made ROAs. The operator carries the route in BGP; the customer or resource holder may control the registry action. The compliance label lands on the operator even when another party controls the missing step.

IRR remains part of the proposed picture. Robachevsky described it as a SHOULD while RPKI coverage moved toward a MUST. That split reflects actual transition paths: some networks still use IRR, and the review had not settled which registries or object sets should count. Treating an IRR entry as a universal substitute would erase the group’s stated distinction. Ignoring IRR would erase how operators currently build filters and describe routes.

MANRS began with nine operators in 2014; Robachevsky said it had grown to about 1,400 by the time of the talk. Its value, he argued, comes from broad adoption of a minimum baseline, not from a tiny club meeting the toughest possible test. A perfect-looking scorecard that excludes networks stuck behind a resource-control boundary can leave the route system with cleaner paperwork and less coverage.

The rule’s credibility therefore depends on the path to compliance. A participant needs to know which announcements require ROAs, who must create them, what happens when the resource holder controls the registry, and how long an existing member has to close the gap. Without those answers, “100%” is a target that moves responsibility around without making the underlying authorization appear.