IoT Session
24 October 2017
2 p.m..
MARCO HOGEWONING: Welcome. We're good to go? Right. Welcome, welcome to Dubai, welcome to the Internet, welcome to the Internet of things. Why are we? I'll give you a bit of background. So, we're at multiple meetings in the past discussing the Internet of things. We had a well attended sessions during RIPE 73 in Madrid and RIPE 74 in Budapest, in Budapest we packed the house, again apologies for having such a small room for thank you for showing up with so many people.
We also had a dedicated RIPE IoT round table meeting in Leeds recently, I'm going to be talking later about that. And then there is the RIPE IoT discussion mailing list that was set up after the BoF in Madrid, people said give us a place where we can talk about this thing and share information.
To date I count the 154 subscribers, a 62 messages, that was when I made the slide, we're currently at 164. It's IoT at discussion [at] ripe [dot] net. It's a public list so you can just go and subscribe. It's also available via the RIPE Forum application if you don't want to deal with all the e‑mail.
Why this session? Well, as during the last BoF in Budapest, the RIPE Chair, Hans Petter hole instood up in the end and said like you know, I have got a bit of space left in the meeting plan an given that this is so big, we can go to the Plenary and if you sort of walk through the Plenary and give us a bit of a sense of what we're going to do, we'll ask the Plenary to agree to give you 90 minutes for the IoT. And then we can have a construct I have discussion moving afford. Do we need a RIPE IoT Working Group and if so, what should such a group do? That's actually why we're here for today. Now being part of the main programme also means that we have remote participation. We also have a scribe, thank you for that. Thank you to my colleagues for taking care that. Also please note this this session is now broadcast, the session is recorded, if you have got questions please use the microphone and state your name and affiliation.
A bit on my role in this, why is this guy up here? I work in the external relations team of the RIPE NCC and one of my tasks currently is to lead RIPE NCC's efforts in the IoT, the engagement, the strategy. I also coordinated the previous IoT sessions, the BoF sessions were basically my idea. I coordinated and shared the round table meeting, and as we were looking at each other like somebody is going to accept up and has to do that thing, I volunteered and the people around me, the people on the list said like yeah, that's fine. You can do that.
However, the RIPE NCC still prefers staff not to Chair a working group. I know I have set some precedent in the past by doing the IPv6ing with while I already was an employee, but it's basically a continuous line of conflict of interest and you have to excuse yourself may too many times.
So if this moves forward, we need a volunteer, or a couple of volunteers to replace me, to coordinate and share future meetings of this group in whatever form it's going to be, whether it's a working group, a task force, I don't know, but yeah, somebody has to take it over from here. Of course, as the secretariat, we're still committed to this activity. I personally will help you get things off the ground and I'm sure my colleagues can help there as well.
So, the agenda then. This was an outcome of the Leeds meeting, Hans Petter and I talked and we decided that the group in Leeds was diverse and big enough to kind of make the decision on the agenda then here. So I'm going to talk a bit more about that meeting, and I'll use that as a lead into a discussion on the future, what are we going to do? Do we want this, need this, the charter and if needed some other Working Group matters. Then the other half, the last half of this session, I kind of came across a couple of IoT talks that were submitted via the RACI programme or came in via other means, via other Working Groups and we thought of it's kind of a nice set of talks to show what's going on around us, and the possible interactions with RIPE and RIPE's interest. So these three talks in the end hopefully will give you a bit of a sense of IoT and what an IoT Working Group could contribute to the meeting.
So with that, the report on the round table meeting.
The RIPE IoT round table, a report from Leeds. So, the first RIPE IoT round table. And this was software an idea that sparked up in our office after the RIPE 74 BoF. It was really busy there, really good, and we kind of people kept talking, 90 minutes is not that much, and there was clear interest from the community to delve a bit deeper into this topic. And we also just got offered a slot mere in Dubai, we thought we need something, we need to put it together. So, the idea was born to do a dead dated day long meeting, into broader stakeholder communities, we reached out to the industry as well to entice people to come along. Give a bit of a sample of what could be done as a Working Group, what could be done as a RIPE activity towards the IoT, and work out some of the details also on the charter etc. And the proposal ahead of this session. So that's what we did.
AQL offered their meeting space in Leeds for this meeting to take place, so we went to Leeds.
On the 21st of September, we had about 30 participants, which is not that big. At the same time it makes for a really active discussion and it was a really broad range of people. We had a couple of well‑known faces from the RIPE community, we had some academia there, we had people from the IoT industry and that was actually a good surprise, not only because we had people building these IoT devices, but I also had people who were interested in the sales and people with more of a financial interest in the IoT. We also had some law enforcement there. So, really nice broad sample of the Internet community at large.
With did the same with the agenda. So, looking for things that I came across where I thought, we thought that would be relevant to RIPE. Sort of the crossing between RIPE's interest and the IoT. So relevant research, a bit of insights and experience with IoT deployments, etc.
So, the agenda then. We kind of carved it up into four blocks straight away and then started seeking what we thought were relevant talks to lead in the discussion. So we first session was kind of focused on why is the IoT special? Why does the IoT need something that's dedicated to it? Why not just call it the Internet? So my colleague Robert Kisteleki came along and gave a lovely talk on showing RIPE Atlas from an IoT perspective, the design philosophy behind the security model, how do we deal with compromised devices, what are the risk assessments there. The talk is now also been converted in a set of RIPE Labs articles, if you are interested you can look up RIPE Labs and there is a bit of a story there explaining what we did.
Enno came along building upon previous work he did with CPE with the premise that these devices are not big enough and not powerful enough to protect themselves. Maybe we should do something at the CPE level, firewall filters or anything that protect these vulnerable devices from the bad Internet.
Moving on a bit more into security, Constanze Dietrich, you might remember her from Budapest, came back, showed some preliminary results from the survey she's been doing and some insights into how often small configuration mistakes are the lead‑in to big security incidents. We had a presentation by Stuart Hyde from AQL, that's CISP, that's a project that's run by the UK police towards the Internet operators where they feed them information about vulnerabilities in the network, compromised devices, known issues and people can subscribe to that feed and clean up the network as such.
Then, finally, a very broad governance regulation. We had Tobias Knoben came along from ECO, who talked a bit about the German market, there is a couple government initiatives there to make industry 4.0 secure and safe so that they sponsor a couple of projects and ECO actually recently started a special interest group on IoT, with all kind of the aim to get better connection to these players, these industrial people that now all of a sudden become part of the Internet. So I think that was also very insightful talk to show what can be done at local level. I was informed that the similar local initiative is also now being set up by HEAnet in Ireland.
Finally, that was sort of the whole idea of that meeting, we had a discussion of moving forward to RIPE 75. Deciding on the agenda for this session and work a built more on the draft charter that I'm going to present in a bit.
So, the meeting report then. This required an extensive full report at this website.
Thank you, Anthony, for preparing that. Biggest take‑away here: Security really remains the big item. That's where everybody is talking about. We really need security by design. The group together also quickly admitted that, yeah, time to market and cost savings are usually more important than security. There was, I think, quite a bit of feedback on Enno's talk about using the CPE where one of the attendees coined the phrase, we have to be careful not to create too much of an "assisted Internet experience," as he called it, I think that was the a nice way to phrase it and yeah, sort of the establishment of keeping the Internet as open and free as possible.
As Constanze showed many security issues originate from mistakes, there is a possibility to do something with sort of sharing or knowledge, our experiences, best current practices, etc. Because that really was the value we established as a sort of RIPE, sharing, providing a platform for people to come together and talk about what they did.
Onwards then to a working group. There was pretty much across the board strong support for doing something like that. As I said, it's information sharing is key, the development of best current practices, people saw as a useful tool to increase the security.
My take, our take, as the RIPE NCC, we often get invited to IoT events. I decline more invitations at the moment than I accept. For us it's very useful to have that focal point, to know where we can go and report about what we see in the field, what we get back from other events and what we think is relevant to the community. Also, to have some backing in the community where we can go and the community can help us develop certain positions, and sort of help us guide in like what to say or what not to say or where to participate and what we can kind of leave, because RIPE thinks it's not that relevant.
And the other thing then, if you start to develop best practices, if you start to develop positions, you need a way to get it out to the IoT industry. So, we need a place to invite them to the community and I think that was sort of the third pillar that came forward in that discussion, and somebody said look you kind of need a sign on the door that says RIPE is looking at IoT, we have a place for this. So in that sense, again people were saying, like, yeah, that there is a need for the Working Group there to make it clear where people can come from the IoT.
So, that was Leeds. I'm going to break for a bit and see if there is any questions about that meeting or what happened there or people who were at the meeting maybe want to add something. I see no hands. We have remote mic participation. I know there is a delay there. Good. Onwards then.
So, the Internet of things, Working Group or not? So, starting with the start. We don't often establish Working Groups, I have been there, it's ‑‑ I had a chat with Hans Petter Holen, so basically I think we still agree that Working Groups are created at the closing Plenary, so we're not going to do that right now. But we need to get a plan together to present Thursday to the closing Plenary, a charter for the IoT Working Group, which, of course, is backed by a rationale and that's of course part of the charter, but it's good to have sort of a bit of an idea, bit of a pitch, this is why we think we need an IoT Working Group. We need one or preferably two volunteers to act as Chair elect. Pending the decision, if the Working Group gets approved, then of course the Working Group needs two Chair persons to guide us, to lead us. Together with of course a volunteer to present this on Thursday. As I said, I like to take a step back from here, so I would prefer that person to be somebody from the community walking up to the Plenary and then work with Hans Petter and guiding the community through that discussion.
A couple of other small ticket items. Of course you need a working group Chair selection procedure. These are mandatory, we have to work that one out. Probably we need a plan to convert the current mailing list into the standard format so we need to rename and relabel it to IoT Working Group and make sure the archives and everything moves along. I am sure we can figure that one out together with the people back at the office.
And of course most importantly having a working group is one thing, but we really need the volunteers, you in the community, to help and contribute to whatever the proposed work is going to be.
So, the charter then. There is several iterations. The first version was kind of bashed out in five minutes after the last BoF, that was the one that Anna Wilson volunteered to take to the Plenary. That was the one why we got the 90‑minute slot. Meanwhile, the discussion list has seen several iterations by Jim, by Peter Koch. This was, to my knowledge, the last sort of full draft charter being posted somewhere along 20th September which reads: "To discuss challenges and opportunities of IoT for the RIPE community; to serve as a focal point for the NCC regarding community input to their IoT activities including liaise once; to invite IoT communities to for a dialogue on matters of operational relevance, including security, the numbering system and applicability of standards; and finally to develop positions of the RIPE community on IoT matters, operational and beyond."
That was what was on the table. There was a bit of feedback. So, where I would like to start is with this part.
There is two minor editorial comments from my side to serve as a focal point for, I would say, I would suggest to include RIPE, the RIPE NCC, that's of course how our organisation is called, to invite IoT communities to for ‑‑ strike to, because that makes it grammatically correct. And then there are two sort of bigger items. Actually the first one is actually my personal suggestion including liaisons with other organisations, I think it's slightly rounder, it also indicates to others what we're going to do; we're not going to send liaisons to ourselves between ourselves and the RIPE NCC, it is for other organisation to say use as a focal point.
And then on the fourth paragraph, there was some suggestions on the mailing list to drop "Operational and beyond."
Drafting time. I need a procedure and I could not think of one so I stole one from the IETF. My suggestion is to let's see if we can do this with a hum. I tried to avoid voting, so for people who are not familiar with the IETF humming process, the idea is that I say something, and if you agree to that, you are going to hum, and if you strongly agree you hum a bit louder, that gives us a really good sense in the room to feel like how big of a consensus is there, and of course, if there is any striking objections, we'll get to that.
Let's test this with the first edit. So, my suggestion including "Liaisons with other organisations." People who agree to add that piece of text there, please hum now. That's quite an impressive hum. So is there anybody who says like, no, I strongly object to including that text. Can you please now explain why you would object to including that text. If I do another hum we get a vote. Anybody against hum?
There is one, go to the mic, explain why. Can you please explain why you don't like to add that text. Thank you, Rudiger.
RUDIGER VOLK: I have trouble to understand how ‑‑ well, okay, the NCC is still there in the text. Okay, the "liaisons with other organisations" like car manufacturers who are building moving objects, is that something you actually really think will be happening in this Working Group or in a RIPE Working Group? I don't think.
MARCO HOGEWONING: Let me explain the reasoning behind that second bullet is for instance we already have been approached by ITU study group twenty, several times, that included a formal liaison for the RIPE towards the RIPE NCC saying, hey, we're doing something with IPv6 addressing. I can see, we kind of redirected them and said you should talk to our community. So in that sense maybe in the future ITU can decide to send a liaison to RIPE and we can land that here in the similar fashion the IETF set up an IoT directorate to sort of do that kind of work.
RUDIGER VOLK: Yes, but the IETF directorate in that case is something very different from a working group in the RIPE community.
MARCO HOGEWONING: True. But I'm a bit sort of start ‑‑ are you debating the whole charter or the purpose of the Working Group or are you in particularly commenting on that green piece of text?
RUDIGER VOLK: Kind of ‑‑ I have very sceptical pre‑disposition for many things and kind of, as you are pulling up certain details, kind of the scepticism is triggered in various ways.
MARCO HOGEWONING: Okay. Thank you: Jim?
JIM REID: Jim Reid, DNS guy from Scotland. Rudiger is a little bit, I think, overstating the case here. We will have a need for liaisons with other organisations, particularly standard development organisations where we think there is standards are relevant or not is a different matter. But there will be a ‑‑ there will be a need for the NCC to be able to have some kind of way of communicating the views of the community that can then be relayed through liaison statements back to SDOs such as the ITU, AIOTA, perhaps also things like NISA, Europol, the commission, all sorts of things like that. So I think having something in the charter that makes explicit researches to having lays once with other organisation Yours sincerely a good thing. That's broadly what we have here in the sense of the room. Yes Rudiger is quite right to be concerned are we going to start talking to car manufacturers, are some other industry sector? Maybe we will, maybe we won't. We need to have the flexibility to decide that at the time and having some text like this gives us that flexibility. We don't necessarily have to take them up. If the people come to us and say sorry, can he can't happy you we don't know anything about cars or IP addresses or cars whatever, that's equally fine but we have to have that flexibility to be able to deal with other organisations and some of those dealings will involve liaison statements or the equivalent of them. I think we should leave the text as has been proposed, i.e. the change "with other organisations."
MARCO HOGEWONING: Thank you.
AUDIENCE SPEAKER: Basically Jim has said what I was going to say. So thanks, Jim.
MARCO HOGEWONING: So, one strong objection. Are you accepting to be in the rough on the text and then we can revisit the purpose of the IoT Working Group? Okay, thank you Rudiger. Then, basically, I'll do the same on the last one where the original text said "Operational and beyond" several people on the mailing list said, we don't really need that, we can basically say to develop positions of the RIPE community on IoT matters.
So hum if you agree on dropping it?
Hum then if you don't agree.
Whoever that was, do you care to elaborate?
JIM REID: Could I say that that wasn't a hum, that was Peter whimpering.
PETER KOCH: Why did I stand up? I'm not so much mourning about giving the words up there, but the reason that "operational" was in that draft is to address concerns that the RIPE community or this Working Group would step into other territory as in developing standards and so on. This is why "operational" is in there and I think it doesn't hurt and gives a bit of clarification. And finally and this is completely rhetoric and you may or may not agree, but the word "beyond" at the end gives the charter such a nice spin that I would appreciate if it stayed.
AUDIENCE SPEAKER: The problem with what he just said is that if you put "operational" in there there for the purpose of limiting the scope to operational, that's fine if you want to do that, then it makes sense. If you put "and beyond" and to the end of it, then you have eliminated that narrowing of scope and now it doesn't really say anything and it's just extra words. So, I'm okay with "operational," but if it's just going to say "operational and beyond" let's just drop it and be done with it.
PETER KOCH: But, this is going to be a thing that needs seriously to be clarified, because you mentioned SD20, which is probably far, far away from operational. But still the ‑‑ I didn't mean the Working Group, I did mean the topics they are working on, no comment on what the state of the DSG is. If the Working Group to be is the body that the RIPE NCC is echoing the DSG20 work into, that needs to be covered somewhere, and that is probably not covered by "operational" only. So I fully agree that there is a gist, maybe I was inconsistent, but that's me. But strictly, adding "Operational" that will be a bit difficult. We need to put the focus on this saying that we do this but we need to have some openness and I actually don't care about the detail of the words.
MARCO HOGEWONING: So your suggestion now is to use the text to make sure that sort of focus is operational but we can do other things, paraphrasing what you just said, right, so that the arguing to keep it there. I am fine either way. Hum again... I don't know... hum to leave it in. Hum to drop it.
Can I refer it to the mailing list, I kind of need this sorted out by Thursday, so I kind of want to leave this stage with an agreement on the text.
JIM REID: Jim Reid again. If the plans to get a Working Group up and off the ground by the end of this meeting, we can't leave this to the mailing list. A decision needs to be made now at this meeting which is why we're having this particular session here today.
So, I would suggest what we should do here is add another bullet point so my suggestion is to have the under bullet point to develop positions of the RIPE community that the that the IoT matters. Leave it at that. Have a final bullet point saying the focus of the IoT will be on operational issues, but we don't limit ourselves to that, it says the main focus.
MARCO HOGEWONING: Sensible. Daniel?
DANIEL KARRENBERG: Maybe we can solve this by considering that if we leave the brown bit out ‑‑ sorry, I didn't choose the colour ‑‑ it's still included. So, if we reconsider this, the fact that we don't really need to be specific, you know, if it says IoT matters that includes everything, can we have a hum again and be done with this.
MARCO HOGEWONING: Okay. So maybe that's the way forward then. Drop it. If the Working Group gets established, you can always revisit your charter and add the bullet point as Jim suggested. Would that be a workable compromise.
(Very loud hum)
Let me recoup. So we're going to add the green bit. We're going to remove the red bit. That's the text that's going to be presented to the Plenary on Thursday, and then if the Plenary agrees to have a working group, the Working Group itself can revisit the charter and take Jim's suggestion and maybe add a point to set some operational focus where needed.
(Applause)
MARCO HOGEWONING: Thank you, we have a charter.
Next step. Anybody who is willing to face the crowd on Thursday and go up there and present this text and as a process also kind of becomes the Chair‑elect of this IoT Working Group if the Plenary agrees. Any volunteers who are willing to do that? Mr. Reid, and I see Farzad.
JIM REID: As you know Marco we have had some discussions about this over the last few months. I would be willing to help get this Working Group off the ground and serve as a co‑chair for a short period of time, maybe a year or two, help find other co‑chairs, sort out the selection process for the Chair rotation and all the rest of it, maybe do some fine tweaking of the charter. I wouldn't want this to be a long‑term thing from my own point of view, primary because I have already been Chair of a working group for a long time and I think it's important we bring in new faces. So, I'd be happy to do it, and I think one of the things that could perhaps also help here is by mentoring newcomers to the RIPE community that might want to get involved in a working group and explain to them how it all works together and how things fit together. So I'd be happy to do it if there was any kind of support for that in the room.
MARCO HOGEWONING: Thank you for your kind offer. And, yeah, I would take your offer on and then I'll leave it to you to find a fellow co‑chair to help you if the community agrees. Is that ‑‑
JIM REID: Yeah, thank you Marco. There have been some other people that have expressed interest in becoming a co‑chair of the Working Group, we have someone down the front whose name I have immediately forgotten, Anna Wilson has also shown some level of interest and has got to the management support for that and there was also an array who was at the workshop in Leeds. So I think we potentially have a pool of volunteers to draw from, but let's see who else ‑‑ unfortunately these two people I mentioned couldn't come to the meeting this week, but we can certainly find ‑‑ I think we should be able to find one or two other volunteers to get this thing up and running.
MARCO HOGEWONING: We can probably make that call to the mailing list and issue a copy to the RIPE list and make a call when the Plenary decides to to do that. I think that's sensible. So formality, hum if you agree to Jim being the appointee volunteer for Thursday. Hum if you don't agree..
Okay. Well, thank you for that, Jim.
(Applause)
Checklist items then. I have got ‑‑ or we now have a proposed text for the charter. We have a volunteer to present that charter. Then the Chair selection procedure. I had this slide prepared because it was discussed on the mailing list, but I'm now kind of take your guidance here, Jim, do you want to discuss this now or shall we take this matter back to the mailing list?
JIM REID: Well, obviously we have to take decisions on the list and I think this is ‑‑ if we have sometime just now, we could start some discussion about people's thoughts on what the selection process might be. I want to also make it clear that I have had chats with Anna about the proposal to use kind of voting procedure like is done in the IPv6 Working Group where there is a deadlock. I'm still very, very uncomfortable personally with the idea of votes in an open community organisation, but obviously this has to be a decision for the Working Group to decide. And if there are any strong feelings either way on a random selection or some kind of voting procedure or whatever, by all means let's discuss it now. If people feel they want to discuss it, and if not that's something that will be one of the first items of discussion on the new Working Group's mailing list.
MARCO HOGEWONING: So your suggestion originally was to basically just copy the DNS Working Group procedure that has draw lots and that indeed enticed Anna to say I don't like the lottery and I would like like a vote. That's basically the two kind of options.
JIM REID: There are a couple of Working Groups that have got this randomised selection thing as a last resort mechanism built into the selection processes. Or suing some kind of voting procedures. So there are schemes out there and obviously whichever one we arrive a the consensus on that's the one of the Working Group adopts.
BRIAN NISBET: I dream of a day when all the Working Groups have the same procedure. I will continue to hold tight to this dream. Just, in regards to ‑‑ and myself and Jim are tag knell on this position ‑‑ I really, really dislike the notion of drawing lots, names out of a hat as a random eyes err. Ideally the Working Group should be able to reach consensus on the people they want to Chair it. As I like elections as a tie‑breaker but only that and should never be the first. The first thing I much prefer them to drawing lots or whatever else. But this may and I see Hans Petter standing there, may be academic, if you knee the heavy hand of the RIPE Chair forces us all to have the same procedure, but, yeah, please don't go withdrawing lots.
HANS PETTER HOLEN: The RIPE Chair just woke up from his dreams to a new discussion of Chair selection procedures. He wants to go back to his dream. I have challenged the Working Group Chairs and I will challenge them again, can we please make one procedure for all the Working Groups that will work, so we don't have to spend time discussing the procedure to select Working Group Chairs in all the Working Groups. I think that was one of the strongest outcomes when we put this in place afterwards. So hopefully, we will not have to spend too much time on that in this Working Group, we can work on the IoTs as well like the Norwegian connected sheep.
MARCO HOGEWONING: Thank you. Daniel... you are done, amen, what Hans Petter said. I think my current time we have got about three minutes left to resolve this. I would say, take it to the list. My personal suggestion as an engineer would be to create convergence, do a count, how many of these Working Group procedures have drawn lots and how many of these Working Group procedures have a vote and then take whatever the current majority is because that gives you closure to convergence, but I see Brian kind of banging his head against his laptop, so I guess that was not a very useful suggestion. Rudiger?
RUDIGER VOLK: Sorry for not being serious but why don't we draw lots on the procedure?
MARCO HOGEWONING: Thursday, the coffee break after the Plenary.
BENEDIKT STOCKEBRAND: Now, I think one of the reasons why we have different procedures, apart from the various personalities of Working Group Chairs, not seriously that's not the problem, is because Working Groups are somewhat different, so the IPv6 Working Group compared to address space, for example S very different because one is doing policy things the other one is doing technical stuff. And with the new Working Group not really being obvious which direction we are going, I think we should just go for simple solution that makes life easy for pretty much everybody and by the time we figure out where this Working Group is going, we might reconsider things because by then we know better what we actually need.
MARCO HOGEWONING: Okay. So let's divert it to the list and then my word of advice would be just look, take something, copy it, that at least gives you less diversity than editing your own text, but as NCC stuff, I have no particular position on how this is going to work.
JAN ZORZ: Do we really need to agree on this to get this Working Group started on Thursday or we can leave this for later?
MARCO HOGEWONING: As far as I know we need a volunteer to present the charter. If the Plenary agrees it's up to the Working Group to prove the process. We can divert it but as Jim suggested, it's good to hear the opinions but I think there is quite a bit of consensus, like we only need one procedure. That's that's what I got.
JAN ZORZ: Just my personal opinion, I don't like to draw lots, because I think the Working Group needs to decide who would be the person to move the Working Group forward.
MARCO HOGEWONING: All right. Thank you. With that then I'm kind of going to wrap it up. Again, join the mailing list, it's called IoT discussion for now. Maybe somewhere in the next few weeks you'll see it reappear as IoT Working Group but that's up, essentially up to you. I mean there is going to be discussion at the closing Plenary on Thursday where you, as the RIPE community, can have your say whether we need this or not. Jim?
JIM REID: Thank you very much. All I want to say Marco is to give a very public thanks to you for the all the hard work you have been doing behind the scenes for getting us to this point and all the IoT activities you have been doing over the last few months as well. I have seen you in action. And I think you have been doing a great job and we're very, very grateful for all that effort and I think with your participation in this IoT Working Group will have hopefully something that's really quite successful. Thank you.
(Applause)
MARCO HOGEWONING: On with the programme. As I said, we're neatly on time. This was expected to wrap‑up in 45 minutes and that's exactly what we have done. So back the agenda. As I said we have got three talks lined up for you that I think are interesting. So, Kevin Meynell, the Internet Society. Is the first speaker who is going to update us on the online trust alliance, which is now an ISOC activity that's very close IOT.
KEVIN MEYNELL: I was asked to give a short talk and threes are almost lightning talks actually, I have just got the 12 minutes. So I wanted to raise awareness of some work that's going on in the online trust alliance. Some of you may be familiar with the OTA, some of you may not. But it's also doing work that's particularly of use to the IoT area so it's worth just raising awareness of that.
So, what is the the online trust alliance? This has been going for a few years now, started in 2007, and it was founded as an industry trade organisation. It sort of built‑up to 65 members. I haven't named them all, they won't fit on the slide but those are so. Names that you probably would recognise and some fairly big players in the Internet trust industry. So it's a pretty broad mix. Certificate providers, large software companies, social media, also some large retailers in that as well.
There was a change this year, and actually the Internet Society and OTA have merged, so OTA is now an activity within the Internet Society, and as a result the OTA members have now been ISOC members as part of that process.
More generalically it's there to promote best practices in protection of user security, privacy identity and also in good practices in data stewardship as well. The ultimate aim behind this tost to develop some meaningful self‑regulation within the industry and it's probably been working a lot in trying to persuade the up take of TLS certificates, web browsers and that type of thing.
So what this does have to do with IoT? There is so the challenges in IoT which we have heard about but I like to bring it back to my house because I can relate to this. So, I sort of went around and did an audit of what devices I have in my house and some of these things are not what I might typically call IoT devices but some probably are. And I went around and you know, I pretty much found that there is about 30 devices I counted, you know at any given time. People take devices in and out of, course but there is roughly around 30, and it's quite a broad mix, you have got PCs and routers and printers, there is a server there as well. But also home security devices, there is a couple of cameras, a couple of smart televisions, and also starting to add some home automation there as well. I haven't gone too far on that for various reasons, but it goes to show you I may be slightly more technical than perhaps the average household, but there is 30 devices in use in that house.
As I said I'm a reasonably astute technical user. I actually went out and bought where I could devices that support things like TLS management and IPv6 support, I can configure the security. Do they support crypted data transmission storage? In the main, yes. But I also know roughly how to do network monitoring as well, so I can, if I want to, go out and work out what some of these devices are sending to and from each other and maybe sending outside of the house as well.
But, you know, I'm time‑poor, I am actually not home much, I can't monitor everything and actually I don't have the inclination to monitor everything as well. And I actually have, even though I am a reasonably astute technical user, I have really little or no idea who these devices are communicating with or who is communicating with them.
I don't really know what data is being collected, you know particularly from things like the smart televisions, and also maybe some of the home automation devices. And I don't know where that information is going either.
The other thing is as well that many of these devices or most of these devices have stopped being supported and usually that support ends after one or two years, you know the smart TV, that stopped after about one year, you got no more updates. Webcams, the security cameras, the support stopped after about two years. The routers are not so bad, I got a Dreytek and they provide some pretty good support ongoing, Apple and Microsoft have regular updates on their systems, so the situation is not quite so bad there. But actually you know basically a lot of these devices are effectively no longer supported but they have still have a useful functional life.
Perhaps more the concerning parts that I bought several of these devices because they did actually support TLS or TLS management, and actually that's now been depricated so TLS 1.0 is no longer supported, a number of web browsers or modern web browsers no longer support that. So if I actually want to use that functionality in the devices, I can no longer use modern web browsers, I have to go back and find an old version or I have to turn off the TLS. I have to do an unencrypted connection. This is the problem you have. You try to do the right thing and then that gets taken away from you at some point in the future.
So this is really what OTA is trying to address or wants to try to address.
This is the sort of the cartoon showing you the kind of worst‑case scenario. So, on my network, I don't really know what's happening, but hopefully nothing too bad is happening. I don't think so, I'm not getting that thing, bad signs, but potentially as all of these prophets of doom can potentially happen and that's the sort of situation that we could potentially be facing.
So something must be done and we must think of the children and all of that type of stuff. But we did, ISOC did a software audit of how many different IoT industry bodies are there and we have we have counted about 40 of these. So there is really a lot of different groups to talk to and they are all doing slightly different things. So OTA really decided to take this broad multistakeholder approach to assess the risks and address some of these security, privacy and lifecycle sustainability within the IoT products and services. They established a Working Group back in January 2015 to develop this IoT Trust Framework, and this involved a consultation with over 100 device manufacturers and major retailers, security and privacy subject matter experts, also consumer testing advocacy organisations as well, plus there was some involvement with government groups too. And the outcome of this is that we published the IoT Security and Privacy Trust Framework in March 2016. That's gone through several revisions now and the latest version was released a few months ago, now up to Version 2 .5.
Just a very quick summary. You can go and read this. It's actually a fairly readable document. Basically it defines 40 principles in four key areas:
To secure IoT devices and their data.
So, sort of first aspect. Security. So this is about ensuring devices use cryptographic protocols by default. They only open physical and virtual ports. And offer the services that are actually required. There is also regular monitoring of security settings, plus when the issues are discovered, there are verifiable patches. So, you know, it would be signed software patches for example.
Also, with user access and credentials, that's the next key area. So, you know, mandate strong authentication, storing credentials encrypted but also providing some anti BruteForcing measures, this reviews a hacking scenario.
Then there is also privacy, disdisclosure and transparency. So the manufacturers or the device manufacturers or the service providers will indicate what data is being transferred and they will only collect data with affirmative user support, but also disclosing, you know, well, when will the security in patch to port end? You buy a device, how long can you expect to get patches for in the lifetime of that device? Is it one year? Is it two years? Is it five years? You know, make that clear, so users ‑‑ consumers can differentiate between different products.
Also notification. So if you do have to send notifications to users, you know, they should be authenticated in some way, so you know, there is some protection against you know the sort of phishing type of attacks.
Okay, so this is all very nice, brilliant, there is a framework, there is some recommendations, quite comprehensive recommendations, but if nobody is going to read this or adopt this then it's not going to be very effective. There is a number of other IoT frameworks that do exist, although these are sort of tending to focus on specific areas like the interoperability and security. So, we think that the OTA is probably the only holistic framework that encompasses all of these different areas that encompasses all of these, specifying end of life‑cycle, all of these different aspects of IoT that need to be thought about and supported, and actually the framework overlaps in many cases with some of the other frameworks. So we're hoping this is a sort of a comprehensive sort of best practice of the best practice within the industry.
But actually, more specifically, we're talking with several leading manufacturers and suppliers who have agreed in principle to sign up to this. I did actually want to announce some of these today but we haven't actually resolved the legalities yet. Apparently that's principle is there, but there is just some Is to dot and Ts to cross, so, I can't say exactly who is involved in this at the moment, but there are quite a few organisations.
And actually a number of large retailers are planning to use the OTA framework as a filter for carrying their products. So they'll only carry products if they conform to the OTA principles.
Also, working with consumer testing and review organisations. We have been talking a little bit about certification programmes, but probably initially this will be sort of, you know, consumer comparisons, so you get ten devices, which one conforms to the best, or conforms most to the principles, so you have a ranking, this, this, product supports, you know, 39 of the 40 key points. And gives a sort of way consumers can distinguish between sort of of different products there.
And then also, the framework, this came very much out of the NTIA, IoT multistakeholder process, so NTIA is an agency of the US Department of Commerce. So, it's conformant with some sort of, I guess, US government‑backed recommendations. So, there is some sort of support there for this framework as well.
That's my last slide. If you are interested in more information, various URLs on the OTA website, specific resources for industry and consumers, and actually if you are interested in being involved in this, it's possible to sign up also to the OTA as well. Okay. That's it.
MARCO HOGEWONING: Thank you, Kevin. I have got time for basically one short question.
AUDIENCE SPEAKER: I'll try and make it shortl. Owen DeLong Akamai. Two key problems that I have seen with IoT that don't seem to be addressed in this and maybe they are and it just wasn't part of the slides or maybe I somehow missed it. Number one is the dependency ‑‑ the inability for the consumer to actually own the IoT device. Usually that comes in the form of dependency on an unsustainably free Cloud service, where the device doesn't function except through the Cloud provided and the Cloud's free when you purchase the device and that's all well and good and happy for the consumer, except that you either have to keep selling enough devices to support this evergrowing base of Cloud requirements or somehow your Cloud is now unsustainable as a free service and now the person who thought they brought the product has to start paying rent for it, or, you know, the product just turns into a brick. The last one being the more prevalent result that has been occurring in the industry so far.
The other problem is even in the DIY developer world of IoT development kits, there is still a huge strong prevalence of the inability to get decent IP addresses on the things in question. And I didn't see that addressed anywhere in your principles either.
KEVIN MEYNELL: Okay. So to the first point, I don't think ‑‑ I can specifically say that the issues of the ownership/non‑ownership are addressed by this, but it does cover the issues of you know, okay, who owns or controls the data on that device, so let's say you want to turn off your subscription, stop paying your subscription, the issue of who the data belongs to or what happens to that data I think is addressed by this framework, so I sort of half‑way answering your question maybe. I'm sorry. And the second point, I didn't quite get the thing about the addresses?
AUDIENCE SPEAKER: So the first point is more that when the free Cloud stops functions and there is no local API on the device, or no documented local API on the device, you have got a brick now instead of the product you thought you bought. So... the data ownership thing is actually orthogonal to what I was talking about.
The second one is about the number of things that still don't support IPv6.
KEVIN MEYNELL: Yes. So, that's a good point, I mean, so this is really more about the, you know, the general principles of how the devices handle data, how they interact with the Cloud, rather than, you know, specific technologies I think that enable that. But I think that it's a fair point with the IPv6. But I don't think I can answer that.
MARCO HOGEWONING: Thank you, Kevin. I am sure you will be around if people have other questions.
So, our next speaker is Ivana. I have seen some of this work presented at the southeast Europe meeting.
IVANA TOMIC: I am working at the Imperial College as a research associate, and the work I will present today has been done in collaboration with professor Julie McCann, and the AESE group that I'm part of. In my talk, because really I didn't have much time to put all the technical details, so I will try to keep it very simple, but if you have any more questions about how it really works, you can ask me after the session.
So, in the talk, I will focus on cyber and security aspects of sensor networks and IoT in general. I will show different types of network layer attacks and a mechanism that helps you to defend against these, which we call the Trusted Routing.
When it comes to IoT systems, I think we all limit ourselves to only the notion of device, so we are thinking about sensors, mobile phones, but what is core there are the communication links that basically make the IoT concept to become reality. So they are like a wide‑range of communication protocols that satisfy different requirements, different applications that we want to use, and that's what makes it really, really different than traditional IT networks, so we're talking about billions of devices that are low cost, low power, so they are very constrained from the perspective of resources, and usually they collect sensitive data. So if it happens that we have some problems there that could lead to the large losses, and it can reduce the quality of our smart lives.
So, when I started working in this area, the first thing that we tried was to identify how many attacks is there and try to group them with respect to the layer structure of sensor networks. This list, of course, it's not the complete one because we get new attacks from, like everyday, but in general, we can group them into two categories, internal or external attackers. In this talk I am assuming that there is a malicious node in our network, so that means I will address only internal attacks. Instead of going through all of them, I will just give you a few examples such as blackhole attack, where basically node rejects to pass any data that is routed through that node. Then we have a sinkhole attack that is more smart version of blackhole where first the node advertises some falsified information to attract traffic and then it starts discarding data. And the last example is replay attack where a node can replay data that was routed through that node or maybe the data that was overheard during the transmissions.
In order to quantify the effect that these attacks can have on the performance of the networks, we did the implementation of these attacks in Contiki OS and we used the Cooja simulator just to get some idea of how bad this can be for the network so we did, we used two matrix to quantify their facts. The first one was the packet delivery ratio and then end‑to‑end delay. We also considered different percentages of the attackers in the network so you can see that for a large percentage of attackers we have the data loss ‑‑ data delivery ratio basically goes under 10%, and really, really large delays can happen in the network.
So, we looked then into how to address this problem, and we came up with the self‑healing scheme basically that has two main techniques. It's using two main techniques. The first one is trust scheme, that basically affects our routing decisions, and then we have a simple notification scheme running in the parallel.
So how this works. Each node basically trusts only itself and by looking into its neighbourhood, it is building the trust model. What does that mean? I mean, if we are overhearing the nodes that are very close to us, we can get different data. How many packets they receive, how many they send, which one they advertise, so by using this we can deduct the notion of trust, so we send our data only to highly trusted regions.
If, over time, the node that we are routing data through becomes malicious, we will be able to see this change. So, as a consequence, we will penalise this node, it will become less trusted. So we would switch to someone else. But this would result in, is basically the data would flow around the affected regions.
So I also mentioned that we have a notification scheme and it has basically two roles. One is to let know base station that there is a problem in the network and which node we detected as malicious, but also, there is a notion of spreading of the attack throughout the network, so in order to bound this damage we used a simple mobile agent based scheme where if I change my decision, not all my neighbours are aware of that, so they might see me as malicious. So you need somehow, instead of having only local view in the network, only your neighbourhood to provide more global view.
So we say that in this way we can bound the damage of the attack.
We run different simulations, we also use the real test bed in France, and then we looked into metrics I mentioned before, so, our scheme on average reduces data loss up to 5%, in some cases it goes down to 1%. So in the graphs I'm not sure how clear it is, the ideal case is in pink. Our solution is the yellow one and the case when you have an attacker in the network without defence is the blue one.
So, as a solution, just to summarise, it doesn't provide only detection, so we are detecting the attacks, but we are also acting upon it in order to avoid these affected regions and ensure the reliability of the network.
The scheme by itself, it's very lightweight, so the overhead here is expressed in terms of percentage of extra messages that we are using, and it's usually around 2%, so it varies between 1% to 2.5, depending on how big is topology, or what kind of attack we have.
The detection scheme by itself, it has high precision, so we can provide a detection reliability of 99.3%, and I have to say that in choosing the thresholds for what we consider as malicious activity, we were very conservative, and that resulted in the large number of false positives, but it just depends how sensitive you want to be in your scheme, so this is user defined parameter and it can be changed, depending on how sensitive is your data and how much you can afford to lose.
Just to summarise. I will leave more time for the questions if you have any. We show that our scheme achieve high effectiveness in terms of data loss with very low overhead. This work has been done in the past year but I continued working in the same area through two different projects. I also put a number of references there in my article on RIPE Labs and I will just want basically to give you some overview of what else I am doing now.
So besides the internal attacks, I also started looking into external attackers and how easy is it to jam your network? I mean if you have you lot of something available it is very easy, but I am looking into more intelligent jamers where you want to go undetected and energy efficient. Also we are investigating different kind of protocols, we are doing jamming on Wi‑Fi but also lower protocols, so if you have any questions, you can ask me now. There is still sometime left, or after the sessions.
Thank you.
(Applause)
MARCO HOGEWONING: We have got a few minutes left for questions, so...
AUDIENCE SPEAKER: Salam Yamout, Lebanon. The question is, how fast does this, does it take for the node to become self healing and to react to whatever it measures?
IVANA TOMIC: So we are doing sampling in the periods of 20 seconds because the devices are very limited. So it takes us one, or for some of the more difficult attacks, two slots to detect malicious activity. So it is quite quick. But we left some sort of flexibility there just to review the number of false positives because you don't want to react to every change in the network. It could be just interference, it doesn't have to be the malicious activity.
MARCO HOGEWONING: I am going to close the queue after this.
JIM REID: Have you any sense of how this scheme of yours will actually scale, if you have got it working with a relatively small number of sensors, how well that adapts as the number of nodes in your network increases will that have any kind of problems, how well will it adapt if you scale up to 1,000 nodes or 10,000 nodes or something like that?
IVANA TOMIC: So far what we tested in the simulator was up to 200 nodes in the test bed it was up to 100. So far it works well and we also tested the scenario when you have different attackers in the same network and they basically run in the same neighbourhood or in a separate neighbourhood. So we are still working on improvement, but like, the actual answers, I'm not sure about it so that's how much we did so far.
JIM REID: Thank you. Interesting to hear more later.
AUDIENCE SPEAKER: Philippe NETASSIST. Interesting work. The question I have for you is about actual consequences of the attack when not is being compromised by someone, this is the most interesting and rare case when you send false data which seems to be valid but it may lead to the system which analyses particular environment computing to bad results, to actually ‑‑ to actually perform some misbehaving thing.
IVANA TOMIC: Okay, so you are thinking about false data injection or...
AUDIENCE SPEAKER: Exactly. I mean about injection and how can you make the trusted routing in a particular way to eliminate such attacks, at least make it nearly really possible.
IVANA TOMIC: Okay. So at the moment we are looking only at the attacks where we don't have to change data, so we don't need to decrypt data and then interfere with that because that brings another level of complexity from the perspective of the attacker. So there's been a lots of work on how to protect the network from false data injection, but we haven't looked into it. So we don't basically change the data. We are either like discarding packets, duplicating them in the network, but we are not looking into the content.
AUDIENCE SPEAKER: Thank you.
MARCO HOGEWONING: Thank you.
Our last speaker then, Farzad Ebrahimi.
FARZAD EBRAHIMI: Hello everybody. I am Farzad Ebrahimi from the IoT Academy of Iran.
First of all, let me appreciate RIPE for selecting me, inviting and supporting me to be here in RIPE 75. Thank you RIPE.
My presentation is about the key factors for the successful entry of developing countries into the Internet of things. My background is seven years in the field of IoT, focusing three years on IoT. I am CEO and founder of BITA, Chairman of IoT Acadamy of Iran, Faculty member at Iran ICT Research Institute, and also Deputy of IoT and big data commission in Tehran, ICT Guild organisation. This organisation consists of more than 4,000 companies as a member. I am Chairman of Technology Working Group in that commission.
Before starting the presentation, let me share hot news related to Dubai and Internet of things. Just two days ago, Sheikh Mohammed bin Rashid Al Maktoum, the leader of Dubai launched IoT strategy. And in the near future, Iran Internet of things road map will be launched by the Minister of Iran. This news shows the importance of IoT in the Middle East countries.
All of you are familiar with IoT. I want just to say IoT is not a technology. IoT is a concept that uses several technologies. About IoT trends. Gartner Hype Cycle for Emerging Technologies shows that IoT platform is a big topic now, and connected home is near the peak of inflated expectations. It means that huge amount of data collected by the sensors should be, and will be stored analysed and visualised in IoT platforms so you can see and you can believe that IoT platform is very important for all the countries because of data governance, and security.
IoT predictions, you can see McEnsey, GE, Cisco and Gartner predictions here, all of them forecasters agree that IoT will affect the economy. It's very important for the near future. For example, you can see global economic value of IoT in less than ten years will be more than total economy of Germany. If you want to know more about this diagram, you can see my article that yesterday is published on RIPE Labs.
What are the main characteristics of developing countries? General poverty, developing countries are poor. High dependence on agriculture. Agriculture is the main occupation in most of developing countries. Underutilised natural resources, lack of industries and enterprises, the industrial sector in developing countries is at the primary stage of development. Lack of capital and technology. Lack of basic infrastructures.
Demographic characteristics. There is high growth rate of population in developing countries. There are a large number of educated young people in these countries. Social cultural characteristics. Different kinds of social groups reside in these countries. And dualistic economy. All of the sectors of economy in these countries have not been developed.
What are the IoT features? The need for specific manpower is one of the features, creative young human resource is needed, especially for training, as I told you before, IoT is not a technology, it's a concept, that uses and consists of several technology.
Realising the IoT. IoT can be used in several industries in all of the businesses and can affect them.
The need for increasing maturity level. Maturity level of the community is important for its use.
And start‑up based approach. You know that start‑up activity is very important for developing the solutions in IoT.
And from the perspective of technology, all of you familiar with the main aspects of IoT. IoT hard aware, network, platform, applications and services, and also data analytics, like big data analytics.
What are the IoT opportunities for developing countries?
IoT needs creative young HR, developing countries have them, because they have young educated persons and people. A smart agriculture is one of the main IoT verticals, you know, developing countries based on agriculture. IoT spreads by start‑ups. Developing countries have this potential, because we have several innovative young people in developing countries. The IoT can take countries out of the bipolar economy. You know that IoT can cause for money saving, so, we can, going out from the bipolar economy in these countries. And finally, IoT needs brain ware, developing countries have educated young people.
What are the key factors for successful entry of developing countries into the IoT?
Cultural difficult fusion of IoT knowledge is one of them.
Training of young educated human resources in the field of IoT is important.
Use of young creative manpower, start‑up activities supported by start‑up business accelerators and creating a new venture capitals, who invest in IoT solutions and services and finally right choice from the perspective of technology for investment.
You know that in developing countries they should invest in their core competences to the IoT concept.
In the second part of my presentation, I want to share our experience in Iran in IoT academy of Iran. As a case study you'll know that Iran is one of the developing countries. IoT Academy of Iran has started its activity in April 2015 with the aim of creating professional didactic ecosystem and cultural difficult fusion of IoT knowledge over the country and training of specialised HR. Now we have several weekly workshops in all of the major aspects of IoT, you can see, and I have a suggestion for RIPE to collaborate with each other for this kind of training. Also, some training courses based on minimal viable production. In our courses participants will ‑‑ and it can be useful for practical efforts and practical activities. Specialist training and consultation in accordance with marketness in IoT verticals. We can help industries, universities, companies to enter IoT. Raising the level of IoT knowledge and IoT dissemination and knowledge sharing.
Our future activities is participation in dissemination of IoT knowledge in the other countries, holding training courses and workshops in the other countries. IoT kids project. We believe that we should start training of IoT from the schools. We have a project and we have a plan for it. IoT projects for improving the life in rural areas. Such as a smart care patients, monitoring the quality of drinking water or something like this. Designing IoT customised evaluation boards for training IoT concept around the world, companies, industries, who started the activity also.
You can see here a sample of our products. IoT based oil and gas detection system that is ‑‑ uses now in oil refineries of Iran as a pilot.
Here, let me talk about the conclusion. It's my last slide.
For the successful entry of developing countries into the IoT market. Widespread knowledge sharing is important. Training of young educated manpower is needed for all of the countries.
Supporting a start‑up culture is essential.
New generation of VCs to invest in IoT related products and areas are needed.
This needs to encompass all aspects of IoT from hardware and network and platform to application and services and big data analytics.
And finally consider the capabilities of the brainware of developing countries cannot only help those countries themselves, but can further technical development worldwide.
Thank you for listening. Any questions?
MARCO HOGEWONING: Thank you. We're go a minute and a half away from coffee so we can take one or two questions.
You said earlier on like you want to cooperate with RIPE. Is there anybody here who knows of similar initiatives outside of Iran that's doing similar things? I really like what you are doing and I think it's good. I see somebody in the back there.
AUDIENCE SPEAKER: Felippe, Netassist. The first question, I will be concise and short at this time. Is the government ready to implement it and use it as a tool to actually make a huge step for it? This is my question. Is government ready? Does it have a plan to make it straightforward? There is a lot of potential. Can you ‑‑
MARCO HOGEWONING: With that, I think, thank you for that. You will be around so people can hopefully find you in the breaks and chat some more about what you are doing.
Thank you all for coming to the session. Reminder again, there is the mailing list, I'll post a note with sort of the final text of the charter as soon as we're done here, and thanks again to Jim for stepping up. And as I said, this is going to continue Thursday in the closing Plenary. So, I hope to see you all there.
Thank you. Enjoy your coffee.
Next session here at 4 o'clock, it's RIPE NCC Services, so please be back on time.
(Coffee break.)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
