RIPE 92
Main room
22 May 2026
Closing Plenary.
BRIAN NISBET: Hello. Good morning to you all. Could I ask you to take seats and end conversations, and we move into the last Plenary session of this rather wonderful RIPE 92. I am Brian, along with Maxwell be chairing this session.
Before we move onto the first talk just a couple of announcements, one of which is do please remember to rate the talks because it gives the PC all sorts of wonderful information about what you would all like for future meetings.
Also, if you have recovered sufficiently from last night, there is a walk up Arthur's seat this afternoon, led by the local hosts HillCo Global from half one to half three, this time is averaged, it may take you longer or shorter depending on your physical state and you can meet at the registration desk to go on that walk.
I highly recommend it, the view is awesome.
So, the other piece of administration that I need to do is the results of the PC elections and once again, thank you to all of the people who volunteered, put themselves forward. It's hugely appreciated and for those of who you were not successful we really hope that you will volunteer and put yourself forward in the future as well.
So, the two successful people were Max Stucchi and Paulius Judickas, so congratulations to them.
Yes, and again thank you to everyone who put themselves forward for this.
So let us move onto the talks.
GINEVRA FABRIZIO: Hi, everyone, this is measuring the input of Post Quantum Cryptography on federated identity management. The tile is very long.
First of all, let's get started. What's this Post Quantum Cryptography, what should it bother us?
First of all we refer to Post Quantum Cryptography as accurately the cryptographic algorithms that are designed to secure data against the threats posted by quantum computers. Right now we do not have a cryptographically relevant quantum computer, but still,s there is the risk because of course a quantum computer is may more powerful than our actual computers, so what happens is that we need to transition to these post quantam cryptography because a quantum computers, when they will arrive, we will break our current encryption methods that are currently used and they will put our communications at risk. For example,s last, I think in the last couple of months, Google announced their Willow super computer, quantum computer, that, so, yes.
So, the thing is, who is right now already transitioning to Post Quantum Cryptography? Of course big companies, Google, Apple, Signal is already using Post Quantum Cryptography, and they are switching to quantum safe alternatives.
For example, CloudFlare already uses it for their communications. Also, Chromium is using it. Mozilla of course and in 2024, I Message started using their own version of I Message protected with Post Quantum Cryptography, Signal already in 2003.
So, the thing is, is it really that simple to just implement something and okay, then that works? Of course, if these cases, that I just mentioned, we just is have a client and a server or for example just two people talking on the phone. So, we have a recommend actively limited number of parties that are communicating and you have to secure the communication. But the Internet is huge and difficult to manage, so, there are many more kind of infrastructures and protocols that need to be taken care of. So, cellular networks, federations, IoT devices and so much more.
So, in this talk I will be focusing on identifed federations and the relevant protocols. In case I will be focusing on SAML.and OIDC.
An identity federation generally allows organisations to share identity user data. So for example, if I need to use very personal case Overleaf and then it says oh, you need to log into Google, so I have to talk to Overleaf, then I have to talk to Google and Google will refer me back to tear identity provider and I will go back to Overleaf.
Typically, an example that here we will be taking, like, there are many kinds of federated architectures, but here, we will be focusing on the hub and spoke architecture, which is shown on the right.
So, for example, here, we can see this is called hub and spoke because avenue central hub that is managing the connections between the service provider. In my case I want to use Overleaf to write some papers and the IDP which is Google and it says okay, then I have your identity, your user and password and I will give it to Overleaf to share your data.
So, this is only one connection. So, only one user authenticating through the identity, through an identity federation will do this step. So, the identity provider will have, will sign a token that will be then sent through a secure connection to the hub. So it's one TLS connection. And then the hub will verify the token, sign it again, because the hub can act as both SP and both and IDP, so it will act as a service provider when it's talking to the identity provider and it will act as an identity provider when it's talking to the service provider.
So, verifying, sign and again and then send it to the service provider. And this is again only one user doing one authentication. So imagine this for a lot of times.
So, what we wanted to do is to take a real world example. So we wanted to use some real data from a real Hub and Spoke architecture, and say observing what happens if they were to switch to Post Quantum Cryptography.
So together with Surf, we gathered the data over the span of 25 days in the month of September which we know is the start of the academic year so many students just enrol and we, it's basically the highest number of enrollment that we have. So what we gather is their system load, all the successful authentication attempts and the kind of authentication that took place so we also had two different shades between open ended connect and the SAML authentications, which we are different protocols of course, so, the number of signing verification and overall cryptography operation that happens are different.
We also collected the HA Proxy logs, we recorded all the HTTP requests, the TLS connection that they received, for a TLS connection we have on top of the SAML and protocol we also have the TLS operation handshake and the digital signatures. And we also recorded this whenever a SAML request or a SAML response was received, which they both mean two cryptography operations. What's the aim of all of this. So we want to estimate the overhead produced when we switch to PQC when we take into consideration a slightly more complex scenario than just two parties talking to one another, and just for I Message or a TLS connection.
So cryptography I can operations required by PQC is what we are interested in because of course Post Quantum Cryptography has, is famously known for having very big signatures, and larger key size and this means that they take up more memory, they take up more time to be processed and also, they affect bandwidth, they affect CPU load, they are computationally intense. And this will require additional resources to handle will increased load.
So as also the provider said, that already as it stands, a whole authentication process can take anything from one second to several minutes with timeouts and what not.
So, if load and authentication time increases, what other resources are needed? So here you can see that we take the busiest day in September that we saw, and here, we have the number of TLS connections, the number of validations and the number of signatures.
.
So, Surf manges these Hub and Spoke federation through the central hub, as I showed it before, and they call it Surf engine. What we will be focusing on also for operator standpoint is the hub because it's the one that handles the most operations as we saw before, they have to handle the TLS connections and they have to verify the token and sign it again because they act as both identity provider and service provider.
So, Surf Hub and Spoke MED racial handles a bunch of bay to.authenticate yourself but what we will be taking into consideration is operating connect as I already said and SAML. So, what we want to put the highlight on is that we want to consider a worst case scenario, so of course we are taking Hub and Spoke because it's the one that IX at that the most operations, and also, we toolkit the day in September which had the highest number of HAProxy and HTTP requests.
So, what's the SAML authentication flow like in engine Surf?
.
So, first of all, this is their hub. So these are the operations that we will be concerned with. But, as you can see, the first step, the service provider sends the request to the hub. The hub acts as an IDP and says okay, then I need the IDP to check your identity. The IDP signs the SAML request that is received and send it back to the hub. This is where we are interested because then the hub performs a verification and then a signing operation, and gets back to the service provider.
So you can already see that here, the hub is the one that is performing the most cryptographic operation. In total we have four but we will be, we take these two into consideration.
.
This is the SAML one. This is a bit more complex and the operating connect authentication flow, it depends from operator to operator how this is implemented but Surf decides to put an operating connect gateway between their already existing SAML infrastructure. So, they have basically a gateway that translates the operating connector requests which use Java web tokens they get translated into a SAML XML sponsor message.
So, first of all, here these arrows indicate strictly operating connect operations. The service provider talks to their gateway, the gateway has to sign, so we have already one operation of signing. Then it gets sent to their underlying SAML architecture. So, they verify. Send back to the IDP, IDP signs, this doesn't concern us for now. Then verify. The hub verifies, signs again, send it to the operating connect gateway. The operator connect gateway verifies and then the operating connect in the eight steps send an operating connect token with three signed and a half a web tokens. So we're we have three signatures taking place and they get sent back to the service provider. The 9th step, and 10th step happen whenever some more data is needed. They don't happen necessarily, they are part of the authentication process but it's just to check the validity of the access and they both perform a Java web token validation. What the take away of all this is that these protocols are complex and they require a lot of cryptographic operations and they happen at different levels of the stack.
So, what did we do to estimate the Surf engine load we take into consideration three types of cryptographic operations. So, signatures, signature validations and key exchanges which are the ones which will be replaced by Post Quantum Cryptography which is heavier, blah blah blah.
So, we consider the busiest period of the year and took the highest number of HTTP requests made, and for each HTTP request we assigned one or more cryptographic operation that was shown previously in the process of either SAML or operating connect, and as you can see here, we have these huge HTTP requests logs and we say okay, we know that IDP metadata, we have in this day of September, we had around 5 K requests, and this path means one SAML signing request, which uses RSA 1496 key. And so on. We do the same for all the rest of the path that we received.
Also notice that for open ID connect requests, it might involve both SAML or Java web token signing, which are different, because Java web token their case uses 2048 RSA while dismiss uses 1496. So we also had to take that into consideration.
And the operation can be related to either Java web tokens or SAML.
Which Post Quantum Cryptography algorithms do we select? They are quite a bunch, but with decided to take into consideration hybrid algorithms which are the ones that are being used right now by CloudFlare and Google and they are the ones that are currently being tried for the transition. And also, the final analysis candidates that have been chosen. So we selected a hybrid one that uses Kyber, Sphincs, which is a hash based signature, Kyber, which is a key change mechanism, this means signature and this is a key exchange algorithm. Then we have another digital signature can, factual tonne, and HQC which is selected as of March 2025 and it is a key exchange mechanism.
So, why we selected these? It's because we wanted to pick the most relevant algorithms and we wanted to compare these PQC algorithms with their current infrastructure is traditional cryptographic that's used right now. Why we chose these scenarios.
So, we decided to test. The signature and the hybrid key exchange mechanism, we wanted to try a lat I say based implementation and hybrid key exchange mechanism, which is the most ‑‑ the easiest choice for an operator to go with, because in case you are using a hybrid combination, what you do, you use a traditional cryptographic categoric algorithm and on top of it you put Post Quantum Cryptography. So you can, let's say, always roll back in case any of those Post Quantum Cryptography algorithms turn out unsafe because this is the biggest problem for now. We have these Post Quantum Cryptography the but as long as we don't have a cryptographically relevant computer, we will not know if they are safe or not.
So, we wanted alattice pleased preliminaries because it's also what is more, the performance is very nice, they are also better than the ones that we are currently using but every now and then some paper that says A is not as safe as we thought pops out. So people are still a bit, let's say lattice are a choice.
Then SPHINCS+ and HQC which are the only non‑lattice based implementation that is possible if we use NIS candidates. SNMP analysis)
.
Then we also choose MLDSA and MLKEM so purelattice based implementation. This is well described in our paper, but we will not ‑‑ I will not be showing any plots about that because these two are the most relevant cases.
So, we wanted to show the differences between lattices and non‑lattices implementations.
So. We ransom bench marks, we ran 100 independent speed attests algorithms performed with cryptographic codes continuously to a machine and we redundant these benchmark using OpenSSL together with open quantum safe. For digital signatures we have the best performance achieved by MLDSA and Falcon and the worse performance is from SPHINCS+, both fast and simple implementation. While for key exchange mechanism we have MLKEM which highly out performance traditional key exchanges methods that are now used and the worse performance is by HQC which which is the one that has been newly appointed since March 2025.
How do we compare the performances in we compare the CPU load of each possible implementation so of the two biggest scenarios that we want to take into examination, and traditional one of course, and here you can see the actual implementation that they have. We had to separate between the identity management operations and the TLS ones. Because we happen at different layers of the stack and they use different key sizes.
So a maximum load here we show a CPU load which expresses the CPU time that is used to perform a set of cryptographic operation and a hundred percent means that a single core is being saturated by cryptographic operations which means that the user has to wait for their authentication to happen.
And we also want to show the decide of a provisioning performed by Surf, by the operator, they said that they want to at least have a 60% load of over‑provisioning to ease all the operations.
And in case the load is exceeded, so, in our case 100%, it means that the queue is filling up. Surf would rather not to go over 60%.
So we compared the traditional actual implementation, and we can see that the maximum load that they achieve is 12%, with an average load of 3, almost 4% load. And the first PQC scenario which is hybrid key exchanges mechanism which is the one used right now by CloudFlare and Chromium, and purely PQC lattices digital signature, and we have that the maximum load is actually lower than the one that they are currently using and the average one too, and it's more balanced between key exchanges and signing.
So, the first PQC scenario that we are taking into consideration a has faster signing and verification time so this is very nice for operators and this leads to less computational load compared to the actual implementation that Surf is using.
The second scenario, which is also please note the difference in scale, this is the same, we are still taking into consideration the traditional implementation, we just highered up the scale because as we can see, using SPHINCS+ and HQC, which are again the only non‑lattice based signature and key exchanges mechanism that NIST is appointing as a future use the maximum load is three times higher than what 100%, so they are taking three times the CPU load and the average load is a fully loaded CPU core. And we have more than 3 seconds of core load for a peak of operations.
.
So what does this mean? It means that we were to use non‑lattice implementation that are standardised by NIST the PQC scenario requires up to four times the current load that is being taken up by Surf.
So, as we mentioned, SPHINCS+ and HQC performance is very problematic because uses more than the four times the computational resources owned by Surf, and MLDSA and hybrid key exchange mechanism perform slightly better than the already existing cryptographic standards. So, if lattices are proven to remain quantum safe then migrating to them is the best choice if they are safe.
So, what can we gather up from all of this?
We can say that lattices and other implementations, they have the potential to out perform our currently used standards, but relying only on lattice based schemes is not a safe bet because if lattices turn out to be unsafe in the future, or when we will have a cryptographically relevant quantum computer, this is a mess.
And also, what we would like to point out is that existing protocols, so for example current SAML standards, they require the use of RSA 2048 bit signatures but leaves other signatures as optional or up to the implementer. So this standard will not hold up in the post quantum era and will have to be revised to accommodate post quantum resilience.
This paper was submitted at TMA last year, and ‑‑ thanks for your attention. If you have any questions, I am here.
(Applause)
MASSIMILLIANO STUCCHI: I see we have a question.
AUDIENCE SPEAKER: First of all, thank you for the presentation. I find a little bit confusing that a key exchange and digital signatures are kind of grouped together in one concern because they operate a different layers of the stack and the digital signatures in particular in my experience are much more complex compared to key exchange, so maybe a bit of feedback for the future would be great to separate them.
Secondly I see that you measured, you used open quantum safe for measurements. Did you have a chance to try actually production library such as OpenSSL, AW, LC, boring SSL.
GINEVRA FABRIZIO: Not yet but we would like to try them out.
SHANE KERR: Shane Kerr. This is amazing. I love everything post quantum even though I don't understand any of it. You highlighted the concern about the lattice collection techniques. Like, what are cryptographers first thinking, is there a concern among the professionals that this is actually a potential vulnerability?
GINEVRA FABRIZIO: So, this is a very interesting question, because I'll be honest, I was first year Ph.D. and we were doing this and two months came out this paper very mathematically dense paper that was saying hey, lattices are like some order of magnitude less safe than what we expected. And I'll be honest, this was two years ago, and there are so little people that are expert in that field that like, I did not have anymore updates on that. But I assume they are probably still looking into that because it was this very mathy paper, very lengthy paper that was basically debunking the safety of lattices. But I am 100% sure people are still looking into that because the experts in that field are not enough. I also looked at that and I was okay, this is way out of my capabilities. But I think the claims are kind of, we should still not rely on only one kind of mathematical problem just for safety. And yeah, also another paper I think came out a while ago that also said that lattices were a bit, not as safe as we thought. But it's still like, let's say, if we thought that they were this safe, this paper says no, they are actually this receive. So, it just a matter of time.
SHANE KERR: That's definitely a concern because if it's so new. Right.
GINEVRA FABRIZIO: Exactly.
MASSIMILLIANO STUCCHI: I don't see anyone else in the queue. Do we have anyone online? Then, thank you.
(Applause)
.
Our next talk now.
ALEXANDER MANNEL: Hi, I am Alex I am going to talk about Hilby‑Hilbert interactive prefix plots. What that means exactly we will get to in a minute. So, you as operators probably have a lot of information and data that can give you insights into optimising your work flows or deployment or make them more resilient. And a lot of that information due to the nature of what we do here will be related to IP addresses or prefixes or sets of IP addresses, and some examples for that may be flow data. So you have questions like hey which address range receives the most traffic is the most important for us, or on the importance of addresses, how many domains resolve to any specific one IP address in my network. So, is this IP address for some reason more important?
Or, just BGP announcements. So what prefixes do others observe of my network?
And I am going to stick with the last example of that. So, we're going to talk about I will use because as a researcher, I do not have the internal operator data but I do have the great RIPE RIS data so I can talk about that last third case of what and how much address space does my AS currently announce according to RIPE RIS.
Now, if I want to investigate this, the first thing I do is I go to the RIPE RIS, I'll get some data and then I have to visualise it in some intuitive way so I can get meaning from it because because I work visually. How do we do that?
Option 1, maybe a table, very detailed. But does not provide a great overview of the data and depending on how rich you are, this list is also going to become quite long.
So, maybe we want to have another option like a pipe log, this is great for all of you but we are losing some of the details, maybe some of the interesting parts because it is getting averaged out on this visualisation and maybe someone already has an idea which AS data I used for this. People have come up with other ideas. Mainly a thing called Hilbert curves. I believe the actual original use case of this or the first use case is the X case D195 where he drew the original allocations in clause for routing and also the allocations to the different RIRs to create what he called a map of the Internet. The end group at ISI has done this for their Internet data and they are publishes these images of the address space. We also did that a couple of months ago for a paper talking about network telescopes.
So, why do people like Hilbert curves for this type of visualisation? The answer is first of all, Hilbert curves are a way, or are called a type of space filling curve, and they are called that way because they help us plot one dimensional data like the IP address space. So every IP that is a predecessor and a successor into two dimensional space by providing a coordinate to that value. There is a bunch of those, but the Hilbert curve has this great additional property that it maintains the locality of the original data very well. And what that means in IP address terms, and not mathy terms, is if you have two prefixes or three prefixes, in this case for example on the right. One /8, its two neighbours are physically right beside it. And this also holds for their sub‑prefixes. So, the four /10s that are contained in one /8 are all within the area of one /8, and these neighbouring, this neighbouring property, so for one 192/10 holds even across the borders of bigger prefixes. So you can see in this case, two /10 and one 128/10, are the neighbours.
Okay, so we have established we kind of want visualisations of IP address related data to help us understand things, Hilbert curves are a way to do this.
But we do lack some tooling to create interactive and scalable plots. There is some older tooling for this but it creates static images and I wanted to have something that I can dig through. So this is where Hilbert comes in. It is a small reactive framework that attracts all the way the complexity of the maths behind it, of the user controls, so it ‑‑ you have zooming and dragging controls also for mobile. Will you have interactive expanding of sub‑nets, this is something I am going to show in a minute. You will full CSS and content control over each sub‑net. So, you can just tell any like colour or text colour or background image that you want to have a specific prefix to show. You could even do a moving rainbow marquee attack if that would be of interest to you for whatever reason. It is also IPv6 capable and IPv6 deaggregation is actually much more important and since it's running in the browser you can do on demand data fetching so you don't need to pre‑build these images, you can build them on‑the‑fly you can change colours, whatever. And I have because I don't want to challenge the life demo gremlins, a little video of this what I call expanding subnets and so this is the demo page, I'll have a QR code up in a minute. It's not running yet. We can see okay this, the full address space. One we can dynamically move in aunt sort of split up specific areas into higher detail if we were interested in this. So this is all announcements from the AWS or the AS of 60 and 509 and we can go to completely different parts of the address space and sort of dig in all the way down to the individual /24 and if we want to go out and sort of understand the macro image again we can do that as well.
So back to my slides.
So, how does that work implementation side for you if you wanted to do this? It's very simple. Hilby wants a call back function from you. It will ask for a prefix the one that the user is looking at and it will give you a config object and in that config obvious you can just tell Hilby, hey this is the colour I want, the background colour, this is all the sorts of the things that I want to see, and Hilby will just apply that to the image. So this is all the data, or you as a data user would have to implement.
Okay, so you are interested at all. The source code is available. It's all on GitHub. It's OpenSource. There is also a playground where you can upload your own CSV as long as it looks IP address, value, and sort of explore it a bit in Hilby. I have tried to get that as general as possible. Will if your data breaks the playground for some reason, show me the data that did that.
Okay, thanks.
(Applause)
BRIAN NISBET: Thank you very much. Do we have any questions? No, everyone just thinks it's cool because it's cool.
Thank you very much. Sorry, there was a question.
AUDIENCE SPEAKER: Yes, there are a few presentations that make me angry, I hadn't thought of that. I love this. Thank you.
BRIAN NISBET: And now to move to our next talk.
WARREN KUMARI: Warren has a request from the Programme Committee. Next time please don't put me after a really good presentation because I am going to look real dumb.
So, BitSquatting or the infinite monkeys theorem. This is an update from work done in 2011 and 2018. But presumably everybody has heard the infinite number of monkeys hitting keys at random will eventually produce the works of Shakespeare. Is something like this actually true?
.
So, a little bit of ground background f you enter something like a domain name somewhere in RAM, it's stored like this. If a bit were to flip from a zero to a one or a one to a zero potentially it ends up in another character that's also a valid DNS name.
Different view of that. Surely stuff like this doesn't happen. We believe that computers are largely deterministic.
Well it turns out it does actually happen not infrequently. One of the most common causes of this is radiation. So, a common thing is cosmic rays, or if you are using leaded soda, it used to contain bits of radioactive material. One the best known casea is from around 1974, computers were becoming a lot more common and Intel decided that they needed a lot more of the ceramic packaging material so they built a factory for on the green river in Colorado and it was downriver from a uranium mine and the water they use was contaminateded with uranium and thorium and this would cause issues.
There are also more real world consequences. This was a flight from Singapore to Perth. And a bit flipped in the air data inertia reference unit and the bit that said whether the data is the angle of attack or the altitude was encrypted and the flight computer panicked pitched the plane down at almost 9 degrees and 53 people ended up in hospital, 14 of them had to be airlifted to hospitals. But why would you care here? Presumably you want planes.
.
Well, as I say this is some work from earlier, and I decided to have a look if there are still these types of events happening.
So I wrote a small thing that would let me enter a domain name and would give me all of the valid bit flips of that were also domain names.
I then went off and registered some of these. This was originally presented at ICANN so I used some of the ICANN names. Some large US financials, and, you know, some other large companies, FB Cadian is a single flip from FB Cedian. The rest of them you can probably figure out fairly easily.
So, then I set up a web server to try and capture if anybody was reaching these names.
And I set up capture what I am call expanded names and SNI information and cookies and URLs.
Probably everybody in the audience is now thinking, meh, probably everything he has seen was successfully just people doing typos on key boards. That's a valid concern, but I tried to minimise that by choosing sort of domain names or things which are far away from each other on the keyboard.
I was also trying and capture what I am calling expanded names. It's entire possible that somebody would type in this, but it's less likely that they would accidentally type in MS edge dot B dot TLU.dl.delivery.microsoft.com
I also tried to do more API or system names. This is an API end point, still possible people might typo this but these are generally handed out in the HTML or when you are following a URL.
I also was collecting SNI names, a quick refresher. In a TLS connection your browser whatever tells what site it would like to connect to and if I have microsont,com and I am getting hits for Microsoft.com, it's clear that that was the intended name somebody didn't typo it. Also, full URLs, it's unlikely that anybody would have typed this in. Possible, but this was clearly a link on a page.
So, as I say I set up a web server and started collecting stats. As you can see there is a bump in you know mid‑May, I added some more names to it at that point. That explains that bump. I was getting a bunch of hits. But as, you know, if you put a domain name on the Internet you get a bunch of word press scrapers and the results of things is people banging on the door.
So I tried to filter out as many of those as I could. And I ended up with some stats.
And these seem to be people who are really getting a bit flips and now hitting my server.
What's interesting and more research is needed here is there is this thing called the estimated planetary K Index that is basically a graph or a number of the amount of cosmic rays hitting the earth at any given time. More stat is needed but it kind of feels like there is a correlation here.
But why is this interesting?
.
Well, some of the things I was doing is collecting what I'm calling expanded names. Over a one or two weeks period, I don't actually remember how long this is, I got at least 719 people trying to reach Teredo dot IPv6 dot Microsoft dotcom. If I decided to set up a Teredo endpoint there, people would proxy their traffic for me. Sounds like a good idea. It made me a little sad. Then I started logging SNI names. This is kind of interesting, that doesn't really tell you I can't do anything useful with this, I don't have certs for these for obvious reasons. It still made me a little bit sad.
Then I started logging URLs. So, these are places wh in the top example somebody is clearly trying to log into the bank of America site. This URL was embedded somewhere on the login page and somebody came along and tried to connect to me. I have a cert for bank of America and I could just serve them and provide a phishing page. I am not really doing anything wrong, I could connect these, I am not doing anything wrong.
So, then there is things like javascript. This is a tiny selection. I got thousands and thousands of people trying to reach something dot JS. And what I think would likely happen, it depends on exactly where the big flip happened, often if I were to serve them javascript would be running in the same web origin as the original name. Could just ship them some javascript that's here you go, it's in your same origin, I can have the cookies please, ship them over here. Or any other interesting JavaScript thing because most of this will happen in the correct web origin.
That made me more sad. Then there are things like executables. If you are trying to download the dot net installer and you go along and get executable even if you are running Windows and is says this is sketchy you clearly downloaded it from Microsoft, it came from their page, you followed the link, you just happened to fetch it from somewhere else.
That's another one that made me even more sad.
Now, we get on to cookies. I had many many many thousands of cookies collected. But this is people are just trying to connect to a site. There is a bit flip and they send me their cookie. This one is somebody apparently trying to pay the rent for their apartment. This one is somebody trying to reach Atlanta specliased care which is their health provider. I could just collect these cookies and pretend to be them, play them back, etc.
.
This was, I believe, over one day. I just collected things that looked like cookies that are authentication or login tokens. I could just collect all of those. I know where the person is trying to go, I have their auth cookie, I can just play that back.
But, we all believe TLS should save us from these sorts of things. Sadly, that's not always true. Here, you can see the SMI is Microsoft, so the browser believes it's trying to connect to Microsoft. I don't have a cert for Microsoft so I just sent them one of my micro assistant ones ore similar. But they continue the connection, because they came back and over the TLS connection they handed me their cookie. So, it depends on exactly where in the stack the bit flip happens, you know, TLS doesn't always save you.
Which made me more scared of the.
So, why did I redo this? Well, there is going to be a new round of new gTLDs coming real soon. I thought wouldn't be sad if somebody were to register a bit flip of a very well known TLD. Maybe in the ICANN process we should have a sort of rule that says you can't register a bit flip for an existing TLD. So I started writing that up and I was like before I propose that, let me just make sure this doesn't already happen a bunch because otherwise I'll look dumb.
Here are single bit flips of existing TLDs to other existing TLDs where it's a single bit flip from one to the other. There are about 60 of them that are one bit flip away. One of them stood out. Happens to be if a bit flips in dotcom you end up at dot bomb. So there is another big well known TLD, single bit flip people end up in the wrong place.
I don't know what we do about that. One mitigating thing is I actually spoke to net dot BR and explained that to them and they were maybe we shouldn't allow any registrations in dot bottom. So good on them.
But well what's the conclusion? Computers suck sometimes. The Internet sucks. I don't know what we can do to mitigate this like ECC RAM would help but clearly you are not going to have ECC RAM in your phone any time soon, so oh well!
.
(Applause)
MAX STUCCI: We don't have any time for questions for this one. Next up we have Andrew, giving us the report from the Code of Conduct team.
ANDREW McCONACHIE: I apologise in advance, I don't have any cats in my slides.
So, I am on the Code of Conduct team and I'll be talking about the Code of Conduct report that happens at the end of every RIPE meeting.
So, since RIPE 91, we had one issue at RIPE 91 that was resolved. We concluded it was a violation and issued a warning. We were also contacted about something that happened at RIPE 91 after RIPE 91, and the reporter decided not to move forward.
So, at RIPE 92 ‑‑ I didn't have time to update this slide actually, because about an hour ago we received an incident. So, up to about an hour ago we were at zero, zero open cases, zero RIPE 92 reports. Now we're at one. So, we have one open case, and we're still triaging, that's all I'll say about that.
This is the standard slide about how to contact the Code of Conduct team. We always want to hear from people. If you are not sure whether you should contact us, we would love to hear from you, please do, it doesn't have to become a report, you can just stop any one of us at any time and talk with us pretty much about anything, even if you are just feeling uncomfortable about something. There is a form you can write the e‑mail address, you can write to any one of us directly. You can also say when you contact any one of us you can say I would only like to deal with you or I'd only like to deal with you, you know, and a couple of other people or I really don't want to have to deal with this person on the Code of Conduct team. We try to be flexible as much as possible in the interests of the reporter. So, if any questions about feeling uneasy or anything happens at a RIPE meeting or in a RIPE context, please contact us.
Last October, we conducted the first RIPE Code of Conduct survey, and I have got two slides to give some high level feedback on that survey.
If you want to dive deeper into this and you are interested in it there is a RIPE Labs article.
First, the purpose of the survey ‑‑ we had this question, right, it was like we don't get that many reports and so we had this question of: Are all RIPE attendees angels or are, you know, are people just not reporting to us for varies reasons like they are scared to report or they don't know how to report or whatever. These were our main questions. How safe do community members feel at RIPE meetings and how likely are community members to report breaches of the Code of Conduct?
.
And kind of a tertiary question related to those was have you ever seen or experienced something at a RIPE meeting that you didn't report? We were interested in that as well. It was open for all of October 2025. It was five short questions, completely anonymous, and we decided we wanted to make this a regular thing. We're not sure if we do it every two or three years, but the idea is that for the purposes of collecting longitudinal data and just, we want to make this a regular thing.
Is here is some of the feedback we received, or well the high level stuff at least.
Again if you are interested in diving into this more, I do recommend the RIPE Labs article, not just because because I am the author.
I think the best thing to come out of the survey was that we received 93 responses. That's a pretty high response rate I think. I wasn't really expecting to receive that many responses but glad we did.
Predominantly male of course because I think that's representative of the community itself.
As far as how safe do people feel at RIPE meetings, the meeting response of nine out of ten. It was higher for men than for women and for those who chose not to report their gender. But still, I don't think we could do better than nine out of ten, right. Like...
So that was pretty good.
The second question is more mixed. Would you report misconduct to the Code of Conduct? 63% said yes for sure, 28% were a maybe and a 9% were no. We had another question which I don't ‑‑ there wasn't really room on the slide but it's more like, you know, if you have ever experienced something at a meeting, did you report it or not? And we drill into that more in the article.
I think that 28 percent is somewhat concerning, but again maybe it could be for a lot of different reasons. And again as I stated, you know, there were differences between male, female and people who didn't report their gender. In general, men just feel safer and are more likely to report incidents, like that's a very easy statement to make based on the data we received.
Team updates: We had one member leave us, a big thanks to Samaneh who was with us for close to a term.
(Applause)
Thanks a lot.
We have also been doing some outreach. We presented at the RIPE fellowship group call a few months ago for the fellows. We are working on an FAQ, I think we said at RIPE 91 we were still working on an FAQ, we got sidetracked with the survey and what not. We are also working on publishing a transparency report as RIPE documents. So right now the only real artifact we create are these presentations that's public. So, we need to, we need to get better about recording the kind of ‑‑ recording and archiving the kind of information that we are proofing about how many incidents we receive at each RIPE meeting, basically turning these presentations into something more that's, I guess, appreciative is like as a historical artifact. Again we can capture data for measuring and what not and to be more transparent. We are working on to turning these presentations into actual RIPE documents for that purpose.
This is us. You have probably seen our faces a bunch this week, our faces seem to be everywhere, which is cool. We do get some reports of why are your faces in the toilets? We are like probably next time we're going to work on not having our faces on the posters in the toilets, but we still, we do want to have some kind of like notifications in the toilets so that people just know that we're out there and we can be contacted. So we are just, we are going to continue to have posters everywhere at RIPE meetings but they'll be like our faces won't be in the toilets anymore.
And that's it. I don't know if we have time for questions, but I'd be happy to take some.
(Applause)
BRIAN NISBET: Thank you very much. We're tight on time but if there are two very quick questions or comments or otherwise.
SANDER STEFFANN: I hope I'm speaking on behalf of all of us when I say thank you very much for doing this very difficult and important work to make this community a better place to the whole team.
(Applause)
ANDREW McCONACHIE: Thank you very much Sander.
SASHA ROMIJN: I specifically wanted to thank you for acknowledging earlier in the presentation how hard it is sometimes to report and that you really want to make it as easy as possible, I have seen events that take no reports and everyone is great and everyone is nice. It's so good that you are acknowledging and trying to help people to actually report something if it feels off. You are doing excellent work, this is really hard work I have done it in other communities. Thank you very much.
(Applause)
BRIAN NISBET: Thank you very much.
And for the presentation you have all been waiting for. How it all worked. How the bits for our slightly travelling circus got to all the right places and the video and all of the other fun things. So Rob please give us the RIPE 92 technical report.
ROB DE MEESTER: Thank you. This week there was no need to look at the RIPE NCC status page to find out how our week was going. The people in this photo were your most reliable uptime indicators, if these faces were smiling, everything was running smoothly. If you saw one of these people in this photo running through the hallway, something was probably on fire. So my name is Rob, I am part of the RIPE 92 technical team, and I would like to share with you a summary basically of how this week went from our perspective.
This week actually started very early for us, because getting our shipment through customs proved to be an interesting challenge. For each item we shipped, the UK customs office required a lot of information from us, and that combined with the fact that we were shipping over 1,600 items to each meeting proved to be a lot of extra work.
So, after filling in these customs forms, already one day later we received our first rejection. Be more specific and please count each individual item. So we went to our storage, we counted all our network cables, resubmitted it, and after a couple of more tries, we got the approval. So our shipment was on the way.
So, what are we actually sending here? Well, like I said a lot of network cables, some super micro servers, a lot of access points. Wait, I see that UK customs office rejected this slide. Let me try again.
We brought exactly 266 ethernet cables ranging from 1 to 30 metres and a bunch of other stuff. And specifically for this meeting also these EU/UK power converters which we ran out of the do you recollect the week. We haven't been to the UK for a while. Looking at the logo there.
So, we had a short set up weekend, our truck arrived on Friday, we started the setup on Saturday. This is 1 day shorter as usual mostly made possible by the fact that we have these new bigger access points that saved us a lot of time on taping them down, mapping them out, planning. But also we have to say the support from the venue IT staff was really amazing, they are very professional, responsive, it's great.
(Applause)
A little bit about our meeting infrastructure. This is the logical topology of our meeting network, all the routers that we run are virtualised on to very small super micro ESX hosts and for this meeting Comms World kindly provided us with the connectivity. The venue kindly allowed us to place our equipment in their patch rooms, which were very neatly organised until we came along. A picture on the right you can also see this little switch with six ethernet cables in it which is feeding the six larger campus E7 access points in the main and side room.
These are our hypervisors, they run about 25 VMs on them and they are mostly deployed abuse ASNsable.
One of the fun things about visiting these different venues in our job is that sometimes you come across these relics from the past. In this case it was surprising to find that some of the outlets, even here, and in these blocks from the seventies, they work fine.
For the meeting network, we like using as much OpenSource technology as possible. And these are some examples of that:
I don't know what this is exactly, but maybe we'll hear a presentation about it at the next meeting. Hopefully at least one less than 13 months.
Moving on. This is a map of our access points placed on the current floor that we are at. As I said, we're using significantly less access points than in previous meetings.
We first introduced these at RIPE 91 in one of the rooms, and they performed really well so we brought a couple more. We always bought the official stands that go with them so we longer have to tape them to a camera tripod, which is an improvement.
Also for this meeting, they again performed quite well during a busy session in the main room they would get like 200 device associations while still getting acceptable speeds.
Also, we used in the other rooms, a couple of the smaller access points, don't rule them out yet. Because this tiny one at the lunch area next to a trash can held the record for most device associations at lunch, which was 275.
But we also had some problems. So on Monday, we started getting reports from a small group of people about some of the IPv6 connections being dropped on the ripe MTG network only. After investigating, we saw some similar reports on like the Ubiquiti forum but they are not exactly the same as what we were experiencing. The advice was generally reboot your access points. We started doing that on Tuesday, rebooting them regularly. We also tried a bunch of other things to fix. Yesterday we also tracked down a problem with one of our switches which we removed this morning. The difficult thing with this is, out of hundreds of attendees, it happens to a handful, and then only a handful of that report these issues to us. Will but because we're really interested in troubleshooting these issues and trying to fix them, small public service announcement.
Are you experiencing any connectivity problems? Please find us at the IT help dynamics or e‑mail us.
See it, say it, we'll try and sort it at least.
Very fast about the presentation system. This is what it looks like on paper. It looks quite neat and tidy here, again in real life maybe not so much.
Each room has two Mac minis connected to an HDMI switcher. The slide are uploaded through our website. They get synced to the tech desk at the back every five minutes, so back they tech desk we prepare everything for the next presentation and then at the right moment we just switch to preset. On the previous slide you might have noticed these small keyboards also. We use them because we have very limited room usually in the back. They are quite convenient unless maybe you haven't had your coffee yet and you are trying to is scroll through the intermission slides.
We prefer sitting close to the AV team usually. That didn't happen this time they are up the top there. But it really helps to fix these lighting or sound issues quickly. Will so for example, on Monday, the audience lighting failed. If you look very closely you can see my colleague, a shade of my colleague Ondrey asking a question during the Plenary, but especially for the online audience it was really difficult to see. So we attempted to communicate this through walkie talkie to the IV people for several sessions but later we discovered the tech desk and the AV team radios had been on separate channels the entire time.
It was fixed on Tuesday, though, together with the lighting. Which by then was kind of unfortunate for Ondrej because he no longer had that cloak of shadows over him when he tried to climb on stage fixing a cable during our CEO's presentation.
A new feature I want to point out is the ability to upload this private version of your slides. It was a really highly requested feature for presenters. So that some people would like to present with presenter notes, and they did not want them visibly public on the website. So with this feature, you get to upload your slides, so the tech team receives your presentation that we show on the lectern here and on the website it will only have the PDF without the presenter notes. So a big thanks to our web services team for working on this.
Then, lastly, some statistics.
On this slide I would have loved showing you the statistics of the IPv6 versus IPv4 traffic. I am sorry to say we still don't have these. It's been on our wish list for a long time.
We only get so much time between meetings and we have our regular jobs also at the RIPE NCC.
Then some wi‑fi statistics. So here you can see the first activity is the two days during our setup weekend and then gradually it gets busier, I don't have this morning statistics here yet.
Finally, some coffee consumption seems to be down compared to previous meetings. But still the barista pulled like almost 1,000 shots expresso per day, which is still impressive.
.
Lastly. I like to give a special thanks to Meetecho for their help with the remote presentation, two of them are in the back. The others are remote. Thank you.
Again, also a very big thanks to our amazing stenographers who did a great job, again.
STENOGRAPHER: There is smoke coming off my machine! (And my hands)
Then Comms World for providing us with connectivity, and the venue which has been really great. So thank you. Any questions?
(Applause)
AUDIENCE SPEAKER: Blake Willis, happy community member. Thanks very much. Just a quick one, please don't take this as a critique or a complaint or anything like that, but I am just curious why we're still using BIND 9 as a resolver. I mean I imagine there is probably a good reason.
ONDREJ CALETKA: So, the reason why we ended up in BIND actually I said this in RIPE ‑‑ the one in Krakow, basically it's the only DNS resolver out there that can do at the same time, DNS over HTTP as DNS over TLS, DNS over UDP 54, people still use this and at the same time, it can do DNS64 but it can also do DNS64 only for particle and sub‑nets. We don't want to the it everyone, all this combination of features we used to use not resolver which was supporting if, unfortunately I found there is a condition there which makes some problem that we had in, where was it, in Italy, in Rome, that the GitHub is blocked and it was actually an issue in not resolved, I have reported it, it's sitting there, it's super hard to trace down the person that was working on it decided to leave the company because of this, I guess. So... the BIND 9 is still alive. It's developed, people are develop it are here in this room so there is nothing wrong with it.
AUDIENCE SPEAKER: Thanks. That's a good reason.
MASSIMILLIANO STUCCHI: I don't see any other questions, do we have anything online? Thank you very much.
(Applause)
MASSIMILLIANO STUCCHI: This concludes the session for us, and I will hand it over to Mirjam for the closing.
MIRJAM KUHNE: Hello everyone. So it's always exciting closing the week, it was a busy week and it's great to see so many of you still here.
.
Let's show you some statistics as well.
This was almost our biggest meeting. Check‑ins online and on site are just close to 1,000. We had one meeting, the one in Rotterdam was slightly bigger, we were just above 1,000. But it's also great to see so many newcomers here, you see the numbers there on the slide. And the countries we had people from 55 countries, the top five of course, you know, the usual kind of local crowd is here obviously. People were Germany, Netherlands, France, the US, around the larger countries but then almost many other countries were here represented.
Thank you Amber for having us, for welcoming us at the Opening Plenary. Beautiful city, I hope some of you had time to explore or maybe stay around for some nice weekend.
Also, I want to recognise the local hubs that were connected to our meetings, three of them throughout the week there, they sent us some pictures, they were active during the week and had a good time there in Turkey and Poland and in Bulgaria.
And again, I have to put them on the slide, a big thanks to the Code of Conduct team for providing the safety net for us at the meeting. And also for providing this great report we just heard.
Another big thanks to the Working Group Chairs who are handling, you know, the content and the engagements of the different Working Groups. Here you see the slides, you see the pictures here of all the Working Groups and as usual, we are saying good‑bye to some of the Working Groups. Some of them have been around for a long time, thank you very much.
(Applause)
If you can come up here, I don't know if you are still here. Nina isn't here, she had to run to the airport. But I gave her a little present when she ran out. I don't know if any of the others are still here. Leo, don't be shy. Come up. Thank you very much for being a co‑chair of the Address Policy Working Group for a long time and there is Julf, he has been co‑chairing the operation Working Group group. Is Peter still here. Moritz.
Thank you.
(Applause)
MIRJAM KUHNE: Then we of course also have some incoming Working Group Chairs, returning my thanks to David for running for another term in the Database Working Group. We have a new Working Group Chair in IoT, Raymona, unfortunately she couldn't be here this week but she got a good support from the group. I am looking forward to working with her and Maria in the IoT Working Group. And they have Mark, our new DNS Working Group Chair and then Leslie Noble for address policy Working Group. We'll here more from them before the next meeting I am sure.
Also PC, you have seen them around during the week chairing the sessions. These are the faces of the Programme Committee members who are responsible for the Plenary at this meeting. Thank you very much for putting together a good programme. I heard good feedback about the content. And please also, you know, fill in the survey and let us know what you thought about it and rate the talks.
There is one PC member who is leaving who decided not to run again. It's Kevin. Are you still here? I don't see him. Thank you Kevin. He is still going to be around but he has other engagements and decided to not spread his energy too thin so he is going to step down. Then you already heard the new PC members, Max has been re‑elected and we have Paulius and we are also adding Mikhail as the representative from the central Asia region. These are the new team members for the next RIPE meeting.
And of course a big thank you again to the meeting organising team. Especially Hafsa, Kajal down there. They look very relaxed in the photograph but I have seen them running around a lot and I mean this was an amazing effort to put this meeting together and this venue. So thank you very much. Also, a big thanks to all the other RIPE NCC staff who are here either to support us or also to engage with the members and the community in various forums.
(Applause)
And last but not least of course a big thanks again to the, to all the sponsors who contributed to this meeting. I would especially like to thank the host, maybe have somebody come up here from the local host.
(Applause)
.
And again, please rate the talks. We have your feedback, I also send a mail afterwards with a lot of links that you can use there and then also here is a QR code for the feedback, so if you want to scan that quickly, you can provide us some feedback while you still have it fresh in your minds. Is there a comment before I move on?
ROBERT KISTELECKI: I think we also need to thank the local weather gods. I feel deceived about the Scottish weather now.
MIRJAM KUHNE: Especially today. It seems to have rained only when I was inside, so it was always wet when I came out but it was sunny, it was great.
So I hope you all scanned the code in the meantime. And now ‑‑ oh yes.
SANDER STEFFANN: Just want to mention that yesterday there was a very successful AI BoF and I heard there are plans to do another one at the next RIPE meeting.
MIRJAM KUHNE: That's up to the PC to decide I guess.
We're come to the part where we actually welcoming the local host and telling you a little bit about the next meeting. Unfortunately the local host, which is actually, you know, the Bulgarian Internet Exchange, they are going to hosts at RIPE 93. Unfortunately they are not here, however they have asked one of their colleagues to tell you a bit about Bulgaria and what to expect.
SPEAKER: Thank you Mirjam, so, it's such a great pleasure for me to invite you all to Bulgaria. Final the RIPE meeting is coming to my country. The venue is the Grand Hotel Millenium Sofia. It's a really big venue. The hotel was finished about seven years ago so it's still quite new. Big conference facilities. A lot of rooms and it's also relatively close to the city centre.
I wanted to also share a few things about Bulgaria for those of who you are not very familiar with the country.
So you see an image of yogurt on the screen. Why is that? Bulgaria has a very long tradition of creating yogurt and also the bacteria that turns milk into yogurt was first isolated in Bulgaria and named after it too. It is also the birth place of the Cyrillic script. It was invented in the 10th century Preslav literary school. That's one of our oldest capitals. Last week Bulgaria won Eurovision, but the country is also very famous in the music world because of our folklore, because it has many unusual vocal harmonies. I'd advise you to take a listen.
There is also a valley in Bulgaria that has the perfect conditions for growing roses. So that valley is responsible for 80% of the world's production of rose oil, which is used in perfumes.
Something that I found out recently about my country is that it's famous also in the fitness world, and in specific an exercise called the Bulgarian split quad that you can see on the screen. It comes up in every fitness video apparently. Will I see some people know about it.
And lastly, for those of you who are planning a trip I would like to explain our head gestures, which are different than what the rest of the world is used to.
So, when we say yes, there is a bit of a head wobble like this which looks like a no for the rest of the world but it's a yes for us. When we say no, we do something like a head nod, but you have to start it from low, so it's no. But when you do it multiple times then it looks like you are nodding so that's confusing. It is what it is. It's what we do.
A little bit about Sofia. It's a very old city. Like most cities in Bulgaria. I'd advise you to visit the archeological complex, Serdica is an old name of Sofia and there you can see buildings from different millenia in basically sharing a single photo frame. And also the archeological museum, it's fantastic, definitely worth a visit. Even if you are not a big history fanatic but for the fanatics there is more museums of history that are on the scene.
.
Then as soon as you land in Sofia you are going to notice a big mountain towering over the city. For those of you who enjoy nature and active hikes, I have listed two suggestions. One of them is to Cherni Vrah, the highest mountain ‑‑ highest peak. And then there is another circular route to the lake and waterfall. The church there is also a UNESCO heritage site. It's a very nice and green route to relax for half a day.
Apart from that, some other sites in Sofia. A lot of foreigners remark about our churches, so the orthodox churches are quite different than what you would see for example in catholic or protestant ones. So if you haven't been in one, I definitely encourage you to go and visit. The Alexander Nevski one is the biggest one but there are plenty more.
Also, please reach out to me if you would like to plan any weekend trips or longer tours, there is plenty to do in Bulgaria. The but, yeah, that's what I have time to share with you now. And I want to hand back over to Mirjam.
(Applause)
It's always good to hear somebody who has been in the country or coming from the country. I hope I feel encourage d to come to Bulgaria. Before I move on I forgot one thing ‑‑ I always forget one thing in the closing. I need to thank or platinum sponsor, AWS, I don't know if any of you are still in the room, Clara or Tina, otherwise we'll ship this to you.
.
Sorry about that.
(Applause)
And finally, this is the closing, please join us for RIPE 93, the registration is already open. You can register I think already some registrations I have come in. I hope to see many of you there in October. And that's it. Enjoy lunch.
(Applause)
See you all in October.