In order to assist with the implementation of Resource Public Key Infrastructure (RPKI) adoption, the GT-RNOC has developed introductory labs that will assist in implementing RPKI using Dragon Research Labs Rcynic validator software in different configurations and environments. There are three sets of instructions, each building upon the previous one, to implement different RPKI architectures. All of the labs are based within GENI, (Global Environment for Network Innovations) a network simulation environment.
Organizations can implement Resource Public Key Infrastructure (RPKI) in either a delegated or a hosted model. In a delegated model, the organization decides that they will host their own Certificate Authority (CA) in addition to the RPKI servers. This allows them to have the ability to sign their own Route Origin Authorizations (ROAs) using their own generated certificates. In a hosted model, the organization will not host their own CA and instead will rely on a parent organization, such as a service provider or a Regional Internet Registry (RIR) to provide certificates and to publish ROAs. In the hosted model an organization will need to only establish an RPKI server. There are legal requirements between providers and RIRs that need to be completed, but those vary per organization and are beyond the scope of this explanation.
To assist in implementing RPKI the GT-RNOC has created the following 3 labs with the intent of getting users acqainted with implementing RPKI using Rcynic from Dragon Research Labs available at rpki.net. This software is a collection of tools that allows for the validating the status of routes, as well as the publishing of ROAs through the included CA tools. The labs begin with a basic tree network with the Southern Crossroads (SoX) network acting as a parent for the University of Alabama, Georgia Institute of Technology, and Clemson University. The labs will grow upon this network expanding the tree and adding organizations and complexity, with the final lab implementing a gateway allowing you to peer your lab environment with a border router running the Border Gateway Protocol (BGP) from your organization to see how the RPKI server validates actual routes from the internet.
The network is simulated within GENI (Global Environment for Network Innovations) using virtual machines (VMs). Each organization in the network will start out with three Linux VMs to act as a client, an RPKI server running Rcynic from rpki.net, and a router using the Quagga software routing suite. From this basic configuration the network will grow with each lab.
UPDATE (01 August 2016): Recently there have been issues regarding certificates when you attempt to download NIST's RPKI-enabled Quagga bundle using yum. In order to remedy this Symantec's Intermediate CA Bundle needs to be installed in the VM acting as the router.
- Create a file named "symantec" in /etc/pki/ca-trust/source/anchors.
- Go to Symantec's page here and copy the contents of the Intermediate CA Bundle into the file you created in step 1. It should start with -----BEGIN CERTIFICATE----- and with -----END CERTIFICATE-----. There will be 2 certificates in this bundle.
- Save the file and run the command: sudo update-ca-trust force-enable
- Re-attempt to update yum and download NIST's RPKI-enabled Quagga bundle.
RPKI Lab 01 Files
Author: Samuel Norris
In this lab the Southern Crossroads (SoX) network will act as a parent to the University of Alabama, Georgia Institute of Technology, and Clemson University networks. All of the IP addresses and ASN numbers used in this lab are private. Each organization will be using the delegated RPKI model, whereby they will publish their own certificates and will sign their own Route Origin Authorizations (ROAs). By the end of this lab you will have experience setting up an RPKI server, publishing your own certificates, publishing ROAs and making route decisions within the Quagga routers. The zip file below will include a PDF of the instructions and network map, a GENI resource specification file in XML format, MySQL Client rpm, and the NIST BGP Secure Routing Extension (SRx) bundle for Quagga routers.
RPKI Lab 02 Files
Authors: Samuel Norris & Humberto Nieves
In Lab 02 the network from Lab 01 has been expanded to a more complex version of the Southern Crossroads Research and Education network. In this lab not all organizations will be using the delegated RPKI model. The University of Georgia will be using a hosted RPKI model, where their certificates and ROAs will be provided by their parent organization, which in this example is the SoX network. Additionally Clemson has been positioned where it will connect via the C-Light network in order to reach the SoX network. This is to add an additional parent to child relationship to the network. Lastly the Georgia Institute of Technology has been given an additional connection to the SoX network to demonstrate multiple connections to the RPKI server.
RPKI Lab 03 Files
Authors: Samuel Norris & Humberto Nieves
In Lab 03 we will take the setup from Lab 02 and add BGP peer relationship between the simulated Southern Crossroads router and an external border router from your organization. The reason for this is to show how routes from the internet can be validated using the RPKI software and Trust Anchor Locators (TALs) from the various regional internet registries (RIRs). Due to the fact that this is connecting a simulated environment that is using real IP prefixes to a router connected to the internet, it is recommended that this lab only be completed if you have experience with the BGP protocol and filtering BGP announcements. If the simulated SoX router happens to announce it's prefixes to your BGP border router, there is the possibility that it can poison the routing tables and hijack the prefixes used in the lab, which is exactly what RPKI is designed to prevent.