Routing Security Survey Report: Findings IV

Routing Security: IRRs and RPKI

This post, the fourth in a series dedicated to sharing the results from a survey of network operators carried out by GCA in 2021, focuses on the use of Internet Routing Registries (IRRs) and Resource Public Key Infrastructure (RPKI) in routing security.

In the first post of the series, we provided the background of the survey mechanics, and shared the results of its demographics questions (with 51 valid responses, representing both technical and business decision-makers at networks across the world). Our second post focused on the set of questions related to the operators’ perceptions of the scale and scope of threats to the Internet’s routing system. The third and last post published to date, finally, dived into operational issues, focusing on the questions related to the operators’ current efforts in routing security.

Today, we are focusing on the questions related to operators’ use of IRRs and RPKI, especially in the context of routing security.

Remember that, if you have specific questions the data analysis might answer, we will be happy to consider them for future posts (please use our social media posts on LinkedIn and Twitter to share your thoughts, under the #RoutingSecurity hashtag). Finally, the collection of posts will be collated, polished, and published as a complete and referenceable report from the survey project.

Let’s get to our questions then.


Do your operational norms include keeping IRR data up to date for your network?

This was a simple ‘Yes/No’ question, with one answer supplied for ‘Other:’

  • Yes…, but like any norms, they are not always applied…

Do you leverage IRRs to prevent propagation of incorrect routing information?

This was another straightforward ‘Yes/No’ question, with the added possibility of expressing that IRRs had been leveraged in the past, but were no longer.

  • Yes 
  • No 
  • Used to, but do different things now 
  • Other (please specify)

The ‘Other’ answers offered were:

  • RPKI
  • If members do not correct [their] data, we will [not] propagate it
  • CAL
  • As we are only Internet service [providers] and not Internet transit [providers], we only use the BGP filter settings on our router, so as not to let propagate prefixes that are not ours

If yes, what is your motivation? 

This was a multi-select question to identify the motivation(s) of those who use IRRs for routing security:

  • Use the IRR to build filters for our customers 
  • Required by the upstream provider 
  • Other (please specify)

The answers specified under other were:

  • Required by IXPs
  • Required by IXPs
  • We also rely [on] automated filtering updates by our upstreams based on our RADB entries
  • To offer a clean and healthy number of prefixes to our members

If you are leveraging IRRs for preventing propagation of incorrect routing information, what is the estimated cost associated with these efforts?

We offered the following cost ranges to choose from:

  • Less than $1,000 USD 
  • $1,000 USD to $9,999 USD 
  • $10,000 USD to $50,000 USD 
  • Other (please specify)

The few ‘Other’ responses we got indicated that the survey respondents were not able to answer the question authoritatively themselves.

If not, what are the primary reasons for not leveraging IRRs?

We also had follow-up questions for those who were not leveraging IRRs for routing security, selecting all that were applicable from this list:

  • Not aware of it 
  • Technically challenging 
  • Consumes too many resources, causes service degradation 
  • Don’t see the return on investment 
  • IRR data is often out of date and/or inaccurate 
  • Can’t express appropriate relationships in IRR databases 
  • Using RPKI instead for route origin validation 
  • Other (please specify)

‘Other’ responses included:

  • My transit provider is protecting me
  • Dynamic updates not needed, filters manual, very few networks that transit our own
  • IRR could host (intentionally or not) erroneous information when not correctly secured


Do you leverage RPKI preventing propagation of routes with invalid origins?

This was presented as a simple ‘Yes/No’ question.

If you leverage RPKI for Route Origin Validation (ROV), how do you use RPKI? 

Respondents were asked to select all of the applicable answers from the following:

  • For registering ROAs 
  • For validating – dropping invalids 
  • For validating all announcements from my customers 
  • Other (please specify)

The one ‘Other’ response was:

  • We have not yet implemented any policy for invalids. Still under investigation

If you leverage RPKI for Route Origin Validation, what is the estimated cost with these efforts?

Respondents were offered cost ranges from which to select:

  • Less than $1,000 USD 
  • $1,000 USD to $9,999 USD 
  • $10,000 USD to $50,000 USD 
  • Other (please specify)

The ‘Other’ responses included:

  • I do not know what the cost of this is
  • Once again, this is something we have hired [a lot] of smart people for. We run global infrastructure in 30+ cloud-zones to keep our RPKI systems alive, so these are [millions] of dollars in cost

If you leverage RPKI for Route Origin Validation, are you using more than one validation?

This question provided the logic to steer subsequent questions. Answer choices were ‘Yes/No/I don’t know.’


If you leverage RPKI for Route Origin Validation, are your current BGP routers RPKI-compliant (RFC 6810 and RFC 6811)?

Digging deeper into the mechanics of RPKI usage, this question also allowed ‘Yes/No/I don’t know.’

Do you leverage RPKI for anything other than Route Origin Validation in routing security? 

Part of the purpose of the survey was to distinguish between those networks that use RPKI strictly for route origin validation, and those that use it for other aspects of routing security (all usually lumped together as ‘implementing RPKI’). Respondents could select (non-exclusively) from:

  • Not at this time 
  • BGPsec path validation 
  • ASPA 
  • Other (please specify)

‘Other’ responses included:

  • [Currently] looking at implementing BGPsec path validation
  • We generate [pseudo]-IRR objects for inclusion in IRR generated prefix filters
  • We use RPKI to facilitate BYOIP-transfers, we also are very much interested and involved in ASPA, [as well] as [in] RSC/RTA and these efforts in and around RPKI

One note about the data for this question: the option ‘Not at this time’ was only added in the final version of the survey. 11 of the 51 respondents did not have the option to select it (one of those marked ‘No’ in the ‘Other’ response).

If you are not leveraging RPKI for route origin validation, what are the primary reasons for not using RPKI? 

Respondents were asked to select as many of the following as were applicable:

  • Lack of training or awareness 
  • No immediate return on investment or financial benefit 
  • Technically challenging 
  • Consumes too many resources, causes service degradation 
  • Concerns around censorship tool by governments 
  • Current routing security measures are sufficient 
  • Other (please specify)

The ‘Other’ responses included:

  • Microtik promises this in a future release— so technical challenge
  • [It’s] on the list [of to-dos]
  • Politics
  • Current state of ROAs will result in the blocking of actual valid routes due to multi-party problems in not coordinating their ROAs
  • Not in the top priority + RPKI doesn’t solve all BGP issues (e.g., AS_PATH modification, BGP leaks)
  • We are in the process of implementing RPKI
  • Slow uptake in the region

Next time… we will go through the questions and responses related to ‘External factors for deployment, and any other considerations.’


The author, Leslie Daigle, is the Chief Technical Officer and the Director of the Internet Integrity Program at the Global Cyber Alliance. You can follow her on Twitter or connect with her on LinkedIn.