- iot-wg - mailman.ripe.net

IGF 2023 - Dynamic Coalitions IoT Session update
by maarten＠gnksconsult.com 07 Aug '23

07 Aug '23

Dear colleagues, � Following our interaction in Rotterdam in which I presented the thinking on progressing a common understanding of global good practice, I herewith provide you with an update on the work done in the context of the Internet Governance Forum. � If you want to contribute, please join us at one of the upcoming events, join the mailing list (https://mail.intgovforum.org/mailman/listinfo/dc_IoT_intgovforum.org) or write to me directly. I really appreciated the interaction in Rotterdam and stand ready to continue to contribute to the work of this working group. � Best � Maarten � � � From: maarten(a)gnksconsult.com <maarten(a)gnksconsult.com> Sent: Friday, August 4, 2023 2:39 PM To: 'dc_iot(a)intgovforum.org' <dc_iot(a)intgovforum.org> Subject: IGF 2023 - Acceptance of the Dynamic Coalitions IoT Session Submission � Dear all � Please note our session is *accepted* for the IGF 2023 in Kyoto. �Registration for the IGF is now open at https://indico.un.org/event/1006568/. We do not know yet at what exact date/time our session will take place. You can find our current session description here. <https://intgovforum.org/en/content/igf-2023-dc-iot-progressing-global-good-…> � * Coming up is our session at APrIGF in Brisbane, Australia, which is currently scheduled for 30 August, 10:00 local Brisbane time. If you are able to participate, please register at https://aprigf.eventsair.com/asia-pacific-regional-internet-governance-foru…. You can find the session at https://www.aprigf.au/program. * In addition, our session proposal for Africa IGF is also *accepted* (19-21 September, Abuja, Nigeria). If you want to participate, please register at https://igf.africa/registration/. We do not know at what exact date/time the session will take place. * You can review the recording of the session during EuroDIG (Tampere, Finland) that took place on 19 June 2023. See here <https://eurodigwiki.org/wiki/Progressing_Core_Internet_Values_and_Global_Go…> . � Input is welcome at any point in time! Suggestions, questions, contributions … aim is to get together to a common global, multistakeholder understanding of how good practice with IoT looks like, taking into the need for and usefulness of IoT applications and services to address societal challenges, core internet values, privacy and data protection in IoT environments, the impact of Artificial Intelligence on IoT governance, and the need to do all this in a secure, transparent way with clear accountability for all that are part of the value chain. You can find the current version of DC-IoT’s Global Good Practice document on the DC IoT Homepage <https://medienstadt-leipzig.org/dciot/> at this link <https://medienstadt-leipzig.org/dciot/wp-content/uploads/sites/3/2023/03/IG…> . � Hoping to see you at one or multiple events, looking forward to your input! Kind regards � Maarten � Maarten Botterman Chair, IGF DC IoT � � � From: Celine Bal <celine.bal(a)un.org> Sent: Friday, July 28, 2023 4:40 PM To: maarten.botterman(a)board.icann.org Subject: IGF 2023 - Acceptance of the Dynamic Coalitions Session Submission � ACCEPTANCE LETTER Thank you for submitting the Dynamic Coalitions Session proposal #9 Progressing Global Good Practice for the Internet of Things, to be considered for the 18th Annual IGF Meeting, hosted by the Government of Japan from 8 to 12 October 2023. Following the review of all session proposals, we are pleased to inform you that your proposal was accepted for the IGF 2023 meeting. We would kindly ask you to confirm by Wednesday, 2 August whether you still intend to hold this DC Session at the IGF 2023. Please note that by next week selected DC Session submissions will be reopened for editing so that organizers can add or modify details for publication in the schedule. A draft schedule will also be shared with organizers in due course. The IGF considers gender balance very important. While you finalize the line-up of speakers for your session, we encourage you to be mindful of equitable and varied gender representation. Meanwhile, we invite you to subscribe <https://www.intgovforum.org/multilingual/content/igf-communications-subscri…> to the IGF info mailing list, through which a regular newsletter with all relevant information is communicated. For further information, please do not hesitate to contact us by email at celine.bal(a)un.org <mailto:celine.bal@un.org> or igf(a)un.org <mailto:igf@un.org> . � We thank you for your continued engagement in the IGF process and we look forward to working together toward a successful 18th IGF. Best regards, IGF Secretariat Internet Governance Forum Secretariat United Nations Office at Geneva | Switzerland Email: igf(a)un.org <mailto:igf@un.org> www.intgovforum.org <http://www.intgovforum.org/>

1 0

Events of interest : IoT / Security
by Vesna Manojlovic 07 Aug '23

07 Aug '23

Dear colleagues, as part of cross-community connections, I am sharing these upcoming events with you: as an invitation to attend, and to promote/represent RIPE Community if you go there -- and to invite those participants back to RIPE community! Regards, Vesna === Chaos Communication Camp 15.-19.08.2023, Ziegeleipark Mildenberg, Zehdenick, Germany https://events.ccc.de/camp/2023/infos/ === BalCCon2k23 - Balkan Computer Congress 08-10 September in Novi Sad, Serbia https://2k23.balccon.org/ === The Things Conference 21-22 September 2023, Amsterdam https://www.thethingsconference.com "event about LoRaWAN® and Low Power Internet of Things. Join 1500+ top IoT professionals, 70+ leading industry players, learn from 90+ curated keynotes and 20+ workshops, learn about the latest developments in the LPWAN market and become a LoRaWAN expert. " === The 9th IEEE World Forum on Internet of Things 12-27 OCTOBER 2023, Aveiro, Portugal THE BLUE PLANET: A MARRIAGE OF SEA AND SPACE https://www.ngi.eu/event/the-9th-ieee-world-forum-on-the-internet-of-things… === For more events, follow: - https://www.ripe.net/participate/meetings/calendar) - https://nsrc.net/calendar - https://pch.net/calendar - https://foss.events/ -- Senior Community Builder, RIPE NCC https://labs.ripe.net/author/becha/

2 1

Summary on our last Session at RIPE 86 in Rotterdam
by peter.wehrle＠t-online.de 01 Jun '23

01 Jun '23

Hello, as you see in the steno <https://ripe86.ripe.net/archives/steno/43/> we had a quite intensive discussion on the focus of the IoT workgroup at RIPE 86 <https://ripe86.ripe.net/programme/meeting-plan/iot-wg/> to stay broad but also be specific in applications of IoT. As the new co-chair along with Peter Steinhäuser I first like to send a big thank you to all participants of the IoT working group at RIPE-86 joining personally in Rotterdam or online. The IoT Working Group Meeting at RIPE 86 in Rotterdam on 24th May was the last meeting for Sandoche Balkrichenan as chair of the IoT Group. Sandoche relocated back to India and did not apply to renew the term as chair. We are grateful for all the good work and support Sandoche gave as chair to IoT Working Group. As Peter Steinhäusers current term as chair is ongoing until RIPE 88, a new candidate for the Co-Chair was required. I, Peter Wehrle saw the opportunity to support the great idea of working groups and to give something back to the very open culture of the RIPE community. Im 56 years old and have a degree in communication engineering topped up by an MBA. I live and work in Germany, Frankfurt area and works as department leader for a smaller Telecommunication- and Cloud-provider, running the Business Support Applications from CRM to billing, Processes digitization, Project management, Data Security and ISO certifications for data centre operations. IOT kicks in with my hobby as radio amateur and the passion, to melt together old ham amateurs and the current maker scene with all kinds of projects, where IoT is the core for applications around all kind of solutions to optimize energy and resource consumption, meter environmental conditions like weather or humidity on fields to achieve data driven insights. I found a great appreciation from the IoT Working group on this view towards applications of IoT especially in some personal talks after the session. In turn Im looking forward being better connected to all the professionals in the IoT Working group, who does work in this field and can provide expertise and insights on the latest technology and solutions around IoT. The intention is to foster the discussion between the technical possibilities and the application of IoT - driving the groups take on necessary guidelines for i.e. IoT device security, addressing of devices etc. and to sharpen the mission of the RIPE IoT Working group in connection to other RIPE working groups like IPv6, Open source and so on. Feel free to share any thoughts on it to intensify the activity of the IoT Working group also between RIPE meetings. We are looking forward to this enhanced exchange. Peter & Peter

1 0

[Peter Wehrle] for co-chair
by peter.wehrle＠t-online.de 23 May '23

23 May '23

Hi, I promised Peter Steinhäuser, that if there is no volunteer yet Im brave enough to step up and apply for the co-chair for this IOT Workgroup. Im a complete newcomer this RIPE is my first RIPE and I joined this work group mailing list this afternoon. Im 56 years old and have degree in communication engineering driving my passion for electronics and radio communication. On top I did an MBA which helped to settle with English apart from my mother language German. I live and work in Germany, Frankfurt area and while Im more IT Application driven in my professional live (I work as a department leader for a small Telecommunication provider running the Business Support Applications from CRM to billing, Processes, Project management, Data Security and ISO certifications), the IOT kicks in with my hobby amateur radio and the passion, to melt together old ham amateurs and the current maker scene. We do run in our area a network on Lora just switched to chirp stack various projects going on which are about to combine (partly self-developed) very low energy consuming sensors and radio links to build up various data driven smart solutions. Im the president of an amateur radio club, running a yearly exhibition where we more and more go into the mission of IOT sensors and radio interfaces as a base of many clever solutions. Hence, I do not have a professional background on IOT (yet), however Im connected to various groups who just drive initiatives on measuring humidity on fields to optimise the water consumption for growing plants, monitor bees health, urban weather project and so on. So, if you dont mind getting somebody on board being passioned about the subject IOT, settled with the electronics, the radio link and being nosy about all the project you can do with it but not being linked into a professional provider Im happy to jump in. If you dont find, that is a good solution, please be honest and speak up. Its an idea and I find IOT too important to just let it down without any volunteer. Maybe that encourages others to apply as well? We will see us tomorrow in the workgroup session. Best Regards Peter Wehrle (contact data and a picture is in the participant list)

2 1

[Reminder] Call for volunteers or nominations for RIPE IoT Working Group co-chair
by Peter Steinhäuser 15 May '23

15 May '23

Dear Colleagues, As Sandoche's term as IoT WG co-chair is about to end with RIPE 86, this is a call for nominations or volunteers to co-chair the RIPE IoT working group. *********************************************************************** Please DO NOT reply to this message if you wish to propose a volunteer. *********************************************************************** I would ask for each candidate to start a new thread with, e.g., "[name] for co-chair", and for members to utter their support by replying to the respective thread. Provided there are no reasoned objections from the WG, I'd like to set May 22nd as a deadline for showing support on the mailing list, so that we can announce the decision on 24th May during the IoT WG sesssion at RIPE 86. More information about WG co-chair responsibilities (https://www.ripe.net/publications/docs/ripe-692) If you'd like further information, don't hesitate to contact Sandoche or me. Thanks for your support, Peter — Peter Steinhaeuser RIPE IoT WG Co-Chair

1 0

RIPE-86 IoT Working Group call for Presentations
by Peter Steinhäuser 07 Apr '23

07 Apr '23

Dear Colleagues, RIPE-86 is being held in Rotterdam, and the IoT working group will have a slot there as well. This e-mail is our official call for topics at the RIPE IoT working group session at the upcoming meeting. Our working group session is currently scheduled for Wednesday, May 24th 2023) at 10:30 CEST (08:30 UTC). Please send your presentation proposals and discussion topics to iot-wg-chairs(a)ripe.net. Please also indicate how much time you would need for your presentation. As usual, both in-person and remote participation in the working group is possible. Thank you, Peter — Peter Steinhaeuser RIPE IoT WG Co-Chair

2 1

Call for volunteers or nominations for RIPE IoT Working Group co-chair
by Peter Steinhäuser 03 Apr '23

03 Apr '23

Dear Colleagues As Sandoche's term as IoT WG co-chair is about to end with RIPE 86, this is a call for nominations or volunteers to co-chair the RIPE IoT working group. *********************************************************************** Please DO NOT reply to this message if you wish to propose a volunteer. *********************************************************************** I would ask for each candidate to start a new thread with, e.g., "[name] for co-chair", and for members to utter their support by replying to the respective thread. Provided there are no reasoned objections from the WG, I'd like to set May 22nd as a deadline for showing support on the mailing list, so that we can announce the decision on 24th May during the IoT WG sesssion at RIPE 86. More information about WG co-chair responsibilities (https://www.ripe.net/publications/docs/ripe-692) If you'd like further information, don't hesitate to contact Sandoche or me. Thanks for your support, Peter — Peter Steinhaeuser RIPE IoT WG Co-Chair

2 1

[BCOP] Adressing Thread & Matter for IoT
by Peter Steinhäuser 03 Apr '23

03 Apr '23

Dear collegues, since the IoT WG released it's first BCOP document [1] some time has passed. Several technologies discussed in the document – i.e. DPP, USP – have become mandatory for large carriers and can be found the majority of their roadmaps. The considerations regarding secure onboarding can also be found in works of other researchers and became common ground – I think this document was a good and useful first step, but technologies are evolving and new options and requirements surface. Recent talks with carriers revealed that all intend to increase their efforts in managing IoT devices in their customer's homes or start such efforts. All of them refer to Thread [2] and Matter [3] as the technologies of choice – which makes sense given that at these standards increase compatibility and are backed up by large players like Google, Amazon & Apple. Since Thread is based upon IPv6 it offers new options and possibilities to integrate with existing network infrastructure an standards. Nevetheless it also requires re-evaluation of threats and attack vectors in such networks. I would like to initiate work on a follow-up BCOP document that centers around the changes Thread and Matter do introduce to networks, but that also takes into account our findings that got incorporated into the fist BCOP document this WG has released. Especially the challenges regarding onboarding and security in general remain the same and would be needed to be evaluated in regards to the new technologies. An IPv6 based IoT networking protocol offers also new possibilities for integrating IoT devices into networks and can change the way we look at such networks. This should also be part of such a document. I would like to ask the members of this WG about their opinion about these considerations. And I also want to ask for volunteers to work an such a new BCOP document and would be glad to initiate and manage the process. Sincerely, Peter [1] https://www.ripe.net/publications/docs/ripe-759 [2] https://openthread.io/guides/thread-primer [3] https://csa-iot.org/all-solutions/matter/ Peter Steinhäuser, CEO embeDD GmbH · Alter Postplatz 2 · 6370 Stans · Switzerland Phone: +41 (41) 784 95 85 · Fax: +41 (41) 784 95 64

2 2

work on revised IoT BCOP
by Michael Richardson 24 Mar '23

24 Mar '23

In a thread that I lost, Peter asked: > since the IoT WG released it's first BCOP document [1] some time has > passed. Several technologies discussed in the document – i.e. DPP, USP – > have become mandatory for large carriers and can be found the majority of > their roadmaps. That's really news to me. I guess maybe this is about USP more than it is about DPP. I'm unware that DPP has become mandatory. As for the USP (TR-369), I'd like to know more: it's quite a fungible spec, and what part exactly has become mandatory, and what transports? In our BCOP, we said we needed a standard phone/browser <-> home gateway API such that we could have innovation at the edge. (Right now, it's a market vertical with a new app for every home gateway) So I'd love to have some discussion, maybe there are even presentations, about where we are here. > Recent talks with carriers revealed that all intend to increase their > efforts in managing IoT devices in their customer's homes or start such > efforts. All of them refer to Thread [2] and Matter [3] as the technologies > of choice – which makes sense given that at these standards increase > compatibility and are backed up by large players like Google, Amazon & > Apple. Since Thread is based upon IPv6 it offers new options and > possibilities to integrate with existing network infrastructure an > standards. Nevetheless it also requires re-evaluation of threats and attack > vectors in such networks. yes, but I think that the carriers are gonna find that they have some serious privacy implications if they get involved. I think that it is gonna bite Google and Apple and Amazon too. > I would like to initiate work on a follow-up BCOP document that centers > around the changes Thread and Matter do introduce to networks, but that > also takes into account our findings that got incorporated into the fist > BCOP document this WG has released. Especially the challenges regarding > onboarding and security in general remain the same and would be needed to > be evaluated in regards to the new technologies. One thing that might be useful is to have a Thread and Matter (they are different and also dependant) reference networks that we could play with in person at a future RIPE meeting. Probably too soon for Rotterdam, but maybe in the fall. (Wherever that will be) > An IPv6 based IoT networking protocol offers also new possibilities for > integrating IoT devices into networks and can change the way we look at > such networks. This should also be part of such a document. > I would like to ask the members of this WG about their opinion about these > considerations. And I also want to ask for volunteers to work an such a new > BCOP document and would be glad to initiate and manage the process. In general, I think that it's too soon to say anything useful in a new document in 2023, but that we should be spending some time understanding what's going on. -- Michael Richardson <mcr+IETF(a)sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide

2 1

RIPE 85 minutes
by sandoche Balakrichenan 29 Nov '22

29 Nov '22

Hello all, Please find the minutes from our last meeting @Belgrade: https://www.ripe.net/participate/ripe/wg/active-wg/iot/minutes/iot-working-… Thanks to alun Davis (RIPE NCC) for preparing the minutes. If there are any errors or omissions, please let us know on the list. Sandoche on behalf of the IoT WG chairs

1 0

Reviews of draft-richardson-t2trg-idevid-considerations (part 1)
by Michael Richardson 02 Nov '22

02 Nov '22

I wanted to appologize to Sini Ruohomaa for letting eir review languish so long in my inbox. I'll also note that I've presented about this document a few times in the past month under the title: 'Social and Technical metrics for Trust Anchor resilence' 1) IoT Security Foundation meeting, https://iotsfconference.com/agenda/. Oct.5 Youtube coming. 2) TPM.DEV, Oct. 13, https://www.linkedin.com/events/tpmdev2022conference6977630882559864832/com… video links coming. 3) RIPE-85 IoT WG. https://ripe85.ripe.net/archives/video/950/ Slides at: https://www.sandelman.ca/SSW/talk/2022-iotsf-anchor-reputations/index.shtml It's also been presented with different slides a few other times during pandemic. One advantage of doing this in person is that I get to see nonverbal nods of agreement, or looks of confusion from the audience, and I think that the concepts have been generally very well received. But, I'm sure that the actual definitions could use some work, and perhaps that will happen when the RG adopts the document. I've also had about ten private discussions with trust anchor creators/technology creators such as CPU and TEE manufacturers. Getting them on the record has been.... challenging. Taking the document out to industry was the homework I was assigned by SECDISPATCH back in 2022. Sini wrote: > I would like to pass my warm greetings to the authors for the > effort of trying to make this more communicable. I would like > to reference this document when it is ready. It is written in a very > approachable way so I see value in it also as an educational document, > not just an evaluation framework. Thank you for the encouraging words. > "An increasing number of protocols derive a significant part of their > security by using trust anchors [RFC4949] that are installed by > manufacturers. Disclosure of the list of trust anchors does not usually > cause a problem, but changing them in any way does. This includes > adding, replacing or deleting anchors. [RFC6024] deals with how trust > anchor stores are managed, while this document deals with how the > associated PKI which is anchor is managed." > The last sentence is a bit hard to parse. Changed to: + The document {{RFC6024}} deals with how trust anchor stores are managed in the device which uses them. + This document deals with how the PKI associated with such a trust anchor is managed. I wonder if that's actually any better. > "Device identity keys are used when performing enrollment requests (in > [RFC8995], and in some uses of [I-D.ietf-emu-eap-noob]. The device > identity certificate is also used to sign Evidence by an Attesting > Environment (see [I-D.ietf-rats-architecture])." > One closing parenthese ")" is missing. fixed. > 3.6 "what else" question > The identities trust anchor for validating identities of non-web-PKI > devices in case they need to ever talk to each other, or the identity > trust anchor of a vendor specific service that the device must connect > to in order to do e.g. enrolment of other identities, setting up > attestation or zero-touch bootstrapping come to mind (this allows the > device too to know who it is talking to, in addition to having the > device authenticate towards such an enrolment service). > I would cover these with a 'other identity validation trust anchors' in > addition to the public web PKI trust anchors, as the category is > probably too wide to cover satisfactorily an individual subcategory at > a time. I have added sections: Private/Cloud PKI anchors Onboarding/Enrollment anchors Onboarded Network-Local anchors > 4.1: minor > "[ieee802-1AR] defines a category of certificates that are installed by > the manufacturer, which contain at the least, a device unique serial > number." > Had trouble parsing the sentence, is the comma right? Changed to: {{ieee802-1AR}} defines a category of certificates that are installed by the manufacturer which contain a device unique serial number. > "This may be a software setting, or could be as dramatic as blowing a > fuse." > I really appreciate the author's hearty writing style here. :D :-) You should imagine a Star Wars/Genosis-Droid-Factory and/or James Bond/Dr.No with a huge laser gently browsing across defenseless router parts on a conveyor belt, permanently stencilling them with an identity. (With so many droids in the Star Wars universe, surely "R2D2" isn't a serial number, but rather a model number? ) > 4.1.2.2 > "Generating the key off-device has the advantage that the randomness of > the private key can be better analyzed. " > A second benefit that I expect has been more commercially interesting > is that (assuming serial numbers or other relevant identities can be > pre-reserved) the certificates can be pre-issued, which eliminates both > CA latency and CA dependency from the manufacturing process itself. I > still would not recommend off-device generation though. I have emphasized this point a bit at: https://github.com/mcr/idevid-security-considerations/pull/4/commits/4ba7a4… > Due to the leak > potential and wider exposure to insider attack it has a creepy ring to > it that may undermine the trust placed in the PKI. Even if we 'never > store' the key (as is suggested later in this section) we will leave > computational traces of the key around. I agree. Yet, this reduction in cost might be the difference between having a real IDevID certificate loaded into your microwave, and having some BS attempt to do fake security. A major point of this document is for manufacturers to feel that it's okay to tell us what they did. The judgement can come later through market opinions. > 4.1.2.3 > Agree with the conclusion that this method shares the downsides of both > above. Do you have any suggestions as to a better name? The CPU/MCU makers are very keen on this method, and it accomodates the whole "PUF" mechanism too. I am personally not convinced PUF is truly random, but I don't think we'll know until someone clones one. > 5. PKIs > "A PKI which discloses one or more private certification authority keys > is no longer secure." > Technically, subCAs exist for the sake that they CAN be revoked by a > higher level CA, to recover from compromise of an issuing level CA > which is typically more exposed than the higher levels. > However, > everything issued from that subCA is indeed due for hardware recall so > the event is major. But the most major event is leaking the root CA, as > there is no way to recover from that within the same root chain. Yes, so subordinate CAs limit the damage of key lost to a malicious actor. > To get really into detail though, a well managed CA is able to keep > track of public keys it has intentionally signed into certificate, and > depending on the use case even a compromised subCA key could > theoretically be worked around in the field through administrative > means that basically let go of the cryptographic protection of the PKI > chain in favour of administrative tracking. This basically turns into some kind of administrative CRL if you take it far enough. > I think that part would be > hackish and beyond the scope of this text, however. Just can't help > myself going through the what-ifs; these PKIs have to be seriously > robust. Well, again, they need to be robust enough for the purpose that expect. At one IoTSF conference, a pen-tester describes finding a building-control management system for a major airport on the Internet with **default** passwords. No amount of good HTTPS certificates on this server side of this system helps you out here. A system of good trust anchors and client-side certificates would be better, assuming that the system needed to be reachable. OTH, an Internet connected alarm clock (with a cartoon character) for my kids' bedroom might not need such a robust PKI. Just one strong enough to onboard it to my network > Just imagine a full hardware recall of a car manufacturer for a > "oops need a quick bootstrapping identity PKI fix". Or of anything > resembling a home wifi access point box that end users don't even touch > if it's still working. Yes, agreed. Imagine a fleet of ambulances that had to be grounded because the radio had certificates whose CA was compromised. > 5.1 > "It is quite common to have a three-level PKI, where the root of the CA > is stored in a Hardware Security Module, while the level one > subordinate CA is available in an online form." > This formulation implies that subCAs would not be in hardware security > modules or that they cannot offer CAs available in online form. I think > we should definitely underline the importance of keeping subCAs in HSMs > as well. So, I wrote that text trying to emphasize that the root CA had to be in an HSM that was offline. While the subordinate CA had to be online to be able to issue EE certificates. I wasn't trying to say that it couldn't be an HSM! Reading it also reveals that I've messed up the level text as well. > I would separate the two dimensions explicitly and say "where the root > of the CA is stored in a Hardware Security Module in a way that it > cannot be continuously accessed ('offline'), while the subordinate CA > can sign certificates at any time ('online')." Or potentially even > another formulation that mentions completely separately that "CA keys > are stored in Hardware Security Modules so that the root ... and the > subordinate ...". I've adapted your text. > The section below talks about this in more length so this could also be > migrated there. > 6.1 > "first-stage initialization" focusing on the raw number of people > 'involved' feels maybe a bit arbitrary. Okay. > - it is also important what level of access these people have to the > device in practice, or are they performing primarily a monitoring task > - considering a factory shopfloor, it may be misleading to think that > only 3 people are involved because 3 people actually are *supposed* to > be touching the board, if in fact 300 other people have access to the > actual space and could pop by to intervene with the process if it's not > happening in a separate locked room. (Note that the janitors could also > be bribed and planted/instructed even though no one would count them as > 'involved' by default.) Your thoughts are very spot on. How many people are involved that could be bribed? If it's not in a locked room, then I would expect to write down 300 people in the factory. How would you rewrite this section to make this clearer? > I might redefine this as 'exposure' of the device while in the process, > where fully automatic closed area might be 'low' and a large shopfloor > where 20+ people have physical access to actually go physically touch > the device or the equipment processing it as 'high', for example. I've changed the metric to be called "first-stage-exposure" > first-second-stage-gap: This factor is not formulated as a question. > (Some later factors are not capitalized and punctuated consistently.) Changed to: first-second-stage-gap: : how far and long does a board travel between being initialized with a first-stage bootloader to where it is locked down so that changes to the bootloader can no longer be made. For many situations, there is no distance at all as they occur in the same factory, but for other situations boards are manufactured and tested in one location, but are initialized elsewhere. At this point, I'm going to start a new email! -- Michael Richardson <mcr+IETF(a)sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

