- iot-wg - mailman.ripe.net

IRTF SMART WG
by Peter Steinhäuser 13 Nov '18

13 Nov '18

Dear Collegues, on the latest IETF meeting the SMART WG of the IRTF was created: https://www.ietf.org/mail-archive/web/smart/current/msg00003.html Researching ways to identify malicious encrypted traffic might also be interesting for projects working on detecting unusual IoT device behaviour (i.e. SPIN or the project of the IETF home networking group presented by CERA on the latest RIPE meeting). If this research project succeeds it will raise a couple of other questions about encrypted traffic - to be honest I’m not sure if I like a positive outcome in terms of privacy and data protection… Best regards, Peter

4 5

Re: [iot-wg] iot-wg Digest, Vol 21, Issue 1
by Avetik Yessayan 09 Nov '18

09 Nov '18

Dear Jim, Congratulations to pass through this important milestone. Dear colleagues, I like to put forward my candidacy on WG co-chair. I bring an extensive experience in IOT system development from the industry and would like to take efforts in coordination and liaising between the RIPE and industry. I like to focus on standards being developed by different actors, and on compilation of those developments to bring it back to the community, to facilitate the ISPs, integrators and solution providers with recommended guidlines developed by those of the Parties. My background is in Microelectronics (undergrad) and Computer Engineering (graduate degree) from University of Southern California, having 30 more years industry experience working in Silicon Valley based high-tech companies, currently based in Armenia. Looking forward to work with you all with a common goal to make IOT more trustful and reliable infrastructure in the world. Thank you very much, Avetik ________________________________________ From: iot-wg <iot-wg-bounces(a)ripe.net> on behalf of iot-wg-request(a)ripe.net <iot-wg-request(a)ripe.net> Sent: Monday, November 05, 2018 3:00 PM To: iot-wg(a)ripe.net Subject: iot-wg Digest, Vol 21, Issue 1 Send iot-wg mailing list submissions to iot-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.ripe.net/mailman/listinfo/iot-wg or, via email, send a message with subject or body 'help' to iot-wg-request(a)ripe.net You can reach the person managing the list at iot-wg-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of iot-wg digest..." Today's Topics: 1. Consensus on WG Chair Selection process (Jim Reid) 2. appointing a co-chair (Jim Reid) 3. Re: appointing a co-chair (Peter Steinh?user) 4. Re: appointing a co-chair (T?ma Gavrichenkov) ---------------------------------------------------------------------- Message: 1 Date: Mon, 5 Nov 2018 06:19:52 +0000 From: Jim Reid <jim(a)rfc1035.com> To: RIPE IoT WG <iot-wg(a)ripe.net> Subject: [iot-wg] Consensus on WG Chair Selection process Message-ID: <2083A05E-DB01-4E77-93B9-415F13054466(a)rfc1035.com> Content-Type: text/plain; charset=us-ascii It's time to declare victory. So that's what I am doing. :-) IMO we have consensus and enough support for the selection process. My thanks to everyone who contributed to the discussion. There is one small tweak to the original text. Peter Koch suggested a clarification which got rid of an ambiguity: replacing "longest-serving co-chair" with "co-chair whose term is up". That's reflected in the text below. I will ask the NCC to put this on the WG's home page and also turn it into a RIPE document. (1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the co-chair whose term is up will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final. ------------------------------ Message: 2 Date: Mon, 5 Nov 2018 06:43:02 +0000 From: Jim Reid <jim(a)rfc1035.com> To: RIPE IoT WG <iot-wg(a)ripe.net> Subject: [iot-wg] appointing a co-chair Message-ID: <10A90F2C-F56B-4FA2-8047-F444B181CCD0(a)rfc1035.com> Content-Type: text/plain; charset=us-ascii Ladies and gentlemen, boys and girls, start your engines! :-) Since the WG now has an appointment process in place, it's time to use it. Anyone interested in volunteering as a co-chair is encouraged to step forward. It would be helpful if potential candidates could post on the list what their vision is for the WG and what they would/wouldn't do if appointed. I would also urge volunteers to consult RIPE692: "RIPE Working Group Chair Job Description and Procedures" to get an appreciation for what this role entails. I'll also be happy to provide advice and guidance to anyone thinking about volunteering, either in private or on the list. The tentative schedule would be to finalise a list of potential candidates by early next year and run the selection process in March or theresabouts so the new co-chair can be in place in good time for RIPE78. Please speak up if you think this schedule is unreasonable or impractical. Although I have no say in who the WG chooses -- I just make the consensus determination -- I would very much like to see someone new in the role. It would be a pity if one of the usual suspects got the job. Not that I have any criticisms of them. A fresh face, new thinking and a break from the same old routine is both healthy and desirable IMO. However that will of course ultimately be a decision for the WG to make. Over to you... ------------------------------ Message: 3 Date: Mon, 5 Nov 2018 09:53:53 +0100 From: Peter Steinh?user <ps(a)embedd.com> To: Jim Reid <jim(a)rfc1035.com> Cc: RIPE IoT WG <iot-wg(a)ripe.net> Subject: Re: [iot-wg] appointing a co-chair Message-ID: <E101EFDF-6C63-440D-9CD6-0BF2B43A091B(a)embedd.com> Content-Type: text/plain; charset=utf-8 Dear Jim, congratulations to the victory ;), it?s an important step for the working group to move forward. Dear Collegues, proceedings defined I put my hat in the ring for working group co-chair. I'm seriously concerned about the impact malicious IoT devices will have on the internet's infrastructure. My goal in the working group is defining best practices and standards about how can be dealt with IoT devices pro-actively to keep the coming attacks under control. Coming from a home gateway/personal router/CPE background (DD-WRT / OpenWRT) such devices are for me potential gatekeepers that can play an important role. Also ISP's should be brought on board, it's in their sole interest as well. To have an effect we need to gain maximum traction in the industry. There are already activities (SPIN / IETF home gateway WG) in this field. I would work on connecting the ongoing activities to form technical standards and reference implementations for easy adoption by the industry. I would also work on advocating these to industry players (i.e. Broadband Forum) to get broader support for these activities as well. It would be my pleasure to work closer with all of you for the better of the internet. Thanks in advance, Peter > Am 05.11.2018 um 07:43 schrieb Jim Reid <jim(a)rfc1035.com>: > > Ladies and gentlemen, boys and girls, start your engines! :-) > > Since the WG now has an appointment process in place, it's time to use it. > > Anyone interested in volunteering as a co-chair is encouraged to step forward. It would be helpful if potential candidates could post on the list what their vision is for the WG and what they would/wouldn't do if appointed. I would also urge volunteers to consult RIPE692: "RIPE Working Group Chair Job Description and Procedures" to get an appreciation for what this role entails. I'll also be happy to provide advice and guidance to anyone thinking about volunteering, either in private or on the list. > > The tentative schedule would be to finalise a list of potential candidates by early next year and run the selection process in March or theresabouts so the new co-chair can be in place in good time for RIPE78. Please speak up if you think this schedule is unreasonable or impractical. > > Although I have no say in who the WG chooses -- I just make the consensus determination -- I would very much like to see someone new in the role. It would be a pity if one of the usual suspects got the job. Not that I have any criticisms of them. A fresh face, new thinking and a break from the same old routine is both healthy and desirable IMO. However that will of course ultimately be a decision for the WG to make. > > Over to you... > > > _______________________________________________ > iot-wg mailing list > iot-wg(a)ripe.net > https://lists.ripe.net/mailman/listinfo/iot-wg ------------------------------ Message: 4 Date: Mon, 5 Nov 2018 17:05:11 +0700 From: T?ma Gavrichenkov <ximaera(a)gmail.com> To: ps(a)embedd.com Cc: iot-wg(a)ripe.net Subject: Re: [iot-wg] appointing a co-chair Message-ID: <CALZ3u+Zn-g36h80ag7vY+GDeMKYt1=iEcWq6y-On86u2S+eb2g(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" I support this. | T?ma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera(a)gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 On Mon, Nov 5, 2018 at 3:54 PM Peter Steinh?user <ps(a)embedd.com> wrote: > > Dear Jim, > > congratulations to the victory ;), it?s an important step for the working group to move forward. > > Dear Collegues, > > proceedings defined I put my hat in the ring for working group co-chair. > > I'm seriously concerned about the impact malicious IoT devices will have on the internet's infrastructure. My goal in the working group is defining best practices and standards about how can be dealt with IoT devices pro-actively to keep the coming attacks under control. > > Coming from a home gateway/personal router/CPE background (DD-WRT / OpenWRT) such devices are for me potential gatekeepers that can play an important role. Also ISP's should be brought on board, it's in their sole interest as well. To have an effect we need to gain maximum traction in the industry. > > There are already activities (SPIN / IETF home gateway WG) in this field. I would work on connecting the ongoing activities to form technical standards and reference implementations for easy adoption by the industry. I would also work on advocating these to industry players (i.e. Broadband Forum) to get broader support for these activities as well. > > It would be my pleasure to work closer with all of you for the better of the internet. > > Thanks in advance, > Peter > > > Am 05.11.2018 um 07:43 schrieb Jim Reid <jim(a)rfc1035.com>: > > > > Ladies and gentlemen, boys and girls, start your engines! :-) > > > > Since the WG now has an appointment process in place, it's time to use it. > > > > Anyone interested in volunteering as a co-chair is encouraged to step forward. It would be helpful if potential candidates could post on the list what their vision is for the WG and what they would/wouldn't do if appointed. I would also urge volunteers to consult RIPE692: "RIPE Working Group Chair Job Description and Procedures" to get an appreciation for what this role entails. I'll also be happy to provide advice and guidance to anyone thinking about volunteering, either in private or on the list. > > > > The tentative schedule would be to finalise a list of potential candidates by early next year and run the selection process in March or theresabouts so the new co-chair can be in place in good time for RIPE78. Please speak up if you think this schedule is unreasonable or impractical. > > > > Although I have no say in who the WG chooses -- I just make the consensus determination -- I would very much like to see someone new in the role. It would be a pity if one of the usual suspects got the job. Not that I have any criticisms of them. A fresh face, new thinking and a break from the same old routine is both healthy and desirable IMO. However that will of course ultimately be a decision for the WG to make. > > > > Over to you... > > > > > > _______________________________________________ > > iot-wg mailing list > > iot-wg(a)ripe.net > > https://lists.ripe.net/mailman/listinfo/iot-wg > > _______________________________________________ > iot-wg mailing list > iot-wg(a)ripe.net > https://lists.ripe.net/mailman/listinfo/iot-wg ------------------------------ Subject: Digest Footer _______________________________________________ iot-wg mailing list iot-wg(a)ripe.net https://lists.ripe.net/mailman/listinfo/iot-wg ------------------------------ End of iot-wg Digest, Vol 21, Issue 1 *************************************

