Malisa, The short answer is: I don't know yet :-)
There are obviously different approaches. To be most effective, the right way to let people propose solutions as individual I-Ds, then have the WG debate over pros/cons of each. The requirements are summarized in Kris' e-mail. Thomas On Thu, May 7, 2015 at 8:46 PM, Mališa Vučinić <[email protected]> wrote: > Thomas, > > On 07 May 2015, at 06:45, Thomas Watteyne <[email protected]> > wrote: > > For the distributed CoAPIE case, > https://tools.ietf.org/html/draft-wang-6tisch-6top-coapie-00 doesn't > focus on security (it's a -00). IMO, there are two options: > - we consider CoAPIE security to be part of L2 security. That is, a > network-wide PSK, or neighbor-by-neighbor keys installed by the JCE > > > Even if you consider CoAPIE security to be protected by different L2 keys, > you need to take care of actual CoAP resource access i.e. difference > between nodes that can READ and DELETE a 6top resource from Kris’ mail. > Assuming the mote possesses a table/ACL locally, you would essentially be > doing some sort of implicit CoAP authorization using L2 keys. The problem > is that higher access granularity at CoAP resource level would then > translate to more complex L2 key distribution schemes, which could be > considered a layer violation. > > - the CoAPIE also encapsulates the DTLS record. Packet will be (much) > bigger, and neighbor-to-neighbor authentication would be needed. > > > If I am reading > https://tools.ietf.org/html/draft-wang-6tisch-6top-coapie-00 correctly, > CoAPIE’s payload at L2 is directly a CoAP message - the rest of the > protocol stack is not included. Do you consider including the full protocol > stack in the IE in order to get DTLS working? > > Mališa > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
