Re: [Roll] home-building-requirements section 7.1

<yoshihiro.ohba@toshiba.co.jp> Wed, 10 December 2014 23:24 UTC

Return-Path: <yoshihiro.ohba@toshiba.co.jp>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5EC1AC427 for <roll@ietfa.amsl.com>; Wed, 10 Dec 2014 15:24:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.702
X-Spam-Level:
X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=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 HKPlcudesAxZ for <roll@ietfa.amsl.com>; Wed, 10 Dec 2014 15:24:05 -0800 (PST)
Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CAE71A1B29 for <roll@ietf.org>; Wed, 10 Dec 2014 15:24:04 -0800 (PST)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id sBANO20T012643; Thu, 11 Dec 2014 08:24:02 +0900 (JST)
Received: (from root@localhost) by arc1.toshiba.co.jp id sBANO2pu028500; Thu, 11 Dec 2014 08:24:02 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA28499; Thu, 11 Dec 2014 08:24:02 +0900
Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id sBANO1je016882; Thu, 11 Dec 2014 08:24:01 +0900 (JST)
Received: from TGXML208.toshiba.local by toshiba.co.jp id sBANO1Pv026986; Thu, 11 Dec 2014 08:24:01 +0900 (JST)
Received: from TGXML210.toshiba.local ([169.254.4.170]) by TGXML208.toshiba.local ([133.199.70.17]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 08:24:01 +0900
From: <yoshihiro.ohba@toshiba.co.jp>
To: <consultancy@vanderstok.org>, <roll@ietf.org>, <mcr+ietf@sandelman.ca>
Thread-Topic: [Roll] home-building-requirements section 7.1
Thread-Index: AQHQB2K8SS6vkJ4SZ0O9+e3jdZRW4Jxux9mAgBbBXQCAANwmgIADJ4gg
Date: Wed, 10 Dec 2014 23:24:00 +0000
Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B29D0F485@TGXML210.toshiba.local>
References: <30100.1416777372@sandelman.ca> <21fd36d565e1ecd9bd96f8f1465b3837@xs4all.nl> <8571.1418064454@sandelman.ca> <6a448d30463f53ff4a1a508b995e8c26@xs4all.nl>
In-Reply-To: <6a448d30463f53ff4a1a508b995e8c26@xs4all.nl>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
x-originating-ip: [133.196.20.221]
msscp.transfermailtomossagent: 103
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/CbrtPu0MA7s6JsP-Btv5RtrpaX8
Cc: mcr@sandelman.ca, abr@sdesigns.dk
Subject: Re: [Roll] home-building-requirements section 7.1
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Dec 2014 23:24:12 -0000

It depends on the requirements on the target system.  If the target system is formed in a totally ad-hoc fashon, then the joining order is not determined by network topology.  

But in home and building networks where some a central management entity typically exists, there will be a connectivity issue if the joining order is not determined by network topology. In such a managed network, the application in a node should be ready to work when the node successfully connected to the network, which happens when the node successfully connected to its neighbor that is "already" connected to the network (that's why joining order comes).

Having said that I think it is OK to mention PANA in section 7.1.  For EAP methods, EAP-TLS is used for ZigBee IP and EAP-PSK is used for Wi-SUN HAN, AFAIK.   On the other hand, I do not mind having DTLS-relay and ongoing 6tisch security work.

Regards,
Yoshihiro Ohba




-----Original Message-----
From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok
Sent: Tuesday, December 9, 2014 4:56 PM
To: Michael Richardson
Cc: roll@ietf.org; mcr@sandelman.ca; Anders Brandt
Subject: Re: [Roll] home-building-requirements section 7.1

Probably we are not going the EAP-PANA route because EAP PANA imposes an order of joining determined by the network topology.
Today, that order will not, cannot, is unlikely to, be respected by the installation protocol.

Consequently, I like to keep the uncertainty in the document.



Michael Richardson schreef op 2014-12-08 19:47:
> You ask:     > What are enrollment tools?
> 
> By this, I mean that the combination of protocols and/or provisioning 
> equipment that allows an installer to make a lightbulb join a 
> particular network.
> 
> That's why I want to know, if you are going the EAP-PANA route, that 
> one needs to know what EAP methods ought to be supported.
> 
> 
> peter van der Stok <stokcons@xs4all.nl> wrote:
>     > thanks for the encouragement.
>     > Concerning bootstrap and security in general. Many things are 
> going on and
>     > there are two approaches to this document:
>     > 1) a conservative one; restrict to what exists and is is proven 
> to work
>     > 2) leaving the doubt that exists today.
> 
>     > For the moment I like to leave the doubt, because in 5 years, 
> what is sure
>     > today will not be implemented is my conviction
> 
>     > Concerning switching on/off:
>     > That is SDO stuff; KNX , BACnet , etc... are preparing 
> additional standards.
> 
>     > What are enrollment tools?
> 
>     > Peter
> 
> 
>     > Michael Richardson schreef op 2014-11-23 22:16:
>     >> I am very pleased with the document; I hope the WG is reading 
> it, and is
>     >> also happy with it.
>     >>
>     >> In secton 7.1 you mention use of PANA to secure new nodes.
>     >> The reference seems very hesistant, and the DTLS relay is just 
> kind of
>     >> thrown in.   Can you make this recommendation more concrete? Or
> remove it.
>     >>
>     >> If it's PANA, I assume EAP is involved, and so what what EAP 
> methods should
>     >> be used?
>     >>
>     >> I think that, having read this document, I ought to be able to 
> create a
>     >> light-bulb or light switch --- I think that I can make it 
> function in the
>     >> network, but I don't think it will use the same enrollment 
> tools at all,
>     >> and
>     >> I'd sure like to change that.  I don't mind being really really 
> specific
>     >> here: I encourage it.
>     >>
>     >> I also don't know what protocol to use for turning lights 
> on/off, but I
>     >> acknowledge that is out of scope for the ROLL WG to specify.
> Perhaps there
>     >> is an informative reference I missed.
>     >>
>     >> I think that unless you have a specific way to use the DTLS 
> relay, you
>     >> should
>     >> remove the reference -- it doesn't help anyone trying to 
> implement an
>     >> interoperable device.

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll