- iot-wg - mailman.ripe.net

Re: [iot-wg] New on RIPE Labs: Visualisations of Periodic IoT Traffic
by Eliot Lear 25 Mar '20

25 Mar '20

Hi Poonam Thanks. The concern here is that the device could choose to identify as something else through a set of false communications. It is indeed an interesting area of research. I am not saying there is nothing to be done, but it is something that requires careful consideration as we aim toward automating policy. I fear in particular that the cloud makes this quite a bit harder, and IOT manufacturer use of their own DNS infrastructure will make it yet more difficult, because we are all using the same cloud infra. Eliot On 19.03.20 15:42, Poonam Yadav wrote: > > Dear Elliot, > > Thank you for your very important question. In the current setting, > our router verifies packets using devices' MAC addresses; it means the > router has a list of mac addresses of all IoT devices. For another > work, we used certificate-based authentication between the router and > device MUD server, something > similar: https://docs.microsoft.com/en-us/azure/iot-edge/how-to-authenticate-downstr… > > We used off-the-self IoT devices so its not easy to integrate many TEE > based solutions. > > Best regards, > > Poonam > > > > On Thu, Mar 19, 2020 at 12:47 PM Eliot Lear <lear(a)ofcourseimright.com > <mailto:lear@ofcourseimright.com>> wrote: > > Very interesting work! > > A cautionary question: > > If I wanted to pretend to be one of these devices on your network, > how hard would it be? > > Eliot > > On 19.03.20 12:56, Poonam Yadav wrote: >> Thanks for sharing! >> >> We have analysed similar pattern in many IoT devices and >> presented periodicity in IoT traffic as FFT (fig 4 - of IoTDI >> paper attached for reference) and some initial results here in >> this report: >> https://www.repository.cam.ac.uk/handle/1810/284092 >> and full paper is here: >> https://dl.acm.org/doi/10.1145/3302505.3310082 >> >> Best regards, >> >> On Thu, Mar 19, 2020 at 10:31 AM Mirjam Kuehne <mir(a)ripe.net >> <mailto:mir@ripe.net>> wrote: >> >> Dear colleagues, >> >> IoT devices often perform activities on a periodic basis. >> Thymen Wabeke >> of SIDN Labs shares his analysis of periodic network traffic >> from IoT >> lightbulbs. Read it on RIPE Labs at: >> >> https://labs.ripe.net/Members/thymen_wabeke/visualisations-of-periodic-iot-… >> >> Kind regards, >> Mirjam Kühne >> RIPE NCC >> >> _______________________________________________ >> iot-wg mailing list >> iot-wg(a)ripe.net <mailto:iot-wg@ripe.net> >> https://lists.ripe.net/mailman/listinfo/iot-wg >> >> >> _______________________________________________ >> iot-wg mailing list >> iot-wg(a)ripe.net <mailto:iot-wg@ripe.net> >> https://lists.ripe.net/mailman/listinfo/iot-wg >

3 2

Re: [iot-wg] New on RIPE Labs: Visualisations of Periodic IoT Traffic
by Mirjam Kuehne 19 Mar '20

