Re: [6tisch] xxx-bootstrap

Mališa Vučinić <malisa.vucinic@inria.fr> Wed, 30 November 2016 12:50 UTC

Return-Path: <malisa.vucinic@inria.fr>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9506812979D for <6tisch@ietfa.amsl.com>; Wed, 30 Nov 2016 04:50:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.397
X-Spam-Level:
X-Spam-Status: No, score=-8.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBZCk7xPSBkT for <6tisch@ietfa.amsl.com>; Wed, 30 Nov 2016 04:50:38 -0800 (PST)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9AC6129841 for <6tisch@ietf.org>; Wed, 30 Nov 2016 04:50:36 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.31,574,1473112800"; d="scan'208";a="202318444"
Received: from unknown (HELO [128.93.84.195]) ([128.93.84.195]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Nov 2016 13:50:34 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mališa Vučinić <malisa.vucinic@inria.fr>
In-Reply-To: <bfd6b70cb59064eed785f18d26542b57@xs4all.nl>
Date: Wed, 30 Nov 2016 13:50:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5EAA50B8-CD29-4BBA-BFA7-0DD9A3D69E49@inria.fr>
References: <efb18853e63642bc4a996dc419cd1efb@xs4all.nl> <AF430AD1-FBB1-494A-ABD4-F0D18599153F@inria.fr> <bfd6b70cb59064eed785f18d26542b57@xs4all.nl>
To: consultancy@vanderstok.org
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/KTboQfWdWd25F8sT-xFLgeKLjFE>
Cc: 6tisch <6tisch@ietf.org>, sandeep kumar <sandeep.kumar@philips.com>
Subject: Re: [6tisch] xxx-bootstrap
X-BeenThere: 6tisch@ietf.org
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" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Nov 2016 12:50:40 -0000

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 <stokcons@xs4all.nl> 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 <stokcons@xs4all.nl> 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
>>> 6tisch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tisch