<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Michael,<div class=""><br class=""></div><div class="">was travelling the last days with busy schedule, my apologizes for my delayed response…</div><div class=""><br class=""></div><div class="">Regarding your initial topic about the NCC training offerings I tend to stand on Jim’s </div><div class="">side. Nevertheless I think this WG could:</div><div class=""><br class=""></div><div class="">1) Identify IoT aspects that affect ISPs from the broad field of topcis, as you already </div><div class=""> mentioned a bit further below. @Daniel: I salute your comment, I think that’s we</div><div class=""> should focus on.</div><div class=""><br class=""></div><div class="">2) Work on RIPE documents, i.e. like the BCOP document we were working on. Such</div><div class=""> documents then could found a base for trainings, if done by the RIPE NCC or third</div><div class=""> parties tends to be seen.</div><div class=""><br class=""></div><div class="">@1) <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">I agree that most manufacturers only react when there’s market pressure. </span></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">If the ISPs set clear requirements how IoT devices need to behave that’s a</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">better leverage IMO. Nevertheless, here the question would be what could</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">be consequence for non-conforming IoT devices. Would denying internet</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">(or network access in general) be legal? This might also be interesting in the</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">context of devices not receiving updates any more etc.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">@3) That’s an interesting approach, this could be a good project for further research</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">and also standardisation of the honeypot setup. The information collected could also</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">be shared between operators and even globally to identify threats much faster.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">@4) Definitely. OpenWrt would be ideal for a reference implementation since it’s</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">de-facto inudstry standard and used by the major chipset makers for their SDKs.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">I do not think if we should work on a full fledged reference secure CPE - but on the </div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">IoT relevant services and configuration. This could result in a specific OpenWrt feed</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">that could be simply consumed by mid sized operators.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Getting engagement from the ISPs seems a tricky matter. Inside prpl currently IoT is</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">not a relevant topic, at least none of the major ISPs seems to have brought it up, yet.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Talking to IXPs as well could give us broader view. Although they have not direct control</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">about the end user’s CPEs they can get seriously affected by DDoS attacks and </div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">should have a good interest in prevention.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">I think you brought up several very valueable topics!</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Thank you,</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Peter</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">Am 30.05.2022 um 21:40 schrieb Michael Richardson <<a href="mailto:mcr+ietf@sandelman.ca" class="">mcr+ietf@sandelman.ca</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">At RIPE84, recorded at <a href="https://ripe84.ripe.net/archives/video/782/" class="">https://ripe84.ripe.net/archives/video/782/</a><br class="">Jad El Cham asks about training from the RIPE NCC on "IoT".<br class="">I watched this today from the archives. I wasn't able to be at the IOT-WG<br class="">meeting in person (yes, you saw me there on Monday), because I was at the IoT<br class="">Security Foundation's ManySecured WG meetings in London.<br class="">Perhaps that makes me more qualified to answer the question?<br class=""><br class="">First, some nitpicks about this presentation. I couldn't hear Jad El Cham's<br class="">name very well, and the lack of slides meant I had to watch the video three<br class="">times to understand his question.<br class=""><a href="https://ripe84.ripe.net/programme/meeting-plan/iot-wg/" class="">https://ripe84.ripe.net/programme/meeting-plan/iot-wg/</a><br class="">has his name correctly, but:<br class="">https://ripe84.ripe.net/archives/#wednesday does *NOT*<br class=""><br class="">If there were three slides with the questions and thoughts on them, then I<br class="">could far better respond to the question.<br class="">(Still not sure if the clapping for Marco leaving RIPE was ... "thanks for<br class="">all the work", or "thank god you escaped with your sanity...)<br class=""><br class="">Second, while I share some of Jim's concern about scope creep, in fact there<br class="">are many things that the RIPE NCC is uniquely positioned to help with that<br class="">would benefit the community, and which probably *does* need a subsidy to get<br class="">done correctly. Profit motives being forever next-quarter, 90% of the IoT<br class="">security problems (as explained in the previous presentation, the slides at:<br class="">https://ripe84.ripe.net/presentations/87-HVIKT-IoT-encounters-ripe.pdf<br class="">include his missing slides...) are the result of next quarter thinking<br class="">combined with very poor operational controls.<br class=""><br class="">If we are going to get a handle on the security issues with networks of<br class="">devices (routers are the Internet of Internet things) then we need more data<br class="">and more sharing of experiences. Back in RIPE79, (Rotterdam), I tried to<br class="">start discussion about how ISPs can collaborate better on dealing with<br class="">security issues, particularly DDoS caused by distributed malware.<br class=""><br class="">So, what would I like to see:<br class=""><br class="">1) increase connection with RIPE NCC with organizations like<br class="">iotsecurityfoundation.org. IoTSF is among the few places I've found which<br class="">are not about hype or marketing, who seem to have real connections to both<br class="">places/people technical and people/places regulatory. Like the IETF, though,<br class="">we need more participation of operators.... not just the airy-fairy senior<br class="">security architects from various ISPs, but actual people in the trenches.<br class=""><br class="">There are dozens of interesting bits of research being done via RIPE Atlas,<br class="">telling more IoT types about the results would be a good thing. That could<br class="">be in the form of some RIPE (NCC?) person talking about research, or perhaps<br class="">for RIPE NCC sponsoring the researcher to present their stuff at a few<br class="">conferences, such as the IoTSF conference in October, but also IETF<br class="">meetings, RSA(*), Industrial Internet Consortium, The Thing Conference, ...<br class=""><br class="">btw: I did two training courses in 2020 for IoTSF on default passwords and<br class=""> software updates. *Manufacturers* are *really* hard to reach.<br class=""> Educating *operators* about what to *ask for*, and which regulation the<br class=""> supplier is not-complliant with when they fail, would also be very good.</div></div></blockquote><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class=""><div class=""><div class="">2) RIPE NCC involvement with specifications like:<br class=""><a href="https://datatracker.ietf.org/wg/mile/about/" class="">https://datatracker.ietf.org/wg/mile/about/</a><br class="">ROLIE RFC 8322<br class=""> good intro:https://www.redhat.com/en/blog/red-hat-adopts-rolie-protocol-automated-exchange-security-compliance-assets<br class=""> GOLIE https://github.com/rolieup/golie<br class=""><br class="">For instance, how many ISPs how how to set this up?<br class="">I have no personal experience.<br class="">Would I come to a day-long workshop (Saturday before or after RIPE?)... YES.<br class="">This is training content that RIPE NCC could develop, and could provide in<br class="">multiple venues for free or for low cost. This is much akin to MANRS, RPKI<br class="">training, and I think there has been IX training occur as well.<br class=""><br class="">ROLIE is not loved by everyone, btw, and there are some alternatives which my<br class="">slides from 79 went into, but actually I'm not, alas, qualified at this time<br class="">to say much, because I know little myself.<br class=""><br class="">3) RIPE (NCC) involvement with regulators on the topic of *privacy* and<br class=""> *liability* around vulnerability disclosures.<br class=""><br class="">Some operators, for instance, have told me that in order to avoid<br class="">violating the privacy of their customers when it comes to detecting<br class="">malware infestations on *their* networks, set up honeypots of (somewhat?)<br class="">vulnerable devices and wait for them to get p0wned.<br class=""><br class="">That's an interesting training course on its own.<br class=""><br class="">4) a RIPE reference secure CPE device...?<br class=""><br class="">I could probably go on for days here with things that could be done.<br class=""><br class="">Many medium-sized operators have decided they don't like what's available to<br class="">them, and have went out to specify/build their own devices. Most bigger<br class="">operators have been doing this for more than a decade, but my observation is<br class="">that the bigger the operator, the less secure their default device is.<br class="">(For instance, we know how many and how poorly some of these devices support IPv6)<br class=""><br class="">Is there an opportunity to collect wisdom together?<br class="">Maybe some kind of symposium of operators and openwrt developers could<br class="">happen. OpenWRT has had conferences, although often not that well advertised<br class="">in advance. pprlFoundation sometimes has conferences I think. The<br class="">WBAlliance does stuff, but alas, 90% of what I see is total marketing.<br class=""><br class="">5) I could come with a fifth, but his email is already too long.<br class="">:-)<br class=""><br class=""><br class=""><br class=""><br class=""><br class="">--<br class="">Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting )<br class=""> Sandelman Software Works Inc, Ottawa and Worldwide<br class=""><br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">iot-wg mailing list<br class="">iot-wg@ripe.net<br class="">https://mailman.ripe.net/<br class=""><br class="">To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/<br class=""></div></div></blockquote></div><br class=""><div class=""> <br class=""><div id="sig" style="border-top: dotted 1px #999999; padding-top: 10px; padding-botton: 10px; margin: 11px 0; font-family: 'Lucida Grande', Verdana, Arial, Sans-Serif; font-size: 11px;" class=""> <img src="https://file.as201155.net/f/5572ae1c73f64c0caea4/?dl=1" width="180" height="38" align="left" style="margin-right: 20px; padding-top: 2px;" class=""> <div style="color: #999999;" class=""> <strong style="color: #333333;" class="">Peter Steinhäuser, CEO</strong><br class=""> embeDD GmbH · Alter Postplatz 2 · 6370 Stans · Switzerland<br class=""> Phone: +41 (41) 784 95 85 · Fax: +41 (41) 784 95 64 </div> <div style="clear: both;" class=""></div> </div> </div> <br class=""></div></body></html>