- iot-wg - mailman.ripe.net

co-chair selection is now under way
by Jim Reid 03 Apr '19

03 Apr '19

Colleagues, it’s high time the WG found another co-chair. Two candidates have come forward: Peter Steinhauser and Sandoche Balakrichenan. Thanks to both for volunteering. Please do not post statements of support for them on this thread. Use the appropriate thread(s): Sandoche: https://www.ripe.net/ripe/mail/archives/iot-wg/2019-March/000393.html Peter: https://www.ripe.net/ripe/mail/archives/iot-wg/2019-March/000395.html Vote early, vote often! :-) Well, OK we don’t vote but I’m sure you all get the general idea. I hope to make a consensus determination by April 26th - just after the Easter holiday. Over to you...

1 0

Agenda planning for Reykjavik
by Jim Reid 02 Apr '19

02 Apr '19

Colleages, RIPE78 is just over 6 weeks away. Yikes! Please send your suggestions for WG agenda items to iot-wg-chairs(a)ripe.net

1 0

CIRA Labs - Secure Home Gateway (SHG) Project Update
by Jacques Latour 27 Mar '19

27 Mar '19

Hi All, Someone told me I'm not communicative enough ;-) Just wanted to give a quick update on the Secure 'IoT' Home Gateway initiative, we made good progress over the course of the last year, you can find project information here. https://github.com/CIRALabs/Secure-IoT-Home-Gateway · https://www.circleid.com/posts/20190305_an_update_from_cira_on_iot_security/ We're starting the 3rd phase of the project April 1st, looking at having fully running code, API definition and internet drafts for the gateway provisioning process, MUD controller and supervisor, IoT onboarding, SIDN SPIN integration, SHG APP and more. All this on top of the Turris Omnia platform. Still have along way to go. We can use some help. For those interested, the Government of Canada and ISOC started a multi-stakeholder process focused on IoT security and made recommendations on network resiliency, on labelling and on consumer education and awareness. There's good stuff we generated: https://iotsecurity2018.ca/ Added a picture to attract your attention :) [cid:image003.png@01D4E496.B21E1410] That's my report :) Someone from the team may be available to present at RIPE 78 Reykjavík in 54 Days 03 Hours 46 Minutes 49 Seconds. Jacques Jacques Latour - CTO & CSO Canadian Internet Registration Authority (CIRA) Tel: (613) 237-5335 [ext.294] | www.cira.ca<https://cira.us17.list-manage.com/track/click?u=02a9cbf99c1f9e5635e527e59&i…> [https://gallery.mailchimp.com/02a9cbf99c1f9e5635e527e59/images/0da6ac5e-6e5…]

1 0

Candidature for Co-Chair
by sandoche Balakrichenan 27 Mar '19

27 Mar '19

Dear all, I would like to put my application for the co-chair role. I believe I could fit into Jim's criteria, not being among the usual suspects :-) _*About my *_ I have been working at the French domain registry (Afnic) for the last 10 years. Since the beginning, I have been carrying out multiple IoT-related initiatives and projects internally and/or with partners. My linked in profile: https://www.linkedin.com/in/sandoche-balakrichenan-2a44645/ 50% of my job profile is oriented towards technology watch, and thus involved in activities at the IETF, GS1 (RFID, Barcode standardization), AIOTI (The Alliance for the Internet of Things Innovation), RIPE, CENTR (Council for European Top Level Domains) and LoRa-Alliance. My interest in IoT includes identification, name resolution, service discovery and using DNS infrastructure as PKI for the _*Some milestones in my IoT profile:*_ * I had participated for two years at the European Commission as an invited member of the IoT expert group. * Our IoT project WINGS (how DNS could be used for service discovery in the supply chain industry?) was awarded the CENTR R&D award for 2013 (https://www.inria.fr/en/centre/lille/news/anr-verso-wings-project-wins-cent…) * Principal contributor to the ONS standard (https://www.gs1.org/sites/default/files/docs/epc/ons_2_0_1-standard-2013013…) * Contributed to LoRa-alliance (lora-alliance.org) Backend interfaces specification on DNS usage for resolving LoRa devices in the Internet. _*What I could do in the Co-chair role?*_ * Will be able to participate in all RIPE physical sessions and other side meetings which a WG co-chair is supposed to attend. * Wil be able to allocate time to follow the policy proposal relevant to the WG; follow and respond to the mailing list discussion; ensure milestones and with the help of Jim, liaise with RIPE NCC. * Will be able to allocate time for administrative activities (like soliciting contents, preparing the agenda etc.) concerning the WG If you believe i can be of use, thanks for your support. Regards, Sandoche BALAKRICHENAN

3 2

appointing another co-chair
by Jim Reid 26 Feb '19

26 Feb '19

Here's what I posted back in November: 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. I would also ask candidates to start a *new thread* -- eg "Your name for co-chair" or something like that -- when they post on the list so there are meaningful and relevant Subject: headers which make it easier to make a consensus judgement. This will also make it clearer for other members of the list to express their support for a candidate.

1 0

re-rebooting the co-chair appointment process
by Jim Reid 26 Feb '19

26 Feb '19

Colleagues, we're still missing a co-chair. The last attempt to find one didn't work out. Although a couple of names were mentioned, there were very few voices of support for any of them - certainly not enough to make a sound consensus decision. It's time for one more heave. I suggest a call for nominations/volunteers/stuckees which ends on April 5th. That gives us 6 weeks for potential co-chairs to be identified and hopefully someone to emerge as the new co-chair. If the results by then are still inconclusive, I'll talk to Hans-Petter about how best to invoke article 5 of our appointment process. Let's hope it doesn't come to that. Please limit your comments on this thread to the proposed time-line and how to solve the problem of lack of WG consensus if this happens this time. I'll post another article for would be co-chairs.

1 0

Proposed Updates to EU RED Directive to increase IoT security
by Marco Hogewoning 14 Feb '19

14 Feb '19

Dear Colleagues, As I mentioned in my presentation to the Working Group during RIPE 77, the European Commission is thinking about updating the Radio Equipment Directive with the aim of improving IoT security. As a quick refresher, the RED applies to all equipment that has a radio on board. The legislation has a few broadly-defined terms regarding security and safety, which can be filled in on a later date. Last year, a number of member states floated the idea of using this option to increase security for a number of IoT devices, mostly toys and 'smart wearables’, for e.g. smart watches and step-counters. The European Commission has now opened a four week ‘feedback’ period on what is called an ‘Inception Impact Assessment’. This means the process is at an early stage and not very specific, and they are seeking feedback from stakeholders on their thoughts so far. As expected, the proposal currently does indeed target toys and wearables. Of course, this could change or be expanded later. Here are the key questions in the Inception document: - The overall objective of this initiative is to ensure an adequate level of security for internet-connected radio equipment and wearable radio equipment at the moment of placing on the market. - The following policy options and their effects for potentially affected parties (e.g. manufacturers, consumers, National Authorities) will be analysed: - Option 0, baseline scenario: a situation in which manufacturers are not obliged to implement any specific measures as it is currently the case. - Option 1, a situation whereby the industry self-regulates to implement the existing legislation which protects personal data, the confidentiality of telecommunications, security and protection against fraud. - Option 2, adoption of a delegated act pursuant Article 3(3)(e). This will require that radio equipment incorporate safeguards to ensure that the personal data and privacy of the user and of the subscriber are protected, also as a tool to enhance the cybersecurity of these products, and this requirement will have to be demonstrated for the purposes of market access. - Option 3, adoption of a delegated act pursuant Article 3(3)(f). This will require that radio equipment incorporates certain features ensuring protection from fraud, also as a tool to enhance the cybersecurity of these products, and this requirement will have to be demonstrated for the purposes of market access. - Option 4, adoption of a delegated act pursuant both Articles 3(3)(e) and (f). In this case, both requirements in Options 2 and 3 will have to be demonstrated for the purposes of market access. More information about the process and the Inception Impact Assessment is available from https://ec.europa.eu/info/law/better-regulation/initiatives/ares-2018-64269… The deadline to submit feedback is Monday, 4 March 2019. This is the very early stage of the development. If a more formal proposal is drafted based on one of these policy options, there will be another 12-week consultation period. At the same time, please be aware that this process could result in a so-called ‘Delegated Act’, which does not require the formal approval of the European Parliament or Council and can come into effect very quickly. Regards, Marco Hogewoning Senior External Relations Officer RIPE NCC ------------------ Summary ------------------ RED security Inception Impact Assessment Feedback period: 4 weeks ending on 4 March 2019 Possibly followed by a 12 week consultation period