1 2

Updated IoT WG agenda
by sandoche Balakrichenan 27 Oct '22

27 Oct '22

Dear all, Due to Visa issues, one of our presenters could not be here. Hence there is a modification in the Agenda. The current agenda looks as follows: * Introduction & House Keeping (5 mins) * Michael Richardson (Sandelman Software Works) – "Social and Technical metrics for Trust Anchor resilence in (IoT) devices" – (30 mins) * Nick Allott(Nquiringminds) - "Secure IOT gateways: highlighting the industry challenges, and identifying the collaborative innovation needed to address them“ – (30 mins) * Peter Steinhaeuser (embeDD) – "Restricting device's network access using MUD files and automatic MUD file creation using OpenWrt“ (25 min) -- Sandoche & Peter RIPE IoT WG Co-Chairs

1 0

RIPE-85 IoT WG Agenda
by Peter Steinhäuser 18 Oct '22

18 Oct '22

Dear all, as you all know, the IoT WG session @RIPE 85 will be on Thursday, October 27th 11:00 - 12:30 (UTC+2). The agenda looks as follows: Introduction & House Keeping (5 mins) Michael Richardson (Sandelman Software Works) – "Social and Technical metrics for Trust Anchor resilence in (IoT) devices" – (30 mins) Bahaa Al-Musawi (University of Kufa) - "A Novel Intrusion Detection Based on Using Non-linear Statistical Analysis and Features Selection Techniques“ – (30 mins) Peter Steinhaeuser (embeDD) – "Restricting device's network access using MUD files and automatic MUD file creation using OpenWrt“ (25 min) Looking forward to see you there! Thank you and kind regards, Peter & Sandoche. — RIPE IoT WG Co-Chairs

