MAT Working Group
RIPE 92
Main room
The 19 May 2026
4
STEPHEN STROWES: Good afternoon. I am going to give folks a second to grab a seat before we get started.
Welcome. First of all, welcome to Edinburgh. It's a slight novelty to be able to welcome to you, in a way, my home.
I want to start you off with a local anecdote before we get into this session proper. There is a map of Edinburgh from 1862 which solves two problems that we have in networking. One of those is difficult, which is measuring one way legacy. The other of those is how do you beat the speed of light? In 1862 they solved this problem. There is a map which you can go and access at the link at the bottom there, Hislops time gun map of Edinburgh and least. Now a time gun sounds much more scifi that it actually is. But at 1 p.m. everyday, the time gun is fired. So this map has a series of concentric rings that are centred around Edinburgh castle. And the map describes to us what the rings mean. Now you can't read that, I definitely can't a read that to allow me to expand.
So the two lines here solve the two problems that I delineated a second ago. The first one is: For every additional circle of dance at which the observer may be from the castle, he should subtract, due to the measure rate at which sounds travel, from the instant he hearing the report, i.e. the firing of the time gun, in order to be obtain the exact moment of fire or one o'clock P M greenish meantime.
This is every concentric ring is two seconds from the firing of the gun based on the speed of sound. We know where we are on the map, although the map doesn't quite include the the EICC. So we are here, so if you hear a bang, it's probably two seconds past one, approximately. Because no map can take into account wind conditions or any other scenarios.
So that's condition 1. This map from 1862 satisfies a constraint for measuring one way latency.
The second part, which I particularly like, is we solve the speed of light. In Edinburgh, the Internet operates at infinite speed.
The Flash of the time gun's fire requires, owing to the immense velocity of light, no correction for any distance.
It doesn't matter how far away you are from the gun, no time has passed.
Faster than light.
1862 they had all of this together. But that's enough from me. On with the session.
Who are we? We are your friendly MAT Working Group co‑chairs, I am Stephen, I am joined by my co‑chairs, Massimo and Nina. If you'd like to contact us, you can do so directly at that address, for friendly comments or whatever you want to raise with us, we are happy to take any and all criticisms.
Session admin. Queue discipline. We haven't super religious about using the meet queue. State your name around affiliation at the microphone. We will try and do our best to capture everybody. But we will cut the mic lines if we are running low on time. During the session please rate the preparations. It's best to rate during the session because otherwise you will forget and I always do. If there is something interesting that comes up, please discuss the presentations on the Working Group lest if you think that that are shared topics to discuss.
Before I continue even further, I have a little bit of paper from the NCC with a bunch of reminders.
.
One is RIPE PC election voting is opened as of 4 p.m. and will close on Thursday at 5 p.m.
The second reminder is there will be a session on diversity, equity and inclusion in tech today at 6 p.m. here in the main room. And the final reminder is that for tonight's social, there are no buses to the social tonight, so, you can walk, use public transport or take a taxi. The directions are on the meeting website. There will be one bus exclusively for guests with mobility issues which will depart from the entrance of the MOXey fountain bridge Edinburgh at 8:45. Remember to bring your badge to the social. I can say that the social venue is only about a 20 to 25 minute walk from here, so it's not super far if you are concerned about the distance.
.
Our agenda today, we have five talks on the agenda. We have kind of clustered them into a couple of IPv6 related talks, we have got a couple of BGP adjacent talks, and we are closing out with this talk on the Iranian Internet shutdowns in the last few months.
So, that's all I have. Our first presenter today is Geoff Huston. For many of you Geoff requires no introduction. But he is going to get one anyway for those of you who it's valuable for. He orchestrated the construction of the first Internet network between Australian universities. He is APNIC's chief SCIONist and an hall of fame err inductey.
GEOFF HUSTON: Thanks Stephen. Good afternoon, my name is Geoff Huston. You don't need to clap that or you are clapping Stephen.
I love this story about the speed of sound. In the 18th century the speed of propagation of electricity through conducters was an equally timely topic, and there were fascinated to figure out how fast electricity moved through a wire. And so a French, whatever, Johnentwan Naulet, got 160 monks, 1.6 miles of iron cable, a lieden jar, got all the monks to hold and keep their feet on the ground and and applied a massive electric shock by the similar stains screams and jumps of all the monks at the same time he concluded that the propagation of electricity through wires was instantaneous. Why don't we do that today. It just sounds like such a great way of measuring stuff.
Here is a v6 packet, everyone jump. So this is actually not a talk about v6 and it is not even a talk about DNS, not really. It's actually a talk about measurement, which is why I sort of put into MAT and nowhere else. It does flow on a little bit from the talk earlier from Tobias in the Plenary, but it kind of leads in a different place and a different way to try and understand, if you will, the problems and intricacies of measurement.
So, we start from the same point. There is quite a venerable RFC, 22 years ago that oddly enough in a document that says v6 transport operational guidelines says you better keep v4 going. An odd title for a conclusion. But, you know, the issues in there are don't forget v4, this is not the time to ditch it the lot and move to v6. Which at the time was quite timely.
Now, there is a changes to that, there is this proposed change, that recommends at least two NSSs for zone and dual stack name service ‑‑ every authoritative DNS zone, should not quite must, served by at least one IPv6 reachable. It's kind of a define hint now, isn't it, because the earlier one said, if you want it to work keep v4 running. This one says, well maybe you should keep v4 running that's up to you, but, you know, you really should have at least something in v6, it's not saying you must. But it's kind of going you really should.
And the assumption behind this new bis, it's a BCP is that v6 is now mature, well understood, and using v6 as transport for the DNS is as good as v4. That's what it's really saying.
Now, if I actually go and look at the world as a whole and look at the, what 5 billion odd users out there, who use the Internet everyday, only half can get anywhere in v6. So, for general use out there on the Internet, that degree of deployment maturity isn't really there, it's a 50% problem. It will get better, but today it's not there.
But the DNS is special, as everyone who works in the DNS keeps on saying they are special. Yes, they are special and it's very sad but, you know, you have to tolerate them.
But this assumption that v6 is now mature, well understood and as efficient, is it true? And more to the point, can we measure it? And so let's actually look at what the measurement question is. If I put something up on the DNS in v6, how many users can reach it? I don't care about what resolvers or what resolvers you use, that's kind of irrelevant, because the people who pay for all this show are you and I paying our ISPs or whatever for this. So if I phrase this not in an infrastructure mode but phrase it as a user problem, people using the Internet. If I switch parts of the infrastructure into using v6 in the DNS, do I piss people off will it just work? Etc. That the question.
And that leads you into a measurement question which is kind of hell on earth, because measuring the DNS is always difficult, it's not straightforward.
Why not? Because the DNS is anything but simple. What's a resolver? Something that gets queries and gives you answers, yeah? It is it a single programme on a single machine? Is Google's 8.8.8.8 some massive thing somewhere? Of course not. It's state of mind as far as I can tell. So is CloudFlare's open resolver. And what about the resolver running in my ISP? Well, I don't pay for it, my ISP pays for it. And I don't pay any extra for it so it's some IBM PC that someone last looked at three decades ago that assumes it running and no one looks at. What is a resolver? There are so many different ways of building it there is no simple answer.
It's not a thing, it's a function. And when you are starting to try and measure the DNS, the things get into the way of the function.
So, a resolver also might be the one that operates on my Mac. It's a wonderful resolver, I am its only client. It loves me.
On the other hand, Google's resolver has approximately, thinking here, about 1 billion clients. And I might be one of them but they don't care about they. I am one in a billion. So, millions of clients, but when I want to talk about the DNS, what my resolver does is supremely irrelevant. Google's behaviour is extremely relevant because it affects so many users.
So understanding resolvers is actually really quite a challenging issue. We don't know.
But okay, well at least we understand DNS queries, don't we? No we don't.
Queries are not end‑to‑end. Queries are kind of these ephemeral things that move from one DNS intelligence point if I auto use that word loosely to another and then it goes and solves the problem. So it's a relayed problem. There is no continuity. I ask my recursive and the recursive says well that's a great problem Geoff, let me go and ask a few of my mates independently to give you back an answer.
So this distributed process of query resolution causes fan outs. It causes a single query being amplified in their own special way.
.
There is no hop count. There is no path. For all we know, there are queries that were made ten years ago that are still looping in the DNS. There is no reason to stop them. They just loop around quietly going hey, you know, and they might be there, we have no idea. There is no snail trail, theres no traceroute, there is nothing.
Queries really have a life of their own.
Now, when you couple that with the next observation that the DNS is free, there are very few of you in this room, there are a few and I sympathise with you, that have to pay for a query. But the rest of you don't. No one pays for queries. I could ask CloudFlare, I could ask Google. Oh let's ask both. Why? It's free. It costs nothing. I'll just take the first answer.
All the way along the line, what you actually find is that the DNS adopts, if you will, the lazy approach and just simply duplicates queries all the time.
So, here is a little graph. The red is A queries. The green is v6 AAAAs, the blue is the oh so fashionable HTTP query, that's all the Apple ecosystem machines out there that are hip and with it and https is the new hip and with it kind of query. You notice, almost everyone queries once. That's really good. So the as many v6 and v4, what's two, three, four, five, six? I went up to 15 but that's because after that it goes to a few hundred but the numbers are small. Query duplication is a thing. Queries just get amplified again and again and again.
To be perfectly frank, roundabout one third of the queries that circulate in the DNS are replicants of a previous query, a precise replicant. Same query name, name severing. They just get repeated a histogram of what's going on there.
UDP is a brilliant protocol. You don't need to wait for an answer. You just ask some more and some more. You can be as impatient as you want. Keep on asking because queries are free and no went cares.
When you are kind of looking at the DNS, how do you get rid of the duplicates to the information? What's real? What's just the DNS chattering to itself? That's a really hard question to answer, because the DNS loves chattering to itself.
So, the next thing. How to measure? Tobias worked up a different kind of measurement. I am Tobias, and there is a bunch of servers out there, I will ask each of them to collect some data. One to many and back again. And it kind of summarises the problem. But to be perfectly frank, the server for Geoff's favourite domain dotcom is supremely irrelevant. And asking him about, you know, my v6 properties makes no difference.
But a lot of people ask google.com, and the properties of that server are actually supremely relevant to each and everyone of you. There are names that are credibly important and servers that are incredibly important. What I really want to know is not the characteristics of individual servers, I want to know the characteristics of the resolvers that you and I use. How do that? Make you ask the question for me, all of you.
Who hasn't received an ad in the last 24 hours? Nobody. Who hasn't received an ad in the last two hours? Well a couple. Ads are everywhere. And oddly enough, ads are a way of doing measurement. Because in an ad you can load a script, that script executes as soon as the ad is loaded, no clicks required, clicks are expensive so if you see APNIC don't click it I am paying. But you can get an extraordinary amount of folk enlisted in performing your measurement for you. And that's what we do.
We use the add system to distribute queries into the DNS at the stub resolver level. But we take a lot of attention in making sure the query name is unique. It all comes back to serve as we operate. So we sit there on these servers and infer what's going on in the DNS from what we see at the server level. So it's many users and a very small number of servers.
So the measurement question. V6 DNS? Yeah.
So, here is what we find early in February. The amount of v6 out there in the world from a user perspective, about 50%, but if I put in an authoritative name server on v6 only it's more encouraging. It's around 60% of users can actually get that name resolved. Dancing in the streets. That's wonderful, let's all go home, this is brilliant.
But how good that measurement and how did I figure out that the user had got the answer? Because I can't change your browser, I can't. I have got the ad to say try and resolve this name. And I see the query, I answer the query, I know I did. But how do I know you received the answer? How do I know that you actually successfully received v6?
.
Years ago when you looked at v6 block acknowledge it wasn't the out going packet filters that got in the way, it was the incoming filters, so even if I deliver a v6 answer, it was highly likely years ago that you would block it because the income filter said no, no v6 here.
So how do I do that?
.
Well, the way I actually do it is that that DNS query is associated with a web fetch. And guess who the only web server is? Well, same old server. So this only works if they actually do the web fetch. It sounds reasonable? Well, yeah, but the problem is that browsers are incredibly loose and noisy. They just get amnesia, they forget thing, they don't attempt. You go away from the web page. It's not. It's not a very good measurement at all. So the real question is, I am actually trying to measure the absence of data, and I don't want to do that. Is there a way of doing it inside the DNS, that the DNS can actually tell me if it got the answer?
.
Well, yes. By doing stupid DNS tricks. And one the stupid DNS tricks is to say here is the name of the name server but, I'm not going to tell you its IP address, you are going to have to work that out. And the only way you can work that out is if you have v6.
So, I send you an answer. No glue. You have to work it out. You need to do v6 to work it out. Only if you work it out, do you do the next query.
So now everyone who does that new query has been able to receive an answer on v6. Brilliant, right? This is a much much much much better answer. This is fantastic. And when I put the two beside themselves, the red line is the web, 60%, the blue line is the DNS, 70%. Fantastic, I found 10% more users by using a better measurement system. Is the web that crappy? Well is some would say yes, live with it. But averages hide anomalies. And some of these anomalies are amazing.
North Africa has a particular form of DNS resolution in Algeria, in Libya and in Egypt where glueless delegations are evil. Evil. They don't do them.
So the web is up around 60%, the DNS measurement is at 0%. In all three countries, well not quite zero? Libby and Egypt but you get this strange difference at a national level, not per ISP but for every ISP operating in that country, riddle me that. Whoever was selling this shit, was doing a really, really good job, you know, if you need some crap solved, go and talk to these people. That sales person is fantastic.
But it kind of goes that DNS is not the same everywhere for reasons that aren't the same everywhere. There are very few resolver implementations but an awful lot of people who play very silly buggers with the DNS. Bolivia, Ethiopia and Myanmar, do it the other way. The DNS gives you a really good answer, the web gives you crap. It's way lower.
And if you look at this distribution you find that even though it kind of is two things talking about the same behaviour, when I try and pin it down, I find these anomalies that swing either way fantastically where the web signal gives a higher result and there is almost no rhyme or reason to this.
So, I can take the maximum of the two and actually get an even better answer. Oddly enough, if I take the maximum of the two and go look, I'll take either, I am desperate, 80% of users sit behind something that somewhere or other it looks like they are able to do v6 resolution over DNS, but either individual technique gives you a lower answer.
So what's this telling me? The DNS is shit! The DNS behaves in way that are entirely non deterministic and that answers are random not systematic. Trying to measure it as an answer in exercising in beating your head against the wall and reshaping your forehead. These simply add layers and layers of obscure complexity that defeat any mechanism to look from the outside in. And you can't follow DNS packets because no traceroute, no nothing.
So, quite frankly this exercise in trying to measure the DNS is one of of those endless employment opportunities. There is so much to try and measure and so many different and wonderful ways that the DNS is going to frustrate the hell out of you. Thank you.
.
AUDIENCE SPEAKER: So, I don't think it changes the results. What we found out is that NS queries are not always answered. So in following delegations most resolvers just use AAAA to the route a AAAA to the TLD a quad to the SLD and a AAAA to get the result. With Q MA minimisation, our first implementation and NS query to the route etc. And at some instance we don't get an answer because it was an NS. If we ask the same thing well, the A or is it AAAA, we got an answer. So with your experiment going well, glueless, we asked for NS, we don't give the glue. So, it won't change your results dramatically but we found that some, I guess it's our middleboxes somewhere that just don't accept anything else than A or AAAA.
GEOFF HUSTON: When I have got the name but no glue I am trying to find an A and our a AAAA for the name. I have walked out of the NS world and I am now back into the mainstream what's the IP address of this name? So, yes, I realise there are issues with NS delegation, but in this technique, I convinced myself that glueless was brilliant. But the real answers go well that's just a theory, and let me find some counter examples to contradict your thinking.
AUDIENCE SPEAKER: What can I say? I am DNS engineer for like 15 years, and longer I do it the more I am amazed that it works at all.
I think begin the place we are meeting perhaps we should consider switching to sheep sheering. Thank you.
(Applause)
NINA BARGISEN: Will thanks Geoff, that was awesome. I am going to quote you forever on DNS is shit.
Now, we are ready for the next speaker. Will he is a Ph.D. student and a research associate in the distribution network systems team at the TU of Dresden. Before that he graduated in computer science in Berlin and his research focuses on Internet measurements to improve network security and is particularly interested in DNS and scalable IPv6 scanning.
MAYNARD KOCH: Thank you very much for the introduction. Hello everyone. So, my name is Maynard and we are doing IPv6 scanning at our Chair they university. And we would like, or I would like to present you a an alternative approach to scan the IPv6 Internet using sub‑router Anycast probing.
A bit of background here. What do I mean with common approach? Currently for example, this is what this talk focuses on, is analysing network topology, and a common approach here is to send out probes to random targets and then analyse returning error messages. If I just probe a random IP address out there in IPv6, it's got a high chance that it's just not existing or not associated in any device so what happens? We get a router that returns an ICMP error message saying host not reachable or whatever, but we can extracts some information of that ICMP error message. In this case for example, the router IP address that the router used to reply to our scanning infrastructure.
However, if we probe more deeply into the network, in IPv6 it's required that routers implement some kind of error message rate limiting. So, what happens is if we hit a router that has a packet and be we reach this limit with our random probing request, because it would like to generate an ICMP error message, we run into rate limiting and the router drops the reply. So we wouldn't observe this router IP address when probing with random targets.
So we can continue this, maybe run into another rate limit here. So we do not have a complete picture. The question was can we improve these common probing messages to elicit more pro IP addresses. We found something in the IPv6 addressing architecture RFC. There is a little subsection about the required Anycast address, and it says "the sub‑net router Anycast address is dumping light" you see on the slides it's basically the sub‑net prefix, the end bits of the sub‑net prefix and then all other bits just set to zero. And routers with interfaces to the, this corresponding sub‑net, should reply when we query the sub‑net router Anycast address. So they should not reply with an error message but if you send the request to the sub‑net router Anycast address we should see an ICMP echo reply.
The idea here is that we do not trigger error messages because an echo reply is an informational message basically. So, the assumption is that we are more or less unaffected or at least less affected by rate limiting. So, we could observe more of these router addresses when we use sub‑net router Anycast probing.
Of course we hit a ‑‑ we probe the sub‑net router Anycast address for which the first router has a sub‑net to it replies with an echo reply. We continue using that knowledge going further into the network and again hitting a sub‑net for by the router, the next router has an interface to. So it replies again instead of, as you have seen before, just dropping the response because of ICMP error message rate limiting.
We can continue this, and hopefully we find all these router addresses because they just reply with an echo reply and we don't hit any rate limiting here.
But there are two challenges. So the first one is how do we know this sub‑net router Anycast address is? So we cannot just randomly generate a sub‑net router Anycast address because it must match to an interface of that router.
So, how did we do that? We just partitioned the routable address space into more specific sub‑nets and iterate through all these sub‑nets and probed the sub‑net router Anycast address for each of them.
For example, if you use a /32, we then partition the address space and probe all for example all /48 sub‑nets for this input prefix. For the first one, okay, the router might not have any interface here. But ‑‑ and we ran into rate limit. But at some point, we reach interface or the sub‑net router Anycast address for which the router has an interface to. So we would just reply with an echo reply.
Nice. So, we can then probe that network because we now know that the, this router has an interface to the sub‑net, so there might be something more behind it. So what we now do is we take this sub‑net and probe each /64. And generate the sub‑net router Anycast address for this.
.
And then we continue. Of course maybe we reach another ICMP error message, hit some rate limiting. But if we're lucky we find that the next router also has a sub‑net no more specific network and then we receive a reply from that router, showing us his IP address. At least the IP address that the router used to reply to the sub‑net.
Are so, how well does this actually work on large scale in practice?
.
We did a couple of measurements. We used sub‑net router Anycast probing and compared it to random probing. So we run our measurements every twelve hours over three days. And what you see here on the Y axis is the number of unique router IP addresses, IPv6 addresses, we find using using sub‑net router Anycast probing and random probing. So, the main finding here is that as our probing reveals, about 10% more on average of router IP addresses compared to random probing, and the number of echo replies also remains stable over time.
Which might be an indicator that the SRR scans are far less affected by ICMP error message rate limiting.
We also find about 9 million router IP addresses exclusively with FRA probing with this approach.
Due to time constraints, I just would like to refer to a paper there are more results if you are interested, please feel free.
There is one more thing I would like to talk about. Be cautious when you perform active measurements because in IPv6 quite a lot of routing loops. Just very briefly, what are the routing loops? For example, if a router has a signed or a provider has assigned a /32 to its customer and the customer only uses a fraction of this address space, then of course, if the customer then, the customer router has no route to it but it has configured a default route, what happens is when we try, or when we query this SRA address, the router would just forward it because it knows it has some kind of path to this sub‑net, but R2 would just use the default route because the address space is not used and it would just send it back to our one, that's where the routing loop emerged. And we receive at some point when the hop limit reaches zero an ICMP time exceeded message.
In our case this was not only a single ICMP message, but more than 200,000. This was due to the router bug that made trigger ample facial of ICMP messages but there are more details in the IPv6 Working Group on Thursday. So, feel free to come to that talk as well.
Two implications for active scanning. First of all please exclude networks that lead to routing loops. So as soon as you find out that there are routing loops, if you actively probe this network, just exclude it and do not use unnecessarily high IP hop limit values here.
So, conclusion.
Exploring the active IPv6 address space is challenging.
But SRA probing is actually a valid approach to complement existing hit lists and replace random probing, but be aware of routing loops.
You can find more details in our paper which is linked here. And we also continue scanning once a week, so we scan a couple of sub‑nets and publish our report under IPv6‑SRA.realv6.org. With that I would like to conclude my talk. Happy to answer any questions. Thank you very much.
(Applause)
AUDIENCE SPEAKER: Warren, could you go back to slide 16, 17 and 18, and while you are doing that, you seem to be making the assumption that things are often or almost always hierarchical, you know, that like the first router has a super net and then there are more specifics further down. And clearly that's true in some cases, Like you are getting more results. But I think it's definitely not always true. Like often a prefix is used for a backbone or a large connectivity and then sites are not actually hierarchical.
MAYNARD KOCH: Yeah. Sure.
AUDIENCE SPEAKER: Jen Linkova. A small comment. If you look at the address, I suggest you look at RFC of 4291 and which is much more up to date than the one you quote. But what I'm a bit confused about, that address is supposed to be assigned on link. So there is no point of looking at that address in /32 because the router would only respond if you have an interface like a signed /64 or/127 and then it would respond, if a just /32 on like the configured this a route or something on that router it wouldn't respond, it must be a link on that device. So I'm not sure how you can find more devices, like why you start scanning behind that router if the router already responded there is no sub‑net behind it anymore.
MAYNARD KOCH: Sure. I mean what we tried to do is, if you mean the /32 example, this would of course be more in the core, in the net core, right. But we still find these addresses replying of course, but the idea, the main idea here is to just improve this random approach to just maybe get more stable results. If I get you right.
AUDIENCE SPEAKER: Erik, Cisco. First, thank you for this speech, excellent. Good ideas. Like Jen, it's 4291 and not 1884, right for your paper.
The other point, like her, I don't understand why you get a reply on a /32, because actually what you are selling it to a /64 is another zero in the prefix.
Now on the way you are numerating, you go from a /32 you go to /48.
MAYNARD KOCH: That's the idea. We iterate throughout them.
AUDIENCE SPEAKER: Why don't you try from /22 you try 01 N of/33 then a /24 will be faster.
MAYNARD KOCH: Again ‑‑
AUDIENCE SPEAKER: Whatever you say, the slide, when you say ‑‑ so you know where you are doing, you went to A11 then B and so on. You are basically jumping my numerating 16 bits in one shot. So you are adding the prefix lengths by 16. So you should do it by one by one.
MAYNARD KOCH: That's what we are doing. This is just for simplicity. So, sorry, if that confused you.
MASSIMO CANDELA: Thank you very much for your presentation.
(Applause)
.
Now we have the next presenter. Job Snijders. He is a consultant engineer who analyses the architect global networks in RPKI systems. He sympathises in Internet routing security and protocol design and runs RPKI views. As a community project and today he will present lots of free data, the RPKI spool format for materialising RPKI data.
JOB SNIJDERS: Well, surprised, surprise, we're going to talk about RPKI.
Let's start with what RPKI views is. All of you know routviews, and when you see a good idea, you better steel it. So, I made RPKI views in the image of routviews but not for BGP data, for RPKI data. Because about five years ago I realised like oh, we're use in RPKI stuff in the production environment. We are going around conferences encouraging everybody to use RPKI data and nobody is storing all the RPKI data. So this makes debugging events and retrospective analysis very hard. We need to start storing the data.
Now, a fun thing about RPKI data is that there is a finite amount of it. With BGP, depending on your placement in the topology, depending on your relationships and because of best path algorithm, there is basically an infinity amount of BGP so the more collection sessions you setup, the more BGP messages you will see.
In contrast, RPKI is sort of a single variety per CA data structure, and in theory, you can capture all of it and it's a finite amount of data.
Now, not many others are collecting the data. RIPE NCC for a number of years has been taking one snapshot per day by the granularity that have is not fantastic in the sense that if a ROA is added and removed in the course of the day, it will not show up in that archive. So RPKI views tries to capture all the data.
.
When I started in 2020 a snapshot was about 120 megabits. Okay, that's not too bad. But as the years went by the snapshot became larger and larger because more of you were creating more ROAs. We are at now 5 hundred megabits better snapshot and this is a bit of a challenge.
In fact, if we look at just one collector this year, I am slurping in about 1.6 terabytes per month, and that's, it's not great. But I have multiple collectors, so really, I am so far in this year already at 20 terabytes and the year is not even over. So, the generation 1 approach of RPKI views was very cool in its simplicity, like every terabyte is one snapshot of the entire RPKI as it was for that node at that time, but it also is entirely unsustainable way of collecting data and, it's not weird, but the flip side of it being so much data is that it also becomes less accessible for researchers. And when I say oh you can download all the RPKI data and the researchers are like I cannot fit 20 terabytes on my laptop, sorry Job, I am going to resource DNS. That makes me sad.
So, something had to change, and if not just to, you know, save my own wallet but also to, for the health of the ecosystem. We had a problem. So enter RPKI spool. With RPKI spool, I tried to make a standardised mechanism how the data capture is done, how to access it, what to expect from these archive files, what's the naming conventions is and document that. If you want to research the RPKI, use RPKI views and RPKI views has documented that this is the approach, how the data is stored.
The RPKI spool you can sort of conceptually think of it as a tape recorder throughout the day as RPKI events happen, just stores all the events and the tapes are what you can later replay and you can replay the RPKI events throughout the day.
So, how this works exactly? An RPKI spool uses industry standard formats. So one of them is the TAR, or packs, but we'll get to at that later, uses C standard for compression, and I am achieving insane compression rates, and it uses CCR, which is essentially a binary format containing a merceltry that is a snapshot of the RPKI state at a particular point in time. All of these are either post extenders or IETF RFC standards. So this makes it accessible. Theres no proprietary binary formats involved.
Everyday starts with a check point. The initial state. Throughout the day, multiple collectors collect all the data and apply a changed data capture process, so there is a second file, the RPKI spool. So everyday gives you two files. The start of the day and the changes throughout the day.
Now in theory, if you are analysing a series of days you can skip the initial states of everyday if you just string together the spools. But this is to make leave easy for researchers that you can latch on to any day in the year that you want, and very cheaply start analysing RPKI data.
Here is a bit of a complicated graph of what's happening.
But the purple line is the number of snapshots per day, it's hovering around 2 thousand snapshots per day it means that he ever few tenths of seconds a snapshot is taken so that's really, really good resolution if you compare that to a snapshot once a day.
The cross barred green is the new objectives that appeared in that day, so it's new CRLs, new manifests, new ROAs, no ASPA objects and the solid portion ‑‑ sorry, the cross green bar is the total number, solid bar is the churn, like the number of objects that were replaced by a new version. At the bottom you see in yellow the compression efficiency, everyday the total capture in compressed form is around 1 gigabyte. But the gotcha is the compression ratio is around 99%. So these are tiny G sop bombs when you put them on your laptop and expand them because then they become quite large. But it means that nor durable storage and for long term archiving a gigabyte a day to capture the entire RPKI from multiple vantage points all over the world is a really, really sustainable model for the long term. So, this is good.
There are currently 14 collectors distributed around the world, like Amsterdam and Singapore and Zurich and Sydney, and Bangalor. I don't really have great access in Africa or South America, so if you have some virtual machine resources you want to contribute to the cause, talk to me, I will happily take your memory and CPR resources.
These collectors represent a diverse set of ingestion strategies, so some of them are RSYNC only, some of them first use RDP and then RSYNC. Some of them have only v4, some of them have v4 and v6. Some of them only use RDP snapshots. There is a wide variety of trying to access the RPKI data through various means so if there are discrepancies between say RSYNC and RDP publications I capture that there are differences between the define access methods.
As I mentioned, that's, you know, it's costing roughly a gig a day so that's good.
Now, as I mentioned, two files a day. Initial state is the start of the day and then the changes throughout the day. You can look at these files yourself if you copy off the European mirror on this here.
In the checkpoint that initial state you'll see millions of tiny files and they are sorted in a way that is optimal for compression. So everything that's similar or even duplicate is put close to each other. And then C standard can do its magic.
The first column in purple is the identifier of the collector, and then the second segment of the file name is the logical path to that particular signed object. So this is a really easy way to construct this was the initial state of that cache of that day.
Then, the RPKI spool, the one that captures the change throughout the day, is a little bit more involved. So, I will go through that one by one.
The time stamps in these files are derived from time stamps inside the signed objects. And this makes, for instance, backdating detection super easy, because if in two days, change capture the two days RPKI spool, you see objects that have like a time stamp that was a few days ago or a few months ago, that means backdating or recirculation of old objects is happening.
Then, in the static directory, you see addressed by contents, so the hash of the contents of that object are the file name. The signed objects, that is the CRLs, the ROAs, the manifests, and by naming everything according to the Shah 256 of the content I get free deduplication and that's one of the efficiency gains of this new system.
Then we have a CCR, a canonical cache representation. CCR is a very modern standard. You can think of this as what MRT was for BGP is what CCR is for RPKI. MRT is this binary format to record BGP information throughout the day. CCR is an entirely different format but like conceptually if you place the tools in the ecosystem, then they are sort of in the same bucket of utilities. And a CCR is essentially a binary encoding of many hashes, and that allows you to reconstruct particular points in time, but also to accurately capture a point in time in a very cheap way. Every CCR is like 20 megabits, compressed 10 megabits if you put a bunch of them together in a TAR file and G standardised ‑‑ do G standard compression, it's even smaller. It's a really efficient method of capturing what the validator was thinking at a particular point in time.
Then other files in the RPKI spool are the standard error and standard out of the validation process and a file that contains open metrics formatted information about that particular run. So you can also receipt actively sort of figure out how long the did particular aspects of the validation process take.
You can interact with the data in these RPKI spools with RPKI clients. RPKI clients has a thing called dash F or file modes. As you can call it, and if you can combine that with for instance, dash J for JSON output, you get a JSON formatted decoding of the binary information and that means you can pipe it into your Python or R or what not analysing pipelines you do, and lift it out of the, say, hardware to access binary format into something that is more accessible to researchers.
So, RPKI client is the go to Swiss army knife to interact with the files in these archives.
The analogy to MRT in this regard is like RPKI client is your may bow or BGP dump or BGP dump to decoder.
In summary. I produced RPKI spools with a 12 hour delay. So that means that today, I publish yesterday's data. The reason is that if there are a network partitions or synchronisation issues to get the data from the collectors to the centralised compacting location I have sometime to allow that process to happen. So multiple retries are tried throughout the day to get the data into a central location and that is why there is a delay. Also the delay allows insane compression ratios so it's very cheap to delay the data publication compared to realtime delivery.
I am almost outs of time, but cool things you can do with RPKI spools. You can discover backdating in the RPKI. I think this is important to be able to detect because if there are incidents we must be able to understand them and back Kate something something that gets if the way of that.
.
Mis‑issue ance happen. For instance, under APNIC, sometimes when you delete a ROA in the web UI, it let's old ROAs reappear for maybe a few second and then those disappear and then the system stabilizes. So it's really weird behaviour to explain but like, a ROA you created a few months ago and deleted a few months ago, can briefly reappear. That's not great.
.
What it also allows you to do is search for like is the RPKI consistent across the globe or are we in Europe seeing a lightly different version than in North America or in Asia? These are important questions to be, to answer, because we expect that the RPKI has some global consistency, like some eventual consistency, but is that actually happening or are there weirder things happening?
.
And if there are like, you know, lawsuits or a fact‑finding missions where it's of critical importance to really understand what happened when with absolute causal certainty, RPKI views is useful for those purposes as well.
Earlier this week somebody produced a ROA that was more than 100 characters file name. Apparently that doesn't fit in a US TAR format. I was using the packs utility standardised to interact it with US TAR formatted archives. I now use the TAR utility to work with PAX formatted archives because TAR supports the PAX interchange format but on many systems PAX does not support PAX. So I hope I cleared this up for you but you use the TAR utility to interact with the RPKI spools which followed a PAIX format.
Great.
.
If you have questions, reach out to me. I am doing this work because I think it helps the community and I think data collection is fascinating in and of itself. I have learned a lot trying to store all the data in a cheap way. If it's cheap for me it's cheap for you to analyse t what you do with it, that is up to you. And I will answer questions about how the archives are structured but like, your research is your research and I am just here to make that possible. Will so this is an open invitation to the community, please use the data that is there for free.
That's it thank you.
(Applause)
STEPHEN STROWES: Do we have any questions? We have one and two, we have running dangerously close to be over time.
AUDIENCE SPEAKER: Pavel. Have you considered any of the shelf databases for storing RPKI data and are you considering Indexing the data?
JOB SNIJDERS: This is a really good question. Thank you for that. And yeah, I have considered this at length, but if I were to store the data in say Postgres, what happens 20 years from now when everybody moved onto something else? So, I was really looking for, what is, like the intersection between efficient but also standardised multiple vendor accessibility? So then you really arrive at IETF standards or Postgres, neither of which have defined and online data engine so to speak. So, I consciously steer away from things like SQ light or Postgres or Marie dB or like what not, because I anticipate that the researchers will take the RPKI spool and then convert into it an intermediate state that is useful for their project at hand. So you take my spool in TAR format, you convert it to the database you like today, and you do whatever you want in that database, but I want to have it accessible in an open standards way.
AUDIENCE SPEAKER: Hi. The question is pretty quick if I understood it correctly the daily snapshot is not necessary to run your data so in case that have does it make sense for older data sacrifice it for CPU and just recreate it?
JOB SNIJDERS: So the daily snapshot is 500 megabytes and the daily change data is also about 500 megabytes. So, like, giving researchers a step up to like very quickly investigate a particular day by having the checkpoint start of the day and then the changes since that moment, I found was worth the 500 megabytes per day. In theory, yeah, if you apply a series of diffs consistently you don't need the intermediate check points. I am trying to accommodate more use cases or make it easier, lower the barrier so to speak.
E‑mail me at Job@BSD .nl if you need help with the archive or are willing to support in some way.
(Applause)
.
Now, our next speaker.
SHYAM KRISHNA KHADKA: Thank you very much for my introduction do it. Good afternoon everyone. I am Shyam, today I am going to talk about our work on detection and characterisation of DDOS scrubbing from BGP data. This was published recently as a paper in passive and active measurement conference.
First, let me start with an overview of DDOS scrubbing. As you see here, an AS, I say a customer AS basically originals its prefix B and it gives its announcements to an ISP. Then the ISP follows out to the rest of the Internet. So that is a normal conditions means no DDOS attack or no scrubbing is involved.
Now, consider a situation when a scrubber, such as CloudFlare, comes into play and this scenario, the customer AS starts announcing its prefix to this scrubber and this scrubber announce to the rest of the Internet. In way the inbound traffic to the customer goes through the scrubber, and the scrubber filters the malicious traffic providing only the legitimate traffic to the customer, which is represented by a green arrow. And the outbound traffic from the customer exits through the normal ISP.
So, with this figure, we see that the scrubbing involves sending routing behaviour and this is an example of attack G 1 scrubber. So the question we asked in this paper is: How can we infer scrubbing using BGP data? To answer that question, the first thing was to select the scrubbers. In this case, in this we selected CloudFlare, Akamai, Prolexic, Vercara, Imperva and Radware. So the reason for selecting those five are because there were top five in terms of their bandwidth capabilities to mitigate DDOS attack at the time of our study. And the second reason is that they were identified as the leading DDOS mitigation provider. And the third reason is that there doesn't exist a comprehensive and authoritative list of DDOS scrubber in the Internet.
The next step is identify the AS numbers they use for scrubbing. For that we inspected the documentation of those scrubbers. We had conversations with the scrubbers and we also analysed past scrubbing events that were mentioned as by companies such as Cisco thousand eyes, etc.
.
Next we analysed the public information collected by RS route collectors, we basically analyse the ribs and updates. Ribs is a snapshot of data that is collected every eight hours by the collectors while updates are collected every five minutes. And in our registry we analysed 30 days of data in May 2025.
Our inference basically looks into the AS paths that are associated with mitigation. And we require at least two collector peers. This is basically to improve the accuracy of our inference.
Using that methodology, we basically found two types of scrubbing, or we defined two types of scrubbing one is always on scrubbing. In this case the traffic towards the customer always goes through the scrubber, which means that upper prefix will have an scrubber as an object in its and AS path and we observed that in BGP ribs and we see, we see those prefixes have one of those scrubbers for 30 consecutive days.
So basically we see a customer and scrubber AS..
.
The second type of scrubbing is on demand scrubbing, which is basically attack driven activation and when the attack is over it gets deactivated.
To find this scrubbing, we analyse the BGP operator data and we observed two types of on demand scrubbing. The first one is upstream change. In this case the customers AS originate the prefix itself and the upstream providers to the scrubber. The second case is origin change, where the scrubber originates the attack prefix on behalf of the customer. In this ways we see the scrubber AS as an origin in BGP AS paths. So we detected those two types of on demand scrubbing using same day and cross day approach.
So same day means the scrubbing is activated and deactivated on the same day. While the cross day means scrubbing is activated on one day while it was deactivated on the next day. And we considered 48 hours as the study period.
Here, I present our findings of always on prefix for the five scrubbers of our study. We observed the dominance of Akamai in our dataset while we found a very low number of prefixes that worked for has its customers.
Next I present our findings on upstream change scrubbing for five scrubbers, here you can see in the Y axis that is scrubbing activations with means the number of prefixes that were scrubbed by those scrubber and the X axis represents the number of days. For now I want to draw your attention into CloudFlare and Akamai.
.
As you can see, CloudFlare was engaged everyday. All the days throughout the 30 days of our study. And it also gives us hints that the DDOS attack is still come on and there is at least one prefix that is under attack.
In the Akamai comes second to the CloudFlare.
Next we put our findings in origins and scrubbing here you see only four scrubbers, it is because we didn't observe any such cases for Imperva and we found a very low number of cases for CloudFlare and Akamai, for example you see only one origin send cases with CloudFlare. So it means most the customers of CloudFlare and Akamai go for on demand scrubbing.
And for Vercara and Radware, we found a high number of search origin chains scrubbing. For those prefixes we analysed their RPKI practices, because this is directly related to route object validation. For example, we observed 52% of those scrub prefixes were RPKI valid, while 12.35 percent are invalid. Invalid means that those prefixes originated by scrubbers didn't have ROAs with those scrubbers with origin ASNs. This indicates that the scrubbing approach might be undermined because the ROA validating ASes might drop so it's invalid announcement.
After analysing the number of prefixes that went scrubbing, we also analysed the duration, the scrubbing session duration. So in our case we define scrubbing session as the timing between the first time a route collector peer saw scrubbing activation and the last time a route collector peer saw the scrubbing changes.
As you can see in the figure, had 25% of scrubbing sessions lasted less than one hour and 25 minutes while the median duration was about ten hours and 25 minutes. Will we found some prefixes which lasted longer than 15 hours. And in our conversation with the scrubber, he mentioned that it might not necessarily web a DDOS attack are, it might be cases where the customers continued to announce their prefix towards the scrubber as a precaution. And this also gives us a hint about the durations of the DDOS attacks, that's happening.
Then to summarise our work.
We inferred scrubbing events use public BGP data.
We observed the dominance of always on prefix over on demand prefix in our study period.
So the reason could be the number of attacks in the time period might be low or in general always on prefix might be higher because of operational simplicity of such protection.
And we observed the dominance of upstream change over origin change scrubbing.
And we suspect, or we thought that the reason could be that the upstream change model of scrubbing gives the customer the flexibility to origin ate their prefixes themselves rather than delegating the prefix origin syntax to this scrubber.
And we found some RPKI invalid prefixes that were originated by scrubbing which might undermine mitigation approach. We hope this this type of insight could be useful for BGP monitoring systems to interpret routing changes that are consistent with scrubbing.
As a future work, we plan to measure the effectiveness of the scrubbing by measuring the coverage of routes during scrubbing. The reason is because there might be some questions where a scrubber is taking a long time to take control of all the Internet routes towards the customer and some malicious traffic may still be reaching the customer.
So, with that, I conclude my presentation. Thank you very much for your attention and I would be happy to take your questions.
(Applause (canned can thank you. So any questions? We have one.
AUDIENCE SPEAKER: Hello. Ivan Beveridge. No affiliation. I can talk to you separately about some of this, but a reason for, potentially a reason for always on is certainly with companies that don't want to get hit and then have to take a while to actually go under mitigation and typically those companies sort of have high value traffic, and so they'll pay the higher upfront costs for that. Also, potentially, for those who are, you found some long running going into mitigation and then taking a while to come out, some companies also kind of want to come out either when they are fairly sure that all the DDOS traffic is gone or during a maintenance slot to some extent, so you may find that if they have got a maintenance slot at 10 p.m., or something like that, even though they went under at 1 a.m., they may leave it till 10 a.m. that day to actually come out even though the traffic in, the DDOS traffic might have stopped within half an hour. I am happy to talk to you after. Thank you very much.
MASSIMO CANDELA: Thank you very much. Now, we go to the last presenter of this session, we have David Belson.
DAVID BELSON: I am unfortunately the former head of data inside CloudFlare, I was hit in the layoffs that happened last week. So, the content I am presenting today is based on public graphs, it's nothing proprietary in there, but I am not officially representing Radar CloudFlare in this context.
But, what I want to talk about today is a high level overview of using CloudFlare Radar to help us understand more about what happened in Iran and with Iran's Internet during these shutdowns.
So, I am sure that many of are you familiar with CloudFlare Radar, but for the few of you that may not be, it's a platform for global Internet traffic security and routing and technology trends and insights that are built on top of data from CloudFlare's network. For the most part we do get some other data from other organisations within the industry.
Radar.CloudFlare.com, I definitely encourage to you check it out and explore it when you have time.
So, we'll talk a bit of about background. Some things that we saw ahead of January 8 shutdown. What happened on January 8th. What happened then on the second shutdown on February 28th. Some artifacts of circumvention tools that may have been used in Iran and then just a quick wrap‑up.
So, in the past, you know, Iran is no stranger to Internet shutdowns. Back in September 2022, there were a number of shutdowns and curfews that were implemented during the protests that were related to the killing of Mahsa Amini. You can see traffic bottoming out over several days in late September early October there in the graphs. That shows similar patterns were shown within the country.
Then almost a year ago when Israel launched a campaign of attacks against nuclear military infrastructure in Iran, you can see some impact Internet connectivity there as well, that attack happened on June 13th and some initial restrictions were put in place that day, you can see traffic dropping, and then there is a very clear shutdown that took place between 18th and 21st, you can see the traffic line there going to zero effectively and then traffic began to return after the ceasefire was announced on June 23rd.
So you can see it start to go climb after that and then returning to more near normal levels the following days.
So, if we look at the initial January 8th shutdown, what happened before it that might have given us a sense that something was happening? So, on New Year's day one of the things observed was that the share of DoH traffic or HTTP traffic from key Iranian networks to the clout one resolver operated by CloudFlare that more than doubled across these network providers. While not a smoking gun that anything was going to be happening, it may have been indicative of additional filtering or increased filtering of DNS traffic over port 53. So standard unencrypted DNS traffic.
And then similarly, we saw shifts across the same networks in terms of traffic share for HTTP 3 and QUIC. Starting on January 3rd, where these networks generally saw h3 and QUIC traffic account for about 40%. And then dropped to generally below 5 percent, there were a couple of spikes there you can see across TCI. But again, you know, this may suggest there was some increased filtering put in place.
Perhaps the most interesting observation here is what happened just before the Internet shutdown was implemented on January 8. So about four hours ahead of that, just before noon UTC, we observed almost 99% drop in announced IPv6 space from Iran. So it went down from about 4 8.4 million /48s, down to 737,000 /48s. Just together accounted for about 17 or18 percent of the lost IP space, they both saw significant drops.
The upside here is that the Radar data showed that whilst the percentage HTTP requests from Iran took place over IPv6. So, ultimately, you know, the withdrawal of the space really had no impact on the overall traffic from the country. So it wasn't really necessarily hey, we're withdrawing IPv6 space, we're going to see traffic drop significantly.
But what we did see happen was that, you know, after the two weeks approach, since around Christmas time, they finally implemented or imposed a complete shutdown. So, traffic fell really rapidly, you can see that obviously in the graphs. Around 16:30 UTC, you can see it plateaus for about an hour. The graph on the right there, by region, is zoomed in to just 24 hour view, you see it plateau there a bit and then another hour later drops off completely basically and goes to zero.
So, it's not clear why the plateau that I mentioned happened only across four of the five providers. Right sell was the one that only went to zero. It's not clear why they were sort of singled out there. The graph on the left shows HTTP request traffic. The graph on the right shows DNS request traffic to the quad 1 resolver. What you can see there is that it drops off again at the same time armed 16:30 UTC on 8th, but then the next day, we see some traffic return of a bit. So traffic, DNS request traffic from both TCI and MCCI spiked around 10 o'clock UTC. And then DNS traffic from AS 49666, the Orange line there, returned around the same time, but stayed more consistent, albeit at a lower level.
Then we saw traffic recovery in fits and starts throughout January. There are a few days where we saw traffic blips, really, really small once, 17th and 18th. A bit more sustained and higher on the 21st and 22nd. Same thing on the 25th and 26th. Then recovery starting on the 27th. Most of that traffic that we observed coming back generally was from MCCI and Iran cell, so two major global provides in the country. Then after the end of January, we basically saw traffic more consistent throughout February.
And that is of course until the events of February 28th.
So, on February 28th, the US launched attacks on Iran around 9:45 local time, and about 7 o'clock UTC, about 45 minutes later, we saw Internet traffic from the country drop precipitously. And really hit about, at that point hit about 98% lower than the same time the previous week. Clearly things were shut down.
And what you can see if you look at it from the top providers, is again, you know, the HTTP request traffic dropped to zero basically almost immediately. You can see also the traffic, the DNS traffic drop is visible within the chart on the right. So February 28th, you can see a lit of drop there. You can see it goes away across most of those major providers. You will see it start to grow again over the next few days and then it drops off sharply around March 6th.
So, if we look alt the traffic distribution across the ASNs within Iran. You can see the few days leading up to February 28th is fairly consistent. But after February 28th, about the 99% of the traffic was loss from Iran. And you can see that the distribution of the Iranian traffic was revery different. Iran cell in the light blue was dominantly for the first week and then dropped. And then you can see that MCCI had a smaller share in the first week but then grew and was responsible for almost half of the traffic times throughout March and April.
And the shutdown, you know, is still going on. We have seen a little bit of growth. You can see it there in the chart, some, you know, minor movement starting in mid‑April. That's due to a law listing of website web applications and due to the so‑called white SIMs and the Internet pro service where there is tiered access for different folks within the country. But by and large, the restrictions in the filtering remained in place. It updated this graph basically through this weekend bun unfortunately I loss access to the internal system that this graph comes from when I was let go last week.
So, you know, we see there is traffic going away but we also know that there's been attempts at circumvention. So the DNS traffic analysis for the DNS traffic I think gives a good constructive often that.
.
So DNS TT is a tunnelling tool that can be used DoH, DOT or UDP 33, and attempts to encode data in resource records like text records. So, that previous spike I mentioned after the following, following February 20th shutdown, we can see on the traffic on the right that, you know, there was a big growth in DNS requests over UDP 53 because it was so ‑‑ the majority was removed from the graph, and then what we can see also on February 28th, is that the share of telecommunications record requests coming from Iran also grew significantly. So basically it was the majority of the requests over that first week.
But we can also see, so clearer, in this text record requests were coming from a mix of the major providers, nearly all of those requests are coming from Iran cell and CCI, Iran cell and TCI. Something shifted on March 6th, and we saw that the text record traffic from Rye cell, MCCI and Iran cell dropped significantly, over time it basically disappeared. You can see the dark blue, light blue and Orange just petter off over the coming weeks.
So, another indicator here, another potential artifact or circumvention is this burst in traffic that we saw on April 14th. This coincides with the release on GitHub of a tool called SNI snoop RS, it's intended to work through CloudFlare but, you know, we believe that the short duration of this spike suggested the authorities in Iran probably detected it and blocked it very quickly.
And unfortunately, this is something that was asked about a lot. As the media was covering the shutdowns is, you know, what about Starlink? Can you have any visibility into Starlink usage in Iran? Unfortunately because there are no Iranian entities in the Starlink geofeed we don't have visibility into the traffic coming from Starlink in Iran.
So, just, you know, wrapping up. Iranian citizens unfortunately have spent most of 2026 offline. Little traffic is left from Iran, distribution across providers is very different than what was before February 28th. And be careful out there if you are use circumvention tools, because they can leave fingerprints.
Finally, contact information for both me and where to find Radar, the Radar resources, and if there is, I know there is a few seconds left, if there are any questions.
(Applause)
AUDIENCE SPEAKER: Hi Warren. Google. Would you mind going back to slide 4 and while you are doing that, CloudFlare Radar is a really wonderful service and I am sincerely sorry that you are no longer involved with it. I hope it continues to exist and thrive.
DAVID BELSON: As do I.
AUDIENCE SPEAKER: So looking on the right graph, before the shutdown, there was a noticeable difference between total bytes and HTTP bytes. And then after the shutdown when it came back is the Delta mainly sort of the loss of 1.1.1 DNS traffic or do we know what the Delta is? Like why the lines now match?
DAVID BELSON: I don't know. So, if I had ‑‑ I can try to dig ‑‑ well I can try to contact folks to try and dig into it but what the Delta may be, would be potentially a DNS related traffic, potentially warp traffic. We had graphs internally that would show, break out the traffic by service. Sometimes when we see these gaps we'll see warp or DNS often accounting for the difference.
AUDIENCE SPEAKER: Shane Kerr, IBM. I am also very grateful that you were able to make this presentation.
Do you think it's possible that that increase in TXT record traffic was from IP over DNS or something equally terrible?
DAVID BELSON: I don't know. So, we didn't dig into, you know, obviously what was in the requests. We were just doing the analysis by breaking it out by the different protocols or different request types, things like that. So... but in line with what DNS TT can do.
AUDIENCE SPEAKER: Blake Willis, speaks as someone with a lot of Persian American and Persian Canadian friends. One of whom got back from Iran yesterday. On a say sightseeing trip in that airport got bombed, so she had to change her flight. Thank you very much for this, I am sorry to hear about the layoffs. Obviously it's pretty hard to see because people are changing their location and so forth, but my friend who was there was able to chat with me just fine while she was there over a VPN and I have no idea how that was actually working but she gave me the IPs of her servers and they were all in Iran. Do you have any ‑‑ I know the data is probably not concurrent enough to share here but do you have any visibility into VPN use and the success that have during this time?
DAVID BELSON: Not offhand. The only thing I can think of would be if you know ‑‑ so you have the IPs and you know that the ‑‑ well and you know ‑‑ sorry, if they are like third party VPN providers, and you know the ASNs, you could use the Radar data explorer to look for traffic from Iran and AS whatever to see if that's coming through. But if it's a VPN server that's on one of the regular Iranian networks, you sort of ‑‑ it looks like the rest of the traffic.
NINA BARGISEN: Thank you he so much. Thank you David.
(Applause)
.
All right. And this brings us to the end of this working group. I am going to do all the remarks.
Please rate, please rate the presentations. Discuss them on our mailing list, and you can send us direct feedback.
Before I let you go, there is one announcement that we haven't done yet.
It's going to be very brief. It is that this is my last RIPE meeting as a working group Chair format Working Group. I have been around forever. I do not want to count. So, it is time for new blood. So, the process is going to be handled by remaining co‑chairs opt mailing list, but I just want to say thank you to all of you for all the years, it's been great. Love you all and see you all in Sophia.
(Applause)
.
.
.
.
.
.
.
Next up is the diversity in tech.