3 3

algorithm agility for IoT
by Jim Reid 24 Jan '19

24 Jan '19

I’m working on a document at ITU Study Group 20 on algorithm agility. [So you don’t have to! :-)] The aim is to produce a Recommendation which essentially says “don’t hard-wire crypto algorithms into IoT stuff because what’s secure today could be insecure tomorrow”. For instance, building or deploying an IoT solution that can’t use anything but MD5 or DES (say) would be bad. Similarly, it would be undesirable to install a sensor network today that can’t handle tomorrow's devices because they might well use new crypto which isn’t around today. At the moment, the document cites the mechanisms used in TLS and DNSSEC as frameworks that those deploying and designing IoT infrastructure should consider. ie Continuously updated registries which add new algorithms when these become available and drop old ones which are considered unsafe or whatever. Please note that the document isn’t going to say everyone *must* use TLS and/or DNSSEC since that clearly depends on specific (unique?) use cases and requirements. Instead the document will say that people should take account of those sorts of frameworks when they are designing, procuring or operating IoT infrastructure. SG20 has said the document needs more examples of these kinds of frameworks. So I’m asking the list if they can suggest some. I’d particularly like to about potential examples from those developing IoT firmware or operating systems. Or authentication schemes for IoT. What sort of mechanisms and frameworks are available? What’s done in RIOT or the stripped down BSD/Linux stuff that underpins some IoT platforms? Anything else? The obvious example that springs to mind are dynamic SSL libraries - for instance the package managers that supply the latest version(s) of OpenSSL. Or the replacements for that which sprung up after the Heartbleed incident. However that’s a bit fuzzy. I suppose CAB Forum advice on X.509 certificates might be another. But there must be more. Any suggestions or pointers?

5 5

Re: [iot-wg] algorithm agility for IoT
by Jim Reid 21 Jan '19

21 Jan '19

> On 21 Jan 2019, at 12:36, Andrei Kolesnikov <andrei(a)rol.ru> wrote: > > Consider this problem of "hard wired crypto" only for specific class of IoT devices: power hungry, long-live, manageable, internet connected. The similarity must be with any user premises equipment, such as wifi routers, cameras, etc. I’m not sure that’s true Andrei. If an IoT device is on the Internet, it shouldn’t have hard-wired crypto. Just like how it shouldn’t have a factory-set password of 0000 or whatever. This should not be a subject for debate. It’s basic common sense.* Whether that device is a node in a sensor network or some piece of CPE is irrelevant from that perspective. Of course there are lots of trade-offs to be made when selecting crypto solutions for IoT: device lifetime, power, key lengths & rotation capabilities, memory & CPU capacity, bandwidth, costs, etc, prevailing policy & legislation, etc. But that’s an entirely different discussion which is orthogonal to the matter at hand. * It’s such basic common sense it isn’t written down anywhere. As least I’ve not been able to find it in a standards document yet. Which means that common sense can’t get baked into equipment procurements, RFPs and so on. So if there’s an RFC or ITU Recommendation or whatever along those lines...

3 4

Fwd: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues
by Töma Gavrichenkov 11 Jan '19

11 Jan '19

Hello WG, Here's a today's announcement from the NANOG mailing list. Some of the RIPE IoT working group members may want to take a look. -- Töma ---------- Forwarded message --------- From: Rich Kulawiec <rsk(a)gsp.org> Date: 10 Jan. 2019 г., 19:23 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues To: <nanog(a)nanog.org> The "dumpsterfire" mailing list is for the discussion of security and privacy issues related to the IoT (Internet of Things). Arguably, the entire IoT *is* a security and privacy issue, but we'll get to that in good time. If you want to join, you can either use the list's web page: http://www.firemountain.net/mailman/listinfo/dumpsterfire or the list's subscription/unsubscription address: dumpsterfire-request(a)firemountain.net The list is public and so is its archive. ---rsk

1 0

Re: [iot-wg] Trendmicro's "The Fragility of Industrial IoT’s Data Backbone"
by Jayden Rowley 17 Dec '18

17 Dec '18

Thanks for all the help and explanation regarding - https://1921681254.xyz/ Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

Trendmicro's "The Fragility of Industrial IoT’s Data Backbone"
by Töma Gavrichenkov 06 Dec '18

06 Dec '18

