Project

RPKI Project
ROA Cache
Configuration Examples
Miscellaneous

MF RPKI Project

Technical background

Internet routing incidents, such as "route hijackings" and route leaks, due to "routing errors" occur all over the world on a daily basis. It is extremely important to work to improve routing security across the Internet, given that these events occurring anywhere in the world are likely to affect your network and traffic.

Since BGP does not have the ability to detect "routing errors", another mechanism is needed to fully protect against these threats. Therefore, a method to enhance security is taken by filtering routes by referring to external information. As a typical example, many networks generate route filters, referring to Internet Routing Registry (IRR) . On the other hand, despite the widespread use of this method, there are some cases where the contents of the IRR are not properly maintained, and the accuracy of the information registered in IRR is not guaranteed in the first place.

RPKI is a technology that attempts to solve problems in BGP and its operation by using digital signatures to prove the assignment of IP addresses and AS numbers. If the correct holder of IP address is proved, an AS who received routes from external AS can determine whether these route advertisements are valid or not. Although RPKI has been discussed for a long time, it has become especially active in the past few years, and now many ASes are introducing it around the world. More and more networks are expected to adopt RPKI for secure Internet routing in the future.

What is RPKI?

RPKI (Resource Public Key Infrastructure) is a public key infrastructure that uses digital signatures to prove the assignment of Internet address resources, such as IP addresses and AS numbers. RPKI issues resource certificates, which are digital certificates of address resources. This resource certificate prove the validity of holding an IP address or AS number.

As shown in the figure below, the structure of RPKI is a tree consisting of Internet registries that allocate address resources. This is similar to the tree structure of Internet Registries with IANA at the top.

Each Internet registry issues a resource certificate as a CA (Certificate Authority) , guaranteed by a higher-level registry, and at the same time ensures the authenticity of lower-level registries. The five RIRs at the top of the tree are called Trust Anchors and serve as a starting point for signature verification. The Relying Party software described below validates the ROA by referring to Trust Anchors shown in TAL (Trust Anchor Locator) and following the signature tree from top to bottom.

RPKI is just an infrastructure of public keys, and by using resource certificates issued by RPKI, for example, BGP can determine routing errors.

What is ROA?

ROA (Route Origin Authorization) is the data signed by resource certificates showing "the correct combination of IP addresses and AS number to which they are assigned". Networks that have been allocated address resources from JPNIC can create and manage ROA by referring to JPNIC sites.

ROA includes the following three items:

  • prefix: IP address space
  • origin AS: The AS number to which the "prefix" has been assigned
  • maxLength: Maximum prefix length for origin AS to advertise the prefix

For example, suppose a certain AS65001 holds 10.0.0.0.0/24 and creates following ROA. In that case, AS65001 can advertise the routes that matches the original prefix length of 10.0.0.0/24, and two /25 routes that split /24 into two spaces (10.0.0.0/25 and 10.0.0.128/25) .

  • prefix: 10.0.0.0/24
  • origin AS: 65001
  • maxLength: 25

About maxLength

RFC7115 advises us that "Instead of using a long maxLength, you should register multiple ROAs with prefix length that actually advertised". This means that the prefix length of ROAs should match the maxLength as much as possible. The reason for this is to avoid the RPKI ROV judging the route to be "Valid" when a malicious AS abuses maxLength and illegally advertise the prefix. Specifically, in a situation where AS65001 advertises only /24 prefix, if a malicious AS65111 advertises /25 prefix with purporting to be AS65001, the route advertisement is considered as "Valid" in RPKI ROV. As a result, the traffic originally destined for AS65001 may flow into AS65111 due to the longest prefix match. However, in practice, route advertising and ROA managing is depends on the policy of each AS, so this point can only be treated as a recommendation.

What is RPKI ROV?

RPKI ROV (Route Origin Validation) is a technology that verifies whether the receiving routes are sent from correct origin AS or not by comparing ROA with the routing information received in BGP. If we assume that RPKI is the database and ROA is the data registered there, we can say that ROV is the implementation of a function to check the validity of a route by BGP using the data registered in the database.

In order to perform ROV on a router, it is first necessary to collect ROAs accumulated by each Internet registry and verify the validity of the digital signatures given to ROAs using the RPKI signature tree. This is done with software that plays the role of RP (Relying Party) . The RP software can also maintain a cache of ROAs whose signatures have been successfully verified. The router connects to RP's ROA cache using a protocol called RTR (RPKI to Router) and downloads the signature verified ROAs locally.

The ROV compares the content of ROA downloaded from RP with prefix and origin AS of the route received by BGP, and obtains one of the three validation results (Validity) . See RFC6811 Section 2 for more information on validation and its algorithms.

  • Valid
    • There is a ROA whose prefix matches and whose origin AS matches.
  • NotFound
    • There is no ROA with matching prefix.
  • Invalid
    • There is a ROA whose prefix matches, but the origin AS is different, or the prefix length exceeds maxLength.

The router uses the ROV Validity to determine whether to accept or discard the route. We can accept Valid and NotFound routes, and also accept Invalid routes with BGP Community, but more and more ASes discard invalid routes these days. Ultimately, more secure Internet routing can be achieved by rejecting routes that are determined to be invalid by all AS implementing RPKI ROV.

What can RPKI ROV prevent?

RPKI ROV can prevent route hijacking due to misconfiguration or operational errors. Many route hijackings occur due to these unintentional factors, and many AS are likely to avoid global routing incidents by deploying ROV.

