Re: 64bit MAC addresses and SLAAC

[Mark Smith <[e-mail]>]

On Thu, 18 Jun 2020, 16:30 Etienne-Victor Depasquale, <[e-mail]>
wrote:

> Philip,
>
> " I also wonder, a device that cannot afford a couple SHa2 hashes? Then
> that
> device is probably insecure and should not be connect to the internet
> anyhow  "
>
> I haven't got any data to make a case.. What I can see is a WSN scenario,
> with some features in it, as follows.
>
> One important operating principle with WSNs is to prolong lifetime.
> When a node turns off, its loss may cause network-wide effects, like RPL
> DODAG tree re-formation.
>
> Sensors are output devices, oriented towards their border router for
> access to the Internet.
> Is it fair to say that they're single-purpose devices, supporting no
> (little?) more than a RESTful interface to their data acquisition?
> I think so.
>
> Does it make sense to load sensors with generation of semantically opaque
> interface identifiers?
> Yes - but only after understanding its impact through a network-scoped
> study of WSN lifetime.
>

So I have a couple of IoT IPv6 books from about 10 years ago, and they talk
about these battery powered devices having AES implementations to encrypt
the radio layer.

So it seems AES was cheap enough to do in battery powered IoT devices 10
years ago, so I would assume it is even cheaper to do now.

I understand crypto algorithms can also be used as a hash generator, so
perhaps the AES in these things can be used to generate hashes for RFC7217
stable IDs.

Regards,
Mark.



> Alternatively:
> keep link-layer addresses in IPv6 IIDs,
> without allowing unauthorized data collection from the nodes,
> by implementing access control to the nodes at the (mains-powered) border
> router.
>
> Etienne
>
> On Wed, Jun 17, 2020 at 11:54 PM Philip Homburg <
> [e-mail]> wrote:
>
>> >   Of course the caveat there with unmanaged network and SOHO and Mobile
>> >where manual or DHCPV6 is not possible or viable.
>>
>> Why is DHCPv6 not possible? Of course there is the Android problem.
>> But I doubt that a low power IoT device would share a wifi-link with an
>> Android device.
>>
>> >    In those cases SLAAC is preferred, but then we have the crux of
>> >    issue and the decision tree on privacy random IID and its overhead
>> >    if its not necessary versus modified EUI64.
>> >    tree of course the underlying operational impacts of random
>> >    versus  stable IID double edged sword operator or individuals
>> >    decision to pick which works best for their use case.  In the
>> >    end net-net is what is simplest to deploy and least overhead
>> >    but also meets the desired goal is generally the thought for
>> >    picking the IID generation solution. For that SLAAC wins out in
>> >    that decision for the use case described above.
>>
>> A stable, unique pseudo random IID per prefix basically requires one
>> SHA2-HMAC (or equivalent in SHA3 or other modern hash function) per
>> prefix.
>>
>> I cannot imagine that computing 2 SHA2 hashes has a significant amount
>> of energy use compared to link attachment and duplicate address detection.
>>
>> This computation is once per prefix, so it becomes an issue if the
>> devices frequently attaches to new links. In which case tracking
>> protection
>> becomes important.
>>
>> I also wonder, a device that cannot afford a couple SHa2 hashes? Then that
>> device is probably insecure and should not be connect to the internet
>> anyhow.
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
>
> --
> Ing. Etienne-Victor Depasquale
> Assistant Lecturer
> Department of Communications & Computer Engineering
> Faculty of Information & Communication Technology
> University of Malta
> Web. https://www.um.edu.mt/profile/etiennedepasquale
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>