19 Mar '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Eliot, Thymen asked me to pass this on to you (but I believe he is now subscribed to the list): - -- Eliot has a valid point. We didn’t focus on this aspect yet, but it’s good to keep that in mind. In general, adversaries can fool any machine learning model once they know the model parameters. One can exploit the parameters to craft so-called "adversarial examples” that will generate a specific output/classification. This is actually a research topic on it’s own called adversarial machine learning [1]. This blog [2] shows some famous examples using images of pandas. [1] https://en.wikipedia.org/wiki/Adversarial_machine_learning [2] https://openai.com/blog/adversarial-example-research/ - --- Kind regards, Mirjam On 19/03/2020 13:47, Eliot Lear wrote: > Very interesting work! > > A cautionary question: > > If I wanted to pretend to be one of these devices on your network, > how hard would it be? > > Eliot > > On 19.03.20 12:56, Poonam Yadav wrote: >> Thanks for sharing! >> >> We have analysed similar pattern in many IoT devices and >> presented periodicity in IoT traffic as FFT (fig 4 - of IoTDI >> paper attached for reference) and some initial results here in >> this report: https://www.repository.cam.ac.uk/handle/1810/284092 >> and full paper is here: >> https://dl.acm.org/doi/10.1145/3302505.3310082 >> >> Best regards, >> >> On Thu, Mar 19, 2020 at 10:31 AM Mirjam Kuehne <mir(a)ripe.net >> <mailto:mir@ripe.net>> wrote: >> >> Dear colleagues, >> >> IoT devices often perform activities on a periodic basis. Thymen >> Wabeke of SIDN Labs shares his analysis of periodic network >> traffic from IoT lightbulbs. Read it on RIPE Labs at: >> >> https://labs.ripe.net/Members/thymen_wabeke/visualisations-of-periodi c-iot-traffic >> >> >> Kind regards, >> Mirjam Kühne RIPE NCC >> >> _______________________________________________ iot-wg mailing >> list iot-wg(a)ripe.net <mailto:iot-wg@ripe.net> >> https://lists.ripe.net/mailman/listinfo/iot-wg >> >> >> _______________________________________________ iot-wg mailing >> list iot-wg(a)ripe.net >> https://lists.ripe.net/mailman/listinfo/iot-wg -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJec4DqAAoJEIZoWwVN2sgM2hUP/RBvIpcXAfHp97uMnfeqzYE4 rSR5Sa5GkQ6uOC3Pu/4uO96ln2m9H/Oy9Bgnz/k3U1KpFPW5MqJHom1Ckmgdxs0a u9/ruzdk/rVCggtWXifY1TIjm0PJ2sOVKd7ERACITlzMOG0xnMll2Ah8NX5AsV2O j+KIO47vbnoZdaqyq/pmCvDQMazEcT2hU9z6KLwIvE436Er6YqluCkvuMPyacARL slj7K2o9gUZJ+3ianIRuRBpGRgTDruSJfEs7XAB+Lfms6BhfspgTANNaRHPMzqLN r8TeaQ7A2swpDnKOyUWWTqT/P/7qK/eZkt/ErWtM55ZFgV8wMZcd8KCsifU+Z1nv oZw67sgJUL618PCHzYdii28FAjciqQaQbLWGDgyOS4ItgSKYh4R2YwcpkqkJHvv4 YY/YjJYqM1cARLlUx3TZzk5PXvWMPc70XQTPpFyyM3t+hIDhnU7qZyt6wBBv2JUP 6j5ep/44XZ4tF4zWkbZZlKbrmkUxCNYPIwHmRZr94Sq8atQMTfw4QoK6hLxw9jf7 XpqAZmsU/2t+6hRHeAack/tvOoVUC1Xzue+upyjrYs8j3otgOPaznWWFN1vIEGZv 8h35qzp+QeQGoB4LjVxVelhdP0uf7GlXjgGgRs+0O308ApMZOz3n4ArO+8SynFhH I/hriOFDdJMqKK8rA6Ci =qLA6 -----END PGP SIGNATURE-----

1 0

New on RIPE Labs: Visualisations of Periodic IoT Traffic
by Mirjam Kuehne 19 Mar '20

19 Mar '20

Dear colleagues, IoT devices often perform activities on a periodic basis. Thymen Wabeke of SIDN Labs shares his analysis of periodic network traffic from IoT lightbulbs. Read it on RIPE Labs at: https://labs.ripe.net/Members/thymen_wabeke/visualisations-of-periodic-iot-… Kind regards, Mirjam Kühne RIPE NCC

2 1

IoT BCOP Document
by sandoche Balakrichenan 18 Mar '20

18 Mar '20

Dear all and Michael, I am piggybacking on Michael's last mail on the IoT BCOP document. We have been discussing this topic for a while and we need to go further. Last time, we discussed there was a brief consensus for this subject within RIPE Scope : "/Best Current Operational Practice (BCOP) document in RIPE scope for proactively mitigating IoT attacks/". If there is an alternative opinion, *please express*. There were proposals from Eliot and others, that we should begin with an *outline*. The initial outline was as follows: ------- The threat Some background on device capabilities and limitations Who can do what to improve the situation? Devices CPE gear Upstreams IoT Manufacturers Consumers (let's not ask much) ------- The functionality for controlling the home network traffic would typically include: Insight in all the devices connected to the home network. Possibility to block traffic. End-user friendly GUI and traffic management possibility. Option to have the traffic management outsourced (e.g. to an ISP). Blocking of compromised IoT devices. ------- We could have discussion on the following points: 1. Outline 2. Volunteers (who wish to contribute) 3. Champions (who will lead the work) - We could limit the number of Champions 4. A deadline These are my two cents. Please feel free with your feedback/contributions. Sandoche.

