RPKI and MANRS for Pakistani ISPs: Routing Security Explained

CTDISR-2025 Section 10 makes routing security mandatory, not advisory. RPKI implementation and MANRS compliance are listed as hard requirements for every Pakistani telecom licensee. For operators who have been running BGP without route origin validation, these are not optional improvements to schedule at some point. They're audited controls with a remediation deadline attached if an auditor finds them absent.

This article explains what RPKI and MANRS actually require in practice, how to implement each one, and what the audit evidence looks like for an operator that's done it correctly.

What RPKI Is and Why It Matters

RPKI, Resource Public Key Infrastructure, is a framework that cryptographically validates which Autonomous Systems are authorised to originate specific IP prefixes. Without it, BGP relies entirely on the trust that a route advertisement is legitimate, which is why BGP hijacks, accidental or malicious, propagate as easily as they do. A misconfigured router at any AS along your path can advertise your prefixes, and without route origin validation, routers everywhere will accept it.

RPKI works by having resource holders (ISPs and their upstream Regional Internet Registries) create Route Origin Authorisations: digitally signed records stating that a specific ASN is authorised to originate a specific prefix. Routers configured for Route Origin Validation check incoming BGP advertisements against the published ROA database and can reject advertisements where the origin AS doesn't match the ROA, or where no ROA exists at all for that prefix.

For Pakistani ISPs, APNIC manages the ROA infrastructure for the Asia-Pacific region. Creating ROAs for your own prefixes requires access to your APNIC account (or your upstream's account if they hold the IP resources), and the actual ROA creation is a few minutes of work per prefix once you have access.

Implementing RPKI: What It Actually Involves

There are two sides to RPKI implementation: creating ROAs for prefixes you originate, and enabling Route Origin Validation on your routers so you're dropping invalid routes from peers and upstreams.

For ROA creation: log into your APNIC account, navigate to the resource management section, and create an ROA for each prefix you originate, specifying your ASN, the prefix, and the maximum prefix length you'll advertise. The max-length field matters: if you advertise both a /22 and its constituent /24s, your ROA needs to cover both, either by setting max-length to /24 or by creating separate ROAs. An ROA covering only the /22 will mark your own /24 advertisements as invalid from your own prefixes.

For Route Origin Validation on MikroTik RouterOS, which is the dominant platform in Pakistani access networks: RouterOS supports RPKI validation via an RTR (RPKI to Router) connection to a validator. The validator fetches the signed ROA data from the RPKI repositories and serves it to your routers in a format they can use to make routing decisions. Cloudflare operates a public RTR server, as does APNIC. Point your RouterOS RPKI validator configuration at one of those, enable validation on your BGP peers, and set your routing policy to handle three states: valid (accept normally), invalid (drop or deprioritise), and unknown (accept with lower local preference as an interim posture while ROA coverage builds across the internet).

The interim handling of unknown routes matters practically. A significant portion of internet routes currently have no ROA published, so setting a strict "unknown routes rejected" policy immediately will drop valid routes to destinations where the originating AS simply hasn't published ROAs yet. Starting with valid preferred, unknown accepted with lower preference, and invalid dropped is the operationally safe approach.

What MANRS Requires

MANRS, Mutually Agreed Norms for Routing Security, is a set of four actions that define responsible BGP operation. CTDISR-2025 cites MANRS compliance as the primary baseline for routing security, meaning PTA expects you to meet all four actions.

Action 1, filtering, requires you to apply prefix filters on customer sessions so customers cannot advertise prefixes you haven't explicitly authorised them to. In practice this means a defined prefix list for each downstream customer, updated when their address space changes, applied as an inbound filter on their BGP session. It also means you're not accepting route advertisements from customers that would propagate prefixes you have no business relationship with.

Action 2, anti-spoofing, requires you to prevent traffic with forged source addresses from entering your network. For access networks this typically means implementing BCP38 uRPF (unicast Reverse Path Forwarding) or equivalent ACL-based filtering at the subscriber edge, so subscribers cannot send packets with source addresses outside their assigned range.

Action 3, coordination, requires you to maintain publicly accessible and accurate contact information for abuse and routing security incidents, and to actually respond when contacted. APNIC's contact records for your AS need to be current and monitored.

Action 4, global validation, refers to RPKI Route Origin Validation as described above, completing the loop between the two frameworks.

MANRS membership itself (registering on manrs.org) demonstrates public commitment and gives you a verifiable record of MANRS conformance. PTA auditors can check MANRS membership directly, so it's also evidence rather than just good practice.

What Auditors Check

For RPKI, auditors will look for ROAs published for your prefixes (verifiable through APNIC's RPKI portal and third-party tools like RIPEstat), RTR configuration on your routers showing you're consuming route validation data, and routing policy documentation showing how invalid routes are handled. An operator who has published ROAs but hasn't enabled validation on their routers has done half the work and still has a finding.

For MANRS, auditors look for MANRS membership status, evidence of prefix filters on customer sessions (router configuration extract or policy documentation), BCP38 or equivalent anti-spoofing implementation, and current contact records in APNIC's database.

The common gap: operators who've implemented anti-spoofing at the subscriber edge but have no prefix filtering on customer BGP sessions, or vice versa. Both are required and auditors check for both.

For ongoing visibility into your routing security posture, PeerIQ covers RPKI and MANRS assessment as part of its routing security analysis alongside the transit cost and IX opportunity analysis. For network architecture work around multi-homing and BGP hardening, Network Design & Optimization covers the implementation directly. And for a scored assessment of your CTDISR-2025 compliance across all sections including Section 10, ISP Audit gives you the gap picture before an auditor does.