Summary

  • LACNIC describes ROAs as signed objects connecting prefixes to an autonomous system authorized to originate them; hosted RPKI lets members use the system without operating their own certificate authority.
  • BTW analysis: the control becomes useful when operators keep ROAs aligned with BGP, verify their effects and deploy route-origin validation with monitoring and redundancy.

Sources: LACNIC RPKI FAQ, RPKI best practices, RPKI at 15, and RPKI and IRR FAQ.

A signed origin statement is narrow by design

LACNIC explains RPKI as a public-key infrastructure that supplies cryptographic material for checking a holder’s right to use Internet number resources. A Route Origin Authorization connects one or more IP prefixes to the autonomous system allowed to originate them in BGP.

That is a precise control, not a universal routing certificate. LACNIC’s FAQ says RPKI does not replace an Internet Routing Registry, which retains functions such as policy registration by ASN. Its 2026 retrospective also distinguishes the system’s initial route-origin objective from the harder problem of validating other elements of a route path.

Hosted service lowers one operating threshold

LACNIC supports hosted and delegated RPKI. Under the hosted model, a member can perform RPKI tasks without maintaining its own certificate authority. This reduces one infrastructure burden, but it does not remove the member’s responsibility for deciding which prefixes and origin ASNs its ROAs should cover.

BTW analysis: the governance boundary is useful because it separates registry-backed authorization from network execution. LACNIC can operate certification infrastructure and publish guidance; the resource holder still owns the accuracy of its ROAs, while network operators decide how validated origin data affects routing.

Accuracy depends on disciplined change control

LACNIC’s best-practice guidance recommends creating ROAs that match what is announced in BGP and nothing more where possible. It warns against overly liberal maxLength settings, recommends checking that a new ROA has not invalidated routes, and advises running multiple validators for redundancy.

The same guidance describes a cautious path for Route Origin Validation: monitor validity states first, then tag announcements or adjust preferences, and only begin dropping invalid announcements once the operator is confident in the setup.

This sequence makes the operational point clear. RPKI provides a structured way to distinguish authorized from unauthorized origins, but its value depends on routine maintenance, observable changes and recovery paths. A stale or over-broad authorization can weaken the control even when every cryptographic signature verifies.

What the evidence does not establish

The cited sources do not establish that every LACNIC member has complete ROA coverage, that every network drops invalid routes, or that a valid origin makes a route reachable or secure end to end. They support a narrower conclusion: LACNIC provides infrastructure and operational guidance for proving and validating route-origin authority.