Pacific routing security sets a deadline

APNIC Routing Security SIG Chair Terry Sweetser delivers an executive-focused routing security risk presentation during PITA 30.

As the APNIC Routing Security SIG Chair, I took part in the first APNIC Sub-Regional Forum during PITA's 30th Annual General Meeting, Business Forum and Expo (PITA 30) in Rarotonga. I had the opportunity to put a simple question to a room full of Pacific Telco executives: Does your network filter forged route announcements? Responses generally reflected uncertainty, ranging from tentative assurances to commitments to confirm details with engineering teams.

Over 25 years of coordinating Pacific telecommunications, Fred Christopher has seen the region repeatedly pull together around common goals with broad benefits. That perspective helped align the discussion around full Route Origin Authorization (ROA) and Route Origin Validation (ROV) coverage as a regional ambition, with PITA 31 identified as a practical checkpoint to review progress.

This represented a constructive step forward for routing security in the region, providing a clear focus for engineering teams as they work toward implementation.

Setting the context

The presentation I gave was intentionally non-technical. The Internet's routing system - Border Gateway Protocol (BGP) - is built on trust. Networks announce to their neighbors which addresses they can reach, with no inherent mechanism to verify that those announcements are legitimate.

RPKI fixes that. It adds cryptographically signed certificates - ROAs - that prove which network is authorized to announce which address space. ROV is the filtering side - configuring your routers to actually check those certificates and drop announcements that fail.

Both pieces are needed for effective routing security. Publishing ROAs without enabling ROV means your routes are signed, but your routers will still accept invalid announcements. Enabling ROV without ROAs means you are filtering based on others' records, while your own routes remain unverifiable. Neither half alone is protection.

I used the April 2018 MyEtherWallet attack as the opening example. A BGP hijack that redirected Amazon's DNS infrastructure for two hours, silently stealing around USD 150,000 from cryptocurrency wallet users who went to the right address and arrived at the wrong server. No passwords were cracked. No malware was deployed. The road signs were simply forged, and nobody on the route was checking them.

For Pacific executives, the risks are relatively easy to frame. Route hijacking can enable financial fraud to pass through a network without compromising it directly. Accidental route leaks - which are far more common than deliberate attacks - can disrupt an entire national Internet, particularly where there is only a single international cable. At the same time, regulatory expectations from the US, EU, and Australia are increasingly shaping what international partners require from their peers.

The cost implications are similarly straightforward. Creating ROAs through MyAPNIC is free for APNIC Members (here's how), and for a typical Pacific Island operator, with a small number of prefixes and border routers, signing routes usually takes around half an hour. Enabling ROV involves deploying a validator and making some BGP configuration changes, which is generally achievable within a day. This is an incremental operational task, not a long-term infrastructure program.

Where the Pacific currently stands

IEISI-ORG's global audit covers 120,000+ routable networks across 249 territories. As of April 2026, the picture in the Pacific is mixed.

Of the 116 routable Autonomous System Numbers (ASNs) associated with Pacific Island networks, 49 show some level of vulnerability - either fully exposed or protected only along certain paths. A small number of networks have implemented local ROV, while most currently rely on upstream filtering to varying degrees, or have no effective protection in place.

Several positive patterns emerge from the analysis. Some networks across the region show strong partial implementations, with very high ROA coverage, suggesting that the majority of advertised routes are correctly signed, while audit findings indicate that ROV filtering has not yet been fully operationalized. This results in a partially implemented security posture. This stage is common in deployment maturity models, where foundational controls are in place and completion typically requires a relatively limited additional operational effort.

In contrast, other Pacific networks show mature implementation. Even at a modest scale, they can achieve consistently high routing security outcomes. The distinguishing factor appears not to be resource availability, but an execution approach where routing security was established as a defined priority, supported by clear ownership and implemented as a structured initiative. This highlights the role of organizational focus and delivery discipline in achieving complete deployment outcomes.

What can be done ahead of PITA 31?

Moving from a vulnerable routing posture to a more secure one typically involves a small number of well-understood steps, none of which require new hardware or vendor contracts. For many Pacific networks, this work fits comfortably within normal operational activities.

Step 1 - Sign your routes (ROA). Create ROA records with MyAPNIC for the prefixes your network advertises. Once logged in, this can be done under the RPKI section. For operators with a small number of prefixes, this is usually a straightforward task.

Step 2 - Enable filtering (ROV). Deploy an RPKI validator and configure border routers to use it to validate BGP announcements. Most common routing platforms, including Cisco IOS-XR, Juniper JunOS, Nokia SR-OS, and open-source stacks, support this natively. For many operators in the region, this is a contained configuration exercise rather than a large infrastructure change.

Step 3 - Verify and get a probe. APNIC Labs' routing security measurements provide a practical way to confirm that ROAs are visible, and validation is working as intended. Complementing this with a RIPE Atlas probe can also be helpful - the hardware is provided at no cost, and it allows routing behaviour to be observed using widely trusted community measurement tools.

Once these pieces are in place, operators may also choose to register with MANRS, which provides a public signal of commitment to routing security practices and ongoing improvement.

Checkpoint PITA 31

Having a clearly articulated regional goal as set at PITA 30 is helpful, particularly when it is public and tied to a specific milestone. It's a way for operators across the Pacific to align expectations, compare approaches, and learn from one another's progress.

The tools to verify your progress are at your fingertips:

By the time PITA 31 takes place, these measurements will reflect the state of deployment across the region, creating a natural opportunity for discussion, knowledge-sharing, and identifying where further support or effort is needed.

APNIC offers hands-on Technical Assistance to Pacific network operators at no cost. Teams that need support with implementation can contact [email protected] - supporting this kind of practical deployment is a core part of APNIC's capacity-building work.

The Routing Security SIG mailing list is the appropriate forum for sharing progress, asking questions, and keeping up with developments. We encourage Pacific operators to contribute while they are working through implementation - not only once deployment is complete.

Terry Sweetser is Chair of the APNIC Routing Security SIG and a member of the Internet Engineering and Internet Standards Institute (IEISI). The ROV audit dataset used in this post is open source and updated regularly on GitHub. The author can be reached at [email protected] .

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.