Over the last couple of years, there has been great progress in terms of RPKI ROA adoption by network operators across the world. While analyzing the BGP prefixes of nine South Asian economies (AF, BD, BT, IN, LK, MM, MV, NP and PK), notable growth of RPKI valid BGP prefixes can be observed in recent years.
As shown in Figure 1, with the rise of valid prefixes in the global routing table, there is an almost symmetrical decrease of RPKI ‘Not Found’ prefixes. That means most of those valid prefixes were previously not covered by ROAs and were marked as not found. As soon as the corresponding ROAs are published by the resource holders, the impact becomes visible.
However, invalid routes still exist in the global routing table. Despite RPKI being one of the most talked-about topics in network operators’ forums in the last couple of years, the invalid prefixes are not going away.
Combining all the BGP prefixes of those nine economies, about 1 to 2% of their total BGP announcements are invalid. It varies in terms of absolute numbers, but the usual number of invalid routes, when observed over a longer period, is more than 500 as shown in Figure 2.
With the consistent presence of RPKI invalid routes, routing incidents such as route leaks, prefix hijacks, and bogon announcements exist in most of the South Asian economies. Figure 3 shows a graph of routing incidents for those nine economies that shows a consistent presence of incidents in the region.
The incidents are interrelated with the RPKI invalid prefixes, so reducing the invalid prefixes would reduce the number of routing incidents and vice versa.
What makes a route RPKI invalid?
The RPKI state of a route in the global BGP table depends on its corresponding ROA, or to be more specific, Validated ROA Payload (VRP). According to RFC 6811, any given BGP route will become RPKI invalid if at least one VRP covers the route prefix, but no VRP matches it.
There could be three RPKI invalid route types:
- Max Length Invalid: The VRP prefix address and the BGP prefix address are identical for all bits specified by the VRP prefix length, but the BGP prefix length is not covered by the VRP Max Length.
- Origin Invalid: The origin ASN of the BGP prefix is not equal to the VRP ASN.
- Max Length and Origin Invalid: The BGP prefix length and its origin ASN are wrong according to its corresponding VRP. It is basically the prefix affected by both criteria in types 1 and 2 above.
Why are there invalid routes?
Invalid routes can exist in the global routing table for multiple reasons:
Incorrect ROAs: Mistakes in creating ROAs can potentially make a BGP prefix RPKI invalid. All the parameters that make a ROA, such as prefix, ASN, and MSA, must be accurate.
In the global routing table, many RPKI invalid prefixes exist due to misconfigured Max Length and it is the most common reason for routes to become invalid. For instance, an LIR/ISP creates a ROA for their /22 IPv4 prefix with an MSA of /22. If they announce a /23 or a /24 subnet of that prefix in BGP that would become RPKI invalid since the corresponding ROA only covers the /22 prefix and not its subnets.
Similar to the Max Length, if the ROA is created using a wrong ASN the corresponding BGP announcements would become RPKI origin invalid.
Wrong BGP announcements: An inaccurate or illegitimate BGP prefix announcement would most certainly make a prefix RPKI invalid. Prefix and AS hijacks are examples of wrong BGP announcements. However, if there’s no corresponding ROA the prefix will not be detected as being incorrectly originated and would not get an RPKI invalid status. That means, a wrong BGP announcement is not RPKI invalid until a ROA/VRP covering that prefix is found with a disagreeing, and so unmatched, ASN and/or Max Length parameter. Otherwise, it would simply be marked as not found or unknown. There are situations when an AS, not being the owner of a prefix, might need to originate the route but without a corresponding ROA that announcement might become RPKI invalid.
Not dropping RPKI invalids: While incorrect ROAs and wrong BGP announcements can make prefixes RPKI invalid, that would not be visible in the global BGP table if ISPs didn’t allow them to propagate. Many networks, including some large ISPs, have already adopted RPKI ROV and drop RPKI invalids. However, invalid routes will not be fully eliminated from the global routing table until all major operators do that.
Fix the global routing table: Who and how
We all know the famous adage ‘Trust but verify’. The Internet backbone is connected via BGP that runs on trust but how do we verify its routes? There are commendable initiatives to help implement best current operational practices such as Mutually Agreed Norm for Routing Security (MANRS), and every network operator forming part of the global routing infrastructure has an equal role in maintaining its hygiene. An invalid-free global routing table might be unrealistic at this moment, but we can all help reduce invalids by applying these best practices:
- Creating appropriate ROAs: Every resource holder needs to ensure accurate ROAs for their prefixes.
- Filtering routes: Transit providers and IXPs must apply inbound filters while receiving prefixes from customer networks. Bogon/Martian routes and unsolicited inbound prefixes should be rejected. Similarly, edge networks should configure outbound filters with peers and transits allowing only the legitimate prefixes to be advertised.
- Dropping RPKI invalids: Network operators, especially ISPs, IXPs, and transit providers should deploy ROV and fully drop RPKI invalid routes.
Awal works for BGD e-GOV CIRT, the National CSIRT in Bangladesh. He manages the network and security operations of the National Data Center.
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.