Network Operator Actions

Home MANRS for Network Operators Network Operator Actions

Version 2.5.2 – 17 May 2021

Mutually Agreed Norms for Routing Security (MANRS) is an initiative to greatly improve the security and resilience of the Internet’s global routing system. It does this by encouraging those running BGP to implement well-established industry best practices and technological solutions that can address the most common threats.

Throughout the history of the Internet, collaboration among its participants and shared responsibility for its smooth operation have been two of the pillars supporting its tremendous growth and success. This document aims to build on this spirit by defining the actions that should be taken by network operators. By doing so, network operators demonstrate a commitment to improving security, develop a culture of collective responsibility, and build a responsible community.

MANRS has the following objectives:

Download PDF
  • Raise awareness of routing security problems and encourage the implementation of actions that can address them.
  • Promote a culture of collective responsibility towards the security and resilience of the Internet’s global routing system.
  • Demonstrate the ability of the Internet industry to address routing security problems.
  • Provide a framework for network operators to better understand and address issues relating to the security and resilience of the Internet’s global routing system.

Scope

MANRS is based around a set of actions that aim to address three main classes of problem:

  1. Incorrect routing information
  2. Traffic with spoofed source IP addresses
  3. Coordination and collaboration between networks

The Compulsory Actions define the steps that network operators should be taking at a minimum to better ensure the security and resilience of the Internet’s global routing system and must be implemented by network operators to be accepted as a MANRS participant.

The Recommended Actions are steps that help address the underlying cause of DDoS attacks, as well as allowing for the cryptographic validation of number resources belonging to other networks.

These actions are based on well-established industry best practices and have been selected on the basis of an assessment of the balance between small, incremental costs to individual network operators and the potential common benefits. However, these actions are not exhaustive and many network operators may already be implementing even stronger measures and controls.

It is also recognised that these actions are not a comprehensive solution to the outlined problems, but each offers steps that if implemented by a large number of network operators, will result in significant improvements in the security and resilience of the Internet’s global routing system.

Definitions

To articulate the specifics of the Compulsory and Expected Actions, it is necessary to define a number of terms relating to their general usage within the Internet industry.

BGPBorder Gateway Protocol, responsible for exchanging routing and reachability information amongst Autonomous Systems on the Internet.
Network OperatorAn organization providing Internet connectivity to other networks and/or end users.
InfrastructureA network operator’s internal network(s) which may or may not be reachable on the Internet. 
Autonomous SystemNetwork(s) forming a single administrative domain that are identified by a unique Autonomous System Number (ASN) and present a common and clearly defined routing policy to the Internet.
End UserEndpoint within a network operator’s AS where traffic is destined for and/or originates from.
Transit NetworkAn external network to which traffic originating from a network operator’s Infrastructure and Customer Networks is sent, and from which traffic from the wider Internet is received.
Customer NetworkAn external network for which a network operator provides transit services. These can be categorised as Directly Connected Customers who may, and Indirectly Connected Customers who may not, have a business relationship with the network operator.
Peer NetworkAn external network to which a network operator is directly connected and exchanges traffic on a settlement free basis.
Stub NetworkA directly connected external network which itself has no customer network although it may have peer networks.
Single-HomedAn End User or Customer Network that only has a single connection to the network operator’s infrastructure over which traffic can flow.
Multi-HomedAn End User, Customer Network or other type of network that has two or more connections to the Internet which provides multiple paths over which traffic can flow.
RIRRegional Internet Registry that manages the allocation and registration of Internet number resources within a region of the world.
NIR National Internet Registry that manages the allocation and registration of Internet number resources for some countries of the world.
MANRS ParticipantNetwork Operators recognized as implementing the MANRS Actions.
MANRS RepresentativeIndividuals(s) nominated by a MANRS Participant as their point of contact.
MANRS Advisory GroupIndividuals elected by the MANRS Participants to supervise the MANRS activities, including the implementation of the MANRS Actions.
MANRS Auditing OfficerAn individual checking that network operators applying to participate in MANRS are implementing the MANRS Actions, and that existing MANRS participants continue to meet the necessary conformance criteria.
MANRS SecretariatThe MANRS Auditing Officer(s) and other administrative staff who may be assigned.

