Subject: Re: [Anima] [6tisch-security] [6lo] Device vs network bootstrapping [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things]

From: Kris Pister <[email-masked]>
Date: Thu, 26 Feb 2015 14:31:59 -0800

Brian -

 >  What we need is a generic solution that doesn't care about which L2
 > technology is involved, because we are trying to establish trust at
 > a level above L3 routing.

This is a fine goal, and it may be exactly what 6lo or some other
group should be working on, but I think that it is out of scope for 6tisch.
What we need to do is figure out who to trust to configure a very specific
L2, with very specific constraints.  If we can leverage other more general
work that's great, but the constraints of 4e/TSCH are likely to push
6top-configuration trust in a different direction.

ksjp

On 2/26/2015 11:23 AM, Brian E Carpenter wrote:
> Below...
>
> On 26/02/2015 19:18, Hedanping (Ana) wrote:
>> Hi Brian,
>> Please see my reply inline.
>>
>>   > -----Original Message-----
>>   > From: 6lo [mailto:[email-masked]] On Behalf Of Brian E Carpenter
>>   > Sent: Thursday, February 26, 2015 3:06 AM
>>   > To: Hedanping (Ana); [email-masked]; Michael Richardson;
>>   > Behcet Sarikaya
>>   > Cc: [email-masked]; [email-masked]; [email-masked]
>>   > Subject: [6lo] Device vs network bootstrapping [Comments needed for Security
>>   > Bootstrapping of IEEE 802.15.4 based Internet of Things]
>>   >
>>   > Hi,
>>   >
>>   > On 26/02/2015 03:48, Hedanping (Ana) wrote:
>>   > ...
>>   > > IMHO, there are distinctions between the network level bootstrapping
>>   > > and joining device level bootstrapping. Network level bootstrapping
>>   > > includes at least two cases: network start-up case and
>>   > > re-commissioning case. The bootstrapping network level bootstrapping
>>   > > request should be different from that of joining device level request
>>   > > in order to converge efficiently. I agree that they need to be clarified.
>>   >
>>   > How does a device that has just been switched on know whether it is joining
>>   > an existing network or is simply one of many devices that are attempting to
>>   > form a new network?
>>   >
>> The device can learn from its neighbors about the network state. For instance, from the bits indicating network ID and device type in hello/beaconing message, the device knows whether a neighbor belongs to an existing network or it is a 'new' device as well, and whether the neighbor has ability to forward/verify authentication message.
>>
>>   > How does a set of devices that are attempting to form a new network know
>>   > that they are re-commissioning a previously existing network?
>>   >
>> Again, the state can be learnt by exchanging the network ID that devices belonged to
>>
>>   > The only safe assumption seem to be that devices cannot know these things.
>>   > Autonomic devices have no state at power-on.
>>   >
>> The devices cannot know these things by themselves, but through collaboration it is possible. From this aspect, I do not object that autonomic devices have no state at power-on.
> OK. With my Anima hat on, I see a strong need for a solution that does
> not have any specific L2 technology dependence. What you describe here
> works for a specific technology with specific bits set in L2 packets.
> What we need is a generic solution that doesn't care about which L2
> technology is involved, because we are trying to establish trust at
> a level above L3 routing.
>
>      Brian
>
> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security