Feedback Requested: Avoiding Commons Pitfalls in Managing ROAs
A MANRS task force has developed a set of recommendations to help increase the resilience and security of Route Origin Authorization (ROA). We would love to have your feedback.
The fear of every network operator is to learn that they have either unintentionally leaked Border Gateway Protocol (BGP) routes or that their own networks have been hijacked. That is why today’s Internet requires stronger protection at the core of its routing.
The good news is that over the last couple of years, more and more networks have enabled Resource Public Key Infrastructure (RPKI)-based filtering of invalid BGP announcements. But the increased reliance on RPKI comes at a cost as any hiccup in the RPKI infrastructure can have negative effects on how traffic is routed on the Internet.
It is therefore important that Operators of RPKI Services (ORS) – primarily those who operate a so-called hosted RPKI from their customers – provide quality, secure, and robust services to consistently meet the needs of the entire industry. To this end, among other recommendations, the task force recommends that the management of ROAs should follow a set of standard practices to avoid network disruptions.
For instance, our guide proposes that ROAs should have a default validity period of 2 years and ORSs should provide an auto-renewal feature as well as an alerting system to keep the ROAs up to date.
Secondly, it is known that any unwanted change in a ROA can have adverse effect in the routing plane. For example, changing the maximum length of a ROA or the authorized ASN can invalidate underlying BGP announcements. One of the recommendations is the implementation of a ‘check and verify’ functionality as a standard service, which will systematically verify the content of any newly created ROA (or any change thereof) against the routing table.
Another recommendation is a standard API with different security levels to create, update, and delete ROAs across all registries.
Currently, the RIRs are the main operators of the RPKI services, therefore consistency of abovementioned features across the five RIRs is important. Below is a table with the current implementation status of the proposed mechanisms by each RIR.
The document is available here. Once we have addressed all comments, it will be updated and published as a MANRS document to inform further efforts, such as development of a common API.
Please share your feedback with us by emailing [email protected] no later than 3 September 2021.
Leave a Comment