Compulsory Actions

Action 1: Prevent propagation of incorrect routing information

Network operator must implement a system whereby they only announce to adjacent networks the AS numbers and IP prefixes they or their customers are legitimately authorised to originate.

Network operator must check whether the announcements of their customers are correct; specifically, that each customer legitimately holds the AS numbers and IP address space they announce.

Discussion:

It is most important to secure inbound routing advertisements, especially from Customer Networks, through the use of explicit prefix-level filters or equivalent mechanisms. AS-path filters might also be used to require that Customer Networks are explicit about which Autonomous Systems (ASes) are downstream of that customer. Alternately, AS-path filters that block announcements by Customer Networks of ASes with which the provider is peering can prevent some types of routing ‘leaks’. Filtering customer BGP announcements by AS-path filters alone is insufficient to prevent catastrophic routing problems at a systemic level.

References:

Action 3: Facilitate global operational communication and coordination

Network operator must ensure that up-to-date contact information is entered and maintained in the appropriate RIR (or NIR) database and/or in PeeringDB. It is strongly recommended that contact information is made publicly available, but at a minimum must be available to other network operators registered with PeeringDB.

Discussion:

Network operators should register and maintain NOC contact information for each AS and netblock(s) that they are responsible for. This must include an email address to which operational queries may be sent and expected to reply within 72 hours, and a telephone number and dedicated abuse email address (e.g. abuse-c) should also be provided. Networks are encouraged to document their routing policies in an IRR, and additional information (e.g. Looking Glass URL) in the appropriate field of their PeeringDB record is welcome.

References:

Action 4: Facilitate routing information on a global scale – IRR

Network operators must publicly document their intended routing announcements in the appropriate RIR routing registry, RADB or an RADB-mirrored IRR. This includes ASNs and IP prefixes originating on their own networks, as well as the networks for which they provide transit services. 

A network operator may alternatively implement Action 4: Facilitate routing information on a global scale – RPKI (defined below) in lieu of a publicly documented routing policy. 

Discussion:

To facilitate the validation of routing information by other networks on a global scale, information about routing policy, including ASNs and IP prefixes that are intended to be advertised to external parties, is necessary. Routing policy can be publicly documented using RPSL in one of the Internet Routing Registries (IRRs) mirrored by RADB (e.g. AfriNIC, APNIC, ARIN, RIPE).

Network operators must register and maintain one (at minimum) or more “as-set” IRR objects containing a list of ASNs intended to be advertised to external parties that can be used by automatic tools to generate prefix filters. Network operators must also maintain their information in the IRR to ensure that is it up-to-date.

References:

Action 2: Prevent traffic with spoofed source IP addresses – Filtering

A network operator should implement a system that enables source address validation for their own infrastructure and end users, and for any Single-Homed Stub Customer Networks. This should include anti-spoofing filtering to prevent packets with an incorrect source IP address from entering or leaving the network.

A network operator must test whether their network is able to send packets with forged source IP addresses using the CAIDA Spoofer Software. This is to alert the network operator as to whether their network might be used to originate Distributed Denial-of-Service (DDos) attacks, whilst generating publicly accessible information allowing that network to be checked by others.

Discussion:

Common approaches to this problem involve software features such as SAV (Source-Address Validation) on cable modem networks or strict uRPF (unicast Reverse-Path Forwarding) validation on router networks. These methods can reduce the administrative overhead in cases where routing and topology are less relatively dynamic. Another approach could be to use inbound prefix filter information to create a packet filter, that would allow only packets with source IP addresses for which the network could legitimately advertise reachability.

References:

Action 4: Facilitate routing information on a global scale – RPKI

A network operator should create a valid Route Origination Authorization (ROA) for each IP prefix or set of prefixes it is legitimately authorised and intends to originate.

Legacy number resources are those AS numbers and IPv4 prefixes that were assigned before RIRs existed or had management authority over the resources in question, and for which is not always possible to create ROAs. Over the years, the RIRs have undertaken initiatives (e.g. ERX – Early Registration Transfer) to move those registrations into the appropriate RIR database, but some legacy number resources still remain unregistered.

