Re: [6lo] privacy enhanced L3 addresses derived from short L2 addresses
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
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
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 wrote: > > samita Chakrabarti wrote: > > 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... > > 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. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > ___ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > > ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] privacy enhanced L3 addresses derived from short L2 addresses
> -Original Message- > From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Michael Richardson > Sent: Friday, September 23, 2016 9:57 AM > To: samita Chakrabarti > Cc: 'lo' <6lo@ietf.org> > Subject: Re: [6lo] privacy enhanced L3 addresses derived from short L2 > addresses > > > samita Chakrabarti wrote: > > 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... > > 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. 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 ___ 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 wrote: > 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... 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. -- 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
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