Re: [6lo] privacy enhanced L3 addresses derived from short L2 addresses

[Michael Richardson]

sajjad akbar  wrote:
> Compression mechanism is still expensive for these low power networks,
> Do you think its affordable trade off?

This is not a generic compression mechanism.  It might look like:
 IID = truncate-lower-61-bits(PRF(L2Key|PANID|16-bits-from-IPHC))

Where PRF is ideally some AES based thing that leverages the hardware.
The 16-bits-from-IPHC is essentially assigned in the same way as short
addresses are otherwise  (by DHCPv6, by taking the last-2-bytes of EUI-64, or
brute force).

Maybe it needs to be reverseable: so that senders can compress IIDs in
destination addresses that they send to.  But I think that maybe it's enough
if it's cachable.  So that when a node sees the 16-bits, it caches the
resulting IID, and can then use that mapping the other way.  6LRs could
probably put the 16-bits as index to routing entry and avoid any
expansion/compression cycle.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] privacy enhanced L3 addresses derived from short L2 addresses

[Michael Richardson]

Dave Thaler  wrote:
> The audience of 6lo-privacy-considerations is document authors (not
> implementers).
> You want a document that's for implementers to be compliant to.  One
> doesn't already exist (but one would indeed make sense).  In my view,
> it's not worth holding up the privacy-considerations spec, but just
> pursue it in parallel assuming there is interest/energy.

Only if there were an obvious document to put this new work into in a timely
way, would I continue to suggest holding it up.  I see that there isn't,
so let's get this one out.

After some thought, the ability to compress l3 IIDs because they match match
L2 addresses only works on the first (for source) and last (for dest) hop,
and not at all in the middle, or near root for traffic not going to the root.

Being able to derive/decompress a 64-bit L3 IID in a deterministic, but
private to holders of the L2 key, from a shorter set of bits that would go
into IPHC header is a better goal.  I think that this fits into charter for
6lo.  (It would be a good codestand.ietf.org project too!)


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] privacy enhanced L3 addresses derived from short L2 addresses

[samita Chakrabarti]

Hi Michael,

>>such work does not yet exist.  I think it would be in charter for 6lo at
this time?  It would seem to be an extension to
draft-ietf-6lo-paging-dispatch in >>some way.  I wonder if it worth delay to
do this now?

Right, there is no document on 6lo address formation  that standardizes the
following suggestion made in the privacy document.
It is though covered in the charter as part of the extension of 6lowpan
stack. 

I don't quite relate the connection with 6lo-paging-dispatch...  

Which document to delay ?

Thanks,
-Samita
-Original Message-
From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Michael Richardson
Sent: Tuesday, September 20, 2016 1:12 PM
To: lo <6lo@ietf.org>
Subject: [6lo] privacy enhanced L3 addresses derived from short L2 addresses


draft-ietf-6lo-privacy-considerations says:

   When Short Addresses are desired on links that are not guaranteed to
   have a short enough lifetime, the mechanism for constructing an IPv6
   interface identifier from a Short Address could be designed to
   sufficiently mitigate the problem.  For example, if all nodes on a
   given L2 network have a shared secret (such as the key needed to get
   on the layer-2 network), the 64-bit IID might be generated using a
   one-way hash that includes (at least) the shared secret together
   with the Short Address.  The use of such a hash would result in the IIDs
   being spread out among the full range of IID address space, thus
   mitigating address scans, while still allowing full stateless
   compression/elision.

such work does not yet exist.  I think it would be in charter for 6lo at
this time?  It would seem to be an extension to
draft-ietf-6lo-paging-dispatch in some way.  I wonder if it worth delay to
do this now?

--
Michael Richardson , Sandelman Software Works  -=
IPv6 IoT consulting =-




___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo