The Resource Public Key Infrastructure (RPKI) is a system that supports routing security through the use of X.509 certificates and cryptographically-signed objects.
In the Internet today, the main type of object used in RPKI is the Route Origin Authorization (ROA). A ROA represents an explicit assertion on the part of an IP address holder that a given Autonomous System Number (ASN) may originate announcements for those IP addresses.
However, there is growing interest in using the RPKI in other ways. One of the efforts in this space is RPKI Signed Checklists (RSCs), as defined in RFC 9323.
What are RPKI Signed Checklists?
An RSC is a new type of RPKI-signed object that permits a resource holder to sign arbitrary files or documents with a set of Internet Number Resources. The recipient of an RSC can then cryptographically verify that the holder of those resources attests to the signed files/documents.
There are several use cases for this functionality.
Bring Your Own IP Address (BYOIP) services
Various cloud services — for example, AWS, OCI, and Azure — support the use of a customer’s IP addresses for Border Gateway Protocol (BGP) announcements from the cloud infrastructure. However, it’s not possible to rely on ROAs alone to prove the customer’s intent here as cloud providers don’t have any proof that the customer has control over the relevant resources. A cloud provider will typically require the customer to prove this by:
- Generating a self-signed key.
- Manually signing a message containing the resource range.
- Adding the resulting signature to the whois record for the resources.
This is a fairly complex process. RSCs could be used to streamline it, so as to avoid the need for interactions with whois, while also making the verification process the same for each Regional Internet Registry (RIR).
Verifying the resource holder in external databases
PeeringDB is a database external to the RIRs, maintained by network operators, for managing interconnection data. Registering ASNs in this database requires registrants to have an email domain that matches the corresponding RIR whois record. Requiring a user to construct an RSC instead would help to improve the security of the registration process by proving that the registrant has access to issue RPKI objects for the relevant resources.
Custom RPKI applications
Because the files/documents in an RSC are up to the resource holder, it’s possible to use RSCs as a container for new, customized RPKI applications without having to take the associated specification through the IETF RFC standardization process. For example, a group of companies might agree to a private object specification and then create RSCs based on those objects. This would make it much simpler to use the RPKI for ad hoc routing-related functionality.
Contact your RIR to learn more
RFC 9323 was published recently (November 2022), and the RIRs support this work in principle. Please get in touch with your RIR if you’re interested in their implementation plans.
Tom Harrison is a Product and Delivery Manager (Registry) at APNIC and co-author of RFC 9323.
This post was originally published on the MANRS Blog.
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.