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

<yoshihiro.ohba@toshiba.co.jp> Fri, 09 January 2015 12:23 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 C402D1A8784 for <roll@ietfa.amsl.com>; Fri, 9 Jan 2015 04:23:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.402
X-Spam-Level:
X-Spam-Status: No, score=-4.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 9uho4giTaGXm for <roll@ietfa.amsl.com>; Fri, 9 Jan 2015 04:23:32 -0800 (PST)
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C7AC1A8780 for <roll@ietf.org>; Fri, 9 Jan 2015 04:23:32 -0800 (PST)
Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id t09CN3bv005545; Fri, 9 Jan 2015 21:23:03 +0900 (JST)
Received: (from root@localhost) by arc11.toshiba.co.jp id t09CN34N009009; Fri, 9 Jan 2015 21:23:03 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id XAA09007; Fri, 9 Jan 2015 21:23:03 +0900
Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id t09CN3W8023399; Fri, 9 Jan 2015 21:23:03 +0900 (JST)
Received: from tgxml050.toshiba.local by toshiba.co.jp id t09CN3Dh028788; Fri, 9 Jan 2015 21:23:03 +0900 (JST)
Received: from TGXML210.toshiba.local ([169.254.4.24]) by tgxml050.toshiba.local ([133.199.68.70]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 21:23:03 +0900
From: <yoshihiro.ohba@toshiba.co.jp>
To: <consultancy@vanderstok.org>, <sandeep.kumar@philips.com>, <roll@ietf.org>, <mcr@sandelman.ca>, <anders_Brandt@sigmadesigns.com>, <emmanuel.baccelli@inria.fr>, <robert.cragie@gridmerge.com>
Thread-Topic: RE: [Roll] home-building-requirements section 7.1
Thread-Index: AQHQKMjm9fDu+Yc+Ika2TwmYkN6Hupy3u4Qw
Date: Fri, 9 Jan 2015 12:23:02 +0000
Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B29D2DDDD@TGXML210.toshiba.local>
References: <f7fb6260cd8b6f260ac3a2091df64cab@xs4all.nl> <rkrc26a5s31jxibbjxa0udwj.1419006023304@email.android.com> <1c811f02f91bb4d3fa29ea58c90dbc4b@xs4all.nl>
In-Reply-To: <1c811f02f91bb4d3fa29ea58c90dbc4b@xs4all.nl>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
x-originating-ip: [133.196.20.219]
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/rBKZdnqn1VJPF5VxoARgbEUlkNE>
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: Fri, 09 Jan 2015 12:23:37 -0000

Hi Peter

Thank you for the new text.  I have one comment:

The following sentence is incorrect because EAP-PSK is used for Wi-SUN HAN (Home Area Network) not building control. 

"For building control EAP-PSK [RFC4764] is the most suitable approach at this moment."

Since Wi-SUN HAN is mostly specific to Japanese HAN use case, I do not mind removing the sentence.

Thanks,
Yoshihiro Ohba


-----Original Message-----
From: peter van der Stok [mailto:stokcons@xs4all.nl] 
Sent: Monday, January 5, 2015 6:21 PM
To: Kumar, Sandeep; roll@ietf.org; Michael Richardson; anders Brandt; emmanuel baccelli; ohba yoshihiro(大場 義洋 ○RDC□NSL); robert cragie
Subject: RE: RE: [Roll] home-building-requirements section 7.1

I made some new text for section 7.1. below

Suggestions for improvement will be appreciated,

Peter

<OLD 006>
At initial deployment the network is secured by consecutively securing nodes at the link layer, thus building a network of secured nodes. The Protocol for carrying Authentication for Network Access
(PANA) Relay Element [RFC6345] in conjunction with PANA [RFC5191] provides a framework for network access and delivery of common link keys.
New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. Other initiatives are likely to emerge in the context of minimal intervention configuration. At this moment it is not clear what the final most widely deployed solution will be.
</OLD 006>

<NEW>
At initial deployment the network is secured by consecutively securing nodes at the link layer, thus building a network of secured nodes. The Protocol for carrying Authentication for Network Access
(PANA) [RFC5191] with an Extensible Authentication Protocol (EAP) provides a framework for network access and delivery of common link keys. Several versions of EAP exist. ZigBee specifies the use of EAP-TLS [RFC5216]. For building control EAP-PSK [RFC4764] is the most suitable approach at this moment.

New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. They assume a partial ordering of the nodes, such that unsecured nodes are added sequentially with the restriction that a path between two secured nodes exists which passes through secured nodes only. Other initiatives are likely to emerge in the context of minimal intervention configuration.
</NEW>

> 
>  -------- Oorspronkelijke bericht --------
>  Onderwerp: RE: [Roll] home-building-requirements section 7.1
>  Datum: 2014-12-11 00:24
>  Afzender: <yoshihiro.ohba@toshiba.co.jp>
>  Ontvanger: <consultancy@vanderstok.org>rg>, <roll@ietf.org>rg>,  
> <mcr+ietf@sandelman.ca>
>  Kopie: <mcr@sandelman.ca>ca>, <abr@sdesigns.dk>
> 
>  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 [1]
> 
> -------------------------
>  The information contained in this message may be confidential and 
> legally protected under applicable law. The message is intended solely 
> for the addressee(s). If you are not the intended recipient, you are 
> hereby notified that any use, forwarding, dissemination, or 
> reproduction of this message is strictly prohibited and may be 
> unlawful. If you are not the intended recipient, please contact the 
> sender by return e-mail and destroy all copies of the original 
> message.
> 
> 
> Links:
> ------
> [1] https://www.ietf.org/mailman/listinfo/roll