1 0

[IoT WG] RIPE-85 Call for Presentations
by Peter Steinhäuser 16 Oct '22

16 Oct '22

Dear collegues, in-person attendence for the RIPE-85 seems to be lower than usual. Although we have good candidates for doing presentations remotely we would like to ask the members of the WG attending RIPE-85 in person if someone has an interesting IoT related topic that could be presented during the WG session on Thursday. Best regards, Peter — RIPE IoT WG Co-Chair

1 0

International Workshop on Socio-technical Cybersecurity and Resilience in the IoT
by Vesna Manojlovic 31 Aug '22

31 Aug '22

https://petras-iot.org/update/star-iot/ STaR-IoT: 1st International Workshop on Socio-technical Cybersecurity and Resilience in the Internet of Things ((12th International Conference of the Internet of Things at the Faculty of Industrial Design Engineering (IDE), TU Delft)) 7 November, 2022 Submission link: https://easychair.org/cfp/stariot22 Submission deadline: Friday 2nd September, 2022 The adoption of IoT technologies and the harnessing of their economic value, represents a process that takes place continually at the intersection between developments in three major domains: social, technical, and economic.  This is because the IoT is much more than just products and services. ‘Things’ are the visible part of the IoT, however, what the IoT really represents, and how it works, goes way beyond devices. We call these interrelated collections of physical and digital objects (sensors, data stores, 3rd parties, business models, actuators, and so on) IoT constellations. As artificial intelligence, data science, and machine learning become more sophisticated, the power of these constellations will become increasingly apparent, and will impact on all aspects of our lives. Therefore, it is critical we fully understand the social and technical interdependencies, opportunities and challenges that exist now and in the future.  Being able to demonstrate that IoT and modern networks can increase security, safety, and resilience when used well, is essential. Bringing together socio-technical researchers to better understand safe and resilient IoT systems, in a way that is culturally appropriate and ethically acceptable and that breeds rather than subverts confidence, is the focus of this workshop. This workshop considers research that examines both social and technical issues relating to the resilience and cybersecurity of IoT devices, systems, and networks. To this end, we aim to bring together researchers to discuss socio-technical challenges and opportunities of IoT technologies, multi-scale deployments of embedded technologies in smart cities, Industry 4.0, logistics, etc. In doing so, it is important to compare local and international regulation, standardization and certification, and public trust in such technologies, and to examine the cybersecurity and resilience of dual-use technologies. This research informs cybersecurity of critical infrastructure, resilience and current geopolitical challenges, international alliances and collaboration, supply-chain security, and preparedness. The workshop will be hosted within the 12th International Conference of the Internet of Things, November 7–10, at the Faculty of Industrial Design Engineering (IDE), on the TU Delft campus (the Netherlands). (https://iot-conference.org/iot2022/) The workshop will be held on the 7th of November 2022. List of topics: We seek submissions that combine the understanding of socio and technical approaches to the resilience and security of IoT systems. Within this domain, particular topics of interest include, but are not limited to: Agile and Self-management architectures for IoT security and resilience Technical and Social emergent behaviours and IoT resilience to faults and threats Secure decentralised edge processing to mitigate faults and threats Law, Economics for security and resilience Public Value of IoT and Applications of IoT to bring Resilience Resilient Security IoT for the Long-term (physical decay, updates/maintenance, aging) IoT verification with the human-in-the-loop Security-by-Design; Privacy-by-Design, Resilience-by-Design Physical Layer Schemes for IoT/CPS key generation Ethics; Responsible and Resilient Innovation

