Editor’s Note: This is a summary of a blog post by authors Lisa Bruder and Moritz Müller from SIDN Labs. The full blog post can be found on the SIDN Labs blog.
Summary
- MANRS participants commit to actions improving routing security, with compliance tracked by the MANRS Observatory.
- Some existing metrics lack sufficient assurance, particularly for detecting controls that block incorrect routing announcements.
- SIDN Labs developed a prototype to simulate and test higher-assurance compliance checks.
- The prototype is available on GitHub, alongside a detailed report with recommendations for future production use.
MANRS+
To further improve routing security on the internet, MANRS is working on MANRS+, an elevated tier of MANRS for Connectivity Providers (CPs) who offer transit services to their customers. MANRS+ demands from CPs to adhere to more detailed requirements and aims to validate conformance to them with a high assurance level through measurements and audits. The MANRS+ working group developed the MANRS+ Controls Matrix to define what the requirements for different domains should be and how they should be validated (Self-declared, Audited or Measured).
In this project, we focused on the measurement of the correct implementation of four controls in the routing security (RS) domain of the control matrix:
- Route Origin Validation (ROV) (control ID: RS-01)
- Prefix Filtering of Customers (control ID: RS-02)
- Control a set of customer ASes (control ID: RS-03)
- Filtering of bogons (control ID: RS-06)
Approach and implementation
Based on discussions with Global Cyber Alliance, we decided on an approach where we measure configured filters of a CP AS by setting up two peering sessions with it. A CP AS has three main types of BGP relationships: one with its peers, one with its transit providers, and one with its customers. It provides connectivity to its customers by forwarding their (legitimate) routes to its peers and transit providers and vice-versa.
By establishing two peering sessions with the CP AS – with the MANRS+ Peer AS representing the role of a peer AS and with the MANRS+ Customer AS representing the role of a customer AS – as shown in figure 1, we can observe how the CP AS processes announcements received from its customers. This can be done by announcing prefixes from the MANRS+ Customer AS and monitoring the announcements received by the MANRS+ Peer AS. If it receives routes that should be rejected according to the controls, this is an indication of improper filtering and configuration of the CP AS router.
To estimate the feasibility of this in a production setup, we set up a local prototype using containerlab, a tool to orchestrate container-based networking labs. To simulate different types of production setups, we set up two topologies. One where the BGP sessions between the CP AS and the MANRS+ ASes are direct and one where they are configured as multi-hop BGP sessions. The latter is important since, on the internet, some tested CP ASes will not be directly connected to the MANRS+ ASes and remote peering over multi-hop BGP allows setting up sessions over intermediary hops.
Next to the routers in our three local ASes, our topology also includes two supporting components: a local Internet Routing Registry (IRR) and a local RPKI. Running a local IRR and RPKI allows easy manipulation of data for demonstration of the different control test cases.
We automate the orchestration of the tests with bash scripts. If necessary for the test, objects are added to the RPKI or IRR. After that, filters in the configuration file of the CP AS router are either disabled or enabled depending on the test case. Finally, a prefix is announced from the Customer AS and the RIB of the Peer AS is monitored. Depending on the test case, the prefix should be announced or discarded at the CP AS and therefore should or should not show up in the RIB of the Peer AS. Our repository on GitHub includes scripts for all test cases and a more detailed documentation of them.
Next Steps
From our simulations with the testbed, we could not identify any major problems that could hinder the measurement of MANRS+ compliancy using the proposed method.
However, several aspects need to be taken into consideration that were not relevant for our testbed. Our recommendations for a production setup can be found in our public report and with these in mind, the next obvious step is to carefully test the measurements on the Internet.
The post MANRS+: Assessing the feasibility of routing security compliance tests appeared first on MANRS.