RPKI validation: Fix maxLength to prevent leaks

RPKI adoption is increasing as of 2026, driving urgent needs for route origin validation durability. You will learn the specific mechanics of ROA objects, including how the maxLength attribute controls prefix deaggregation to prevent unauthorized announcements. Finally, we address strategic ROA deployment, highlighting why conservative use of length attributes is critical to avoiding security gaps that mimic the failures of the legacy IRR.

The transition from basic origin checks to reliable autonomous system authorization requires more than just enabling features on substantial router platforms. It demands a clear understanding of how resource certificates bind IP blocks to specific AS numbers through signed statements. Unlike the legacy Internet Routing Registry, this system offers verifiable proof of authority that is operationally viable today.

However, the devil lies in the details of RFC 6482 specifications regarding prefix lengths. Operators must navigate the trade-offs between flexibility and security when defining maxLength values. Liberal settings can inadvertently authorize forged origins, whereas precise, multi-ROA strategies offer tighter control. By mastering these configurations, network engineers can ensure their BGP infrastructure resists hijacking attempts effectively.

The Role of RPKI in Modern BGP Security Architecture

RPKI Architecture: X.509 Certificates and Trust Anchor Hierarchy

The framework secures BGP by extending standard X.509 certificates with IP address fields set in RFC 3779. This extension transforms the existing website authentication standard into a specialized tool for verifying network resource ownership. Operators replace trust-based filtering with cryptographic proofs that bind IP prefixes to specific Autonomous System numbers.

Global stability relies on a hierarchy where Regional Internet Registries function as root Trust Anchors. These entities-AFRINIC, APNIC, ARIN, LACNIC, and RIPE-sign certificates for their members, creating a chain that mirrors the official IP allocation hierarchy. Local Internet Registries subsequently delegate authority to end users who sign Route Origin Authorizations. This structure ensures that validation decisions reflect the actual distribution of internet number resources rather than arbitrary policy claims.

A significant architectural tension exists between this rigid hierarchy and the flexible nature of modern multi-homing strategies. The system effectively prevents origin hijacks but requires precise configuration to align announcement policies with the delegation model. Liberal usage of maxLength in ROAs opens networks to forged origin attacks, necessitating that ROAs match prefixes as announced in BGP to maintain security posture.

Operationalizing Route Origin Validation via RTR Protocol

Route Origin Validation prevents BGP route hijacking by cryptographically verifying prefix announcements against ROAs. This mechanism mimics IRR route objects but operates in a more trustworthy manner through cryptographic proofs.

Operators deploy a local validator that fetches Route Origin Authorizations and compiles them into Validated ROA Payloads. The validator pushes this dataset to border routers using the RPKI-to-Router protocol, establishing a strict separation between the validation plane and the forwarding plane. Routers subsequently tag incoming BGP UPDATE messages as Valid, Invalid, or NotFound based on the received VRP list. This architecture blocks unauthorized origin announcements yet relies entirely on the accuracy of the published ROA maxLength attributes. Overly permissive length values in the original authorization can inadvertently validate specific prefix hijacks.

RFC 6811 describes the possible statuses when comparing VRPs to route announcements: Valid (covered by a VRP), Invalid (unauthorized AS or too specific), and NotFound (not covered). As adoption increases, continuous measurement of validation durability becomes necessary for maintaining stable peering relationships. The shift from manual filtering to automated cryptographic enforcement reduces operational overhead but demands rigorous ROA management to avoid self-inflicted outages. RPKI adoption is explicitly stated to be increasing as of 2026, driving the need for continuous measurement of Route Origin Authorization objects and validation states.

Origin Validation vs Path Validation in BGP Security

Origin validation is the sole RPKI function currently operational across global networks. This mechanism verifies that an Autonomous System holds authority to announce a specific IP prefix, effectively preventing unauthorized origin claims. All substantial router vendors have implemented ROV in their platforms, enabling operators to filter routes based on cryptographic proof rather than manual lists. In contrast, path validation secures the entire AS sequence traversed by traffic, a capability standardized in RFC 8205 but limited in real-world deployment. Standard BGP secures path selection logic but fails to authenticate the source of routing updates without these extensions. Origin validation addresses accidental misconfigurations and basic hijacks while leaving the AS path vulnerable to manipulation by intermediate actors. The distinction matters because widespread adoption of origin checks does not guarantee protection against sophisticated path tampering. Origin validation serves as a stepping stone while path validation remains a future objective documented in IETF.

Operators must recognize that current infrastructure relies heavily on this partial mitigation. Relying solely on origin checks leaves a gap where valid origins can still propagate fraudulent paths.

Inside the Cryptographic Mechanics of ROAs and VRPs

ROA Structure: Signed Statements Linking IP Blocks to AS Numbers

