Please Adopt Me! Sincerely, Resource Public Key Infrastructure

An emerging security technology being implemented on the Internet helps secure the global routing table. Originally standardized in 2012, Resource Public Key Infrastructure (RPKI) addresses a shortcoming in how network service providers connect to each other and to customers to share routing data. Four years later, adoption of this important technology remains low, especially in North America — and especially in higher education. Implementing an RPKI program on your campus network is neither expensive nor difficult and will go a long way to ensuring the stability of this critical shared resource we have come to rely on.

IP Addresses

Internet Protocol (IP) networks are a critical resource for all campus operations. Campus IT infrastructures handle key administrative functions, building automation control, core functions of research, online learning management systems, and classroom multimedia technology. The growth in cloud-based services has blurred the campus border, requiring continuous availability of Internet resources.

IP addresses are the core of your network's identity on the global Internet. Like phone numbers, they identify your organization and its resources to the rest of the world. IP addresses can be stolen or hijacked instantly and may result in loss of Internet connectivity and/or diversion of your traffic. Until recently, your institution could not "prove" ownership of its IP address, and the Internet "trusts" that evil-doers won't attempt to steal IP addresses. The Internet is too big to differentiate between trustworthy organizations and evil-doers without a formal, traceable method of authentication.

A Brief Primer on Internet Routing

Unlike the public switched telephone network (PSTN), which has country-specific authorities that provide addressing and routing structure, the Internet is completely decentralized. While telephone numbers are hierarchical and require manual configuration to route between and among providers, IP address blocks can exist anywhere at any time and can be added, withdrawn, or moved dynamically using the Border Gateway Protocol (BGP).

Generally, large networks such as those run by campuses connect to one or more service providers and "speak" BGP both to learn about the topology of the Internet and to announce to the world the IP addresses the network serves. If your campus has been assigned a block of addresses, say 172.22.0.0/16, your campus border routers will announce to your providers, such as Internet2, that they are willing to receive traffic for those addresses. That tells the world your network identity. There is nothing inherent in BGP that prevents another organization from making the same announcement or claim. This false claim, called route hijacking, happens either inadvertently through misconfiguration or deliberately through malicious action. The current method to prevent route hijacking relies on the upstream providers, the networks receiving such announcements, to perform a sanity check — something that is neither universal nor foolproof.

RPKI Certificates

No central organization controls the Internet. Still, we need some way to handle basic coordination to ensure assignment of unique addresses to each network connecting to the Internet. RPKI provides a method to authoritatively verify the relationship between a block of IP addresses and an autonomous system (an autonomous system, or AS, represents a network run by a single entity such as an Internet service provider, a large company, or a campus).

Organizations called Regional Internet Registries (RIRs) will issue certificates (or delegate authority to generate certificates) to verify that an entity's claim, through its BGP announcement, is authorized. Network operators wishing to check such claims can collect these certificates and verify their authenticity. Five RIRs coordinate and manage the assignment of "number resources" on the Internet, specifically IP addresses and autonomous system numbers (ASNs). Until recently, when an RIR assigned or allocated an IP prefix to a network, there was no authoritative way to verify that relationship. RPKI fills that gap.

Advice on RPKI for the CIO, CISO, and Engineer

Depending on your role at your institution, RPKI will raise different issues for consideration.

Advice for the CIO

Chief information officers must first and foremost understand that failing to act poses an ongoing risk to the institution. The possibility of a hijacking event, either through an innocent mistake elsewhere on the Internet or for nefarious reasons, is real for all of us. Just as your college or campus protects its brand identity through trademarks, as CIO you need to protect your IT identity through RPKI.

How can you do this?

• Prioritize the need to establish Internet infrastructure security via RPKI within your security and network engineering teams.
• Discuss your RPKI activities with your peers.
• As key services move outside your data center, require the SaaS or cloud provider to demonstrate use of RPKI to ensure that the network resources used are protected with RPKI. For smaller institutions that don't manage the campus border infrastructure, again, require the service provider or carrier to use RPKI to secure the IPs assigned for your use.

Additionally, consider encouraging Internet2 to both adopt this technology on its backbone and develop programs to help member institutions adopt RPKI.

Advice for the CISO

