MANRS defines 4 Actions, which are really the building blocks for simple use cases. We believe that if even these measures are implemented widely, security and resilience of the Internet routing system will significantly improve. The minimum baseline that MANRS defines also allows networks to build on, implementing routing security in more complex network typologies.
But it is easier to say then to implement. To facilitate implementation of MANRS Actions the community have developed a BCOP document – a MANRS implementation guide.
In order to make it more practical and useful we need actual configuration examples from most commonly used vendors and equipment models.
We created a simple survey to collect this information. It should take only 10-15 min to complete if you know how to configure these things. For some of the questions there are example, to give you an idea of what is expected.
Please contribute to the survey and share knowledge:
Your participation is highly appreciated!
Lats year one of the Orange subsidiaries – Open Transit Internet (OTI) joined MANRS. The company offers the wholesale Internet connectivity services and DDoS protection among others.
While OTI complied with all 4 actions at the time of joining, its engineers worked hard on strengthening security policy further, that includes, for example, monitoring potential BGP leaks and mitigating them as appropriate.
“Digital technologies and the Internet are the backbone of our society and economy. They are deeply changing our lifestyles and organizations. This is why, at Orange, as trusted connectivity provider we are always looking for greater reliability and security. The adherence to MANRS initiative is part of our commitment to cooperate with leading actors, like ISOC, in order to improve the security for all” – said Arnaud MARTIN, Chief Information Security Officer (Orange group).
BGP prefix hijacking remains a problem for Internet routing, despite the (partial) use of RPKI or detection services. In order to better understand the existing BGP hijacking defenses and the needs of network operators, CAIDA and the ICS-FORTH research institute, started a research effort, developing a survey as a first step.
The survey, which is targeted at network operators, has the objective to study several things:
– the operators’ awareness of BGP prefix hijacking attacks,
– presently used defenses (if any) against BGP prefix hijacking,
– the willingness to adopt new defense mechanisms, and
– reasons that may hinder the deployment of BGP prefix hijacking defenses.
The survey can be found here: http://tinyurl.com/hijack-survey. It has a total of 21 questions, which should take no longer than 10 minutes to answer. We encourage network operators to participate.
A summary of the aggregate results will be published as a part of an article/conference paper.
A MANRS Best Current Operational Practices (BCOP) document has been published. Its objective is to provide guidance to network operators in implementing the MANRS actions. The development of the document was done at the BCOP Task Force at RIPE where it was reviewed by the experts from the operators community.
Based on the BCOP document, a set of online training modules is under currently development. These will walk engineers through a tutorial and provide a test at the end, with a view to this being the first step towards a MANRS certification. The modules will be available as standalone ones, but we are also working with other partners who are interested in including it in their curricula.
Last week at RIPE 73 in Madrid, the MANRS BCOP document was presented and discussed at the BCOP TF session and the Routing-WG. The MANRS BCOP document “provides guidance to ease deployment of measures required by MANRS and is targeted at stub networks and small providers. The document should also assist in checking if the network setup is compliant with MANRS.”
It was agreed to give the community another four weeks of review. Last call ends on 28 November 2016, and we welcome your feedback via the RIPE BCOP Mailing List.
Although the content of the document itself wasn’t discussed at the meetings, people shared their views on the best way to publish the document once the review is complete.
In the RIPE region, a standard way to publish a completed work is to produce a RIPE document. This is a great way of making it available to the community, but some felt a RIPE document may not be ideal because every change then requires issuing a new RIPE document, and the MANRS BCOP is a bit too volatile for that.
An idea could be to rearrange the document into a stable/fundamental part and more volatile parts, and publish the first as a RIPE document. This may take some time and work.
In the meantime, we will publish the draft document on the MANRS site and refer to it from the RIPE BCOP repository, Deploy360, and other known places. We’ll assign a version number to ensure stability of the publication and consistency of references.
Please join the discussion on the BCOP mailing list and help us review the document between now and 28 November.
We are approaching the second anniversary of launching this MANRS initiative, and we have now grown to over 40 network operators. We have just published a press release about MANRS and are working to increase MANRS’ visibility in wider circles. Working together, these participating network operators are taking action to improve the resilience and security of the routing infrastructure to keep the Internet safe for businesses and consumers alike.
From the release: “Implementing MANRS helps improve Internet security and resilience and helps enable a sustainable business environment. MANRS provides added value for the network operator and its customers: better protection against traffic anomalies caused by misconfigurations; cleaner setups resulting in easier troubleshooting and lower time-to-resolution (TTR); improved peering conditions; and opportunities for valuable collaboration with other operators through a discussion forum and professional network. Although committing to MANRS has its costs, the scope of the actions is specifically defined to minimize costs and the risks of implementing them.
We are excited to embark upon this public relations outreach to inform more network operators about the initiative, grow its membership, and work toward improving routing security for everyone on the Internet.
Read the full release here, and stay tuned for a coverage recap in a few days!
Today two leading Scandinavian research and education networks – NORDUnet and SUNET – have joined MANRS.
As Fredrik Korsbäck, Network Architect at NORDUnet said:
“NORDUnet is committed to robust global routing polices and MANRS is one of the best initiatives so far to help out operators with this. We hope with our participation that more of the R&E sector will sign the Routing Manifesto and live up to the norms. We hope that in the future MANRS will be the standard, not the exception.”
Let us hope this will be an ice-breaker for network operators in Nordic countries renown for their engineering potential and attention to security.
We are looking for more leaders – networks that have already implemented the MANRS recommendations and much more – to sign up, support this effort, and encourage others!
Today over on the Internet Society Internet Technology Matters blog, I wrote a piece about RFC 7908 being published. Most of us have heard the term “route leak,” but it was a vague term without an official, technical definition. RFC 7908 now provides that definition:
A route leak is the propagation of routing announcement(s) beyond
their intended scope. That is, an announcement from an Autonomous
System (AS) of a learned BGP route to another AS is in violation of
the intended policies of the receiver, the sender, and/or one of the
ASes along the preceding AS path. The intended scope is usually
defined by a set of local redistribution/filtering policies
distributed among the ASes involved. Often, these intended policies
are defined in terms of the pair-wise peering business relationship
between ASes (e.g., customer, transit provider, peer). For
literature related to AS relationships and routing policies, see
[Gao], [Luckie], and [Gill]. For measurements of valley-free
violations in Internet routing, see [Anwar], [Giotsas], and
The result of a route leak can be redirection of traffic through an
unintended path that may enable eavesdropping or traffic analysis and
may or may not result in an overload or black hole. Route leaks can
be accidental or malicious but most often arise from accidental
The above definition is not intended to be all encompassing. Our aim
here is to have a working definition that fits enough observed
incidents so that the IETF community has a basis for developing
solutions for route-leak detection and mitigation.
In my post, I went on to say that “This definition is an important milestone in the work to make routing more secure, and in particular on mitigating or preventing route leaks from happening. Because without a problem statement, how can you be sure you are providing the right solution?”
Here with MANRS, we’re working on creating solutions. In fact, we know that maintaining up-to-date filters for customer announcements could have mitigated some known cases of route leaks. That’s why it’s already embedded in one of the Actions required in MANRS.
If you’re already implementing this (along with some of the other Actions), you’re one step ahead of the game. Sign up as a MANRS participant today to show your support, or share this with your network operator colleagues to get them moving toward a safer, more secure Internet.
We are pleased to announce that a Japanese translation of the MANRS document is now available. It is linked from the main MANRS page.
This was a community effort led by the team at JPNIC and especially Masayuki Okada with valuable contributions from network operators, namely Seiichi Kawamura and Matsuzaki Yoshinobu. Special thanks to Izumi Okutani for her energy in promoting the MANRS initiative in the Japanese networking community.
We hope that availability of the MANRS document in Japanese will raise awareness among Japanese network operators and motivate them to join this effort!
Some time ago, a group of MANRS participants agreed that it’d be a good idea to have more precise guidance for the implementation of MANRS Actions. Having such a document could serve at least two purposes:
- Ease deployment of measures required by MANRS (stub networks or small providers – the majority of ASNs)
- Help check if the network setup is compliant with MANRS
Job Snijders presented this idea and an outline of the MANRS BCOP document at RIPE71 in November 2015. The idea was supported by several network operators and experts who joined the team to develop such guidance. Since then the team has done some heavy lifting as it appeared even the implementation of basic routing security practices cannot be accomplished by a single line in a config file!
We plan to present this work at the RIPE BCOP TF on May 23 during the RIPE meeting. If you are planning to attend RIPE72, please join the discussion.
This is a work in progress, but you can find the current version of the document here:
We welcome your review and contributions. We expect that shaping up of the document will continue in the RIPE BCOP TF.