RIPE 82
.
IoT Working Group
.
20 May 2021
.
1:00 (UTC plus 2)
CONSTANZE DIETRICH: Hi everyone. It is so not nice to not see you again. It's good to not hear anybody sneeze or cough or breathe. Anyway I'm still very happy to be here and, first of all, want to thank all the people that are persistently and successfully making these meetings happen, despite the obstacles we currently still have.
.
And with that, welcome to the IoT Working Group session. Sandoche and I have prepared a cute little agenda for you, starring housekeeping, as well as announcing who is going to share that screen space with me the next time around.
.
Then we have arranged for two talks.
.
Afterwards, I'd like to present a few results of the IoT Working Group survey and start a discussion which I hope will have to be continued on SpacialChat afterwards but I really don't know what I was thinking when I reserved only ten minutes for that whole thing.
.
Anyway, housekeeping.
.
Here is all the information you need. So, out of order, you can use the group chat to communicate with other participants which you can see in the participants list. If you want to ask a question to the presenter, you can do that by using the Q&A window and have Sandoche handle the talking part or you can use the audio queue and if you want also share your webcam video. That said, be aware that the session is being recorded and will be published on RIPE 82 archives, together with the chat logs, by the way, so please be nice to each other and especially to our speakers.
.
All right. If you could state your name and your affiliation if not otherwise indicated, that would be great.
.
I am going to show you a little preview of what the RIPE 83 slides are going to look like. Why? What?
.
Working Group consensus on the list was that Sandoche shall remain co‑chair of the IoT Working Group. Congratulations, Sandoche.
SANDOCHE BALAKRICHENAN: Thank you. As I mentioned earlier, I stood for the second time because I thought that the things that we wanted to happen at IoT is not complete. Even though it is not complete, I could say that I have been ‑‑ participated at the first IoT hackathon team and also preparing the RIPE IoT BCOP document, so thank you, everybody, for having me the second time. Thank you.
CONSTANZE DIETRICH: And also thanks to Peter Steinhaeuser for standing, I think it's really cool to see that engagement.
.
And on that note, both Peter and Sandoche, as well as Eliot Lear, Michael Richardson, Phil Stanhope, Jelte Jansen and Jan Zorz also deserve a shout‑out on the work for IoT device security in the home, which, meanwhile, has been published under the RIPE 759. It's a document that, as the world changes, is likely going to be edited or extended once in a while, and I suggest that if you haven't already, to have a look.
.
Okay. You have about ten seconds to applaud for them now while I give everything up to our speaker. Said.
SAID JAWAD SAIDI: Okay. Can you hear me? So I think there is an issue with my sharing. Let's use the pre‑uploaded slides.
.
Thanks a lot, Constanze and Sandoche, I am very happy to be here. Hi, IoT and the RIPE community. Today, I am going to present our work on scalability detection of IoT devices in the wild, and this was a joint work with Northeastern University, and all the names are down here on the slide.
.
I would be very happy to have your feedback and comments as well.
.
So, we all know that IoT devices are very popular these days, and also there is a lot of security issues has been reported by them; for example, the ‑ attack, and also you know that these devices are cheap and so there are some security issues with the cheap devices that come into play, and the question is, okay, so with all these problems, we are curious can we identify and locate devices in our networks?
.
And so we had this problem can be studied in different environments. And we had a collaboration with a large European ISP, and we took this challenge and thought how can we perform these tasks? And the question is, why should we do it it in the first place and where can we use this ‑‑ where can this be used in the context of ISP? So it has multiple benefits. For example, this can ‑‑ as an opt‑in service for ISPs can be used for the benefit of the customer. For example, if one of the devices gets infected or is compromised and participate in large attacks, or we can notify the customers about it. And also, if for example a device is, again, participating in an attack or a compromise and a security issue with it, we can go ahead and find what other subscribers of an ISP might have the same issues.
.
There has been work that shows that an aftermath of UI attack, ISPs engaged in the notifying customers by a variety of means from sending e‑mail, calling them, even they went to the extent of redirecting their traffic to this page and telling them, hey, you have an infected device at home, please do something about it.
.
So ‑‑ but, in any case, if you want to perform an IoT detection at the scale of a provider is not an easy task, because, as we said, there are a lot of different type of devices and there were some works that suggested that we could perform ‑‑ we should deploy some scanner or agent inside the ‑ of each customer and start scanning, but this is not scalable and it's very privacy‑intrusive and we have to make sure that we don't breach the privacy of our users.
.
There is active measurements, if we want to send probes and see what devices at home. It won't work, especially when the devices are behind the NAT and also cannot do the packet inspection to perform this because of, first of all, the privacy concern and also the scale and the amount of data that we have.
.
This asks the questions that which customers can be used? So we have providers are already collecting NetFlow captures, or flow capture, each of the flow capture data for their other operational purposes. And but this data also sampled ‑‑ they don't have payload and they contain only the headers.
.
So, the question is can we use these data sources or can we detect IoT devices using limited, passive and sparsely sampled flow data? At what granularities can we do that? And how fast can we detect IoT devices? And how are IoT devices deployed today as observed in the flow data?
.
The key insights of our work is that devices that we have studied showed repeating patterns of communication that appear even in sampled flow data.
.
And the detection rules, we generated patterns.
.
And detection that can use these limited fields to detect devices and of the studied devices we were able to generate patterns and also apply these patterns that resulted in the detection of 77% of study IoT manufacturers in a large ISP and European IXP.
.
So how do we perform that? The key insight of our work is that, here, we have an ISP and this ISP, or service provider, has different customers and each customer has ‑‑ may or may not have some devices. And this device, in order to provide their services, they have to communicate with certain backend infrastructure in the Internet, or servers. And we said, okay, if we focus on the destinations and contacted by these IoT devices ‑‑ which subscriber has which I‑path device.
.
Next, I am just going to quickly outline our methodology which contains five parts.
.
First we had to generate IoT traffic that ‑‑ and then we have to check whether we can see even the traffic of a single IoT device from a single vantage point in the net flow ‑‑ or at the ISP level, and then, after that, we had to generate, or use features that we saw in the IoT traffic, for example domains, IP addresses and port numbers, to detect some patterns, and to generate some patterns, and the detection rules, and also, we had to check ‑‑ cross‑check with the detection rules to make sure that we are not ‑‑ we are actually able to detect our devices even at our vantage point. And also, we applied this detection rules on the devices, the net flow data have the ISP.
.
Okay, so the first step was generating traffic. And how did we generate this? So we set up two testbeds and 56 IoT products from 40 vendors. And they were these six different categories and we triggered these devices in two ways: By setting an idle experiment and active experiment. In the idle experiment, the devices were simply connected to the Internet, and in the active experiments we programmed them to interact with devices in an automated fashion, for example by asking Alexa device or Amazon Echo device what is the capital of Italy or what is the time of the day and so on. It depends on the functionality of the devices.
.
And we ‑‑ during this experiments, we connected our labs to a home vantage point inside the parameters of ISP, and then captured the IoT traffic across a home vantage point and also at different locations in the ISP.
.
Next, we went ahead and we wanted to see, okay, can we see even a single ‑‑ traffic from a single device, from a single vantage point or not. The answer is yes. During here, the Y axis, you see number of devices detected within Jabber and X axis shows the duration of the different experiments we conducted. We are comparing the number of devices active or observable at home, and number of devices observable in sample flow data. And we detected that from what is the secure person devices and detect activity at this level as at least observing at least one packet from them that goes to or comes from the device.
.
Okay. And how can we generate pattern or find other subscribers that might have the same ‑‑ that might host the same type of devices? So one approach is, okay, I have the ground truth IoT traffic, and each device talks to different IP addresses over different ports.
.
And I want to generate detection rules or pattern for each device. So, I just look at the same traffic and look for the same destinations in the network data and say okay, number 1, that is this type of device, and number 2 has this type of device.
.
This will result in a specification.
.
Then there is the partial coverage, and because the IP addresses that we saw in the ground flow or lab traffic are incomplete and you might not see all the IP addresses contacted by the devices, and this is destination IP addresses that were contacted might change over time.
.
And we also ‑‑ there is a chance ‑‑ there is chance that we confuse the non‑IoT traffic that we see in the NetFlow data with the IP traffic. Because the IP addresses might belong to some generic services and domains like NetFlix or something.
.
And also, some of these IP addresses go to shared infrastructure such as CDNs where these are contacted by a wide range of services, or users, not only devices but human activity also is included in those ‑‑ or human activities is also included in this data.
.
So how can we handle this issue?
.
We use passive DNS data to ‑‑ and since we only had the lab traffic we know the domains, so we started with the domains sorted by each device and find out what type of domains, for example, that this device belongs to generic infrastructure or is it belonged to shared CDN and also using the same passive DNS data to find other IP addresses associated with the domain. And we remove the domains and also subsequently all live addresses that belong to shared or generic infrastructure and then generate the patterns for each device.
.
We did check that we can apply these rules ‑‑ apply the rules on our own dataset to see how many of the devices can be detected. But in the interests of time, I will skip that part and show ‑‑ show what kind of routes were detected, I will show the result of our methodology and ISP data.
.
In the route generator, we had three levels of granularity. One was the product level. In the product level routes, we could only see ‑‑ this is the final granularity, and to say what type of device are we seeing, is it an Amazon Echo or was it TV or not?
.
At the manufacturer level, we cannot say the type of the product but we can see to which manufacturer does it belong and at the platform level we can only say it's a generic IoT device. We cannot comment on the manufacturer nor the product level.
.
And overall, theses account for 77% of the manufacturers in our testbeds.
.
What happens if we apply this methodology ‑‑ or these patterns in the data from ISP?
.
Here, what we see again, the result of applying or methodology. In the Y axis, we see number of unique subscribers per hour. In the X axis, we see the duration of the data that we consider and each point shows the number of unique subscribers that have the specified IoT device by looking on only one hour of NetFlow data. And we started with Samsung IoT and Alexa because they were the most popular ones in our dataset, and what we see here is between ‑‑ by looking at even one hour of data, we were able to infer the presence of more than 1 million subscribers depending on Alexa‑enabled devices. Alexa‑enabled device is a device that responds to Alexa voice service command.
We also observed some other patterns, and for Alexa and Samsung‑enabled devices.
.
What happens if we look ‑‑ or we take into consideration more or longer duration? And here, we have again the same plot as we had earlier, but in order to decide whether the subscriber has one device or not, we take ‑‑ we look into at least 24 hours, at most 24 hours of data for that given subscriber. And what you see here is a number status stable and there is not a lot of valuations here and you see that increasing observation period had detected even more devices. There is ‑‑ one reason is that this these devices talk to their destination domains at different rates.
.
And overall, we detected that it was more than 20% of our subscribers.
.
If we zoom in on the 32 IoT devices that I showed you in the previous plot, we see here, on the X axis, the number of ‑‑ or each device. And in the Y axis, each device. In the X axis, again the date, and each box shows that how many devices detected on that date or how many subscribers to that device was detected at that date. We grouped them into the device that went to Amazon, the country of ISP and see what is its ranking? Amazon, basically, in Amazon marketplace. We see here we saw some correlation between the device popularity and the devices that were popular that were in the top 10 or top 100 in ISP in Amazon and that also popular in our dataset. For those we couldn't find any ranking we put them in the other category. And for some of them, we saw the handful of devices in the dataset as well.
.
And in the end, our methodology has its own limitations. So, there are a lot of ‑‑ so some limitations aren't here, if the device relies only on shared infrastructure. Since we don't have access to DNS data, we only have access to the header information. We won't be able to detect that device.
.
If we want to generate detection rules and patterns for the device, you need to study that device and if the domain name is contacted by the device's change, it will also be not easy for us to notice that.
.
And detection of devices with a small activity, we have defences that were not activated ‑‑ that were very small activity, for example, smart plugs and these devices are only ‑‑ mostly generate their traffic when they have ‑‑ when we are triggered. And in that sense, we won't be able to see all of them.
.
And with that, I want to conclude here, that we show the methodology to detect IoT devices based on limited, sampled flow data.
.
These devices, they are rules that we generated account for more than 77% of the studied IoT manufacturers in our testbeds.
.
We detected around 4 million subscribers with at least multiple devices that were in the both popular and not popular categories.
.
If you are interested in the patterns that we have generated, you can go to this link, or you can scan this QR code and have a look into our patterns that we have generated, and if you have any further questions, you can reach me on these addresses.
.
In fact, I would be happy to take questions.
SANDOCHE BALAKRICHENAN: Thank you. We do have some questions in the Q&A session. I will start from the first. It is from Patrik Tarpey from Ofcom:
.
"Do you observe any use of encrypted DNS resolvers for IoT traffic?"
SAID JAWAD SAIDI: At least in the dataset that we have, in the devices that we have, the devices they were not ‑‑ they didn't use encrypted DNS resolvers. And of course, there will be an issue here, and for example if someone wants to ‑‑ okay, let me put it this way: If someone wants to apply our methodology using only ‑‑ or caption the DNS for this, that would be very good. As you said, if the users are going to require encrypted DNS resolvers, then it would be hard for the service providers to know what their devices are in their network.
SANDOCHE BALAKRICHENAN: Okay. The next question is from Jacques Latour from CIRA:
.
"It's curious to see if you run a report to look at which country the IoT device connects to."
SAID JAWAD SAIDI: Very interesting questions. My collaborators had previous work, and you can ‑‑ just by changing the URLs to IMC 19, they have shown the countries that these devices talk to and they are changing or connecting to different ISPs will impact the set of infrastructure that these devices might talk to. So, yes, there are some destinations that are outside Europe and also going even back to China and Taiwan that these devices are talking to. Yes. We observed that.
SANDOCHE BALAKRICHENAN: Okay. Thank you. We have Marco Hogewoning from RIPE NCC, he had multiple questions. I will give you all and then you can respond as you wish:
"In analysis, did you consider the impact of NATs, also local ones, or are you able to give an estimate how NATs would impact your methodology by bundling multiple devices behind a small set of addresses and ports?
.
Subsequently, he also asks: How would IPv6 eruption impact this result?
SAID JAWAD SAIDI: Very good question. Impact of NAT if we don't have carrier grade NAT in our service provider. If there is a carrier grade NAT, then there would be a problem.
.
And second is that if ‑‑ what is the impact ‑‑ how NAT would impact our methodology. So if, for example, we had multiple devices of the same type behind the NATed interface then our methodology won't be able to detect ‑‑ or if we have any stronger signal, then it would be easier to detect them, but we won't be able to say okay, that if there are three of these devices or four of these devices. In this sense, the numbers that we have reported are only lower bound, not the upper bound, so there might be more and this is the impact of NAT in that ‑‑ on our methodology.
.
And looking at the sort of how would IPv6 impact this research? I'm not sure that how it ‑‑ thinking off the top of my head, it won't negatively impact it, because it might at some ‑‑ when I I think it might even help because there would be NAT and then we can even detect at a better granularity, a finer granularity you can say, okay, now the subscriber is not only a single IP address and assuming that the NAT will be gone away at the subscriber's boundary, each device will have its own IPv6, global IPv6, then it would be easier for us to dissect it.
SANDOCHE BALAKRICHENAN: Thank you. Constanze, I will let you introduce the second presenter.
ANNA MARIA: I have also something to add about the questions about the NATs. Actually ‑‑ first of all, hello everyone, I am ‑‑ I am also did this work with Jawad. Thank you for the presentation. So the NATs, the usage of NATs doesn't impact anything in our work, it was like for creating this tool what we do is we look at the destinations, so that the addresses of these devices are contacting, so the usage of NATs won't impact anything and the usage of IPv6, as Jawad said, it would be even better for our research, because, I mean, the methodology will remain the same but we will have more addresses to use exclusively for the destinations that these devices are contacting. That's all.
SANDOCHE BALAKRICHENAN: Thank you.
CONSTANZE DIETRICH: Thanks, Anna Maria. Looking at the time, I would right now go quickly over to Natasha.
NATASHA D'SOUZA: Hi. I am going to just try and share my screen and see how that goes. Okay. So I'm here to talk to you about the implementation of IoT SAFE using a registry. So we, at CIRA, have worked on a really interesting project that focuses on leveraging eSIMs today to extend the use of our registry.
.
I am just trying to get my slides to move.
.
So, our future Internet is evolving. Today, it's just a bunch of web pages and websites that you can access. Our future is really smart, smart cities, autonomous vehicles, smart energy, and a lot of this technology will be 5‑ or 6G‑based but as well as have eSIMs on them. The role of the registry will expand to not only support what we are supporting today, but as well as supporting these things in the future.
.
So, our IoT registry project is really geared towards extending the use of our registry and supporting the Internet in that realm.
.
So, today, with our Internet, we could do a few things with our registry, and that is you can switch between Internet provider, so if you want to switch between GoDaddy and WIX, you can do that easily. If you are a coffee shop owner and you share your business, you can transfer open source of your domains to the new owner as well. So, we're taking these same concepts to the future. Today, a lot of our IoT devices are based on walled gardens and, in order for the world of IoT to scale, we really need that to have generic providers.
.
So, for example, in our smart city, you have got our smart meter, you can you can change your providers from Parko Serve to Car Park Serve. You can also transfer open source between different cities, for example. And the third thing that we're going to be able to do is transfer between mobile operators, so, in Canada, for example, you could transfer been TELUS and Bell.
.
And that is something that will ‑‑ is similar in concept to what we have today with your registry, but we'd like to take that into the world of IoT, so we can move away from the walled garden.
.
What are the standards that we have started to will leverage for this is the GSMA IoT SAFE. So all the GSMA has the end‑to‑end and consumer spec. IoT SAFE really brings the whole ecosystem together. It brings the device manufacturers, it brings their service providers together, and provides a way for everyone, or talk to each other in a secure manner.
.
At the root of this, we are leveraging an eSIM as a robust scaleable hardware router trust and what we're really trying to do in this scenario is create a chain of trust within the ecosystem.
.
So, what is different about this SIM versus any other SIM?
.
This SIM has the GSMA IoT SAFE applet on it, and what it does is, it enables this eSIM to act as a crypto safe, where is can generate key pairs, it can verify signatures and publish a public key. At the end of the day, this is super important because what we're trying to do is create a secure TLS connection.
.
So, this is what our registry looks like. You can see that we have got our DNSSEC, we have got our certificate authority, and we have got the server middleware and APIs. In northbound, it talks to the application service provider. So this is the provider in the Cloud for the service. For this phase, we have used Solace as our MQTT broker, and our mobile operator is TELUS and that's using the equipment to provide the Cloud OTA, to provide the APIs, as well as the safe module.
.
So this save module is what talks to the safe applet on the eSIM. We have a cellular module in here, and the IoT device has the device middleware.
.
So we submitted this project where we partnered up with TELUS and Solace to provide a platform for medical devices to continue their innovation.
.
So, one of the challenges that we had with this project is the middleware, which is why Zero provided the middleware, and part of what needs to happen is that some of these need to be part of the Open SSL standards. So that's why we provided the middleware. However, going forward, it's going to be up to the IoT manufacturer to decide what they are going to do with this middleware and, you know, are they going to be Raspberry Pi‑based or Arduino‑based.
.
So that's ‑‑ the way this works is when an IoT device is powered up on a network, so for example, if it's a tech at the hospital checking to make sure the heart monitoring work or if it's a tech out in the field installing a parking meter or it's an actuator on a nuclear plant, the first time it's powered up it's got this eSIM on it so it's going to make contact with the closest cell tower, and try and establish a connection with the correct mobile operator. So what happens is, the customer will send the EIDs of this device, or eSIM, to the CRR registry, which, in turn, will pass that to the IoT security server, which, in turn, will pass it to the IoT device, and what it does is it tells the mobile operator: Hey, you need to establish connection with this IoT device that has EID 0050, for example.
.
So once that connection has been established, the IoT SAFE or the eSIM, the applet, will now send ‑‑ publish the public private key peer. The private key always stays on the eSIM. It does not get published publicly at all, but it's the hash of the public key that is transferred.
.
So this information, in turn, is sent back to the registry that adds all the appropriate certs to it, and then will send the information to the applications service provider and to Solace so that this TLS connection is established.
.
So that is basically, from a technical perspective, how this registry works. And so, in a nutshell, what the registry does, it provides the user or the customer the capability to register their IoT device to activate the IoT device, to transfer it and to deactivate it as well as delete it, So, for example, in the MedTech accelerator that we participated in, some of the companies said we no longer want ‑‑ we have done our development but we don't want to consider down this path at the moment and so we're able to just go into our registry and delete those EIDs.
.
So, this is really important in the context of IoT devices, because if you start to think about it, there is millions of IoT devices out there in the future, and we're going to have some of them end of life‑d, some of them hacked, so there is got to be a way to very quickly and easily deactivate these IoT devices and take them out of the network quickly and easily. As well as once they are no longer used, you can delete them from the system.
.
So, that's kind of what we did with our IoT registry, and we are continuing to do our development with this.
.
So some of the questions that we have are: Where do we go with this? Because if Zero says, hey, we're going to have this registry and it's going to be for Canada only, does this mean other ccTLDs do the same? So, should every ccTLD operate their own IoT registry? How can we have more open source code that supports the Dane ‑‑ Danish DNSSEC validation on mutual TLS connections? How should the inter‑registry registration activity be trusted? So, you know, if the answer is every ccTLD operates their own registry, then does one registry talk to another?
.
So, is the trust in operating a ccTLD leverageable to operate an IoT registry?
.
And then how do we differentiate the IoT registry from current hard‑coded locked‑in major Cloud provider solutions?
.
So, you know, we have built enough of this registry, we have, you know, validated the standard, we have taken it a step further and actually used it in a real life MedTech platform.
.
However, going forward, here are some of the questions that we need the broader community to answer, or debate, in order for us ‑‑ well, not just us to move forward, not from so much a technical perspective but just an adoption perspective.
.
That's it. I think I am here to answer some questions.
SANDOCHE BALAKRICHENAN: Thank you, Natasha, a very good presentation. We have some questions already in the Q&A session. The first one is from Eliot Lear from Cisco:
.
"Natasha, great presentation. Interested in the specific middleware challenges you ran into at the SSL level. They also ran into some as well as relating to ESTNCSR attributes."
NATASHA D'SOUZA: What are the challenges we have? You know, so there were the practicalities in that we had a timeline and we had to build enough to get to work. But at the same time, you know, part of the middleware challenge is that this is not part of the Open SSL standard. So, we had to use a goal anc as a wrapper just to get this working and to set up that by directional TLS connection. It is a short‑term solution to ‑‑ in order to get this registry working. However, long term, GSMA is working with some of the Open SSL groups. You know, we'd be happy to take this offline. It's a pretty in‑depth discussion, so we'll be happy to take this offline and discuss it.
SANDOCHE BALAKRICHENAN: Okay. The next one is from Carsten Schiefner. He asks:
"I have not a fully understood the concept of moving IoT services from one provider to the other which is in your slide 5. As it appears predominantly, it currently is one distinct service per provider, other than with domains where the service can easily transfer from one registrar to the other."
NATASHA D'SOUZA: So, you know, in an enterprise situation or in industry in general, you know, when some technology has been adopted, there is always the push for cost savings. And so the challenge that organisations have is: Hey, we have tried this technology, we have used it, but now we need to have a cost savings. And so today with our IoT devices, the challenge that we have is that they are in walled gardens, so if you design ‑‑ if you have your IoT device and you use some of the big Cloud provider today, you're pretty much locked in, as a vendor and as a customer. You have no other options. But in the future for it to scale. It's kind of like the Internet, when the Internet was hard‑coded, we couldn't scale. We are now at millions and billions of domains because of this transferability and that flexibility.
.
So, in order for IoT and smart cities or any of these things to happen in scale, it's really having this flexibility. So, if I'm a parking meter, for example, and I'm leveraging Parko Serve, which is a Cloud provider, and as an IT department we have to reduce our cost, but hey logic, Car Park Serve is giving us this fabulous deal for our Cloud services. Car Park serve also provide Cloud services for parking meters, and so it's the parking meters that are generic and have that interoperability and so you will be able to transfer between these parties.
.
So, we don't have full transfer working today because we just started with the MedTech platform. However, we have part of our transfer working in the sense that, in order to transfer, you have to deactivate and then you have to change your port and your URL or FQDN and then reactivate it again. It's not a complex thing to do. At the end of the day, you are just changing end points. What is more complex to do, which is the outside of the scope of our registry, it's really with the Cloud providers being inter‑operable from that context, and as well as from the IoT devices.
SANDOCHE BALAKRICHENAN: We have three more questions and we have three minutes. So I will stop the Q&A line.
.
The next one is from Florian Streibelt:
.
"Great work. I wonder what the thread something are? Would it be possible, for example, to disable all IoT devices on a country level in case of conflicts between states, e.g. sanctions?"
NATASHA D'SOUZA: I would say that is very similar to shutting down of all the domains in a country. So, with this registry, you'd be able to fairly quickly to deactivate these IoT devices. So, by deactivation is, you are shutting down that secure TLS connection, right. So, there is a mechanism ‑‑ you know, there is a theoretical mechanism to do that.
SANDOCHE BALAKRICHENAN: The next one is from David Schweizer, NetDEF:
.
"How does technology impact secondhand sold devices? Can devices be reactivated without the registry that is after the vendor stops offering services for it?"
NATASHA D'SOUZA: So, that is a good question. You know, it's a level of detail that we have to work all the way through. But from our thinking or where our implementation today, where we're at, is that you can ‑‑ the IoT device will have this eSIM that has a public/private key on it, right, and so it's through passing of this public /private key to our system in what we call the registry payload, you are able to really say: Hey, this device is who they say they are. So when you deactivate it and delete it from the registry, that public /private key is no longer there, right. Like, it's ‑‑ that is what we call the hardware router trust.
.
So, from a theoretical perspective, if something is end of life‑d or it goes into the recycling market, it would most likely have to be reactivated again.
.
However, we'd have to actually test this out for that use case, but, based on what we have today, we believe you should be able to do that.
SANDOCHE BALAKRICHENAN: And the final question, Swaathi Vetrivel from TU Delft: Again, great presentation.
.
"Can you touch upon the visibility of large‑scale eruption of this model in country‑marked devices, they tend to be more plug, play and forget."
CONSTANZE DIETRICH: Sorry for interrupting, but I would really like to present the few results of the survey we have, but I suggest that you take that to SpacialChat afterwards, to the coffee break area, to discuss that further, because I believe all our speakers are actually planning to be there.
SANDOCHE BALAKRICHENAN: Okay.
NATASHA D'SOUZA: Look forward to the discussion. Thank you for having me.
SANDOCHE BALAKRICHENAN: Thank you.
CONSTANZE DIETRICH: If you see nothing, that's good. So, a few of you might remember from the last meeting since, let's face it, the IoT Working Group isn't the biggest party amongst the mailing lists and since we couldn't meet and mingle at RIPE meetings, etc., the idea was to send out a survey to find out what we, as Chairs, should do with the Working Group. So, that was done, and basically kicked off the new year with it. The survey got 16 responses, 11 of which came from mailing list subscribers, two of which never attended a physical RIPE meeting. Looking at 16 respondents, I am afraid that's about the full extent to which any quantitative analysis makes any sense. That said, you guys are old. Just kidding, and I would really like to hear you laugh now.
.
One of the first questions was: What do people view as the Internet of Things? To be honest, it was a bit expected. So, for some, it's anything with an IP address focusing on Internet connectivity, for others it's mostly about the lack of classical interfaces, clearly putting the emphasis on a devices function without human interaction or with unusual human interaction. Some explicitly point out the things talking to things part over some kind of API, any network basically. For a few, it's just the security threat with reliability maintenance.
.
I might be wrong here, but maybe we should discuss after all whether we, as part of RIPE, should try to define this for ourselves and where we maybe put the emphasis on. Moreover, we also asked the people that are not subscribed to the mailing list, why that is? And it turns out 80% didn't know it exists, which is why I am going to put the URL to subscribe on every slide now.
.
Also, there seemed to be some insecurity about how this whole working group thing works in the first place, both amongst new members and as well as members to be and so explaining that might be something I'd like to tackle next.
.
So, while the non‑subscribers seemed happy with what we do, there was indeed some feedback on what we should do more or less of, what we should start doing, keep doing, or stop doing. And one thing I'd like to mention first, or rather quote, is: "I think that despite some extensive efforts to set the Charter, it still isn't exactly clear why the Working Group exists other than a general feeling of we should be doing something."
.
Considering the reasons we sent out that survey, I think that one takes the biscuit, because looking at other responses, I have to say there is quite some bandwidth between wanting us to be a source of credible technical information on an accessible level and being a source of advice on how to regulate IoT as an industrial sector.
.
So, if you are not sure what to think about for the next two minutes, make it that and let us know about your thoughts, please.
.
So, what else was there? There was a general wish from our communication feedback and discussion, and let me just say here, I feel you, and I hope that whatever we do next, that's going to be a natural consequence. Then also a collaboration was a thing I read in between the lines a few times implicitly pointing toward other Working Groups within and outside of RIPE.
.
As you can see, security is still very present, as that pretty much is the one topic that we talk about all the time, and I guess I need to mention that our respondents seemed to miss the focus on network operators and also would like to see some recommendations specifically for ISPs.
.
And we also ‑‑ we should also try to include operators that operate large‑scale IoT networks, and as an entry to the question that was added within the response, I happen to know they exist at RIPE and I am already working on it. That said, if anybody feels called upon here, really, please just say 'hi' sometime because that ties in quite well well with what we apparently should do less of, which is home assistance stuff, although I have also seen kind of opposing opinions on that one.
.
So, this is just a pretty small excerpt of the responses for now because I want to lose two sentences on how it was to look at the spreadsheet for quite some time.
.
To be honest, I was surprised to look at a huge variety of background, both professionally and personally, and also a huge variety of interests. And what actually tended to stick little pins into my screen to connect the cells. And that was both pretty cool, but also reminded me again why we really need those physical meetings, and maybe, for now, as cheesy as it may sound, also some kind of 'hi, my name is...' introductory posts for new members on the mailing lists, that would be nice.
.
So, to conclude, as the immediate next step, it would be really nice to have some kind of ‑‑ some sense of purpose, and also some kind of coordinated roadmap for the next meeting. And with that, I am looking forward to your feedback now. Anyone in the queue, maybe? Sandoche, are you operating the audio queue?
SANDOCHE BALAKRICHENAN: Yeah. Just a minute. There were people asking to send video, but I don't know ‑‑ so there is a question from Peter Koch:
"The survey is still open. Are you considering future responses?"
CONSTANZE DIETRICH: Absolutely.
DANIEL KARRENBERG: Hi. A couple of things. Thanks for the survey and thanks for asking the questions. I think, if I remember it correctly in the genesis of this Working Group, one big concern was that we, as a group of sort of classical ISPs, saw that the operation of sort of IoT things was using our services, basically lots of IoT stuff uses the Internet and we wanted to give an interface for the people sort of using us and using the servers of the ISPs to talk to us and give us their requirement and basically talk operational stuff so that we know that there would be less surprises and better results for everyone. And I think that should be at least part of the Charter.
.
One thing that I heard you say, oh, there should be an introduction on what the Working Group does. Well, that's the Charter. So, I think I would suggest that the group really works on finalising the Charter and then it will be clear for everyone what the group is proposing to do, and when you have the Charter you can also look at the work plan, you know, stuff that, you know, roadmap, whatever you call it. So I think work on the Charter and put in the interface between classical ISPs and IoT deployment. Thank you.
CONSTANZE DIETRICH: Thanks, Daniel.
The coffee break area, I don't know what the policy is these days for running late.
SPEAKER: Hi. Everybody, good afternoon. Good morning to those in America. I just want to thank you Constanze and Sandoche for their work here, and thank you to Constanze for conducting the survey. I want to make one general point and I'll use the slide that's on the screen to make it.
.
Where it says less of home assistant security stuff. The reason that you saw a BCOP come out along the lines of home security was that we saw a role for service providers to play here. That is to say, there is a consumer aspect ‑‑ consumers need to be represented, consumers need guidance, help, easy interfaces to make simple decisions about the devices that are on their network and the ISP is a natural player in that space because we have the relationships with consumers already, and so that leads to this Charter discussion that Daniel mentioned.
.
It seems to me that the work that needs to be done in this space needs to relate directly to what the RIPE community can have influence over, and that is to say the role of ‑‑ primarily, the role of service providers, and indirectly the role of consumers, the role of IoT gear, even the role of industrial, and, by way of example, right, we just saw a huge break‑in in the United States involving a pipeline that took down good portions of the southern economy, at least for brief moments, in the United States, and that was due to a failure on the part of how the pipeline was ‑‑ how remote access was being used by the pipeline management. And so one question that I think we can ask is: What is the role of the service provider in facilitating and helping industrial users in terms of ‑‑ inasmuch as they are at all connected to the Internet, and they have to be connected to the Internet in the last year due to Covid, because people will continue to work from home ‑‑ they continued to work from home, but there were no ‑‑ people needed help finding best practices, some didn't, and we had failures like this. So as we go into this discussion about the Charter, we should be thinking about questions that service providers can address.
.
Anyway, thanks for the time.
CONSTANZE DIETRICH: Thanks, Eliot. So, again, we're going to take this into the coffee break area. Thanks to Said and Natasha for the interesting presentations. Please rate the presentations, everyone, who is still here and participating.
.
And have a nice rest of the evening ‑‑ rest of the meeting. Bye‑bye.
SANDOCHE BALAKRICHENAN: Thank you, Constanze. Bye.
.
(Coffee break)
