Re: 64bit MAC addresses and SLAAC

[Mark Smith <[e-mail]>]

On Fri, 19 Jun 2020, 19:18 Etienne-Victor Depasquale, <[e-mail]>
wrote:

> But there are certainly computing&communicating platforms not powerful
>> enough to run AES.
>
>
>>
>  So IPv6 is probably not the right protocol for those devices.
>
>
>
> That "probably" is the saving grace :)
>
> I'd go for IPv6 on any communicating device and give in to alternatives
> with very great reluctance.
>


"Right tool for the job", as my father taught me.

I'm also reminded of how good a blade screwdriver is at opening a paint
can, except that doing that ruins the blade screwdriver for undoing screws!
Buy a cheap blade screwdriver and call it a "paint can opener", making it
then the right tool for the job, and also accepting that it can't be
reliably used as a screwdriver anymore.





>
>
> On Fri, Jun 19, 2020 at 12:04 AM Mark Smith <[e-mail]>
> wrote:
>
>>
>>
>> On Fri, 19 Jun 2020, 00:30 Alexandre Petrescu, <
>> [e-mail]> wrote:
>>
>>>
>>>
>>> Le 18/06/2020 à 09:50, Mark Smith a écrit :
>>> >
>>> >
>>> <snip>
>>> >
>>> >
>>> > 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.
>>>
>>> Probably AES is not an issue on some platforms, in terms of having
>>> enough cycles.
>>>
>>> But there are certainly computing&communicating platforms not powerful
>>> enough to run AES.
>>>
>>
>> So IPv6 is probably not the right protocol for those devices.
>>
>> It's great to try to use IPv6 for everything, but it doesn't mean IPv6
>> must be used for everything.
>>
>> IPv6 is a general purpose internetworking protocol, so it isn't going to
>> be optimal for all cases.
>>
>> At some point, the compromises or costs of using IPv6 will outweigh the
>> benefits of using a general commodity protocol. At that point, the expense
>> of a better suited and more specific protocol to suit the problem protocol
>> is worth paying.
>>
>> The IoT applications being discussed are local network only applications.
>> Since an internetworking protocol solves a much bigger problem -
>> internetworking hosts attached to a network of networks, using an
>> internetworking protocol to solve a local network application problem is
>> always going to involve a compromise - accepting a larger packet overhead
>> because of using an address space that is far larger than it needs to be to
>> solve the problem.
>>
>> Unfortunately we don't really have a middle ground, general purpose, yet
>> local network only protocol. MPLS is close, but not really general purpose
>> enough.
>>
>> Now that IPv4 can't solve the Internet internetworking problem (hence
>> invention of IPv6), perhaps we should repurpose it to use for local network
>> only application problems..
>>
>> Regards,
>> Mark.
>>
>>
>>
>>> And, it is not only a matter of energy consumption or time it takes to
>>> compute.
>>>
>>> There are very many additional aspects involved in using crypto
>>> technology, at all layers from 0 to Political.  Bind them all to an IP
>>> address?
>>>
>>> Alex
>>>
>>> >
>>> > 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]
>>> >     <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] <mailto:[e-mail] <ipv6@ietf..org>>
>>> >     Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6
>>> >
>>>  --------------------------------------------------------------------
>>> >
>>> >
>>> > --------------------------------------------------------------------
>>> > IETF IPv6 working group mailing list
>>> > [e-mail]
>>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> > --------------------------------------------------------------------
>>> >
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>> --------------------------------------------------------------------
>> 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
>