Verify MANRS compliance automatically with ROSE-T

Antonio Prado and Tommaso Caiazzi co-authored this post.

Hygienic routing is critical for securing the Internet. MANRS helps mitigate the most common routing threats by encouraging organizations to adhere to a set of best practices and guidelines and proposes specific actions in four programs: Network Operators, Internet Exchange Points, CDNs and Cloud Providers, and Equipment Vendors.

In this post, we will focus on the Network Operators’ actions — Coordination, Global Information, Anti-Spoofing, and Filtering — and how we have developed a first-of-its-kind open source tool to verify MANRS compliance automatically.

The challenge of complying with MANRS

Complying with each action requires gathering information or validating network policies.

Although there are several network configuration verifiers available for network operators to use for this purpose (for example, Batfish, Bagpipe, BGPVerif), they each have their challenges, such as:

Relying on simulation or formal proofs, employing routing protocol models that may diverge from actual vendor implementations.
Being complex to understand and use.
Not being complete products or existing as early prototypes, therefore, lacking specific requirements such as implementing all BGP RFCs.

Additionally, none of these tools is explicitly devised for MANRS verification, further complicating the process of achieving compliance.

To tackle these challenges, we developed ROuting SEcurity Tool (ROSE-T), the first open source tool to verify MANRS compliance automatically. The project aims to standardize and speed up MANRS adoption, allowing network operators to finally test their configurations without relying on manual and error-prone procedures.

ROSE-T follows a ‘Trust No One’ approach. That is, it can be run locally to perform the self-assessment without relying on third-party services. Remember that ROSE-T is in the early stages of development, and currently, it can only verify the compliance of a single router configuration.

How does it work?

Suppose we want to verify the compliance of Autonomous System A (AS A) in the following network.

Figure 1 — The example network we will use to explain ROSE-T throughout this post.

To achieve this, ROSE-T performs the following five steps (Figure 2).

Figure 2 — ROSE-T main steps to verify MANRS compliance.

Step 1 — Gather

The first step is to validate the static information associated with the candidate network.

The candidate provides its AS Number (ASN), from which we can fetch the Internet Routing Registry (IRR) entry and parse the (mp-)import and (mp-)export objects. We also dump the latest full-RIB from a route collector and filter the routes originated by the candidate by checking the first ASN in the AS_PATH attribute.

With these two pieces of information, we verify that the set of networks announced to the transits ‘in the wild’ (that is, from the RIB dump) is equal to the ones defined in the IRR entry and vice versa (Figure 3). The current version of ROSE-T only focuses on checking the transits, but we plan to extend the verification to all peering in future project iterations.

Figure 3 — We combine the information of the IRR entry with the ones announced ‘in the wild’ (extracted from the RIB dump) to verify if the candidate complies with the Global Information check.

Step 2 — Parse

At this point, the candidate provides its vendor-specific configuration (for example, Cisco IOS-XR). But, for it to be easily processed by the rest of the pipeline, we need to transform it into an agnostic format.

Currently, ROSE-T exploits Batfish’s parser to do so since it understands most of the vendor syntaxes and translates them into a unified format (Figure 4). However, during development, we noticed that Batfish currently lacks some features, most importantly, it does not support IPv6. Therefore, we use the Batfish output as a baseline and extract the missing information using another custom parser that we implemented. We plan to write our own comprehensive parser in the future.

Figure 4 — We use a combination of Batfish and our custom parsers to transform the vendor configuration into an agnostic network representation.

Step 3 — Analyse

The outcome of the previous step is a data structure holding the essential information in an agnostic format. However, it lacks knowledge of the network’s relationships between the different ASes. To establish these relationships, we again rely on the IRR entry (Figure 5), which is assured to contain accurate information at this stage, having successfully passed the Gather step.

Figure 5 — We use the IRR entry of the candidate (already validated in the ‘Gather’ step) to understand neighbor relationships in the network.

We add a dummy gateway (Figure 6, ‘Internet’) to:

Interconnect all the providers in the network.
Propagate the default route top-down.
Have an AS where we can insert a hypothetical host on the Internet.

Finally, we again use the RIB dump, and for each AS, we define the prefixes originated by each of them. ROSE-T also supports multi-hop peerings, which are not shown in this example.

