Internet2

close
Use Internet2 SiteID

Already have an Internet2 SiteID?
Sign in here.

Internet2 SiteID

Blogs

Update on Resource Public Key Infrastructure Progress

May 27, 2020, by Steven Wallace
Tags: Frontpage News, Security, Security Scene

The Internet routing infrastructure lacks adequate security. By malice or accident, traffic can be diverted, inspected, or simply blocked. Sometimes this weakness causes a news-worthy event, such as the April 2020 hijack of Google, CloudFlare, and others, by a Russian internet service provider. As is the case with most hijack incidents, it’s impossible to tell if it was an accident (e.g., a misconfiguration) or purposeful.

The Internet’s stakeholders have agreed on a set of operational practices to improve its security and resilience. The coordinated effort to encourage their adoption is known as Mutually Agreed Norms for Routing Security (MANRS; see: manrs.org).

One component of MANRS is Resource Public Key Infrastructure (RPKI). RPKI allows the owner of a network to cryptographically sign its routing announcements with a record called a Route Origin Authorization (ROA). This enables internet service providers to detect when a fake route is being announced, and take appropriate action, such as deleting the fake route.

Internet2 is developing capabilities to mark and measure the RPKI ROA validation status of the routes we receive. We're moving an instance of Cloudflare's RPKI Validator Tools from our internal lab to its production home in the cloud. We've also created reports to understand the diffusion and status of routes associated with ROAs.

Putting the pieces together (i.e., standing up the validator, configuring routers, creating reporting software, etc.) is challenging. Internet2's route architecture, with its multiple services in separate routing tables (VRFs), is limiting our current view to the R&E routing table (i.e., AS11537). 

The ROA graph (below) depicts the number of Valid (route matches its ROA), Invalid (route doesn’t match its ROA), Unknown (the route doesn’t have the corresponding ROA), and Unverified (the validator for whatever reason wasn’t able to determine the route’s status) routes we see in the Internet2 routing table. We intend to share these graphs monthly, starting later this month.

It's important to know that Internet2's routing policy is not affected by a prefix’s ROA status. Some Internet providers, such as ATT and NTT, have announced that they drop invalids. In the future, in coordination with the community, it may improve the resilience of the R&E infrastructure to incorporate ROA status in Internet2's route policy. We're looking forward to those discussions.

Please send questions or comments to irr-help@internet2.edu.