LACNIC Assists RPKI Deployment in Ecuador

RPKI deployment is relatively slow in the LACNIC service region. This is due to a "chicken-and-egg" situation - operators don't want to deploy a technology they don't have experience with, but they won't gain experience if they don't start deploying it.

We thought it would be beneficial to create some "islands of trust" where the technology is fully deployed and from which others can learn. We also wanted to find out what exactly the gaps are: What is stopping people from deploying RPKI? What are their concerns?

So, in order to overcome the "chicken-and-egg" problem, we went out and created our very own case study. This success story took place in Ecuador and we hope others can learn from it and replicate it.

The Ecuador Internet Exchange (NAP.EC) has been operated by AEPROVI since 2001 as a not-for-profit operation. There are two locations, one in Quito and one in Guayaquil.

Figure 1: NAP.EC has two locations in Ecuador

There is a special situation in Ecuador - 97% of all Internet users in Ecuador are directly connected to NAP.EC. The IXP also allows smaller Internet service providers to indirectly interconnect. This means that almost 100% of local users and traffic go through the Exchange.

Consequently the adoption of a new technology by NAP.EC and its community would result in the adoption by the entire country by default. All organisations involved in this project - large network operators, small business networks, public and private organisations - have an interest in improving the routing problems in the country. NAP.EC is an IXP with mandatory multilateral peering and route servers in each location, which makes it easier to activate origin validation and to become an island of trust.

Action Plan

We identified the following gaps in RPKI deployment and found ways in which to address them:

Human capacity building and training

In July 2013, an informal meeting took place that brought together technical staff of those operators connecting to NAP.EC. The meeting covered a short introduction to RPKI, origin validation and ROA creation, as well as the timeline and impact of the project.

Equipment

In August 2013, two Cisco ASR-1001 routers were installed as route servers (one in Quito, one in Guayaquil). For RPKI, redundant validators were implemented: 2 virtual machines, each one with two different processes, with software provided by the RIPE NCC and by rpki.net. Origin validation was implemented in the route servers and no action was taken regarding RPKI validity status.

Monitoring Tools

LACNIC provides a number of RPKI monitoring tools, for instance a looking glass, various monitoring charts, a list of announcements.

Figure 2: Looking glass available on the LACNIC tools pages

ROA Creation

LACNIC also provides a tool to create Route Origination Authorisations (ROAs).

Figure 3: The LACNIC ROA wizzard

Measuring Success

The goal of this project was to create a success story and to show RPKI working in a production environment. We wanted to achieve that 70-80% of the country's networks be covered by ROAs. We also hoped to create local capacity and expertise, while being able to use the results to inspire and encourage others to adopt similar efforts.

Community event

After the initial phase of training and installation, we organised an event on 4 - 5 September 2013 and invited all resource holders from Ecuador. At this event all resource holders created ROAs for the address space allocated to them. This resulted in a ROA coverage of 90% of all IPv4 and IPv6 address space allocated to organisations in the country. It was encouraging to see how enthusiastic the operators were in using this new technology and how keen they were to manage their customer's BGP announcements.

The graphs below show the coverage of IP address space in Ecuador and in the entire LACNIC region. Note how the events in Ecuador increased the overall deployment.

Figure 4: Percentage of ROAs in Ecuador

Figure 5: Percentage of ROAs in the entire LACNIC region

 You can find more statistics on the LACNIC RPKI charts pages .

Conclusion and Next Steps

In conclusion, although lack of knowledge and the fear of "break things" were predominant at the outset, operators were very willing to work through the process.

We are now working with local operators to help them fix their announcements or their ROAs when necessary. We are also documenting the entire process and the lessons learned so we can apply them to other countries or communities. A technical committee consisting of technical staff from NAP.EC will evaluate what to do with invalid routes: whether the routes with validity status “invalid” will be discarded or just marked with a community tag or set up to have less preference than valid routes. We are also working on an expansion of our toolset.

Acknowledgements

This project would not have been possible without the help of all involved stakeholders. In particular we would like to thank AEPROVI and NAP Ecuador for their willingness to try new things and for their work in connecting with their community. Cisco Systems was also a key player in this project. Their help with equipment procurement and in having people on the ground during the community event was also a key success factor. Thanks to everyone!

This article is based on a presentation given by Sofia Silva Berenguer at the recent IEPG meeting in Vancouver, Canada. More statistics are presented on the slides.

Please also note the document published for CITEL on the LACNIC Labs site .