RPKI in Latin America: we passed 50% coverage and what that means for your network
For years, RPKI was that technology every network operator knew they should implement but kept pushing to “the next maintenance window.” The implicit argument was that if nobody else was doing it, there was no urgency in being the first.
That argument no longer holds. In the context of NANOG 96 and current LACNIC data, we can confirm that global RPKI coverage has surpassed 50% of IPv4 address space. In Latin America, adoption has been accelerating driven by LACNIC and the major regional operators. The time to configure RPKI on your network is not “when everyone else does it” — it’s now, while you still have the margin to do it on your own terms and not in the middle of an incident.
What RPKI is and why it matters
RPKI (Resource Public Key Infrastructure) is a public key infrastructure specifically designed for the internet routing system. Its core function is simple: it allows the legitimate owner of an IP address block to cryptographically sign a statement that says “this prefix can only be originated by this autonomous system number (ASN).”
That signed statement is called a ROA (Route Origin Authorization). A ROA has three key fields:
- The IP prefix (for example, 200.45.0.0/16)
- The ASN authorized to originate that prefix
- The maxLength: the maximum specificity considered valid (for example, if the maxLength is /24, the owner authorizes subnets up to /24 from that block to be originated, but not /25 or more specific)
When a router receives a BGP announcement, it can validate it against the RPKI database and determine whether the prefix’s origin is authorized. That process is called Route Origin Validation (ROV) and has three possible outcomes:
- Valid: a ROA exists that covers the prefix and the originating ASN is authorized
- Invalid: a ROA exists for that prefix but the originating ASN is not the authorized one (this is exactly what happens in a hijacking)
- Not Found: no ROA exists for that prefix
Why BGP hijacking is still a real problem
BGP has been the internet’s routing protocol for over thirty years, and its structural weakness has never been a secret: it has no native mechanism to verify that whoever announces a prefix is the legitimate owner. Any BGP router can announce any prefix, and if that announcement propagates, traffic gets diverted.
The documented cases are numerous and vary in impact:
Pakistan Telecom (2008): Pakistan Telecom accidentally announced YouTube’s prefix 208.65.153.0/24. The announcement propagated globally and YouTube became unreachable for about two hours from much of the world.
Rostelecom (2020): The Russian operator Rostelecom originated prefixes from more than 200 networks, including major CDN providers and financial services. The incident lasted approximately one hour before being mitigated.
Amazon IP hijacking (2018): Traffic was redirected toward Amazon’s DNS service (Route 53) to steal cryptocurrency over a two-hour period.
In all of these cases, RPKI with active ROV would have automatically blocked the propagation of invalid routes on routers with validation enabled. Hijacking remains possible wherever there is no active ROV, and the 50% coverage we celebrate today means there is still plenty of room for attacks.
The 50% milestone: what changed and what stayed the same
The 50% coverage is an important milestone, but it doesn’t mean the problem is solved. To understand what changed, we need to separate two concepts that sometimes get confused:
RPKI coverage (having ROAs): a prefix has coverage if a ROA exists that describes it. Surpassing 50% coverage of address space means that the majority of internet IPs have a published ROA defining who can originate them.
Active ROV (validating and filtering): a router has active ROV if, in addition to being able to query the RPKI database, it makes routing decisions based on that query. In particular, if it discards routes marked as Invalid.
Having coverage without active ROV on the routers is like having security cameras without monitoring: the data is available but there are no consequences for violators. Real protection comes from the combination of both: ROAs published by prefix owners, plus active ROV on operator routers.
The acceleration in coverage over the past two years has a clear explanation: the major transit operators (global Tier 1 and Tier 2) enabled active ROV, which creates an immediate incentive for their customers and peers to publish ROAs. If your prefix doesn’t have a ROA and your uplink has active ROV, your traffic may be marked as “Not Found” (which today is generally not filtered) or in the worst case someone can hijack your prefix without it being blocked.
Latin America and LACNIC: the regional context
LACNIC is the Regional Internet Registry (RIR) for Latin America and the Caribbean. In addition to managing the region’s address space, LACNIC operates one of the five global RPKI Trust Anchors: the root repository from which the cryptographic signatures of all ROAs in the region are chained.
The progress of RPKI in Latin America has been consistent but uneven:
The large operators (Claro, Movistar, TIM, NET Virtua, VTR, and other regional tier 1s) have mostly already published ROAs for their main blocks. The gap is with medium and small ISPs: regional operators, city-level ISPs, rural access providers that have had assigned blocks for years but never published ROAs.
For that segment, the ROA publication process is simpler than it seems.
How to publish ROAs on the LACNIC portal
The process has two steps: authenticate on LACNIC’s management system (LACNIC WHOIS / resource management portal) and create the ROAs for the blocks you manage.
Step 1: Access the portal
LACNIC offers the RPKI system through its resource management portal at lacnic.net. Organizations with resources assigned directly by LACNIC have access to the RPKI panel from the same account they use to manage their assignments. Organizations that received resources through an LIR (Local Internet Registry) should contact their LIR to manage their ROAs, or may request direct access depending on the case.
Step 2: Create a ROA
The interface allows you to create ROAs specifying:
Prefix: 200.45.0.0/16
Origin ASN: 65001
maxLength: /24
Period: 1 year (renewable)
The maxLength is the field most frequently misconfigured. If you have the block 200.45.0.0/16 and want to announce more specific sub-prefixes (for example, 200.45.1.0/24 for a customer), the maxLength must be /24. If you leave it at /16, the more specific announcements will appear as Invalid on routers with active ROV.
maxLength recommendation:
Don’t use an excessively permissive maxLength. If your policy is to announce up to /24, set it to /24. Don’t set it to /32 “just in case” because that negates much of the protection: any sub-prefix down to /32 would be marked as Valid even if another ASN is announcing it, as long as it uses the same parent block.
Step 3: Verify the publication
Propagation of a newly created ROA through the RPKI hierarchy takes between a few minutes and a few hours. To verify that your ROA is available, you can use online tools such as RIPE NCC’s RPKI Validator or LACNIC’s validation portal, or from the command line:
# Check the RPKI status of a prefix using routinator
routinator validate --prefix 200.45.0.0/16 --asn 65001
# Alternative with rpki-client (on BSD/Linux systems)
rpki-client -v
# Then query the generated local database
Enabling ROV on your routers: vendor guide
Publishing ROAs protects your prefixes from others announcing them without authorization. But for your network to also reject hijackings of third-party prefixes, you need to enable Route Origin Validation (ROV) on your border routers.
The process has two parts: configuring an RPKI Cache Server (also called an RTR server) that downloads and validates the RPKI database, and then connecting your routers to that cache to obtain validation data.
RPKI Cache Server: Routinator
The most common option for network operators in Latin America is Routinator, an open source RPKI validator developed by NLnet Labs:
# Installation on Ubuntu/Debian
apt install routinator
# Initialization (accepts the TALs from all 5 RIRs)
routinator init --accept-arin-rpa
# Start the service
systemctl enable routinator
systemctl start routinator
# Verify it's serving on RTR (port 3323 by default) and HTTP (8323)
routinator server --rtr 0.0.0.0:3323 --http 0.0.0.0:8323
Routinator downloads the RPKI repositories from all five RIRs (LACNIC, ARIN, RIPE NCC, APNIC, AFRINIC), validates the certificate chains, and serves the validated database to routers via the RTR protocol (RPKI-to-Router, RFC 8210).
For production, install Routinator on a dedicated VM with internet access (to download the repositories) and with access from your border routers on the RTR port (3323 by default).
Configuration on Huawei VRP
# Configure the RTR peer (Routinator)
rpki
session 10.0.0.100 65535
tcp port 3323
connect-retry-interval 30
#
# Enable BGP route validation
bgp 65001
ipv4-family unicast
bestroute routerid-prior rpki
rpki route-valid-import
rpki route-invalid accept # or drop depending on your policy
#
# Verify the RTR cache status
display rpki session all
display rpki routing-table
The policy for what to do with Invalid routes is the most important decision:
rpki route-invalid drop: discards Invalid routes. Maximum protection, but if someone publishes an incorrect ROA for their own prefix, that network’s legitimate routes get blocked on your router.rpki route-invalid accept: accepts Invalid routes but marks them with a community. Allows monitoring without immediate impact.
For operators just getting started with RPKI, the recommended strategy is to start with accept and monitor for 30-60 days, then migrate to drop once you’re confident that the state of ROAs in the region is sufficiently correct.
Configuration on MikroTik RouterOS 7.x
# Add the RTR server
/routing rpki
add address=10.0.0.100 port=3323 name=routinator
# Verify the status
/routing rpki print
/ip route print where rpki-valid=yes
/ip route print where rpki-invalid=yes
# Configure BGP filtering policy
/routing filter rule
add chain=bgp-in comment="Drop RPKI Invalid" action=discard \
rpki-valid=no
RouterOS 7.x supports native RPKI since version 7.1. In previous versions (6.x), there is no native support and external solutions would be required.
Configuration on Cisco IOS-XR
! Configure the RTR server
router bgp 65001
rpki server 10.0.0.100
transport tcp port 3323
refresh-time 300
!
!
! Enable validation in the address family
router bgp 65001
address-family ipv4 unicast
bgp bestpath origin-as allow invalid
bgp origin-as validation signal ibgp
!
!
! Verify
show bgp rpki summary
show bgp rpki table
show bgp ipv4 unicast 200.45.0.0/16
Filtering policy: the Valid-only vs. Invalid-drop debate
A frequent question when implementing RPKI: should you reject all Invalid routes, or only those from prefixes with RPKI coverage?
The answer depends on the RPKI ecosystem maturity level among the peers and transits you receive. With 50% global coverage, there is a non-trivial fraction of operators that have published ROAs with errors (incorrect maxLength, wrong ASN in the ROA, expired ROA). If you adopt an aggressive Invalid-drop policy, you may end up blocking legitimate routes from networks with misconfigured ROAs.
The current operational recommendation for most ISPs in LATAM is as follows:
- Stage 1 (first 4-8 weeks): Enable ROV with accept policy for Invalid. Monitor the volume of Invalid routes reaching your network and from which peers.
- Stage 2: Review recurring Invalid routes. In many cases these are misconfigured ROAs from peers you can contact to get them corrected.
- Stage 3: Migrate to Invalid-drop when the false positive noise is low and you have confidence in the data.
For incoming traffic from transit upstreams, the major carriers already apply their own ROV policies. The most impactful thing you can do today as a mid-sized ISP is to publish correct ROAs for all your assigned blocks and enable ROV on your border routers with a conservative policy.
What 50% global coverage means for those who haven’t done it yet
The 50% coverage creates an incentive landscape that worsens for laggards:
Higher probability of targeted hijacking: Prefixes without ROAs are the natural target for anyone wanting to do route hijacking, because they are the ones that cannot be automatically blocked. As more prefixes get ROAs, those without stand out as targets.
Upstream pressure: Tier 1 operators that have enabled active ROV may apply stricter policies over time. Today most accept Not Found routes. In the future, some may choose to mark or filter them.
Operational reputation: In the network operator community (NANOG, LACNOG, LACNIC forums), an operator’s RPKI status is increasingly visible. Peering partners check whether your blocks have ROAs before accepting or prioritizing agreements.
Our experience with ISPs in LATAM
At Ayuda.LA we work with ISPs across Latin America on RPKI implementation as part of broader BGP security and infrastructure hardening projects. The most frequent pattern we encounter is operators that have had assigned blocks for years (sometimes with fragmented numbering from different assignments) and never published ROAs because “it wasn’t urgent.”
The process of auditing your own blocks, mapping the ASNs that legitimately originate them, and publishing the correct ROAs typically takes between one and three days of work. It’s not a long project. The biggest effort usually lies in documenting the actual state of the blocks (what’s being announced, from which ASN, at what granularity) when that documentation doesn’t exist or is outdated.
Learn more about our network security and hardening services for ISPs.
Want to review the RPKI status of your network?
We can audit the current status of your assigned blocks, identify missing or incorrect ROAs, and guide you through configuring ROV on your border routers.
Let’s talk about your network →
Have questions about RPKI, BGP, or routing security? Write to us at [email protected] — we reply to every message.