Re: 64bit MAC addresses and SLAAC

[Alexandre Petrescu <[e-mail]>]

Le 18/06/2020 à 08:29, Etienne-Victor Depasquale a écrit :
> 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.

The alternative makes sense.

Alex

> 
> Etienne
> 
> On Wed, Jun 17, 2020 at 11:54 PM Philip Homburg 
> <[e-mail] <mailto:[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] <mailto:[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
> --------------------------------------------------------------------
>