RPKI application and practice
April 25, 2011
Enabling Operational Use of RPKI via Internet Routing Registries
Manish Karir and Larry BlunkMerit Network Inc.
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.
(Free access, no subscription required)
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.