Cleaning up ROAs inconsistent with the BGP state

By on 16 Oct 2018

Category: Tech matters

Tags: , , , , ,

1 Comment

Blog home

Until recently, few network operators protected themselves from BGP hijacking attacks by implementing some form of Route Origin Validation (ROV).

One form of ROV is supported by the Resource Public Key Infrastructure (RPKI); using so-called  Route Origin Authorizations (ROAs), which allow BGP prefix-origin pairs to be validated before they are accepted by the receiving router.

An Autonomous System (AS) performing ROV is less vulnerable to receiving BGP hijacking announcements than an AS not doing so. ROV increases the chance that traffic going out of the AS is routed to the correct destination AS (if a ROA for the destination prefix exists).

Figure 1 — An example of a RPKI ROA, which authorizes AS13335 to announce the prefix 1.1.1.0/24 (other ASes are not authorized to announce 1.1.1.0/24). A BGP announcement originated by any other AS would be flagged as INVALID by any router performing ROV.

RPKI-based ROV is gaining traction (examples: 1, 2, 3, 4, 5, 6, 7), however one problem is the amount of broken legacy ROAs that cause many INVALID prefix-origin pairs.

In the past, IP holders creating incorrect ROAs weren’t a problem, as there was no negative effect of broken ROAs — considering no one performed validation. However, these inconsistent ROAs are now causing many RPKI INVALID BGP announcements (INVALIDs), which is, to some extent, blocking wider ROV adoption.

In this post, I’ll analyse RPKI INVALID BGP announcements to answer the following questions:

  • What does the distribution of INVALIDs look like across the Regional Internet Registries (RIRs)?
  • Which ROAs cause most INVALIDs?
  • Which IP holders can eliminate many INVALIDs by modifying just a few ROAs?
  • How many entities need to be contacted to solve all INVALIDs causing unreachable prefixes?

Answering these questions should help to efficiently contact affected parties, and set us on a course towards cleaning up and limiting the number of unreachable INVALIDs, so we can start identifying BGP hijacks more confidently.

Filtering INVALIDs to focus on unreachable IP space

As of 14 September 2018, there are more than 6,700 INVALID prefix-origin pairs (IPv4 + IPv6). But how many prefixes would actually become unreachable in a ROV environment?

To answer that question, I filtered the complete set of INVALIDs to those that actually result in unreachable IP space.

Here are a few examples of INVALIDs I don’t care about because they don’t result in unreachable IP space (alternative prefix-origin pairs are covering for an INVALID).

VALID/unknown less-specific available

Even though 5.1.0.0/23 is INVALID due to an ASN mismatch, it is still reachable because it is a part of 5.1.0.0/19 (which is VALID):

Figure 2 — Less-specific covers for more-specific.

VALID equally-specific available

Figure 3 — Equally-specific prefix-origin pair is available.

Multiple VALID more-specifics available

Figure 4 — Multiple more-specific cover for INVALID less-specific (100% overlap).

After filtering these cases that do not result in unreachable prefixes we are down to 2,415 (IPv4: 2,323 + IPv6: 92) prefix-origin pairs (2,403 unique prefixes). This remaining set is actually unreachable in an environment that performs ROV.

There are also prefixes with partial reachability as seen in the example below. For simplicity, let’s consider the entire prefix (202.57.120.0/21) unreachable even though half of it is reachable. So this one is also part of the 2,415 prefix-origin pairs we’d consider unreachable.

Figure 5 — Example of a partially (50%) reachable prefix.

Distribution of INVALIDs by RIR

Most INVALIDs are in the LACNIC region. This is just by the number of prefix-origin pairs; it doesn’t say anything about the size of the affected IP space since a single prefix can be more relevant (/16) than others (/24).

Figure 6 — RPKI INVALIDs and unreachable prefix-origin pairs by RIR.

Break down by reason

No. of affected prefix-origin pairs Reason
1338 INVALID_ASN
1077 INVALID_LENGTH

Break down by RIR and reason

No. of affected prefix-origin pairs RIR Reason
693 LACNIC INVALID_ASN
509 LACNIC INVALID_LENGTH
404 RIPE INVALID_ASN
334 APNIC INVALID_LENGTH
203 RIPE INVALID_LENGTH
193 APNIC INVALID_ASN
47 ARIN INVALID_ASN
31 ARIN INVALID_LENGTH
1 AFRINIC INVALID_ASN

Break down by announcing AS (top 10)

No. of affected prefix-origin pairs Announcing AS
180 AS14080
128 AS23650
111 AS52308
79 AS22080
64 AS35104
59 AS43554
52 AS52228
51  AS10299
46 AS264797
38 AS45774

In total, there are 454 unique ASes announcing unreachable INVALIDs.

Which ROAs cause most INVALIDs?

