The Maxlength Trap: How Generous ROA Scoping Enables Prefix Hijacking

RPKI (Resource Public Key Infrastructure) prevents BGP route hijacking by binding IP prefixes cryptographically to their authorized Autonomous System Numbers (ASNs). The Route Origin Authorization (ROA), a certificate specifying which ASN can announce a particular prefix, is central to this system. Despite RPKI's security promise, misconfiguration is common. One of the most dangerous mistakes is careless use of maxLength values in ROAs.

The maxLength field specifies which prefix can be announced and which more-specific subnets from that prefix are also authorized. When an organization sets this value too generously, it creates an attack surface. Malicious actors can announce unauthorized more-specific prefixes from wrong ASNs, hijacking portions of the organization's address space.

Understanding ROAs and Maxlength

A Route Origin Authorization (ROA) has three components:

1. ASN — The autonomous system authorized to announce the prefix
2. Prefix — The IP address block covered by the authorization
3. maxLength — The maximum prefix length (specificity) that may be announced

A ROA might specify:

ROA: AS65001 may announce 203.0.113.0/24 with maxLength 26

AS65001 can then announce:

• 203.0.113.0/24 itself
• 203.0.113.0/25, 203.0.113.128/25
• 203.0.113.0/26, 203.0.113.64/26, 203.0.113.128/26, 203.0.113.192/26

And any more-specific subnets down to /26.

maxLength is meant to allow operational flexibility. Organizations can subnet their allocations without creating new ROAs for each subnet. Set carelessly, it creates a permissions boundary far wider than the organization's actual control.

The Misconfiguration: How It Happens

Three scenarios typically lead to maxLength problems:

Scenario 1: Copy-Paste from Documentation
Administrators follow outdated guides using permissive maxLength values (32 for IPv4, 128 for IPv6) and never adjust them to match their subnetting strategy.

Scenario 2: Future-Proofing Gone Wrong
An organization anticipates possible future subdivisions and sets maxLength higher than their current delegation strategy requires, creating years of unnecessary over-authorization.

Scenario 3: Misunderstanding Prefix Semantics
Some operators confuse the prefix with authorization boundaries. They think a /24 ROA only affects /24-sized blocks, missing that maxLength extends authorization to all more-specific subnets.

Consider this: An organization holds AS65001 with 203.0.113.0/20. They create one ROA with maxLength 32 to "cover everything." This ROA now authorizes AS65001 to announce any subnet from /21 to /32 within that /20. If they actually only need to delegate /24-sized blocks internally, this authorizes 256 times more subnets than necessary.

Attack Scenario: Exploitation in the Wild

An attacker spotting an overly broad ROA can exploit it through prefix hijacking:

Step 1: Intelligence Gathering
The attacker scans publicly available RPKI repositories (accessible via RPKI validators) and identifies organizations with high maxLength values.

Step 2: BGP Announcement
The attacker, controlling their own ASN or compromised infrastructure, announces a highly specific subnet within the over-authorized range. For example:

Announce 203.0.113.42.0/24 AS65099

This /24 falls within 203.0.113.0/20 and within the maxLength authorization. RPKI validation passes.

Step 3: Traffic Hijacking
BGP's longest-prefix-match routing prefers the attacker's more-specific /24. Internet traffic for 203.0.113.42.0/24 now flows to the attacker's network.

Step 4: Monitoring Blind Spot
Most organizations don't actively monitor which more-specific subnets others announce under their prefixes. They verify they can announce their main blocks but miss unauthorized more-specifics.

The Cost: Real-World Impact

The consequences go beyond theory:

• Traffic Interception: Attackers redirect production traffic, enabling man-in-the-middle attacks, data theft, or service disruption.
• Reputational Damage: Users experience outages. DNS queries, CDN connections, or critical services become unreachable.
• Regulatory Liability: Organizations may face liability for weak BGP security, especially in regulated sectors like finance and telecommunications.
• Incident Response Cost: Remediating a hijack requires coordination with upstream ISPs, investigation, and post-mortem analysis.

A one-hour hijack of a /24 at a large organization can affect millions of users and cost hundreds of thousands in lost revenue and remediation.

Detection and Monitoring: Catching the Misconfiguration

CompliSight identifies this vulnerability through several mechanisms:

1. ROA Auditing
Automated analysis flags maxLength values exceeding documented delegation requirements. A report shows:

Organization: ExampleCorp
Prefix: 203.0.113.0/20
Current maxLength: 32
Recommended maxLength: 26 (based on /24 delegation strategy)
Excess Authorization: 64x more-specific subnets
Risk Level: HIGH

2. Announcement Monitoring
Continuous monitoring of BGP announcements shows which more-specific subnets are actually announced. If a /28 is announced but ROA authorization extends to /32, the gap is logged.

3. Anomaly Detection
Machine learning flags unusual patterns: sudden appearance of previously unadvertised more-specifics, announcements from unexpected ASNs, or announcements outside known delegation patterns.

4. Comparative Analysis
Comparing ROA scoping against actual subnet allocation in DNS or internal routing reveals misalignment. If your documentation shows /24 subdivisions but ROAs permit /32, the discrepancy signals risk.

Mitigation: Practical Implementation Steps

Step 1: Audit Existing ROAs
Review all ROAs in your organization. For each, determine the maximum specificity you actually need:

Prefix: 203.0.113.0/20
Current Subnetting: /24 allocations to 10 regional offices
Required maxLength: 24 (not 32)
Action: Update ROA

Step 2: Implement Least-Privilege Authorization
Set maxLength to the actual maximum specificity required:

# Overly generous (WRONG)
ROA: AS65001 authorizes 203.0.113.0/20 maxLength 32

# Least-privilege (CORRECT)
ROA: AS65001 authorizes 203.0.113.0/20 maxLength 24

For sub-allocations to different ASNs, create separate ROAs:

ROA 1: AS65001 authorizes 203.0.113.0/22 maxLength 24
ROA 2: AS65002 authorizes 203.0.113.4.0/22 maxLength 24

Step 3: Document Your Subnetting Strategy
Write down your delegation hierarchy. This is your source of truth for setting maxLength.

Step 4: Implement Announcement Filtering
Configure routers to reject more-specific announcements beyond your documented allocation, regardless of RPKI validity:

route-policy RPKI-FILTER
  if (prefix is-within-range 203.0.113.0/20) and 
     (prefix length > 24) then
    drop
  else
    pass
  endif
end-policy

Step 5: Continuous Monitoring
Alert on:

• ROAs with unnecessarily high maxLength values
• BGP announcements with unexpected specificity
• Announcements from unauthorized ASNs (even if RPKI-valid)

Key Takeaways

1. maxLength is a permission boundary, not an operational target. Set it to your actual subdivision needs, not as a future-proofing blanket.

2. Overly broad ROAs create attack surface proportional to the authorization gap. Each additional prefix length multiplies hijack vectors.

3. Align your ROAs with documented delegation strategy. If your documentation shows /24 subnets but ROAs permit /32, fix the configuration.

4. Detection needs both RPKI validation and BGP announcement monitoring. RPKI alone won't stop a valid-but-unauthorized announcement. You need to watch what's actually announced.

5. Prefer multiple ROAs with tight maxLength to one permissive ROA. Operational complexity is negligible against the security benefit.

Organizations with overly broad ROAs often seem fine. They announce their prefixes without issue, ROAs validate, nothing breaks. But the misconfiguration is a vulnerability waiting to be found. Attackers actively scan for this mistake. Audit your ROAs and keep maxLength conservative.