1 0

Re: [iot-wg] iot-wg Digest, Vol 61, Issue 1
by Phil Stanhope 08 Jul '22

08 Jul '22

I think that Michaels' suggestion of an informal group, invite only, chatham house rules is excellent. Within the DNS community this existed for many years (I wasn't a direct participant). It was led by folks like Andrew Sullivan (now Internet Society CEO) and others. Inside Baseball what they termed it ... because they'd use IETF meeting or NANOG meetings to then get to the closest baseball game, have a series of meetings, etc. Always Chatham House rules. I know similar groups exist in the DDoS fighters space -- with some overlap to the DNS operators because of amplification attacks, etc. Always discussing sensitive matters, so Chatham House rules definitely apply. I'm certain that there are those at RIPE now (or previously) who could provide guidance on how comms were established, etc. I know I was in the room with folks who brokered contacts with other key players during the Oct 2016 Dyn attack as an example. -phil On Thu, Jul 7, 2022 at 6:00 AM <iot-wg-request(a)ripe.net> wrote: > 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: the vague IoT/RIPE-NCC training question (Michael Richardson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 06 Jul 2022 13:10:59 -0400 > From: Michael Richardson <mcr+ietf(a)sandelman.ca> > To: =?utf-8?Q?Peter_Steinh=C3=A4user?= <ps(a)embedd.com>, IoT WG RIPE > <iot-wg(a)ripe.net> > Subject: Re: [iot-wg] the vague IoT/RIPE-NCC training question > Message-ID: <27027.1657127459@localhost> > Content-Type: text/plain; charset="utf-8" > > > {did we sort out who are the new co-chairs?} > > Peter Steinh?user <ps(a)embedd.com> wrote: > > Regarding your initial topic about the NCC training offerings I tend > to stand on Jim?s > > side. Nevertheless I think this WG could: > > > 1) Identify IoT aspects that affect ISPs from the broad field of > topcis, as you already > > mentioned a bit further below. @Daniel: I salute your comment, I > think that?s we > > should focus on. > > > 2) Work on RIPE documents, i.e. like the BCOP document we were > working on. Such > > documents then could found a base for trainings, if done by the RIPE > NCC or third > > parties tends to be seen. > > Any other thoughts? > > > Getting engagement from the ISPs seems a tricky matter. Inside prpl > currently IoT is > > not a relevant topic, at least none of the major ISPs seems to have > brought it up, yet. > > Talking to IXPs as well could give us broader view. Although they > have not direct control > > about the end user?s CPEs they can get seriously affected by DDoS > attacks and > > should have a good interest in prevention. > > This concern is what originally motivated CIRA to engage in the SHG > project. > What we really have is a major, industry-wide, tragedy of the commons > https://en.wikipedia.org/wiki/Tragedy_of_the_commons situation. > The entities most affected by poor security and resulting DDoS attacks are > not the entities able to affect change. The ones who could affect change > do > not have the resources and/or motivation to do so. > > >> So, what would I like to see: > >> > >> 1) increase connection with RIPE NCC with organizations like > >> iotsecurityfoundation.org. IoTSF is among the few places I've > found which > >> are not about hype or marketing, who seem to have real connections > to both > >> places/people technical and people/places regulatory. Like the > IETF, though, > >> we need more participation of operators.... not just the airy-fairy > senior > >> security architects from various ISPs, but actual people in the > >> trenches. > > Let me ask a question here. > Is there a means by which the RIPE NCC can (or is already) be in the loop > for reports about DDoS > attacks on ISPs and critical (European) infrastructure? > I don't mean *me*, or the IOT-WG. I understand that this kind of thing is > often confidential. I am asking if the RIPE NCC can act as an air-gap > firewall, exfiltrating important aspects of the incidents. > We can only fix things that we can measure! > Also: _tell me how you will measure me, and I'll tell you how I will act_ > > >> Is there an opportunity to collect wisdom together? > >> Maybe some kind of symposium of operators and openwrt developers > could > >> happen. OpenWRT has had conferences, although often not that well > advertised > >> in advance. pprlFoundation sometimes has conferences I think. The > >> WBAlliance does stuff, but alas, 90% of what I see is total > marketing. > > One approach might be a small colloquium of operators/developers meeting > under Chatham House rules. I'm sure that I could get IoTSF to host such a > thing in London, but there may be better times/places at which the right > people are already there. Note that for the conversation to be genuine it > couldn't be open to the public, but a report would be generated. > > > > -- > Michael Richardson <mcr+IETF(a)sandelman.ca> . o O ( IPv6 I?T consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > >

