Community comes together to make deploying RPKI easier

By on 6 Apr 2020

Categories: Community Development Tech matters

Tags: , , , , ,

Blog home

The hands-on labs were a highlight for many of the 40-odd participants who attended the RPKI Deployathon held at APRICOT 2020. (Image: Md Abdul Awal)

Signing your Route Origin Authorization (ROA) is only the first step towards securing your routes from misuse and hijacks. This was a key lesson to come out of the RPKI Deployathon workshop held at APRICOT 2020 in Melbourne, Australia in February 2020.

Supported by the Japan Network Information Center (JPNIC), who’ve been actively promoting the use of RPKI since organizing the first RPKI workshop at APRICOT 2015 in Fukuoka, Japan, the 1.5-day event attracted more than 40 network engineers from across the Asia Pacific region.

Building upon the success of the Deployathon held at APNIC 48 in Chiang Mai, Thailand, the workshop sought to develop attendees’ awareness of and ability to create and sign ROAs correctly as well as assist the wider networking community by providing feedback on tools and documentation to help validate signed routes and appropriate propagation configurations.

Read: How to: Creating RPKI ROAs in MyAPNIC

Tashi Phuntsho, who as part of a community-led team — including experts from APNIC, ISOC, JPNIC, NSRC and SEACOM — assisted in developing and facilitating the workshop. For him the Deployathon uncovered a range of issues he and his colleagues have been tracking for some time, which are hindering the deployment and usefulness of the Resource Public Key Infrastructure (RPKI) to secure Border Gateway Protocol (BGP) networks. These include:

  • Some differences in the number of ROAs observed between different validators: ROAs were missing between RIPE NCC’s RPKI Validator 3 and NLnetLabs’ Routinator 3000; LACNIC and NIC.MX’s Fort validator was missing close to 20 ROAs compared to Cloudflare’s Octorpki.
  • Cisco, Juniper and Nokia routers had different cache flush lifetimes, some configurable others not.
  • Cisco IOS-XE has a problem when it propagates an unverified prefix to iBGP peers; it is marked as valid.

“Network operators recognize the need to secure their routes but the process to do it is currently not as easy as it should be,” said Tashi. “By having operators test various deployment scenarios we can start to develop better and easier to follow practices which will reduce things from breaking. This is what all network operators fear the most and is a root cause for their reluctance to adopt new protocols.”

Tashi says he and the rest of the Deployathon team are currently collating and validating the feedback and results (watch Philip Smith’s summary of the Deployathon), and plan to report on and share these with the community in the coming months. Stay tuned! 

RPKI champions to assist with building awareness

Before 2019, the percentage of RPKI deployment in the APNIC region was among the lowest of the Regional Internet Registries (RIRs).

Figure 1 — This graph depicts the percentage of IPv4 address space declared in the RPKI Trust Anchors that is covered by ROAs. The percentage shown in this graph is computed with normalized address space (in units of /24 equivalents). Note: that RIPE NCC has included ‘legacy’ address space in its TA since October 2013. (Source: NIST)

Much of this had to do with developing awareness of RPKI and its importance, not just for securing individual and organization-wide networks, but the health of the overall Internet, given the role it can play to stop route misuse and hijacks; nobody wants their AS involved in that!

The success of its deployment in other RIR regions has been largely thanks to the maturity of their Internet Routing Registry (IRR) systems — these services provide a collective method to allow one network to filter another network’s routes — as well as individuals and groups that have taken it upon themselves to champion its inclusion as a best current practice for deploying and maintaining BGP networks.

JPNIC has played a key role in the Asia Pacific region since 2015 in this regard.

At the recent Network Information Registry (NIR) meeting held at APRICOT 2020, JPNIC’s Taiji Kimura presented on the successes and lessons they’ve learnt operating a single server to accommodate RPKI in Japan and providing support to their Members from signing their ROAs correctly and using RPKI Validators.

“We see it as beneficial and a value-added service for our members, as well as a duty of an NIR to support initiatives that secure the Internet,” said Taiji.

“We encouraged our NIR friends to also take a lead and have offered our services and experience to help with their RPKI campaigns and services in the future.

“Four NIRs have started testing the RPKI testbed and it was great to see people from some of the NIRs also participating in the Deployathon too.”

Watch: Participants and organizers share their thoughts from the RPKI Deployathon.

In addition to its support for the Deployathon, JPNIC, with the help of the APNIC Foundation, invited and sponsored participants from Internet Exchanges in Bhutan, Myanmar and Nepal to travel to and attend the conference’s RPKI sessions in an effort to develop their awareness of and capacity to deploy RPKI as well as champion its use among their members and networking communities in their own economies. Participants from Fiji also accepted the invitation, but paid their own travel expenses, recognizing the importance of developing their capacity in this area.

“It is much better to have people joining these sessions in person as it allows them to ask questions and clarify if they have signed their ROAs and configured their routers correctly to propagate them,” said Taiji.

“Further it provides us an opportunity to also learn what challenges they face with deploying RPKI so we can better develop campaigns, training and documentation to help overcome these.”

For Sonam Namgyel, the workshop validated some of the issues that he and his team at TashiCell had experienced with deploying RPKI previously.

“We tried to implement RPKI but there were some inconsistencies in RPKI validation in our multi-vendor environment: One vendor’s prefix was considered valid by its equipment but not by another vendor,” said Sonam.

“I’ll go back to my work and try to implement RPKI validation at all of our border gateways again; I hope I will be able to reject the invalid prefixes.

“At Bhutan IX, it has already been implemented in the route server, using IXP Manager, so my job is to convince our members to use the route server or do RPKI validation at their border gateways.”

Khin Sandar plans to follow suit with Myanmar IX members too: “Most ISPs [in Myanmar] don’t know about this. So, I will share the knowledge I learnt with them. We need more and more awareness.”

Video recordings of the Deployathon are available on the APRICOT 2020 website. To learn more about RPKI check out Security@APNIC.

Rate this article

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Top