MANRS Network Operator Actions Guide: Meeting All Four Routing Security Actions

Most BGP hijacks, route leaks and spoofed floods succeed because some networks still accept and pass on whatever their neighbours send them, and MANRS is the industry's agreed minimum for stopping that. MANRS (Mutually Agreed Norms for Routing Security) is a community initiative, with secretariat support from the Global Cyber Alliance and part funding from the Internet Society, that runs programmes for network operators, internet exchange points, CDN and cloud providers and equipment vendors. This guide covers the network operator programme: what each of the four actions requires under the normative actions document (MANRS-003.01, approved 17 May 2021), which are compulsory, how to implement them with the MANRS implementation guide, how the MANRS Observatory measures you, and how to keep conformance once you have joined. It is written for network engineers, NOC leads and security architects at ISPs, hosting providers, enterprises with their own autonomous system, and anyone writing routing requirements into supplier contracts. The routing protocol background lives in the BGP and Routing Security Guide; this page is about meeting the norm.

Key takeaways

• Three actions are compulsory, one is recommended. Under MANRS-003.01, filtering (Action 1), coordination (Action 3) and publishing routing information in an IRR or RPKI (Action 4) are compulsory; anti-spoofing (Action 2) and ROAs as a recommended practice are recommended.
• Prefix filters on customers matter most. MANRS states that explicit prefix-level inbound filters from customers are the most important control and that AS-path filters alone are insufficient.
• Response times are part of the norm. Participants must answer verification within 72 hours, mitigate routing incidents from their own or direct customer ASNs within 24 hours of awareness, and report globally disruptive incidents within 72 hours.
• Registration coverage is measured at 90 percent. Ongoing conformance for Action 4 means at least 90 percent of advertised prefixes registered as route objects, or valid ROAs for at least 90 percent of authorised prefixes.
• The Observatory watches passively. Scores are built from public data (GRIP, CAIDA Spoofer, RIPEstat, PeeringDB, ROAST and others), so leaks, bogons and missing registrations show up whether or not you report them.

The four actions at a glance

An operator may become a participant if at least 50 percent of its ASNs are conformant, and the Secretariat can grant exceptions with an adequate explanation. Note that the MANRS website lists the actions as filtering, anti-spoofing, coordination and global information; the numbering above follows the normative document.

Action 1: filtering announcements

The goal is that your network never becomes the path by which a mistaken or malicious announcement reaches the rest of the internet. The implementation guide (MANRS-007.01) sets out the required filters.

• Inbound prefix filters from customers: required, and the most important control. Build them per customer from that customer's as-set and route objects, after verifying that the customer actually holds the address space (RIR records, letters of authority for unusual cases).
• Outbound prefix filters to peers and upstreams: required. Announce only your own prefixes and those of your customer cone.
• Inbound filters from peers: recommended.
• Bogon filtering: applies at all times, for special-purpose prefixes and bogon ASNs.
• Transit-leak caution: only provide transit for prefixes a customer announced directly to you, not ones you learned from them by other paths. This is the classic route leak pattern.
• IXP route servers: relying on an IXP's IRR filtering is acceptable for ingress only; the guide states that outsourcing egress filters to an IXP is not MANRS compliant.

Automating filters safely

Hand-built prefix lists do not scale. The guide names bgpq4, IRRPT and IRRToolset for generating prefix lists from as-sets (IRRPT also tracks changes between runs), and recommends three deployment safeguards that prevent automation from causing its own outage:

1. Syntax checks: reject empty prefix lists, because some platforms treat an empty list as "allow any".
2. Delta checks: block automatic deployment when a generated list changes by more than a set threshold, and route it for human review.
3. Beacons and bogons: test that known beacon prefixes always pass and bogons never pass before committing.

Complementary BGP hygiene

MANRS sits alongside the IETF's BGP Operations and Security practice, BCP 194 (RFC 7454). Its recommendations include GTSM (TTL 255 checking per RFC 5082) on directly connected sessions, TCP-AO in preference to MD5 where implemented, discarding non-global special-purpose prefixes, generally not accepting IPv4 longer than /24 or IPv6 longer than /48, max-prefix limits per peer set below a full table, requiring the first AS in the path to match the peer (except route servers), never accepting your own ASN in the path by default, and scrubbing inbound communities that use your ASN. BCP 194 also recommends RPKI origin validation: accept valid, discard invalid, and deprioritise routes with no ROA.

Route origin validation