2 1

the vague IoT/RIPE-NCC training question
by Michael Richardson 06 Jul '22

06 Jul '22

At RIPE84, recorded at https://ripe84.ripe.net/archives/video/782/ Jad El Cham asks about training from the RIPE NCC on "IoT". I watched this today from the archives. I wasn't able to be at the IOT-WG meeting in person (yes, you saw me there on Monday), because I was at the IoT Security Foundation's ManySecured WG meetings in London. Perhaps that makes me more qualified to answer the question? First, some nitpicks about this presentation. I couldn't hear Jad El Cham's name very well, and the lack of slides meant I had to watch the video three times to understand his question. https://ripe84.ripe.net/programme/meeting-plan/iot-wg/ has his name correctly, but: https://ripe84.ripe.net/archives/#wednesday does *NOT* If there were three slides with the questions and thoughts on them, then I could far better respond to the question. (Still not sure if the clapping for Marco leaving RIPE was ... "thanks for all the work", or "thank god you escaped with your sanity...) Second, while I share some of Jim's concern about scope creep, in fact there are many things that the RIPE NCC is uniquely positioned to help with that would benefit the community, and which probably *does* need a subsidy to get done correctly. Profit motives being forever next-quarter, 90% of the IoT security problems (as explained in the previous presentation, the slides at: https://ripe84.ripe.net/presentations/87-HVIKT-IoT-encounters-ripe.pdf include his missing slides...) are the result of next quarter thinking combined with very poor operational controls. If we are going to get a handle on the security issues with networks of devices (routers are the Internet of Internet things) then we need more data and more sharing of experiences. Back in RIPE79, (Rotterdam), I tried to start discussion about how ISPs can collaborate better on dealing with security issues, particularly DDoS caused by distributed malware. So, what would I like to see: 1) increase connection with RIPE NCC with organizations like iotsecurityfoundation.org. IoTSF is among the few places I've found which are not about hype or marketing, who seem to have real connections to both places/people technical and people/places regulatory. Like the IETF, though, we need more participation of operators.... not just the airy-fairy senior security architects from various ISPs, but actual people in the trenches. There are dozens of interesting bits of research being done via RIPE Atlas, telling more IoT types about the results would be a good thing. That could be in the form of some RIPE (NCC?) person talking about research, or perhaps for RIPE NCC sponsoring the researcher to present their stuff at a few conferences, such as the IoTSF conference in October, but also IETF meetings, RSA(*), Industrial Internet Consortium, The Thing Conference, ... btw: I did two training courses in 2020 for IoTSF on default passwords and software updates. *Manufacturers* are *really* hard to reach. Educating *operators* about what to *ask for*, and which regulation the supplier is not-complliant with when they fail, would also be very good. 2) RIPE NCC involvement with specifications like: https://datatracker.ietf.org/wg/mile/about/ ROLIE RFC 8322 good intro:https://www.redhat.com/en/blog/red-hat-adopts-rolie-protocol-automate… GOLIE https://github.com/rolieup/golie For instance, how many ISPs how how to set this up? I have no personal experience. Would I come to a day-long workshop (Saturday before or after RIPE?)... YES. This is training content that RIPE NCC could develop, and could provide in multiple venues for free or for low cost. This is much akin to MANRS, RPKI training, and I think there has been IX training occur as well. ROLIE is not loved by everyone, btw, and there are some alternatives which my slides from 79 went into, but actually I'm not, alas, qualified at this time to say much, because I know little myself. 3) RIPE (NCC) involvement with regulators on the topic of *privacy* and *liability* around vulnerability disclosures. Some operators, for instance, have told me that in order to avoid violating the privacy of their customers when it comes to detecting malware infestations on *their* networks, set up honeypots of (somewhat?) vulnerable devices and wait for them to get p0wned. That's an interesting training course on its own. 4) a RIPE reference secure CPE device...? I could probably go on for days here with things that could be done. Many medium-sized operators have decided they don't like what's available to them, and have went out to specify/build their own devices. Most bigger operators have been doing this for more than a decade, but my observation is that the bigger the operator, the less secure their default device is. (For instance, we know how many and how poorly some of these devices support IPv6) Is there an opportunity to collect wisdom together? Maybe some kind of symposium of operators and openwrt developers could happen. OpenWRT has had conferences, although often not that well advertised in advance. pprlFoundation sometimes has conferences I think. The WBAlliance does stuff, but alas, 90% of what I see is total marketing. 5) I could come with a fifth, but his email is already too long. :-) -- Michael Richardson <mcr+IETF(a)sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide

