Re: [iot-wg] "The Internet of Threats: Fighting FUD with MUD"
...and now bringing my question/suggestion to the mailing list. Previously on topic: we've agreed (haven't we?) that MUD is not currently targeting industrial IoT and connected health. So, smart homes. (By the way, it is more proper to directly specify the issue you're handling before proposing a solution. As MUD doesn't solve the security problem of IoT in general, let's then call it a solution for smart homes, but not a solution for IoT.) The issue with smart homes, wearables etc. is that a contemporary commodity IoT device is not connected to the Internet in order to really provide a service to the customer. Instead, it collects, processes and sends data and telemetry which is precious for its vendor, which said vendor would then be able to sell. - https://www.theverge.com/2017/7/24/16021610/irobot-roomba-homa-map-data-sale - https://www.warc.com/newsandopinion/news/general_motors_generates_new_radio_... - et cetera. Expecting a vendor to cut their own cables themselves is a strange move, isn't it. Hence, "default policy is no access" stuff isn't just going to fly. And, setting a firewall will only slightly help because of countless reasons. a) We have agreed today (haven't we?) that an IoT device needs to be updated frequently, and probably via the Internet. Let's now phrase it in a different way: we have agreed that an IoT device has a right to connect to a server of its vendor and exchange encrypted data with that server. Good luck telling updates from telemetry streaming then. b) Given a), a vendor will have an 100% legitimate excuse for denying you a service (i.e. remotely switching off a device, or more precisely, *not switching it on*) if the device doesn't have an Internet connectivity. c) Moreover, if a data collected by roombas would be actually worth selling, we can prophesize that ToSes for devices would start to *include* that connectivity requirement. I.e. if you don't want to share data with a vendor, then you must not buy this $9 vacuum cleaner but should rather go for that $199 vacuum cleaner, because it costs $150 to produce the device and for the former, the remaining $141 are covered by selling the data you don't want to share now. I'd be thrilled to see if anyone would be really going to spend additional $190 for privacy and security. d) Also, if said data is worth selling, setting up a firewall won't help because an IoT device will then use whatever radio technology built-in to connect to the Internet without your nice firewall. The only outcome would be an increased manufacturing cost because of additional radio module (and yes, it's the customer who's gonna pay for this). Sorry guys. Nothing personal, it's just business. e) You cannot possibly set a firewall between the Internet and wearables, SmartTV, cars, etc. ... I'm curious how does MUD address those concerns. | Töma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera@gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58
Töma Gavrichenkov <ximaera@gmail.com> wrote: > Previously on topic: we've agreed (haven't we?) that MUD is not > currently targeting industrial IoT and connected health. So, smart > homes. The authors of the MUD specification have specific industrial uses in mind. > (By the way, it is more proper to directly specify the issue you're > handling before proposing a solution. As MUD doesn't solve the In a 15 minute presentation, there isn't time for that. If you'd like to have a longer conversation, that would be great. > The issue with smart homes, wearables etc. is that a contemporary > commodity IoT device is not connected to the Internet in order to > really provide a service to the customer. Instead, it collects, > processes and sends data and telemetry which is precious for its > vendor, which said vendor would then be able to sell. I agree that there are many devices like this. If the device provides no value to end user, then the garbage bin is probably the appropriate security. Vote with your wallet. > Expecting a vendor to cut their own cables themselves is a strange > move, isn't it. Hence, "default policy is no access" stuff isn't just > going to fly. The purpose of the MUD file is to encode the list of acceptable destinations, and without such a file, there is no access. So, if it is acceptable to the end user that their vacuum cleaner maps out their house, then they can enable the access. The purpose of this work is keep the vacuum cleaner, when compromised, from being used to attack the infrastructure of the Internet. > And, setting a firewall will only slightly help because of countless > reasons. > a) We have agreed today (haven't we?) that an IoT device needs to be > updated frequently, and probably via the Internet. Let's now phrase it > in a different way: we have agreed that an IoT device has a right to > connect to a server of its vendor and exchange encrypted data with > that server. Good luck telling updates from telemetry streaming then. If the vendor wants to hide telemetry inside firmware updates, that's okay. That's not the goal. > b) Given a), a vendor will have an 100% legitimate excuse for denying > you a service (i.e. remotely switching off a device, or more > precisely, *not switching it on*) if the device doesn't have an > Internet connectivity. Agreed. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
On 19/10/2018 17:10, Michael Richardson wrote:
The purpose of the MUD file is to encode the list of acceptable destinations, and without such a file, there is no access.
The purpose of this work is keep the vacuum cleaner, when compromised, from being used to attack the infrastructure of the Internet.
That is why I believe in some additional 'MUD-features', such as restricting bandwidth (not every fridge needs 100Mbit/s), or restricting access to the internet only on certain hours of the day. It seems that another idea of ours, restricting access based on DNS-queries, seems to already been incorporate in the current version of the draft. Cool ;-) Maybe there are other ideas as well? -- Marco Davids Research Engineer SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 00 | marco.davids@sidn.nl www.sidnlabs.nl | www.sidn.nl XMPP: marco.davids@jabber.sidn.nl | Twitter: @marcodavids
On 19 Oct 2018, at 16:23, Marco Davids <Marco.Davids@sidn.nl> wrote:
It seems that another idea of ours, restricting access based on DNS-queries, seems to already been incorporate in the current version of the draft. Cool ;-)
Marco, you might be too optimistic. :-( If DoH takes off, IoT devices might well use port 443 rather than port 53 to do their lookups. IMO DoH is going to be a game-changer. And not just for IoT.
DoH? How to resolve local add? How can Enterprise controll trafic? Using DoH will more or less switch of local DNS server, are we shure we want this? Groet, Eric Von: "Jim Reid" <jim@rfc1035.com> An: "Marco Davids" <Marco.Davids@sidn.nl> Kopie: "RIPE IoT WG List" <iot-wg@ripe.net> Datum: 19-10-2018 18:09 Betreff: Re: [iot-wg] "The Internet of Threats: Fighting FUD with MUD" Gesendet von: "iot-wg" <iot-wg-bounces@ripe.net>
On 19 Oct 2018, at 16:23, Marco Davids <Marco.Davids@sidn.nl> wrote:
It seems that another idea of ours, restricting access based on DNS-queries, seems to already been incorporate in the current version of the draft. Cool ;-)
Marco, you might be too optimistic. :-( If DoH takes off, IoT devices might well use port 443 rather than port 53 to do their lookups. IMO DoH is going to be a game-changer. And not just for IoT. _______________________________________________ iot-wg mailing list iot-wg@ripe.net https://lists.ripe.net/mailman/listinfo/iot-wg
On 19 Oct 2018, at 17:41, e.vanuden@avm.de wrote:
DoH?
DNS over HTTP(S). See Sara Dickinson’s *excellent* presentation from Monday’s plenary.
How to resolve local add?
You don’t. The focus of DoH is improving the browser experience. Whatever that ugly phrase means. DoH is orthogonal to the issues around resolving local names or addresses.
How can Enterprise controll trafic?
They don’t/can’t. Unless they can force everything through a suitable TLS1.3 capable web proxy. Or configure every edge device to only use the enterprise's DoH resolvers. Good luck with that.
Using DoH will more or less switch of local DNS server, are we shure we want this?
Whether you want this or not, DoH’s going to happen and it’ll be verging on the impossible to stop. The browser vendors are mostly driving this. DoH support is already shipping in Chrome and Firefox. [It’s in Android Pie too.] Once this gets switched on, Chrome and Firefox should be faster at loading pages because there’s reduced DNS latency. Which should mean the other browser vendors will be obliged to deploy DoH to catch up. The big CDNs will pile in behind them* and then it’s game over. Most web-based DNS traffic will go dark. * Imagine the opportunities for a CDN if it was able to couple an end user's DNS queries to their browser preferences. This akamai blog posting is well worth reading though it’s not so apocalyptic: https://blogs.akamai.com/2018/10/architectural-paths-for-evolving-the-dns.ht... The blog by one of the people behind DoH is also a good read: https://bitsup.blogspot.com/2018/05/the-benefits-of-https-for-dns.html Further discussion of DoH in general belongs on another list, perhaps dns-wg@ripe.net. We should try to keep the discussion here on the impact/use of DoH by IoT devices.
Hi Jim, Thanks for your reply. I know what DoH is. Sorry that I was to short. The questionmark was meant in the case, I don't see it as a solution for IoT security. Regards, Eric Oorspronkelijk bericht Van: jim@rfc1035.com Verzonden: 19 oktober 2018 19:50 Aan: e.vanuden@avm.de Cc: iot-wg@ripe.net Onderwerp: Re: [iot-wg] DoH - TEOTIAWKI? On 19 Oct 2018, at 17:41, e.vanuden@avm.de wrote:
DoH?
DNS over HTTP(S). See Sara Dickinson’s *excellent* presentation from Monday’s plenary.
How to resolve local add?
You don’t. The focus of DoH is improving the browser experience. Whatever that ugly phrase means. DoH is orthogonal to the issues around resolving local names or addresses.
How can Enterprise controll trafic?
They don’t/can’t. Unless they can force everything through a suitable TLS1.3 capable web proxy. Or configure every edge device to only use the enterprise's DoH resolvers. Good luck with that.
Using DoH will more or less switch of local DNS server, are we shure we want this?
Whether you want this or not, DoH’s going to happen and it’ll be verging on the impossible to stop. The browser vendors are mostly driving this. DoH support is already shipping in Chrome and Firefox. [It’s in Android Pie too.] Once this gets switched on, Chrome and Firefox should be faster at loading pages because there’s reduced DNS latency. Which should mean the other browser vendors will be obliged to deploy DoH to catch up. The big CDNs will pile in behind them* and then it’s game over. Most web-based DNS traffic will go dark. * Imagine the opportunities for a CDN if it was able to couple an end user's DNS queries to their browser preferences. This akamai blog posting is well worth reading though it’s not so apocalyptic: https://blogs.akamai.com/2018/10/architectural-paths-for-evolving-the-dns.ht... The blog by one of the people behind DoH is also a good read: https://bitsup.blogspot.com/2018/05/the-benefits-of-https-for-dns.html Further discussion of DoH in general belongs on another list, perhaps dns-wg@ripe.net. We should try to keep the discussion here on the impact/use of DoH by IoT devices.
On 19 Oct 2018, at 19:31, e.vanuden@avm.de wrote:
I know what DoH is. ... I don't see it as a solution for IoT security.
Indeed. If anything, DoH uptake by IoT devices will worsen the already unpleasant security problems.
e.vanuden@avm.de wrote: > I know what DoH is. Sorry that I was to short. The questionmark was meant in > the case, I don't see it as a solution for IoT security. It's a challenge to IoT security, as it means that one can no longer do name-based security in the MUD file.
Marco Davids <Marco.Davids@sidn.nl> wrote: >> The purpose of this work is keep the vacuum cleaner, when >> compromised, from being used to attack the infrastructure of the Internet. > That is why I believe in some additional 'MUD-features', such as > restricting bandwidth (not every fridge needs 100Mbit/s), or restricting > access to the internet only on certain hours of the day. I agree that these would be a beneficial extensions. > It seems that another idea of ours, restricting access based on > DNS-queries, seems to already been incorporate in the current version of > the draft. Cool ;-) It's damn annoying to implement, and violates lot of layering. But, in an HTTPS-everywhere world, particularly one where google.com gives different answers at different times, it's necessary. The google.com entrance gateways do all sorts of things: we enabled access to google analytics for our demo, and then realized that it provided access to google.com as well. This is something I'd like to engage google about. (Not an issue in IPv6) > Maybe there are other ideas as well? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
[This time with feeling- to everyone] Dear Marco and other colleagues, On 19.10.18 17:23, Marco Davids wrote:
That is why I believe in some additional 'MUD-features', such as restricting bandwidth (not every fridge needs 100Mbit/s), or restricting access to the internet only on certain hours of the day.
I would like to bring to your attention a new draft: https://datatracker.ietf.org/doc/draft-lear-opsawg-mud-bw-profile/ The purpose of this draft is to describe the behavior of devices that are MUD-capable in terms of bandwidth utilization. You will note that the draft is marked as experimental. We can change this designation, depending on how the work progresses. I have already received several comments on ways in which the model can be simplified, and several comments on how it can be otherwise improved, having only published it a few days ago. This having been said, I solicit your thoughts and comments. In particular: * How might we assist manufacturers in completing this aspect of the MUD file? * What are we missing? * Is the classification approach (ACLs) correct? Eliot
Dear Töma, first of all a great thanks for your talk on RIPE 77 - nice to see we have the same favourite band ;)
Previously on topic: we've agreed (haven't we?) that MUD is not currently targeting industrial IoT and connected health. So, smart homes.
(By the way, it is more proper to directly specify the issue you're handling before proposing a solution. As MUD doesn't solve the security problem of IoT in general, let's then call it a solution for smart homes, but not a solution for IoT.)
The issue with smart homes, wearables etc. is that a contemporary commodity IoT device is not connected to the Internet in order to really provide a service to the customer. Instead, it collects, processes and sends data and telemetry which is precious for its vendor, which said vendor would then be able to sell.
- https://www.theverge.com/2017/7/24/16021610/irobot-roomba-homa-map-data-sale <https://www.theverge.com/2017/7/24/16021610/irobot-roomba-homa-map-data-sale> - https://www.warc.com/newsandopinion/news/general_motors_generates_new_radio_... <https://www.warc.com/newsandopinion/news/general_motors_generates_new_radio_advertising_insights/41073> - et cetera.
Expecting a vendor to cut their own cables themselves is a strange move, isn't it. Hence, "default policy is no access" stuff isn't just going to fly.
The question here to me seems what we want to achieve. I’m totally on your page in terms of data collection and privacy. But that’s to a large part the end users choice - even if I have to admit most of them simply don’t care, just look at the amount of data people share via facebook: Happy social engineering! My concern is more the integrity of the network infrastructure and how to reduce the impact of hacked IoT devices used by DDOS attacks. MUD files can help to identify what’s a devices purpose and monitoring if the device is doing what it’s supposed to do. I agree that we should not have much hope that the device makers will do their job but I’m sure a community fueld MUD proxy could play a role here.
d) Also, if said data is worth selling, setting up a firewall won't help because an IoT device will then use whatever radio technology built-in to connect to the Internet without your nice firewall. The only outcome would be an increased manufacturing cost because of additional radio module (and yes, it's the customer who's gonna pay for this). Sorry guys. Nothing personal, it's just business.
e) You cannot possibly set a firewall between the Internet and wearables, SmartTV, cars, etc.
That’s totally true in terms of privacy and data mining, but here - as said - it’s the customer’s choice (given all the cons we all know). In therms of preventing IoT devices being abused for DDOS firewalling can help. What’s not been adressed so far is the fact that a hacked IoT device could be used to hack other IoT device in an end user’s network. That can not be prevented by firewalling in most cases but there are a few things that can be done (separate network segments for differnet IoT device classes, isolation for wirelessly connected devices, UPnP control etc.). The SPIN project https://www.sidnlabs.nl/a/weblog/spin-a-user-centric-security-extension-for-... <https://www.sidnlabs.nl/a/weblog/spin-a-user-centric-security-extension-for-in-home-networks> and the activities of the IETF home network working group presented in Michael’s talk on Thursday follow similar approaches and I think we should work into that direction. Regards, Peter Peter Steinhäuser, CEO embeDD GmbH · Alter Postplatz 2 · 6370 Stans · Switzerland Phone: +41 (41) 784 95 85 · Fax: +41 (41) 784 95 64
On 21 Oct 2018, at 11:40, Peter Steinhäuser <ps@embedd.com> wrote:
The question here to me seems what we want to achieve. I’m totally on your page in terms of data collection and privacy. But that’s to a large part the end users choice - even if I have to admit most of them simply don’t care, just look at the amount of data people share via facebook: Happy social engineering!
Yes and no. I’d like to think that most people would be *far* more careful about their use of social media if they knew how their data were being exploited and/or thought about the long term consequences of that. Then again, users of social media are mostly idiots IMO. And that’s before we get to making the cost/benefit analysis of supposedly “free” services in exchange for reduced privacy and 24x7 surveillance by our corporate overlords.
My concern is more the integrity of the network infrastructure and how to reduce the impact of hacked IoT devices used by DDOS attacks.
That’s a big and scary problem Peter. But it’s not the only one. I’m also concerned about these home assistants^W^Wspyware people install with little or no consideration: “Hey Alexa/Siri/whatever, turn on the webcams in my neighbour’s house”. Then there's the damage that can be done by tampering with weakly secured door entry systems, so-called smart meters and allegedly smart thermostats. Imagine a 21st century version of the Internet worm that borks smart meters and leaves people without power or water.
MUD files can help to identify what’s a devices purpose and monitoring if the device is doing what it’s supposed to do. I agree that we should not have much hope that the device makers will do their job.
Indeed. However at least MUD files should (in principle anyway) give people an idea of what their latest IoT toy will do once it’s plugged in. Though just saying it phones home to google/Amazon/Facebook every so often isn’t much help if you don’t know what it's sending and receiving. Or why it’s doing that. MUD files are a small step in the right direction. Hopefully we’ll one day see this information printed on the IoT device itself and the box it comes in. BTW, Jelte spoke about the SPIN project at the WG meeting in Marseille. It was a revelation to see how much data was being sent outside his home network from its IoT devices. [And on a related note, why does my DVD player call the mothership and what data are being exchanged?] Michael’s idea of an IoT firewall would mean we can see what’s going on. This sort of thing will be essential if the concept of informed consent means anything.
The question here to me seems what we want to achieve. I’m totally on your page in terms of data collection and privacy. But that’s to a large part the end users choice - even if I have to admit most of them simply don’t care, just look at the amount of data people share via facebook: Happy social engineering!
Yes and no. I’d like to think that most people would be *far* more careful about their use of social media if they knew how their data were being exploited and/or thought about the long term consequences of that.
I agree but I have no real idea how to make people aware. Most of the end users focus on convenience - do we really have to see more cases of misuse of personal data? I don’t know...
MUD files can help to identify what’s a devices purpose and monitoring if the device is doing what it’s supposed to do. I agree that we should not have much hope that the device makers will do their job.
Indeed. However at least MUD files should (in principle anyway) give people an idea of what their latest IoT toy will do once it’s plugged in. Though just saying it phones home to google/Amazon/Facebook every so often isn’t much help if you don’t know what it's sending and receiving. Or why it’s doing that.
MUD files are a small step in the right direction. Hopefully we’ll one day see this information printed on the IoT device itself and the box it comes in.
I absolutely agree. But as long as the device makers don’t see a benefit in providing (correct) MUD files we have to seek ways to create them. Also a MUD file provided by the device maker with detailed information would not prevent the device from sending personal data or doing things the end user doesn’t like as long as it’s encoded correctly in the MUD file. I did like the MUD proxy idea from Michael’s presentation that provides „correct“ MUD files. Another concern is how far CPE/home gateway manufacturers would adopt related technical proposals. So far most firmwares are based upon chipset maker’s SDKs that serve the purpose of selling chipsets instead of providing reliable and secure solutions. The lastest FCC and ETSI rulings (=> RED discussion) did also not make it easier to provide alternative firmware solutions (i.e. OpenWRT), let’s see how the RED ruling goes.
Peter Steinhäuser <ps@embedd.com> wrote: > I did like the MUD proxy idea from Michael’s presentation that provides > „correct“ MUD files. Some of the security criticisms of the mud spec is that: a) a MUD controller does not have to check the signature b) the entity that signed the MUD file has no clear relationship to the manufacturer. It's basically TOFU. c) it is underspecified as to what to do if the URL inside the MUD file that points to the signature file is a relative URL. So our idea is that we would like to have a cloud service that provides currated MUD files, signed with a signature that is properly anchored. It is my understanding that for industrial uses, that this is where some vendors think the money is: in the subscription to this service. The SHG crew are looking towards some kind of crowd-sourced service where people collaborate to improve MUD files. It would be as simple as a github repo on which people can send pull requests, but the curration activitiy would require too much human resources in such a simple situation. In particular, we'd want a MUD-diff program that presented the changes in a much easier to understand format. With voting up/down... so think stackexchange.com/serverfault/uservoice/etc. instead. > Another concern is how far CPE/home gateway manufacturers would adopt > related technical proposals. So far most firmwares are based upon > chipset maker’s SDKs that serve the purpose of selling chipsets instead > of providing reliable and secure solutions. The lastest FCC and ETSI > rulings (=> RED discussion) did also not make it easier to provide > alternative firmware solutions (i.e. OpenWRT), let’s see how the RED > ruling goes. I'd say a lot depends upon whether or not ISPs will put out an RFP that asks for an IoT firewall based upon MUD in future products. Maybe some one here would like to test the waters with an RFI. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
Am 22.10.2018 um 23:38 schrieb Michael Richardson <mcr@sandelman.ca>:
The SHG crew are looking towards some kind of crowd-sourced service where people collaborate to improve MUD files. It would be as simple as a github repo on which people can send pull requests, but the curration activitiy would require too much human resources in such a simple situation. In particular, we'd want a MUD-diff program that presented the changes in a much easier to understand format. With voting up/down... so think stackexchange.com/serverfault/uservoice/etc. instead.
having currated MUD files would make a lot of sense, indeed
Another concern is how far CPE/home gateway manufacturers would adopt related technical proposals. So far most firmwares are based upon chipset maker’s SDKs that serve the purpose of selling chipsets instead of providing reliable and secure solutions. The lastest FCC and ETSI rulings (=> RED discussion) did also not make it easier to provide alternative firmware solutions (i.e. OpenWRT), let’s see how the RED ruling goes.
I'd say a lot depends upon whether or not ISPs will put out an RFP that asks for an IoT firewall based upon MUD in future products. Maybe some one here would like to test the waters with an RFI.
What I’ve seen with ISPs is that - unfortunately - they are mostly concerned about cost. We had several cases where ISPs chose inferior solutions which cost them more money in the long run. But somebody in the purchase department got a raise. As long as the ISPs do not understand the cost that can result from hacked IoT devices I doubt will ask for something that doesn’t bring them additional revenue. Another issue are the ODMs. The software development here is rarely focused on longevity - it’s important to get the products out of the doors with minimum effort. So even if an ISP is requiring an IoT firewall they will build something that works somehow. Maybe providing an OpenWRT package as reference might help...
Peter Steinhäuser <ps@embedd.com> wrote: >> I'd say a lot depends upon whether or not ISPs will put out an RFP >> that asks for an IoT firewall based upon MUD in future products. >> Maybe some one here would like to test the waters with an RFI. > What I’ve seen with ISPs is that - unfortunately - they are mostly > concerned about cost. We had several cases where ISPs chose inferior > solutions which cost them more money in the long run. But somebody in > the purchase department got a raise. As long as the ISPs do not > understand the cost that can result from hacked IoT devices I doubt > will ask for something that doesn’t bring them additional revenue. > Another issue are the ODMs. The software development here is rarely > focused on longevity - it’s important to get the products out of the > doors with minimum effort. So even if an ISP is requiring an IoT > firewall they will build something that works somehow. Maybe providing > an OpenWRT package as reference might help... The point of an RFI is to push the ODM vendors to notice a reference package. At this point, we are living on the expensive Omnia Turris device, hoping that it will move quickly to stock openwrt 18.06 (or 19.xx in January), rather than the custom (and difficult to use) build system it uses now. This ecosystem issue is what is keeping us from getting to a reference package situation. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
On 10/21/18 2:33 PM, Jim Reid wrote:
MUD files can help to identify what’s a devices purpose and monitoring if the device is doing what it’s supposed to do. I agree that we should not have much hope that the device makers will do their job.
Indeed. However at least MUD files should (in principle anyway) give people an idea of what their latest IoT toy will do once it’s plugged in. Though just saying it phones home to google/Amazon/Facebook every so often isn’t much help if you don’t know what it's sending and receiving. Or why it’s doing that.
Or, as it was in the case of Samsung Television voice control data, whether the data that is ostensibly sent for a reasonable purpose is passed on to third parties by the service anyway. No amount of technical measures will protect against that. But at least then it will be the services' responsibility.
MUD files are a small step in the right direction. Hopefully we’ll one day see this information printed on the IoT device itself and the box it comes in.
I have started to wonder whether this won't be the other way around. As in, whether device manufacturers might be forced to disclose what their devices will be doing on the internet (similar to how they should disclose what power they safely operate at), and that MUD (or MUD-like) profiles will be derived from that.
BTW, Jelte spoke about the SPIN project at the WG meeting in Marseille. It was a revelation to see how much data was being sent outside his home network from its IoT devices. [And on a related note, why does my DVD player call the mothership and what data are being exchanged?] Michael’s idea of an IoT firewall would mean we can see what’s going on. This sort of thing will be essential if the concept of informed consent means anything.
Peter and I have been in contact after that presentation :) Anyway, the move to everything being encrypted, while protecting against eavesdroppers, will certainly not help protect against what our devices are sending out. At most to whom initially (but now I am repeating myself). But that is already very revealing; I have done a few presentations about SPIN where we connected an audience member's phone to the system, and every single time something interesting has popped up so far. The biggest 'whoa what the' moment you can get, by the way, if you can show an Amazon Echo owner that Amazon stores -and you can play back- all the audio commands they have ever given those things. Jelte
Hi, I just joined this group. Today's and tomorrow's smart television are more a full blown computer with screen and keyboard, and it difficult to pin down exactly what the device should be doing in a MUD profile. It's not a real IoT device. A MUD profile for a thermostat or video camera or a real IoT device will be useful. The prototype has shown for far it's functionally possible to make MUD work. Jack
-----Original Message----- From: iot-wg <iot-wg-bounces@ripe.net> On Behalf Of Jelte Jansen Sent: October 22, 2018 12:29 AM To: Jim Reid <jim@rfc1035.com>; Peter Steinhäuser <ps@embedd.com> Cc: RIPE IoT WG List <iot-wg@ripe.net> Subject: Re: [iot-wg] "The Internet of Threats: Fighting FUD with MUD"
MUD files can help to identify what’s a devices purpose and monitoring if the device is doing what it’s supposed to do. I agree that we should not have much hope that the device makers will do their job.
Indeed. However at least MUD files should (in principle anyway) give people an idea of what their latest IoT toy will do once it’s plugged in. Though just saying it
On 10/21/18 2:33 PM, Jim Reid wrote: phones home to google/Amazon/Facebook every so often isn’t much help if you don’t know what it's sending and receiving. Or why it’s doing that.
Or, as it was in the case of Samsung Television voice control data, whether the data that is ostensibly sent for a reasonable purpose is passed on to third parties by the service anyway. No amount of technical measures will protect against that. But at least then it will be the services' responsibility.
MUD files are a small step in the right direction. Hopefully we’ll one day see this information printed on the IoT device itself and the box it comes in.
I have started to wonder whether this won't be the other way around. As in, whether device manufacturers might be forced to disclose what their devices will be doing on the internet (similar to how they should disclose what power they safely operate at), and that MUD (or MUD-like) profiles will be derived from that.
BTW, Jelte spoke about the SPIN project at the WG meeting in Marseille. It was a revelation to see how much data was being sent outside his home network from its IoT devices. [And on a related note, why does my DVD player call the mothership and what data are being exchanged?] Michael’s idea of an IoT firewall would mean we can see what’s going on. This sort of thing will be essential if the concept of informed consent means anything.
Peter and I have been in contact after that presentation :)
Anyway, the move to everything being encrypted, while protecting against eavesdroppers, will certainly not help protect against what our devices are sending out. At most to whom initially (but now I am repeating myself). But that is already very revealing; I have done a few presentations about SPIN where we connected an audience member's phone to the system, and every single time something interesting has popped up so far.
The biggest 'whoa what the' moment you can get, by the way, if you can show an Amazon Echo owner that Amazon stores -and you can play back- all the audio commands they have ever given those things.
Jelte
_______________________________________________ iot-wg mailing list iot-wg@ripe.net https://lists.ripe.net/mailman/listinfo/iot-wg
Hi Jacques,
I just joined this group. Today's and tomorrow's smart television are more a full blown computer with screen and keyboard, and it difficult to pin down exactly what the device should be doing in a MUD profile. It's not a real IoT device.
nevertheless a MUD file could be used to describe service classes of a TV, like „TV Streaming“, „Social Media“ etc. to give the end user simple choices and at least some control about what the device should be allowed to do. Regards, Peter
Yes, we just talked about this at lunch, MUD would be useful to lockdown your smart TV to netflix and youtube only + vendor firmware update.
-----Original Message----- From: Peter Steinhäuser <ps@embedd.com> Sent: October 22, 2018 10:02 AM To: Jacques Latour <Jacques.Latour@cira.ca> Cc: Jelte Jansen <ripe@tjeb.nl>; Jim Reid <jim@rfc1035.com>; RIPE IoT WG List <iot-wg@ripe.net> Subject: Re: [iot-wg] "The Internet of Threats: Fighting FUD with MUD"
Hi Jacques,
I just joined this group. Today's and tomorrow's smart television are more a full blown computer with screen and keyboard, and it difficult to pin down exactly what the device should be doing in a MUD profile. It's not a real IoT device.
nevertheless a MUD file could be used to describe service classes of a TV, like „TV Streaming“, „Social Media“ etc. to give the end user simple choices and at least some control about what the device should be allowed to do.
Regards, Peter
Unfortunately MUD does not solve the possibility of corrupted/hacked update servers. This is a highly likely attack type we will see in the future. I highly appreciate your approach of detecting behaviour pattern changes of devices, it could help reducing the effects of hacked devices as well as from corrupted firmware updates. I also think a collaboration with the SPIN project would be really beneficial, they work on similar concepts and solutions and can contribute a lot.
Yes, we just talked about this at lunch, MUD would be useful to lockdown your smart TV to netflix and youtube only + vendor firmware update.
-----Original Message----- From: Peter Steinhäuser <ps@embedd.com> Sent: October 22, 2018 10:02 AM To: Jacques Latour <Jacques.Latour@cira.ca> Cc: Jelte Jansen <ripe@tjeb.nl>; Jim Reid <jim@rfc1035.com>; RIPE IoT WG List <iot-wg@ripe.net> Subject: Re: [iot-wg] "The Internet of Threats: Fighting FUD with MUD"
Hi Jacques,
I just joined this group. Today's and tomorrow's smart television are more a full blown computer with screen and keyboard, and it difficult to pin down exactly what the device should be doing in a MUD profile. It's not a real IoT device.
nevertheless a MUD file could be used to describe service classes of a TV, like „TV Streaming“, „Social Media“ etc. to give the end user simple choices and at least some control about what the device should be allowed to do.
Regards, Peter
I was talking to Cristian at lunch also about integrating SPIN, so yes, detecting and quarantining infected IoT device is important, but the big question is what do we do with the infected device.
-----Original Message----- From: Peter Steinhäuser <ps@embedd.com> Sent: October 22, 2018 1:51 PM To: Jacques Latour <Jacques.Latour@cira.ca> Cc: Jelte Jansen <ripe@tjeb.nl>; Jim Reid <jim@rfc1035.com>; RIPE IoT WG List <iot-wg@ripe.net> Subject: Re: [iot-wg] "The Internet of Threats: Fighting FUD with MUD"
Unfortunately MUD does not solve the possibility of corrupted/hacked update servers. This is a highly likely attack type we will see in the future.
I highly appreciate your approach of detecting behaviour pattern changes of devices, it could help reducing the effects of hacked devices as well as from corrupted firmware updates.
I also think a collaboration with the SPIN project would be really beneficial, they work on similar concepts and solutions and can contribute a lot.
Yes, we just talked about this at lunch, MUD would be useful to lockdown your smart TV to netflix and youtube only + vendor firmware update.
-----Original Message----- From: Peter Steinhäuser <ps@embedd.com> Sent: October 22, 2018 10:02 AM To: Jacques Latour <Jacques.Latour@cira.ca> Cc: Jelte Jansen <ripe@tjeb.nl>; Jim Reid <jim@rfc1035.com>; RIPE IoT WG List <iot-wg@ripe.net> Subject: Re: [iot-wg] "The Internet of Threats: Fighting FUD with MUD"
Hi Jacques,
I just joined this group. Today's and tomorrow's smart television are more a full blown computer with screen and keyboard, and it difficult to pin down exactly what the device should be doing in a MUD profile. It's not a real IoT device.
nevertheless a MUD file could be used to describe service classes of a TV, like „TV Streaming“, „Social Media“ etc. to give the end user simple choices and at least some control about what the device should be allowed to do.
Regards, Peter
I was talking to Cristian at lunch also about integrating SPIN, so yes, detecting and quarantining infected IoT device is important, but the big question is what do we do with the infected device.
Basically using the same quarantining used for new devices would be sufficient: a) drop all connections to the „outside" b) if the device is connected wirelessly isolate it at AP level c) inform the end user and recommend to remove it from the network (?) I don’t know in detail how you implemented the quarantining, are there any papers about it?
-----Original Message----- From: Peter Steinhäuser <ps@embedd.com> Sent: October 22, 2018 1:51 PM To: Jacques Latour <Jacques.Latour@cira.ca> Cc: Jelte Jansen <ripe@tjeb.nl>; Jim Reid <jim@rfc1035.com>; RIPE IoT WG List <iot-wg@ripe.net> Subject: Re: [iot-wg] "The Internet of Threats: Fighting FUD with MUD"
Unfortunately MUD does not solve the possibility of corrupted/hacked update servers. This is a highly likely attack type we will see in the future.
I highly appreciate your approach of detecting behaviour pattern changes of devices, it could help reducing the effects of hacked devices as well as from corrupted firmware updates.
I also think a collaboration with the SPIN project would be really beneficial, they work on similar concepts and solutions and can contribute a lot.
Yes, we just talked about this at lunch, MUD would be useful to lockdown your smart TV to netflix and youtube only + vendor firmware update.
-----Original Message----- From: Peter Steinhäuser <ps@embedd.com> Sent: October 22, 2018 10:02 AM To: Jacques Latour <Jacques.Latour@cira.ca> Cc: Jelte Jansen <ripe@tjeb.nl>; Jim Reid <jim@rfc1035.com>; RIPE IoT WG List <iot-wg@ripe.net> Subject: Re: [iot-wg] "The Internet of Threats: Fighting FUD with MUD"
Hi Jacques,
I just joined this group. Today's and tomorrow's smart television are more a full blown computer with screen and keyboard, and it difficult to pin down exactly what the device should be doing in a MUD profile. It's not a real IoT device.
nevertheless a MUD file could be used to describe service classes of a TV, like „TV Streaming“, „Social Media“ etc. to give the end user simple choices and at least some control about what the device should be allowed to do.
Regards, Peter
Peter Steinhäuser, CEO embeDD GmbH · Alter Postplatz 2 · 6370 Stans · Switzerland Phone: +41 (41) 784 95 85 · Fax: +41 (41) 784 95 64
Peter Steinhäuser <ps@embedd.com> wrote: > I don’t know in detail how you implemented the quarantining, are there > any papers about it? It's a proof-of-concept, so is no quarantine... We know how to do it. We can keep a wireless device seperated, but a wired device will be able to attack laterally.
Peter Steinhäuser <ps@embedd.com> wrote: > nevertheless a MUD file could be used to describe service classes of a > TV, like „TV Streaming“, „Social Media“ etc. to give the end user > simple choices and at least some control about what the device should > be allowed to do. Such a multi-functional device (in particular, any game console), might need to take on a multitude of identities for it's different personalities, with appropriate MUD files for each personality. (And possibly, parental MUD file overrides, including number of packets/bytes allowed to be transmitted per day, and even perhaps elapsed duration between first transmitted packet, and last one, to enforce "screen-time" limits) We currently implement filtering by L2 address (MAC). That's works for most Things, and it also lets us cleanly implement the quarantee function in a way that isn't *trivially* side stepped by changing L3 address. To meaningfully prevent changing L2 address, a group of students at Algonquin College, in collaboration of Telus have been working on making sure that there is a unique WPA key per mac address, and that it's easy to setup. That means that changing your mac address would mean losing access to the (wireless) network. How this will work with mac address randomization remains to be seen: my understanding is that after pure randomization, Apple realized that they should use the same mac address with the same AP in order to not annoy mac-address based controls. So the multi-functional device should adopt a policy of pick a unique, persistent mac address for each sub-function or "game". My observation of how our family Wii(U) works is that all the networking boots up each time for each game, and so this probably would be easy to do. Mind, I also use a wired USB cable on GbE to keep the video streaming away from the fragile WiFi, so there is no WiFi key to help me keep an p0woned WiiU From going bonkers by changing MAC address all the time. This brings up the default policy for new devices: it needs to be restrict. But this is gonna be a pain in quite a number of situations, so it needs a really intuitive user interface. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
Am 22.10.2018 um 23:49 schrieb Michael Richardson <mcr@sandelman.ca>:
nevertheless a MUD file could be used to describe service classes of a TV, like „TV Streaming“, „Social Media“ etc. to give the end user simple choices and at least some control about what the device should be allowed to do.
Such a multi-functional device (in particular, any game console), might need to take on a multitude of identities for it's different personalities, with appropriate MUD files for each personality. (And possibly, parental MUD file overrides, including number of packets/bytes allowed to be transmitted per day, and even perhaps elapsed duration between first transmitted packet, and last one, to enforce "screen-time" limits)
I see the point, that would get pretty complex...
We currently implement filtering by L2 address (MAC). That's works for most Things, and it also lets us cleanly implement the quarantee function in a way that isn't *trivially* side stepped by changing L3 address. To meaningfully prevent changing L2 address, a group of students at Algonquin College, in collaboration of Telus have been working on making sure that there is a unique WPA key per mac address, and that it's easy to setup. That means that changing your mac address would mean losing access to the (wireless) network.
I think current MAC whitelisting would be sufficient (?) Assigning individual WPA keys for each IoT device sounds impractical to me.
This brings up the default policy for new devices: it needs to be restrict. But this is gonna be a pain in quite a number of situations, so it needs a really intuitive user interface.
Absolutely!
On 22 Oct 2018, at 00:29, Jelte Jansen <ripe@tjeb.nl> wrote:
The biggest 'whoa what the' moment you can get, by the way, if you can show an Amazon Echo owner that Amazon stores -and you can play back
Which might lead to other “interesting directions” re. storage of personal data for prolonged period of time. Consider the old phone sales, where the conversation is recorded as proof of a contract entered or consent being given. Can imagine that by the time you can tell your algorithmic assistant to order and buy stuff, a similar need arises; need a way to keep record of the order for legal purposes. For the purpose of MUD less relevant, you either have the channel and can make the purchase or it gets blocked and you don’t. But in terms of what to expect or what is “allowable behaviour” probably something to keep in mind. MarcoH
Jim Reid <jim@rfc1035.com> wrote: >> MUD files can help to identify what’s a devices purpose and monitoring >> if >> the device is doing what it’s supposed to do. I agree that we should not >> have much hope that the device makers will do their job. > Indeed. However at least MUD files should (in principle anyway) give > people an idea of what their latest IoT toy will do once it’s plugged > in. Though just saying it phones home to google/Amazon/Facebook every > so often isn’t much help if you don’t know what it's sending and > receiving. Or why it’s doing that. I disagree.... please don't over-extend what this is designed to do! MUD files will not, even in principal, tell people what the device will do! It simply say, "will phone home to XYZ on port Q" (for various ways of expressing XYZ). {If IoT devices start doing DNS-over-HTTPS (to an HTTPS server other than the local one), then MUD files won't be able to express XYZ in terms of names, and will have to use fragile IP addresses, or in the case of big providers like Google, the list will either be very long or be useless. If the manufacturer is writing the MUD files (best case!), then the people writing the MUD file will poke the people deploying DNS-over-HTTPS, and there will be a conversation. Worst case, it's not the manufacturer writing the MUD file, and the end user will have decide to either carte-blance the device (very low bandwith caps become very useful here, I think), throw the device out, or perhaps someone will discover some intermediate state. (Like if you block DNS-over-HTTPS, it fails back to DNS, and you can observe it properly.)} The most useful thing about the MUD file, assuming it's not carte-blanche, is that it won't say: "let 100,000 pps to *.root-servers.net, port 53" > BTW, Jelte spoke about the SPIN project at the WG meeting in > Marseille. It was a revelation to see how much data was being sent > outside his home network from its IoT devices. [And on a related note, > why does my DVD player call the mothership and what data are being > exchanged?] It's not a DVD player. It's a Transformer Robot hiding in your house. > Michael’s idea of an IoT firewall would mean we can see > what’s going on. This sort of thing will be essential if the concept of > informed consent means anything. One of things we are dealing with at the technical level is getting the right counters into the forwarding plane so that we can count the right things. We think we have to switch from {ip,ip6,eb}tables to nftables, and we think that once we do, that we can get all the counters we want in the places we want, and we can avoid yanking the numbers out with awk. ps: I think that any IoT manufacturer who is smart enough to adopt DNS-over-HTTPS is probably going to be smart enough to give us a reasonable MUD file. It's the ones that slapped some arduino code on an ES8266 and shipped it that we should be worried about. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
On 22 Oct 2018, at 22:29, Michael Richardson <mcr@sandelman.ca> wrote:
Indeed. However at least MUD files should (in principle anyway) give people an idea of what their latest IoT toy will do once it’s plugged in. Though just saying it phones home to google/Amazon/Facebook every so often isn’t much help if you don’t know what it's sending and receiving. Or why it’s doing that.
I disagree.... please don't over-extend what this is designed to do!
MUD files will not, even in principal, tell people what the device will do! It simply say, "will phone home to XYZ on port Q" (for various ways of expressing XYZ).
Michael, I think we are in violent agreement. MUD files are a step in the right direction. They will tell people that their IoT things are phoning home and what sorts of traffic is being generated. This is to be strongly encouraged. It would be even better if we knew what data were carried in that IoT traffic (and why). Though that’s not something which MUD offers - at least not yet.
On 22 Oct 2018, at 22:29, Michael Richardson <mcr@sandelman.ca> wrote:
BTW, Jelte spoke about the SPIN project at the WG meeting in Marseille. It was a revelation to see how much data was being sent outside his home network from its IoT devices. [And on a related note, why does my DVD player call the mothership and what data are being exchanged?]
It's not a DVD player. It's a Transformer Robot hiding in your house.
Well, it was a robot. Then it turned into a DVD player. :-) Or was it the other way round? :-) No matter. The point I was trying to make is that it’s very rare to be properly informed about the traffic IoT devices generate or why. Manufacturers generally don’t volunteer that information. From that PoV a DVD player is no different from a smart lightbulb or a transformer robot. I naively assumed my DVD player might check for new firmware from time to time. But it’s doing a lot more than that and one of these days I’ll get around to finding out exactly what it’s doing.
Hi. Please see below.
On Oct 18, 2018, at 19:00, Töma Gavrichenkov <ximaera@gmail.com> wrote:
...and now bringing my question/suggestion to the mailing list.
Previously on topic: we've agreed (haven't we?) that MUD is not currently targeting industrial IoT and connected health. So, smart homes.
We are talking to some health providers.
(By the way, it is more proper to directly specify the issue you're handling before proposing a solution. As MUD doesn't solve the security problem of IoT in general, let's then call it a solution for smart homes, but not a solution for IoT.)
It absolutely is targeting IoT.
The issue with smart homes, wearables etc. is that a contemporary commodity IoT device is not connected to the Internet in order to really provide a service to the customer.
Huh?
Instead, it collects, processes and sends data and telemetry which is precious for its vendor, which said vendor would then be able to sell.
You would not pay money for a device with such a purpose, much less let it on your network.
- https://www.theverge.com/2017/7/24/16021610/irobot-roomba-homa-map-data-sale - https://www.warc.com/newsandopinion/news/general_motors_generates_new_radio_... - et cetera.
Expecting a vendor to cut their own cables themselves is a strange move, isn't it. Hence, "default policy is no access" stuff isn't just going to fly.
The point isn’t to have the vendor “cut their own cables” but to cut their own (needless) exposure.
And, setting a firewall will only slightly help because of countless reasons.
a) We have agreed today (haven't we?) that an IoT device needs to be updated frequently, and probably via the Internet. Let's now phrase it in a different way: we have agreed that an IoT device has a right to connect to a server of its vendor and exchange encrypted data with that server. Good luck telling updates from telemetry streaming then.
b) Given a), a vendor will have an 100% legitimate excuse for denying you a service (i.e. remotely switching off a device, or more precisely, *not switching it on*) if the device doesn't have an Internet connectivity.
c) Moreover, if a data collected by roombas would be actually worth selling, we can prophesize that ToSes for devices would start to *include* that connectivity requirement. I.e. if you don't want to share data with a vendor, then you must not buy this $9 vacuum cleaner but should rather go for that $199 vacuum cleaner, because it costs $150 to produce the device and for the former, the remaining $141 are covered by selling the data you don't want to share now. I'd be thrilled to see if anyone would be really going to spend additional $190 for privacy and security.
I agree that vendors want to monetize information. Your idea that some products REQUIRE connectivity is in the rear view mirror as they say, regardless of anything to do with MUD. The only thing MUD can do is inform the network owner or his or her proxy as to what the device is and its communication needs. Eliot
d) Also, if said data is worth selling, setting up a firewall won't help because an IoT device will then use whatever radio technology built-in to connect to the Internet without your nice firewall. The only outcome would be an increased manufacturing cost because of additional radio module (and yes, it's the customer who's gonna pay for this). Sorry guys. Nothing personal, it's just business.
e) You cannot possibly set a firewall between the Internet and wearables, SmartTV, cars, etc.
...
I'm curious how does MUD address those concerns.
| Töma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera@gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58
_______________________________________________ iot-wg mailing list iot-wg@ripe.net https://lists.ripe.net/mailman/listinfo/iot-wg
Good day, On Tue, Oct 23, 2018 at 9:15 PM Eliot Lear <lear@lear.ch> wrote:
The issue with smart homes, wearables etc. is that a contemporary commodity IoT device is not connected to the Internet in order to really provide a service to the customer.
Huh?
Explained in the next sentence.
Instead, it collects, processes and sends data and telemetry which is precious for its vendor, which said vendor would then be able to sell.
You would not pay money for a device with such a purpose, much less let it on your network.
So is MUD being designed for me personally? As for the rest of the customers, a majority of them will prefer an $9 vacuum cleaner instead of an $199 one with the same characteristics, even if the former is streaming some data. They let Amazon Echo and Samsung SmartTVs to be on their network. What else do you want me to prove here? | Töma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera@gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58
participants (10)
-
e.vanuden＠avm.de -
Eliot Lear -
Jacques Latour -
Jelte Jansen -
Jim Reid -
Marco Davids -
Marco Hogewoning -
Michael Richardson -
Peter Steinhäuser -
Töma Gavrichenkov