By Jorge Cano, Senior Software Architect at LACNIC
The evolution of the LACNIC RPKI (Resource Public Key Infrastructure) and our organization’s ongoing commitment to improving Internet infrastructure security have led to significant progress in implementing RPKI in the region, laying the foundation for a more secure and stable future for Internet routing. Over the last three years, our organization has devoted considerable effort to changing RPKI to strengthen the resource certification process in the region.
We have helped increase global routing security by using Resource Certificates and Route Origin Authorizations (ROAs), promoting resource certification.
We notice a sustained growth in the use of RPKI as the network operator community becomes more familiar with this technology. This helps them make informed decisions to improve their routing security.
(Free access, no subscription required)
DIFFERENCES
Every organization that has RPKI through LACNIC and uses it via the MiLACNIC platform is using hosted RPKI. In other words, LACNIC is responsible for everything related to managing cryptography, such as storing cryptographic keys, generating and storing certificates, etc. Organizations are only responsible for generating route origin authorizations (ROAs) through a web interface.
On the other hand, delegated RPKI is very similar to DNS delegation. A DNS NS record, a kind of pointer, is configured in the certificate tree. All certificates corresponding to a series of numbering blocks must be retrieved from a certificate authority under the tree.
FOUNDATIONS
The LACNIC RPKI architecture comprises three layers: the RPKI core, which is the most complex part and handles all cryptographic processing; the pubserver and pre-validation layer, which validates the material that is produced, prepares the repository, and checks what will be published); and the front-end layer, which offers and publishes the validated content.
DIFFERENCES
Every organization that has RPKI through LACNIC and uses it via the MiLACNIC platform is using hosted RPKI. In other words, LACNIC is responsible for everything related to managing cryptography, such as storing cryptographic keys, generating and storing certificates, etc. Organizations are only responsible for generating route origin authorizations (ROAs) through a web interface.
On the other hand, delegated RPKI is very similar to DNS delegation. A DNS NS record, a kind of pointer, is configured in the certificate tree. All certificates corresponding to a series of numbering blocks must be retrieved from a certificate authority under the tree.
FOUNDATIONS
The LACNIC RPKI architecture comprises three layers: the RPKI core, which is the most complex part and handles all cryptographic processing; the pubserver and pre-validation layer, which validates the material that is produced, prepares the repository, and checks what will be published); and the front-end layer, which offers and publishes the validated content.
During the RPKI core migration process, we found that one of the most delicate aspects of making changes to an RPKI system is preserving the integrity of the clients’ cache. This is why we conducted extensive testing with different versions of various RPKI validators to verify that our changes wouldn’t affect the community, other than the need to restart the validator in the case of some older versions.
It’s been more than 15 years since the first versions of LACNIC’s RPKI were released
In late 2022, we began working on the assumption that the old RPKI core had to be replaced, and once again we decided to use an open source product called Krill.
Krill is an implementation featuring a Certificate Authority (CA) and publication server that can operate as a delegated child of an RIR, or as a trusted anchor. By using Krill as core, we at LACNIC were able to focus our resources on developing and implementing RIR-specific features. After a couple of years’ work, we managed to bring the new core of the LACNIC RPKI into production.
This is how we managed the migration to the new system—by adapting the development to our users’ database—and arrived at a configuration where the final step was simply changing some DNS records.With this we achieved a sustainable platform.
WHAT ARE THE NEXT STEPS?
When we talk about RPKI, we always talk about origin assurance by signing prefix origins. The next step is signing the path. Two different strategies have been proposed for path assurance: BGPSec (a Border Gateway Protocol security extension) and ASPA (Autonomous System Provider Authorization). LOAs will also be able to be signed with RPKI using RCSs.
You are probably one of the communities that use RPKI the most and have the clearest understanding of the operational reality of the protocols involved. That’s why I look forward to receiving your suggestions, complaints, and comments at rpki-admin@lacnic.net.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.
