Re: [6tisch] xxx-bootstrap

[peter van der Stok <[e-mail]>]

Hi Malisa,

I read the 6tisch-minimal-security draft.
I do have some detailed questions, which probably have to do with my 
reading things which are not there.

If I understand correctly, the Join response returns the link2 keys to 
secure the the links between JN, JA and possibly other neighbours of JN.
Consequently, that means during the whole bootstrap process the link 
between JA and JN is not secured by layer2 keys.
My question concerns step 2 , neghbour discovery.
It is mentioned that ND is executed, but it is not clear to me how that 
works in detail.
The whole 6tisch network uses link-layer protection, while JA-JN link is 
not protected; Does that not need an additional protocol specifications 
for JA?

Do I understand correctly that during discovery the prefix is received 
and a global IP address is constructed to be used for the JOIN request?

A more global related question is why can you not transmit link-layer 
keys to be used for JA-JN link after the security handshake and then 
start ND?

Other questions:
Do you expect the JCA to be on the 6tisch network or can it be anywhere 
else?
What about securing a heterogeneous network of which the 6tisch network 
happens to be part? The link-layer keys will not be adequate in that 
case.

Thanks for answering,

Peter



Mališa Vučinić schreef op 2016-11-30 13:50:
> Hi Peter,
> 
> Yes, that is correct, we propose to use OSCOAP for communication
> between JN and JCE. In the model, JA is a CoAP proxy so the choice of
> OSCOAP and EDHOC was quite natural. We use CBOR/COSE to transport the
> keys and the short 15.4 address. Certificate enrollment belongs to
> Phase 1, and at the moment we don’t have the details on how this is
> done but hopefully we can come to an agreement to use the common
> protocols for both phases such that Phase 2 is a natural extension of
> Phase 1.
> 
> First step in that direction could be to discuss the most efficient
> way of JA forwarding. We decided against IP-in-IP encapsulation
> because it results in three IP headers in the constrained part in case
> JCE is not collocated with 6LBR. Having JA play the role of a CoAP
> proxy is a plausible alternative.
> 
> Mališa
> 
>> On 30 Nov 2016, at 11:07, peter van der Stok <[e-mail]> 
>> wrote:
>> 
>> Hi Malisa,
>> 
>> thanks for the answer. I am happy to read that there is a shared 
>> concern about reuse.
>> 
>> My concern is the communication between joining node and central node.
>> 
>> Did I understand correctly that you propose to use oscoap for the 
>> communication between joning node and central node?
>> what content-formats do you propose to transport between joining node 
>> and central node? Will those be different in phase 1 and 2?
>> What contents do you propose to transport? certificates, YANG/CBOR 
>> documents, keys?
>> How should I see the co-existence between phase 1 and phase 2? Will 
>> phase 2 be an extension of the transported contents of phase 1?
>> Apologies for the naivety of my questions, but the number of discussed 
>> possibilities at this moment are quite overwhelming.
>> 
>> I just like to get clear how the bootstrap can be composed of 
>> different standardized parts and where the future evolution is.
>> Identifying and describing those parts will be a nice step forward.
>> 
>> Peter
>> 
>> 
>> Mališa Vučinić schreef op 2016-11-30 10:22:
>>> Hello Peter,
>>> My understanding of the IETF 97 meeting outcome is that Phase 1
>>> solution will be anima-compatible i.e., it will provide zero-touch
>>> bootstrapping with manufacturer-installed certificate as the start
>>> state and locally relevant credential as the end state. At the 
>>> moment,
>>> I believe that Michael’s proposal for Phase 1 is quite 6tisch 
>>> agnostic
>>> and it can be used in other scenarios.
>>> However, the end state of Phase 2 are 6tisch-specific key(s) (cf.
>>> minimal draft) and temporary network identifiers that we tackle in 
>>> the
>>> minimal-security draft. This builds upon existing work in 6tisch and
>>> will be needed no matter what common bootstrapping approach is used.
>>> Mališa
>>>> On 30 Nov 2016, at 09:06, peter van der Stok <[e-mail]> 
>>>> wrote:
>>>> Hi 6tisch bootstrap followers,
>>>> Curently, we live in a confusing world wih many bootstrap proposals.
>>>> They all seem to have in common; a joining node, an assistant, a 
>>>> central authority, and Michael Richardson.
>>>> While each bootstrap proposal seems to have a different naming 
>>>> history.
>>>> Joking apart, I like to plead for a commmon bootstrap approach in 
>>>> 6tisch, and anima to share parts of the bootstrap protocols.
>>>> I suspect that the discovery and the push- or pull start will be 
>>>> technology and context dependent.
>>>> My concern is with the number of protocols that the central 
>>>> authority has to support.
>>>> When there are too many bootstrap approaches, we may end up with as 
>>>> many protocol converters as there are bootstrap protocols.
>>>> The anima bootstrap team has recognized the importance of low 
>>>> resource devices by supporting the use of coap.
>>>> The drafts "EST over coaps" demonstrate that the support of two 
>>>> protocols (coap and http based) in the cental authority is 
>>>> realistic.
>>>> My plea is that we find a common protocol that replaces EST for the 
>>>> coap nodes.
>>>> I understand that after the bad experience with CoMI, the 6tisch 
>>>> people do not want to be dalayed again by waiting for a common 
>>>> approach.
>>>> Nevertheless, I think it is worthwhile to explore this avenue.
>>>> Any comments?
>>>> Peter
>>>> --
>>>> Peter van der Stok
>>>> _______________________________________________
>>>> 6tisch mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/6tisch