At APRICOT 2020, I gave a presentation during the RPKI Deployment session looking at a trend that I’ve been monitoring with great interest, and concern, over the past year.
This trend has to do with people incorrectly signing their Route Origin Authorizations (ROAs), of which I feel we, as a community, have some blame for (more on this later).
As you can see from the graph below, RPKI validation for IPv4 prefixes (green) has been growing at a fairly constant rate since 2014. But so too has the number of invalids (red) and to a lesser extent the number of unknowns (not-founds, yellow). This is peculiar given that a rise in one should see a fall in one of the others, but this doesn’t seem to be the case. So, what gives?
Max lengths offer a clue
To understand what might be happening, I’ll go back to another presentation I gave at NPNOG in late 2019. During it I showed attendees the screenshot below of a portal that we are working on internally at APNIC to monitor the validity of global routes over time.
I want to draw your attention, as I did with them, to the Invalid Max Length (InvalidML) figure for IPv4.
Invalids due to Max Length may not seem like a major issue from a reachability point of view because you could still have an aggregate that covers your more specifics (with a valid ROA). But it is an operational issue because if you were relying on more specifics to load balance your traffic (inbound) across multiple links, they will now be seen as invalid and could be dropped by those doing Route Origin Validation (ROV). This means you would have to rely on the default BGP best-path selection, which means you’re no longer running your network.
To avoid such scenarios, while creating your ROAs, instead of going with the global routing prefix lengths (/24 for IPv4 and /48 for IPv6), or the defaults suggested by your RIR/NIR portals, ensure you match your ROA max-lengths to the actual routes you’re announcing in Border Gateway Protocol (BGP). The “Import Routes from BGP” option in MyAPNIC is a good tool to help you do this.
Having discussed this with NPNOG attendees it was pleasing to see this Invalid Max Length number drop by more than 400 in the next six weeks (Figure 3), as well as the significant drop in the number of unknowns (which is indicative of more folk creating ROAs).
Surprisingly though, you’ll note that the number of invalid routes due to origin ASes had gone up by more than 300.
What we’ve learned from assisting people when creating their ROAs is that many people seem to run separate transit and access/domestic ASes for many good reasons. One such motivation could be because they want to set up free domestic peering with their transit/downstream customers (sharing their domestic routes for free) while charging them only for Internet routes.
That’s all good and valid, but what’s happening is that people are only creating ROAs for their transit ASes whereas the routes are actually being originated from their access/domestic AS.
As such, if you are running transit and access/domestic ASes, please mirror what you do for both your access and transit ASes. Or better still, just create ROAs for the AS from which you are originating the route.
One size doesn’t fit all
This brings me back to how I feel we, RPKI proponents, all have some responsibility as to this rise in invalids.
It’s one thing to ask people to certify their resources by creating ROAs, and giving them a t-shirt for their efforts, but if we don’t factor into consideration that every network is architected differently then we’ll continue to see these counter-intuitive trends.
Instead, I think we have to hold the hands of folk who don’t fully understand the process. As part of this I think the key message should be that what you announce on the BGP table is what I (and the rest of the Internet) receive and if there is a governing ROA for that then everything is valid.
So, the next time you ask someone to create ROAs, ask them:
- What are you announcing to the Internet?
- What kind of network design do you have?
- Have you segmented your network?
Based on the answers to these questions, you and they should have a better understanding of how they should create ROAs for their network.
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.