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