Hi, +1. I think the draft is useful and I would support its adoption. The draft still needs some work but that should be done as part of the working group.
Thanks, Shiva On 29 Sep 2016, at 14:13, Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> wrote: Dear chairs and all : As an author I support the adoption of this document. There is ample art -and recent events- that suggests that: - IOT devices cannot be trusted for their actions towards the network they live in and the internet at large. They may easily be compromised and do all sorts of things from impersonating other sensors to bombing web sites. - IOT devices cannot stay awake and defend their addresses against attackers that may claim their addresses and then use them for malicious purposes, from black-holing critical sensors to reporting the wrong data. IOT networks could be expected to protect the devices; but with the current protocols they cannot easily recognize right from wrong. There is nothing in 6LoWPAN ND that proves ownership of an address in SAVI terms, e.g. first come first serve, and an attacker may successfully impersonate any device if it knows its MAC address and its IP address, one possibly derived from the other in a reversible fashion. There is a clear need for a better control, so that the 6LR/6LBR may recognize that a device that claims an address is the true owner. With reliable information they can enforce that a device that uses an address as source of a packet also owns that address. This is what this draft is all about. Basically, we propose to secure the 6LoWPAN ND registration to prevent theft from a third party. This echoes the past work at SeND and SAVI, but in a very simple fashion that does not require heavy artillery in the device as SeND does. Basically the IOT device uses a crypto ID information (like CGA) instead of the unique ID (the MAC address) in the ARO option, as extended by rfc6775-update; ownership of that ID can verified and the ID can be used to validate that a next registration come from the same device as the previous. A same crypto ID can be used to register multiple addresses, and the addresses to not need to derive from the crypto ID (as opposed to SeND). The ID is stored at the 6LR and 6LBR associated with the address, and they can use ND extension to revalidate the ID ownership at any time they want. Cheers, Pascal From: 6lo [mailto:[email protected]] On Behalf Of samita Chakrabarti Sent: mardi 27 septembre 2016 03:15 To: 'lo' <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: [6lo] WG adoption call for draft-sarikaya-6lo-ap-nd-04 Hello 6lo WG: We have discussed the following document at the IETF meetings and mailing list about the use of cryptographic ID to identify one device with a particular IPv6 address during the Neighbor Discovery Process. The crypto-ID association is helpful when MAC-ID or EUI-64 ID may not be used. There has been fair amount of interest in securing the IP-address owner authentication using this method, in the WG meetings(IETF95). The co-authors have addressed several WG comments in the 04 version. The adoption call starts now and ends on Oct 10th, 2016. Please provide your opinion with yes/no answer and a short explanation for this adoption call within the deadline. Thanks and Regards, -Gabriel and Samita (6lo co-chairs) > > > Name: draft-sarikaya-6lo-ap-nd > Revision: 04 > Title: Address Protected Neighbor Discovery for Low-power and Lossy > Networks > Document date: 2016-08-22 > Group: Individual Submission > Pages: 17 > URL: > https://www.ietf.org/internet-drafts/draft-sarikaya-6lo-ap-nd-04.txt > Status: https://datatracker.ietf.org/doc/draft-sarikaya-6lo-ap-nd/ > Htmlized: https://tools.ietf.org/html/draft-sarikaya-6lo-ap-nd-04 > Diff: https://www.ietf.org/rfcdiff?url2=draft-sarikaya-6lo-ap-nd-04 > > Abstract: > This document defines an extension to 6LoWPAN Neighbor Discovery. > This extension is designed for low-power and lossy network > environments and it supports multi-hop operation. Nodes supporting > this extension compute a Cryptographically Unique Interface ID and > associate it with one or more of their Registered Addresses. The > Cryptographic ID (Crypto-ID) uniquely identifies the owner of the > Registered Address. It is used in place of the EUI-64 address that > is specified in RFC 6775. Once an address is registered with a > Cryptographic ID, only the owner of that ID can modify the state > information of the Registered Address in the 6LR and 6LBR. _______________________________________________ 6lo mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6lo
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
