Re: [6tisch] xxx-bootstrap

Mališa Vučinić <> Thu, 15 December 2016 10:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41BC41295A6 for <>; Thu, 15 Dec 2016 02:19:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.816
X-Spam-Status: No, score=-9.816 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qKaqoFoSYvsz for <>; Thu, 15 Dec 2016 02:19:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C3A7712983F for <>; Thu, 15 Dec 2016 02:19:48 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.33,351,1477954800"; d="scan'208";a="204672766"
Received: from unknown (HELO []) ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Dec 2016 11:19:47 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mališa Vučinić <>
In-Reply-To: <>
Date: Thu, 15 Dec 2016 11:19:46 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: 6tisch <>, sandeep kumar <>
Subject: Re: [6tisch] xxx-bootstrap
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Dec 2016 10:19:52 -0000

Hi Peter,

Thanks for your comments. See my responses inline.


> On 15 Dec 2016, at 09:56, peter van der Stok <> wrote:
> 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.

Yes, that’s correct.

> Consequently, that means during the whole bootstrap process the link between JA and JN is not secured by layer2 keys.

This is still under discussion within the design team, but the conclusion is the same — we can’t provide any L2 security at that point because L2 keys are simply not known. One option is to use well-known K1 to provisionally protect the join packets at L2 but this of course does not provide any security other than helping to bootstrap L2. Another option is for JA to simply accept unsecured packets at L2, and make it an exception for join traffic, potentially only during the duration of the join process.

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

Yes, that needs more work. Will create an issue to update it in the next version. The ND at that point refers to a registration of JN’s link-local address at JA, in order to bootstrap the neighbor tables in IPv6 compliant way. So, in summary it refers to a single NS/NA exchange between JN and JA.

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

In Section 5, we state: 

"The JN uses the initial key K1 [I-D.ietf-6tisch-minimal] until it is configured with a new link-layer key K2 as described above. JA SHOULD secure/verify DATA and ACKNOWLEDGMENT frames destined/originated at JN with K1 only during the duration of the join process.  How JA learns whether the join process is ongoing is out of scope of this specification."

Again, instead of K1 the frames between JN and JA could simply be unsecured at L2. Is this what you are referring to or would you like to see other text added? 

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

No, there is no prefix information distributed at that time. This happens after the node has joined. JOIN request is sent link-local to link-local from JN to JA, and using global addresses from JA to JCE (possible because JA is already part of the network). Will clarify.

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

As stated above, ND at that point refers to NS/NA exchange in order to register link-local address of JN before it should start sending IPv6 packets from the interface. RPL DIOs which contain prefix information are encrypted using K2 and can only be decrypted once the node has joined.

But you are right, we may not need the NS/NA exchange in case minimal-security follows Phase 1, assuming it has been done before. Will clarify in the next version.

> Other questions:
> Do you expect the JCA to be on the 6tisch network or can it be anywhere else?

There is no reason why JCE would need to be collocated with 6LBR. It suffices that JA knows JCE’s global address for the communication to take place. 

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

I don’t understand the use case, could you provide some more details? 

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