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

From: Michael Richardson <[email-masked]>
Date: Tue, 20 Sep 2016 16:12:24 -0400

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "samita Chakrabarti" <[email-masked]>
Date: Tue, 20 Sep 2016 16:44:18 -0700

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:[email-masked]] On Behalf Of Michael Richardson
Sent: Tuesday, September 20, 2016 1:12 PM
To: lo <[email-masked]>
Subject: [6lo] privacy enhanced L3 addresses derived from short L2 addresses

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 <[email-masked]>, Sandelman Software Works  -=
IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 22 Sep 2016 20:56:46 -0400

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

If we were to define a way to map short-L2 addresses, using the PANID
and L2-key, into random-looking 64-bit IIDs, then we'd want to be able
to indicate in 6lo compression mechanisms that we want to compress addresses
out.

I realize upon further thought that 6lo-paging-dispatch is not the right
place to define what is really a small extension to RFC6282.  But I didn't
think that roll-routing-dispatch was either.

I'm not sure what to do here:  it seems that 6lo-privacy-considerations ought
to make a stronger statement about what to do, and to the point of having a
normative reference to something concrete that ought to be done.

---

From: Dave Thaler <[email-masked]>
Date: Fri, 23 Sep 2016 03:31:58 +0000

> Sent: Friday, September 23, 2016 9:57 AM
> To: samita Chakrabarti <[email-masked]>
> Cc: 'lo' <[email-masked]>
> Subject: Re: [6lo] privacy enhanced L3 addresses derived from short L2
> addresses
> 
> 
> If we were to define a way to map short-L2 addresses, using the PANID and
> L2-key, into random-looking 64-bit IIDs, then we'd want to be able to indicate
> in 6lo compression mechanisms that we want to compress addresses out.
> 
> I realize upon further thought that 6lo-paging-dispatch is not the right place
> to define what is really a small extension to RFC6282.  But I didn't think that
> roll-routing-dispatch was either.
> 

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.

Dave

---

From: sajjad akbar <[email-masked]>
Date: Fri, 23 Sep 2016 11:49:30 +0100

Hi

Compression mechanism is still expensive for these low power networks, Do
you think its affordable trade off?

Regards
Sajjad

On Fri, Sep 23, 2016 at 1:56 AM, Michael Richardson <[email-masked]>
wrote:

>     > Right, there is no document on 6lo address formation  that
> standardizes
>     > the
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Sep 2016 12:08:07 -0400

Dave Thaler <[email-masked]> wrote:
    > 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!)

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Sep 2016 12:21:57 -0400

sajjad akbar <[email-masked]> 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.