Re: 64bit MAC addresses and SLAAC

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.

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 <
pch-ipv6-ietf-6@u-1.phicoh.com> 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
> ipv6@ietf.org
> 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