RPKI application and practice

25/04/2011

Enabling Operational Use of RPKI via Internet Routing Registries

Background:

The Resource Public Key Infrastructure (RPKI) security framework has emerged as the most secure way to secure IP address allocations and their related announcements via the BGP routing protocol. All five regional Regional Internet Registries (RIRs) either already have working prototypes in production or intend to roll them out within the next year. These developments have ensured that RPKI is likely to be the method of choice for resource certifications in the hierarchy from IANA to the RIRs and then the resource holders (ISPs). However, the deployment of RPKI at the resource administration level has not yet addressed the problem of how a large-scale adoption of RPKI for operational validation of BGP routing might be facilitated.

The Internet Routing Registry (IRR) system [1][6] is a collection of routing registries whose purpose is to allow network operators to register and lookup both their own as well as the routing policy of other networks. Based on information in these routing registries, Internet operators can then easily use automated tools to generate route filters that can help prevent the propagation of anomalous BGP update messages. In this context, the IRR system is a natural fit for helping to spread the adoption of RPKI to the broader Internet community.

The goal of this article is to discuss different options by which we can integrate RPKI into the IRR system. In particular we propose four different techniques that can help bring these two systems together. The first is to extend the Routing Policy Specification Language (RPSL) to include support for RPKI attributes. The second is to build and operate a public RPKI validation cache. The third is to modify the core routing registry software to allow it to lookup and return RPKI validity information for each route query. The fourth is to augment existing toolsets so that they can be use the RPKI information being distributed via the IRRs.  We describe these below.

Integration Options:

RPSL extensions to support RPKI:

The RPSL specification [2][3][4] has proven extremely useful in helping to promote the use of routing policies in a well-structured syntax. However though there have been sporadic attempts to extend and adapt the basic specification, few have been successful other than the efforts under the RPSL-ng umbrella to allow for IPv6 and multicast objects. We are considering whether to add additional attributes to the RPSL specification that will allow users to specify RPKI attributes. One such method that we have investigated is the addition of a roa-uri tag. This tag allows users to specify for each route object in the routing registry, a tag or pointer to the actual location of a certified attestation for that route for.  Other possible changes we are considering is adding support for an additional field such as roa-valid which will serve to simply indicate whether the routing registry have validated a given route object to be valid or not. It is also possible to add other RPKI attributes that Internet operations community might wish to use such as tags that simply indicate whether or not a given prefix has implemented RPKI, or even perhaps allow the entire x509 certificated to be stored as part of that route object.

Build and operate a public validation cache as part of RADB:

The RPKI framework [5] allows for the use of a validation cache to serve as a trusted repository of route objects that have been validated. This validation cache can then be used to lookup valid routes such that the validation does not have to be done by each router that is attempting to use RPKI validation. The validation cache can also be used to provide an easy lookup service to the Internet community for troubleshooting and debugging purposes. We could develop and operate a production quality validate cache. This cache will sync with all the five RIRs and provide to the Internet community a secondary consolidate source of validated routes. Our goal is to operate this validation cache as a production service as a part of the RADB service.

Modify IRRD software to add support for RPKI lookups:

The IRRD software, which powers much of the IRR system, is built and maintained by Merit and offered to the community under and open-source license. We could modify the IRRD software to add hooks that support RPKI lookups into a validation cache. The goal of this would be to provide the Internet community with RPKI information every-time a query is sent to whois.radb.net. The RADB whois service [7] receives over 5M queries a day and this would ensure that all queries by default obtain results that include some RPKI information. The most likely additional attribute that can be provided in the manner is a roa-valid tag. For each prefix lookup this tag can indicate whether that route is present in the validation cache and has been validated by the cache. This will allow the community to very quickly and easily determine the status of any given route with respect to its RPKI status.

Augment existing IRR toolsets to include support for RPKI attributes:

Most network operators use a standard set of tools such as RtConfig, IRRtoolset, or IRRPowerTools to query the IRR system and build router configs.  We would need to enhance these tools so that they are able to utilize the additional RPKI attributes that a routing registry can provide.

Conclusions:

While the RPKI system provides a much needed security framework for certifications of route allocations and use, it does not directly address the issue of large-scale integration into the network operational environment.  The IRR system due to its familiarity to the operations community provides us with a unique path to accelerate the adoption and use of RPKI on a day-to-day basis.

References:

[1] Merit Network Inc., The IRR System, https://www.irr.net, Feb 2011.

[2] C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra, Routing Policy Specification Language (RPSL), http://tools.ietf.org/html/rfc2622, June 1999.

[3] L. Blunk, J. Damas, F. Parent, A. Robachevsky, Routing Policy Specification Language next generation (RPSLng), http://tools.ietf.org/html/rfc4012, March 2005.

[4] R. Kisteleki, Securing RPSL Objects with RPKI Signatures, http://tools.ietf.org/html/draft- ietf-sidr-rpsl-sig-01, July 2009.

[5] M. Lepinski, S. Kent, An Infrastructure to Support Secure Internet Routing, http://tools.ietf.org/html/draft-ietf-sidr-arch-12, Feb 2011.

[6] L. Blunk, M. Karir, Internet Routing Registry, http://www.merit.edu/networkresearch/papers/pdf/2011/NANOG51 IRR Tutorial.pdf, Feb 2011.

[7] Merit Network Inc., Routing Assets Database, http://www.radb.net, Feb 2011.