Cleaning up your RPKI invalid routes

By on 28 Apr 2021

Category: Tech matters

Tags: , , ,

1 Comment

Blog home

As more networks start to implement RPKI Route Origin Validation (ROV), it’s good practice to regularly check your Route Origin Authorizations (ROAs), to ensure they are consistent with your Border Gateway Protocol (BGP) announcements. A ROA contains information about which Autonomous System Number (ASN) is authorized to announce which IP prefix. Networks that have implemented ROV consume this information to prevent routing incidents such as route hijacks and leaks.

If you make a mistake when creating your ROA, such as a typo in your origin ASN or incorrect MaxLength, the details in your ROA will not match what is seen in BGP. Networks implementing ROV can’t see if an ‘RPKI invalid’ is caused due to an error in the ROA creation or a route hijack, so they may drop the prefix.

Recently, RIPE NCC announced that they will enable ROV on their network, AS3333, and start rejecting RPKI invalid routes. While APNIC has not implemented ROV on our network, AS4608, some of our upstream networks have implemented it and more are in the process of doing so.

If your network has RPKI invalid routes, you will not be able to reach the APNIC network and access APNIC services, including MyAPNIC, in the following scenarios:

  1. Your upstream provider(s) have implemented ROV and start rejecting RPKI invalid routes
  2. A network, somewhere between APNIC and your network, starts rejecting RPKI invalid routes
  3. All APNIC upstream providers start rejecting RPKI invalid routes

You will need to use a network that has an RPKI valid or unknown announcement to access MyAPNIC and fix your incorrect or outdated ROA.

On 27 April 2021, we saw 3526 RPKI invalid routes for IPv4 addresses delegated to APNIC Members:

Validation resultIPv4 countIPv6 count
Invalid AS55637
Invalid AS and ML45624
Invalid ML2514456
Total3526517

Table 1 — Validation counts for IPv4 and IPv6 on 27 April 2021, collected from Routeviews collector SG and Routinator 0.8.3.

Incorrect ROA MaxLength

The majority of these RPKI invalids are caused due to invalid MaxLength. The MaxLength attribute is used to specify the most specific prefix (maximum length) that the AS may announce.

As an example, if you have a /23 IPv4 prefix and you announce it as an aggregate /23, you can create a ROA for that prefix with a MaxLength value of /23. However, if you deaggregate and start announcing a more specific /24, your /24 announcement will be seen as RPKI invalid to anyone doing ROV. Therefore, you must be cautious when specifying your MaxLength value, making sure it will cover all your actual announcements.

Fixing your incorrect or outdated ROAs is quite easy. First, you need to identify the ROA that is causing the RPKI invalid. You can validate ROAs using any relying-party software, or you can try RIPE’s web-based RPKI validator.

The following is an example of what you will see when you search for a prefix under the ‘BGP preview’ page of the RPKI validator.

Figure 1 — RIPE Validator’s BGP Preview.
Figure 1 — RIPE Validator’s BGP Preview.

In this example, AS58445 is announcing the aggregate /22 prefix as well as all the deaggregate /23 and /24 prefixes. While the /22 and /23’s announcements are RPKI valid, all /24 announcements have RPKI invalid MaxLength.

Clicking on the invalid entry will show you the details of the ROA that is causing the RPKI invalid.

Figure 2 — RIPE Validator’s announcement preview.
Figure 2 — RIPE Validator’s Announcement Preview.

In this example, a ROA has been created for 116.206.132.0/22 authorizing AS58445 to announce this prefix with a MaxLength value of /23. For this reason, the more specific /24 announcements are considered RPKI invalids.

About this example.

At the time of writing, we contacted this Member to make them aware of this RPKI invalid. They subsequently updated their ROA and gave us permission to use this example to help others.

How to update your ROA

 Updating your ROA only takes a few minutes, by following these steps:

  1. Login to MyAPNIC
  2. Go to Resources > Routes (under Route Management)
  3. Search for the relevant prefix
  4. Click on Edit
Figure 3 — MyAPNIC’s route management.
Figure 3 — MyAPNIC’s route management.

If you have specified an incorrect MaxLength value, simply update the value and click on ‘Submit’. That’s it, you are done.

More information: See the Route Management guide.

Figure 4 — Editing routes in MyAPNIC’s route management.
Figure 4 — Editing routes in MyAPNIC’s route management.

Keep in mind that the prefix and Origin AS values in a ROA cannot be edited. If you have any outdated ROAs that are no longer needed, simply delete those ROAs and create a new one, if you haven’t already done so.

The APNIC Services team has been actively reaching out to Members to make them aware of their RPKI invalid routes. APNIC is also making several improvements to the MyAPNIC route interface that will assist Members in creating and managing their ROAs.

If you need support with RPKI or any service APNIC provides, please contact APNIC Helpdesk staff who will be happy to assist.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

One Comment

  1. Bayar

    Very informative post. We, Mobinet LLC have checked the ROA status of ours it seems all correct now. Ic thank you for the support APNIC team

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Top