Plenary session, main hall,
RIPE 92
19 May 2026
2 p.m.
A big to Happy Birthday to Mirjam, 21 plus VAT today!
Have a great day!!
JAN ZORZ: Welcome back to the afternoon session, please find a seat. Turn off your phones because we are about to start. We have all the speakers here. Please find your seat.
MATT PARKER: Our first talk for today is Tobias with it's coming time for IPv6 in the DNS.
TOBIAS FIEBIG: Welcome everyone. I am now affiliated with Vienna since the 1st March, a little bit of colour change in the slides. I am going to talk about RFC 3901.
.
What is RFC 3091? It's the /TK‑PBGS IPv6 transport operational guidelines. It has been published in 2004. The bottom line is that recursive DNS servers should be IPv4 or dual‑stack, also authoritative DNS servers should be well actually this should say authoritative, not recursive, they should be v4 or dual‑stack and v6 is maybe kind of if you want and feel like it.
It should have at least one IPv4 name server. Again IPv6 is explicitly optional and zone validation, if you are delegating a zone and testing the name servers in that delegation, that should test IPv4 functionality. IPv6, well maybe, if you feel like it but not mentioned.
And at IETF 118 I was approached by my co‑author who thought it might be a good idea, given that it's kind of 2023 at that point in time, to start doing IPv6 in the DNS. So, we gave that a shot.
The question is why wouldn't we want to change RFC ‑‑ by the way, Jan, could you please set the clock.
So, why would you not want to change RFC 3901? This has been at that point in time roughly ten year discussion, so documented by this really nice blog post from 2015.
Well IPv6 does not allow path fragmentation. If the packets get too big they will have to be fragmented at the end sites and they might not make it if they are fragments.
PathMTU discovery is notoriously difficult for IPv6. It's just difficult.
There is this high fragment drop rate which will inhibit DNSKEY records because they tend to be bigger than 1,500 bytes.
TCP fallback, even though we were told to run DNS servers that do support TCP ages ago it does not always work.
And with DNSSEC on the rise because we all have deployed DNSSEC, right, everyone else? Anyone else? With DNSSEC, this gets an even more pressing issue.
So, there is a couple of counter arguments you can make to this also brought forward in this ten year old discussion.
At the moment, all TLDs are on dual‑stack authoritative name servers, if doing that would be a problem we would not be able to resolve TLDs especially not with DNSSEC. But we can.
PathMTU discovery is not that bad it's also bad for IPv4, so it doesn't matter in which IP address family you fail.
Fragment dropping is not that bad or you might be able to fix it, TCP fall back is in fact often used already.
DoH and doc exist, and DoH and especially doc, so DNS over HTTP 3, they really suffer from broken IPv4 connectivity with CGNs as was was brought forward by some vendors during the discussion of the RFC. Because the timeouts on the CGN is too short and usually these DoH connections are long lived UDP connections and then they break off because the date expired.
Then there is also RFC 9715 which is limiting the EDNS 0 size, people are deploying that, it works and OpenSource developers are actually looking at even lower EDNS 0 valuation that even suggested in this document.
In dynamics to that we ransom experiments. We tried to resolve the Google crux top 10 million using a minimally covering NS set. That's an idea from Peter, basically and idea that you hit each NS set at least once, once for DNSSEC once nor no DNSSEC, so you guilty a maximally wide perspective on different NS sets. Why while not causing too much unnecessary traffic. I mean I don't have to check the CloudFlare DNS servers roughly I think one or two million times in the top 10 million. It's kind of pointless. They behave the same. We also implemented different MTU scenarios. We put an MTU of 1280 on the link of the box which means that the box is aware of the lowest MTU path. And did that with working pathMTU discovery. We did the same with broken PathMTU discovery so dropping packet messages then we also did it on an on PathMTU break so the box was on an MTU 1500 link. Further down there was a break to 1280 and it onward continued.
In addition to these we also tested it once via our mix of Tier 1s and once via LGI. So all inbound traffic came via Liberty Global. Why did we do this? Rumour had it that Liberty Global actually dropped fragments on transit.
So, what did we see? Overall resolvability is mostly comparable. This matches up roughly with the 60, 65‑ish percent IPv6 resolvability. We measured across a board in earlier studies. It's lower for zones that actually do DNSSEC. It doesn't mean that DNSSEC makes your zones resolve better over IPv6. It means that people running modern protocols on modern software supporting model modern standards like IPv6 also tend to use DNSSEC and the other way round.
Some IPv6 packets end up getting packet too big. ENS 1232, that was interesting because apparently if you send a packet of size 1280, something on path might decide that it might be fun to add 8 bytes more. Most likely atomic fragment header of of middleboxes. There is a small baseline of broken NS, so name servers that have broken IPv6 set‑ups but IPv6 addresses are in the DNS, this is something that would be caught by actually testing IPv6 resolution when delegating zones as well.
For some reason we saw more fragments for IPv4 at EDNS 1496. For broken PathMTU discovery, IPv4 has more timeouts with DNSSEC at EDNS 0 set to 1232.
We also found the kind of expected high fragment drop rates. One tier 1 used to drop IPv6 fragments on transit. They put in after they got note of this, after the IETF meeting in Bangkok in March last year, a lot of effort to get this fixed in three months which still hugely impresses me because changing security policy on all routers of a Tier 1 within three months including will he being and deploy is I think impressive.
An actually when we had compared the values like the resolution values for working fragments and not working fragments, it also kind of looked the same.
If we do this with RFC 9715 compliance or rather the more strict interpretation of OpenSource developers, there is no notable difference. And with EDNS 0 set to 4096. There is roughly 1% of more fallbacks. Even with DNSSEC a bit more and the difference in timeouts which we see is basically not existent.
So, with all of that out of the way, we were able to get adoption for the document in the DNS Op Working Group. It went through Working Group consensus, it went through IETF last call and the IFG and it's sitting in the RFC editor's queue.
So, one note. All of these measurements that you have seen, they were done on measurement.netwok which is a project that received support from several members of the RIPE community and the RIPE community project funds. So, if you ask yourself, what the fee sometimes buy, this is one of the things. Like the upcoming 3901 bis.
So, what do we change here? We expanded ‑‑ this is a copy from the changed log in 3901 bis. We expanded the terminology section. It aligned with the newest DNS terminology document. We expand the text on how name space fragmentation can happen in practice. We recommend the use of IPv4 and IPv6 for authoritative DNS servers instead of leaving IPv6 optional. We added text for recursive and step resolvers, also recommending dual‑stack operation.
We now recommend testing IPv4 and IPv6 when delegating zones. And we added some more strict guidance to IP layer fragmentation handling. And guidance on how you handle address family issues on recursive and stop resolvers.
Which leaves a question for everyone dealing with DNS for one reason or another, is everyone in this room, even the people doing BGP, what shall we do now?
.
If you happen to be IANA, what I would really appreciate is if you could handle the open IANA task which currently keeps this document in the edit A state, and consider the IANA requirements which we put in, which is basically updating your own requirements for delegating zones to TLDs. And I kind of suspect and hope that this is what IANA is currently busy with and that's why it takes so long because such a document needs consensus, and here I am.
If you are NIC, you don't really have to do that much. At least not on your authoritative servers. So this is data up until mid‑2022 from an earlier publication and back then you could already see that 100% of TLDs are actually running IPv6 and IPv4 on their authoritatives and they are actually resolvable via IPv6‑only. Doing 9715 and MSF clamping might be cool but that's basically just some additional gravy. One thing to note is that some TLDs are doing better than others. Dot Dev has 94, 95% v6 resolvability. Dot IO, 94. Dot DK, 85. Dot NL, 84, 85. And for example, Dot IT only 20.
One thing to note, there is this little v6 incomplete point there. That means that for, in this case for example, 34.26% of zones in dot IT we found some remnants of IPv6 connectivity on the name server sets responsible for those zones. For example, if you do have missing IPv6 glue but put corresponding IPv4 and IPv6 addresses into the zone itself, so it is a child, you might end up in that part.
We will get to that in a bit.
So, if you are a NIC, you could start asking for v6 as well. You can ask SIDN how do you that. A little hint. Money that kind of works. Ideally ask for two times IPv4 and two times IPv6 and maybe push people to do 9715 as well. And maybe wait sometime without requiring it, it's like people will appreciate that, give them some sometime to accustom.
If you are writing zone checkers, check if IPv6 is there and at least soft fail, like notify. If IPv6 is there make sure it actually works.
Maybe do some additional testing for 9715. That technically needs a large resource records and DNSSEC, again for that you can ask SIDN or Switch how you can encourage people to do that, and again the hint is money.
You should also test the resolvability of out of zone NS for each protocol.
If you happen to be a registrar, you might want to run the tests recommended for NICs to run on the zone files just on your customer's domain. If you already did and found customers that are not doing this, poke your customers before your NIC starts poking you with money driven carrot in front of your face. And think about poking the biggest host not supporting IPv6 among the domains you are registering. Which might be you.
GoDaddy in 2017 I think, changed the total number of IPv6‑only resolvable zones by 17% globally because they added IPv6 glue to their name servers. And they are still a couple of those around. So if you look at the top NS sets in non‑IPv6 resolvable zones, it's like a lot of domain parking, so, in dot IT for example you have 20% of non‑IPv6 resolvable zones just sitting on domain parking and there is v6 dotcom, which also is an IPv4 only endeavour, which for some reason hosts a lot of zones. And there is also sometimes per TLD champions. So for Vulture ‑‑ for dependance I think we talked about this, I think we had the conversation with them about v6 on their reverse DNS, and Amazon AWS, but I heard from a relatively reliable source that they are currently working on fixing that.
And IP also mentioned dot IT, which is also funny, only 20‑ish percent of IPv6 resolution capability and 34.26% incomplete. So you have some IPv6 there but it does not really work.
And 25.32% of all zones are on one hoster. And there is one hoster has kind of broken IPv6, so it use four name servers, all of these name servers do have AAAA records. Three of them have given IPv6 glue and the parent. One of them the one in Dutch, has no IPv6 glue but still AAAA record in the zone itself.
However, the name servers for those three zones are in a different zone. They are in a Aruba dot IT and they don't have IPv6 addresses. So, if those servers would get IPv6 addresses and IPv6 glue, then all those 20%, 25% of zones in dot IT would be IPv6 resolvable in a moment. So if knows somebody at Aruba IT, please poke them. If somebody is a customer, please also poke them, it works better when a lot of customers do it at the same time.
So, if you are a hoster, roll out IPv6 on your authoritatives. If you already did that, fix your glue records. If you already did that, poke yourself hosting customers, and if you already did that, thank you. You are really helping.
As an ISP, it gets a bit more difficult because CGN is a lifeline for people do not have enough IPv4 for their customers, they need t and well, state is I think one of the biggest pains in networking, but it might be at the time to make a little bit more state base for your translation tables when it comes to DNS over HTTP, which is somewhat problematic because it's not really the thing you thud get from other QUIC traffic which an overall big problem which would go away if we would all be using IPv6. So, yeah, difficult, roll out more IPv6.
If you are a transit provider, please consider not dropping prefix fragments. If you are an end user ISP please also consider not dropping IPv6 fragments also on your CPEs. So a lot of CPEs which you can buy actually come from firewall rules that are for dropping IPv6 fragments. If you are just worried about DNS, it also helps if those can just cleanly communicate with your recursives which are not behind something that drops IPv6 fragments.
Note though, dropping IPv6 fragments doesn't hurt as much as previously believed, but in the end, it might be beneficial ‑‑ well while we are at it to just clean that up as well.
If you run your own resolver zone please also see the next slides, which is this one.
Please, start implementing 9715. Or ideally follow what most OpenSource implementations are doing, which is EDNS 0. If you are doing TCP fall backs, consider clamping. It doesn't hurt too much these days. It might get a bit more painful with post quantum cryptography and much much much larger keys, but that sadly takes some time still. Do support IPv6 DNS resolution, and again, on the path resolver, make sure that v4 and fiction fragments are not dropped. And if you do, it doesn't hurt that much.
If you happen to write DNS servers, it would be cool if you do something which Unbound is doing. It has a really cool NAT64 feature. All my person resolvers are running v6 only and I configured the NAT64 prefix in Unbound and then without CLAT they can go to the PLAT, get their queries translated and then they can do IPv4 DNS resolution without actually having v4 in the resolvers, it's pretty nice.
It also does a really cool EDNS 01232 factual back, which it means if it can't get anything going, it sends one query with EDNS 01232. And maybe, maybe do a bit more logic on IP selection to deal with misconfigured delegations, for example non‑GUA addresses. If you do not have that already, I think most of you actually cleaned that out.
If you build CPEs, software is not wine, it does not get better with age. So there is no need to use software which is at least in most European states allowed to drink and drive not at the same time. Nevertheless, people keep doing that.
Do not configure caching resolvers for others to be IPv4 only even if IPv6 is available. Ship defaults that signal EDNS 1232, if you have a forward on board, Clamp MSS on device originated queries. And personal wish of mine, maybe ensure people can always install their own OS, and your firmwares and do not rely on funny blobs. This is DNS unrelated but I have a dream.
If you read Libcs maybe count higher than 3, this may sound a bit funny but actually it is a resolve conf on the most hosts with Libcs actually supports only three name servers, that's like hard‑coded. However what comes with this is a problem of doing proper resolver connection if you get multiple ones from different sources and potential multiple different resolution and different resolution capabilities. What I would recommend is participate in v6 ops about picking resolver address families correctly. Erik has at least an idea for a draft there and it will hopefully become a draft soon. And then we at least get some guidance on this, hopefully.
I also built a little thing which happens to be like all of the little things I build, really ugly and a web interface, but it allows you to give FQDN and preferred resource record which you would like to resolve then it does DNS resolution against a bunch of differently configured DNS servers in different network conditions. So, with this, dual‑stack resolution, etc., of course MTU 180 on path with no fragment dropping and PathMTU discovery can frag dropping, without frag dropping and without PathMTU discovery. But basically, an exhaustive iteration of all the possible use cases.
The UI is kind of difficult. So if anyone here feels like doing some front‑end development, I would appreciate that.
I am also willing to trade zone files for stats. So, all the tests from the previous slides run against a set of zones of your choosing and providing.
I am also willing to provide the biggest single entity evaluations, so, that data about like who is doing how bad and who are the most responsible hosters in your zone, I have that for all public suffix list zones since December of 2025.
I am also willing to offer broken network as a service. I know some people don't need that as an additional service, they get it as a free add‑on. But I'm willing to do it intentionally. So I can offer virtual machines in broken network conditions to run resolvers and authoritatives on. If you open to be an OpenSource developer of this kind of software and you would like to have a VM in these conditions to see how your software is doing, drop me an e‑mail. There is a plan to be at IETF in Vienna to provision boxes where they are needed.
With that, one last call. Roll out IPv6 please, it will solve a lot of problems, software and technical nature which we are as a community currently struggling with.
So, thank you and please ask any questions you want.
JAN ZORZ: Thank you.
(Applause)
JIM REID: Interesting talk. I can't stop burying my head in the hands a bit because this just seems to be a manifestation of the general problem of IPv6 up take. We have also problems of getting people to deploy IPv6 and having issues with DNS up take for IPv6. It doesn't seem all that different from the problems we have with just getting IPv6 transport done. However, I have got two points to make on your presentation. The first one is to do with trying to get more IPv6 into TLD delegations. I think it's going to be a problematic for IANA to do anything there directly.
TOBIAS FIEBIG: 100% of TLD delegations have delegations and are resolvable. This is basically the only time where you will hear me say we do not need more IPv6 because we are at a hundred percent.
JIM REID: I thought you were asking for getting more v6 information.
TOBIAS FIEBIG: I am asking them to update their guidelines because all the ccTLDs and other TLDs are copy‑pasting from the guidelines because it's easier than writing your own document.
JIM REID: The thing about that those guidelines is getting those guidelines changed would be problematic. You hinted about when you are giving a presentation, because the way in which ICANN works, I don't know IANA can act a three year, they need to get some kind of mandate from the ICANN community and this can be difficult to achieve because anything takes a long time to achieve in an ICANN setting. On the other side that have in terms of do dealing with that for will ccTLDs, it may be better to try and get something done through centre or a CCT TLD type community rather than trying to go through the ICANN machinery, you might get more success there, particularly if people have connection could get influence on their stakeholder registries, that might be a better way and quicker way forward.
The other point I want to make is to go back to slide 7 where you mentioned the the DNS serve fields are more prevalent whenever DNSSEC wasn't used. Fields were like at 33%, then with DNSSEC was being measured, it was less than 10%.
That seems to be very strange. DNSSEC introduced new ways to create serve fails. If a valid ‑‑ if a DNSSEC validation fails because of a keying error ‑‑
TOBIAS FIEBIG: This is before you get the records. So this is a zone of which I know that it has DNSSEC which I tried to resolve but I cannot even contact name servers so I run into a ServFail before I get to the DNS part.
JIM REID: That explains it. Thank you.
AUDIENCE SPEAKER: Thanks for the speech. Just one detail of the slide after. This one. There is a Tier 1 that applies a (inaudible) policy on transit packets. And the security policy of to drop fragments for v6 only not for v4.
TOBIAS FIEBIG: Yes. And I changed that very quickly.
AUDIENCE SPEAKER: Okay. And the other point your recommendation about the CPE vendors, are you applying this suggestions to the FR... v6 ops Working Group where they do work on the CPE requirement?
TOBIAS FIEBIG: I actually haven't thought about that.
AUDIENCE SPEAKER: This could be easy, right, so please do.
AUDIENCE SPEAKER: If you do go down the route of trying to convert more ccTLDs and similar to have this types of policies, it would be helpful to explain to them why this is good for them and helpful to them instead of what the tone often is, which is you guys are doing this wrong. I think a reasonable amount of the tone in this was: You people are doing it wrong and should do better. Not, here is why this would be really nice to do. It's just a tone and wording thing.
JAN ZORZ: Okay. There are no more questions, thank you very much.
(Applause)
GERHARD STEIN: Thank you. Let's go. It's great to be back. Thank you very much for this opportunity. A great pleasure. As introduced, I am lead research engineer at Flexoptix and before I start with this presentation, a question to you. Who has the task to monitor temperatures continuously of transceivers? Please raise your hands. All right, we have a couple. Nice. Okay.
Well, then particularly for you, it's interesting. Who of you have accessed the VDM or the diagnostic monitoring? Okay. I would say it's a bit of a hidden feature, there is an analysis of optics obviously but I also snuck in an analysis of network use particularly switches, but before I get to this, I want to answer a question.
Transceivers, especially 400 G 1, Coherent, 800 G and so on, are consuming a lot of power, and in this presentation, I am going to show you where this comes from. We want to have a clear look at this problem because it's easy to assume, if you have the opportunity to keep your laser turned off, even though the transceivers is connected, you can put it into the state and you turn it on, all of a sudden it draws more power, so it's easy to think that it's to blame the laser, but let's look deeper into t
.
I start with some basics, the diagnostic monitoring, then a discussion about the laser, TEC, then a bit of power budget and planning and then an own definition of efficiency, actually what I want to discuss in efficiency is how you are transporting it, because it's not only power consumption, that's obviously converted almost a hundred percent into heat and how can you transport is out of your system efficiently.
Let's start with this.
These are the devices under test. We came up. So we have 100 G, 400G, 800 G and some switches, a newer Cisco one. We got led by one of our customers and some legacy Cisco, and Juniper ones. And before we looked deeper into the versatile diagnostic monitoring, first I want to explain the difference. When you read the temperature it's like the first value if you look to the bottom, by 22, and by 23, and you read out this temperature and what usually the network here does is takes its bytes and converts them and that is what you get when you read out your temperature. Now, diagnostic, versatile diagnostic monitoring is an extension to that and has one big advantage and if you look clear, instead of having a byte you have TAB ID. Why? Because it gives the vendor the opportunity to advertise what it reports, why was VMM you have a table where you read out all the possible values. Some of these values, there is a probability that they are not reported and maybe you have some strange values and you don't know how to interpret them and that is quite annoying especially for developers who have to deal with that. So with versatile diagnostic monitoring what you do is build your own floor loop. You go through this, check which way this is, look at the table, if it's tier you will just skip it, if it's a value you translate it and with that you do not only get the values with the calculated samples you also know what the transceiver advertised. That is particularly important because for coherent transceivers, for example, you have different values then for grey ones and all the VDM tables are across different agreements where you find this.
Now we did some tests with different switches as mentioned these support only DDM. Sometimes you find it in manney, sometimes we have to get. If you have modular temperature on, there is basic ways of DDM, it's most likely that it only supports that.
Even though it could support more but it really depends on what pages it is accessing. Same with the Cisco one. Here we have an example of the more modern Cisco one and here is one where I want to discuss about it, TC current and laser temperature, and we have an interesting fact, it feels a bit like it's being hacked around because usually laser temperature when you read it from your agreements, now we know it supports, but another fact, if you read it directly with your own code, you never get absolute temperature. You always get a difference. Why a difference? Because you want to have this difference on theory. Because the laser temperature is the critical value. Modular temperature I mean you can reflect, 30 degrees 40 degrees, it depends on your environment. But the laser temperature is a point. It's a specification, if you cannot keep up this temperatures is problematic. Fortunately the transceiver has a contra circuit and something that really provides that stable temperature.
And 50 degrees is a usual temperature. Here you see the variation. That's normal. Sometimes 50 dot 02, some laser operate on 55 degrees, or 60, but that is the temperature you usually have.
Now, two years ago we talked about coherent transceivers and these are quite interesting because they get very warm and most of it, of the power you invest as a set that consumed 70 watts. Most of it is translated into heat. Some of the energy is translated into the value you really want to have. But we want to look into the of 16.99 watts and where does this power consumption come, where does it go, where is the most current consumed for all these chips? And I mean the formula is basic electrical engineering, you have voltage, you have current, and for the powers of laser, you can, with the help of DDM, read it out. But for the power of the TEC, which is a term electric cooler, I get to this device, the cooling device, you need VDM, so, if you have these values, some other ways are read from specifications like laser voltage, you have to look into data sheets, but you can assume that's important because it's the voltage, it has to be.
So, with that, you can calculate your power consumption of different devices inside your transceiver. Let's talk about the term electric cooler.
I find it a fascinating device because it's a particular element, you can see to the top right a typical particular element which you might find in chemistry laboratories, but in reality, in the transceiver, if you look inside, it's hidden and it's next to the laser. How does it work?
.
Well actually, you have two they are automatic plates. You have a metal bridge inside with a semi conducter blocks and if you let current flowing through, putting a voltage on the metal bridge, what inducing is a heat flow, and if you inverse its polarity that is the more interesting paragraph, you are also inversing the heat flow. So with that an a contra circuit together you can ensure that your laser at all times will have a stable temperature. Does it warm up? It's too hot, it can cool down with the proper current you just invert it and you heat it up. And for that, it is quite efficient and fast.
On the other side it is not so efficient because depending on the temperature, which is stable yes, but elements have a degree of efficiency of 10% unfortunately that's the reason why that makes sense to have it in a transceiver and air conditioner is out of question but on the other side a pelt a element for your room for cooling down your room is also not a good idea. For that air conditioner is better because 30, 40 controversial is what they can achieve compression, depression of the gas you have inside.
So that's the idea.
Now, power budget, there have been some agreements on the left side you see the ones for 100 G transceivers, to the right side you see the one for some 100 but also 40 and 800 ones. They have simplified. You might have seen it in some manuals the documentation where you use a power cluster to really see what the the worst case scenario, how much power you are going to consume. That is not as important anymore, because it's also a bit difficult with the different flavour, variants, a taste of transceivers you can buy nowadays, to have power classes where you can trust the way they are given. So power class 1.5 and if you have aid you have to look at 107, it's the same as agreement, said screw that let's just give it with maximum power, you recollect still import the power class, it can change, other than that it's not as relevant anymore. What you want to know is the worst case scenario, how much and maximum where your transceiver consumes.
And at Flexoptix, I have simplified this by just if you are looking for a transceiver, you are planning, I mean you do it ever about you buy it, obviously, and you just look at power consumption and that is the maximum way you can expect it will be drawn when you are planning. Usually when they are running like two, three, four percent below is what you usually can expect, but, you know, worse‑case scenario for planning so you have enough power.
Now, you have seen the flex box, some of you are using it, there are some research tools I wrote myself. This is what I understand the most, I am not sure if you can do this better on Ross but I like this as a framework a lot. I also dissected the flex box 5, it has a battery where you can monitor everything. And as soon as I plug in the transceiver, you can see what's happening inside the transceiver and also the different temperatures which are of interest.
Now the laser is still turned off, as I said previously, this was out links, the laser is not yet running but you can access the transceiver, you can read out measurements and see the temperature. The temperature is going up when you plug it in. Now give it power, that is what happens, and it's running a low power mode. You can see it was green curve to the bottom that between 1.2, 1.8 some transceivers, some Korean consume around 2 watts. But it's really the maximum so. You don't have to worry about heat and dissipation. You can access a transceiver still operate with some with some functions on it but it's not running a link yet. What you can do is a firm way upgrade but you can also measuring what it's currently doing and how accessible it is.
Now let's turn on the laser. As you can see here, now the whole thing is operating. You can see the term electric cooler that is heading up the laser because the temperature that is in this case specified to 55 degrees, it is heating up so the derivation is very low as I said before because lasers have to be at a constant temperature. If the temperature is way too different to what it is specified, it not only becomes less efficient, it might change frequency, it might change wavelength and this is also bad for the link. There is a filter but still that is something you don't want. So this contra circuit is quite strict on it.
Also you can see is connect a jumper cable you have tomorrow signal 2 DP, if you check the blue curve. Jumped up from the 94 dB where there was nothing of power and the temperature obviously goes up. As I promised you before, we are looking into this rise of temperature and why is it happening. Is it really to blame the laser.
Before I get to that, I want to also talk about generations of transceivers because it's also exists we have the 400 GFR 4 for example that was released in 2018, and for 2025 there was a revision. It looks the same, you have the same connector, connectors, media site and host site. But what is inside changes from time to time. It really comes down to nanometres from 12 to 9, it's a good gain. So if you can get later generations of transceivers, that is also worth an investment, because with manufacturing technology and nanometres that are going down, you are also saving energy and power consumption. So that is kind of a solution you can apply already because you are not only saving power obviously you don't have to transport as much heat. But it's something to look for. Will for example, the 1.6 T, there is a second generation already and it's the same. Sometimes they change components like A6 loop and 40 SP and different drivers. There is a lot going around with different generations.
Not a bad idea to look for it.
Now talking about efficiency and heat transport. One of my favourite topics.
Ideation is something we hopefully don't get to see in data centres because camp fire, that is what you feel when you put your hands close to it. We are talking here about combustion temperature of between 1,000, 2,000 degrees. That's something you don't want to have in your data centre obviously and most likely will not get. But conduction, convection models we have to look at, mathematical models. Here is are some equations and it comes from differential equations but the thing is they are uncoupled from geometry so if you want to apply geometry like this simple example, I did not put any special heat things because it gets more and more complex, they exist, entire books talking about it and a lot of scientists who wrote the papers, that one is the most famous one because I say used a lot, and fluid mechanics and if you combine all these formulas, that is what I did for this particular case. It turns out that if you double the speed of your fans, you are not doubling the watts why do I want to show that you? Because in the last years I have observed dataset are getting quite loud and noisy. I have the impression that the solution is to just increase the fan speed. Put more fans into it. Increase the fan speed and so on. But I want to warn you about this because it's not linearly escalating. You have a problem here, if you double your air flow speed you are not doubling the watts, you have to quadruple it every time. Doubling the fan speed is not a good idea. But as I mentioned later generations, or if you have the opportunity different heat things, more area to saturate your heat could be a solution but normally we want to reduce speed ‑‑ we want to reduce space like Meta already mentioned they want to reduce the space here, it's becoming a problem if you want to have better heat dissipation. I think the best solution is later generations.
Now getting it down to where does the power come from. This is a logarithmic description of this transceiver I was measuring here. It was a coherent set. As you can see the TLC power which is the blue curve, if you compare to TEC in laser power surprisingly it doesn't draw that much current. That's interesting because a laser at 50 degrees and maybe ambient of 30 degrees if you can cool down your device as efficient, you would think because it gets hot, that is where the voltage comes from but it is not that. So if you subtract term electric cooler and laser, what is really there, modulation is what takes most of the power. It's like with the CPU, this transceiver are becoming more like a CPU, the modulation is some are sort of calculation that from coherent transceiver, like we saw in the morning, you have your bit stream and your translating them. I mean your quantum diagram is really a mathematical description of your phase shift in polarization, in the end all this needs to be calculated and then needs to be recovered on the other side, right.
So, that's the thing that draws a lot of power actually and also is converted to heat. And I was looking for the hot spot because I really thought that TEC, because cooling requires energy, and laser, there would be a hot spot where you can find, add 50 degrees or I tried different cases here, you would find like a spot where it goes down, but it's almost constant. So it's really negligible what you have here. You really have to look more into MTUs and more efficient chip set to the do the kind of modulation we require.
Now, some results of switches, because that was more interesting. I think in the software switches operating systems, maybe a sonic operating system, I want to look more into this, you can reduce the power, hopefully, because you have a feature as I explained previously, you can decide to enable your transceiver but also set it up the way that it does not turn on the laser. If you do a different kind of diagnostic, a different kind of test. You can even tell the transceiver to just do some bit rate measurement only on the media side so you can rule out where the problem comes from if you are not happy with your transmission quality for whatever reason and you want to find out is it a problem with your network here or is it a problem with your media, your optical fiber, so there are a couple of features you can test and also read out what is being advertised.
But interestingly, if I subtract the base power consumption of the switch without any transceivers, just subtracted it, depending on the model, and plug in a transceiver, you have different kinds of overheads, especially with the Juniper one, with the cable I connected you can see it goes up. It should draw 3.5 watts but it's also at 7, so there is some overheads, some management that happens if I resolve the IX is goes down a bit but it's still consuming and that leads me to the impression that not all the features that are on the transceiver are really used by these switches. That's unfortunate. There is a pin called low power mode which you can set. You can imagine it with a television, you put it on standby with your remote control you can turn it on whenever you use it. It consumes very little of power. There is something similar you can do in switches in low power mode. The big advantages is you don't have to go to the data centre and pull them out if you want to save energy. There are ways you can do everything with software.
Anyway, the right side was the Cisco that performed a bit better, but you have licensing with fan types and so on, but then the device we tested here did pretty well with the transceiver, we connected two different kinds, they consume the same power. I really wanded to check how they behave, and it's almost the same, and why not.
Now, one last experiment which I promised because last year we weren't down transceivers with 250 degrees. Now I am going to freeze a transceiver this time. So, this ICE packet with some ice cubes on top are just for decoration. Actually what I did was using some tetra fluoroethanol gas and this gas is able to pull down the temperature down to a minus 40 degrees, and now with a combination of heating up the whole time, you see some condensation effects, I'm not sure if you can see t I think it's ‑‑ there is some frozen drops there which warm up and you remove the gas. So there is a thermo dynamic exchange which is quite interesting. More interesting is how much power it draws, if you cool it down because it makes you believe that having a cooled down system, because warm electronics consume even more voltage, how much it helps and in the end, it really is about 200 megawatts. So it's not that much. But it's interesting to see. You have to imagine we had minus 10, minus 20 degrees, and it's still operating at 50 degrees, so you have a data of 70 kelvin, that's a lot. It's interesting how efficient devices still can operate on such conditions.
.
Anyway, getting to the conclusion.
Laser and TEC are not the main energy draw, we have to be more efficient at MCU and DSP and see if we can develop a firmware that is more efficient.
You can run PRBS to find out how it would perform if you don't have a switch, if you have a coder box you want to do it on, that is a good test where you can do it because it goes almost to the maximum power consumption.
Laser temperatures are usually at 50 degrees. That's a different way. Don't get confused with the other temperatures.
If you are able to shut your port, do it. Especially with the coherent one. 7 up to 20 fold less energy is consumes. You saw the one with 17 watts. This one consumes around 1 watt if you shut the port. This really helps. It puts the transceiver into low power mode. You still can access it but it's not really consuming that much power. So better have that if you have ports you are not using, right.
You can measure power at the switch. And that is something we also do with the flex box.
And that's t thank you very much. I am happy to take questions.
(Applause)
MATT PARKER: Thank you.
AUDIENCE SPEAKER: Blake Willis, optical geek. I really appreciate the shut out to the new VDM standard, I was not aware of that. I would encourage everyone in this room that writes RFPs to is ask your vendors about it and that you ask them to support it because if you don't poke them they won't do it. Will thanks.
GERHARD STEIN: Yeah, let's poke them.
MATT PARKER: Anything online? No. Okay. Thank you.
(Applause)
Just a quick reminder we have PC elections this week. If you want to nominate anybody or you want to nominate yourself, you have 30 minutes remaining, 3:30 is the deadline for nominations. And up next we have James and you are going to have to remind me, Elinor Ostrom, from Childlight. It's a global child safety Institute from the university of Edinburgh.
ELINOR OSTRUM: Good afternoon everyone. This is, it's a slightly different topic from our previous speakers where we really put at the centre of our work children and young people. I'm Elinor Ostrom I am a professor of criminology at Childlight at the university of Edinburgh, and we work with Childlight which is a global child safety Institute focusing on the safety, the online safety of children and young people.
So, as I mentioned, we are based at the university of Edinburgh, we have been funded four years ago by the human dignity foundation, and we work with a number of partners around the globe to really identify the risks that children and young people are exposed to online and we are here to share some of the data that we have just launched today.
So, we started our global Index two years ago focusing on technology facilitated CSEA, child sexual exploitation and abuse. What we have done this year, we have added some further studies, in fact we have had 19 additional studies that we have added to our Index. Between '23 and '2024. And we have included some sub‑types of technology, child sexual exploitation and abuse.
And this data has been presented really for the first time globally and as I mentioned, it's been launched today.
And what we found, largely, is that 9.1% of male and females reported facing online exploitation and abuse online during childhood at least once in their lifetime. And I am accompanied here with my colleague James, who is going to take you through our data.
JAMES STEVENSON: It's a little bit of a different type of presentation. But we take a public healthy approach towards tackling technology facilitated child sexual exploitation and abuse. As part of that we think that a surveillance model which looks at multiple sources of data, so some is based on survey data, which this meta analysis is based on, then we also conduct stud eats in child sexual abuse materials that is available on online and hosted by a number of different companies, as well as the distribution and shares of child sexual abuse guidance documents.
So, first, I am going to present a bit on our technology facilitated findings from the meta analysis.
You'll see that one in four children is likely to face online sexual extortion during their childhood. So this is based on a number of studies that were conducted both with children as well as survivors, so those would be adults that dealt with or perpetrated against.
What we see is that in western Europe this number increases to 37.4. So that's over one third of people are experienced some form of online solicitation.
We also added a new sub‑type as Elinor Ostrom referenced which was exposure to unwanted sexual content which will be of particular interest as recent legislation, within the UK but also pushed worldwide, is focusing on limiting exposure to children to sexual content. So making sure that there is age verification for entering adult pornography sites or spaces of the Internet that should be only accessed by adult users.
And as you can see, 7.3% ever children have experienced this type of exposure.
When we look at some of the regional findings we see that online solicitation is especially high in Latin America and Caribbean region. Eastern Europe also shows up as high in unwanted exposure. Same with eastern Europe and central Asia. We did see a sex difference between the reported types of child sexual abuse with girls experiencing more commonly online solicitation, exploitation and sextortion, also known as sexual extortion.
Boys experienced high rates of exposure to CSAM and that's exposure town wanted sexual content.
My question to everyone here is can this be addressed to tailored safety interventions in how can we use this information about sex and gender breakdowns as well as regional differences to create a safer environment for children online?
In terms of regional findings based on child sexual abuse material we used data from four of the global actors in this space that measure whether it's reporting of CSAM or the hosting of that content so we take data from the International Hotline Network, the IWF which is based in the UK, the Internet Wash Foundation as well as net neck in the United States and thorn as well as child rescue coalition, we have broken this down into regional availability in terms of proportional measures, as well as the tagged content within those different regions. So what does the actual content look like of this legal material?
.
One things we have seen within this content is that commercial tags of limited proportion and volume exist across the world. This is the sale of child sexual abuse material and the marketing of the same. We also saw that a large portion of that commercial content is found on the onion router, and this is especially important as we look at kind of how to disrupt the availability of this material as the onion router or often used as a facilitator to access on this type of content on the clear web.
So, one of the areas that I mentioned earlier is that it's new to this dataset is data on child sexual abuse documents. Or paedophile manuals. These documents are created by perpetrators and offenders and shared both on peer‑to‑peer network as well as clear net and DarkNet. And they provide three different functions based on data from a round table that we hosted. So the first one is instructional intent. So, they provide guidance on what to do in order to prepare a child or to harm a child.
They also provide a justification for those actions. So they act as kinds of like this is the reason that this is okay, and they are sharing in possession symbolises that especially. Finally it creates a culture of normalisation within this community that harming children online and in person is okay. And those are the three things that we would like to disrupt.
So, when we look at the distribution of these based on just one data source, we find that they are largely located in high income countries. And this is especially important as we look for levers and advocacy and support in terms of disrupting the availability of these materials. It's because high income countries largely have the legislative levers as well as the resources to disrupt this type of content being made available.
So the fact that 82% in 2023 and 75% in 2024 were located within these regions shows the responsibility of these governments and organisations to address their availability.
So, if there is one takeaway that you can kind of take from this, is that we are trying to promote three different types of responses to this. So the first one is to recognise it, which, as you can see from the data, is, it's a global phenomenon, it's something that needs to be recognised.
The second is prevent it and for this we have talked about before is taking a public health approach and that's not saying that tech sector is solely responsible for this, but has a duty of care to children and especially child users to protect them online. And they are one of many architects that can help facilitate this. Others are through education sector, through health itself, through criminal justice, and legislation, all of these need to work together in order to disrupt the availability of this type of material, as well as the availability of the instruments to groom, harm and exploit children online.
So, I don't know if there are any questions. Elinor Ostrom and I will be in the hall after this presentation. Please come up to us if you'd like to have a further discussion, we are happy to share, as Elinor Ostrom shared, this is available for the first time today, and it's building on the continued work that we do at Childlight around murk the scale prevalence and nature of technology facilitated child sexual exploitation and abuse.
Thank you everyone.
(Applause).
AUDIENCE SPEAKER: Speaking for an NGO, not one ISP now.
First, thank you for the presentation. Over the decades, we have seen such reports, nothing has changed. It's always the same numbers, always the same same sources. We had a discussion about 30 years ago and it was the first time I was involved in this discussion and we had a problem that there was an understanding that there is something to protect, but the misunderstanding or the misconception here is, Internet is not a safe place. The Internet is the mirror of the real world. You have to deal with this world. You can't make a safe space for the purpose for good purpose by restricting everybody else. That's not possible.
So, the real problem is how to make, and why (inaudible) it the Internet so it can be used safely. It's the same question we have, how to protect children in the real world. There are some areas, there are some no go areas for children and the parents are responsible for this. You can't go out. Politics has to say something that no area in the world might be a problem. It's not possible. We have the same discussion here in the Internet.
The Internet is content neutral. It means I do not understand your presentation for this audience here because I say technical people. We are responsible for keep it working, nor for stop it. For some reason, the reason might be good, but do some productive on this. For 30 years we started with an action delete instead of blocking, and it was a huge success because the law enforcement agencies had no interest in going out and delete content, harmful content. There is some really bad content there needs to be taken by the law enforcement, the people have to be taken down of course. But it has to be done by them, not by us because they can decide what this useful or not. The same is for Tor network. The Tor network is there in order to protect a lot of people. I am coming from a region where we had our first project was with new religious organisations and we seek for how can somebody want to get out of a sect or something, how to protect them and we use these networks for this.
JAN ZORZ: The comment is longer than the lightning talk.
AUDIENCE SPEAKER: Thank you. It's Lukasz from the university. I think we are obviously on a very emotional topic here and also very at tens between child protection and also privacy and the Internet. And I was just wanting to ask whether you had a look into like technical measures regarding making the compromise between protecting children online but also still retaining the ability to stay anonymous in the Internet? I think there are some, and I think it's important to provide guidance to governments and also companies, how to implement such measures. I was wondering if you had a look into that.
SPEAKER: I'd like to first answer to the first gentleman that spoke. I'm really sorry that you think that this topic is not relevant. I tend to disagree. I think everybody has the necessity and I think to learn about what the data 20 years later is still saying, to show that, you know, the landscape is still quite fragile for children, young people and I agree it's a very emotional topic.
But as you say, it's important to share these findings, to share this data which comes from organisations that we respect and they are working day in and day without to ensure that the Internet is a safe space.
In terms of, you know, what do we do with governments? Absolutely, governments have a huge responsibility in shaping legislations and policies, and we inform governments with our data to, you know, to show robustness about some of the recommendations that we always put forward to them in particular.
And going back to the technical side, I think, you know, we all know that the Internet wasn't designed for children and young people. However, they are the largest consumers, and users, as we know, so it's important to take them into account when we do design new products.
So that safety by design, which you probably heard hundreds of times in your work, it's something at that that we put at the very core of our recommendations with tech companies and industry. And I'm not sure if James wants to add anything.
AUDIENCE SPEAKER: Andrew Campling, my affiliation is relevant for this talk, I am a trustee of the Internet watch foundation, which is a charity that locates and removes child sex abuse material. I think it's important to raise the topic, because it is technology facilitated harm. So we can close our eyes to the problem but it's a problem that the industry is enabling whether we like it or not. And I guess thinking about that privacy comment, there is also the privacy of children which is actively being harmed by these attacks. So do we protect the privacy of largely privileged adults at the expense of the privacy of children and arguably their other human rights as well remembering that privacy is a qualified human right versus things like the right to life, which is an absolute right.
So sometimes I think we get distracted by privacy and forget other human rights matter as well, so we need to take a much more balanced approach.
.
(Applause)
JAN ZORZ: Petr.
PETR SPACEK: Thank you very much. This is going to be another little bit emotional topic, for me. I am Petr Spacek I work with ISC on all things DNS but this time I am talking on behalf of many projects, I couldn't fit them all on the slide.
From the news you already know that LLMs can find a lot of bugs. Some of them actually exist. A sub‑net of these is exploitable.
The tool itself is just a tool, but the real problem is again in this case as well the people. There are many people who nowadays use the CVEs as a character enhancer and their own keeper authenticate rs based on the number of CVEs they get assigned. When they submit things to OpenSource project, it's not the help the project, it's to help themselves to the next bonus.
Case in point. BIND DNS server received this year today, well yesterday, it has changed overnight, over 200 reports we have managed to track 130 of them up until yesterday, 84 more to go, yesterday, again, and roughly 8% were actually valid security issues of various severity levels.
We have 500 more to go.
.
Going to the routing land, FRR. A similar story. 62 reports to date. This is only for this year. Roughly 4% valid.
Number of CVEs is kind of messy for FRR because anyone can go and assign a number of FRR which is just insane but that's what happens.
Unbound: Similar story, lots of reports, definitely more than previous year.
BIRD, in the routing land, again similar story, 70 reports only to this day for 2026, 7% valid.
PowerDNS, exactly the same story. Lots of reports, 5 percent valid.
DNSmasq, I didn't have a chance to meet Simon Kelly in person, the maker of DNSmasq so I have just quoted out of his e‑mail on the public list. Will you can see lots of issues, time spent on finding duplicates, insane.
Why is it a problem? Well we like to receive bug reports, that's all right. Send it our way. But this is an example of course you cannot read it but that's just to give you a sense how it looks like. This is one report for BIND is goes for pages and pages and pages. It has sub‑titles like step by step proof of concept. The catch is that it goes on for a couple of more pages and then you find out you cannot ever use it and the LLM just wrote something but there is no way to trigger that. And the motivation for the submitter was to get a CV E number and to get a money for the bug bounty.
So, if the reports were a drink, it would be about this quality. And the OS maintainers get that drink everyday at least two, so yeah, not good for your health.
In a essence, what is happening is that in our service attack on the development team, it's a handful of people, they are here in this room, they have spent sometime together, you can shake their hands and see that it is people not machines, and it's really taxing. For you as the users of the OpenSource projects, that in effect means that the features are not being developed really, or perhaps at a very slow pace because all the time is spent on triage basically. Perhaps you have all your features, you don't care about the features. That will be good, I would like to stop doing your features for a while. But perhaps your deployment is growing and would you like some performance optimisations, these are not happening either.
To cut out the, you know, try to optimise the process, at least in a BIND DNS, we have decided to stop providing work‑arounds along with the bug description because it takes even more time for every single bug to find out how exactly you can configure it so it doesn't trigger and we have like 300 nodes. The same version goes for version affected. Historically we have provided the first version affected was this number and the last was this n we are not going through that anymore. We have 125 years of history, it takes time to find out the exact version number and we don't have the time.
So, the bottom line is: It's going to be very interesting going forward. I can see some things in the pipeline, and other projects shared their view that this is going to happen. So, can you upgrade? How long does it take? Please think about it, because if you have a CVE fix released like every short period of time, it will be interesting.
I spoke in the hallways to route server operators, so the, one the most critical parts of the infrastructure, of course I am DNS guy so I know nothing about BGP, that's also critical, obviously. But in DNS land the route servers are critical, and some route server operators told me well, okay, you ship new code, we release it, we have automation, we can deploy it any time. That's how I like it because it will get used very often.
Perhaps you can say okay, these small projects, they suck, they cannot keep up. Well, I don't consider Linux kernel to be a small project, and judging by the last week and the security release like every week, it's not limited to small projects, you can read more often the link.
Perhaps you know these OpenSource snowflakes, they cannot take it. Well, here is a statement from Microsoft of course, it's a huge corporation, so like, five floors was working on that statement so it's huge and you have to parse it. The bottom line is we are able to act quickly and if you can act quickly you will be better off. The long story short.
Going forward, it is entirely possible that the usual luxury of having the embargo and you have one week advance notice that there will be something and then you upgrade might not actually hold because if someone used the LLM to find exploitable bug, there is no reason why someone else cannot do that. And that is actually happening in practice, because we are getting duplicate reports at the same time, or, you know, in a span of a week, so apparently multiple people are finding the same things at the same time, and while the reports we see are from the good guys, sort of, at least half good, but I don't see any reason why the bad guys who actually want to exploit that instead of getting the number for the CVE, wouldn't do that. So, well, be ready.
.
If you are a searcher or new researcher, please send a message that verify reports are actually harmful to the projects. If you find something verified before we send it over, we have enough unverified stuff. Here, there is a link in the slides for a template which is useful perhaps for the projects as well and basically cuts it to, we don't need cold flow explanation because we know how our code works. We need actually report user and the assumptions you have about a test. So if you are reporting bug in DNS, let's say, and your assumption or the assumption your LLM used is that the parents of this malicious, then go home, this is not a security issue, because the parent in DNS can do anything, that's how the protocol is designed. Maybe it's a bug but definitely not a security one.
If your LMM can generate pages of text, perhaps it can generate something more useful. If it can generate a test, executable code that demonstrates the issue instead of a vague description, that would be excellent, send it over. Not like 5 MEGS of code but like ten lines or okay 100 lines if ten doesn't do it, please send it over. That will actually help.
With that, I am at the end of the talk. There is not really much we can do alone, but you can help us. Different projects are in different situations. Some projects would like, you know, having the money so they can hire more people to work on it, that means more projects. Other prongs perhaps enough money, but they would like to, for people, but perhaps they would like to play with the LLMs, gives them access to hardware, give them access to the LLMs, or generally ask them what they need because they need better than I do.
Brace for frequent upgrades. Thank you for attention. We have like 45 seconds, I apologise, I am not sure how we handle this.
(Applause)
MATT PARKER: I am going to cut the queue immediately if you could all be as brief as possible please.
AUDIENCE SPEAKER: My statement was generated by LLM, so point one out of five is...
I liked your observation that the social contract apparently needs a little bit of restructuring in that, for instance, you no longer do all the leg work to figure out what's affected what's not effected. It's like okay, it was identified, latest release has the fix, enjoy your life. I think cutting in old features or removing legacy like headache parts of code bases, a lot of projects benefit from like a spring cleaning because it reduces your surface, there is no negotiation with the machine. Like, you have recommendations like include this, include that, but in OpenBSD we now see that the LLMs just fully automated dump reports on GitHub, there is no human on the other side at all. So there is nobody to even negotiate with.
It is what it is. So, thank you for your presentation, I found is very insightful and I can corroborate all your observations and I agree with your analysis of the current situation.
PETR SPACEK: I can see that we have a bunch of open source maintainers in the room. Perhaps if you stand up and wave, people will know who to ask for, what they need.
AUDIENCE SPEAKER: Daniel, I am Internet citizen. First of all, thank you for the presentation. I think it's eye opening. I also agree with your conclusion, be ready for quick updates. Everybody in the room should take note.
This just strikes me as the, a repeat of the whole story of spam. Basically, it's a DDoS. And the way to deal with this is probably so, as in the OpenSource community, to make some tools to deal with the avalanche. So, open source maintainers should probably get together and make a, rather than paying for, having maintenance fees and paying for dozens of people doing stuff, creating some software that helps dealing with the deluge. Maybe that's an idea. Think about it. Thank you.
MATT PARKER: Like I say we are very short of time. We have one more presentation left so please even quicker.
AUDIENCE SPEAKER: Hi, Andrew Campling, 419 Consulting, the relevant affiliation this time. I was at the RSA conference, the annual cybersecurity conference a few weeks back, the headline from that is it's going to get far worse than LLMs because agentic AI is currently redteaming your software, your infrastructure and even very under funded new agentic AI is placing in the top 1% of hacking capability in capture the flag competitions at the moment. State actor backed agentic AI hacking will be far better than that. So this is going to be a problem. It will find the actual viable issues not just superficial ones. And probably the whole of the issues is going to be technical debt.
AUDIENCE SPEAKER: Lukasz. I was just thinking about the social side of this issue. Because, like, there may be someone is spending time with the project, finding bugs. Maybe it's AI assisted, maybe they didn't put so much work in and may they did and maybe they do want to talk about it. Maybe I was wondering if it was a good idea to encourage like communication with open source maintainers beyond publishing a CVE. Maybe you don't need to directly put up a CVE, maybe it might be better to have a chat in the first place and maybe see if you can even confirm the issue and only then put up a CVE with documentation. That was just an idea that came to my head but thanks for raising the discussion, it's an important topic
GERT DÖRING: Thanks for bringing this up. We have the same issue. Like seven reports in the last two weeks. And we haven't yet been able to triage them even. They don't look critical. But we have had to do many more updates than in the previous years.
On the subject of CVEs, this is actually an interesting point. When do you assign a CVE because the rules are what fuzzy. Doing a CVE is more work than not doing a CVE. Do you do a CVE and then an embargo release because it's only a minor bug? It's a nightmare.
PETR SPACEK: Let's talk. We have the same questions. Let's talk in the hallway.
GERT DÖRING: One of the things we need to address is actual distributions, because like OpenWRT, Debian, whatever, they ship stable versions of the software, which means I have to go back to like two releases earlier and figure out is the bug still there and we don't do releases for open 2.7 anymore because we are 2.7. So if somebody ships 2.5, the patch might not apply and then all these updates stuff falls apart, which is a problem we need to fix.
PETR SPACEK: Let's talk.
AUDIENCE SPEAKER: Dave Knight. Thanks for the talk. I hate to see you struggle but as it's said, a wake up call for operators. You mentioned that some of us are sitting with our deployment at the end of a CICD pipeline, we have got the test bed and we can rapidly do I think so this. That's not everyone. And I think, you know, operations streams to have to be having conversations with themselves right now because our model for how we do this stuff has to change to adapt to this. Previously where we could look at a CVE and think about it in terms of attack surface, do we need to patch now or is this a firewall thing? The work‑arounds.
We're not going to be able to have those talks and keep up that. We are just going to have to keep rolling out patches and so we are in that danger of now we're doing things we understand less and so it's going to bring operational instability as well as you know nightmares to your lives. Sorry.
(Applause)
MATT PARKER: Last talk.
STEPHEN FARRELL: I guess I have like minus one minute.
This is kind of a little bit lighter I guess.
Encrypted ClientHello. Has been worked for loads of years and finally it's kind of done, it's an RFC since March. We got code into OpenSSL in April. Even though that code had been more or less stable for a couple of years. There is some details there. The work we did was funded by open tech fund who are a good funder who gave us money to contribute code upstream for OpenSSL and for a bunch of web servers to enable ECH.
Without this, the server name indication the SNI in the first TLS exchange exposes the domain that you are talking to. That can be used for monitoring or it has been used for censorship and other things as well. We'd like to encrypt some things in the client message, including SNI, maybe LPN, maybe other future parameters, and that mostly makes sense when you are not exposing the DNS name through DNS over port 53.
This is how it works. I'm not going to explain it. How many people were a rough idea how this thing works. Scattering, if you are interested, ask me. The interesting part here is that the client is now looking up A and quad A and approximate resource records in the DNS. It has the ECH public key that we use to do the encryption. It has other things. It speed up browsers as well. By putting out an exchange. There is a bit of key management required because you need a private key to go to the public key. You have got to update the DNS and so on. That's probably the trickiest part and updating clients that previously had a simple model of how they looked at mapping names to DNS content. This HTTP resource record makes it a bit more complicated.
That explains the same thing in text. There is a bunch of cases that I'll skip over because I have got minus one minute.
The code changes. If you are going to deploy this you need some kind of key management, typically it's like a Cron like service where you refresh these keys periodically. CloudFlare in their test sites for example do it every hour. We do that in same in our test sites because it's in the nature of the protocol that it doesn't give you forward sequencing. You want to replace those keys at some frequency.
On the client side it's relatively straightforward. The mechanics is all inside the DNS library. The hard part for clients is doing the fancy new DNS stuff, which related to Happy Eyeballs and all sorts of things. Doing that simply just to get it working is relatively straightforward. Doing it in a fully featured way is more complicated.
On the server it's much easier. Essentially, patches for things like Apache are a couple of hundred lines of code only. One the TLS library supports the feature.
What's supported. OpenSSL has, this is the client libraries here, support is pretty good. There are of course API differences between OpenSSL and boring SSL. In terms of client, Firefox, Chrome and derivatives, we contribute code to Curl, which is there now.
On the server side, all those webservers have it in their main branches. Now that OpenSSL has released this, hopefully it will in future releases of though web server products, it will be a feature you can just turn on and configure and relatively straightforward have it work.
So that's basically it. It's kind of more ready to be widely deployed if you are deploying web servers in particular, or if you are poking at TLS exchanges to look the at the SNI in the client, things might change. If you are interested in applying it, we're happy to kind of help you. We still have some funds from our funded project so we can help people get it deployed. There is, on the project site there is some various reports including one of a little trial we did with the wikimedia foundation where they enabled it on a small property they had last year. The headline is nothing broke so it works and doesn't break things.
With that, I am done. I expect fewer questions than for the last presentation.
JAN ZORZ: Thank you Stephen. Brilliant stuff and I see it's very clear. We are standing between them and coffee.
STEPHEN FARRELL: If you are interested, just grab me or Niall O'Reilly and we can talk to you about it.
JAN ZORZ: All right. Thank you very much.
(Applause)
MATT PARKER: Just one announcement. If there are no buses to the social tonight. Just be aware, you'll need to make your own way there, you can walk, you could take public transport, you could take a taxi but there are no buses. There is one exception if you have mobility issues there will be a bus outside the Moxy at 8:45, but that's only for people with mobility issues. Thank you very much.
(Coffee break)
.
.
.