RPKI tools

An ISC implementation of the RPKI drafts can be found here http://www.rpki.net/.
Since all objects published in RPKI repository are in ASN1, dumpasn1 can be used to quickly peek at the objects. Here's an example.

Sample asn1 dump

RPKI Products: ROA

Current described by this draft, Route Origin Authorizations (ROAs) associate an AS number and a list prefixes in an object which is then CMS signed by a the owner of the prefixes. By generating a ROA, the owner of the prefix is stating that the as number in the ROA is allowed to originate the prefixes listed in the ROA. Third parties can then fetch ROAs, verify their cms signature and then use validation rules as per http://tools.ietf.org/wg/sidr/draft-ietf-sidr-roa-validation/. ROAs encapsulate end entity certificates within them. A sample ROA is shown below.

Sample ROA

RPKI Manifests

Manifests are currently documented by this sidr draft. Manifest are signed objects that have a list of all the objects in a repository (except the manifest itself) and their corresponding hash. A valid manifest helps to ascertain that the objects in a publication point are fresh (latest issued) and complete i.e. none are missing.
Similar to ROAs, manifests embed an End Entity (EE) which enforces the manifest validity period. A sample manifest is shown below.

Sample Manifest

RPKI CRLs

Each engine (rpki instance with a certificate) is expected to maintain an update to date CRL that is generated at regular intervals. The CRL records any keys revoked due to product expiry or security incidences. Each certificate points to it's parent CRL by using the X509v3 CRL Distribution Points attribute (It's the parent that issued a certificate. Consequently, revocation responsibility lies with the parent).
An example CRL is shown below. The important bits:

• Authority Key Identifier and Issuer point to the issuer (certificate in previous article).
• CRL number which is incremented with each issue.
• Last update and next update time constraints.
• Revocation number and date of each certificate identified by a serial number. 

Sample CRL

RPKI certificates

Resource certificates are defined in the SIDR resource certificate profile specification. In this second part of the series, we'll start analysing a set of certificates from the AfriNIC repository (rsync://rpki.afrinic.net) from the top. We'll visit the trust anchor locator, trust anchor certificate, RIR certificate and an LIR certificate. An important point to note is that each certificate is a CA certificate with the exception of embedded end entity certificates.

Trust Anchor Locator

A trust anchor as a trusted entry point of any PKI is expected to be stable over time. However, the current practice has RIRs running their own roots with their resources specified in the root cert.

If an RIR receives an allocation, they have to issue a new certificate that contains the new resources which will have to be propagated to validators. Taking the case of IPV4, 17 blocks were allocated in a span of a year (2009). This corresponds to 1 trust anchor change every 21 days on average. On top of this, certificates have time constraints which will induce certificate re-issues due to expiry.


The TAL format is specified in the SIDR TA draft to work around these issues. Essentially, the TAL contains the rsync URI of the root certificate with rfc3779 extensions and the public key component of that certificate. These two are separated using a [CR]LF According to the specification, the public key is ``a base 64-encoded, DER-encoded X.509 subjectPublicKeyInfo [RFC5280]''.

It can easily be generated by using shell utilities and OpenSSL.
Since the TAL doesn't have resources and time constraints, It can be long lived requiring change when the key is rolled.

Here is the AfriNIC TAL.

rsync://rpki.afrinic.net/repository/AfriNIC.cer
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxsAqAhWIO+ON2Ef9oRDM
pKxv+AfmSLIdLWJtjrvUyDxJPBjgR+kVrOHUeTaujygFUp49tuN5H2C1rUuQavTH
vve6xNF5fU3OkTcqEzMOZy+ctkbde2SRMVdvbO22+TH9gNhKDc9l7Vu01qU4LeJH
k3X0f5uu5346YrGAOSv6AaYBXVgXxa0s9ZvgqFpim50pReQe/WI3QwFKNgpPzfQL
6Y7fDPYdYaVOXPXSKtx7P4s4KLA/ZWmRL/bobw/i2fFviAGhDrjqqqum+/9w1hEl
L/vqihVnV18saKTnLvkItA/Bf5i11Yhw2K7qv573YWxyuqCknO/iYLTR1DToBZcZ
UQIDAQAB