2 1

Draft minutes from RIPE77
by Jim Reid 09 Nov '18

09 Nov '18

Amanda Gowland has produced an excellent set of draft minutes from the WG session at the last RIPE meeting. Many thanks to her. Please speak up on the list if there are any errors or omissions. IoT WG RIPE 77 Thursday, 18 October 2018, 16:00 - 17:30 Scribe: Mirjam Kühne Agenda: 1. Administrivia Jim Reid opened the second official meeting of this group as a RIPE Working Group. 2. RIPE NCC Update (Marco Hogewoning) The presentation is available at: https://ripe77.ripe.net/archives/video/2307 Jim Reid asked how the community could help to fill the empty spaces currently in the directive. Marco said he didn't know at that point. He recommended to work with the local regulators. Pete Koch, DENIC, mentioned that there were large concerns about open source products. He wondered if there was awareness about that or special ideas for treating open source products. Marco responded that the document seemed to be fine with open source software, but manufacturers needed to stay within their limits. However, there were exemptions for amateur radio operators. Brian Nisbet, HEAnet, said that some of those pieces that were currently missing were things that should be there right now, for instance network abuse. He wondered why they were waiting for later. Marco explained that the directive was indeed very generic. It suggestd to stick within the particular regulatory framework, but it leaves details open to the regulator. Christian Bretterhofer, Andritz, suggested having discussion about why and what devices actually needed to be connected to the Internet. Marco explained that there was indeed an ongoing discussion about possibly slowing down innovation and making more conscious decisions about connecting or not connecting devices. Florian Streibelt, Max Planck, clarified that the exemptions were only for ham radio operations. 3. The Internet of Threats: Fighting FUD with MUD (Michael Richardson, Sandelman Software Works) The presentation is available at: https://ripe77.ripe.net/archives/video/2309 Artem Gavrichenkov asked who was going to implement this. Michael explained that they believed it should in the interest of the ccTLDs. It was necessary to make that investment. They would also present this at the ICANN meeting to encourage ccTLDs to implement this. Artem noticed that the presentation only covered smart homes, noting that that’s only a small fraction. He wondered why, for instance, industrial devices were not included. Michael explained that the protocols they were proposing to apply in the home were variations of some of the IETF protocols that were being developed for specifically securing industrial devices. Artem said he was afraid that smart home vendors weren't going to implement this because they would lose money. Michael explained that this was one of the reason they were building a firewall around them. Jelte Jansen, SIDN, made the audience aware of the SPIN project at SIDN and that there were quite a number of similarities to the presented solution. He suggested to possibly standardise the way MUD files were spread. Michael responded that the initial thought was to add a trust anchor and that they were going to get a curated database with changes that came from the community. Jelte suggested to think about a more general solution. Robert Kisteleki, RIPE NCC, applauded Michael and others for this exciting work. He asked what role machine learning could play, adding that this was the best remote presentation he'd seen. 4. Police Perspective on IoT, Challenges and Strategy (Jaap van Oss, Manon den Dunnen, Politie Nederland) The presentation is available at: https://ripe77.ripe.net/archives/video/2311 Jim said he hoped this was a start of an ongoing dialogue. Artem asked what data source the speakers were using for making the statement that the majority of DDoS attacks come from IoT devices. Jaap van Oss responded that this was based on his general knowledge in investigating these kinds of crimes. 5. Security Problems in IoT (Thomas Stols, Computest) The presentation is available at: https://ripe77.ripe.net/archives/video/2313 Jan Zorz, ISOC, asked if an IoT device had the 'smart' at the core, was connected to the Internet and could be controlled from the cloud. He wondered whether it was a security risk. Thomas responded that this was not necessarily the case if the cloud was properly secured. But yes, it could definitely be a risk. Brian Nisbet was shocked to hear that a hackers' organisation was shorting the stock of a company just because they have no bounty programme. Tomas said he agreed, but from a legal perspective this was a grey area. Manon asked if Thomas thought that sharing biometrical identity was the way to go. Thomas said it could possibly be used as an additional security mechanism. Manon said she was concerned about this, because it’s giving away the closest thing to our identity and sharing them on the Internet. Thomas responded that it was definitely improving security compared to passwords. Peter Steinhäuser, enbeDD, clarified that the facial recognition of Apple was actually not going to the cloud, but it stayed on the device. Neofytos Kountardas, Greek Cybercrime Unit, added that the European Commission was looking at the option to add cybersecurity certificates for devices. Thomas welcomed this initiative by governmental institutions. 6. The Internet-of-Insecure-Things: Causes, Trends and Responses (Arman Noroozian, TU Delft) The presentation is available at: https://ripe77.ripe.net/archives/video/2317 Jim thanked the speaker for this fantastic work and said he would like to see more of this kind of work. Jelte said he was surprised to see that doing nothing is better than informing your customers by email. Arman clarified that people just tended to ignore these kinds of informational emails. Purely sending abuse emails didn't seem to work. 7. AOB Jim said he would like to close the discussion on the WG chair selection process on the mailing list shortly after this meeting. He hoped to have a co-chair for RIPE 78.

