IoT Working Group
23rd May 2019
At 11 a.m.:
JIM REID: Ladies and gentlemen, boys and girls, welcome to the IoT Working Group at RIPE 78 in Reykjavik. Could I please remind everybody that this session is being recorded and when you come to the mic to make any comments or questions, please state your name and affiliation so that the people following the webcast know who it is that is speaking, as indeed can the stenographer who is taking notes for the record of what is going on.
Before we get started today we have got a fairly packed agenda, we have ‑ I have a couple of announcements to make.
First of all, is the minutes of the last meeting ‑‑ the minutes of the last meeting were circulated in good time, and thanks to the NCC for preparing them. There will be no comments on the list so I assume the minutes can be approved (there have been) if nobody has any objections. I see silence, implies consent so therefore the minutes of the last meeting are approved. Thank you very much.
My other important announcement is that we at long last have a could chair for this Working Group, from AFNIC. And I am very glad there is someone else who can help me with the running of the Working Group. In that context, in case anyone has got any doubts on this, I will be standing down this time next year, so my job is always to try and get this IoT Working Group up and running, and once that's done is to fade into the background and so we will have another appointment process in a year's time and I am looking forward somebody else taking over. If anybody is interested in standing and wants to know more about the IoT Working Group please come forward to talk to us about what this is going to entail for them.
My other announcement is about our plans for a hackathon. So we are hoping to one a hackathon around about the time of the next RIPE meeting, probably on the Sunday before the next RIPE meeting starts. And if you are interested in what that entails or you have got any ideas about what we could use as a theme, please talk to us, and let them know your thoughts because again it's part of my submission for the future is to delegate to somebody else, find somebody else to run these things and I am happy to see both Constanze to get this thing off the ground. Time for me to shut up and get down to miss, the first talk is from Matthias ‑‑ my apologies, Patrik. It may have been something to do with a certain event that took place last night, I am not quite fully awake. My apologies. Patrik is going to gave quick update remotely at what was happening at the recent ITU study group 20 meeting.
By video‑link:
PATRIK FALSTROM: I could help to run the mailing list for the whiskey BoF. Let's talk about study group 20. I am Patrik Falstrom, technical director and head of security at Netnod and I will chat you a a bit about my view what is going on regarding IoT in ITOT.
So, as many of you in the room know, I have been dealing with this for some time, and I have been advise advising the Swedish Government for many years, starting around 2003 and specifically I have been part of the Swedish delegation at various ITU meeting.
I have also been the liaison from the IETF for a bunch of years so I have been working quite a lot with the overlap between various standards and organisations.
So regarding T I U‑T, have many study groups, it's one ‑‑ one can compare the study groups with Working Groups in the IETF but it's not really the same thing. Within each study group there are many questions and each is discussing a topic and that my result in a document.
What we have to remember when looking at the approval process is that this ultimately is a United Nations based process, which means each member have one vote. There is a slight discrepancy between different membership but we don't have doing into the details here.
What is important to point out, though, regarding this document is that there are two different processes in ITU‑T one is the alternative approval process that was agreed to around the year 2000, and that was just because people felt that the traditional process which is the other one is too cumbersome and the alternative process says that after adoption bay study group recommendation that do not require formal consultation with the Member States are considered to be approved. And then the question is of course what do you mean by "require consultation"? If a document do have regulatory implications, or if there is a doubt in that case formal consultation Member States are are needed and then the alternative approval process cannot be used.
In that case, the traditional approval process had to be used instead. Now, what about this document? The document's name is Y.4449 or IoT‑Interop and this text which you can read yourself, this is sort of the abstract or the summary that was put forward as part of the alternative acceptance process that was launched. It claims that it introduces the digital object architecture which handles a bit more and also talks about how security is added and how interoperability and security issues among IoT is, thanks to the use of the digital object architecture.
Weighed look at that in Sweden and a couple of other Member States and we, in Sweden, we recommended this to not be approved in the alternative approval process because of the history three reasons.
First of all it, it relates to TAP process need to be used.
Secondly, that even without the default route TAP should have been used because these do have regulatory implications and policy, because the implications on deployment are IoT.
Third, we thought the document was just crap, in plain English.
To be a little bit more technical, the document mixes requirements with how DOA is fulfilling those requirements and from my perspective if this was in the IETF, this would have been requested to be split into two documents, one with requirements and the second one how DOA is fulfilling those requirements and then you can have other kind of architectures that is also trying to meet all of those requirements.
So these are the three main reasons.
Sweden was not the only one that objected, we also had other Member States object, Canada, Finland, Australia, Czech Republic, New Zealand, Norway, Orange, Sweden UK and United States and Denmark, and orange is not a country.
So, what is next? .
Well you have this document ‑‑ got a lot of push back but the study group chair still wanted to run it this through the alternative acceptance process. What is needed that Member States had to be at the study group meeting physically and object and later file these objections formally from the members you just saw the names of. So there is a slight risk that someone will try to push this document once again through an AAP if it's the case that the study group meeting is in a geographical location which people cannot travel to or something else. But it is pretty clear at the moment that the push back SG20 is so strong not even medium changes this document will fly.
In the other hand in SG20 there are many other proposals including from China talks about DOA and block chain for smart cities. The issue here is SG20 is the default route for the whacky proposals. We had these kind of things in other S Gs in ITU‑T 20 years ago but those issues were worked out and ironed out and we have generally good cooperation through all the other study groups but SG20 is dangerous so watch out. Thank you.
JIM REID: Thank you very much, Patrik. Any questions or comments from the floor? Apparently not. Just one thing I would like to add and in thanking Patrik for his contribution. You might all be happening what happens in an organisation the Geneva doesn't really matter. Well, that's really not the case, because if some of this stuff comes out of study group 20 in particular it will almost certainly be enacted in national legislation and at that point there will be a requirement for vendors, manufacturers, and systems integrators and stuff to comply with an ITU recommendation so this stuff could then end up being in your kit. This could end being in your equipment and the stuff that is going around the world. So even if you don't think this stuff is all that important it would have good to have a conversation with your country's ITU representatives or your government or your regulator or whoever it is that goes, and at least explain to them what the problems might be, it's not just about DOA, as Patrik points out, much as DOA is very important but having that conversation will at least alert the officials to know what is going on. Thank you very much Patrik.
(Applause)
We have obviously, we are using remote connections and at the mercy of the Internet gods, things don't always work out for that as intended. I apologise for that. Matthiass is next up to talk about ‑‑
MATTHIASS WAEHLISCHMATTHIASS WAEHLISCH: I am one of the co‑founder of the RIOT operating system. What it is about, when the RIPE community talks about the IoT we do not consider the large platforms but small hardware platforms because these micro make up the huge amount in the me future. If you compare the spectrum in the IoT you have ‑‑ or even mobile phones and this is not address devices and this low end IoT devices have much less hardware resources compared to the high end. Still, to be successful in the IoT in the long‑term you need an operating system running on this IoT devices to enable flexibility and dual functionality and this is where RIOT kicks in, it is an operating system for constraint IoT devices, operating source based on grass roots community.
So basically you can summarise it in one sentence: If your IoT device is not capable to run Linux as an operating system, you should use RIOT.
And the RIOT operating system is based on continuously growing community and we have more than 100 active developers contributing to this operating system. It's started in 2013 and it's continuousry growing. As it's a bit boring to just communicate via e‑mail to blame your fellow writers about bad requests, digitally, we organised since a couple of years, a yearly get together of the RIOT community and summit, last year it was the first time not organised in Germany but in Amsterdam, and thanks to our sponsors, this event was also free of charge and a special thanks to RIPE NCC and Mirjam and Marco who helped us as local logistics in Amsterdam.
Last day we had roughly 90 participants from Europe, US and Asia. That is a bit below compared to previous year, maybe because of the higher hotel prices in Amsterdam. As I said, participation is always free of damage because we want to be an inclusive community and lower the barriers to attend.
How does this summit looks like? Usually it's a two‑day event, the first day kicked off by keynote talk, and this year the keynote talk was given by Jamie, who is a master research at Ericsson and Working Group chair of the consent Working Group in the IETF, and he was talking about how to do ‑‑ bring Open Source frameworks and commercial products together and he nicely illustrated that being successful in the commercial business does not conflict with using Open Source software, in fact I mean, if you want to be successful long‑term with IoT we need to have somehow open ecosystem.
Furthermore, in addition to the keynote talks we had 12 talks given by RIOT and non‑talking about IoT incoming and applications and security and ethics, the last talk was given by Vesna from RIPE. Waives good mixture of practical insights from a technical and non‑technical point of view.
We also had a lot of demos illustrating and show casing how to use RIOT in practice, and the second day was mainly composed by tutorials and break out sessions so we had the beginners and maintainers so if you are a been invited good opportunity get easy overview on how to start with software system. Break out sessions were mainly dealing with testing, so operating system because we currently ‑‑ I mean, one important objective is to have a reliable system so we put a lot of effort into testing and testing infrastructure, which is not easy if you consider how many different platforms we have in this IoT world and testing all of these platforms is challenging. Important topic was update to allow secure update, cooperation task force and obviously stuff that relates to the maintenance of the system. And in addition to the talks and demos, we had even more discussions during the breaks, but also at very B B Q, very nice social and so went quite well and long, not only with beer but as I said also including very in‑depth technical discussions. If you are interested in more details, there is a RIPE Labs article about us, LinkedIn this presentation.
And I know you are wondering this is a cool event, you get free technical talk nice discussions and even cool T‑shirts, how can I join? When will it take place and where? This year, here is the answer, it will take place September 5 to 6th, this time in Helsinki, it's a larger area. We already have some sponsors but we are looking for more. If you are interested to support this event, go to the website or contact me off‑line. If you are interested to give a talk or present something or have other input go to the RIOT summit website. And I hope to see you there.
JIM REID: Thank you. Are there any questions or comments or feedback? No. Thank you. Next up, Mirjam Kuehne ‑‑ going to talk about some of the legal aspects and policy considerations for running some kind of IoT network, in this case obviously it's to do with the right Atlas network.
MIRJAM KUEHNE: So I gave this presentation and Matthias and Vesna gave it at the RIOT workshop, maybe this is something I could briefly present here even though a lot of you are probably familiar with RIPE Atlas but maybe not with the underlying considerations that went into the infrastructure and the probes and all the technicalities in the background, so I thought I might go into a little bit of details kind of as an example for thousand do this maybe for other IoT devices as well.
We started this project in I think 2010, IoT wasn't really a thing yet but if you look at it it is in fact an IoT network with all these little devices that we ask people to put in their homes.
Let me go through this. How many of you here have a RIPE Atlas probe in their house? Right. So you do know what RIPE Atlas is, I don't have to explain that. It's a large global infrastructure of those little measurement devices, I don't have one here but I think we have one person ‑‑ my colleague, she has some at the desk.
Just maybe to set the stage. There are a lot of use cases and people using RIPE Atlas for the most diverse analysis and studies that we didn't foresee in the beginning when we started this, which is great. So people are measuring network distributions, cable cuts, also they are using it for censorship, measuring DNS, and they are also using RIPE Atlas to monitor connectivity, where to put caches in the network and to go to their ‑‑ to get closer to their customers. So, we have seen a lot of use cases, mostly these articles or these links they are all pointing to articles on RIPE Labs. If you are interested, there is a whole page with RIPE Atlas related studies.
Just to give you an idea, I mean there are over 10,000 of these probes out there right now and we have 400 RIPE as lass anchors which are these larger probes that have a bit more capacity, can do more measurements and can also use this targets for measuring ‑‑ for measurements. We have cover over 80 countries and 5.6 IPv4 ASs, 9% IPv6 ASs, still some work to do, you can see on the map obviously a big focus or consideration of probes is in the RIPE NCC service region, we are still working on covering other parts of the world with more.
And there are 7,000 measurements done per second, which is kind of capped and stored by our underlying infrastructure or back end.
So when we started this, and I see, I think some of the developers in the original person who has ‑‑ had the original idea in the room so if I miss anything or you have any questions I am sure they can answer them, probably much Bert than I can. One principle at the beginning was if you wanted to make it as easily accessible as possible, so you didn't need to sell these, small, low battery use or low power use, cheap, we wanted to give them out for free, and we also decided that they only do active measurements and not do any traffic or content measurements, anything like that.
We also decided to make all the data in the API and the tools based on top of it like for free and open, and also a big discussion we had at the beginning, we started with a very limited number of measurement types, and we added some more later on, and we had quite a discussion on the http measurements and I have a separate slide on that. And which was interesting because what we also did from the very beginning was a very strong involvement from the community, I remember when we started we had bi‑weekly calls and people we had, online calls with people who were in early adopters of the project, like pioneer users, they gave us feedback about what works and doesn't and that is still going on. There is quite an active mailing list where the community discusses issues and use cases amongst themselves and the RIPE NCC is there to answer questions and help people.
So that really worked out very well to have a strong feedback mechanisms from the start.
The whole RIPE Labs project basically was also set up a lot to facilitate this community involvement.
So in addition to these design principles there were also ethical considerations, for instance the http measurements that I mentioned earlier was a big one and there was a big discussion on the mailing list where people wanted to have, you know, thought this would be perfect device, also project to do http measurements to various targets and destinations, and others, including the RIPE NCC also felt that it could potentially put the hosts of the probes at risk. We are asking people to put some hardware in their network in various countries all over the world and you can use those people's hosting ‑‑ probes to initiate measurements to other destinations. So not only your own probe but also those other host' probes so it's all accessible and didn't want to put people at risk there, so you can't measure against a website that might be illegal in that person's country. We compromised and said well, we can use http measurements towards Atlas anchors because very limited number of them out there, they are aware of the risks and they agree to those. So that's currently the case.
And also, the first point maybe is interesting that we don't do any traffic on bandwidth measurements because first of all there are others who do that, and we didn't want to kind of eat into people's bandwidth limitations possibly. So the number or the type of measurements that we are now providing are very small, so they don't take a lot of bandwidth or power or anything.
And we also said together some time ago specifically with the focus on research also because a lot of researches are using RIPE Atlas for studies and we said together with a number of people and wrote down the ethical considerations and maybe people, it's a link to to another labs article there that we published at the time to basically say hey if you use RIPE Atlas please take these into account so that you don't put any people at risk.
I think this is all I had about this part.
We are doing some other things as well, like regular security audits and constantly reviewing those probes. And I just have a few slides on securing the probes in the back‑end and I don't know too much about that so last time I gave this presentation when of my colleagues did that so if I get anything wrong I am asking whoever is in the room, I don't want to put you on the spot, but please help out.
So the architecture is quite an architecture in the background that use these probes, they are not standalone and go through all initiation process and they have Trust Anchors and then they get linked to a certain controller in the back‑end and the controllers also know where these probes are and so we have quite a good idea where these probes are and what keys they have and can communicate with them. So I don't want to say a lot more about this. This is all documented also on the website.
The main point really is that if you want to limit consequences. If something goes wrong we know how to isolate these probes so obviously we discourage kind of tampering with these probes. It has happened obviously but if it happens we can we can isolate these probes. They don't create harm for the entire network or the surrounding probes potentially. So, what it says there, basically, we try to make them as cheap as possible, as I said earlier so we kind of built them ourselves and make ‑‑ know what is in there, in the probes. And sometimes we lose probes, we also looking for abnormal behaviour in the networks, we kind of have some filters there in place, using off‑the‑shelf firmware that we then replacing with our own firmware and constantly updating that as well. And we are doing a lot of testing before we send out these probes. You should see how they get assembled in the office, it's like a big kind of electronics workshop where people are putting them together and testing them. And then as I said earlier, they also have these individual keys that we can identify them with.
Yes. So the third thing may be interesting, we do kind of a lazy firmware updates, whenever they connect back to the network, they get up dates. Or but we can also force these firmware updates if something really needs to get out, if there is a bug or some security issue, then we can also push that out.
What else do I need to say here? Of course, in the last point might be interesting is even though some of these probes look like they can do other things, they use the previous version were access points but we took all the wireless access out there and they are not ‑‑ you can't do any other services then, it's not interface to interact with. So they all kind of goes through the network on to these probes.
At the moment they look like this. This is the new version, a little black boxes. Literally. Because we hope you cannot open them. That was one of the improvements and also as you might remember the last version had some issues sometimes with the USB sticks that were on the side so these ones are different, they don't have USB sticks on the side any more. And as I said, each of them are they cryptographically verified so they all have individual keys.
And this is basically a quick run rundown what we realise is that it's actually it could be quite nice best current practices for other IoT devices as well and there is an Internet draft, the IETF that was published within the IETF framework which I believe is out of date now, what's the word?
JIM REID: Obsolete.
MIRJAM KUEHNE: It still has some interesting guidelines in there and we were pleased to see it quite matches with what we would be doing as well in the RIPE Atlas infrastructure. And there are some labs that explain all this and the ‑‑ Robert, my colleague ‑‑ Robert Kisteleki who can't be here, if you want to know about this, a bit less wobbly than my presentation then you can read all this there on the RIPE Labs. And yeah, that's it.
(Applause)
JIM REID: Thank you. I think the very good to get this kind of input. Are there any questions or comments? Kuhn don't spare me, I can find out if I don't know.
AUDIENCE SPEAKER: For how long has it been running and how many generations of probes has there been.
MIRJAM KUEHNE: The project runs in 2010, and I believe in we are now in fourth version of probes. Yeah.
AUDIENCE SPEAKER: Chris speaking for myself. I looked up, there is a businessy box online from the probe and all the BIZZy box was published and that's odd, so all the rest of the software for the probe so whatever you write here nobody else can ‑‑
MIRJAM KUEHNE: Interesting, I forgot to mention that, all the source code is available as Open Source.
AUDIENCE SPEAKER: Not all the source course. Just BIZZy box.
MIRJAM KUEHNE: I don't know. There was actually decision we made together with the community to publish the source code. But ‑‑
AUDIENCE SPEAKER: We can help with that.
JIM REID: There was a recent document published by the UK Government consultation on IoT devices and there was aspects and firmware updates for those devices. There is a lot of discussions on these particular topics but one ‑‑ there isn't a clear place doing and find that kind of information or advice, you could point at a single document. So I have got a investigation for Mirjam and her colleagues in the NCC is, perhaps these requirements and design decisions are put in a simple self‑contained RIPE document that says these are the requirements you need for some kind of device or for IT device or network where you have got to have theality to have reasonably secure access to them, securing the firmware updates and so on, I think that would be very, very helpful because at the moment we don't really have a single one place doing and get that kind of document, there are bits being done in the IETF and study group 20, there is bits being done all over the place but there is no one place we can find that kind of information. And now we have got a couple of more comments.
MIRJAM KUEHNE: Maybe it would be great if this Working Group could help with that.
JIM REID: Absolutely.
MIRJAM KUEHNE: I would love RIPE documents produced by the community and not necessarily by the RIPE NCC.
JIM REID: Definitely yes.
JAN ZORZ: This would be a great topic for the best current operational practice document.
MIRJAM KUEHNE: Could be, yes, yes
JAN ZORZ: In Rotterdam we will have a session on Monday evening and you are welcome to the agenda.
MARCO HOGEWONING: A question for brief clarification. RIPE NCC. As my colleague Mirjam said, that is certainly something to look into but we would rely on input from the RIPE community, but also to clarify, are you looking for technical implementation specs or as you make reference to the UK, because I basically yesterday got another slide forwarded that listed at least 15 European directives that have something to do with IoT but then you can inter scope like medical devices in something so I would be a bit or worried for us to delve into that because that is going to be very, very deep.
JIM REID: I was not thinking to do something to that kind of extent expressing the high level principles and I hope that is something members of this Working Group would help produce. I shouldn't be talking. Next up, Daniel.
DANIEL KARRENBERG: So, speaking to what Jim' suggestion about should we make some recommendations as RIPE ‑‑ and to what Marco said ‑‑ to echo what Marco said I think we should think about limiting the scope in a useful way. And here is an idea for people to think about: We are a club of mainly classical Internet operators and I think we could limit the scope a little bit by saying here is what you do to your IoT devices or their gateways or whatever you call them in order to minimise adverse effects on the Internet infrastructure as such. Like, you know, cameras that do DDoS and things like that, if we limit ourselves to that scope I think we can make a useful contribution, just a food for thought.
JIM REID: Thank you. Thank you, Mirjam.
(Applause)
Our next speaker is Jan Zorz, and not only interesting ideas about what is happening with IoT, strange things to do with the electrical wiring regulations in Slovenia.
JAN ZORZ: Thanks Jim. I work for Internet Society but this presentation is on my own behalf and the views here does not necessarily reflect views of my employer.
With this out of the way, a couple of months ago, right, was it Prague IETF meeting, where Jim and I decided it's a go idea to sit down in a beer and have a chat and it comes to a topic that I am building a house and then Jim was interested so what are you putting in your house, I am sure you will be doing it in some IoT way, I said of course, I am a geek and an engineer, right? He said, can you put your thought process in how you experimented with this stuff, can you put it in a presentation and present at the IoT Working Group? I said, well, okay, if you insist. But I said, what can I possibly talk about for more than five minutes and then I started making slides, and now I have one hour worth of material here. So, I will try to do it in 20 minutes, so I will go very, very fast.
Lets start. This is my new IoT lab. And it looks pretty much like a house, right? And what to put in here. You start here, you start thinking about how to make it smart, how to automate it and you would like to build a smart house or IoT enabled and then you have two options: You outsource it and do it. I have seen offers for amounts of money crazy completely that would make your house smart, but then what I don't like here is that it works in a way that the vendor sets it up, you don't have access to the rules or you need to call them to set up new rules and then you need to adjust your life to match the way how the vendor envisioned the smartness of your house, or, you decide that your technical experimental skills are up to the task and you will build the whole thing yourself. Okay I decided to build it myself, obviously, because I don't have that money for to buy something that I can build myself and it's cost would too much money and it's much fun, you will learn a lot through the process, as you will see.
Warning: It consumes lots of your time because you need to experiment a lot and test a lot of things and things fail and you would like to throw the whole thing into the corner and give up. Don't give up, go through the whole process. IoT is a wild wild west. When you come for the first time, everybody is trying to sell you everything, right? Think about it. Think about what you really, really, really need.
Okay. First thing that I had to decide was the architecture of the system that I'm building. Right? Or should I buy cheap sensors and actuateers that connects over the Internet to unloan Cloud intelligence somewhere in the world and let my home environment be controlled and measured by random folks from the Internet? Do I really want to do that? Or design sensors and actuators around home gateway that doesn't talk to the Cloud but uses local intelligence and keep controls and data in my home inside my home. Which one would you choose?
AUDIENCE SPEAKER: Trust the Google.
JAN ZORZ: Trust the Google, trust the Cloud, right. I don't want random people from around the world to open my front door locks or to set the temperature of my house just because they can. I don't want to do that. I decided that this is not a good idea.
Next question: Some home gateways are not very smart and uses remote intelligence in the Cloud to control your home environment, should I use them, yes or no?
AUDIENCE SPEAKER: Trust Google.
JAN ZORZ: That's right. I decide for no obviously because there are home controllers that talks to ‑‑ uses external intelligence to do everything, so, you know, if you did you decide to use home controller and use of them you didn't do much.
So, what to use then? Raspberry PI or Linux system with Open Source home automation control system software or some vendors' boxes that supposedly don't talk to the Cloud? What would you use?
AUDIENCE SPEAKER: Obviously B.
JAN ZORZ: Obviously. Except not. For experimenting, I used Raspberry PI with Linux, I said okay this is a controlled environment, I set up my firewalls so people cannot talk to my controller, controller cannot talk to the outside, okay it can talk to the up state services but not to everybody. And then I said okay I need to control ‑‑ I need to connect something to it, what do you do?
For first experiments I used Z wave and Zigbee USB controllers, I connected them and went out and bought some samples. As it turned out later, when you start building rules, when you have a couple of rules for your home your Raspberry PI is fine because it's cheap and has 1 gig of memory. As you start building more complex rules this little device starts to choke so I figured out I need something a little bit more sophisticated and powerful. So I decided to go for desk mini PC with I 5 processor, two disks in mirror and 16 gigabytes of ram and you go into Linux and home to, that this device will cope with the whole thing. So this is my experimental device with, you see here, this is the Z‑wave that talks to USB devices and this is my new and shiny box that will go into my house or IoT lab when we actually move in.
Okay. Then, we have hardware, what to do with this? Right, automation software dilemma: What exactly do we expect from this IoT stuff? Are we doing this just because neighbours had it or our colleagues have it or we really need it? What are we going to do with it? How are we going to programme the rules? What kind of interface do we expect? We need to ask ourselves first what are we going to need this for? And before testing the software decide on the sensors. If you try to test the automation software without anything connected, it will not be very useful, because you will not understand what this software is doing. So, buy some samples from different technologies and connect them and just play with them. I tested Z‑wave, Zigbee and my testing is, see, this is the Zigbee controller, USB, it comes somewhere from France, I believe, because the user manual was in French. For whatever reason. This is a temperature sensor on Zigbee, this is the Z‑wave device motion sensor, temperature, humidity, whatever you can measure. This is my Z‑wave controller, and this is Zigbee, stuff that you put under your washing machine if it starts leaking, this starts screaming and the whole thing goes off. This is the door sensor so I get notice whenever somebody opens my front door, I know, so I know when people leaves my house and comes back.
So, buy samples, connect them and play with them. It's nice and fun. And it will use lots of your time you will learn a lot.
Okay. Automation software dilemma continues. I tested more than ten of them, including all of these. And then with testing them all, I started to understand what I need. I had no idea before what I really need and what I really want so go, test, test. And test. Did I mention test? Yes. Okay.
So, which one to choose? It depends on what you are looking for but after you install and test all of them, you will understand. I was in the end torn between open HAB and Domoticz, but then I decide for Domoticz, it's my completely personal it has slightly better rules creation because I want my children to be able to write rules for their rooms because there will be some devices in their rooms and I want to control their rooms on their own. They are smart enough. These children are very smart these days, believe me, you would not imagine. But it has a bit older interface, the interface is not very modern but, you know, can't have it all. But I suggest you go, you test, you decide.
This is the Domoticz with one additional skin. It looks like this, you have couple of devices in it and you will be done. These are some graphs from from some temperature in my kitchen and these are the rules. They implemented blockly, this is the way how you just create rules with just dragging blocks one into another and automatically the rules appear and it all starts working and looks like and pretty and it's easy for kids.
Now what? Well, testing testing and more testing, as I mentioned. Until you are happy with your decision and you get enough experience to understand what you need and expect from your system. Don't be fooled, reading about it doesn't give you any experience. You will still have no idea what you need. Try it. Practical experience is what counts.
Experience and stories. Z‑wave sensors can store settings, scenes and things that you would not imagine. At some point it became scary when one of the home controlling software started storing scenes into Z‑wave sensors around my house, and at some point in time, it's the IoT ‑‑ it's the ITU made protocol and it shows a little bit. It's slow. And its proxy doesn't work. Well, okay. The thing was that I refreshed the SD card in my Raspberry PI to test another software and the machine comes back with the flash, with the completely new software without rules and as soon as Z‑wave devices around my house connected back to the Z‑wave controller on USB, the whole thing started working as it was before because previous settings were stored in the devices, do I smell security issues here? Probably. So because if things goes wrong and you disconnect you power off the home controller, the whole system will still work as before. It's fast but I am not sure I want that.
The Z‑wave sensors and actuators that are not directly reachable by controller they connect over other devices and this tends to be slow, so you may experience, if you have one or two hops between, that you press the button and your light will go on in like one minute or two, that's not very ‑‑ that's not very useful. In my personal experience, Zigbee sensors, it was developed in IETF and this is fast, lightweight and it works. So, currently I have little better experience with Zigbee.
Okay. Z‑wave sensors are much more expensive because it's licensed and a little bit more expensive. This is my ‑‑ this is the installment in my electricity box to control the lights. 11 dimers, they are on Z‑wave because I couldn't find Zigbee ones. If you try to go this way, be aware ‑‑ make sure your electrical wiring is correct because we had like two days of debugging with the vendor because they were connected correctly but not. If you mix the phases in the electrical wiring then you might get into troubles that you would not expect.
Okay. Start creating rules and scenes and you will learn how those things works and every rules engine has its own way of interpreting things. You will have to learn each one and any of them.
And now to big Jim's amusement, when Jim saw my slides he came back with an e‑mail: Are you crazy, you have 3 phase electricity in your house, what are you building, a factory or something? No. But look, this is my electrical box in my house, and you see here I have three phases and Jim was oh, my God, really seriously? This is a default in my country. But you really want to understand because this is all depending on the electricity, you really want to understand how much current you are drawing into your house because you want to know, because we measure things. So, I decided to look for a cheap passive measurement system that measures the current and I couldn't find one and Raspberry PI seems a good way how to measure things and I found a very cheap one phase current meters that you can talk to them over USB and it works currently I am busy assembling it, that is my desk at home, this is the enclosing, this is the Raspberry PI, they took over USB, basically it's a mud bus over USB and I will put them all together, I will measure through ‑‑ I will read the measurements from this split coil transformers and I will store them in whichever database of your choice RRD or whichever you want to do, and print the graphs.
That's it.
Second thing: Battery‑powered sensors, you have these motion sensors around, and then you are good for one or two years and then the batteries start dying and you start running around your house and changing batteries, I said hell no, I am not going to do that. I don't like batteries. So, isn't there a device that would do all this stuff and have Internet connector that can be powered overpower over Internet because we have this magical power over Internet so I couldn't find one. We decided to build our own, my nephew he is a developer and also hardware developer as I am also a little bit, and we decided to develop our own POE‑powered sensor so the CPU we chose is the STM 32 F030 cc. It has enough RAM and it's cheap. Ethernet port, you would not imagine that the biggest issue that we had was with some hardware was it doesn't have Mac address pre‑configured. I never thought it would be an issue. But is is an issue. And POE is wild wild west. Again, it's crazy. I would never expect that this is so hard with POE, but we managed it to work somehow. This is our first board we put together, the processors and this is the final design of sensor that will be hanging from the walls in my house.
So, after couple of versions, the smoke tends to escape from these devices and it did, it's a proven fact. It's a magic smoke that went out. We put the smoke back in the new version and finally it started working, we can now talk to a device over IPv6 and it is responding.
It will be IPv6 only, it will have POE. We will implement MQ TT and web of things to communicate with the device and that's lots of works I had but, you know, it's an experiment, I hope we will pull it through, if interested we will keep you posted.
AI, artificial intelligence. I never imagined I would say that, but when you start creating rules, it becomes quite complex, and then some rules starts interfering with other rules so one rule wants to open your ‑‑ switch on your light and other rule wants to switch off your light and it starts going flip flap. And I thought, okay why we don't have a box that would actually connect to the home gateway as me, as Jan, and observe, and then if something happens, for example, there is movement, somebody switches on the light outside it's dark because it's night, and somebody, two seconds later, starts shutting down the shutters, this means that this person wants ‑‑ don't want other people from the street see you on the inside, why we don't have an intelligent box that would learn if this happens a couple of times, it will start doing it for me and it will start building the rules. So this is still an idea, I am looking into software that would be able to do this and the mechanisms and he is telling me I need to stop. Okay. And I'm looking for if you are into this stuff, please talk to me, I would like to understand how this is doable.
Couple of thoughts, and I need one more minute:
Because of simplicity, people tend to connect whatever they can buy cheaply and allow this devices talk to the Internet. I am not sure this is a good idea. Think about it. Who has the control of the data on the other side? What is this data being used for? Who has taken the control of your environment? Think about this stuff.
If somebody ‑‑ if we can unlock our front door with just simply calling the help desk of our front door lock provider, this is perceived as not a good idea because then somebody breaks the Cloud, into their Cloud and unlocks like thousands of doors around the world. Local artificial intelligence, is this something that we need or want? IoT world is a wild wild west. Test everything and think really hard what you want to deploy because these things can be dangerous. And it will be dangerous. We need to think about the security of IoT and somehow to think about what we want to do.
And with this ‑‑ how long was I? Two minutes. Okay. Any questions, suggestions, comments? Please.
(Applause)
BENEDIKT STOCKEBRAND: Speaking for myself. A couple of things, first is, as soon as you use wireless people can listen in and a lot of wireless stuff doesn't even offer anything remotely like crypto because it draws too much battery power, so you really want to be careful with that at that level and things get worse if your neighbour builds another lab right beside you because interference will be getting worse so going right approach really makes sense in the long run.
Another thing about building your own stuff using the EN C chips, Whois net just recently released 6,000 and something chip set that actually does IPv6 in hardware, unlike the 5,000 series did TCP IPv4 only, so by now we have actually chips that move all the TCP related stuff right into a chip and you can go for much smaller micro controllers.
JAN ZORZ: Send on the link. Thank you very much. In terms of wireless, I have 56 UTP cables in my home and people ask me, why you didn't install fiber and like how the hell am I going to power my devices over fiber? Oh, yeah. Right.
AUDIENCE SPEAKER: What I would ask you now, why did you prefer the v6 over v4?
JAN ZORZ: Do I have to answer this, seriously?
AUDIENCE SPEAKER: Yeah, yeah. It has much smaller memory footprint and I am not sure you really want to access all ‑‑ the only thing you want to access is your controller, the hub.
JAN ZORZ: Because I don't want to manage two stacks in my house. My house will be IPv6 only, for simple reasons, because I don't want to deal with legacy protocols.
JORDI PALET: I started to build home automation in my home in 2003, so I have a little bit long history on this. Last December, I decided to refurbish it and actually I went more or less to the same path as you, I had not 56 UTP cables, I have only 48 but I tried to use as much as I can over the Ethernet for big devices but for sensors I decided doing for Zigbee, very cheap devices, even if I need to replace the battery for the doors and Windows and so on and I went one step further, instead of using Z‑wave or things like that which is expensive, I went for the switches, the light switches and some specific sensors or device I went for wireless, I found in China for about 8 dollars inwall switches can do dimming, I do it in every switch behind the switch itself, it fits there. I think it's quite convenient. And the other thing I decided, I took the risk to dismantle my old alarm system and using automated ‑‑ which my home automation I had running since the last two months, my own built in alarm system using also some L U A so basically we are doing the same in slightly different ways but I really think it's a good development going to ‑‑ I guess some people will have a different experience but I think it's a good way. Thank you.
JAN ZORZ: Thank you.
AUDIENCE SPEAKER: Owen delong. Zigbee is relatively cheap but given the advent of the IPv6 stack now available on the ardweno development environment for the 8266 you can get E SP 12 modules for a dollar 75, that's worth considering over Zigbee because you get the full flexibility of wi‑fi.
JAN ZORZ: Thank you for your suggestion.
Jari: Thank you very much for this, this was really interesting and a good discussion topic and I agreed with most of the things you said. I did want to add one thing, at least in my experience has been really key in setting up things in these kinds of environments, in your own home. That is that you can actually have the system up and running and can change components as technology changes and we know that wireless technology keeps changing every couple of years and the systems you like today are different than in five years. How do we do that? I think there is two key components, someone you have like this basic influx like UTP cables that you can use for power distribution if not for something else and the second is the control of your own data. As long as you have controlled your own data you have access to it and you can manipulate it, you can write the script over whatever that connects, the new thing and old thing or whatever you need to do. That's pretty important, maybe more so than detailed competition between wireless standard 1 or 2 or wired standard 3.
JAN ZORZ: It's a thought process that matters, that you incorporate the basic understanding of your privacy and security into the designing of your smart home. And when you talk about adding a new protocols, new wireless protocols, you need the machines with enough USB ports and you stick new controllers in the USB ports and write software and modules that would talk to this thing. So yeah, it's quite important if you want to test new protocols and new ways of communicating that you keep it open and do things with Open Source.
AUDIENCE SPEAKER: Yes, and even if you don't want to you have to because you can't buy that old stuff any more.
JIM REID: Thank you very much, Jan.
(Applause)
And we have two speakers, Jelte Jansen and Peter Steinhauser, I believe we are going to get a live demo.
JELTE JANSEN: Hello. I work at SIDN labs and I am to talk about the SPIN project and collaborative work regarding IoT security and CPE protection.
As you are all here you already know the IoT has kind of some worrying features and I am not going to talk about those, if you want to see me talking about those you can see one of the earlier presentations I gave about this, one of the parts of that presentation was that what can we do about it, we as a community but we as several communities of people that use and make and run Internet devices, and IoT devices. And the ‑‑ I am not going to list the questions here but my answer to the ‑‑ which one of these we should do was yes, we should do them all, and that's way too much work for my specific person, luckily there is a lot of collaborative work here and these letters are very small, I am not going to read it out loud. Within the IETF there is for instance wok on MUDs, so designing blocking all the other traffic there is works on DOTS and especially the call home graph is interesting to me it allows ISPs or other controlling partners to say, like, please stop this specific behaviour from your network and just leave the rest running, I am not going to cut you off completely, stop this specific behaviour and they focus mainly on DDoS protection and I think that can be much wider. That is a discussion for IETF, not for RIPE. If you want to go to really high level talks there is ISO that talks about this and CEN and several countries, maybe even in all countries there is talking about standardisations, certification, regulation, so if you want to and put a little bit of effort in it you can talk about IoT as a full‑time job or maybe more as a full‑time job and you can talk about it all day and never get anything done. If you want doing to these organisations, I kind of like to actually do something physical as well and sit at my computer and I try to make the world a little bit better and in this case, SIDN decided to do that by trying to empower the users and making it more easy to protect the home network. So we started the SPIN project, and it has two goals: One is to protect those home networks from rogue and insecure IT devices and to promote the Internet from rogue home networks by protecting the networks themselves.
So the SPIN project itself, it stands for security and privacy for inhome networks and we researched ways to provide that functionality so we want people to have better insight in what is the devices on the network do, we want to protect that network possibly automatically and by that, protect service providers like SIDN or other Internet service providers from rogue devices and, for instance, DDoS attacks from the home.
With this, we also created some prototypes like the monitor and the local traffic analysis too. We want to keep it local because we don't want yet another Cloud service for the time being. And then possibly control that traffic as well.
So, the first thing we made was the running prototype of the visualiser, I am going to try to demo this later today so if anybody wants to be a guinea pig and dares to connect their phone to my little wi‑fi network I set up there, please step forward while my colleague is going to talk. Otherwise I will use one of my own devices.
But there is lots of other collaboration going on. We have been talking to CIRA about centralising MUD distribution, we have been talking to CN R or expanding what it is in the traffic we look at and have been talking to embed about getting this deployed into CPEs. After talking to a lot of random people we decided to have some other changes since the last presentation I gave about this, so for instance, we now release it for the Raspberry PI and for virtual box so interested people like all of you are are, you can download it and directly install it on your home systems. And just play around with it a little bit. And we added the prototype of the spin‑off tools, like importing data from an existing PCAP file to see what the visualisation would look like, we have a peak detection prototype that does nothing until a device starts talking way more than usual as a sort of early example of anomaly detection. We have added a very early prototype of a much fancier custom interface and we have actually the dots signal home because we had built that but with a custom on the fly protocol and not a standardised IETF way. We are going to look into that next.
Some of this is in the current release, otherwise things are going to be in the webbings one.
As I said, we have also been talking to embed and they had many, many suggestions on what we would need to get this deployed into actual customer premises equipment. So for instance, we had a custom kernel module for efficient capture of the traffic and they said, no, nobody will ever deploy that, because kernel level of programming is dangerous and error prone. So please don't do that; use one of the standard kernels. I like kernel programming but sure okay. So we now use standard kernel modules.
We added UCI, which is OpenWrt way to do configuration, which allows you to do LUCI which makes it easier to integrate into standard cooperation tools. The same goes with RPC and UBUS, you can use tools to read data from the system, and we are working on much better packaging, so you can install it on any OpenWrt system.
Can I hand you my colleague.
AUDIENCE SPEAKER: My name is Peter Steinhauser from embed. I ran into Jelte at RIPE 76 in Marseilles after he was giving a speech, I had to talk to him, because we were on the CPE level concerned about security, network security in a big way, and what he was presenting seemed to be ideal. And so we did discuss to move this technology to the CPE and there is a couple of obvious reasons why. I mean, if you have to connect several devices to your network, it's one device more and people often are scared to put a new device there, they don't know what it does and they don't know how to configure it and connect it correctly so moving the software to the CPE reduces your network's complexity and makes things way easier.
And it also simplifies utilising what has been ‑‑ if you put it on the CPE you can, for instance, trigger automatic actions like triggering firewall rules to shut down if a device behaves maliciously or you could also use the CPE to inform the ISP that something unusual is happening and to take action, whatever.
And the goal was at the end by simplifying this process, also help the adoption of technologies like SPIN because if you put it on the CPE, into the CPE operating system, we suggest or we think it's getting much wider adoption.
So, why would he choose OpenWrt? I shouldn't ask that question. I mean, OpenWrt is the de facto standard for Open Source software CPE development, wide hardware support from many vendors and also some industry players are adopting it, for instance with QS DK, they are not adopting it in the way we would like to see, but that's a different story and would really ‑‑ it's not for here today.
So, we help the SIDN with a SPIN project a little bit for an easy OpenWrt integration, so they created an OpenWrt O package and you can see the link it where there is a page pointing to the package at a certain point and the installment instructions. There are still some small things about configuration which Jelte is currently solving to have hassle free installation in OpenWrt.
So, some things maybe to be mentioned in this context is some related initiatives. One is that we started talking to some people from the broadband forum because we think it would be a good idea to integrate the notification of unusual network events into the T R‑069 protocol or US P protocol which is used for remotely managing more than 1 billion broadband devices at the moment.
And then also, I really have to thank Gert Doring for the suggestion, I talked with him a little bit and he said what about UPnP, I mean UPnP is disabled on many CPEs but when it's enable you have no clue what the devices are do, one of the ‑‑ modify UPnP that can be controlled by SPIN to just tell the CPE okay, this device is not supposed to open any UPnP port and we hope we can increase the security of the home networks by these activities.
So, now to Jelte's presentation, any guinea pigs yet? Oh, excellent. Okay.
JELTE JANSEN: I hope you can reach the wi‑fi here, that it not interfere too much by the excellent wi‑fi that RIPE is providing. There we go. So let's see, I am not storing any of this traffic by the way, I am just showing it to the rest of the world and there it is being broadcasted globally now. So from what we can tell immediately is that you connect to your home which is Karrenberg.net. We can see this is probably an iPhone because I see Apple there and iCloud and Apple and more Apple. I don't know if people at the back can see it. Maybe it's a little bit too small but we can probably zoom in a little bit. We see Akamai, we see you use I tunes, apparently you use IPv4.
DANIEL KARRENBERG: I don't.
JELTE JANSEN: This is interesting.
AUDIENCE SPEAKER: This is 464 XLAT.
JELTE JANSEN: Even if you don't use I tunes your device decides that you do. And apparently you use IPv4 only again as well.
JAN ZORZ: That is the NAT 64 discovery protocol.
JELTE JANSEN: You use, something is talking to YouTube, no cookie, I don't know ‑‑ I didn't know there is a YouTube no cookie.com. There is more. I don't know what this IP address is. So yeah, so what this shows you even at high level the iPhone is talking to many services. We originally intended this project to be about actual small purpose IoT devices which generally connects to five, six remote addresses, and they send some data, if you connect a laptop and you start up a ‑‑ this will explode and probably crash because the JavaScript cannot handle it from the front end. A phone is still manageable and a television as well, just like we saw I tunes here, I connected my home network to this and I saw my television was connecting to Facebook, and I don't use Facebook on my television.
So, yes, that's ‑‑ I don't know. There is an option here that you can actually download the full PCAP traffic. I will not do that for you, Daniel.
DANIEL KARRENBERG: Thank you.
JELTE JANSEN: But yes, so this view in general, the things that SPIN mainly looks at is just the high level traffic information and not the what data they actually send out.
I think that just is showing who you talk to is already very, very interesting and I am not sure if you are still connected but I can now say that you should pay attention to the presentation and not to your phone.
DANIEL KARRENBERG: I switched it off.
JELTE JANSEN: If you would switch it on now these bubbles would turn red because I just blocked your entire device from network. Which is obviously, this is a manual thing and obviously you need to be looking at this but it's mostly a proof of concept that this is easy information to get by the devise and from this, this blocking can also be automated. And what I would hope to ‑‑ to reach ‑‑ there we go ‑‑ that is actually the router trying to talk back to the device. Need to block IPv6 as well. This is actually a bug because it should have seen that is the same device and connected them together. So there are still some little bugs here and there. But yeah, so one thing I would like to reach is, for instance, with the DOTS implementation, if we keep a small bit of history on the router itself then signal from the ISP saying we saw you were joining a DDoS attack at 12:17, please stop that or we are going to cut you off then you can use similar system like this to actually do that and to just quarantine that specific device and not the entire network.
You can see if you are looking at this, if you are interested person like me in what your network is doing you can see when a device suddenly starts going wild and connecting to all kinds of things. And of course you can see unexpected things that your devices do, like going into iTunes; if you don't have iTunes or go to Facebook if you don't have Facebook. That's it. Are there any questions?
(Applause)
JIM REID: Any questions?
JELTE JANSEN: I have one slide left, which is questions, I believe.
JAN ZORZ: Jelte, thank you for this. There are many good things in there but the big revelation for me is that I didn't know that Apple actually implemented 464 XLAT on the iPhone it's like wow. It's there. Anyway.
JIM REID: Thank you. Any more questions. I think there is someone from the chat room? No. With that, thank you very much to both Peter and Jelte, thank you.
(Applause)
We are running very, very late and we have one more presentation which will probably take 20 minutes or so and I don't think we are going to have time to fit it in. And I am also not sure ‑‑ thumbs up.
We have two choices here: We could run very, very late and have Working Group overrun by about 15 minutes or postpone's Michael's presentation until the next meeting, bearing in ‑‑ and I have just been told there is a Working Group chair's lunch coming up. I am going to have to apologise to Michael because he has got up very early in the morning, he is in Canada, I am veer we are running, we are going to have to postpone your talk until the next RIPE meeting. I apologise.
MICHAEL RICHARDSON: Read the slides.
JIM REID: I understand he is coming to the next RIPE meeting, so that would be great he can give his presentation in person. Just before you leave, one other announcement to make, there is still time for lightning talks in the closing plenary so if you have any interest or some people like to present there, please contact the PC chairs or the Programme Committee and see if we can get a slot for you in that. I apologise to Michael and like to thank everybody for coming. Thanks to the presenters, thanks to the RIPE NCC staff for helping out with things like the chat room and the minutes and, the audiovisual people, and Aoife the stenographer for doing a great job for transcribing my gibberish into intelligible text. Thank you.
LIVE CAPTIONING BY AOIFE DOWNES, RPR
DUBLIN, IRELAND