A Route Origin Authorization functions as a digitally signed object that authorizes specific Autonomous Systems to originate routes for IP prefixes. This cryptographic object links address space to an AS number through a statement created solely by the legitimate holder of the block. RPKI uses X.509 certificates extended with specific fields for IP addresses and AS identifiers (RFC 3779) to create Route Origin Authorizations (ROAs). The creation process relies on the resource certificate associated with the IP addresses, remaining entirely independent of the certificate holder's own AS identity. Consequently, a resource holder may authorize any external AS to originate their prefix, a flexibility necessary for complex hosting arrangements. Once processed by a validator, the data becomes a Validated ROA Payload containing the prefix, origin AS, and maximum length. This transformation enables routers to enforce strict origin policies without manual intervention. The structural separation between resource ownership and origination authority prevents single points of failure in policy management. However, liberal usage of maxLength or imprecise ROAs can open networks to forged origin attacks where malicious actors spoof AS numbers.

Calculating Route Validity: Valid, Invalid, and NotFound Status Logic.

RFC 6811 defines three distinct outcomes when routers compare BGP announcements against Validated ROA Payloads. The Valid status applies when a route announcement prefix equals or is more specific than a VRP entry, confirming authorized origin. An Invalid result triggers if an unauthorized AS originates the prefix or the announcement exceeds the configured maxLength. This status indicates the prefix is announced from an unauthorised AS or is more specific than allowed by the maxLength set in a matching VRP. The NotFound state indicates no matching VRP exists, leaving the route subject to local policy rather than cryptographic rejection.

Routers apply these binary Valid/Invalid assessments to automate filtering decisions previously requiring manual maintenance. Unlike traditional registry checks, this mechanism relies on cryptographically signed data structures rather than trust-based peer relationships. Equinix uses RPKI as part of its prefix validation process, demonstrating how substantial exchanges enforce legitimacy at the network edge. However, widespread deployment reveals that many globally routed prefix-AS pairs remain unprotected by ROAs, creating a mixed environment where NotFound routes dominate. Relying solely on origin validation leaves the AS path vulnerable to manipulation, a gap that future path validation standards aim to close.

ROA vs IRR Route Objects: Authority and Trust Differences

The legitimate holder of IP space uses a resource certificate to issue an authoritative, signed statement defining authorized originators. Unlike traditional routing registries that rely on a model where database entries lack cryptographic verification, RPKI enforces ownership through a strict chain of trust. This fundamental shift replaces manual filtering with automated Route Origin Authentication, ensuring that only the certified resource holder can authorize BGP announcements for their prefixes.

Strategic Configuration of maxLength and Multi-ROA Deployments

MaxLength Constraints in ROA Prefix Authorization

Set in RFC 6482, the maxLength parameter dictates the longest IP address prefix an AS may advertise under a specific authorization. Consider a Route Origin Authorization for 192.0.1.0/24 where the limit is set to /25. The holder can originate the single /24 block or divide it into two adjacent /25 subnets. Any announcement more specific than /25 becomes cryptographically unauthorised. Administrators establish this boundary by setting the maximum prefix length value during ROA creation, frequently employing shorthand notation like 192.0.1.0/24-25 to denote the allowed range. This mechanism grants precise control over deaggregation boundaries that traditional registry objects lack. Broad maxLength ranges expose networks to forged origin attacks on unused sub-prefixes. A malicious actor could hijack a specific slice of space covered by a wide maxLength without triggering an invalid status. Operational flexibility must be balanced against security posture; defining narrow, exact matches reduces the attack surface notably. If a prefix will have only a few sub-prefixes announced, multiple ROAs for specific announcements should be used instead of one ROA with a long maxLength. This approach ensures that only intended subnets remain valid while rejecting unauthorized variations.

Precise definitions prevent attackers from exploiting gaps in coverage.

Strategic Scenarios for Strict versus Lenient maxLength Settings

Conservative maxLength usage helps prevent forged origin attacks where malicious actors spoof AS numbers. This attribute gives the prefix holder control over the level of deaggregation an AS is allowed to do, a feature not present in route objects in RPSL. If a prefix will have only a few sub-prefixes announced, multiple ROAs for specific announcements should be used instead of one ROA with a long maxLength. Liberal usage opens the network to attacks on unannounced sub-blocks that would otherwise remain cryptographically undefined.

Operators must choose between strict single-ROA policies for stable aggregates and flexible multi-ROA configurations for flexible environments. Equinix uses RPKI as part of its MLPE prefix validation process, effectively filtering invalid announcements at the exchange edge. This real-world enforcement means that overly permissive length settings on customer prefixes can inadvertently authorize hijacks of unused address space. The limitation is administrative overhead; maintaining multiple ROAs requires rigorous coordination to avoid accidental invalidation of legitimate traffic during maintenance windows.