Observatory metric M9 reflects ROV. The implementation guide lists validators (Routinator, FORT, rpki-client, OctoRPKI, rcynic), connection to routers over the RPKI-to-Router protocol, and import policy that classifies routes as valid, invalid or not found. It advises tagging invalid routes during rollout before switching to reject, and gives vendor examples such as bgp rpki server with route-maps matching rpki valid on Cisco IOS XE, validation-state in route policy on IOS XR, rpki origin-validation on Arista EOS and validation-state based policy on Nokia SR OS. See the RPKI and Route Origin Validation Deployment Guide.

Action 2: anti-spoofing

Although recommended rather than compulsory, anti-spoofing addresses a root cause of reflection DDoS. MANRS asks for source address validation for single-homed stub customers, your own end users and your infrastructure, so that packets with incorrect source addresses cannot enter or leave your network.

• Placement: as close to the source as possible, ideally per customer at the provider edge to customer edge interface; aggregation-point filtering is second best.
• uRPF: strict mode on customer-facing interfaces is the primary recommendation (with an allow-default option where a default route points upstream); feasible-path mode for multihomed customers; loose mode is useful for source-based remotely triggered blackholing.
• ACLs: where uRPF is not possible, explicit permit filters for the customer's prefixes and deny everything else.
• Access networks: SAVI and DHCP snooping on switches, and cable source-verify with DHCP LeaseQuery on cable networks.
• NAT is not anti-spoofing: the guide states this explicitly.
• Testing: the CAIDA Spoofer client, run from at least two segments with public addresses, is the joining evidence. A proposed (not yet adopted) requirement would add automated, ongoing anti-spoofing checks.

The method choice per interface type is covered in depth in the Source Address Validation and Anti-Spoofing Guide.

Action 3: coordination and contacts

Routing incidents are resolved by people phoning or emailing each other at short notice. Action 3 makes sure the right person can be found.

Good practice in MANRS-003.01: an operational email that receives replies within 72 hours, a phone number and a dedicated abuse address. Ongoing obligations: complete the annual contact verification within 72 hours, identify and mitigate routing incidents from your ASNs or direct customer ASNs within 24 hours of becoming aware, and notify the Secretariat within 72 hours of any incident that causes noticeable global disruption. If your representatives are unreachable for 72 hours, the Secretariat will try your RIR, NIR or PeeringDB technical and abuse contacts.

Action 4: publishing routing information

Others can only filter you correctly if you tell them what you intend to announce. MANRS recommends publishing in both the IRR and RPKI.

• Route objects: a route or route6 object for each exact prefix and origin ASN you announce, for your own space and that of transit customers.
• AS-SETs: at least one as-set listing the ASNs you intend to announce, typically a customer-cone set and an "all" set, which neighbours use to generate filters for you.
• aut-num policy: document peering and transit policy with mp-import and mp-export, at minimum one reasonable definition per peering.
• ROAs: create them through your RIR's hosted service. Only issue ROAs for prefixes you actually announce, avoid overly broad maxLength values (they permit more-specific hijacks), and use AS0 ROAs for space that must not be routed.
• Process: make ROA and route object creation part of the NOC procedure for every new prefix, so registration never lags announcement.
• Legacy space: some pre-RIR resources cannot easily get ROAs; the conformance thresholds allow legacy prefixes to be excluded.

Joining and staying conformant

1. Gap assessment: look up your ASNs in the MANRS Observatory and a public route registry tool to see current filtering, registration and contact metrics.
2. Fix registration first: route objects, as-sets and ROAs are fast to correct and feed both Action 4 and your neighbours' Action 1 filters.
3. Fix contacts: RIR, PeeringDB and website contacts, with a monitored NOC mailbox and phone line.
4. Automate customer filters: per-customer prefix lists generated from IRR and RPKI data with syntax, delta and beacon checks; at least daily refresh (BCP 194 suggests IRR-based filters be refreshed at least daily).
5. Deploy ROV: validators in at least two locations, tag invalids, review, then reject invalids.
6. Anti-spoofing: SAV on stub customers and end users; run CAIDA Spoofer from two segments.
7. Apply: submit the description of filter generation and customer verification, and answer the Secretariat verification.
8. Operate: add the 24-hour mitigation and 72-hour notification commitments to NOC runbooks and the incident process.

Enforcement: the MANRS Advisory Group can suspend participants; suspended operators are flagged on the website, may be removed if issues are not fixed within six months, and cannot reapply for twelve months. Action 3 suspension can follow a missed 72-hour verification or failure to respond to an incident within 72 hours; Action 4 suspension follows falling below 90 percent on both the IRR and ROA thresholds over three months. MANRS-003.01 notes that some per-action non-conformance criteria are still proposed rather than final.