Discussion:

The most secure method of facilitating validation on a global scale is through the RPKI system which allows their routing announcements to be cryptographically verified. Network operators can obtain RPKI certificates for their own IP prefixes from the RIRs that allocated them, and then generate, publish, and maintain Route of Origin Authorizations (ROAs) corresponding to the IP prefixes they announce. Network operators must also encourage their Customer Network operators to do so as well.

References:

Conformance Requirements

A network operator must generally fulfill the minimum requirements outlined in this section in order to be accepted as MANRS conformant and therefore eligible to be a MANRS participant. It is recognised however, that there can be legitimate reasons as to why some requirements cannot be met 100%, and exceptions may be granted where an adequate explanation is provided.

A network operator may become a MANRS participant if at least 50% of ASNs are MANRS conformant. 

Action 1: Prevent propagation of incorrect routing information

Joining requirements:

A network operator must provide a detailed description of the following:

  • If prefix filters are used, what are the mechanisms for generating them? If not, what kind of controls are used?
  • How frequently are these filters are updated?
  • What is the mechanism for checking that a customer legitimately holds the ASN and IP blocks they intend to announce?
  • An ASN must be visible and announcing IP prefixes to the Internet’s global routing system for a minimum of 3 months.
  • An ASN must not have, in the previous 3 months, announced an AS number and/or IP prefix they or their customers are not legitimately authorised to originate. 

Ongoing requirements:

A network operator must continue to maintain controls that prevent the announcement of AS numbers and/or IP prefixes they or their customers are not legitimately authorised to originate.

Action 2: Prevent traffic with spoofed source IP addresses

Joining requirements:

A network operator must run the CAIDA Spoofer Software on at least two network segments using public IP addresses, and the results must appear in the CAIDA Spoofer Database.

Ongoing requirements:

It is proposed that it becomes a requirement that a network operator should run anti-spoofer checks on an ongoing basis, preferably in an automated manner. This might take the form of a wider suite of conformance-checking software.

Action 3: Facilitate global operational communication and coordination

Joining requirements:

A network operator applying to become a MANRS participant must provide the contact details of at least one individual who will be their primary MANRS representative. They may nominate another individual as their secondary MANRS representative.

The MANRS Secretariat will check these contact details for completeness and send a contact verification e-mail to the MANRS representative(s). The network operator must reply to this communication within 72 hours in a manner that verifies the contact details are correct and demonstrates that communications are being actively read and responded to.

Ongoing requirements:

A network operator must ensure that their MANRS representatives are aware of their responsibilities with respect to the MANRS Actions, and their contact details are registered and up-to-date.

The MANRS Secretariat will check the contact details of each network operator at least once per calendar year by sending a contact verification e-mail to the registered MANRS representative(s). The network operator must reply to this communication within 72 hours in a manner that verifies the contact details are correct and demonstrates that communications are being actively read and responded to.

A network operator must take steps to identify and mitigate any routing incident originating from either their ASN(s) or a direct customer ASN within 24 hours of becoming aware or being notified of an incident. Within 72 hours, they must also notify the MANRS Secretariat <[email protected]> of any routing incident where this has caused noticeable disruption to the global routing system, indicating the mitigation measures that are being or have been taken.

The MANRS Secretariat may then disseminate this information to the other MANRS Participants. The MANRS Secretariat may request a response from a network operator within 24 hours of becoming aware of a routing incident, and may also issue a public statement as follows…

”We are aware of recent reports about a routing security incident involving <network operator>, a MANRS participant. We have asked for an explanation and expect the necessary remedial actions to be undertaken if issues are identified. Shared responsibility and collaboration are two pillars of MANRS and it is important that participants continue to be conformant with the MANRS Actions on an ongoing basis.”

The MANRS Secretariat will initially attempt to contact a network operator through its registered MANRS representative(s). If these contacts are no longer valid or there is no response within 72 hours, the MANRS Secretariat will subsequently attempt to contact the technical or abuse contact registered in the appropriate RIR (or NIR) database and/or in PeeringDB.

