MANRS Task Force Develops New Guidelines for Managing ROAs
By Somesh Chaturmohta and Ali Monfared, Microsoft Networking
Today, we are happy to see the Mutually Agreed Norms for Routing Security (MANRS) community coming together to propose a set of recommendations for the management of cryptographic objects that are at the heart of Resource Public Key Infrastructure (RPKI).
This effort is aimed at bringing consistency into the hosted RPKI model across Operators of RPKI Services (ORSes) and preventing mistakes that might happen in Route Origin Authorization (ROA) management. The intent of these standards is to ensure that RPKI adoption across Autonomous Systems (ASes) is smoother and more reliable.
A MANRS task force, comprised of Microsoft and other members of the community, started the effort to standardize management of publication of the signed ROA objects a year ago. We are delighted to publish the final document today, “Common ROA Management Requirements and Security Standards for Operators of RPKI Services (ORS).”
Organizations represented in the task force, including Microsoft, are already leading the effort to ensure all routes originated from our networks are signed. For example, earlier this year, Microsoft announced its commitment to RPKI which makes sure propagation of its routing announcements through Border Gateway Protocol (BGP) across the Internet is secure against all origin AS attacks.
The task force is also making every effort to accelerate adoption of RPKI across the Internet community and ensure that the emphasis of these standards is to make the Internet secure and reliable.
We have identified the following best practices that contribute to a more reliable implementation of RPKI for our networks and for our partners:
- Consistent Validity – This best practice focuses on the need for setting consistent validity periods on the ROA records as well as auto-renewal of these records for members. Consistent validity ensures that organizations managing resources across the Internet registries will not have to worry about different operator policies with regards to certificate length and renewal.
- Consistent API – As customers have resources across multiple ORSs, it becomes important to have consistent APIs that allows them to ubiquitously manage these resources. Consistent APIs help eliminate customization of these management practices on the side of customers and hence contributes to the reliability of the customers’ implementation of RPKI.
- Health Metrics for RPKI Infrastructure – As more networks rolled out RPKI in their infrastructure, the task force realized the importance of having consistent health metrics from all ORSes. In the hosted model of RPKI deployment, users are dependent on the ORSes for health and RPKI information, and it is critical for users to watch for any issues declared by the publishers of the records. This information helps the users take proper actions to preserve the security and reliability of their networks when it comes to routing traffic to customers.
- Change Integration with Routing Plane – Lastly, the task force observed that inconsistencies happen in the publication of RPKI records when the routing plane information does not match the signatures announced on RPKI streams. Microsoft has taken extra measures to catch such instances of inconsistencies and protect our routing plane against them. We realize that not all organizations have the capacity to develop such in-house measures. Since ORSes have access to the routing plane information as well as RPKI publication channels, we suggest that the best place to prevent these mistakes is at the point of publishing the ROAs which is the OSR.
These best practices will ensure that organizations both large and small can easily adopt RPKI standards without having to build large and complex infrastructure, and thereby avoid making mistakes with ROA management. We remain committed to building on the security of our network for our customers and look forward to doing more to bring such security to all users of BGP and democratize RPKI for the Internet.
We hope the document will be used for other activities, including development of a full API specification and further discussions in the regional Internet registry communities. Please read it and let us know what you think using the comment function below.
Leave a Comment