Aim of the Article
This article is a two parter looking at how Jisc is using RPKI to protect its customers. This first episode describes how we are protecting customers by dropping potentially malicious or incorrect routes at our boundary so that customer traffic is not black-holed or routed to potentially harmful resources. Part two will describe the role of ROAs (Route Origin Authorizations) in RPKI (the unit of cryptographically signed information that is at the heart of RPKI) and how Jisc is assisting all customers to be further protected by providing a ROA creation service.
What is RPKI?
BGP is the routing protocol used across the internet to share information about where to send packets. It was created at a time when the internet was much smaller and trusted. There is no build in mechanism to know if the information within a prefix advertisement can be trusted.
RPKI is a system that aims to allow a BGP peering router to reject a prefix advertised to it if it is not from the prefix’s owner. This protects against route leaking/hijacking where a router advertises a prefix falsely, either maliciously or because of human error. The devices receiving these invalid routes would then (without RPKI) send traffic in the wrong direction.
Software on the router compares received BGP advertisements with databases of RPKI records. If the prefix is from the wrong ASN or has a smaller prefix than the owner states it will advertise, the router should drop it. Typically the legitimate route is then allowed to be used and traffic flows correctly.
This article isn’t going to add to the long list of resources explaining in detail what RPKI does. For further reading see the list of resources at the end of this article.
Current State of RPKI and Why Only Invalids are Dropped
There are three validation states for each route received:
- valid
- invalid
- unknown
We can infer from a typical full internet routing table after validation the quantity of prefixes that have an associated ROA. According to NIST about 57% of IPv4 prefixes are valid today. The same site shows the change over time of the state of BGP received advertisements as shown below. My rough extrapolation suggests at the current rate the vast majority of prefixes will be covered by ROAs by 2031.
The picture is better for IPv6, possibly because most prefixes are covered by modern LIR based allocation which often includes the automatic creation of ROAs. But in general ROA creation is optional and requires knowledge & effort from end customers. In my opinion LIR/SP need to do better (see part 2).
Uptake of RPKI is a slow with the trend starting about 15 years ago but in theory there is an end state as described above. What happens close to that point is described in a later section.
Today it isn’t possible do drop unknown prefixes as there is no certainty whether they are legitimate or malicious. 90%+ of unknowns are legitimate destinations but without an admin who has taken the necessary steps to protect their asset. In the UK a large percentage of IPv4 address space associated with universities is within this category. The lack of network operators dropping unknown prefixes is small enough that those that haven’t created ROAs for their prefixes will not experience issues. Yet.
There is a continuous move in the right direction with lots of ISPs blocking invalids, possibly at a greater rate than ROA creation. For example:
February 22, 2024 – Deutsche Telekom (AS3320) One of the largest ISPs in Europe, now filters RPKI invalid routes received by its global network. [source]
Tipping Point
As suggested in my extrapolation above, we could reach a tipping point in a few years time when the vast majority of prefixes have ROAs. At some stage security risk adverse networks will drop all but valid. They will consider the small percentage of unknowns to be from locations that don’t consider security a high priority and therefore the risk of their users not reaching important resources is lower than connecting to them. This should accelerate ROA creation to close the gap even quicker. In some areas of the globe the RIR makes it easier for address space holders to create ROAs, incorporating it into standard database editing/creation for example. If this is adopted more widely the acceleration of ROA creation will be amplified.
Even so, this might not happen for years unless some larger ISPs mandate it for prefixes they source. In other words the community needs to not only drop invalid prefixes (relatively easy) but encourage the creation of ROAs (like herding cats). Hence Jisc’s two pronged approach.
What is Jisc Doing?
Jisc has invested in infrastructure to facilitate the dropping of invalid prefixes from all external peering routers. This includes the geographically disperse servers that act as validating cache servers. We have tested the effects of first validating and then dropping invalid routes on large internet facing routers over the first half of 2025. Over the summer of 2025 we will continue the changes to routers that enforce our new policy.
As well as spotting and dropping invalids we will also add well known BGP communities to all prefixes so that the small number of research members who take a full internet table from us can observe the remaining prefix status.
What Will Customers Notice?
The vast majority of users and customer IT teams will not notice anything. In the same way as we don’t notice an email provider removing obvious spam for us. The protection is there nonetheless and can be spotted if you are keen.
If you want to experiment there is a way to test both on campus and from your home network the following two sites offer tests.
https://isbgpsafeyet.com/
https://rpkitest.nlnetlabs.net
I found that I got different results from both but using the IP address 103.21.244.9 proved that on domestic broadband via Zen the route was dropped while 104.17.230.6 was permitted. During July 2025 customers using the Janet network will likely not see either being dropped while we carefully complete changes to the very large number of external peering (see last section). Please give this a go and add a comment with what you found.
Members that receive a full routing table will notice a small reduction in size and the addition of communities:
- origin-validation-state-invalid members 0x4300:0:2
- origin-validation-state-unknown members 0x4300:0:1
- origin-validation-state-valid members 0x4300:0:0
An example Junos CLI output for an example invalid prefix:
> show route 103.21.244.9 table inet.0 hidden detail > > inet.0: 987174 destinations, 1602298 routes (987167 active, 0 holddown, 57 hidden) > 103.21.244.0/24 (2 entries, 1 announced) > BGP /-101 > Next hop type: Router, Next hop index: 1071 > Address: 0x145ce05c > Next-hop reference count: 5591 > Source: 195.66.244.71 > Next hop: 195.66.244.71 via ae1.0, selected > Session Id: 0x505 > State: <Hidden Ext Changed> > Inactive reason: Unusable path > Local AS: 65527 Peer AS: 13335 > Age: 2w0d 2:19:32 > Validation State: invalid > Task: BGP_13335.195.66.244.71 > AS path: 13335 I > Aggregator: 13335 10.34.23.28 > Communities: 13335:10063 13335:19020 13335:20000 13335:20500 13335:20530 unknown iana opaque 0x4300:0x0:0x2 > Localpref: 100 > Router ID: 162.158.32.1 > Hidden reason: Rejected by import policy
Why Bother?
One key point I want to add here is that while readers might consider the small number of invalid routes seen on the internet today a non issue, that figure could rise sharply if large scale attacks were to be implemented. It is also worth considering that even a single prefix that was blackholed or led to a bad part of the internet could mean a bad day for many users within our community. Especially if that hijacked route was the customer’s own IP space. The benefits come when the full internet plays nicely together.
The parallel with IPv6 is that we know we should be doing the thing, but the thing takes effort, and we can’t see the benefit immediately. So why bother? The first reason is that route injection prevents users getting to the resource they want or in rare cases could cause a connection to malicious versions of content. By dropping the invalid prefix the original (valid) route is used. The less direct reason for Jisc’s action is to be a good internet citizen. Similar to recycling if one person doesn’t do it the effect isn’t noticed. But if everyone does it the effect is huge. By embracing RPKI and making a little noise about it we hope to encourage others to do the same. Eventually the goal of 100% ROA coverage should remove this form of attack entirely. Consider how little we think about web certificates any more (apart from the chore of administration). It would be nice to get to that state with routes.
Interesting Findings
We found that you have to protect the whole ASN (i.e. every entry/exit point for the network) with validation otherwise the effect is minimal. if you have routes from multiple sources (in our case multiple private and transit peers) and you drop the advertisement from one peering the traffic will automatically exit the network in a different place before travelling in the same direction to an invalid destination. This is the reason that while we have already begun the rollout the effect is hard to spot.
Similarly, covering just IPv4 is only partially useful given that DNS provides IPv6 resolutions too. Jisc’s goal is to validate 100% of routes received from external sources.
Resources
To learn more about RPKI and test your domain:
https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/
https://networklessons.com/bgp/resource-public-key-infrastructure-rpki
https://rpki.cloudflare.com/ https://internet.nl/test-site/
Other related information:
Example of large scale effects of BGP route leaking (what we are trying to prevent)