Secure Internet Routing with RPKI

Wrong routing decisions can have a big impact

The Internet is more important than ever. Large companies rely on the Internet for services that need to be reachable at all times and from everywhere in the world. These companies do everything to provide services reliably to their clients. However, sometimes that is not enough. In reality, third parties, often by accident, can be responsible for the disruption of an online global service. That means that the Internet routing infrastructure isn’t sufficiently protected against the injection of wrong routes.

YouTube and Pakistan Telecom

The most well-known example was the hijacking of YouTube’s IP prefixes by Pakistan Telecom in 2008. Due to an unauthorised route announcement out of Pakistan Telecom’s AS17557, the prefix 208.65.153.0/24 got hijacked. Normally, Pakistan Telecom's transit provider wouldn’t allow this prefix and would drop it. It turned out, however, that the routing filters set by transit provider PCCW Global weren’t configured properly so that this route was propagated across the entire Internet. As a result, a quarter of all the IP addresses covered by 208.65.153.0/22 (held by YouTube) was not reachable anymore.

Prefix hijacking

The example above is an extreme case of IP prefix hijacking, but it is a problem that still occurs on a regular basis. Not all companies that peer on an Internet Exchange Point or through private peering have route filtering in place and therefore run the risk to pass on wrong routes. This can result in traffic not ending up in the right place. Route filters and max-prefix limits for limiting the number of prefixes advertised by an AS are being used, but are not the most elegant solutions and do not protect against all risks.

Resource Public Key Infrastructure is the future

Over the last few years a lot of work has gone into deploying RPKI and its making the Internet routing infrastructure more secure. If one uses RPKI for Route Origin Validation, every route is validated against a set of certificates called Route Origin Authorisations (ROAs). ROAs are certificates that contain a combination of a prefix and an AS Number. For example:

ASN: 15703
Prefix: 87.233.0.0/16
Max length: 18

This ROA specifies that 87.233.0.0/16 will only be seen as a valid route if it is originated by AS 15703. The maximum length indicates how long specific routes can be. In this case, all four /18s within the /16 are allowed to be announced separately. Should a /24 from that range be announced, it will be marked as invalid (See this RPKI video for more information).

Assigning the validation status

Marking a route as invalid doesn’t really mean anything yet. The validation status of a route is used in routing policies. For example, the local preference can be set such that valid routes are preferred over invalid ones. It is also possible to completely ignore invalid routes and not include them in the routing table at all.  Currently this is not advisable because RPKI deployment is still pretty low. There isn’t enough information available yet and the percentage of RKPI validated routes is still relatively low.

Setting up ROAs yourself

To create your own ROAs, you need to set up a Certificate Authority (CA) first. You can set it up yourself if you want to keep control over the entire process. However, it is also possible to use one of the hosted services provided by the Regional Internet Registries (RIRs). The RIPE NCC implemented a system in the LIR Portal that makes it easy for RIPE NCC members to create their ROAs. That way you can easily assign ROAs to all prefixes originated by your AS.

RPKI for a better organisation

Using the RPKI information of these ROAs means that better routing decisions can be made in the future. The current model in which ASNs trust each other doesn’t work so well anymore in the large Internet of today. The addition of RPKI can lead to better organisation of the Internet routing infrastructure. Before RPKI can be used in day-to-day operations though, it is important that the vast majority of the Internet deploys it. The RPKI Dashboard shows that RPKI has been adopted by just under 6% of all routes. That’s way too low for a system that has been invented to make origin validation possible for the entire Internet. The more ASes are going to use RPKI, the more useful the information in the system will be. Even if you don’t make use of RPKI information in your routing configuration, it is useful to create ROAs for your routes so that other parties who want to deploy RPKI an do so.

BGPSEC

In addition to origin validation, RPKI is also going to be used for BGPSEC . BGPSEC is an extension of BGP that makes origin and path validation possible. This means that the entire path from A to Z can be protected instead of only the destination. It’s going to take some time until BGPSEC is deployed, but it would make it much easier if RPKI would be widely deployed by that time.

The future

More people must be ready to use RPKI by creating ROAs. If enough ASes have set up ROAs, the RPKI system can be used for origin validation. At the moment, we have a chicken-and-egg situation where the deployment of RPKI doesn't have operational benefits yet, but if nobody uses it, it will never be useful! Therefore it is very important that every AS creates their ROAs. With the available tools this is not difficult at all.

On Sunday, 2 November, the RIPE NCC will provide a free training course in London just before the start of the RIPE 69 meeting. RPKI will also be a topic of this course.

This article was first published on the true.nl blog (in Dutch).