Making MANRS Even Easier to Implement – Last Call for the MANRS BCOP Document

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.

Promoting MANRS to a Wider Audience

MANRS Logo 150x150We 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!

NORDUnet and SUNET join MANRS

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!

RFC 7908 Defines “Route Leak”

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
   [Wijchers].

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

   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.

Japanese Translation of MANRS Document Now Available

MANRS_Japanese_ScreenshotWe 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!

JPNICと日本のコミュニティに感謝!

Discussing MANRS at RIPE 72 Next Week

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:

https://docs.google.com/document/d/1fQxknkC3_ggdNnPF3NfaWFpmc4ajTonVQIiD9DYBhlg/edit?usp=sharing

We welcome your review and contributions. We expect that shaping up of the document will continue in the RIPE BCOP TF.

More Fraudulent Routing = More Need for MANRS

MANRS Logo 150x150Last week Doug Madory from Dyn Research presented a new set of examples of fraudulent routing, this time coming out of the Ukraine. Most of them are cases of address squatting, when a network announces an arguably unused space to do bad things like spam or malware.

They often do this (a) to hide and redirect attribution for these bad things if they are discovered, and (b) to avoid being banned by various blacklists. Like parasites, they hijack someone else’s address space, exploit it for awhile, and then move on.

Doug has observed two concerning trends. First, criminals’ assumptions are not always correct about how “unused” the address space is. A seemingly unused space can be used once in awhile, like the APRICOT network that is only used about four weeks a year. But when this usage clashes with a hijacking the impact can be severe, leading to a massive denial of service on the network.

A second trend is that criminals are getting better at hiding. Not only announcing others’ space, but also forging the AS path – a BGP attribute showing networks that routing information passed through to get to a specified router. This forged path shows the correct origin for the announced address space, so it is hard to detect and hard to filter out.

The good news is that incidents like this can be spotted and prevented if more networks begin watching more carefully what their customers are announcing. And the more networks do that, the fewer opportunities there are for criminals to exploit the global routing system, undermining its stability and security.

The MANRS actions are aimed exactly at that. MANRS defines a new industry norm for routing security that will to a great extent prevent incidents like this and improve confidence in the routing system of the Internet.

Are you a network operator already implementing the MANRS actions? Sign up today to show your support for MANRS! Interested in learning more? Read the full MANRS document and its expected actions, or contact us with any questions.

MANRS In The News!

CIO MANRS ShotThe Internet Society’s Andrei Robachevsky recently discussed with IDG News Service Collaborative Security, MANRS, and how we can work together to make the Internet’s routing system a safer and more stable place. In Fixing the Internet’s routing security is urgent and requires collaboration,” Andrei and others discuss anti-spoofing, DDoS attacks, and more.

Regarding MANRS, specifically, here’s a snippet of the article:

Implementing the MANRS recommendations, which are based on existing industry best practices, can have some short-term costs for ISPs, but according to ISOC, that’s probably not the reason why many of them have failed to implement them. The bigger problem, the organization believes, is a lack of awareness about these problems or not having the expertise to fix them.

The methods through which routing leaks and IP address spoofing can be dealt with are diverse and currently documented in different places across the Internet. That’s why ISOC and the MANRS members are working on a Best Current Operational Practices (BCOP) document that will bring those recommendations together and provide clear guidance for their implementation.

The goal is to assist the small, regional ISPs with adopting these measures, because they make up around 80 percent of the Internet, said Andrei Robachevsky, ISOC’s technology program manager.

We encourage you to read the whole article, and if you haven’t already looked into MANRS, do it and sign up now!

Paving the Way Forward for MANRS

How do you get a community effort off the ground and make it a success? How do we even define success? Is it the number of participants, general awareness beyond its participants, or new parallel activities that the effort stimulates? Last week during NANOG 66, several MANRS participants met to discuss the challenges we want to address in 2016 and beyond that are critical to the success of this effort.

Someone recently commented that MANRS will start paying off when it begins to motivate network operators to implement the outlined Actions in order to join the initiative. That is, indeed, our objective and that is what we really see as success.

