Re: [Anima-bootstrap] bootstrap purpose

peter van der Stok <stokcons@xs4all.nl> Tue, 24 May 2016 15:02 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E96E12D871 for <anima-bootstrap@ietfa.amsl.com>; Tue, 24 May 2016 08:02:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 b0LQsAQKSGlt for <anima-bootstrap@ietfa.amsl.com>; Tue, 24 May 2016 08:02:15 -0700 (PDT)
Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C959F12D875 for <anima-bootstrap@ietf.org>; Tue, 24 May 2016 08:02:09 -0700 (PDT)
Received: from webmail.xs4all.nl ([194.109.20.217]) by smtp-cloud2.xs4all.net with ESMTP id yF261s0054h15BW01F26iD; Tue, 24 May 2016 17:02:06 +0200
Received: from AMontpellier-654-1-65-44.w90-0.abo.wanadoo.fr ([90.0.40.44]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 24 May 2016 17:02:06 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 24 May 2016 17:02:06 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: "Michael Behringer (mbehring)" <mbehring@cisco.com>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <61110f7e2870402ba4ecfdaf5e909264@XCH-RCD-006.cisco.com>
References: <1913d4ecf0647ffdb77ff7f4d751218c@xs4all.nl> <61110f7e2870402ba4ecfdaf5e909264@XCH-RCD-006.cisco.com>
Message-ID: <06638ab8359175685feb61f9873799bc@xs4all.nl>
X-Sender: stokcons@xs4all.nl (ZIOlwz2U3zdSFgL5CD0fNlnihpQ47VQV)
User-Agent: XS4ALL Webmail
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima-bootstrap/VcR5ola9Wp6PUvUGW6yH3dKPWsI>
Cc: Anima-bootstrap <anima-bootstrap@ietf.org>, consultancy@vanderstok.org
Subject: Re: [Anima-bootstrap] bootstrap purpose
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2016 15:02:17 -0000

Hi Michael,

In earlier versions of the bootstrapping the purpose was to add an 
unsecured node to a secured mesh network.
Nodes on the secured network exchanged encrypted messages.
New nodes had to learn the keys to encrypt.
New nodes were not allowed to communicate with other secured nodes but 
for starting the acquisition of the keys.

Therefore the joining node needed a neighbouring proxy, because 
unsecured messages were not routed over the secured network.
I don't find the concept of secured network any more and start wondering 
why we need the neighbouring proxy.

Peter

Michael Behringer (mbehring) schreef op 2016-05-24 13:23:
> Hi Peter,
> 
> The primary purpose of draft-ietf-anima-bootstrapping-keyinfra is to
> deploy a domain specific key infrastructure. You're not mentioning
> that, I assume because it's obvious?
> 
> What a device does with that key material is outside scope of this
> document. Although, 3.5 and 3.6 go a little step in that direction.
> IMO we should keep the bootstrap of key material (current objective of
> doc) clearly separate from what to do with this key material. So we
> should probably be clearer that 3.5 are just examples.
> 
> To me, the objectives you mention:
> 
>> As far as I understood there are 2 objectives;
>> 1) a packet sent by an unauthorized node is not routed through the 
>> network
>> 2) An unauthorized node cannot interpret a packet sent by an 
>> authorized
>> node
> 
> are not the main objective of this work, but of course a security
> consideration for the bootstrap process.
> 
> Since I'm not sure I understood you fully, please let me know whether
> we're in line!
> Michael
> 
>> -----Original Message-----
>> From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On
>> Behalf Of peter van der Stok
>> Sent: 24 May 2016 09:23
>> To: Anima-bootstrap <anima-bootstrap@ietf.org>
>> Subject: [Anima-bootstrap] bootstrap purpose
>> 
>> Hi all,
>> 
>> I looked again at the keyinfra draft and did not recognize an explicit
>> description of the purpose of securing the network with the bootstrap.
>> 
>> As far as I understood there are 2 objectives;
>> 1) a packet sent by an unauthorized node is not routed through the 
>> network
>> 2) An unauthorized node cannot interpret a packet sent by an 
>> authorized
>> node
>> 
>> Neither does the text tell us how this is achieved once the bootstrap 
>> has
>> successfully concluded.
>> Do we aim at a specific protocol or do we want to leave this open?
>> 
>> --
>> Peter van der Stok
>> vanderstok consultancy
>> 
>> _______________________________________________
>> Anima-bootstrap mailing list
>> Anima-bootstrap@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima-bootstrap
> 
> _______________________________________________
> Anima-bootstrap mailing list
> Anima-bootstrap@ietf.org
> https://www.ietf.org/mailman/listinfo/anima-bootstrap