Decision guidance: a stub network or enterprise with its own ASN and one or two upstreams can usually reach conformance quickly, because it has no customers to filter: the work is ROAs, route objects, contacts, outbound filters and SAV on its own edge. A transit provider has the heavy lift in Action 1 (customer verification and filter automation) and should resource it as an engineering project. Organisations that buy transit rather than operate an ASN can still use MANRS as a procurement requirement: ask providers whether they participate and what their Observatory scores are. See the Third-Party Risk Management Guide for supplier assurance practice.

Measuring with the MANRS Observatory

The Observatory computes a composite score per action with three states: Ready, Aspiring and Lagging. Its measurement framework describes passive data sources, so networks do not need to cooperate for measurement.

Some metrics (M1, M1C, M3CAdmin, M4Admin, M4CAdmin, M7Conflict) are warnings that do not affect the score but are worth acting on, especially IRR and RPKI conflicts. Check the framework page for the current thresholds before reporting them internally, as they can change.

Internal metrics to track:

• Percentage of customer BGP sessions with an automatically generated inbound prefix filter.
• Percentage of originated prefixes covered by a valid ROA, and by a route object (target at least 90 percent each, the conformance floor).
• Number of RPKI-invalid routes accepted from customers or peers (target zero after the tag phase).
• Mean time to mitigate a routing incident originating from your ASN or a direct customer (target under 24 hours).
• Days since contact details were last verified in RIR, PeeringDB and the MANRS portal.
• Observatory state per action per ASN, reported monthly.

Where identity fits

Routing registries are trust anchors controlled by accounts: RIR portal logins that can create or delete ROAs, IRR maintainer credentials, PeeringDB accounts and the API keys used by filter-generation automation. A compromised RIR account can withdraw your ROAs or authorise someone else's origin, which defeats the controls MANRS builds. Put these accounts under named owners with MFA, store automation API keys in a secrets manager with scoped permissions, and alert on ROA and route object changes. See the API Key Management Guide.

Common failure patterns

• Relying on AS-path filters alone: MANRS states they are insufficient. A customer can leak a full table through an allowed AS path; only prefix filters stop it.
• Stale or bloated as-sets: customer as-sets that include upstreams or unrelated networks make generated filters accept almost anything. Review the as-sets you build filters from.
• Empty prefix lists treated as "allow any": an IRR query failure produces an empty list that the router interprets as permit all. The syntax check exists for exactly this.
• ROAs with broad maxLength: a ROA for a /20 with maxLength /24 makes a forged more-specific origin from your ASN look valid. Issue ROAs for the prefixes you actually announce.
• Contacts that bounce: PeeringDB lists a former employee and the NOC mailbox is unmonitored, so the 24-hour mitigation window is missed because nobody heard about the incident.
• Outsourcing egress filtering to an IXP: explicitly non-compliant; your own outbound filters must exist.

Framework mapping

Practitioner checklist

• Create or correct route and route6 objects and an as-set for every ASN and prefix you announce.
• Issue ROAs for every announced prefix with tight maxLength, and AS0 ROAs for space that must not be routed.
• Generate inbound customer prefix filters automatically, with syntax, delta and beacon checks.
• Apply outbound prefix filters to all peers and upstreams; never rely on an IXP for egress filtering.
• Run RPKI validation in at least two places, tag invalids, then reject them.
• Apply source address validation to stub customers, end users and infrastructure, and run CAIDA Spoofer from two segments.
• Update NOC, abuse and security contacts in RIR databases, PeeringDB and your website, and monitor them.
• Write the 24-hour mitigation and 72-hour notification commitments into NOC runbooks.
• Protect RIR, IRR and PeeringDB accounts with MFA and alert on ROA and route object changes.
• Review your Observatory state monthly and treat Aspiring or Lagging as a ticket.

Standards and references

• MANRS: Network Operator Actions (MANRS-003.01)
• MANRS: Implementation Guide for Network Operators (MANRS-007.01)
• MANRS: Observatory Measurement Framework
• MANRS: Network Operators Programme
• IETF: RFC 7454 BGP Operations and Security (BCP 194)
• IETF: RFC 8704 Enhanced Feasible-Path Unicast Reverse Path Forwarding
• NIST: SP 800-189 Rev. 1 Border Gateway Protocol Security and Resilience (Initial Public Draft)
• CAIDA: Spoofer Project

Related NHI Mgmt Group resources: BGP and Routing Security Guide · RPKI and Route Origin Validation Deployment Guide · Source Address Validation and Anti-Spoofing Guide · DDoS Protection Guide