4 5

IoT conference in Delft - call for workshops
by Aaron Ding 19 May '22

19 May '22

Hi all, a kind reminder for the workshop proposals at 12th International Conference on IoT https://iot-conference.org/iot2022/call-for-workshops/ Proposals can be submitted to workshops-iot2022-IDE(a)tudelft.nl<mailto:workshops-iot2022-IDE@tudelft.nl> Important Dates * Workshop proposal submission deadline: May 25th, 2022 * Notification of workshop acceptance: Rolling, typically within three weeks but no later than June 30 * Workshop papers Submission deadlines: Camera ready date no later than October 17, 2022 * Workshop dates: TBD within November 7-10, 2022 Workshop Program Chairs: Aaron Ding & Kimberly Garcia Aaron -- Associate Professor, TU Delft Associate Editor for ACM Transactions on IoT <https://homepage.tudelft.nl/8e79t/>https://homepage.tudelft.nl/8e79t/

1 0

LoRa Alliance's LoRaWAN World Expo conference
by Jim Reid 19 May '22

19 May '22

In case anyone's interested in this event... > Begin forwarded message: > > From: Olivier Beaujard <obeaujard(a)semtech.com> > Subject: [T20ALL] LoRa Alliance's LoRaWAN World Expo conference in Paris > Date: 19 May 2022 at 09:04:00 BST > To: "t22sg20all(a)lists.itu.int" <t22sg20all(a)lists.itu.int> > Cc: "tsbsg20(a)itu.int" <tsbsg20(a)itu.int> > Reply-To: Olivier Beaujard <obeaujard(a)semtech.com> > > The LoRa Alliance is organizing a two ways conference in Paris on July 6-7: the LoRaWAN World Expo. > > There will be an impressive line-up of ~50 speakers from our entire Global Ecosystem who will come and present about the Power of LoRaWAN in the IoT: Miscrosoft, AWS, Eutelsat, Echostar, Cisco, Tata,… and many others. > > You can see the latest version of the agenda: https://bit.ly/38d6rgk > and the latest list of speakers here: https://bit.ly/3kUaEs4 > > You can register for this important IoT event via this link: > https://cvent.me/EzK049 > > and you are welcome to use the 10% discount code: LWE-SAVE10 (valid through May 31). > > Let me know if you do have any question. > > > > With best regards, > > Olivier Beaujard > Senior Director, LoRa Ecosystem > Semtech > LoRa Alliance Board Member & > Chairman of the Regulatory Work Group > +33 667 027 641 > obeaujard(a)semtech.com >

