What’s the AS0 ROA policy, and what should I know as a network operator?

By Augusto Luciano Mathurin, MANRS fellow

After a lot of research, you have some knowledge about Resource Public Key Infrastructure (RPKI) and how to implement it in your organization. You have registered some Route Origin Authorizations (ROAs), chosen the validator that fits your infrastructure, and configured your routers and equipment.

Everything is set up, or almost! When you start the RPKI validator, it’s necessary to configure which Trust Anchor Locators (TALs) it will use and trust. Based on what you’ve read, a TAL is a simple file that contains basic information to retrieve and verify the entities you’ll trust: The Trust Anchors. There should be five: one per Regional Internet Registry (RIR), but guess what… Some of them have more than one!

This post will explain the reasons behind this additional Trust Anchor (TA) some RIRs are implementing, and if it’s necessary to add them all.

Back to the TALs, we’ve said that they are a simple file that contains a URL to retrieve the TA and a public key to verify its authenticity. This is because there’s no single point of trust.

Instead, in RPKI, routing security follows the Internet number resources assignment scheme, with this responsibility delegated to the Regional Internet Registries (RIRs), the organizations that oversee the allocation and registration of Internet number resources, including IP addresses (both IPv4 and IPv6) and autonomous system numbers (ASNs) within a particular region of the world. There are currently 5 RIRs in operation:

• American Registry for Internet Numbers (ARIN) for the United States, Canada and parts of the Caribbean.
• RIPE Network Coordination Center (RIPE NCC) for Europe, the Middle East and Central Asia.
• Asia-Pacific Network Information Center (APNIC) for Asia and the Pacific Region.
• Latin American and Caribbean Internet Address Registry (LACNIC) for Latin America and parts of the Caribbean.
• African Network Information Center (AFRINIC) for Africa.

As the RIRs assign the IP prefixes and AS numbers to the organizations, they also act as a trusted authority for RPKI. You would expect that five TALs should be set to your validator: one for each RIR, right? Well… Not exactly. APNIC has two TALs, and some other RIRs may have an additional anchor too. Why?

To answer this, we have to understand the AS0 ROA policy. It defines a standardized way of managing BGP routing to address blocks that have not been allocated officially, and which are often used for harmful purposes like spam or Distributed Denial of Service attacks.

As we know, RPKI uses specific objects called ROAs, cryptographically signed statements about which autonomous system is authorized to originate certain prefixes in BGP. This offers a useful technique for validating BGP announcements. Basically, the ROA repositories act as an allowed list that says which ASes are authorized to announce certain prefixes.

The problem is there needs to be a way of handling unassigned prefixes that should not be advertised by any Autonomous System (AS), so the AS0 ROA policy is to bind these to AS0. As RFC 6483 says, this strategy results in some kind of blocked list:

Some RIRs have received proposals from their communities to start generating ROAs with the AS0, for all unallocated or unassigned IPv4 and IPv6 addresses under their administration space.

On August 9th 2019, APNIC made the first proposal (prop-132) and now have it fully implemented. RIPE NCC was the second RIR to make a proposal on October 22nd 2019 (proposal 2019-08) but after three versions, it was withdrawn recently. AFRINIC proposed a draft version (AFPUB-2019-GEN-006-DRAFT01) on November 4th 2019 and it’s still being discussed pending a second version. LACNIC issued its proposal on May 5th 2020 (LAC-2019-12) which was approved and is now waiting to be implemented. No proposals have been made in the ARIN region so far.

The issue has triggered debates in the community. Some have said this policy should adopt an opt-in approach whereby operators should choose if they accept AS0 ROAs. In this way, APNIC would generate these ROAs under a different TAL so operators could choose whether to include them or not. Another approach is to post SLURM files instead of creating ROAs to save efforts and costs related to maintaining a whole RPKI infrastructure.

But why is this discussion important? And what are the reasons against accepting these ROAs from RIRs?

A strong argument against this policy is the potential power it delegates to the registries and how this can lead to network blocking or censorship. It can affect networks from vulnerable areas or with fewer resources, like community networks, who might be late with their membership payments. If their RIRs mark their prefixes as invalid with a AS0 ROA, a large number of networks may withdraw their routes and there disconnect them from the Internet.

Regarding the consequence of giving the registries, or the governments from the countries where they are based, an easy way to censor or block networks, it’s important to highlight that the policy says RIRs can only create ROAs of unallocated resources.

Also, prior to AS0 ROAs, RIRs can effectively do the same thing by de-registering the member due of breach of membership agreement such as non-payment. There are many operators who actively filter based on IRR route-objects although such updates are subject to operator policy which will vary compared to the AS0 ROAs which offer updates in a matter of minutes.

It is an administrative decision of the RIRs to extend the payment deadline to avoid unnecessarily losing membership because of political issues. The policy clearly mentions that “what is unallocated resource” is an administrative decision and sometimes members fail to pay membership fees for more than a year and are still able to use the resources. Administrative decisions come under RIR bylaws and are governed by the respective boards, and the AS0 policy does not pretend to address this.

Other concerns against about this policy are from a cost-benefit perspective. RIRs must already publish which IP blocks are unallocated, but creating ROAs for them adds another point of failure and it needs more work to consolidate all the data and avoid mistakes. Costs rise if the RIR decides to publish AS0 ROAs under a different TAL because a whole new Certificate Authority and repository needs to be created and maintained.

All this implies dedicating resources, including computing resources, operational support processes, staff and so on… Of course, this is a community decision has to be made on the basis of whether it provides sufficient benefit in return for the level of membership fees. Furthermore, RIRs do not allocate or delist resources on a daily basis, so there will be minimum changes on the AS0 TAL.

In conclusion, you can already add the respective TAL to opt-in to the AS0 ROA policy for the APNIC address space, and will probably have the same option for LACNIC and AFRINIC in the near future. It seems that no RIR will implement this policy on their main TA, so there’s no need to opt out from them with some mechanism such as a SLURM file. But you can generate your own SLURM file to invalidate the unallocated address space from RIPE NCC and ARIN, which seem not to have plans to implement the policy in the short term.

By accepting the AS0 ROAs, you have a quick way to protect your network against bogon address blocks, which are often used for harmful purposes, like spam or DDoS attacks. On the other hand, if you want to have more control, you can skip these specific TALs and use customized filters. So, as a network operator, you have the freedom to choose whether to add the additional AS-0 ROA TALs or not, and we hope this post helps you to make this decision.

What is important is that you are filtering BGP announcements using RPKI. Filtering is one of the main MANRS actions that network operators should take to achieve a more reliable Internet.

Speaking of which, did your network join MANRS? If not, what are you waiting for!

Editor’s Note: This is a guest post by a MANRS fellows. Fellows are emerging leaders who strongly believe that routing security is an essential component for the future well-being of the Internet and are ready to contribute to its improvement. Viewpoints expressed in this post are those of the author and may or may not reflect official MANRS positions.