Chief information security officers know full well that the IT infrastructure — key to the success of any institution — was not designed with security in mind. The Internet represents a cooperative agreement between thousands of organizations to connect to a common infrastructure, voluntarily using the same rules, or protocols. This system grew out of a much smaller world where the participants either knew or implicitly trusted each other. Security, and identity in particular, was left out.

For the most part, many of those shortcomings have been addressed, if only through bolt-on technologies. Telnet has been replaced with secure shell, FTP by SCP, and plain-text web (HTTP) by HTTPS. In the case of HTTP, we now almost exclusively provide our servers, sites, and applications with certificates that can "prove" their identity through a chain of trusted cryptographic certificates. But what about the global routing infrastructure itself? This part of the infrastructure isn't user-facing and has largely escaped the attention of security improvements, still relying on human-to-human trust.

Like many issues facing CISOs, preparation is key. RPKI provides the tools to avoid network hijacking events. I recommend you:

• Assess the risk a hijacking event would have on your network.
• Prioritize an RPKI deployment to protect your institution's internet identity.
• Educate your CIO and other decision makers in order to help allocate resources.

Advice for the Engineer

RPKI has two key parts: signing your organization's route announcements and validating the announcements from other organizations. Each of these parts can be implemented independent of the other, making deployment easier.

To prove that an IP prefix you are announcing is properly assigned to your institution, you must create one or more route origin authorizations (ROA) that contain a list of prefixes and the origin ASN along with an expiration date and optional mask length range. There are two options for making these ROAs available for other networks to validate: hosted or delegated.

In the hosted model, you use the infrastructure of your Regional Internet Registry (RIR) to create and host each ROA. This is by far the easiest way for a campus to start participating in RPKI. The RIR maintains the infrastructure to sign the ROA and make it available to others to download and validate. In North America, the American Registry for Internet Numbers (ARIN) maintains a web interface that allows a campus engineer to easily generate and request an ROA be signed.

Alternately, you may run your own certificate authority (CA) and use the delegated model of RPKI. In this case, you will need to request a delegated resource certificate from ARIN, which will allow your institution to sign its own ROAs as well as ROAs for customers or other organizations that receive address resources from you. This approach also requires that you maintain the hardware, software, policies, and procedures to run a CA, which includes publishing a Certification Practice Statement (CPS). You will also need to maintain highly available infrastructure to host the resource certificates, ROAs, and Certificate Revocation Lists (CRLs) that other networks will use to validate resources assigned to your organization.

The second part of RPKI is collecting and validating the ROAs of other networks, and then optionally acting on this information.

Collection and validation are accomplished with software external to your routing infrastructure. An RPKI validator collects and processes the ROAs. There are a number of such tools, for example, RIPE's RPKI Validator and Dragon Lab's RPKI Tools.

Once running, you establish a connection to your border routers with the RPKI-to-router protocol. Cisco IOS, IOS-XR, Alcatel SR-OS, and Junos support RPKI. The outcome of the validation process results in a prefix being in one of three states, as detailed in Section 2 of RFC 6483:

• Valid: the route is covered by at least one ROA and matches the proper origin AS
• Invalid: there is a mismatch between the AS in the ROA and the announced route or the prefix is more specific (longer mask) than what is covered by the ROA
• Unknown: No matching ROA found for this route

Best practices for what to do with this information is still being developed by the operational community. Given the large amount of the address space not covered by ROAs, it is not advisable to simply drop all unknowns, or even invalid prefixes.

As a campus engineer, if your CIO or CISO hasn't asked you to investigate and plan an RPKI deployment, you should initiate the discussion. Educate upwards — your IT management might not be aware of the risk. Also, share your experiences with peers at other institutions. Peer pressure in this situation is good! RPKI benefits from the "network effect" where the more it is adopted, the more useful it becomes.

Sharing Responsibility

The security and integrity of the global route table is a shared responsibility. Participating in RPKI is a low-effort activity that protects not only our own institutions but also the global network that we all rely on. As historic leaders in the Internet's early days, colleges and universities have both a unique opportunity and responsibility to continue providing leadership in technology.

---

Andrew Gallo is principal network architect, Division of IT, The George Washington University.