- iot-wg - mailman.ripe.net

[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