IoT Working Group
Thursday, 17 May 2018
2 p.m.
JIM REID: Good afternoon everybody. This is the first ever meeting of the IoT Working Group, so I would like to say welcome to everybody. Before we get started, I have a couple of announcements to make. Could you please make sure that your phones and other buzzable devices are put on to silent modes it will be very embarrassing if a phone rings half‑way through somebody's presentation. The session is being recorded and being webcast and when you come to the mike to make a question or comment, please identify yourself so we know who it is that's making these comments. This is particularly important for the people who are following the proceeds on the webcast, they would like to be able to know what is actually saying whatever it is they're saying and it will be helpful later when we look at the transcripts to know what's going on.
Before we get down to business I have a couple of other small announcements to make. We have tried to get some kind of consensus on a working group Chair selection process, and so far we haven't reached that consensus, and that kind of issue sort of fell of oft end of my never ending list to do. My apologies, the day job has intervened and other things got in the way but my intention is that we're going to get this thing sorted out shortly after the RIPE meeting concludes this week, and we will run the selection process roughly around about the time of the next RIPE meeting so that there is another co‑chair to get this Working Group up and running and off the ground as it were.
So openfully we'll get that sorted over the next few months and there'll be somebody else besides myself for RIPE 77.
If there is nobody with any other comments on the sucked agenda I think the first thing to do is just get started. And our first presentation.
MARCO HOGEWONING: I work for the RIPE NCC. You have seen me I work for the external relations team and one of of my tasks at the RIPE NCC is to kind of guide the RIPE NCC through IoT, finding what's interesting and what is not. You have seen me getting involved in getting this Working Group off the ground in the past with a couple of BoFs.
Very brief, what are we doing?
So, as I said, my main objective, my main attacks in the RIPE NCC is to kind of make the connection between the RIPE NCC, the RIPE community, and everybody in the IoT space. They include many manufacturers and developers but also talking to policy makers, civil society, everybody who has a stake in the IoT, trying to find where does it overlap with RIPE's mission, where does it overlap with the things we try to do in RIPE. And of course, raise awareness about our key topics. Of course IPv6 is on the table. The other big thing that usually is more important to a lot of people are the security concerns. How is this going to look like? Privacy is an important factor, but also especially from where we stand, denial of service attacks.
Talking to a lot of people and looking at solutions, what you'll find is that there is a lot of IoT ‑‑ it's actually not that much Internet. A lot of people do not use IP directly. They are working the application space or use dedicated protocols that do not use IP.
A lot of it is basically just VPN style long hall transport, the Internet is a cheap way to get data across the globe. The people who do interface with IP often immediately point to the carrier, yeah if you plug your television into your house Wi‑Fi it kind of becomes the problem of you are ISP to provide that connectivity. Yet, still, we try to raise awareness about hey, there is this Internet and it's important also to your business even though you don't immediately interface with it. And also, just to create awareness about the way it's organised.
We use many different channels. As I said, existing relationships, Europol, inter toll, the ITU, government in general, the European Commission in Brussels, they all have big things on the table regarding IoT, regarding your privacy, your security, etc. Of course we're also exploring our membership, in particular the larger mobile telecom operators, the larger ISPs, who are significant players in the IoT space.
Dedicated organisations, RIPE NCC is a member of the alliance for IoT invasions, I'll come back to that. The ISTAR partners, IETF, a lot of work going on there related to IoT, the IAB has their say in it, ISOC, the other RIRs, ICANN a bit. And we do a lot of media relations and publications.
So, to that, we always get questions almost on a weekly, on a daily basis, usually relating to security events, security incidents. We generally respond, we see that there is a good opportunity to explain who we are, what our role is and usually advocate for an open, self‑regulatory, multistakeholder approach, essentially the RIPE model, the Internet model.
Also, articles and blogs, you might see my name POP up at random websites because we sort of try to grab people's attention, explain the benefit of this model, and show the value for them to come to meetings like this engage with you, participate in the meetings, and essentially make the IoT a better, safer place.
ITU study group 20, that's focussing on IoT, Jim just came back from their meeting, we have been active for a few years now, it's very broad in topics. Work is also very abstract, very high level. Our biggest concerns there is that a lot of it involves identification, a lot of it involves addressing. And the topics there range from drugs to counter fit medicine, it's really all over the place. You then see things like digital object architecture POP up or similar solutions that might not be called DOA but are very much similar and there is a specific work item there on IPv6 addressing, I'm not going to address it here. Next session in the side room, IPv6 Working Group has half an hour dedicated to this particular work item, so please come along.
AIOTI. We're a member. It was established by the European Commission. It's now a fully independent association. The secretariat and the website have also been transferred. Right now we're mostly just tracking the ongoing work. Last year you may have seen an invite by them on the survey about addressing needs. That document is kind of ready, it's awaiting publication. It's only a small mention of IPv6. It refers to us as sort of the authoritative body, so it's all fine. But it's really goes into specifics of industrial automation and what they need in terms of identification and addressing at that level. So it kind of ignores the Internet again.
And that's kind of all I have to say right now. If you have any questions, I'm not sure whether Jim allows for T otherwise, find me, mail me, talk to me in the hallways.
JIM REID: Are there any questions for Marco? No, okay, well just before Marco steps off the stage, I would like to express my personal thanks for all the work that Marco has been doing in study group 20, we have been both been involved there for about a year or so trying to fight the good fight, as it were, and an I'm very, very grateful for the assistance that Marco has been able to provide in that. He has been doing a great job. So thank you. Thank you for your presentation. And I would also like to underline the fact that the next session of IPv6 Working Group after the coffee break is going to discuss this draft IPv6 for IoT devices document which is being discussed at study group 20. Please come along to that session if you have any interest in that at all. The more comments we have in this document, the better, it would be very, very helpful to those who are making the arguments about it.
Next up we have he will I have cert, we have new faces, I have this is the first time she has given a presentation. She is going to be talking about some of the other privacy aspects of IoT in a rather interesting context. This is about sewage and I think there might be a joke in there somewhere but I better not explore that.
ELIF SERT: Hi. I am one of the RIPE NCC fellows and I'm researcher. So, today I'll be talking about privacy implications of sewage testing for illicit drugs. It's a research that my colleague and I are conducting.
To start with. Smart cities. We know that they promise the feature, they bring a lot of economical values, sustainability, and they are basically the digital urban Ecosystems that monitor everyday activities by collecting a lot of data.
How so? IoT. We know that Internet of things devices are being deployed everywhere and they are going to ‑‑ it's estimated that the market value is going to triple itself in four years, but there is really one thing that is important with Internet of things. It's, if you know that Internet of things devices are seamlessly integrated into our surroundings and cannot see them and actually this is why, in a way, that they are designed for. So, but this creates of course some privacy concerns because cannot see them, and it's kind of contradicts what traditional privacy concerns, how are you going to get the consent if cannot see it and how are you going to notice the data subject. So it's hard.
Some researchers came up with the idea of provision by privacy) it's basically the idea of keeping privacy in mind from the very first step of let's say creating a device, so you should design it in a way that it's not going to collect more data than it is necessary. And again, some researchers boil privacy by designing to do not collect any personal data. But, even though you don't collect any personal data, you collect the behavourial data of a group and this is still concerning because the group could be still targeted, discriminated because of the state of it, no self awareness. Some researchers in Europe brought in a new concept which is group privacy. It is hard to define and the group changes and the contacts, so let's not touch on that a lot.
But as I sat, currently privacy laws are very individualistic and they currently protect the individual only. But, with the data of the world and data technologies we know that the data collection is tilting from personal behavour to behavourial group data. And data technologies do it by collecting anonymised data which also complies with the law. So it's totally lawful. But it still creates problems and one of the examples to see this like to understand these problems is to look into the waste what you are testing. Here comes the fun part. What is waste water testing. The waste water goes through the pipes and it goes to the plant and there, researchers picks some chemicals to test, this is totally up to them and it it be illicit drugs, pharmaceuticals, bio markers, whatever you say, and then they try to understand what is the population that feeds those pipes, and then they measure the chemicals they want to measure and then they back calculate it to the percentage of those, therefore 1,000 people in a day. And these tests are normally being done in cities, so bigger areas, but we saw the special applications of schools, jails, festivals and clubs. For example, the portatoilets outside a festival in London were tested and no need to say the results. Also, the support events. A some researchers took this research into the ethical review reports and the ethical Review Board said no you are totally fine, you are not collecting any personal data so it's not intrusive, you are good to go. But also, like, our ethical review boards thought that it's timesaving, it's less costly because currently when people want to gather information about the drug use, they try having surveys and people lie on the surveys so it doesn't really work. As we know, people also do not know what kind of drugs they are using so it is important to show them like realtime drug characteristics, let's say.
But, even though it has some advantages, it also has disadvantages along with privacy concerns which I'm going to mention soon.
So, we know that different by these excrete different kind of chemicals and also the chemicals breakdown into other chemicals and when you find morphine in water you don't know whether it's coming from the hospital or somewhere else. Also, as I said in the beginning of my presentation, it's totally up to the researchers to pick the test area and pick the drugs they are going to test, and the history showed us that they tend to pick the poor areas and the drawings that poor people use. So this is kind of concerning.
And this is the map where currently this waste water testing is going on, but this is not a complete list so I might be missing a couple of spots.
And in those areas, my colleague and I picked three special cases to show how the collection of N M IS data could actually be harmful and we need to consider a couple of things before doing it.
The first case stud is Australia, and Australia is an interesting case study in a way to see how the research data could be used to harm people.
So, Australia started this drug committeesing programme in 2016, it's a three year programme, it covers a 65% of the population, and you see here the places. And what is striking here is that the welfare reform 2017, because in the reform the government said that oh we're going to pick two random cities in Australia and pick 5,000 people in that random cities and we're going to dug test them to give welfare. And apparently they decided to use the waste water test research results to pick those so‑called random places. This didn't happen because of other political reasons but it's a great way of showing how this data could be easily used to discriminate people, prevent them from applying for a welfare, and in this case, those people have actually no rights because this doesn't fall under privacy, so on and so forth.
And the second case is Turkey, my country. So, Turkey is a great example of showing how already existing public perceptions direct a so‑called objective research data research. So in Turkey, two years ago, everything started in this city, the second highest drug use city in Turkey. And then it stumbled. I don't know if it's safe because they picked two locations in Adana which are the most crowded ones but in Istanbul, what they did was to pick two areas with the highest crime rates. So, we showed, we see that even with the start, we already had this stigmatisation and pre‑existing thoughts in their mind, and what is important here is also how the media reflected this study, they were like oh my God like we have a lot of junkies in these towns, this is horrible. They also produced drugs, this is even more concerning, and of of course, politicians got involved in the research and then the media. So, we started seeing that this guy, provincial Police Chief of Istanbul, even though he is not a partner of this research, he seemed to be very active and if there is a meeting about waste water research, so he said that if there is ‑‑ like this research data will be used to find a crime and a criminal if necessary.
So this research is still ongoing. We don't know how the results will be used yet. But I mean, as a Turkish, I know where it could go.
And the last case study is MIT under worlds project. So, this case study shows a way of looking into the future of these waste water tests. So, what MIT did was developing this robot called Luigi, the former one was Mario, Luigi is the smarter one. What it does is to just travel in these pipes really with a remote controller, researchers can just push it wherever they like, and here what we really need to know is what those researchers who this kind of research tell. They say that oh if the manage to push the consensus a little bit high up, we would be able to get more accurate and granular data which would also raise the research quality but if you go here, you have the whole building. So this is really concerning, and I still have no idea how this is going to go. And as far as we know, this is point here, but there is not a concrete example there, it's still on the developing stage.
So conclusion:
Even though it's not a data on a specific individual, the data being generated by the group still poses similar harms that individual might have.
The second, even though the anonymised dataset do not fall under the data protection laws the outcomes or effects of the anonymised data is very, very similar to the outcomes that the data protection laws try to protect against. As I mentioned discrimination, social stigma and physical harm.
And data is on thought as objective. It's not. As we saw in this Istanbul case. Policy makers can use this data to back up their own political predetermined decisions, and more data does not necessarily create objective policies.
And lastly, we need better mechanisms to develop smart cities that will make positive changes for communities. Simply removing the collection of individuals' data does not necessarily protect individuals but it does remove their control over data. It is imperative to give back the individuals and the choice to those individuals.
Thank you I'd like to commence on questions.
JIM REID: Thank you. Any questions? Nobody? Well, I have one. Have you any indications that this data that's gathered might be getting cross referenced with other types of smart city IoT type data gathering exercises and cross referencing between the two to give you an even closer granularity, the sort of thing I was just thinking about as you were talking would be say for a bus network, to the bus network got sensors on it you say for example one hour after a particular bus stops at this particular location, there is a sudden strike in drug usage in the bus stop next to the bus stop. Could that sort of thing be done and has anyone given you knits thoughts about those kind of things.
ELIF SERT: It sounds quite possible to me, I'm not sure if it's converged with other IoT projects in this case, but I know that this research data was also merged with demand graphical data and also cell phone signals to detect the population, but it didn't go to very specific to say oh these specific individuals were there so they should be using drugs. But, they are trying to make this research data more quality by putting other data together, and as we live in the big data world.
JIM REID: Okay. Thank you. Sorry, we have a question here.
AUDIENCE SPEAKER: Hi. So ‑‑ Hugo Vincent, I am from Arm. We have seen in the last couple of years quite a lot in progress in regulating privacy for individuals. Are there any groups or organisations that are making progress around trying to define what kind of rights and how to regulate group privacy?
ELIF SERT: So, researchers are based in Europe are working on this very hard and they published a couple of books, even though you read the books, everything is up in the air, it's complicated. Because as you said right now we have this very, very individualistic way of looking into privacy. So, it is kind of hard to tilt our focus from individual to group, and like, privacy could be one of the solutions to tackle this problem but there could be other ones as well.
So, the group privacy term is still ripe, and it needs to get better would be my answer.
JIM REID: Thank you very much.
(Applause)
Our next speaker is also a first timer I believe at RIPE, he is talking about the operating system which I'm sure many of you is aware of is found in quite a lot of IoT devices.
MATTHIAS WAEHLISH: I am from Berlin and I am one of the co‑founders I want to give you some background by RIOT and why it should be useful to you.
Let's start with some numbers. 50 billions is a number of IoT devices that companies predict independently will be available until 2020. It's a huge number of devices.
To put this in perspective in the networking context. I mean these devices will be syncs, small syncs with low resources, they have different network access compared to a lap stop or smartphone, usually this network access includes very low data rates such as bluetooth or 15.4. Even though this network access is low data rate, access, it might easily load, overload the existing network connections just because of the huge number of devices. So think about you just need 600 K blue tooth energy device to say fill up a 100 gig or 476,000, 15.4 devices.
This number of devices, way below 1% of these 50 billions.
So, this is very important I think that you as a network operator now in the future which systems will connect to your network, right, otherwise you have, you are in trouble about debugging or when something goes wrong.
And this means that you should now in more detail which type of devices we're talking here, and the vast majority of these 50 billion devices will be so‑called micro controllers. They are very, very tiny computers that have everything on one chip, a CPU, peripherals, networking connection, and cards and so on. Very tiny and cheap.
So compare this. The IoT is a very, very vague term. Everyone understands something differently and IoT. You can distinguish broadly into two types of IoT devices. On the one hand you have high end IoT devices and on the other hand you have the low end IoT devices. High end IoT devices is everything, I mean that is more or less comparable with your smartphones, or your laptop. So, it includes processor capacities with gigahertz, 32‑bit, 64 bit, in terms of memory, the range is been mega byte and gigabyte. It consumes what's, it's usually connected to a power line, and the network access is also not lower data rate access.
The other end you have of the spectrum you have low end IoT devices also called constraint IoT devices. Constrained because they are limited in their hardware. As a process usually ranges around megahertz of processing capacity, you have very, very low memory resources, that means that you have only a kilobyte of Ram and Rom. Usually these devices are also powered by batly and as I said already already have very constrained network access.
And the high end IoT devices are not very ‑‑ I mean not very challenging. There you can run whatever you are already used to, Linux, maybe embedded Linux, some Android stuff. It's that bit boring, what's more having and challenging the low end IoT device.
Because of this limited hardware capacities, you have some trouble in terms of bringing software on these devices. On the one hand. On the other hand, a lot of the devices in the low end spectrum comes with proprietary software. Also communicate based on proprietary tree protocols. So, at the end, you will end up with some kind of silo architecture that are not really interoperable with each other. This is not the Internet that we know. This is not the Internet that we currently have and it is not the Internet that we want in the future. What we actually want is an Internet that allows for a full inter‑connection of devices end‑to‑end that that allows you with a software that you would like to run. And this means that these devices should come up with flexible software architecture and also allows for open protocols.
So, our perspective here is to be successful in the IoT on the long term, you need some kind of software platform on this low end IoT devices similar to what we have in the current Internet. And this means that you have some kind of operating system and this operating system should support a low resource fingerprint in terms of ‑‑ allow for interoperability, a lot ‑‑ it should allow to address a different number of hardware vendors, it should allow for full interconnection and it should be independent of a specific hardware manufacturer.
And this is the point where RIOT comes in place. RIOT is an Open Source operating system for these low end IoT devices.
Originally, RIOT was funded by three research institutes in Berlin, Hamburg and France. And the original core kernel of this operation was written from scratch, so it is not an adaptation of Linux or whatever, it was written from scratch in 2008 and as we developed a network stack based on IoT protocols in 2010 and actually went public in 2013, with this brand RIOT. And just to make this very, very clear, even though this project started as a research project, it is not a research project any more. It is a real successful Open Source project. Supported by a lot of people. Also America, Asia Europe and so on. Supported by companies such as Cisco, Fytech and other important players. It is also supported by hobbyists. I mean that's where huge diverse set of people involved in this.
So now, let me briefly give you some more details about RIOT in particular at the end about the networking stack.
To summarise RIOT in one sentence. Our objective is to be the Linux for the IoT. If you have a device that is limited in terms of hardware where cannot run Linux, then you can easily run RIOT. To give you the same benefit and comfort as you know it from the Linux world, which is different to other operating systems for this embedded devices, where you for example have to learn specific programming language or do not have a full network stack. This is different in RIOT. We support basic APIs, we support native C and we can full IoT networking stack which means that it brings you 6 low pan, IPv6, could he AP, and so on. Another important aspect is that it is completely modular, so you can easily change and extend building blocks. It is independent of a specific vendor, hardware vendor. It comes with a renice hardware construction layer which allows you to port it to different devices. Very important for the success of an open IoT, it comes with a very open licence which is a GP A 2.1 and to make it also clear, this does not mean that you are not able to combine this Open Source operating system with proper proprietary software. It is doable, so you can bid on top of this commercial business.
In terms of network capabilities, RIOT supports all these, and it also allows to you use these interfaces in parallel. There is a generic networking, GNRC from RIOT that we wrote from scratch. We support existing network stacks from LWIP, we support open WSN and we support some future networking architecture. And on the lower layer, we also support Loa 1. So everything that is important for this lower end IoT device to say interconnect them is more or less supported. You can use it out of the box.
So, then now let's conclude with some actual numbers. What you see here, about the performance of this networking stack, what you see here is a processing rate of the networking stack depending on the layers. And the protocol pay load. For the RIOT networking stack that runs on a Linux ‑‑ as a native port on the Linux. What you see is I mean the performance depends on the layer which is not so much surprising because on the upper layer you are less complexity, on the lower layer you are more complexity because you are more frame sizes you have to do fragmentation and so on. But you can easily achieve appropriate performance.
And to make illustrate this more. We also compared the performance of a low end IoT bot with a RasPi. It's nor us, the high end IoT device and you see also the straight line and you see first that the RIOT networking performances even slightly above RasPi performance and if you turn off some of the complexities such as acknowledgment and so on, you can easily achieve that.
So, if you did not hear about RIOT until now, you should have a look into this because I mean, this low end IoT devices will be a major part of the Internet in the future. And there will be some operating system running on this, and one computer in this case is RIOT and if you think it's a cool idea and you want for example to have such a nice shirt, you are also invited to the RIOT summit, it's a yearly get together of the RIOT community. This year it will take place in Amsterdam kindly sponsored by RIPE NCC and SIDN labs and Wolf SSL. Participating in the summit will be free of charge, we will have a nice social in Amsterdam and nice talks and also nice break out sessions, if you want to support this, click on this link. If you want to give a talk or have ideas how we should shape the summit, there is also a call for participation, feel free to give us your input. Thanks a lot.
JIM REID: Thank you. Are there any questions? One question from me then. What do you think is the next big thing that you want to do with RIOT?
MATTHIAS WAEHLISH: One very freshing topic is update. Automatic update of these tiny devices. You do not have a user interface, only network connection and this update should be preferably over the air and secure. And this is very challenging considering this low hardware resources and this is something that we are working on. There is one thing the other thing I said, you want to have an easy system to share applications and what we are actually working on is some kind of an app store as you know from the mobile world for these low end IoT devices.
JIM REID: Next speaker... he is talking about one of the activities that the Dutch domain registry has on IoT calls SPIN.
JETTE JANSEN: So, I have way too many slides and way too little time so I'm going to either talk really fast and just click with like a crazy maniac or I'm going to talk really really really fast and you are just going not to see any of slides because they dispeer too quickly.
I am here to talk about SPIN as the previous two presentations said the IoT is kind of a vague term. When I first started this project, I looked up what the definition of the IoT is and this is what Wikipedia said. I'm not going to read t this is the shortest definition I found. The global standards initiative, they have this definition, it is way longer and I trim E, they published an 86 page document and it didn't have a conclusion.
In my view it's kind of of simple. It's generally stuff that was in the network before and it can be even simpler and it's one big mess.
So, I kind of assume that most of you, since you are in this room right now already know that, and this is one of the symptoms of the problem.
So we were thinking, this is another one.
What can we do about this and we came up with this list and it's probably not even complete or not even close to completion, we can have better practices were manufacturers, better software libraries, international policy, regulation, certification and we can have market demand, so week try to make more market demand for secure products instead of just for features or we can guarantees bad actors at the ISP level. I have something more to tell but that later. Maybe we just educate the user or empower users?
Our conclusion initially was, yes. We need to do all of this. And then for various degree of we, we as in the entire world, the collection of societies, the people that work on the Internet and the people that make stuff.
But in this case, I am going to talk about empowering users, and that's why we started the SPIN project at SIDN, at the SPIN project, it's short for security and privacy for inhome networks and we researched and prototype what we call the SPIN functionality. For instance advising network traffic. That was easy to start out with. Just have an easy way to see what your devices in your home are doing and we are only talking about IoT in the IP sense. So not lower one or big. In the end those devices tends to talk to IP at some point, so, we are only worried about IP at this moment.
And then when you can visualise it, when you can see it you can think of automatically blocking the bad traffic while still allowing the good traffic. And since we don't want this to be a purely theoretical research project, we made a prototype. It's Open Source software and we developed it based on open WRT. It's available as a direct download image for specific G L INET devices but it's Open Source so you can probably compile it for most devices that can run open WRT. In the idea is in the end it will help protect operators on the Internet and the DNS operators like us perform DDos attacks by just making the home network safer and we do that by helping end users Chrome the security of their home network.
This is the architecture. I'm not going to stand still. That's too long, because it's ‑‑ I actually included it because it's a nice picture. The simpler way is this one. So, in general, we have a router that captures traffic. It sends it to, in an abbreviated form to an MQTT server, it hands it out to applications including visualizer. The next one is you use this as a separate gateway for your IoT devices. Because we can all expect computers to be virus protected and safe and computers are never hacked so we don't care about those. The real reason is we have these teen tiny devices and computers have too much different Internet traffic and IoT devices tend to be much more manageable.
This is what we have so far that looks like this. It's the visualizer that shows what DNS queries your devices do, but it also shows the actual traffic patterns. It is unique in the sense that most applications that do this either show DNS or they show traffic and then maybe if they show something more than IP addresses they just show the reverse DNS query and we actually keep track of the forward queries and see the only deputy packet inspection that we data networks it's only metadata, but it can tie the traffic data to the queries that it does. And I ran this at home when we had a first version running and I could see my television connected to all kinds of things that I expected, but it also connected to Facebook. I don't have a Facebook application on my television. I use Facebook on my phone, but not on my television so I don't know why it started contacting Facebook but I didn't like it and I wanted to block it.
Components are mostly written in C and Lua. But what I'm talking talking about here, is these several sub projects that its SPIN project is doing, once we got into this we discovered a number of fields that we wanted to do research on. So, the first two are about device profiles, so what our devices allows us to do and is there a way that we can specify that so they can block anything that they are not allowed to do. Then there is of course the always interesting nominally detection. Finally we have a thing that I'm working on that's called the incident report system. Some people call it the Telco API. The idea that they have some way to granularly stop devices from going bad without quarantining the entire network.
The proposal files. The conceptual is you might have some idea. So you have this basic profile that says social networks, Facebook, Twitter, whatever. Maybe you have a base profile called streaming sites, Nick Netflix and Twitch and whatever. Or maybe you have just a simple profile that allows a device to record milk. We'll get to that. Or a profile to download updates from a specific manufacturer or maybe you have a sort of reverse profile like don't spread mill a, that sounds like a nice Mo file. So if you don't have a device you can say I want to tie several different profiles to it. So for example, my television I want to attach to other sites. I want to download updates. If we have a fridge it would be slightly filter. Even, because it might even if I wanted to then it might be able to order new milk and download updates or in the more general way of not spreading MIRAI, please don't to any have I Russey stuff, please do the milk thing and nothing else.
So, that's still kind of conceptual and it's hard to imagine how do we actually implement that, luckily there are people at IETF working on something similar so we are talking to the people at the IETF about the draft that is currently in the works, in a sense manufacturers uses this description and their idea is that you can specifies exactly what your device wants to do and you can translate that specification directly into the firewall rules. I don't think that's useful for the purpose we had in mind. But, I am thinking of it as a very good basis for that. So, we have somebody looking ‑‑ well we wrote a small implementation, and we have somebody looking at how to actually automatically generate the data.
So, there is this tool called MUD and I have a master student that's working on this and he is looking into how much you can actually deduce around profiles from behaviour that you observe when you turn it on.
We have another project here that's called Lua MUD, it's a small thing written in Lua, I'm working hard on getting that into a full version, so if you like Lua and you are interested in MTU MUD, please check it out.
Have any of you ever been quarantined by your provider? Me too, several times, until I turned off my RIPE Atlas probe, unfortunately. But, the thing was that they never told me why they quarantined me. They said you have been quarantined, we saw bad traffic from you, go away and reinstall Windows, which did not turn out to be the solution and I already knew that when it happened because at that moment none of my Windows machines was turned on and I have 16 different Internet capable devices in my home and one that does window and that one had not been on for a week. So...
And I was thinking, maybe we can use this projects to find a better way to do that too. So, I looked at another initiative in the Netherlands, called the abuse Internet Exchange and they have a system called the abuse hub, and the idea there is that if an Internet service provider that is connected sees bad traffic then it reports that to the abuse hub. The abuse hub then reports it to the Internet service provider that originated that traffic and they can handle that usually by quarantining and usually by saying please reinstall Windows. I think we can do better, so suppose you have that home network and it has a number of devices and suppose the ISP does not say I'm quarantining you but it just says in the first place, hey, we have had reports about this abuse at this time to this address maybe you can fix it yourself and if you don't fix it then we're going to quarantine you. But if the home network has a smart router that keeps a little bit of track locally about what their devices do, then it can just block that device and report to the user, this device has been compromised it has been disabled until you fix it.
We wrote a prototype, it's not been released but if people are interested in that I can release it soonish and if people are interested in running a proof of concept, please come talk to me
Finally, we are also working on nominally detection but that's still in a very, very early phase and we are just putting up the framework to actually do some research there.
So please go try this out if you are interested. And more importantly, if you are interested in set something up a proof of concept with some actual user, we have currently a pilot running with 20 students and we are going to expand that to 100. But if you have some non student users, and you might want to think of setting up an approve of concept or a pilot, please concontact me or Stuart, and until that time I will be happily taking any questions if there is time for that.
JIM REID: Thank you. Any questions?
AUDIENCE SPEAKER: Hello. MATious. Just a small remark, regarding your privacy analysis of IoT devices are you aware of the work of the Princeton people.
JETTE JANSEN: Yes, the IoT Inspector. We haven't had contact yet, but we probably are contact them.
JIM REID: One question from me. I was fascinateed to find that you find your television was actually talking to Facebook. And I'm wondering if probably one of the best things for an end user to have would be something the equivalent of Little Snitch in a Mac which sits on the router and can tell you all the nasty and weird things that your fridge and your kettle is doing when it's actually dying out to the Internet. Have you done any kind of ‑‑ have you had any considerations about looking at that particular aspect?
JETTE JANSEN: One of the things I wanted to visualise was actually see that. We can only do it realtime time now it doesn't look into the actually data that this was sending because it would cause a who will new slew of privacy problems. That's one of the reasons this is a research project is we want to look into how we can actually efficiently report what kind of things your devices are doing.
JIM REID: I mean this is the thing I was thinking my mother, I would be able to give my mother something, she could sit at home and she would know that the TV is talking to Facebook or whatever, that would be very, very useful, and I think that would be a very useful thing in general.
JETTE JANSEN: It's still a bit of power user thing but that is the end goal of what we're trying to do here.
JIM REID: Great. Wait, sorry, another question.
AUDIENCE SPEAKER: I have a question on Jabber. And he is kneels baker asking what's your ISP that kept disconnecting here?
JETTE JANSEN: It's a local ‑‑ well, so, in the end, I'm with Zigo but it's not them, they have this desks that does my parliament building and it was not my choice any want this fire work connection that does this cheap desk and I probably shouldn't name them.
AUDIENCE SPEAKER: I have another remote participation. I just don't know the name because I still didn't ask. But I have a participant saying I want to mention that there are products on the market right now that do per device, parental control like FRITZ box that any end user can use can easily isolate their IoT devices or wireless.
JIM REID: Thank you.
JETTE JANSEN: There is many products and new and old and there have been a lot released in the last year. Most of them are still doing mostly parental controls or DNS block lists. There are smarter solutions ‑‑ yeah, noted.
JIM REID: Thank you.
(Applause)
Hugo Vincent from a well known chip company called Arm.
HUGO VINCENT: Hello everyone. Thank you very much for having me here to talk, it's a pleasure to be at RIPE. Can I just, out of interest, I am completely new to RIPE, I don't know a great deal about RIPE. Can I get a show of hands, who has heard of Arm? That's better than some places I speak at. That's good. We are somewhat low profile but our technology ends up in all sorts of places.
I am on the security group in Arm research and I'm just going to share a little bit about what we're doing in security for IoT.
Just briefly. Arm is a processor design company. We design what we call IP processing IP, we then licence this to partners who build chips around it. And originally we did CPU, but we do lots of other stuff. Over the last couple of years we have been getting into kind of web services and our platform for IoT as well.
The numbers are quite cool. So, Arm processors have so far shipped in over 100 billion chips. Apparently more than 70% of the world's population uses processors from Arm. And we're in well over 90% of mobile devices.
This is possible from a small British company because we are with a large partnership of more than 1,000 companies who work with us to develop this technology and get it into chips.
I come from a sort of embedded systems background, I have been around about seven years and I helped set up arm's IoT research group with two of my colleagues back in 2011, helped set up our business units around that now and I am currently leading our security research group.
Let's just talk a bit about security for devices. The other speakers did a great job of explaining the problem, especially the speaker from RIOT who really explained what we mean by constrained high end IoT. We tend to think of IoT a lot in terms of the low end because we think that's where a lot of volume is. For every sort of one high end IoT device there might be ten or 100 of the smaller ones.
So, just to sort of some general principles. Hopefully fairly obvious. Security is not a feature, it's a property of the system design, right. You you can get perfect securities, it's about managing risks and as a system designer you need to defend against anything, whereas the attacker only defines one thing. The attackers are crafty and the security measures you need to use to defend against that can be non obvious. And the result of this is sort of ecosystem level is this arms race, really like this term that some people in the community call the red queen effect from Alice in Wonderland where the red queen said to Alice, at that takes, in this place it takes all the running in the world just to stay where you are, and that's what working in security is like.
So, to give an example of some of the considerations that can be important in securing IoT devices. Remember these are very low cost devices, manufactured at large scale with a complex global supply chain. And security can come ‑‑ security can come from any sort of point a lodge that supply chain. I like this example because it's quite obtuse. And this is acute cryptonanalysis. Electronic devices need compass terse, it's an extremely low cost, component that's in everything. They are made like this, layers of ceramic, separated by a conduct err, and basically, when you put a varying voltage on them they flex ever so slightly by just microns and this flecture shows up in the PCB as well and this produces a really small sound. And the credits on the slide, many years ago, sort of noticed you could pick up the sound and actually, it might be interesting and so they started off with this setup, 1,000 dollar microphones all very carefully controlled, and they ransom you know, RSA signatures and you can see just from the sound certain things about what the Crypto processing is doing and through extending the sort of techniques you can eventually compromise the security of the system. That's all sort of layer red stuff, not very interesting. It turns out you can also do it with like a parabolic microphone from across the room. You can do it with a microphone built into a mobile phone. So, it kind of does matter.
And these are the sort of esoteric things as a hardware company we have to figure out how to try and solve to make the IoT a more secure place.
Security is really all about economics, right, what motivates the attacker. And really, it's about most of the time at least, notwithstanding some nations that attackers, it's about money. And you can use this as kind of a vehicle for reasoning about where the threats are coming from.
The way you approach this obviously is through threat modelling, trying to understand where they are coming from and trying to work out how to defend against that.
So, one thing I wanted to highlight here is in the traditional security community, I would say patching has been one of the single most important security mechanisms we have, right. Every single one that's found, sure enough you hear a short time later, hopefully straight away, if a responsible disclosure been done there is a patch available it, you fix it and everything is glorious, and this is true I think, but in IoT things are often different. So there is some challenges in IoT. Often an IoT device will not have any UI. It will not have any way of having someone accept a patch update. It would have to be done through a fully automated process and that could be while the device is in operation, so it needs to be fail safe and bullet proof.
Other things, and the technology, in the low end devices there is much less commonality in the technology. It's not like a standard Linux system where you use your package to update your SSL library or whatever. There is often bespoke work, we have to do engineering to take in the watch and make it work on your device. You need to test it. And because there is no UI and there is no means of recovery and there is not a human to go and fix things, you need to be confident that it's actually you know, the patch cannot go wrong. And so you have to reason about that risk. And then in addition to that, like, the colleague from RIOT was talking about earlier, there is also resource limits. These come from the cost of the device and they are going to limit the extent of patchability. And you know, maybe initially that's okay but over time, over the device as lifecycle, that can lead to unpleasant choices between either do we add functionality or do we incorporate the security effects or worse, do we actually remove existing functionality to incorporate security fix? Right. Those resource constraints not just sort of memory and processing power, they can also be energy. It's quite common that battery powered IoT like low power sensors and that sort of thing for a firmware update to actually consume a significant chunk, 20, 30% of the lifetime energy supply in that battery.
So, you have to be a little bit more disciplined about when you deploy updates and patches and sort of the cycle of oh, no we found a vulnerability, we patched it, it's fine. Is not going to work in the way that we are used to in other communities for IoT. It is nuns an important part that we need and one of the ingredients that we need.
Here is a nice example. This is a pacemaker. The last device you want security vulnerability in. The vulnerability was found, it was responsibility closed by the manufacturer developed a patch and they issued this guidance through the FTA in the US, the regulator of the medical devices. There is a couple offing this things in t I have never seen this in any other IoT device patching type cycle. But they have actually computed probabilities of this going wrong. And one of them down the bottom there is, you know, there is a percentage chance of complete loss was functionality of the device. And if you work that out by the number of patients who have this implanted in the US, that's actually 14 patients in the US who have gone through a high risk procedure, opened up their chest to put in the pacemaker, and you know, accepting the security patch might lead to complete loss of functionality of the device. That's not cool.
So, that's the problem. My colleague suggested, many of you will know him from his work in the IETF, he suggested I spend a few minutes talking to you about what we're doing around security in the IoT. Our business is split into two groups the there is IP products group which develops the Arm architecture and CPUs and other processes elements that implement that. I think it's worth spending a moment on nomenclature. The word architecture is one of the overloaded terms in technology. When we talk about architecture we're talking about architecture at architecture, which is the contract between the hardware and the software. This is kind of our core business. We developed that and then us and our partners build CPUs that implement that and then our partners build chips that contain those CPUs. And our architecture takes two flavours, there is what we all the A profile, which is you know, it has its origins in mobile, it's the vast majority of mobile phones. And it's also pushing into the other domains, like automotive and high performance computing and stuff like that. And the other side is M profile, these are the micro controllers, these are the part that I work on. Here are two examples to software you give you an idea of scale. This one is a commercial product that's used in volume today. It's from one of our partners, NX P, it's a 32‑bit micro controller with memory and not a lot of storage and clocks and power suppliers and basically it's a stand‑alone single chip system, it's 1mm on a side. That's golf balance for scale. This is not just a chip, it's a complete system. This incorporates I think three Arm processors, a radio, a solar cell, a battery, some sensors, it's designed for being implanted into an eyeball for medical monitoring of glaucoma. So these things can be small and ubiquitous and for that reason we're quite excited about the responsibility of IoT really getting to really as astronomical scales. She is court of devices anywhere there is a need for them we think they'll show up. Our growth curve in terms of devices, we're now at sort of over 10 billion devices better quarter, 5 to 10 billion devices per quarter, we want to ship another 100 billion over the next four years. So we like this trend.
That's kind of like half our business. The other half many of you won't have heard of. This is a new group called ISG, this is our IoT services group and this is a set of web services and IoT platform technology for helping people build IoT devices that are more secure and easier for and more rapid to develop. So we have a bunch of technology under M bed brands which provides services like security, firmware updates and that sort of thing. Our IoT strategy is kind of really leveraging that synergy between those two groups. We have got on the one hand, the deep involvement in the hardware that people are building and all of the chips that are being used for these things. On the other hand, these sort of emerging web services for supporting them in IoT. And so, we're putting in features into the hardware, into the basis architecture, and we have this thing called the platform security architecture that our partners are building chips for, and chips that implement this are basically have all the features that we think you need to develop pretty good level of security. Then our web services can sit on tomorrow top of them and talk to them and leverage those security features to do the device identity and device management.
So, if we extrapolate forth a couple of years, what is a secure connected device look like? This is kind of a sketch. So, there is going to be some hardware. And hopefully that's an Arm processor, maybe it's not some other processor and inside that processor there is going to be some support for secure execution, we have a technology called trust zone that helps with that. And that isolation technology allows to you split the software into sort of a retro S world and a more secure world where you have got tight control over what's happening. We have as part of our platform security a trusted firmware that goes in that there that supplies Crypto services, secure storage of keys and provision material, firmware update that sort of thing. Also in our CPUs we have got CRYPT heey acceleration and so forth, which is what I work on.
And tying all that together, and using those services and hardware, we have got our Cloud services that are providing identity and management service to the devices.
So, to wrap up. Securing IoT devices is still somewhat of a new thing. It's still fairly difficult, and it's as such mostly still done quite badly. We want to change that and we think there is a lot of hope on the horizon. Many the challenges that we see in securing IoT devices are pretty similar to the ones we know from securing other types of devices like PCs and mobile whatever. We just need to figure out to adapt them into IoT. For example you don't have a human in the loop, those sort of things. There is technology trends, macro economic technology trends that are still helping us out. Like Moore's Law is start to go slow down at the highen. It's still giving us this improvement in capability of improvement for the same costs. We are seeing trends and platformisation and increased commonality, and these will, I think, lead to better security, that will create economies of scale, reduce development costs and generally improve things.
We are seeing across the industry an increasingly widespread understanding of the problems and the solutions from the manufacturers from consumers, from government, and I think there is already a strong market pull for security, and if the market doesn't respond to that then probably regulators will intervene and that in my opinion probably won't be a good thing.
Many IoT devices don't have a human in the loop. This is also a liability but also an opportunity. Humans are as we know from the history of computer security, not always that sensible. They are on easily tricked and IoT devices are quite simple and I think ultimately this gives us the opportunity for IoT to be a lot more secure than what we see in other types of computing. That's a good thing I think.
Finally I just wanted to highlight this one thing that we're doing, you may have heard. Arm got acquired by Softbank about two years ago and they have a very big vision across the technology space and are investing a lot of money in all sorts of things and they have encouraged us to think over a longer timescale, and we tended to sort of think year‑by‑year before. They are now saying does 20 years look like? We have done a lot of thinking about that and what could IoT really unlock over sort of a 20 year timeframe and we think there is actually a really strong argument for masses and masses of IoT devices, 1 trillion of them in fact in 20 years that will together unlock all sorts of productivity improvements across the industry. There is a nice white paper that actually argues that will amount to 3% of global GDP, which is a very large number, as you might imagine.
So, if you are interested go look at that paper. It's quite fun. Thank you very much.
(Applause)
AUDIENCE SPEAKER: Alan from ICANN. I like your perspective for looking at it in 25 years because I'm thinking about updating those device and firmware over such a long period of time and especially they go dormant for many years so you are talking about having some route anchors or trust anchors, how do you manage trust anchors when the device goes dormant over that time.
HUGO VINCENT: That's obviously a big challenge. I don't know I could answer that without writing an entire thesis to answer that. I think, you know, I think the only way of doing it needs to have strong hardware identity and hardware router trust so that when the device comes back after being dormant for how long you have extremely high assurance it's still the same device and you are start reasoning on the Cloud side who is responsible for that device, has ownership changed those sort of things, and that allows you do a lot of that management without having to talk to the device.
AUDIENCE SPEAKER: Authentication has to go both ways. So it's one thing to identify the device, it's another for the device to identify what's coming to it.
HUGO VINCENT: As you say it's a big challenge. If I knew the answer to that I would be a very rich man I think.
AUDIENCE SPEAKER: Vesna, I speak for myself as a world citizen. So since you are considering very long term, 25 years, are you also concerned about sustainability? So, on the one hand, where are the materials for all these devices going to come from? On the other hand recollect the repsycho cling or the reviews, do you have any plan for that.
HUGO VINCENT: That's a fantastic question. It's one we think about a lot of just recently we wrapped up a research project looking at that. So, I don't think there is one answer. We are interested in the overall sort of global system efficiency and if you can use a device that costs some resources so save a lot of resources somewhere else I think that's the right trade off. We want to make the devices themselves as sustainable as possible. Minimising their energy. We spend a lot of research on energy for example, we are doing a the love work on ex creamily lower power processors that will not need a battery, will just be able to harvest energy for their lifetime. We're doing work with plastic semi‑conductors for example to reduce the energy input into the device compared to silicone, that sort of thing. Very important question I think.
AUDIENCE SPEAKER: Verizon nay: Would you be willing to give a presentation on that subject for the next RIPE meeting?
HUGO VINCENT: I would love to invite one of my colleagues who is an expert on that but yes, absolutely.
JIM REID: I think we are time for one more question.
AUDIENCE SPEAKER: Peter, if you find some solution for the trust anchor update problem, please tell us because the DNSSEC community is looking into it for like last ten years at least.
HUGO VINCENT: It's not an easy problem. Would love to, yeah.
JIM REID: Just before you go, I would make one observation, Arm is in a very interesting position in this particular market place and there is a lot of things you could do for good by example by encouraging your channel partners to have come signed of security framework for the live updates of IoT devices, and also perhaps maybe consider Open Sourcing some of that stuff.
HUGO VINCENT: A lot of our IoT stack is Open Source. Not all of it but a lot of it and I would actually say, not just an opportunity, I think we have a responsibility to improve the security.
JIM REID: Thank you very much Hugo.
(Applause)
Our final speaker is Sandoche from AFNIC who is going to touch on something which is touching the talking about numbering and the naming schemes for IoT devices. This might get one or two people have had or excited, not necessarily in a good way, we'll see.
SANDOCHE BALAKRICHENAN: I work with a .FR registry, so most of you who doesn't know about AFNIC, my company, we manage the domain name space for France, so wins we manage the naming partner of the Internet for France, that's why the title we have the naming community. The numbering community for example in RIPE, in the European region it is RIPE and you.
So, the idea for this presentation is that in IoT, we overlook the identifier part a number of times, we talk about security, we talk about privacy, interoperability, other issues, which are mostly overlooked. The presentation here will try to show what is the relationship between the numbering and naming community at the European level, how we are contributing to the Internet ecosystem now and future how we can contribute to the IoT domain.
So, this is a simple picture of how we communicate with the Internet. For example, if I'm using my laptop, and I want to access the website Wikipedia .FR I just type whatever, but my laptop has an identifier as an IP address and the, NTT of interest, what is the content of Wikipedia is somewhere in the Internet in the web server which is also identified by an IP address. So, in the Internet we have a communication which doesn't have any problem in each of my laptop and the web server are uniquely identified and the identifier is being constituted by some rules which we call naming something and it is an IETF standard.
Similarly, since we as humans we don't remember numbers, we use names, that is why the need for domain name, that's why we say dub‑dub‑dub dot Wikipedia .FR and we have a domain name system which translates to an IP address and these domain names has also been constituted by a naming thing and that is also standardized at the IETF. There are two basic identifiers in the Internet. One is the names and the numbers.
This was a photo that was taken during the IGF at last year at general owe a. So RIPE NCC and centres sign an MoU. All of you know RIPE centre a group of organisations like my company for .FR, for Germany and all these people constitute together and they discuss domain operations in this group called the centre.
So what is the contents in the MoU? The main points were that it says that we formalise the existing relationship between RIPE and centre. It means that RIPE and CE N TR has some relationship before, both the numbers and the names. They are the natural ‑‑ like the natural resources recollect the resources for the Internet, so, we as companies would benefit from these resources and so we have) an objective to contribute back to the Internet community because we went fit from them. Then promoting the use of IPv6 both the numbering and nailing committee do that. And finally, we have to tell, give feedback to the new policy makers, for example maybe at the national level or at the new level to tell them what type of policy they can do for governments, so these are the main features of that MoU.
When I say for the first time they formalise the existing relationship between RIPE and CENTR.
The top 1, 2, 3, 4, those some history about the numbering community at the EU level and the bottom shows the naming community at the EU level. So as we say, RIPE began as a big group of people who wanted to talk about IP network operations. They started in 1989, they formalised it in 1990. RIPE NCC got established in 1992 and became a separate entity in 1998. So, in case of the naming community, what happened was that, similar to the IP exchanges, people who are managing domain name operations, they wanted to formalise a group to exchange between them at the EU level, so they said that why not we do that under the umbrella of the RIPE. But RIPE consciously thought that they should be away from the RIPE members, consciously thought that they should not involve with the domain name operations, but anyway in 1997 many of them convinced many of the RIPE to create a tier Working Group and finally the 1998 the RIPE CENTR was formed and it became a separate entity in 1999. So this was the history but what we see from this history is that both of them were using different resources and identifier resources in the Internet and they had the same path until now.
So, we know that the RIPE members are mostly LIRs and ccTLDs, the CENTR members are ccTLDs. We have two different roles. One is for the RIPE address location assignment and routing. The domain for the ccTLDs, we have domain name allocation resource, so we make sure that the identifiers either the IP addresses or domain names are unique, we make sure they are available to the end users, there is no problem and we contribute by liaising with the standards, we contribute training tools and measurements etc.
So, until now, we have seen about Internet. We see how the numbering and naming community has a role in the Internet, and now we will go to the IoT part.
When I saw the slide of the dub‑dub‑dub dot Wikipedia .FR, the entity of interest was that the web server dub‑dub‑dub dot Wikipedia .FR, what is the entity, what does the IoT say? In the IoT we say that anything that is anything of interest could be connected to the Internet. So anything, me, you, or the Chair or the table or anything can be connected to the Internet. So, let's take an example here. Let's take the example of the could you here. The cow is an entity of interest for a farmer. Let's suppose that the farmer has been like 1,000 cows and what is interesting to him is that he wants to know the ovulation window of the cow. So, he has 1,000 cows cannot monitor it every time so he goes to use technology. He wants to use technology to know that. It is said that the ovulation window is 18 to 24 hours in a month or so. So in that window the cow, Yours sincerely more active so what he does is that he adds a pedomoter into the cow and the cow, the pedomoter will count, will send in information if the cow walks more than average, more than an average. So, for that information to be sent and to identify that cow within this thousand cows, we need some type of device. So on the right side we have the different devices which we use currently in the IoT. So this device can enable to identify the cow individually and also transport the data.
Now, in the IoT, we have, as we have seen in previous presentations, the IoT device are classified as constrained devices. So, in this case, it is not using IP as of now. It is using different types of of identifiers. So, there are silos that we have seen also in the previous presentations, currently even to they are connected to the Internet, they are not interoperable with each other, they are acting as silos. So, I will take two examples here, for example, one for the sense or devices and one for the RF I device. Boast of them have a type of identifier, and each of these identifiers also like the IP addresses the domain names have a set of rules on how these identifiers should be constituted. For example, in the consumer industry uses an identifier called E PC, electronic product code. In the case of the sensor devices, it might be EU I 64 addresses.
And these devices are also can be classified into two different categories, one is hierarchical, and the other is flat. For example let's take E PC, like the domain name system has one prefix, which is a country prefix, then we can have a product code, we can have a company code, a product code, seriously number like that.
The advantage with the hierarchical thing is that it is like in the DNS, so it can be a distribution ‑‑ it can be managed in a distributed manner, and there is a flat identifier, where cannot classify them into the categories, for example the Apple, unique device ID.
So, these are the two types of categories that we see in the identifiers in the IoT as of now.
Now, what happens when a non IP device, it has to connect to the IoT is what we say is that we connect to the Internet. When a non IP device connects to the Internet it should have a gateway. The gateway should talk the proper proprietary protocol the IoT is using, and it should restructure the packet and send it to the Internet. For that case, it should make some re‑ordering, processing, and also in case in it has to resend the packet to the device it has to know its state. So these are complex processes and in more if that, if the packet is encrypted, the packet has to be decrypted and restructured to, resecured in the IP data gramme to send it to the Internet.
So what we see is that why not use IP in these devices. The problem in using IP in these devices is that now cannot, IPv4 is mostly saturated, when we say IP and IoT, it's IPv6. So the IPv6 heard header is too large for the constrained devices.
So that is where the standards comes into play. In the IETF we have a set of Working Groups who are working on different standards to make sure that IP could be enabled in the IoT. Let's start from header compression, 6 slope an, IPv6 or local wide area, 1% area network.
So, what's it does is makes sure that the IPv6 header could be compressed and put into the constrained devices. Then we have other scenarios like how the data, how the packets are routed within these constrained devices. So that's where the ROA Working Group comes into place with the RPL, routing protocol over lower and... where we can have a routing and packet forwarding. Then we have like the ACT P, the qua for consent devices there is a core Working Group at the IETF that does that so we can communicate in the application level. Then we have network management, for example we have protocols like a constraint management phrases, we have object language, we have security, the detailers in constrained environments. We have authentication. So there are a set of Working Groups and protocols that have been developed so that the constrained devices can use IPv6 and can be, and can have end‑to‑end connection between Internet and the constrained network.
So the question is that will all the industries that is existing that has IoT will use IPv6? We are working with country men industry using the GS1 standard for a while and we found that enabling a standard called ONS it was very difficult for them to move to another technology because their industry has been in that for a long widely while, the technology the infrastructure is in place, so wall mart will use IPv6 as in the place of the bar code, it's not going to happen in like five or ten years I think.
So in that case, we can use the DNS, we say that when the packet comes from the constrained devices to the Internet gateway, it has a processing to be done and that onwards, that identifier that has been received from the constrained devices to a domain name. The example up there, so I'm taking like the flat identifier as well as the hierarchical identifier, the hierarchical identifier on the left is used by the consumer industry, the flat is the UI D. It's completely imagination, it's not there, it's just said that we can do that, transform them into domain name and send it to the Internet for resolving to the Internet.
What I'm saying is that there are already working on standardisations that has been done. For example, the top one we know, the E PC, electronic proposal that is being the identity identification schema in the product consumer industry, we see the bar code ID. The O ID and it is object names, it is not that it's the standard is there but it is not used in the real way but the standardisation is there. It uses DNS. Similar low we have O ID, DO I and all the naming services use DNS for resolving.
Now, what are the problem there? For us, forth numbering and the naming community, we have to start ‑‑ I'm not sure whether RIPE has already started thinking, but tomorrow there might be a scenario like in IoT service provider which asks about like 1,000 devices to be connected to the Internet, there could be scenarios like that. We should start thinking about that. Then also for us, the naming community, that could be impossible if things happen, well we could have a number of new TLDs for the IoT, we can see whether we could take all this load of the DNS and escapable security and all in the future.
So, finally, for concluding. What we have to see is that, just I'm taking a use case that I am taking part in the, where we are the local wide area network, we see they are using UI 64 as identifiers in the device, there are a number of issues, real issues coming for the manufactures err, so why not the community, our community go and tell them that maybe there are standards like this that is already there, why not use IPv6 for, as an identifier in the constrained network.
For the naming technology, we could use the naming services and we could push everybody to use DNS as a naming service, and also as usually, we could do more tools trainings, that is all part of the RIPE IoT charter.
That's it.
(Applause)
JIM REID: Thank you. Questions?
AUDIENCE SPEAKER: Marco, RIPE NCC. Very interesting talk, and we kind of spent time on this. From a RIPE NCC perspective, what our usual repair is be aware that the current model IPv6 addresses represent the network location. You take the device, you move it, your address is likely to change. Make it very unusable for identification. I understand we can change this. But that's also where confusion starts because from my observations in talking to people, a lot of people wanted both. They want a permanent fixed immutable identifier, and want to use that same identifier to deliver traffic to the device wherever it is. We can solve this, but as this IoT Working Group is concerned, as a RIPE NCC speaking, I would like to see some guidance from the community on what our future line will be. Everything is possible, but right now I spend a lot of time trying to explain the working of IPv6 as an network architecture and not as a permanent identifier.
JIM REID: Thank you. One comment I have myself is, it would be good if you could help us make some outreach into these other organisations that are doing work in this area. I get this sense of what the stuff in the IoT around the ideas of naming and numbering to do with that is we got ships passing in the night where we have got vendors doing one thing and the technical doing something else and regulators and government bodies doing something else yet again. It would be good to get a clear understanding of what the problem statements were and what the challenges were in these other sectors and encourage them to come along here and have a discussion with us. That might be very helpful.
AUDIENCE SPEAKER: Vicky Risk from ISC. Probably I'm missing something, but to follow on the comment about the IPv6 addresses indicate a network location, we do have a long history of using Mac identifiers, Mac addresses to identify a device interface, and there is plenty of room into the existing legacy space for Mac identifiers to over load them with a lot for information, is that something you have considered? I realise that these things are not all going to have an Internet interface.
SANDOCHE BALAKRICHENAN: I will take a specific use case, for example, in the Lora we used UI 64 is something like the Mac address, where our identifier for the device is considered as also in UI 64 and the identifier for locating the joint server which we all is also an UI 6 had. So, what I think is that for location for communication like in the computers, we can have a Mac type UI 64 address and for the communication between the protocol on the Internet, we could use IPv6. So that could be ‑‑ but there are inherent issues, we have to read more. It can not be told like that, we have to read more into that to see whether this would work as Marco said.
JIM REID: Thank you Sandoche.
(Applause)
Okay. That concludes the first session of the RIPE IoT Working Group. I'd like to thank you all for coming. My thanks also go to the NCC staff for all the help behind the scenes and today with all the audio visual help, with the scribing and of course to our excellent stenographer for the wonderful work you do throughout the RIPE meeting.
So with that I will close the meeting but before you all go, I would remind you that we have this session on IPv6 as planned to suggested for being used for IoT as ITU sees it, this will be discussed in the IPv6 Working Group immediately after the coffee break and that also goes back to what Sandoche was saying about numbering and numbering being tied to devices. So this I think is very interesting. If any of you particularly would like to know why we have having that discussion in the IPv6 Working Group, and what some of the issues are, please talk to myself or Marco during the coffee break, we'll be more than happy to fill you in with the details.
The IPv6 Working Group is in the side room after the coffee break. Thank you everybody.
(Applause)
(Coffee break)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
