Lowpanners, as we discussed in Philadelphia, we need to make progress on our new charter items. A very important work item that will influence most of the others is the security model.
First of all, there is the Internet-Draft draft-daniel-6lowpan-security-analysis-02.txt, which in particular describes the threats a 6lowpan is subjected to and various existing specifications that may aid us in countering them. In Philadelphia, I said that I would like to see one more round of this document as an individual contribution and then ask the WG to decide to take it on as a WG document for charter item 5. In addition to the existing authors, Shoichi Sakane and Robert Moskowitz have volunteered to take an active role in this. To obtain more input to this document, I would like the mailing list to discuss four aspects of 6lowpan security this week: 1) end-to-end security. I have heard a lot of people saying IKE is too heavy for a 6lowpan node; but there has been little evidence that ESP can't be made to work. What would be the right ciphersuite (and how can we trade off security with our strict packet size requirements)? What is the field of application (i.e., where would even ESP be too heavy)? What key management solutions make sense here instead of IKE? 2) where even ESP is too heavy for a node, a border device on the 6lowpan might act as a proxy, doing the heavy lifting. This might mean that we use existing AES-CCM on-chip hardware for the intra-lowpan hop(s), and encapsulate in ESP on the proxy border device (just as a VPN gateway would do). Note that none of this is application-specific, but we still need to understand how to split the work between the low-capability end node and the security proxy. (The security proxy might even speak IKE, making this solution more compatible to today's security gateways in der Internet.) What key management solutions work right in this three-party system? 3) how do we protect the network? ND, routing/meshing, and multicasting need availability protection beyond the end-to-end integrity/confidentiality that ESP can afford. In particular, we need to protect the batteries of the devices. From simple group keying solutions to GDOI (see MSEC WG and KMART BOF the previous week), a lot of alternatives are out there. What role does the AES-CCM hardware play here? What key management solutions work to protect ND and routing/meshing? How much battery protection can we achieve? 4) how do the various forms of key management interface to commissioning? Commissioning (i.e., the process of "making friends" as opposed to the process of "finding the friends" and building the network that we call bootstrapping) will be a process that involves user interfaces, special buttons on devices, bar code labels, serial/USB/NFC communication -- clearly mostly outside of the scope of the communication standards, but with much influence on interoperability. When replying to this message, please indicate which of the four items above (or anything else that I forgot) you are addressing. Gruesse, Carsten _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
