IoT Working Group
17 October 2019
At 11 a.m.:
CHAIR: I hope we can start, we are at 11:00, I think the better to start now. We have a minute taker and we have a scribe. So, today we have like a big presentation of about for 50 minutes and time permits we might have a demo also. Then we have 20 minutes presentation about anomaly detection in IoT devices and we had a RIPE IoT hackathon during the weekend, so there will be an update on that hackathon. And finally, Jim will give a brief overview of whether we should have a BCOP document for RIPE. So if there is anything else, nothing to tell, maybe we can start with the presentation.
MICHAEL RICHARDSON: So you can hear me. Hi. And I am going to be talking about IoT lifecycle security and where this came from, and ‑‑ how many here are IoT workers? A few. How many are ISPs? Good. So I really want to talk to ISPs and it's really what I am here to talk about but it's about security and things like that. What about the rest of you who didn't put your hand up, who are you? People, yes, but where do you work, is what I want to know. I didn't hear that. No. Okay. Eliot is going to be doing some things in the middle.
I talked about the secure home gateway project and a little bit about MUD, manufacturer usage description which is now an RFC 8520, the quarentine programme that we imagine for malicious or failing IoT devices and essentially how they get ‑‑ put into use, and what do we do when they commit crimes again, recidivism?
As I said, I gave a talk last year about sir /RA labs secure home gateway home, and our usage of MUD. So, for just a little bit of status of the thing, after that talk, we went into a kind of a bit of a storming phase, we had a prototype, a proof of concept and trying to figure out what do with do with this thing and turn it into a usable product to people. And in the summer, sips about March, we have been trying to enter into this norming stage at the end of every week we have a C I process and Romijn you can run, I am sorry to say we are not at that point and I hope the project will continue (R OM) and we are kind of looking for ways to move this forward.
The project is essentially to protect the Internet from IoT devices, so CIRA is a Canadian TLD and one of the things the DNS guys freaked out about in the 2016 ‑‑ 2015 Dyn attack by home routers and PDRs, was how vulnerable the critical infrastructure, the route name servers etc., were to this huge number of devices so we would like to protect the Internet from them and at the same time like to protect the devices from ran tomorrow things. You have probably all seen the website that will give you a random selection of home web cams that you can view. Right.
So, MUD is a thing for this Eliot, how does things go and...
ELIOT LEAR: How many people in this room could have guessed that this printer needed these ports? Raise your hand. Okay. I want everybody to take a good look at those hands raised, all those people are lying. The whole point of MUD is able to to what sort of access a device needs. I will leave it to Michael to continue.
MICHAEL RICHARDSON: Right. So effectively, what the MUD file does is it allows you to pass the information from the device at up to a firewall, through bunch of protocols, bunch of different protocols DHCP, LLDP, 082.1 X. One architecture is, you know, there is a whole bunch of radius infrastructure and MUD manager and results in some access control lists. If you think of MUD of ACKLES in JSON form with a digital signature in a way that is suitable for loading programme atically into a router.
This is what our system looks like. One of the recognitions we had floor MUD files available by DHCP at this point but you can stick a QR code and that is almost as good and don't even have to open the box, you can stick QR code in, effective on the box, on the cardboard box, effectively without even looking in the device, so if you know what it is it's good. And one of the places where I believe that this could happen is that some countries may ask you to do this as a voluntary regulation and that is kind of the direction we are hoping to go for. This is a little bit what a MUD file might look like, and it's a bit abstract, it doesn't necessarily deal with IP addresses directly, there is DNS lookups and also some levels of indirection that are important there. So, what do we do when we violate, what is the home router going to do with the device violates the profile that we are told it's supposed to follow? Well, probably quarantine it, so the bad let us case, the reframing rater has gone rotten and we should report there is something happening. So what do we do? We are going to put it on to a quarantine network. Those of you in the enterprise space with Windows platforms and N EA and this kind of stuff, are familiar ‑‑ may be familiar with you don't get on the Internet until the network is sure that you are running the latest virus scanner and patches and things like this. So that's a space of things. One of the things we have tried to do is write a document and this is what this is about, about this, it turns out it's called a play book. There was a Working Group in the IETF or a BoF in March on standardising, having the IETF standardise play books but it looks like that work is going to happen at oasis instead.
So the fundamental thing is, what is going to happen, right? You have your refrigerator attack some piece of critical infrastructure and it's blocked, okay? So what is going to happen, you are going to get an alert on your phone or computer and it's going so say your refrigerator has done something wrong. So now what? Think what your non‑technical friends will do. Are they going to call the application developer of the mobile snap that is a possibility because that's the one that mobile app told you that, you may give it a one star review at that point. Are you going to go to the home router vendor and say it's your app, you, you know, your home router told me my reframinger was wrong what do I do now is are you going to call the ISP help desk? The answer is probably yes, because apparently people call them for all sorts of reasons because, you know, if it involves the Internet you probably call your ISP. That is why I want to pre‑warn you, the people in the room who are involved in ISPs, that this is going to happen and I have no control over it, so I'd like to help you and I would like your help to basically make it easier to help you.
Okay. What are you going to do? Well, what I hope is that there is going to be some coordination and you are going phone police as it were, and talk about some kind of process, about dealing with bad reframing rateers, and how you are going to do that? I hope you are not going to send them a fax, although that is probably what they are expecting today. I hope we are going to use something like DOTS, so that is an IETF Working Group that is distributed, I can't remember acronyms today. So there is a bunch of other ones. There is a European project called MISP project.org, which is supposed to be coordinating and I am wondering is anyone here involved in that? Too bad.
So, what else there. Oh, the next question is, you might call a refrigerator manufacturer, that is who ultimately we want to get involved, right? But at least where I live, I don't buy my reframing rater from the manufacturer, they hardly want to hear from me and I am not even sure there is any point in sending in registration card. That let's them send me junk mail. That is who they want to get involved. Are they going to believe me my system, when they get a call from this guy there is something wrong with them. That is the kind of thing we want to enable.
The other thing we might need to do, we might have some critical systems in the home which we need to make sure are still alive, maybe you have been sent home or your relative has been sent home with some monitoring device which is apparently going to be a thing in the future such that they can send you home early from the hospital because they can monitor you remotely and outcomes apparently are much, much better if people go home early they don't get sick from hospital borne diseases, so there is a lot of good reasons. So the question is: How are you going to make sure this is still working there? Because the alternative to this guy blocking the traffic is, this guy blocks the traffic, right, and then you are off‑line. So if you have off‑line, this is off‑line. So how are you going to be sure that, you know, this stuff is still working. That's part of the question. So‑so what I want to talk about, and I am hoping you guys will fill up the mic line, is where ‑‑ what the different states of this device is and what are the protocols that we need and what are the gaps are in the protocols so we can move the device through these different states without human intervention. So we have a new device, the important thing about a new device is if we wipe it again nobody is upset, right? Brand new iPhone, you haven't logged in, if someone says need to wipe the firmware and upgrade it before you start personalise it you are not really that worried, okay? Hey, okay, cool. As soon as you started personalising, the device you go wait a minute, am I going to lose all my stuff, my connections, particularly if you have ever used some of the devices where you have to like type in, I don't know, your Netflix password with a ‑‑ two buttons on the thing to move around the screen, it takes you half an hour to do that, at which point there is no way you are going to wipe that device because it took you so long to get the password right. That is a critical thing, that is going to upset people.
So, something suspicious happens, device performs unexpected communication, the device doesn't know it's suspicious but the network does. So at this point, what are we going to do? And this is the question. We need to have some communication and we might need ‑‑ this is not a suspicious communication, this is okay, it turns out the MUD file, or whatever other policy was there, was wrong and that is the most likely case for the first, I am going to say, five years of deployment of of MUD, is that new firmware went out, market didn't update the ‑‑ or the CDN cached it it, stuff happened, right, that is the most likely case. This is one of the open questions. If we ask the user then they are going to be habituated to saying okay, okay, I have re‑enabled the device, okay. We would like to have this happen somehow in automated fashion. But if it turns out that it really is suspicious, and it happens repeatedly, then we need to get someone involved, okay? So we need some kind of way to capture the traffic, the event, in a privacy preserving fashion that is going to communicate to somebody who cares.
So, maybe the device is owned, we have figured this out, there is a possibility. I am not sure. So, it could be that it's suspect, we don't really know if it's owned or not, but we are trying to figure that out. So now it's suspect, someone says this is definitely suspicious activity and I definitely want to let anyone know who has this device if you see this activity that it's suspicious, you should quarantine the device if there. Some external information comes along and says, hey, the device is quarantined. Now, if it's a refrigerator, it probably still keeps your food cold, it just doesn't order new ‑‑ new milk or cheese when you run out, okay? If it's an Amazon echo does it do anything at all without the Internet and the answer is probably not. So there is a very big difference when you quarantine different things as to what happens to them. If it's a baby it keeps crying even if you disconnect the Internet, right?
So, the point here is that the quarantine doesn't mean the device is dead or unplugged and if it's a battery operated device, unplugging it may be meaningless. If it's energy harvesting device then the question is how do I keep it from operating at all because there is no battery to pull, even.
So the device might be unfixable and you might actually have to say, I'm removing it. Someone in the drink break said, I fix IoT devices on my campus with a large hammer, I smash them into bits. And you know, you might have to do that, that may be part of the lifecycle we consider, how do we permanently decommission this device? At which point you destroy the device and unfortunately it's landfill and this is ‑‑ this is the end point that many of us would like to avoid. Maybe people would like to sell you better device would like this to happen but mostly he would like to avoid landfill. We need to upgrade and we need to figure out how to return the service so that means convince the network we have operated and go back into service. I am wondering if anyone has any big problems with this, you know, kind of state of things?
Okay. So, if I add some protocols, you know, to some of these ARCs, this is my opinion, okay, I think that IPFIX is the right answer here. I think a MUD update is the right signal that the device is okay and you should go on. There is mile and something called R OL i.e. and these are protocols mustily seem to deal with human organisations to other human organisations, sharing data on compromises. Can they be used for this? That's what I'm interested in, specifically I am interested in ISPs who are involved in this, you know, if you have some opinion about this.
I OC dot PDF, one of the way it happens, they exchange information about what is going on. Clearly that is not automatable, that is protocol between humans. That's what we have right now. We have to do better than that and do it in a privacy preserving way.
So that part where we are sure about what is going on, there is a whole stack of projects and if it says here is the details of what is wrong, how you recognise it, maybe even, you know, how to defend packets against attacks from this thing and that's being distributed through this process, which is ‑‑ the Department of Homeland Security likes TAXI and ROLI, this is the European side, American side and gap based on ROLI, some of it happening in the IETF and other in other places.
So, upgrading. IETF has a protocol called suit, software update for Internet of things. The original proposal was FUD for Firmware Update, cooler name but maybe more scary for some people. So it includes a digital signature distinct, so one of the proposals, one of the extensions proposals that I have, even when you are quarantined you are going to need access to your firmware update and so we need to enable that, to happen, right. So the device is quarantined but still gets some access from DNS and other stuff to get what is going on.
Remote attestation, how is the network sure the device is up grated and not a malicious attack, so says, of course I upgraded, please reenable me, because that's going to happen, right? And one of the other things that if I was writing malware for these things, I would be thrilled if you have a home router with an API with a default password admin admin because I will go and enable myself, right? So you need to think about this, that there are attacks from the inside of the network and that it doesn't matter that the home router is not accessible from the Internet, you therefore can have a weak authentication mechanism because the bad guy is already in the home.
So return service. So there is an attestation going on and one of the things is, how do you get your back‑ups, if there was a backup on the network and it had a conversation actually (I had) at the O PC where they are very concerned when you replace the device because it is in fact this way, that some element of the network recognises this is the replacement device for the thing that went ‑‑ went down and I need to give it the configuration from the previous device and so the then the question is who backed up the configuration. So that's a kind of thing we tonight usually think about. To we need a standard for configuration and the answer is, well no, it's a devices issue, what's the issue. Well, if we can't take it off line, wipe it and reinstall it, if we we can't restore the configuration because that pisses people off, right? And how many have not avoided upgrading a computer because you didn't want to lose access to some gain or something, right?
So COCAO is not happening at the IETF. This is basically the end of the presentation. I want to know what you think of the next step. Are any of these protocols stuff that you know? Are you deploying it? What is happening with your ‑‑ in your organisation? Are you taking calls?
JELTE JANSEN: Not an operator but working on similar things as you all know. I was wondering, can you go back two slides. Do you see any role for dot signal home here as well? Like you ‑‑ you can also ‑‑ devices could become suspect not because they violate their own MUD file but because an external entity tells them hey, off bad device and this was the traffic that was bad.
MICHAEL RICHARDSON: That was the intention of this, was that, yeah, so exactly, dot signal home, exactly, was the question of the Internet or your ISP has determined that devices of this type are suspect and should be taken off‑line until such time as they have upgraded. Okay. And I am totally with this, but recognise this is also a major denial of service on you and what if you can get your competitors' devices on that list, okay, or just, you know, random vandalism, right. Totally has to happen, how to we trust that part?
JELTE JANSEN: Good question.
AUDIENCE SPEAKER: Alain. You were asking for some feedback and I am going to offer you some candidate feedback. This looks extraordinarily ‑ and lots of moving pieces in the home, in the IETF home network things go off the rail in a certain way because they were extraordinarily complicated. If you go to the diagram, full diagram, there is a lot of pieces there and to your point, maybe your competitor is going to try to do something bad in there, so put you on the bad list or not correct list, all will have to depend on some kind of cryptography for this to work reliably, but it's really hard to manage. I am somehow wondering if we are not shooting too high for this and if we should not go for something much, much simpler.
MICHAEL RICHARDSON: I am open. This is why I wanted to come, I want the push back. So would you just do this differently or would just simplify it how?
ALAIN DURAND: If we simply leave it to, we have detected something wrong and we are going to crowd on you and not solve how you get back on the network, that might be a good first step.
MICHAEL RICHARDSON: So we have that with MUD, that's our first step. Okay. And it's ‑‑
ALAIN DURAND: That works if the router has mot been compromised. If the router has been compromised, which has been quite the case a number of times, then all better off, right?
MICHAEL RICHARDSON: At which point the ISP has to disconnect them.
ALAIN DURAND: Yes and no. You could have similar filters on the ISP.
MICHAEL RICHARDSON: Now. How would they filter, in a v4 NAT situation?
ALAIN DURAND: You could apply some machine algorithm to determine what is the properties of a pattern and filter that one out. There are a number of solutions in that space.
MICHAEL RICHARDSON: Yes.
ALAIN DURAND: You know. The point I am trying to make here is, we have seen service providers automating thing it's a hard problem. In the home it's a harder problem because it's unmanaged. That's my point I wanted to bring you.
MICHAEL RICHARDSON: Are you aware of people that have deployed machine learning systems to take off ‑‑ take out users, disconnect?
ALAIN DURAND: Yes.
MICHAEL RICHARDSON: Yes. Okay.
ELIOT LEAR: I agree with all that to a certain extent that is pretty complex diagram, but I have a question for the room as well, which is: Who believes that the service provider has a role in the home in terms of protecting their customers? Anybody? Good number ‑‑
MICHAEL RICHARDSON: A few but not the majority.
ELIOT LEAR: Okay. Because to me, if you don't believe that, then we are wasting a little bit of time here. And so, I just want to point out a couple of facts of physics at that point. How many are unconvinced that the service provider has a role in the home? Okay. I would say it looks about 50/50 to me.
AUDIENCE SPEAKER: I am concerned about the binary nature of that question, I think that's too binary.
ELIOT LEAR: We could get into that, but the fundamentals for me are simply this: Consumers have very difficult time making choices about security. They need help and they need aggregate help that can come either from a service provider or an organisation like Google, home networking, come from Amazon it has to come from somebody, they need somebody to act as their agent, in this part, in the home.
And so, for me, much of this mechanism here, right, it can start small, right, but it means that the service provider has to receive or whoever this agent is, has to receive some amount of intelligence in terms of what is being connected and has to be trusted with that information such that they won't abuse it and provide the consumers some very basic questions like: I see this device has been attacked or this particular device is problematic in your home, I am quarantining it or going to take a certain action, I ‑‑ would you like me to report the problem to the manufacturer? You know, a question like that. Has to be very simple in that regard. And then in order to address this it seems to me there needs to be a bit of a step‑by‑step process because consumers aren't going to swallow all this at once and neither are service providers so how do you isn't that right.
MICHAEL RICHARDSON: I haven't said which piece gets deployed first. I know this is happening and this is happening. And I know this part is happening, the MUD part. The rest of it, well, I don't know, right? That's going to be up to the ISPs to decide what is going to happen. And but between the IoT space of people, the home router space of people and the ISP space of people, we are going to need to have some kind of agreement on what is going on. There are some ISPs, I took a picture of one in Berlin of a T Mobile home system, including your door locks, and I just ‑‑ I can't imagine my insurance company would allow me to trust my ISP with my home security that way. I'm sure that there's going to be a dispute if I am broken into as to who is responsible and ultimately I won't get my insurance money, right? But the fact is that this ISP was offering a vertical solution, connectivity, home router, IoT appliances. Right? So, they are going to do something for this, because they have to reduce ‑‑ they have to ruse their opex ‑‑ you know, they can't have people being locked out of their houses and they call their ISP, right? Think about that, right? Is the ISP going to have roaming locksmiths? I don't know. It could be broken and they can't open it remotely.
MALCOLM HUTTY: Random consumer, we will say, who wandered in off the street. This basic architecture assumes that the manufacturer knows best as to what the device does and can do and that it is in my interests as a consumer to make sure that ‑‑ you are in a better position to be able to protect me from the evil hackers out there that will exploit the devices, and for the vast majority of cases in most scenarios, this is sort of good enough.
MICHAEL RICHARDSON: Yes.
MALCOLM HUTTY: But as a relatively sophisticated consumer but nonetheless a consumer nonetheless and forgive me if I get some of the nomenclature wrong, I am the person that run thigh traffic for VPN and all that sort of stuff and I don't believe that the manufacturer is always acting in my interests; quite often, my interests are directly opposed to the manufacturers' and their continuing control over devices I bought. I am always not always convinced that my ISP is acting in my best interest, that is why I would run a VPN. I would like the benefits of the kind of of direction that you are roughing for this kind of ‑‑ offering nor kind of thing. I would like to protect myself from the lockout that this architecture is building that prevents me from having greater control. I would like, rather than the manufacturer being able to be in the place that is baked in as the sole control of this, for me to be able to manage that control as the owner of the device and local network, manage that control myself or to appoint somebody else ‑‑ I trust the Cody foundation, I don't even check the digital signature ton did you it does stuff that that I trust better than the Amazon interface and I choose that. As a consumer I don't have to know ‑‑ be in a tiny fraction of one percent of people that actually write the code on this stuff to be able to defeat it, I want somebody else that I trust, that I can appoint to protect my interests better and more in line ‑‑ I think is more in line with my interests than say the manufacturer or Amazon. Is anyone doing work that would support that, that's my question?
MICHAEL RICHARDSON: So within the secure home gateway project we did one of the challenges we came up with is there were no MUD files. We would have to create our own. And so part of the other thing we realised quite rapidly was even when a manufacturer did create a file, that the products they were probably going to get it wrong or they were going to over claim so that they, based upon some new thing they were thinking about, right, post your current watch list to Facebook from your Cody, right, so your friends can see what you are liking today. But you might not want to do that, and so you may have to have not just one MUD file but you may actually have a series of MUD files which are applied in some union intersection complicated fashion, questions there, but I am sure you will deal with that and I am sure I can deal with it. So, you could say, well, you know, you know what, there is this suspicious activity that keeps having where it tries to reach Facebook to post your lists and you keep saying no on your router, it's not ‑‑ it's not a violation, it's just your policy is no, you can't do this. TCP resets, NX domain you want ‑‑ think the right process is. And that's not a suspicious activity. Furthermore, we also had the opinion that there may be a space for an online, I think of it as user voice or stack exchange type interface where you would post your changes to the MUD file and other people would upper air them and go yeah, yeah, I like this version and that may go into some Crowd Sourced set of rules, and I think that that's an ecosystem that should exist in there.
The other thing is that there are companies that build home routers that want to put this in this and want to sell it directly to you, not through your ISP. So they, in many cases, would like you to trust them with this stuff, rather than the manufacturer or your ISP. And maybe that ecosystem will grow, okay. I don't know. But there is relatively big companies doing this at this point. I just don't think they have products out yet so ‑‑
MALCOLM HUTTY: Aren't the protocols you are building baking in the idea that the signed MUD file from the manufacturer you know has to be verified and if I pointed out some unsigned modifier, that would be disregarded if it's unsigned. Eliot can answer that question. To a certain extent RFC is vague about how we trust the signature, okay. So what those trust anchors are and how do you get them, not in the RFC, and so, yeah.
ELIOT LEAR: Michael is on point there, the whole idea is, it's who you want to trust with that information, whether it's the manufacturer or somebody else. Let me add one other point: The manufacturer put that information into the MUD file because that's how the device was designed. It's not like he is saying I want this access because I want ‑‑ because I want it, it's because this is the way the device was designed. Where the learning curve will be, will be the manufacturer understanding what access the device needs. Rich and then upgrades where they add features and, you know, things they can learn, skills become a real pain in the ass because come with their own MUD file.
MALCOLM HUTTY: Any kind of firmware hacking and side loading has all these problems. This is not new. But the successful projects out there that have actually significant consumer support, do actually address these kinds of things and have a working thing, that's how they get significant consumer support and I want the protocols to be something that will not make those impossible.
MICHAEL RICHARDSON: I think it's possible for you to be locked into an Apple only universe but I think it won't be the only product you could buy.
BENEDIKT STOCKEBRAND: Speaking for myself. First thing, when I am doing IoT stuff, which I have not for a while, it's mostly the rather ‑‑ rather than Raspberry Pi, let alone Smart TV with the main board in the back, this will only work for fairly powerful devices, as far as I can see, just from the complexity you wouldn't fit that on a ‑‑
MICHAEL RICHARDSON: This complexity is in the home router and the ISPs, not on your device. So your device would have to emit, you know, a 70 bite DHCP option, pointing to the Cloud where your MUD file is, okay? And that's it. That's the extent. And you have to have new clue to realise if you are using M2T2 to a particular place to do something, that need to put that in your MUD file.
BENEDIKT STOCKEBRAND: Second point: With the manufacturers being perfectly happy to not provide you with any updates so you buy the latest product, I find it rather difficult to convince manufacturers to work or supply these things and updates.
And finally, with the centre approach, why don't you just follow a plan where basically you deliver your device with some information that contains everything you need to know about where this device is going to connect to, what ports, possibly some more stuff and set up a reasonable filter on your CPE in that way so the machine is protected like that and you ‑‑ by setting up ‑‑
MICHAEL RICHARDSON: That's what MUD does, is it encodes a list of ports and destinations that you want in a JSON format, YANG description, there is a bit of formalism on top of that, and provides for digital signature so you can be sure if you want to check it that it comes from a reputable source.
So that's the ‑‑ this is what my white‑list is. And that's really good thing aye hope it will happen everywhere and it's what you just said. So if everything is good the device is safe there is never any exploit and nothing happens and the device continues operating, the question is what if that's not the case, what happens when the device violates the policy that it declared, what do we do at that point? Do we just remove it, right, do we just dumpster it, I don't want to do that, okay? But, somehow, there is probably, I hope, that there is a firmware update and it fixes the problem, okay? If there isn't, you know, maybe you solve the problem with a hammer to the network card, that's how you keep your stove off the ‑‑
BENEDIKT STOCKEBRAND: That's what happens most of the time these days, not that I am happy about it but that's pretty much the market situation. One more thing: If there is such a thing as a description of what ports a machine connects to, something like that, I, as a reasonably qualified end user in that case, would like actually to see something like that in a human readable form so I can decide I am not going to buy this it's come from half of China and three‑quarters of Taiwan and can I actually see what to expect from a device like that, this way?
MICHAEL RICHARDSON: That's what it looks like in prettified JSON. You typically conicalise spaces to sign it, but that's optional. So, there it, you know, matches my controller, this is maybe not a terribly wonderful example, but you can see that and there is some people that have produced some nice or have worked on some visualisation tools so you can stuff them in and see a pretty picture on your browser, what it does. The question is: Can you get that without opening the box, okay? So, I am afraid I can't, you know, can't right consumer rights law for you, but if we put the ‑‑ if the MUD file winds up as a sticker on the outside of the box, maybe yes you can go and find it out.
BENEDIKT STOCKEBRAND: There are two ways to follow on to that and do it at a political level or as some sort of basically ‑‑ maybe can say you get the information and that's why you want to buy our products.
MICHAEL RICHARDSON: Part of the multi holder or stakeholder that started the project in Canada, that group also basically came up with a bunch of labelling that they wished to make voluntary. For instance, I con that says this product has a live mike.
PETER STEINHAUSER: How is the MUD adoption going from the vendors' side? Because this whole project lives or dies with MUD files being available and also in this context, general question, nobody answered is the reliability and the accountability for attacks, so I mean, there should be an incentive. IP, if we say the end user is liable if a device is doing something malicious, I don't care, I am fine with that. But somebody needs too far motivation and I also don't have a problem with telling people your IoT device sucks, throw it away. I mean, next time people will be careful.
MICHAEL RICHARDSON: Quality of implementation, so I know people have asked me should I blah‑blah and you shouldn't buy anything because you are going to throw it in the garbage in two years.
MICHAEL RICHARDSON: How is the MUD? It's six months into the having RFC number, and my impression is there is a lot of enthusiasm among certain places.
ELIOT LEAR: I work at Cisco and we focus on enterprise, we have a number of enterprise devices that are building in the MUD capability, mostly involving what we call carpeted spaces so think lighting is an example, sensors you might put in a ceiling, we have one company who showed up at the IETF last time who, they managed 60 million devices in Japan and are very enthusiastic about moving forward; they tested against Michael's implementation and the NIS implementation and ours and found a bug in Michael's implementation, was it yours?
MICHAEL RICHARDSON: No.
ELIOT LEAR: There was definitely one bug found in the process. It took them probably 45 minutes to do the config on their side and they spent the rest of the time doing Interop testing. But, that having been said, on the consumer side we haven't really made a push yet. We are beginning ‑‑ I have had a couple of conversation with a couple of companies in Japan about this, but you know, they are very big companies and exactly, permeating this information into the industry is going to take some time.
MICHAEL RICHARDSON: As to the question of liability, I don't know if you saw Marco's last little thing yesterday about European Commission comments about the network termination point, that's the same conversation, right? Because if the ISP owns the CPE, then, and there is responsible for that ‑‑
AUDIENCE SPEAKER: One comment, Erik, speaking for myself. I have two observations and one of this is going the direction which you never mention, there are two models, we have a free router market in several European countries, so people can go to media mart or whatever or buy a route and connect it to the line. The second step is when it is a router developed by the ISP in most of cases under control by system from the called DR 69, or DR 369. Am I correct in thank I am missing this system in your suggestion or is this not correct from us.
MICHAEL RICHARDSON: I don't know how ‑‑ I don't know thousand integrate this with T R 69 but it clearly can be, right. So the point is that the ISP would say here, do this ‑‑ configure with TR69 your IPFIX messages to this server, so there is some attributes there. That is how I would expect to do that. I don't expect to send traffic over TR69. There is ‑‑ there is a lot of people not happy and something more modern.
AUDIENCE SPEAKER: DR 369 coming up.
ELIOT LEAR: One point to add is one of the people who have done a reference implementation for MUD are Cablelabs. Right.
CHAIR: Eliot has four minutes and we will not be able to have questions and answers.
ELIOT LEAR: It's just a quick demo. The idea behind the demo is it's gave view for ‑‑
What we are doing for manufacturers really, right, and the same could be done for the consumer case, you have a device, call it Internet Barbie or something like that, this is going to be MAT he will who makes Barbie, for Internet Barbie dolls, and these are just a little bit of information about the device and what it's connecting. And pretty classic connection pattern for consumer devices they want to get to their Cloud end point. So that's basically ‑‑ they want to have Internet communication but Internet communication to specific hosts. Maybe there is a Cloud connector called Barbie.MATTEL.com. Like to think they are communicating on port 443, the thing is likely initiating it.
So, now, for the rest of the world they are probably going to select IPv4 but since we are at a RIPE location, let's dream, okay? So here is the MUD file that they can then just take and use, they have to sign it, but that's just one more step. If they want to see how it's going to interact with the world, I have a little visualisation tool here. Here you have a PC and it might want to have access to everything and here is just the access that Barbie has to this thing, it doesn't have access to the PC, even. And suppose we want to, you know, an fire control system into the mix, let's go for this is more of an enterprise pool, right and we can automate some more of in this in terms of how to select controllers when we are working on that. It doesn't really matter what IP address. Here you have a controller function and this guy can talk to the Internet, so here is that PC still, it doesn't talk to the controller either and ‑‑ here is Internet Barbie still, still connecting. And so, this tool by the way was designed just over the summer, and the idea is to provide at least the manufacturer with a notion of what sort of access they are signing up for when they derive the MUD file. That is the demo, the code is available on GitHub, you can integrate it into your products if you want. This is basically, I won't say it's a starting point because we started already but it's a nice stepping point and that's as far as I really wanted to go today. Any comments? Questions?
CHAIR: We can take quick question, one or two.
AUDIENCE SPEAKER: Access for all, wondering what ‑‑ if I want to ship malicious hardware, what keeps me from slapping on the sticker that says I am a computer?
ELIOT LEAR: What keeps you from doing that today? I mean, the ‑‑ the point is that MUD is just ‑‑ it's just a control function, right? People can lie, right? If I go and I buy a Google nest, Google could lie. I see I have a red light flashing here so I should probably keep it to that. Come find me later, I can answer that question in more detail. Thanks for your time.
(Applause)
The next presentation is by Anna and she has done some work in RIPE hackathon based on dataset so shell explain.
ANNA MARIA MANDALARI: First of all, I would like to thank the RACI for giving me opportunity to be here, thanks to all the RIPE committee for choosing my presentation.
I am going to take about last work in collaboration with Northeastern University that is going to be presented next week in IMC about privacy or non‑privacy after this work and IoT devices.
So, how many of you has IoT devices at home, Amazon, Google home? If you don't have but you buy, you bought a television in the last ten years, then probably you have an IoT devices because Amazon ‑‑ most televisions are smart nowadays so Internet capable.
It was calculated we have by 2020 more than 20 billion devices connected to the Internet and the main problem, the main challenge on privacy in this context is that these devices are like black boxes so we don't have any clue, all the traffic is encrypted so it's difficult to do man in the middle. Another problem we don't have in other context like in the mobile environment for example tool for simulai to the device, let's say for ‑‑ we have RIPE Atlas, for we can use Europe for IoT devices we don't really have a real test‑bed.
But let's consider what we consider privacy in this work. So we are considering just consumer IoT devices, and for us, privacy is personal information, so what is the information that is exposed that is going to all the destination and who are the destination. Destination can be first parties like manufacturers, they can be support parties, let's say IWUS, Akamai, CDNs and Cloud providers; third party, it's like advertisement, double click; and even Morris key, eavesdropers.
So is our information going to non‑first party and is going to different regions that are different from your current regulations, government regulations. So different from GDPR in Europe. Can infer activity by your network traffic. So for understanding this, we made some research question and the first of the research questions is about what is in the destination, is the traffic encrypted, which is the content that is sent and if you can infer activity from network traffic by these IoT devices.
For doing that in methodology you need tools, so we made up a methodology for sniffing all the traffic in the router and the tool is able to classify the traffic per device and per experiment because you know these devices can be controlled by an app usually or a companion device like you can control the using Alexa or Google home so we had a methodology for classifying the kind of experiments we are doing and we built test beds in north eastern university is like studio where students go in and make their laundry using the microwave, play the station with smart television and other one is in Imperial college. It's quite different but we are working on making nice imperial.
We VPN the traffic from UK test‑bed to US and the opposite for having a clue if these devices are detecting your location by peer address and behaving differently, in a sense.
How we collect the device: Well, we buy ‑‑ we bought devices that are more popular, the most popular device in Amazon and tried to buy the devices that are in common between the two regions. So we have in total 81 different devices, now we have more than 150 so we are expanding, and we try to buy all the categories, to cover all the categories, cameras, smart hubs, appliances, smart coffee machines and so on.
We design three experiments, so we are capturing all the traffic when the device isn't idle ‑‑ I don't mean when the device isn't on, but nobody is interacting with it. And, we do some control experiments, so how our tool is able to automatically open the app in the phone, switching on the light we are capturing the time we are switching on the light or off or make coffee or make a tea with smart kettle, and we also ‑‑ so in total we did more than 30,000 experiments, and we are also uncontrolling inter ah so we are capturing the traffic not when the device isn't idle and not doing automatic experiments but the students are going to the room and we have no clue when they are using the device but we have the traffic also for uncontrolled experiments.
So let's see the ‑‑ where is the destination? How we do that: We have the network traffic and for the network traffic by looking at the DNS response http response we identified the second level domain. After that we use the Whois database for understanding the organisation and then we classify the organisation as first party, support parties, let's say if we call Amazon.com we classify it as a support party. If we say AD tracker then it's third party.
From the other hand we collect also all the destination IP and we identify the organisation by looking at the IP. We also do geolocation using the new tool that is called password and we check if the destination is the same region or different region. Let's say the device is in UK and this is contacting US then it's. If the device is in UK and contacting Italy then we consider it like same region.
So this is about categories. So we split them into categories and the majority of traffic, as you can see, sent by cameras because streaming video and from UK most of the traffic is sent to US, so with different regulation about privacy. And the devices they are manufactured in China and rely a lot on Cloud host in China, so your information is going to ‑‑ your video is going to China and they have different regulations there, as you know.
So the takeaway here is many devices contact outside jurisdiction, and if you want to know more about this, we did BBC programme, it's called "click" and about the GDPR and how your vacuum cleaner is still sending to Cloud in China.
Who have the most contacted destinations? Of course Cloud support party like Amazon, Google, Akamai, but Chinese Cloud providers and mostly all the televisions and dongles are contacting Netflix, even if you don't have an account for Netflix and didn't login the app.
We saw some regional difference, US are contacting more destinations, maybe for GDPR we don't know because it's encrypted.
Let's say how is ‑‑ how is the traffic is encrypted. So, for the understanding how much the traffic is encrypted on these IoT devices we started from the simple test, so if the protocol that they are using is still as quick then we can say the traffic is encrypted. If we saw like no encodings like audio, video, compressed then we can say that the traffic is unencrypted. And the remaining traffic with the methodology using, calculating and computing the antropy. If the antropy is 0.8 then the traffic isn't encrypted. If it's lower than 0.4, then traffic is unencrypted. If it's in the middle, we say we can ‑‑ we don't know.
So, some results:
Fortunately, at least these, most of the traffic is encrypted only two unencrypted one in US, UK. Most traffic encrypted. And for the other devices we don't know.
Per category, we see that cameras and TVs have the most recognisable encrypted traffic because they are sending more data basically, and speakers ‑‑ sorry, the most unencrypted traffic is the streaming video. And speakers and televisions are the most recognisable encrypted traffic.
But what information is that? So how ‑‑ what is our methodology for understanding what these devices are to go with your data. First, we searched for all unencrypted traffic so and we started with the simple stuff, and we just see if encrypted traffic we can see PI I, so we configured these devices and put our mail, our name and we tried to understand if these PI I at least unencrypted traffic. Then we search for traffic for media markers. We look for colour content, mike content and the last part is the most difficult because we try to understand patterns for activities, so we know, for example, when you are ‑‑ there is a motion, the device is sending certain A traffic and apply this to the traffic we don't know, the idle traffic or uncontrolled and we try to see if we saw these patterns.
So, the fridge is sending the Mac address completely unencrypted and this home LE D is doing the same, and the I NS T E O N hub for controlling motion sensors or smart box and this camera from China but that was done for the EU market is sending the time stamp, each time this is a motion at home, sending the time stamp and video of the motion completely unencrypted.
We saw other unencrypted content like fire ware updates so this makes the device recognisable, from separate parties or third parties.
How we can infer activity? So for us activity information can be interaction method, so if the user is using an app or companion device for activating the device, or we can imagine functionality like switching on and off the light. The idea is that as I said before, we have a traffic patterns and can apply this traffic to the unknown traffic. And how you do that, you do that as you to with everything nowadays using machine learning, supervised machine learning. So we use random forestry class fire, of course, and for other features we consider the packet size, the interlink time between packets and we use cross‑validation and F1 store.
So, for us activity is predictable when the F1 score greater than 0.75 and we discovered the most predictable activity is when powering on and off devices. Maybe because when you are powering on the devices is contacting more destinations because of traffic on DNS recast.
And the ‑‑ activity is more predictable when it generates more traffic, so videos, cameras, televisions, are still the more vulnerable devices.
But another question that we had is: Is the devices doing something weird? So unexpected. And for doing that, we find that the traffic patterns for our control experiments and we apply it to the uncontrolled experiments and to the idle and we try understand if we can infer the activity.
What we found is that these popular door bells, is from Amazon. They are, even if you disable the fact that you don't want to receive them, the video of the motion, the video each time there is a motion at home, they are still continuously recording and sending to the Cloud. So we recognise these activities for the uncontrolled experiment.
So, televisions and all dongles, like fire TV, they are contacting Facebook, Netflix, double click and even if you don't have the app on the television, even if you never login install the apps and you can have more information about this in article that went out three weeks about our work in the Financial Times, talking about televisions and streaming video devices, contacting third parties.
And then, there are some ‑‑ we are working more on this because this is like apart from all the other work, and so we are trying to understand if Alexa activates even if you are not saying "Alexa" and we discovered sometimes it's activated with some sentence like: "I like Star Trek." So they really need to improve the method of the weak words.
Found some cameras triggered falsely the motion, because the device was in the room but they detect a motion. And the device ‑‑ switching off and on a lot, so they disconnected from the wi‑fi or switching off and on and they refresh very frequently. There are some devices doing this more than others but they are doing it.
So in conclusion, this is the first step before extended, this is the extended work on devices for activities, particularly for consumers. And the value of this work is having two best beds in different regions so you can compare. And as you saw non‑first parties are contacted by many devices. Some devices, 24 of 81, you can infer the activity from that devices. And they do also some unexpected activities, and if you want to know more about this, there is a lot more work, it's in our web page, and if you want to use our tool, then you have there all the test‑bed automation, you can build your own mini test‑bed using our tool, classified experiments in the device so you can repeat our experiment if you don't want to do our own test‑bed you can use our data because we also put everything online and you can freely download it. So we have ‑‑ 112 traffic for idle and for the controlled experiments and you have also the analysis scripts. So you can ‑ you have everything, basically, you don't have excuse.
And that's all. Thank you very much. Questions?
(Applause)
Another thing. No one of these IoT devices are using MUD files. And
ELIOT LEAR: They are consumer devices but you can still generate MUD files for them.
ANNA MARIA MANDALARI: I know. This will be the next step maybe. If I will do, it will be like in my test beds. The idea is that the manufacturers ‑‑
ELIOT LEAR: The idea has to catch with them, if they see it, what you have done, it may just do that.
CHAIR: We have one minute so please.
MARCO HOGEWONING: RIPE NCC but private. Can you clarify regarding the Mac addresses. Is that the Mac address flowing across the Internet back to the operator? Because I can assume in the LAN the Mac address should be plain text because otherwise you have got a problem?
ANNA MARIA MANDALARI: We are talking about the payload, yes.
JIM REID: Very interested observer. Great talk and very interesting work you and your colleagues are doing.
Two quick questions:
First one is, what do you think might be the ultimate purpose of your research? You plan to publish a list of naming and shaming vendors and products they produce so can inform the public, don't buy this brand of toaster because it's listening to your e‑mail or whatever?
My second question: Have you seen any evidence these IoT starting to use DNS over https?
ANNA MARIA MANDALARI: The first question is a great idea. We are planning to have a web page for the sort of classifier, so you can click let's say, Echo Sport and see this device is called like 8 over 10, because it's contacting this many destinations and sending the traffic encrypted, so we can have some baseline for understanding how good is the devices, and this will be useful for the community or for interservice provider and manufacturer and they have to do more.
For the second question, no, we didn't see any do.
JAN ZORZ: Random consumer. This is all very horrible and you know that, right? So, in my home, I already starting putting devices on the blacklist. So I actually reversed the firewall, and I'm protecting the Internet from my devices talking to the Internet. Doorbell being one of them, next one is probably new TV and all this stuff. And I would be very interested to run the code of yours and see what other devices in my house are talking to the rest of the world that I probably don't want to. So thank you.
ANNA MARIA MANDALARI: Thanks.
(Applause)
CHAIR: As you all know, we had a RIPE IoT hackathon just before the RIPE 79, so Constanze one of the organising committee so she'll explain what happened during the hackathon and what could be the future action items.
CONSTANZE DIETRICH: Hi, I am going to give you a quick update on the tenth IoT ‑‑ no, the tenth RIPE NCC hackathon, which was dedicated to the IoT. Do I have a clicker?
So, how did we end up here? Basically, Jim said let's to a hackathon and have a team figure out the rest. We had nine conference calls, published two articles, figured out logistics and promoted the hackathon wherever it even remotely made sense basically. We looked for front end and back end developers, engineers, scientists or researchers, UX designers, basically for everyone who is passionate about the IoT or sceptical, because maybe something you have to discuss with people who had rather not so pleasant experiences. Right. And I am not quite sure how many applications we got, I think it was about 55 ‑‑ 61 with us as organisers. Right. And 22 project proposals, of which 4 ended up being worked on in the hackathon.
The first one was team PARGAV who changed their acronym confusingly. They decided privacy for generic research ‑‑ visualisations. As I have been told, that was merger of three projects and Anna Maria also provided the data sets they used. Goal was a proof of concept of detecting traffic anomalies of home network devices based on patterns and used existing sets and looked for parameters such as bandwidth connections, star gets or ports.
The team was divided ‑‑ well, divided themselves basically in three tasks, which was data processing, visualisation and anomaly detection and the findings can be used to train AIs, for example, in the future.
Team Maria delivered what we considered the most complete project. They focused on a technology for low data rate long range communication between low powered devices and addressed those expensive these gateways are, by using Raspberry Pi as a gateway and adding Atlas RIPE probe functionalities to it.
And they got it working. For both a full DBN packages were even available on the platform. In the future users are supposed to be able to install these packages to their Raspberry Pi and use it as a probe. On that regard, the probe software still makes some kind of challenges but the team already drafted a list of things to change. Moreover, Randy plans to get this thing on a commercial router in order to make router an Atlas probe. Which is pretty cool.
Here we see our team ‑‑ doomsday ‑‑ they discussed how to handle a zombie apocalypse without having access to the global Internet, they didn't exactly call it that but what else is it supposed to be about when it's about alerts and warnings? What they did was, developing a concept of how to deliver authenticated information to devices and they are users, after all, in fragmented networks. So the current state of IP networks requires clients to know the IP address of the desired data before fetching that, however in such scenarios, either non‑hosts are not reachable due to network fragmentation or the client is not aware of the responsible host.
So, obviously, we needed drones. In this case a drone works basically as the medium collecting information from a trusted source and delivering it to the user by hovering the neighbourhood, and at the hackathon they presented a basic dissemination scenario focusing on information‑centric networking with it's in‑network caching to store the data. In the future they will be looking into authentication to make sure it's not the zombies sending or requesting information. So, our smallest team, grew over the cross of the hackathon with two late comeers, I think. They had a noble goal, I think, which was measuring the sometimes somewhat terrible wi‑fi in German railway stations. That said, a low end E SP 32 serving as a wi‑fi probe can basically be used everywhere where you don't really trust your service provider. As reliability was one of the main roles to measure the quality of service.
As most other projects, they didn't start from scratch, actually Chris to have had quite a few ‑‑ visualising incoming traffic with Rafana which they managed to do, as well as refactoring the code. With several hundred lines of code sometimes you need to clean up and rearrange stuff to allow for stuff like unit testing etc.. this team used the weekend off to get some fun work done, which is certainly one of the things we considered when keeping the topic of the hackathon that broad.
Right. So, I will be quick here. This was fun. From discussing how to disable the smoke detectors to be able to use the solaring station after all, up to having the participants being creepily focused on their projects, like I really tried hard sometimes to get them to lunch but they just wouldn't listen. It was a cool thing to organise, also because of the team, and we are actually quite happy with the outcome. There will be at least one more article published on RIPE Labs and as one of the requirements for the projects was to ‑‑ well, publish potential code under a free Open Source licence, there also will be code. Moreover, we made sure the participants get the chance to talk at the next RIPE meeting in case they continue to work on their projects.
And of course, as this really was fun, we would like to do more hackathons and consider keeping the topic even broader as it's good for people to just work on their projects and be focused in this moment.
So, right. And it would be good to get other Working Groups on board for that.
Right. So, thanks to Jim Reid, Sandoche, Matthias, Vesna and a lot of other RIPE NCC staff for doing this, because it was just fun, it was fun. Okay. That's it.
(Applause)
CHAIR: We do have some time for questions and if you have any feedback on hackathon and if you think do you want to participate or to have another hackathon, please.
CONSTANZE DIETRICH: One more comment. So I didn't explain I think, the people you see here in green, they are here, so if you have any questions about projects contact them directly.
JIM REID: Working Group co‑chair, I would like to say thank you very much to Constanze, Sandoche and Vesna in particular for being the organising committee and doing all the hard work to make this thing such a great success.
And I'd like to pay a personal thanks to all of the NCC staff who facilitated this and voluntarily gave up their weekend to make the whole thing happen. I am very grateful for this whole effort, thank you very much, much appreciated.
(Applause)
CONSTANZE DIETRICH: Can we mention the participants? Thanks to the participants, you were great.
CHAIR: So that ‑‑ Jim wanted to do a BCOP document, so Jim will explain it.
JIM REID: Thank you very much, everybody. This will be very, very short, I hope. You might remember that we had a little bit of discussion two RIPE meetings ago after Michael's excellent remote presentation about his work on MUD files and things. And we thought maybe there was a possibility for producing a RIPE document or two, one might be to see try and figure out how we can do mitigation of these kind of attacks and these devices potentially could be exposed to, and also, maybe another one to try and document the problem space.
Now, so far, we haven't had any great success at trying to produce those documents. I am trying to get a sense of the room at this moment. Is this something that people are willing to work on? If anyone is interested in working in this, trying to push the document we could put out, put your hand up. I can see Peter, Jan, Sandoche and Michael. Eliot and myself and I am sure if we all get together and have a chat and try and produce; I think the need for some documentation which doesn't easily fit in these kind of fora, so maybe we could with general benefit for the community.
JAN ZORZ: With my BCOP task force hat on, I think this would be a great.
JIM REID: We are done. And for the first time ever we finish ahead of time. I blame the new co‑chair.
LIVE CAPTIONING BY AOIFE DOWNES, RPR
DUBLIN, IRELAND
