RIPE 91
4 pm main room.
Plenary.
FRANZISKA LICHTBLAU: Let's get started with this session please. Everyone come in, find your chairs, we have plenty of chairs, doors will close any second...
Come in, I suggest we start on time so we can actually get out on time again.
So, welcome to day one to the afternoon plenary session of RIPE 91. I am Franziska and together with Antonio, we will chair this session for you, we will have two full presentations, three lightning talks for you today, so I hope you enjoy it. And without further ado, our first speaker is Dirk from Radboud university and SIDN Labs and he will talk to us about how we are going to pave the way for post‑quantum cryptography for RPKI
Dirk.
DIRK DOESBURG: Hi everyone, my name is Dirk, I recently did my masters thesis at Radboud university and with the people... the topic is post‑quantam cryptography for RPKI and let's get started with a quick recap of what RPKI is. So RPKI is a hierarchy of CAs, resource certificates that are owned by resource holders so this contains statements like this company can control the following resource, internet resources.
At the leaves of RPKI are signed objects such as ROAs that are verifiable statements about what some companies wants to happen in routing.
These certificates and signed objects are then tub pub published in a repository and downloaded by all verified parties...
So all of the signatures in RPKI are currently RSA signatures and this goes for certificates, for the signatures signed objects as well as for the communication between CAs and CAs and their repositories.
So there's been this fear that RSA will be broken by sufficiently powerful quantam computers and as a consequence, people have been trying to prepare to switch to post‑quantum cryptography, in some applications where confidence is important, there is good progress on this, TLS encryption can use past quantam cryptography and in these applications it's very urgent because somebody could store encrypted data right now and wait for five or ten or fifty years and finally decrypt this data and get your secrets.
Other applications don't need confidentiality but integrity, some examples are of this are DNS SEC and TLS, at least TLS authentication, this is much less urgent but still there's some progress going on because these are not simple protocols for change, and for RPKI, that's one more example where integrity matters and confidentiality does not but there are nothing until now has been done.
So some of you might wonder and some have even ready asked why should we worry about RPKI right now. And simple answer is because migrating will take years, many years. And we know this from experience, so for example in the DNS SEC, there's in graph chart from my supervisor about how long it took to introduce... Crypto for DNS SEC, it took five years between the initial draft and the first signed...
So if we take it takes ten years before we need post‑quantam rip tow in the RPKI, it seems like about the right time to start actually thinking about that.
Second there's an interesting difference between applications like DNS SEC, where TLS authentication and RPKI so in many applications, if you can forge signatures, that means you can rob one layer of protection, in DNS SEC, if you forge a signature that means that you can essentially down grade to plain DNS, in RPKI we will see that it can actually be much worse which makes it more important to, yeah, think about this.
So let's assume for a minute that someone can actually create forgeries. The obvious attack would be you can forge a ROA, that allows some malicious BGP announcement, we are making vulnerable you can make your malicious BGP announcement valid, it was bypass the validation, there's a worse attack that you can do which is using revocation, so by forging a certificate revocation list that revokes legitimate ROAs or even entire CAs, you can actually make all current announcements legitimate announcements become R OV invalid and make sure the malicious announce am, you can have this announcement be the only option that is considered so it doesn't even have to compete with legitimate paths any more. So this way you can actually weaponise the RPKI when the Crypto is broken to be worse than BGP without the RPKI.
And of course something similar can be done where you don't make a ROA for your legitimate, your malicious route, to make everything unroutable and similar attacks can be done using aspa.
Skipping two pages. So we have assumed that making a forgery is possible but actually forging a signature does not guarantee that you can also get your forged objects to be validated by relying parties. So how do you make this happen? There's four ways that are listed here, essentially in order of how easy they are. First there's the option to make a forgery of an RFC 492 message, this is essentially a certificate signing request used between a CA and its parent. So if you can forge one of those, you can request your parent's access route to make a certificate that gives your malicious key the resource address of your victim's CA. This is a simple way in a single signature, you can take over an entire CA.
Next, if this doesn't work you can forge actual RPKI objects and then get them published in a CA by attacking RFC 8181 so similar protocol for messages from a CA to its repository, this is somewhat harder but it can still work. Then entirely different attack is by attacking a web interface such as RIPE's RPKI dashboard, of course if you can steal a session there, it's quite easy to make ROAs for whatever you want, without actually needing to forge RSA signatures at all.
And finally there's the hardest way which is forging RPKI objects and not injecting them in a repository but injecting them in the traffic from a repository to a relying party, you could try to down grade disconnection from RDP to to R‑sync, it's non‑encrypted, it's reasonably easy to inject something but keep in mind you would have to do this on the trafficked in many relying parties to actually make an attack work, it's not as easy as it sounds.
So now to my thesis. How can we protect against this. So first this attack that works by attacking the web interfaces of for example RIPE, I leave it out of scope, there's very smart people that are figuring out how to secure TLS work for example, it needs to happen but I don't focus on it. But I worked on RPKI objects themselves so the RSA signatures, and finally there's the RFC 183 protocol which essentially manages the authentication of messages between CAs, this is somewhat easier to replace in the signatures than in RPKI itself because it's only local, but there's still something missing there, which is a way to replace the trust anchors that are used between these parties inbound and this is an issue that was already brought up at the IETF a couple of years ago. As part of my thesis, there's four topics that I go into, first what signature can you use to replace RSA. And similarly what is the performance impact of making this change. Then I proposed a way to mitigate the large part of this performance impact and finally there's the question of how do you actually do the network migration in the RPKI.
So first off, let's see what post‑quantam algorithm would be suitable. NIST have a competition where three signatures algorithms were standardised and there's a second competition for additional candidates that also has some more options, these options all come in five different security levels and it turns out that the level one, the lowest of them all is actually sufficient for the RPKI because it's still stronger than RSA.
To be safe, if one of these new algorithms turns out to be broken, it's a good idea to still use hybrid, so combining traditional Crypto with post‑quantam ones and then they are on to the most interesting part which is performance, so there's two criteria, the size of both signature and public keys and verification speed. For size it's good to keep in mind that post‑quantam signatures are almost always much larger than their traditional counterparts. And the RPKI consists of many, many signatures and also many public keys that are all downloaded by every single Rel league party, increasing the signature size amounts to quite a lot of data that has to be downloaded. So to get an idea of how big the impacts of this change would be for a given algorithm, the baseline measurement of how long it takes to download all of this data, when using routinator when you measure only the amount of time it takes to download RDP snapshots, so only the snapshots, that excludes a lot of constant delays when setting up sessions or waiting for time‑outs, then I got to roughly 14 and a half seconds from a Dutch data centre, this is somewhat optimistic but the idea is if the size doubles, then the time spent, this 14 and a half seconds would also double. Similarly for verification speed, every single validator will periodically verify every single signature, so this should be also measured, again this turned out to take 13 CPU seconds and again if signature verification for a single signature becomes twice as slow, we expect it also to become twice as slow for the whole bunch.
Now, keep in mind 13 and 14.5 seconds are not comparable to each other, this 13 seconds is single core CPU time, you can paralyze it somewhat easily whereas downloading time is much harder to do and also these numbers don't reflect every single relying party.
So when you apply these base lines to post‑quantam algorithms, then this is what we get. So this shows the total size that RPKI would get if you use the estimated download time and estimated verification CPU time and the conclusion from this table is Falcon 512 is probably the best option, it's one of the initial winners of NIST competition which means it will be standardised much sooner than some of the option further down this list if they got standardised at all. It will be available much sooner than the others and in size and verification speed, it performs quite well.
Yeah, so I said we should use a hybrid. The hybrid component is not included in this list but keep in mind there would be some extra overheads for using hybrid, there's just no clear choice on that traditional components should be used here. And some of these options further down this list would also work of course but yeah, they are just less secure choices right now.
So, now that we see what what impact we can expect, there's actually a way to mitigate a large part of this. Because many of the signatures in RPKI don't actually really need to be there.
So right now every single signed object in RPKI which includes both ROAs and also for example manifest contain two signatures and one public key each. There's one signature from the CA on a certificate, this certificate has a subject public key for one time use key pair and using this key pair there's one signature made on the actual content of the object. So the total cost is two signatures and one public key, intuitively you would assume only one signature directly from the CA on the object should be enough so you might wonder why is this.
The answer is revocation, revocation in the RPKI uses revocation list, particularly certificate revocation list, so these are listed of certificates that have been revoked and quite simply they only contain certificates whereas this one signature would be a CMS signed data object which is not a certificate.
So this inter immediate layer is only used once is only there to allow revocation. So that's not that efficient. So I was wondering can we do this more efficiently and indeed we can. The trick here is the null scheme, which is a specialised signature scheme I came up with that works essential essentially still keeping an end entity certificate in there, subject the public key of this certificate instead of an RSA public key be the hash of the content to be signed, the signature we also still leave in there but they can be empty and verification is done simply comparing the signed objects content with the hash that's in the public key field of the certificate and the total cost of this per on correct is one signature and one hash.
Which is less than the two signatures and one public key.
But structurally, signed objects remain the same, we don't actually need any changes to the protocols only an hour for migration to the null scheme for for these objects.
So by introducing this we can save quite a lot of size, so for example in median sized ROA, we can get rid of roughly a quarter of total size, when the size of the signatures and public keys increases, then the savings also increase.
So if we were to use for example hybrid with Falcon and RSA, we can save half of the size of the typical ROA. And similarly for verification, we save 35% regardless of what algorithm is used.
So clearly when we introduce this together with post‑quantam Crypto, we can get quite close to what they were before or what they were right now.
Over the summer I worked it out in more detail, there's an internet draft you might have seen in the sidrops mailing list. I have also implemented this in kill to show that it actually works, feel free to try it out, make it yourself. Whatever.
And then we are back to the actual main content, this is perhaps the most important part, how do we actually perform the algorithm migration.
On first inspection, this is quite simple because there's an RFC that prescribes how to do it which is 6916. The idea of the RFC is essentially that first we set a couple of milestone dates to be published in an RFC.
Then we create an algorithm B version of the RPKI top down. When that's done, when every CA has made a copy of itself then relying parties can switch from the A version to the B version and eventually when all of the relying parties have switched, the algorithm B3 can be removed.
Now this is, this has never been used before and I would say it's quite unattractive, I don't think it would work as well if we did try this, it has some downside which is first of all that it is top down, this means that there needs to be a lot of co‑ordination between every single CA here, a member of RIPE can only migrate after RIPE itself has made it B version, this also means the first relying parties can only switch when every single CA has also made it over from B version, so this co‑ordination is just very complicated, there's also the parallel 3 maintenance, they need to be kept synchronised which is just pretty hard to do so all of these concerns have actual will he been brought up back when this RFC was still a draft, but the discussion turned sour a little bit and eventually it was published as is.
Luckily there is quite easy alternative, which is using mixed trees, in this scenario, CA can have an algorithm B child and the other way around as well. Which simplifies a lot of things. So it works in essentially three steps. First of all, you would update relying party software, so publish up software that can be updated, at the same time it would be good if the trust anchors such as RIPE already publish the keys that they will end up using. Even if they don't start using them just yet. This way they can be packaged in the relying party updates packages.
And then there's a long phase of simply waiting. You have these updates published and just wait for everyone to start using these. That will take of course probably a couple of years but that's fine. During this time you can actually already start measuring whether relying parties have indeed updated so you can see in the second little tree that there is already one CA using algorithm B, now this is CA wouldn't know for sure whether people actually validated this product but that way you can start measuring how relying parties are doing. And this is also nice for experimentation before we actually start migrating at all. Finally when all of the validators have updated or at least sufficiently many or when post‑quantam Crypto really becomes urgent shall every single CA can start rolling up individually which is now just a local decision for a single CA so they don't have to wait for their parent to go first and they also don't have to wait for their children to go first, it's a strictly local change which is done using only a simple key role so there's a working procedure for key rollover that's used a lot, so this makes it really easy for operators to actually do this change eventually.
I have also implemented this in key roll, we know it works quite easily and it works like a charm.
So this different approach has a couple of advantages compared to RFC 616 which comes down to that, it's much easier for operators as a consequence of it not being top down, we don't have to maintain two versions of the RPKI in parallel. Both also need to contain the same data. Operators don't have to co‑ordinate with their parents or their children to do the migration, we can already do experiments using an experimental CA even before RIPE creates a B version, so it's just more flexible for operators which is something I think operators will just appreciate and eventually would also make things move quicker.
And finally there's this nice feature that we can use this to introduce more than one scheme so you could have for example Falcon post‑quantam scheme but also some other option so that if latter space Crypto, which includes Falcon, turns out to be a broken, there's still a different algorithm you can quickly switch to. And similarly you could chose to use stronger but less performance Crypto, for example trust anchors or business RPKI that is used between C ats, they are not performance critical. Wrapping up, I think there's a few steps we can do to prepare for post‑quantam Crypto in RPKI which is first introducing the null scheme, I think that would be a really nice way to avoid much of the performance overhead that will inevitably be added by post signatures, as an alternative first step, we could also do elyptic curve crypto to try out the mixed tree migration procedure and get some nice performance improvement in the meantime, although that will be lost when we actually need post‑quantam signatures. Regarding the added fall back, we should use Falcon 512, it's one of the widely available ones for now. We can consider adding fall back algorithm, that's not letters based or using this more secure but less performance signatures for trust anchors and finally when we doify great the first steps should be updating relying party software, publishing the trust anchors to be used later on and the rest can wait for many years.
That's it. So we should have some time for questions now.
ANTONIO PRADO: Thank you, Dirk, I see there are questions, Jim?
JIM REID: Just some random guy that wandered in off the street. I think you are doing great work here, it's fascinating stuff, please keep it up. I was a little bit alarmed though when you say this taking of the order of 15 CPU seconds to validate a PQ signature, I wonder how much of that will translate into the real world? It seems to me that may be too much for an operator, I am not an operator, I clearly don't know what I'm talking about here but I wonder if you have got any indications from operators the requirements that they have for things like signature lengths and validations?
DIRK DOESBURG: I verified every single signature so it's not for 50 seconds for one signature.
JIM REID: OK, thank you.
DIRK DOESBURG: There are signatures that would take 50 seconds originally but I didn't consider those options at all.
AUDIENCE SPEAKER: The problem with deployment both of DNS SEC and the new post‑quantam algorithms isn't actually the standards, it's open SSL, it's stuff like Redhead Aid having open SSL 1.1 and not even the provider for all the QS so the reason why it takes so long for ECDSA to get into DNS SEC was actually the open SSL because it was so complicated to get the algorithm and it's going to be problem for PQC as well if we don't push open SSL to actually implement Falcon in our algorithms soon enough, just look what happened with QUIC in open SSL, it's a complete disaster. Implementing QUIC in any project is just impossible unless you just like bold and glue and use a lot of duct tape, it is a major implementation, it's going to be the same problem with PQC if nothing happens in open SSL because there would be no algorithm support and the implementers have a hard time to implement the PQC this their software.
DIRK DOESBURG: I agree, I have to say for implementation side, there was no need to use SSL at all, as long as of course at least for this more niche software, yeah, I hope they do.
ANTONIO PRADO: We have a question, Franziska?
FRANZISKA LICHTBLAU: Yes, can I, we have a question from the chat. A and we are chosing the queue for this one and Michael Richardson asked: Proposed IETF working group plans would merge CT, CL and CRL signatures into Merkle trees, would you look at whether this would help with RPKI?
DIRK DOESBURG: That's tough. I have not. I expect big changes with RPKI are probably not realistic, which is also why there's no scheme for this. It's not much efficient but it's easy to introduce so, simple is important.
ANTONIO PRADO: OK, last question, Marco.
AUDIENCE SPEAKER: We need to start now, you are arguing that we need to start using post‑quantam cryptography for RPKI because update DNS resolver takes a lot of time but I think this is an invalid assumption, updating RPKI validators will take much less time because there is a really tiny number of validators, maybe 1,000, over the world. So I think there is no hurry right now to use a post‑quantam Crypto for RPKI and we can maybe wait for more analysis and better standardisation of the algorithms and better libraries.
DIRK DOESBURG: I would recommend the need to wait a little longer, I have seen some charts of how long it takes for new RPKI validator software to get deployed, it's not actually that fast. So I think a half life of two years, so that's still a couple of years you could hurry of it course but yeah.
ANTONIO PRADO: Thank you. Thank you, Dirk.
(APPLAUSE.)
OK. We have now BGP and DNS, our main topics for us an also for Lefteris I guess, my friend Lefteris, monitoring route DNS prefixes.
LEFTERIS MANASSAKIS: Hello everyone. My name is Lefteris, I work for Cisco Thousand Eyes as an engineering technical leader. We are a group of researchers from Crete in Greece. We started a start‑up that did BGP monitoring, named code BGP, it was acquired by Cisco in August of 23. This presentation contains a project we started while at code BGP in January of 2023. And it's about monitoring route DNS prefixes.
Before I devilled into to the topic, I need to speak a bit about BGP, it's the glue that holdings the internet together. But it's vulnerable to attacks, due to viruses. It's a specification that dates back to the late 80s where the internet was surprised by research institutes, universities, and entities that essentially trusted each other. So there was no inherent need to embed security in the protocol, a lot of things have changed since then of course, the advent of RPKI and many other things make BGP more secure but we still have issues.
Also I need to say a few things about what are the root DNS servers, they are the authoritative name servers for the DNS root zone, essentially they are the core of the DNS system. And we have, we have 26 including the six prefixes that have been announced by 11 operators. All over the world.
One question is why are we monitoring them?
There is one reason that I have not included in the slides. We were a small start‑up from Crete and we wanted to detect events because we wanted visibility. Also, it was critical internet infrastructure and worth protecting and also since these prefixes are heavily anycasted due to the nature of DNS, we were expecting that any exact prefix hijacks would have limited impact on the data plane because due to the nature of BGP, like forwarding only, I mean hiding all the paths and showing only the best paths, only the exact prefix hijack would be affected, that was our hunch.
It's quite easy to alert on such events because essentially you identify the covering prefix of the IP address of root DNS server IP and identify the ASN that announce it's and it create a rule if I see it in the origin, any other AS other than the AS supposed to announce this prefix, I will let it it. The only exception to this role is Verisign. Because Verisign uses a unique ASN node, it's described in detail in RFC 6382 what they do, the reason they do it mainly is more more granular monitoring because they know for each ASN where they are using it, which location in the world, if they see any hijacks, they know exactly where it happened, but this is quite interesting and also it's interesting how the visualisation of this announcement turns up in the Thousand Eyes platform, it looked like a mushroom, on the left‑hand side we see the monitors that see the prefix available in this case, after the number of hops that are hidden in this view, we see the AS which is the other AS of Verisign, right next we have all the ASes that use all the nodes by Verisign and on the right side we see what's availed.
So now I am going to start presenting the events that we detected, we started monitoring on January 15, 2023, a few weeks later, AS 24028 appeared as origin of the prefix of the inter systems consortium, I want to say that I have deliberately not included names of companies, only the AS numbers because the goal here is not to name and shame, the goal is to raise awareness mainly.
This event was visible only by one RIPE RIS monitor residing in Singapore. And the reason I assume is due to the fact these were six prefixes covered by a A, the propagation of this announcement was very limited. On February 25, 2023, we have an event that was slightly more interesting. AS 17639 appeared as origin of the prefix of the consortium again. On the same date, same time stamp, everything the same, the same AS also announced the v6 prefix of v‑root of NASA and this served as an experiment on the real internet how RPKI can impact the revocation of announcements because the E‑root case, in the E‑root blast rate of the event was three times larger compared to F root and E‑root was not covered by ROA and F root is covered by a ROA.
On June 12, to 2023, AS 201333 appeared as the origin of the F‑Root prefix of RIPE NCC, for all these events we are informing the network operators, the DNS operators that we have detected these events, and in some cases we didn't get an answer, in other case we got an answer, we are looking into it but the issue was not resolved for hours or days. In the case of RIPE NCC, the good folks of RIPE NCC replied immediately, essentially in event was visible only in Italy, it had local impact and it was a miss configured host stripping the AS of RIPE NCC and propagating the announcement, they would throw the prefix from this specific host and the issue was resolved.
And on April 28, 2023, AS 137661, an India network appeared as origin of the prefix of acan, we will focus on this E a bit more because it is quite interesting. The first thing is that this announcement has a very long AS path, it's 11 hops long due to the fact that one of the ASes is prepended seven times. That's why at the time of the detection it was only being picked up by one monitor of Code BGP back then, nothing else. I mean we were using the RIPE NCC monitors and the RIPE RIS dataset and our own monitors, only one monitor was picking it up.
Also the super prefix was being announced by the same AS, the super prefix of this specific speaks also belongs to ICANN and it was being announced by the same AS and it was not being picked up, not by RIS or our own monitors. I was only able to see it in LookingGlasses such as one as the one that I have shown here.
So I started monitoring the AS itself, to see exactly what they are doing, what they are announcing. So the only, they were announcing various prefixes, the only prefixes that were prepended seven times were the two prefixes of ICANN, which I found quite interesting.
So, this AS was announcing these two prefixes to their upstreams, they had two upstreams. And another India network, it was brought back to AS 9498, Bharti Airtel, one of the big networks from Indian and it was propagating the announcement to all the public peering points, essentially to all the locations where they had presence in IXPs and here we can see a screenshot from links Alice Looking Glass.
All the IXPs were propagating the announcement and that's how I was picking it up, except for Dee kicks because they were using routing security hygiene and they stopped the announcement that have legal origins using I should mention you know as a notable exception that DECIX was not propagating the announcement. As I said, it was picked up only from own monitors initially because later, it was also picked up and being picked up by a few RIPE RIS monitors but initially was not being pick up anything else else other than the code BGP monitors and this topic is a well known research topic. Like research has shown that carefully crafted hijacks to avoid detection by public sources are feasible. So we have had the like some relations in the paper that I mentioned in the slide was offered by the way by one of our master students, it is visible but this was shown only in simulations, we have not had examples from the real internet of such events but apparently they exist, it's not just theory.
And we stopped monitoring in August of 23 because the company was acquired and the core BGP platform got decommissioned, we started monitoring again in the summer of 2024 and the event was still ongoing.
This is how the visualisation of AS paths for this event is visible in the Thousand Eyes platform, you see how the legitimate path is only in favour with the illegitimate one an it was being picked up only by two monitors again who reside in India. No other monitor was able to see the event one year later.
And also now that we are with Thousand Eyes, one of the cool things ‑‑ when we joined we were thinking that and also before when we were at Code BGP, when we wanted to talk about data plane impact, we had no data because the code BGP platform was a pure control plane platform, so I mean we were saying in low posts that we assume the impact on the data plane would be illegible of the announcement, since they have to so low visibility but now with Thousand Eyes, measure and see exactly what is the impact, in this case of this announce. Only three probes in India, cloud acts as we call them were forwarding queries via the offending ASN, the impact of this E was limited only in India.
And lastly, the last event we detected it was on June 20th of this year, 2025, a Peruvian network, AS 3132 appeared as origin of the v4 prefix of ICANN and we will delve more deeper on this event since we have more data now. The event was seen only again by 19 out of the many hundreds of BGP monitors, therefore the visibility of this event was also limited and here we see again how the prefix is withdrawn, one with the dots, the dotted line, the legitimate path he is essentially is withdrawn in favour of the illegitimate one, on the time stamp of the event when it happened.
The BGP updates table that we have developed using the BMPprotocol 7854, we can see that AS which is picking autopsynd propagating the announcement is AS 3356, Lumin. And as I said, now we can measure the impact on the data plane and since we are talking about DNS prefixes, the most suitable test is DNS test essentially, you query a .org domain because L‑Root serves among other . org domains, I use the Wikipedia.org, and select the L‑Root IPs as. Look up servers and your goal is to see, to create an alert rule and see all of the paths that you get from the 1,000 like probes that we have cloud agents we call them all over the world, how many of them are impacted, how many of them forward traffic towards a route prefix through the illegitimate AS and you might wonder why do you care, I think most people would know that I mean we have no information on intention but when it goes through an AS that is not supposed to, this AS can eavesdrop, can manipulate DNS queries, they are not encrypted in most cases. So it's not great I would say.
What we detected is that out of the 1,000, more than 1,000 probes that we have already over the world, 104 of them were forwarding DNS queries via the offending ASN. And let me go back a bit.
Can I? I can't. In this case, I managed to speak with the ICANN people in IETF in Dublin, they identified the event, it was again a misconfiguration, they with clawed the prefix from the host ‑‑ they withdrew the prefix from the host and the issue was resolved, traffic data was 3%, it was not 10% and it was not a malicious event, it was a misconfiguration essentially but in any case, I cared to inform them. So to conclude, RIPE NCC has a very intuitive and easy to use interface for RPKI ROAs. It's very easy to do for the people who who have not done it yet, they must do it because as I have shown, it protects a lot your prefixes an also in BGP, the more you look, the more you find as we know and there's a need for quality BGP monitoring.
Thank you very much for your attention. And I would like to hear your questions.
(I would love)
FRANZISKA LICHTBLAU: Thank you very much. And you can ask questions online, via Meetecho and in the room and we start at the microphone here.
AUDIENCE SPEAKER: Rudiger Volk. Let me first put a question and then actually comment on the question.
Did I miss anything beyond detecting that an unexpected AS origin showed up in the root for triggering your evaluation that there is a hijack?
LEFTERIS MANASSAKIS: No, you didn't miss anything I would say.
RUDIGER VOLK: So a kind of one wonders how, well OK how much that actually buys, that means that an attacker who actually wants to go under the radar of your system just has to fake the original AS and we know there is nothing that prevents fake ASes, fake origin ASes in the current routing system. Maybe when as par is around, kind of faking of origin can be not that easily subverted but kind of any serious attacker quite obviously has a freeway.
LEFTERIS MANASSAKIS: I mean given the fact that not every network does BGP pre‑filtering and not every network does RPKI correctly yes you are right, there is a chance like this. That's why I mentioned that although security has made advances in BGP, we have a way to go.
SHANE KERR: Shane Kerr, IBM, we have a lot of knowledge which can protect against the impacts of such hijacks, right. So DNS SEC will protect the data, Q and A minimisation will protect the identity from the users of traffic, potentially things like authoritative DNS over TLS could even break anyone who is hijacking and prevent them using this, so now you are looking at RPKI, where do you think the community should be focusing its effort because we have the technologies to fix this.
LEFTERIS MANASSAKIS: I am speaking on behalf BGP, we need a combination of RPKI, as par and BGP sec, which I say to to many people get, you know, get sick but I mean we need protection on the origin, on the first hop an on the path essentially and I mean BCP SEC might not be the answer but that is what we need to do and I am not sure when we are going to be able to achieve it, maybe we'll take decades, until we do it, this is the current state.
AUDIENCE SPEAKER: Hi. I am sorry that I missed the first part of your presentation due to an alarm system at home. Just one quick question and comment. A quick question: Have you seen any problems with the route servers who do have ROAs for their prefixes?
LEFTERIS MANASSAKIS: Yes, I have.
AUDIENCE SPEAKER: I suspected that, so thank you for confirming, you have an old IP address for B‑Root, B‑Root has a new IP address since probably the last year and a half.
LEFTERIS MANASSAKIS: Yeah, yes, this was a monitoring that took place in early 2023 when B‑Root had not made the change yet.
AUDIENCE SPEAKER: Thanks.
FRANZISKA LICHTBLAU: OK. Any more questions? Do we have anything online? . OK. Then thank you Lefteris.
LEFTERIS MANASSAKIS: Thank you.
(APPLAUSE.)
FRANZISKA LICHTBLAU: Now we start with the round of three lightning talks, the first one is by Simone and we seen the year before it's always interesting to follow a development of a project that with the over a couple of years and today we will get an update on host managed deployments.
SIMONE BASSO: Thank you. Yeah, so my name is Simone, I have been collaborating and contributing with M‑Lab and recently I joined the team. The topic today is basically first M‑Lab Measurement Lab in general and host managed deployments and a solution that can help us and where you can continue to the M‑Lab platform in an easier way.
So about M‑Lab. We are an OpenSource non‑commercial project. And we have this word wide fleet of servers and the objective is for researchers to deploy their internet measuring experiments on Measurement Lab anded idea is basically that the researchers write their clients and clients measure toward the servers application level traffic mainly and then collect the data and publish it and the code must be OpenSource and the data is published as open data.
Now, there are several experiments in M‑Lab, i.e. actually the HTTMI deployed one, but the most famous one is NDT, the natural diagnostic tool. And NDT is a sort of a sped test plus plus in the sense that it collects low level data as part of the test so you can correlate what you have seen at application level with packet headers and TCP info data, the success of NDT is also elated to the fact that the client has been integrated by several organisations, the most popular integration is the Google search integration so right off it's my internet an on top the blue baton, you end up running an NDT test that collects M‑Lab data. There are other integrations.
Air B&B has integrated the client, unique G‑Gof project has integrated the client, Uniprobe has integrated the client, collectively over the last year, all these integrations were running 3.5 million download tests per day, yeah, on the average.
Now, the data is open data, I won't go through the slides really in specifically, it's just now that you can access the data through big inquiry or cloud storage, you can download it and, yeah, you can go to it if you are interested and there are instructions and suggestions how you can inspect the data.
Let's move onto the platform now.
So we have here the geographic distribution of the M‑Lab's servers against which client test, we have more than 500 servers globally. We currently manage the servers and this means we have deployed over years servers and IXPs and ISPs, academic networks, transit providers and cloud and that's where we stand right now. Let's go to towards the host managed deployments. So we have coverage gaps. And those coverage gaps reflect the way in which M‑Lab has grown and so for example we have some gaps in central Asia, some gaps in north Africa and in the Middle East and this is where we start thinking is there a way for us to scale faster, is there a way for us to ask the potential community including you in the room to have more servers, to have more capacity and create capacity where we don't have capacity and the answer is this host managed deployments project, where we try to shift the model from us managing the servers, signing the hardware and basically so managing the hair war and the operating system to the organisation that wants to contribute and provide the servers and we provide the software means to attach this server to Measurement Lab. The way in which it works is significantly simpler than the previous model, so the organisation that wants to ask a selfer, they get an API key,what they need to provide a server, IP address, a minimum of one gigabit her second uplink and very kind of minimal small specification and then by running a Docker Container that we provide and an API key, this server becomes part of the platform, we started a pilot for this project in 2024, with our research network in Brazil, we are also now starting to experiment with off managed deployments in India. Our goal is for next year to have these solutions to be completely available.
Before closing I wanted to mention that beyond benefitting M‑Lab itself, hosting a node benefits also the organisation that has the node, and the reason is that the way in which Mlab tests work is that they spray client's traffic, well a client is going to test against one of the few servers near them. This means that on the other end from the client's side, from the server side, the organisation sees traffic not only from its own users but from several users and indirectly this gives them information about how good their interconnections are and my colleague Matt is working on automated to detect this at scale provide this information. This is basically the end, here's nigh call for action, talk to me, I am here today and tomorrow and then I will left there documentation in forms of the link and the QR link that you can use to like inform yourself and know more about in project. And with that, I am happy to take your questions.
(APPLAUSE.)
ANTONIO PRADO: Any questions for Simone? Maybe online? No no? Not yet. OK. Thank you Simone. Thank you. (APPLAUSE.)
And now we have another lightning talk. Christoff on residential proxies, a double edged sword fork network research. The floor is yours.
CHRISTOFF VISSER: Hi, yes, my name is Christoff Visser, I am from IAJ research lab out in Japan and today I am going to talk, well I guess it follows up quite nicely after Simone's talk about residential proxies and a little bit of what they are and how they could be very useful for network research but there is some concerns about them. From my point of view.
So, ideally for us as network researchers/operators, it would be great to have a perfect view of the internet, there are currently this is a couple of months ago now but like 54,000Ïsh RIPE Atlas probes. However, only about 13,000 of them are connected. But you know, what if we could have 150 million plus vantage points all around the world in places such as North Korea, the Vatican, etc and just have that available for us to give us a perfect idea of what the internet actually looks like?
So, this is dumb little Meme, RIPE Atlas is the same as MLabs now and things and we should use residential proxies instead, surely with that many vantage points, how could you not. But we also started to have a thing like 150 million plus from one provider out of many. Where do these IPs come from. With a RIPE Atlas probe or with the new M‑Lab hosting things at home, you are required to have explicit consent like you need to actually install the probe and register it, etc, so there's a very explicit consent to that.
These proxy providers are murky to say the least. There's kind of three layers. The first is through like mobile apps or on your TV. They incentivize people. This would be for instance if you play a game hey if you want extra lives, agree to this and the terms is share your IP and some of your bandwidth to get access or it removes ads or it can be on your Smart TV to get multiple backgrounds of a fine burning log.
So these are the ethical ones on how they get content for that. Some of the more grey area ones come bundled with free VPNs or apps and it's somewhere hidden in terms of service, you don't actually know that these services are running at the back of it but they are there.
And then there is the more malicious ones. So these get spread through the likes of malware, bot nets, very popular there was for content that was repackaged, included all of these proxy clients there and I will get back to that one in a second because that comes from a real example and kind of a big thing that started this conversation.
And I showed some of the examples from the, this is from the same YouTube video of the ethical IP, this is kind of the interface you are looking at to accept to be part of this and one of the things that they actually highlight as part of the YouTube video is that people can agree to this, go out of your app and never use it again and it will always be running on your device.
And for the developers, they get passive income from there but from the end user, they have no idea this is still going on.
So those are... yeah, even the ethical ones have some questionable actions and that's only from the ones I have been able to find out how they get these.
And but then the other issue is do you actually know if there's any proxies in your network, do you know if you have, this could be a residential proxy, this could be one? I don't know. Because part of the way that these are implemented is they look like and act like normal user traffic, it makes it extremely difficult to single out. But for researchers, there's some nice benefits. This can be used because you have got real at home point of views, you can use this to characterise like how CDNs are deployed, get a real world network topology and you can look at what internet censorship looks like between places but the big place they make their money is in the likes of enterprise, most importantly in the last couple of years especially has been web scraping, some people want to do price comparison or look at products but AI training is definitely the biggest one there, gets around all of your rate limits etc or you can do it to make sure if you have paid one to someone to show an ad, that the ad is actually showing.
Now the right‑hand side, this is kind of the reason for my talk, it came out of a discussion that was at NANOG earlier this year and while it was not recorded, I highly recommend going to the link here to read more about the discussions, it was about a four hour discussion. But they talked about this, this 911S5 proxy service, that was an illicit proxy service that was there and it was being used to do credit card frauds, swatting, death threats, ransomware, illegal materials and distribution, DDoS, etc, and it kind of brings up this question that if I can't verify this and I think as a residential proxy, how can you say that, how can you link an ID for a person to an IP when they could be a victim of this. Luckily the FBI did work on this, people knew they were part of these proxies but at the same time with all of these addresses before like, you don't know, if you can't even tell if there's one running on your network. So then it comes to our researcher's dilemma, should we use them and it's hard, there's pros, there's unique large data sets with millions of viewpoints all across the globe and it's real world use cases, they have mobile proxies now and as you mentioned, small places that was in Fortune in a that I mentioned, there's a population of 11,000 people, having a couple of view points there is massive.
So we get visibility into these hard to reach places. And they actually have, so these are from like some of the top ones there, they do have some programmes, non‑profits, to work with, universities, and a lot of them do work with them.
But then there's the cons side. As I just talked about before, can you actually say with full confidence that the user has full consent, that their device is being used in this way. The providers will say yes, they are, it's all good and things, they have some certifications to say but I have struggled to find any clear details on what those actually mean and on the other side is are we, by using these ourselves, are we enabling the bad actors to continue to work? The same argument could be brought across for VPNs, you can use that to access other areas, they can also be used for malicious work. I don't really have a conclusion, unfortunately.
But I did want to mainly, and I am really glad that this is at the start of the week, all being here, researchers know of this to some extent, a lot of operators do not, actually none of these sites that said they work with researchers and maybe data centres but none of them had any ISPs or operators on there so I don't know how many people even know about them.
But I wanted to have a discussion with everyone and I have got a survey here just to fill out to get an idea of people's experiences and how familiar they are. Just asking are these considered ethical, can we justify using these tools even though we can get new information in hard to reach places, however we can't say that they are ethically sourced, even though other people use that for web scraping otherwise. And can we, you know, how can we say that a network or traffic that you are seeing on your network is that a normal user or is that a malicious actor using these proxies. And then lastly, what is our path forward like. Realistically, to give you an idea of these services charging about three to five dollars a gig to use their ones? So if somebody is just trying to circumvent a proxy restriction or like a geoblock is going to use minimal things that it's really the AI web scraping that's funding these people. So what can we do about it? Do we need to ask for more transparency, is there a way to have a platform of this size and scale and ethically. So yeah, please answer the survey and I guess for the rest of the week I am here an discuss with each other, yeah. That's it for me.
(APPLAUSE.)
FRANZISKA LICHTBLAU: Open for questions? . Starting here.
AUDIENCE SPEAKER: I see Rudiger is in the queue but he hasn't stood up. Very simply the first question. Sorry. I'm Tom Hill from British Telecom. Can we justify using these tools if we can't be 100% sure about their consent? We can't. In the UK and Europe, we have laws that define consent, end user consent, this is very clear in law, no, we can't, not ethically. And I agree that these things are tempting because look at the dataset, it's enormous, but the users, if you've buried something in terms of service, none of us would like to that to happen to us, so I don't think he can ever say that's ethical.
CHRISTOFF VISSER: We actually touch another interesting point and that we kind of discussed about especially for here is I in a way technically these users are leasing their IP to someone else and that's, I know is more on the illegal side rather than the unethical side but well, if your customer is doing it but might not be aware of.
AUDIENCE SPEAKER: They are sub‑leasing their IP addresses but IP addresses at least in the UK Protection Act are classed as personal data so it comes back to the law, generally.
CHRISTOFF VISSER: Cool, thank you.
FRANZISKA LICHTBLAU: OK, do we have anything online? Back at the microphone.
AUDIENCE SPEAKER: Very interesting presentation. One comment that I have is even if we may agree that this is not ethical, there's a need to argue that you can put really in a lot of danger people around the world by using these kinds of service if you try to connect to a website, their censured in a certain country, you can create a damage to the end users that don't know what's happening. And I mean one of the, I remember discussing with RIPE Atlas one of the reasons they don't have HTTP fetch is exactly that, by using this kind of service, you can really create damage to users and you should be aware of that.
CHRISTOFF VISSER: Yes I absolutely agree, especially when it comes to the really malicious or illegal content and stuff. Because if an operator can't pinpoint that it's a user, it's going through your residential proxy, it's a client that doesn't even know they had it that's going to be the victim here.
BRIAN NISBET: We actually had this conversation with a number of the universities that use our network when they became aware of a number of them, some point in the last year or so, and I mean our answer was so the user is one thing, it breaks our IUP to do this, it is, it says very clearly and we are running this public interest academic charitable network, you are not allowed resell the services, you are not allowed do any of this. And whatever bout commercial ISPs and fumbling the greasy till, etc, from our point of view it's like no, I don't care what this is being used for, it is against the A UPand also we would suggest that our users don't use them because who knows what they are doing and even the most ethical ones in this day and age someone might buy them, change the code, do a whole bunch of things and yeah, it's very, very murky. Cool.
CHRISTOFF VISSER: That's exactly it, I wanted to start the conversation here.
FRANZISKA LICHTBLAU: Excellent and we are we have no more on line.
(APPLAUSE.)
OK our last speaker is Remco who will finally help us say our goodbyes to ARP.
REMCO VAN MOOK: Well it is a dream, isn't it. Hi, so everyone, my name is Remco van Mook and this is a lightning talk about a dream, how can we use IPv6 to resolver IPv4 great ways, it's not a nice title to a fair well to ARPs, if you will. A single gateway.
And to make sure we are all on the same page here, this is a tunnel free presentation.
We are not adding layers of encapsulation, no tunnels, keep that in mind.
What's the foundation of all of this, the foundation of modern networking I am sure some people in the room recognise it, maybe some of you wrote this code, this is pseudo code derived from 4.2 BSD from 1983 I think thereabouts, which has the AF INET socket and connect which is probably the most used API on the planet.
As of today still. It's all going to go, it's not going to go away. Let me look at my notes.
Software will be binding and connecting to IPv4 addresses for a very, very long time indeed still. But inside of your modern orchestrated multi‑tenant network, what is it look like? A lot of this. Like a lot, a lot of this constant noisy broadcast based discovery, terrible. So let's establish a premise for this dream, dual stack means a lot of work, it's a lot of double work that we want to avoid if we can. Second of all we are going to need to acknowledge that the need to communicate over IPv4 across the internet specifically across the internet is going to be there for a good while and talking IPv4 to the internet is not necessarily the same thing as talking IPv4 locally and it's going to be a very long time indeed before you will have a router that, I mean a packet walks into an IP IPv4 packet walks into a router, the router doesn't know what it is.
And discovery mechanisms like ARP which actually even pre‑the 4.2 B in 1982 we are talking about now is actually a very bad idea in a multi‑tenant environment anyway. Your modern orchestrated network knows exactly where to send stuff and your layer 2 network, your east next network knows full well how to carry an IPv4 packet, it's been there for a while. So the dream.
The dream is how, have a network design that solely focuses on picks and I never thought I would say this, no IPv4 subnets, no ARP, you have automated addressing prefix delegation, you have a design and routing fully based on picks, you can hosts can have a public V4 address as a tag for your end point software to connect to, your 4.2 Bs's DHcode, the network will know how to move IPv4 traffic, we have RFC 8950 which says, which has V6 next hops for V4 routes. There's one thicky they think when you try to implement it across it's board though. Hosts don't know how to send IPv4 traffic back to the internet if you try to do this so if you distill that dream into a picture, there's a lot of good stuff going on here and there's of course there's the red arrow and the question marks and the lightning bolt because this is where stuff gets confused.
That makes testimony time to talk about the default gateway.
The least used most important IP address you have ever seen.
In many cases, data centre and ISP networks it is the only other device that your host or CPE will talk to on a public subnet, the main function of the default gateway is nothing else than an identifier to do a Mac address look up. ARP.
And really the value of that identifier doesn't matter. At all. As long as the host knows which interface to use to send that request to. What what if we could tell a host to simply use the same layer 2 resolution for IPv4 and IPv6. The single gateway, if you will. Have a default gateway IPv4 address that just means, just go look at picks, right, I mean find out what the default gateway for V6 is send your packet to the layer, it will be fine, instead of everybody building their own hacks, let's use one of the, we have a special registry that IANA maintains, there's IPv4 address space that's not maintained by the RIR system, 19200 /24 so have a special purpose address that you can actually build into network stacks of operate to go systems to actually recognise it as an oh, oh you mean this, let's do this in this case and as it just so happens the next one available in that range is 192.0.011, let's see if we can use that for that purpose. What does that could do in terms of the solution, it's the same picture except your host now has oh 192.0.011, I know what it means, it goes to talk to the IPv6 stack and there it has and off to the race is. Now a lot of you are going to go, come up screaming to the microphone saying what about backwards compatibility, of course this is all and none of this will never work anyway which means this will never happen. Actually, it does already exist, backward compatibility. Hosting providers are using this right now.
You can use current DHCP, like let's they are does this, which gives you a /32 IP address on an interface, it gives you a host route for the default gateway, sets the of course the default gateway and then on your router you are just configure 192.0.0.11 as generic universal signal gateway IP.
I am now out of time so I would appreciate your thoughts, thanks to Tobias and Warren and for providing their input, there's some working code I have in a Linux user space, any kernel from 5.2 upwards could do this so it's been there for a while. Using RT next link, this aligns with a lot of work that's currently ongoing in the IETF work, V4, via V6, here's the Github and questions, comments, let me know what you think, I am really curious. Thank you.
(APPLAUSE.)
FRANZISKA LICHTBLAU: Thank you. OK, that was a race. One, two, three!
AUDIENCE SPEAKER: Thank you. Shouldn't we use 127.0.0.2 as the other end of myself, never mind! Never mind!
REMCO VAN MOOK: If you want to talk to yourself, you can use any address you like, it's fine. I don't judge.
AUDIENCE SPEAKER: Gert Doering. I do like the way you are thinking. Especially with the, it's just an identifier to look up the key. It will confuse the hell out of people, but it will work. There's one small catch and that is the IPv6 default gateway, what is that if you have multiple interface routes and all this stuff.
REMCO VAN MOOK: You can still do this, this works. And.
AUDIENCE SPEAKER: It works if you have a /0 route or something that can be identified.
REMCO VAN MOOK: If you can figure out to where to spend IPv6 packets to the internet, you can figure out you want to use that same input.
AUDIENCE SPEAKER: There might be multiple ways or interfaces, there's a fine print.
REMCO VAN MOOK: There's undoubtedly corner cases that you can find in unique.configurations where it won't work.
AUDIENCE SPEAKER: I am not saying it won't work.
REMCO VAN MOOK: Good, thank you.
AUDIENCE SPEAKER: My question was his question so thank you.
REMCO VAN MOOK: In that case, I would very much look forward to all of your encouragement and positive feedback and comments on the Github and let's see if we can, this is a draft internet draft, I don't know if that's not a status, so I am preparing this to go to the IETF and once it's there, I would very much like to have the operators who are largely not very present in the IETF to hear what they think.
FRANZISKA LICHTBLAU: OK, I think we have one final question, Tom, check in with you, you didn't lower your hand as well, right? OK. Dimitry. And we are closing the queue.
AUDIENCE SPEAKER: Thank you, one of the big IPv6 fan. That's a presentation I was waiting for. Quick question: Are you referring to the famous Scottish incident for IPV6?
REMCO VAN MOOK: There's also a move re that basically dials it up to eleven and that makes it extra good, you can find any reference you like.
AUDIENCE SPEAKER: I think 426 might be better, good luck.
REMCO VAN MOOK: I mean as just to so happens, 11 is actually easily memorised by people fwho were not deeply inside of technology as well, I don't know. We'll see.
FRANZISKA LICHTBLAU: We love numbers, this is going to be great. OK. I think with that we can close this session. Thank you.
(APPLAUSE.)
Before everybody runs off, I would I can loo to remind you, please rate the talks, our lovely submission system has a rating button, if you click on the presentation on the agenda and you are logged in with your access account, you can rate presentation and leave comments, if they are within the code of conduct, we food them to the presenters to so they get heard and appreciated.
Please remember that you can volunteer yourself for the Programme Committee until tomorrow at 3.30 Bucharest local time, just send a mail with a picture and a short bioto PC at RIPE dot net, if you have questioned regarding this, you can find the current members of the Programme Committee all across the venue and just talk to us and now we have a quick coffee break and after that in this room, we have a BoF about a current ICP‑2 document update. Enjoy.
(APPLAUSE.)
(Coffee break).