1 1

Interest for a virtual RIPE 80 meeting
by sandoche Balakrichenan 18 Mar '20

18 Mar '20

Dear all, As you all know RIPE 80 will happen between 11-15 May 2020 in Berlin. With the Covid-19 situation, there is a query from the RIPE meeting Organisers to the chairs on whether there will be interests from the WG to continue with sessions and presentation in case of a remote meeting? In the event, there is a remote meeting, it will be shortened (may be it will happen in a single day) overall RIPE meeting. The chairs would like to know from the WG: A. Would you like to continue with sessions and presentations in the case of a remote meeting? B. If yes to A, do you think we could limit to one or two remote presentations (Overall max. time allocated to IoT WG could be 30 to 40 minutes)? We have already three interesting presentations planned for RIPE 80 or do you think we should allocate the time for presenting any other topic that needs to be discussed urgently. C. Would you envision anything beyond having speaker and slides available with chat and stenography? Thanks for your feedback. RIPE IoT WG Co-chairs, Sandoche and Jim.

6 6

EduRoam for IoT
by sandoche Balakrichenan 10 Dec '19

10 Dec '19

Dear all, I am sure that you might have all heard about EduRoam (https://www.eduroam.org/how/). We are in discussion with some academic partners to develop a platform similar to EduRoam for IoT, initially for Research purposes. The idea initially is to have IoT devices (e.g. LoRa devices) authenticated in visited networks based on its identifier. For example, a LoRa end-device which has established authentication in its home network (e.g. in University A) should be able to connect to a gateway and Network Server in a visited network (e.g. In University B) with the same security credentials. This is not a new idea. We can see that there have been related works at the IETF, WBA alliance etc. The purpose of this mail is to know if any of you are aware of similar work and will this topic be of interest for the RIPE community? Thanks for your suggestions, contacts, feedback. Sandoche.

3 4

New on RIPE Labs: How Consumer IoT Devices Expose Information
by Mirjam Kuehne 13 Nov '19

13 Nov '19

Dear colleagues, For those who missed Anna Maria Mandalari's presentation at RIPE 79, you can now read the summary of her interesting (and scary) research on RIPE Labs: How Consumer IoT Devices Expose Information https://labs.ripe.net/Members/anna_maria_mandalari_2/how-consumer-iot-devic… Kind regards, Mirjam Kühne RIPE NCC

1 0

New on RIPE Labs: Results of the IoT Hackathon
by Mirjam Kuehne 12 Nov '19

12 Nov '19

Dear colleagues, The tenth RIPE NCC hackathon took place just before RIPE 79. Four teams of community members worked on a number interesting projects related to the Internet of Things (IoT) and came up with some great results. Check out the findings on RIPE Labs: https://labs.ripe.net/Members/becha/results-of-the-first-iot-hackathon Kind regards, Mirjam Kühne RIPE NCC

2 1

RIPE 79 IoT WG Minutes
by sandoche Balakrichenan 01 Nov '19

01 Nov '19

Dear all, Thanks for reviewing the minutes below and providing your feedback, if any. It will be soon published in the website. Thanks to Marco for drafting the minutes. ---- **** ------- Minutes of the RIPE 79 IoT Working Group Date: 17 October 2019 Chairs: Sandoche Balakrichenan and Jim Reid Scribe: Marco Hogewoning (RIPE NCC) 1. Administrivia The chairs opened the session and introduced the agenda, then continued to introduce the first speaker. 2. The Security Lifecycle of an IoT Device Michael Richardson (Sandelman Software Works) Presentation available at:https://ripe79.ripe.net/archives/video/252 Michael, together with Eliot Lear (Cisco) presented on the different standards and mechanisms that exist to manage the security of IoT devices throughout their lifetime. Eliot also engaged in a short demo regarding a connected printer. Jelte Jansen (SIDN) asked whether there was room for third parties to warn the system about vulnerabilities in a particular device, such as the proposed DOTS â€œcall homeâ€ signal. Michael answered that such an approach would involve some challenges regarding who to trust, taking into account deliberate actions to disconnect a competitor or other forms of â€œdigital vandalism.â€ Alain Durand (ICANN) commented on the complexity of the system, pointing out the many moving parts, and noted that the home environment is a difficult place to protect. Eliot engaged in a small poll with the audience, asking them who believed that there is a role for the ISP to play in protecting the consumer. Whilst Malcom Hutty (LINX) commented the question was too binary, a quick show of hands revealed that although many supported the statement, there wasnâ€™t a clear majority. Eliot further shared his vision of this process being step-by-step, with a gradual implementation to provide agents with the necessary details and asking informative questions to the consumer such as: â€œshould I notify the manufacturer about this problem.â€ Michael shared an anecdote about insurance and the use of online â€œsmartâ€ locks. Malcolm Hutty in his role as consumer stated that the proposed model centered around the fact that the service provider knows best. Although this might work for the majority of consumers, it doesnâ€™t for him as he doesnâ€™t necessarily trust his provider and likes to tinker with the settings himself. Michael in response laid out a system where various MUD configuration files could work in unison and part of the information could even be crowdsourced. Benedikt Stockebrand (Stepladder IT) sought some clarifications on the type of device that could implement the proposed model. Michael clarified this was meant to run on the CPE and provided some details on the inner workings of the protocols. Peter SteinhÃ¤user (embeDD Gmbh) asked how much adoption there was, suggesting that more clarity regarding the liability for vulnerabilities could act as a driver for adoption. Eliot responded that a number of their enterprise systems had support for MUD and he knew several other companies were testing with it, confirming one of them even discovered a bug in the implementation. But he agreed that this still needed a push in the consumer market and adoption there might take a while. Eric van Uden asked if the proposed model was planning to make use of TR69 to control the CPE. Eliot confirmed that one of the parties testing had been CableLabs and they intent to use TR69 or equivalent models to provision the system. After Eliotâ€™s demonstration, Kai Storbeck (XS4ALL) asked if the system had any assurances with regards to compatibility or conformity, to which Eliot responded that people can always lie but it would be discovered. 3. Information Exposure from Consumer IoT Devices: A Multidimensional Network-Informed Approach Anna Maria Mandalari, Imperial College London Presentation available at:https://ripe79.ripe.net/archives/video/257/ Anna Maria presented on her study with a laboratory setup to discover IoT device behavior in regular domestic use. Marco Hogewoning (RIPE NCC) asked for clarification regarding the use of MAC addresses and Anna Maria confirmed that they are regularly seen in unencrypted payload as a form of device identification. Jim Reid (RTFM llp) asked if there was any intention to publish a â€œname and shame listâ€ and whether any of the devices was observed using DNS-over-HTTPs (DoH). Anna Maria responded it was a good idea and they were considering publishing some sort of classifier or ranking system to indicate a deviceâ€™s performance. She said that DoH was not seen in the test network. Jan Zorz (ISOC) offered to run the code in his own home environment to learn more. 4. Update on the IoT Hackathon Rotterdam 2019 Constanze Dietrich, LEXTA Consultants Group Presentation available at:https://ripe79.ripe.net/archives/video/259/ Constanze presented about the experiences and outcomes of the RIPE NCC IoT Hackathon that she helped to organise in the weekend ahead of the RIPE meeting. Jim Reid thanked the organising team, complementing them on the results. 5. Best Current Operational Practice (BCOP) Document in RIPE Scope for Proactively Mitigating IoT Attacks Jim Reid, RTFM llp Presentation available at:https://ripe79.ripe.net/archives/video/261/ Jim, making reference to earlier discussions in the community about creating a document, polled the room if there was still interest. When asked, several people in the room indicated they would be available to help out as volunteers. Sandoche thanked all the participants and closed the meeting.

1 0

clarification on BEREC consultation
by Jim Reid 17 Oct '19

17 Oct '19

Peter kindly pointed out that my earlier mail today on this topic mistakenly quoted an ETSI thing, not the BEREC consultation. Apologies for any confusion. The morning coffee hadn't kicked in when I sent the email. Well that's my excuse and I'm sticking to it. The important thing is unchanged though. The Connnect WG is leading the effort on a community response to the BEREC consultation on identification of the network termination point. If members of the IoT WG have input to that community response, please raise them in the Connnect WG. We can of course discuss BEREC's ideas here. However that is unlikely to influence whatever community response emerges from the Connect WG.

3 4