From nobody Sun Feb 1 10:36:56 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5671A8AAF for ; Sun, 1 Feb 2015 10:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 rdoUmCwlLzkp for ; Sun, 1 Feb 2015 10:36:53 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5831A8ACB for ; Sun, 1 Feb 2015 10:36:53 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 92C74200A3; Sun, 1 Feb 2015 13:43:43 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 26F29637F6; Sun, 1 Feb 2015 13:36:52 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 10A48637F5; Sun, 1 Feb 2015 13:36:52 -0500 (EST) From: Michael Richardson To: Duzongpeng In-Reply-To: References: <54C6E23A.2040209@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B042698@nkgeml512-mbx.china.huawei.com> <9411.1422665346@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: "anima@ietf.org" , Sheng Jiang Subject: Re: [Anima] DISCOVERY(ANY) mechanism was: RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 18:36:55 -0000 --=-=-= Content-Type: text/plain Duzongpeng wrote: > In my understanding, Sheng is talking about the number of objectives, > and you are talking about the number of respondents. That's why I asked, because I was unclear. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVM5yQ4CLcPvd0N1lAQJRfQf+OVoNk7CQ6N7EzUDR6La9yQGcUjBc7egE TJg8s4U0ye2S/W1/sA5znvfm+V0EHLi6IhYNrLtzpAiatIn/cAfBzuwi1OgOk7HL XNnY8npgo8Vs7OrHsh7Ne1wuVcZYgbYlCLCg1rbHwYv2GdvkJzkQIWxpQqbd4db5 TXkaT/JTa0UfxQsWlKDbhReOThF5NRFwTU69UB76Hpj8pdvnOFsizPJjjmv8iuOu EtXSDIQhOU1EGngDllDawNF00Ar5Oc5uO1j8OAQWrMTJ8jtzSz8FXOThgCxmccnR g5uVV55tq+YNOwtUUTya4M3rS2L75zxuChZCYmhlYuwb138Gu0thOA== =cibY -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Feb 1 11:06:22 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1C21A9081 for ; Sun, 1 Feb 2015 11:06:18 -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 g-BuRYxW1WO7 for ; Sun, 1 Feb 2015 11:06:15 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239E51A1A91 for ; Sun, 1 Feb 2015 11:06:15 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id fb1so73356057pad.10 for ; Sun, 01 Feb 2015 11:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AjaNS/ArxOKgOPE0aAQLfG+AYmHef0eFOoKtyop+phs=; b=iyYqdrXx3WS+xt569izi4chYJK9u6Tae7IHZEdxyk2EHvvpj8PZL6eFl6EdWpNoqUJ VNaw9MzAlYb+zhVxuOpScKosyep07l7QlQH6B0q+TF4XN0DZ3kecYXkXmFUyftqcpt5s uoEcEweDX0IS7nTITwO3REp+MSfx47BpKzfVp68P80kZVdG43NzDKzpbL60iiEEysK8B sAzhdyKVibtaTWV1l1MTs8hx9CdKjzMkMI2PNA69VmmCiTJjeCAP6Xeo2qoKBn2MTN79 +F3nkcEDFW9iO82p63qSMEo0P1FCvaZEDPF2j8PARUg9tysuyBfbFkXmeWmjg5cf8W83 w4vQ== X-Received: by 10.68.132.103 with SMTP id ot7mr24489539pbb.0.1422817574264; Sun, 01 Feb 2015 11:06:14 -0800 (PST) Received: from ?IPv6:2406:e007:63da:1:28cc:dc4c:9703:6781? ([2406:e007:63da:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id c9sm16640026pdm.51.2015.02.01.11.06.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Feb 2015 11:06:13 -0800 (PST) Message-ID: <54CE7920.9040002@gmail.com> Date: Mon, 02 Feb 2015 08:06:08 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Fuyu (Eleven)" References: <54C6E23A.2040209@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B04385F@nkgeml512-mbx.china.huawei.com> <54C9AFF6.4030202@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima@ietf.org" , Sheng Jiang Subject: Re: [Anima] unsolicited Response message//RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 19:06:19 -0000 On 30/01/2015 20:28, Fuyu (Eleven) wrote: > Hi Brian, > > For example, the autonomic network node sends a discovery message try to discover the objective A. The counterpart responds it and then sends an unsolicited Response message including an objective B which is related to the objective A. > The objective B and the objective A have some relationship. That relates to my idea that in such a case, there is no need to discover B separately, because A implies B. I'm not sure of the best solution. Regards Brian > > Cheers > Yu > > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Thursday, January 29, 2015 11:59 AM > To: Fuyu (Eleven); Sheng Jiang > Cc: anima@ietf.org > Subject: Re: [Anima] unsolicited Response message//RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01) > > On 29/01/2015 15:09, Fuyu (Eleven) wrote: >> Hi Sheng, >> >>> So, Brian, I guess Yu's message implied a suggestion: you may need to first describe a suitable requirement/scenario/use case. Without it, we may not be able to validate the design. >> >> Yes, a description of the requirement/scenario/use case will make sense. > > It would have to be a negotiation objective that a majority of nodes will want to negotiate, to justify an unsolicited broadcast. And I'm not sure I have an eaxmple for that. Any ideas? > > Brian > > >> Thanks >> Yu >> >> -----Original Message----- >> From: Sheng Jiang >> Sent: Wednesday, January 28, 2015 2:02 PM >> To: Fuyu (Eleven); Brian E Carpenter >> Cc: anima@ietf.org >> Subject: RE: [Anima] unsolicited Response message//RE: GDNP open >> issues (draft-carpenter-anima-gdn-protocol-01) >> >>>> For my opinion, I don't think it is reasonable to allow an >>>> unsolicited Response message in Discovery process. >>>> It may increase extra traffic and the content in unsolicited >>>> Response message may not be exactly what the counterpart want. >> >>> Hi, Yu, >> >>> When discussion unsolicited Response message, it is based on there are some mechanism on the autonomic network node has some hints to predict the counterpart wants the objective in the message. Some example, could be based on previous discovery message or a current discovery message that tries to discover an associated objective. >> >>> So, Brian, I guess Yu's message implied a suggestion: you may need to first describe a suitable requirement/scenario/use case. Without it, we may not be able to validate the design. >> >>> Best regards, >> >>> Sheng >> >>>> So it may not speed up the discovery process. Another potential >>>> issues is that the Discovery initiator may be subjected to Dos attack. >>>> But I think it is reasonable to design unsolicited Response message >>>> in Synchronization process to synchronize the status of the >>>> objective since the status of counterpart had been changed. >>> >>>> Cheers >>>> Yu >>> >>> -----Original Message----- >>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >>> Carpenter >>> Sent: Tuesday, January 27, 2015 8:56 AM >>> To: anima@ietf.org >>> Subject: [Anima] GDNP open issues >>> (draft-carpenter-anima-gdn-protocol-01) >>> >>> Hi, >>> >>> We'd like to get a sense of where to focus discussion leading up to Dallas. >>> There are a lot of open issues in the -01 draft. >>> Below I've extracted (and shortened) some that seem most important to >>> me personally. I've re-ordered them a bit too. Please send feedback >>> (maybe set the Subject of your message accordingly). >>> >>> Of course this list is not exclusive, and comments on any aspect of >>> the draft are welcome. >>> >>> o DTLS or TLS vs built-in security mechanism. The current >>> approach requires expensive asymmetric cryptographic >>> calculations for every message. (D)TLS has startup >>> overheads but cheaper crypto per message. >>> >>> o We mention convergence mechanisms and mechanisms to avoid >>> loop dependencies. These issues need more work. >>> >>> o Is it reasonable to consider that a Discovery Objective is really >>> just a set of specific Negotiation and/or Synchronization >>> Objectives? >>> >>> o Would a DISCOVERY(ANY) mechanism be useful during bootstrapping? >>> >>> o Would it be reasonable to allow an unsolicited Response message >>> with Discovery Objective content, to speed up discovery during >>> bootstrapping? >>> >>> o Should we consider a distributed or centralised DNS-like approach >>> to discovery (after the initial discovery needed for >>> bootstrapping)? >>> >>> o DoS Attack Protection needs work. Ideas welcome. >>> >>> o Alternatives to TLV format. It may be useful to provide a method >>> of carrying negotiation/synch objectives in pre-existing formats. >>> >>> o UDP vs TCP: If messages exceed a reasonable MTU, a TCP mode >>> may be necessary. >>> >>> Regards, >>> Brian >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima From nobody Sun Feb 1 11:14:10 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C42E1A9093 for ; Sun, 1 Feb 2015 11:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_102=0.6, SPF_PASS=-0.001] autolearn=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 pHt5azup2iLH for ; Sun, 1 Feb 2015 11:14:05 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0321A1A9C for ; Sun, 1 Feb 2015 11:14:03 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id fa1so73301402pad.8 for ; Sun, 01 Feb 2015 11:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=URhOhY0UjsTQc+HrXG2CS5mMoSqP9aVXtXwmvN9IVvc=; b=DzHnBA5iN65tuIonNAi63sEnurizrhnOIzrUX7E4sbENxyUznDmaBayYK8DDFsHGHg NElx7l0VEQUgQu3Dq2aGNJbtRomI+qfwP3QeKfyNIYk9crhBdHe6ueFi4lII5VNLpKvY DXAo7P3dBefKt5jj3kzgsTrd9WoTrxoVTjJwvuEJu3iKCxQfhORGTjYSp8gTOTNVWEk2 FnHPjGOweCKZhfuky7J8+PysXsoFaYafnJPGj7ckE16k1NVAuVEVxLy1yVbElLsH1yss 97cF72UkVuX0AHI9N66B04NWXMJiI+QqScYQe1KyhMrNMeToHqc/sB3xNt9oDMRSSOiC 9P0Q== X-Received: by 10.70.51.199 with SMTP id m7mr23984860pdo.111.1422818043166; Sun, 01 Feb 2015 11:14:03 -0800 (PST) Received: from ?IPv6:2406:e007:63da:1:28cc:dc4c:9703:6781? ([2406:e007:63da:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ta9sm16624392pbc.50.2015.02.01.11.13.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Feb 2015 11:14:02 -0800 (PST) Message-ID: <54CE7AF5.3080503@gmail.com> Date: Mon, 02 Feb 2015 08:13:57 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Duzongpeng , Michael Richardson , "anima@ietf.org" References: <54C6E23A.2040209@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B042698@nkgeml512-mbx.china.huawei.com> <9411.1422665346@sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Sheng Jiang Subject: Re: [Anima] DISCOVERY(ANY) mechanism was: RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 19:14:08 -0000 On 31/01/2015 16:34, Duzongpeng wrote: > Hi Michael: > > In my understanding, Sheng is talking about the number of objectives, and you are talking about the number of respondents. In a sense, it doen't matter, because the total response traffic generated will be proportional to the product of the two. > > Some other comments here. > The objectives needed to be broadcasted can be further classified. > 1. in size, maybe some key elements are short and do not occupied too much bandwidth, but others not In discovery, I think all the responses will be short. > 2. in frequency, maybe some objectives are needed to be updated frequently, but others not For synchronization, that's true, but we would expect to use some algorithm such as Trickle to optimize the rate of traffic. For discovery, we do need to decide how long responses are cached. Brian > 3. in importance, it is impossible to always broadcast everything, and some essential objectives should be identified > ... > > Best regards, > > Zongpeng Du > > > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: Saturday, January 31, 2015 8:49 AM > To: anima@ietf.org > Subject: Re: [Anima] DISCOVERY(ANY) mechanism was: RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01) > > > Sheng Jiang wrote: > >> o Would a DISCOVERY(ANY) mechanism be useful during bootstrapping? > > > This depends on a) how many are ANY, b) how many counterpart may be > > discovered. > > > If ANY is less than twenty or thirty, it may not be a very big > > impact. But if ANY is more than a hundred, it may be too much for both > > the autonomic network and the initiated node. My guess is we could not > > limit how many objectives may be developed in the future. > > I'm confused in this thread if the cardinality we are talking about is the number of objectives,or the number of respondants. > > If we are talking about how many peers there might be, then I wonder how many links are actually natively multicast. We don't have coax and ethernet hubs anymore, so a device (L3-aware L2-switch) is always involved in multicasting among a network. If that device speaks GNDP, then the LAN only has two ends. > > While there likely are lots of L2 switches that won't speak GNDP, I would think that where this is first deployed, in operator and backbone DC > networks, that this won't be the case. Even modern wifi > is a star-configuration with MIMO antenna, etc. > > (this scenario is not dissimilar from CDP/LLDP) > > > > -- > Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- > > > > From nobody Sun Feb 1 18:04:51 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0681A1A8952 for ; Sun, 1 Feb 2015 18:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_102=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 kOGTDNmPL8Uf for ; Sun, 1 Feb 2015 18:04:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7C01A871F for ; Sun, 1 Feb 2015 18:04:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOQ77584; Mon, 02 Feb 2015 02:04:45 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Feb 2015 02:04:43 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 2 Feb 2015 10:04:33 +0800 From: Sheng Jiang To: Brian E Carpenter , Duzongpeng , Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] DISCOVERY(ANY) mechanism was: RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01) Thread-Index: AQHQOgMykO0t2KWCikSq2y+LXudAzJzY5UsAgAAuTACAApi6gIAA9aEw Date: Mon, 2 Feb 2015 02:04:33 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923B0453AD@nkgeml512-mbx.china.huawei.com> References: <54C6E23A.2040209@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B042698@nkgeml512-mbx.china.huawei.com> <9411.1422665346@sandelman.ca> <54CE7AF5.3080503@gmail.com> In-Reply-To: <54CE7AF5.3080503@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] DISCOVERY(ANY) mechanism was: RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 02:04:49 -0000 Pj4gICAgIEluIG15IHVuZGVyc3RhbmRpbmcsIFNoZW5nIGlzIHRhbGtpbmcgYWJvdXQgdGhlIG51 bWJlciBvZiBvYmplY3RpdmVzLA0KPmFuZCB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIG51bWJl ciBvZiByZXNwb25kZW50cy4NCj4NCj5JbiBhIHNlbnNlLCBpdCBkb2VuJ3QgbWF0dGVyLCBiZWNh dXNlIHRoZSB0b3RhbCByZXNwb25zZSB0cmFmZmljIGdlbmVyYXRlZA0KPndpbGwgYmUgcHJvcG9y dGlvbmFsIHRvIHRoZSBwcm9kdWN0IG9mIHRoZSB0d28uDQoNCkV4YWN0bHkhIFRoYXQncyB3aGF0 IEkgYW0gdGFsa2luZyBhYm91dC4gVGhlIHRvdGFsIHJlc3BvbnNlIGlzIGRlY2lkZWQgYnkgYm90 aCB0aGUgbnVtYmVyIG9mIG9iamVjdGl2ZXMgYW5kIHRoZSBudW1iZXIgb2YgcmVzcG9uZGVudHMu IFNvLCBldmVuIHRoZSB0b3BpYyBpcyBtYWlubHkgaW5pdGlhdGVkIGJ5IHRoZSBudW1iZXIgb2Yg b2JqZWN0aXZlcywgdGhlIGRpc2N1c3Npb24gY2Fubm90IG9taXQgdGhlIG51bWJlciBvZiByZXNw b25kZW50cy4gVGhlIGFtYml0aW9uIG9mIEdETlAgaXMgdG8gYmUgYWJsZSB0byBkbyBMMyBkaXNj b3ZlcnkuIFNvLCBpbiBhIGxhcmdlIHNjYWxlIGF1dG9ub21pYyBuZXR3b3JrcywgaWYgdGhlcmUg aXMgbm8gYXV0b25vbWljIHBhcnRpdGlvbiBtZWNoYW5pc21zIGRlcGxveWVkLCB0aGVyZSBtYXkg YmUgaHVuZHJlZHMgY291bnRlcnBhcnRzLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj4+ DQo+PiAgIAlTb21lIG90aGVyIGNvbW1lbnRzIGhlcmUuDQo+PiBUaGUgb2JqZWN0aXZlcyBuZWVk ZWQgdG8gYmUgYnJvYWRjYXN0ZWQgY2FuIGJlIGZ1cnRoZXIgY2xhc3NpZmllZC4NCj4+IAkxLiBp biBzaXplLCBtYXliZSBzb21lIGtleSBlbGVtZW50cyBhcmUgc2hvcnQgYW5kIGRvIG5vdCBvY2N1 cGllZCB0b28NCj5tdWNoIGJhbmR3aWR0aCwgYnV0IG90aGVycyBub3QNCj4NCj5JbiBkaXNjb3Zl cnksIEkgdGhpbmsgYWxsIHRoZSByZXNwb25zZXMgd2lsbCBiZSBzaG9ydC4NCj4NCj4+IAkyLiBp biBmcmVxdWVuY3ksIG1heWJlIHNvbWUgb2JqZWN0aXZlcyBhcmUgbmVlZGVkIHRvIGJlIHVwZGF0 ZWQNCj5mcmVxdWVudGx5LCBidXQgb3RoZXJzIG5vdA0KPg0KPkZvciBzeW5jaHJvbml6YXRpb24s IHRoYXQncyB0cnVlLCBidXQgd2Ugd291bGQgZXhwZWN0IHRvIHVzZSBzb21lIGFsZ29yaXRobQ0K PnN1Y2ggYXMgVHJpY2tsZSB0byBvcHRpbWl6ZSB0aGUgcmF0ZSBvZiB0cmFmZmljLiBGb3IgZGlz Y292ZXJ5LCB3ZSBkbyBuZWVkDQo+dG8gZGVjaWRlIGhvdyBsb25nIHJlc3BvbnNlcyBhcmUgY2Fj aGVkLg0KPg0KPiAgIEJyaWFuDQo+DQo+PiAJMy4gaW4gaW1wb3J0YW5jZSwgaXQgaXMgaW1wb3Nz aWJsZSB0byBhbHdheXMgYnJvYWRjYXN0IGV2ZXJ5dGhpbmcsIGFuZA0KPnNvbWUgZXNzZW50aWFs IG9iamVjdGl2ZXMgc2hvdWxkIGJlIGlkZW50aWZpZWQNCj4+IAkuLi4NCj4+DQo+PiBCZXN0IHJl Z2FyZHMsDQo+Pg0KPj4gWm9uZ3BlbmcgRHUNCj4+DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+IEZyb206IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE1pY2hhZWwNCj5SaWNoYXJkc29uDQo+PiBTZW50OiBTYXR1cmRheSwgSmFu dWFyeSAzMSwgMjAxNSA4OjQ5IEFNDQo+PiBUbzogYW5pbWFAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6 IFJlOiBbQW5pbWFdIERJU0NPVkVSWShBTlkpIG1lY2hhbmlzbSB3YXM6IFJFOiBHRE5QIG9wZW4N Cj5pc3N1ZXMgKGRyYWZ0LWNhcnBlbnRlci1hbmltYS1nZG4tcHJvdG9jb2wtMDEpDQo+Pg0KPj4N Cj4+IFNoZW5nIEppYW5nIDxqaWFuZ3NoZW5nQGh1YXdlaS5jb20+IHdyb3RlOg0KPj4gICAgID4+ IG8gIFdvdWxkIGEgRElTQ09WRVJZKEFOWSkgbWVjaGFuaXNtIGJlIHVzZWZ1bCBkdXJpbmcNCj5i b290c3RyYXBwaW5nPw0KPj4NCj4+ICAgICA+IFRoaXMgZGVwZW5kcyBvbiBhKSBob3cgbWFueSBh cmUgQU5ZLCBiKSBob3cgbWFueSBjb3VudGVycGFydA0KPm1heSBiZQ0KPj4gICAgID4gZGlzY292 ZXJlZC4NCj4+DQo+PiAgICAgPiBJZiBBTlkgaXMgbGVzcyB0aGFuIHR3ZW50eSBvciB0aGlydHks IGl0IG1heSBub3QgYmUgYSB2ZXJ5IGJpZw0KPj4gICAgID4gaW1wYWN0LiBCdXQgaWYgQU5ZIGlz IG1vcmUgdGhhbiBhIGh1bmRyZWQsIGl0IG1heSBiZSB0b28gbXVjaCBmb3INCj5ib3RoDQo+PiAg ICAgPiB0aGUgYXV0b25vbWljIG5ldHdvcmsgYW5kIHRoZSBpbml0aWF0ZWQgbm9kZS4gTXkgZ3Vl c3MgaXMgd2UgY291bGQNCj5ub3QNCj4+ICAgICA+IGxpbWl0IGhvdyBtYW55IG9iamVjdGl2ZXMg bWF5IGJlIGRldmVsb3BlZCBpbiB0aGUgZnV0dXJlLg0KPj4NCj4+IEknbSBjb25mdXNlZCBpbiB0 aGlzIHRocmVhZCBpZiB0aGUgY2FyZGluYWxpdHkgd2UgYXJlIHRhbGtpbmcgYWJvdXQgaXMgdGhl DQo+bnVtYmVyIG9mIG9iamVjdGl2ZXMsb3IgdGhlIG51bWJlciBvZiByZXNwb25kYW50cy4NCj4+ DQo+PiBJZiB3ZSBhcmUgdGFsa2luZyBhYm91dCBob3cgbWFueSBwZWVycyB0aGVyZSBtaWdodCBi ZSwgdGhlbiBJIHdvbmRlciBob3cNCj5tYW55IGxpbmtzIGFyZSBhY3R1YWxseSBuYXRpdmVseSBt dWx0aWNhc3QuICBXZSBkb24ndCBoYXZlIGNvYXggYW5kIGV0aGVybmV0DQo+aHVicyBhbnltb3Jl LCBzbyBhIGRldmljZSAoTDMtYXdhcmUgTDItc3dpdGNoKSBpcyBhbHdheXMgaW52b2x2ZWQgaW4N Cj5tdWx0aWNhc3RpbmcgYW1vbmcgYSBuZXR3b3JrLiAgSWYgdGhhdCBkZXZpY2Ugc3BlYWtzIEdO RFAsIHRoZW4gdGhlIExBTg0KPm9ubHkgaGFzIHR3byBlbmRzLg0KPj4NCj4+IFdoaWxlIHRoZXJl IGxpa2VseSBhcmUgbG90cyBvZiBMMiBzd2l0Y2hlcyB0aGF0IHdvbid0IHNwZWFrIEdORFAsIEkg d291bGQNCj50aGluayB0aGF0IHdoZXJlIHRoaXMgaXMgZmlyc3QgZGVwbG95ZWQsIGluIG9wZXJh dG9yIGFuZCBiYWNrYm9uZSBEQw0KPj4gbmV0d29ya3MsIHRoYXQgdGhpcyB3b24ndCBiZSB0aGUg Y2FzZS4gICBFdmVuIG1vZGVybiB3aWZpDQo+PiBpcyBhIHN0YXItY29uZmlndXJhdGlvbiB3aXRo IE1JTU8gYW50ZW5uYSwgZXRjLg0KPj4NCj4+ICh0aGlzIHNjZW5hcmlvIGlzIG5vdCBkaXNzaW1p bGFyIGZyb20gQ0RQL0xMRFApDQo+Pg0KPj4NCj4+DQo+PiAtLQ0KPj4gTWljaGFlbCBSaWNoYXJk c29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+LCBTYW5kZWxtYW4gU29mdHdhcmUNCj5Xb3JrcyAg LT0gSVB2NiBJb1QgY29uc3VsdGluZyA9LQ0KPj4NCj4+DQo+Pg0KPj4NCg== From nobody Sun Feb 1 22:32:51 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2EC1A9237 for ; Sun, 1 Feb 2015 22:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 iZgnLvbSx8T3 for ; Sun, 1 Feb 2015 22:32:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67011A1B94 for ; Sun, 1 Feb 2015 22:32:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOQ93451; Mon, 02 Feb 2015 06:32:44 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Feb 2015 06:32:43 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 2 Feb 2015 14:32:36 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Call for agenda ANIMA @ IETF92 Thread-Index: AdA+sgQiAayWyIJ1SBKW5B+Vws1dug== Date: Mon, 2 Feb 2015 06:32:35 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923B0455C9@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "anima-chairs@tools.ietf.org" Subject: [Anima] Call for agenda ANIMA @ IETF92 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 06:32:50 -0000 SGksIGFsbCwNCg0KQWZ0ZXIgbXkgcHJlLWNhbGwtZm9yLWFnZW5kYSAiQU5JTUEgQCBJRVRGOTIi IHR3byB3ZWVrcyBhZ28sIHdlIGhhdmUgcmVjZWl2ZWQgc2V2ZXJhbCBhcHBsaWNhdGlvbnMgZm9y IGF1dG9ub21pYyBuZXR3b3JrIHRvcGljcyBiZXNpZGVzIHRoZSBXRyBtaWxlc3RvbmVzLiBTbywg d2UgaGF2ZSBjb25zdWx0ZWQgb3VyIHJlc3BvbnNpYmxlIEFEIGFuZCByZXF1ZXN0ZWQgdHdvIHNl c3Npb25zIChhIDItaG91ciBzZXNzaW9uIGZvciBXRyBtaWxlc3RvbmVzLCBhbm90aGVyIDEuNS1o b3VyIHNlc3Npb24gZm9yIG5vbiBXRyBtaWxlc3RvbmUgdG9waWNzKSBmb3Igb3VyIEFOSU1BIFdv cmtpbmcgR3JvdXAgbWVldGluZyBhdCBJRVRGOTIuDQoNClRoZSBjb25mbGljdCBsaXN0IGlzIGFz IGZvbGxvd3M6DQogICBGaXJzdCBQcmlvcml0eToJaG9tZW5ldCBuZXRjb25mIGRoYyB2Nm9wcw0K ICAgU2Vjb25kIFByaW9yaXR5OglvcHNhcmVhIDZtYW4gc29mdHdpcmUgbm1yZw0KICAgVGhpcmQg UHJpb3JpdHk6CWNmcmcgc2FhZyA2dGlzY2gNCg0KV2UgaGF2ZSBhbHNvIHJlcXVlc3RlZCBhIE1l ZXRlY2hvIHN1cHBvcnQgaW4gdGhlIHJvb20gaW4gY2FzZSBhbnlvbmUgaXMgcmVtb3RlIC8gbmVl ZCB0byBwcmVzZW50IHJlbW90ZWx5Lg0KDQpQbGVhc2Ugc2VuZCB1cyAoYW5pbWEtY2hhaXJzQHRv b2xzLmlldGYub3JnKSByZXF1ZXN0cyBmb3IgdGltZSBzbG90IGFuZCBpbmNsdWRlOg0KDQogICBO YW1lIG9mIHRpbWUgc2xvdDoNCiAgIE5hbWUgb2YgZHJhZnQocykgKHByZWZlcnJlZCBidXQgbm90 IG5lY2Vzc2FyeSk6DQogICBUaW1lIHJlcXVlc3RlZDoNCiAgIFByZXNlbnRlciBuYW1lKHMpOg0K ICAgQnJpZWYgZGVzY3JpcHRpb24gb2Ygd2hhdCBpc3N1ZXMgbmVlZCBkaXNjdXNzaW5nIGFuZCB3 aGF0IHlvdSBob3BlIHRvIGFjY29tcGxpc2ggYnkgcHJlc2VudGluZzoNCg0KQWxzbywgcHJlc2Vu dGVycyBhbmQgZHJhZnQgYXV0aG9ycyBwbGVhc2UgaW52b2tlIGFjdGl2ZSBkaXNjdXNzaW9ucyBp biB0aGUgQU5JTUEgbGlzdC4gV2UgaGF2ZSB2ZXJ5IGxpbWl0ZWQgdGltZSBmb3IgZWFjaCB0b3Bp YyBpbiB0aGUgZmFjZS10by1mYWNlIG1lZXRpbmcuIE1haWwgbGlzdCBpcyBhIHZlcnkgZ29vZCBw bGFjZSB0byBhdHRyYWN0IGF1ZGllbmNlcycgYXR0ZW50aW9uIGFuZCBnZXQgdGhlbSB0byBhY3R1 YWxseSBrbm93IHlvdXIgdG9waWMsIGFsc28gZGV0YWlscywgYmVmb3JlIHRoZSBtZWV0aW5nLiBT bywgd2UgY291bGQgaGF2ZSB0aGUgYmVzdCB1c2Ugb2Ygb3VyIG1lZXRpbmcgdGltZS4gV2UgY291 bGQgbm90IG1ha2Ugc2lnbmlmaWNhbnQgcHJvZ3Jlc3Mgd2l0aCBvbmx5IHRoZSBmYWNlLXRvLWZh Y2UgbWVldGluZy4gTWFpbCBsaXN0IGlzIHRoZSBvZmZpY2lhbCB3b3JrIHBsYWNlIGluIHRoZSBJ RVRGLg0KDQpBZ2FpbiwgYXMgYSBlbXBoYXNpcywgdGhlIEFOSU1BIFdHIGlzIG9wZW4gZm9yIHRv cGljcy9kcmFmdHMgdGhhdCBhcmUgcmVsZXZhbnQgdG8gYXV0b25vbWljIG5ldHdvcmtpbmcuIEJl c2lkZSB0aGUgY3VycmVudCBtaWxlc3RvbmVzLCBvdGhlciBhdXRvbm9taWMgaW5mcmFzdHJ1Y3R1 cmUgY29tcG9uZW50cywgcG9saWN5IGludGVudHMsIHVzZSBjYXNlcyBvciBhdXRvbm9taWMgDQpz ZXJ2aWNlIGFnZW50cyBhcmUgc3Ryb25nbHkgZW5jb3VyYWdlZCwgYXMgaW5kaXZpZHVhbCBzdWJt aXNzaW9ucy4gVGhleSBjb3VsZCBiZSBkaXNjdXNzZWQgYXMgcG90ZW50aWFsIHJlY2hhcnRlciBj b250ZW50cyBpbiB0aGUgZnV0dXJlLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nIGFuZCBUb2Vy bGVzcw0K From nobody Mon Feb 2 00:13:44 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1CE1A002A; Mon, 2 Feb 2015 00:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Limt7hPqpqpp; Mon, 2 Feb 2015 00:13:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB831A000B; Mon, 2 Feb 2015 00:13:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRZ36103; Mon, 02 Feb 2015 08:13:33 +0000 (GMT) Received: from SZXEML433-HUB.china.huawei.com (10.82.67.210) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Feb 2015 08:13:31 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.208]) by szxeml433-hub.china.huawei.com ([10.82.67.210]) with mapi id 14.03.0158.001; Mon, 2 Feb 2015 16:13:19 +0800 From: "Hedanping (Ana)" To: Michael Richardson Thread-Topic: [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things Thread-Index: AQHQM5RsrNIDfMmvyk2+BhTY9xEGY5zY7gyAgAQCtnA= Date: Mon, 2 Feb 2015 08:13:19 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> In-Reply-To: <6426.1422664463@sandelman.ca> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.94.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "anima@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 08:13:41 -0000 Hi Michael, Thank you for the interest and the questions are illuminating. Please see m= y reply inline. > I have added a number of CCs, I think that this fits into ANIMA best. >=20 > Hedanping (Ana) wrote: > > A new draft is submitted, it's about the security bootstrapping > > architecture and methods for IoT networks that implement IETF > protocols > > (e.g. 6LoWPAN, 6lo, RPL, AODV, DSR) over IEEE 802.15.4. > > Two types of bootstrapping methods are developed: network level > > bootstrapping and joining device level bootstrapping >=20 > > The link is: > > http://tools.ietf.org/html/draft-he-iot-security-bootstrapping-00 >=20 > I read the document with great interest. > I found that you explained the incremental boot-strapping process quite = well, > and nobody has clearly articulated the process yet. People have just as= sumed > that everyone knows this process, but really it needs to get written dow= n, so I > thank you for doing that. Thank you for the praise. As it is the initial version, more discussions an= d comments are needed to make it better. >=20 > Given that: >=20 > Because IEEE 802.15.4 maximum payload size is 128 Bytes, a standard > security bootstrapping protocol should be light-weight with low > complexity. The protocol must allow for commissioning of devices >=20 > I was surprised that the draft then suggested EAP with PANA as a transpo= rt: >=20 > If EAP is used, PANA can be used to relay the authentication message > from configured FFDs to 6LBR. If the validation is successful, the > IP address and network key are generated and delivered to the FFD. >=20 > But, EAP-TLS with PANA is exactly what the Zigbee IP specification has s= pecified. > Do you envision any changes from that specification? Zigbee IP specification was developed to enable IP address for Zigbee appli= cation, thus the protocol stack are built on IETF's standards, including EA= P-TLS.=20 As discussed in many working groups, TLS might result in a significant amou= nt of retransmissions due to unreliable communication capability of the net= work and device, thus energy will be consumed fast. I think EAP over DTLS /profiled DTLS could be a good option. > A minority of people had prefered this mechanism for 6tisch-security, bu= t > none stepped forward to write up that mechanism. Perhaps this draft co= uld > fulfill that need? Yes, we should describe more clearly on this mechanism, and maybe this draf= t is a right place. It would be great if folks in the mailing list make com= ments and contribution on this technical point.=20 > You write that the IP address would be generated; usually that occurs vi= a > distribution of PIOs via ND (router-adveristments) or RPL. Were you goi= ng to > suggest something else here? According to my knowledge, IP address can be generated once a device is aut= henticated to network access, afterwards, other further protocols can use I= P to communicate.=20 Besides, PANA needs IP as well. The incremental bootstrapping takes advanta= ge of such IP address generation mechanism, so that PANA can be run without= any problem. =20 > From the ANIMA and 6tisch-security point of view, my view is that this i= s all > about the choice of certificates for the TLS setup. Do you have any vie= w on > how that might work? For unconstrained environment, I agree with you. But when it comes to const= rained device and constrained network communication, TLS might not be a goo= d choice as mentioned before. Certificate is not a good choice either due t= o the high cost.=20 I would like to say: it is about the choice of credential type for secure c= hannel setup. The good candidates of credential types are Raw public key, P= hysical Unclonable Function (PUF). >=20 > The 6tisch-security bootstrap process aims to create a > YANG/CBOR-over-CoAP-over-DTLS session between a Join Coordinator and the > Joining Node: over that management link, security (and timeslot scheduli= ng) > would be provisioned. CoAP-DTLS coincides with my idea. Yang sounds like at a higher level, but I think EAP is actually the mechani= sm running behind ^_^ Regards, Ana From nobody Mon Feb 2 15:50:34 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50701A1B6C for ; Mon, 2 Feb 2015 15:50:25 -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 DArijtp9Pon8 for ; Mon, 2 Feb 2015 15:50:19 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B377B1A896F for ; Mon, 2 Feb 2015 15:48:52 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id bj1so88571106pad.1 for ; Mon, 02 Feb 2015 15:48:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=lZBAjBbuIo724R4DlgeUft8zxBQLFSp91znuO5eKQhQ=; b=bI8aqRn9VG0lnCtLv9w3e7p6l/UFLassc1Lg1PCib6mHjaOwTdYwNPtyNXXT/W182e 3y0evZ+flD21Bdbqulpo005kQf0ImvpSpRTMOvbGF7hpaXwCTvvc5h0qcnaWrXZHYtOx gAN7frUCgjwDr9yiSBdiKk5XIZgTw3Vo9VV11RVCG627wUK+mddKWtYrghyZikEQNHO3 wXXgk0JwXD/fFnG/XxIOfdXZKXRe9ICjMAd0/ExwIJaF4jN2Tgd9FsB1TNaUA661uV6h OHUGkW9hrirtnz8eLKpoLs1uQXFJDNSGdiY9DM8NCQ48NHQ3pq+NiolBJw/FU5efJmN8 we9A== X-Received: by 10.70.46.98 with SMTP id u2mr33636434pdm.26.1422920932018; Mon, 02 Feb 2015 15:48:52 -0800 (PST) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id yd9sm172904pab.30.2015.02.02.15.48.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Feb 2015 15:48:50 -0800 (PST) Message-ID: <54D00CE0.9070204@gmail.com> Date: Tue, 03 Feb 2015 12:48:48 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Anima WG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] About the Anima trust model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 23:50:27 -0000 Hi, I've just been reading about the DNCP trust model at http://tools.ietf.org/html/draft-ietf-homenet-dncp-00#section-9.3 My question for Anima is this: do we want something as flexible as that, or do we want a simpler and more rigid approach, with fewer options that need to be stated in a profile? Note, I don't want to discuss the details of DNCP here; that belongs in homenet. I'm just asking what general approach we should take in Anima. Regards Brian From nobody Mon Feb 2 19:49:46 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733B21A1DBE for ; Mon, 2 Feb 2015 19:49:44 -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 CPx--O8xA13o for ; Mon, 2 Feb 2015 19:49:43 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3799A1A1DE2 for ; Mon, 2 Feb 2015 19:49:43 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id ey11so90776482pad.7 for ; Mon, 02 Feb 2015 19:49:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/NITPCmoZN3enr6rLNSdHOWNiW4WTWwkKhtsJkr2z30=; b=DkUBWAvA6C9OPbV6q85P1UXCqaAp1tIQ7G8bqZdRWEXkENoPQg/rff27kCiBeS5eIg q8GxJcrpRiAk95DDdq9lTymgC0el6gHCTeM6n6u7hXnWj8/9riLE6VcBBAG57J7KueTi n+NrrruOKBpJyDnu5mfVBW/w0QSXLg0PhZWst/lNal/rXa3PyVAwirmVdMFmOcgCfHEp k2M/ceAmB9OZ/rlHJ696ihlK+nXrD8KLUfwRmZJfqrZoSAsRCLduYgom+QmvKKw0Tmbn OP0GuifFPMmYgpM7t6mAVvpdG91/ubK4tmOU/swEbRHZraJkXwJyxuDBY5EeKm5+3WVZ VvqQ== X-Received: by 10.66.119.193 with SMTP id kw1mr35225819pab.64.1422935382525; Mon, 02 Feb 2015 19:49:42 -0800 (PST) Received: from ?IPv6:2406:e007:7a07:1:28cc:dc4c:9703:6781? ([2406:e007:7a07:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id do2sm514224pbc.23.2015.02.02.19.49.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Feb 2015 19:49:41 -0800 (PST) Message-ID: <54D04554.1040703@gmail.com> Date: Tue, 03 Feb 2015 16:49:40 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sheng Jiang References: <5D36713D8A4E7348A7E10DF7437A4B923B0455C9@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923B0455C9@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima@ietf.org" , "anima-chairs@tools.ietf.org" Subject: Re: [Anima] Call for agenda ANIMA @ IETF92 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 03:49:44 -0000 Name of time slot: GDNP Name of draft(s): draft-carpenter-anima-gdn-protocol Time requested: 20 min + discussion Presenter name(s): Brian Carpenter Brief description of what issues need discussing and what you hope to accomplish by presenting: Open issues listed in the draft (prioritised to fit the time). We want to resolve as many as possible, and understand the WG opinion of the general direction described in the draft. Brian + Bing From nobody Tue Feb 3 15:49:40 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB8A1A00F9; Tue, 3 Feb 2015 03:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 2hnmQlKun9c6; Tue, 3 Feb 2015 03:59:45 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7BC1A8987; Tue, 3 Feb 2015 03:59:44 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t13BwSLI009787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Feb 2015 13:58:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t13BwRf0006160; Tue, 3 Feb 2015 13:58:27 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21712.47075.522836.495543@fireball.kivinen.iki.fi> Date: Tue, 3 Feb 2015 13:58:27 +0200 From: Tero Kivinen To: "Hedanping \(Ana\)" In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 9 min Archived-At: X-Mailman-Approved-At: Tue, 03 Feb 2015 15:49:37 -0800 Cc: Michael Richardson , "anima@ietf.org" , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Anima] [6tisch-security] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 11:59:47 -0000 Hedanping (Ana) writes: > > Because IEEE 802.15.4 maximum payload size is 128 Bytes, > > a standard security bootstrapping protocol should be > > light-weight with low complexity. The protocol must allow > > for commissioning of devices I was surprised that the > > draft then suggested EAP with PANA as a transport: If EAP > > is used, PANA can be used to relay the authentication > > message from configured FFDs to 6LBR. If the validation > > is successful, the IP address and network key are > > generated and delivered to the FFD. But, EAP-TLS with > > PANA is exactly what the Zigbee IP specification has > > specified. Do you envision any changes from that > > specification? > > Zigbee IP specification was developed to enable IP address for > Zigbee application, thus the protocol stack are built on IETF's > standards, including EAP-TLS. > As discussed in many working groups, TLS might result in a > significant amount of retransmissions due to unreliable > communication capability of the network and device, thus energy will > be consumed fast. > I think EAP over DTLS /profiled DTLS could be a good option. There is work going on in the IEEE 802.15.9 task group which specifies the key management for 802.15.4, or more specifically it will specify a way to transport existing key management protocols over the 802.15.4 frames. This would allow running for example IKEv2 + EAP over the 802.15.4 and generate keys for 802.15.4 security and then protect all messages between the two nodes. In normal case this would be run even before the IEEE 802.15.4 assocation is done, i.e. immediately after the beacon before doing the association, and would allow protecting the association process too. For this uses the IKEv2 + EAP would be most likely quite good, i.e. the IKEv2 frames would be exchange between the peer joining the network and its next hop router, and inside those IKEv2 frames there would be EAP messages, which are then relayed to the AAA server (trust center TC in draft-he-iot-security-bootstrapping-00) for actual authentication. The 802.15.9 is now in letter ballot phase in IEEE, meaning we should be finished quite soon. One issue there is that, during the 802.15.9 work we noticed some issues with 802.15.4 base specifciation which have been worked on in the 802.15.4 maintenance revision process, and we need to wait for it to finish before 802.15.9 can finish... Most likely both of those will finish before the end of year. -- kivinen@iki.fi From nobody Tue Feb 3 21:56:08 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE991A1DBD for ; Tue, 3 Feb 2015 21:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 6tCjBub0u4dm for ; Tue, 3 Feb 2015 21:56:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398AB1A1BF8 for ; Tue, 3 Feb 2015 21:56:04 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSB56798; Wed, 04 Feb 2015 05:56:02 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Feb 2015 05:56:00 +0000 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.222]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 4 Feb 2015 13:55:55 +0800 From: "Fuyu (Eleven)" To: "anima@ietf.org" Thread-Topic: Comments for draft-pritikin-anima-bootstrapping-keyinfra-00 Thread-Index: AdBAPzoZSQgjkIgVRjmj/d4Olk1g3Q== Date: Wed, 4 Feb 2015 05:55:55 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.184] Content-Type: multipart/alternative; boundary="_000_EF6A204047BD994A860EE26D5F23BF5881562D5Ankgeml505mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Comments for draft-pritikin-anima-bootstrapping-keyinfra-00 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 05:56:07 -0000 --_000_EF6A204047BD994A860EE26D5F23BF5881562D5Ankgeml505mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpTb21lIGNvbW1lbnRzIGZvciBkcmFmdC1wcml0aWtpbi1hbmltYS1ib290c3Ry YXBwaW5nLWtleWluZnJhLTAwDQoNCg0KMS4gICAgICAgQWJzdHJhY3Q6IHRoZSBsYXN0IHNlbnRl bmNlDQo+V2hlbiBhIHZlbmRvciBjbG91ZCBzZXJ2aWNlIGlzIHByb3ZpZGVkIGRldmljZXMgY2Fu IGJlIGZvcmNlZCB0byBqb2luIG9ubHkgc3BlY2lmaWMgZG9tYWlucyBidXQgZm9yIGNvbnRyYWlu ZWQgZW52aXJvbm1lbnRzIHdlIGRlc2NyaWJlIGEgdmFyaWV0eSBvZiBvcHRpb25zIHRoYXQgYWxs b3cgYm9vdHN0cmFwcGluZyB0byBwcm9jZWVkLqGxDQoNCldoYXQgZG9lcyB0aGUgobEgY29udHJh aW5lZKGxIG1lYW4/IEEgdHlwbz8NCg0KDQoyLiAgICAgICBTZWN0aW9uIDEgaW50cm9kdWN0aW9u IDogdGhlIGxhc3Qgc2VudGVuY2UNCj5TdWZmaWNpZW50IGFnaWxpdHkgdG8gc3VwcG9ydCBib290 c3RyYXBwaW5nIGFsdGVybmF0aXZlIGtleSBpbmZyYXN0cnVjdHVyZXMgKHN1Y2ggYXMgc3ltbWV0 cmljIGtleSBzb2x1dGlvbnMpIGlzIGNvbnNpZGVyZWQgYWx0aG91Z2ggbm8gc3VjaCBrZXkgaW5m cmFzdHJ1Y3R1cmUgaXMgZGVzY3JpYmVkDQoNCg0KRG9lcyBpdCBkZXNjcmliZSB0aGUgYWx0ZXJu YXRpdmUga2V5IGluZnJhc3RydWN0dXJlcyBpbiB0aGlzIGRyYWZ0PyBGb3IgZXhhbXBsZSwgaG93 IHRoZSBzeW1tZXRyaWMga2V5IHNvbHV0aW9ucyB3b3JrPyAgSWYgbm90LCBJIHRoaW5rIGEgYnJp ZWYgZGVzY3JpcHRpb24gaXMgbmVlZGVkLg0KDQoNCjMuICAgICAgIFNlY3Rpb24gMjogID4gRG9t YWluIElkZW50aXR5OiAgKEEgc3RyaW5nIHZhbHVlIGJvdW5kIHRvIHRoZSBEb21haW4gQ0EncyBz ZWxmIHNpZ25lZCByb290IGNlcnRpZmljYXRlIHN1YmplY3QgYW5kIGlzc3VlciBmaWVsZHMgaXMg b2Z0ZW4gY29sbG9xdWFsbHkgdXNlZCBhcyBhIGh1bWFuaXplZCBpZGVudGl0eSB2YWx1ZSBidXQg ZHVyaW5nIHByb3RvY29sIGRpc2N1c3Npb25zIHRoZSBtb3JlIGV4YWN0IHRlcm0gYXMgZGVmaW5l ZCBoZXJlIGlzIHVzZWQpLg0KDQpJIHRoaW5rIHRoZSBEb21haW4gSWRlbnRpdHkgaXMgdGhlIHRl cm1pbm9sb2d5LiBJdCBpcyBub3Qgc3VpdGFibGUgdG8gZGVzY3JpYmUgaXQgaW4gdGhpcyBzZWN0 aW9uIGZvciB0aGUgbG9naWNhbCBjb21wb25lbnQgZm9yIGJvb3RzdHJhcHBpbmcgYXJjaGl0ZWN0 dXJlLg0KQlRXo6xjb2xsb3F1YWxseT8gQSB0eXBvPw0KDQoNCjQuICAgICAgIFNlY3Rpb24gMjog ID4gTUFTQSBDbG91ZCBTZXJ2aWNlOiAgZW5jb3Jwb3JhdGUgPiBpbmNvcnBvcmF0ZQ0KDQoNCg0K NS4gICAgICAgU2VjdGlvbiA0OiBJdCBkb2VzIG5vdCBub3RlIHRoZSBGaWd1cmUgMiB1bmRlciB0 aGUgZmxvdyBwcm9jZWR1cmUuDQoNCg0KDQo2LiAgICAgICBTZWN0aW9uIDQuMSwgPiBBOiBTZWFy Y2ggZm9yIGEgUHJveHkgb24gdGhlIGxvY2FsIGxpbmsgdXNpbmcgTmVpZ2hib3IgRGlzY292ZXJ5 Lg0KDQoNCklzIHRoZSBOZWlnaGJvciBEaXNjb3ZlcnkgdXNpbmcgTkQ/IERvZXMgdGhlIE5EIGNh biB3b3JrIGluIHRoaXMgdXNlIGNhc2U/DQoNCg0KNy4gICAgICAgU2VjdGlvbiA0LjMsIHRoZSBm aXJzdCB3b3JkOiBvbmUgPiBvbmNlLg0KDQoNCg0KOC4gICAgICAgU2VjdGlvbiA0LjMuMiA+IElu IGFsbCBjYXNlcyBhIFJlZ2lzdHJhciBtdXN0IHVzZSB0aGUgZ2xvYmFsbHkgYXZhaWxhYmxlIE1B U0EgY2xvdWQgc2VydmljZSB0byB2ZXJpZnkgdGhlIGRldmljZSdzIGhpc3RvcnkgbG9nIGRvZXMg bm90IGluY2x1ZGUgdW5leHBlY3RlZCBSZWdpc3RyYXJzLg0KDQoNCkkgYW0gY29uZnVzZWQgd2l0 aCBob3cgYSBSZWdpc3RyYXIgdG8gdmVyaWZ5IHRoZSBkZXZpY2UncyBoaXN0b3J5IGxvZyBkb2Vz IG5vdCBpbmNsdWRlIHVuZXhwZWN0ZWQgUmVnaXN0cmFycy4gRG9lcyBpdCBjYW4gdmVyaWZ5IHRo ZSBsb2cgZG9lcyBub3QgaW5jbHVkZSB1bmV4cGVjdGVkIGRldmljZXM/DQoNCg0KOS4gICAgICAg U2VjdGlvbiA2ID4gVGhlIHJlZ2lzdHJhciBtYXkgY2hvc2UgdG8gYWNjZXB0DQoNCkNob3NlID4g Y2hvb3NlDQoNCg0KMTAuICAgSSB0aGluayBpdCBuZWVkIHRvIGRlc2NyaWJlIHNvbWUgc3BlY2lm aWMgdGVybWlub2xvZ3kgc3VjaCBhcyBhdXRob3JpemF0aW9uIHRva2VuLCBkb21haW4gaWRlbnRp dHksIGRldmljZSdzIGhpc3RvcnkgbG9nIGluIFNlY3Rpb24gMS4xLg0KDQpDaGVlcnMNCll1DQo= --_000_EF6A204047BD994A860EE26D5F23BF5881562D5Ankgeml505mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Some comments for draft-pritiki= n-anima-bootstrapping-keyinfra-00

 

1= .   &= nbsp;   Abstract: the last sent= ence

>When a vendor cloud service= is provided devices can be forced to join only specific domains but for co= ntrained environments we describe a variety of options that allow bootstrap= ping to proceed.=A1=B1

 

What does the =A1=B1 contrained= =A1=B1 mean? A typo?

 

2= .   &= nbsp;   Section 1 introduction = : the last sentence

>Sufficient agility to suppo= rt bootstrapping alternative key infrastructures (such as symmetric key sol= utions) is considered although no such key infrastructure is described &nbs= p;

=  

Does it describe the alternativ= e key infrastructures in this draft? For example, how the symmetric key sol= utions work?  If not, I think a brief description is needed.

 

3= .   &= nbsp;   Section 2:  > D= omain Identity:  (A string value bound to the Domain CA's self signed = root certificate subject and issuer fields is often colloqually used as a h= umanized identity value but during protocol discussions the more exact term as defined here is used).

 

I think the Domain Identity is = the terminology. It is not suitable to describe it in this section for the = logical component for bootstrapping architecture.

BTW=A3=ACcolloqually? A typo?

 

4= .   &= nbsp;   Section 2:  > M= ASA Cloud Service:  encorporate > incorporate

=  

5= .   &= nbsp;   Section 4: It does not = note the Figure 2 under the flow procedure.

 =

6= .   &= nbsp;   Section 4.1, > A: Se= arch for a Proxy on the local link using Neighbor Discovery.

 =

Is the Neighbor Discovery using= ND? Does the ND can work in this use case?

 

7= .   &= nbsp;   Section 4.3, the first = word: one > once.

=  

8= .   &= nbsp;   Section 4.3.2 > In a= ll cases a Registrar must use the globally available MASA cloud service to = verify the device's history log does not include unexpected Registrars.

 =

I am confused with how a Regist= rar to verify the device's history log does not include unexpected Registra= rs. Does it can verify the log does not include unexpected devices?

 

9= .   &= nbsp;   Section 6 > The regi= strar may chose to accept

 

Chose > choose

 

1= 0.   I think it need to desc= ribe some specific terminology such as authorization token, domain identity= , device's history log in Section 1.1.

 

Cheers

Yu

--_000_EF6A204047BD994A860EE26D5F23BF5881562D5Ankgeml505mbxchi_-- From nobody Thu Feb 5 08:03:04 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC3E1A88A6 for ; Thu, 5 Feb 2015 08:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.611 X-Spam-Level: X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 kmDeqRtQaN82 for ; Thu, 5 Feb 2015 08:03:00 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F6D1A8868 for ; Thu, 5 Feb 2015 08:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20999; q=dns/txt; s=iport; t=1423152180; x=1424361780; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=d+M1tDwZoc41DzT9T5XWZZLjZeKWVY2TN5s+4j8fIU4=; b=HS6buJnfKHmwfsoUBZYqyveEY7c42w0xoRz0ArOhBGYbKbwRhettveCX CbByLMf1meBbqE77QUWqWLCxuRsde9fbKE4+EBBl+OvnybyBRlXmGj5ZX p4vZdG5DEDYH0hS+48JINE9OhLwG0LhaaCdKGqHVKP88d1/ZgXOi6kmTP Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CWBQAek9NU/49dJa1RCYJDQ1JZBIJ9vSWIFwKBJUMBAQEBAX2EDAEBAQQhAQtcAgEIEQEDAQELBREHAgMCMhQDBggBAQQBEggTiBKjZJxnAZYwAQEBAQEBAQEBAQEBAQEBAQEBAQEBF48dKjcBgmUxgRMFjTGBY5wUIoNub4FEfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,524,1418083200"; d="scan'208,217";a="120874151" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP; 05 Feb 2015 16:02:59 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t15G2xBZ017414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Feb 2015 16:02:59 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.12]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Thu, 5 Feb 2015 10:02:59 -0600 From: "Michael Behringer (mbehring)" To: "Fuyu (Eleven)" , "anima@ietf.org" Thread-Topic: Comments for draft-pritikin-anima-bootstrapping-keyinfra-00 Thread-Index: AdBAPzoZSQgjkIgVRjmj/d4Olk1g3QBHWszA Date: Thu, 5 Feb 2015 16:02:59 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21D4F92A@xmb-rcd-x14.cisco.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.132] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21D4F92Axmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Comments for draft-pritikin-anima-bootstrapping-keyinfra-00 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 16:03:02 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21D4F92Axmbrcdx14ciscoc_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Thanks for the feedback. Most comments are about clarifications, we=1B$B!G= =1B(Bll work through them and clarify. Expect a new version shortly. Thanks, Michael From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Fuyu (Eleven) Sent: 04 February 2015 06:56 To: anima@ietf.org Subject: [Anima] Comments for draft-pritikin-anima-bootstrapping-keyinfra-0= 0 Hi all, Some comments for draft-pritikin-anima-bootstrapping-keyinfra-00 1. Abstract: the last sentence >When a vendor cloud service is provided devices can be forced to join only= specific domains but for contrained environments we describe a variety of = options that allow bootstrapping to proceed.=1B$B!I=1B(B What does the =1B$B!I=1B(B contrained=1B$B!I=1B(B mean? A typo? 2. Section 1 introduction : the last sentence >Sufficient agility to support bootstrapping alternative key infrastructure= s (such as symmetric key solutions) is considered although no such key infr= astructure is described Does it describe the alternative key infrastructures in this draft? For exa= mple, how the symmetric key solutions work? If not, I think a brief descri= ption is needed. 3. Section 2: > Domain Identity: (A string value bound to the Domai= n CA's self signed root certificate subject and issuer fields is often coll= oqually used as a humanized identity value but during protocol discussions = the more exact term as defined here is used). I think the Domain Identity is the terminology. It is not suitable to descr= ibe it in this section for the logical component for bootstrapping architec= ture. BTW=1B$B!$=1B(Bcolloqually? A typo? 4. Section 2: > MASA Cloud Service: encorporate > incorporate 5. Section 4: It does not note the Figure 2 under the flow procedure. 6. Section 4.1, > A: Search for a Proxy on the local link using Neigh= bor Discovery. Is the Neighbor Discovery using ND? Does the ND can work in this use case? 7. Section 4.3, the first word: one > once. 8. Section 4.3.2 > In all cases a Registrar must use the globally ava= ilable MASA cloud service to verify the device's history log does not inclu= de unexpected Registrars. I am confused with how a Registrar to verify the device's history log does = not include unexpected Registrars. Does it can verify the log does not incl= ude unexpected devices? 9. Section 6 > The registrar may chose to accept Chose > choose 10. I think it need to describe some specific terminology such as authori= zation token, domain identity, device's history log in Section 1.1. Cheers Yu --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21D4F92Axmbrcdx14ciscoc_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

= Thanks for the feedback. Mos= t comments are about clarifications, we=1B$B!G=1B(Bll work through them and= clarify.

=  

= Expect a new version shortly= .

=  

= Thanks,

= Michael

=  

From:<= /span> Anima [mailto:anima-bounces@ietf.org] = On Behalf Of Fuyu (Eleven)
Sent: 04 February 2015 06:56=
To: anima@ietf.org
Subject: [Anima] Comments fo= r draft-pritikin-anima-bootstrapping-keyinfra-00

 <= /span>

Hi all,

 

Some comments for draft-pritikin-anima-bootst= rapping-keyinfra-00

 

1.       Abstract:= the last sentence

>When a vendor cloud service is provided d= evices can be forced to join only specific domains but for contrained envir= onments we describe a variety of options that allow bootstrapping to proceed.=1B$B!I=1B(B

 

What does the =1B$B!I=1B(B contrained=1B$B!I= =1B(B mean? A typo?

=  

2.       Section 1= introduction : the last sentence

>Sufficient agility to support bootstrappi= ng alternative key infrastructures (such as symmetric key solutions) is con= sidered although no such key infrastructure is described  

=  

Does it describe the alternative key infrastr= uctures in this draft? For example, how the symmetric key solutions work? &= nbsp;If not, I think a brief description is needed.

=  

3.       Section 2= :  > Domain Identity:  (A string value bound to the Domain CA'= s self signed root certificate subject and issuer fields is often colloqual= ly used as a humanized identity value but during protocol discussions the more exact term as defined here is used).

 

I think the Domain Identity is the terminolog= y. It is not suitable to describe it in this section for the logical compon= ent for bootstrapping architecture.

BTW=1B$B!$=1B(Bcolloqually? A typo?

 

4.       Section 2= :  > MASA Cloud Service:  encorporate > incorporate

=  

5.       Section 4= : It does not note the Figure 2 under the flow procedure.=

 

6.       Section 4= .1, > A: Search for a Proxy on the local link using Neighbor Discovery.<= o:p>

 

Is the Neighbor Discovery using ND? Does the = ND can work in this use case?

 

7.       Section 4= .3, the first word: one > once.

=  

8.       Section 4= .3.2 > In all cases a Registrar must use the globally available MASA clo= ud service to verify the device's history log does not include unexpected R= egistrars.

 

I am confused with how a Registrar to verify = the device's history log does not include unexpected Registrars. Does it ca= n verify the log does not include unexpected devices?

 

9.       Section 6= > The registrar may chose to accept

 

Chose > choose

 

10.   I think i= t need to describe some specific terminology such as authorization token, d= omain identity, device's history log in Section 1.1.

 

Cheers

Yu

--_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21D4F92Axmbrcdx14ciscoc_-- From nobody Thu Feb 5 10:14:59 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38C61A07BC for ; Thu, 5 Feb 2015 10:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qwvBSj1VjAfB for ; Thu, 5 Feb 2015 10:14:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB4F1A0377 for ; Thu, 5 Feb 2015 10:14:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSH44551; Thu, 05 Feb 2015 18:14:52 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Feb 2015 18:14:52 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 6 Feb 2015 02:14:48 +0800 From: "Liubing (Leo)" To: "anima@ietf.org" Thread-Topic: Several questions about draft-pritikin-anima-bootstrapping-keyinfra Thread-Index: AQHQQPNORCxhSL3PvUK4ebw0UwTekQ== Date: Thu, 5 Feb 2015 18:14:47 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F457CEA1981@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.26.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Several questions about draft-pritikin-anima-bootstrapping-keyinfra X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 18:14:56 -0000 Hi, I'm reading the draft. Here are several primary questions.=20 1. In 3.2 "...or a device can auto-select itself to take on this function, using a detection mechanism to resolve potential conflicts and setup communication with the Domain Certification Authority. An automated Registrar selection processes is not detailed here" Will this mechanism be in the future version, or another dedicated draft? 2. Regarding to Cloud Service In Abstract, it is called "a vendor based cloud service"; then in the forma= l text, it is called "third-party cloud service". I'm a little confused, does the MASA support bootstrapping the devices from= other vendors or not? And must the MASA operated by the vendors? 3. In 4.1.1 "IEEE 802.1X Where the New Entity can be cast as the "supplicant" and the Proxy is the "authenticator". The bootstrapping protocol messages are encapsulated as EAP methods. The "authenticator" reencapsulates the EAPOL frames and forwards them to the "Authentication Server", which provides Registrar functionalities." When there is no Proxy, will 802.1x also fit in the scenario? Best regards, Bing From nobody Fri Feb 6 03:05:58 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB551A01CB for ; Fri, 6 Feb 2015 03:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 1pO8mYyG30UU for ; Fri, 6 Feb 2015 03:05:51 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422C61A01A8 for ; Fri, 6 Feb 2015 03:05:51 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 5ABA01F0CB11E; Fri, 6 Feb 2015 11:05:47 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t16B5nf4019185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Feb 2015 12:05:49 +0100 Received: from [172.27.204.62] (135.239.27.41) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 6 Feb 2015 12:05:49 +0100 Message-ID: <54D4A007.1030903@alcatel-lucent.com> Date: Fri, 6 Feb 2015 12:05:43 +0100 From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sheng Jiang , "anima@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B923B0455C9@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923B0455C9@nkgeml512-mbx.china.huawei.com> Content-Type: multipart/alternative; boundary="------------050703090701050508010808" X-Originating-IP: [135.239.27.41] Archived-At: Cc: "anima-chairs@tools.ietf.org" Subject: Re: [Anima] Call for agenda ANIMA @ IETF92 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 11:05:55 -0000 --------------050703090701050508010808 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Dear ANIMA chairs, all, I am kindly asking for two slots. _slot 1:_ Name of time slot: predictive risk awareness for proactive management. Name of draft(s) (preferred but not necessary): TBA. Time requested: 10min. + Q&A Presenter name(s): Laurent Ciavaglia Brief description of what issues need discussing and what you hope to accomplish by presenting: requirements and applicability to ANIMA functionality/protocol suite. _slot 2__:_ Name of time slot: coordinating multiple (conflicting) autonomic functions. Name of draft(s) (preferred but not necessary): TBA. Time requested: 10min. + Q&A Presenter name(s): Laurent Ciavaglia Brief description of what issues need discussing and what you hope to accomplish by presenting: highlight coordination as a key issue in autonomic networking, requirements and applicability to ANIMA functionality/protocol suite. Best regards, Laurent. --------------050703090701050508010808 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Dear ANIMA chairs, all,

I am kindly asking for two slots.
slot 1:
   Name of time slot: predictive risk awareness for proactive management.
   Name of draft(s) (preferred but not necessary): TBA.
   Time requested: 10min. + Q&A
   Presenter name(s): Laurent Ciavaglia
   Brief description of what issues need discussing and what you hope to accomplish by presenting: requirements and applicability to ANIMA functionality/protocol suite.
slot 2:
   Name of time slot: coordinating multiple (conflicting) autonomic functions.
   Name of draft(s) (preferred but not necessary): TBA.
   Time requested: 10min. + Q&A
   Presenter name(s): Laurent Ciavaglia
   Brief description of what issues need discussing and what you hope to accomplish by presenting: highlight coordination as a key issue in autonomic networking, requirements and applicability to ANIMA functionality/protocol suite.

Best regards, Laurent.
--------------050703090701050508010808-- From nobody Wed Feb 11 11:09:07 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8281A8A91 for ; Wed, 11 Feb 2015 11:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 IV35Djh-Mf3y for ; Wed, 11 Feb 2015 11:08:52 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C588B1A8A82 for ; Wed, 11 Feb 2015 11:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3813; q=dns/txt; s=iport; t=1423681731; x=1424891331; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=K/248bxOFkH/Z7jQRNu15/oUScDwA76CGH0ycMTwjSE=; b=WUpLiK2sDqbN6+2y745WRPDluiuIAnDZ7aoqpfhKRBHN9ljNJ0qkXvpD wFWnYxuOYCH5LvpLsfUedQqpmNKEZHaGt2tCvTkyN1charY92IYnTAhwx Ou0frhm4HAfSGeGXIpnuqjilGym3iDRrhRugvDiWOcwShw63tzccZ+9/K E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AKBgBvp9tU/5RdJa1bgwZSWgTAXoIcCoVxAoEpQwEBAQEBAXyEDAEBAQQBAQEaHTQLDAQCAQgRBAEBCxQJBycLFAkIAQEEAQ0FCIglDdJ5AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLDIQVBwEBHjEHBoMQgRQFhB2LCIc4gxGDBosjgz4ig25vgQICBxcGHH8BAQE X-IronPort-AV: E=Sophos;i="5.09,560,1418083200"; d="scan'208";a="122681965" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP; 11 Feb 2015 19:08:42 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t1BJ8gKi014196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Feb 2015 19:08:42 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Wed, 11 Feb 2015 13:08:41 -0600 From: "Michael Behringer (mbehring)" To: Sheng Jiang , "anima@ietf.org" Thread-Topic: Call for agenda ANIMA @ IETF92 Thread-Index: AdA+sgQiAayWyIJ1SBKW5B+Vws1dugHeq5Tw Date: Wed, 11 Feb 2015 19:08:41 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EB8A8A@xmb-rcd-x14.cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B0455C9@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923B0455C9@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.200.237] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "anima-chairs@tools.ietf.org" Subject: Re: [Anima] Call for agenda ANIMA @ IETF92 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 19:09:02 -0000 Sheng,=20 We should present the following drafts:=20 Name of time slot: Bootstrapping a trust infrastructure Name of draft(s) (preferred but not necessary): draft-pritikin-anima-bootst= rapping-keyinfra Time requested: 20 min plus discussion Presenter name(s): Max Pritikin (tbd) Brief description of what issues need discussing and what you hope to accom= plish by presenting: This draft should describe a generic way to bootstrap = a trust infrastructure, and it should be applicable to other working groups= .=20 Name of time slot: Separated Autonomic Control Plane Name of draft(s) (preferred but not necessary): draft-behringer-anima-auton= omic-control-plane Time requested: 20 min plus discussion Presenter name(s): Michael Behringer (tbd) Brief description of what issues need discussing and what you hope to accom= plish by presenting: This is a new concept, which needs peer validation and= feedback.=20 Name of time slot: ANIMA reference model Name of draft(s) (preferred but not necessary): draft-behringer-anima-refer= ence-model Time requested: 20 min plus discussion Presenter name(s): Michael Behringer (tbd) Brief description of what issues need discussing and what you hope to accom= plish by presenting: A new version of the draft will be posted soon; the re= ference model should accurately describe the overall architectural approach= for ANIMA, and needs discussion.=20 Thanks, Michael > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang > Sent: 02 February 2015 07:33 > To: anima@ietf.org > Cc: anima-chairs@tools.ietf.org > Subject: [Anima] Call for agenda ANIMA @ IETF92 >=20 > Hi, all, >=20 > After my pre-call-for-agenda "ANIMA @ IETF92" two weeks ago, we have > received several applications for autonomic network topics besides the WG > milestones. So, we have consulted our responsible AD and requested two > sessions (a 2-hour session for WG milestones, another 1.5-hour session fo= r > non WG milestone topics) for our ANIMA Working Group meeting at IETF92. >=20 > The conflict list is as follows: > First Priority: homenet netconf dhc v6ops > Second Priority: opsarea 6man softwire nmrg > Third Priority: cfrg saag 6tisch >=20 > We have also requested a Meetecho support in the room in case anyone is > remote / need to present remotely. >=20 > Please send us (anima-chairs@tools.ietf.org) requests for time slot and > include: >=20 > Name of time slot: > Name of draft(s) (preferred but not necessary): > Time requested: > Presenter name(s): > Brief description of what issues need discussing and what you hope to > accomplish by presenting: >=20 > Also, presenters and draft authors please invoke active discussions in th= e > ANIMA list. We have very limited time for each topic in the face-to-face > meeting. Mail list is a very good place to attract audiences' attention a= nd get > them to actually know your topic, also details, before the meeting. So, w= e > could have the best use of our meeting time. We could not make significan= t > progress with only the face-to-face meeting. Mail list is the official wo= rk > place in the IETF. >=20 > Again, as a emphasis, the ANIMA WG is open for topics/drafts that are > relevant to autonomic networking. Beside the current milestones, other > autonomic infrastructure components, policy intents, use cases or > autonomic service agents are strongly encouraged, as individual > submissions. They could be discussed as potential recharter contents in t= he > future. >=20 > Best regards, >=20 > Sheng and Toerless > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Feb 11 11:13:41 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B292D1A8AA7 for ; Wed, 11 Feb 2015 11:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 sSDRDoWghEua for ; Wed, 11 Feb 2015 11:13:22 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589D11A8AAA for ; Wed, 11 Feb 2015 11:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1750; q=dns/txt; s=iport; t=1423681970; x=1424891570; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Ak6V5AeqrPyg0TECbxe0RqifF7r/PtuoHO1MJABeo9Q=; b=lhcsU0s/45M7izceqiPqdmCuR9X90FbjyahyXXPBPHsZOzHMqHvkfQtA ABaM2ti2TUKDAatJ72FF5FC1t01DuHOJga8JDXFcRs2SDqY0hAswwtWOw gXpq2Uj9/oK093BNS2Wod9C6bDmMnQEzQnfXeNPtmOh24XtEID+gzM625 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AKBgAcqdtU/4cNJK1bgwZSWgTAXoIcCoVxAoEpQwEBAQEBAXyEDAEBAQQBAQE3NBcEAgEIEQQBAQEKFAkHJwsUCQgCBAESCIglDdMCAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLDIQ8OAaDEIEUBY8likmLI4MGgz4ig25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,560,1418083200"; d="scan'208";a="122685116" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP; 11 Feb 2015 19:12:49 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t1BJCnA6032492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Feb 2015 19:12:49 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Wed, 11 Feb 2015 13:12:49 -0600 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] I-D Action: draft-behringer-anima-autonomic-control-plane-00.txt Thread-Index: AQHP965HwnxXabmvmkGDG4S5dbvJBZzYgWwAgBPsdlA= Date: Wed, 11 Feb 2015 19:12:49 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EB8AB5@xmb-rcd-x14.cisco.com> References: <20141017131337.4423.84144.idtracker@ietfa.amsl.com> <5457F566.4080409@gmail.com> <54CA9E92.10802@gmail.com> In-Reply-To: <54CA9E92.10802@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.200.237] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-control-plane-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 19:13:31 -0000 We are planning an upgrade, but it'll take some time. I suggest you review = now, and we include your comments in the next version.=20 Michael > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: 29 January 2015 21:57 > To: anima@ietf.org > Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-control- > plane-00.txt >=20 > Hi authors of -autonomic-control-plane, >=20 > I was thinking of reviewing this draft as a potential application of GDNP= , but > before I do that, are you planning an update soon? >=20 > Brian >=20 >=20 > On 04/11/2014 10:36, Brian E Carpenter wrote: > > Hi, > > > > This draft seems fairly clear to me, though I assume it will evolve as > > other aspects of anima become clear. The proposal to use a ULA prefix > > (section 3.7) seems good, since it decouples the ACP from all external > > addressing considerations and will work from a pure factory-reset > > condition. However, it does raise a question (which also came up in > > homenet recently). What happens if the network partitions? The ACP > > will automatically partition too, but it will presumably keep the same > > /48 ULA prefix everywhere. Does the partitioned network retain the > > same domain ID in both parts? What happends in the part that doesn't > > include the trust anchor? What happens if the network recombines - > > will there be a risk of clashing subnets created during the partition? > > > > Also what happens if two previously unrelated networks combine? > > > > Brian > > >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Feb 12 08:37:24 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBF31A00A2 for ; Thu, 12 Feb 2015 08:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 4dRdYIIDqL7O for ; Thu, 12 Feb 2015 08:37:20 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994361A00EC for ; Thu, 12 Feb 2015 08:37:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2955; q=dns/txt; s=iport; t=1423759039; x=1424968639; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YtllHFHoaieAlGV1/xSlAR0yr6CX2HmRDjJvozopvU8=; b=ckBclRlvmow24lSe/F9ANZ8/kIbImTCDH9gDRGX4etWTSj3BV3xCu0ug Cy3oY43QAbO3KWp12TGPg0/l+zhA3XXsgWrI3S4GEh2RnhKbrHf5qn2Ps rhAJxLH37aNTnFna8OqkY8mHjq/8OBxRVmQwWSA+nhSIZ9V95gQdFF8R0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BZBQAK1txU/4sNJK1bgwZSWgTAf4IcCoVxAoEpQwEBAQEBAXyEDAEBAQMBAQEBNzQLBQcEAgEIEQQBAQsUCQcnCxQJCAIEAQ0FCIgdCA3VVwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiwyEPDEHBoMQgRQFjymKS44qgz4ig25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,565,1418083200"; d="scan'208";a="122948752" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP; 12 Feb 2015 16:37:18 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t1CGbI1g018054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Feb 2015 16:37:18 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 12 Feb 2015 10:37:18 -0600 From: "Michael Behringer (mbehring)" To: "Liubing (Leo)" , "anima@ietf.org" Thread-Topic: [Anima] Several questions about draft-pritikin-anima-bootstrapping-keyinfra Thread-Index: AQHQQPNORCxhSL3PvUK4ebw0UwTekZztHjkw Date: Thu, 12 Feb 2015 16:37:17 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EB9859@xmb-rcd-x14.cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F457CEA1981@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F457CEA1981@nkgeml506-mbx.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-pritikin-anima-bootstrapping-keyinfra@tools.ietf.org" Subject: Re: [Anima] Several questions about draft-pritikin-anima-bootstrapping-keyinfra X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 16:37:22 -0000 Thanks for your feedback, Liubing. Inline... > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Liubing (Leo) > Sent: 05 February 2015 19:15 > To: anima@ietf.org > Subject: [Anima] Several questions about draft-pritikin-anima- > bootstrapping-keyinfra >=20 > Hi, >=20 > I'm reading the draft. Here are several primary questions. >=20 > 1. In 3.2 > "...or a device can > auto-select itself to take on this function, using a detection > mechanism to resolve potential conflicts and setup communication with > the Domain Certification Authority. An automated Registrar selection > processes is not detailed here" > Will this mechanism be in the future version, or another dedicated draft? My current feeling is that the details aren't really relevant right now, an= d I would leave it as is. The current revision (coming) labels it clearly a= s "out of scope" for now, to be clear. Open to suggestions.=20 > 2. Regarding to Cloud Service > In Abstract, it is called "a vendor based cloud service"; then in the for= mal > text, it is called "third-party cloud service". > I'm a little confused, does the MASA support bootstrapping the devices > from other vendors or not? And must the MASA operated by the vendors? I believe the next revision makes this clear, and also doesn't mention the = word "cloud" any more (on request of Brian). It's now called an "Internet b= ased MASA service", or short "MASA service". =20 Bottom line: The 802.1ar credentials we suggest to use can be put by either= . We see the primary use case in the vendor providing hardware assurance fo= r his devices. But an integrator can fulfil the same function, and is the m= ore likely scenario in certain markets.=20 So, if a network operator buys devices from say 2 vendors, he would use the= MASA services of each for their respective devices. Where an integrator do= es some pre-staging, he could provide the trust anchors, and then the netwo= rk might only require a single MASA server (from that integrator).=20 Tried to be clearer in the doc now.=20 > 3. In 4.1.1 > "IEEE 802.1X Where the New Entity can be cast as the "supplicant" and > the Proxy is the "authenticator". The bootstrapping protocol > messages are encapsulated as EAP methods. The "authenticator" > reencapsulates the EAPOL frames and forwards them to the > "Authentication Server", which provides Registrar functionalities." > When there is no Proxy, will 802.1x also fit in the scenario? Well, .1x requires an authenticator. So my take would be that you require a= proxy in this case.=20 The next version of the document is imminent - bear with us! Thanks for your comments! Michael > Best regards, > Bing >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Feb 12 08:59:14 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC701A0178 for ; Thu, 12 Feb 2015 08:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.888 X-Spam-Level: X-Spam-Status: No, score=-11.888 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 sotBsDLzxwqu for ; Thu, 12 Feb 2015 08:59:09 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92AC11A00A2 for ; Thu, 12 Feb 2015 08:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17256; q=dns/txt; s=iport; t=1423760343; x=1424969943; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=IT+jC2xUTKoDhYYGIv71/Ypa5vmToKcbYx9LE2z7Uew=; b=U7bwPX49uudzU8vWhVkLHgu+dbT75gQgWo6yvoL5yInn9D1yeODaKPtK OK9lrwSRvwd9YpCpCfAkzgRaEohX/R5ma4vCE12hSiXg9SAX1smrq9Kqv 9nYgAzi57X+szh5EcgSSmcOYH8mP3aMZEUsl0KX3kHn5cZBVSycg7MR0s 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AJCgBy29xU/xbLJq1SCYJDgRVagwKtUgEBAQEBAQUBdZFKAQmFcQIjgUkBAQEBAQF8hA0BAQQBAQEgCgUBOwoRCQISCAIFFgEKAgIJAwIBAgEVIg4GAQwGAgEBF4gSDaFmnGyXHgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGEY4UIhBJigmiBQgEEjUKLGoEYhS6IfIM+IoNvPTGCQwEBAQ X-IronPort-AV: E=Sophos;i="5.09,565,1418083200"; d="scan'208,217";a="343415082" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 12 Feb 2015 16:59:00 +0000 Received: from [10.55.238.136] (ams-mbehring-8817.cisco.com [10.55.238.136]) (authenticated bits=0) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t1CGwwsF004864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 12 Feb 2015 16:58:59 GMT Message-ID: <54DCDBD2.7080705@cisco.com> Date: Thu, 12 Feb 2015 17:58:58 +0100 From: Michael Behringer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Fuyu (Eleven)" , "anima@ietf.org" References: In-Reply-To: Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Authenticated-User: mbehring Archived-At: Subject: Re: [Anima] Comments for draft-pritikin-anima-bootstrapping-keyinfra-00 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 16:59:12 -0000
Hi Fuyu, thanks for your comments! Inline...

On 04/02/2015 06:55, Fuyu (Eleven) wrote:

Hi all,

 

Some comments for draft-pritikin-anima-bootstrapping-keyinfra-00

 

1.       Abstract: the last sentence

>When a vendor cloud service is provided devices can be forced to join only specific domains but for contrained environments we describe a variety of options that allow bootstrapping to proceed.â€

 

What does the †contrained†mean? A typo?


Yes. Fixed.

2.       Section 1 introduction : the last sentence

>Sufficient agility to support bootstrapping alternative key infrastructures (such as symmetric key solutions) is considered although no such key infrastructure is described  

 

Does it describe the alternative key infrastructures in this draft? For example, how the symmetric key solutions work?  If not, I think a brief description is needed.


Yes, this is missing, and will be added.

3.       Section 2:  > Domain Identity:  (A string value bound to the Domain CA's self signed root certificate subject and issuer fields is often colloqually used as a humanized identity value but during protocol discussions the more exact term as defined here is used).

 

I think the Domain Identity is the terminology. It is not suitable to describe it in this section for the logical component for bootstrapping architecture.


Not sure I understand what you mean?

BTW，colloqually? A typo?


Yup. colloquially. Fixed.

 

4.       Section 2:  > MASA Cloud Service:  encorporate > incorporate

Fixed.

 

5.       Section 4: It does not note the Figure 2 under the flow procedure.

Fixed.

 

6.       Section 4.1, > A: Search for a Proxy on the local link using Neighbor Discovery.

 

Is the Neighbor Discovery using ND? Does the ND can work in this use case?

ND could be used to discover peers.

 

7.       Section 4.3, the first word: one > once.

Done.

 

8.       Section 4.3.2 > In all cases a Registrar must use the globally available MASA cloud service to verify the device's history log does not include unexpected Registrars.

 

I am confused with how a Registrar to verify the device's history log does not include unexpected Registrars. Does it can verify the log does not include unexpected devices?


Tried to clarify with "Because if a device had previously registered with another domain, the registrar of that domain would show in the log."
Does that make it clearer?

 

9.       Section 6 > The registrar may chose to accept

 

Chose > choose

Fixed.

 

10.   I think it need to describe some specific terminology such as authorization token, domain identity, device's history log in Section 1.1.

Hmmm... It's all in the draft actually. For example, domain ID is 3rd definitino after figure 1. Authorization token is defined in the client behaviour section. Will see whether we can make that clearer.

Thanks for the feedback again!
Michael

 

Cheers

Yu



_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

From nobody Fri Feb 13 02:36:31 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07491A6F22 for ; Fri, 13 Feb 2015 02:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 rFQJqy3Czc0e for ; Fri, 13 Feb 2015 02:36:25 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846B51A1BAA for ; Fri, 13 Feb 2015 02:36:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3802; q=dns/txt; s=iport; t=1423823785; x=1425033385; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PL1f1uKQIsSAHDE9BJV0MXJptMqSDTOVkVBF+//ozdg=; b=LdezqfuydbPE3CEWW9TOyFNaJe1A361ujQoW90/lmSxL0sS+sTITBrWm m00g1BfhClqgKI+yMgj+FaRFiB+k4a+o85G/GlLlcHPBoDtmxoNhZVJlc Xdi2Hh2xuXiKwtRGD4pQrRcY9KM9oN4HQ718reI04v9/bt1lcaw0DRbzP M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ChBQBv091U/49dJa1bgwZSVQUEgn6+NIInhXECHHlDAQEBAQEBfIQMAQEBBCMRQw4EAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBBMIAYgkCAW8c5dLAQEBAQEBAQEBAQEBAQEBAQEBAQEYgSGJa4Q8OAaCYi6BFAWPNINWhnc4gk+IH4MJgz4igjKBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,570,1418083200"; d="scan'208";a="123191503" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP; 13 Feb 2015 10:36:24 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t1DAaOfX013577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 13 Feb 2015 10:36:24 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Fri, 13 Feb 2015 04:36:24 -0600 From: "Michael Behringer (mbehring)" To: "anima@ietf.org" Thread-Topic: New Version Notification for draft-pritikin-anima-bootstrapping-keyinfra-01.txt Thread-Index: AQHQR2N0aSSh9ETEXU+Qn6ZyPvfxeZzuQgBQ Date: Fri, 13 Feb 2015 10:36:23 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EBB377@xmb-rcd-x14.cisco.com> References: <20150213080241.29611.75227.idtracker@ietfa.amsl.com> In-Reply-To: <20150213080241.29611.75227.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.136] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Anima] FW: New Version Notification for draft-pritikin-anima-bootstrapping-keyinfra-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 10:36:28 -0000 V2UganVzdCBwb3N0ZWQgYW4gdXBkYXRlIHRvIHRoaXMgZG9jdW1lbnQsIGluY29ycG9yYXRpbmcg bW9zdCBvZiB0aGUgY29tbWVudHMgcmVjZWl2ZWQgc28gZmFyLiBXZSBhcmUgbm90IGFkZHJlc3Np bmcgdGhlIHN5bW1ldHJpYyBzY2hlbWVzIHlldCAoY29tbWVudCBmcm9tIEZ1eXUpLg0KDQpUaGlz IGRvY3VtZW50IGFkZHJlc3NlcyBhIFdHIGRlbGl2ZXJhYmxlLCBhbmQgd2Ugd291bGQgbGlrZSB0 byB3b3JrIHRvd2FyZHMgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBhcyBhIFdHIGRvY3VtZW50 LiANCg0KV2hpbGUgb2YgY291cnNlIHRoaXMgZG9jdW1lbnQgcmVxdWlyZXMgYSBsb3Qgb2Ygd29y aywgd2Ugd291bGQgbGlrZSB0byBzb2xpY2l0IGZlZWRiYWNrIG9uIHdoZXRoZXIgdGhlIG92ZXJh bGwgc3RydWN0dXJlIGFuZCBjb250ZW50IG9mIHRoZSBkb2N1bWVudCBpcyBnb2luZyBpbiB0aGUg cmlnaHQgZGlyZWN0aW9uLiBXZSB3b3VsZCBsaWtlIHRoaXMgZG9jdW1lbnQgdG8gYmUgYSBnZW5l cmljIHdheSB0byBib290c3RyYXAgYSB0cnVzdCBpbmZyYXN0cnVjdHVyZSwgaW4gYWxsIHBvc3Np YmxlIGRlcGxveW1lbnQgc2NlbmFyaW9zLCBmcm9tIHNpbXBsZSBuZXR3b3JrcyBsaWtlIGEgaG9t ZW5ldCBvciBzZW5zb3IgbmV0d29yaywgdG8gU1AgbmV0d29ya3MuIA0KDQpQbGVhc2Ugc2hhcmUg eW91ciB0aG91Z2h0cyB3aXRoIHVzLCBzbyB0aGF0IHdlIGNhbiBwb3NzaWJseSBkbyBhbm90aGVy IHJldmlzaW9uIGJlZm9yZSB0aGUgSUVURi4gDQoNCk1pY2hhZWwNCg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogMTMgRmVicnVhcnkgMjAxNSAwOTow Mw0KPiBUbzogTWF4IFByaXRpa2luIChwcml0aWtpbik7IE1pY2hhZWwgQmVocmluZ2VyIChtYmVo cmluZyk7IFN0ZWludGhvcg0KPiBCamFybmFzb24gKHNiamFybmFzKTsgTWljaGFlbCBCZWhyaW5n ZXIgKG1iZWhyaW5nKTsgTWF4IFByaXRpa2luIChwcml0aWtpbik7DQo+IFN0ZWludGhvciBCamFy bmFzb24gKHNiamFybmFzKQ0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXByaXRpa2luLWFuaW1hLWJvb3RzdHJhcHBpbmctDQo+IGtleWluZnJhLTAxLnR4dA0K PiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1wcml0aWtpbi1hbmltYS1ib290 c3RyYXBwaW5nLWtleWluZnJhLTAxLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IE1pY2hhZWwgSC4gQmVocmluZ2VyIGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVw b3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1wcml0aWtpbi1hbmltYS1ib290c3RyYXBwaW5n LWtleWluZnJhDQo+IFJldmlzaW9uOgkwMQ0KPiBUaXRsZToJCUJvb3RzdHJhcHBpbmcgS2V5IElu ZnJhc3RydWN0dXJlcw0KPiBEb2N1bWVudCBkYXRlOgkyMDE1LTAyLTEzDQo+IEdyb3VwOgkJSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJMjMNCj4gVVJMOiAgICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXByaXRpa2luLWFuaW1hLQ0KPiBi b290c3RyYXBwaW5nLWtleWluZnJhLTAxLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcHJpdGlraW4tYW5pbWEtDQo+IGJvb3RzdHJh cHBpbmcta2V5aW5mcmEvDQo+IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1wcml0aWtpbi1hbmltYS1ib290c3RyYXBwaW5nLQ0KPiBrZXlpbmZyYS0wMQ0K PiBEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt cHJpdGlraW4tYW5pbWEtDQo+IGJvb3RzdHJhcHBpbmcta2V5aW5mcmEtMDENCj4gDQo+IEFic3Ry YWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhdXRvbWF0ZWQgYm9vdHN0cmFwcGlu ZyBvZiBhbiBrZXkNCj4gICAgaW5mcmFzdHJ1Y3R1cmUgdXNpbmcgdmVuZG9yIGluc3RhbGxlZCBJ RUVFIDgwMi4xQVIgbWFudWZhY3R1cmluZw0KPiAgICBpbnN0YWxsZWQgY2VydGlmaWNhdGVzLCBp biBjb21iaW5hdGlvbiB3aXRoIGEgdmVuZG9yIGJhc2VkIHNlcnZpY2Ugb24NCj4gICAgdGhlIElu dGVybmV0LiAgQmVmb3JlIGJlaW5nIGF1dGhlbnRpY2F0ZWQsIGEgbmV3IGRldmljZSBoYXMgb25s eQ0KPiAgICBsaW5rLWxvY2FsIGNvbm5lY3Rpdml0eSwgYW5kIGRvZXMgbm90IHJlcXVpcmUgYSBy b3V0YWJsZSBhZGRyZXNzLg0KPiAgICBXaGVuIGEgdmVuZG9yIHByb3ZpZGVzIGFuIEludGVybmV0 IGJhc2VkIHNlcnZpY2UsIGRldmljZXMgY2FuIGJlDQo+ICAgIGZvcmNlZCB0byBqb2luIG9ubHkg c3BlY2lmaWMgZG9tYWlucyBidXQgZm9yIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cw0KPiAgICB3 ZSBkZXNjcmliZSBhIHZhcmlldHkgb2Ygb3B0aW9ucyB0aGF0IGFsbG93IGJvb3RzdHJhcHBpbmcg dG8gcHJvY2VlZC4NCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+IHN1Ym1pc3Npb24gdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Sun Feb 15 18:19:14 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75EA31A8718 for ; Sun, 15 Feb 2015 18:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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 nYmcRhogW0Ch for ; Sun, 15 Feb 2015 18:19:11 -0800 (PST) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE9A1A8714 for ; Sun, 15 Feb 2015 18:19:11 -0800 (PST) Received: by pdjp10 with SMTP id p10so32044739pdj.3 for ; Sun, 15 Feb 2015 18:19:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nNolylXCusO6TEtb44XELSaFOTjVOG5NaFITQhiOO5k=; b=KrEGj5l9AEgokx3KP5mHjTPFklOapSrKSoAQybrpHAmyoqqjy9JO2PcfSujzzlYVtD tfJsZhEIIJltO12TSo1/8xYYWXJ4Eu9eb9BHgp0rVPDcjdgoGIwKSgIq7NKAcTntjR+N YYfgX6ouxzmiVNXG5t84hqXw7317IxUE06b/JhrrcbNPlF9OUW3EWjLGpTaxu1zXhhv/ Q/FTMiNMOSCjI7K9i0r6zf9lVHMk81wWkh2mjPtlmIH+wv/ohmXseYhhcezGoeZhNUMd WAOuuKFiFyKBwXiFGCRHhyVlXYHeH1qJflaeKI268qzlna22JkLZxeK8fERw+0V+zm1g KpLw== X-Received: by 10.66.249.39 with SMTP id yr7mr35334014pac.43.1424053149168; Sun, 15 Feb 2015 18:19:09 -0800 (PST) Received: from ?IPv6:2406:e007:4e0d:1:28cc:dc4c:9703:6781? ([2406:e007:4e0d:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id b3sm13006916pbu.0.2015.02.15.18.19.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Feb 2015 18:19:08 -0800 (PST) Message-ID: <54E153AA.1070208@gmail.com> Date: Mon, 16 Feb 2015 15:19:22 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Anima WG References: <20150213080241.29611.49937.idtracker@ietfa.amsl.com> In-Reply-To: <20150213080241.29611.49937.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-pritikin-anima-bootstrapping-keyinfra-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 02:19:13 -0000 Thanks for this update. I think my main points have been well answered. We're hoping to get an update of the GDNP protocol draft out in a few days. An interesting exercise would be to do a walkthrough of the whole process of bootstrapping a new device using both drafts. Maybe we need to find a very large whiteboard in Dallas. Regards Brian On 13/02/2015 21:02, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Bootstrapping Key Infrastructures > Authors : Max Pritikin > Michael H. Behringer > Steinthor Bjarnason > Filename : draft-pritikin-anima-bootstrapping-keyinfra-01.txt > Pages : 23 > Date : 2015-02-13 > > Abstract: > This document specifies automated bootstrapping of an key > infrastructure using vendor installed IEEE 802.1AR manufacturing > installed certificates, in combination with a vendor based service on > the Internet. Before being authenticated, a new device has only > link-local connectivity, and does not require a routable address. > When a vendor provides an Internet based service, devices can be > forced to join only specific domains but for constrained environments > we describe a variety of options that allow bootstrapping to proceed. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-pritikin-anima-bootstrapping-keyinfra/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfra-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-pritikin-anima-bootstrapping-keyinfra-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Sun Feb 15 18:53:34 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5C41A049C for ; Sun, 15 Feb 2015 18:53:32 -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 WudKz9Q6fmKn for ; Sun, 15 Feb 2015 18:53:30 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D061A0451 for ; Sun, 15 Feb 2015 18:53:29 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id kx10so32046854pab.0 for ; Sun, 15 Feb 2015 18:53:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Yb3bnzJBQy/TLy7CcLmK02pNq/S0OJzKWTqgr4n/CpI=; b=NXk6yD1enReFnX5YY9g8nNRYdpXY8MhwPw7EwFeLNXFx9Mvzc3ml9RIDO+ZXIaqa8s pUKIxd1YRBrtSyZ3aA4QquRhpU94y3EuTaq3NJ+jiTkQt0I6tzXJLBeFUnQ8UlwYjzyI QFv+CjSZQ5cnEQiQR9sv/jx5YPrVJbmPzwUisWxkIj/l1gHDtXpZc+8D2VBM6TYEMC56 d3jayA+mVkmimSN1GIrdoklNY7FpgYEAzxdIj2lzTfutbE+ah+MR23NI/J7J9dqsVWWW QFed/2EHj0AdXuQXd/z10zJNTAV4Kk7tb+ycIeK+nEmmAUt4BEF4eSlvZy+xqt5PompB ueNw== X-Received: by 10.66.119.238 with SMTP id kx14mr940219pab.149.1424055208969; Sun, 15 Feb 2015 18:53:28 -0800 (PST) Received: from ?IPv6:2406:e007:4e0d:1:28cc:dc4c:9703:6781? ([2406:e007:4e0d:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id qp3sm12357940pdb.11.2015.02.15.18.53.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Feb 2015 18:53:28 -0800 (PST) Message-ID: <54E15BB5.6020005@gmail.com> Date: Mon, 16 Feb 2015 15:53:41 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , "anima@ietf.org" References: <20141017131337.4423.84144.idtracker@ietfa.amsl.com> <5457F566.4080409@gmail.com> <54CA9E92.10802@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EB8AB5@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EB8AB5@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-control-plane-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 02:53:32 -0000 Hi Michael, This may be a bit late but we've been working hard on the GDNP protocol spec... > 3.1. Preconditions > > > Each autonomic device has a globally unique domain certificate, with > which it can cryptographically assert its membership of the domain. > The document [I-D.pritikin-bootstrapping-keyinfrastructures] > describes how a domain certificate can be automatically and securely > derived ... One thing we need to agree on is the size of this cert, or rather of its hash, which draft-pritikin calls the Domain Identity and sets at 160 bits. In the GDNP draft we picked 128 bits and called it Device Certifcate Tag. The good news is that we all agree that it's needed. > 3.2. Adjacency Discovery This we can certainly do with the GDNP Discovery and Synchronization mechanisms. Some details TBD of course, but it's a text book application of GDNP. > > 3.3. Authenticating Neighbors > > > Each neighbour in the adjacency table is authenticated. I think this falls right out of Discovery since the discovery response would contain the relevant Domain Identity a.k.a. Device Certifcate Tag and that can be checked with the CA. Note that draft-ietf-homenet-dncp has a quite complicated "trust verdict" mechanism. I personally don't think that is necessary, but we should probably find out why they included it. > 3.4. Capability Negotiation ... > To establish a trusted secure > communication channel, devices must be able to negotiate with each > neighbour a set of parameters for establishing the communication > channel, most notably channel type and security type. I think GDNP is very likely to end up simply using TLS (although that's not what the draft says right now, the arguments from the DNCP team have almost convinced me). In any case, secure channels between GDNP nodes are fundamental, as for the ACP. I have doubts whether we should leave options or choices in this area: choices always end up causing problems later. But if you do want to negotiate the secure channel, GDNP is the protocol for the job ;-). > ... using IPv6 link local > addresses between two adjacent neighbours. This way, the ACP > tunnels are independent of correct network wide routing. They > also do not require larger than link local scope addresses, which > would normally need to be configured or maintained. Each AN node > MUST support this function. Certainly that will be the fall-back. We expect GDNP to run over routed connections too, but link-local must always work. But as you describe in section 3.7 and 3.8, routed connections using a ULA are also valuable. (The protocol is not restricted to ULA of course, but the ACP use case can certainly have that restriction). Bottom line: I see no primary difficulty in using GDNP both to help build the ACP and to exploit it. The Domain Identity/Device Certifcate Tag issue needs to be resolved but that should be easy. Regards Brian On 12/02/2015 08:12, Michael Behringer (mbehring) wrote: > We are planning an upgrade, but it'll take some time. I suggest you review now, and we include your comments in the next version. > > Michael > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 29 January 2015 21:57 >> To: anima@ietf.org >> Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-control- >> plane-00.txt >> >> Hi authors of -autonomic-control-plane, >> >> I was thinking of reviewing this draft as a potential application of GDNP, but >> before I do that, are you planning an update soon? >> >> Brian >> >> >> On 04/11/2014 10:36, Brian E Carpenter wrote: >>> Hi, >>> >>> This draft seems fairly clear to me, though I assume it will evolve as >>> other aspects of anima become clear. The proposal to use a ULA prefix >>> (section 3.7) seems good, since it decouples the ACP from all external >>> addressing considerations and will work from a pure factory-reset >>> condition. However, it does raise a question (which also came up in >>> homenet recently). What happens if the network partitions? The ACP >>> will automatically partition too, but it will presumably keep the same >>> /48 ULA prefix everywhere. Does the partitioned network retain the >>> same domain ID in both parts? What happends in the part that doesn't >>> include the trust anchor? What happens if the network recombines - >>> will there be a risk of clashing subnets created during the partition? >>> >>> Also what happens if two previously unrelated networks combine? >>> >>> Brian >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Feb 16 00:44:43 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7C91A1A8B for ; Mon, 16 Feb 2015 00:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=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 eNHRNcYswm63 for ; Mon, 16 Feb 2015 00:44:38 -0800 (PST) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.227]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA201A00C5 for ; Mon, 16 Feb 2015 00:44:38 -0800 (PST) Received: from poro.lan (80.220.64.126) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 54C8F2EA0281D2F5; Mon, 16 Feb 2015 10:42:04 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Markus Stenberg In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923B0455C9@nkgeml512-mbx.china.huawei.com> Date: Mon, 16 Feb 2015 10:42:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <02817548-0AD9-4AE4-B5B1-F97B53C5154E@iki.fi> References: <5D36713D8A4E7348A7E10DF7437A4B923B0455C9@nkgeml512-mbx.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Markus Stenberg , "anima@ietf.org" , "anima-chairs@tools.ietf.org" Subject: Re: [Anima] Call for agenda ANIMA @ IETF92 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 08:44:40 -0000 Name of time slot: DNCP Name of draft(s) (preferred but not necessary): = draft-ietf-homenet-dncp-01 (-01 will show up pre-Dallas) Time requested: 10 min Presenter name(s): Markus Stenberg (TBD) As there was some call for =E2=80=98more generic=E2=80=99 state = synchronization protocol in Hawaii, we obliged by splitting HNCP to DNCP = and HNCP. This is relatively =E2=80=99tightly coupled=E2=80=99 = synchronization protocol, as it essentially ensures state perceived by = all participants matches (about the data they care about, and as a side = effect, about the connectivity graph of participating nodes). This is = more of an awareness presentation than anything else. Name of time slot: DNCP + X !=3D GDNP Name of draft(s) (preferred but not necessary): TBD (I hope to submit = one pre-Dallas) Time requested: 20min Presenter name(s): Markus Stenberg While the name of the time slot is bit of a joke, I am planning to write = up my thoughts on how both loose and tightly coupled synchronization = among anima nodes should work. It will be a DNCP profile, with few more = exchanges defined for pure discovery and negotiation. Also, a =E2=80=9Clar= ge scale=E2=80=9D scalability model is introduced to describe how this = could work with =E2=80=9Cmany=E2=80=9D nodes.=20 (And to be precise, I am not planning to replace GDNP with this draft, = but just to illustrate that with fewer pages of text + DNCP you can = actually have a complete solution from my point of view, with some = running code already forming base of it.) Cheers, -Markus= From nobody Mon Feb 16 04:23:49 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FECF1A1AE5 for ; Mon, 16 Feb 2015 04:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 RjHvwpXPGcuD for ; Mon, 16 Feb 2015 04:23:44 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4371A1AE0 for ; Mon, 16 Feb 2015 04:23:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11480; q=dns/txt; s=iport; t=1424089424; x=1425299024; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=reIwXNCI2nu9rVB5SdlIFraDtzWF19tL7j34iI4aND0=; b=H/qlTBN1CM7nyxrc+z0Ww0brnlqba4ze6bxzy8a/O0Bd8Uh5GIwoCeH6 R8kHMwCjbmw4LnbzKimfAMBZTVVWfM9eR8gwbI/+rXeBMHqWIUJITPKcG A6zpeFPtiIQmiMW+rjx/M1wDTwwfUjAE369wb3Vr44ZVQwvbv5cQ2liJo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A2BgC64OFU/5pdJa1TCYMGUloEgn+9EIIgCoVxAhx6QwEBAQEBAXyEDAEBAQMBAQEBIBE6EAcEAgEIEQEDAQEBAgIGHQMCAgIfBgsUAQIGCAIEARIIEod/AwkIDbVHkQQNhUYBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEhiWuCQ4FPKhYiBoJiLoEUBY84h3GCXoVYhVZDgkaDPiKBfQQdgVBvAYFDfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,587,1418083200"; d="scan'208";a="123963591" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP; 16 Feb 2015 12:23:43 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1GCNhl1021662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Feb 2015 12:23:43 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Mon, 16 Feb 2015 06:23:43 -0600 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] I-D Action: draft-behringer-anima-autonomic-control-plane-00.txt Thread-Index: AQHQSZO+Bvpqyrs2m02MQXzdxO8neZzy/1Mg Date: Mon, 16 Feb 2015 12:23:43 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EC817B@xmb-rcd-x14.cisco.com> References: <20141017131337.4423.84144.idtracker@ietfa.amsl.com> <5457F566.4080409@gmail.com> <54CA9E92.10802@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EB8AB5@xmb-rcd-x14.cisco.com> <54E15BB5.6020005@gmail.com> In-Reply-To: <54E15BB5.6020005@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.136] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-control-plane-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 12:23:47 -0000 VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIEJyaWFuISBJbmxpbmUuLi4NCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFu LmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDogMTYgRmVicnVhcnkgMjAxNSAwMzo1NA0K PiBUbzogTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKTsgYW5pbWFAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtBbmltYV0gSS1EIEFjdGlvbjogZHJhZnQtYmVocmluZ2VyLWFuaW1hLWF1dG9u b21pYy1jb250cm9sLQ0KPiBwbGFuZS0wMC50eHQNCj4gDQo+IEhpIE1pY2hhZWwsDQo+IA0KPiBU aGlzIG1heSBiZSBhIGJpdCBsYXRlIGJ1dCB3ZSd2ZSBiZWVuIHdvcmtpbmcgaGFyZCBvbiB0aGUg R0ROUCBwcm90b2NvbA0KPiBzcGVjLi4uDQo+IA0KPiA+IDMuMS4gUHJlY29uZGl0aW9ucw0KPiA+ DQo+ID4NCj4gPiAgICBFYWNoIGF1dG9ub21pYyBkZXZpY2UgaGFzIGEgZ2xvYmFsbHkgdW5pcXVl IGRvbWFpbiBjZXJ0aWZpY2F0ZSwgd2l0aA0KPiA+ICAgIHdoaWNoIGl0IGNhbiBjcnlwdG9ncmFw aGljYWxseSBhc3NlcnQgaXRzIG1lbWJlcnNoaXAgb2YgdGhlIGRvbWFpbi4NCj4gPiAgICBUaGUg ZG9jdW1lbnQgW0ktRC5wcml0aWtpbi1ib290c3RyYXBwaW5nLWtleWluZnJhc3RydWN0dXJlc10N Cj4gPiAgICBkZXNjcmliZXMgaG93IGEgZG9tYWluIGNlcnRpZmljYXRlIGNhbiBiZSBhdXRvbWF0 aWNhbGx5IGFuZCBzZWN1cmVseQ0KPiA+ICAgIGRlcml2ZWQgLi4uDQo+IA0KPiBPbmUgdGhpbmcg d2UgbmVlZCB0byBhZ3JlZSBvbiBpcyB0aGUgc2l6ZSBvZiB0aGlzIGNlcnQsIG9yIHJhdGhlciBv ZiBpdHMgaGFzaCwNCj4gd2hpY2ggZHJhZnQtcHJpdGlraW4gY2FsbHMgdGhlICBEb21haW4gSWRl bnRpdHkgYW5kIHNldHMgYXQgMTYwIGJpdHMuIEluIHRoZQ0KPiBHRE5QIGRyYWZ0IHdlIHBpY2tl ZCAxMjggYml0cyBhbmQgY2FsbGVkIGl0IERldmljZSBDZXJ0aWZjYXRlIFRhZy4gVGhlIGdvb2QN Cj4gbmV3cyBpcyB0aGF0IHdlIGFsbCBhZ3JlZSB0aGF0IGl0J3MgbmVlZGVkLg0KDQpZZXMsIEkg dGhpbmsgd2UgYWxsIGFncmVlIHRoYXQgY2VydGlmaWNhdGVzIGFyZSB0aGUgb25seSB3YXkgdG8g bWFrZSBkZXZpY2VzIGF1dG9ub21pYyAtIG1ha2Ugc3VyZSB0aGV5IGNhbiB0YWxrIHRvIGVhY2gg b3RoZXIuIEEgcG9pbnQgd2VsbCB3b3J0aCBub3RpbmcgZG93bi4gDQoNClJlZ2FyZGluZyB0aGUg c2l6ZSBvZiB0aGUgaGFzaCwgbmVlZCB0byB0aGluayBtb3JlLCBidXQgcXVpY2sgcmVhY3Rpb24g aXMgdGhhdCBhIFRMViBzaG91bGQgYWxsb3cgZmxleGliaWxpdHkuIA0KDQo+ID4gMy4yLiBBZGph Y2VuY3kgRGlzY292ZXJ5DQo+IA0KPiBUaGlzIHdlIGNhbiBjZXJ0YWlubHkgZG8gd2l0aCB0aGUg R0ROUCBEaXNjb3ZlcnkgYW5kIFN5bmNocm9uaXphdGlvbg0KPiBtZWNoYW5pc21zLiBTb21lIGRl dGFpbHMgVEJEIG9mIGNvdXJzZSwgYnV0IGl0J3MgYSB0ZXh0IGJvb2sgYXBwbGljYXRpb24gb2YN Cj4gR0ROUC4NCg0KVGhpcyBpcyBvZiBjb3Vyc2UgdGhlIGludGVudGlvbiA7LSkgICANCg0KPiA+ DQo+ID4gMy4zLiBBdXRoZW50aWNhdGluZyBOZWlnaGJvcnMNCj4gPg0KPiA+DQo+ID4gICAgRWFj aCBuZWlnaGJvdXIgaW4gdGhlIGFkamFjZW5jeSB0YWJsZSBpcyBhdXRoZW50aWNhdGVkLg0KPiAN Cj4gSSB0aGluayB0aGlzIGZhbGxzIHJpZ2h0IG91dCBvZiBEaXNjb3Zlcnkgc2luY2UgdGhlIGRp c2NvdmVyeSByZXNwb25zZSB3b3VsZA0KPiBjb250YWluIHRoZSByZWxldmFudCBEb21haW4gSWRl bnRpdHkgYS5rLmEuIERldmljZSBDZXJ0aWZjYXRlIFRhZyBhbmQgdGhhdA0KPiBjYW4gYmUgY2hl Y2tlZCB3aXRoIHRoZSBDQS4NCg0KUmlnaHQsIGJ1dCBoZXJlIHRoZSBkZXZpbCBpcyBpbiB0aGUg ZGV0YWlsLiBXZSBuZWVkIGEgc2VjdXJpdHkgYXNzb2NpYXRpb24gd2l0aCB0aGUgcGVlciBkZXZp Y2UuIFRoaXMgYXNzb2NpYXRpb24gY2FuIGJlIGVzdGFibGlzaGVkIHZpYSB0aGUgZGlzY292ZXJ5 IHByb3RvY29sLCBhbmQgcmUtdXNlZCBmb3Igc3Vic2VxdWVudCBjb21tdW5pY2F0aW9ucywgc3Vj aCBhcyB0aGUgQUNQLiBPciwgd2UgY291bGQgaGF2ZSB0aGUgQUNQIGVzdGFibGlzaCBpdHMgb3du IHNlY3VyaXR5IGFzc29jaWF0aW9uLiBNeSBmZWVsaW5nIGlzIHRoYXQgd2Ugc2hvdWxkIGVzdGFi bGlzaCBvbmUgc2luZ2xlIFNBIGFuZCB1c2UgaXQgZm9yIGFsbCBzdWJzZXF1ZW50IG9wZXJhdGlv bnMuIFdlIG5lZWQgdG8gY292ZXIgdGhpcyBwb2ludCBpbiB0aGUgcmVmZXJlbmNlIGFyY2hpdGVj dHVyZS4gDQoNCj4gTm90ZSB0aGF0IGRyYWZ0LWlldGYtaG9tZW5ldC1kbmNwIGhhcyBhIHF1aXRl IGNvbXBsaWNhdGVkICJ0cnVzdCB2ZXJkaWN0Ig0KPiBtZWNoYW5pc20uIEkgcGVyc29uYWxseSBk b24ndCB0aGluayB0aGF0IGlzIG5lY2Vzc2FyeSwgYnV0IHdlIHNob3VsZA0KPiBwcm9iYWJseSBm aW5kIG91dCB3aHkgdGhleSBpbmNsdWRlZCBpdC4NCg0KTXkgY3VycmVudCB1bmRlcnN0YW5kaW5n ICh3aGljaCBjb3VsZCBiZSB3cm9uZykgaXMgdGhhdCBob21lbmV0IHRyaWVzIHRvIGF2b2lkIGEg c2luZ2xlIHRydXN0IGFuY2hvciwgb3IgYSBzaW5nbGUgc291cmNlIG9mIHRydXRoLCB3aGljaCB0 aGV5IGFsc28gY2FsbCB0aGUgImdvZCBib3giLiBQZXJzb25hbGx5LCBJIGRvbid0IHRoaW5rIGhh dmluZyBhIHRydXN0IGFuY2hvciBpbiBhIGhvbWVuZXQgaXMgYSBiaWcgZGVhbCwgYnV0IG9waW5p b25zIHZhcnkgaGVyZS4gSW4gYW55IGNhc2UsIGhhdmluZyBhIGRpc3RyaWJ1dGVkIG1lY2hhbmlz bSBjb3VsZCBiZSB2ZXJ5IGVsZWdhbnQgZm9yIHNvbWUgc2NlbmFyaW9zLCBzbyB3ZSBzaG91bGQg YXQgbGVhc3QgbG9vayBhdCBpdCBhbmQgY29uc2lkZXIgaXQgKHN0aWxsIGhhdmUgdG8gcmVhZCB0 aGUgZHJhZnQuLi4pLiANCg0KVGhpcyB3b3VsZCBiZSB0aGUgdWx0aW1hdGUgaW4gImRpc3RyaWJ1 dGlvbiIgaWYgeW91IGRvbid0IGV2ZW4gaGF2ZSBhIGNlbnRyYWxpc2VkIHRydXN0IGFuY2hvci4g UGhpbG9zb3BoaWNhbGx5IEkgcXVpdGUgbGlrZSB0aGlzIGlkZWEuIFdlIG5lZWQgdG8gY2hlY2sg dGhlIGRldGFpbHMuICANCg0KPiA+IDMuNC4gQ2FwYWJpbGl0eSBOZWdvdGlhdGlvbg0KPiAuLi4N Cj4gPiAgICBUbyBlc3RhYmxpc2ggYSB0cnVzdGVkIHNlY3VyZQ0KPiA+ICAgIGNvbW11bmljYXRp b24gY2hhbm5lbCwgZGV2aWNlcyBtdXN0IGJlIGFibGUgdG8gbmVnb3RpYXRlIHdpdGggZWFjaA0K PiA+ICAgIG5laWdoYm91ciBhIHNldCBvZiBwYXJhbWV0ZXJzIGZvciBlc3RhYmxpc2hpbmcgdGhl IGNvbW11bmljYXRpb24NCj4gPiAgICBjaGFubmVsLCBtb3N0IG5vdGFibHkgY2hhbm5lbCB0eXBl IGFuZCBzZWN1cml0eSB0eXBlLg0KPiANCj4gSSB0aGluayBHRE5QIGlzIHZlcnkgbGlrZWx5IHRv IGVuZCB1cCBzaW1wbHkgdXNpbmcgVExTIChhbHRob3VnaCB0aGF0J3Mgbm90DQoNClRMUz8gTm90 IERUTFM/IChzb3JyeSBJIGhhdmVuJ3QgcmVhZCBhbGwgdGhlIG1haWxzKQ0KDQo+IHdoYXQgdGhl IGRyYWZ0IHNheXMgcmlnaHQgbm93LCB0aGUgYXJndW1lbnRzIGZyb20gdGhlIEROQ1AgdGVhbSBo YXZlDQo+IGFsbW9zdCBjb252aW5jZWQgbWUpLiBJbiBhbnkgY2FzZSwgc2VjdXJlIGNoYW5uZWxz IGJldHdlZW4gR0ROUCBub2Rlcw0KPiBhcmUgZnVuZGFtZW50YWwsIGFzIGZvciB0aGUgQUNQLiBJ IGhhdmUgZG91YnRzIHdoZXRoZXIgd2Ugc2hvdWxkIGxlYXZlDQo+IG9wdGlvbnMgb3IgY2hvaWNl cyBpbiB0aGlzIGFyZWE6IGNob2ljZXMgYWx3YXlzIGVuZCB1cCBjYXVzaW5nIHByb2JsZW1zDQo+ IGxhdGVyLg0KDQpXZSBoYXZlIGEgbnVtYmVyIG9mIGFyY2hpdGVjdHVyYWwgb3B0aW9ucyBoZXJl OiANCi0gV2UgY291bGQgdXNlIEdETlAgZXN0YWJsaXNoIGFuZCBtYWludGFpbiBhIHNlY3VyaXR5 IGFzc29jaWF0aW9uLCBzYXkgRFRMUy4gQW5kIHRoZW4gbmVnb3RpYXRlIGEgc2VwYXJhdGUgY2hh bm5lbCBmb3IgdGhlIEFDUC4gDQotIE9yIHdlIGNvdWxkIGVzdGFibGlzaCB3aXRoIEdETlAgYSBz ZWN1cml0eSBhc3NvY2lhdGlvbiwgYW5kIHVzZSB0aGF0IHNhbWUgZm9yIHRoZSBBQ1AuIA0KDQpB dCB0aGUgZW5kLCB0aGUgQUNQIGVzc2VudGlhbGx5ICppcyogYSBwZXJzaXN0YW50IHNlY3VyaXR5 IGFzc29jaWF0aW9uIGJldHdlZW4gbm9kZXMsIHNvIEkgdGhpbmsgd2UgY291bGQgdXNlIEdETlAg dG8gZGlyZWN0bHkgZXN0YWJsaXNoIGEgc2VjdXJlIGNoYW5uZWwgd2hpY2ggZXNzZW50aWFsbHkg YmVjb21lcyB0aGUgQUNQIGlmIHdlIHByb3ZpZGUgY29udGV4dHVhbCBzZXBhcmF0aW9uIHdpdGgg dGhlIGRhdGEgcGxhbmUuIEFnYWluLCB0aGlzIG5lZWRzIHRvIGdvIGludG8gdGhlIHJlZmVyZW5j ZSBhcmNoaXRlY3R1cmUuIA0KIA0KPiBCdXQgaWYgeW91IGRvIHdhbnQgdG8gbmVnb3RpYXRlIHRo ZSBzZWN1cmUgY2hhbm5lbCwgR0ROUCBpcyB0aGUgcHJvdG9jb2wgZm9yDQo+IHRoZSBqb2IgOy0p Lg0KDQpBZ3JlZSwgd2UgdGhpbmsgdGhlIHNhbWUgd2F5LiANCg0KPiA+ICAgICAgIC4uLiB1c2lu ZyBJUHY2IGxpbmsgbG9jYWwNCj4gPiAgICAgICBhZGRyZXNzZXMgYmV0d2VlbiB0d28gYWRqYWNl bnQgbmVpZ2hib3Vycy4gIFRoaXMgd2F5LCB0aGUgQUNQDQo+ID4gICAgICAgdHVubmVscyBhcmUg aW5kZXBlbmRlbnQgb2YgY29ycmVjdCBuZXR3b3JrIHdpZGUgcm91dGluZy4gIFRoZXkNCj4gPiAg ICAgICBhbHNvIGRvIG5vdCByZXF1aXJlIGxhcmdlciB0aGFuIGxpbmsgbG9jYWwgc2NvcGUgYWRk cmVzc2VzLCB3aGljaA0KPiA+ICAgICAgIHdvdWxkIG5vcm1hbGx5IG5lZWQgdG8gYmUgY29uZmln dXJlZCBvciBtYWludGFpbmVkLiAgRWFjaCBBTiBub2RlDQo+ID4gICAgICAgTVVTVCBzdXBwb3J0 IHRoaXMgZnVuY3Rpb24uDQo+IA0KPiBDZXJ0YWlubHkgdGhhdCB3aWxsIGJlIHRoZSBmYWxsLWJh Y2suIFdlIGV4cGVjdCBHRE5QIHRvIHJ1biBvdmVyIHJvdXRlZA0KPiBjb25uZWN0aW9ucyB0b28s IGJ1dCBsaW5rLWxvY2FsIG11c3QgYWx3YXlzIHdvcmsuIEJ1dCBhcyB5b3UgZGVzY3JpYmUgaW4N Cj4gc2VjdGlvbiAzLjcgYW5kIDMuOCwgcm91dGVkIGNvbm5lY3Rpb25zIHVzaW5nIGEgVUxBIGFy ZSBhbHNvIHZhbHVhYmxlLg0KPiAoVGhlIHByb3RvY29sIGlzIG5vdCByZXN0cmljdGVkIHRvIFVM QSBvZiBjb3Vyc2UsIGJ1dCB0aGUgQUNQIHVzZSBjYXNlIGNhbg0KPiBjZXJ0YWlubHkgaGF2ZSB0 aGF0IHJlc3RyaWN0aW9uKS4NCg0KSSAqdGhpbmsqIHdlIGFyZSBvbiB0aGUgc2FtZSBwYWdlLiBM ZXQgbWUgZGVzY3JpYmUgdGhpcyBmcm9tIG15IHBvaW50IG9mIHZpZXcsIHRvIHNlZSB3aGV0aGVy IHRoYXQncyB0cnVlLiANCg0KVG8gbWUsIEdETlAgYmV0d2VlbiBhZGphY2VudCBub2RlcyBzaG91 bGQgQUxXQVlTIHVzZSBsaW5rIGxvY2FsIChQcm9iYWJseSBhICJNVVNUIiBpbiB0aGUgZG9jdW1l bnQpLiBMaW5rIGxvY2FsIGhhcyBubyBkZXBlbmRlbmN5IG9uIGNvcnJlY3QgY29uZmlndXJhdGlv biwgc28gY29uZmxpY3RzIHdpdGggd2hhdCB0aGUgYWRtaW5pc3RyYXRvciBkb2VzIGFyZSBtaW5p bWFsLiBJIGZlZWwgdmVyeSBzdHJvbmdseSBhYm91dCB0aGlzLiBJIHNlZSBubyByZWFzb24gdG8g Tk9UIHVzZSBsaW5rIGxvY2FsLiAoQnV0IGhhcHB5IHRvIGJlIGVkdWNhdGVkKS4gDQoNCk5vdywg d2UgYWxzbyB3YW50IHRvIG5lZ290aWF0ZSAvIGRpc2NvdmVyIG5vZGVzIHRoYXQgYXJlIG5vdCBk aXJlY3RseSBhZGphY2VudC4gRm9yIHRoaXMgd2UgbmVlZCB1bmljYXN0IChvciBtdWx0aWNhc3Qs IGFueWNhc3QsIHBvc3NpYmx5KSB0byByb3V0YWJsZSBhZGRyZXNzZXMuIFRvIG1lLCB0aG9zZSBy b3V0YWJsZSBhZGRyZXNzZXMgY291bGQgZWl0aGVyIGJlIGRlcml2ZWQgYXV0b21hdGljYWxseSwg aW4gd2hpY2ggY2FzZSBpdCB3b3VsZCBsaWtlbHkgYmUgVUxBLCBvciBjb25maWd1cmVkLCBpbiB3 aGljaCBjYXNlIHdlJ2QgaGF2ZSBVTEEgb3IgZ2xvYmFsIGFkZHJlc3Nlcy4gDQoNCkFyZSB3ZSBv biB0aGUgc2FtZSBwYWdlPyAoQW5kIGFwb2xvZ2llcyBpZiB5b3VyIGRyYWZ0IG1lbnRpb25zIHRo aXMsIGhhdmVuJ3QgcmVhZCB0aGUgbGFzdCB0d28gdmVyc2lvbnMgeWV0LCBzaWdoLi4uKQ0KIA0K PiBCb3R0b20gbGluZTogSSBzZWUgbm8gcHJpbWFyeSBkaWZmaWN1bHR5IGluIHVzaW5nIEdETlAg Ym90aCB0byBoZWxwIGJ1aWxkIHRoZQ0KPiBBQ1AgYW5kIHRvIGV4cGxvaXQgaXQuIFRoZSBEb21h aW4gSWRlbnRpdHkvRGV2aWNlIENlcnRpZmNhdGUgVGFnIGlzc3VlDQo+IG5lZWRzIHRvIGJlIHJl c29sdmVkIGJ1dCB0aGF0IHNob3VsZCBiZSBlYXN5Lg0KDQpBZ3JlZS4gDQoNCk1pY2hhZWwNCiAN Cj4gUmVnYXJkcw0KPiAgICAgQnJpYW4NCj4gT24gMTIvMDIvMjAxNSAwODoxMiwgTWljaGFlbCBC ZWhyaW5nZXIgKG1iZWhyaW5nKSB3cm90ZToNCj4gPiBXZSBhcmUgcGxhbm5pbmcgYW4gdXBncmFk ZSwgYnV0IGl0J2xsIHRha2Ugc29tZSB0aW1lLiBJIHN1Z2dlc3QgeW91IHJldmlldw0KPiBub3cs IGFuZCB3ZSBpbmNsdWRlIHlvdXIgY29tbWVudHMgaW4gdGhlIG5leHQgdmVyc2lvbi4NCj4gPg0K PiA+IE1pY2hhZWwNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBG cm9tOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBC cmlhbiBFDQo+ID4+IENhcnBlbnRlcg0KPiA+PiBTZW50OiAyOSBKYW51YXJ5IDIwMTUgMjE6NTcN Cj4gPj4gVG86IGFuaW1hQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbQW5pbWFdIEktRCBB Y3Rpb246DQo+ID4+IGRyYWZ0LWJlaHJpbmdlci1hbmltYS1hdXRvbm9taWMtY29udHJvbC0NCj4g Pj4gcGxhbmUtMDAudHh0DQo+ID4+DQo+ID4+IEhpIGF1dGhvcnMgb2YgLWF1dG9ub21pYy1jb250 cm9sLXBsYW5lLA0KPiA+Pg0KPiA+PiBJIHdhcyB0aGlua2luZyBvZiByZXZpZXdpbmcgdGhpcyBk cmFmdCBhcyBhIHBvdGVudGlhbCBhcHBsaWNhdGlvbiBvZg0KPiA+PiBHRE5QLCBidXQgYmVmb3Jl IEkgZG8gdGhhdCwgYXJlIHlvdSBwbGFubmluZyBhbiB1cGRhdGUgc29vbj8NCj4gPj4NCj4gPj4g ICAgIEJyaWFuDQo+ID4+DQo+ID4+DQo+ID4+IE9uIDA0LzExLzIwMTQgMTA6MzYsIEJyaWFuIEUg Q2FycGVudGVyIHdyb3RlOg0KPiA+Pj4gSGksDQo+ID4+Pg0KPiA+Pj4gVGhpcyBkcmFmdCBzZWVt cyBmYWlybHkgY2xlYXIgdG8gbWUsIHRob3VnaCBJIGFzc3VtZSBpdCB3aWxsIGV2b2x2ZQ0KPiA+ Pj4gYXMgb3RoZXIgYXNwZWN0cyBvZiBhbmltYSBiZWNvbWUgY2xlYXIuIFRoZSBwcm9wb3NhbCB0 byB1c2UgYSBVTEENCj4gPj4+IHByZWZpeCAoc2VjdGlvbiAzLjcpIHNlZW1zIGdvb2QsIHNpbmNl IGl0IGRlY291cGxlcyB0aGUgQUNQIGZyb20gYWxsDQo+ID4+PiBleHRlcm5hbCBhZGRyZXNzaW5n IGNvbnNpZGVyYXRpb25zIGFuZCB3aWxsIHdvcmsgZnJvbSBhIHB1cmUNCj4gPj4+IGZhY3Rvcnkt cmVzZXQgY29uZGl0aW9uLiBIb3dldmVyLCBpdCBkb2VzIHJhaXNlIGEgcXVlc3Rpb24gKHdoaWNo DQo+ID4+PiBhbHNvIGNhbWUgdXAgaW4gaG9tZW5ldCByZWNlbnRseSkuIFdoYXQgaGFwcGVucyBp ZiB0aGUgbmV0d29yaw0KPiA+Pj4gcGFydGl0aW9ucz8gVGhlIEFDUCB3aWxsIGF1dG9tYXRpY2Fs bHkgcGFydGl0aW9uIHRvbywgYnV0IGl0IHdpbGwNCj4gPj4+IHByZXN1bWFibHkga2VlcCB0aGUg c2FtZQ0KPiA+Pj4gLzQ4IFVMQSBwcmVmaXggZXZlcnl3aGVyZS4gRG9lcyB0aGUgcGFydGl0aW9u ZWQgbmV0d29yayByZXRhaW4gdGhlDQo+ID4+PiBzYW1lIGRvbWFpbiBJRCBpbiBib3RoIHBhcnRz PyBXaGF0IGhhcHBlbmRzIGluIHRoZSBwYXJ0IHRoYXQgZG9lc24ndA0KPiA+Pj4gaW5jbHVkZSB0 aGUgdHJ1c3QgYW5jaG9yPyBXaGF0IGhhcHBlbnMgaWYgdGhlIG5ldHdvcmsgcmVjb21iaW5lcyAt DQo+ID4+PiB3aWxsIHRoZXJlIGJlIGEgcmlzayBvZiBjbGFzaGluZyBzdWJuZXRzIGNyZWF0ZWQg ZHVyaW5nIHRoZSBwYXJ0aXRpb24/DQo+ID4+Pg0KPiA+Pj4gQWxzbyB3aGF0IGhhcHBlbnMgaWYg dHdvIHByZXZpb3VzbHkgdW5yZWxhdGVkIG5ldHdvcmtzIGNvbWJpbmU/DQo+ID4+Pg0KPiA+Pj4g ICAgQnJpYW4NCj4gPj4+DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4+IEFuaW1hIG1haWxpbmcgbGlzdA0KPiA+PiBBbmltYUBp ZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1h DQo+ID4NCg== From nobody Mon Feb 16 04:23:53 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C415A1A1AE5 for ; Mon, 16 Feb 2015 04:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 lx_uzR6-2GfJ for ; Mon, 16 Feb 2015 04:23:46 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A4FD1A1ADC for ; Mon, 16 Feb 2015 04:23:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3066; q=dns/txt; s=iport; t=1424089426; x=1425299026; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jG0A0SAdkU1HbCu/bRK04FqysvcJydB2HzC/Kgp4ekU=; b=eMlu5CSQV2XaG7CMBu15ophsICLBpG+cKYW2pzlDITcJdzpnkB1hSeYC lVjpm54Z/5qAxw+82QkkWNXKw4hHFrvX8ZPpPRjG5zYhAOuA1HFkF8lsC eJf5j9udMVZFoIkqe4DoBLMzFOPysNov2hXFEfNh08x7dsj6qCdWUYroM Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AkBgBF4OFU/40NJK1cgwZSVQUEwA+CIAqFcQKBFkMBAQEBAQF8hAwBAQEDAQEBATc0EAcEAgEIEQQBAQEKFAkHJwsUCQgCBAESCAGIHAgIBcwkAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sMhDwzBQaDEIEUBY84g1eGeDiCVYghRoYBIoNubwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.09,587,1418083200"; d="scan'208";a="123888646" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP; 16 Feb 2015 12:23:45 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t1GCNj4n001518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Feb 2015 12:23:45 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Mon, 16 Feb 2015 06:23:45 -0600 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] I-D Action: draft-pritikin-anima-bootstrapping-keyinfra-01.txt Thread-Index: AQHQSY79sM8YSmicoUip6YrpyB/I05zzByNg Date: Mon, 16 Feb 2015 12:23:44 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EC8183@xmb-rcd-x14.cisco.com> References: <20150213080241.29611.49937.idtracker@ietfa.amsl.com> <54E153AA.1070208@gmail.com> In-Reply-To: <54E153AA.1070208@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] I-D Action: draft-pritikin-anima-bootstrapping-keyinfra-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 12:23:48 -0000 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: 16 February 2015 03:19 > To: Anima WG > Subject: Re: [Anima] I-D Action: draft-pritikin-anima-bootstrapping- > keyinfra-01.txt >=20 > Thanks for this update. I think my main points have been well answered. >=20 > We're hoping to get an update of the GDNP protocol draft out in a few day= s. > An interesting exercise would be to do a walkthrough of the whole process > of bootstrapping a new device using both drafts. Maybe we need to find a > very large whiteboard in Dallas. Agree, we need to put all the bits together now, and an in-person meeting w= ould definitely make this easier.=20 Michael =20 > Regards > Brian >=20 > On 13/02/2015 21:02, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Bootstrapping Key Infrastructures > > Authors : Max Pritikin > > Michael H. Behringer > > Steinthor Bjarnason > > Filename : draft-pritikin-anima-bootstrapping-keyinfra-01.txt > > Pages : 23 > > Date : 2015-02-13 > > > > Abstract: > > This document specifies automated bootstrapping of an key > > infrastructure using vendor installed IEEE 802.1AR manufacturing > > installed certificates, in combination with a vendor based service o= n > > the Internet. Before being authenticated, a new device has only > > link-local connectivity, and does not require a routable address. > > When a vendor provides an Internet based service, devices can be > > forced to join only specific domains but for constrained environment= s > > we describe a variety of options that allow bootstrapping to proceed= . > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-pritikin-anima-bootstrapping-ke > > yinfra/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfra > > -01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-pritikin-anima-bootstrapping-k= e > > yinfra-01 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Feb 16 11:06:00 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFBD1A1B36 for ; Mon, 16 Feb 2015 11:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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 H73Ku_Dhn9qy for ; Mon, 16 Feb 2015 11:05:55 -0800 (PST) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ED291A1ADA for ; Mon, 16 Feb 2015 11:05:55 -0800 (PST) Received: by pdjy10 with SMTP id y10so38205739pdj.13 for ; Mon, 16 Feb 2015 11:05:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QLYStrwgRv1rxAD5eOpvvaaplP9+JYT5Ohn8J0oL7+M=; b=J2j3c0mStVd+LSAfeUne1cNq97mpG020WQHo+ZMu7A+AylBXGfd4L9KAffUTVF+I58 Gwoovl+1x4B5bpWI0LEDfJ+vKTZGl8CS3F9dJj/79VG1EU8SBf9daL2W6RcjBAULRjdo qcGZnVGbrprryUwzpJjKJDId3rhZbeHCxNvG+tWqdLHkSHCyulWRhrSJ78xXYMLmn21T agMarw7+R8D6xryhI8Dtzjbi93BSKY7zOUTF47O0PwWlwQRX5rsPJjpL5bK4cUBEXzch ByfAqF/XMZlk+742mItpc7pjERWM8nA6LEAFmBMlbIAvaU2g5o2pbsJuL0rjAzTHS0rj C4Ig== X-Received: by 10.68.192.101 with SMTP id hf5mr42003783pbc.117.1424113555246; Mon, 16 Feb 2015 11:05:55 -0800 (PST) Received: from ?IPv6:2406:e007:635d:1:28cc:dc4c:9703:6781? ([2406:e007:635d:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id pr2sm15335252pbb.88.2015.02.16.11.05.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Feb 2015 11:05:54 -0800 (PST) Message-ID: <54E23F9D.3030709@gmail.com> Date: Tue, 17 Feb 2015 08:06:05 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , "anima@ietf.org" References: <20141017131337.4423.84144.idtracker@ietfa.amsl.com> <5457F566.4080409@gmail.com> <54CA9E92.10802@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EB8AB5@xmb-rcd-x14.cisco.com> <54E15BB5.6020005@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EC817B@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EC817B@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-control-plane-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 19:05:59 -0000 Hi again, On 17/02/2015 01:23, Michael Behringer (mbehring) wrote: > Thanks for your comments Brian! Inline... Ditto... > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: 16 February 2015 03:54 >> To: Michael Behringer (mbehring); anima@ietf.org >> Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-control- >> plane-00.txt >> >> Hi Michael, >> >> This may be a bit late but we've been working hard on the GDNP protocol >> spec... >> >>> 3.1. Preconditions >>> >>> >>> Each autonomic device has a globally unique domain certificate, with >>> which it can cryptographically assert its membership of the domain. >>> The document [I-D.pritikin-bootstrapping-keyinfrastructures] >>> describes how a domain certificate can be automatically and securely >>> derived ... >> >> One thing we need to agree on is the size of this cert, or rather of its hash, >> which draft-pritikin calls the Domain Identity and sets at 160 bits. In the >> GDNP draft we picked 128 bits and called it Device Certifcate Tag. The good >> news is that we all agree that it's needed. > > Yes, I think we all agree that certificates are the only way to make devices autonomic - make sure they can talk to each other. A point well worth noting down. > > Regarding the size of the hash, need to think more, but quick reaction is that a TLV should allow flexibility. > >>> 3.2. Adjacency Discovery >> >> This we can certainly do with the GDNP Discovery and Synchronization >> mechanisms. Some details TBD of course, but it's a text book application of >> GDNP. > > This is of course the intention ;-) > >>> >>> 3.3. Authenticating Neighbors >>> >>> >>> Each neighbour in the adjacency table is authenticated. >> >> I think this falls right out of Discovery since the discovery response would >> contain the relevant Domain Identity a.k.a. Device Certifcate Tag and that >> can be checked with the CA. > > Right, but here the devil is in the detail. We need a security association with the peer device. This association can be established via the discovery protocol, and re-used for subsequent communications, such as the ACP. Or, we could have the ACP establish its own security association. My feeling is that we should establish one single SA and use it for all subsequent operations. We need to cover this point in the reference architecture. I think I agree, except that anything can go wrong at any time, so it must always be possible to recreate the SA. I don't think that changes whether we use (D)TLS or IPsec - just keep the channel open unless it breaks or you run out of resource. > >> Note that draft-ietf-homenet-dncp has a quite complicated "trust verdict" >> mechanism. I personally don't think that is necessary, but we should >> probably find out why they included it. > > My current understanding (which could be wrong) is that homenet tries to avoid a single trust anchor, or a single source of truth, which they also call the "god box". Personally, I don't think having a trust anchor in a homenet is a big deal, but opinions vary here. In any case, having a distributed mechanism could be very elegant for some scenarios, so we should at least look at it and consider it (still have to read the draft...). > > This would be the ultimate in "distribution" if you don't even have a centralised trust anchor. Philosophically I quite like this idea. We need to check the details. > >>> 3.4. Capability Negotiation >> ... >>> To establish a trusted secure >>> communication channel, devices must be able to negotiate with each >>> neighbour a set of parameters for establishing the communication >>> channel, most notably channel type and security type. >> >> I think GDNP is very likely to end up simply using TLS (although that's not > > TLS? Not DTLS? (sorry I haven't read all the mails) Well, it's an open issue right now; but I am 99% sure we'll need a TLS mode for cases where the objective is a large data structure. I also have a feeling that DTLS introduces a significant start-up overhead that makes the difference compared to TLS start-up very small. > >> what the draft says right now, the arguments from the DNCP team have >> almost convinced me). In any case, secure channels between GDNP nodes >> are fundamental, as for the ACP. I have doubts whether we should leave >> options or choices in this area: choices always end up causing problems >> later. > > We have a number of architectural options here: > - We could use GDNP establish and maintain a security association, say DTLS. And then negotiate a separate channel for the ACP. > - Or we could establish with GDNP a security association, and use that same for the ACP. > > At the end, the ACP essentially *is* a persistant security association between nodes, so I think we could use GDNP to directly establish a secure channel which essentially becomes the ACP if we provide contextual separation with the data plane. Again, this needs to go into the reference architecture. > >> But if you do want to negotiate the secure channel, GDNP is the protocol for >> the job ;-). > > Agree, we think the same way. > >>> ... using IPv6 link local >>> addresses between two adjacent neighbours. This way, the ACP >>> tunnels are independent of correct network wide routing. They >>> also do not require larger than link local scope addresses, which >>> would normally need to be configured or maintained. Each AN node >>> MUST support this function. >> >> Certainly that will be the fall-back. We expect GDNP to run over routed >> connections too, but link-local must always work. But as you describe in >> section 3.7 and 3.8, routed connections using a ULA are also valuable. >> (The protocol is not restricted to ULA of course, but the ACP use case can >> certainly have that restriction). > > I *think* we are on the same page. Let me describe this from my point of view, to see whether that's true. > > To me, GDNP between adjacent nodes should ALWAYS use link local (Probably a "MUST" in the document). Link local has no dependency on correct configuration, so conflicts with what the administrator does are minimal. I feel very strongly about this. I see no reason to NOT use link local. (But happy to be educated). We don't state that at the moment, although we do state the inverse: a link-local address MUST NOT be used in a Divert option, because that is intended to send you off-link. There's a slight complication there, which is that a device (router) that is sending a Divert option needs to know the appropriate routeable address. We need to figure out how it learns it in the first place. But I agree that link-local is a safer choice whenever possible. > Now, we also want to negotiate / discover nodes that are not directly adjacent. For this we need unicast (or multicast, anycast, possibly) to routable addresses. To me, those routable addresses could either be derived automatically, in which case it would likely be ULA, or configured, in which case we'd have ULA or global addresses. The GDNP draft now says that a router running GDNP relays discovery messages to all its interfaces, so that a non-router doesn't need to worry about this issue. > > Are we on the same page? (And apologies if your draft mentions this, haven't read the last two versions yet, sigh...) We're pretty close, I think, but there's work to be done... Brian > >> Bottom line: I see no primary difficulty in using GDNP both to help build the >> ACP and to exploit it. The Domain Identity/Device Certifcate Tag issue >> needs to be resolved but that should be easy. > > Agree. > > Michael > >> Regards >> Brian >> On 12/02/2015 08:12, Michael Behringer (mbehring) wrote: >>> We are planning an upgrade, but it'll take some time. I suggest you review >> now, and we include your comments in the next version. >>> >>> Michael >>> >>>> -----Original Message----- >>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >>>> Carpenter >>>> Sent: 29 January 2015 21:57 >>>> To: anima@ietf.org >>>> Subject: Re: [Anima] I-D Action: >>>> draft-behringer-anima-autonomic-control- >>>> plane-00.txt >>>> >>>> Hi authors of -autonomic-control-plane, >>>> >>>> I was thinking of reviewing this draft as a potential application of >>>> GDNP, but before I do that, are you planning an update soon? >>>> >>>> Brian >>>> >>>> >>>> On 04/11/2014 10:36, Brian E Carpenter wrote: >>>>> Hi, >>>>> >>>>> This draft seems fairly clear to me, though I assume it will evolve >>>>> as other aspects of anima become clear. The proposal to use a ULA >>>>> prefix (section 3.7) seems good, since it decouples the ACP from all >>>>> external addressing considerations and will work from a pure >>>>> factory-reset condition. However, it does raise a question (which >>>>> also came up in homenet recently). What happens if the network >>>>> partitions? The ACP will automatically partition too, but it will >>>>> presumably keep the same >>>>> /48 ULA prefix everywhere. Does the partitioned network retain the >>>>> same domain ID in both parts? What happends in the part that doesn't >>>>> include the trust anchor? What happens if the network recombines - >>>>> will there be a risk of clashing subnets created during the partition? >>>>> >>>>> Also what happens if two previously unrelated networks combine? >>>>> >>>>> Brian >>>>> >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >>> From nobody Mon Feb 16 11:16:12 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95911A3BA6 for ; Mon, 16 Feb 2015 11:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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 PXgHyydnvHE9 for ; Mon, 16 Feb 2015 11:16:08 -0800 (PST) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54BF1A1AE7 for ; Mon, 16 Feb 2015 11:16:08 -0800 (PST) Received: by pdbnh10 with SMTP id nh10so34077276pdb.11 for ; Mon, 16 Feb 2015 11:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RH1PS+xmoGnfixW1H8MZOFeoh95aOu9a1QD69fx3cPw=; b=tVItMz9VIFvdrnFNlEpX4mVXZ7L+bGU8w1ZU112wOUzdmgD/ukQQTyQWiDO372AFfC lGar+CmpN9WswRjhcq1/diSJ3PIOWwcIRUQmgHtVFJD0UpLpFFLGmU8rO9l4xz4Dqy8z ZEYWHKMYWuYp5jwEA69IZ8+00qZUPhaYQ4LjpSBKpUZ5PqNi3ogig0wM9RN4UMfHJWz0 Ceq+DzrSivQT1q2KTZnVuhQZDWs621ZLayGBes4573oJWJB2Y/7iNCwdoWKRaU3jWC0t e2MLVK3qSMxYXqV/RDFX74a+J5l3n1U/AamW3FINOwL5vGAswNmDqU2HOyMXqBCNw6l2 D9jw== X-Received: by 10.68.135.136 with SMTP id ps8mr43135530pbb.130.1424114168305; Mon, 16 Feb 2015 11:16:08 -0800 (PST) Received: from ?IPv6:2406:e007:635d:1:28cc:dc4c:9703:6781? ([2406:e007:635d:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id dx6sm15649192pab.14.2015.02.16.11.16.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Feb 2015 11:16:07 -0800 (PST) Message-ID: <54E24207.5000803@gmail.com> Date: Tue, 17 Feb 2015 08:16:23 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Markus Stenberg , Sheng Jiang References: <5D36713D8A4E7348A7E10DF7437A4B923B0455C9@nkgeml512-mbx.china.huawei.com> <02817548-0AD9-4AE4-B5B1-F97B53C5154E@iki.fi> In-Reply-To: <02817548-0AD9-4AE4-B5B1-F97B53C5154E@iki.fi> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "anima@ietf.org" , "anima-chairs@tools.ietf.org" Subject: [Anima] DNCP + X != GDNP [ Call for agenda ANIMA @ IETF92] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 19:16:11 -0000 Hi Markus, I'm looking forward to this. Just one comment for now: > (And to be precise, I am not planning to replace GDNP with this draft, = but just to illustrate that with fewer pages of text + DNCP you can actua= lly have a complete solution from my point of view, with some running cod= e already forming base of it.) GDNP is not sacred, so we can have an open-minded discussion on that. Unfortunately we probably won't have the GDNP prototype code updated to the latest spec before Dallas, though. As for the number of pages of text, I think that mainly depends where you choose to write down the details, including background information, requirements, theory of operation and alternatives. We chose to put all of it into one document for GDNP. Brian On 16/02/2015 21:42, Markus Stenberg wrote: > Name of time slot: DNCP > Name of draft(s) (preferred but not necessary): draft-ietf-homenet-dncp= -01 (-01 will show up pre-Dallas) > Time requested: 10 min > Presenter name(s): Markus Stenberg (TBD) >=20 > As there was some call for =E2=80=98more generic=E2=80=99 state synchro= nization protocol in Hawaii, we obliged by splitting HNCP to DNCP and HNC= P. This is relatively =E2=80=99tightly coupled=E2=80=99 synchronization p= rotocol, as it essentially ensures state perceived by all participants ma= tches (about the data they care about, and as a side effect, about the co= nnectivity graph of participating nodes). This is more of an awareness pr= esentation than anything else. >=20 >=20 > Name of time slot: DNCP + X !=3D GDNP > Name of draft(s) (preferred but not necessary): TBD (I hope to submit o= ne pre-Dallas) > Time requested: 20min > Presenter name(s): Markus Stenberg >=20 > While the name of the time slot is bit of a joke, I am planning to writ= e up my thoughts on how both loose and tightly coupled synchronization am= ong anima nodes should work. It will be a DNCP profile, with few more exc= hanges defined for pure discovery and negotiation. Also, a =E2=80=9Clarge= scale=E2=80=9D scalability model is introduced to describe how this coul= d work with =E2=80=9Cmany=E2=80=9D nodes.=20 >=20 > (And to be precise, I am not planning to replace GDNP with this draft, = but just to illustrate that with fewer pages of text + DNCP you can actua= lly have a complete solution from my point of view, with some running cod= e already forming base of it.) >=20 > Cheers, >=20 > -Markus > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Mon Feb 16 22:31:12 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9401A8728 for ; Mon, 16 Feb 2015 22:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=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 sp616Uo21BeA for ; Mon, 16 Feb 2015 22:31:08 -0800 (PST) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id 5568B1A8727 for ; Mon, 16 Feb 2015 22:31:08 -0800 (PST) Received: from poro.lan (80.220.64.126) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 54C8F2EA02B08802; Tue, 17 Feb 2015 08:31:01 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Markus Stenberg In-Reply-To: <54E24207.5000803@gmail.com> Date: Tue, 17 Feb 2015 08:30:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <082248A1-BB56-43B4-972D-4F9CA1980FCF@iki.fi> References: <5D36713D8A4E7348A7E10DF7437A4B923B0455C9@nkgeml512-mbx.china.huawei.com> <02817548-0AD9-4AE4-B5B1-F97B53C5154E@iki.fi> <54E24207.5000803@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Markus Stenberg , "anima-chairs@tools.ietf.org" , "anima@ietf.org" , Sheng Jiang Subject: Re: [Anima] DNCP + X != GDNP [ Call for agenda ANIMA @ IETF92] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 06:31:10 -0000 On 16.2.2015, at 21.16, Brian E Carpenter = wrote: > As for the number of pages of text, I think that mainly depends where > you choose to write down the details, including background = information, > requirements, theory of operation and alternatives. We chose to put = all > of it into one document for GDNP. Yes, GDNP spec is heavy on theory/requirements (and comparisons to some = degree).=20 However, given the document, it is completely unclear to me how it would = work in practise (and given the latitude allowed to the individual = objectives, perhaps intentionally so). The TODO list is a (partial) = indicator of that. I do not mind the theory/requirements parts (they are = skippable if not interested in them after all), but the lack of concrete = detail I find somewhat distracting. Perhaps it is just a difference of opinion on what should be the leading = part of an effort ;) Cheers, -Markus From nobody Mon Feb 16 23:47:45 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF961A870D for ; Mon, 16 Feb 2015 23:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 xKgMHynHr8z4 for ; Mon, 16 Feb 2015 23:47:42 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2213A1A8712 for ; Mon, 16 Feb 2015 23:47:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5798; q=dns/txt; s=iport; t=1424159260; x=1425368860; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RgE+7AXBjN3TIL/GrCHTCUWQpwiZ1oI9P7fHinpvSRE=; b=SdUEsVLjyUJ7yyo0Q52YCCqNZhoQ6bKKrcNjBvSWnA8RHii0qEOhLix6 ZJO2EeixekXe1FYHMD3DrcfCxjun+I5N87t4g0RWIJAZqoxbGmNUjkHl4 vjyhf621V2tdV6QskUjQb2CVhUXfEDlDcCjGQhGAkBTQBWFROyx71P8wc Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B+BQDO8eJU/4wNJK1SCYMGgSwEgn+9GIgbAhx2QwEBAQEBAXyEDAEBAQMBIxFRBAIBCBEBAwEBAwIGHQMCAgIfERQBAgYIAgQBEgiFc4IeAwkItyeRSg2FPgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYlrgkOBTyo4BoJiLoEUBY1MgWyHcYJehViGGYJGgz4igX2BcW8BgUN/AQEB X-IronPort-AV: E=Sophos;i="5.09,593,1418083200"; d="scan'208";a="397086730" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP; 17 Feb 2015 07:47:24 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t1H7lOkp023352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Feb 2015 07:47:24 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Tue, 17 Feb 2015 01:47:24 -0600 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] I-D Action: draft-behringer-anima-autonomic-control-plane-00.txt Thread-Index: AQHQSZO+Bvpqyrs2m02MQXzdxO8neZzy/1MggAEJVICAAG12AA== Date: Tue, 17 Feb 2015 07:47:23 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EC93E1@xmb-rcd-x14.cisco.com> References: <20141017131337.4423.84144.idtracker@ietfa.amsl.com> <5457F566.4080409@gmail.com> <54CA9E92.10802@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EB8AB5@xmb-rcd-x14.cisco.com> <54E15BB5.6020005@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EC817B@xmb-rcd-x14.cisco.com> <54E23F9D.3030709@gmail.com> In-Reply-To: <54E23F9D.3030709@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.136] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-control-plane-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 07:47:44 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBb bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDogMTYgRmVicnVhcnkg MjAxNSAyMDowNg0KPiBUbzogTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKTsgYW5pbWFAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtBbmltYV0gSS1EIEFjdGlvbjogZHJhZnQtYmVocmluZ2Vy LWFuaW1hLWF1dG9ub21pYy1jb250cm9sLQ0KPiBwbGFuZS0wMC50eHQNClsuLi5dDQo+ID4+PiAg ICBFYWNoIG5laWdoYm91ciBpbiB0aGUgYWRqYWNlbmN5IHRhYmxlIGlzIGF1dGhlbnRpY2F0ZWQu DQo+ID4+DQo+ID4+IEkgdGhpbmsgdGhpcyBmYWxscyByaWdodCBvdXQgb2YgRGlzY292ZXJ5IHNp bmNlIHRoZSBkaXNjb3ZlcnkNCj4gPj4gcmVzcG9uc2Ugd291bGQgY29udGFpbiB0aGUgcmVsZXZh bnQgRG9tYWluIElkZW50aXR5IGEuay5hLiBEZXZpY2UNCj4gPj4gQ2VydGlmY2F0ZSBUYWcgYW5k IHRoYXQgY2FuIGJlIGNoZWNrZWQgd2l0aCB0aGUgQ0EuDQo+ID4NCj4gPiBSaWdodCwgYnV0IGhl cmUgdGhlIGRldmlsIGlzIGluIHRoZSBkZXRhaWwuIFdlIG5lZWQgYSBzZWN1cml0eSBhc3NvY2lh dGlvbg0KPiB3aXRoIHRoZSBwZWVyIGRldmljZS4gVGhpcyBhc3NvY2lhdGlvbiBjYW4gYmUgZXN0 YWJsaXNoZWQgdmlhIHRoZSBkaXNjb3ZlcnkNCj4gcHJvdG9jb2wsIGFuZCByZS11c2VkIGZvciBz dWJzZXF1ZW50IGNvbW11bmljYXRpb25zLCBzdWNoIGFzIHRoZSBBQ1AuIE9yLA0KPiB3ZSBjb3Vs ZCBoYXZlIHRoZSBBQ1AgZXN0YWJsaXNoIGl0cyBvd24gc2VjdXJpdHkgYXNzb2NpYXRpb24uIE15 IGZlZWxpbmcgaXMNCj4gdGhhdCB3ZSBzaG91bGQgZXN0YWJsaXNoIG9uZSBzaW5nbGUgU0EgYW5k IHVzZSBpdCBmb3IgYWxsIHN1YnNlcXVlbnQNCj4gb3BlcmF0aW9ucy4gV2UgbmVlZCB0byBjb3Zl ciB0aGlzIHBvaW50IGluIHRoZSByZWZlcmVuY2UgYXJjaGl0ZWN0dXJlLg0KPiANCj4gSSB0aGlu ayBJIGFncmVlLCBleGNlcHQgdGhhdCBhbnl0aGluZyBjYW4gZ28gd3JvbmcgYXQgYW55IHRpbWUs IHNvIGl0IG11c3QNCj4gYWx3YXlzIGJlIHBvc3NpYmxlIHRvIHJlY3JlYXRlIHRoZSBTQS4gSSBk b24ndCB0aGluayB0aGF0IGNoYW5nZXMgd2hldGhlciB3ZQ0KPiB1c2UgIChEKVRMUyBvciBJUHNl YyAtIGp1c3Qga2VlcCB0aGUgY2hhbm5lbCBvcGVuIHVubGVzcyBpdCBicmVha3Mgb3IgeW91IHJ1 bg0KPiBvdXQgb2YgcmVzb3VyY2UuDQoNCk9mIGNvdXJzZS4gV2hpY2ggcHJvdG9jb2wgdG8gdXNl IGlzIGEgZGV0YWlsLCBJIHRoaW5rLiBUaGUgcXVlc3Rpb24gaXMgaG93IG1hbnkgU0FzIHdlIHdh bnQgYmV0d2VlbiBwZWVycywgYW5kIG9mIGNvdXJzZSB3ZSBuZWVkIHNvbWUga2VlcGFsaXZlIG1l Y2hhbmlzbSwgYW5kIHJlLWVzdGFibGlzaG1lbnQgaWYgdGhlIHNlc3Npb24gZ29lcyBkb3duLiBJ IHRoaW5rIHdlJ3JlIGluIHN5bmMuIA0KDQpbLi4uXQ0KPiA+Pj4gMy40LiBDYXBhYmlsaXR5IE5l Z290aWF0aW9uDQo+ID4+IC4uLg0KPiA+Pj4gICAgVG8gZXN0YWJsaXNoIGEgdHJ1c3RlZCBzZWN1 cmUNCj4gPj4+ICAgIGNvbW11bmljYXRpb24gY2hhbm5lbCwgZGV2aWNlcyBtdXN0IGJlIGFibGUg dG8gbmVnb3RpYXRlIHdpdGggZWFjaA0KPiA+Pj4gICAgbmVpZ2hib3VyIGEgc2V0IG9mIHBhcmFt ZXRlcnMgZm9yIGVzdGFibGlzaGluZyB0aGUgY29tbXVuaWNhdGlvbg0KPiA+Pj4gICAgY2hhbm5l bCwgbW9zdCBub3RhYmx5IGNoYW5uZWwgdHlwZSBhbmQgc2VjdXJpdHkgdHlwZS4NCj4gPj4NCj4g Pj4gSSB0aGluayBHRE5QIGlzIHZlcnkgbGlrZWx5IHRvIGVuZCB1cCBzaW1wbHkgdXNpbmcgVExT IChhbHRob3VnaA0KPiA+PiB0aGF0J3Mgbm90DQo+ID4NCj4gPiBUTFM/IE5vdCBEVExTPyAoc29y cnkgSSBoYXZlbid0IHJlYWQgYWxsIHRoZSBtYWlscykNCj4gDQo+IFdlbGwsIGl0J3MgYW4gb3Bl biBpc3N1ZSByaWdodCBub3c7IGJ1dCBJIGFtIDk5JSBzdXJlIHdlJ2xsIG5lZWQgYSBUTFMgbW9k ZQ0KPiBmb3IgY2FzZXMgd2hlcmUgdGhlIG9iamVjdGl2ZSBpcyBhIGxhcmdlIGRhdGEgc3RydWN0 dXJlLiBJIGFsc28gaGF2ZSBhIGZlZWxpbmcNCj4gdGhhdCBEVExTIGludHJvZHVjZXMgYSBzaWdu aWZpY2FudCBzdGFydC11cCBvdmVyaGVhZCB0aGF0IG1ha2VzIHRoZQ0KPiBkaWZmZXJlbmNlIGNv bXBhcmVkIHRvIFRMUyBzdGFydC11cCB2ZXJ5IHNtYWxsLg0KDQpUaGF0IGlzIGEgcG9pbnQgd2Ug bmVlZCB0byBkaXNjdXNzIGluIG1vcmUgZGV0YWlsLiBNeSBmZWVsaW5nIGlzIHRoYXQgRFRMUyBp cyBtb3JlIGFwcHJvcHJpYXRlLCBlc3BlY2lhbGx5IHdoZW4gd2Ugc3RhcnQgcm91dGluZyBwYWNr ZXRzIHRocm91Z2ggdGhpcyBpbmZyYXN0cnVjdHVyZSB3aXRoaW4gdGhlIEFDUCwgYnV0IHRoaXMg Y2xlYXJseSBuZWVkcyBtb3JlIHRoaW5raW5nIChvbiBteSBzaWRlIGF0IGxlYXN0IDstKSAuIFRo YXQncyBwcm9iYWJseSBhbHNvIGEgZ29vZCBkaXNjdXNzaW9uIHRvIGhhdmUgaW4gRGFsbGFzLiAN Cg0KWy4uLl0NCg0KPiA+IFRvIG1lLCBHRE5QIGJldHdlZW4gYWRqYWNlbnQgbm9kZXMgc2hvdWxk IEFMV0FZUyB1c2UgbGluayBsb2NhbA0KPiAoUHJvYmFibHkgYSAiTVVTVCIgaW4gdGhlIGRvY3Vt ZW50KS4gTGluayBsb2NhbCBoYXMgbm8gZGVwZW5kZW5jeSBvbg0KPiBjb3JyZWN0IGNvbmZpZ3Vy YXRpb24sIHNvIGNvbmZsaWN0cyB3aXRoIHdoYXQgdGhlIGFkbWluaXN0cmF0b3IgZG9lcyBhcmUN Cj4gbWluaW1hbC4gSSBmZWVsIHZlcnkgc3Ryb25nbHkgYWJvdXQgdGhpcy4gSSBzZWUgbm8gcmVh c29uIHRvIE5PVCB1c2UgbGluaw0KPiBsb2NhbC4gKEJ1dCBoYXBweSB0byBiZSBlZHVjYXRlZCku DQo+IA0KPiBXZSBkb24ndCBzdGF0ZSB0aGF0IGF0IHRoZSBtb21lbnQsIGFsdGhvdWdoIHdlIGRv IHN0YXRlIHRoZSBpbnZlcnNlOg0KPiBhIGxpbmstbG9jYWwgYWRkcmVzcyBNVVNUIE5PVCBiZSB1 c2VkIGluIGEgRGl2ZXJ0IG9wdGlvbiwgYmVjYXVzZSB0aGF0IGlzDQo+IGludGVuZGVkIHRvIHNl bmQgeW91IG9mZi1saW5rLg0KPiANCj4gVGhlcmUncyBhIHNsaWdodCBjb21wbGljYXRpb24gdGhl cmUsIHdoaWNoIGlzIHRoYXQgYSBkZXZpY2UgKHJvdXRlcikgdGhhdCBpcw0KPiBzZW5kaW5nIGEg RGl2ZXJ0IG9wdGlvbiBuZWVkcyB0byBrbm93IHRoZSBhcHByb3ByaWF0ZSByb3V0ZWFibGUgYWRk cmVzcy4NCj4gV2UgbmVlZCB0byBmaWd1cmUgb3V0IGhvdyBpdCBsZWFybnMgaXQgaW4gdGhlIGZp cnN0IHBsYWNlLiBCdXQgSSBhZ3JlZSB0aGF0IGxpbmstDQo+IGxvY2FsIGlzIGEgc2FmZXIgY2hv aWNlIHdoZW5ldmVyIHBvc3NpYmxlLg0KDQpPSywgbmVlZCB0byByZWFkIHRoZSBsYXRlc3QgdmVy c2lvbiBvZiBHRE5QIGZpcnN0IGJlZm9yZSBJIGNhbiBjb21tZW50IGhlcmUgOi0pIA0KIA0KPiA+ IE5vdywgd2UgYWxzbyB3YW50IHRvIG5lZ290aWF0ZSAvIGRpc2NvdmVyIG5vZGVzIHRoYXQgYXJl IG5vdCBkaXJlY3RseQ0KPiBhZGphY2VudC4gRm9yIHRoaXMgd2UgbmVlZCB1bmljYXN0IChvciBt dWx0aWNhc3QsIGFueWNhc3QsIHBvc3NpYmx5KSB0bw0KPiByb3V0YWJsZSBhZGRyZXNzZXMuIFRv IG1lLCB0aG9zZSByb3V0YWJsZSBhZGRyZXNzZXMgY291bGQgZWl0aGVyIGJlDQo+IGRlcml2ZWQg YXV0b21hdGljYWxseSwgaW4gd2hpY2ggY2FzZSBpdCB3b3VsZCBsaWtlbHkgYmUgVUxBLCBvciBj b25maWd1cmVkLCBpbg0KPiB3aGljaCBjYXNlIHdlJ2QgaGF2ZSBVTEEgb3IgZ2xvYmFsIGFkZHJl c3Nlcy4NCj4gDQo+IFRoZSBHRE5QIGRyYWZ0IG5vdyBzYXlzIHRoYXQgYSByb3V0ZXIgcnVubmlu ZyBHRE5QIHJlbGF5cyBkaXNjb3ZlcnkNCj4gbWVzc2FnZXMgdG8gYWxsIGl0cyBpbnRlcmZhY2Vz LCBzbyB0aGF0IGEgbm9uLXJvdXRlciBkb2Vzbid0IG5lZWQgdG8gd29ycnkNCj4gYWJvdXQgdGhp cyBpc3N1ZS4NCj4gDQo+ID4NCj4gPiBBcmUgd2Ugb24gdGhlIHNhbWUgcGFnZT8gKEFuZCBhcG9s b2dpZXMgaWYgeW91ciBkcmFmdCBtZW50aW9ucyB0aGlzLA0KPiA+IGhhdmVuJ3QgcmVhZCB0aGUg bGFzdCB0d28gdmVyc2lvbnMgeWV0LCBzaWdoLi4uKQ0KPiANCj4gV2UncmUgcHJldHR5IGNsb3Nl LCBJIHRoaW5rLCBidXQgdGhlcmUncyB3b3JrIHRvIGJlIGRvbmUuLi4NCg0KSSBhZ3JlZS4NCg0K TWljaGFlbA0KWy4uLl0NCg== From nobody Tue Feb 17 11:07:54 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596EC1A6FFC for ; Tue, 17 Feb 2015 11:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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 lxXt0CMYYZXn for ; Tue, 17 Feb 2015 11:07:50 -0800 (PST) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3256E1A909D for ; Tue, 17 Feb 2015 11:06:56 -0800 (PST) Received: by pdev10 with SMTP id v10so45659150pde.7 for ; Tue, 17 Feb 2015 11:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=H7LdqpF0qqoXRtYPKWyi2gu8vQl6CoSmi3SXIHeJTTM=; b=x4I2Exqelu4UKt+BxIV80Ed0Fw8UnRX7NfYuDSIVHDScqy3eRIt6PQpi/PAu9kCcA6 wlXzaxMj62k7mr/l8b008pKKKhg1EJ+wzKYbSHVtvgkI3as+L4wLyRIUfJp+X7EgsPap /mQGb5oKwg6D36nhQNjCRGboES+Ss1ePOtf72KZHgOYF2T/fHthfkODMk/ddhoVpN7sf jLKQxygXQlwaT4UNomRuoQAJZb/j1l/27usdHuylrRq2nsi1QkowyzAgJt7T6/uqcelr xZ63iG1blBWHUKTbVrY6u83s5CA1SCI+Taz6WNvMLP3hSaur9+XL5AgN2GKTg82HJePz vmRw== X-Received: by 10.68.68.202 with SMTP id y10mr51433598pbt.106.1424200015882; Tue, 17 Feb 2015 11:06:55 -0800 (PST) Received: from ?IPv6:2406:e007:79cd:1:28cc:dc4c:9703:6781? ([2406:e007:79cd:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id yf6sm18585424pab.26.2015.02.17.11.06.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Feb 2015 11:06:54 -0800 (PST) Message-ID: <54E39160.5070607@gmail.com> Date: Wed, 18 Feb 2015 08:07:12 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Markus Stenberg References: <5D36713D8A4E7348A7E10DF7437A4B923B0455C9@nkgeml512-mbx.china.huawei.com> <02817548-0AD9-4AE4-B5B1-F97B53C5154E@iki.fi> <54E24207.5000803@gmail.com> <082248A1-BB56-43B4-972D-4F9CA1980FCF@iki.fi> In-Reply-To: <082248A1-BB56-43B4-972D-4F9CA1980FCF@iki.fi> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima-chairs@tools.ietf.org" , "anima@ietf.org" , Sheng Jiang Subject: Re: [Anima] DNCP + X != GDNP [ Call for agenda ANIMA @ IETF92] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 19:07:52 -0000 On 17/02/2015 19:30, Markus Stenberg wrote: > On 16.2.2015, at 21.16, Brian E Carpenter wrote: >> As for the number of pages of text, I think that mainly depends where >> you choose to write down the details, including background information, >> requirements, theory of operation and alternatives. We chose to put all >> of it into one document for GDNP. > > Yes, GDNP spec is heavy on theory/requirements (and comparisons to some degree). > > However, given the document, it is completely unclear to me how it would work in practise (and given the latitude allowed to the individual objectives, perhaps intentionally so). The TODO list is a (partial) indicator of that. There will be a new version soon where the TO DO list is quite a bit shorter, and hopefully there will be time in Dallas for a protocol walk-through, but you are correct, we are intentionally being generic in this draft. > I do not mind the theory/requirements parts (they are skippable if not interested in them after all), but the lack of concrete detail I find somewhat distracting. > > Perhaps it is just a difference of opinion on what should be the leading part of an effort ;) I know exactly what you mean. Remember that there is some prototype code, though. The next version does (IMNSHO) tie down a lot more details, to the point where I feel I could at least write a pseudo-code version of the whole thing. And my co-author is on the hook to update the prototype code when time permits. Brian > Cheers, > > -Markus > > From nobody Wed Feb 18 01:25:14 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFC71A0360 for ; Wed, 18 Feb 2015 01:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 iSYpqiUmWxTE for ; Wed, 18 Feb 2015 01:25:10 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 790C01A00A9 for ; Wed, 18 Feb 2015 01:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6465; q=dns/txt; s=iport; t=1424251510; x=1425461110; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=f92EHWgMhVPHe4PH+i3ZpahPhl3rZ8GCbHdItfDXrBs=; b=RkOiNEqxDjNamFkY6AwvOkXq5tzI/3DCbvzaqlGlVSTmb+ZqT3iqDtkY K6LTy/cnnfJixcF+FQ5tZV/6hhgMHr77uKzLX+7FNsXjU1exXtUADvcjk rtoIQRPVhTxK8EUMaQE2U2B7l1fxOE2PjORKjfe6U7HKN1TUDXmqoy+VE Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AzBQAJWuRU/5RdJa1bgwaBMMAoiBsCgRlDAQEBAQEBfIQOAQQ6PxIBKhRCJgEECgQNiCfRTwEBAQEBAQEDAQEBAQEBAQEaj0wxgx2BFAWPQ4pVhVqDc4gsIoNugXMkHH8BAQE X-IronPort-AV: E=Sophos;i="5.09,595,1418083200"; d="scan'208";a="397085072" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP; 18 Feb 2015 09:25:09 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t1I9P9lP032668 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Feb 2015 09:25:09 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Wed, 18 Feb 2015 03:25:09 -0600 From: "Michael Behringer (mbehring)" To: "draft-carpenter-anima-gdn-protocol@tools.ietf.org" Thread-Topic: Comments on draft-carpenter-anima-gdn-protocol-01 Thread-Index: AdBKsHcp2LfS0pCqS+u/lHbunF+j7Q== Date: Wed, 18 Feb 2015 09:25:08 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22ECD57A@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "anima@ietf.org" Subject: [Anima] Comments on draft-carpenter-anima-gdn-protocol-01 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 09:25:12 -0000 Authors,=20 I finally went through this document in detail, and have some comments/ques= tions. Overall, I think this document is going in the right direction, it's= clearly written, nice to read.=20 Now, whilst reviewing I saw Brian's message to the list that he's re-doing = the draft right now. So I stop my review for now where I am. So far I got o= nly to the end of section 2. When the new revision is out, I'll review the = rest.=20 There are a couple of pretty fundamental questions here, so probably worth = having some exchange on those already. And we need to develop this in sync = with the reference doc, which is next on my plate for a revision. Bear with= me! :-)=20 Michael General:=20 *** "configuration": The abstract is about how " to negotiate mutual config= urations". I think autonomic processes don't negotiate configuration. Confi= guration is in my world the thing that admins (or NMS systems) fight with, = transfer, input. I think in AN we should talk about negotiating parameters = and settings. Those may be in conflict with configuration, btw, as outlined= in the NMRG definitions draft.=20 *** Which type of discovery are we talking about? There are many types of d= iscovery. peer discovery, service discovery, topology discovery. Which one = are we talking about here? I *thought* this draft is about peer based disco= very, but it looks like you want it to be generic enough to cover all forms= of discovery? I think this is an important point, which we should clarify.= For example, is this going to overlap with mDNS type discovery in the end?= =20 In my mind (not saying that I'm right or wrong, just explaining a view poin= t) I thought this GDNP is for peer discovery, and negotiation of parameters= with a peer. To me, service discovery is a different beast. (again, not cl= aiming I'm right, just dumping my brain here) Intro:=20 *** " Therefore, the discovery mechanism needs to be able to bootstrap itself without making any prior assumptions about network structure." I find it a bit strange to say that a mechanism needs to bootstrap itself. = Specifically, it does need a trust infrastructure which it cannot bootstrap= itself. I would say "a device needs to bootstrap itself". That bootstrap = process includes discovery and negotiation. (as well as bootstrapping a tru= st infra).=20 *** " The PKI may be managed by an operator or be autonomic."=20 Suggest to add a reference ", for example as described in draft-pritikin...= ".=20 2.1 Requirements for discovery *** " In an autonomic network we must assume that when a device starts up i= t has no information about any peer devices." I would add, ", the network a= nd its services, nor about its own role in this network".=20 *** What is a "user session" in this context? Confused... I think you want= to bring in an example of a user connecting to the network? Maybe, start w= ith "for example". A more concrete example would be better. Also, the examp= le you bring could be answered with "use AAA" - the example needs to be cle= ar why this may not be optimal.=20 Maybe a better example would be that a device when booting doesn't know whe= re the AAA service, is, and it could ask its peer for it?=20 Or, to find the boundary of the network you need a local discovery mechanis= m. That is I think a better example for local discovery.=20 *** " During initialisation, a device must be able to discover the approp= riate trust anchor, i.e. the appropriate PKI authority." Initialisation is= a more complex process, I think we shouldn't try to project that larger pr= oblem entirely onto discovery. For example, in draft-pritikin, we suggest a= process where the new device doesn't really discover ANYTHING apart from t= he link local peer device, and specifically NOT a trust anchor.=20 So I disagree with "this is just a specific case of discovery". There is a = bigger process required to make that a secure operation. (And you point to = the boostrap draft). I think it's just a question of wording.=20 2.2 *** " It follows that a requirement for the protocol is to be capable of be= ing installed in any device that would otherwise need human intervention." I suggest s/be= ing installed in/operate on/ because "install" to me implies a user action,= which I don't think we want to imply.=20 *** " the protocol must be capable of supporting a "dry run" of a changed c= onfiguration before actually installing the change." I don't think THE PRO= TOCOL must be, the overall autonomic process must be. This is not a require= ment on the protocol, and I think this requirement actually doesn't belong = here. I suggest to take that entire paragraph out.=20 *** " The protocol needs to be capable of detecting unexpected events" - Sa= me comment. The protocol needs to understand failures of the protocol itsel= f, such as timeouts. General failures are not the protocol's job. This does= n't mean that you couldn't use it for some validation, but the logic of gen= eral failure detection is OUTSIDE the protocol. So this paragraph should be= changed to reflect that the protocol must detect failures in its own opera= tion, but not general failures.=20 *** " Another consideration is whether to be able" change to " Another cons= ideration is whether it should be able" 2.3 *** First paragraph. I think what you want to say is that the protocol tran= sport may have protocol dependencies, but the protocol payload should be pr= otocol independent.=20 *** " The protocol must be able to access off-link counterparts, i.e., mu= st not be restricted to link-local operation." That sounds a bit weird. Wha= t about "must be able to work with routable as well as link local addresses= ." =20 *** " The negotiation process must be guaranteed to terminate..." - again, = the PROCESS is outside scope for the protocol spec and requirements, I thin= k. Since this is a re-curing thing, maybe we need to discuss this as a sepa= rate topic. To me, there are two pieces: The protocol, and the usage thereo= f. And we should keep those separate. I think some of this should probably = move into the reference draft.=20 *** " Policy constraints" paragraph: I don't see why this paragraph is here= ?=20 *** Next paragraph, same comment. Some of this text could / should move to = the reference doc, IMO.=20 From nobody Wed Feb 18 08:47:09 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AB01A8A78 for ; Wed, 18 Feb 2015 08:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 appnSh_dUkQh for ; Wed, 18 Feb 2015 08:47:05 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3BB81A8A70 for ; Wed, 18 Feb 2015 08:47:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2670; q=dns/txt; s=iport; t=1424278025; x=1425487625; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=JeJSZ/QiDj5x2wZu1gvpCyxjeqPdQNMxwau9bcXbG9Q=; b=TlhBLHe8IQznNsyynH3kj6MOhMgVIyiczc2GF0MSMbtOcj8i5ggQX89z TfTf5NBQWzkZm5Yf+2DRxH2Et8nXR40NpejWutMRujS0z7co0uUCQj3UY Iz2MXNBe1/FtP0RTZ42aUhQTnjEXiY0HstLNOXygFTYqJXa+/fkoANR/p I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BbBQBoweRU/5pdJa1bgwZSWgTAMIIgCoVxAoEeQwEBAQEBAXyEDAEBAQQBAQE3NBcEAgEIEQQBAQsUBQQHJwsUCQgCBAESCIgnDdJzAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKEX6EPTgGgxCBFAWPQ5QiiCwigjKBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,602,1418083200"; d="scan'208";a="397182318" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 18 Feb 2015 16:47:05 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1IGl4iu008028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Feb 2015 16:47:04 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Wed, 18 Feb 2015 10:47:04 -0600 From: "Michael Behringer (mbehring)" To: Sheng Jiang , Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] Mechanisms to avoid loop dependencies was: RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01) Thread-Index: AQHQOfqBPFt+KcxEyk6jtR8YUyuZ/JzUt38AgABkcwCAIaJ2oA== Date: Wed, 18 Feb 2015 16:47:04 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22ECDFD0@xmb-rcd-x14.cisco.com> References: <54C6E23A.2040209@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B042621@nkgeml512-mbx.china.huawei.com> <54C7E02A.5000602@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B0436B5@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923B0436B5@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Mechanisms to avoid loop dependencies was: RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 16:47:07 -0000 Sorry for the late reply. This discussion touches on one of the points I ma= de in my review of the GNDP.=20 I think GNDP is a fairly low level protocol, in the sense that it allows se= nding and receiving of information, but without the understanding of that i= nformation. It is a semantic-free protocol. Any negotiation, synchronisati= on, etc will have its own semantic. Therefore, the "logic" of any particula= r autonomic transaction is not in the GNDP, but in the Autonomic Service Ag= ent which implements the function, and merely uses GNDP to send and receive= the information it requires.=20 A "TTL" may be required for some state machines, but not for others. In my = mind, this is just another TLV to be added to the protocol, if and when nee= ded, and it should probably not be a generic field in all packets. I can't = think of any example right now where we would need it. Can you?=20 Michael > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang > Sent: 28 January 2015 01:59 > To: Brian E Carpenter; anima@ietf.org > Subject: Re: [Anima] Mechanisms to avoid loop dependencies was: RE: > GDNP open issues (draft-carpenter-anima-gdn-protocol-01) >=20 > >>> o We mention convergence mechanisms and mechanisms to avoid > >>> loop dependencies. These issues need more work. > >> > >> Personally, I don't think we could complete these mechanisms to avoid > >> loop > >dependencies. These mechanisms are specific with certain autonomic > >network agents, who use GDNP to make decisions. On another side, a > >generic mechanism to detect looped message may be needed. Also some > >guidance for autonomic network agents design on how to avoid loop > >dependencies would be great. But I am not sure it is in the scope of GDN= P > design document. > >It may worth a separated document, I guess. > > > >Well, we do need to add a section setting out general guidelines for > >the definition of negotiation objectives. Mechanisms to guarantee > >convergence should probably be mentioned there. > > > >Maybe we need to add a countdown field (like a TTL) to each negotiation. >=20 > This sounds a reasonable design. :) >=20 > Best regards, >=20 > Sheng >=20 > > Brian > > > >> > >> Best regards, > >> > >> Sheng > >> > >>> Regards, > >>> Brian > >>> > >>> _______________________________________________ > >>> Anima mailing list > >>> Anima@ietf.org > >>> https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Feb 18 11:11:43 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38FC1A00E6 for ; Wed, 18 Feb 2015 11:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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 Bs2amqcthy3I for ; Wed, 18 Feb 2015 11:11:40 -0800 (PST) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8C41A0016 for ; Wed, 18 Feb 2015 11:11:40 -0800 (PST) Received: by pabrd3 with SMTP id rd3so3394279pab.1 for ; Wed, 18 Feb 2015 11:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7jJdRhWMYAp7aFD1+BdZUF65AMqw66Y/zn/o27KvrRE=; b=H+OUdeTptnc2WqntPs6Efj9SX969cogfYm5GBPgO3YedUuSXL5bIsF10MFanUkAV8c BjPzYq0OpVaUN1yuafyxOagBEr8dBLPPDhTlFRqX6BMrPJo63Sbsa3kEhKx1IvmTkxmY Q8ogpQhblWgfkUNAX5PkJ6XaLwXuhN+HQWJFkyx020CsXJnPbt3h19h+MMhqwr+1tluL p49Kpju75A8pBApuma1tBkewy1lVP3x31CbfEAi9DkS/yWdWl3aosLo0z13V59ScKt1v PgkobY4nQ/UzVCT8ZckTG4LHgkfnGYqTIURBbG/BxhbCsSkgr4emJD4hyEZQibo7Onb8 kxsw== X-Received: by 10.70.88.199 with SMTP id bi7mr1279236pdb.126.1424286700207; Wed, 18 Feb 2015 11:11:40 -0800 (PST) Received: from ?IPv6:2406:e007:5091:1:28cc:dc4c:9703:6781? ([2406:e007:5091:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id z2sm12381987pde.94.2015.02.18.11.11.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Feb 2015 11:11:39 -0800 (PST) Message-ID: <54E4E3FF.30803@gmail.com> Date: Thu, 19 Feb 2015 08:11:59 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Sheng Jiang , "anima@ietf.org" References: <54C6E23A.2040209@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B042621@nkgeml512-mbx.china.huawei.com> <54C7E02A.5000602@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B0436B5@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22ECDFD0@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22ECDFD0@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Mechanisms to avoid loop dependencies was: RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 19:11:43 -0000 Hi Michael, On 19/02/2015 05:47, Michael Behringer (mbehring) wrote: > Sorry for the late reply. This discussion touches on one of the points I made in my review of the GNDP. > > I think GNDP is a fairly low level protocol, in the sense that it allows sending and receiving of information, but without the understanding of that information. It is a semantic-free protocol. Any negotiation, synchronisation, etc will have its own semantic. Therefore, the "logic" of any particular autonomic transaction is not in the GNDP, but in the Autonomic Service Agent which implements the function, and merely uses GNDP to send and receive the information it requires. > > A "TTL" may be required for some state machines, but not for others. In my mind, this is just another TLV to be added to the protocol, if and when needed, and it should probably not be a generic field in all packets. Well, my opinion is that we always have a risk of a lost message or a dead state machine, so a timeout is always needed. As for a loop count, I think I disagree - while you are correct that a specific type of negotiation should have intrinsic termination conditions, what happens (especially in a multi-vendor situation) if one side is buggy or for some unpredicted reason never gives up in an "after you..., no after you..." situation? But I do agree that the TTL field (which we plan to call "loop-count" for clarity) should only be present if you actually need it. Anyway let's discuss the concrete proposal which will be in the -02 draft, rather than discussing in the abstract. > I can't think of any example right now where we would need it. Can you? Hmm... that's a good question to ask, but the inverse question is whether you can prove that every plausible use case will have a definite termination condition. Rgds Brian > > Michael > > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang >> Sent: 28 January 2015 01:59 >> To: Brian E Carpenter; anima@ietf.org >> Subject: Re: [Anima] Mechanisms to avoid loop dependencies was: RE: >> GDNP open issues (draft-carpenter-anima-gdn-protocol-01) >> >>>>> o We mention convergence mechanisms and mechanisms to avoid >>>>> loop dependencies. These issues need more work. >>>> >>>> Personally, I don't think we could complete these mechanisms to avoid >>>> loop >>> dependencies. These mechanisms are specific with certain autonomic >>> network agents, who use GDNP to make decisions. On another side, a >>> generic mechanism to detect looped message may be needed. Also some >>> guidance for autonomic network agents design on how to avoid loop >>> dependencies would be great. But I am not sure it is in the scope of GDNP >> design document. >>> It may worth a separated document, I guess. >>> >>> Well, we do need to add a section setting out general guidelines for >>> the definition of negotiation objectives. Mechanisms to guarantee >>> convergence should probably be mentioned there. >>> >>> Maybe we need to add a countdown field (like a TTL) to each negotiation. >> >> This sounds a reasonable design. :) >> >> Best regards, >> >> Sheng >> >>> Brian >>> >>>> >>>> Best regards, >>>> >>>> Sheng >>>> >>>>> Regards, >>>>> Brian >>>>> >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Feb 18 11:49:15 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9265F1A0141 for ; Wed, 18 Feb 2015 11:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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 ieJYw6_22_yD for ; Wed, 18 Feb 2015 11:49:12 -0800 (PST) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D72C1A0119 for ; Wed, 18 Feb 2015 11:49:12 -0800 (PST) Received: by pabrd3 with SMTP id rd3so3622647pab.1 for ; Wed, 18 Feb 2015 11:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EAnMBuebl1EAsG69zH+EaZIS60wD6n+LbbV01HW9ulw=; b=mgCJwVMwCCiDSmHES0UjIOdoFleuMZNhSPUMNoHD+O264WId/0X1arAj2O+tKAZpQf uRErrdNT8mKqGorEuK4by9G3JBlW6wyjqYNENdFt/tsuySoRB/ZnisD2LXCPVoWR1crc JqxwrehRyY7g6cvWudae9or1vfa7qFfGMIftOmj2Y9+LT7AgG6kt9E+yfujW8mMUczxU oT0wlkHZwliiq2LMrW3HuUJ+y0Ac8PaZaq55r5ifAx7uW01p97EJLjxZ4EHuBQLgKMEo n0xZ8yOx0fVDrCc/ZDkqlHQfwf18GhMfdxkTF+BN8NAeak6C3UI91ivBcCsGmCmnFuLV 7wBg== X-Received: by 10.68.109.195 with SMTP id hu3mr1643637pbb.84.1424288951690; Wed, 18 Feb 2015 11:49:11 -0800 (PST) Received: from ?IPv6:2406:e007:5091:1:28cc:dc4c:9703:6781? ([2406:e007:5091:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id rj7sm21391122pbc.58.2015.02.18.11.49.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Feb 2015 11:49:10 -0800 (PST) Message-ID: <54E4ECCA.7000303@gmail.com> Date: Thu, 19 Feb 2015 08:49:30 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , "draft-carpenter-anima-gdn-protocol@tools.ietf.org" References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22ECD57A@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22ECD57A@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] Comments on draft-carpenter-anima-gdn-protocol-01 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 19:49:14 -0000 Hi Michael, Thanks for the review so far. On 18/02/2015 22:25, Michael Behringer (mbehring) wrote: > Authors, > > I finally went through this document in detail, and have some comments/questions. Overall, I think this document is going in the right direction, it's clearly written, nice to read. > > Now, whilst reviewing I saw Brian's message to the list that he's re-doing the draft right now. So I stop my review for now where I am. So far I got only to the end of section 2. When the new revision is out, I'll review the rest. > > There are a couple of pretty fundamental questions here, so probably worth having some exchange on those already. And we need to develop this in sync with the reference doc, which is next on my plate for a revision. Bear with me! :-) > > Michael > > > General: > *** "configuration": The abstract is about how " to negotiate mutual configurations". I think autonomic processes don't negotiate configuration. Configuration is in my world the thing that admins (or NMS systems) fight with, transfer, input. I think in AN we should talk about negotiating parameters and settings. Those may be in conflict with configuration, btw, as outlined in the NMRG definitions draft. Well, first, the discrepancy is about words, not substance. The way I look at it is that AN is setting parameters that were traditionally set by manual or NMS methods (including modern traditions like NETCONF). I hadn't thought of the word "configuration" being strictly limited to manual or NMS actions. Actually the definitions draft, in the Abstract, says "The fundamental goal is self-management, including self-configuration,...". But later on the text uses "configuration" when it clearly means traditional methods. Certainly we can tidy this up. > > *** Which type of discovery are we talking about? There are many types of discovery. peer discovery, service discovery, topology discovery. Which one are we talking about here? I *thought* this draft is about peer based discovery, Yes, the goal is to discover the peer(s) for a given negotiation or synchronization objective. In -02 we will significantly update the description of objectives, which makes this much more clear (I think). > but it looks like you want it to be generic enough to cover all forms of discovery? I think this is an important point, which we should clarify. For example, is this going to overlap with mDNS type discovery in the end? That isn't the goal, but if we make a generic design then of course it might overlap. > In my mind (not saying that I'm right or wrong, just explaining a view point) I thought this GDNP is for peer discovery, and negotiation of parameters with a peer. To me, service discovery is a different beast. (again, not claiming I'm right, just dumping my brain here) Yes. But in the end, the boundary will be fuzzy and if we succeed at all, it's the market that will decide. > > Intro: > *** " Therefore, the discovery mechanism needs to be able to bootstrap > itself without making any prior assumptions about network structure." > I find it a bit strange to say that a mechanism needs to bootstrap itself. Specifically, it does need a trust infrastructure which it cannot bootstrap itself. I would say "a device needs to bootstrap itself". That bootstrap process includes discovery and negotiation. (as well as bootstrapping a trust infra). Physically, it's each device of course. > *** " The PKI may be managed by an operator or be autonomic." > Suggest to add a reference ", for example as described in draft-pritikin...". Yes, we need to start inserting linkages between the various documents. > > 2.1 Requirements for discovery > *** " In an autonomic network we must assume that when a device starts up it has no information about any peer devices." I would add, ", the network and its services, nor about its own role in this network". That is certainly the intention - it's a factory-fresh device. But it does know what roles it is capable of playing. > > *** What is a "user session" in this context? Confused... I think you want to bring in an example of a user connecting to the network? Maybe, start with "for example". A more concrete example would be better. Also, the example you bring could be answered with "use AAA" - the example needs to be clear why this may not be optimal. > Maybe a better example would be that a device when booting doesn't know where the AAA service, is, and it could ask its peer for it? > Or, to find the boundary of the network you need a local discovery mechanism. That is I think a better example for local discovery. I need to think about that a bit. > > *** " During initialisation, a device must be able to discover the appropriate trust anchor, i.e. the appropriate PKI authority." Initialisation is a more complex process, I think we shouldn't try to project that larger problem entirely onto discovery. For example, in draft-pritikin, we suggest a process where the new device doesn't really discover ANYTHING apart from the link local peer device, and specifically NOT a trust anchor. > So I disagree with "this is just a specific case of discovery". There is a bigger process required to make that a secure operation. (And you point to the boostrap draft). I think it's just a question of wording. Actually I now think it's a special case. Once you have executed draft-pritikin, you are a trusted member of the domain, and exchange authenticated traffic. That makes everything easier. Before you are enrolled, all traffic is suspect. This does need some rewording. > 2.2 > *** " It follows that a requirement for the protocol is to be capable of being installed in > any device that would otherwise need human intervention." I suggest s/being installed in/operate on/ because "install" to me implies a user action, which I don't think we want to imply. Yes. > *** " the protocol must be capable of supporting a "dry run" of a changed configuration before actually installing the change." I don't think THE PROTOCOL must be, the overall autonomic process must be. This is not a requirement on the protocol, and I think this requirement actually doesn't belong here. I suggest to take that entire paragraph out. Sheng made a similar remark, and that led me to think that we are all correct. The overall process must support this, and therefore the protocol must allow it. In practice that means that it's a requirement on the design of individual objectives. My conclusion is that we do need to discuss it, but in a slightly different way. > *** " The protocol needs to be capable of detecting unexpected events" - Same comment. The protocol needs to understand failures of the protocol itself, such as timeouts. General failures are not the protocol's job. This doesn't mean that you couldn't use it for some validation, but the logic of general failure detection is OUTSIDE the protocol. So this paragraph should be changed to reflect that the protocol must detect failures in its own operation, but not general failures. Yes, it is the autonomic service agent that has to detect functional failures. But (see previous message) I think the protocol does need to detect timeouts and loops in its own operations. > *** " Another consideration is whether to be able" change to " Another consideration is whether it should be able" Ack > > 2.3 > *** First paragraph. I think what you want to say is that the protocol transport may have protocol dependencies, but the protocol payload should be protocol independent. Sure. > > *** " The protocol must be able to access off-link counterparts, i.e., must not be restricted to link-local operation." That sounds a bit weird. What about "must be able to work with routable as well as link local addresses." Semi-consciously, the phrasing is to draw a contrast with HNCP, which is very clear that it's on-link only. > > *** " The negotiation process must be guaranteed to terminate..." - again, the PROCESS is outside scope for the protocol spec and requirements, I think. Since this is a re-curing thing, maybe we need to discuss this as a separate topic. To me, there are two pieces: The protocol, and the usage thereof. And we should keep those separate. I think some of this should probably move into the reference draft. Well, I do see this as the protocol detecting failures in its own operation, to use your phrase. > > *** " Policy constraints" paragraph: I don't see why this paragraph is here? > > *** Next paragraph, same comment. Some of this text could / should move to the reference doc, IMO. It's a matter of taste perhaps. You could grab some of this for the reference model, and if it fits nicely there we can remove it here. Thanks very much, Brian From nobody Thu Feb 19 09:27:28 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69D41A1A29 for ; Thu, 19 Feb 2015 09:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 Lm_inYetQZsm for ; Thu, 19 Feb 2015 09:27:25 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9FC21A039C for ; Thu, 19 Feb 2015 09:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1464; q=dns/txt; s=iport; t=1424366844; x=1425576444; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=kZshekpEpijxMZI9ffvzx5VRUKfkqwNbD2QpwCbsn6I=; b=La1QBAs4XQK6BgvijGlZiuTY5nONhXIWIPePIz426AmPNa2pDWGEHsev mrhPb/+QmQuuj8+C8hfGLtGBDQGjFeWmeDTuHSM4zngitplNweXVMAQ/q fpf/tFKFtKvFQr5GiFz8BPUXsbdjTXR0TZz6/xzd2cxFHNFomE4C4zOJZ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeBQC+HOZU/5pdJa1bgwZSWgTAPYIgCoVxAoEhQwEBAQEBAXyEDwEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEARIIiCcN01cBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsPhD04BoMQgRQFj0ucYyKDbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,609,1418083200"; d="scan'208";a="397475501" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 19 Feb 2015 17:27:24 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1JHROw2000835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Feb 2015 17:27:24 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Thu, 19 Feb 2015 11:27:23 -0600 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] I-D Action: draft-behringer-anima-autonomic-control-plane-00.txt Thread-Index: AQHP965HwnxXabmvmkGDG4S5dbvJBZz44wpw Date: Thu, 19 Feb 2015 17:27:23 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22ED2EC8@xmb-rcd-x14.cisco.com> References: <20141017131337.4423.84144.idtracker@ietfa.amsl.com> <5457F566.4080409@gmail.com> In-Reply-To: <5457F566.4080409@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-control-plane-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 17:27:26 -0000 This will be addressed in the next version, probably out tomorrow. Bottom l= ine: partitions and merges should not cause an issue.=20 Michael > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: 03 November 2014 22:37 > To: anima@ietf.org > Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-control- > plane-00.txt >=20 > Hi, >=20 > This draft seems fairly clear to me, though I assume it will evolve as ot= her > aspects of anima become clear. The proposal to use a ULA prefix (section > 3.7) seems good, since it decouples the ACP from all external addressing > considerations and will work from a pure factory-reset condition. However= , > it does raise a question (which also came up in homenet recently). What > happens if the network partitions? The ACP will automatically partition t= oo, > but it will presumably keep the same /48 ULA prefix everywhere. Does the > partitioned network retain the same domain ID in both parts? What > happends in the part that doesn't include the trust anchor? What happens = if > the network recombines - will there be a risk of clashing subnets created > during the partition? >=20 > Also what happens if two previously unrelated networks combine? >=20 > Brian >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Feb 19 17:52:36 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7309E1A1B21 for ; Thu, 19 Feb 2015 17:52:35 -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 Fltt4yZbLM-C for ; Thu, 19 Feb 2015 17:52:33 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FBDC1A1B1E for ; Thu, 19 Feb 2015 17:52:33 -0800 (PST) Received: by pabkx10 with SMTP id kx10so4087513pab.13 for ; Thu, 19 Feb 2015 17:52:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FAZX9mYHIw1G+LzBVYBdPcQRRRRlQnZhZSNPvUDYUws=; b=vGOT/H5cmZ/ZXCboPie/WPKIDf85E3kQ2kplKUmZPQN8bbtJtlK7F984fYnSfwuWrP XGPjnBZ9YWSlbLjDIjWjnp4GNRKDpfqePlht84XmQJ6KeOJROxm9LgXLViIvUsrQP4cM N+KV1zH/UGaO32EKvcpqxFNVqjMYbJN6arCbcErjeAa8mCkhIfzGpoxMS7glmSDY9w3k HRGB6unhuFcooS7SQjLyzplJV17nw8Ew7YwN2qByLyye9swwxZfitXxaGEDuc1JFcxNy Uok1IKZzSz5Y1AeWe9JawZ6TlbX1lo4q3L6gA1wc+Mlp8oQLVPxjtFthcpxB0Er0L/Jq XsPw== X-Received: by 10.66.141.5 with SMTP id rk5mr12630285pab.112.1424397152517; Thu, 19 Feb 2015 17:52:32 -0800 (PST) Received: from ?IPv6:2406:e007:652c:1:28cc:dc4c:9703:6781? ([2406:e007:652c:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id w17sm25049340pdj.83.2015.02.19.17.52.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Feb 2015 17:52:31 -0800 (PST) Message-ID: <54E69377.7010204@gmail.com> Date: Fri, 20 Feb 2015 14:52:55 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: anima@ietf.org References: <20150220014140.20786.48915.idtracker@ietfa.amsl.com> In-Reply-To: <20150220014140.20786.48915.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-carpenter-anima-gdn-protocol-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 01:52:35 -0000 Here's an update of the protocol proposal. There are a lot of changes, summarised as: * Tuned requirements to clarify scope, * Clarified relationship between types of objective, * Clarified that objectives may be simple values or complex data structures, * Improved description of objective options, * Added loop-avoidance mechanisms (loop count and default timeout, limitations on discovery relaying and on unsolicited responses), * Allow multiple discovery objectives in one response, * Provided for missing or multiple discovery responses, * Indicated how modes such as "dry run" should be supported, * Minor editorial and technical corrections and clarifications, * Reorganized future work list. It's a long document but we really do hope people can review it before Dallas, so that we can have a substantive discussion there. N.B. My co-author Bing is on vacation but his most recent comments, and Michael's, are supposed to be covered by this version. Regards Brian Carpenter On 20/02/2015 14:41, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : A Generic Discovery and Negotiation Protocol for Autonomic Networking > Authors : Brian Carpenter > Bing Liu > Filename : draft-carpenter-anima-gdn-protocol-02.txt > Pages : 46 > Date : 2015-02-19 > > Abstract: > This document establishes requirements for a protocol that enables > intelligent devices to dynamically discover peer devices, to > synchronize state with them, and to negotiate parameter settings > mutually with them. The document then defines a general protocol for > discovery, synchronization and negotiation, while the technical > objectives for specific scenarios are to be described in separate > documents. An Appendix briefly discusses existing protocols with > comparable features. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-anima-gdn-protocol/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-carpenter-anima-gdn-protocol-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Fri Feb 20 00:45:09 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7481A86DD for ; Fri, 20 Feb 2015 00:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 R_R38nL0rGFv for ; Fri, 20 Feb 2015 00:45:06 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701CB1A710C for ; Fri, 20 Feb 2015 00:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3302; q=dns/txt; s=iport; t=1424421906; x=1425631506; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=kQkto+oLTkFHWLpW2kAzWb31R9HFg9nKBIS7MTX6afo=; b=UCX7yr4pZ9ApJCQEqnFb8eZ5HLLQf0BLawU7ystgTsVIRwumQRT1pC/L QSZG11kyuztCA/yb7UnSvj0CuABZV9WNF3GI1gIeVfH77XD+TmkgIiZRx mDY5nhAuli64R4FYYevWo6p97hXew+q5kmOmEUNpdQfmsnQNRJ1aNXZUr w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgBgD38uZU/4kNJK1bgwZSVQUEgwS9QYIqhXECHHlDAQEBAQEBfIQPAQEBBCMRQw4EAgEIEQQBAQMCBgsSAwICAjAUAQYBAQUDAgQTCAGIJggFuw2YUwEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYluhD04BgSCXi6BFAWPToNchn44gluOfyKCMoE8b4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,613,1418083200"; d="scan'208";a="125294139" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP; 20 Feb 2015 08:45:05 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1K8j5cl005322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 20 Feb 2015 08:45:05 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Fri, 20 Feb 2015 02:45:05 -0600 From: "Michael Behringer (mbehring)" To: "anima@ietf.org" Thread-Topic: New Version Notification for draft-behringer-anima-autonomic-control-plane-01.txt Thread-Index: AQHQTOkVRmkHCtcKWkKhexJbil03Jpz5OGqA Date: Fri, 20 Feb 2015 08:45:05 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22ED3BE2@xmb-rcd-x14.cisco.com> References: <20150220084152.13713.25936.idtracker@ietfa.amsl.com> In-Reply-To: <20150220084152.13713.25936.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Anima] FW: New Version Notification for draft-behringer-anima-autonomic-control-plane-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 08:45:08 -0000 SGVyZSBpcyB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIEFDUCBkcmFmdCwgdGFraW5nIGludG8g YWNjb3VudCBhbGwgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGJ5IG5vdy4gVGhlcmUgYXJlIHF1aXRl IGEgZmV3IGNoYW5nZXMgdG8gdGhlIHByZXZpb3VzIHZlcnNpb24sIG5vdCBpbiB0aGUgdGVjaG5p Y2FsIGFwcHJvYWNoLCBidXQgZXhwYW5kaW5nIG9uIHRoZSBleHBsYW5hdGlvbnMsIGRpc2N1c3Np bmcgc3BlY2lmaWMgc2NlbmFyaW9zIChuZXR3b3JrIHBhcnRpdGlvbi9tZXJnZSBmb3IgZXhhbXBs ZSksIGFuZCBjbGFyaWZ5aW5nIHRoaW5ncy4NCg0KU2luY2UgdGhpcyBpcyBhIGRyYWZ0IHJlbGF0 ZWQgdG8gYSBtaWxlc3RvbmUsIHdlJ2QgYXBwcmVjaWF0ZSBhIHRob3JvdWdoIHJldmlldyBiZWZv cmUgRGFsbGFzLiANCg0KTWljaGFlbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXQ0KPiBTZW50OiAyMCBGZWJydWFyeSAyMDE1IDA5OjQyDQo+IFRvOiBCYWxhamkg QiBMIChibGJhbGFqaSk7IE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZyk7IFRvZXJsZXNzIEVj a2VydA0KPiAoZWNrZXJ0KTsgU3RlaW50aG9yIEJqYXJuYXNvbiAoc2JqYXJuYXMpOyBNaWNoYWVs IEJlaHJpbmdlciAobWJlaHJpbmcpOw0KPiBUb2VybGVzcyBFY2tlcnQgKGVja2VydCk7IFN0ZWlu dGhvciBCamFybmFzb24gKHNiamFybmFzKTsgQmFsYWppIEIgTCAoYmxiYWxhamkpDQo+IFN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYmVocmluZ2VyLWFuaW1hLWF1 dG9ub21pYy0NCj4gY29udHJvbC1wbGFuZS0wMS50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtYmVocmluZ2VyLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5lLQ0K PiAwMS50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNaWNoYWVsIEgu IEJlaHJpbmdlciBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBO YW1lOgkJZHJhZnQtYmVocmluZ2VyLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5lDQo+IFJl dmlzaW9uOgkwMQ0KPiBUaXRsZToJCUFuIEF1dG9ub21pYyBDb250cm9sIFBsYW5lDQo+IERvY3Vt ZW50IGRhdGU6CTIwMTUtMDItMjANCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4g UGFnZXM6CQkxNA0KPiBVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtYmVocmluZ2VyLWFuaW1hLQ0KPiBhdXRvbm9taWMtY29udHJvbC1wbGFu ZS0wMS50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWJlaHJpbmdlci1hbmltYS0NCj4gYXV0b25vbWljLWNvbnRyb2wtcGxhbmUvDQo+ IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZWhyaW5n ZXItYW5pbWEtYXV0b25vbWljLQ0KPiBjb250cm9sLXBsYW5lLTAxDQo+IERpZmY6ICAgICAgICAg ICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1iZWhyaW5nZXItYW5pbWEt DQo+IGF1dG9ub21pYy1jb250cm9sLXBsYW5lLTAxDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgSW4g Y2VydGFpbiBzY2VuYXJpb3MsIGZvciBleGFtcGxlIHdoZW4gYm9vdHN0cmFwcGluZyBhIG5ldHdv cmssIGl0IGlzDQo+ICAgIGRlc2lyYWJsZSB0byBhdXRvbWF0aWNhbGx5IGJyaW5nIHVwIGEgc2Vj dXJlLCByb3V0ZWQgY29udHJvbCBwbGFuZSwNCj4gICAgd2hpY2ggaXMgaW5kZXBlbmRlbnQgb2Yg ZGV2aWNlIGNvbmZpZ3VyYXRpb25zIGFuZCBnbG9iYWwgcm91dGluZw0KPiAgICB0YWJsZS4gIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGFwcHJvYWNoIGZvciBhIGxvZ2ljYWxseSBzZXBhcmF0 ZWQNCj4gICAgIkF1dG9ub21pYyBDb250cm9sIFBsYW5lIiwgd2hpY2ggY2FuIGJlIHVzZWQgYXMg YSAidmlydHVhbCBvdXQgb2YNCj4gICAgYmFuZCBjaGFubmVsIiAtIGEgc2VsZi1tYW5hZ2luZyBv dmVybGF5IG5ldHdvcmssIHdoaWNoIGlzIGluZGVwZW5kZW50DQo+ICAgIG9mIGNvbmZpZ3VyYXRp b24sIGFkZHJlc3NpbmcgYW5kIHJvdXRpbmcgb24gdGhlIGRhdGEgcGxhbmUuDQo+IA0KPiANCj4g DQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQo= From nobody Fri Feb 20 04:28:24 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35171A8992; Fri, 20 Feb 2015 04:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 0Zb00pzU7Gqx; Fri, 20 Feb 2015 04:28:19 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC661A898A; Fri, 20 Feb 2015 04:28:18 -0800 (PST) Received: from [192.168.131.131] ([80.92.119.127]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MeP5b-1YBwdM2qhr-00QG9d; Fri, 20 Feb 2015 13:27:51 +0100 Message-ID: <54E72846.20807@gmx.net> Date: Fri, 20 Feb 2015 13:27:50 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: robert.cragie@gridmerge.com, "Hedanping (Ana)" , Michael Richardson References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> In-Reply-To: <54E7219B.6040006@gridmerge.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3cbOx7ufkamEpP9JNkJgWaX6Hj7Trx0px" X-Provags-ID: V03:K0:ksifMiPqNyrn78RtNjbZodstXr0Fmq9pnpOicYWU6TrwffNBzLZ bt9u7qdV3rBmtFgDrr/3LuKtWEzMBFRlTdyex9AqA6Jtlfzh9dgrqJR4IJydn3lK6cbry/+ mQySw/D7licv6MXgP8/biK7vMhLwgnLduEEsvtCkgOTs0z4jkBzG9TtpZawVnqPfSCeFAxX 00uojUmFvUC5FKzTGL5tw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "anima@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 12:28:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3cbOx7ufkamEpP9JNkJgWaX6Hj7Trx0px Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Danping, I would also like to note that [I-D.pritikin-anima-bootstrapping-keyinfra] is only one possible way of distributing new keys (based on already pre-provisioned certificates). I would like to understand how it relates to other approaches. Particularly if you consider an approach "heavy" it would be good to know what your main concerns are since there is no free lunch with security and most of the design decisions are trade-offs. Ciao Hannes On 02/20/2015 12:59 PM, Robert Cragie wrote: > [I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch > bootstrapping key infrastructure to allow joining device securely and > automatically bootstraps itself based on 802.1AR certificate. It can't= > be directly used in 802.15.4 devices due to the high security complexit= y > and heavy communication overhead.": I disagree with this statement. We > used this approach in ZigBee IP. I agree some may think the > communication overhead "heavy" but that doesn't mean it can't be done. > The associated security complexity is also becoming less onerous as > crypto accelerators become built into hardware and cores. --3cbOx7ufkamEpP9JNkJgWaX6Hj7Trx0px Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU5yhGAAoJEGhJURNOOiAt/2AH/jXDh23lwVNri9WwlgCGIN3T UQ5KWI3HSf4R5G76xIrhL4qKrMT5ZqeGK4FG8lqllRj1LJ7LUTFKiP5VjaCjklRA Jd5cD+eY1DKVZkgCUhTsXKZiE0Nh7Viq3IJUICspMBUtVIOBgFEP2fsyg10OkxzA 0zq9tmGXumg597oZDxnIdwSntu4jnEOxpkq5Zsphx7QuL/PDqzjvuL9UhUHEiLK+ fVssZZ8gnTAVJQ55uFXulmUcfg/GkVEhuqS8VLuqwFKZK6vVFeeAPb3KKWgry4bu wQIQrqKLy+rfHQdCtMTXPa1hreEaNlbRGjkrCRwyuxu8Da3tyTovRryzJDReKqY= =XEuy -----END PGP SIGNATURE----- --3cbOx7ufkamEpP9JNkJgWaX6Hj7Trx0px-- From nobody Fri Feb 20 09:01:43 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F0D1A1B2E for ; Fri, 20 Feb 2015 09:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 BFBv2-Thuk2l for ; Fri, 20 Feb 2015 09:01:40 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFF811A0AC8 for ; Fri, 20 Feb 2015 09:01:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2912; q=dns/txt; s=iport; t=1424451699; x=1425661299; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=4K2KplX0I6pL8CNWwNMquryqlaybDo5RmUNkQq2quyU=; b=RDofVWh0ndmrUyynHVyu7qD8YIcAQZoI38ias2eZW2Q2FpGutcvECSjv YXfJ42Q5bCzFR/kMuLeAdRmuqAxdlcIDc41/1/ZMcNTqh8xRZbU5lphCV AcGeWNBRKDM8S9UqG4EgQ+7nibunWtv1+OS3q7XxgNbolRGA1JFGKQ77E w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQBQBeZ+dU/4YNJK1bgwaBMIMEvUSIGwIcfEMBAQEBAQF8hA8BAQEDASMRUQQCAQgRBAEBAwIGGQQDAgICHxEUAQgIAgQBEgiIEwMJCLxDkwgNhSUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGJboJEgXk4BoJiL4EUAQSPT4d8gmGFZIYrhgcigjKBPG8BgQEHO38BAQE X-IronPort-AV: E=Sophos;i="5.09,615,1418083200"; d="scan'208";a="125412923" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP; 20 Feb 2015 17:01:38 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t1KH1cFZ027254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Feb 2015 17:01:38 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Fri, 20 Feb 2015 11:01:38 -0600 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Sheng Jiang , "anima@ietf.org" Thread-Topic: [Anima] Mechanisms to avoid loop dependencies was: RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01) Thread-Index: AQHQOfqBPFt+KcxEyk6jtR8YUyuZ/JzUt38AgABkcwCAIaJ2oIAAj8GAgAKZaYA= Date: Fri, 20 Feb 2015 17:01:37 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22ED4943@xmb-rcd-x14.cisco.com> References: <54C6E23A.2040209@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B042621@nkgeml512-mbx.china.huawei.com> <54C7E02A.5000602@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B0436B5@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22ECDFD0@xmb-rcd-x14.cisco.com> <54E4E3FF.30803@gmail.com> In-Reply-To: <54E4E3FF.30803@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Mechanisms to avoid loop dependencies was: RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 17:01:41 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBb bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDogMTggRmVicnVhcnkg MjAxNSAyMDoxMg0KPiBUbzogTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKTsgU2hlbmcgSmlh bmc7IGFuaW1hQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQW5pbWFdIE1lY2hhbmlzbXMgdG8g YXZvaWQgbG9vcCBkZXBlbmRlbmNpZXMgd2FzOiBSRToNCj4gR0ROUCBvcGVuIGlzc3VlcyAoZHJh ZnQtY2FycGVudGVyLWFuaW1hLWdkbi1wcm90b2NvbC0wMSkNClsuLi5dDQo+ID4gQSAiVFRMIiBt YXkgYmUgcmVxdWlyZWQgZm9yIHNvbWUgc3RhdGUgbWFjaGluZXMsIGJ1dCBub3QgZm9yIG90aGVy cy4gSW4gbXkNCj4gbWluZCwgdGhpcyBpcyBqdXN0IGFub3RoZXIgVExWIHRvIGJlIGFkZGVkIHRv IHRoZSBwcm90b2NvbCwgaWYgYW5kIHdoZW4NCj4gbmVlZGVkLCBhbmQgaXQgc2hvdWxkIHByb2Jh Ymx5IG5vdCBiZSBhIGdlbmVyaWMgZmllbGQgaW4gYWxsIHBhY2tldHMuDQo+IA0KPiBXZWxsLCBt eSBvcGluaW9uIGlzIHRoYXQgd2UgYWx3YXlzIGhhdmUgYSByaXNrIG9mIGEgbG9zdCBtZXNzYWdl IG9yIGEgZGVhZA0KPiBzdGF0ZSBtYWNoaW5lLCBzbyBhIHRpbWVvdXQgaXMgYWx3YXlzIG5lZWRl ZC4gQXMgZm9yIGEgbG9vcCBjb3VudCwgSSB0aGluayBJDQo+IGRpc2FncmVlIC0gd2hpbGUgeW91 IGFyZSBjb3JyZWN0IHRoYXQgYSBzcGVjaWZpYyB0eXBlIG9mIG5lZ290aWF0aW9uIHNob3VsZA0K PiBoYXZlIGludHJpbnNpYyB0ZXJtaW5hdGlvbiBjb25kaXRpb25zLCB3aGF0IGhhcHBlbnMgKGVz cGVjaWFsbHkgaW4gYSBtdWx0aS0NCj4gdmVuZG9yIHNpdHVhdGlvbikgaWYgb25lIHNpZGUgaXMg YnVnZ3kgb3IgZm9yIHNvbWUgdW5wcmVkaWN0ZWQgcmVhc29uIG5ldmVyDQo+IGdpdmVzIHVwIGlu IGFuICJhZnRlciB5b3UuLi4sIG5vIGFmdGVyIHlvdS4uLiIgc2l0dWF0aW9uPw0KPiANCj4gQnV0 IEkgZG8gYWdyZWUgdGhhdCB0aGUgVFRMIGZpZWxkICh3aGljaCB3ZSBwbGFuIHRvIGNhbGwgImxv b3AtY291bnQiDQo+IGZvciBjbGFyaXR5KSBzaG91bGQgb25seSBiZSBwcmVzZW50IGlmIHlvdSBh Y3R1YWxseSBuZWVkIGl0Lg0KPiANCj4gQW55d2F5IGxldCdzIGRpc2N1c3MgdGhlIGNvbmNyZXRl IHByb3Bvc2FsIHdoaWNoIHdpbGwgYmUgaW4gdGhlIC0wMiBkcmFmdCwNCj4gcmF0aGVyIHRoYW4g ZGlzY3Vzc2luZyBpbiB0aGUgYWJzdHJhY3QuDQoNClRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlLiBJ IGhhdmVuJ3QgcmVhZCAtMDIgeWV0LCB3aWxsIGRvIHRoYXQuDQoNCkZvciBub3csIEknbSBub3Qg Y29udmluY2VkIHlldCA6LSkgIA0KIA0KPiA+IEkgY2FuJ3QgdGhpbmsgb2YgYW55IGV4YW1wbGUg cmlnaHQgbm93IHdoZXJlIHdlIHdvdWxkIG5lZWQgaXQuIENhbiB5b3U/DQo+IA0KPiBIbW0uLi4g dGhhdCdzIGEgZ29vZCBxdWVzdGlvbiB0byBhc2ssIGJ1dCB0aGUgaW52ZXJzZSBxdWVzdGlvbiBp cyB3aGV0aGVyDQo+IHlvdSBjYW4gcHJvdmUgdGhhdCBldmVyeSBwbGF1c2libGUgdXNlIGNhc2Ug d2lsbCBoYXZlIGEgZGVmaW5pdGUgdGVybWluYXRpb24NCj4gY29uZGl0aW9uLg0KDQpJdCBkZXBl bmRzIGVudGlyZWx5IGhvdyB5b3UgY29uc3RydWN0IHRoZSBhdXRvbm9taWMgc2VydmljZSBhZ2Vu dC4gVG8gbWUsIHRoZXJlIGlzIGEgbG9naWMgbGlrZSAiSSdsbCBhc2sgbXkgbmVpZ2hib3VyIiwg d2hpY2ggd2lsbCByZXN1bHQgaW4gYSBHRE5QIHBhY2tldCB0byBiZSBzZW50LiBJZiB0aGVyZSBp cyBubyByZXBseSwgdGhlIHN0YXRlIG1hY2hpbmUgd2lsbCBzZW5kIGFub3RoZXIgcGFja2V0LCBh bmQgYWZ0ZXIgMyB0cmllcyBpdCB3aWxsIHJlcG9ydCBhbiBlcnJvciBvciBkbyBzb21ldGhpbmcg ZWxzZS4gSW4gb3RoZXIgd29yZHMsIHRoZSBkZWNpc2lvbiBvbiByZXRyeSwgdGltZW91dCwgZXRj LCBhcmUgbm90IG1hZGUgb24gdGhlIEdETlAgbGV2ZWwsIGJ1dCBvbmUgbGV2ZWwgYWJvdmUuIA0K DQpCdXQsIG5vIGRvdWJ0LCB3ZSBuZWVkIHRvIGNvbnRpbnVlIHRoYXQgZGlzY3Vzc2lvbiA7LSkg DQogDQpNaWNoYWVsDQoNCg== From nobody Fri Feb 20 10:51:58 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E3F1A1E10; Fri, 20 Feb 2015 10:51:42 -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 AfzMTRfhFOut; Fri, 20 Feb 2015 10:51:38 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7EC31A1BBF; Fri, 20 Feb 2015 10:51:31 -0800 (PST) Received: by pdjg10 with SMTP id g10so9529610pdj.1; Fri, 20 Feb 2015 10:51:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=h2HlgcFvp3babhMDiVziH5awpkSXqkiHVGG1R0hFHWo=; b=Q6sRRe/2ZeBnKaz7nkwnxE71OARlxrNXJhH5I5dnmOzeEKaX22st+tG5nULew7hcg/ +C/MivtBPjS9ZuVAkwu/1+PTVt2V0/+AZRT7YkrhIcAFX0Nl/nfGcd7+IqM8IaIqstJ1 m1O8RXMLx8LtRRDy0GmJVtFUW3fHUOVtjE6CJJYmFmzOJtpHM2mfHrdeLInL/SsPYq2l n1QmDc5Fz1Mu2DFQ0QsC3tDuAJXmXbgY2VXhi+aQOJ5V2FNxhgfXjC3pN8GO7klWoUA8 1ZNcapFzgsJM7yhsEadK9FBlN0F5TgwKTmDw0N0LPxErP5YrwamYh2+NYHC5SW5x6oAn d+BQ== X-Received: by 10.68.234.164 with SMTP id uf4mr10351839pbc.37.1424458291008; Fri, 20 Feb 2015 10:51:31 -0800 (PST) Received: from ?IPv6:2406:e007:7a9d:1:28cc:dc4c:9703:6781? ([2406:e007:7a9d:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ma9sm25837077pdb.14.2015.02.20.10.51.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Feb 2015 10:51:30 -0800 (PST) Message-ID: <54E7824A.4040906@gmail.com> Date: Sat, 21 Feb 2015 07:51:54 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Hannes Tschofenig , robert.cragie@gridmerge.com, "Hedanping (Ana)" , Michael Richardson References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> In-Reply-To: <54E72846.20807@gmx.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima@ietf.org" , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 18:51:42 -0000 Hannes, I agree that we need to compare different approaches. I do have one concern in the anima context that leads me to the conclusion that we *must* pick a preferred solution: if we consider a collection of multivendor equipment in factory condition that we want to bootstrap itself into a secure network when we apply power, I don't see how we can avoid having a single default solution. If not, we get a rather ludicrous situation where we need a single default solution to the problem of choosing which bootstrap solution to use. Regards Brian On 21/02/2015 01:27, Hannes Tschofenig wrote: > Hi Danping, > > I would also like to note that > [I-D.pritikin-anima-bootstrapping-keyinfra] is only one possible way of > distributing new keys (based on already pre-provisioned certificates). I > would like to understand how it relates to other approaches. > Particularly if you consider an approach "heavy" it would be good to > know what your main concerns are since there is no free lunch with > security and most of the design decisions are trade-offs. > > Ciao > Hannes > > On 02/20/2015 12:59 PM, Robert Cragie wrote: >> [I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch >> bootstrapping key infrastructure to allow joining device securely and >> automatically bootstraps itself based on 802.1AR certificate. It can't >> be directly used in 802.15.4 devices due to the high security complexity >> and heavy communication overhead.": I disagree with this statement. We >> used this approach in ZigBee IP. I agree some may think the >> communication overhead "heavy" but that doesn't mean it can't be done. >> The associated security complexity is also becoming less onerous as >> crypto accelerators become built into hardware and cores. > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Feb 20 12:51:38 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C89C1A87B0; Fri, 20 Feb 2015 12:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 5Rc4zCN9t1W5; Fri, 20 Feb 2015 12:51:32 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F406F1A879F; Fri, 20 Feb 2015 12:51:31 -0800 (PST) Received: by lams18 with SMTP id s18so8540082lam.13; Fri, 20 Feb 2015 12:51:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gx9Pwjc2tDPn/MvFBc4h57v3BOIE2hdSAgPdsA9KyAc=; b=yk+b0G33gKTIpBCZYH92abNGpZYaMrAaG8WQtzUPVOQXHqoYXUfsrgRPzavMPrR06o +OF1suCBE+OH2DWTMugasMXjmp/QCP6FUHnkUdiRsRZ9oGQSBoabAdOETMAMAJZf0ajb lM4fCsPqz7vL1gD1piRf4qrDlABfGuNUwRDYmsW1SnK918KkRPsTq3wvtDkhVyyaBv7N Vm9vG8+yntoSoYsRNm/vR1uTcACLZEQBi61q9wuxBqUPqmAAOF9tM7AkPFyq6lxTzQvF yX4RKjj5JS2K/d+W1ra+BXizr7j+9ettoG6a7cMaP1WLok+LPRvJu+LGeEHtXQYDPpXP LKgA== MIME-Version: 1.0 X-Received: by 10.112.134.106 with SMTP id pj10mr10455995lbb.58.1424465490453; Fri, 20 Feb 2015 12:51:30 -0800 (PST) Received: by 10.114.187.13 with HTTP; Fri, 20 Feb 2015 12:51:30 -0800 (PST) In-Reply-To: <54E7219B.6040006@gridmerge.com> References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> Date: Fri, 20 Feb 2015 14:51:30 -0600 Message-ID: From: Behcet Sarikaya To: robert.cragie@gridmerge.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Michael Richardson , "Hedanping \(Ana\)" , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "anima@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 20:51:35 -0000 Hi Robert, Thank you for your comments. On Fri, Feb 20, 2015 at 5:59 AM, Robert Cragie wrote: > Hi Danping, > > I have some general comments on the draft and some additional comments > inline, bracketed by > > General comments: > > I think the general model is good but could be simplified to two cases: > > 1) Where the authenticator is in direct communication > 2) Where the authenticator is not in direct communication (relay case) > > My reasoning is because: > > a) There isn't much distinction between RFD and FFD from an authentication > perspective > b) There isn't much distinction between joining an existing network and > initial joining > > If you think there are distinctions, then they need clarifying. > > Other points: > > "Because IEEE 802.15.4 maximum payload size is 128 Bytes, a standard > security bootstrapping protocol should be light-weight with low > complexity.": I think it would be better to say "should ideally be > light-weight with low complexity". There may be requirements where high > security strength is required and therefore this will necessarily involve > more communication overhead and processing. > I think the hierarchical joining description is generally useful. > It is conceivable for an RFD to communicate directly with a 6LBR so I don't > think that should be excluded from Figure 1 > "[I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch > bootstrapping key infrastructure to allow joining device securely and > automatically bootstraps itself based on 802.1AR certificate. It can't be > directly used in 802.15.4 devices due to the high security complexity and > heavy communication overhead.": I disagree with this statement. We used this > approach in ZigBee IP. So there is already ZigBee IP's EAP-TLS approach. Then, why do you think a new approach is needed? > I agree some may think the communication overhead > "heavy" but that doesn't mean it can't be done. The associated security > complexity is also becoming less onerous as crypto accelerators become built > into hardware and cores. > The document mentions a couple of protocols (EAP and PANA) but doesn't go > into enough detail on how those are deployed. Also, there are other choices. > The document could give generic names to the particular communications and > then add a section to give examples. > Thanks for the pointers. We are currently working on an analysis draft to see if there is interest in new work in this area. I think that any solution work should follow on the results of such a discussion. What do you think? Regards, Behcet > Robert > > On 02/02/2015 08:13, Hedanping (Ana) wrote: > > Hi Michael, > Thank you for the interest and the questions are illuminating. Please see my > reply inline. > > > I have added a number of CCs, I think that this fits into ANIMA best. > > > > > Hedanping (Ana) wrote: > > > A new draft is submitted, it's about the security bootstrapping > > > architecture and methods for IoT networks that implement IETF > > protocols > > > (e.g. 6LoWPAN, 6lo, RPL, AODV, DSR) over IEEE 802.15.4. > > > Two types of bootstrapping methods are developed: network level > > > bootstrapping and joining device level bootstrapping > > > > > The link is: > > > http://tools.ietf.org/html/draft-he-iot-security-bootstrapping-00 > > > > I read the document with great interest. > > I found that you explained the incremental boot-strapping process quite > well, > > and nobody has clearly articulated the process yet. People have just > assumed > > that everyone knows this process, but really it needs to get written > down, so I > > thank you for doing that. > > Thank you for the praise. As it is the initial version, more discussions and > comments are needed to make it better. > > I agree that it has not generally been articulated well. To some > extent, it is because up to now, there has been no "the one way to do it". > Therefore, something ZigBee IP is a profile which defines one particular way > of doing it. There are other ways as well, of course. I guess the question > is whether it can be generalised sufficiently to be generally applicable and > whether that is in fact worth doing > > > > > Given that: > > > > Because IEEE 802.15.4 maximum payload size is 128 Bytes, a standard > > security bootstrapping protocol should be light-weight with low > > complexity. The protocol must allow for commissioning of devices > > > > I was surprised that the draft then suggested EAP with PANA as a > transport: > > I realise that PANA/EAP/EAP-TLS gets roundly criticised for being > "heavyweight". Indeed, there are overheads in the use of these three very > well-established protocols which could be removed in certain cases. However, > this would result in the development of new protocols. Having done a lot of > work in looking at DTLS options, I can confidently say that the difference > at the end of the day is quite small > > > > > If EAP is used, PANA can be used to relay the authentication message > > from configured FFDs to 6LBR. If the validation is successful, the > > IP address and network key are generated and delivered to the FFD. > > > > But, EAP-TLS with PANA is exactly what the Zigbee IP specification has > specified. > > Do you envision any changes from that specification? > > Zigbee IP specification was developed to enable IP address for Zigbee > application, thus the protocol stack are built on IETF's standards, > including EAP-TLS. > As discussed in many working groups, TLS might result in a significant > amount of retransmissions due to unreliable communication capability of the > network and device, thus energy will be consumed fast. > I think EAP over DTLS /profiled DTLS could be a good option. > > EAP-TLS only uses TLS handshakes carried as EAP payloads, therefore has > little to do with TLS as it is normally used, i.e. over TCP. If you then > start to look at the difference between EAP-TLS (over UDP) and DTLS > handshakes over UDP, there is actually not much difference. In some areas, > EAP is actually preferable (fragmentation and header overhead) > > > A minority of people had prefered this mechanism for 6tisch-security, but > > none stepped forward to write up that mechanism. Perhaps this draft > could > > fulfill that need? > > Yes, we should describe more clearly on this mechanism, and maybe this draft > is a right place. It would be great if folks in the mailing list make > comments and contribution on this technical point. > > I am happy to write up that mechanism > > > You write that the IP address would be generated; usually that occurs via > > distribution of PIOs via ND (router-adveristments) or RPL. Were you > going to > > suggest something else here? > > According to my knowledge, IP address can be generated once a device is > authenticated to network access, afterwards, other further protocols can use > IP to communicate. > Besides, PANA needs IP as well. The incremental bootstrapping takes > advantage of such IP address generation mechanism, so that PANA can be run > without any problem. > > ZigBee IP solved this problem by using SLAAC IPv6 addresses based on > the EUI-64. These can be used in PANA straight away without the need for any > other configuration > > > > > From the ANIMA and 6tisch-security point of view, my view is that this is > all > > about the choice of certificates for the TLS setup. Do you have any view > on > > how that might work? > > For unconstrained environment, I agree with you. But when it comes to > constrained device and constrained network communication, TLS might not be a > good choice as mentioned before. Certificate is not a good choice either due > to the high cost. > I would like to say: it is about the choice of credential type for secure > channel setup. The good candidates of credential types are Raw public key, > Physical Unclonable Function (PUF). > > There certainly are overheads in certificates but in the 802.1AR > scenario (draft-pritikin-anima-bootstrapping-keyinfra-01) it has clear > value. > > > > > The 6tisch-security bootstrap process aims to create a > > YANG/CBOR-over-CoAP-over-DTLS session between a Join Coordinator and the > > Joining Node: over that management link, security (and timeslot > scheduling) > > would be provisioned. > > CoAP-DTLS coincides with my idea. > Yang sounds like at a higher level, but I think EAP is actually the > mechanism running behind ^_^ > > Again, in this document, it might be better to abstract this session > and describe what it is used for > > > Regards, > Ana > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > > > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > From nobody Sat Feb 21 03:15:04 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37521A6EE8; Sat, 21 Feb 2015 03:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 P3XIxWHQfkS3; Sat, 21 Feb 2015 03:14:59 -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 E66F21A6EE9; Sat, 21 Feb 2015 03:14:58 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.195]) by smtp-cloud3.xs4all.net with ESMTP id uzEw1p0084CYHle01zEwEt; Sat, 21 Feb 2015 12:14:57 +0100 Received: from AMontpellier-654-1-246-246.w92-133.abo.wanadoo.fr ([92.133.17.246]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Sat, 21 Feb 2015 12:14:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 21 Feb 2015 12:14:56 +0100 From: peter van der Stok To: Brian E Carpenter Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <54E7824A.4040906@gmail.com> References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> Message-ID: X-Sender: stokcons@xs4all.nl (AsAHeD7lEuZk0ZrPDfGtV74FeSZGUKV6) User-Agent: XS4ALL Webmail Archived-At: Cc: 6tisch-security@ietf.org, Michael Richardson , "Hedanping \(Ana\)" , robert.cragie@gridmerge.com, 6lo@ietf.org, Hannes Tschofenig , anima@ietf.org Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 11:15:01 -0000 Hi Brian, Just a small annotation to your default approach comment. Bootstrapping is subject to different installation procedures. A clear example is the difference between home (plug and play) and the building control where bootstrapping is organized from a database. In the professional domain the order of things can depend on the installer. For example, some may want to bootstrap together with the setup of the network, others may want the network to be ready and then do the security bootstrap. Although I agree with your concern expressed as "a default procedure to decide on the bootstrap procedure", I think there is room for 2-4 different security bootstrap procedures. These procedures will be chosen as function of the application domain and application owner, installer. Peter Brian E Carpenter schreef op 2015-02-20 19:51: > Hannes, > > I agree that we need to compare different approaches. I do have one > concern in the anima context that leads me to the conclusion that > we *must* pick a preferred solution: if we consider a collection of > multivendor equipment in factory condition that we want to bootstrap > itself into a secure network when we apply power, I don't see how > we can avoid having a single default solution. If not, we get a > rather ludicrous situation where we need a single default solution > to the problem of choosing which bootstrap solution to use. > > Regards > Brian > > On 21/02/2015 01:27, Hannes Tschofenig wrote: >> Hi Danping, >> >> I would also like to note that >> [I-D.pritikin-anima-bootstrapping-keyinfra] is only one possible way >> of >> distributing new keys (based on already pre-provisioned certificates). >> I >> would like to understand how it relates to other approaches. >> Particularly if you consider an approach "heavy" it would be good to >> know what your main concerns are since there is no free lunch with >> security and most of the design decisions are trade-offs. >> >> Ciao >> Hannes >> >> On 02/20/2015 12:59 PM, Robert Cragie wrote: >>> [I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch >>> bootstrapping key infrastructure to allow joining device securely and >>> automatically bootstraps itself based on 802.1AR certificate. It >>> can't >>> be directly used in 802.15.4 devices due to the high security >>> complexity >>> and heavy communication overhead.": I disagree with this statement. >>> We >>> used this approach in ZigBee IP. I agree some may think the >>> communication overhead "heavy" but that doesn't mean it can't be >>> done. >>> The associated security complexity is also becoming less onerous as >>> crypto accelerators become built into hardware and cores. >> >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Sat Feb 21 03:44:55 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBB91A6F12; Sat, 21 Feb 2015 03:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 iEUb9MZRwtMW; Sat, 21 Feb 2015 03:44:49 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA3C1A6F11; Sat, 21 Feb 2015 03:44:48 -0800 (PST) Received: from [192.168.131.132] ([80.92.119.127]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M3i8r-1XYgJw2Iy1-00rJFr; Sat, 21 Feb 2015 12:44:29 +0100 Message-ID: <54E86F9A.8020104@gmx.net> Date: Sat, 21 Feb 2015 12:44:26 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: consultancy@vanderstok.org, Brian E Carpenter References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Gqg86Uv725iahDLQicWAW3taVjFAausoO" X-Provags-ID: V03:K0:+7T9JUNVIbli+P19R7yBd3/mH+P5lQ4Q6ASMRsDp+QKyt/exPIM opclHI0YbEMm4ShfX7yq8DP+rsj92xxWjh21iy7Zkg9BVYY2/oBeNZEknmTHuwjvnRF7AYn bXd5l+J+ziZoDkMyGHx+oAwJVulSb9aDHkYZlq02RkSQQB4pYrt+oiT1lJ9Jpnahii1LyKJ slb4Mez7LuRDr6Ql6E4zA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: 6tisch-security@ietf.org, Michael Richardson , "Hedanping \(Ana\)" , robert.cragie@gridmerge.com, 6lo@ietf.org, anima@ietf.org Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 11:44:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Gqg86Uv725iahDLQicWAW3taVjFAausoO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Peter, Brian, I would strongly recommend not to use the term bootstrapping. Replacing it with some other word that explains what you want to do. After-all, we are engineers and not marketing guys. I tend to get a bit nervous when I read terms like "zero-touch" and alike that create the impression that there is no configuration that needs to be done by anyone. Of course, that's not the case. With all the security drafts in NETCONF (zerotouch) or in ANIMA I get the impression that we are re-inventing the wheel not only because we want to work on new stuff but largely because we actually don't understand the state of the art ourselves anymore. I fear that the document also falls into the category of not understanding the state-of-the-art. I understand if someone is not up-to-speed with the most recent efforts in Thread (because they are only visible to members of that organization) but the ZigBee-IP work should be known. While ZigBee-IP may be considered dead by know it also appears to me that any new work in the IETF on security/routing/etc. for IEEE 802.15.4 will have to compete against Thread. Thread has seen a dramatic growth rate in terms of membership and so I doubt that work in the same area has a lot of chances for success. Sorry for the rant but I believe it will help everyone to figure out that most of the groups are actually developing the same solutions over and over again. Now to the issue of the multi-vendor equipment. Adding new solutions (as it is done in ANIMA) while other groups and organizations have already standardized similar technologies (using different terminology) will not make the interoperability any better. I am sure you know that far too wel= l. It would be great to have a conversation (maybe at the next IETF meeting) how the different environments (home environment, enterprise environments/industrial environments) are different in terms of provisioning credentials and configuration information to IoT devices. Needless to say that there are differences and you can see them when you look at how existing products work. That does, however, not necessarily mean that there are no common building blocks. Ciao Hannes On 02/21/2015 12:14 PM, peter van der Stok wrote: > Hi Brian, >=20 > Just a small annotation to your default approach comment. > Bootstrapping is subject to different installation procedures. > A clear example is the difference between home (plug and play) and the > building control where bootstrapping is organized from a database. > In the professional domain the order of things can depend on the > installer. For example, some may want to bootstrap together with the > setup of the network, others may want the network to be ready and then > do the security bootstrap. >=20 > Although I agree with your concern expressed as "a default procedure to= > decide on the bootstrap procedure", I think there is room for 2-4 > different security bootstrap procedures. > These procedures will be chosen as function of the application domain > and application owner, installer. >=20 > Peter >=20 >=20 >=20 > Brian E Carpenter schreef op 2015-02-20 19:51: >> Hannes, >> >> I agree that we need to compare different approaches. I do have one >> concern in the anima context that leads me to the conclusion that >> we *must* pick a preferred solution: if we consider a collection of >> multivendor equipment in factory condition that we want to bootstrap >> itself into a secure network when we apply power, I don't see how >> we can avoid having a single default solution. If not, we get a >> rather ludicrous situation where we need a single default solution >> to the problem of choosing which bootstrap solution to use. >> >> Regards >> Brian >> >> On 21/02/2015 01:27, Hannes Tschofenig wrote: >>> Hi Danping, >>> >>> I would also like to note that >>> [I-D.pritikin-anima-bootstrapping-keyinfra] is only one possible way = of >>> distributing new keys (based on already pre-provisioned certificates)= =2E I >>> would like to understand how it relates to other approaches. >>> Particularly if you consider an approach "heavy" it would be good to >>> know what your main concerns are since there is no free lunch with >>> security and most of the design decisions are trade-offs. >>> >>> Ciao >>> Hannes >>> >>> On 02/20/2015 12:59 PM, Robert Cragie wrote: >>>> [I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch >>>> bootstrapping key infrastructure to allow joining device securely an= d >>>> automatically bootstraps itself based on 802.1AR certificate. It ca= n't >>>> be directly used in 802.15.4 devices due to the high security >>>> complexity >>>> and heavy communication overhead.": I disagree with this statement. = We >>>> used this approach in ZigBee IP. I agree some may think the >>>> communication overhead "heavy" but that doesn't mean it can't be don= e. >>>> The associated security complexity is also becoming less onerous as >>>> crypto accelerators become built into hardware and cores. >>> >>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima --Gqg86Uv725iahDLQicWAW3taVjFAausoO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU6G+bAAoJEGhJURNOOiAtZxgH/34ekWfwg1/ynImQxnqhpxHN RhCnusRFZ+atZ+g+ynR0xLx5b+4QJALi9e1Dh7gxGv7Xcyb9FaScWpxXVe2m4PY7 bDjpPA5944W+fPYkA2SgsPUBqYxGCbuPp9SCfK8KJy3mqeA9xhPdAf+vRPXy0JWm qtleqUvIdaHzb/QGl3NoIKokEttEhNHDBdJDOZoxhZToIXetAFF3gir3KjwUzQKU ANHWP/77kqUEqXsZePn5Q4nMNp3nz+B7sSdTu+W7K9SQvl2ITbZ05D4ug7LndajU L/CecSm4uTe3SHYZSK0WvJ48s6VEyKC9atNHlFU/m7Mg8oKVLJCgFhVseum+mbY= =ahVc -----END PGP SIGNATURE----- --Gqg86Uv725iahDLQicWAW3taVjFAausoO-- From nobody Sat Feb 21 10:54:14 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C041A0406; Sat, 21 Feb 2015 10:54:11 -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 Tyy8iha9fktV; Sat, 21 Feb 2015 10:54:09 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 134011A039F; Sat, 21 Feb 2015 10:54:09 -0800 (PST) Received: by pdev10 with SMTP id v10so15318341pde.7; Sat, 21 Feb 2015 10:54:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IAUVJqETenLIMIhH8QaUYX4sVJEeTUod/4YKVi/CTks=; b=HOV5k6vMtDv3eacOa2I4Kc9wSUP2rdzpxQDhkfQYdDTBSmQehEvigiO+aeBMh8Hsxj 6QXcjzl9zhpIAlZooK8d1q2ffgptkNfSmu7zWAUFpxtctQYKp/oOMomJMLYpqDzMFIaT 04X9Zvlz9nbS8JhcIugmamzFWKQ+QOAwzrEgnSOTG48jDfgNthUcQuyQOq+6Kq0GEjwt zj/wwe1aD+fiD1PixYc0NnfOOQuDeJtDowRgeINQOa9WvTP06ANsqF41c0Z2189icH1g q95/yZalFSWgbuBpQpxGQcstl4wt7RnK7KQLdEBpI2+5FmcqXzk3bWWamc+ooWSUqnhW hWfQ== X-Received: by 10.66.157.231 with SMTP id wp7mr6369535pab.70.1424544848389; Sat, 21 Feb 2015 10:54:08 -0800 (PST) Received: from ?IPv6:2406:e007:4f14:1:28cc:dc4c:9703:6781? ([2406:e007:4f14:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ak7sm10602887pad.47.2015.02.21.10.54.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Feb 2015 10:54:07 -0800 (PST) Message-ID: <54E8D442.6020909@gmail.com> Date: Sun, 22 Feb 2015 07:53:54 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Hannes Tschofenig , consultancy@vanderstok.org References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> In-Reply-To: <54E86F9A.8020104@gmx.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6tisch-security@ietf.org, Michael Richardson , "Hedanping \(Ana\)" , robert.cragie@gridmerge.com, 6lo@ietf.org, anima@ietf.org Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 18:54:12 -0000 Hannes, "Bootstrapping" is a colloquialism, of course, but it conveys the idea of having no prior knowledge which is the main point here. Of course it's true (as Peter said) that different situations call for differences in the solution. The initial target for Anima is "professionally managed networks" and for that we tend to assume that devices are pre-registered in some sense; that is a false assumption for homenets and (I assume) IoT. I am pretty sure that IoT approaches will be a false assumption for large international carrier networks. I know nothing about Thread, whatever and whoever it is. If they want to repeat the Bluetooth error of working in secret, there is nothing we can do about it, neither can we sit back and do nothing. At least draft-pritikin-anima-bootstrapping-keyinfra builds pn IEEE 802.1AR. Regards Brian On 22/02/2015 00:44, Hannes Tschofenig wrote: > Peter, Brian, > > I would strongly recommend not to use the term bootstrapping. Replacing > it with some other word that explains what you want to do. > > After-all, we are engineers and not marketing guys. I tend to get a bit > nervous when I read terms like "zero-touch" and alike that create the > impression that there is no configuration that needs to be done by > anyone. Of course, that's not the case. > > With all the security drafts in NETCONF (zerotouch) or in ANIMA I get > the impression that we are re-inventing the wheel not only because we > want to work on new stuff but largely because we actually don't > understand the state of the art ourselves anymore. I fear that the > document also falls into the > category of not understanding the state-of-the-art. I understand if > someone is not up-to-speed with the most recent efforts in Thread > (because they are only visible to members of that organization) but the > ZigBee-IP work should be known. While ZigBee-IP may be considered dead > by know it also appears to me that any new work in the IETF on > security/routing/etc. for IEEE 802.15.4 will have to compete against > Thread. Thread has seen a dramatic growth rate in terms of membership > and so I doubt that work in the same area has a lot of chances for > success. > > Sorry for the rant but I believe it will help everyone to figure out > that most of the groups are actually developing the same solutions over > and over again. > > Now to the issue of the multi-vendor equipment. Adding new solutions (as > it is done in ANIMA) while other groups and organizations have already > standardized similar technologies (using different terminology) will not > make the interoperability any better. I am sure you know that far too well. > > It would be great to have a conversation (maybe at the next IETF > meeting) how the different environments (home environment, enterprise > environments/industrial environments) are different in terms of > provisioning credentials and configuration information to IoT devices. > Needless to say that there are differences and you can see them when you > look at how existing products work. That does, however, not necessarily > mean that there are no common building blocks. > > Ciao > Hannes > > On 02/21/2015 12:14 PM, peter van der Stok wrote: >> Hi Brian, >> >> Just a small annotation to your default approach comment. >> Bootstrapping is subject to different installation procedures. >> A clear example is the difference between home (plug and play) and the >> building control where bootstrapping is organized from a database. >> In the professional domain the order of things can depend on the >> installer. For example, some may want to bootstrap together with the >> setup of the network, others may want the network to be ready and then >> do the security bootstrap. >> >> Although I agree with your concern expressed as "a default procedure to >> decide on the bootstrap procedure", I think there is room for 2-4 >> different security bootstrap procedures. >> These procedures will be chosen as function of the application domain >> and application owner, installer. >> >> Peter >> >> >> >> Brian E Carpenter schreef op 2015-02-20 19:51: >>> Hannes, >>> >>> I agree that we need to compare different approaches. I do have one >>> concern in the anima context that leads me to the conclusion that >>> we *must* pick a preferred solution: if we consider a collection of >>> multivendor equipment in factory condition that we want to bootstrap >>> itself into a secure network when we apply power, I don't see how >>> we can avoid having a single default solution. If not, we get a >>> rather ludicrous situation where we need a single default solution >>> to the problem of choosing which bootstrap solution to use. >>> >>> Regards >>> Brian >>> >>> On 21/02/2015 01:27, Hannes Tschofenig wrote: >>>> Hi Danping, >>>> >>>> I would also like to note that >>>> [I-D.pritikin-anima-bootstrapping-keyinfra] is only one possible way of >>>> distributing new keys (based on already pre-provisioned certificates). I >>>> would like to understand how it relates to other approaches. >>>> Particularly if you consider an approach "heavy" it would be good to >>>> know what your main concerns are since there is no free lunch with >>>> security and most of the design decisions are trade-offs. >>>> >>>> Ciao >>>> Hannes >>>> >>>> On 02/20/2015 12:59 PM, Robert Cragie wrote: >>>>> [I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch >>>>> bootstrapping key infrastructure to allow joining device securely and >>>>> automatically bootstraps itself based on 802.1AR certificate. It can't >>>>> be directly used in 802.15.4 devices due to the high security >>>>> complexity >>>>> and heavy communication overhead.": I disagree with this statement. We >>>>> used this approach in ZigBee IP. I agree some may think the >>>>> communication overhead "heavy" but that doesn't mean it can't be done. >>>>> The associated security complexity is also becoming less onerous as >>>>> crypto accelerators become built into hardware and cores. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >>>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima > From nobody Sat Feb 21 14:17:18 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E441A00F1; Sat, 21 Feb 2015 14:17:13 -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 h3brc_GLYO6B; Sat, 21 Feb 2015 14:17:12 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AF911A00F0; Sat, 21 Feb 2015 14:17:12 -0800 (PST) Received: by paceu11 with SMTP id eu11so17272124pac.7; Sat, 21 Feb 2015 14:17:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TYwhsCb8hVNgAghS0mrdoB3foEKlLXKpCamO8Zw57uQ=; b=SxmEWSvaI/SX8xfLv/uEAHXdfUNHI26Zy9U38p6fLm5xkfUFKdF2SNgfIzMilBkwh0 9/y12ptKNMDid0+Oq614eSWXwU7XHbwu/Y9Ke2CMfqQZYZbat8GODJtKEaY4kgBgSByr jSqcp+unYRkXVWd/BBFjbkHINgsNNNiCJEyy1NgE+FzCh9NVas2+jMIKBpe8VPMycqGb EZ1DbeBlGYouv0j00vd68AKrAywqdDSm3Q+xusqchzlneynjedfJCN5tgpslUZWJc+gs BMd4DZ785T4h8w5kO++Sw3sRPMA8KzRpVi2xRgCfJxt2hkIFelX6m3oGABh1yYdTy+VZ gR2A== X-Received: by 10.68.239.69 with SMTP id vq5mr7183287pbc.96.1424557031318; Sat, 21 Feb 2015 14:17:11 -0800 (PST) Received: from ?IPv6:2406:e007:4f14:1:28cc:dc4c:9703:6781? ([2406:e007:4f14:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id l2sm30962578pbq.50.2015.02.21.14.17.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Feb 2015 14:17:10 -0800 (PST) Message-ID: <54E903E1.4020004@gmail.com> Date: Sun, 22 Feb 2015 11:17:05 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Hannes Tschofenig , robert.cragie@gridmerge.com, "Hedanping (Ana)" , Michael Richardson References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> In-Reply-To: <54E7824A.4040906@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima@ietf.org" , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 22:17:14 -0000 By the way, even if it's ludicrous... On 21/02/2015 07:51, Brian E Carpenter wrote: > Hannes, > > I agree that we need to compare different approaches. I do have one > concern in the anima context that leads me to the conclusion that > we *must* pick a preferred solution: if we consider a collection of > multivendor equipment in factory condition that we want to bootstrap > itself into a secure network when we apply power, I don't see how > we can avoid having a single default solution. If not, we get a > rather ludicrous situation where we need a single default solution > to the problem of choosing which bootstrap solution to use. This could be done with GDNP. Notionally, it would look like this Discover("Enrollment Method"="Any") followed by Response("Enrollment Method"="Thread", Locator=) or Response("Enrollment Method"="RFCxxxx", Locator=) or whatever. I would consider this unfortunate because it immediately raises interoperability issues. But it could be done, if the world ends up with competing solutions. Brian From nobody Mon Feb 23 00:21:59 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529C21A0369; Mon, 23 Feb 2015 00:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 G7WrQGjWjjFt; Mon, 23 Feb 2015 00:21:51 -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 537C11A0354; Mon, 23 Feb 2015 00:21:50 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.206]) by smtp-cloud3.xs4all.net with ESMTP id vkMl1p00K4SmhUa01kMlVi; Mon, 23 Feb 2015 09:21:47 +0100 Received: from AMontpellier-654-1-246-246.w92-133.abo.wanadoo.fr ([92.133.17.246]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 23 Feb 2015 09:21:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 23 Feb 2015 09:21:45 +0100 From: peter van der Stok To: Brian E Carpenter Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <54E8D442.6020909@gmail.com> References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> Message-ID: <8433fd8e2ec09423daf06db840bcc759@xs4all.nl> X-Sender: stokcons@xs4all.nl (d2NmU6l6z9F+68ohht0pgC8sRnCGJOlh) User-Agent: XS4ALL Webmail Archived-At: Cc: consultancy@vanderstok.org, 6tisch-security@ietf.org, Michael Richardson , "Hedanping \(Ana\)" , robert.cragie@gridmerge.com, 6lo@ietf.org, Hannes Tschofenig , anima@ietf.org Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 08:21:53 -0000 Hi Brian, Hannes, About negotiation of bootstrapping choice: Standardizing components for the "security bootstrapping" of low resource devices, gives a consortium the possibility to agree on a selection of building blocks which is preloaded in the consortium stamped devices, accompanied by parameter settings. The parameter setting may further determine the bootstrap actions. Prefixing parameter settings is a well-known technique. This can be done in the factory; Servers can also be used for that matter. Peter Brian E Carpenter schreef op 2015-02-21 19:53: > Hannes, > > "Bootstrapping" is a colloquialism, of course, but it conveys the idea > of having no prior knowledge which is the main point here. Of course > it's true (as Peter said) that different situations call for > differences > in the solution. The initial target for Anima is "professionally > managed > networks" and for that we tend to assume that devices are > pre-registered > in some sense; that is a false assumption for homenets and (I assume) > IoT. > I am pretty sure that IoT approaches will be a false assumption for > large international carrier networks. > > I know nothing about Thread, whatever and whoever it is. If they > want to repeat the Bluetooth error of working in secret, there is > nothing we can do about it, neither can we sit back and do nothing. > At least draft-pritikin-anima-bootstrapping-keyinfra builds pn > IEEE 802.1AR. > > Regards > Brian > > On 22/02/2015 00:44, Hannes Tschofenig wrote: >> Peter, Brian, >> >> I would strongly recommend not to use the term bootstrapping. >> Replacing >> it with some other word that explains what you want to do. >> >> After-all, we are engineers and not marketing guys. I tend to get a >> bit >> nervous when I read terms like "zero-touch" and alike that create the >> impression that there is no configuration that needs to be done by >> anyone. Of course, that's not the case. >> >> With all the security drafts in NETCONF (zerotouch) or in ANIMA I get >> the impression that we are re-inventing the wheel not only because we >> want to work on new stuff but largely because we actually don't >> understand the state of the art ourselves anymore. I fear that the >> document also falls into the >> category of not understanding the state-of-the-art. I understand if >> someone is not up-to-speed with the most recent efforts in Thread >> (because they are only visible to members of that organization) but >> the >> ZigBee-IP work should be known. While ZigBee-IP may be considered dead >> by know it also appears to me that any new work in the IETF on >> security/routing/etc. for IEEE 802.15.4 will have to compete against >> Thread. Thread has seen a dramatic growth rate in terms of membership >> and so I doubt that work in the same area has a lot of chances for >> success. >> >> Sorry for the rant but I believe it will help everyone to figure out >> that most of the groups are actually developing the same solutions >> over >> and over again. >> >> Now to the issue of the multi-vendor equipment. Adding new solutions >> (as >> it is done in ANIMA) while other groups and organizations have already >> standardized similar technologies (using different terminology) will >> not >> make the interoperability any better. I am sure you know that far too >> well. >> >> It would be great to have a conversation (maybe at the next IETF >> meeting) how the different environments (home environment, enterprise >> environments/industrial environments) are different in terms of >> provisioning credentials and configuration information to IoT devices. >> Needless to say that there are differences and you can see them when >> you >> look at how existing products work. That does, however, not >> necessarily >> mean that there are no common building blocks. >> >> Ciao >> Hannes >> >> On 02/21/2015 12:14 PM, peter van der Stok wrote: >>> Hi Brian, >>> >>> Just a small annotation to your default approach comment. >>> Bootstrapping is subject to different installation procedures. >>> A clear example is the difference between home (plug and play) and >>> the >>> building control where bootstrapping is organized from a database. >>> In the professional domain the order of things can depend on the >>> installer. For example, some may want to bootstrap together with the >>> setup of the network, others may want the network to be ready and >>> then >>> do the security bootstrap. >>> >>> Although I agree with your concern expressed as "a default procedure >>> to >>> decide on the bootstrap procedure", I think there is room for 2-4 >>> different security bootstrap procedures. >>> These procedures will be chosen as function of the application domain >>> and application owner, installer. >>> >>> Peter >>> >>> >>> >>> Brian E Carpenter schreef op 2015-02-20 19:51: >>>> Hannes, >>>> >>>> I agree that we need to compare different approaches. I do have one >>>> concern in the anima context that leads me to the conclusion that >>>> we *must* pick a preferred solution: if we consider a collection of >>>> multivendor equipment in factory condition that we want to bootstrap >>>> itself into a secure network when we apply power, I don't see how >>>> we can avoid having a single default solution. If not, we get a >>>> rather ludicrous situation where we need a single default solution >>>> to the problem of choosing which bootstrap solution to use. >>>> >>>> Regards >>>> Brian >>>> >>>> On 21/02/2015 01:27, Hannes Tschofenig wrote: >>>>> Hi Danping, >>>>> >>>>> I would also like to note that >>>>> [I-D.pritikin-anima-bootstrapping-keyinfra] is only one possible >>>>> way of >>>>> distributing new keys (based on already pre-provisioned >>>>> certificates). I >>>>> would like to understand how it relates to other approaches. >>>>> Particularly if you consider an approach "heavy" it would be good >>>>> to >>>>> know what your main concerns are since there is no free lunch with >>>>> security and most of the design decisions are trade-offs. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> On 02/20/2015 12:59 PM, Robert Cragie wrote: >>>>>> [I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch >>>>>> bootstrapping key infrastructure to allow joining device securely >>>>>> and >>>>>> automatically bootstraps itself based on 802.1AR certificate. It >>>>>> can't >>>>>> be directly used in 802.15.4 devices due to the high security >>>>>> complexity >>>>>> and heavy communication overhead.": I disagree with this >>>>>> statement. We >>>>>> used this approach in ZigBee IP. I agree some may think the >>>>>> communication overhead "heavy" but that doesn't mean it can't be >>>>>> done. >>>>>> The associated security complexity is also becoming less onerous >>>>>> as >>>>>> crypto accelerators become built into hardware and cores. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >>>>> >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >> > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo From nobody Mon Feb 23 10:53:10 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A421A1EFD; Mon, 23 Feb 2015 10:53:07 -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 OM-YcUdosRUW; Mon, 23 Feb 2015 10:53:04 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A580D1A1EEC; Mon, 23 Feb 2015 10:53:00 -0800 (PST) Received: by pdjy10 with SMTP id y10so27410709pdj.6; Mon, 23 Feb 2015 10:53:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9BCNkCZD/HGdQ7fPHRL/ccIhkLI3JvWj2tg0wWtCNsY=; b=eZldD5vE9thacU1cL1Y5U3pAl/PyADyt6EdCjf8yzZpjyrpB4OA/Ael9Gx2TnVm3dq 3X66Wfo3Onfmx0MoXIGuU/7k9acofPkiONtvElwOeBTsAcuverYqpJsz1sqsE7ZSP62Q CL4vKw234lmUvHQa0I3GyoH5qfi7pifYOHzs4Zw94HauAfKUPE6Eimd5lnxH2myz4xB+ McE03dNWXBrIvOSkNj4m+qsE7W1QVXy8IF8gdekbSFAQfCwXW3+5XDFPR2Gof7V//Tm+ XDmRaVSdEUWqq+frY8NqD2drOGx2fv672rM10WUVhl1ga947GFfHvDjtWwe0ywemrW+B E9Xg== X-Received: by 10.70.88.199 with SMTP id bi7mr21212297pdb.126.1424717579912; Mon, 23 Feb 2015 10:52:59 -0800 (PST) Received: from ?IPv6:2406:e007:7ae1:1:28cc:dc4c:9703:6781? ([2406:e007:7ae1:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id dr5sm32200544pdb.48.2015.02.23.10.52.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 10:52:58 -0800 (PST) Message-ID: <54EB7702.2030801@gmail.com> Date: Tue, 24 Feb 2015 07:52:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: consultancy@vanderstok.org References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <8433fd8e2ec09423daf06db840bcc759@xs4all.nl> In-Reply-To: <8433fd8e2ec09423daf06db840bcc759@xs4all.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6tisch-security@ietf.org, Michael Richardson , "Hedanping \(Ana\)" , robert.cragie@gridmerge.com, 6lo@ietf.org, Hannes Tschofenig , anima@ietf.org Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 18:53:07 -0000 On 23/02/2015 21:21, peter van der Stok wrote: > Hi Brian, Hannes, > > About negotiation of bootstrapping choice: > > Standardizing components for the "security bootstrapping" of low resource devices, gives a consortium the possibility to agree > on a selection of building blocks > which is preloaded in the consortium stamped devices, > accompanied by parameter settings. And that is a problem. I mean the word "consortium" is a problem; it amounts to a cartel and excludes non-consortium members from the market. That is not what we want in the Internet. We may have to deal with it as part of reality, but we have to focus on open standards that everybody can implement. Whether the open standard is based on draft-pritikin or something else is a separate question, of course. In the last few days I've had to deal with two vendor-specific wireless enrollment issues (garage door openers and remote weather sensors) and I don't think that is a direction we should encourage. > The parameter setting may further determine the bootstrap actions. > Prefixing parameter settings is a well-known technique. And it's exactly what we want to avoid in autonomic networks. Brian > This can be done in the factory; Servers can also be used for that matter. > > Peter > > Brian E Carpenter schreef op 2015-02-21 19:53: >> Hannes, >> >> "Bootstrapping" is a colloquialism, of course, but it conveys the idea >> of having no prior knowledge which is the main point here. Of course >> it's true (as Peter said) that different situations call for differences >> in the solution. The initial target for Anima is "professionally managed >> networks" and for that we tend to assume that devices are pre-registered >> in some sense; that is a false assumption for homenets and (I assume) IoT. >> I am pretty sure that IoT approaches will be a false assumption for >> large international carrier networks. >> >> I know nothing about Thread, whatever and whoever it is. If they >> want to repeat the Bluetooth error of working in secret, there is >> nothing we can do about it, neither can we sit back and do nothing. >> At least draft-pritikin-anima-bootstrapping-keyinfra builds pn >> IEEE 802.1AR. >> >> Regards >> Brian >> >> On 22/02/2015 00:44, Hannes Tschofenig wrote: >>> Peter, Brian, >>> >>> I would strongly recommend not to use the term bootstrapping. Replacing >>> it with some other word that explains what you want to do. >>> >>> After-all, we are engineers and not marketing guys. I tend to get a bit >>> nervous when I read terms like "zero-touch" and alike that create the >>> impression that there is no configuration that needs to be done by >>> anyone. Of course, that's not the case. >>> >>> With all the security drafts in NETCONF (zerotouch) or in ANIMA I get >>> the impression that we are re-inventing the wheel not only because we >>> want to work on new stuff but largely because we actually don't >>> understand the state of the art ourselves anymore. I fear that the >>> document also falls into the >>> category of not understanding the state-of-the-art. I understand if >>> someone is not up-to-speed with the most recent efforts in Thread >>> (because they are only visible to members of that organization) but the >>> ZigBee-IP work should be known. While ZigBee-IP may be considered dead >>> by know it also appears to me that any new work in the IETF on >>> security/routing/etc. for IEEE 802.15.4 will have to compete against >>> Thread. Thread has seen a dramatic growth rate in terms of membership >>> and so I doubt that work in the same area has a lot of chances for >>> success. >>> >>> Sorry for the rant but I believe it will help everyone to figure out >>> that most of the groups are actually developing the same solutions over >>> and over again. >>> >>> Now to the issue of the multi-vendor equipment. Adding new solutions (as >>> it is done in ANIMA) while other groups and organizations have already >>> standardized similar technologies (using different terminology) will not >>> make the interoperability any better. I am sure you know that far too well. >>> >>> It would be great to have a conversation (maybe at the next IETF >>> meeting) how the different environments (home environment, enterprise >>> environments/industrial environments) are different in terms of >>> provisioning credentials and configuration information to IoT devices. >>> Needless to say that there are differences and you can see them when you >>> look at how existing products work. That does, however, not necessarily >>> mean that there are no common building blocks. >>> >>> Ciao >>> Hannes >>> >>> On 02/21/2015 12:14 PM, peter van der Stok wrote: >>>> Hi Brian, >>>> >>>> Just a small annotation to your default approach comment. >>>> Bootstrapping is subject to different installation procedures. >>>> A clear example is the difference between home (plug and play) and the >>>> building control where bootstrapping is organized from a database. >>>> In the professional domain the order of things can depend on the >>>> installer. For example, some may want to bootstrap together with the >>>> setup of the network, others may want the network to be ready and then >>>> do the security bootstrap. >>>> >>>> Although I agree with your concern expressed as "a default procedure to >>>> decide on the bootstrap procedure", I think there is room for 2-4 >>>> different security bootstrap procedures. >>>> These procedures will be chosen as function of the application domain >>>> and application owner, installer. >>>> >>>> Peter >>>> >>>> >>>> >>>> Brian E Carpenter schreef op 2015-02-20 19:51: >>>>> Hannes, >>>>> >>>>> I agree that we need to compare different approaches. I do have one >>>>> concern in the anima context that leads me to the conclusion that >>>>> we *must* pick a preferred solution: if we consider a collection of >>>>> multivendor equipment in factory condition that we want to bootstrap >>>>> itself into a secure network when we apply power, I don't see how >>>>> we can avoid having a single default solution. If not, we get a >>>>> rather ludicrous situation where we need a single default solution >>>>> to the problem of choosing which bootstrap solution to use. >>>>> >>>>> Regards >>>>> Brian >>>>> >>>>> On 21/02/2015 01:27, Hannes Tschofenig wrote: >>>>>> Hi Danping, >>>>>> >>>>>> I would also like to note that >>>>>> [I-D.pritikin-anima-bootstrapping-keyinfra] is only one possible way of >>>>>> distributing new keys (based on already pre-provisioned certificates). I >>>>>> would like to understand how it relates to other approaches. >>>>>> Particularly if you consider an approach "heavy" it would be good to >>>>>> know what your main concerns are since there is no free lunch with >>>>>> security and most of the design decisions are trade-offs. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> On 02/20/2015 12:59 PM, Robert Cragie wrote: >>>>>>> [I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch >>>>>>> bootstrapping key infrastructure to allow joining device securely and >>>>>>> automatically bootstraps itself based on 802.1AR certificate. It can't >>>>>>> be directly used in 802.15.4 devices due to the high security >>>>>>> complexity >>>>>>> and heavy communication overhead.": I disagree with this statement. We >>>>>>> used this approach in ZigBee IP. I agree some may think the >>>>>>> communication overhead "heavy" but that doesn't mean it can't be done. >>>>>>> The associated security complexity is also becoming less onerous as >>>>>>> crypto accelerators become built into hardware and cores. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Anima mailing list >>>>>> Anima@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >>> >> >> _______________________________________________ >> 6lo mailing list >> 6lo@ietf.org >> https://www.ietf.org/mailman/listinfo/6lo > From nobody Mon Feb 23 12:59:11 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835F91A6F17; Mon, 23 Feb 2015 12:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 UgYm6QU4uIOF; Mon, 23 Feb 2015 12:59:05 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B9A71A6F01; Mon, 23 Feb 2015 12:59:05 -0800 (PST) Received: by labge10 with SMTP id ge10so21142434lab.12; Mon, 23 Feb 2015 12:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bgCjGCwkEawEEeUye/leKIL+oF4mXOZ2UJEybeW+puQ=; b=XH0OLVJTFWNJPTFeQg6GqltJoAr7xI+iR8tLi/21aahCmujN60bEAt2jxqLJgbkV1S Zc3LJFGn0BzweRVB3/HbxAnSOsKFeowpuwgvnFyQDlcsbgW/l8uhH3RfU+ZySPwzYMDn iff8W2gphPZ95GRQavK/rCliDHGbNlRdQJR9FQhh5i8ohgccuPlxi5CLKDmAYBk8m/xR 1/qL6V4oRkIJSp8p85fmY0sOQpY8KLEwLlOTXgDs/6jjSY6ntdPitKbcR3WgQ3gLMy8L s0iBPesBJQgG71HZmMjonX9mnG8HLBL2hp6i9EwnMuB7YcCWI7uTy2RZk0H30qPAY4+u nIrg== MIME-Version: 1.0 X-Received: by 10.112.141.225 with SMTP id rr1mr10670599lbb.71.1424725143416; Mon, 23 Feb 2015 12:59:03 -0800 (PST) Received: by 10.114.187.13 with HTTP; Mon, 23 Feb 2015 12:59:03 -0800 (PST) In-Reply-To: <54E86F9A.8020104@gmx.net> References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> Date: Mon, 23 Feb 2015 14:59:03 -0600 Message-ID: From: Behcet Sarikaya To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: consultancy@vanderstok.org, 6tisch-security <6tisch-security@ietf.org>, Michael Richardson , "Hedanping \(Ana\)" , robert.cragie@gridmerge.com, "6lo@ietf.org" <6lo@ietf.org>, "anima@ietf.org" Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 20:59:07 -0000 Hi Hannes, On Sat, Feb 21, 2015 at 5:44 AM, Hannes Tschofenig wrote: > Peter, Brian, > > I would strongly recommend not to use the term bootstrapping. Replacing > it with some other word that explains what you want to do. > > After-all, we are engineers and not marketing guys. I tend to get a bit > nervous when I read terms like "zero-touch" and alike that create the > impression that there is no configuration that needs to be done by > anyone. Of course, that's not the case. Sorry but, Hannes, you have been saying these things for some time but I have not heard your proposal yet. What should we call it if not bootstrapping? > > With all the security drafts in NETCONF (zerotouch) or in ANIMA I get > the impression that we are re-inventing the wheel not only because we > want to work on new stuff but largely because we actually don't > understand the state of the art ourselves anymore. I fear that the > document also falls into the > category of not understanding the state-of-the-art. Don't worry about it. > I understand if > someone is not up-to-speed with the most recent efforts in Thread > (because they are only visible to members of that organization) but the > ZigBee-IP work should be known. While ZigBee-IP may be considered dead > by know You mean by now? > it also appears to me that any new work in the IETF on > security/routing/etc. for IEEE 802.15.4 will have to compete against > Thread. Thread has seen a dramatic growth rate in terms of membership > and so I doubt that work in the same area has a lot of chances for > success. > Yes but what is Thread's solution on this? Is this different than what we have in IETF? > Sorry for the rant but I believe it will help everyone to figure out > that most of the groups are actually developing the same solutions over > and over again. Agreed, so it should be based on IETF work? > > Now to the issue of the multi-vendor equipment. Adding new solutions (as > it is done in ANIMA) while other groups and organizations have already > standardized similar technologies (using different terminology) will not > make the interoperability any better. I am sure you know that far too well. > > It would be great to have a conversation (maybe at the next IETF > meeting) how the different environments (home environment, enterprise > environments/industrial environments) are different in terms of > provisioning credentials and configuration information to IoT devices. Exactly. Maybe this is what Peter is pointing at when he says several solutions can be developed, different for each environment. > Needless to say that there are differences and you can see them when you > look at how existing products work. That does, however, not necessarily > mean that there are no common building blocks. Good point. > > Ciao > Hannes > > On 02/21/2015 12:14 PM, peter van der Stok wrote: >> Hi Brian, >> >> Just a small annotation to your default approach comment. >> Bootstrapping is subject to different installation procedures. >> A clear example is the difference between home (plug and play) and the >> building control where bootstrapping is organized from a database. >> In the professional domain the order of things can depend on the >> installer. For example, some may want to bootstrap together with the >> setup of the network, others may want the network to be ready and then >> do the security bootstrap. >> >> Although I agree with your concern expressed as "a default procedure to >> decide on the bootstrap procedure", I think there is room for 2-4 >> different security bootstrap procedures. >> These procedures will be chosen as function of the application domain >> and application owner, installer. >> >> Peter >> >> >> >> Brian E Carpenter schreef op 2015-02-20 19:51: >>> Hannes, >>> >>> I agree that we need to compare different approaches. I do have one >>> concern in the anima context that leads me to the conclusion that >>> we *must* pick a preferred solution: if we consider a collection of >>> multivendor equipment in factory condition that we want to bootstrap >>> itself into a secure network when we apply power, I don't see how >>> we can avoid having a single default solution. If not, we get a >>> rather ludicrous situation where we need a single default solution >>> to the problem of choosing which bootstrap solution to use. >>> >>> Regards >>> Brian >>> >>> On 21/02/2015 01:27, Hannes Tschofenig wrote: >>>> Hi Danping, >>>> >>>> I would also like to note that >>>> [I-D.pritikin-anima-bootstrapping-keyinfra] is only one possible way of >>>> distributing new keys (based on already pre-provisioned certificates). I >>>> would like to understand how it relates to other approaches. >>>> Particularly if you consider an approach "heavy" it would be good to >>>> know what your main concerns are since there is no free lunch with >>>> security and most of the design decisions are trade-offs. >>>> >>>> Ciao >>>> Hannes >>>> >>>> On 02/20/2015 12:59 PM, Robert Cragie wrote: >>>>> [I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch >>>>> bootstrapping key infrastructure to allow joining device securely and >>>>> automatically bootstraps itself based on 802.1AR certificate. It can't >>>>> be directly used in 802.15.4 devices due to the high security >>>>> complexity >>>>> and heavy communication overhead.": I disagree with this statement. We >>>>> used this approach in ZigBee IP. I agree some may think the >>>>> communication overhead "heavy" but that doesn't mean it can't be done. >>>>> The associated security complexity is also becoming less onerous as >>>>> crypto accelerators become built into hardware and cores. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >>>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima > > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > From nobody Mon Feb 23 17:32:22 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1C51A1A79; Mon, 23 Feb 2015 17:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 E5WYRwmx9xJL; Mon, 23 Feb 2015 17:32:17 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0118.outbound.protection.outlook.com [207.46.100.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEFF41A01F2; Mon, 23 Feb 2015 17:32:17 -0800 (PST) Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB505.namprd05.prod.outlook.com (10.141.71.140) with Microsoft SMTP Server (TLS) id 15.1.93.16; Tue, 24 Feb 2015 01:32:15 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.93.16; Tue, 24 Feb 2015 01:32:13 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.145]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.145]) with mapi id 15.01.0093.004; Tue, 24 Feb 2015 01:32:14 +0000 From: Kent Watsen To: Brian E Carpenter , Hannes Tschofenig , "robert.cragie@gridmerge.com" , "Hedanping (Ana)" , Michael Richardson Thread-Topic: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things Thread-Index: AQHQPsAs1Fk6oPIjq0+DdhpeTE5AU5z5k/7lgABrGACABNMFgA== Date: Tue, 24 Feb 2015 01:32:13 +0000 Message-ID: References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> In-Reply-To: <54E7824A.4040906@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.14] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-forefront-prvs: 04976078F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(24454002)(377454003)(164054003)(189002)(51704005)(199003)(68736005)(106356001)(19580395003)(101416001)(105586002)(2900100001)(2950100001)(102836002)(15975445007)(66066001)(64706001)(83506001)(62966003)(46102003)(19580405001)(92566002)(77156002)(122556002)(99286002)(2656002)(87936001)(93886004)(106116001)(50986999)(36756003)(76176999)(86362001)(40100003)(97736003)(2501003)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <0DDF429DE23B10428B5AC669D6888268@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2015 01:32:13.5969 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB505; X-OriginatorOrg: juniper.net Archived-At: Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "anima@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 01:32:20 -0000 I also have been thinking that there can be only one default for a given piece of vendor equipment. Though it is conceivable that a vendor may offer different SKUs to set which default is used. That said, it seems that the "default mechanism" can actually be a suite of mechanisms. I postulate that there can be a safe ordering of bootstrapping mechanisms, so long as a denial-of-service on an earlier mechanism doesn't lead to a weaker mechanism. To this I add that physical presence (e.g., USB flash drive) is more secure than networking, and that local networking (link-local) is more secure than WAN networking. The question is if using a more secure mechanism actually makes a difference. For instance, one might think that information loaded from a USB flash drive could forego needing to be signed, but why do this if the risk it introduces is non-zero and the signing operation is low-burden? Thanks, Kent On 2/20/15, 1:51 PM, "Brian E Carpenter" wrote: >Hannes, > >I agree that we need to compare different approaches. I do have one >concern in the anima context that leads me to the conclusion that >we *must* pick a preferred solution: if we consider a collection of >multivendor equipment in factory condition that we want to bootstrap >itself into a secure network when we apply power, I don't see how >we can avoid having a single default solution. If not, we get a >rather ludicrous situation where we need a single default solution >to the problem of choosing which bootstrap solution to use. > >Regards > Brian > >On 21/02/2015 01:27, Hannes Tschofenig wrote: >> Hi Danping, >>=20 >> I would also like to note that >> [I-D.pritikin-anima-bootstrapping-keyinfra] is only one possible way of >> distributing new keys (based on already pre-provisioned certificates). I >> would like to understand how it relates to other approaches. >> Particularly if you consider an approach "heavy" it would be good to >> know what your main concerns are since there is no free lunch with >> security and most of the design decisions are trade-offs. >>=20 >> Ciao >> Hannes >>=20 >> On 02/20/2015 12:59 PM, Robert Cragie wrote: >>> [I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch >>> bootstrapping key infrastructure to allow joining device securely and >>> automatically bootstraps itself based on 802.1AR certificate. It can't >>> be directly used in 802.15.4 devices due to the high security >>>complexity >>> and heavy communication overhead.": I disagree with this statement. We >>> used this approach in ZigBee IP. I agree some may think the >>> communication overhead "heavy" but that doesn't mean it can't be done. >>> The associated security complexity is also becoming less onerous as >>> crypto accelerators become built into hardware and cores. >>=20 >>=20 >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >>=20 > >_______________________________________________ >Anima mailing list >Anima@ietf.org >https://www.ietf.org/mailman/listinfo/anima From nobody Tue Feb 24 13:13:12 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689F71A8934; Tue, 24 Feb 2015 13:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.57 X-Spam-Level: X-Spam-Status: No, score=-0.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 XKepvFo81z1V; Tue, 24 Feb 2015 13:13:08 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7BB1A8925; Tue, 24 Feb 2015 13:13:07 -0800 (PST) Received: from [192.168.10.152] ([5.148.12.26]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lngv5-1XsyEz3DhP-00hvEk; Tue, 24 Feb 2015 22:12:47 +0100 Message-ID: <54EB4F24.7030609@gmx.net> Date: Mon, 23 Feb 2015 17:02:44 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Brian E Carpenter , consultancy@vanderstok.org References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> In-Reply-To: <54E8D442.6020909@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cRmb3eqjp1C1MUDaDdj7iCuUSPSbQ4PGh" X-Provags-ID: V03:K0:QMURGqhFk0YG7ZkIOuGBDxCraIWfPXQZFWsdoECOi8aIbb9zFbM hmjeRS0NgV6a/rbH2mBYARCebhyEKhPHtoVaMdZAMY9m7Tvb8CN7viPY7pvGjiSuujXMvMl Zhc4a4nTPQG17+BUOr8qQ4UYFlCOryn7bRF93SgKDAgTqPHaXoGlzx4y5uauOcHYLqulQ+C oU/Im8BOcm78bggQrp7nw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: 6tisch-security@ietf.org, Michael Richardson , "Hedanping \(Ana\)" , robert.cragie@gridmerge.com, 6lo@ietf.org, anima@ietf.org Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 21:13:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cRmb3eqjp1C1MUDaDdj7iCuUSPSbQ4PGh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Brian, On 02/21/2015 07:53 PM, Brian E Carpenter wrote: > Hannes, >=20 > "Bootstrapping" is a colloquialism, of course, but it conveys the idea > of having no prior knowledge which is the main point here. The problem with the term is that it is ill-defined. In many of the cases it actually does not mean that there is no prior knowledge. For the specifications we are talking about here we are assuming various information pre-configured, such as certificates, trust anchors, and other configuration parameters. That's not exactly my understanding of "no prior knowledge". Of course > it's true (as Peter said) that different situations call for difference= s > in the solution. The initial target for Anima is "professionally manage= d > networks" and for that we tend to assume that devices are pre-registere= d > in some sense; that is a false assumption for homenets and (I assume) I= oT. > I am pretty sure that IoT approaches will be a false assumption for > large international carrier networks. >=20 > I know nothing about Thread, whatever and whoever it is. Here is an intro document: http://threadgroup.org/Portals/0/documents/events/ThreadIntro.pdf If they > want to repeat the Bluetooth error of working in secret, there is > nothing we can do about it, neither can we sit back and do nothing. The IEEE, the Bluetooth SIG, and Thread have (as organizations) many things in common. Only member companies can influence the specification content but, unlike the IEEE, Thread is a fairly new organization and hence their specifications have not yet been released since they are still work in progress. Both IEEE and Bluetooth SIG release their specifications to the general public when they are finalized. I am not sure I agree that the Bluetooth SIG made huge mistakes since otherwise the technology wouldn't be so successful. > At least draft-pritikin-anima-bootstrapping-keyinfra builds pn > IEEE 802.1AR. To be honest, I am a bit doubtful about the value of the IEEE 802.1AR specification. The specification basically says to use certificates and the PKI (using RSA / ECC-based keys) for authenticating devices and defines a MIB for configuring various aspects of that infrastructure (using SNMP). It also lists the fields of a certificate and defines the "device identity" in Section 7.2.8 as "This may include the unique device serial number assigned by the manufacturer or any other suitable unique DN value that the issuer prefers." I am sure there are some (not described) good reasons why the specification exists but it is not as earth-shaking as you might think. Particularly, if you plan to use it in ANIMA you might ask yourself how many management interfaces you actually need to provision and configure credentials on devices. (This actually leads us back to my original mail.= ) I have to think about the use of these specifications for Internet of Things scenarios I am a bit hesitant to immediately get excited. I already have other protocols that provide this functionality and much more functionality (such as a software update mechanism) without the use of a network management protocol. In general, the specification offers too many options. How does all of this relate to the work you are doing in the ANIMA working group? I do not necessarily have any objections against a new attempt to solve problems that have already been solved before. There may be short-comings with the existing solutions. Of course, that assumes that one has ideas about what should be improved about the existing solutions. Ciao Hannes >=20 > Regards > Brian >=20 > On 22/02/2015 00:44, Hannes Tschofenig wrote: >> Peter, Brian, >> >> I would strongly recommend not to use the term bootstrapping. Replacin= g >> it with some other word that explains what you want to do. >> >> After-all, we are engineers and not marketing guys. I tend to get a bi= t >> nervous when I read terms like "zero-touch" and alike that create the >> impression that there is no configuration that needs to be done by >> anyone. Of course, that's not the case. >> >> With all the security drafts in NETCONF (zerotouch) or in ANIMA I get >> the impression that we are re-inventing the wheel not only because we >> want to work on new stuff but largely because we actually don't >> understand the state of the art ourselves anymore. I fear that the >> document also falls into the >> category of not understanding the state-of-the-art. I understand if >> someone is not up-to-speed with the most recent efforts in Thread >> (because they are only visible to members of that organization) but th= e >> ZigBee-IP work should be known. While ZigBee-IP may be considered dead= >> by know it also appears to me that any new work in the IETF on >> security/routing/etc. for IEEE 802.15.4 will have to compete against >> Thread. Thread has seen a dramatic growth rate in terms of membership >> and so I doubt that work in the same area has a lot of chances for >> success. >> >> Sorry for the rant but I believe it will help everyone to figure out >> that most of the groups are actually developing the same solutions ove= r >> and over again. >> >> Now to the issue of the multi-vendor equipment. Adding new solutions (= as >> it is done in ANIMA) while other groups and organizations have already= >> standardized similar technologies (using different terminology) will n= ot >> make the interoperability any better. I am sure you know that far too = well. >> >> It would be great to have a conversation (maybe at the next IETF >> meeting) how the different environments (home environment, enterprise >> environments/industrial environments) are different in terms of >> provisioning credentials and configuration information to IoT devices.= >> Needless to say that there are differences and you can see them when y= ou >> look at how existing products work. That does, however, not necessaril= y >> mean that there are no common building blocks. >> >> Ciao >> Hannes >> >> On 02/21/2015 12:14 PM, peter van der Stok wrote: >>> Hi Brian, >>> >>> Just a small annotation to your default approach comment. >>> Bootstrapping is subject to different installation procedures. >>> A clear example is the difference between home (plug and play) and th= e >>> building control where bootstrapping is organized from a database. >>> In the professional domain the order of things can depend on the >>> installer. For example, some may want to bootstrap together with the >>> setup of the network, others may want the network to be ready and the= n >>> do the security bootstrap. >>> >>> Although I agree with your concern expressed as "a default procedure = to >>> decide on the bootstrap procedure", I think there is room for 2-4 >>> different security bootstrap procedures. >>> These procedures will be chosen as function of the application domain= >>> and application owner, installer. >>> >>> Peter >>> >>> >>> >>> Brian E Carpenter schreef op 2015-02-20 19:51: >>>> Hannes, >>>> >>>> I agree that we need to compare different approaches. I do have one >>>> concern in the anima context that leads me to the conclusion that >>>> we *must* pick a preferred solution: if we consider a collection of >>>> multivendor equipment in factory condition that we want to bootstrap= >>>> itself into a secure network when we apply power, I don't see how >>>> we can avoid having a single default solution. If not, we get a >>>> rather ludicrous situation where we need a single default solution >>>> to the problem of choosing which bootstrap solution to use. >>>> >>>> Regards >>>> Brian >>>> >>>> On 21/02/2015 01:27, Hannes Tschofenig wrote: >>>>> Hi Danping, >>>>> >>>>> I would also like to note that >>>>> [I-D.pritikin-anima-bootstrapping-keyinfra] is only one possible wa= y of >>>>> distributing new keys (based on already pre-provisioned certificate= s). I >>>>> would like to understand how it relates to other approaches. >>>>> Particularly if you consider an approach "heavy" it would be good t= o >>>>> know what your main concerns are since there is no free lunch with >>>>> security and most of the design decisions are trade-offs. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> On 02/20/2015 12:59 PM, Robert Cragie wrote: >>>>>> [I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch >>>>>> bootstrapping key infrastructure to allow joining device securely = and >>>>>> automatically bootstraps itself based on 802.1AR certificate. It = can't >>>>>> be directly used in 802.15.4 devices due to the high security >>>>>> complexity >>>>>> and heavy communication overhead.": I disagree with this statement= =2E We >>>>>> used this approach in ZigBee IP. I agree some may think the >>>>>> communication overhead "heavy" but that doesn't mean it can't be d= one. >>>>>> The associated security complexity is also becoming less onerous a= s >>>>>> crypto accelerators become built into hardware and cores. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >>>>> >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >> >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 --cRmb3eqjp1C1MUDaDdj7iCuUSPSbQ4PGh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU608lAAoJEGhJURNOOiAtpeQH/RLj3hLaw1wUFCQS6+0jmCT2 7hwP1hE1B6X8rWoC6YHKNZt3BjOL34lIfAkw8iHIRp9n5X15ZLyAhwT9g1PxhkDn YqPtIQLJPsG5t+2H1+qUIO+3v6emA9o/olbl2kWJUWUHA+mXQ+owzd//xUvyeYxH 26PtzLKt0mj0H7mtZF+PUOSB2jXXsX6H3Ra4bjakZkwpP1EwHweYpl7lej+kdf/S PsVDVV+qI+BvZsdFHk3TO2LSVymd80BHc3Ukx8Peu9QOJUJbCS9ECi8R+hB77lTh 8NeCuCIJQIZQeXPpaSw8CR/Zo3VHMQNG09zwW1cQvj+KFrioPUKRUjuGwiCdZ5M= =QhWp -----END PGP SIGNATURE----- --cRmb3eqjp1C1MUDaDdj7iCuUSPSbQ4PGh-- From nobody Tue Feb 24 16:40:31 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD40B1A0AFE; Tue, 24 Feb 2015 16:40:28 -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 sT7KvCp2YlZs; Tue, 24 Feb 2015 16:40:26 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28A11A1A4A; Tue, 24 Feb 2015 16:40:26 -0800 (PST) Received: by pabrd3 with SMTP id rd3so816674pab.1; Tue, 24 Feb 2015 16:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ahUNCQOAzfJvCYWsseq9rJV/uPFzkrseYj8jEPjdyA8=; b=JEK9aYwjZsJUgBIVnsBbaRoafSrgY1IoYxDxrQKD5m37psPazaz/DpztNrvGDfAUKT MEeMDqg0F1OAtID12rEIoTaVqstbGA88p3epInhfhg4Z2ohL5LqypfnSUA7qqhvAcZoF RWhih6kvArMzfkkaES1YyhQYe2l0EH90BrVdHelO7k8vhjf9VbWJz93Fzj5/CBCLuo8q qUcP6pS3lWGAHCmkBFiONUvbWsAh4XaGzpybV/GGiR9QrbKntV/k50rlvtsBhfgCf3Fo 4qwyW1Oi6qU+wKpTVVPtDarCDNyRvYyh0rkLz94K9t4yWc3s0vMAjln0VvPVa4zjBibv Y/Ow== X-Received: by 10.68.208.101 with SMTP id md5mr997813pbc.28.1424824825964; Tue, 24 Feb 2015 16:40:25 -0800 (PST) Received: from ?IPv6:2406:e007:5009:1:28cc:dc4c:9703:6781? ([2406:e007:5009:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id kd9sm29427293pab.0.2015.02.24.16.40.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 16:40:24 -0800 (PST) Message-ID: <54ED19F4.6030706@gmail.com> Date: Wed, 25 Feb 2015 13:40:20 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kent Watsen , Hannes Tschofenig , "robert.cragie@gridmerge.com" , "Hedanping (Ana)" , Michael Richardson References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "anima@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 00:40:28 -0000 Hi Kent, On 24/02/2015 14:32, Kent Watsen wrote: > > I also have been thinking that there can be only one default for a given > piece of vendor equipment. Though it is conceivable that a vendor may > offer different SKUs to set which default is used. I fear that we may have to assume the worst (i.e. there is no universal solution that all vendors will support). > That said, it seems that the "default mechanism" can actually be a suite > of mechanisms. I postulate that there can be a safe ordering of > bootstrapping mechanisms, so long as a denial-of-service on an earlier > mechanism doesn't lead to a weaker mechanism. Sigh: you are probably right. This sounds like a major topic in itself, so Anima will have to be flexible. > To this I add that physical > presence (e.g., USB flash drive) is more secure than networking, Well in theory yes, but don't forget the Stuxnet propagation mechanism. > and that > local networking (link-local) is more secure than WAN networking. I would extend link-local to domain-local (for a professionally managed network), but otherwise I agree. > The > question is if using a more secure mechanism actually makes a difference. > For instance, one might think that information loaded from a USB flash > drive could forego needing to be signed, but why do this if the risk it > introduces is non-zero and the signing operation is low-burden? Makes sense in a large network where USB drives found in the parking lot might be considered a risk. Brian > > Thanks, > Kent > > > > On 2/20/15, 1:51 PM, "Brian E Carpenter" > wrote: > >> Hannes, >> >> I agree that we need to compare different approaches. I do have one >> concern in the anima context that leads me to the conclusion that >> we *must* pick a preferred solution: if we consider a collection of >> multivendor equipment in factory condition that we want to bootstrap >> itself into a secure network when we apply power, I don't see how >> we can avoid having a single default solution. If not, we get a >> rather ludicrous situation where we need a single default solution >> to the problem of choosing which bootstrap solution to use. >> >> Regards >> Brian >> >> On 21/02/2015 01:27, Hannes Tschofenig wrote: >>> Hi Danping, >>> >>> I would also like to note that >>> [I-D.pritikin-anima-bootstrapping-keyinfra] is only one possible way of >>> distributing new keys (based on already pre-provisioned certificates). I >>> would like to understand how it relates to other approaches. >>> Particularly if you consider an approach "heavy" it would be good to >>> know what your main concerns are since there is no free lunch with >>> security and most of the design decisions are trade-offs. >>> >>> Ciao >>> Hannes >>> >>> On 02/20/2015 12:59 PM, Robert Cragie wrote: >>>> [I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch >>>> bootstrapping key infrastructure to allow joining device securely and >>>> automatically bootstraps itself based on 802.1AR certificate. It can't >>>> be directly used in 802.15.4 devices due to the high security >>>> complexity >>>> and heavy communication overhead.": I disagree with this statement. We >>>> used this approach in ZigBee IP. I agree some may think the >>>> communication overhead "heavy" but that doesn't mean it can't be done. >>>> The associated security complexity is also becoming less onerous as >>>> crypto accelerators become built into hardware and cores. >>> >>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > From nobody Wed Feb 25 06:49:28 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876EF1A802E; Wed, 25 Feb 2015 06:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 fEFCFmJGKNZr; Wed, 25 Feb 2015 06:49:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DB3E1A802A; Wed, 25 Feb 2015 06:49:17 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPP84944; Wed, 25 Feb 2015 14:49:15 +0000 (GMT) Received: from SZXEML426-HUB.china.huawei.com (10.82.67.181) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Feb 2015 14:49:14 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.208]) by szxeml426-hub.china.huawei.com ([10.82.67.181]) with mapi id 14.03.0158.001; Wed, 25 Feb 2015 22:48:56 +0800 From: "Hedanping (Ana)" To: "robert.cragie@gridmerge.com" , "Michael Richardson" , Behcet Sarikaya Thread-Topic: [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things Thread-Index: AdBRAvGc69BnJhn/Q3CGDKBvEioXpgAAaKNQ Date: Wed, 25 Feb 2015 14:48:56 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D92F887@szxeml557-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D92F855@szxeml557-mbs.china.huawei.com> In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D92F855@szxeml557-mbs.china.huawei.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.27.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "anima@ietf.org" , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 14:49:25 -0000 Hi Robert, Thank you very much for the comments, please see my reply inline. > -----Original Message----- > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > Sent: Friday, February 20, 2015 7:59 PM > To: Hedanping (Ana); Michael Richardson > Cc: 6tisch-security@ietf.org; anima@ietf.org; 6lo@ietf.org > Subject: Re: [6lo] Comments needed for Security Bootstrapping of IEEE > 802.15.4 based Internet of Things >=20 > Hi Danping, >=20 > I have some general comments on the draft and some additional comments > inline, bracketed by >=20 > General comments: >=20 > I think the general model is good but could be simplified to two cases: >=20 > 1) Where the authenticator is in direct communication > 2) Where the authenticator is not in direct communication (relay case) >=20 > My reasoning is because: >=20 > a) There isn't much distinction between RFD and FFD from an authenticat= ion > perspective > b) There isn't much distinction between joining an existing network and= initial > joining >=20 > If you think there are distinctions, then they need clarifying. >=20 IMHO, there are distinctions between the network level bootstrapping and jo= ining device level bootstrapping. Network level bootstrapping includes at l= east two cases: network start-up case and re-commissioning case. The bootst= rapping network level bootstrapping request should be different from that o= f joining device level request in order to converge efficiently. I agree th= at they need to be clarified. >From authentication messaging point of view, there is no much distinction b= etween RFD and FFD. This feature allows scalability and we don't need to re= invent the wheel and develop different authentication message for different= types of devices. > Other points: > * "Because IEEE 802.15.4 maximum payload size is 128 Bytes, a standard > security bootstrapping protocol should be light-weight with low complex= ity.": > I think it would be better to say "should ideally be light-weight with = low > complexity". There may be requirements where high security strength is > required and therefore this will necessarily involve more communication > overhead and processing. > * I think the hierarchical joining description is generally useful. > * It is conceivable for an RFD to communicate directly with a 6LBR so I= don't > think that should be excluded from Figure 1 * > "[I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch > bootstrapping key infrastructure to allow joining device securely and > automatically bootstraps itself based on 802.1AR certificate. It can't= be > directly used in 802.15.4 devices due to the high security complexity a= nd > heavy communication overhead.": I disagree with this statement. We used > this approach in ZigBee IP. I agree some may think the communication > overhead "heavy" but that doesn't mean it can't be done. The associated > security complexity is also becoming less onerous as crypto accelerator= s > become built into hardware and cores. ' can't be directly used' means that fragmentation is needed and certifica= te management is needed once 802.1AR is applied. Thank you for providing this application information, the expression will b= e modified in the next version. > * The document mentions a couple of protocols (EAP and PANA) but doesn'= t > go into enough detail on how those are deployed.=20 This is the initial version, we expect to reach consensus on the mechani= sm and architecture at first. >Also, there are other > choices. The document could give generic names to the particular > communications and then add a section to give examples. Good point. We are preparing to do so. The certificate approach you impl= emented is useful, are you willing to contribute to the new section? > Robert > On 02/02/2015 08:13, Hedanping (Ana) wrote: > Hi Michael, > Thank you for the interest and the questions are illuminating. Please s= ee my > reply inline. >=20 > > I have added a number of CCs, I think that this fits into ANIMA best= . > > >=20 > > Hedanping (Ana) wrote: > > > A new draft is submitted, it's about the security bootstrappin= g > > > architecture and methods for IoT networks that implement > IETF > > protocols > > > (e.g. 6LoWPAN, 6lo, RPL, AODV, DSR) over IEEE 802.15.4. > > > Two types of bootstrapping methods are developed: network > level > > > bootstrapping and joining device level bootstrapping > > > > > The link is: > > > > http://tools.ietf.org/html/draft-he-iot-security-bootstrapping-00 > > > > I read the document with great interest. > > I found that you explained the incremental boot-strapping process > quite well, > > and nobody has clearly articulated the process yet. People have jus= t > assumed > > that everyone knows this process, but really it needs to get written > down, so I > > thank you for doing that. >=20 > Thank you for the praise. As it is the initial version, more discussion= s and > comments are needed to make it better. > I agree that it has not generally been articulated well. To some e= xtent, > it is because up to now, there has been no "the one way to do it". Ther= efore, > something ZigBee IP is a profile which defines one particular way of do= ing it. > There are other ways as well, of course. I guess the question is whethe= r it > can be generalised sufficiently to be generally applicable and whether = that is > in fact worth doing >=20 >=20 This draft targets at 802.15.4 networks, and one standard approach is po= ssible. It is worth of generalizing an automatic mechanism for bootstrappin= g IoT network. As the size of the network can be large, network start-up or= re-commission will be the burden of the network administrator. =20 > > > > If EAP is used, PANA can be used to relay the authentication > message > > from configured FFDs to 6LBR. If the validation is successful, t= he > > IP address and network key are generated and delivered to the > FFD. > > > > But, EAP-TLS with PANA is exactly what the Zigbee IP specification h= as > specified. > > Do you envision any changes from that specification? >=20 > Zigbee IP specification was developed to enable IP address for Zigbee > application, thus the protocol stack are built on IETF's standards, inc= luding > EAP-TLS. > As discussed in many working groups, TLS might result in a significant > amount of retransmissions due to unreliable communication capability of= the > network and device, thus energy will be consumed fast. > I think EAP over DTLS /profiled DTLS could be a good option. > EAP-TLS only uses TLS handshakes carried as EAP payloads, therefor= e > has little to do with TLS as it is normally used, i.e. over TCP. If you= then start > to look at the difference between EAP-TLS (over UDP) and DTLS handshake= s > over UDP, there is actually not much difference. In some areas, EAP is > actually preferable (fragmentation and header overhead) >=20 >=20 I agree that the handshake process is similar, however DTLS and UDP is s= upported by CoAP and match the feature of constrained device. Reusing the p= rotocols can reduce the HW and SW cost. Besides, EAP-TLS only supports cert= ificate as authentication material, while allowing other materials would be= desired for IoT network. >=20 > > A minority of people had prefered this mechanism for 6tisch-security= , > but > > none stepped forward to write up that mechanism. Perhaps this > draft could > > fulfill that need? >=20 > Yes, we should describe more clearly on this mechanism, and maybe this > draft is a right place. It would be great if folks in the mailing list = make > comments and contribution on this technical point. > I am happy to write up that mechanism >=20 That's great, we'll discuss more and move this work forward. >=20 > > From the ANIMA and 6tisch-security point of view, my view is that th= is > is all > > about the choice of certificates for the TLS setup. Do you have any > view on > > how that might work? >=20 > For unconstrained environment, I agree with you. But when it comes to > constrained device and constrained network communication, TLS might not > be a good choice as mentioned before. Certificate is not a good choice = either > due to the high cost. > I would like to say: it is about the choice of credential type for secu= re channel > setup. The good candidates of credential types are Raw public key, Phys= ical > Unclonable Function (PUF). > There certainly are overheads in certificates but in the 802.1AR > scenario (draft-pritikin-anima-bootstrapping-keyinfra-01) it has clear > value. >=20 >=20 Agree >=20 > > > > The 6tisch-security bootstrap process aims to create a > > YANG/CBOR-over-CoAP-over-DTLS session between a Join Coordinator > and the > > Joining Node: over that management link, security (and timeslot > scheduling) > > would be provisioned. >=20 > CoAP-DTLS coincides with my idea. > Yang sounds like at a higher level, but I think EAP is actually the mec= hanism > running behind ^_^ > Again, in this document, it might be better to > abstract this session and describe what it is used for >=20 =20 I am not sure whether I understand the meaning of 'session'. >=20 >=20 > Regards, > Ana >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo >=20 From nobody Wed Feb 25 11:06:31 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D691A6F28; Wed, 25 Feb 2015 11:06:28 -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 aFUj7lve6Mm2; Wed, 25 Feb 2015 11:06:27 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C777E1A6F03; Wed, 25 Feb 2015 11:06:26 -0800 (PST) Received: by pablf10 with SMTP id lf10so7344399pab.12; Wed, 25 Feb 2015 11:06:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RboVMV6kxyGrRtc9yRXnN9puBe7j9n9T/rYmgoPk8LI=; b=dDo1BFy3WVESJsRXKXtk1zyfbnqVoAjcEXav3MeKpwLfh21qpB5n0Uu8Cw5amY86hF 6zfsvjlrFVmkVaSMN3dlGvBSVcIQDjH2lpUc28u5Nj2H6iMts18SWqM/Xx/DukiRaNls 1X/3svzvDgE+itK4rIh02ut6g2lFoTYrqyDxC6Wck7zF4QD8KfqsWyd6mwbZlGLnMQFw CVRdGHrNeaeUjT5gJHSATXu1x43q4J5s/JXZG4UrC3I23UEYa9vclWXA3GyY+vEzt7GD Bdvo0xas/wXExeXQpU6hOTKlzQbPYiLW60jVx5uyhgKhb6yrAWmUp8veGVdkOcOakkuG Jbmw== X-Received: by 10.68.232.200 with SMTP id tq8mr7846514pbc.133.1424891186050; Wed, 25 Feb 2015 11:06:26 -0800 (PST) Received: from ?IPv6:2406:e007:6564:1:28cc:dc4c:9703:6781? ([2406:e007:6564:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id y2sm42904529pdm.31.2015.02.25.11.06.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Feb 2015 11:06:24 -0800 (PST) Message-ID: <54EE1D2E.5040707@gmail.com> Date: Thu, 26 Feb 2015 08:06:22 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Hedanping (Ana)" , "robert.cragie@gridmerge.com" , Michael Richardson , Behcet Sarikaya References: <77FA386512F0D748BC7C02C36EB1106D92F855@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D92F887@szxeml557-mbs.china.huawei.com> In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D92F887@szxeml557-mbs.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "anima@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: [Anima] Device vs network bootstrapping [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 19:06:28 -0000 Hi, On 26/02/2015 03:48, Hedanping (Ana) wrote: ... > IMHO, there are distinctions between the network level bootstrapping > and joining device level bootstrapping. Network level bootstrapping > includes at least two cases: network start-up case and re-commissioning > case. The bootstrapping network level bootstrapping request should be > different from that of joining device level request in order to converge > efficiently. I agree that they need to be clarified. How does a device that has just been switched on know whether it is joining an existing network or is simply one of many devices that are attempting to form a new network? How does a set of devices that are attempting to form a new network know that they are re-commissioning a previously existing network? The only safe assumption seem to be that devices cannot know these things. Autonomic devices have no state at power-on. Brian From nobody Wed Feb 25 13:25:46 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E04C1A88D1; Wed, 25 Feb 2015 13:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 Kp5A0KPktzKL; Wed, 25 Feb 2015 13:25:40 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789651A88C3; Wed, 25 Feb 2015 13:25:39 -0800 (PST) Received: by labgm9 with SMTP id gm9so6904816lab.2; Wed, 25 Feb 2015 13:25:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BiaR6Ay+yaG7vTNbwsaZnfiXyw8K/IZVa9Ue1Y0jGZs=; b=L5FOb2knDDypjN1eHVJ2DbNfsVgGA/SZT+bZ4+nERHCXbb51TlE4mQtg1vs5EemFhO eIr/qOkiwljy8luflPiGGMr7PDz7ZxJ80dRtJ4VrYq8ie0adUgXYshqzyA9hmvSRRkZk jeSwpYaGHdeMOjWeeqmugAsPSFN+XyLfSpLCpIS9OBTVwf+3hJPObP3Phesb7eS1C8fn IZ5X4y0D62+vttl0SvGKrd3+Ko6S9xDZ7X/G6vpMeFxjnBDaY7vRLRyA3x5YDd4zzjj0 uRtKJYXPmtPzHU2P7IpsTaYtmpkcuPezoBY8qDDWGV/dBTNZacGiTovEVw4KJXfhTJrG Dy3Q== MIME-Version: 1.0 X-Received: by 10.152.45.74 with SMTP id k10mr4734431lam.108.1424899537781; Wed, 25 Feb 2015 13:25:37 -0800 (PST) Received: by 10.114.187.13 with HTTP; Wed, 25 Feb 2015 13:25:37 -0800 (PST) In-Reply-To: <54EB4F24.7030609@gmx.net> References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <54EB4F24.7030609@gmx.net> Date: Wed, 25 Feb 2015 15:25:37 -0600 Message-ID: From: Behcet Sarikaya To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: consultancy@vanderstok.org, 6tisch-security <6tisch-security@ietf.org>, Michael Richardson , "Hedanping \(Ana\)" , robert.cragie@gridmerge.com, "6lo@ietf.org" <6lo@ietf.org>, "anima@ietf.org" Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 21:25:42 -0000 On Mon, Feb 23, 2015 at 10:02 AM, Hannes Tschofenig wrote: > Hi Brian, > > On 02/21/2015 07:53 PM, Brian E Carpenter wrote: >> Hannes, >> >> "Bootstrapping" is a colloquialism, of course, but it conveys the idea >> of having no prior knowledge which is the main point here. > > The problem with the term is that it is ill-defined. > > In many of the cases it actually does not mean that there is no prior > knowledge. For the specifications we are talking about here we are > assuming various information pre-configured, such as certificates, trust > anchors, and other configuration parameters. That's not exactly my > understanding of "no prior knowledge". > > Of course >> it's true (as Peter said) that different situations call for differences >> in the solution. The initial target for Anima is "professionally managed >> networks" and for that we tend to assume that devices are pre-registered >> in some sense; that is a false assumption for homenets and (I assume) IoT. >> I am pretty sure that IoT approaches will be a false assumption for >> large international carrier networks. >> >> I know nothing about Thread, whatever and whoever it is. > > Here is an intro document: > http://threadgroup.org/Portals/0/documents/events/ThreadIntro.pdf > I think we need to clarify here that Thread Group is formed to deal with home environments. Enterprise or industrial environments seem to be excluded. Regards, Behcet > > If they >> want to repeat the Bluetooth error of working in secret, there is >> nothing we can do about it, neither can we sit back and do nothing. > > The IEEE, the Bluetooth SIG, and Thread have (as organizations) many > things in common. Only member companies can influence the specification > content but, unlike the IEEE, Thread is a fairly new organization and > hence their specifications have not yet been released since they are > still work in progress. Both IEEE and Bluetooth SIG release their > specifications to the general public when they are finalized. > > I am not sure I agree that the Bluetooth SIG made huge mistakes since > otherwise the technology wouldn't be so successful. > >> At least draft-pritikin-anima-bootstrapping-keyinfra builds pn >> IEEE 802.1AR. > > To be honest, I am a bit doubtful about the value of the IEEE 802.1AR > specification. > > The specification basically says to use certificates and the PKI (using > RSA / ECC-based keys) for authenticating devices and defines a MIB for > configuring various aspects of that infrastructure (using SNMP). > > It also lists the fields of a certificate and defines the "device > identity" in Section 7.2.8 as "This may include the unique device serial > number assigned by the manufacturer or any other suitable unique DN > value that the issuer prefers." > > I am sure there are some (not described) good reasons why the > specification exists but it is not as earth-shaking as you might think. > Particularly, if you plan to use it in ANIMA you might ask yourself how > many management interfaces you actually need to provision and configure > credentials on devices. (This actually leads us back to my original mail.) > > I have to think about the use of these specifications for Internet of > Things scenarios I am a bit hesitant to immediately get excited. I > already have other protocols that provide this functionality and much > more functionality (such as a software update mechanism) without the use > of a network management protocol. In general, the specification offers > too many options. > > How does all of this relate to the work you are doing in the ANIMA > working group? I do not necessarily have any objections against a new > attempt to solve problems that have already been solved before. There > may be short-comings with the existing solutions. Of course, that > assumes that one has ideas about what should be improved about the > existing solutions. > > Ciao > Hannes > >> >> Regards >> Brian >> >> On 22/02/2015 00:44, Hannes Tschofenig wrote: >>> Peter, Brian, >>> >>> I would strongly recommend not to use the term bootstrapping. Replacing >>> it with some other word that explains what you want to do. >>> >>> After-all, we are engineers and not marketing guys. I tend to get a bit >>> nervous when I read terms like "zero-touch" and alike that create the >>> impression that there is no configuration that needs to be done by >>> anyone. Of course, that's not the case. >>> >>> With all the security drafts in NETCONF (zerotouch) or in ANIMA I get >>> the impression that we are re-inventing the wheel not only because we >>> want to work on new stuff but largely because we actually don't >>> understand the state of the art ourselves anymore. I fear that the >>> document also falls into the >>> category of not understanding the state-of-the-art. I understand if >>> someone is not up-to-speed with the most recent efforts in Thread >>> (because they are only visible to members of that organization) but the >>> ZigBee-IP work should be known. While ZigBee-IP may be considered dead >>> by know it also appears to me that any new work in the IETF on >>> security/routing/etc. for IEEE 802.15.4 will have to compete against >>> Thread. Thread has seen a dramatic growth rate in terms of membership >>> and so I doubt that work in the same area has a lot of chances for >>> success. >>> >>> Sorry for the rant but I believe it will help everyone to figure out >>> that most of the groups are actually developing the same solutions over >>> and over again. >>> >>> Now to the issue of the multi-vendor equipment. Adding new solutions (as >>> it is done in ANIMA) while other groups and organizations have already >>> standardized similar technologies (using different terminology) will not >>> make the interoperability any better. I am sure you know that far too well. >>> >>> It would be great to have a conversation (maybe at the next IETF >>> meeting) how the different environments (home environment, enterprise >>> environments/industrial environments) are different in terms of >>> provisioning credentials and configuration information to IoT devices. >>> Needless to say that there are differences and you can see them when you >>> look at how existing products work. That does, however, not necessarily >>> mean that there are no common building blocks. >>> >>> Ciao >>> Hannes >>> >>> On 02/21/2015 12:14 PM, peter van der Stok wrote: >>>> Hi Brian, >>>> >>>> Just a small annotation to your default approach comment. >>>> Bootstrapping is subject to different installation procedures. >>>> A clear example is the difference between home (plug and play) and the >>>> building control where bootstrapping is organized from a database. >>>> In the professional domain the order of things can depend on the >>>> installer. For example, some may want to bootstrap together with the >>>> setup of the network, others may want the network to be ready and then >>>> do the security bootstrap. >>>> >>>> Although I agree with your concern expressed as "a default procedure to >>>> decide on the bootstrap procedure", I think there is room for 2-4 >>>> different security bootstrap procedures. >>>> These procedures will be chosen as function of the application domain >>>> and application owner, installer. >>>> >>>> Peter >>>> >>>> >>>> >>>> Brian E Carpenter schreef op 2015-02-20 19:51: >>>>> Hannes, >>>>> >>>>> I agree that we need to compare different approaches. I do have one >>>>> concern in the anima context that leads me to the conclusion that >>>>> we *must* pick a preferred solution: if we consider a collection of >>>>> multivendor equipment in factory condition that we want to bootstrap >>>>> itself into a secure network when we apply power, I don't see how >>>>> we can avoid having a single default solution. If not, we get a >>>>> rather ludicrous situation where we need a single default solution >>>>> to the problem of choosing which bootstrap solution to use. >>>>> >>>>> Regards >>>>> Brian >>>>> >>>>> On 21/02/2015 01:27, Hannes Tschofenig wrote: >>>>>> Hi Danping, >>>>>> >>>>>> I would also like to note that >>>>>> [I-D.pritikin-anima-bootstrapping-keyinfra] is only one possible way of >>>>>> distributing new keys (based on already pre-provisioned certificates). I >>>>>> would like to understand how it relates to other approaches. >>>>>> Particularly if you consider an approach "heavy" it would be good to >>>>>> know what your main concerns are since there is no free lunch with >>>>>> security and most of the design decisions are trade-offs. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> On 02/20/2015 12:59 PM, Robert Cragie wrote: >>>>>>> [I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch >>>>>>> bootstrapping key infrastructure to allow joining device securely and >>>>>>> automatically bootstraps itself based on 802.1AR certificate. It can't >>>>>>> be directly used in 802.15.4 devices due to the high security >>>>>>> complexity >>>>>>> and heavy communication overhead.": I disagree with this statement. We >>>>>>> used this approach in ZigBee IP. I agree some may think the >>>>>>> communication overhead "heavy" but that doesn't mean it can't be done. >>>>>>> The associated security complexity is also becoming less onerous as >>>>>>> crypto accelerators become built into hardware and cores. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Anima mailing list >>>>>> Anima@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > From nobody Wed Feb 25 16:52:08 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B35B1A9237; Wed, 25 Feb 2015 16:52:04 -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 O9qUXkflg3id; Wed, 25 Feb 2015 16:52:01 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74E41A1A33; Wed, 25 Feb 2015 16:52:01 -0800 (PST) Received: by padfa1 with SMTP id fa1so9523414pad.2; Wed, 25 Feb 2015 16:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=f+GzGrU/ZiBF50mtmHt1L6Mi7m4HBgGiwskSBhTOdmI=; b=yYEdhVo1KPcV+1ei2gmjEd2NK+6Kw29iJpWKVJlhjnYS5jqpUrRIZk3BExoh2yWTrE 03GH8UqNw7upud9QwMYFv8Xd5GIcXjn+aVVw/lXzg7eOYr5P5tonVOyg1zJhyJoWcwEl 2zHeps5KsxJhzltHSziu/OLVT+VsNsIPhFyOeTBMZ8ksaHj9TgB+oTWhlitVd4tKC9aL 7UM3WEI/H39JIpjTd0NnaOHPMBGAhKJj5iJwuVP/KUBMGR8rIOkol+TqIh4QfoUZntf8 zR4FNKJf1pLqL0DkjtvIa05u5KJKREcjcn9CK2o3z3nQC1sf0EYtx6PzoISplsSBbXVz qkpg== X-Received: by 10.70.30.3 with SMTP id o3mr10229887pdh.114.1424911920838; Wed, 25 Feb 2015 16:52:00 -0800 (PST) Received: from ?IPv6:2406:e007:6564:1:28cc:dc4c:9703:6781? ([2406:e007:6564:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id v2sm43272820pdm.77.2015.02.25.16.51.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Feb 2015 16:51:59 -0800 (PST) Message-ID: <54EE6E31.8030609@gmail.com> Date: Thu, 26 Feb 2015 13:52:01 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: sarikaya@ieee.org, Hannes Tschofenig References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <54EB4F24.7030609@gmx.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: consultancy@vanderstok.org, 6tisch-security <6tisch-security@ietf.org>, Michael Richardson , "Hedanping \(Ana\)" , robert.cragie@gridmerge.com, "6lo@ietf.org" <6lo@ietf.org>, "anima@ietf.org" Subject: [Anima] Thread [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 00:52:04 -0000 On 26/02/2015 10:25, Behcet Sarikaya wrote: ... >>> I know nothing about Thread, whatever and whoever it is. >> >> Here is an intro document: >> http://threadgroup.org/Portals/0/documents/events/ThreadIntro.pdf Thanks for that. It seems to have all the downsides of secretive ad hoc membership-based consortia, except for the upside of a RAND-RF IPR policy. > I think we need to clarify here that Thread Group is formed to deal > with home environments. > > Enterprise or industrial environments seem to be excluded. So far. The boundary between this and larger building services networks is pretty fuzzy, isn't it? In any case, should we (the WGs on copy, and perhaps some others) be asking the IAB to arrange a meaningful liaison with Thread? Back at Hannes: is there a spec for their approach to security enrollment? Brian From nobody Wed Feb 25 17:44:55 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF191A92E6; Wed, 25 Feb 2015 17:44:53 -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 E_9VxibT3xyw; Wed, 25 Feb 2015 17:44:51 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9345F1A92E3; Wed, 25 Feb 2015 17:44:51 -0800 (PST) Received: by pablf10 with SMTP id lf10so9733360pab.12; Wed, 25 Feb 2015 17:44:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C95H5R0vEEfrMF75w2xDKdnpQgUABTXhsGQqYks4gQM=; b=UYKVhzL0LgrU56UHIj+LKDh+y4SHHdDJnl4ExKA592f8AusHATaF2W2RZDtry9jPqc BM3ExgXgseYpcn8Ta15ijidMPNgS7wRWLLQr7bMB6DEqKRDbYaMUEmjgMxx3EMsoOVC1 INoqhdtsFWi4UY55GdZTTaEqR4vrHvq+9zYh3xKqFYw9ZpRaG5gaCbhCY4tsLhK55WXn PR0vCZ2Lv0IFCXBoLoyttz/C5m0Lc1jkWZESU0cCVmUobAZckS45XlxbVpWdiIwBB8Oc UDp1ZKfNd24e9h2NTGO5xdvapiDLOclEhVZe2b3BRFKuQfH/PyJtjeKKLNQ07Nq8r6o8 3AQw== X-Received: by 10.66.154.17 with SMTP id vk17mr10326511pab.5.1424915089854; Wed, 25 Feb 2015 17:44:49 -0800 (PST) Received: from ?IPv6:2001:420:c0c8:1006::332? ([2001:420:c0c8:1006::332]) by mx.google.com with ESMTPSA id ni8sm6634483pdb.83.2015.02.25.17.44.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Feb 2015 17:44:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ralph Droms In-Reply-To: <54EE6E31.8030609@gmail.com> Date: Wed, 25 Feb 2015 17:44:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <92A14CCB-ABBB-4C80-B3FA-AF21F398EA7A@gmail.com> References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <54EB4F24.7030609@gmx.net> <54EE6E31.8030609@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: consultancy@vanderstok.org, 6tisch-security <6tisch-security@ietf.org>, Michael Richardson , "Hedanping \(Ana\)" , Robert Cragie , sarikaya@ieee.org, "6lo@ietf.org" <6lo@ietf.org>, Hannes Tschofenig , "anima@ietf.org" Subject: Re: [Anima] [6lo] Thread [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 01:44:53 -0000 > On Feb 25, 2015, at 4:52 PM 2/25/15, Brian E Carpenter = wrote: >=20 > On 26/02/2015 10:25, Behcet Sarikaya wrote: >=20 > ... >>>> I know nothing about Thread, whatever and whoever it is. >>>=20 >>> Here is an intro document: >>> http://threadgroup.org/Portals/0/documents/events/ThreadIntro.pdf >=20 > Thanks for that. It seems to have all the downsides of secretive ad = hoc > membership-based consortia, except for the upside of a RAND-RF IPR > policy. >=20 >> I think we need to clarify here that Thread Group is formed to deal >> with home environments. >>=20 >> Enterprise or industrial environments seem to be excluded. >=20 > So far. The boundary between this and larger building services > networks is pretty fuzzy, isn't it? >=20 > In any case, should we (the WGs on copy, and perhaps some others) > be asking the IAB to arrange a meaningful liaison with Thread? What would we want to get from a liaison arrangement with Thread? We had a liaison with ZigBee Alliance but let it lapse as ZA appears to = have finished its work on Z-IP. We might also consider a liaison arrangement with Wi-SUN Alliance = because of the Wi-SUN FAN spec. As I seem to sit at an intersection of WG chairs and IAB, I can bring up = the issue if we think there is reason to move forward. - Ralph >=20 > Back at Hannes: is there a spec for their approach to security > enrollment? >=20 > Brian >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo From nobody Wed Feb 25 19:12:48 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3721A1A03; Wed, 25 Feb 2015 19:12:46 -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 eWgV55k05nTs; Wed, 25 Feb 2015 19:12:44 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5211A0387; Wed, 25 Feb 2015 19:12:44 -0800 (PST) Received: by padbj1 with SMTP id bj1so10350393pad.5; Wed, 25 Feb 2015 19:12:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SAuV4hw8MMi7TyH1dl9MYjkz5J4T+O7nkka+luj7/Zg=; b=jKeb6kvUOXzgmo5YninWtJu0wcYtXPrU7mIWw/sXjo1YIvermkKmIFQh5Fq/+0NWPS GiRjcHOpS7MPP8qckNXjSTAixYtPeFgNTSBZ4kRCbzbAI+L/NBHJBVfBNj7CLhSfIq9Q wWuzTxo9Ky8T9yavy5ZwdZqAufjWYHtV3hLmSJGhgLvRZ6ccx/CRfXrLAOjYWf5KnyqH ABca4c1G/ck5y3auZBINhYqeC3qDjfH6Bri7vSVxyn1/hoXsWoPYm7lrLaR0sHiUx05D Jo1YONl2jsnGRDHTHOUkThs/5SPSGW17c6aYUikAw1/PjGh7t3ijWaJr+BXCYS9E1Iih nCZQ== X-Received: by 10.66.118.129 with SMTP id km1mr11044346pab.112.1424920363941; Wed, 25 Feb 2015 19:12:43 -0800 (PST) Received: from ?IPv6:2406:e007:6564:1:28cc:dc4c:9703:6781? ([2406:e007:6564:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ox10sm42696897pbc.17.2015.02.25.19.12.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Feb 2015 19:12:42 -0800 (PST) Message-ID: <54EE8F2C.2030301@gmail.com> Date: Thu, 26 Feb 2015 16:12:44 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ralph Droms References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <54EB4F24.7030609@gmx.net> <54EE6E31.8030609@gmail.com> <92A14CCB-ABBB-4C80-B3FA-AF21F398EA7A@gmail.com> In-Reply-To: <92A14CCB-ABBB-4C80-B3FA-AF21F398EA7A@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: consultancy@vanderstok.org, 6tisch-security <6tisch-security@ietf.org>, Michael Richardson , "Hedanping \(Ana\)" , Robert Cragie , sarikaya@ieee.org, "6lo@ietf.org" <6lo@ietf.org>, Hannes Tschofenig , "anima@ietf.org" Subject: Re: [Anima] [6lo] Thread [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 03:12:46 -0000 Hi Ralph, On 26/02/2015 14:44, Ralph Droms wrote: > >> On Feb 25, 2015, at 4:52 PM 2/25/15, Brian E Carpenter wrote: >> >> On 26/02/2015 10:25, Behcet Sarikaya wrote: >> >> ... >>>>> I know nothing about Thread, whatever and whoever it is. >>>> >>>> Here is an intro document: >>>> http://threadgroup.org/Portals/0/documents/events/ThreadIntro.pdf >> >> Thanks for that. It seems to have all the downsides of secretive ad hoc >> membership-based consortia, except for the upside of a RAND-RF IPR >> policy. >> >>> I think we need to clarify here that Thread Group is formed to deal >>> with home environments. >>> >>> Enterprise or industrial environments seem to be excluded. >> >> So far. The boundary between this and larger building services >> networks is pretty fuzzy, isn't it? >> >> In any case, should we (the WGs on copy, and perhaps some others) >> be asking the IAB to arrange a meaningful liaison with Thread? > > What would we want to get from a liaison arrangement with Thread? I think the main thing is to have a chance to review their specs before finalization. They seem to touch numerous IETF WGs directly or indirectly (at least homenet, anima, 6lo, 6tisch and probably 6man indirectly). Both sides have everything to gain by detecting misfits and overlaps ASAP. Brian > > We had a liaison with ZigBee Alliance but let it lapse as ZA appears to have finished its work on Z-IP. > > We might also consider a liaison arrangement with Wi-SUN Alliance because of the Wi-SUN FAN spec. > > As I seem to sit at an intersection of WG chairs and IAB, I can bring up the issue if we think there is reason to move forward. > > - Ralph > >> >> Back at Hannes: is there a spec for their approach to security >> enrollment? >> >> Brian >> >> _______________________________________________ >> 6lo mailing list >> 6lo@ietf.org >> https://www.ietf.org/mailman/listinfo/6lo > > From nobody Wed Feb 25 22:18:28 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3431A1AA9; Wed, 25 Feb 2015 22:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 kCWU_N6uvR3p; Wed, 25 Feb 2015 22:18:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C181A1A10; Wed, 25 Feb 2015 22:18:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSZ76341; Thu, 26 Feb 2015 06:18:21 +0000 (GMT) Received: from SZXEML425-HUB.china.huawei.com (10.82.67.180) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Feb 2015 06:18:20 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.208]) by szxeml425-hub.china.huawei.com ([10.82.67.180]) with mapi id 14.03.0158.001; Thu, 26 Feb 2015 14:18:07 +0800 From: "Hedanping (Ana)" To: Brian E Carpenter , "robert.cragie@gridmerge.com" , "Michael Richardson" , Behcet Sarikaya Thread-Topic: [6lo] Device vs network bootstrapping [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] Thread-Index: AQHQUS4tx8J/6+pZKkyjUrHlb5vjfp0Cbtew Date: Thu, 26 Feb 2015 06:18:07 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D92FAEF@szxeml557-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D92F855@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D92F887@szxeml557-mbs.china.huawei.com> <54EE1D2E.5040707@gmail.com> In-Reply-To: <54EE1D2E.5040707@gmail.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.94.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "anima@ietf.org" , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Anima] [6lo] Device vs network bootstrapping [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 06:18:25 -0000 Hi Brian, Please see my reply inline. > -----Original Message----- > From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Thursday, February 26, 2015 3:06 AM > To: Hedanping (Ana); robert.cragie@gridmerge.com; Michael Richardson; > Behcet Sarikaya > Cc: 6tisch-security@ietf.org; anima@ietf.org; 6lo@ietf.org > Subject: [6lo] Device vs network bootstrapping [Comments needed for Secu= rity > Bootstrapping of IEEE 802.15.4 based Internet of Things] >=20 > Hi, >=20 > On 26/02/2015 03:48, Hedanping (Ana) wrote: > ... > > IMHO, there are distinctions between the network level bootstrapping > > and joining device level bootstrapping. Network level bootstrapping > > includes at least two cases: network start-up case and > > re-commissioning case. The bootstrapping network level bootstrapping > > request should be different from that of joining device level request > > in order to converge efficiently. I agree that they need to be clarifi= ed. >=20 > How does a device that has just been switched on know whether it is join= ing > an existing network or is simply one of many devices that are attempting= to > form a new network? >=20 The device can learn from its neighbors about the network state. For instan= ce, from the bits indicating network ID and device type in hello/beaconing = message, the device knows whether a neighbor belongs to an existing network= or it is a 'new' device as well, and whether the neighbor has ability to f= orward/verify authentication message. > How does a set of devices that are attempting to form a new network know > that they are re-commissioning a previously existing network? >=20 Again, the state can be learnt by exchanging the network ID that devices be= longed to > The only safe assumption seem to be that devices cannot know these thing= s. > Autonomic devices have no state at power-on. >=20 The devices cannot know these things by themselves, but through collaborati= on it is possible. From this aspect, I do not object that autonomic devices= have no state at power-on. Regards, Ana From nobody Thu Feb 26 00:23:13 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720911A1B3D; Thu, 26 Feb 2015 00:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 cVrYx7K7CpzZ; Thu, 26 Feb 2015 00:23:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B59AD1A1B0C; Thu, 26 Feb 2015 00:23:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSZ88380; Thu, 26 Feb 2015 08:23:05 +0000 (GMT) Received: from SZXEML434-HUB.china.huawei.com (10.82.67.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Feb 2015 08:23:04 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.208]) by szxeml434-hub.china.huawei.com ([10.82.67.225]) with mapi id 14.03.0158.001; Thu, 26 Feb 2015 16:22:34 +0800 From: "Hedanping (Ana)" To: "sarikaya@ieee.org" , Hannes Tschofenig , Michael Richardson , "robert.cragie@gridmerge.com" , "consultancy@vanderstok.org" , Brian E Carpenter Thread-Topic: [6lo] [Anima] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things Thread-Index: AQHQT6uSD0GBXwxvX0y9UjwipdA/2p0Ck7Sw Date: Thu, 26 Feb 2015 08:22:33 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D92FB28@szxeml557-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.94.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "anima@ietf.org" , 6tisch-security <6tisch-security@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 08:23:09 -0000 SGkgSGFubmVzLCBCZWhjZXQgYW5kIGFsbCwNCg0KPiA+IEl0IHdvdWxkIGJlIGdyZWF0IHRvIGhh dmUgYSBjb252ZXJzYXRpb24gKG1heWJlIGF0IHRoZSBuZXh0IElFVEYNCj4gPiBtZWV0aW5nKSBo b3cgdGhlIGRpZmZlcmVudCBlbnZpcm9ubWVudHMgKGhvbWUgZW52aXJvbm1lbnQsIGVudGVycHJp c2UNCj4gPiBlbnZpcm9ubWVudHMvaW5kdXN0cmlhbCBlbnZpcm9ubWVudHMpIGFyZSBkaWZmZXJl bnQgaW4gdGVybXMgb2YNCj4gPiBwcm92aXNpb25pbmcgY3JlZGVudGlhbHMgYW5kIGNvbmZpZ3Vy YXRpb24gaW5mb3JtYXRpb24gdG8gSW9UIGRldmljZXMuDQo+IA0KPiANCj4gRXhhY3RseS4gTWF5 YmUgdGhpcyBpcyB3aGF0IFBldGVyIGlzIHBvaW50aW5nIGF0IHdoZW4gaGUgc2F5cyBzZXZlcmFs IHNvbHV0aW9ucw0KPiBjYW4gYmUgZGV2ZWxvcGVkLCBkaWZmZXJlbnQgZm9yIGVhY2ggZW52aXJv bm1lbnQuDQo+IA0KDQpbQV0NCkl0IGlzIGEgZ29vZCBpZGVhLCBhIGNvbnZlcnNhdGlvbiBpcyBk ZWZpbml0ZWx5IG5lZWRlZC4gSSB0aGluayBpdCB3b3VsZCBiZSBncmVhdCBpZiBhbiBhbmFseXNp cyBkcmFmdCBpcyBwcmVwYXJlZCwgYW5kIHdlIGNhbiBkaXNjdXNzIG1vcmUgZWZmaWNpZW50bHkg aW4gRGFsbGFzLiANCkFjY29yZGluZyB0byBvdXIgZGlzY3Vzc2lvbiwgdGhlIGRvY3VtZW50IHdp bGwgaW5jbHVkZSBzdXJ2ZXkgb2YgdGhlIHN0YXRlLW9mLXRoZS1hcnQgd29ya3MgYnkgSUVURiwg VGhyZWFkLCBaaWdCZWUsIElFRUUsIGV0Yy4sIGFuZCBpdCB3aWxsIGFsc28gYW5hbHl6ZSB0aGUg aW1wYWN0cyBvZiBkaWZmZXJlbnQgY2F0ZWdvcmllcyBvZiBlbnZpcm9ubWVudC4NCkkgYW0gd2ls bGluZyB0byBwcmVwYXJlIHRoZSBkcmFmdCwgYXJlIHlvdSBpbnRlcmVzdGVkIGluIGFkZGluZyB5 b3VyIHdvcmRzIGluIGl0Pw0KWy9BXQ0KDQpDaGVlcnMsDQpBbmENCg0KPiANCj4gPiBOZWVkbGVz cyB0byBzYXkgdGhhdCB0aGVyZSBhcmUgZGlmZmVyZW5jZXMgYW5kIHlvdSBjYW4gc2VlIHRoZW0g d2hlbg0KPiA+IHlvdSBsb29rIGF0IGhvdyBleGlzdGluZyBwcm9kdWN0cyB3b3JrLiBUaGF0IGRv ZXMsIGhvd2V2ZXIsIG5vdA0KPiA+IG5lY2Vzc2FyaWx5IG1lYW4gdGhhdCB0aGVyZSBhcmUgbm8g Y29tbW9uIGJ1aWxkaW5nIGJsb2Nrcy4NCj4gDQo+IEdvb2QgcG9pbnQuDQo+IA0KPiA+DQo+ID4g Q2lhbw0KPiA+IEhhbm5lcw0KPiA+DQo+ID4gT24gMDIvMjEvMjAxNSAxMjoxNCBQTSwgcGV0ZXIg dmFuIGRlciBTdG9rIHdyb3RlOg0KPiA+PiBIaSBCcmlhbiwNCj4gPj4NCj4gPj4gSnVzdCBhIHNt YWxsIGFubm90YXRpb24gdG8geW91ciBkZWZhdWx0IGFwcHJvYWNoIGNvbW1lbnQuDQo+ID4+IEJv b3RzdHJhcHBpbmcgaXMgc3ViamVjdCB0byBkaWZmZXJlbnQgaW5zdGFsbGF0aW9uIHByb2NlZHVy ZXMuDQo+ID4+IEEgY2xlYXIgZXhhbXBsZSBpcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGhvbWUg KHBsdWcgYW5kIHBsYXkpIGFuZA0KPiA+PiB0aGUgYnVpbGRpbmcgY29udHJvbCB3aGVyZSBib290 c3RyYXBwaW5nIGlzIG9yZ2FuaXplZCBmcm9tIGEgZGF0YWJhc2UuDQo+ID4+IEluIHRoZSBwcm9m ZXNzaW9uYWwgZG9tYWluIHRoZSBvcmRlciBvZiB0aGluZ3MgY2FuIGRlcGVuZCBvbiB0aGUNCj4g Pj4gaW5zdGFsbGVyLiBGb3IgZXhhbXBsZSwgc29tZSBtYXkgd2FudCB0byBib290c3RyYXAgdG9n ZXRoZXIgd2l0aCB0aGUNCj4gPj4gc2V0dXAgb2YgdGhlIG5ldHdvcmssIG90aGVycyBtYXkgd2Fu dCB0aGUgbmV0d29yayB0byBiZSByZWFkeSBhbmQNCj4gPj4gdGhlbiBkbyB0aGUgc2VjdXJpdHkg Ym9vdHN0cmFwLg0KPiA+Pg0KPiA+PiBBbHRob3VnaCBJIGFncmVlIHdpdGggeW91ciBjb25jZXJu IGV4cHJlc3NlZCBhcyAiYSBkZWZhdWx0IHByb2NlZHVyZQ0KPiA+PiB0byBkZWNpZGUgb24gdGhl IGJvb3RzdHJhcCBwcm9jZWR1cmUiLCBJIHRoaW5rIHRoZXJlIGlzIHJvb20gZm9yIDItNA0KPiA+ PiBkaWZmZXJlbnQgc2VjdXJpdHkgYm9vdHN0cmFwIHByb2NlZHVyZXMuDQo+ID4+IFRoZXNlIHBy b2NlZHVyZXMgd2lsbCBiZSBjaG9zZW4gYXMgZnVuY3Rpb24gb2YgdGhlIGFwcGxpY2F0aW9uIGRv bWFpbg0KPiA+PiBhbmQgYXBwbGljYXRpb24gb3duZXIsIGluc3RhbGxlci4NCj4gPj4NCj4gPj4g UGV0ZXINCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gQnJpYW4gRSBDYXJwZW50ZXIgc2NocmVlZiBv cCAyMDE1LTAyLTIwIDE5OjUxOg0KPiA+Pj4gSGFubmVzLA0KPiA+Pj4NCj4gPj4+IEkgYWdyZWUg dGhhdCB3ZSBuZWVkIHRvIGNvbXBhcmUgZGlmZmVyZW50IGFwcHJvYWNoZXMuIEkgZG8gaGF2ZSBv bmUNCj4gPj4+IGNvbmNlcm4gaW4gdGhlIGFuaW1hIGNvbnRleHQgdGhhdCBsZWFkcyBtZSB0byB0 aGUgY29uY2x1c2lvbiB0aGF0IHdlDQo+ID4+PiAqbXVzdCogcGljayBhIHByZWZlcnJlZCBzb2x1 dGlvbjogaWYgd2UgY29uc2lkZXIgYSBjb2xsZWN0aW9uIG9mDQo+ID4+PiBtdWx0aXZlbmRvciBl cXVpcG1lbnQgaW4gZmFjdG9yeSBjb25kaXRpb24gdGhhdCB3ZSB3YW50IHRvIGJvb3RzdHJhcA0K PiA+Pj4gaXRzZWxmIGludG8gYSBzZWN1cmUgbmV0d29yayB3aGVuIHdlIGFwcGx5IHBvd2VyLCBJ IGRvbid0IHNlZSBob3cgd2UNCj4gPj4+IGNhbiBhdm9pZCBoYXZpbmcgYSBzaW5nbGUgZGVmYXVs dCBzb2x1dGlvbi4gSWYgbm90LCB3ZSBnZXQgYSByYXRoZXINCj4gPj4+IGx1ZGljcm91cyBzaXR1 YXRpb24gd2hlcmUgd2UgbmVlZCBhIHNpbmdsZSBkZWZhdWx0IHNvbHV0aW9uIHRvIHRoZQ0KPiA+ Pj4gcHJvYmxlbSBvZiBjaG9vc2luZyB3aGljaCBib290c3RyYXAgc29sdXRpb24gdG8gdXNlLg0K PiA+Pj4NCj4gPj4+IFJlZ2FyZHMNCj4gPj4+ICAgIEJyaWFuDQo+ID4+Pg0KPiA+Pj4gT24gMjEv MDIvMjAxNSAwMToyNywgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+ID4+Pj4gSGkgRGFucGlu ZywNCj4gPj4+Pg0KPiA+Pj4+IEkgd291bGQgYWxzbyBsaWtlIHRvIG5vdGUgdGhhdA0KPiA+Pj4+ IFtJLUQucHJpdGlraW4tYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYV0gaXMgb25seSBvbmUg cG9zc2libGUNCj4gPj4+PiB3YXkgb2YgZGlzdHJpYnV0aW5nIG5ldyBrZXlzIChiYXNlZCBvbiBh bHJlYWR5IHByZS1wcm92aXNpb25lZA0KPiA+Pj4+IGNlcnRpZmljYXRlcykuIEkgd291bGQgbGlr ZSB0byB1bmRlcnN0YW5kIGhvdyBpdCByZWxhdGVzIHRvIG90aGVyDQo+IGFwcHJvYWNoZXMuDQo+ ID4+Pj4gUGFydGljdWxhcmx5IGlmIHlvdSBjb25zaWRlciBhbiBhcHByb2FjaCAiaGVhdnkiIGl0 IHdvdWxkIGJlIGdvb2QNCj4gPj4+PiB0byBrbm93IHdoYXQgeW91ciBtYWluIGNvbmNlcm5zIGFy ZSBzaW5jZSB0aGVyZSBpcyBubyBmcmVlIGx1bmNoDQo+ID4+Pj4gd2l0aCBzZWN1cml0eSBhbmQg bW9zdCBvZiB0aGUgZGVzaWduIGRlY2lzaW9ucyBhcmUgdHJhZGUtb2Zmcy4NCj4gPj4+Pg0KPiA+ Pj4+IENpYW8NCj4gPj4+PiBIYW5uZXMNCj4gPj4+Pg0KPiA+Pj4+IE9uIDAyLzIwLzIwMTUgMTI6 NTkgUE0sIFJvYmVydCBDcmFnaWUgd3JvdGU6DQo+ID4+Pj4+IFtJLUQucHJpdGlraW4tYW5pbWEt Ym9vdHN0cmFwcGluZy1rZXlpbmZyYV0gcHJvcG9zZXMgYSB6ZXJvLXRvdWNoDQo+ID4+Pj4+IGJv b3RzdHJhcHBpbmcga2V5IGluZnJhc3RydWN0dXJlIHRvIGFsbG93IGpvaW5pbmcgZGV2aWNlIHNl Y3VyZWx5DQo+ID4+Pj4+IGFuZCBhdXRvbWF0aWNhbGx5IGJvb3RzdHJhcHMgaXRzZWxmIGJhc2Vk IG9uIDgwMi4xQVIgY2VydGlmaWNhdGUuDQo+ID4+Pj4+IEl0IGNhbid0IGJlIGRpcmVjdGx5IHVz ZWQgaW4gODAyLjE1LjQgZGV2aWNlcyBkdWUgdG8gdGhlIGhpZ2gNCj4gPj4+Pj4gc2VjdXJpdHkg Y29tcGxleGl0eSBhbmQgaGVhdnkgY29tbXVuaWNhdGlvbiBvdmVyaGVhZC4iOiBJIGRpc2FncmVl DQo+ID4+Pj4+IHdpdGggdGhpcyBzdGF0ZW1lbnQuIFdlIHVzZWQgdGhpcyBhcHByb2FjaCBpbiBa aWdCZWUgSVAuIEkgYWdyZWUNCj4gPj4+Pj4gc29tZSBtYXkgdGhpbmsgdGhlIGNvbW11bmljYXRp b24gb3ZlcmhlYWQgImhlYXZ5IiBidXQgdGhhdCBkb2Vzbid0DQo+ID4+Pj4+IG1lYW4gaXQgY2Fu J3QgYmUgZG9uZS4NCj4gPj4+Pj4gVGhlIGFzc29jaWF0ZWQgc2VjdXJpdHkgY29tcGxleGl0eSBp cyBhbHNvIGJlY29taW5nIGxlc3Mgb25lcm91cw0KPiA+Pj4+PiBhcyBjcnlwdG8gYWNjZWxlcmF0 b3JzIGJlY29tZSBidWlsdCBpbnRvIGhhcmR3YXJlIGFuZCBjb3Jlcy4NCj4gPj4+Pg0KPiA+Pj4+ DQo+ID4+Pj4NCj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+Pj4+IEFuaW1hIG1haWxpbmcgbGlzdA0KPiA+Pj4+IEFuaW1hQGlldGYub3Jn DQo+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KPiA+ Pj4+DQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPj4+IEFuaW1hIG1haWxpbmcgbGlzdA0KPiA+Pj4gQW5pbWFAaWV0Zi5vcmcN Cj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCj4gPg0K PiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA2bG8gbWFpbGluZyBsaXN0DQo+ID4gNmxvQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG8NCj4gPg0K From nobody Thu Feb 26 01:25:09 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50C81A1AC6; Thu, 26 Feb 2015 01:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 YENS75McU-Xq; Thu, 26 Feb 2015 01:25:05 -0800 (PST) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBEE31A0367; Thu, 26 Feb 2015 01:25:04 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.200]) by smtp-cloud6.xs4all.net with ESMTP id wxR11p0054K0fSy01xR1oR; Thu, 26 Feb 2015 10:25:02 +0100 Received: from AMontpellier-654-1-214-175.w92-145.abo.wanadoo.fr ([92.145.225.175]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 26 Feb 2015 10:25:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 26 Feb 2015 10:25:01 +0100 From: peter van der Stok To: "Hedanping (Ana)" Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D92FB28@szxeml557-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <77FA386512F0D748BC7C02C36EB1106D92FB28@szxeml557-mbs.china.huawei.com> Message-ID: <81a99be98d7d457e509a9fd3e1e9a4aa@xs4all.nl> X-Sender: stokcons@xs4all.nl (2oTK8zM1CM+DfVc7fclmOrjllO6J2dXE) User-Agent: XS4ALL Webmail Archived-At: Cc: 6tisch-security <6tisch-security@ietf.org>, consultancy@vanderstok.org, Michael Richardson , robert.cragie@gridmerge.com, sarikaya@ieee.org, 6lo@ietf.org, Hannes Tschofenig , anima@ietf.org Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 09:25:07 -0000 Hi Ana, I would certainly be interested to contribute, Peter Hedanping (Ana) schreef op 2015-02-26 09:22: > Hi Hannes, Behcet and all, > >> > It would be great to have a conversation (maybe at the next IETF >> > meeting) how the different environments (home environment, enterprise >> > environments/industrial environments) are different in terms of >> > provisioning credentials and configuration information to IoT devices. >> >> >> Exactly. Maybe this is what Peter is pointing at when he says several >> solutions >> can be developed, different for each environment. >> > > [A] > It is a good idea, a conversation is definitely needed. I think it > would be great if an analysis draft is prepared, and we can discuss > more efficiently in Dallas. > According to our discussion, the document will include survey of the > state-of-the-art works by IETF, Thread, ZigBee, IEEE, etc., and it > will also analyze the impacts of different categories of environment. > I am willing to prepare the draft, are you interested in adding your > words in it? > [/A] > > Cheers, > Ana > >> >> > Needless to say that there are differences and you can see them when >> > you look at how existing products work. That does, however, not >> > necessarily mean that there are no common building blocks. >> >> Good point. >> >> > >> > Ciao >> > Hannes >> > >> > On 02/21/2015 12:14 PM, peter van der Stok wrote: >> >> Hi Brian, >> >> >> >> Just a small annotation to your default approach comment. >> >> Bootstrapping is subject to different installation procedures. >> >> A clear example is the difference between home (plug and play) and >> >> the building control where bootstrapping is organized from a database. >> >> In the professional domain the order of things can depend on the >> >> installer. For example, some may want to bootstrap together with the >> >> setup of the network, others may want the network to be ready and >> >> then do the security bootstrap. >> >> >> >> Although I agree with your concern expressed as "a default procedure >> >> to decide on the bootstrap procedure", I think there is room for 2-4 >> >> different security bootstrap procedures. >> >> These procedures will be chosen as function of the application domain >> >> and application owner, installer. >> >> >> >> Peter >> >> >> >> >> >> >> >> Brian E Carpenter schreef op 2015-02-20 19:51: >> >>> Hannes, >> >>> >> >>> I agree that we need to compare different approaches. I do have one >> >>> concern in the anima context that leads me to the conclusion that we >> >>> *must* pick a preferred solution: if we consider a collection of >> >>> multivendor equipment in factory condition that we want to bootstrap >> >>> itself into a secure network when we apply power, I don't see how we >> >>> can avoid having a single default solution. If not, we get a rather >> >>> ludicrous situation where we need a single default solution to the >> >>> problem of choosing which bootstrap solution to use. >> >>> >> >>> Regards >> >>> Brian >> >>> >> >>> On 21/02/2015 01:27, Hannes Tschofenig wrote: >> >>>> Hi Danping, >> >>>> >> >>>> I would also like to note that >> >>>> [I-D.pritikin-anima-bootstrapping-keyinfra] is only one possible >> >>>> way of distributing new keys (based on already pre-provisioned >> >>>> certificates). I would like to understand how it relates to other >> approaches. >> >>>> Particularly if you consider an approach "heavy" it would be good >> >>>> to know what your main concerns are since there is no free lunch >> >>>> with security and most of the design decisions are trade-offs. >> >>>> >> >>>> Ciao >> >>>> Hannes >> >>>> >> >>>> On 02/20/2015 12:59 PM, Robert Cragie wrote: >> >>>>> [I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch >> >>>>> bootstrapping key infrastructure to allow joining device securely >> >>>>> and automatically bootstraps itself based on 802.1AR certificate. >> >>>>> It can't be directly used in 802.15.4 devices due to the high >> >>>>> security complexity and heavy communication overhead.": I disagree >> >>>>> with this statement. We used this approach in ZigBee IP. I agree >> >>>>> some may think the communication overhead "heavy" but that doesn't >> >>>>> mean it can't be done. >> >>>>> The associated security complexity is also becoming less onerous >> >>>>> as crypto accelerators become built into hardware and cores. >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Anima mailing list >> >>>> Anima@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/anima >> >>>> >> >>> >> >>> _______________________________________________ >> >>> Anima mailing list >> >>> Anima@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/anima >> > >> > >> > _______________________________________________ >> > 6lo mailing list >> > 6lo@ietf.org >> > https://www.ietf.org/mailman/listinfo/6lo >> > From nobody Thu Feb 26 11:23:43 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578E71A1BE4; Thu, 26 Feb 2015 11:23:42 -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 iEl2mjFHCIkA; Thu, 26 Feb 2015 11:23:40 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E38A1A1BAA; Thu, 26 Feb 2015 11:23:40 -0800 (PST) Received: by pabli10 with SMTP id li10so223439pab.0; Thu, 26 Feb 2015 11:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=l4JaJZifVkWfRbGxCFCuRPjIDQXuHySi14XWq20xvZw=; b=b8TvVC6fXeN6rASY59jsq8oCP/60vV5F7VOXVAlgOTql7DXgPQyxt7S7ujjpDXrU2P IQWJlet/deYOTpmPI8yZl+Oy/t+MzlmGB9Q2l9eG7Hk5OUNjicpYxDVcJoocYEABxA11 dtjRWB/7VQnEesdKwr8Gamq3DjnuZQnCyusFPqgWvqq9trTVl+rfdMf7NntHouC6fjaz X0ezgfRhAWgDCQYCmHee+JaEiboYjJgxg8HSlJSwMDzjvwmUXH4cXdpoSf8S+MreFGWi AJtjypZ7dkKlREWuEbO72GzTQeqYOhsKYINpWL+afSAaYnbmrHXtKivzYb0OIQKqQxqG fETA== X-Received: by 10.70.136.164 with SMTP id qb4mr17447382pdb.145.1424978619739; Thu, 26 Feb 2015 11:23:39 -0800 (PST) Received: from ?IPv6:2406:e007:7acd:1:28cc:dc4c:9703:6781? ([2406:e007:7acd:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id wq9sm1684841pbc.85.2015.02.26.11.23.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Feb 2015 11:23:38 -0800 (PST) Message-ID: <54EF72BF.3070603@gmail.com> Date: Fri, 27 Feb 2015 08:23:43 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Hedanping (Ana)" , "robert.cragie@gridmerge.com" , Michael Richardson , Behcet Sarikaya References: <77FA386512F0D748BC7C02C36EB1106D92F855@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D92F887@szxeml557-mbs.china.huawei.com> <54EE1D2E.5040707@gmail.com> <77FA386512F0D748BC7C02C36EB1106D92FAEF@szxeml557-mbs.china.huawei.com> In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D92FAEF@szxeml557-mbs.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima@ietf.org" , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Anima] [6lo] Device vs network bootstrapping [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 19:23:42 -0000 Below... On 26/02/2015 19:18, Hedanping (Ana) wrote: > Hi Brian, > Please see my reply inline. > > > -----Original Message----- > > From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Brian E Carpenter > > Sent: Thursday, February 26, 2015 3:06 AM > > To: Hedanping (Ana); robert.cragie@gridmerge.com; Michael Richardson; > > Behcet Sarikaya > > Cc: 6tisch-security@ietf.org; anima@ietf.org; 6lo@ietf.org > > Subject: [6lo] Device vs network bootstrapping [Comments needed for Security > > Bootstrapping of IEEE 802.15.4 based Internet of Things] > > > > Hi, > > > > On 26/02/2015 03:48, Hedanping (Ana) wrote: > > ... > > > IMHO, there are distinctions between the network level bootstrapping > > > and joining device level bootstrapping. Network level bootstrapping > > > includes at least two cases: network start-up case and > > > re-commissioning case. The bootstrapping network level bootstrapping > > > request should be different from that of joining device level request > > > in order to converge efficiently. I agree that they need to be clarified. > > > > How does a device that has just been switched on know whether it is joining > > an existing network or is simply one of many devices that are attempting to > > form a new network? > > > The device can learn from its neighbors about the network state. For instance, from the bits indicating network ID and device type in hello/beaconing message, the device knows whether a neighbor belongs to an existing network or it is a 'new' device as well, and whether the neighbor has ability to forward/verify authentication message. > > > How does a set of devices that are attempting to form a new network know > > that they are re-commissioning a previously existing network? > > > Again, the state can be learnt by exchanging the network ID that devices belonged to > > > The only safe assumption seem to be that devices cannot know these things. > > Autonomic devices have no state at power-on. > > > The devices cannot know these things by themselves, but through collaboration it is possible. From this aspect, I do not object that autonomic devices have no state at power-on. OK. With my Anima hat on, I see a strong need for a solution that does not have any specific L2 technology dependence. What you describe here works for a specific technology with specific bits set in L2 packets. What we need is a generic solution that doesn't care about which L2 technology is involved, because we are trying to establish trust at a level above L3 routing. Brian From nobody Thu Feb 26 13:53:42 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497841A1A02; Thu, 26 Feb 2015 13:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 TZebw4CPZviv; Thu, 26 Feb 2015 13:53:36 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::724]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CEA01A07BE; Thu, 26 Feb 2015 13:53:36 -0800 (PST) Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB409.namprd05.prod.outlook.com (10.141.74.153) with Microsoft SMTP Server (TLS) id 15.1.99.14; Thu, 26 Feb 2015 21:53:18 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.93.16; Thu, 26 Feb 2015 21:53:16 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.145]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.145]) with mapi id 15.01.0093.004; Thu, 26 Feb 2015 21:53:16 +0000 From: Kent Watsen To: Brian E Carpenter , "Hedanping (Ana)" , "robert.cragie@gridmerge.com" , Michael Richardson , Behcet Sarikaya Thread-Topic: [Anima] [6lo] Device vs network bootstrapping [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] Thread-Index: AQHQUYwNy3Z2h13Nn0iISWx/0+0uKp0DUF+A///V9AA= Date: Thu, 26 Feb 2015 21:53:16 +0000 Message-ID: References: <77FA386512F0D748BC7C02C36EB1106D92F855@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D92F887@szxeml557-mbs.china.huawei.com> <54EE1D2E.5040707@gmail.com> <77FA386512F0D748BC7C02C36EB1106D92FAEF@szxeml557-mbs.china.huawei.com> <54EF72BF.3070603@gmail.com> In-Reply-To: <54EF72BF.3070603@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.13] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB409; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-forefront-prvs: 0499DAF22A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2501003)(66066001)(92566002)(46102003)(93886004)(36756003)(102836002)(122556002)(99286002)(87936001)(2656002)(86362001)(50986999)(76176999)(54356999)(106116001)(2900100001)(62966003)(40100003)(77156002)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <21E707C35C206F4CBB66A2DE5B6DAECB@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2015 21:53:16.1805 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 X-OriginatorOrg: juniper.net Archived-At: Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "anima@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Anima] [6lo] Device vs network bootstrapping [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 21:53:38 -0000 >OK. With my Anima hat on, I see a strong need for a solution that does >not have any specific L2 technology dependence. What you describe here >works for a specific technology with specific bits set in L2 packets. >What we need is a generic solution that doesn't care about which L2 >technology is involved, because we are trying to establish trust at >a level above L3 routing. Agreed. This is why the netconf-zerotouch drafts have emphasized devices downloading signed documents, so that it does not matter how the documents are obtained (usb flash drive vs network, ip vs. optical, v4 vs v6, etc.). That said, the big difference I see in the homenet/anima vs Enterprise/SP scenarios is a notion of the device having an "owner". The NETCONF ZeroTouch solution keys off tying a serial-number to an "owner" that has staged some config for the device to find, whereas homenet/anima are more about having someone in the local environment (e.g, the home) do something to associate trust between the instance and network. I believe that these are irreconcilable differences that will drive the solutions to difference ends. Kent =20 From nobody Thu Feb 26 14:41:56 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9841A8894; Thu, 26 Feb 2015 14:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 8xBhKq7O62ck; Thu, 26 Feb 2015 14:41:53 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B44D21A1A66; Thu, 26 Feb 2015 14:41:52 -0800 (PST) Received: by wevm14 with SMTP id m14so15432464wev.8; Thu, 26 Feb 2015 14:41:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=AbMktC7kyQOGAl0BZZnEYvt8n0vP7m4iletusodi8E0=; b=FAZTgWwOXPOwavmw01wfLJ0CabI6/O0Tqt3D6OKIyk/r8aLbCFc1892DYIHFcTnjFn 8maIZ5dgklHhAT8u82CC+hRqVp6AcwMWWLlWkOGdHG6Dtlf1925ZEzaZIofV30jKGEJB Jb02ynr6jbT8FE9zNgwx+oGRmjsF36H9bl4qWeMP3pcDCDk5RNfkPL4jAjgKiFl2jEhy cUSpqkcMwu6jV1DwwJEAQnpWWDusvyhm6KsRysDWnNEv3XxKfLAVpsqXE0K2Sao2p1Ls dExxfNpnCtSE/Gy1ysQCzuW5XAr9iFqi6pOA7BzlJZ/XCnYqIWjTQiF9oR6YbVuV6rEZ z41Q== X-Received: by 10.194.5.168 with SMTP id t8mr21771215wjt.150.1424990511495; Thu, 26 Feb 2015 14:41:51 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.194.82.39 with HTTP; Thu, 26 Feb 2015 14:41:31 -0800 (PST) In-Reply-To: <54EF5C27.1040400@cisco.com> References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <54EB4F24.7030609@gmx.net> <54EF5C27.1040400@cisco.com> From: Thomas Watteyne Date: Thu, 26 Feb 2015 23:41:31 +0100 X-Google-Sender-Auth: kzBvp7Y1jp8Y77iupS7cPeLtQO0 Message-ID: To: "Paul Duffy (paduffy)" Content-Type: multipart/alternative; boundary=047d7b5d44c63f000c05100575b2 Archived-At: Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "consultancy@vanderstok.org" , Michael Richardson , "Hedanping \(Ana\)" , "robert.cragie@gridmerge.com" , Hannes Tschofenig , "anima@ietf.org" Subject: Re: [Anima] [6tisch-security] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 22:41:54 -0000 --047d7b5d44c63f000c05100575b2 Content-Type: text/plain; charset=UTF-8 I'm definitely interested in having that discussion in Dallas. Thomas On Thu, Feb 26, 2015 at 6:47 PM, Paul Duffy wrote: > > > On 2/23/2015 11:02 AM, Hannes Tschofenig wrote: > >> At least draft-pritikin-anima-bootstrapping-keyinfra builds pn >>> IEEE 802.1AR. >>> >> To be honest, I am a bit doubtful about the value of the IEEE 802.1AR >> specification. >> >> >> > > "Cisco Connected Grid Security for Field Area Network" > > http://www.cisco.com/web/strategy/docs/energy/C11- > 696279-00_cgs_fan_white_paper.pdf > > Page 3 > > Cheers > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > --047d7b5d44c63f000c05100575b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm definitely interested in having that discussion in= Dallas.
Thomas

On Thu, Feb 26, 2015 at 6:47 PM, Paul Duffy <<= a href=3D"mailto:paduffy@cisco.com" target=3D"_blank">paduffy@cisco.com= > wrote:


On 2/23/2015 11:02 AM, Hannes Tschofenig wrote:
At least draft-pritikin-anima-bootstrapping-keyinfra builds pn
IEEE 802.1AR.
To be honest, I am a bit doubtful about the value of the IEEE 802.1AR
specification.




"Cisco Connected Grid Security for Field Area Network"

http://www.cisco.com/web/stra= tegy/docs/energy/C11-696279-00_cgs_fan_white_paper.pdf
Page 3

Cheers

_______________________________________________
 6tisch-security mailing list
6tisch-securi= ty@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch-security

--047d7b5d44c63f000c05100575b2-- From nobody Thu Feb 26 15:02:59 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3F21A8912; Thu, 26 Feb 2015 15:02:56 -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 5cQ9vmFa5v1L; Thu, 26 Feb 2015 15:02:54 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2081F1A8909; Thu, 26 Feb 2015 15:02:54 -0800 (PST) Received: by pdbfp1 with SMTP id fp1so16358667pdb.9; Thu, 26 Feb 2015 15:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qTdSyUHdY+u5xek4TIMhPiYeGgi8FS+eplRRQjwiiEk=; b=fkuIcFzM11jHHMmF2aKpxKze3wPZmjyW9bMBFPp2nRAKnihDzmcSbXfQ2OfOq5Q5Sd bdFS9C0bfo+mKBowrGqcigh/rsx4DIGRxoeYzaaCwZr+cNL5jwEZKDF8H3DwOASC7USx pfnFc10OB+BYLC1EgR1vcshA6lr57EPOW5JDo2ZxVipOvMSLadmHPef2OLgy+Lxyr0sJ immhtXYR7ZNOItELURMnPxXSMDJjyNsvwKirOXrokzrdpbj7PdyUuwDjq9nFZwpErBD5 G00y8/E5EU6a/SnFPrcTUm6bM+vTPPIwAiHYYSNCjDoFoodwDrFFpIZ1Ktqkdg1Oz7lU iv2Q== X-Received: by 10.70.126.167 with SMTP id mz7mr18551902pdb.109.1424991773249; Thu, 26 Feb 2015 15:02:53 -0800 (PST) Received: from ?IPv6:2406:e007:7acd:1:28cc:dc4c:9703:6781? ([2406:e007:7acd:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id pm12sm1956054pdb.75.2015.02.26.15.02.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Feb 2015 15:02:52 -0800 (PST) Message-ID: <54EFA620.4060303@gmail.com> Date: Fri, 27 Feb 2015 12:02:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kris Pister , "Hedanping (Ana)" , "robert.cragie@gridmerge.com" , Michael Richardson , Behcet Sarikaya References: <77FA386512F0D748BC7C02C36EB1106D92F855@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D92F887@szxeml557-mbs.china.huawei.com> <54EE1D2E.5040707@gmail.com> <77FA386512F0D748BC7C02C36EB1106D92FAEF@szxeml557-mbs.china.huawei.com> <54EF72BF.3070603@gmail.com> <54EF9EDF.2090508@berkeley.edu> In-Reply-To: <54EF9EDF.2090508@berkeley.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "anima@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Anima] [6tisch-security] [6lo] Device vs network bootstrapping [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 23:02:56 -0000 On 27/02/2015 11:31, Kris Pister wrote: > Brian - > >> What we need is a generic solution that doesn't care about which L2 >> technology is involved, because we are trying to establish trust at >> a level above L3 routing. > > This is a fine goal, and it may be exactly what 6lo or some other > group should be working on, but I think that it is out of scope for 6tisch. > What we need to do is figure out who to trust to configure a very specific > L2, with very specific constraints. If we can leverage other more general > work that's great, but the constraints of 4e/TSCH are likely to push > 6top-configuration trust in a different direction. That sounds absolutely reasonable, as long as the various WGs involved are aware of their own scope and the potential for overlaps. I think Anima has to ride over these various solutions (and be versatile, since in some scenarios we can expect pre-registration and in others we can't, to answer Kent's point). Brian > > ksjp > > On 2/26/2015 11:23 AM, Brian E Carpenter wrote: >> Below... >> >> On 26/02/2015 19:18, Hedanping (Ana) wrote: >>> Hi Brian, >>> Please see my reply inline. >>> >>> > -----Original Message----- >>> > From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Brian E Carpenter >>> > Sent: Thursday, February 26, 2015 3:06 AM >>> > To: Hedanping (Ana); robert.cragie@gridmerge.com; Michael Richardson; >>> > Behcet Sarikaya >>> > Cc: 6tisch-security@ietf.org; anima@ietf.org; 6lo@ietf.org >>> > Subject: [6lo] Device vs network bootstrapping [Comments needed for Security >>> > Bootstrapping of IEEE 802.15.4 based Internet of Things] >>> > >>> > Hi, >>> > >>> > On 26/02/2015 03:48, Hedanping (Ana) wrote: >>> > ... >>> > > IMHO, there are distinctions between the network level bootstrapping >>> > > and joining device level bootstrapping. Network level bootstrapping >>> > > includes at least two cases: network start-up case and >>> > > re-commissioning case. The bootstrapping network level bootstrapping >>> > > request should be different from that of joining device level request >>> > > in order to converge efficiently. I agree that they need to be clarified. >>> > >>> > How does a device that has just been switched on know whether it is joining >>> > an existing network or is simply one of many devices that are attempting to >>> > form a new network? >>> > >>> The device can learn from its neighbors about the network state. For instance, from the bits indicating network ID and device >>> type in hello/beaconing message, the device knows whether a neighbor belongs to an existing network or it is a 'new' device >>> as well, and whether the neighbor has ability to forward/verify authentication message. >>> >>> > How does a set of devices that are attempting to form a new network know >>> > that they are re-commissioning a previously existing network? >>> > >>> Again, the state can be learnt by exchanging the network ID that devices belonged to >>> >>> > The only safe assumption seem to be that devices cannot know these things. >>> > Autonomic devices have no state at power-on. >>> > >>> The devices cannot know these things by themselves, but through collaboration it is possible. From this aspect, I do not >>> object that autonomic devices have no state at power-on. >> OK. With my Anima hat on, I see a strong need for a solution that does >> not have any specific L2 technology dependence. What you describe here >> works for a specific technology with specific bits set in L2 packets. >> What we need is a generic solution that doesn't care about which L2 >> technology is involved, because we are trying to establish trust at >> a level above L3 routing. >> >> Brian >> >> _______________________________________________ >> 6tisch-security mailing list >> 6tisch-security@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch-security > >