On the other hand, as mentioned in the ROA section, ROV is not effective against malicious route hijacking. Since ROV cannot verify "Whether the origin AS of the route is really correct", it will be valid even if a route's origin AS is spoofed or a route is propagated from a malicious AS. In addition, the ROV does not prevent route leak. In order to verify that the sequence of ASes (i.e. AS_PATH) that the route comes through is correct, Path Validation is required.

Scenario

The figure below shows an overview of RPKI ROV.

1-Create ROA

Assuming that AS65001 is assigned IPv4 address 10.0.0.0/20 by JPNIC and advertise it to the Internet. ROA creation for AS65001 can be done through the RPKI system operated by JPNIC.

In most cases, you can create ROAs using the RPKI system of the Internet Registry who allocated the resources to you. On the other hand, if you want to operate the RPKI system yourself, you can also operate the CA (Certificate Authority) software as shown as "ISP" in the signature tree in Figure 2 and connect to the RPKI signature tree.

The created ROAs is stored in a repository managed by each Internet registry or ISP that operates its own CA.

2-Retrieve and validate ROA with relying party

As mentioned above, RP (Relying Party) retrieves ROAs from the repository and cryptographically validates the digital signature given to the ROAs. The RP uses TAL (Trust Anchor Locator), a file containing the Trust Anchor's URL and public key, to connect to the RIR's repository, and while traversing the signature tree, it obtains and verifies ROAs, including those registered in its repository. For example, APNIC's TAL can be found at here. ROAs are transferred using protocols like rsync and RRDP.

RP is able to cache ROAs that have been successfully verified. It exposes the cache and inputs ROAs to BGP routers connected with the RTR protocol.

When you actually perform ROV, it is recommended that you run the RP inside your own network instead of using the RP published on the Internet (for example, MF RP ) . This is due to the fact that rsync does not encrypt communications (some RP software support encryption), and the need to provide a stable ROA cache in an environment unaffected by external networks.

3-Perform ROV

AS65002 enables RPKI ROV on border routers. The router obtains ROAs information from RP via RTR protocol. As mentioned above, since AS65002 performs ROV, RP should run inside AS65002 (in the cloud in the figure).

AS65002 is receiving routes from two ASes, each with 10.0.0.0/20 and its sub prefix. AS65001 is the rightful holder of 10.0.0.0/20 and creates ROA through the RPKI signature tree. On the other hand, AS65111 incorrectly advertises the longer prefix 10.0.0.0/21, which can be said to be causing the route hijacking. If AS65002 implements route filters that discards routes determined to be Invalid, only 10.0.0.0/20 advertised by the correct holder, not the hijacked route, can be installed in the routing table.

RPKI ROV on the route server

The route server is responsible for propagating routes received from a customer on IX to other customers, so it is required to filter routes appropriately. In particular, it is an important responsibility of the route server to prevent the propagation of routes determined to be Invalid.

JPNAP RouteFEED filtering policy

RPKI-enabled route server use the following policy for route filtering based on the validity of the ROV:

  • Valid, NotFound
    • If the route passes through other route filters, it will be accepted and advertised to other customers.
  • Invalid
    • The route is rejected.

For more information on JPNAP route filters see here. (for JPNAP customers only)

Path Validation

As mentioned above, RPKI ROV has no effect on route leak. Path Validation is required to verify the correctness of the AS_PATH in order not to suffer from route leaks.

A common technology in the context of Path Validation is BGPsec, but BGPsec is not intended to prevent route leak. It is a technology to prove that AS_PATH has not been spoofed and can prevent attacks that manipulate AS_PATH. However, there are still many challenges to be solved to make this a reality, including the increased load on BGP routers associated with signature verification, the need for high adoption rates across the Internet, and the risk of downgrade attacks that can bypass BGPsec when negotiating to establish peer with BGP.

ASPA (Autonomous System Provider Authorization) is another technology that has been discussed in the IETF in recent years, and unlike BGPsec, ASPA explicitly aims to prevent route leak. ASPA signs ASPA objects that represent the routing relationships between two ASes (just Customer and Provider in terms of BGP announcements, not business) with resource certificates issued by the RPKI and publishes them in the same way with ROA. The router that receives a route validates its AS_PATH from ASPA object, like ROV. It's got a lot of attention because it's simple, scalable, and similar to ROV. For more information, see draft-ietf-sidrops-aspa-profile and draft-ietf-sidrops-aspa-verification.

There are no implementations currently available in the real world, but let's hope that these technologies will enable more secure Internet routing in the future.

Initiatives of Internet Multifeed on RPKI

On October 1st, 2014, Internet Multifeed Co. (MF) launched ROA cache server.

The demand for route validation in BGP is growing. It can be easily hijacked and users may not reach to the correct destination by misconfiguration or malicious attack. We see many incidents, where unauthorized route advertisement (such as "YouTube incident", happened in 2008) gives negative influence to the Internet world.

While cooperating with JPNIC and some of the major router vendors, we have been testing ROA cache servers, router implementations and giving feedbacks to the community about RPKI technologies in order to improve reliability of the Internet routing since 2012.

We will continue to contribute to the enhancement of the Internet by supporting the evolution of RPKI technology.

Note

Route hijacking

It refers to an event in which an AS that do not originally possess the IP prefixes advertises them. Traffic destined to the original AS may be blackholed by the AS that caused the route hijacking. Malicious case is rare, and most of the causes are said to be human errors due to misconfiguration or operation.

Route leak

It refers to an event that advertised routes propagate beyond the scope originally intended. For example, a network with multi-homed transit connections may mistakenly advertise routes received from one transit AS to the other, and then the advertised transit AS may diffuse the routes to the Internet due to incorrect route filtering. For more information, see RFC7908.