Root certificate

The root certificate sits at the root of the Resource PKI. It contains all the resources suballocated in the tree below it. In an ideal world, there would be the one root certificate and it's number resources would be:

• 0/0 for IPV4
• 0/0 for IPV6
• 1-4294967296 for AS numbers

Unfortunately, in the current structure, each RIR is running it's own root and encoding it's resources only. So for example, the AfriNIC certificate will only contain IANA's allocation to AfriNIC.

In the figure on the first post, the first dashed rectangle represents the root repository. It contains all the certificates issued by the root, a CRL and a manifest for this repository. This structure is replicated across the entire PKI tree that is, each certificate has a repository that is accessible over rsync and contains: 

• A CRL.
• A manifest.
• Zero or more products (ROAs, AAAs...) in it's repository.
• Certificates for sub CAs.

An example certificate can be seen below. It's highlights are:

• Self signed which implies that it's a root certificate.
• The location of the repository and manifest are encoded in the certificate.
• The certificate has x509 CA extensions (Green sections).
• Has rfc3779 extensions (sbgp-* sections). 

AfriNIC root certificate

Resource certificate

The root certificate is a special case of the resource certificate. A non root resource certificate has:

• A parent - Authority Information Access in a certificate.
• Zero or more children - Subject Information Access is a pointer to a store with this certificate's children.
• Zero or more - Subject Information Access also points to a store with this certificate's products. products. 

 An example tree is shown below. In this case, the root certificate shown above issues the RIR certificate in figure below which in turn issues the LIR certificate in the last figure. Please note that relationship between the certificates as indicated by the colour coding.

RIR Certificate

LIR Certificate

Introduction to RPKI

What is RPKI

Resource Public Key Infrastructure (RPKI) is the name of the game.
For the Internet to work, we need BGP¹ which in turn requires IP prefixes and AS numbers.  When an LIR or any multi homed organization wants to be reachable on the Internet, they have to peer using these number resources.

No security framework exists that authenticates whether a peer does indeed own the resource set that they are advertising. Consequently, rogue announcements² may appear on the internet that will impact on the reachability of legitimate sites. RPKI allows one to take these resources, add them into a certificate and then use these resource aware certificates to sign Route Origin Authorizations (ROA) and a set of other objects that may be defined in the future (The underlying specification documents are still in draft status For the latest and up to date specifications, please see the sidr ietf page).

Number resources are issued by IANA to the 5 RIRs. These RIRs then issue resources to LIRs/NIRs which issue their resources to their customers. Their customers may issue their resources... PKIs do follow a similar tree structure where there's a root (self signed CA certificate) issues other certificates (Which may be CA certificates that subissue ...). Consequently, every resource owner can and should have a resource certificate.


These two hierarchical structures are similar and this allows them to be tightly integrated.

An example allocation structure:

Table 1: Resource Allocation table

ORG IPV4 IPV6 ASN Function IANA 0/0 0/0 1-2**32 Issues resources to RIRS AFRINIC 196/8 2001:4200/23 327680-328703 Issues resources to LIRS LIR C 196.1/16 2001:4200/32 327680-327690 Large ISP. ISP X 196.1.0/23 2001:4200/48 327685 Small ISP.

An example PKI structure:

What is RPKI...Really?

Well:

• It allows a resource holder to prove that they do actually owns a set of resources (Binds number resources to the subject of the certificate).
• A resource holder can provide a PKI based authorisation attesting that a peer is allowed to originate a set of prefixes on their behalf (In simple terms, I am a small company X who buys bandwidth with A & C. A ROA can be created to attest that only A & C can advertise X's prefixes)
• CRLs are also published and their distribution points listed in certificates.
• Certificates, CRLs and products such as ROAs for each authority publication point are listed along with their hashes in a signed structure that is published. This structure is called a manifest(mft).
• CA certs, CRLs, MFTs, ROAs are published in a repository to the world over rsync and optionally https.
• Validation tools exist that can validate an entire repository tree

Next, A quick peek at sample RPKI certificates.