Hello dear WG, Did anyone miss IoT DDoS attacks? They are back. And, this time it's not those nice Smart Home appliances everybody's so keen to talk about. It's industrial IoT nowadays. "...with this simple picture in mind, an attacker already knows which product is worth targeting in terms of exposed hosts. For example, by inspecting Kepware messages, an attacker can learn that this product is popular for the management of solar panel plants". https://documents.trendmicro.com/assets/white_papers/wp-the-fragility-of-in… | 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

2 2

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

New on RIPE Labs: RIOT in Amsterdam
by Mirjam Kuehne 15 Oct '18

15 Oct '18

Dear colleagues, Please find on RIPE Labs a summary of the RIOT Summit that took place in Amsterdam last month. The RIOT Summit is the yearly get-together of the community around the RIOT operating system for the Internet of Things (IoT). https://labs.ripe.net/Members/martine_sophie_lenders/riot-in-amsterdam Kind regards, Mirjam Kühne RIPE NCC

1 0

Re: [iot-wg] RIPE document on IoT security solutions
by Apostolos Malatras 11 Oct '18

11 Oct '18

Hi all, Just my two cents that might help/contribute in this effort. In November 2017, ENISA published -with the help of an amazing group of experts- the Baseline IoT Security Recommendations, which among else provides numerous links to related ongoing initiatives: https://www.enisa.europa.eu/publications/baseline-security-recommendations-… These have also been mapped in the online tool available here: https://www.enisa.europa.eu/iot-tool We will be soon publishing more info on the topic so please do feel free to reach out to us. Best, -Apostolos ------------------------------------------------------------------------------------------------------ Dr Apostolos Malatras Network and Information Security Expert European Union Agency for Network & Information Security Address: 1 Vass Sofias Str, Marousi 151 24, Attica, Greece E- mail: Apostolos.Malatras(a)enisa.europa.eu Office: +30 2814 409 630 Mobile: +30 6985 051 401 -----Original Message----- From: iot-wg <iot-wg-bounces(a)ripe.net> On Behalf Of iot-wg-request(a)ripe.net Sent: Thursday, October 11, 2018 1:00 PM To: iot-wg(a)ripe.net Subject: iot-wg Digest, Vol 20, Issue 6 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. Re: RIPE document on IoT security solutions (Peter Steinh?user) 2. Re: RIPE document on IoT security solutions (Nigel Titley) 3. Re: RIPE document on IoT security solutions (Peter Steinh?user) 4. Re: another heave on the co-chair selection procedure (Farzad Ebrahimi) ---------------------------------------------------------------------- Message: 1 Date: Wed, 10 Oct 2018 14:40:36 +0200 From: Peter Steinh?user <ps(a)embedd.com> To: Jim Reid <jim(a)rfc1035.com> Cc: RIPE IoT WG List <iot-wg(a)ripe.net> Subject: Re: [iot-wg] RIPE document on IoT security solutions Message-ID: <6A2D21F6-53DC-48D6-9C15-76AA861DC7CE(a)embedd.com> Content-Type: text/plain; charset="utf-8" > There?s not much to learn Peter. RIPE doesn?t develop standards. In the sense that IEEE or IETF develops standards. RIPE sometimes develops policies, usually on the allocation of numbering resources. These policies are produced though the process defined in RIPE document 710: https://www.ripe.net/publications/docs/ripe-710. > > Anything can become a RIPE document, not just policies. The process is simple. Someone just says to the NCC ?please publish this as a RIPE document?. And it is done. > > For this case, I think we want something that reflects a consensus view of the WG. If you can produce an initial draft or outline and post it to the list, we can discuss that, make changes and go through a few iterations of the document. Hopefully we then end up with something that has broad acceptance from the WG. At that point, someone takes the finished article to the NCC and asks for it to become a RIPE document. > > Over to you... Got it - will prepare an initial draft. - 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

1 0

Bad actors
by Wolfgang Tremmel 10 Oct '18

10 Oct '18

Hi, Interesting read about bad actors of IoT vendors (well, one vendor): https://krebsonsecurity.com/2018/10/naming-shaming-web-polluters-xiongmai/ best regards Wolfgang -- Wolfgang Tremmel Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 | wolfgang.tremmel(a)de-cix.net Geschaeftsfuehrer Harald A. Summa | Registergericht AG Köln HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net

7 15