What It Takes for a Non-transit (Stub) Network to Join MANRS

Recently, I’ve been asked what level of effort is required for an organization to join MANRS. In this post, I will share my experiences and opinions on what it takes for a non-transit network (sometimes called a ‘stub’ or ‘leaf’ network) to apply to the Network Operators Program.

MANRS is a set of actions that all network operators should already have implemented. It’s a floor – a minimum of what we should all be doing. And in many cases, organizations have already completed, or substantially completed, the actions specified in the Network Operators Program.

In short, joining MANRS is achievable and beneficial to both your network and the whole Internet.

Action 1: Prevent propagation of incorrect routing information

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

Network operators 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.”

Action 1 is important because ensuring correct information in the routing table contributes to the stability and reliability of the Internet and ensures that traffic follows the intended paths.

This one is fairly easy for non-transit networks to implement because there are no downstream customers. The only thing such a network has to be concerned with is to ensure that it announces only its own IP and ASN to its upstreams and peers. As I mentioned at the start of this article, you should already be doing this! RFC 7454 / BCP 194, Section 6.3.2 states:

A leaf network will most likely have a very straightforward policy:
  it will only announce its local routes. It can also configure the
  prefix filters described in Section 6.2.1.2 to avoid announcing
  invalid routes to its upstream provider.

The exact syntax of such a policy will vary by platform; below is a partial configuration for a Juniper router.

prefix-list My_Prefixes_v6 {
  2001:0db8:5000::/48;
  2001:0db8:9000::/48;
}

policy-statement eBGP_export_v6_Prefixes {
  term "match My Prefixes" {
    from {
      prefix-list My_Prefixes_v6;
    }
    then accept;
  }
  term All-Other-Prefixes {
    then reject;
  }
}

group Upstream1_v6 {
  type external;
  export eBGP_export_v6_Prefixes;
  peer-as 4200113886;
  neighbor 2001:0db8:5c5b:4901::1;
}

Level of Effort: Low. This is a one-time configuration that changes only when your IP address allocations change.

Estimated Time: Initially, a few hours for research and testing; ongoing, an hour per year for verification and any changes.

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.”

Action 3 is important because if another operator needs to reach you to report a problem, the information needs to be easily accessible and correct.

This one is fairly straightforward. And again you should already be doing this! (Am I getting repetitive?)

Make sure your WHOIS records with your Regional (or National or Local) Internet Registry are up to date. In the ARIN region, all Points of Contact (POCs) should receive yearly emails to validate that the information is still correct. You can easily check by looking up your own records:

nicinfo 2001:0db8:5000::

       [ ENTITY ]
         Handle: somehandle-ARIN
       Common Name: Abuse Administrator
      Organization: Abuse Administrator
          Email: [email protected]
          Phone: +1-950-KL5-0199 ( work, voice )
          Roles: Abuse
      Last Changed: Thu, 09 Dec 2021 13:25:53 -0500
      Registration: Mon, 08 Mar 2004 17:26:43 -0500
         Remarks: -- Unvalidated POC --
            1: ARIN has attempted to validate the data for this POC, but has received no response from the POC since 2022-12-09

Look at the remarks: — Unvalidated POC — This is an easy fix. The POC should log into the ARIN portal and confirm or update the contact information.

PeeringDB is also a great place to share your contact info. Setting up an account is free and easy.

Contact information can also be stored in Internet Routing Registries (IRR), which will be covered in the next section.

Level of Effort: Low. Update contact information when it changes, or a yearly reminder to confirm existing information.

Estimated Time: Initially, an hour; ongoing, an hour per year for verification and any changes.

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 (Resource Public Key Infrastructure, defined below) in lieu of a publicly documented routing policy.”

Action 4 is important because documenting the proper prefix-ASN mapping allows operators, particularly your upstreams, to automatically create filters to ensure that only proper route advertisements are accepted and propagated.

This action may also be implemented by creating RPKI ROAs and/or IRR entries.

While IRRs and the Routing Policy Specification Language (RPSL) can get complicated for large, complex networks, for non-transit networks, creating the necessary records is straightforward.

The IRR data is what maps prefixes to origin ASes, and allows operators to build prefix lists. MANRS requires IRR entries in RADB directly, or a database that RADB mirrors, which includes all the Regional Registries. The exact method of how to make entries will vary depending on the database you choose. Details on the format of the object can be found here.

Level of Effort: Medium. For some non-transit networks, IRR is a new experience. Your upstreams may have created ‘proxy’ entries on your behalf without you even knowing. There may be some initial effort involved to research and document the address space you have. Again, hopefully, this is something you already have or can easily generate. Internet number resources are valuable assets and should be tracked and maybe even recorded as an organizational asset. Once completed, changes to IRR records and/or ROAs only need to be made when number allocations change or if services such as DDoS scrubbing services are engaged (primarily if you need to allow the service to originate your address space). Many IRRs have easy-to-use web interfaces. Also, many RIRs have automated (or are in the process of) creating IRR entries when ROAs are created.

Estimated Time: Initially, a few hours for research and testing; ongoing, an hour per year for verification and any changes.

Recommended Actions

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.”

Action 2 is important because preventing packets with spoofed source addresses from leaving a network is a critical component to stopping Distributed Denial of Service (DDoS) attacks. This is especially true for non-transit, or edge, networks since implementing these filters as close to the source of potentially spoofed traffic is the most effective place to stop such traffic.

This action is optional not because it is unimportant, but because it is difficult to reliably measure from the outside.

To comply with this action, a network should have packet filters at its border which drop any traffic from leaving that is not sourced for address blocks assigned to that network. Even better, having such filters (either static access lists or unicast reverse path forwarding, uRPF) on end or leaf subnets drops spoofed traffic from reaching any network, including other subnets inside your border. It’s also a good idea to have filters that drop packets destined for your network that come looking like they’re sourced from your network.

Level of Effort: Low. One last time – this is something you should already be doing. If you aren’t, the effort is low to implement, and quite valuable to help protect not only your network but everyone else’s. To verify this action, MANRS will ask you to run CAIDA’s Spoofer which will report if packets with forged addresses can leave your network. Running the tool is quick and easy. I would recommend running it periodically. The client can be left running to test in the background. I’ve installed the Linux client on a few Raspberry Pis and let them run weekly tests.

Estimated time: Initially, a few hours for research and testing; ongoing, an hour per year for verification and any changes.

Summary

There is no fee for an organization to join the MANRS Network Operators Program. The level of effort, initially, is a few to several hours of research and record keeping, and potentially making some configuration changes. Once that is done, maintaining compliance is simple and should be part of your normal network operations procedures.

If there are questions on how to implement or perform any of these actions, please ask – the community is here to help you help us all secure the shared global infrastructure.

Join the MANRS Network Operators Program!