When a Valid ROA Still Leaves a Hole

A Route Origin Authorization (ROA) with a permissive maxLength can leave unannounced sub-prefixes exposed to forged-origin BGP hijacks even when your aggregate route shows RPKI-valid. Because BGP prefers the most specific prefix, an attacker who announces a longer prefix inside your ROA's permitted range and appends your authorized origin ASN to the AS path can pass Route Origin Validation (ROV) everywhere.

Publishing a ROA is a major step forward for BYOIP and routing security, but "Valid" is only as tight as the prefix lengths you authorize. Understanding how covering ROAs interact with longest-prefix match explains why RFC 9319 recommends minimal-length ROAs.

How a loose maxLength creates a forged-origin opening

Suppose your organization holds 198.51.100.0/22 (four contiguous /24 blocks) and originates only the single 198.51.100.0/22 aggregate from AS64496. When creating the ROA, an operator sets maxLength: 24 "just in case" the team later splits the block into /24 announcements.

That single setting changes what validating routers accept across the Internet:

Route Origin Validation (RFC 6811) checks only two things against the covering ROA: whether the rightmost ASN in the AS_PATH matches the ROA's origin ASN, and whether the announced prefix length is less than or equal to maxLength. It does not verify that AS64496 actually sent the announcement to AS64511.

When the ROA permits /24 and the legitimate holder only announces /22, no legitimate /24 route exists in global routing tables to compete with the forged /24. Every network on the Internet prefers a valid /24 over a valid /22.

What recent incidents and measurements show

This is not a purely theoretical edge case. In the August 2026 BGP hijack affecting Virtualizor's infrastructure, routing analysis showed an unauthorized more-specific route announced with the legitimate origin ASN appended to the AS path while a covering ROA permitted the longer prefix. Because both the origin ASN and prefix length satisfied the ROA, Origin Validation alone could not reject the route.

Subsequent IPinfo research on a 28 September 2026 routing sample (using routes visible from at least two public-collector peers) found that 16.2% of RPKI-covered IPv4 routes had a covering authorization that permitted longer prefixes without an operator-announced more-specific route filling that space. That 16.2% figure measures structural exposure rather than a count of active attacks, and it shows how often operators over-provision maxLength.

Minimal-length ROAs vs cloud BYOIP requirements

IETF operational guidance in RFC 9319 (Section 5) is direct: avoid using maxLength wider than the prefix itself unless every permitted sub-prefix is actually announced, and instead publish discrete ROAs for the exact prefixes in your routing plan.

When onboarding a prefix to a cloud BYOIP platform, check how the platform's control plane validates and subdivides your block:

• Single aggregate announcement: If you import a /22 or /24 and announce it only as that single block, set maxLength equal to the prefix length (/22 for a /22, /24 for a /24).
• Google Cloud Standard Tier: Google's documentation explicitly recommends publishing separate exact-length ROAs for the public advertised prefix and for each delegated sub-prefix you provision, rather than one wide covering ROA, when you want the tightest authorization scope.
• AWS VPC IPAM: AWS IPAM requires maxLength to allow /24 for IPv4 (and /48 for IPv6) on advertisable pools so you can allocate regional CIDRs. When a platform requires a wider maxLength, pair your ROA with BGP monitoring for unexpected sub-prefixes and path validation controls such as ASPA.

Step-by-step process for tightening permissive ROAs

Never delete an existing ROA before its replacement has propagated to relying-party caches, or your live routes will briefly evaluate as NotFound or Invalid. Follow this make-before-break process.

FAQ

Related resources