RIPE 93.. 11 AM.
.
.
.
.
.
RIPE 93, main hall,
27 October 2026
11 a.m. Plenary
BRIAN NISBET: Good morning folks, welcome to the 11 o'clock Plenary session of RIPE 93. I am Brian, I am chairing this session. We have some very interesting talks for you all. First off just to begin to remind people the nominations for the PC elections close at 15:30 eastern European time today, so if you are interested, please take a look at the website and volunteer, that would be wonderful.
So, without further ado, I will ask our first speaker to come up and start. He has a live demo, just all prepare yourselves for this. He is going to talk about measuring propagation of RPKI validity changes on the data plane.
ALEXANDER MANNEL: Thank you for the introduction do it. Hello everyone. I am Alex, I am from TU Dresden, currently a Ph.D. student there. I am supervised by these names here, and this joint work with Ties from the RIPE NCC and Thomas from Hamburg, and I am going to talk about measuring propagation time of RPKI validity changes on the data plane today.
Although most people in this room will probably know how RPKI works, I am going to give a brief example for what you need to know for this talk and this is how the RPKI, the Resource Public Key Infrastructure, works for an individual prefix and how it tries to secure routing for this one specific prefix.
So, we start with a ROA object that defines which AS is allowed to announce or specific prefix in BGP, and this ROA, this entry of who is allowed is put in an RPKI repository. And what happens next is that so‑called relying parties, so basically pieces of software that read these entries and validate them cryptographically go to the RPKI repositories and fetch all these entries, they run their calculations, they figure out which prefixes are allowed to be announced by which AS and they then push this data down to routers and the routers will store this information and then evaluate incoming announcements based on these stored data.
So, in our case, we say AS 10 is announcing 10, 20, 24 and the ROA that is used for this prefix says okay, allowed by AS 10 and this is the number behind the dash. We also are allowing a max length of 24 so you are also allowed to announce any sub‑prefix up to the length of /24.
And this is correct for the announcement that was seen for AS 10 so all the routers are like yes, this is a good router, I'll put it in my routing table and I will forward packets.
Now,s say we change this ROA now to go to a max length of 16, so, you are only allowed to announce the specifics /16 and not the /24 anymore. This turns the announcement that we have into an invalid, but this new information has to be pushed to the routers first, and RPKI does not have a unified update point, but rather every relying party will go on its own interval and its own timing to the different repositories and fetch this information whenever they have time. And this means that there is a transition period where some routers have a different view of the, what is allowed and what is not allowed than other routers.
As in this example, you can see that the middle relying party has already pulled the new information, has figured out the new updated ROA and has pushed it down to the routers that it is responsible for. But we can see that is only a subset of all routers in our little example here. At some later point, the second relying party may fetch this information and push this new info down to its routers causing another set of routers to drop the route, but there is still some connectivity because the bottom relying party has not yet refetched this data.
And then at some later point, every relying party has updated its, or has refetched this data from the repository, and we arrive at a sort of unified view on what is allowed again and what is not. As you can see, then all the routers are green.
So this poses a sort of obvious question: How fast does the data plane react on ROA changes? Or how long is this transition period if there is a change on the ROA, how long does it take until the Internet update or the routers update and the prefix actually turns unreachable?
.
Now, solving this question comes with two problems or two challenges. The first one is you need some baseline where you understand how did the route look before the prefix was impacted, so you need a traceroute before the ROA change. And you then need traceroutes after the change but that's less of a problem. And secondly, you want to have as many vantage points as as many prefixes as you can to cover all the different diverse topologies that do exist on the Internet and not just measure one or two ASes.
So, we are not the first to think about this. There has been prior work that has looked at this and he have been this using ROA beacons or RPKI beacons, which basically means they had a prefix they self controlled and they flip the validity of this prefix when they are required to and so through this, they can run traceroutes before they flip it and after they flip it. But this limits their topological coverage to the AS that is announcing this beacon and to the upstreams right beside this AS announcing the prefix.
Now it would be cooler is to study in the wild prefixes, which then cover a much more diverse topology because we are basically measuring on the Internet and we're measuring a lot of prefixes on the Internet but this introduces uncontrolled behaviour because we no longer know when the prefix will undergo this change and so it's harder to establish a baseline.
So, what signal can we use to measure data plane before the RPKI ecosystem actually runs a ROA change the answer is we cannot know beforehand but we can know a bit earlier than everyone else, which is effectively the same thing for us. The way we measure this is by using a couple of tricks for our own relying party. The first one being we were using the CDN origin of the RIPE repository instead of the CDN deployment. This gives us 30 seconds of head start of everyone else we were using an optimised validator that is able to update on the RIPE repository much much faster than a lot of the public deployments.
And if we detect a VRP change we then run traceroutes from over 300 CAIDA Ark notes to the impacted prefix for an hour ever three minutes.
Now, you might correctly ask did that work? The answer is yes, I think. We have a list of public validators that are run by third parties like CloudFlare runs one, a lot of IXs run one and there is a lot of them you can look at and we compared went we saw an event versus when those validators saw an event and we were at least 57 seconds faster but on the median we were actually 5 minutes faster than the next validator.
So, it is good enough to send out the traceroute before anyone else probably reacts.
Let's get to what we found. We ran these measurements for three months from November 2025 to January 2026 and we observed 25 thousand, roughly, ROA transitions that actually changed VRPs. Now this is only for the RIPE repository, we are not looking at every single object in the RPKI but only RIPE repository, so the number for the overall Internet will be higher.
.
And from these 25,000 transitions, we observed roughly 1,500 single transition events so where only one change happened, that went from or to an invalid state. Excluding ROAs because that's a lot more complicated. These are great because if a prefix goes to valid or from invalid it turns from unreachable to reachable which is something I can see in my traceroutes. So through this, we can figure out when ‑‑ how quickly ASes on the Internet actually react to this new RPKI information. Let's have a look at that.
First invalid to valid. So a prefix becoming reachable after being previously being declared unreachable. And we can see that for a single homed networks the median time for 50 percent of or vantage points to be able to reach those prefixes was 12 minutes while for multihome networks this immediate even time is nine minutes. The reason why multihomed networks announcing these changing prefixes is a bit faster is because you deputy on your upstreams to update their RPKI data as well and by having multiple upstreams you are essentially increasing your chance that one of those upstreams pulse the data a bit quicker than your one single upstream does. This is what we can see in the data both with the median time being a bit lower and also you can see that the tail end of the distribution is much thinner than for single home networks.
For valid to invalid, so prefixes that should no longer be reachable, takes quite a bit longer because BGP loves connectivity and will start to path hunt once people withdraw such an announcement. For single home networks, median time for 50% reachability was 30 minutes. While more multihomed networks median time was 42 minutes until 50% of our vantage points were able to reach the prefix. Here it's the opposite to the valid to invalid you case. As long as you have one upstream that doesn't have its RPKI data updated yet, it will leave ‑‑ it will announce your prefix to some of the Internet at least. So, the more options you have, the longer you sort of stay visible and you can also see that by the fact that on the left at 30 minutes, some of the single homes, so the blue is actually at zero, while the same thing only starts at 50 minutes for multihomed because you need every single upstream to actually withdraw this announcement.
.
Also note we only ran the traceroutes for an hour, so the cut‑off is not magically everyone has perfectly withdrawn the stuff but rather, I have not looked further.
Okay, so, we can also do a fun thing of look at how long large networks take to disappear from the traceroute because we're running so many traceroutes we can sort of see who is providing these paths for longer. And we can see that there are differences between the reaction times of larger networks, and the important thing to keep in mind here, is that a lot of networks deputy on their route protection from their upstreams so long as an arch network is keeping an announcement reachable, all their non‑route enforcing customer ASes also are able to still reach this prefix.
There is a lot of caveats with this slide, so, please be aware, CAIDA Ark has some bias when it comes to locations. This is also a year old data, so at this point some networks might perform a bit differently.
Okay, so what does this mean for you as operators? Reduce propagation time. Because the RPKI may be too slow to combat an ongoing hijack of your prefixes as we were able to see 40 minutes and it's still reachable for 50% of the world, not great.
.
So, create your ROAs in advance to prevent this situation from ever even happening. But for the people that are not able to create their ROAs and to also be a good Internet citizen, also lower your validator fetch interval to 10 or possibly even 5 minutes, because this is really the main delay contributor that we see for our data.
The second thing is enable RRDP for your publication point, because most RP software now prefers it and it is most of the time a bit faster than the others.
Now you may be wondering how your network performs, if you were not on this slide before for the large networks, and we have actually since the original study last winter, moved the measurements up to RIPE Atlas and published these, the results continuously, so you can actually have a look into our data and see where your system ends up, and I would like to change to the live demo now if that's possible.
If you follow the link on the slides on the talk abstract and everywhere basically, you will end up on this page. The AS explorer, where you can input any AS number and have a look how long this AS number appears in our traceroutes if a prefix turns invalid. So, we can maybe take 1299 as an example here, we have seen them, or paths going through 1299 for 280 events, 300 probes and 333 thousand traceroutes roughly, and we can see that they are actually quite quick in their reaction. Most of the probes do not see hops through 1299, somewhere between 20 and 30 minutes which is roughly what we expect for a network with ten minute refresh interval. But we can also see that at some points there may be, or there are probes that go through 1299 for a much longer time, even one half and a half hours after the the prefix has changed its status.
So we can just click on any point in this graph and then scroll down and have a look at these individual change events and the traceroutes that we showed you in the graph and so we can, for example, have a look at this one and see the probes that were still going through 1299 at that point. We can also have a look at the trace more in detail and see that the specific probe still went through 1299 and went over the Atlantic 1299 probably. And see maybe a stuck route or something that is enable this probe to even go through 1299 after one‑and‑a‑half hours. So we can also click on the specific event here and actually see what happened for this specific situation, so here a ROA for AS 0 was added for this prefix, turning it invalid, and we can see both BGP visibility and web Atlas visibility in this graph here and see this is one of the faster cases because the AS in question only has one upstream so we are seeing a very quick disappearance, and we can click on any point in time here again and get a kind of view of how probes were able to reach the AS announcing the impacted prefix, and we can see their only upstream is 1299, that's where the atlas probes are going and if we now sort of go through a point in time, we can see probes are no longer able to reach this impacted prefix. But at the very end, there is a couple of probes through 1299 that are still reaching this.
Another fun thing you can look at on the network page is, you can look at probe migration. So this means probes that, for the entire measurement, went through 1299, versus probes that ended up there presumably by path hunting from their host AS and only went to 1299 at a later point and you can see quite nicely that in blue is the probes that are, spent their entire time in 1299, we see a pretty uniform distribution which is sort what have we expect for a randomly distributed ten minute update interval, but in the cases where it took them a bit longer to react to this change, we actually have a lot of probes that have hunt and then go through 1299 as a backup path and we can click on any point again and see that maybe for this event, there was only four probes that went initially through 1299 but a lot of probes migrated through 1299, and if we look at the this here, we can see that originally Cogent was the make‑up upstream for this AS and as Cogent withdrew the announcement, everyone migrated over to 1299. Then as 1299 withdrew, the announcement, reachability went completely down.
So, that's about it for what you can see on the platform. Now, if you are a smaller network you may not be visible in our traceroute because we are only running traceroutes from 100 probes. So bigger networks turn up a lot. Smaller networks have very few data points. So, there is a solution for this, it lives behind this donate button over here, and so you can first see how much credit we are missing to keep this project running, because it is quite Atlas credit hungry, it consumes 5 to 10 million credits a day, and so I am requiring donations. .I am already very grateful for the people on the RIPE Atlas mailing list who have come in and supported the measurement.
And one the ways I want to give back to people who give RIPE Atlas credits is for every 10,000 credits that you donate, you can put one probe into one measurement and basically piggyback to the measurements we're running for the research purposes and through this, also collect traceroutes for your AS or your specific probes to see how the performance of your own AS is. You will have more data points on this explorer page also for your network.
Okay, that sort of concludes my talk. Any questions? Thank you for listening.
(Applause)
.
BRIAN NISBET: Thank you very much. So, please...
AUDIENCE SPEAKER: Hi, at this moment, RIPE NCC. I was on slide 18 I think. I have a question about prefixes becoming invalid and the time it takes for that to be become effective essentially. My hunch is that also depends a bit on whether that is the only announcement or whether it is a governing announcement. Because in the latter case if you hit on the data plane at some point that still accepts it you get directed there. Otherwise, it depends on how ‑‑ whether networks close to you have dropped the only announcement. Have you looked into that difference at all?
ALEXANDER MANNEL: That is what I mentioned in the slides at the beginning that we're only looking at single origin cases. This is actually a bit more strict than if you were just talking multiple origin ASes in terms of two different AS numbers announcing the same prefix, but we excluded everything where there would have been a covering announcement to really get only the cases where you have reachable to unreachable in the measurement basically. Because those cases, yeah, you get all kind of weird effects on the data plane because you migrate over to the covering announcement or, yeah. Those are filtered out.
AUDIENCE SPEAKER: Kaitlin with ARIN Advisory Council but really asking for my own curiosity. It sounds like too few upstreams and too many upstreams have their own sets of problems. Is there a happy medium in between that you found?
ALEXANDER MANNEL: I mean, problems is sort of the wrong idea to think about. I talked about if you have upstreams that was sort of how I presented it, but in these cases really we want the prefix to disappear to having many upstreams is beneficiary to the AS announcing the invalid but to the the broader Internet it is bad because the prefix is reachable for much longer. There isn't really a good or bad here, it's more everybody should get up to speed more quickly and then this, you know, more upstreams of course better for resilience but in this case it slows down the process a bit.
AUDIENCE SPEAKER: Sebastian Becker. I am not sure if speed isn't that thing that is the good way. Actually we decided not to be quick with that, to have kind of safeguard and say okay if there is really something wrong and there was an example a few years ago where a lot of ROAs got lost and we could preserve the state, so we actually decided not to do it, we do the update one time a day, which is if you think about, this is a documentation that should be happening beforehand for the prefixes, you should be already have your ROAs like you have your route objects in your database, then quick is not necessarily good.
ALEXANDER MANNEL: Yeah, that's fair. It very much depends on the individual situation, right. And for a lot of like we're scaring people previously of RPKI, was this, hey, do I have this case? Because I misclicked a ROA and I unintentionally ‑‑ can we flip to the screen one more time please? You have cases like this where an operator doesn't change and find out hey this actually broke my setup and comes back 30 minutes later.
But if you take, for example, the recent Hedsena hijack, one the remediations they were doing was the exact example that I gave at the very beginning where they pulled, where they tightened their max length attribute of the ROAs they were publishing and in such a case, quick reactiveness would have saved a lot of update systems going down. It's really a case by case thing and it depends on what is causing these invalids in the end, which is a different research question that I don't have the perfect answer to right now.
BRIAN NISBET: Okay, do we have any questions online?
ANTONIO PRADO: Not a question but I just read that is someone who is willing to donate some credit.
ALEXANDER MANNEL: That would be great. Just on the page that's reRPKI on the donate page, there is at the bottom, just the e‑mail if you just want to donate credits without using your probe slots. I am very grateful for that. So again keep this very hungry system running. The.
BRIAN NISBET: Okay. Thank you very much.
(Applause)
.
So, next up we have our next talk. So, Osama has pre‑recorded his presentation, and so we're going to play that and then we'll take questions and if Osama is solidly online but also Antonious is in the room as well to help us. So if we can play the video please.
USAME EJAZ: It's my first ever RIPE meeting which I intended to attend in person, I tried my best, but, you know, unfortunately things happen, so, the work which I have done is under the supervision of Antonious Shyden and while I was doing my internship at the Cisco ThousandEyes. If we could talk about the work of we have done here. So when we build a filter out filter, so use more than one source, like for example, we would look at the IRR objects and we see that those of the objects are valid, invalid or like so on by using the RPKI, and also we would use the PeeringDB to see that like which of the network operator has stored the AS‑Set object so we can expand to the IRR also.
So in those cases most of the cases agree with each other. But here, now we want to see those cases which don't agree and also we want to see that if these cases happened, so what should an operator do when these things happen.
So, here in the slide we have utilised the four different questions. We start with the BGP, what was announced. In terms of the IRR is that the exact in the router to show that origin at the more specific prefix length has been stored or their honour is also the RPKI valid, and also in terms of the AS‑SET objects, does the network declare that origin. So in that case like, we were about to ask that, where they agree and where they have the conflict.
So, further on the result data and then we will move on. We have used a study from the 8‑1 August, the same time in terms of the BGP. We have used 57 BGP collectors from the RIPE RouteViews. In terms of the IRR we have utilised the 19 sources. In terms of RPKI we utilised 18 of the nodes from the RPKI's Spools of the RPKI views in terms of the PeeringDB we have used the AS‑Set object which is expand to the IRR. Here about two thirds have exact IRR match and between the 64.6 and 65.1%, that is moved closer like fewer of the objects can be removed or changed. And from that one, almost like 80% of those route object which has been stored in the single registry and almost like 20% of them which has a multiple copy in a different registry.
.
So, here here are two expandable results to map it to the high level over views that we use BGP announcement to see the origin ASes and we go out around like 1.6 million prefix origin, prefix origin pairs from the BGP announcement or so an then we try to it map them and see how many of them has been matched with the route object of the IRR and then we try to match those route objects which has been matched with the BGP announcement to see that like how many of them has a different type of status.
If we compare them with the RPKI spool nodes or so. And here we saw that around like almost of 73.2% of them which has been actually matched with the route object of the IRR, and also like we got 22.2% of them which has not been shown or registering the RPKI spool also, and in terms of the long one, the maximum length, 0.04 has been actually having something because of the maximum length and also in terms of the wrong origin ASes, like 0.01 of them. Also here we have utilised the RPKI spool node or so.
So here, we saw that 0.06 percent of the RPKI spool nodes which has a different status. And here, we have 4.4% of them, which has been status has been changed over a week or so. Also, like, here, we tried to see that as how many of the route objects which has actually the same origin, which has actually the same origin if we compared them with the BGP announcement origin also and then we tried to map them with the RPKI ROAs also.
Here we also got 63.1% of them which has been a valid status in terms of the RPKI. And also here, we have around the other IRR region only source, so it actually shows that in the BGP announcement, we have seen the different origins but in the route object we have a different origin but same IP address also.
And also you can see that even with the exact match, IRR match, we had like 22.2% of the RPKI ROAs which has shown a status ‑‑ we found, which we can still use if we make without filter by using our different data sources or so.
When we zoomed in to see that we got 1.6 million of the observed in the BGP. Two thirds has an exact IRR match, about a million pairs also and roughly three quarters valid and roughly a quarter of not found. Where IRR is all you have, and then we would go to the DE‑CIXes which are invalid 1.1 K of them, almost which are invalid around all of the RPKI spool nodes which is around one in 1,000, and of this, 786 of the invalid goes to the maximum length. And this 415 in the wrong origin. Which means that the IRR RPKI is real. But when it happens, this one we have to see that.
Here, we see that as like day by day in the region we can see that as a flag, which is about the .47 to the 481 but the maximum length is not. It's down to 560 for five days and up to the 396 on the other. You can see that I can like the 160 pair in one day looks like a bulk of the ROA clean‑up also.
And also like here, the number we tried to map those of the invalid ones, if we compare them whenever the IRR route object. So among the 786, 782 of the cases which has been only, you can say, not historical, like one of the data obtained. So, it means that those route objects are actually unique. Like they have no duo modal objects which has been stored into more routing registries also and also here, we also have seen that top 5 percent of those ASN has actually the highest amount of invalid one in like both of the situations, and the situation of the maximum length and also in the situation of the wrong origin ASN also on.
And also, in terms we have seen in the RIPE, APNIC and AFRINIC has a higher amount of them. And the highest amount of the invalid one, a number of has been shown among the whole week of the RPKI invalid data source.
This is two different modes have like different something, for example, we can say see that two, in terms of the invalid maximum length, the highest amount of the invalid has the highest amount of the visibility, but in terms of the wrong region, it has most of them with the single route collector also. So we can say that at the maximum length globally while the invalid wrong region scattered locally.
So here is the one case, so two of the slash 24S, the original AS in the ARIN. And on this was announced in August. But the covering ROAs has actually only three /23 one, so both of the 24 ones are invalid in all of the length party, we are still checking the September number, still it was invalid. Also we can see that in the IRR it shows the same as shown in the BGP. So here it's not authorised question. We can say that the adjacent IRR data also can help us in such cases.
Also in terms of the origin AS we used the 22 of the something cases which are actually highly visible to the route collectors and we tried to have the most possible explanation here as the origin of the wrong regions and here, we go to the ROA has been actually removed and we tried to use the AS relationship. In some of the cases at the see the something relationship and also we tried to use the AS rank of the CAIDA, and we saw that like five of the cases is of the origin AS has been actually belonged to the same company and also one of the ROA has been changed the status after our study. So here, we can see that the same IP address with the origin AS and it has been shown the status as the same as in the RIPE IRR and also the BGP data as well but it has shown the wrong origin as by all of the RPKI spool noted here, and after the next month, we saw the same IP address with the origin ASN. So the status has been changed. So we can also see that if we are having such issues, we can also use the IRR, which may help us with seeing the route object.
Now, we want to see how all these IRR records and also look at the maximum length ROA source, we can see that in terms of the invalid maximum length. So half of or most of them has more than five years old. But in terms of the origin one, so it has actually, the scatter bar also. So here we can see that it's like two different publishers sitting in the same background.
So the two questions we can ask is the exact origin copies remained scattered fragmented across the IRR. Here we can see in terms of the coverage, so we can see that in terms of the RIPE and also in terms of the ARIN, it has the highest amount of the route object which has been stored in the RIR and also in terms of the new one, new object of the route object has the highest amount of store in the AFRINIC. And also in the LACNIC also.
This slide is a detailed slide. It makes up like two registries hold the same object with the same declared there, the other registry. Here we can see that it's the RADB between 65 to 90% depending on the region. And also the exception is like the APNIC one where the new object has been registered in the APNIC also.
So, same table with a different question when the registry held a newer copy it was the RADB before like 74, it was 97% of time, and if you do not (inaudible) they are missing most of the duplicate space here. Also we can see that AFRINIC also has their new object has been stored in the RIPE node.
So that was the registries compared against each other. Now a question inside IRR itself. So, when an operator registers a more specific prefix, does the old broader object stay behind? Also here, we have the role is like the same origin ASN and the new more specific object in the IRR and then older covering route object that has not appeared in the BGP in the whole week of our studies also. And here like we can see that they aren't actually matched, 13.6 percent of the object peer which got around 140 K of data which has been stored in the IRR routing registry. So you can say that like more than half of the time, the older object and the newer object sits in the different routing.
.
So, here, we can see that the old and the new objects sit in the different registries. We got around 127 distribution pattern. The pattern here is the highest amount of them which has been stored as the old object is APNIC and now the new object has been stored in the RADB also.
So here, we asked which the objects live, and the picture is very simple. We can see that the RADB has the highest amount of objects, like in the 57%. If we add APNIC and the ARIN one, so it appears 82% also.
Here is our last session. So everything so far has been about the work of the registry and now what happens when you actually try to build a filter for them.
So here if we want to build a route filter by using the data which we have talked about before. So there is like three steps in which you can say that we would take the AS‑Set object which has an operator has been declaring PeeringDB, then we would map them to the AS‑Set object, which has been stored in the IRR, an then those of the member of the AS‑Set object from the IRR, so we would map them to the route and the route 6 exchange objects of the IRR also. And then we can deploy our own routing policy.
After that we found that our almost 48 percent of the active PeeringDB network which has actually declared the AS‑Set object at all and a quarter of those don't (inaudible) at all. Also the most important part is if an AS‑Set doesn't resolve ‑‑ it does not have ‑‑ the origin is missing, so it can be issued that the network operator has not defined the AS‑Set in that PeeringDB also.
So part of the subject that has been in the PeeringDB which has been expanded to the 10.7 origin ASN also. So we take all of the route object IRR matches. So 99.27 percent fall inside that. Then we move to the direct membership, which we got as 96 percent of them and the recursive expansion helped us to go to 330K route objects more. Then we would go. 1.8K difference has not been found, and which makes more, 7.5K of the route object, which has been only in the IRR.
So, if you talk about the remaining one, it's like the 0.7%, which we can say as random ones. It's like the 60% comes from the network with the PeeringDB record but it doesn't declare the AS‑Set object as all. For example, we can see that two Verizon accounts for half of them which has been missing. If we declare the AS‑Set object in the PeeringDB. So we can build our filters like more complete by using the IRR. Also like here is the one of the number that matters, all if we miss those records, so we can also miss 5.6 valid cases which are also stored in the RPKI ROAs also.
Also like here, we have again the operator when the IRR and RPKI disagrees for example in terms of the valids we can check the authentication one belonging to your customer or not. And in terms of the maximum length. So we can see at the RIPE origin or the prefix too has to be specific. And in terms of the wrong origin AS, we have to see that we do the BGP tools, the RIPEstat also and also in terms of it has been stored in the route object of the IRR also to see that the recent object has been updated also.
In terms of the not found, also, as we haven't registered the ROA in the RPKI, so like this is a place and we can utilise the IRR evidence also you can see an exact IRR match cannot override in the RPKI invalid. But in terms of the maximum length, we can try to use those route objects but we can also see that as they are belonging to the five RIRs ones and also it's the most...
Here is the key takeaways, you can see that 99.27 percent which actually expanded from the PeeringDB AS‑Set to the IRR also. And in terms of the maximum length region, we got around 786. Which should be investigated by tools and also the IRR, recently it would also have been helpful in that sense. Also we got 140.3K, which has the IRR history, the old object which needs to also be reviewed as well. One of the bounties which we want to highlight here, we saw the traffic loads also but we intended to do so, to see that like which kind of filter can show us how much of the traffic loads can be happening.
So, thank you so much for having me. If you have any questions, feedback, I would love to have it, and if you have anything further discussion later, here is our e‑mail addresses, I so would love to connect with all. Thank you.
ANTONIO PRADO: Okay. Are thank you. Any questions? There is Antonious in the room.
BRIAN NISBET: Usame is online, he is set as a speaker. If you ask for permissions, you should be able to bring you up online as well. Also maybe Antonious.
AUDIENCE SPEAKER: My name is James from Interlink. So, I don't know if the speaker can hear me or not are if you can, thank you very much for your presentation, it was a really good, really interesting presentation, I really liked it. My question is: I have also been looking into exactly the same area, and so I am curious to know if you dared to do longer prefix matching. So all of was based on exact prefix matching. I wonder if you dared to look either at shorter or longer prefixes. So one the things that I noticed is that for example, I announced two /23s ‑‑ sorry, someone is announcing, let's say, four /24s in the DFC, they document them in the IRR as one /22 and two /23s with a max length of 4 in RPKI so that the they are three clearly different things. I wondered did you dare to look beyond exact matching because when I tried to do it it was a disaster?
ANTONIOS CHARITON: Thank you for the question. The answer is yes and it is way more complicated the results were way more noisy, but since most people apply their filters like that, it made sense to do it. And some of the results I think in the slides, they cover like they also include this. But it was way more complicated thing that we reserved for exploring further in the future.
AUDIENCE SPEAKER: Thanks for the research. It's very good.
ANTONIO PRADO: Okay. Thank you.
(Applause)
ANTONIO PRADO: Now the next peering.
SAMUELE QUINZI: Hello everybody. I am presenting this work that is the core of my Ph.D. that I did here under the supervision of these people.
This is with or without RPKI? Measuring the impact of RPKI on BGP volume.
What will us go through now, some motivation of this study, the RPKI growth from last year and the main research question that we all address during this entire presentation: Is it a RPKI a threat to BGP stability? We will see which data sources we used and then the methodology to measure the growth in ten years of RPKI deployment. Of course we'll go through results and takeaways from this study.
So, some motivation.
RPKI has grown very much. We are happy for that. Now, about 70% of the entire routing table is protected by ROAs. So, a radical thing. But the same growth is reflected on the event that happened daily in RPKI repository. So ROAs, addition, deletion, revocations. As we can see here, this has experienced a study growth through recent years.
So someone could say that routers take decision based on RPKI data and so, we may be concerned about this steady growth. A change in the repository content may change the output, since this output is what router used to make decisions, this can generate some BGP updates. It's worth noting that not every change in the repository content can have an impact on routing since we could add some ROAs that already cover BGP that were already covered by some other ROA, maybe some renewal before expiration for example and this the not modify the router behaviours.
We know that BGP is a noisy protocol and so RPKI can be a potential trigger for additional updates. We want to know how much is this addition.
So, you as an operator may wonder is deploying RPKI safe for routing stability, for the stability inside of my AS? Did the impact of RPKI evolve over time and how. Should we continue to deploy RPKI? In summary, is RPKI a threat to stability? This will be the main question of this presentation.
To answer this, we need to first collect RPKI events that happened in the past. Then we have to identify the time interval affected by this event and inside this time interval, measure the updates that were generated.
So, first of all, let's represent in this way the RPKI infrastructure. We have two things that can change. We can have changes in the repository, addition, revocation or expiration of ROAs objects. And we will call this like RPKI changes. This probably will not have an effect on routing if they cover already valid objects. What we can have really an impact on routers decision are changes on the validator output, so the list of VRP in output of the validator and we will call this RPKI events. And we want them.
We analysed RPKI deployment from 2014 to 2026. The period before that was not really long enough. Very early stage of deployment. Almost no events were captured, so, not really interesting for our measurement.
Let's see which data sources we used. So, first of all, we have RPKI events data sources and we have two different kinds of data sources. The first is related to RPKI changes and the other related to RPKI events. The first is the RIPE RPKI archive. While the second is called RPKI flutter.
The first one collects daily snapshots of the entire repository of the RPKI. All around the world. So the other is many validators to record exactly RPKI events that happened. So changes in the output list of the validator.
In the first case we have to infer the events that happened by looking at the validity intervals of ROAs. While in the second case, we already have all the events that we need.
The problem is, the first one probably from the early stage of RPKI. While the second only started on May 2024, so it's not well suited for historical analysis in this case.
Then we have the BGP data sources for this we analysed the updates collected by RIPE RIS peers.
So, let's go through the methodology that we used. To make this measurement we essentially here represent two main challenges, the first one is identifying the RPKI related updates. And the second is the fact that the RIPE archive may miss some ROAs.
In the first case essentially went he we have an update, when we have an event, we have some updates, and we don't know how much we should measure here. On the second case, when we have two consecutive snapshots, and we have a short ROA in the window, this ROA will be completely lost. So, to address the first challenge we set up three hours are convergence threshold to be really conservative and we leveraged some ROA experiments that we made and some previous works. So, essentially when we detect an RPKI event we considered the three hours after it to be affected by this event. Then we grouped together events that were close in time to avoid multiple counting of the same updates and we create what we call a cluster in this case. So, an even cluster.
Then we take all the updates that are inside this time window, we consider all these updates as RPKI related updates and we consider all the other outside the Windows as other updates. We compute the fraction of RPKI noise and this fraction of RPKI noise will be the method that I will use to explain our results.
For the second challenge, essentially we have, if we take two consecutive snapshots we can have different situations of short ROAs. The first one is this example. Suppose we have a series of ROAs that is overlapping with validities overlapping, they refer to the same content. So in this case actually, no RPKI events should be generated. But if we miss these two ROAs because they are too short to be captured by the snapshot, in this case we will generate two events in the beginning of R1 and R4. These are events that didn't happen but didn't we do not have the middle ROA we will think it is a happened event.
The second kind of situation are short ROAs that are consecutive. This could be an example a experiment or even a single short ROA that happens in between the two snapshots. Again this will be completely lost. So, here we should generate an event for each ROA addition or deletion, but we will completely lost the two events generated by R6.
.
So, the question can be is historical data accurate enough? We have a common period between flutter and the RPKI archive, so, we assess the accuracy of the historical data by comparing what we collect with archives and with flutter in the same period.
.
The results show that the amount of updates that we measure with both of them are essentially comparable, while the archive missed some peaks that are related to short bulk ROAs that were missed by the archive. But, in order to understand the evolution, so the average behaviour and impact of RPKI routing, it can be interesting but it's not really for us.
A question could be what about RPKI views? RPKI views is the data source we use for RPKI analysis. It's essentially similar to the archive because they have snapshots, but they are way more frequent snapshots so in the first case we have 24 hour gaps. In the second, it's 50 to 20 minutes before 2026, now it's even way better. The point is that the first one is very easy to process. The second you might a lot of gig process per day and we want to make comprehensive analysis. Moreover, the first was available at the early stage, the other started in 2021. So since we assessed the historical analysis for us, it's good enough, we stick to using the RPKI archive and be consistent in the overall period.
Of course RPKI views would improve precision for the last years, because the collection frequent and the multiple vantage point and show the coverage of the RPKI objects collect.
.
Small practical aspect, reading BGP updates requires processing tonnes of terabytes. So it's really impractical to do the whole analysis. So we wanted to make a sampling that is representative for RPKI events in this case. We did that by analysing the distribution of RPKI events over the weekdays and picking the weekday that we prefer.
The distribution is showed here and we cannot see that the distribution on Monday have a peak, second peak, higher peak on the highest number of events and actually a longer tail. So, we decided to use the Mondays as representative weekdays in order to give an over estimation of the updates volume daily.
So let's go through some results and takeaways that we can take from this measurement.
How noisy is RPKI? We analysed over ten years, we gave an over estimation of the noise per day, and it's worth noting that before 2018, this impact is really negligible. So it was not even worth displaying it here.
This plot shows the evolution of the fraction of RPKI updates per day. So, that fraction that we showed before. Overall the RPKI related updates account for less than 1% of the total volume each day. And essentially, if you look at the plot, the one that's reached the 1% are the peaks related to flutter observations. If you actually take the average behaviour on the last years, it's around 0.2%. So, very, very small. Given that this is an over estimation essentially, it's a quite encouraging result.
But what happened during this ten years? So we want to measure the evolution of the number of updates collected and the distribution of this collection between the different peers that we analysed. So, here we are displaying the data aggregated monthly between all the collectors. To read this graph, let's take as an example the last column. This is essentially a timeline of CDFs. If we take the last column as an example, in the bottom we see that a very small percentage of peers collected only a few updates. Then we have around 30 percent of the collector that falls into this green and blue boxes, that means that they collected some hundreds and thousands of updates. Then we have the vast majority collected from hundreds of millions of updates to a few billion of updates. And on the top, a very small percentage collected tens of billions of updates. Again, this is aggregated monthly: It is worth noticing that even these high numbers of updates are actually less than 1% of the total volume of updates daily.
What we can see here is that sharp increase on the number of updates collected. We can see that in late 2019, green boxes and blue boxes started to appear, and we switched very quickly to the part purple side and indigo side of this plot. Actually this increase matches more or less the increasing of the coverage of RPKI. So, a question for the future could be possibly when all the routing table is covered, this increase will set too. We don't know that.
Let's give some details of what we see for each cluster. So, we want to know how many updates are actually captured after an event. We're curious about that. To do that we analyse each cluster. Each cluster referring to one prefix, one collector and in one day.
This plot shows the distribution of updates volume for the clusters. They represent minimum and maximum. The boxes are 25, 50 and 75 percentile and we are referring to flutter data. So, we are looking at the updates collected in the last two years of the observations, so close to the present time.
We divided this cluster into three types: The addition, deletion and mixed. The first one contains only events that refer to an addition of a VRP to the validator list. The second time type, a deletion of a VRP while in the third type, we can have mixed event in the cluster.
So, some numbers related to this plot.
First of all, we took out all the clusters that have zero updates inside, and this actually accounted for around 90% of the total clusters.
.
Of the remaining clusters, 75 percent of them collects less than five updates after each event. And if we want to look at the maximum values, in the first case it's around 4,400, the second case 2,300, and the last case 6,000 updates in the cluster. . So this is essentially background noise. We are considering all the updates in the window has related it to RPKI but we know that BGP is a noisy protocol. So, here, we are essentially including this background noise inside our measurement because it's difficult to understand which of these updates were actually generated by the RPKI event or by other events in the network.
The other thing is that most of the time RPKI events do not affect routing at all. So, something changed but router decisions actually do not. Some more numbers, details, about these tables we observed in this plot. When we considered the percentage of clusters with more than ten updates, amounts of clusters that contains some updates, we have the percentage of clusters are both 10, it's around 5, 4.5 percent. A bit higher for the mixed kind of event. This percentage computed over the cluster of updates. If we go higher, the percentages reduces a lot. And in the case of clusters with more than 1000 updates, these are like just a very, very small number considering that we are analysing all the clusters collected in a period of almost two years, 2024 and 2025.
So what does this plot say essentially? That since 90% of clusters contain zero updates, RPKI has mostly local effect or no effect at all.
And for the second case, we see that 95% of the clusters with updates only contains less than 10 updates. So, in general, RPKI events do not generate a large update volume.
Then we have this very small fraction with less than ‑‑ more than 1,000 updates. This is essentially the proof we are including background noise in our measurement. And even with that, we are less than 1% of the total update volume.
.
So this plot confirms the over estimation.
It is worth noticing, maybe, that the RPKI slightly increased the update rate. So we measured this update rate in this way. We collected the updates inside and outside the clusters, and for each day and for each collector, we took the same set of prefixes and some of the updates observed for all these prefixes inside the clusters and outside the clusters, and then computing the rate by dividing this number of updates by the total time of clusters, or the total time remaining during the day.
As I said, these rates are computed over the same set of prefixes for each collector, so they are essentially comparable.
We noticed that the cluster rate, so the rate related to RPKI is slightly increased. So that means RPKI has an effect here so a non‑negligible fraction of what we observed in terms of raise is actually given by background annoys.
So, in conclusion, what should you do as an operator? Well you should be assured, first of all, deploying RPKI ads less than 1% of the total update volume. You should continue to protect the Internet. We have shown that RPKI benefit on security are essential for everyday BGP activity. But you could be big aware of bulk ROAs. So, in order to avoid isolated events that can still be disruptive in terms of updates that they generate. So, going on the peaks.
And maybe try to avoid frequent changes and flapping ROAs in order to avoid creating more and more events.
Last but not least, maybe keep monitoring the situation and see if with the increasing of the RPKI adoption, this impact continues to increase or if we cover the entire routing table, then it settles to a single line.
Some future questions to represent the peaks. So we could be interested to analyse what actually happened in this peak, were the certification authority involved, the operators involved, and why this event happened.
And maybe ask if RPKI spool can improve with precision, so RPKI spool is the new form of presented by Job Snijders last RIPE meeting, and it provides the duplicated and complete set of RPKI objects. So, it captures the snapshot of the highest possible figure essentially for you, if you combine all the validators that are used, you go to 30 to 45 second gaps. This would allow for a precise measurement of the RPKI event and what happened after.
.
So, is RPKI a threat to Internet stability? Well, no, at least for now.
With that, thank you, all of you for your attention. A special thanks to Randy Bush, I think he is in this room somewhere, for giving resources to set up of our ROA beacon. Thank you for your attention.
(Applause)
BRIAN NISBET: Okay. Do we have any questions? We do.
RUDIGER VOLK: I wonder whether you had any considerations about what can go wrong locally? Kind of my memory going back to the nineties when a policy update essentially could only be made effective by resetting the BGP peerings and optimisations in BGP implementations in routers stemming back from that time, creating essentially a big load on the BGP peerings because a ROA change would mean that yes, you are asking all your peers to resend you the old table, is there any other thing around as a danger like that, and have these problems actually disappeared by now? I have been out of the job for six years, so I don't know whether the vendors actually have fixed their defaults.
SAMUELE QUINZI: Thank you for the question. Actually, we considered these, we tried to think about this when we made our measurements. The problem is using public collectors does not give us visibility of what happened on specific days. For what I know, the recommendation when he deploy RPKI on your routers, it's to keep the Adj‑Rib and to actually have doing this request of the full content every time an RPKI event, something changes in the RPKI content. I am not aware of the default of all the vendors, of course, but I am quite sure that this is standard practice from a long time, I suppose.
AUDIENCE SPEAKER: Tim Brussels, RIPE NCC. So you talk about adoption being a factor and I think that it's mainly validation adoption that is a factor here, like is the data used to make routing decisions. And well, I'm making an assumption but I think most of the changes in ROAs are intentional and reflect changes that people want to happen in BGP. So, I'm a bit confused about the causality here. I think to a degree you can indeed measure that there is, there are timing issues between ROAs being published and announcements being done and that converging. So that may indeed increase the rate and I am not sure if that's what you are actually trying to measure here. It might be.
Other than that, fortunately we don't have many large scale outages, but if we did, then I think it would be very interesting to know what the impact of such an outage would be.
SAMUELE QUINZI: Thank you for this analysis. I am quite frankly agree with all of that. It's essentially what we observed by looking at the clusters that were involved, that most of the events were caused by a real addition of RPKI data or expiration or deletion of ROAs. So, this is essentially true, and for that it's good, but this amount it's very, very low. Regarding the analysis of peaks. For us it's interesting for future works because what we observed, and this is actually the reason we decided to keep the peaks outside for this analysis, is that the frequencies of these peaks is very low. So for that reason, we stuck to measuring the average behaviour, but outages analysis, it's surely the next step in this case. So thanks for that.
AUDIENCE SPEAKER: Alex. On slide 37, if you can go back, you showed how many events per cluster you observed. Or how many updates you observed. And it's by ‑‑ further back. Then you have each cluster refers to one prefix, one collector and in one day. And if you are assuming you have some changed event that actually causes some policy change that in turn causes an update to actually go out and be sent, how are you seeing in most events only one to five update messages on the entire collector for one? Shouldn't at least each peer on the collector probably send an update?
SAMUELE QUINZI: Maybe here the naming it is a bit confusing. When I say collectors, I mean actually the collected peer. It's essentially what you are asking, yes of course. It's not a full collector, yeah.
BRIAN NISBET: Anything on Meetecho? No. Okay, thank you very much.
(Applause)
.
Okay, so, that concludes this session. If you thought it was awesome and you want to make it even more awesome at the next meeting, please do volunteer for the PC. You can do that up until 15:30 today. Thank you all very much. Enjoy your lunch.
(Lunch)