1 0

Consensus on WG Chair Selection process
by Jim Reid 05 Nov '18

05 Nov '18

It's time to declare victory. So that's what I am doing. :-) IMO we have consensus and enough support for the selection process. My thanks to everyone who contributed to the discussion. There is one small tweak to the original text. Peter Koch suggested a clarification which got rid of an ambiguity: replacing "longest-serving co-chair" with "co-chair whose term is up". That's reflected in the text below. I will ask the NCC to put this on the WG's home page and also turn it into a RIPE document. (1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the co-chair whose term is up will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final.

1 0

Re: [iot-wg] "The Internet of Threats: Fighting FUD with MUD"
by Töma Gavrichenkov 24 Oct '18

24 Oct '18

...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(a)gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58

10 32

serious vulnerabilities FreeRTOS
by Jim Reid 23 Oct '18

23 Oct '18

As surely as day follows night, there’s news of another example of scary/buggy/crappy IoT firmware. A large number of security vulnerabilities have been found in FreeRTOS and other variants which presumably share the same code base. These include information leaks, DoS and remote code execution. Nice. One of those variants is SafeRTOS -- oh the irony! -- that’s "certified for use in safety critical systems". Whoops! https://blog.zimperium.com/freertos-tcpip-stack-vulnerabilities-put-wide-ra… According to the above link, "FreeRTOS and SafeRTOS have been used in a wide variety of industries: IoT, Aerospace, Medical, Automotive, and more.”. The vulnerabilities are apparently in the TCP/IP stack. How is this possible? Rock-solid public domain TCP/IP code has been around since BSD4.4 20+ years ago. Or even earlier. Why would someone shun that, write their own code and do it badly? I just don’t understand the thinking(?) behind that. Does anyone have more info on the actual devices/applications which could be vulnerable?

3 2

In response to questions on ReD (RIPE 77)
by Marco Hogewoning 20 Oct '18

20 Oct '18

Dear all, If you followed the discussions during RIPE 77, I did not have an immediate answer to the process of establishing a Delegated Act. Meanwhile a helpful person has supplied me with some more details: The document here https://ec.europa.eu/info/law/law-making-process/adopting-eu-law/implementi… contains some more information regarding the process. There is also a website that allow you to track delegated acts being prepared: https://webgate.ec.europa.eu/regdel/#/home And of course my advise remains to also consult with your national regulator on your position under this Directive and its potential extensions. Regards, Marco Hogewoning -- External Relations - RIPE NCC

2 1

GrowthEnabler's "Market Pulse Report for Internet of Things"
by Töma Gavrichenkov 18 Oct '18

18 Oct '18

Hi all, Apparently, the report I've mentioned today during the WG session is available on the Web, feel free to take a look: https://growthenabler.com/flipbook/pdf/IOT%20Report.pdf | Töma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera(a)gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58

1 0

code of conduct for IoT devices
by Jim Reid 16 Oct '18

16 Oct '18

The UK's National Cyber Security Centre and the Department for Digital, Culture, Media and Sport has just published a code of conduct on security for consumer IoT devices. It's full of the usual advice: no default passwords, update firmware, protect personal data, etc. The document's available here: https://www.gov.uk/government/publications/secure-by-design/code-of-practic… In case anyone's wondering DCMS is the government department which (amongst other things) looks after Internet matters.

3 2

another heave on the co-chair selection procedure
by Jim Reid 15 Oct '18

15 Oct '18

Colleagues, the selection process needs another nudge. Although there have been a few expressions of support and no objections, I’m reluctant to declare consensus because only a handful of people have spoken. I’d *really* like to declare victory so we can get on with the job of finding a co-chair. It’s uncomfortable to do this when the WG has argely been silent about how the leadership is selected. So could you please indicate your support or opposition to the following? Thanks. I would also ask the WG to avoid the temptation to rat-hole or over-think the selection procedure, for instance by proposing elaborate steps to apply in corner cases that in all probability will never arise. We're only appointing a WG co-chair, not the Internet's Supreme-Leader-for-Life. The WG can always change the suggested process later if practical experience proves it is broken or needs improvement. Note too that there is no mention of elections or votes. This is deliberate. (1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the longest serving co-chair will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final. Vote early, vote often. Well OK, we don’t vote but I hope you get the point. :-)

15 21