Never underestimate the power of community. This has been the biggest lesson that we, in Mongolia, have learnt in our journey to become the second economy in the world to reach 100% Route Origin Authorization (ROA) coverage.
In this post, I want to share the story of how we achieved ROA coverage for all routes announced in BGP, and our future plans to achieve 100% Route Origin Validation (ROV), so that other communities can learn from and achieve similar results.
Planting the seed
Our journey started at the inaugural Mongolia Network Operator Group meeting (mnNOG-1) in September 2020. We held a social ROA signing to educate attendees about the Resource Public Key Infrastructure (RPKI) framework and why it’s important for secure global routing to create ROAs for their routes.
RPKI is a public key infrastructure framework designed to secure the Internet’s routing infrastructure, specifically the Border Gateway Protocol (BGP), against route hijacking and other attacks.
If network operators understand why secure global routing is important, and are provided some guidance in current best practices, they realize the value of building/designing their network with security in mind, including what they announce in BGP.
Although we didn’t get all attendees to sign their ROAs during the social, we planted the idea in their heads.
Getting networks operators to act
The next step was to follow up with attendees, and the broader network operator community in Mongolia, to encourage and assist them with creating their ROAs.
My fellow mnNOG Program Committee (PC) members and I, with assistance from the APNIC Training team, identified and reached out to our colleagues and friends managing networks that we knew had not created ROAs and walked them through the process using the APNIC portal. For those who are unaware of how to do it, it only requires five clicks!
How to: Creating RPKI ROAs in MyAPNIC
Below are some of my fellow PC member’s experiences with this outreach:
“We expected several confused communications with some of the operators, but some just required a single phone call or a one sentence message or email to get it done. I noticed also that after mnNOG-1, it was somehow easier/more comfortable/less interfering to call engineers of other ISPs.”
Tugsorshikh Badarch
“I called two of my contacts/friends at other networks to have a quick discussion and then sent the instruction to them via email.”
Damjinkhuu Davaasuren
“I sent email instructions to a few ASNs. In one instance, one of the engineers contacted my via Facebook and I walked him through the process on Messenger.”
Ulsbold Enkhtaivan
After around six months, these efforts got us to 87% ROA coverage. With 100% in sight, APNIC’s Tashi Phuntsho emailed in June to discuss how to reach the final 17 networks that had not created ROAs for their resource.
After more follow-up calls and emails, we finally reached 100% ROA coverage just before mnNOG-2.
While this has been a great achievement in and of itself, given that we were only the second economy to do this after Bhutan, we are only halfway to fully securing our inbound/outbound routes.
Now to get networks to filter and drop Invalids
Creating ROAs for your own routes/prefixes is just a signal to the world about which networks you have authorized to originate those routes. But for Mongolia’s networks to trust the routes/paths they learn from others, and to be protected from being directed along bogus/hijacked paths, they need to start filtering incoming route announcements from the rest of the Internet (including peers and downstreams). Mongolia’s networks will need to start dropping invalid routes, based on the existence — or non-existence — of ROAs,
Read: Dropping invalids in Mongolia
With some Mongolian operators already performing ROV, we are now continuing our outreach efforts of the past 12 months to get others to follow their lead. The challenges that we have faced so far are that they perceive it to be difficult, and they don’t wish to upset their (downstream) customers by dropping their traffic.
In terms of the former, we tell them that it doesn’t need to be a difficult process and there are simple community-proven practices that they can follow. These include:
- Understanding your platform defaults (JunOS, IOS-XE/XR, EOS), as some have unique implementations
- Deploy more than one validator/RTR server for redundancy, and be aware that the validation state defaults to ‘not found’ when the RTR session fails and ROA cache on the routers has timed out
- Monitor both your validator and RTR server
- Analyse the validation states of incoming routes before deciding to drop/reject invalids. Are there alternate paths to those invalid destinations that are ‘Valid’ or ‘Not Found’?
- If yes, then drop them.
- If no, call those networks and help them fix any accidental invalids. Also, let them know you will be dropping invalids in X weeks or months
While many are rightfully cautious about this step, not wanting to upset their downstream customers by dropping their routes, we are continually reminding them that many of their upstreams and content providers, including Google, are starting to perform ROV, which will impact their own traffic. As such, it’s best to start discussing these changes with downstream customers as soon as possible, so they’re aware of the inevitable change.
Reach out to the mnNOG team, or the staff at APNIC, for assistance at any time
Gonchig Altansukh is the manager of Network and System Planning at Skytel and member of the mnNOG program committee and coordination teams.
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.