ROA quality

Last update: {{timestampString}}

Please wait: loading data...

It's worth the wait!

Update (17 April 2016): I have reorganized the classification of ROAs in order to display what was previously classified as "other problem ROA". Now all ROAs causing problems are shown, even if we can't explain the reason of the invalidity in some of them. Moreover I'm now also trying to detect cases in which an announcement is made from a wrong AS number which has a very similar AS-name string as the correct one. More info pressing the botton below.

In this table we show some of the problematic ROAs present in the RPKI repositories.

Every ROA is used for validating a number of BGP announcements. Whenever a ROA is causing a BGP announcement to be considered invalid, we list such ROA on this page. While some of these invalid BGP announcements might be the result of the ROA doing its job, most of the problems listed here are due to mis-registration of ROAs from operators.

Here we present problematic ROAs in two categories:

  • Questionable ROAs: ROAs for which there are some BGP announcements passing validation and others failing it (so it is partially causing problems).
  • Problem ROAs: ROAs for which there are no BGP announcements passing validation (so they are only causing problems).

For each ROA we present the list of all (valid and invalid) BGP announcements. For all invalid BGP announcements we then try to deduce the reason why the announcement failed validation.

As we said, most of the problems are due to mis-registration of ROAs made by operators. For most invalid BGP announcements we are able to detect and show the problem as one of the following cases:

  1. The ROA is covering the prefix of the BGP announcement, however the maximum length field of the ROA has been incorrectly set, making the announcement invalid.
  2. The origin AS of the BGP announcement doesn't match the AS authorized in the ROA, but the correct AS (listed in the ROA) is present on the AS_PATH.
  3. The origin AS of the BGP announcement doesn't match the AS authorized in the ROA. However the AS-name (whois "name" field) of the invalid origin AS is very similar to the AS-name of the correct AS (listed in the ROA).

Case 1 represents with high probability an error in creating the correct ROA, or deaggregating something without checking what is registered in the ROA. For example: ROA maximum length 18 ( is registered, but is announced.

Case 2 represents with high probability a provider who registered a ROA for its prefix, but forgot to create a ROA for each customer who is announcing part of the provider's address space (PA space). For example: provider announce and register a ROA for, but a customer announce from a different origin AS.

Case 3 represents with high probability an error by the operator who registered a ROA for a given AS, but later sent the BGP announcements from a different AS of the same organization (i.e. for BGP anycast purposes). For example: provider register ROA for,AS1 but laters announce from AS2. We can detect such case because AS names reported in the WHOIS tends to be very similar. For example AS1's name is "My fancy provider AS" and AS2's name is "My fancy provider corp", so we can try to deduce that the two strings are related.

Invalid BGP announcements not falling in the categories above might be the result of another less common case of mis-registration (such as problems in the address transfers procedures). Some other examples manually inspected, as well as other details, are listed at page 67 and before in my thesis. Ultimately, other invalid announcements not falling in the categories above might be "properly" caused by a mis-origination.

"Satisfied ROAs" are ROAs which correctly validate all BGP announcements they match. We don't list them (they are a lot).

Note that when we talk about ROAs, we are talking about "ROA records". A single ".roa" file may contain several ROA records. We do all counting on number of records (prefix,maxlen,asn), not on number of ".roa" files.

Nearly all these problems could be solved by operators by checking their ROAs, reason why this page exists.

Satisfied ROAs: {{rirdata['v4']['green']+rirdata['v6']['green']}}

Prefix Maximum length Authorized AS Detected problems Links
({{roa[3].length}} BGP announcements matching this ROA)
Prefix announcedAS PATHMatching ROAsProblem detail
{{ announcement[0] }} {{asnx}}{{asnx}} {{matchingroa[0]}}-{{matchingroa[1]}}, {{matchingroa[2]}} Maxlength problem Invalid origin, shadowing ROA Wrong origin configured?

Source data for BGP announcements

Contact: info at this domain