[Roll] home-building-requirements section 7.2
Rene Struik <rstruik.ext@gmail.com> Tue, 16 December 2014 16:08 UTC
Return-Path: <rstruik.ext@gmail.com>
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 7D1701A1B75 for <roll@ietfa.amsl.com>; Tue, 16 Dec 2014 08:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 qHSmOlXujiKE for <roll@ietfa.amsl.com>; Tue, 16 Dec 2014 08:08:21 -0800 (PST)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF3E1A1B30 for <roll@ietf.org>; Tue, 16 Dec 2014 08:08:20 -0800 (PST)
Received: by mail-ig0-f176.google.com with SMTP id l13so7619345iga.3 for <roll@ietf.org>; Tue, 16 Dec 2014 08:08:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cSXu+3CLmAVdd0yiNBsibq/kximv6Zm2V77KZ6+ooq8=; b=PMz7hSWK+K9uOyd5yp4lLH/eP5RwpgEqDzV4LTK8D9K85uWhZfYND9fTyuxdHmoWNt ivi5T5rORp58OaCvkU/v8+ZDjMH4CC7ejCikmt3BANgdLYa1xqs2tI5I0ZJl/gON6a3L LBi6oZpvHwV+U0hNQDDV1a/VR6h2ezMDRhcJNGuWnTuLb6F1tJoBYq3vUmK8eHVFEsI4 U7y4eJIxPuzNwbL5ZR4WmZ23H6uZYLlpF1Pnrqgcd4FlkeUb93/s/Xz33YLAywIHFp3G xclu3GBk8PNczeZLVvrnxHfosruzLE2SO+iaHCtmp6yclrILLA68eAw8qWmjISjXIGrb d2rw==
X-Received: by 10.50.134.65 with SMTP id pi1mr3318781igb.32.1418746100011; Tue, 16 Dec 2014 08:08:20 -0800 (PST)
Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id q196sm460837ioe.5.2014.12.16.08.08.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Dec 2014 08:08:19 -0800 (PST)
Message-ID: <549058E9.7040507@gmail.com>
Date: Tue, 16 Dec 2014 11:08:09 -0500
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks <roll@ietf.org>
References: <30100.1416777372@sandelman.ca> <21fd36d565e1ecd9bd96f8f1465b3837@xs4all.nl> <8571.1418064454@sandelman.ca> <6a448d30463f53ff4a1a508b995e8c26@xs4all.nl>
In-Reply-To: <6a448d30463f53ff4a1a508b995e8c26@xs4all.nl>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/7fSZOGwsBCKSserIyD7ulkrB72g
Cc: mcr@sandelman.ca, Anders Brandt <abr@sdesigns.dk>
Subject: [Roll] home-building-requirements section 7.2
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: Tue, 16 Dec 2014 16:08:23 -0000
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 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
- [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