Hi,

I also support adoption of this work.

Cheers,

Carles


> 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
>


_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo

Reply via email to