IoT Working Group
22 May 2024
At 11 a.m.:
PETER WEHRLE let's start on time, I am the chair with you here for the IoT session so there's another Peter, so we made it simple here in the work group. Peter Steinhauser is on a business trip in US so he hopefully joins us here now so 4:00 in the morning for him.
We want to start with the ‑‑ with a little housekeeping, so first of all, just going to the, I have a clicker here, so on the housekeeping, we have three talks today, so therefore, the schedule is quite full.
So the first I is Eric, just I was a little nervous because I did not recognise him we have Poonam, for her the first time in the RIPE meeting and for doing a presentation for us, and last but not least, Jad, around with us, he wants to give us some updates on the RIPE NCC IoT because there's some interesting things we discussed last time in and now getting an update.
The co‑chair selection, I did a mistake in the group, it was election, it's definitely selection, so that we use the Meetecho and I will give you a short introduction to this.
First of all, from the housekeeping, so we have validated the RIPE 87 minutes so it was distributed on the e‑mail list and so there was no objection to this and, of course, so we have also this meeting under the Code of Conduct, if there's please anything let's take under this conditions.
On the minutes from the last meeting, I stated it was posted to the group. There was no further discussions on it. We have also published the links, so the minutes of meeting is now finally agreed.
So today, we have also then people typing again the next minutes and let's see how that goes.
So if you have any questions as for all other sessions, so we are now in the middle of the RIPE meeting so you might have experience already, go to the mic and ask a question and say your name and affiliation, which is then noted. You might either speak for your organisation or for yourself.
Just to mention on remote participants, so you can have audio video, question, stenography, you can go for chat and for the poll so we are opening now a poll, how to go to Meetecho, so you got a link with your registration here in the meeting and this is a unique link for you so you can go to Meetecho and open the chat, even if you are here in the room so there's a simplified version which helps you here in the room, and this is we will open the poll now, you can either use your telephone here, your laptop and, especially, yeah, if you are online, then you have the chance to put, yeah, your choice on the three candidates, so we have ‑ so he applied as well as Peter Steinhauser, so he is my co‑chair now, he is asking for second round, and we have Andre, so sorry for the spelling mistake, it should be a Y on Andre so he sent his e‑mails into the e‑mail group, you had some time to do some discussions there so we are open now, the Meetecho poll that you can give whenever during the meeting your voice to one of the candidates. We will then visit the results in the end of the meeting.
So, if there's any question on the procedure? Okay. So, I'm happy then to, because we have quite tight schedule, so we have scheduled roughly around 25 minutes for the presentations and so the first one is from Eric and I'm happy to welcome him here directly in the room.
(Applause)
You may know how this works.
ERIC VAN UDEN: Good morning. For those who visited RIPE meeting in Rome, I had a short presentation about topic, in this case we promised in this case with Peter Steinhauser we would go a little bit more in‑depth and a few weeks ago there was a broadband for spring meeting in Miens in Germany, and there was as well a very interesting link between the data models, so in this case the 369 and tier 181 and the IoT world, in this case, Meta.
So what I do for you is that I give you some slides already here, you have seen them and some slides are sent by me from the broadband forum and give you an impression what's happening over there and where is the link between the broadband forum and the RIPE community as we are here?
Some words, who is, make it very short and simple, we are manufacturer of the well‑known German FRITZ box, you find them in Europe, we will products for these L K fibre and cable networks like 4G and 5G
Why I am here? I am a generalist, I am not a specialist but anyway, I have a deep role within the company as AVM looking what do we need in the international market, what are the directions we see of the Internet world, in this case from the already mentioned technologies as well from the IoT world, that's my world.
Stepped in in the broadband forum in the executive advisory Board because AVM is very relevant, to be on track what is happening on the standards and all the T R 369, TR69, you name it, that's very relevant for us.
Last but not least AVM is building products including more and more IoT solutions and we have to do something and that's why we are very keen and very interested on the feedback you are giving to us here direct on the RIPE meeting together with one of my colleagues, or later on via e‑mail.
And I keep it as a surprise. I said we do Matter, that's true, we implemented Matter now it's running as we called it in‑house test so MPE and AVM have the ability to use the Matter technology and looks quite promising but still we are in the beginning of this stage of this product so we still need feedback from our colleagues but as well from the community.
If you look to the broadband forum and how they react and what they do, they have cooperation between several companies, or organisations, in this case the IETF. So there is feedback coming from both sides, it feeds into groups like we do here, and implement those things in the stacks as we see.
If you look to what's relevant here, I will give you more insight look, we have some things the tier 1A 1, tier 369 USP certifications and so on.
Let's step further ‑‑ sorry, some mismatch ‑‑ what is USP? USP ‑‑ and I give it in my own words, USP is a solution where you can monitor and control devices, and define devices that's very wide, it can be, in this case, routers, as we built, it can be ONTs, the IT devices more or less in very broad spectrum of equipment. Nowadays, mainly used for Wi‑Fi management, Wi‑Fi control, and setting up the first connection of an Internet device, can be done by TR369 or TR69 standards. It gives a lot of opportunities and possibilities, and I remember years ago there was a document also coming from the IoT Working Group for security, how to control an IoT device and in that ‑‑ I hope I pronounce it right, this draft document, there was as well 369 as a standard and also I believe 369 is USP is the standard to communicate to devices without and implementing all software from all foreign vendors into your router products so we use as AVM 369 as the international common standard to communicate to our routers or our CPEs as well to the equipment behind the CPE and from AVM point of view we think this is the right approach and the right approach to go forward, because it's the standard and it is well known and is used by a lot of ISPs in the world.
Okay. In part as well is a question: As an ISP, say nicely, do I want to know which type of equipment an end user is using in their home? Is this relevant for me? Yes, no? Is it a security topic? Yes, no? And when I am doing this, how to do this in the standard way, if you made a decision yes, I will, yes I do, then T R 181th the data model is from our point of view the right approach.
What do I like to see? I like to see a map of the user equipment, where it is, how it's connected, as already said I need to know and I want to see the Wi‑Fi quality because that's the main reason why a customer is calling this help desk at the ISP, Internet is broken and as we all know it's not Internet broken, it's one part of the connection what's broken and USP gives you the ability to look and to control what's happening, what's looking at the inside world of this ‑‑ at the customers.
Moving a little bit, let's already said, I want to connect those worlds, yeah, Matter is something I give a few slides last RIPE meeting in Rome, so sorry, a little bit of repeat but anyway that's what we promised as well in the RIPE meeting because there came some questions. Matter is the protocol used for smart home, for controlling smart home in the standard way. If you are aware of it and nowadays you need an every vendor to control your lights or your climate system, and Matter looks very promising to give a standard by a control where you would ‑‑ you can control all your type of IoT devices.
Matter is something what popped up by the big vendors, the big suppliers built it, there was a delay, do we implement this? Do we go forward? Google is very active on this, this element, and own experience like I say, it looks very promising and easy so what I have now just an example on mobile phone using Google home I can control all the FRITZ devices because at AVM we decide to use the protocol for controlling our IoT devices and it's not the most ‑‑ it's well known standard for controlling devices. But anyway, by implementing Matter, now I can control all the stuff from a Matter point, and this makes this open to the world, not only at AVM side but a lot of other vendors doing exactly the same.
That's why it's so important that to interrupt the several devices is already there and you can use it and we hope, not really sure but I think and hope that this will be the common standard. It's not really 100 percent clear that it will be the standard but as already said several times, it looks very promising and I think it will be the standard for a lot of vendors in this environment.
Some technical slides because I learned here presenting you like to know it, okay, TCP, UDP, ICP version 6 and lower layers based on layer 1 can be a Wi‑Fi threat build an a lot of other stuff and with this you control it.
As said and already promised with Peter Steinhauser if wanted we can do an in‑depth in between, unfortunately that couldn't take because of very tight schedules on all sides but anyway, if there are some questions, that's why I could promise we can do it as well.
As already said, what has USP to do with Matter? Where is the link? And the link is that with the data model TR181 and messages from our implementing more and more IoT, so in this case you can use the standard 369 data model by controlling the IoT devices, including the Meta devices and that's why, again, there's a cooperation between the broadband forum and the CSA, that is more or less the company behind the whole Matter stuff, how to do it, what to implement and how to implement all those stuff in the current data model, in this case TR181.
Matter, first of all, we think as well as from AVM it's relevant but be careful, we are still on ‑‑ do we want to know, I repeat the question from the ISP side: Do we want to know what's used internally at the end customer's home? Do I want to control ‑‑ do I want to see all the things are happening over there? So, from my point of view, there's still some, how do you say it, correlation needed to look and see well, what do we implement in the data model so that we can have control or only just monitoring and so on and so on? So there's still some work in progress, and today I received the broadband forum information about the new data model and I saw there is ‑‑ yeah, there are still some topics they are working on.
As already said, there is already work done so it's in the ‑‑ in Matter interface is implemented in the model. Thread technology, layer one for communicating is implemented, but as already said several times, we are not there. It's still a lot of work to do and we still need some feedback; is this the right way? Is this the right direction? Or do you say please go away, this is not the right direction because...
Let's say very nice and I'm in Dutch so I am not really well known as political correct, the cooperation between the CSA and the broadband forum is interesting. I will leave it that way, but anyway, it's very complicated, but anyway, both organisations think that this is the way to go forward and that's the way they think we have to go cooperate with each other, and as already said, and I am repeating myself, has ‑‑ USP has the right cards to do it. That's also one of the reasons why I am doing this talking here, we need the feedback from you, from the audience, from the RIPE community, and as well on the broadband forum they are doing more or less the same sessions that I am doing here, to collect the feedback on several organisations, and to see, okay, how we deal with it, is this the right thing? And so on and so on.
What's happening? If you like to travel, the broadband forum has the next meeting in South Korea where it will be begin on one of the topics on the agenda. And is also town hall meetings and they are meetings about the whole new technology, new things and people can, let's say, promote their solution, their things, their feature proof things about new things and new technologies. It's very interesting, they did it in Germany as well at the spring meeting.
If you like to know more, I have some links for you where you can see all the stuff and what's happening over there. I am here with three of my colleagues, so we are open for questions if you like, or at this moment, and yeah, that's more or less it. I want to thank you and I hope you give you an overview of what's happening and why it's so relevant for the industry. Thank you for listening.
(Applause)
Any questions?
AUDIENCE SPEAKER: I have a question about the technical scheme you showed. There was a layer of IPv6 about is it going to also support the IPv4, because like a lot of IoT devices suggest as Zigbee and stuff only do IPv4 from what I recall?
ERIC VAN UDEN: That's correct. I have to look to my right side but as far as I know, it's completely the ‑‑ the communication is completely done using IP version 4 so no IPv6 in this case.
PETER WEHRLE: There is one question in the network from Maarten botter man: Has there been a privacy impact assessment and/or is there any at least commitment to minimum dataset or personal data?
ERIC VAN UDEN: That's the, exactly, the one million dollar question and exactly the topic where I was aiming on. As far as I know, and give me ‑‑ as already said, my own impression if you are in a data model the system is communicating with the devices, it's communicating with the devices. So there should be an opt‑in solution and there's more or less the same we do in the CPE when the customer is activating his device, he receives: Do I allow the operator to communicate with my device, yes or no? From my point of view the next step is exactly the same, you ask ‑‑ does an end customer have to make a decision, or do I allow that the operator can and see and control my IoT devices? Yes? No? I think this is the most ‑‑ secure is not the right word, but the most common case what will happen. We all know that most of the customers don't read it and click yes, yes, that's the normal case but anyway you have to do something and it's exactly the point of view how I look to it. You have somewhere to allow the operator that he can see what's happening in your home. Good question
PETER WEHRLE: There's no further question on the Internet. Any further question in the room? Okay. That seems to be not the case. Eric, thanks for your presentation, I think you are still around so if, later on, somebody has a question, you may take a coffee and doing some discussions on those.
ERIC VAN UDEN: Thank you, all.
(Applause)
PETER WEHRLE: We have a few more minutes gained so I want to ask the second presenter, Poonam. Your slides should be there. So you have a little bit more time.
POONAM YADAV: Hello, everyone. Good morning. I am assistant professor at University of York UK. Today I am going to present something we just heard from Eric on Matter and something more related to Matter, this is called Thread Communication and I am going to look at the vulnerability in specifically in some of the communication protocols in IoT.
This is kind of work my team at York is doing and our work at the university is funded by UK RIE PSRC, Department of Science, Innovation and Technology and these different projects.
So, before I will start, I would like to introduce my group, which is called Systron lab, which consists of 15 members at the moment, one of my PhD students did a talk yesterday, he is here, and the focus of our lab is to do systems and networks intra‑operability so we do understand intra‑operability of the systems is quite challenging and sometimes ‑‑ this is not like very creative research from academic point of view, but because we are a system researchers, it's very important to make a system more resilient and robust. And we looked at this from a different perspective, for example communications, Internet architectures, protocols, security and, finally, from machine learning point of view as well.
Specifically when you have a system already and you plug into a new, say new protocol or new machine learning algorithm, what is the impact of that on the network? What is the impact of that on the system security? And that's what we look at.
So going forward, today I am presenting one of our projects called SafetyNet Project and in this project, at the university, we look from different workstreams. One of the core aim is to build security and resilient IoT he can systems and we specifically focus on smart home and home IoT ecosystem. So the first steam in this one, we look at the vulnerability in protocols, for example, Zigbee, Thread, Bluetooth and IoT, even cellular networks. We also investigate at IoT device fingerprinting; for example, identifying devices uniquely or similar kind of devices in the network, without looking at the IP addresses of the packets, so the whole idea is how we can identify IoT devices based on the behaviour of the devices in the network, and when we talk about behaviour, we look at different parameters in the whole networking stack; you start from physical layer, mark layer, networking, application layer and so on, sometimes we join these parameters from different layers and once this fingerprint is created, we can use this fingerprint to defect the abnormal network behaviour of the device then, devices is connected in the network. This abnormal behaviour can be due to various reasons; for example, it could be the case that the device has been attacked and behaving differently or it could be the case device got ‑‑ has some internal problems; for example, it's a faulty or some of the senses or communications chip is not working as appropriate. So, these fingerprints which we create could detect different kinds of attacks.
Another line of direction we look at is prevention of attacks and privacy leakage, we look particularly on this one is can we make a system secure by design and can we incorporate privacy by design? When we look at secure ‑‑ securing the system by design, one of the key particulars which we look in our lab is reducing attacks by deploying MUD which is IETF 8520 standard, MUD is manufacturer user description files and we did quite a lot of work in having a MUD application in the stream where we looked at MUD ecosystem, for example, rule enforcement, IP table was the EBBF, what extensions MUD user interface for accountability and transparency. And other things, for example, how do device or user authentication, authorisation, access controls and encryption.
When we look at privacy, again we look at different techniques, for example, different share privacy distributed learning, anonymisation schemes and authorisations and finally, accountability and transparency.
So now today I am going to talk about Thread. So just before my presentation, I will give you an idea of a Matter protocol. Matter is application layer intra‑operability protocol whereas ‑‑ so if you look at this graph on the top, Matter will sit somewhere here, but we still will be building the whole network underneath which will be networking stack. So, many of our IoT devices these days in our house are having, for example, Zigbee protocols or wireless or something which all these protocols are bit on top of IEEE 80215.4 physical layer and now the question comes here is: How do we include those physical layer into this matter ecosystem? Had so there's ‑‑ now the first question is, Matter, you just heard Matter is IPv6‑based protocol, and because we are bringing in intra‑operability Matter could run on Wi‑Fi, Zigbee or any other protocol, but how do we make sure now, how do we plug or Zigbee‑based network in this whole ecosystem so this is a part of this Matter ecosystem? So that's where the new, protocol which is called Thread, has been introduced in December ‑‑ in July 2014. Thread group was launched before Matter, and with the aim that it provides best Matter for connecting and controlling your IoT devices in home and building. Thread is IPv6 based mesh networking protocol and developed by the same mar, it is CS and industry led technology companies, right now there are 250 industries is backing up this Thread consortium and Matter consortium.
To highlight that, Matter and Thread are still not standards. They are still community‑driven initiatives and bringing this whole ecosystem together, which is run by investees.
So going forward, in market there are already number of commercial devices from different companies; for example, Google. These are the number of devices which are in our Labs which are Thread‑compliant.
The basic characteristics of the Thread network, when it is being built or being designed, that the network should be simple to install or start or to do operations. It should be secure, so there should be inbuilt authorisation encryption at network and application layer. There will be small and it should be applied to both small and large home networks for the large commercial networks and also should allow bidirectional service discovery and connectivity, should provide a larger range as compared to our existing Zigbee or other networks. And one of the main other Entrusting point to note is that Thread should address the single point of failure, so it shouldn't ‑‑ should be designed, the mass protocol should be designed in such a way if a node ‑‑ if a leader fails or the other node in the network take responsibility of that leader and still makes the network connected fully.
It should have, also ‑‑ it should have also immediate to comply with the low power and cost‑effectiveness.
So, now because we have a commercial devices which has a Thread network, Google also released Open Thread, which is an Open Source implementation of a Thread specification which allowed like researchers like us or start‑up companies or other ecosystem to develop Thread‑based products and employ ‑‑ deploy those in a different scenarios.
So if you look at in this figure, it provides what services or functionality Open Thread at the moment supports, that is being ‑‑ that has been part of the Thread specification. So Open Thread implements all Thread networking layers, IPv6, 6 LOW PAN ID, IEEE, Mac security, mesh link establishment, refresh routing and device routes.
So now let's get back to 802.15.4 standard, it seems like it's my favourite one. As I said we already have all these 802‑based 15.4‑based wireless technologies, they are already part of our ecosystem, they are not going to go ahead and we had to retrofit them into the new ecosystem. And because part of this Thread is built on an 802.15.4, the physical layer looks like this. The whole Thread stack is built on this physical and MAC layer.
The physical layer features include standard features which are all aware of like modulation, demodulation, switching between transmitter and receiver, fragmentation, scrambling, interleaving and error connections and codings.
One of the key structure which we call frame control filled in 802.15.4 physical layer is a two‑byte packet size which looks like this: It has a number of fields and why I am showing you this, because this is the ‑‑ this is one of the most important bits we find when we are talking about the vulnerability in our 802.15.4. So, these, I will come back to this in a second.
So, then the ‑‑ at a physical layer, when a packet arrives at a device which is built on 802.15.4 physical layer, the device driver do one of these sequences: Either tell the device that you go in ideal mode, for example, sleep modes or energy saving mode, or you go to the sequence ‑‑ C sequence or transmit sequence or continuous CCA or TR sequence means transmit and receive sequence.
I am not going to go through all of the sequences but I will follow you through one of the sequences, which is called receive sequence, so let's work ‑‑ let me walk you through on this sequence.
So when a packet arrives at the a device, at the frame control field as part of the first it's kind of header in the packet, is received, the driver at the physical layer checks the length of the frame. If it's valid, it verifies the frame type and version.
When the destination address for example, personal area network, ID and addresses matches, it checks whether these addresses are for this particular node. When the entire frame is received, the driver also verifies that CRC and checks that packet and finally, it time stamps the packet after the final bit of that packet is arrived.
So, if all these checks are passed, the driver passes these received frame to the MAC layer and that's how from physical layer to the MAC layer the packet is being transferred.
Now, the issue is, specifically now if you look at the acknowledgements in this system, the MAC layer decides the acknowledgement sequence, what will happen if I receive this packet. So, in this diagram, I am showing how these acknowledgements are handled in Thread. So if in a Thread a peering device and a child device communicating with each other, there could be direct automatic acknowledgement sequence could be figured out; for example, parent can send a data frame to child and child send acknowledgement frame that I have received this packet correctly. However, there's another way of setting these acknowledgements frames, where, instead of directly sending a packet, a child can request a data frame from the parent and if the parent has the data requested for that frame, it sends ‑‑ sorry, if a parent does not have any data for that request, it sends an acknowledgement frame with the frame pending bit is equal to zero, it says that: I don't have a packet which you are requesting. Again, in the future, if a child again requests a frame, and if the parent has a data for that frame, it sends the acknowledgement, yes, I do have a packet, by setting the frame pending bit to 1 and so on the communication keeps going on.
So this parent and child relationship and this acknowledgement exchange in 802.15.4 physical layer is different in both Zigbee or Thread network. So if you are looking at Thread mode, if the driver matches the source address with the in the pending list it sets at zero so it's another check they do so if I am receiving a packet, say, child I know what is the address of a child in my list and I already authorise this child, then only I am sending a frame pending is equal to one, otherwise not.
So what the ‑‑ what do you think what is happening here? What is the problem? You can see, if a child in adversary node which is not part of the ecosystem, say the child here, we start sending request to parent for a data, you can see parent is still sending acknowledgements, and if it's a battery‑powered device, say parent has a battery‑powered device, it keeps sending this acknowledgement every time and draining the power of the device, which is a use‑less traffic, so this ‑‑ this is a very simple process, it should be figured that out, the device, even though the value is frame pending bit is sent as a zero in Thread mode, but it's still a problem, and that's what we were able to exploit in our experiment.
So before I go into the little bit more detail on that, I will a little bit talk about the Thread network architecture.
So, in Thread network we could have a number of roles in the networks so we could have an end devices which are minimal Thread devices, with a list requirement on device the role of resources, and normally configured at device only, we could have a Thread leader, we have a Thread router, which is shown as Orange colour, and we could have a border router. So with all of the border router is is where we are running mic the Matter, basically, because border router connects your Thread or your Zigbee network to the rest of the network which is IPv6‑based network. And you can see here.
As previously I said because of the mesh networking topology, the whole game of the Thread network is to make that there's no single point of failure in the network.
So now one of the questions is, 802.15.4 is a very small ‑‑ supports a very small database, now do we incorporate IPv6 on this, this kind of physical layer? So 6LoWPAN provides a compression mechanism that reduces IPv6 header sizes sent over the air and, there's two RFCs, you can go and read in a little bit more detail if you are interested in how that whole compression mechanism works so we can take IPv6 packet frame the longer ‑‑ IPv6 packet to and compress it in two bytes long header. So RFC4444 and 6282 and that's what Thread does, the Thread using 6 low Panigl to figure out the best header for Thread network.
Let's come back to the Thread network vulnerability, because, like Thread, like Zigbee, wireless, are other 802.15.4‑based, all those vulnerabilities which they had at physical layer, so Thread also have vulnerability at physical layer. So it doesn't matter what you run at the application layer or network layer, how strong your security protocols are, whether you are using authorisation, authentications or intra‑operability protocol like Matter, as long as we are not resolving the issues at physical layer, our networks are still vulnerable.
So, to do some of these tests in our Labs we have semiconductor and silicon laboratories, we use these two types of build our own Thread network. We use Open Thread libraries to install and create the whole Thread network. So, IoT Thread network set‑up that looked like this. We had four Nordic boards and one of the Nordic boards smallest footprint chip we connected with Raspberry Pi to make it as a Boarder router. You can see in the Orange you have an open sniffer from Sewio Open Sniffer, to inject packets in the network to create an attack and another Nordic Board we use as a sniffer just to observe the network, what is happening in the network.
So, when we create IoT Thread network, the new device, when we connect in a network, has to go through a new device commissioning process. So, for example, here, the blue dot shows, say, this is a new device, you would like to connect to already existing network. It exchanges the DTLS sessions with external commissioner. So there are different ways to Commission. You can use a CLI based tool or you can use an application. In our system we use a mobile apps which was provided by Open Thread community, to Commission a device. Every device for this commissioning needed a unique extended unique identifier so that's where you can see the bar code which we created, we took the identifier off the devices and then we created a bar code for that devices. So now in the next I will show, this is a mobile which also we downloaded ‑‑ which is also supported by Open Thread community, which allows you to select a border router and enter the paraphrase, it's like a key which is ‑‑ which is unique to the network for the security and you scan the QR code of the new device. When this shows you runs the join command on the device and wait for the join process to complete and device is added. So this is the ‑‑ a one‑way of connecting a new device into the network but there are other matters like ‑‑ you can do that as well.
So, this is our new test‑bed which looks like this. Now in new test we are both Silicon boards and Nordic boards joined together as Thread network. So first of the device here is full ‑‑ configured as full Thread devices and also which device acts as a leader and router. The other four ‑‑ five devices are minimal Thread devices and act as end devices. A magnetic frame which makes our life quite easy to ‑‑ for network topology.
One of the things is Silicon Board community has provided a very good tools and SD K to do the experiment and research on Open Thread and all kind of research in that direction. So, they have a tool called Thread Topology Monitor System, which allows you to even observe your network topology at a given time. To run the topology monitor you need a Nordic Board so we were running this Thread topology monitor on one of the Nordic Boards so this keeps sending many messages to the rest of all the devices in the network, it's ‑‑ and keeping all the devices and getting the response from them and in a realtime you can see how my topology looks like.
So to create an attack, because we needed something, a sniffer, to see what is happening in the network, we use OpenSniffer from SEWIO, can scan the wireless channels in that particular area. So for Thread network we operated channel, you can see we selected all the four bands like 780 band, 868, 915 and 2400 and we ‑‑ after few seconds, this device was able to tell us which channel my Thread network is sending aspects on.
So, we figured out most of the time my Thread network is sending a packet on, say, channel number 15. Now, with the OpenSniffer, we are we were able to capture one of these packets and then reconfigure and descend that packet in the network from a third devices which was not part of the network at all, and we could see, this is the same attack that the device where we are sending a packet which was part of the network, keep replying to these newly message as acknowledgement message. Here we can see packet number 11 is ‑‑ is being acknowledged, which was a replay packet from a non‑authorised IoT device.
So it comes from that, yes, acknowledgements are still going on. So what we did, we configured some of these Nordic Board with the batteries and we tried to run this attack for like two hours, with the back‑end scripts and we could see that battery drainage happens quite quickly. That ‑‑ because we were not very efficiently doing the power measurements like I'm not very confident that I can present that as a result today but I can confirm that that has happened, right now most of our Boards are already plugged on power so we could not experimentally show the drainage that happens on power boards.
So that was the replay attack. We thought maybe let's do another experiment on this network. Here, we ‑‑ we took a normal packet so you can see a packet of 32 bytes here, a random packet. We, using a Python script library ‑‑ a Python script provided by a library, we were able to replicate and run that, resending that packet again in the network for a little bit longer time and with the spacing of one millisecond, and what we saw after that, we could come from that using even a spectrum analyser that these packets were going in a channel, for example, number 15 and the interfacing between these different packets is one millisecond in between and what we could see after few milliseconds, instead of having the full networking stack as you see the whole Thread network, all of the nodes which were empty D nodes were disappeared, they were not responding to the network, and this happened within a few, like in one or two seconds, so it didn't took longer time to do this attack. So it was not even a replay attack; it was just identifying which channel your Thread network is currently working on and just bombarding the network with traffic on that channel.
So now this let us do a little bit investigation a bit more which we are currently doing so we are still investigating is it a CS M kind of error problem or is it a network drowning problem because if we look from acknowledgement point of view, generally it takes around one ‑‑ 69 micro seconds for ‑‑ from a point when a packet arrives in node and that node sends an acknowledgement but here in this experiment we were sending packets after every one millisecond so we assumed there was sufficient time for a node to reply to the acknowledgement, but these packets are still dropped because they are not valid packets. So this graph just shows that after few seconds when we were just doing a sniffing of the network we could only see the packets which we were playing in the network but nothing from our Thread network because Thread networks don't really stop working and not doing anything in the network. So these are quite primarily result and it's like ‑‑ we are still investigating a little bit more on this direction but I hope you learned a bit from this presentation and find it useful.
As I said, there are a couple of directions we are investigating on this one. If you would like to follow our work, our development, GitHub is Thread edge test‑bed and our previous version demo, which is recorded, which is showing step by step of this whole attack, are will be found on our GitHub dot Systron lab/Thread battery attack, which was recorded by one of my students and we also presented this this demo earlier this year.
Thank you so much for listening. Any questions, I'm happy to take now. I would like to say thank you to my team, my colleagues, Anthony and Peter and my previous students who did quit a lot of work in this direction, and all my funders for sponsoring this research. Thank you so much.
(Applause)
PETER WEHRLE: Thank you, I have one question from the Net, Peter Steinhauser is online but he has problems to come in, he wanted to look to the calls on line, I might read it out on the question, from Michael Richardson: 802.15.4, networks are usually encrypted as Layer 2. Did you OpenSniffer need to know that Layer 2 endescription key?
POONAM YADAV: That's a very good question. No, at the moment OpenSniffer was just doing at physical layer framing so it was not looking at Layer 2 and it does not need to know the Layer 2 encryption. Anyone has any other questions?
PETER WEHRLE: No other question on the Net as I see it. No question in the room? Thanks for your presentation, you are still around so your first RIPE in in person here.
(Applause)
Okay, so I will probably directly hand over to Jad for the last presentation on the schedule today.
JAD EL CHAM: As a non‑native English speaker I always feel nervous when I have to present at 12 because I am not sure what kind of greeting should I use, good morning, good afternoon, etc. Being the sensible engineer I am in 2024, I did what everybody might do in this situation and I asked ChatGPT. According to ChatGPT, we have to be neutral and I can say: Good day everyone, my name is Jad El Cham, I work as senior public policy adviser at the RIPE NCC and today I am going to present an update on the IoT situation, or as the French might say (in French).
Unlike the two previous presenters I walk a lot and I was told that can be distracting so I apologise in advance if me moving allot distracts you.
The first section would cover IoT trends, these are things I have noticed in the last couple of years, trends related to connectivity and the IoT data itself and we will touch base a little bit on IoT security here.
The second section we will be covering the IoT regulations in 2024 so we will see that the policy makers and the regulators have been quite busy lately and there are quite a few pieces of legislations that would be touching on the IoT ecosystem in one way or another.
And then finally, we ‑‑ I would like to get the opinion of the Working Group members about possible opportunities for learning and development.
So, let's start. This section will be quick, a little bit of IoT trends, we will start with the IoT connectivity stuff.
So, for a while, we had the sense that not much had been happening in the IoT connectivity scene. Typically, when we talk about cellular IoT specifically, there are different types of categories there. So we might be talking about massive IoT where we need lots of devices, usually that requires not a lot of data rates. So typically we had connectivity options like LTE M which were both considered for GM and that served the purpose. But as we started moving into other category of IoT devices so we talk about critical IoT, we talk about industrial IoT or we talk about broadband IoT, then these devices required not necessarily high density capacity but more throughout, and typically, we could have served that using one of two things: Either the LTE Category 1 through 4 or if we had 5G deployments we had to go through layer C next releases.
So, I am going to put this a little bit to the side and go through the points that I have mentioned here.
So one of the things that we have been seeing more and more happening in the last couple of years is the introduction of satellite connectivity within the IoT ecosystem, whether it is for local blackholing or to ensure global IoT services. So now we see more and more providers, we see more and more advancements talking about hybrid, terrestrial networks and non‑terrestrial networks. We also see a trend going through the pushing IoT deployments within private cellular networks so that usually happens for specialised IoT deployments, let's say certain agriculture firms in very rural areas or let's say we have an industrial plant that requires very low latency, very high data throughouts so we see more and more private cellular opportunities there and typically either of these two options the use of global satellite connectivity or the private cellular networks it had been impoured by the increased adoption by IoT manufacturers of technologies or appropriate provisioning solutions so we are talking about the EYCC or the integrated EYCC.
Now I would like to circle back to the 5G advances. And during the last two years, mainly, the three GP P had released 17 and 18 being finalised. I believe we release ‑‑ had their code freeze in Q2, 2022 and release 18 had their code freeze now in 2024.
So, what they brought to the table is a new category of connectivity within 5G and that is the red cap. Red cap stands for reduced capacity. So, while, before, the type of connectivity for IoT that I mentioned earlier where we had acquired potentially higher throughout, either we had the option to do it through LTE to 4 or we had to go for a full fleshed 5G new radio infrastructure. And that meant that the device complexity, the device cost was very high in 5G, with the introduction of the release 17 and release 18 red cap, now we can have IoT devices with a complexity reduction of somewhere between 50 to 65%.
So, and typically, by all estimates, that would be around 60% of the IoT devices by the end of 2028.
So, with this whole movement, we see more and more optimisation of the 5G options for IoT connectivity, coupled with non‑terrestrial options, in order to deploy globally available IoT solutions.
So, this is what I saw in the last couple of years when it comes to IoT connectivity. Now, there are some trends when it comes to the IoT data side of things, and it wouldn't be a technical conference in 2024 if we don't mention the magic two letters, AI. So we see a lot of AI or L L M being used to treat the data, to filter the data, to do an analysis of the data, so in all major conferences, a big part of the work that has to do with IoT data is trying today to explore how AI can fit in this space.
More specifically, given that we have more through‑put powers so we have ‑‑ we have IoT devices being able to generate a lot of data, and instead of pushing all of this data to the Cloud, the topic of edge computing is becoming or more specifically in the IoT case, what we refer to as edge IoT, where we can treat the data closer to the device, and this had been, if you want, expedited by the introduction of AI. So now we hear about video cameras with embedded AI inside them or they can treat the frames, relay the needed information or not, etc. So, I expect to see more and more advancements in that space and that also leads to the last topic that I have mentioned here, which is the digital twinge.
Through the twinning) that I have been fold through the works I have been seeing and some of the initiatives and the reports that I have read, it seems that the digital twinning is an excellent use case for the use of AI ‑‑ the use of IoT. A Mackenzie report expected digital twinning it would be increasing every now between now and 2028 with a potential market of 75 billion dollars so a lot of IoT data handlers are looking ‑‑ are investing more into the whole digital twinning space. We see there are ‑‑ we see it quite active in the ‑ space, in the industrial space, we see more and more governments moving in that space, I live in Dubai, the government over there they went into a full scale digital twin of the whole city in order to test and model things.
Now, before moving to the second section, I just want to add a couple of notes related to the use of AI, in the IoT ecosystem and that's from a cyber security perspective. So there are three things we consider when we say we are using AI and security so AI can help the network operators or the service providers to try to mitigate cyber security threats. We all know that BOTs are being smarter and the pattern of the attacks are changing so arguably AI can help us understand and mitigate and react faster to these attacks. So that's the first component when it comes to AI and security.
But AI can also be used by the adversaries and the malicious entities in order to mount smarter attacks so that's the other side of the coin.
And third note that should be considered going in the future, when we are saying that we have stuff like edge AI and we have AI computing, all of these data, the AI itself can be compromised, either the model or the data that feeds inside the AI. And you know the model, garbage in, garbage out. So this I would like to move to the second section, which is IoT regulations in 2024:
In a nutshell, I try to put things in perspective and these are, more or less, the pieces of legislations that I believe we should be interested in and looking at during 2024. I try to limit myself to the EU, the US and the UK, there are a lot of other pieces of legislations in other places of the world; for example, Singapore is introducing cyber security labelling scheme for IoT devices, there are some stuff happening in the Middle East between the UAE and Saudi Arabia. But what I am going to talk about here, briefly, is some of these, and these mainly are EU predominantly, a little bit of UK and a little bit of US.
Now, keep in mind that these are things that are relevant in 2024. I mean, either they have been voted on in 2024 or recently voted on and will take effect in 2024. There are some other pieces of legislation that still apply to the IoT world like for example the EU Cyber Security Act that was, I think, in 2019, or, for example, the US Cyber Security improvement act that was enacted in 2020. They are still in effect but I will not be talking about these.
So, I decided to choose three of these in order to talk a little bit more about them. I will not be going into details of them. If you'd like, we can talk more during the breaks. I also have RIPE NCC colleagues, like Desiree or Roman that follow these legislations very closely.
The first one is NIS directive 2. Last week, there was the telecom and digital infrastructure Cyber Security forum in Helsinki, and I can tell you that the NIS 2 was used like, was said more than 100 times. So it's the big thing, right? You might be familiar with the NIS directive that was issued back in the days; well, NIS directive 2 is here to broaden the scope of the entities and the sectors that falls under the NIS directive. All right? So it introduces the necessary structure and procedures for cyber crisis management. So it defines what are the thresholds of the security incidence that happen so at what point should they start reporting and to whom do they report? And this applies to either essential entities or important entities. Now, how they define these, it can either be through a sector, like let's say utility companies would fall under /SAEPBS entities, digital service provides might fall under important entities or they have a certain classification based on the size and revenue of the companies. For example, what they consider as essential entities in terms of size, could be 250 employees and up and you know revenues of around €50 million or so.
But the important ‑‑ the interesting part here is that NIS 2 is not a law per se; it's a directive, and the Member States of the EU, they have up until 17th October 2024, to create national legislations that would cater for the NIS 2. And each Member State has the possibility to decide on their own as well, what to include as an essential entity or what to include as an important entity so digital service providers or what they might refer to as critical infrastructure so let's say you are running an IoT solution for smart metring or plant automation or utility management, whatever the case is,ing they might fall under the critical infrastructure and you will have to be follow these specific regulations.
Now, it also introduced some very frameworks, very strict frameworks for reporting and compliance. So that's NIS 2.
The second one that I wanted to report on is EU cyber resilience act and a lot of people think that this is the biggest move in EU regulations since GDPR. It's usually ‑‑ it is coupled with the EU Cyber Security Act but while the Cyber Security Act introduces more full on programmes or frameworks, the cyber resilience act proposes legal obligations to ensure high level of Cyber Security across the whole EU, and the scope touches everything that has a digital element, whether it's hardware‑based, software‑based or plainly defined as an IoT device, wearable either it's statically connected or not, to the Internet.
The regulations, it follows the whole lifecycle, from the design phase all the way to hitting the market, all the way to maintaining it, making security patches available, but also disposing it and end‑of‑service and end of support for it.
Non‑compliance will be penalised and they are introducing, I think, a fine of around €10 million or 2% of, like, a company's worldwide revenue, if they fail to comply with this.
Now, who are affected by the cyber resilience act? It's the manufacturers, the distributors, the importers and the retailers of such digital products, so in a nutshell, they are trying to cover the whole supply chain for the IoT, for the IoT devices. And this most likely is focused on the consumer side of things.
When it comes to time frames, the European Parliament approved it in March 2024 so we should start seeing more updates for this really, really soon.
Now, the third piece of legislation is the UK product security and telecom infrastructure act, we had ‑‑ so basically, it covers Internet ‑‑ covers three categories of devices: Either internet connectible products, network connectible products or computer input products and what they cover here are the, what is labelled as UK consumer product. So per se, the products that are used for business to business things do not fall under this legislation, unless the same product can be used by consumers.
Also, they enforce some sorts of management of the whole life cycle of these consumer devices and failure to comply will come with hefty penalties, either protocol recalls, fines of up to £10 million or 10% of the worldwide revenues. Who does it apply to? Manufacturers, importers and distributors.
What is the time frame for that? Took effect as of 29th April 2024.
Some of the things they would like to see here they don't want to have devices with default passwords on the market, they want consumers when they buy the devices to be able to have access to information as on how long the product will be supported, so it should be clear from the point of sale so this device will be supported at least for the next five years, and it also requires from the manufacturers and distributors to have disclosures of vulnerabilities or security incidents or, for example, if there are patches or not, if these patches will be automatic or not etc.
So, I also believe there are three other pieces of legislations that we should keep an eye on. The first one is the EU Cyber Security certification scheme. So you might be aware that within the EU space, there's a programme that tries to certify different things? So Cyber Security, labelling scheme. There was a vote that was supposed to take place in April 2024 but it was shelved a little bit till May 2024, and it relates to the Cyber Security of Cloud services. Now, while this might not affect directly the IoT product themselves, but as we realise today, a lot of the back ends, the servers, the servers that ingest the data or manages the devices, the IoT devices themselves, they live in the Cloud itself. So, arguably, this will have an effect on the Cloud providers that host the IoT back ends and the brains of the IoT solutions.
The second thing is the US cyber trust mark, so the FCC actually voted on this in March 2024, it will come in effect a little bit later on in approximate this year, so what they define as voluntary Cyber Security labelling programme for wireless consumer Internet of things, products. So just like back in the days when we used to go to our favourite electronic shop and get a router and say this is Wi‑Fi aliance or whatever the case is, they will have a new label there which is called the US cyber trust mark, they are proposing also to include a QR code where the consumer can scan it and will get easily understandable information about the status of the test, conducted on these devices, whether there are vulnerabilities or not, how long it will be supported, whether they should be doing regular updates themselves or the security updates would be pushed automatically to the devices, etc., etc. So again, that's a voluntary Cyber Security label but the idea is that hopefully this incentivises the manufacturers to all moves towards this labelling programme and, hence, you know, improve the status of security for everyone in the market.
They count on public and private collaborations, there will be certified Labs where they test the different devices.
And finally, you might be aware of the radio equipment directive in the EU. There is not ‑‑ sorry, not amendments but there's something called red Article 3.3 that talks about Cyber Security of the digitally connected components that have radio equipment inside that. It was supposed to be enforced in 2024 but that was postponed until August 2025 because the scope upon which like the number of products, the categories of products that it covers, it's quite large, so basically, anything with a radio equipment which nowadays can be everything, has to follow under red Article 3.3. Specifically, there are three parts: Article 3.3D that talks about improving the network protection, so about the radio interface itself, making sure it's compliant, it doesn't cause disruptions, etc.; Article 3.3 E, talks about strengthening the personal data and privacy protection so talks more about the devices themselves and there's Article 3.3 F, that covers the devices that are used more specifically to handle transactional data like financial transactional data and here they try to reduce the risk of fraud so stuff like authentication, proper authentication and these kind of things.
So this concludes the IoT regulation landscape for 2024. And that brings me to the last section for today, and that's IoT capacity building.
And a small trip down memory lane: This topic was first brought back at RIPE 84 Berlin and so I asked the room whether you think that the RIPE NCC should develop some learning and development material, whether it is training courses or webinars or one‑off workshops related to IoT topics?
I can say that I received mixed feed backs. So to put in politically correct context. Some people were in favour of this, some people were not in favour of this, some people did not speak directly in the room but later reached out to me on private basis. There was a little bit of discussion on the mailing list following this, some people proposed that RIPE NCC join forces with other organisations that talk about IoT security etc., etc. But nothing really materialised out of this discussion.
But between then and now, there are two surveys that were conducted by the RIPE NCC; one of them was the 2023 member survey, hopefully everybody in the room had access to the survey and included their answers and in both of these surveys there was a question related to training activities. So what kind of training topics what kind of training engagements in would bring value to you in?
In the first survey, the first one here on the slide where we received 3518 answers, 22% of them did report that they would like to see something in IoT because it is important for their jobs, for their operations or for other reasons. And within a smaller survey that was conducted by the learning and development department at the RIPE NCC, in Q4, 2022, out of 250 responses, 28% of them said that they see value in this. So, based on this, maybe ‑ if I can get it ‑ second time is ‑‑ sorry. Ah. Second time is a charm, maybe.
So, I would like to solicit input from the Working Group, either right now, later on, on the mailing list, do you think there is a need for the RIPE NCC, specifically the learning and development department, to tackle topics related to IoT? We know, for example, that in 2021, this Working Group published a BCOP document related to architectural security design considerations for IoT, for home IoT devices. But maybe it could be a webinar related around that, it could be an awareness activity related to that. I know in 2023 there was a request on mailing list about possible BCOP document on Thread and Matter but, you know, this is not finalised yet.
So, I will leave it here. And any questions, feedbacks, complaints, ideas, we are open.
(Applause)
PETER STEINHAUSER: Good day from my side as well, I hope you can hear me. I think we should start with the questions from the you had an audience.
NIALL O'REILLY: RIPE vice‑chair and for me, good morning. I haven't had lunch yet so it must still be morning. But a small point of information: Since the participation in the Working Group isn't restricted to RIPE NCC members, not everybody in the room would necessarily have access to the RIPE NCC member survey. And there may well be interest in the kind of learning and development initiatives that you are talking about among the broader RIPE community, you might consider whether it could be made more available, more widely available.
JAD EL CHAM: The surveys or the offerings?
NIALL O'REILLY: The offerings.
JAD EL CHAM: Yes, we did consider this. For example, what we gave at the RIPE NCC, this is not only for our members ‑‑
NIALL O'REILLY: Good, good, we don't need to take up lots of meeting time ‑‑
JAD EL CHAM: Something we are actively considering and trying to see how we can manage our resources to do. Good point.
PETER STEINHAUSER: We also have a question in the Q&A section from Maarten Botterman, he was asking regarding trends: What is happening to minimise the carbon footprint, is this already generally considered in the design process today, both energy used, material used and longevity, usability of devices?
JAD EL CHAM: Good question. I can provide a partial answer to this. So, for example, one of the incentives to introduce the red cap connectivity options for ‑‑ within the release 17 and 18, is that it allows to have the same peak rates but at the lower energy consumption ratio so maybe in that regards this is more geared towards sustainability. Unfortunately, I don't have much, how can I say, insights on how to reduce the Net footprint, like the carbon within the IoT connectivity space itself.
PETER STEINHAUSER: Thank you very much.
PETER WEHRLE: I don't see any further question in the room. Thank you again for linking it back to the NCC work.
(Applause)
Coming to the last agenda point, I want to be quick. So we are about to ask for new co‑chair here in the session and so we have David Schweizer, Peter Steinhauser and we have Andre, and I want to give the opportunity to David, he is here in the room, to have a small greeting and if you could manage to keep Andre and after the micro after to David just to make him visible and we want to close the round.
There's a question on the ‑‑
JIM REID: One of the founding co‑chairs of this Working Group, some years ago. I have had some private conversations with yourself and with your cocoa co‑chair, Peter. I am very concerned about this development because first of all we decide things by consensus and the use of a Meetecho poll seems to be a violation in the way in which we do could chair selection in this Working Group and I don't like the idea of using votes. This is discriminatory because you discriminate people who will not able to use Meetecho, if we were using the mailing list it's open to everybody and I am strongly against what's being done here and I am very, very surprised this has been allowed to happen.
PETER WEHRLE: Thanks for that input. I have another input and I may answer ‑‑
MARTIN WINTER: Speaking as a co‑chair from the Open Source Working Group. I strongly open to the mailing list version and if you don't know why attend Working Group tomorrow what happened in our case last time.
PETER WEHRLE: I was not much activity as I joined the group, so then it was very hard to get election done on the group. So this time we tried to just use participation in the room, so other selections in the room itself made the vote so maybe that is not ‑‑ not the end of the evolution of finding a good way forward but it's balancing all of the things.
JIM REID: We have an election procedure, appointment procedure is documented and that seems to be, decide things by consensus, I don't understand why we have deviated from that. Whether we decide things using mailing list or not is neither here nor there, we make decisions by consensus, this smells of making decisions by votes and I think I think that's very wrong because it limits the participation. If we decide things using the mailing list it's open to everybody. By doing this with Meetecho, you limit it to the people in the room or can open up a Meetecho client and there are people other than that have some kind of say in what's being done and that's being denied to them because of the way you have chosen to do this and I don't remember anything being announced on this mailing list to say that's how we are going to do this, I think something has gone very badly wrong here.
PETER WEHRLE: Thanks, noted. So I published it in the mailing list quite beforehand in terms of ‑‑ 7th of April on ‑‑ the candidates had a chance to also put their input into the mailing list and there was some echo from the mailing list and so there was choice to get it done on Meetecho, so that is the way we are collecting it now. So I'm happy to take it forward so we have tomorrow also, a session with Mirjam directly, we meet as Working Group chairs and see the different ways we did it and the experience and to develop it further.
Maybe I will just give David a quick chance to say hello.
David: I am currently working for Network Device Education Foundation, and I am a person who is really interested in IoT devices, I really like to play around with hardware and I try also to meddle around with the firmware of all the devices I own, it's really kind of a personal interest I have in all things considered when it comes to device security and the data protection and, for example, the use of privacy for the end users of those devices.
If you have any questions for me, you can either meet me in the hallway later or maybe if we have the time, we are slightly over time, you can ask them now.
PETER WEHRLE: Okay, thank you, and Andrey.
ANDREI: I am following RIPE meeting from the very beginning and I am the director of IoT association in Russia and basically, NGO who is doing different things in IoT field, it's like everything from the devices to the applications, security, API integration and all that stuff. I actually wrote my little bio an e‑mail and just echo this meeting and the previous very interesting and very compressed report, I should add, that what I think about the Working Group is that there should be some balance between the what we call the human IoT, the IoT for the people, and the industrial IoT which is about 50% money‑wise, worldwide, so 50% generated by people, 50% by the industrial, and I think that in the group, there must be some practical focus on some of the industrial cases, including security, including the digital integration, as it was already said in the part of it because IEG plays a significant role, some very interesting development in the ‑ family of the protocol for the transportation and self‑driving cars. There is a whole world of labelling addressing resolution for the IoT devices and datasets, it's a whole world which also can be covered in the Working Group. So, it's a lot of things, actually, to do if you take the industrial part of it, it's verticals, like agricultural which I personally really like and I enjoy having a lot of experience in agricultural and IoT, but transportation, logistics, satellites, so that's a whole world of the IoT which can be discovered in the Working Group, in the norm of like little pitches about the case, particular case, problems, address the ‑‑ address problems, address resolutions, the experience and things like that, just to make it more fun, because if there is no fun, I mean, what is the reason of it? That's my position actually for the group. Thank you.
PETER WEHRLE: Thank you, Andrey. So, I think the vote is now coming down to close or that is to collect just opinion from the group. So, I want to thank you for all the participants and also to say you are not need to be a Chair to contribute to the group, especially the Chair has some facility tasks but the main drive‑through comes from you, participants, so there's no ‑‑ please don't hesitate if you have any points and as we have now three candidates, maybe two will not get co‑chair but that should not block you from doing any work within the group and then get things forward.
That's ‑‑
NIALL O'REILLY: There's one small detail that I have missed, perhaps because I wasn't paying attention and everybody else in the room knows the answer, but just for clarification how many vacancies are there?
PETER WEHRLE: So there's one co‑chair so the end ‑‑ at the end of Peter Steinhauser's role and we are looking for a new one. We have three candidates for one place. So that is ‑‑ the candidates again we announced the way we are doing it on the mailing list on 7th April and there was plenty room of doing a discussion and it was the one rule which we applied.
NIALL O'REILLY: Thanks for clarifying.
PETER WEHRLE: I think we can close the counting. Does anybody have a direct look to the results? So is it now that what I see in Meetecho, so can somebody ‑‑ sorry, I am not that experienced ‑‑ okay, so I have ‑‑ is it possible to have it on‑line here ‑‑ good. So, playing with the latest technologies, so we have eight supports for Peter, we have three for Andrei and one for David, so, Peter, you are continuously running the Working Group, together with me, and if you are looking for next slot, so my term is now, in the middle of the term, so in one year's time there's another chance to come in. And again, Peter, Andrei, please do not hesitate to put your work into the group and share your thoughts. Thank you very much.
PETER STEINHAUSER: Thank you very much for all the attendees and a quick comment on Jim's remarks. I think we should take it very, very seriously and I agree absolutely that the discussion about the selection procedure should have better handed on the mailing list, I agree with Jim, it's the Working Group's decision how to do this process, so we really have to take this very, very seriously. And Jim, my apologies, for not doing things the right way. Thanks, everybody.
PETER WEHRLE: Okay, thanks. So, I am closing ‑‑
JIM REID: Just another remark on this. Peter there's no need to apologise just doesn't make sure, if the Working Group was to change in the way it wanted to appoint its co‑chairs it's perfectly free to do that, we need to get consensus for new appointment mechanism, so I have no strong feelings about how the Working Group wants to do this thing because it's time for old farts like me to step into the background and leave it to the next generation to take over, it has to be probably discussed and worked out in advance rather than just being imposed on us the way it has been this time. I have no strong feelings how you want to do it in the future, when we have got a procedure, we should be sticking with it until we feel it needs to be changed.
PETER WEHRLE: Thanks from your feedback. So we learn from the feedback. So the impression from my side was cheering in the room and you look for applause, may not be the right way of doing it, so involving also the remote participant, so we will have Working Group meeting tomorrow which then looks into the aspect and the ideas from the various groups and we will definitely evolve from this. Thanks also for your feedback and if there's any ideas, please also share with the full group so we can all develop together.
Thanks so much. Sorry for running out. I hope the queue on the lunch is not that long any more so then you can grab your lunch directly and thanks for your participation.
(Applause)
LIVE CAPTIONING BY AOIFE DOWNES, RPR
DUBLIN, IRELAND
