Re: [Roll] home-building-requirements section 7.2
peter van der Stok <stokcons@xs4all.nl> Wed, 17 December 2014 07:40 UTC
Return-Path: <stokcons@xs4all.nl>
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 1CB511A066B for <roll@ietfa.amsl.com>; Tue, 16 Dec 2014 23:40:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 Ze3BLecMGmIy for <roll@ietfa.amsl.com>; Tue, 16 Dec 2014 23:40:03 -0800 (PST)
Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36CCF1A1A94 for <roll@ietf.org>; Tue, 16 Dec 2014 23:40:02 -0800 (PST)
Received: from roundcube.xs4all.nl ([194.109.20.208]) by smtp-cloud3.xs4all.net with ESMTP id UXfz1p0094VN29601XfzFM; Wed, 17 Dec 2014 08:39:59 +0100
Received: from [2001:983:a264:1:84e4:c65a:f9ca:92c0] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 17 Dec 2014 08:39:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Wed, 17 Dec 2014 08:39:59 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: Rene Struik <rstruik.ext@gmail.com>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <549058E9.7040507@gmail.com>
References: <30100.1416777372@sandelman.ca> <21fd36d565e1ecd9bd96f8f1465b3837@xs4all.nl> <8571.1418064454@sandelman.ca> <6a448d30463f53ff4a1a508b995e8c26@xs4all.nl> <549058E9.7040507@gmail.com>
Message-ID: <885b361c8b320419b6f81390af619654@xs4all.nl>
X-Sender: stokcons@xs4all.nl (2Ug8UZDWpbEH4Nv4oFiEsF9OpsMMQGy1)
User-Agent: XS4ALL Webmail
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/2ZjX-Op7Bf_c51uY1134crBh60A
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, mcr@sandelman.ca, Anders Brandt <abr@sdesigns.dk>
Subject: Re: [Roll] home-building-requirements section 7.2
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: consultancy@vanderstok.org, 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, 17 Dec 2014 07:40:06 -0000
Hi Rene, I think you got most requirements right. Sandeep and I will prepare an I-D for 6lo in which we will motivate the order of joining in more detail. We think that the joining operation as explained in draft-richardson-6tisch--security-6top-04 covers already many aspects. Concerning routing: I expect that separating routing protocol operation from the joining process is beneficial. e.g. Routing is started up before network is secured, or use an inefficient nd-related routing during joining, etc. Hope this helps, Greetings, Peter Rene Struik schreef op 2014-12-16 17:08: > Hi Peter: > > When contemplating some joining protocol details, I was wondering > about incremental deployment (as mentioned in clause 7.2 of your > draft). This was also one of the scenarios that came up with hallway > discussions with Sandeep Kumar during IETF-91. > > From your email below, it seems that you would like to have the join > protocol have the following features: > a) the order of joining should be orthogonal to routing protocol > topology considerations, if it all possible. > b) in particular, not all installations follow the pattern where one > has an operational network and where all non-local communications > during the join protocol not of the type {joining node - neighbor > router} are within the operational network (case in point: tree-like > structure, where network is built from tree root up onwards). > > The joining process consists of various stages, including > authentication, authorization, and configuration, where configuration > and possibly authentication and authorization may require a > communication path between joining node and a network management node > that may be multiple hops away, where the latter typically takes place > via the neighbor router. > > If the joining process is aimed to provide security services, the main > requirement on the communication path between neighbor node and > network management node(s) is "that it is there" (i.e., there is > connectivity) although there may be additional requirement to counter, > e.g., denial of service attacks on communications related to the > joining process emanating from the neighbor node. > > Do you think that designing the join process so as to minimize > dependencies between joining process and routing protocol would be > beneficial for your use case of facilitating "random" installation > process flows? (An alternative would be to intertwine routing and > joining processes, but it seems to conflict item #b above.) > > Obviously, once a node is part of the network, it should be able to > route packets (but that is not part of the join protocol itself, but > next-stage phase). > > Any insights on incremental deployment scenarios appreciated. > > Best regards, Rene > > On 12/9/2014 2:55 AM, peter van der Stok wrote: >> 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
- [Roll] home-building-requirements section 7.1 Michael Richardson
- Re: [Roll] home-building-requirements section 7.1 peter van der Stok
- Re: [Roll] home-building-requirements section 7.1 peter van der Stok
- Re: [Roll] home-building-requirements section 7.1 Michael Richardson
- Re: [Roll] home-building-requirements section 7.1 peter van der Stok
- Re: [Roll] home-building-requirements section 7.1 yoshihiro.ohba
- [Roll] home-building-requirements section 7.2 Rene Struik
- Re: [Roll] home-building-requirements section 7.2 peter van der Stok
- Re: [Roll] home-building-requirements section 7.1 peter van der Stok
- Re: [Roll] home-building-requirements section 7.1 yoshihiro.ohba
- Re: [Roll] home-building-requirements section 7.1 peter van der Stok