Figure 6 — We announce the prefixes (both IPv4 and IPv6) originated by each AS that are extracted from the RIB dump. The ‘Internet’ AS propagates the default route.

Step 4 — Emulate

At this point, we have all the information to transform the intermediate representation into a runnable network scenario. Unlike previous tools, we rely on emulation, which makes it possible to run actual software implementations and realize a network that behaves as much as possible as the real one.

We run the emulation using Kathará, an open source network emulator based on containers. Each AS is represented with a single router, for which we generate a configuration following the information contained in the intermediate representation (Figure 7).

For all the routers except the candidate one, we use FRRouting as the routing suite. As for the candidate router, we use the specific vendor container derived from the input configuration. For now, ROSE-T supports Cisco IOS-XR and Juniper JunOS, but we are working on extending the support to other vendors’ suites.

Figure 7 — We transform the intermediate representation into a runnable network scenario using the Kathará syntax.

We also plug two client machines in the emulation that will be used in the next step —one in the candidate AS and one in the ‘Internet’ AS (Figure 8).

Figure 8 — The minimal emulated network used to perform Anti-Spoofing and Filtering checks.

Step 5 — Verify

After waiting for the BGP convergence, we can perform the Anti-Spoofing and Filtering verification.

We start with Anti-Spoofing, which is performed on each provider in the network (green router in the following figures). First, we insert a client machine inside the provider AS. Then, we assign IPv4 / IPv6 addresses to each client in the network (Figure 9). There are two main challenges in the assignment:

Select subnets that are correctly announced and mutually reachable from the information at our disposal.
Select a valid random IP subnet to assign to the ‘Internet’ host that will act as the malicious subnet. Such subnet must not overlap with the other prefixes announced in the network.

Figure 9 — The network is ready to perform the Anti-Spoofing check on AS B. In the figure, each client has an IPv4 address assigned. The ‘Internet’ client acts as the malicious host (source of the spoofed packet).

At this point, we perform the actual check. We put a tcpdump on the ‘Internet’ host interface to sniff packets. Using Scapy, we craft an ICMP packet from the candidate client host. The packet has the spoofed IP as a source and the provider client IP as a destination. Two conditions can arise when sending the packet:

It is forwarded from the candidate router to the provider. In this case, we check if the ‘Internet’ client receives the packet. If so, the configuration is not compliant.
The candidate router correctly blocks the spoofed packet. If so, the packet is not received by the ‘Internet’ client, and the configuration is compliant.

As a double check, we verify that legit packets are correctly forwarded/received from/by the provider client (Figure 10).

Figure 10 — On the left, the candidate AS A does not implement correct filtering of spoofed packets towards the provider AS B, so the packet reaches the malicious host. In this case, the configuration is not valid. On the right, the candidate filters out spoofed packets towards the provider AS B. Therefore, it complies with the Anti-Spoofing check. The procedure is repeated for IPv6.

The Filtering check is performed on each customer (Figure 11, green router). First, we select a malicious subnet that the customer announces to the candidate. As for the Anti-Spoofing check, we choose a valid random IP subnet that must not overlap with the other prefixes announced in the network. Next, we wait for the BGP announcement to propagate, at which time the malicious prefix is:

Propagated from the candidate to the providers. In this case, we check the FRRouting control plane on each provider to verify if the announcement has been received. If so, it means that the configuration is not compliant;
Filtered by the candidate. If so, it means that the configuration is compliant.

Figure 11 — On the left, candidate AS A does not implement correct filtering of incorrect customer announcements. In this case, the configuration is not valid. On the right, the candidate filters out false announcements. Therefore, it complies with the Filtering check. The procedure is repeated for IPv6.

What next?

We are currently working on extending the verification from a single router to multiple routers, considering also iBGP peerings.

Next, we plan to extend the verification to the other two programs (Internet Exchange Points and CDN / Cloud Providers).

In the future, ROSE-T can be extended for additional purposes, for example, verifying RPKI deployments or Autonomous System Provider Authorization (ASPA) validation, or could release a certificate to have tangible proof that a specific network is MANRS compliant.

ROSE-T is open source, and we welcome any contribution via our GitHub repository.

Mariano Scazzariello is a Postdoctoral Researcher at KTH Royal Institute of Technology (Sweden). His research mainly focuses on high-speed networking and programmable networks.

Originally published on MANRS blog.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.