You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.1

IoT Working Group

Threaded
Collapse

[iot-wg] New on RIPE Labs: Visualisations of Periodic IoT Traffic

User Image

Mirjam Kühne

2020-03-19 11:31:15 CET

RIPE NCC staff member

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-traffic

Kind regards,
Mirjam Kühne
RIPE NCC

Poonam Yadav

2020-03-19 12:56:23 CET

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 _at_ ripe _dot_ 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-traffic
>
> Kind regards,
> Mirjam Kühne
> RIPE NCC
>
> _______________________________________________
> iot-wg mailing list
> iot-wg _at_ ripe _dot_ net
> https://lists.ripe.net/mailman/listinfo/iot-wg
>
User Image

Mirjam Kühne

2020-03-19 15:25:46 CET

RIPE NCC staff member

-----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 _at_ ripe _dot_ net
>> mir _at_ ripe _dot_ 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 _at_ ripe _dot_ net iot-wg _at_ ripe _dot_ net>
>> https://lists.ripe.net/mailman/listinfo/iot-wg
>>
>>
>> _______________________________________________ iot-wg mailing
>> list iot-wg _at_ ripe _dot_ 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-----

Eliot Lear

2020-03-19 16:04:39 CET

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-downstream-device
>
> 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 _at_ ofcourseimright _dot_ com
> lear _at_ ofcourseimright _dot_ 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 _at_ ripe _dot_ net
>>     mir _at_ ripe _dot_ 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-traffic
>>
>>         Kind regards,
>>         Mirjam Kühne
>>         RIPE NCC
>>
>>         _______________________________________________
>>         iot-wg mailing list
>>         iot-wg _at_ ripe _dot_ net iot-wg _at_ ripe _dot_ net>
>>         https://lists.ripe.net/mailman/listinfo/iot-wg
>>
>>
>>     _______________________________________________
>>     iot-wg mailing list
>>     iot-wg _at_ ripe _dot_ net iot-wg _at_ ripe _dot_ net>
>>     https://lists.ripe.net/mailman/listinfo/iot-wg
>

Michael Richardson

2020-03-19 18:47:00 CET

Eliot Lear <lear _at_ lear _dot_ ch> wrote:
    > 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.

Manufacturers SHOULD avoid using their own DNS infrastructure in my opinion.

        Operational Considerations for use of DNS in IoT devices
         draft-richardson-opsawg-mud-iot-dns-considerations-01

Abstract

   This document details concerns about how Internet of Things devices
   use IP addresses and DNS names.  The issue becomes acute as network
   operators begin deploying RFC8520 Manufacturer Usage Description
   (MUD) definitions to control device access.

   This document explains the problem through a series of examples of
   what can go wrong, and then provides some advice on how a device
   manufacturer can best make deal with these issues.  The
   recommendations have an impact upon device and network protocol
   design.

..co-authors, reviews, pull-requests and comments sought.

{I'm annoyed that the DNSOP group declined to define "QuadX" as a term in
ietf-dnsop-terminology-ter. Actually, I don't care what it's called, as along
as I have a term for such public recursive services}

--
Michael Richardson <mcr+IETF _at_ sandelman _dot_ ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



Poonam Yadav

2020-03-26 00:45:41 CET

Thank you Eliot and Michael for this thoughtful discussion and sharing the
draft. I agree with you regarding the security issue with  shared cloud
infrastructure and DNS. However on IoT device side,  do you think, a
hardware based authentication  (e.g., quantum tunnelling  -
https://www.cryptoquantique.com/solution ) may solve some of these issues?

Best regards,
Poonam

On Thu, Mar 19, 2020 at 5:47 PM Michael Richardson <mcr+ietf _at_ sandelman _dot_ ca>
wrote:

>
> Eliot Lear <lear _at_ lear _dot_ ch> wrote:
>     > 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.
>
> Manufacturers SHOULD avoid using their own DNS infrastructure in my
> opinion.
>
>         Operational Considerations for use of DNS in IoT devices
>          draft-richardson-opsawg-mud-iot-dns-considerations-01
>
> Abstract
>
>    This document details concerns about how Internet of Things devices
>    use IP addresses and DNS names.  The issue becomes acute as network
>    operators begin deploying RFC8520 Manufacturer Usage Description
>    (MUD) definitions to control device access.
>
>    This document explains the problem through a series of examples of
>    what can go wrong, and then provides some advice on how a device
>    manufacturer can best make deal with these issues.  The
>    recommendations have an impact upon device and network protocol
>    design.
>
> ..co-authors, reviews, pull-requests and comments sought.
>
> {I'm annoyed that the DNSOP group declined to define "QuadX" as a term in
> ietf-dnsop-terminology-ter. Actually, I don't care what it's called, as
> along
> as I have a term for such public recursive services}
>
> --
> Michael Richardson <mcr+IETF _at_ sandelman _dot_ ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> iot-wg mailing list
> iot-wg _at_ ripe _dot_ net
> https://lists.ripe.net/mailman/listinfo/iot-wg
>