1 0

Re: [iot-wg] iot-wg Digest, Vol 59, Issue 4
by Phil Stanhope 17 May '22

17 May '22

I just wanted to add my support for Peter. It was a pleasure to work with Peter and other members of the working group on the IoT Architectural Considerations paper we released in April 2021. Peter helped keep us organized and focused during the drafting and review process. -phil On Sun, May 15, 2022 at 6:00 AM <iot-wg-request(a)ripe.net> wrote: > 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. [Peter Steinhaeuser] for co-chair (Peter Steinh?user) > 2. Re: [Peter Steinhaeuser] for co-chair (fwd) Michael > Richardson: Re: [Peter Steinhaeuser] for co-chair (Michael > Richardson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 14 May 2022 17:17:26 +0200 > From: Peter Steinh?user <ps(a)embedd.com> > To: IoT WG RIPE <iot-wg(a)ripe.net> > Subject: [iot-wg] [Peter Steinhaeuser] for co-chair > Message-ID: <6A271EB2-9384-477F-9237-632AA7FC4F8A(a)embedd.com> > Content-Type: text/plain; charset="us-ascii" > > Dear collegues, > > I put my hat (again) into the ring and ask you to support me as a candiate > for co-chairing this WG. > > I think that this WG is still trying to find it's place in the RIPE > community, the overall acitivity level has beend a bit low. Of course the > years of the pandemic and the lack of opportunities to meet in person were > not helpful. Nevertheless it seems that IoT is still something that is > often considered to live in the consumer space, and also many carriers > currently seem to have other priorities. > > With the expanding support of IP for IoT connectivity - i.e. the Thread > and Matter protcol - I think this WG can work more closely with the other > RIPE WGs and should working on linkinf with other RIPE WGs and > standardisation and industry entities to better understand what this RIPE > WG can contribute. > > There are already activities (IETF home gateway WG, Telcom Infra Project) > in this field and also carriers bit by bit seems to pay more attention to > IoT. Industrial IoT is also getting traction and new technologies like LiFi > are emerging. Such should also come this WG's attention and there's are > strong tendency to move toward IP (in my understanding). > > As a WG chair I would focus working on connecting the ongoing activities > to form technical standards and reference implementations for easy adoption > by the industry. I would also work on advocating those to industry players > (i.e. via Broadband Forum & prpl Foundation & Telcom Infrastructure Project > - TIP) to get broader support for these activities as well. In my role as > project manager for prplOS in the prpl Foundation I also propose > technologies for adoption & funding by the prpl Foundation and it's > members, as well as in the TIP project where we contribute technology and > solutions to the Open Coverged Wireless WG (and recently started working on > IoT integration as well). > > I would appreaciate your support for my standing for co-chair for this WG > and supporting it's activities. I still think that this WG can make > meaningful contributions - we had a good start with the BCOP document and > it was a pleasure for me to work with the participating WG members. > > Sincerly, > Peter Steinhaeuser >

1 0

Re: [iot-wg] iot-wg Digest, Vol 59, Issue 6
by Phil Stanhope 17 May '22

17 May '22

I just wanted to add my support for Peter. It was a pleasure to work with Peter and other members of the working group on the IoT Architectural Considerations paper we released in April 2021. Peter helped keep us organized and focused during the drafting and review process. -phil On Tue, May 17, 2022 at 6:00 AM <iot-wg-request(a)ripe.net> wrote: > 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: [Peter Steinhaeuser] for co-chair (T?ma Gavrichenkov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 16 May 2022 20:01:19 +0200 > From: T?ma Gavrichenkov <ximaera(a)gmail.com> > To: Peter Steinh?user <ps(a)embedd.com> > Cc: IoT WG RIPE <iot-wg(a)ripe.net> > Subject: Re: [iot-wg] [Peter Steinhaeuser] for co-chair > Message-ID: > < > CALZ3u+aEXc5nLWGNcazAJAk15Zy6iDchj4c1YeTEMmNm6b+jJQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Peace, > > I, too, support Peter for the IoT WG Chair position. > > -- > T?ma > > On Sat, May 14, 2022, 5:17 PM Peter Steinh?user <ps(a)embedd.com> wrote: > > > Dear collegues, > > > > I put my hat (again) into the ring and ask you to support me as a > candiate > > for co-chairing this WG. > > > > I think that this WG is still trying to find it's place in the RIPE > > community, the overall acitivity level has beend a bit low. Of course the > > years of the pandemic and the lack of opportunities to meet in person > were > > not helpful. Nevertheless it seems that IoT is still something that is > > often considered to live in the consumer space, and also many carriers > > currently seem to have other priorities. > > > > With the expanding support of IP for IoT connectivity - i.e. the Thread > > and Matter protcol - I think this WG can work more closely with the other > > RIPE WGs and should working on linkinf with other RIPE WGs and > > standardisation and industry entities to better understand what this RIPE > > WG can contribute. > > > > There are already activities (IETF home gateway WG, Telcom Infra Project) > > in this field and also carriers bit by bit seems to pay more attention to > > IoT. Industrial IoT is also getting traction and new technologies like > LiFi > > are emerging. Such should also come this WG's attention and there's are > > strong tendency to move toward IP (in my understanding). > > > > As a WG chair I would focus working on connecting the ongoing activities > > to form technical standards and reference implementations for easy > adoption > > by the industry. I would also work on advocating those to industry > players > > (i.e. via Broadband Forum & prpl Foundation & Telcom Infrastructure > Project > > - TIP) to get broader support for these activities as well. In my role as > > project manager for prplOS in the prpl Foundation I also propose > > technologies for adoption & funding by the prpl Foundation and it's > > members, as well as in the TIP project where we contribute technology and > > solutions to the Open Coverged Wireless WG (and recently started working > on > > IoT integration as well). > > > > I would appreaciate your support for my standing for co-chair for this WG > > and supporting it's activities. I still think that this WG can make > > meaningful contributions - we had a good start with the BCOP document and > > it was a pleasure for me to work with the participating WG members. > > > > Sincerly, > > Peter Steinhaeuser_______________________________________________ > > iot-wg mailing list > > iot-wg(a)ripe.net > > https://lists.ripe.net/mailman/listinfo/iot-wg > > > > To unsubscribe from this mailing list, get a password reminder, or change > > your subscription options, please visit: > > https://lists.ripe.net/mailman/listinfo/iot-wg > > >

1 0

it's co-chair selection time!
by Jim Reid 16 May '22

16 May '22

My term as WG co-chair ends at RIPE80 or theresabouts. I will not be standing for another term. First of all, bringing in new and hopefully younger faces to freshen things up is long overdue. Second, I only volunteered to bootstrap the new WG. That has been completed. So it’s time to step away and let the WG find somebody else. There’s some info on WG co-chair responsibilities in RIPE692. Anyone interested in applying who wants more advice on what the job entails, likely time commitments and so on is welcome to contact Sandoche or myself. Or any other recent/current WG co-chair for that matter. I would also ask potential 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. It’ll save the current co-chairs reading every message on the mailing list to decide if they contain something in favour or against a particular candidate. This will also make it clearer for other members of the list to express their support (or not) for a candidate. Anyone can volunteer to become a co-chair and you can even nominate yourself. There’s no requirement to have N people nominating a candidate for them be considered for selection (for values of N > 1). Ideally, it would be good to be able to announce the new co-chair at RIPE80. Though that could be too short notice since the meeting’s just under 4 weeks away. If you think more time is needed to decide, please speak up. There’s no firm deadline and we should take our time about making this appointment - provided of course the new co-chair is in place in plenty of time for RIPE81. Although I think 4 weeks (ish) should be long enough to find a new co-chair, this is for the WG to decide too.

11 19

Re: [iot-wg] [Peter Steinhaeuser] for co-chair (fwd) Michael Richardson: Re: [Peter Steinhaeuser] for co-chair
by Michael Richardson 14 May '22

14 May '22

Peter Steinh=C3=A4user <ps(a)embedd.com> wrote: > I put my hat (again) into the ring and ask you to support me as a > candiate for co-chairing this WG. I am very supportive of Peter doing this! > I think that this WG is still trying to find it's place in the RIPE > community, the overall acitivity level has beend a bit low. Of course > the years of the pandemic and the lack of opportunities to meet in > person were not helpful. Nevertheless it seems that IoT is still > something that is often considered to live in the consumer space, and > also many carriers currently seem to have other priorities. I thik that these are astute observations. I really enjoyed the RIPE79 (Rotterdam) IoT hackathon. I think that there are interesting operational things that RIPE IoT WG could have deeper converations about. There will be a grandchild-of-HOMENET effo= rt at the IETF that might get called SNAC. It would be interesting to me to do some kind of *interop* testing of IoT systems and ISP systems. > As a WG chair I would focus working on connecting the ongoing > activities to form technical standards and reference implementations > for easy adoption by the industry. I would also work on advocating > those to industry players (i.e. via Broadband Forum & prpl Foundation= & > Telcom Infrastructure Project - TIP) to get broader support for these > activities as well. =20=20=20=20 > In my role as project manager for prplOS in the > prpl Foundation I also propose technologies for adoption & funding by > the prpl Foundation and it's members, as well as in the TIP project > where we contribute technology and solutions to the Open Coverged > Wireless WG (and recently started working on IoT integration as well). This kind of promotion of new open source systems and open-stand.org (standards) is really important to me as well. -- Michael Richardson <mcr+IETF(a)sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

1 0

RIPE 84 IoT WG Agenda
by sandoche Balakrichenan 13 May '22

13 May '22

Dear all, As you all know, the IoT WG session @RIPE 84 will be on Wednesday 18th May9:00 - 10:00 (UTC+2). The agenda looks as follows: * Introduction & House Keeping (5 mins) * Leandro Lanzieri (Hamburg University of Applied Sciences) – "Secure and Authorized Client-to-Client Communication for LwM2M" - (15 mins) * Tommy Haga (Helse Vest IKT) - "IoT encounters in Health Care Networks" (25 mins) * Jad El Cham – "RIPE NCC IoT Update 2022" (10 min) * Co-Chair announcement & AOB (5 mins) Thanks and kind regards, Constanze& Sandoche.

1 0

Call for volunteers or nominations for RIPE IoT Working Group co-chair
by sandoche Balakrichenan 13 May '22

13 May '22

Dear Colleagues As Constanze's term as IoT WG co-chair is about to end with RIPE 84, this is a call for nominations or volunteers to co-chair the RIPE IoT working group. *********************************************************************** Please DO NOT reply to this message if you wish to propose a volunteer. *********************************************************************** I would ask for each candidate to start a new thread with, e.g., "[name] for co-chair", and for members to utter their support by replying to the respective thread. Provided there are no reasoned objections from the WG, I'd like to set *May 16th* as a deadline for showing support on the mailing list, so that we can announce the decision on *18th May* during the IoT WG sesssion at RIPE 84. More information about WG co-chair responsibilities (https://www.ripe.net/publications/docs/ripe-692) If you'd like further information, don't hesitate to contact me or Constanze. Have a nice day! Sandoche

4 8