A single ROA can invalidate many BGP announcements at once. Therefore, I looked at how many BGP announcements a given ROA invalidated because fixing them first would be more efficient than fixing other less relevant ROAs.

By fixing the top 10 ROAs on this list, we could solve more than 20% of INVALID prefix-origin pairs!

The listing below shows ROAs and how many INVALIDs they cause (this is a slight simplification since multiple ROAs can invalidate the same prefix).

No. of affected prefix-origin pairs RIR ASN as seen in ROA Prefix as seen in ROA maxLength as seen in ROA
91 LACNIC AS60458 181.214.0.0/15 24
78 LACNIC AS37692 191.96.0.0/16 24
62 LACNIC AS61440 191.101.0.0/16 24
59 APNIC AS23650 61.160.0.0/16 16
54 RIPE AS43554 5.105.0.0/16 16
52 LACNIC AS52228 152.231.128.0/17 17
41 APNIC AS4809 115.168.0.0/14 14
39 APNIC AS23650 61.155.0.0/16 16
37 LACNIC AS22080 200.112.128.0/19 19
35 APNIC AS23650 61.147.0.0/16 16
32 RIPE AS43343 78.158.160.0/19 19
30 LACNIC AS52308 190.108.32.0/19 19
30 LACNIC AS52308 181.114.192.0/19 19
30 LACNIC AS33182 179.61.128.0/17 24
30 APNIC AS45774 49.213.32.0/19 19
29 LACNIC AS22080 200.112.160.0/19 19
29 LACNIC AS10986 190.114.96.0/19 22
27 LACNIC AS52308 181.174.128.0/19 19
23 LACNIC AS10620 190.147.0.0/16 24
21 LACNIC AS7195 200.25.0.0/17 17

Notifying affected IP holders

The next step (which was my initial intention when looking at INVALIDs) is to send emails to affected IP holders and ask them to address the INVALIDs. However, I believe the impact would be greater if these emails came from a trusted entity such as the RIR relevant to the affected IP holder instead of a random entity (myself) who they have never had any contact with before.

Asking RIRs to reach out to their Members also scales better since every RIR would only have to take care of their own Members. Figure 7 provides a brief breakdown of how many Members each RIR would actually have to contact (this is a rough approximation since I use the ASN and not the actual IP holder to count Members):

Figure 7 — An approximation of how many Members each RIR would have to contact to fix INVALIDs.

Sending these <500 emails could actually make a difference in reducing the number of INVALIDs.

What role do RIRs have in monitoring and informing RPKI INVALID BGP announcements?

This is a question that’s worth discussing in all regions serviced by RIRs. For me, I’d like to know whether RIRs:

  • Are currently monitoring the amount of RPKI INVALID BGP announcement prefixes resulting in actually unreachable IP space (in a ROV environment)?
  • Would be open to actively informing their affected Members about their affected IP prefixes?
  • Would encourage others to reach out to their affected Members (possibly in an automated way)?

In the event RIRs do undertake such outreach, it will be important to measure the number of prefixes that become unreachable if a router performing ROV discards RPKI INVALID BGP announcements over time to see how effective the outreach program is. NIST’s RPKI monitor has graphs but they take all INVALIDs into account, not just those that result in actually unreachable IP space in a ROV environment.

For this reason, I propose the following future steps should be considered:

  • Auto-generate results on a regular interval.
  • Analyse results based on IP space size (not just prefix-origin pair counts) — read my follow up post on this.
  • Reach out to NIST to suggest adding graphs about unreachable prefixes to their RPKI monitor.

Acknowledgements, disclaimers and data

I used RIPE NCC’s RPKI Validator 3.0–313 software with ARIN’s TAL enabled.

Don’t take the numbers too seriously; I made a few assumptions (RPKI validator 3 API documentation could be improved) and there might be some corner cases I didn’t take care of, but the results are sufficiently similar to other people’s results.

Adapted from original post, which appeared on Medium on 14 September 2018.

Nusenu cares about privacy enhancing technologies and likes Internet Metrics. He came across RPKI and routing security when measuring how resilient the Tor network is against BGP hijacking attacks.

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. Sofia

    Great article Nusenu! Thanks for your work in this area.

    I have a few comments:

    * Re: Distribution on INVALIDs amongst RIRs. I think this may have to do with the amount of IP space in the LAC region that is covered by ROAs. I think it would be interesting to consider relative figures (% of INVALIDs out of covered space) instead of absolute counts.

    * Re: Fixing ROAs to solve INVALIDs. This is assuming the ROAs are wrong. I think it’s good to keep in mind that some of this INVALIDs could be detecting actual BGP hijackings.

    Reply

Leave a Reply

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

Please answer the math question * Time limit is exhausted. Please reload CAPTCHA.

Top