IoT Working Group session
.
29 October 2020
.
2 p.m. CET
CONSTANZE DIETRICH: Shall we start? It's two o'clock. Hi everyone, it's good to see you, I guess. You look a little small up here from the stage, I suppose. Yeah, so, welcome to the IoT session at RIPE 81. I am Constanze Dietrich, I am here together with Sandoche Balakrichenan, we are the co‑chairs of the IoT Working Group, and we have some exciting stuff for you today, I hope.
.
For one, of course, the introduction. Then Marco will give us an update on what's been happening or been interesting at the RIPE NCC IoT‑wise.
.
And also, we will have Peter Steinhaeuser talk about the very first document that's been introduced in the IoT Working Group at the moment.
But first of all, housekeeping.
.
I suppose you have all seen the slide many times in the past days. However, I am going to repeat the content of it a bit.
.
So ‑‑ you have various ways to participate in the session. For one, you can ask questions at the end of the talk by using the audio queue, just queue up there and just read or ask your question out loud. And please state your name and affiliation so we know where you are coming from and who you are.
.
You can also use, during the session, the Q&A section, that's the little question‑mark over there under your name probably where you can just type your questions.
.
However, there is also a chat. Please make sure that if you have questions, you put them in the Q&A session and not like in the Q&A session and not in the chat.
.
The notes or the stenography is also available on Meetecho and please be aware that the session is being recorded, so if you choose to ask your question out loud, you are going to be recorded as well.
.
And then I have another announcement. It's a survey, because apparently that's what I do. The thing is that now, due to Corona and also because maybe we're still a quite young Working Group, the Working Group has been rather quiet, at least on the mailing list, and we would like to change that.
.
However, the IoT Working Group has a very broad charter, which is good, we don't want to change that. However, we would like to know a bit about what is interesting for you, so what concerns you about the IoT, what kind of topics would you like to see being discussed on the mailing list or during the IoT session. What else would you like to see happening? Like, would you like to have another hackathon like we had a year ago, or also what kind of deliverables we should aim for? Who we should talk to, what we should look into, etc. So that's what the survey is for. It's not only for people who are already subscribed to the mailing list but also people who are generally interested in the IoT. So we're going to send the survey to the IoT mailing list as well as the general mailing list.
.
That's it from me. Now, we are going to have Marco talk about the RIPE NCC IoT update.
MARCO HOGEWONING: I will. Thank you, Constanze. If you can relinquish your screen, I can start mine.
CONSTANZE DIETRICH: I am not quite sure how I do that ‑‑ there we go.
MARCO HOGEWONING: Thank you. Good afternoon, good morning, good evening, everybody. I am Marco, I work for the RIPE NCC, and I am going to talk a bit about what we see in public policy developments. Now, before I steam off and I don't have much time, but this is a very EU‑focused presentation that's not entirely deliberately or maybe it is because it provides a nice few concrete examples of what we see happening here. Rest assured, we are also checking what's happening in the non‑EU member states. This is, after all, a global space, this is a global problem.
.
So, there is things going on, for instance, in Council of Europe looking into artificial intelligence. The OECD is doing similar stuff, also looking into data‑sharing. Of course we see elements of this come back in IETF, we see elements of this coming back in ITU, so, rest assured, even if you are not in the EU, this probably, sooner or later, will find its way to you.
Also, if not only because the EU as a trade block, of course, has significant impact on the global market space, especially when you start looking into market access, the question like can this device actually be sold in this country?
.
That's of course where they will have an impact.
.
So, two things that I flagged before in this group and just to give you a quick update. So you might recall from RIPE 77, already a long time ago, that I talked a bit about the radio equipment directive, and the way that the red has kind of two place holders where additional security requirements can be brought in and the EU calls that delegated acts.
.
The idea there, of course, is that pretty much every IoT device has a radio on board so any requirement that you push into the radio equipment will automatically apply to all these devices. It's a relatively low‑hanging fruit from a policy perspective.
So where are we at these days? There was an impact assessment study published not so long ago, like April or May. If you download the slides, I hope this link actually works, you can click on it, you'll find it's a 250‑page report, it's rather long, but it's also quite a good read.
.
For instance, it provides a really nice gap analysis of all the legal frameworks and how they could interact with this space. Also, then, as it identified anything that's important for the discussion was that it actually says okay, right now, it's rather difficult to push a misbehaving IoT device from the market.
.
Now, if a device does it wrong privacy‑wise, you might have chance of a GDPR, then you can only select times on it, you can't walk into a shop and say, sorry, you can't sell this any more. So that's one of the key items that might be addressed with the radio equipment directive.
.
Also, no surprise there, it says like a regulatory approach was the most effective.
.
The report then contains a lot of recommendations, I have highlighted a few that I think are most relevant. It says that activate the delegated acts on both articles, that's a bit of a technical argument, but one of them is specific to security and safety. The other one is very specific about fraud. So, it says, like, okay, better to do both just to cover all your tracks.
.
Same there, that it concludes that, yeah, better just connect all the connected devices, or scope all the connected devices.
.
The question that remains in the report is that you do them sort of one category at a time. This originally started by looking at wearables, smart watches, toys, or do we just do it all in $1 go?
.
The other thing then is that it recommends that the European Standard Organisations, the ESO, gets a mandate to develop some harmonised standards, what is it that we want these devices to do or what is it that we don't want these device to say do. That sounds a bit scary at first, do we need yet another standard? But luckily it also very much emphasises that you should make use of what's already there. So don't reinvent the wheel. Take existing standards, take existing best practice and use that, where possible.
.
So, it also very much in that that's an explicit call further down for the industry to share good practice. So, looking forward in the agenda, the document that this group is producing might actually help there, it might actually be contributing to this discussion.
Just to summarise, it's moving slowly, it will ‑‑ but the main goal here is to have something that you can basically say, like, okay, if your device does do X or Z or actually it doesn't do X, Y, Z, we can ban it from the market. So you can essentially not sell it here, and that's an important addition that you would get from that.
.
Further down, ePrivacy, and again really, really high level, really short. My colleague Suzanne recently published a nice little article on RIPE Labs talking about EU legislation that talks about ePrivacy, so just to take it in the context of the IoT.
.
This is an effort to update, rewrite the 2002 directive, rewrite it into a regulation, so it also gets a bit of a higher standard and status that is effective immediately.
.
Mostly, also to align it with GDPR. The European view there is that these kind of go hand in hand. GDPR, of course, talks about data privacy. This one talks a bit more about how this would work in the electronical space, but the idea is to make sure that it aligns with the terms and definitions of the GDPR and, where possible, references the GDPR.
.
Now, this has been going on for quite a while. This started in 2017. Right now, where we are, the member states still have to agree on a unified position. Again, a bit of a European technicality in the way the legislation works.
.
The Commission proposes something, the Member States and Council have to agree on a position, parliament have to agree on a position, propose amendments and then these three work in what's called the trial log to come to a conclusion and find the final version.
.
At this stage, and of course it's around the corner, we're not expecting those negotiations to start before 2021, so best guess this will come into law and applicable 2022, 2023, probably, even.
.
But the potential for impact is quite big, it's not specific on IoT, but then it refers to what they say electronic communication networks, electronic communication services. It also as I said, it's a regulation, it's quite a big thing, similar as so GDPR. So, whenever your IoT uses an electronic service or an electronic network, it probably has to apply or comply with the rules in this regulation.
.
Of course, the benefit there, for instance, it protects the confidentiality, but the drawback obviously is that it might mean that you have to be compliant to this regulation. So even if you are designing now, probably good to keep an eye out and see what it's about and make sure that you don't got any surprises once this is finally agreed.
.
Very quickly then, because I already have to stop. The pipeline, what else is there? Well, we don't see a lot of discussions about the IoT. What you usually see is what is essentially the component part of IoT. As I said in my opening, there is a lot about safety and ethics, about artificial intelligence on these days that will have an impact on what you do in your daily job.
.
Another big thing in Europe but also in other countries is cross‑border data flows where data is stored, for instance. Like I said, this is not ‑‑ you saw my presentation hopefully by my colleague Max earlier on. For instance, Russia is quite specific on how these things are handled.
.
Another big one, 5G.
.
Usually the argument is like, oh, yeah, but with 5G we can do X, Y, Z, or if we want to do X, Y, Z we need 5G, so be it spectrum or any other aspect, you often see 5G and IoT go hand in hand, so this is also pretty important to keep an eye out for what's happening in that space.
.
Specific legislation, again a bit of a focus on what we see happening in the European Commission around the European space. That's what I call the European data strategy, and one of the things there is a focus on business‑to‑business data‑sharing and, as they put it, you should try it on co‑generated industrial data. Now, it's all a bit vague what that would be or how that would be defined, but yeah, our industry also generates a lot of data as we go along in NetFlow, etc., so probably get ‑‑ a good one to keep an eye out on what's happening there.
.
And finally, then, again, it seems a bit far off, the NIS directive, and of course this is very recently connected but we are going to a review process, it's two years old, and part of that was a survey question and, in that survey, was there, like, is there a need for common cyber security for connected products? It goes in the same direction of where the radio directive is already deployed.
SANDOCHE BALAKRICHENAN: I think we are out of time.
MARCO HOGEWONING: Good. Because I am done.
CONSTANZE DIETRICH: I am conscious we don't have any more time left for questions, but I suggest that you meet in the SpatialChat to discuss a few things, like Michael Richardson had a question. Let's just meet there today and talk during the dinner for example.
MARCO HOGEWONING: I'll get back to you Michael. Thank you.
SANDOCHE BALAKRICHENAN: The next presentation will be by the IoT BCOP task force. Actually, this work was initiated by Jim Reid in RIPE 79. It's a small group of people, eight people, who have worked from RIPE 80 until now. So, I will let Peter do the presentation. And one important thing is that, during the course of this presentation, there will be a survey and there will be four questions asked. Each survey is sequential so after each survey, there will be four minutes, so I will ask all the participants to respond. And finally if possible, we can give you a snapshot.
Waiting for Peter. Do you think Peter, should I ‑‑ if you have issues, should I share the screen? .
PETER STIENHAUSER: I hope everybody can see what I am presenting.
.
So, here we go. So, good morning, good afternoon, good evening everybody, in whatever time zone you are. I think we discuss IoT security many, many times and the major purpose is of not turning one of your IoT minions into something like that, what you see at the bottom of the screen, so that's what we want to prevent.
.
So, after Michael Richardson's excellent presentation about IoT lifecycles and RIPE 79, Jim Reid reached out to a couple of the members of the IoT Working Group to form a BCOP task force how we called it, so just to list them, so it's Sandoche, Jelte, Jan, Elliott, Lear, Jim Reid, Michael Richardson, Phil Stanhope, myself and Jan Zorz. And the goal was to create a BCOP document what are best practices for IoT devices. So, the motivation I think, is pretty obvious. So we have a radically growing number of IoT devices, and, despite the many discussions and warnings about the recent years, the majority of the devices still has to be considered to be very unsecure.
.
We have many standards and technologies related to IoT devices security, but, I mean, practically most of the manufacturers simply don't care because it's completely price‑driven.
.
So, while there is progress on IoT standards and regulatory activities and the future will be better, it's not evenly distributed yet. And we always need mitigation of legacy.
.
So taking the situation into account, I mean, we all see that regulators are working on the issue that we will see regulation in the future, and there might be pressure from the market. That's not really helping us on the short run.
.
So, we were considering to look at things a little bit differently. So, what we have when we are dealing with IoT devices themselves, we are dealing with a countless number of device makers. Also, on the regulatory side, as I said, it's going to take time to define the rules and specially faster and most of those devices are added to networks, I mean that's just the facts we are facing.
.
So, inside the group and also I think coming from the focus of some of the group members in their daily work, we are thinking about just shifting the view from the IoT devices themselves to what's connecting the home users network with all those devices to the Internet, so it's the CPE or the home gateway. I mean, already today, it's the gate keeper for the customer to the Internet, and it can be used to prevent unwanted traffic north and south bound, I mean even west and westbound but that's not the scope of our work yet. And it can even help organise the consumer's internal network, for instance, in using VLANs etc. So the technology is there. And that was the reason for the group to say okay, let's focus on the home gateway and the CPE instead.
.
So, talking about a BCOP task force in the beginning, actually this is not a BCOP document.
.
From what we found, the home gateways or the CPEs are rarely dealing especially with IoT devices. They are a little bit out of scope. So, it seems for the majority of the carriers and ISPs, there is not really a focus for the work or for the products and services. And so we came to the conclusion, but I mean everybody can prove us wrong, and we would be happy about that, that there are actually no current practices for home gateways CPEs at all, so I mean, if there are no current practices, cannot create a best practices document for sure.
.
So, I mean, while we hope that the contents of this document would be helpful and maybe become best practices one day, currently it's more a proposed CPE evolution for IoT security. Nevertheless, I mean, there is some work done.
.
So, let's talk a little bit about the scope of the document.
.
So, the document is mostly targeted to ISPs and CPE makers and of course to anybody who wants to set up their own CPE. It's clearly focused on consumer home networks. Because those are considered a real critical space when it comes to IT security. I mean, the customers themselves, they are completely security unaware in most cases, they just buy something, they put it into the network and they hope it works, and as long as it seems to work, they don't care.
.
Therefore, we think, given that the recent impacts we have seen from IoT based attacks, ISPs and carriers should have a strong interest in securing the customers' networks, and that's for several reasons.
.
First of all, it's just reducing the support effort in case there is some hacked devices affecting the ISP's network infrastructure. And of course it's about avoiding network limitations or router blocking, whatever, due to malicious traffic.
.
And the major focus of an ISP is also to keep their customer happy. As long as the customer is happy, there is no trouble, there is no support effort, so it's kind of taking precautions for them.
.
So, the approach we took here, it's very practice orientated. So, we didn't want it to deal with upcoming standards and emerging technologies because we think this work is to ‑‑ is about providing something that can have an effect on a short run. So, we didn't want to wait for things to emerge.
.
Therefore, this document delivers methodologies to handle parts of an IoT devices lifecycle. Also principles device manufacturers should follow to ensure customer safety and privacy, and of course references to suitable technologies and standards.
.
Here, just let's have a quick look at the document structure itself. So, we started with securely introducing the device into the network.
.
So the idea behind this is when you add a device to a network, it gives you a unique opportunity to try to identify what kind of device is this and what kind of network access this device actually needs to operate. And when you can make a decision about that, you can also provide appropriate access to the device.
.
Here, we have the use of fingerprinting and also MAT which is also already standard and also used in some implementations.
.
Then another topic is monitoring the device behaviour during its lifecycle. The idea here is to see is there any misbehaviour from what a device is expected to do. And if that happens, also to limit this device's access to prevent any malicious activity as soon as possible.
.
While part of this can be done automatically, of course some steps require user interactions, and here we are also trying to shed some light on how an approval work flow might like and who has responsibilities in that work flow.
.
And then we are ending up with some summaries about it. So, about what secure devices ISPs should provide. Also, in case when the ISPs device is not considered secure enough but cannot be exchanged, what's about adding a second router to the network. So a stacked device approach. Nevertheless, this is not desirable, but in some cases, cannot prevent that.
.
Of course we also had some principles on device safety and privacy.
.
Given that this is the current status of the document, of course this is just the beginning, or it can just be the beginning.
.
We put our ideas together and we provided an initial version of the document but we hope for a lot of feedback. We might be on a completely wrong track, that's fine, but hopefully we can start a discussion about this aspect of securing IoT devices.
.
So, any feedback from the community or from carriers, ISPs, viewpoints are highly welcome. And with that feedback we would just like to improve the document at emerging standards and technologies when they become usable in the field, and also, one of the initiatives we were discussing are about just providing a reference configuration for OpenWRT to create a kind of proof of concept, so people can really tryout what we are describing in the document. Most of the technologies are available, some need a little bit of work, but we think this can be done for sure until the next RIPE meeting.
.
And with this, I will open the field for the discussion. Any questions, remarks, and I hope that my colleagues can also jump in and help a little bit.
SANDOCHE BALAKRICHENAN: There is one question from Patrik Tarpey, Ofcom: To what extent does DOCSIS 3.1 provide pointless?
PETER STIENHAUSER: I think in terms of DOCSIS, Phil, I don't know are you promoted to speaker yet, can shed some light on that.
SANDOCHE BALAKRICHENAN: I have promoted everybody in the IoT task force.
.
PHIL STANHOPE: I think DOCSIS provides some guidance in terms of how you could secure the CPE device itself, so you could carry some of the DOCSIS forward, is he second stage you protecting the integrity of the firmware, ensuring that the firmware is exactly what the operator wants to be running with the home owner. But that's really just becoming the beginning of what the CPE could start to take on. And that's really you know protecting the LAN side in the operator's network. How I think about DOCSIS, and it bonds a CPE into its network. But the IoT security is really going to be on the LAN and the wireless LAN side and so what additional similar approaches could you bring to that side of device management. I'm not sure that answers the question, but that's how I think about it.
SANDOCHE BALAKRICHENAN: So I'm waiting for new questions. And maybe if ‑‑ until there are questions, maybe the others who are part of the task force would want to give some more input? Please go ahead.
ELIOT LEAR: This is Eliot. Just to add a little flavour into the previous question, and the answer. The focus of DOCSIS 31, and even DOCSIS 4, has been primarily on the CPE. The focus of this work is on how the CPE can protect the device in the home, how can it automate boot‑strapping and, more importantly, what the proper role of a service provider to the home should be evolve to.
.
So, what's the responsibility or the opportunity, if you will, for a service provider to protect consumers, customers, in terms of the IoT gear that that he install and how might they protect those consumers from each other given the externalities that are involved and what issues arise when that is attempted. Thank you.
.
MICHAEL RICHARDSON: What I have heard from a system of providers as when they acknowledge there is problems with the IoT services, the service provider is going to likely take the call and they would rather not to do. So there is a ‑‑ the opportunity is to reduce support costs, and then there are a number of service providers in some countries which are offering full top to bottom kind of IoT solutions and it's unclear to me to what extent they really have any ability to deal with issues that come up with equipment that they are essentially recommending or selling in many cases.
SANDOCHE BALAKRICHENAN: Still waiting for questions. I think many of you would have read the document. Michael, please, do you want to say something.
MICHAEL RICHARDSON: Do the Chairs have the results of the second poll?
SANDOCHE BALAKRICHENAN: Actually, the second poll, we had: Yes ‑ 75 percentage; no ‑ 12 percentage; and I don't know ‑ 12 percentage.
MICHAEL RICHARDSON: I was really surprised that so many of the people who responded, I don't know who provide a CPE device to their customers, and I am wondering how many of them, obviously if they are not a residential ISP, then they probably aren't doing that, but I am just wondering, I am really surprised by that number because most places it's inverted, like, you know, some countries it's 99% of CPEs are provided by ISPs kind of thing.
RAYMOND JETTEN: We should have asked was this a relevant question in the first place for them.
SANDOCHE BALAKRICHENAN: Normally, we will have the results by the RIPE meeting, people at the end of the session, so they will have had a snapshot of all the polls.
.
Coming back to the BCOP document, maybe we have sometime, we have like 7 to 8 minutes, so, anybody who wants to give some instances or ideas or do you think the document could go in a different way than a BCOP technical document? How could it be for the RIPE community, so suggestions are welcome.
JAN ZORZ: If I may add something with a different hat, but with my BCOP task force co‑chair hat on. I don't think that this is, at the end of the day, the BCOP, because there is no current operational practice for what we are talking about. I think we should classify this document a little bit differently as sort of a technical report or technical advice or something that may lead into the best current operational practice. So, how would this Working Group like to change the direction it would like to go.
MICHAEL RICHARDSON: It became obvious we couldn't specify best practice because we didn't know there were none. Then the question in my mind came up, well, what advice can we give as a kind of things to be aware of when you are buying, right. These are the things that we think are upcoming issues and you should be aware of when you are buying. Kind of, like, I think ten years ago we said okay, you are not running IPv6 yet, but you should make sure your equipment is capable, right, so that you can do ‑‑ turn it on immediately when you are ready.
JAN ZORZ: We all wanted this becomes best operational practice, of course, but how do we get there?
ELIOT LEAR: Let me just add one comment which is, I'd like to know actually if there is interest from this group in improving the posture of the CPE and IoT devices? Is this something that people would like to see us give advice on here at RIPE? And would you like to participate in the development of the document?
RAYMOND JETTEN: The Chair also needs to know this to determine consensus whether to go on with this document, so... please everybody provide feedback.
SANDOCHE BALAKRICHENAN: Thank you. We have two more questions. The first one is from Chris Bellman, Carleton University: When considering more general guidelines or outcomes to achieve, how important in the task force strategy that implementations across ISPs or manufacturers remain similar? Do you see a detriment to having multiple different avenues to the same security outcome?
ELIOT LEAR: I can take that one. We have to divide that into parts. I think there are parts where the IoT device May participate in some way, and so for instance, in on boarding. There I think it's important to have one or hopefully very small number of standards in to how the device does that. Because we all go crazy and the IoT manufacturers will go crazy if they are pointed to a dozen different standards and how do we know this? Because they are all going crazy because of a bunch of little small standards have developed. But they are beginning to consolidate a little bit which is nice. How a CPE communicates to the MSO or to the Home Office, if you will, may not be something that we need to standardise. How the CPE observes traffic may not be something that we need to standardise. How a CPE segregates traffic may not be something that we need to standardise, but that it does these things is probably important, but maybe you disagree.
SANDOCHE BALAKRICHENAN: Okay. So the next question is from Anna Maria Mandalari from Imperial College London: How difficult it will be to identify good behaviour concerning different usage of the devices from different users sometimes in the same room?
PETER STIENHAUSER: That's a good one, actually.
MICHAEL RICHARDSON: The CPE involved is only it has the knowledge of who is who doing what. And why it's ineffective when we do it at ISP because they don't know which refrigerator is malfunctioning, right.
RAYMOND JETTEN: Is also depends on how you define good behaviour of course, but...
ELIOT LEAR: Good behaviour is what's ‑‑ Anna knows this too, she has come to speak at RIPE before and she is an expert, and it was a pleasure always, but one way is for the manufacturer to declare what good behaviour is and that's what manufacturer usage descriptions is about. Another is to have a body of work or a corpus to determine the answer to that question. But you have to be able to identify which device is which, of course, in that conversation.
SANDOCHE BALAKRICHENAN: Okay. I don't see any more questions here. Maybe we can have one more question on the RIPE NCC update, we have two more minutes, and meanwhile, I would like the RIPE team to, if possible, to share the screen on the results of the poll. Xavier, are you there?
.
We have one more minute. If you have any questions.
CONSTANZE DIETRICH: Maybe one more question to the BCOP task force. What are, except for collecting feedbacks, what do you think are the next steps for you?
ELIOT LEAR: I think the next steps, first of all to decide what this thing is in terms of what we call it, but, most importantly, I think we want to continue to develop it based on feedback from the IoT Working Group here at RIPE. So we really do need the feedback. And we know we have a few things that we want to involve in the document, and so participation is desired and requested.
RAYMOND JETTEN: One for you Chairs to determine, whether this should be a working group document, and I would suggest it is, because we were involved, but...
SANDOCHE BALAKRICHENAN: We think that it should be a working group document. We discussed with the RIPE chat also but it also depends on, it's a consensus from the community, so we want, as everybody mentioned, I am not repeating it. Please send your suggestions to the mailing list and we are at the end of the time.
.
Thank you everybody for participating and we need more discussions on the mailing list and please respond to the survey that Constanze will be sending, so that the Chairs will see how we can do better ourselves to make the IoT Working Group more active. Constanze, please.
CONSTANZE DIETRICH: Yeah. Thank you also to the presenters, Marco, Peter, and of course the rest of the BCOP, and I hope you all have a nice day.
.
(Coffee break)
