APNIC has recently deployed some changes to its RPKI service, and is in the process of continuing developments that will be released across 2013. This article discusses the changes, and what’s on the horizon early next year.
Splitting the TAL
A highly visible change to the APNIC RPKI system recently was to split our trust anchor into five discrete parts. Before discussing why we did this, we realize that this can become quite a complex topic, so perhaps a quick primer on certificates and certificate validation may be helpful.
A Quick Primer on Certificates and Validation
RFC3779 defines a method of specifying Internet Number Resources in Public Key Cryptography (PKI) Certificates. RPKI is a framework that has been defined to use this method to specify PKI outcomes relating to IP addresses, encompassing secure routing. This RPKI framework combines the IP address registration hierarchy with a public-private key based certification hierarchy, and provides a secure basis for attestations about IP addresses anyone can validate and verify for themselves. RPKI provides a strong, testable basis for supporting digital signatures in statements made about IP addresses.
Certificate based Public Key Cryptography (PKI) uses the concept of a “trust anchor” or TA, which is the cryptographic public key that a relying party (the ones who perform validation) is prepared to trust innately. The process of confirming that any given certificate (or an object signed by a private key whose counterpart public key is described in a certificate) is valid becomes a process of establishing if there is a “chain of trust” between the Certification Authority (CA) whom the replying party trusts, namely the Trust Anchor, and the issue of the certificate being validated. To do this the relying party attempts to construct a “validation chain”, which is a sequence of certificates where the subject of each certificate in the chain is the issuer of the next certificate in the chain, starting with a certificate issued by one of the replying party’s TAs and ending with the certificate being validated.
Conventionally, these trust anchors (TA) are obtained ‘out of band’ from any specific certificate chain being validated. For example, You may receive a large number of TAs embedded in browsers, and operating systems often use pre-loaded TAs to support the integrity of code distribution through signed code releases, such as iOS, OSX or Windows. Through the use of a validation chain, the integrity of the checking process for a digital signature now depends on the integrity of the TA itself.
The RPKI TA Framework
Managing TAs is an issue of concern in the RPKI because the integrity of the assertions will be ‘tested’ by relying parties against the TAs they hold. At present there is no single TA covering the entire span of the IP address space. Today we use a collection of TAs, where each TA encompasses a subset of the address space under separate registry management. Each Regional Internet Registry publishes its own public key as a ‘putative’ TA for relying parties to use.
TA management is not directly defined by the RPKI standards, except in respect of the TA Locator or ‘TAL’ which is a defined mechanism to be told the public key of the TA, and a URL to fetch it from. Using this TAL, a relying party can obtain a RPKI certificate, and then can use this to anchor validation chains of RPKI certificates. .A relying party can use multiple TAs, and these TAs can encompass overlapping ranges of Internet Number Resources, because the validation process is defined as finding any TA which can validate the resources in the PKI, not a specific TA.
APNIC’s TA Changes
When APNIC started deploying RPKI, it adopted a simple model of anchoring its resources in a single TA. This was easy to deploy, and reflected our understanding at the time of what internet number resources we had administrative management authority over within APNIC’s registry, as distinct from the other RIR registries that provide number resource administrative management. As the RPKI project has progressed, other RIR are now publishing their own TA, and these TAs include resources that are contained in the APNIC registry.
While it is possible to operate the RPKI with these “overlapping” TAs, it is APNIC’s goal to realign our issued certificates to accurately reflect the “provenance ” of the resources that are held in our registry. For example, if a resource in APNIC’s registry is a fragment of a larger block that is held in, say, the RIPE NCC’s registry, then we would like to use a certificate structure that reflects this. In this way we would like to structure APNIC’s RPKI certificate collection, and the associated TA material to better reflect the hierarchy of registry responsibility for internet number resource management.
To this end, APNIC recently converted its TA from a single, unified record of resources we manage, into 5 discrete components. Each component reflects a different ‘inheritance’ of resources from one of five different sources:
- Resources for which the IANA has assigned administrative responsibility to APNIC. These number blocks are described in the IANA number registries as being assigned to APNIC, such as 42.0.0.0/8 and 2400::/12
- Resources that are managed by APNIC, but have been transferred as a fragment of a larger number block that is administered by another RIR. This inter-RIR registry arrangement is typically the result of a relocation of administrative control from one RIR region to another (such as when an multinational entity decides to move Internet Number resource management from Europe to its Asian office), and, more recently, may arise from an inter-RIR address transfer.
We took the decision to make this delineation explicit, because we felt that it was appropriate to maintain a direct relationship between the RPKI certificate structure and the specific path of registry responsibility that APNIC has over those resources through another RIR,. In effect, by converting to this split TAL model now, APNIC avoids any future need to re-issue operating certificates, and the associated resources held by members in future. Given that we have few products published now, but intend promoting RPKI strongly through 2013, we have avoided a future migration for all RPKI certified members.
Other RIRs have taken a different approach and have opted to publish all resources they hold under the hierarchy of a single “root” certificate, which is, in effect, their TA. . Right now we are not sure if this represents the preferred option for the community of RPKI relying parties. If there is a desire to further simplify the APNIC TA structure it is possible to generate a single encompassing certificate and publish a single APNIC TA, but we would like to understand the larger story of the overall direction of RPKI trust anchors and the community preference relating to the management of trust anchors across the entire RPKI as a precursor to further changes in this area.
APNIC Key Management
As part of the security model for operating a TA, APNIC has implemented the key management for this level of our PKI on secure hardware, designed to protect public-private keys. The general name for this kind of equipment is a ‘Hardware Security Module’ or HSM, and the functional specifications of HSMs are documented by the US Federal Information Processing Standards or FIPS standards. HSM manufacturers must go through rigorous testing of their systems to ensure private keying materials cannot accidentally leak from the HSM. This provides an assurance that all signing made using private keys maintained on the HSM are not falsely made elsewhere. In our case this means that as long as APNIC continues to operate the HSM in line with its declared Certificate Practice Statement (CPS) and Certification Policy (CP), as naturally we undertake to do, relying parties are given a stronger sense of integrity in the signed products produced and published by APNIC.
APNIC also took the opportunity of this functional split, to re-key our existing TA, and place it, and the new TA on the HSM, and embed the dedicated use of the HSM in our operational procedures relating to TA management. We now have complete backup of all TA associated private keys, in the form of a vendor-provided backup keystore, and an alternate cold-swap HSM can now be operated with the same keys, should we suffer catastrophic hardware failure.
Standards compliance
As one of the earliest adopters of RPKI technology (APNIC was the first RIR to integrate a production RPKI subsystem into its portal in 2009,) we have found that our system has not kept pace with the changing standards environment. Elements of our code were built prior to the completion of IETF standards in this area. We had concentrated on a service delivery code development, and not targeted ‘relying party’ tools, so we did not have our own RPKI validation tools to check our published RPKI products with, against other implementations (We have internal testing systems including unit tests that encompass validation, but since these are coded using a common code base, there isn’t an independent code path inside APNIC to test our RPKI published products)
Luckily, both the RPKI.NET and the RIPE NCC engineers have written fully independent relying-party validation tools which present as web services, and APNIC was able to test its products under both. This has identified a number of incompatibilities which were due to our pre-standardization deployment.
- We hadn’t ensured that Issued certificates used the right ASN.1 encoding for textual labels. The coding library we use is part of OpenSSL exposed to Perl, and has an ‘optimization’ that if it detects a more compact ASN.1 encoding can be used, it selects the ASN.1 textform which has the shortest encoding. Since the alphabet we named elements of the system in was not defined, it sometimes selected the ‘wrong’ one. We’ve now ensured we use an alphabet which adopts the appropriate ASN.1 encoding for strings all the time.
- Some mandatory elements were missing, and others wrongly encoded.
As of the time of writing, APNIC’s published RPKI products show “all green” on the status boards for both web relying-party repository tools, and we continue to monitor this as the relying party codebase is upgraded. It is of course still possible that our published products may drift from the relying party toolset view of standards compliance, and we don’t commit that any further changes made in the relying party tool set will be reflected in our code: we might after all, have the correct interpretation of the standard! However, we are now checking this aspect of our RPKI systems much more closely and have software processes to keep our encodings and products in line with community expectations as expressed in the commonly used relying party tool sets.
Provisioning Protocol services
APNIC has been running a provisioning protocol since the inception of our web portal service. The MyAPNIC portal uses provisioning protocol to talk to the APNIC RPKI engine, to ensure strict separation between the RPKI products we make, as a registry, and the RPKI products that our members direct us to make.
However, we hadn’t provided a publicly visible port of this RPKI certificate management protocol to the wider community, and we didn not have any mechanism to exchange business PKI information, which is necessary since the messages which flow over provisioning protocol are signed CMS.
We’re in the process of writing a simple User Interface on the MyAPNIC Portal to permit members to upload their business PKI (bPKI) information, using the RPKI.NET defined XML which encodes the trust chain, behind the certificate which will be used ‘on the wire’ to sign the CMS.
By incorporating this key material into the APNIC trust set, we can validate not only that the CMS part of the subsequent protocol exchange is well signed, but that the certificate chain over it reflects the currently known authority for that member. We believe this is a good reflection of community expectations, although its details are not currently defined by any standards or draft-standard. Rob Austein, the developer, has informed us that the XML may well change in 2013 to reflect changes in his model of provisioning new bPKI relationships and we intend working to adopt his new model as it is defined.
APNIC has also identified some process complexities in migrating from an existing hosted solution (using MyAPNIC to create RPKI outcomes) to an external self-hosted system, and we are designing a User Interface which clearly identifies the transitional stages and ensures the member is clearly in charge of the process at all times. Obviously, having a an ambiguous state where there is both a “live” RPKI space in the MyAPNIC managed service area and a “live” RPKI space managed entirely by the member is unhelpful, to say the least!
RPKI User Interface changes to the MyAPNIC Portal
APNIC offers internet number resource management through a web based system called MyAPNIC. The design of this system reflects a sense of what kind of user-interface or UI we felt members needed, to manage their resources, and allows APNIC to offer a high degree of integrity in the contents of Registry. The Design of the user-interface (UI) tries to maintain a sense of consistency in operations, style of web elements, position and placement of elements of the interface.
APNIC’s original RPKI user interface (UI) was designed over 3 years ago, and reflected our sense of how users wanted to specify signing operations over their resources. We designed a system for making abstract named collections of resources, modeling the concepts like “my customers” or “my infrastructure” so that members could create signed outcomes which reflected the distinctions of use between different classes of resources held by the member.
We also made it explicit that Route Origin Attestations (ROA) had specific lifetimes and exposed the exact state of the ROA to the member.
Recently we have been looking at the kind of system being developed by the RIPE NCC and noticed that a radically simpler, and far easier to understand model had been developed by the RIPE NCC, which we think is a better reflection of how users interact with this kind of system.
What the RIPE NCC development team have done, is to hide the existence of any specific ROA from the user and concentrate on the more abstract idea of “my certified prefixes” –the user is presented with a list of what is seen in routing (ie in BGP) and what they have currently defined, each as a list of prefix and origin-AS couplets. As long as you specify you want the given prefixes to be originated by the given origin-AS, the system ensures that exactly the right ROAs are published to achieve this, and that they are subsequently kept up to date.
We liked this system a lot. We liked it so much, that we asked the RIPE NCC if we could take their design and re-implement it into our MyAPNIC portal, and a redesign is now underway, due for release early in 2013.
We see benefits in this adoption of a common UI which should help with RPKI deployment for everyone:
- Training and Promotional materials are now much more likely to be similar in both the APNIC and the RIPE NCC regions. There may even be opportunities for direct sharing of products such as e-learning packages or slidepacks.
- Members who maintain resources in both regions will have a more consistent UI experience managing their resources in each portal. The tools will look very similar and will behave in the same manner on each system.
- Reporting tools under development by the RIPE NCC such as RIPEstat and the RIS are much more likely to deliver outcomes useful to members who maintain their RPKI in the APNIC portal.
Our goal is to release an early version of the new UI timed for the APRICOT meeting in Singapore, Feb 2013. This initial UI will then be further developed and brought into alignment with the RIPE NCC portal as it develops in turn.
We hope to develop a range of promotion and training outcomes reflecting this new UI design, and aim to increase adoption of RPKI in the Asia-Pacific region as much as we can.
- Members will have simpler mechanisms to enable RPKI on their resources, and reflect their current BGP state of origination.
- Members who operate in the RIPE NCC and APNIC regions will have a more consistent service offering in both portals.
- Members who wish to self manage, and NIR will now be able to use provisioning protocol to tie themselves into the global RPKI framework respecting resources managed at APNIC. The business PKI tokens which secure this relationship will be managed using the community-accepted methods, in the MyAPNIC portal
General sign and non-BGP uses of RPKI
APNIC has been interested for some time in the ways that RPKI could be used outside of secure BGP, to improve the trust in Internet Number Resource management.
An example of this might be the ways which resource holders currently request origination of their prefix by a provider, which is a very ad-hoc process. Some members use WHOIS data to provide an out-of-band check on permission to originate. Some use WHOIS data in the form of RPSL Internet Routing Registries to construct filters, and manage their view of prefix origination. Others rely on the APNIC hostmasters to facilitate a process between different parties. We think we can use digital signatures and the RPKI to improve aspect of this situation.
APNIC has designed a general-signing model, which permits RPKI certificates to be used to sign more arbitrary attestations with RFC3779 certificates. The mechanism uses a structured signing which permits multiple signatures, and clarification of which resources are being signed against, so that everyone involved can know the certificates reflect what they consciously wanted signed over, as well as performing a formal RFC5280 PKI validation of the signed products including the RFC3779 part.
We envisage use cases such as:
- “Please can you originate this prefix for me, behind your origin AS. I have created a ROA to authorize this, but I want you now to add my prefix to your BGP configuration and provide transit, signed (prefix holder)”
- “I am interested in transferring the following resources to you for a consideration. To demonstrate I have functional control and authority over these resources, I have signed this statement with my RPKI certificate and you can compare the list of resources in this proposal with the certificate to ensure I have correctly identified the rights to transfer, signed (prefix holder)“
This allows signed attestations to be made by resource holders that can be independently validated.
This work is still under development, as we refine the documentation around how to encode the signed outcomes, and we are interested in community feedback as to what would be useful here in supporting existing and new business processes relating to the use of IP addresses.
What do you think?
We’re committed to continue improving our RPKI services, and we’d love to know what people think of these changes and the proposed activity in 2013. If you’d like to get in touch with us, please use the MyAPNIC system to contact helpdesk or hostmaster, or get in touch with us at research@apnic.net. We hope to present on this topic at the 2013 APNIC meeting held jointly with APRICOT, and in the future as we release changes to our systems
