BGP was built for a cooperative network of known peers. The internet that exists today is neither. RPKI, ROV enforcement, and ASPA are the cryptographic layer that turns routing assertions into verifiable commitments — and keeps your customers' traffic on the paths you intend.
The Border Gateway Protocol was designed in 1989 for a network of cooperative, mutually trusting peers. It has no built-in mechanism to verify that the AS announcing a prefix is actually authorised to do so. That gap is the attack surface. Hijacks redirect traffic through adversary-controlled infrastructure. Route leaks propagate misconfigurations globally in minutes. Neither requires any access to your systems — only the ability to send BGP UPDATE messages.
The internet routes traffic based on assertions. RPKI turns assertions into cryptographic commitments. The technology is mature — the gap is deployment, not readiness.
Terry Sweetser, IEISIA BGP hijack occurs when an AS announces a prefix it does not own. Without RPKI ROV enforcement at upstream and peer routers, that announcement propagates globally. Traffic destined for your infrastructure — including customer data, authentication flows, and DNS queries — can be redirected to an attacker-controlled network. High-profile incidents have targeted financial institutions, DNS providers, and government infrastructure.
A route leak occurs when an AS re-announces routes it should not propagate — typically customer routes re-advertised to other providers, creating unintended transit paths. The consequences range from suboptimal routing to complete traffic black-holing. Route leaks don't require malicious intent: a misconfigured policy on a routine change can affect millions of end-users before the first alert fires.
When you enforce ROV on your network, you protect not only your own infrastructure but every customer behind it. An ISP or IXP that accepts RPKI Invalid routes is one hop away from becoming unwitting transit for hijacked traffic. From a board-level perspective, this is a third-party risk issue: your customers trust you to route their traffic only across paths with verifiable authorisation.
CISA, NIST, and the major RIRs (APNIC, ARIN, RIPE NCC) have all published routing security guidance that treats RPKI deployment as a baseline expectation for responsible network operators. MANRS provides the industry framework. Boards and executives who have not reviewed their organisation's RPKI status are carrying reputational and operational risk they may not have formally quantified.
Routing security is not a single configuration change. It is a programme spanning registry hygiene, router policy, operational training, and governance. The sequencing matters: signing ROAs without enforcing ROV leaves your customers exposed to others' invalid routes; enforcing ROV without correct ROAs risks disrupting your own reachability. I have worked through this sequence across ISPs and carriers in Asia-Pacific and know where the operational surprises are.
Structured audit of your current posture: ROA coverage against announced prefixes, ROV status on peering and transit sessions, IRR record accuracy, and RIR registry hygiene. Produces a gap analysis and sequenced implementation plan — starting with the fixes that carry the highest risk if left unaddressed.
End-to-end Route Origin Authorisation signing for your APNIC, ARIN, RIPE NCC, or LACNIC allocated address space. Covers max-length policy (a critical decision with operational consequences), covering ROA strategy for sub-delegation, and IRR cleanup that should accompany any ROA programme. Vendor-neutral across all RIR RPKI portals and hosted RPKI services.
Router policy design and configuration to drop or deprioritise RPKI Invalid prefixes — turning RPKI from a passive repository into active protection. Covers session-level policy, handling of NotFound prefixes, and the operational monitoring required to catch ROV-induced reachability issues before customers do. Supported on Cisco IOS/IOS-XR, Juniper Junos, MikroTik, BIRD, and FRRouting.
Autonomous System Provider Authorization is the next generation of BGP security — extending RPKI from origin validation to path validation, enabling detection of route leaks that ROAs alone cannot prevent. ASPA is in active IETF standardisation and early deployment. Advisory on ASPA object creation, provider relationship documentation, and readiness for networks preparing to deploy as standards finalise.
Practical routing security workshops for NOC and network engineering teams: RPKI architecture, ROA management workflows, ROV troubleshooting, IRR hygiene, and BGP security incident response. Designed for operators who maintain these systems in production — not for engineers sitting a certification exam. Delivered in-person across Asia-Pacific or remotely.
Routing security policy documentation, board-level risk framing, and governance framework alignment (MANRS, NIST CSF, ISO 27001 Annex A). For management and boards who need to understand their organisation's routing security posture as part of broader cyber risk governance — and for operators who need policy documents that survive an audit or a regulatory review.
Good cybersecurity is layered. At the network layer, that means RPKI. But the decision to deploy — and the accountability when it hasn't been — belongs at every level of an organisation: from the engineer handling ROA max-length policy to the board member approving the cyber risk register.
Boards routinely ask about ransomware preparedness and data breach liability. They should also be asking: does our AS have ROAs signed? Are we enforcing ROV? The answers to those questions are a direct statement about whether we protect our customers' traffic.
Terry Sweetser, IEISIROA signing, ROV enforcement, RPKI cache configuration, BGP policy maintenance, and incident response. Routing security is operational technology: it requires the same change management rigour, monitoring, and runbook depth as any other production change. Training and implementation support for the teams who will own this day to day.
Routing incidents have caused outages at financial institutions, redirected customer authentication traffic, and generated regulatory scrutiny. For CISOs, CTOs, and operations leadership, the question is not whether RPKI matters — it is how to sequence deployment without disrupting production, and how to communicate the risk to boards who are not network engineers.
Cyber risk governance frameworks (ISO 27001, NIST CSF, Essential Eight) focus heavily on endpoint and application security. Routing security often falls through the gap. For boards overseeing ISPs, telcos, cloud providers, or any organisation with an AS number, RPKI deployment status is a legitimate governance question — and one that most cyber risk registers do not yet capture.
BGP security works better the more networks deploy it. A single AS enforcing ROV is protected from invalid routes — but propagation of those routes upstream still affects the broader internet. Network Operators Groups across Asia-Pacific are the right venue to drive coordinated adoption, share operational experience, and build the peer pressure that moves industry norms faster than regulatory mandates ever will.
RPKI adoption in Asia-Pacific has grown substantially — but the work is not done. ROA coverage is uneven across the region, ROV enforcement remains a minority practice among smaller ISPs, and the operational knowledge to deploy and maintain RPKI correctly is not uniformly distributed. Through APNIC training programmes delivered across 56 economies, I have seen directly where the gaps are and what barriers operators actually face.
Across Asia-Pacific, ROA registration has grown substantially — driven by RIR outreach, MANRS commitments, and peer pressure in the NOG community. But ROV enforcement — configuring routers to actually reject Invalid prefixes — lags significantly behind. An RPKI ecosystem where many networks sign ROAs but few enforce ROV provides limited actual security: hijacked prefixes can still propagate to non-enforcing networks. The value of RPKI compounds as enforcement adoption grows. Every additional AS that enforces ROV makes the internet incrementally safer for everyone else.
Reconcile announced prefixes against IRR records and RIR allocations. Fix stale, incorrect, or missing objects before signing ROAs against them.
Define max-length policy carefully — overly permissive max-lengths undermine security; overly restrictive ones break traffic engineering. Get this right before signing.
Create ROAs for all announced prefixes via your RIR's RPKI portal or hosted RPKI service. Validate coverage with external tools (Cloudflare, RIPE Stat) before moving to enforcement.
Configure RPKI-RTR, validate cache connectivity, apply BGP policy to mark or drop Invalid prefixes. Start on a single upstream session; expand after confirming no reachability impact.
Operationalise: ROA expiry alerting, RPKI cache health monitoring, periodic prefix coverage reviews, and runbooks for handling ROV-induced reachability issues.
Resource Public Key Infrastructure (RPKI) is a cryptographic framework that lets IP address holders create digitally signed certificates — Route Origin Authorisations (ROAs) — declaring which Autonomous Systems are permitted to originate their prefixes. When a network enforces Route Origin Validation (ROV), its routers check incoming BGP announcements against the RPKI repository and can reject prefixes from unauthorised ASes. ROAs protect your prefixes from being hijacked by others who enforce ROV; ROV protects your network and your customers from others' invalid routes.
Signing ROAs is necessary but not sufficient. ROA signing registers your authorised origin AS in a cryptographically verifiable repository — it protects your prefixes on networks that enforce ROV. But it does nothing to protect your network or your customers from RPKI Invalid routes announced by third parties. That protection requires ROV enforcement: configuring your routers to reject or deprioritise Invalid prefixes. Without enforcement, you are contributing to the RPKI ecosystem but not receiving its full protection.
Yes — if your own ROAs are incorrect. This is the most common concern about ROV deployment, and it is also the most manageable risk. Before enabling enforcement, validate that every prefix you announce has a correct, non-expired ROA with an appropriate max-length. Test in monitoring mode (marking Invalid prefixes without dropping them) before enforcing. The operational risk of ROV is real but well-understood — it is a reason to prepare carefully, not a reason to delay indefinitely.
Autonomous System Provider Authorization extends RPKI from origin validation to path validation. ROAs verify that the originating AS is authorised to announce a prefix. ASPA records verify that the transit path is consistent with actual provider relationships — enabling detection of route leaks, which ROAs cannot prevent. ASPA is being standardised at the IETF and is in early operational deployment. Networks should begin documenting their provider relationships now in preparation for broader adoption.
MANRS (Mutually Agreed Norms for Routing Security) is a global initiative from the Internet Society that defines concrete actions for network operators, IXPs, CDNs, and cloud providers to improve routing security. For network operators, the core actions cover filtering (IRR-based prefix filtering), anti-spoofing (BCP38), coordination (publishing accurate routing policy information), and global validation (RPKI ROV enforcement). MANRS membership is a credible, publicly verifiable signal to peers and customers that you take routing security seriously — and the community is where operators share the operational experience of having already worked through deployment.
Most cyber risk frameworks focus on endpoint security, identity management, and application-layer controls. Routing security operates one layer below — at the network infrastructure level. A BGP hijack can redirect authentication flows, intercept unencrypted traffic, and cause denial of service without touching a single endpoint. Defence in depth requires protecting the network layer. RPKI, IRR hygiene, and MANRS conformance are the network-layer equivalents of patching, MFA, and access logging — hygiene controls that most organisations have not yet formally assessed or documented.
Whether you are starting your RPKI programme, troubleshooting an ROV deployment, preparing a board briefing on routing risk, or wondering where to begin — start with a conversation. No sales cycle, no pitch deck.