Action 4: Facilitate routing information on a global scale

Joining requirements:

A network operator must have registered all AS numbers and IP prefixes they advertise to other networks in a RIR or RADB-mirrored IRR as aut-num and route/route6 objects.

OR

A network operator must have created valid Route Origination Authorizations (ROAs) for all IP prefixes or sets of prefixes they are legitimately authorised to originate. Legacy IP prefixes may be excluded from this requirement.

Ongoing requirements:

A network operator must continue to register at least 90% of the IP prefixes they advertise to other networks in a RIR or RADB-mirrored IRR as aut-num and route/route6 objects.

OR

A network operator must have valid Route OriginationAuthorization (ROAs) for at least 90% of IP prefixes or sets of prefixes they are legitimately authorised to originate. Legacy IP prefixes may be excluded from this requirement.

Failure to maintain minimum standards

It is important that network operators are not only conformant with the MANRS principles upon joining but also continue to demonstrate conformance on an ongoing basis. The value of MANRS towards improving the security and resilience of the Internet’s global routing system is dependent upon its participants continuing to implement the Compulsory Actions at a minimum. 

It is fully recognised that mistakes and false positives can occur, and that MANRS participants should be given every opportunity to provide explanations and undertake any necessary remedial actions if issues are identified. Nevertheless, there does need to be a process to handle situations whereby network operators fail to address routing security incidents, fail to respond to communications in a timely manner, or demonstrate persistent non-conformance with the MANRS Actions.

The MANRS Advisory Group will decide on matters of non-conformance upon notification by the MANRS Secretariat and may suspend the participation of a network operator until any necessary remedial actions have been undertaken. If a network operator fails to undertake the advised actions within 6 months, the MANRS Advisory Group may decide to delete them from the list of MANRS participants.

Suspension of Participation

A network operator that has been suspended as a MANRS participant will be indicated as such on the MANRS website and may not participate in discussions relating to the MANRS Actions. They may however, continue to participate in meetings and utilise MANRS communication channels.

Termination of Participation

A network operator that has been deleted from the list of MANRS participants may no longer use the MANRS logo and must remove any references to MANRS. They may not re-apply to become a MANRS participant for a minimum period of 12 months.

Action 3: Facilitate global operational communication and coordination

Network operators may be suspended from MANRS participation for the following reasons:

  • Failure to respond to a contact verification request within 72 hours of it being sent by the MANRS Secretariat.
  • Failure to respond or provide an explanation of a routing incident within 72 hours of being notified by the MANRS Secretariat.
Action 4: Facilitate routing information on a global scale

Network operators may be suspended from MANRS participation if over a 3 month period they have failed to register at least 90% of the AS numbers and IP prefixes they advertise to other networks in a RIR or RADB-mirrored IRR as aut-num and route/route6 objects AND have also failed to maintain valid ROAs for at least 90% of IP prefixes or sets of prefixes they are legitimately authorised to originate and for which they are able to create ROAs.

It is proposed to further describe the criteria for non-conformance on a per-action basis, timelines for taking corrective measures, and outcomes for persistent non-conformance.

MANRS Observatory

The MANRS Observatory collates data from publicly available data sources in order to track routing incidents and provide an overview of the state of global routing security. This data can also be displayed by region and country/economy, whilst MANRS participants may access data about their own network(s).

MANRS Observatory data is used to determine the level of MANRS readiness of network operators. For each of the Actions, a composite metric defines three states of conformance: Lagging (non-compliant), Aspiring (minor improvements are needed), and Ready.

The measurement framework and the thresholds are documented at https://observatory.manrs.org/#/about (‘Measurement Framework’ section).

Contact Information

The MANRS initiative can be contacted at ‘[email protected]’.

Acknowledgements

Andrei Robachevsky, Kevin Meynell, David Belson, Jean-Michel Combes, Rich Compton

Other Versions of the MANRS Document for Network Operators

Editor’s note: The Japanese and Portuguese translations are the ones of the previous version of this document. The current version will be translated, stay tuned!