ROAs should be as precise as possible, meaning they should match prefixes as announced in BGP. This approach limits the blast radius of potential configuration errors while maintaining strict cryptographic boundaries. Networks requiring frequent changes face a constraint between operational agility and the security posture provided by narrow authorization scopes. Precise matching ensures that only intended announcements pass validation checks on downstream routers.

Mitigating Fat-Fingered Hijacks Through Origin Validation Limits

Strict maxLength enforcement in ROAs prevents accidental over-specific announcements that trigger route invalidation. Operational data indicates the vast majority of route hijacks are unintentional errors where an operator 'fat-fingers' a prefix they do not hold. Origin validation mitigates most of these problems by cryptographically rejecting announcements exceeding the authorized scope. While RPKI adoption is increasing, liberal usage of broad maxLength ranges opens networks to forged origin attacks on unannounced sub-blocks. The security outcome provides proof of origin, notably reducing hijack risks compared to manual filtering. However, setting an overly permissive maxLength allows malicious actors to exploit undefined space within the authorized aggregate. Operators should issue multiple specific ROAs rather than one broad authorization when deaggregation needs are limited. This approach limits the attack surface should an AS number be spoofed. Conservative configuration is recommended to match prefixes exactly as announced in BGP. Failure to restrict prefix length invites instability where accidental leaks become cryptographically valid. The drawback of a single misconfiguration outweighs the administrative burden of managing multiple ROA objects. Precision in ROA creation ensures that only intended traffic flows remain valid during validation checks.

Implementing RPKI Validation and Resolving Invalid Announcements

Defining Validated ROA Payloads for Router Configuration

Routers consume Validated ROA Payloads (VRPs) containing an IP prefix, maximum length, and origin AS number to enforce cryptographic route filtering. This data structure separates the validation plane from the routing plane, allowing validators to push verified lists to routers via the RPKI-to-Router protocol. Operators configure local validators to fetch these records, creating a binary decision matrix for incoming BGP updates.

1. Valid: The announcement matches a VRP prefix and origin AS within the allowed maxLength.
2. Invalid: The prefix originates from an unauthorized AS or exceeds the specific maxLength limit.
3. NotFound: No covering VRP exists for the announced prefix in the local cache.

The resulting validation state dictates whether the router accepts, de-prefers, or drops the route based on local policy. Operational flexibility often conflicts with security precision; a broad maxLength permits legitimate sub-prefix announcements but expands the attack surface for forged origin incidents on unused blocks. Only intended prefixes gain cryptographic authorization, neutralizing accidental hijacks caused by configuration errors.

Creating ROAs to Authorize Specific AS Origin Statements

Legitimate IP block holders use resource certificates to sign statements authorizing specific autonomous systems to originate prefixes. The creation of a ROA is solely tied to the IP address space listed on the certificate and not to the AS numbers. Consequently, the holder of the certificate can authorise any AS to originate their prefix, not their own autonomous systems. This flexibility supports complex hosting arrangements but demands precise configuration to avoid validation failures.

1. Access the RPKI portal for your specific Regional Internet Registry.
2. Select the IP prefix covered by your current resource certificate.
3. Enter the origin AS number permitted to advertise this space.
4. Define the maxLength to limit acceptable deaggregation depth.

This process generates a digitally signed X.509 certificate that authorizes one or more Autonomous Systems to originate routes for specific IP prefixes. Validators subsequently compare incoming BGP updates against these records to determine if an announcement is Valid, Invalid, or NotFound. Setting a broad maxLength simplifies management but increases exposure to forged origin attacks on unannounced sub-blocks. Accidental over-specific announcements do not inadvertently invalidate legitimate traffic paths while maintaining strict cryptographic control over the routing table.

Troubleshooting Invalid Announcements Using RFC 6811 Status Codes

Diagnose route failures by mapping BGP updates against the three RFC 6811 validation states: Valid, Invalid, and NotFound. Operators must verify if a prefix matches a VRP entry or violates the configured maxLength constraint. An Invalid status indicates the announcement originates from an unauthorized AS or exceeds the authorized specificity limit. Conversely, a NotFound result implies no covering ROA exists, leaving the route subject to local policy rather than cryptographic rejection.

Configure routers to fetch VRP data via RTR and enforce strict dropping of invalid paths.

Equinix uses this logic within its MLPE prefix validation to filter illegitimate routes at the exchange edge. Aggressive deaggregation conflicts with validation stability; splitting prefixes without updating ROAs triggers Invalid states globally. InterLIR recommends maintaining precise maxLength values to prevent accidental route rejection during network renumbering. The system processes 509 distinct prefix entries per update cycle while tracking 6811 potential origin mismatches across the peering fabric.

References

• Worldwide we observe a very low effective coverage of