We are not there yet. In the 14 months since MANRS launched, the membership has grown steadily, but the questions remain: What are the main components that can grow it faster, solidify the membership, and mature the whole effort?

In our view there are three: Scalability, Credibility, and Community.

Scalability is about how we facilitate exponential growth and wider promotion of MANRS. We discussed a few potential ideas for us to will work on:

  • Encourage and support existing participants to become active ambassadors of the effort and MANRS.
  • Allow participants to publish guest blog posts related to their experiences on the MANRS website.
  • Develop guidance on how an organization can leverage MANRS to differentiate itself; market it internally and externally; and encourage customers, peers and suppliers to meet this security baseline.
  • Design a cool t-shirt, for MANRS members only.

Credibility is crucial. The attractiveness and motivation to join can be severely affected if operators don’t believe existing participants are running their networks above the norm documented by MANRS. There are two possible avenues to explore:

  • Compliance tests. For some Actions, such tests are relatively easy and we are already doing them when evaluating sign-up requests. Is up-to-date contact information recorded in the PeeringDB, RADB, or RIPE? Does the network publish its routing policy in one of the IRRs?It is more difficult to tell if the first two Actions are properly implemented by looking from the outside. Can you say if a network has deployed measures preventing wrong announcements from its customers, or those originated in the network itself? Probably not. But you can infer the opposite – there are potential holes in a network’s outward defense – if you observe announcements from it. It has the caveat of having false negatives, but it is better than no checks. That is what we are probably going to develop: look at the network’s BGP activity over past, say six months, and see if there are “suspicious” events that need further explanation.

    It is almost impossible to test from the outside whether or not a network blocks packets with spoofed source IP addresses (see, for example http://www.internetsociety.org/doc/addressing-challenge-ip-spoofing). Fortunately, there is a tool operated and maintained by CAIDA called Spoofer that we can ask a potential participant to run to verify compliance with Action 2.

  • Vouching. When building trusted communities, it is common to use vouching when accepting new members. In many cases, peers, upstreams, and customers have a pretty good idea of the quality and security of a network they are dealing with. This probably cannot be the only acceptance test, but vouching for new members can positively contribute to the credibility and further strengthen the community around MANRS.

Community is probably one of the most important elements, since it makes the effort both scalable and credible. How can we make MANRS not a one-off sign-up event, but a continuous collaborative activity? Like security in general, MANRS is not a product – it is a process. Here, participants offered three ideas:

  • Develop a BCOP document that provides guidance for practical implementation of the Actions. This activity is already underway.
  • Use the member-only mailing list for MANRS participants to discuss issues and coordinate actions in a more trusted environment than on a public NOG list. This mailing list already exists.
  • Encourage MANRS participants to contribute to related activities, like URSA.

It was only a lunch meeting, and we could not touch on all aspects or do a deep dive into any specific issue, but the discussion provided great feedback and guidance for the improvements and expansion of the effort.

What other ideas do you have for bringing MANRS to the wider global technical community?

MANRS news: 3 New Members & A New BCOP Document is Born

We’re happy to announce that recently the list of MANRS participants has grown. Three network operators from Russia have now supported the initiative. They are:

Fastnet (UCA Networks)
Meganet-2003
Invest Mobile

These networks have already been using practices that meet the MANRS requirements, but initially doubted the benefit of signing up to the initiative itself. Fortunately we had a lively and useful discussion at the BoF session “BGP: Towards a Better Protocol and Practices” at the MSK-IX Peering Forum last week and that motivated some of the operators to look at the initiative again.

Another news is that following Job Snijders presentation, “MANRS Implementation Document” at the BCOP Task Force meeting at RIPE71 a few weeks ago, we corralled a group of volunteers to move this project forward.

To continue discussions and produce a draft document for wider review we created a mailing list at https://elists.isoc.org/mailman/listinfo/manrs-bcop. Feel free to subscribe and get involved if you are interested!

Otherwise – stay tuned, or sign up for MANRS yourself!