From nobody Mon Feb 2 09:35:39 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: X-Mailman-Approved-At: Mon, 02 Feb 2015 09:35:38 -0800 Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "anima@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [6tisch-security] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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 Tue Feb 3 03:59:54 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: Cc: Michael Richardson , "anima@ietf.org" , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [6tisch-security] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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 08:04:40 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722B91A1A66 for <6tisch-security@ietfa.amsl.com>; Tue, 3 Feb 2015 08:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 i_Vl2_reK4ar for <6tisch-security@ietfa.amsl.com>; Tue, 3 Feb 2015 08:04:34 -0800 (PST) Received: from sjmda13.webex.com (sjmda13.webex.com [64.68.124.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16EFD1A0687 for <6tisch-security@ietf.org>; Tue, 3 Feb 2015 08:00:47 -0800 (PST) Received: from jva2tc114.webex.com (sjc02-wxp00-lbace03-core-vl120-np10-2.webex.com [64.68.121.246]) by sjmda13.webex.com (Postfix) with ESMTP id D4E65C00B9 for <6tisch-security@ietf.org>; Tue, 3 Feb 2015 16:00:46 +0000 (GMT) Received: from jva2tc114.webex.com (localhost [127.0.0.1]) by jva2tc114.webex.com (Postfix) with ESMTP id 83AEB15F54A for <6tisch-security@ietf.org>; Tue, 3 Feb 2015 16:00:46 +0000 (GMT) Date: Tue, 3 Feb 2015 16:00:46 +0000 (GMT) From: Michael Richardson To: 6tisch-security@ietf.org Message-ID: <13400416.12298.1422979246537.JavaMail.nobody@jva2tc114.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_12296_1095879397.1422979246536" X-Priority: 3 Importance: normal Archived-At: Subject: [6tisch-security] WebEx meeting rescheduled: 6tisch security X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mcr+nomcom@sandelman.ca List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 16:04:36 -0000 ------=_Part_12296_1095879397.1422979246536 Content-Type: multipart/Alternative; boundary="----=_Part_12297_1625268707.1422979246536" ------=_Part_12297_1625268707.1422979246536 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTWljaGFlbCBSaWNoYXJkc29uIGNoYW5nZWQgdGhlIHRpbWUgZm9yIHRoaXMgV2Vi RXggbWVldGluZy4KCgo2dGlzY2ggc2VjdXJpdHkKVHVlc2RheSwgRmVicnVhcnkgMywgMjAxNQo0 OjMwIHBtICB8ICBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUgKE5ldyBZb3JrLCBHTVQtMDU6MDApICB8 ICAxIGhyIDIwIG1pbnMKCgpKT0lOIFdFQkVYIE1FRVRJTkcKaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bTAxZWQxNWQ2MDIyMWVlNGFhZWFiZDIxNWQ4MDg2OWZhCk1lZXRp bmcgbnVtYmVyOiA2NDIgNTg1IDQ4OQpNZWV0aW5nIHBhc3N3b3JkOiBqb2luam9pbgoKDQpKT0lO IEJZIFBIT05FDQoxLTg3Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0Nh bmFkYSkgCjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkKQWNj ZXNzIGNvZGU6IDY0MiA1ODUgNDg5CgpUb2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IApo dHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZg0KDQoKQWRk IHRoaXMgbWVldGluZyB0byB5b3VyIGNhbGVuZGFyOgpodHRwczovL2lldGYud2ViZXguY29tL2ll dGYvai5waHA/TVRJRD1tMzQwZjVhZWFmZWVlNTc1OWE5NzNlNDBjMjdkZTk2MzANCg0KCkNhbid0 IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOgpodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvbWMKCgpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMg V2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVy aW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxl IGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRp Y2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0 byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3Ig ZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uCg== ------=_Part_12297_1625268707.1422979246536 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBNaWNo YWVsIFJpY2hhcmRzb24gY2hhbmdlZCB0aGUgdGltZSBmb3IgdGhpcyBXZWJFeCBtZWV0aW5nLgog ICAgICAgICAgICAgICAgCSAgICAgICAgICAgPC90ZD4KICAgICAgPC90cj4KPC90YWJsZT4KCgoK Cjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6 MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZSAgd2lkdGg9IjEwMCUi PgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0iZm9udC1zaXplOjE2cHg7IGNvbG9yOiM0 RDRENEQiPgoJCQkJCQkJCQk8Yj42dGlzY2ggc2VjdXJpdHk8L2I+CgkJCQkJCQkJPC90ZD4KCQkJ CQkJCTwvdHI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD5UdWVz ZGF5LCBGZWJydWFyeSAzLCAyMDE1CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8 dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD40OjMwIHBtJm5ic3A7Jm5ic3A7fCZu YnNwOyZuYnNwO0Vhc3Rlcm4gU3RhbmRhcmQgVGltZSAoTmV3IFlvcmssIEdNVC0wNTowMCkmbmJz cDsmbmJzcDt8Jm5ic3A7Jm5ic3A7MSBociAyMCBtaW5zCgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwv dHI+CgkJCQkJCTwvdGFibGU+Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsi Pjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8 dGFibGUgc3R5bGU9IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50Ij4KCQkJCQkJCTx0 cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImNvbG9yOiMwMEFGRjk7Zm9udC1zaXplOjE2cHgiPgoJCQkJ CQkJCQk8YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMDFl ZDE1ZDYwMjIxZWU0YWFlYWJkMjE1ZDgwODY5ZmEiCgkJCQkJCQkJCQlzdHlsZT0idGV4dC1kZWNv cmF0aW9uOm5vbmU7Zm9udC1zaXplOjE2cHg7Y29sb3I6IzAwQUZGOSI+CgkJCQkJCQkJCQk8Yj5K b2luIFdlYkV4IG1lZXRpbmc8L2I+CgkJCQkJCQkJCTwvYT4KCQkJCQkJCQk8L3RkPgoJCQkJCQkJ PC90cj4KCQkJCQkJPC90YWJsZT4KCQkJCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0 aDphdXRvIWltcG9ydGFudCI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJ CTx0ZCBzdHlsZT0icGFkZGluZy1yaWdodDogNXB4OyI+CgkJCQkJCQkJCU1lZXRpbmcgbnVtYmVy OgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQkJPHRkPjY0MiA1ODUgNDg5CgkJCQkJCQkJPC90ZD4KCQkJ CQkJCTwvdHI+CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJwYWRkaW5nLXJpZ2h0OiA1 cHg7Ij5NZWV0aW5nIHBhc3N3b3JkOjwvdGQ+CgkJCQkJCQkJPHRkPmpvaW5qb2luPC90ZD4KCQkJ CQkJCTwvdHI+CgkJCQkJCTwvdGFibGU+CgoKCgkKCgk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhl aWdodDoyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJs ZT48dGFibGU+PHRyPjx0ZCBzdHlsZT0iZm9udC1zaXplOjE2cHgiPjxiPkpvaW4gYnkgcGhvbmU8 L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPjxiPjEtODc3LTY2OC00NDkz PC9iPiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48 dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48Yj4xLTY1MC00NzktMzIwODwvYj4mbmJzcDtDYWxs LWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBw eCI+PHRkPkFjY2VzcyBjb2RlOiZuYnNwOzY0MiA1ODUgNDg5PC90ZD48L3RyPjx0ciBzdHlsZT0i bWFyZ2luOjBweCI+PHRkPjxhIGhyZWY9Imh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJl ZV9yZXN0cmljdGlvbnMucGRmIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXpl OjEzcHg7Y29sb3I6IzAwQUZGOTsiPlRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvYT48 L3RkPjwvdHI+PC90YWJsZT4KCgkJCQkJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBw eCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxl Pjx0cj48dGQgc3R5bGU9ImZvbnQtc2l6ZToxM3B4Ij48YSBocmVmPSJodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/TVRJRD1tMzQwZjVhZWFmZWVlNTc1OWE5NzNlNDBjMjdkZTk2MzAi IHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5OyBmb250LXNpemU6MTNw eCI+QWRkIHRoaXMgbWVldGluZzwvYT4gdG8geW91ciBjYWxlbmRhci48L3RkPjwvdHI+PC90YWJs ZT4KPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdo dDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlPgogICAgPHRyPgogICAgICAg PHRkIHN0eWxlPSJmb250LXNpemU6IDEzcHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiAjNjY2 NjY2OyI+CiAgICAgICAgQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8KICAgICAJPGEgaHJlZj0iaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7 Zm9udC1zaXplOjEzcHg7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzAwQUZGOTtmb250LWNvbG9y OiMwMEFGRjk7Ij4KICAgICAgICAJQ29udGFjdCBzdXBwb3J0LjwvYT4KCQk8L3RkPgogICAgPC90 cj4KPC90YWJsZT4KPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDEwcHg7Ij48dGQgc3R5 bGU9ImhlaWdodDoxMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlPgoJ CQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0iZm9udC1zaXplOjEycHg7Y29sb3I6ICNBMEEw QTA7Ij4KCQkJCQkJCQkJSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdl YkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmlu ZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBp biBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNh bGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8g YmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRv IG5vdCBqb2luIHRoZSBzZXNzaW9uLjwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoJ CQkJPC90ZD4KCQkJPC90cj4KCQk8L3RhYmxlPgoJPC90ZD4KICAgPC90cj4KPC90YWJsZT4KCjwv Ym9keT4= ------=_Part_12297_1625268707.1422979246536-- ------=_Part_12296_1095879397.1422979246536 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEzMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkNMQVNTOlBVQkxJQwpERVNDUklQVElPTjpc blxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW1iMWY1M2Q4ODk3MDYzZDQ5NWM5MjhjZDRjNDMzNmM3MVxuTWVldGluZyBudW1iZXI6 IDY0MiA1ODUgNDg5XG5NZWV0aW5nIHBhc3N3b3JkOiBqb2luam9pblxuXG5cbkpPSU4gQlkgUEhP TkVcbjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKSBc bjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcbkFjY2VzcyBj b2RlOiA2NDIgNTg1IDQ4OVxuXG5Ub2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IFxuaHR0 cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGZcblxuXG5cbkNh bid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOlxuaHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL21jXG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhh dCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBz ZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2Nv dmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBh dXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNv bnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBo b3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuClgtQUxULURFU0M7Rk1UVFlQRT10ZXh0 L2h0bWw6CTxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+IDxGT05UIFNJWkU9 IjQiIEZBQ0U9IkFSSUFMIj4JCTxhCQkJCQlocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2ll dGYvai5waHA/TVRJRD1tYjFmNTNkODg5NzA2M2Q0OTVjOTI4Y2Q0YzQzMzZjNzEiPjxGT05UIFNJ WkU9IjMiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlhbCI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9G T05UPjwvYT4JCQk8dGFibGU+CQkJCTx0cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyOjwvRk9OVD4JCQkJCTwv dGQ+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj42NDIgNTg1IDQ4OTwvRk9OVD4JCQkJCTwvdGQ+CQkJCTwvdHI+CQkJPC90YWJsZT4JCQk8 dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi Pk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBDT0xPUj0i IzY2NjY2NiIgRkFDRT0iYXJpYWwiPmpvaW5qb2luPC9GT05UPjwvdGQ+PC90cj48L3RhYmxlPgkJ PC9GT05UPjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwv Rk9OVD48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQg U0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48c3Ryb25nPjEtODc3LTY2OC00 NDkzPC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpPC9G T05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij48c3Ryb25nPjEtNjUwLTQ3OS0zMjA4PC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51bWJl ciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+QWNjZXNzIGNvZGU6IDY0MiA1ODUgNDg5PC9GT05UPiZuYnNwOyA8 QlI+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9u cy5wZGYiPjxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+VG9sbC1m cmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9GT05UPjwvYT4gJm5ic3A7IDxCUj48L0ZPTlQ+PEJS PjxCUj4JJm5ic3A7PEJSPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPgkJCQlDYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD4JPGEgaHJlZj0iaHR0cHM6Ly9p ZXRmLndlYmV4LmNvbS9pZXRmL21jIj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZB Q0U9IkFyaWFsIj5Db250YWN0IHN1cHBvcnQuPC9GT05UPjwvYT4JJm5ic3A7PEJSPiZuYnNwOzxC Uj48Rk9OVCBDT0xPUj0iI0EwQTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJpYWwiPklNUE9SVEFOVCBO T1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBh bmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3Jk ZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5p bmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3Jk aW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlv dXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48L0ZP TlQ+PC9GT05UPgpBVFRFTkRFRTtDTj0iTWljaGFlbCBSaWNoYXJkc29uIjtST0xFPVJFUS1QQVJU SUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm1jcitub21jb21Ac2FuZGVsbWFuLmNhCkRUU1RBTVA6 MjAxNTAyMDNUMjEzMDAwWgpVSUQ6V0VCRVgtTUVFVElORyBDRU5URVItNi4wNDU2NjgwLTMxMjA3 MzU1Ny1TVT1pZXRmClBSSU9SSVRZOjUKUkVDVVJSRU5DRS1JRDtUWklEPSJFYXN0ZXJuIFRpbWUi OjIwMTUwMjAzVDA5MDAwMApEVFNUQVJUO1RaSUQ9IkVhc3Rlcm4gVGltZSI6MjAxNTAyMDNUMTYz MDAwCkRURU5EO1RaSUQ9IkVhc3Rlcm4gVGltZSI6MjAxNTAyMDNUMTc1MDAwClNFUVVFTkNFOjE0 MjI5NzkyNDYKU1VNTUFSWTo2dGlzY2ggc2VjdXJpdHkKVFJBTlNQOk9QQVFVRQpPUkdBTklaRVI7 Q049Ik1pY2hhZWwgUmljaGFyZHNvbiI6TUFJTFRPOm1jcitub21jb21Ac2FuZGVsbWFuLmNhCkxP Q0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0ZgpCRUdJTjpWQUxBUk0KVFJJR0dFUjot UFQxNU0KQUNUSU9OOkRJU1BMQVkKREVTQ1JJUFRJT046UmVtaW5kZXIKRU5EOlZBTEFSTQpFTkQ6 VkVWRU5UCkVORDpWQ0FMRU5EQVIK ------=_Part_12296_1095879397.1422979246536-- From nobody Tue Feb 3 14:13:44 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338B41A8992 for <6tisch-security@ietfa.amsl.com>; Tue, 3 Feb 2015 14:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 jKQrEn1feFQJ for <6tisch-security@ietfa.amsl.com>; Tue, 3 Feb 2015 14:13:39 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 CD79D1A89FE for <6tisch-security@ietf.org>; Tue, 3 Feb 2015 14:13:37 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id hl2so30404850igb.3 for <6tisch-security@ietf.org>; Tue, 03 Feb 2015 14:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=56LRMfxyaF2MlXNVhRcbil8KTnas+2/xU8rWWKP1VtA=; b=EaOqpQUEqUdEisJJ61Met/mIxtvvae09YJPAgPKOtkiNYbFub1bcnFwOBGtn8dABpw WrPyrEZlQM73TecT3fL+BrKFl3pWzRd4Yp5W4Z21jWgb0mDoq4wnLJhRYgw87CjZeRnk zWAxZfFLj6IcZP6goksBgDAw/ulY2atGWV4KqvTRMQcxlQLubdcqGlCq6dnjCLBCAPY9 nANPl5NbY8z45kLiNtTjURknFrqHjqiYQpxgteK2PcYs1yn5sKQ/dyxNleQusKBhuiax 9YCJGOkmTZgtAQPf4Wc9W5TMpiLgvZwER1gqLIKq8TttedXgAZAAlFYq0jABW4o3dBH9 MG1w== X-Received: by 10.50.66.131 with SMTP id f3mr20645440igt.17.1423001616945; Tue, 03 Feb 2015 14:13:36 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id f1sm143583igt.14.2015.02.03.14.13.36 for <6tisch-security@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Feb 2015 14:13:36 -0800 (PST) Message-ID: <54D1480C.2070400@gmail.com> Date: Tue, 03 Feb 2015 17:13:32 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: tisch-security <6tisch-security@ietf.org> Content-Type: multipart/alternative; boundary="------------030107060009020105040402" Archived-At: Subject: [6tisch-security] reminder - 6tisch security conf call not this week, but next week, Tue Feb 10, 2105, 4.30pm EST X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 22:13:41 -0000 This is a multi-part message in MIME format. --------------030107060009020105040402 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear colleagues: During the 6TiSCH security conf call last week (Jan 27, 2015), we decided to skip this week's call and and reconvene next week. I noted this in the minutes (cf. below); apologies if this was unclear. _Next call will take place Tue Feb 10, 2015, 4.30pm EST._ Best regards, Rene -- http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00417.html 5. AOB RS suggested to cancel the 6tisch security call of next week and reconvene two weeks from now, which was agreed upon. _Next call will take place Tue Feb 10, 2015, 4.30pm EST._ -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------030107060009020105040402 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear colleagues:

During the 6TiSCH security conf call last week (Jan 27, 2015), we decided to skip this week's call and and reconvene next week. I noted this in the minutes (cf. below); apologies if this was unclear.

Next call will take place Tue Feb 10, 2015, 4.30pm EST.

Best regards,

Rene

--

http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00417.html
5. AOB
RS suggested to cancel the 6tisch security call of next week and reconvene two weeks from now, which was agreed upon. Next call will take place Tue Feb 10, 2015, 4.30pm EST. 
-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------030107060009020105040402-- From nobody Fri Feb 6 02:19:40 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783051A1B23; Fri, 6 Feb 2015 02:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, 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 jzRw8iTxaH3c; Fri, 6 Feb 2015 02:19:25 -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 7A9561A1B1D; Fri, 6 Feb 2015 02:19:25 -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 t16AIesv003806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Feb 2015 12:18:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t16AIaKG009946; Fri, 6 Feb 2015 12:18:36 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21716.38140.675311.694062@fireball.kivinen.iki.fi> Date: Fri, 6 Feb 2015 12:18:36 +0200 From: Tero Kivinen To: sarikaya@ieee.org In-Reply-To: References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <21712.47075.522836.495543@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 3 min Archived-At: Cc: "Hedanping \(Ana\)" , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [6tisch-security] [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 10:19:26 -0000 Behcet Sarikaya writes: > > 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. > > Did you consider 802.1X which does similar things? Yes, but 802.1X is not enough on its own. It only provides authentication, not key management. We currently have two 802.1X versions, i.e. 802.1X/MKA and 802.1X/KEY, but there is going to be some rewriting happening on those sections. In addition to those we have IKEv2, HIP, PANA and Dragonfly. -- kivinen@iki.fi From nobody Fri Feb 6 05:17:04 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E2B1A702C; Thu, 5 Feb 2015 12:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.75 X-Spam-Level: X-Spam-Status: No, score=-3.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, GB_I_LETTER=-2, 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 S9ivanC6C0JN; Thu, 5 Feb 2015 12:29:04 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::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 39C381A8AA8; Thu, 5 Feb 2015 12:29:04 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id w7so11350606lbi.1; Thu, 05 Feb 2015 12:29:02 -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=6X6AJDLSG15fJN6bmkHeTgbDy1SUUQqkTr4SybZ1xNQ=; b=KnEwbjc5vuVsRs3jqnMIBaYV+mSA1HGxj+Nx4X9GruEPFwyFRlK+Wr6LFCTZde5y2Y WL8K/L7EigGPP9sn0G8QmDNrbXvXzmQZAcFDLnD5XRdSWyErHT9DiqpmUaLph5w1JoBB NWjRHeUOhNTWlMKF8h5Zpx7vlAtmF5MheR9BGM2RFaTdnXgUVUwmSPf6HPt6DrE26JHZ zqRKFzgFRrsOsrzDuEbnj5XZaUXCQj4GqgA8cMjaR7dDzP4MoDVasLcXUqXCQdhUVh/Q sSHmmws10zCPE+dsb9BINhQBlTMNLvWIkGICZfs8ES98siNpTsn6U/9hakdahy3dzdP9 OnYA== MIME-Version: 1.0 X-Received: by 10.152.3.70 with SMTP id a6mr5862505laa.71.1423168142656; Thu, 05 Feb 2015 12:29:02 -0800 (PST) Received: by 10.114.3.130 with HTTP; Thu, 5 Feb 2015 12:29:02 -0800 (PST) In-Reply-To: <21712.47075.522836.495543@fireball.kivinen.iki.fi> References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <21712.47075.522836.495543@fireball.kivinen.iki.fi> Date: Thu, 5 Feb 2015 14:29:02 -0600 Message-ID: From: Behcet Sarikaya To: Tero Kivinen Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Fri, 06 Feb 2015 05:17:00 -0800 Cc: "Hedanping \(Ana\)" , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [6tisch-security] [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 20:29:09 -0000 Hi Tero, On Tue, Feb 3, 2015 at 5:58 AM, Tero Kivinen wrote: > 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. > Did you consider 802.1X which does similar things? > 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. Good to know. Regards, Behcet > -- > kivinen@iki.fi > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Feb 9 20:50:31 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28B51A8A7D for <6tisch-security@ietfa.amsl.com>; Mon, 9 Feb 2015 20:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_PORT=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 VpeCnCYssQyO for <6tisch-security@ietfa.amsl.com>; Mon, 9 Feb 2015 20:50:22 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (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 31E8A1A8714 for <6tisch-security@ietf.org>; Mon, 9 Feb 2015 20:50:22 -0800 (PST) Received: by iecat20 with SMTP id at20so13613326iec.12 for <6tisch-security@ietf.org>; Mon, 09 Feb 2015 20:50:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=IcT4tIMj/RJcDkEzAfTol1kcJqBGAPfwBFkE7Ts6PVA=; b=rnGy+9xzKMA1QUJDc1i0aH/nFFz0mLsBdZTaQzAUmm6zDz2XW7Lj+BSMZRvOUQ9mMA 55wv9h2oAQ/elYschN8sivrJ8beDm9Lod3yL3RlPdVJMdLowU5FCyONBJ9RCk9QDYzmN EdLLQM9JFo9P0u5BsE8/bfA/vbm5De4DDnnN3gasU8fL1LRtlj7u6Bg4q3J/utjVQN6f MqdSvqrJFpGBaD3Qs81xJnmMk1RhlVMpPwOisOZHDdc2jaVd9uhLIvhPv9vd6jrLSItd hFfXA8h4+yMbDaktqvJMXAI8lnCJs1yRv2mss8xVK9yO57ah1JU4HGXDdEqmej93fGt3 FT9Q== X-Received: by 10.107.3.159 with SMTP id e31mr30894545ioi.65.1423543821610; Mon, 09 Feb 2015 20:50:21 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id j6sm7112340igv.4.2015.02.09.20.50.20 for <6tisch-security@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Feb 2015 20:50:20 -0800 (PST) Message-ID: <54D98E01.4090103@gmail.com> Date: Mon, 09 Feb 2015 23:50:09 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: tisch-security <6tisch-security@ietf.org> References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> In-Reply-To: <54C8FD34.5040307@gmail.com> Content-Type: multipart/alternative; boundary="------------060705000307020900040904" Archived-At: Subject: [6tisch-security] Reminder -- 6tisch security call *tomorrow*, Tue Feb 10, 2015, 4.30pm EST (includes dial-in info) X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 04:50:29 -0000 This is a multi-part message in MIME format. --------------060705000307020900040904 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear colleagues: Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue February 10, 2015, 4.30pm EST. I have not seen any email traffic the last two weeks, nor any more feedback on the draft document I posted on Fri January 9th. I put as tentative item on the agenda "time latency aspects" of the join protocol. I will send out a more definitive agenda tomorrow around noon EST. Please send agenda request to me prior to that time. Suggested agenda: 1) administrativia {agenda bashing/minutes} 2) time latency aspects 3) AOB On 1/28/2015 10:16 AM, Rene Struik wrote: > Dear colleagues: > > Please find below the minutes of the 6TiSCH Security conf call as of > January 27, 2015, 9-10am EST. > > Minutes 6TiSCH Security conf call, Wed January 27, 2015, 9-10am EST > {note taker: Rene Struik} > {recording: not available (Michael Richardson had control, but was not > on the call} > {discussion material (referenced in minutes): this time, no posted > collatoral} > > 1. Attendance: > Tero Kivinen, Yoshi Ohba, Rene Struik > > 2. Agenda > The suggested updated agenda was approved. > Suggested agenda: > 1) administrativia {agenda bashing/minutes} > 2) prep for IETF-92 in Dallas > 3) AOB > > 3. Minutes > The minutes of the previous 6TiSCH security conference call (Thu > January 22, 2015) were approved. > > 4. Prep for IETF-92 in Dallas {more of a 6tisch security various > "varia" discussion really} > YO asked what happened with the output of the join process overview > text discussed during last week's call. RS mentioned that Pascal > Thubert included this in the 6tisch architecture draft (Section 13 - > Security Considerations) and would issue > draft-ietf-6tisch-architecture-05 for WGLC some time this week. > > RS mentioned that at the IETF-92 meeting in Dallas in March, the > 6tisch group would presumably recharter and include more > security-related milestones into the revised charter. He thought it > would be useful to have a 6tisch security draft by that meeting that > could serve as baseline. > > TK provided some more insight into the 802.15.4rev effort. He > suggested that there would be 1-2 more letter ballots, followed by the > start of sponsor ballot around end of March 2015, with anticipated > conclusion of the work around July-August this year. RS commented that > this schedule seemed quite aggressive, considering historical > timelines of IEEE 802.15 efforts. TK mentioned that according to Bob > Heile (Chair IEEE 802.15) the 802.15rev draft would only be available > in the 802.15 private member area or to those people participating in > person in an actual IEEE 802 meeting. Therefore, it does not seem > possible to make a draft available to interested parties in the 6tisch > community who did not meet those criteria (as previously suggested). > > 5. AOB > RS suggested to cancel the 6tisch security call of next week and > reconvene two weeks from now, which was agreed upon. _Next call will > take place Tue Feb 10, 2015, 4.30pm EST._ > > RS mentioned he had received feedback from Kris Pister and Yoshi Ohba > on draft-struik-6tisch-security-architectural-considerations-01 > (posted January 9, 2015). Before updating the draft, he would like to > see more people give this a look. He invited people to use the now > cancelled slot of next week's call to review this draft... > > [call ended @9.23am EST] > > > On 1/26/2015 12:15 PM, Rene Struik wrote: >> Dear colleagues: >> >> Just a quick reminder that we have a 6TiSCH security conf call >> tomorrow, Tue January 27, 2015, 9am EST. I expect this to be a short >> call. >> >> Suggested agenda: >> 1) administrativia {agenda bashing/minutes} >> 2) prep for IETF-92 in Dallas >> 3) AOB >> >> The dial-in info is below. >> >> Best regards, Rene >> >> _B) Dial-in information:_ >> English : New York Time 6tisch security >> Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00) >> Meeting number: 641 709 118 >> Meeting password: joinjoin >> Audio connection: >> 1-877-668-4493 Call-in toll free number (US/Canada) >> 1-650-479-3208 Call-in toll number (US/Canada) >> >> Access code: 641 709 118 >> Meeting link: >> https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6 >> >> The etherpad we have used is at: >> http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt >> >> >> >> >> On 1/21/2015 10:30 AM, Rene Struik wrote: >>> Dear colleagues: >>> >>> Giuseppe Piro offered to give a presentation on MAC security >>> aspects, resulting in the updated agenda below. Dial-in info at >>> bottom of email. >>> >>> Remember: 6tisch security call is now tomorrow, Thu Jan 21, 2015, >>> 1pm EST, with duration not to exceed one hour. Please call-in on >>> time and test your speaker/mike beforehand. >>> >>> Suggested updated agenda: >>> 1) administrativia {agenda bashing/minutes} [4 min] >>> 2) 6tisch security conf call schedule moving forward [1 min] >>> 3) input 6tisch security to architecture draft [15 min] >>> -- RS to present result homework assignment of last call >>> 4) presentation Giuseppe Piro re MAC security [30 min] >>> 5) prep for IETF-92 in Dallas [10 min] >>> 5) AOB >>> >>> Link to suggested text (item #3 above): >>> https://drive.google.com/file/d/0B2a6Ilxu1XfCbVhfd0ZONXoxc00/view?usp=sharing >>> >>> On 1/20/2015 4:54 PM, Rene Struik wrote: >>>> Dear colleagues: >>>> >>>> Due to connectivity problems, those on the 6tisch security call >>>> today concluded that it was best to reschedule the call. >>>> >>>> The rescheduled 6tisch security call will take place this Thursday, >>>> January 22, 2015, 1-2pm EST. >>>> (Please note that this is only once; schedule moving forward will >>>> otherwise remain the same) >>>> >>>> Agenda and dial-in info remain the same (please scroll down). >>>> >>>> Best regards, Rene >>>> >>>> >>>> On 1/20/2015 4:35 PM, Rene Struik wrote: >>>>> I posted the document on Google drive, see weblink below. >>>>> >>>>> https://drive.google.com/file/d/0B2a6Ilxu1XfCa3RyZzlZb3RRREk/view?usp=sharing >>>>> >>>>> On 1/20/2015 1:13 AM, Rene Struik wrote: >>>>>> Dear colleagues: >>>>>> >>>>>> Please find attached my analysis of the three text proposals. I >>>>>> hope this helps in zooming in on consensus text. >>>>>> >>>>>> I will present this in more detail as item #3 on the agenda for >>>>>> the 6tisch security call of tomorrow, Tue Jan 20, 2015, 4.30pm EST. >>>>>> >>>>>> We can discuss this in more detail during that call (I won't have >>>>>> much time beforehand). >>>>>> >>>>>> Best regards, Rene >>>>>> >>>>>> [excerpt of minutes of 6tisch security conf call as of January >>>>>> 14, 2015, 11am-12pm EST] >>>>>> TW asked whether RS could review the three text proposals >>>>>> currently on the table and suggest a way forward that takes into >>>>>> account consensus and what was discussed during the call. RS >>>>>> agreed to take this on as homework assignment, with target to >>>>>> report back on this to the group by the end of Monday next week >>>>>> (January 19, 2015). >>>>>> >>>>>> On 1/19/2015 2:20 PM, Rene Struik wrote: >>>>>>> Dear colleagues: >>>>>>> >>>>>>> Just a quick reminder that we have a 6TiSCH security conf call >>>>>>> tomorrow, Tue January 20, 2015, 4.30-5.30pm EST. >>>>>>> >>>>>>> Suggested agenda: >>>>>>> 1) administrativia {agenda bashing/minutes} >>>>>>> 2) 6tisch security conf call schedule moving forward >>>>>>> 3) input 6tisch security to architecture draft >>>>>>> -- RS to present result homework assignment of last call >>>>>>> 4) prep for IETF-92 in Dallas >>>>>>> 5) AOB >>>>>>> >>>>>>> For dial-in info, please see bottom of this email. >>>>>>> >>>>>>> As to item #2 above, if you wish to weigh-in, please do respond >>>>>>> to the Doodle poll by end of *today*, see >>>>>>> https://doodle.com/q63844gqd59urrae. >>>>>>> >>>>>>> Best regards, Rene >>>>>>> >>>>>>> -------- Forwarded Message -------- >>>>>>> Subject: reminder -- 6tisch security call *tomorrow*, Wed Jan >>>>>>> 14, 2015, 11am EST (dial-in info at bottom) >>>>>>> Date: Tue, 13 Jan 2015 19:37:04 -0500 >>>>>>> From: Rene Struik >>>>>>> To: tisch-security <6tisch-security@ietf.org> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Dear colleagues: >>>>>>> >>>>>>> Just a quick reminder that we *do* have a conf call tomorrow, >>>>>>> Wed Jan 14, 2015, 11am EST. >>>>>>> >>>>>>> Currently, the main agenda item is item #4b of last week: input >>>>>>> to the 6tisch architecture draft. It would also be good to have >>>>>>> some more comments on the draft I posted. >>>>>>> >>>>>>> Minutes of calls later tonight (sorry - extremely busy). For >>>>>>> conf call dial-in info, see bottom of email. >>>>>>> >>>>>>> Best regards, Rene >>>>>>> >>>>>>> == >>>>>>> Note: next week's call is on Wed Jan 14, 2015, 11am EST. >>>>>>> >>>>>>> On 1/6/2015 11:48 AM, Rene Struik wrote: >>>>>>>> Dear colleagues: >>>>>>>> >>>>>>>> Happy New Year! >>>>>>>> >>>>>>>> According to the agreed-upon 6tisch security conf call >>>>>>>> schedule, we will resume the conference call series today, Tue >>>>>>>> Jan 6, 2015, 5pm EST. >>>>>>>> >>>>>>>> I propose we continue the discussion where we left off prior to >>>>>>>> Christmas (essentially, item 3c below), except that we may have >>>>>>>> a short presentation first (item #2). >>>>>>>> >>>>>>>> Agenda: >>>>>>>> 1) administrativia {agenda bashing/minutes} >>>>>>>> 2) {still to be confirmed} presentation Giuseppe Piro >>>>>>>> 3) join protocol details >>>>>>>> -- a) (done) status update MAC behavior >>>>>>>> -- b) (brief!) recap of routing/communication flow aspects >>>>>>>> -- c) incremental deployment aspects >>>>>>>> 4) input 6tisch security to other 6tisch documents >>>>>>>> -- a) terminology draft >>>>>>>> -- b) architecture draft >>>>>>>> >>>>>>>> Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris >>>>>>>> time. {The next call, on January 6, 2014) is also at 5pm EST >>>>>>>> (see schedule till half of January 2015)}. >>>>>>>> Note: next week's call is on Wed Jan 14, 2015, 11am EST. >>>>>>>> >>>>>>>> Dial-in info at end of this email. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Rene >>>>>>>> >>>>>>>> -------- Forwarded Message -------- >>>>>>>> Subject: Suggested agenda for 6tisch security call of *today*, >>>>>>>> Tue December 16, 2014, 5pm EST (dial-in info at bottom) >>>>>>>> Date: Tue, 16 Dec 2014 09:21:20 -0500 >>>>>>>> From: Rene Struik >>>>>>>> To: tisch-security <6tisch-security@ietf.org> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Dear colleagues: >>>>>>>> >>>>>>>> I propose we continue the discussion where we left off last week. >>>>>>>> >>>>>>>> Agenda: >>>>>>>> 1) administrativia {agenda bashing/minutes} >>>>>>>> 2) join protocol details >>>>>>>> -- a) (brief!) status update MAC behavior >>>>>>>> -- b) continuation of routing/communication flow aspects {last >>>>>>>> week, we did not finish the only two slides on this >>>>>>>> 3) input 6tisch security to other 6tisch documents >>>>>>>> >>>>>>>> Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris >>>>>>>> time. {The next call, on January 6, 2014) is also at 5pm EST >>>>>>>> (see schedule till half of January 2015)}. >>>>>>>> >>>>>>>> Dial-in info at end of this email. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Rene >>>>>>>> >>>>>>>> -------- Forwarded Message -------- >>>>>>>> Subject: suggested agenda for 6tisch security call of >>>>>>>> tomorrow, Tue December 9, 2014, 9am EST (dial-in info at bottom) >>>>>>>> Date: Mon, 08 Dec 2014 17:16:40 -0500 >>>>>>>> From: Rene Struik >>>>>>>> To: tisch-security <6tisch-security@ietf.org> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Dear colleagues: >>>>>>>> >>>>>>>> For last week's Tue Dec 2, 2014, 9am EST conf call I prepared >>>>>>>> some material and posted prior to the call. During the call, we >>>>>>>> discussed all MAC-related aspects relevant for the join >>>>>>>> protocol and did not discuss higher-layer aspects I prepared >>>>>>>> material for yet. I suggest we continue the systematic >>>>>>>> discussion of last week and take that topic on now. >>>>>>>> >>>>>>>> This leads to the following suggested agenda for this week >>>>>>>> (essentially a continuation of last week's one): >>>>>>>> >>>>>>>> Same as last week's, except with >>>>>>>> #1a-b) focus on routing/communication flow related aspects join >>>>>>>> protocol; >>>>>>>> #2a): confirm concensus on MAC (as discussed last week) and >>>>>>>> routing/communication flow aspects >>>>>>>> #2c) {as consequence of two items above} what to squeeze into >>>>>>>> architecture draft >>>>>>>> >>>>>>>> The detailed agenda and dial-in info is below (#A, resp. #B). >>>>>>>> >>>>>>>> Best regards, Rene >>>>>>>> >>>>>>>> _A) Suggested agenda Tue Dec 9, 2014, 9am EST call_ >>>>>>>> >>>>>>>> Proposed agenda: >>>>>>>> >>>>>>>> 0) Agenda bashing >>>>>>>> >>>>>>>> 1) Join protocol details >>>>>>>> >>>>>>>> a) desired properties >>>>>>>> b) realizable properties >>>>>>>> >>>>>>>> #1a-b) focus on routing/communication flow related aspects >>>>>>>> join protocol (we discussed MAC-related join-relevant >>>>>>>> aspects during the conf call of Tue Dec 2, 2014, 9am EST). >>>>>>>> For slides, see >>>>>>>> https://drive.google.com/folderview?id=0B2a6Ilxu1XfCNF9JaXR1ZXlzZlU&usp=sharing >>>>>>>> (same slides as sent out prior to Dec 2, 2014, 9am EST call) >>>>>>>> Relevant slides: Slides 23-25 (contained in entire slide >>>>>>>> deck (ppt), but also in excerpt (pdf)) >>>>>>>> >>>>>>>> 2) Next steps: >>>>>>>> a) consensus on 1#a and 1#b >>>>>>>> >>>>>>>> #2a): confirm consensus on MAC (as discussed last week) and >>>>>>>> routing/communication flow aspects >>>>>>>> #2c) {as consequence of two items above} what to squeeze >>>>>>>> into architecture draft >>>>>>>> >>>>>>>> b) form tiger team to work out details >>>>>>>> - project phases >>>>>>>> - communication of sub-results >>>>>>>> c) what to squeeze into architecture draft, etc. >>>>>>>> >>>>>>>> I will prepare material to facilitate discussion on 1) and 2), >>>>>>>> to be discussed during the call. >>>>>>>> >>>>>>>> _B) Dial-in information:_ >>>>>>>> English : New York Time 6tisch security >>>>>>>> Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00) >>>>>>>> Meeting number: 641 709 118 >>>>>>>> Meeting password: joinjoin >>>>>>>> Audio connection: >>>>>>>> 1-877-668-4493 Call-in toll free number (US/Canada) >>>>>>>> 1-650-479-3208 Call-in toll number (US/Canada) >>>>>>>> >>>>>>>> Access code: 641 709 118 >>>>>>>> Meeting link: >>>>>>>> https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6 >>>>>>>> >>>>>>>> The etherpad we have used is at: >>>>>>>> http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>>> >>>>> >>>>> -- >>>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>> >>>> >>>> -- >>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>> >>> >>> -- >>> email:rstruik.ext@gmail.com | Skype: rstruik >>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >> >> >> -- >> email:rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > -- > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------060705000307020900040904 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue February 10, 2015, 4.30pm EST.

I have not seen any email traffic the last two weeks, nor any more feedback on the draft document I posted on Fri January 9th.

I put as tentative item on the agenda "time latency aspects" of the join protocol. I will send out a more definitive agenda tomorrow around noon EST. Please send agenda request to me prior to that time.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) time latency aspects
3) AOB

On 1/28/2015 10:16 AM, Rene Struik wrote:
Dear colleagues:

Please find below the minutes of the 6TiSCH Security conf call as of January 27, 2015, 9-10am EST.

Minutes 6TiSCH Security conf call, Wed January 27, 2015, 9-10am EST
{note taker: Rene Struik}
{recording: not available (Michael Richardson had control, but was not on the call}
{discussion material (referenced in minutes): this time, no posted collatoral}

1. Attendance:
Tero Kivinen, Yoshi Ohba, Rene Struik

2. Agenda
The suggested updated agenda was approved.
Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) prep for IETF-92 in Dallas
3) AOB

3. Minutes
The minutes of the previous 6TiSCH security conference call (Thu January 22, 2015) were approved.

4. Prep for IETF-92 in Dallas {more of a 6tisch security various "varia" discussion really}
YO asked what happened with the output of the join process overview text discussed during last week's call. RS mentioned that Pascal Thubert included this in the 6tisch architecture draft (Section 13 - Security Considerations) and would issue draft-ietf-6tisch-architecture-05 for WGLC some time this week.

RS mentioned that at the IETF-92 meeting in Dallas in March, the  6tisch group would presumably recharter and include more security-related milestones into the revised charter. He thought it would be useful to have a 6tisch security draft by that meeting that could serve as baseline.

TK provided some more insight into the 802.15.4rev effort. He suggested that there would be 1-2 more letter ballots, followed by the start of sponsor ballot around end of March 2015, with anticipated conclusion of the work around July-August this year. RS commented that this schedule seemed quite aggressive, considering historical timelines of IEEE 802.15 efforts. TK mentioned that according to Bob Heile (Chair IEEE 802.15) the 802.15rev draft would only be available in the 802.15 private member area or to those people participating in person in an actual IEEE 802 meeting. Therefore, it does not seem possible to make a draft available to interested parties in the 6tisch community who did not meet those criteria (as previously suggested).

5. AOB
RS suggested to cancel the 6tisch security call of next week and reconvene two weeks from now, which was agreed upon. Next call will take place Tue Feb 10, 2015, 4.30pm EST.

RS mentioned he had received feedback from Kris Pister and Yoshi Ohba on draft-struik-6tisch-security-architectural-considerations-01 (posted January 9, 2015). Before updating the draft, he would like to see more people give this a look. He invited people to use the now cancelled slot of next week's call to review this draft...

[call ended @9.23am EST]


On 1/26/2015 12:15 PM, Rene Struik wrote:
Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue January 27, 2015, 9am EST. I expect this to be a short call.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) prep for IETF-92 in Dallas
3) AOB

The dial-in info is below.

Best regards, Rene

B) Dial-in information:
English : New York Time 6tisch security
Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00)
Meeting number:   641 709 118
Meeting password: joinjoin
Audio connection:
      1-877-668-4493 Call-in toll free number (US/Canada)
      1-650-479-3208 Call-in toll number (US/Canada)

Access code: 641 709 118
Meeting link:
        https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6

The etherpad we have used is at:
       http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt


On 1/21/2015 10:30 AM, Rene Struik wrote:
Dear colleagues:

Giuseppe Piro offered to give a presentation on MAC security aspects, resulting in the updated agenda below. Dial-in info at bottom of email.

Remember: 6tisch security call is now tomorrow, Thu Jan 21, 2015, 1pm EST, with duration not to exceed one hour. Please call-in on time and test your speaker/mike beforehand.

Suggested updated agenda:
1) administrativia {agenda bashing/minutes} [4 min]
2) 6tisch security conf call schedule moving forward [1 min]
3) input 6tisch security to architecture draft [15 min]
-- RS to present result homework assignment of last call
4) presentation Giuseppe Piro re MAC security [30 min]
5) prep for IETF-92 in Dallas [10 min]
5) AOB

Link to suggested text (item #3 above):
https://drive.google.com/file/d/0B2a6Ilxu1XfCbVhfd0ZONXoxc00/view?usp=sharing

On 1/20/2015 4:54 PM, Rene Struik wrote:
Dear colleagues:

Due to connectivity problems, those on the 6tisch security call today concluded that it was best to reschedule the call.

The rescheduled 6tisch security call will take place this Thursday, January 22, 2015, 1-2pm EST.
(Please note that this is only once; schedule moving forward will otherwise remain the same)

Agenda and dial-in info remain the same (please scroll down).

Best regards, Rene


On 1/20/2015 4:35 PM, Rene Struik wrote:
I posted the document on Google drive, see weblink below.

https://drive.google.com/file/d/0B2a6Ilxu1XfCa3RyZzlZb3RRREk/view?usp=sharing

On 1/20/2015 1:13 AM, Rene Struik wrote:
Dear colleagues:

Please find attached my analysis of the three text proposals. I hope this helps in zooming in on consensus text.

I will present this in more detail as item #3 on the agenda for the 6tisch security call of tomorrow, Tue Jan 20, 2015, 4.30pm EST.

We can discuss this in more detail during that call (I won't have much time beforehand).

Best regards, Rene

[excerpt of minutes of 6tisch security conf call as of January 14, 2015, 11am-12pm EST]
TW asked whether RS could review the three text proposals currently on the table and suggest a way forward that takes into account consensus and what was discussed during the call. RS agreed to take this on as homework assignment, with target to report back on this to the group by the end of Monday next week (January 19, 2015).

On 1/19/2015 2:20 PM, Rene Struik wrote:
Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue January 20, 2015, 4.30-5.30pm EST.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) 6tisch security conf call schedule moving forward
3) input 6tisch security to architecture draft
-- RS to present result homework assignment of last call
4) prep for IETF-92 in Dallas
5) AOB

For dial-in info, please see bottom of this email.

As to item #2 above, if you wish to weigh-in, please do respond to the Doodle poll by end of *today*, see https://doodle.com/q63844gqd59urrae.

Best regards, Rene

-------- Forwarded Message --------
Subject: reminder -- 6tisch security call *tomorrow*, Wed Jan 14, 2015, 11am EST (dial-in info at bottom)
Date: Tue, 13 Jan 2015 19:37:04 -0500
From: Rene Struik <rstruik.ext@gmail.com>
To: tisch-security <6tisch-security@ietf.org>


Dear colleagues:

Just a quick reminder that we *do* have a conf call tomorrow, Wed Jan 14, 2015, 11am EST.

Currently, the main agenda item is item #4b of last week: input to the 6tisch architecture draft. It would also be good to have some more comments on the draft I posted.

Minutes of calls later tonight (sorry - extremely busy). For conf call dial-in info, see bottom of email.

Best regards, Rene

==
Note: next week's call is on Wed Jan 14, 2015, 11am EST.

On 1/6/2015 11:48 AM, Rene Struik wrote:
Dear colleagues:

Happy New Year!

According to the agreed-upon 6tisch security conf call schedule, we will resume the conference call series today, Tue Jan 6, 2015, 5pm EST.

I propose we continue the discussion where we left off prior to Christmas (essentially, item 3c below), except that we may have a short presentation first (item #2).

Agenda:
1) administrativia {agenda bashing/minutes}
2) {still to be confirmed} presentation Giuseppe Piro
3) join protocol details
-- a) (done) status update MAC behavior
-- b) (brief!) recap of routing/communication flow aspects
-- c) incremental deployment aspects
4) input 6tisch security to other 6tisch documents
-- a) terminology draft
-- b) architecture draft

Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris time. {The next call, on January 6, 2014) is also at 5pm EST (see schedule till half of January 2015)}.
Note: next week's call is on Wed Jan 14, 2015, 11am EST.

Dial-in info at end of this email.

Best regards,

Rene

-------- Forwarded Message --------
Subject: Suggested agenda for 6tisch security call of *today*, Tue December 16, 2014, 5pm EST (dial-in info at bottom)
Date: Tue, 16 Dec 2014 09:21:20 -0500
From: Rene Struik <rstruik.ext@gmail.com>
To: tisch-security <6tisch-security@ietf.org>


Dear colleagues:

I propose we continue the discussion where we left off last week.

Agenda:
1) administrativia {agenda bashing/minutes}
2) join protocol details
-- a) (brief!) status update MAC behavior
-- b) continuation of routing/communication flow aspects {last week, we did not finish the only two slides on this
3) input 6tisch security to other 6tisch documents

Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris time. {The next call, on January 6, 2014) is also at 5pm EST (see schedule till half of January 2015)}.

Dial-in info at end of this email.

Best regards,

Rene

-------- Forwarded Message --------
Subject: suggested agenda for 6tisch security call of tomorrow, Tue December 9, 2014, 9am EST (dial-in info at bottom)
Date: Mon, 08 Dec 2014 17:16:40 -0500
From: Rene Struik <rstruik.ext@gmail.com>
To: tisch-security <6tisch-security@ietf.org>


Dear colleagues:

For last week's Tue Dec 2, 2014, 9am EST conf call I prepared some material and posted prior to the call. During the call, we discussed all MAC-related aspects relevant for the join protocol and did not discuss higher-layer aspects I prepared material for yet. I suggest we continue the systematic discussion of last week and take that topic on now.

This leads to the following suggested agenda for this week (essentially a continuation of last week's one):

Same as last week's, except with
#1a-b) focus on routing/communication flow related aspects join protocol;
#2a): confirm concensus on MAC (as discussed last week) and routing/communication flow aspects
#2c) {as consequence of two items above} what to squeeze into architecture draft

The detailed agenda and dial-in info is below (#A, resp. #B).

Best regards, Rene

A) Suggested agenda Tue Dec 9, 2014, 9am EST call

Proposed agenda:

0) Agenda bashing

1) Join protocol details
a) desired properties
b) realizable properties

#1a-b) focus on routing/communication flow related aspects join protocol (we discussed MAC-related join-relevant aspects during the conf call of Tue Dec 2, 2014, 9am EST).
For slides, see https://drive.google.com/folderview?id=0B2a6Ilxu1XfCNF9JaXR1ZXlzZlU&usp=sharing (same slides as sent out prior to Dec 2, 2014, 9am EST call)
Relevant slides: Slides 23-25 (contained in entire slide deck (ppt), but also in excerpt (pdf))
2) Next steps:
        a) consensus on 1#a and 1#b
#2a): confirm consensus on MAC (as discussed last week) and routing/communication flow aspects
#2c) {as consequence of two items above} what to squeeze into architecture draft
        b) form tiger team to work out details
            - project phases
            - communication of sub-results
        c) what to squeeze into architecture draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call.

B) Dial-in information:
English : New York Time 6tisch security
Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00)
Meeting number:   641 709 118
Meeting password: joinjoin
Audio connection:
      1-877-668-4493 Call-in toll free number (US/Canada)
      1-650-479-3208 Call-in toll number (US/Canada)

Access code: 641 709 118
Meeting link:
        https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6

The etherpad we have used is at:
       http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363






-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363




-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------060705000307020900040904-- From nobody Tue Feb 10 10:26:53 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7CB1A1B34 for <6tisch-security@ietfa.amsl.com>; Tue, 10 Feb 2015 10:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.51 X-Spam-Level: X-Spam-Status: No, score=-5.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 UzEg4fSVQLYg for <6tisch-security@ietfa.amsl.com>; Tue, 10 Feb 2015 10:26:50 -0800 (PST) Received: from sjmda11.webex.com (sjmda11.webex.com [64.68.124.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B52D1A1B32 for <6tisch-security@ietf.org>; Tue, 10 Feb 2015 10:26:50 -0800 (PST) Received: from jva2tc114.webex.com (sjc02-wxp00-lbace03-core-vl120-np10-2.webex.com [64.68.121.246]) by sjmda11.webex.com (Postfix) with ESMTP id EB0FAC0628 for <6tisch-security@ietf.org>; Tue, 10 Feb 2015 18:26:49 +0000 (GMT) Received: from jva2tc114.webex.com (localhost [127.0.0.1]) by jva2tc114.webex.com (Postfix) with ESMTP id 99C8515F54A for <6tisch-security@ietf.org>; Tue, 10 Feb 2015 18:26:49 +0000 (GMT) Date: Tue, 10 Feb 2015 18:26:49 +0000 (GMT) From: Michael Richardson To: 6tisch-security@ietf.org Message-ID: <1591392841.54438.1423592809627.JavaMail.nobody@jva2tc114.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_54436_1355183710.1423592809626" X-Priority: 3 Importance: normal Archived-At: Subject: [6tisch-security] WebEx meeting rescheduled: 6tisch security X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mcr+nomcom@sandelman.ca List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 18:26:52 -0000 ------=_Part_54436_1355183710.1423592809626 Content-Type: multipart/Alternative; boundary="----=_Part_54437_361053888.1423592809627" ------=_Part_54437_361053888.1423592809627 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTWljaGFlbCBSaWNoYXJkc29uIGNoYW5nZWQgdGhlIHRpbWUgZm9yIHRoaXMgV2Vi RXggbWVldGluZy4KCgo2dGlzY2ggc2VjdXJpdHkKVHVlc2RheSwgRmVicnVhcnkgMTAsIDIwMTUK NDozMCBwbSAgfCAgRWFzdGVybiBTdGFuZGFyZCBUaW1lIChOZXcgWW9yaywgR01ULTA1OjAwKSAg fCAgMSBociAyMCBtaW5zCgoKSk9JTiBXRUJFWCBNRUVUSU5HCmh0dHBzOi8vaWV0Zi53ZWJleC5j b20vaWV0Zi9qLnBocD9NVElEPW1mMWVlZTI5ZTIwYTFmNzY0OTEyZmJkZDgyNWExMmIxOApNZWV0 aW5nIG51bWJlcjogNjQzIDI0OSAwODkKTWVldGluZyBwYXNzd29yZDogam9pbmpvaW4KCg0KSk9J TiBCWSBQSE9ORQ0KMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9D YW5hZGEpIAoxLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpCkFj Y2VzcyBjb2RlOiA2NDMgMjQ5IDA4OQoKVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiAK aHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYNCg0KCkFk ZCB0aGlzIG1lZXRpbmcgdG8geW91ciBjYWxlbmRhcjoKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2oucGhwP01USUQ9bWFiZWQ5OTdlNDljOTE3MDlhNGQ1MmY0YTk2OTgwZDMyDQoNCgpDYW4n dCBqb2luIHRoZSBtZWV0aW5nPyBDb250YWN0IHN1cHBvcnQgaGVyZToKaHR0cHM6Ly9pZXRmLndl YmV4LmNvbS9pZXRmL21jCgoKSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlz IFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1 cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJs ZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0 aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQg dG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9y IGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLgo= ------=_Part_54437_361053888.1423592809627 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBNaWNo YWVsIFJpY2hhcmRzb24gY2hhbmdlZCB0aGUgdGltZSBmb3IgdGhpcyBXZWJFeCBtZWV0aW5nLgog ICAgICAgICAgICAgICAgCSAgICAgICAgICAgPC90ZD4KICAgICAgPC90cj4KPC90YWJsZT4KCgoK Cjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6 MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZSAgd2lkdGg9IjEwMCUi PgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0iZm9udC1zaXplOjE2cHg7IGNvbG9yOiM0 RDRENEQiPgoJCQkJCQkJCQk8Yj42dGlzY2ggc2VjdXJpdHk8L2I+CgkJCQkJCQkJPC90ZD4KCQkJ CQkJCTwvdHI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD5UdWVz ZGF5LCBGZWJydWFyeSAxMCwgMjAxNQoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQkJ PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+NDozMCBwbSZuYnNwOyZuYnNwO3wm bmJzcDsmbmJzcDtFYXN0ZXJuIFN0YW5kYXJkIFRpbWUgKE5ldyBZb3JrLCBHTVQtMDU6MDApJm5i c3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzEgaHIgMjAgbWlucwoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8 L3RyPgoJCQkJCQk8L3RhYmxlPgoKPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7 Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJ PHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFudCI+CgkJCQkJCQk8 dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJjb2xvcjojMDBBRkY5O2ZvbnQtc2l6ZToxNnB4Ij4KCQkJ CQkJCQkJPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWYx ZWVlMjllMjBhMWY3NjQ5MTJmYmRkODI1YTEyYjE4IgoJCQkJCQkJCQkJc3R5bGU9InRleHQtZGVj b3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxNnB4O2NvbG9yOiMwMEFGRjkiPgoJCQkJCQkJCQkJPGI+ Sm9pbiBXZWJFeCBtZWV0aW5nPC9iPgoJCQkJCQkJCQk8L2E+CgkJCQkJCQkJPC90ZD4KCQkJCQkJ CTwvdHI+CgkJCQkJCTwvdGFibGU+CgkJCQkJCTx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lk dGg6YXV0byFpbXBvcnRhbnQiPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJ CQk8dGQgc3R5bGU9InBhZGRpbmctcmlnaHQ6IDVweDsiPgoJCQkJCQkJCQlNZWV0aW5nIG51bWJl cjoKCQkJCQkJCQk8L3RkPgoJCQkJCQkJCTx0ZD42NDMgMjQ5IDA4OQoJCQkJCQkJCTwvdGQ+CgkJ CQkJCQk8L3RyPgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0icGFkZGluZy1yaWdodDog NXB4OyI+TWVldGluZyBwYXNzd29yZDo8L3RkPgoJCQkJCQkJCTx0ZD5qb2luam9pbjwvdGQ+CgkJ CQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoKCgoJCgoJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1o ZWlnaHQ6MjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFi bGU+PHRhYmxlPjx0cj48dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4Ij48Yj5Kb2luIGJ5IHBob25l PC9iPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48Yj4xLTg3Ny02NjgtNDQ5 MzwvYj4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+ PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+PGI+MS02NTAtNDc5LTMyMDg8L2I+Jm5ic3A7Q2Fs bC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjow cHgiPjx0ZD5BY2Nlc3MgY29kZTombmJzcDs2NDMgMjQ5IDA4OTwvdGQ+PC90cj48dHIgc3R5bGU9 Im1hcmdpbjowcHgiPjx0ZD48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZy ZWVfcmVzdHJpY3Rpb25zLnBkZiIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6 ZToxM3B4O2NvbG9yOiMwMEFGRjk7Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L2E+ PC90ZD48L3RyPjwvdGFibGU+CgoJCQkJCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIw cHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPjx0YWJs ZT48dHI+PHRkIHN0eWxlPSJmb250LXNpemU6MTNweCI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndl YmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWFiZWQ5OTdlNDljOTE3MDlhNGQ1MmY0YTk2OTgwZDMy IiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOTsgZm9udC1zaXplOjEz cHgiPkFkZCB0aGlzIG1lZXRpbmc8L2E+IHRvIHlvdXIgY2FsZW5kYXIuPC90ZD48L3RyPjwvdGFi bGU+Cjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWln aHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT4KICAgIDx0cj4KICAgICAg IDx0ZCBzdHlsZT0iZm9udC1zaXplOiAxM3B4O2ZvbnQtZmFtaWx5OiBBcmlhbDtjb2xvcjogIzY2 NjY2NjsiPgogICAgICAgIENhbid0IGpvaW4gdGhlIG1lZXRpbmc/CiAgICAgCTxhIGhyZWY9Imh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYyIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25l O2ZvbnQtc2l6ZToxM3B4O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMEFGRjk7Zm9udC1jb2xv cjojMDBBRkY5OyI+CiAgICAgICAgCUNvbnRhY3Qgc3VwcG9ydC48L2E+CgkJPC90ZD4KICAgIDwv dHI+CjwvdGFibGU+Cjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAxMHB4OyI+PHRkIHN0 eWxlPSJoZWlnaHQ6MTBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZT4K CQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxMnB4O2NvbG9yOiAjQTBB MEEwOyI+CgkJCQkJCQkJCUlNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBX ZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJp bmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUg aW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGlj YWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRv IGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBk byBub3Qgam9pbiB0aGUgc2Vzc2lvbi48L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJsZT4K CQkJCTwvdGQ+CgkJCTwvdHI+CgkJPC90YWJsZT4KCTwvdGQ+CiAgIDwvdHI+CjwvdGFibGU+Cgo8 L2JvZHk+ ------=_Part_54437_361053888.1423592809627-- ------=_Part_54436_1355183710.1423592809626 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEzMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkNMQVNTOlBVQkxJQwpERVNDUklQVElPTjpc blxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW00ZmYzODNhNWMzODAwMmMyZGJmNzhlZWI0YjJjNGY5M1xuTWVldGluZyBudW1iZXI6 IDY0MyAyNDkgMDg5XG5NZWV0aW5nIHBhc3N3b3JkOiBqb2luam9pblxuXG5cbkpPSU4gQlkgUEhP TkVcbjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKSBc bjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcbkFjY2VzcyBj b2RlOiA2NDMgMjQ5IDA4OVxuXG5Ub2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IFxuaHR0 cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGZcblxuXG5cbkNh bid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOlxuaHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL21jXG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhh dCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBz ZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2Nv dmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBh dXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNv bnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBo b3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuClgtQUxULURFU0M7Rk1UVFlQRT10ZXh0 L2h0bWw6CTxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+IDxGT05UIFNJWkU9 IjQiIEZBQ0U9IkFSSUFMIj4JCTxhCQkJCQlocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2ll dGYvai5waHA/TVRJRD1tNGZmMzgzYTVjMzgwMDJjMmRiZjc4ZWViNGIyYzRmOTMiPjxGT05UIFNJ WkU9IjMiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlhbCI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9G T05UPjwvYT4JCQk8dGFibGU+CQkJCTx0cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyOjwvRk9OVD4JCQkJCTwv dGQ+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj42NDMgMjQ5IDA4OTwvRk9OVD4JCQkJCTwvdGQ+CQkJCTwvdHI+CQkJPC90YWJsZT4JCQk8 dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi Pk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBDT0xPUj0i IzY2NjY2NiIgRkFDRT0iYXJpYWwiPmpvaW5qb2luPC9GT05UPjwvdGQ+PC90cj48L3RhYmxlPgkJ PC9GT05UPjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwv Rk9OVD48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQg U0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48c3Ryb25nPjEtODc3LTY2OC00 NDkzPC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpPC9G T05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij48c3Ryb25nPjEtNjUwLTQ3OS0zMjA4PC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51bWJl ciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+QWNjZXNzIGNvZGU6IDY0MyAyNDkgMDg5PC9GT05UPiZuYnNwOyA8 QlI+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9u cy5wZGYiPjxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+VG9sbC1m cmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9GT05UPjwvYT4gJm5ic3A7IDxCUj48L0ZPTlQ+PEJS PjxCUj4JJm5ic3A7PEJSPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPgkJCQlDYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD4JPGEgaHJlZj0iaHR0cHM6Ly9p ZXRmLndlYmV4LmNvbS9pZXRmL21jIj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZB Q0U9IkFyaWFsIj5Db250YWN0IHN1cHBvcnQuPC9GT05UPjwvYT4JJm5ic3A7PEJSPiZuYnNwOzxC Uj48Rk9OVCBDT0xPUj0iI0EwQTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJpYWwiPklNUE9SVEFOVCBO T1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBh bmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3Jk ZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5p bmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3Jk aW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlv dXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48L0ZP TlQ+PC9GT05UPgpBVFRFTkRFRTtDTj0iTWljaGFlbCBSaWNoYXJkc29uIjtST0xFPVJFUS1QQVJU SUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm1jcitub21jb21Ac2FuZGVsbWFuLmNhCkRUU1RBTVA6 MjAxNTAyMTBUMjEzMDAwWgpVSUQ6V0VCRVgtTUVFVElORyBDRU5URVItNi4wNDU2NjgwLTMxMjA3 MzU1Ny1TVT1pZXRmClBSSU9SSVRZOjUKUkVDVVJSRU5DRS1JRDtUWklEPSJFYXN0ZXJuIFRpbWUi OjIwMTUwMjEwVDA5MDAwMApEVFNUQVJUO1RaSUQ9IkVhc3Rlcm4gVGltZSI6MjAxNTAyMTBUMTYz MDAwCkRURU5EO1RaSUQ9IkVhc3Rlcm4gVGltZSI6MjAxNTAyMTBUMTc1MDAwClNFUVVFTkNFOjE0 MjM1OTI4MDkKU1VNTUFSWTo2dGlzY2ggc2VjdXJpdHkKVFJBTlNQOk9QQVFVRQpPUkdBTklaRVI7 Q049Ik1pY2hhZWwgUmljaGFyZHNvbiI6TUFJTFRPOm1jcitub21jb21Ac2FuZGVsbWFuLmNhCkxP Q0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0ZgpCRUdJTjpWQUxBUk0KVFJJR0dFUjot UFQxNU0KQUNUSU9OOkRJU1BMQVkKREVTQ1JJUFRJT046UmVtaW5kZXIKRU5EOlZBTEFSTQpFTkQ6 VkVWRU5UCkVORDpWQ0FMRU5EQVIK ------=_Part_54436_1355183710.1423592809626-- From nobody Mon Feb 16 17:14:25 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E67E1A8952 for <6tisch-security@ietfa.amsl.com>; Mon, 16 Feb 2015 17:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.92 X-Spam-Level: * X-Spam-Status: No, score=1.92 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, 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 IhibRshtIUIE for <6tisch-security@ietfa.amsl.com>; Mon, 16 Feb 2015 17:14:21 -0800 (PST) Received: from rominette.imag.fr (mx2.imag.fr [IPv6:2001:660:5301:59::17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83BD1A8954 for <6tisch-security@ietf.org>; Mon, 16 Feb 2015 17:14:19 -0800 (PST) Received: from globule.imag.fr (globule.imag.fr [129.88.34.238]) by rominette.imag.fr (8.13.8/8.13.8) with ESMTP id t1H1EA3u008463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6tisch-security@ietf.org>; Tue, 17 Feb 2015 02:14:11 +0100 Received: from dhcp-33-61.eecs.berkeley.edu (dhcp-33-61.EECS.Berkeley.EDU [128.32.33.61]) (authenticated bits=0) by globule.imag.fr (8.13.8/8.13.8) with ESMTP id t1H1EBVh013017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6tisch-security@ietf.org>; Tue, 17 Feb 2015 02:14:13 +0100 From: Malisa Vucinic Content-Type: multipart/alternative; boundary="Apple-Mail=_4C17C210-6AE4-47C5-BEBB-21D310306111" Message-Id: <8E377EDE-074F-472E-B397-86F29AEDEB19@imag.fr> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Date: Mon, 16 Feb 2015 17:14:11 -0800 References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> <54D98E01.4090103@gmail.com> To: 6tisch-security@ietf.org In-Reply-To: <54D98E01.4090103@gmail.com> X-Mailer: Apple Mail (2.2070.6) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (rominette.imag.fr [129.88.30.17]); Tue, 17 Feb 2015 02:14:11 +0100 (CET) X-IMAG-MailScanner-Information: Please contact MI2S MIM for more information X-MailScanner-ID: t1H1EA3u008463 X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-SpamCheck: X-IMAG-MailScanner-From: malisa.vucinic@imag.fr MailScanner-NULL-Check: 1424740453.00455@A922rkxNn8qwdsU6n1z1Dw Archived-At: Subject: [6tisch-security] Latency aspects of TSCH X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 01:14:23 -0000 --Apple-Mail=_4C17C210-6AE4-47C5-BEBB-21D310306111 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I prepared a couple of slides on latency aspects with TSCH that can = hopefully be useful for evaluating different proposals for the join = process once there are more details on message sizes involved. Regards, Malisa > On 09 Feb 2015, at 20:50, Rene Struik wrote: >=20 > Dear colleagues: >=20 > Just a quick reminder that we have a 6TiSCH security conf call = tomorrow, Tue February 10, 2015, 4.30pm EST.=20 >=20 > I have not seen any email traffic the last two weeks, nor any more = feedback on the draft document I posted on Fri January 9th. >=20 > I put as tentative item on the agenda "time latency aspects" of the = join protocol. I will send out a more definitive agenda tomorrow around = noon EST. Please send agenda request to me prior to that time. >=20 > Suggested agenda: > 1) administrativia {agenda bashing/minutes} > 2) time latency aspects > 3) AOB --Apple-Mail=_4C17C210-6AE4-47C5-BEBB-21D310306111 Content-Type: multipart/mixed; boundary="Apple-Mail=_25799639-0E67-401E-AFDE-C0E316E8C0B1" --Apple-Mail=_25799639-0E67-401E-AFDE-C0E316E8C0B1 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi all,

I prepared a couple of slides on latency aspects with TSCH that can hopefully be useful for evaluating different proposals for the join process once there are more details on message sizes involved.

Regards,
Malisa

--Apple-Mail=_25799639-0E67-401E-AFDE-C0E316E8C0B1 Content-Disposition: inline; filename=latency_tsch_dedicated_cells.pdf Content-Type: application/pdf; x-mac-hide-extension=yes; x-unix-mode=0644; name="latency_tsch_dedicated_cells.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAFFUT1vwjAQ3fMrXktbHEocnz9IvBZ16YZkiQE6RaAOpFKa /y/1bGLjG3x+9z5O8oQDJigoqfhoo63rCR156fnAWYW/C474RbufCcMMSjUPLHJmoY1FURXsVrDF 3KjOm97gVuIeyA+um5igYwJvwzUP1cRRsSXsSFJayFglu85hGPERYG2a89WTtM77HRp+hBFtCJp1 4YoTxFNdNUpaiOfVS83bcPda4w69RYAg1svgLNKEkXO9QJuMvN9FlcguWbwqlId8m8gGokmNZsNi LfOsTZs5CJVJFFnfCF/4DPw3h38TJFCrCmVuZHN0cmVhbQplbmRvYmoKNSAwIG9iagoyMzEKZW5k b2JqCjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDYgMCBS IC9Db250ZW50cyA0IDAgUiAvTWVkaWFCb3ggWzAgMCA3MjAgNTQwXQo+PgplbmRvYmoKNiAwIG9i ago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSIC9D czIgOCAwIFIgPj4gL0ZvbnQgPDwKL1RUMiAxMCAwIFIgPj4gPj4KZW5kb2JqCjExIDAgb2JqCjw8 IC9MZW5ndGggMTIgMCBSIC9OIDMgL0FsdGVybmF0ZSAvRGV2aWNlUkdCIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+CnN0cmVhbQp4AYVV32/bVBQ+iW9SpBY/IFhHh4rFr1VTW7kbGq3GBkmTpe1KFqXp 2Cok5Do3iakbB9vptqpPe4E3BvwBQNkDD0g8IQ0GYnvZ9sC0SVOHKqpJSHvoxA8hJu0FVeG7dmIn U8Rc9frLOd855zvnXttEPV9ptZoZVYiWq66dzySVk6cWlJ5NitKz1EsD1KvpTi2Ry80SLsEV987r 4R2KCMvtke7+TvYjv3qL3NGJIk/AbhUdfRn4DFHM1Gu2SxS/B/v4abcG3PMc8NM2BAKrApd9nBJ4 0ccnPU4hPwmO0CrrFa0IvAY8vNhmL7dhXwMYyJPhVW4buiJmkbOtkmFyz+Evj3G3Mf8PLpt19Oxd g1j7nKW5Y7gPid4r9lS+iT/XtfQc8EuwX6+5SWF/BfiP+tJ8AngfUfSpkn103udHX1+tFN4G3gV7 0XCnC037anUxexwYsdH1JeuYyCM413VnErOkF4DvVvi02GPokajIU2ngYeDBSn2qmV+acVbmhN3L s1qZzAIjj2S/p83kgAeAP7StvKgFzdI6NzOiFvJLV2turqlB2q6aWVEL/TKZO16PyCltu5XClB/L Drp2oRnLFkrG0ekmf61memcR2tgFu54X2pCf3dLsdAYYedg/vDov5gYc213UUmK2o8BH6EREI04W LWLVqUo7pFCeMpTEvUY2PCUyyISFw8thMSJP0hJs3Xk5j+PHhIyyF70tolGlO8evcL/JsVg/U9kB /B9is+wwG2cTpLA32JvsCEvBOsEOBQpybToVKtN9KPXzvE91VBY6TlDy/EB9KIhRztnvGvrNj/6G mrBLK/QjT9AxNFvtEyAHE2h1N9I+p2trP+wOPMoGu/jO7b5ra3T8cfON3Yttxzawbsa2wvjYr7Et /G1SAjtgeoqWocrwdsIJeCMdPVwB0yUN62/gWdDaUtqxo6Xq+YHQIybBP8g+zNK54dCq/qL+qW6o X6gX1N87aoQZO6YkfSp9K/0ofSd9L/1MinRZuiL9JF2VvpEuBTm7772fJdh7r19hE92KXWjVa581 J1NOynvkF+WU/Lz8sjwbsBS5Xx6Tp+S98OwJ9s0M/R29GHQKs2pNtXst8QQYNA8lBp0G18ZUxYSr dBZZ25+TplI2yMbY9COndlyc5ZaKeDqeiidIie+LT8TH4jMCt568+F74JrCmA/X+kxMwOjrgbSxM Jcgz4p06cVZF9Ap0m9DNXX4G3w6iSat21jbKFVfZr6qvKQl8yrgyXdVHhxXNNBXP5Sg2d7i9wouj JL6DIo7oQd77vkV23Qxt7ltEh//CO+tWaFuoE33tEPW/GtqG8E585jOiiwf1ur3i56NI5AaRUzqw 3/sd6Uvi3XS30XiA91XPJ0Q7Hzca/643GjtfIv8W0WXzP1kAcXgKZW5kc3RyZWFtCmVuZG9iagox MiAwIG9iagoxMDQ3CmVuZG9iago3IDAgb2JqClsgL0lDQ0Jhc2VkIDExIDAgUiBdCmVuZG9iagox MyAwIG9iago8PCAvTGVuZ3RoIDE0IDAgUiAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdlndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRR iUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nn t9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz 9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48Sv bPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjAShXJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlf zOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHimZ+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN 4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zs rC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC03pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/uf gm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TMzAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR 6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRodV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAx Csi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9kciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyA M3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqG wUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQOBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6 CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhHwsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVf wpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQDqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh 1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJNhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxw frgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/Bc/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYg JGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7YQbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9 IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxFQtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9 Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6fJ18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJ RZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIlpSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0 H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyTjLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUi lWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uuq43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o9 6pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoLtQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+ pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0svWC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0Gb waihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgm NKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIudFt0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJpr XWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtOu8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR 6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6 zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrPC16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752 vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARGBFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC /EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJFREPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtF l0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoe Gx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9B teB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqwK10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZ ZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTkmuRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6t hdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99uit7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVs FWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/ndzPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu 4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqvakfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/T AY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2 wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibak Nml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HOFZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6w rt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n +l37L972un3ljv+dGwOLBvruLr57/17cPel93v3RB6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjX Zqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV 0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5Wf jT93fAn88ngmbWbm3/eE8/sKZW5kc3RyZWFtCmVuZG9iagoxNCAwIG9iagoyNjEyCmVuZG9iago4 IDAgb2JqClsgL0lDQ0Jhc2VkIDEzIDAgUiBdCmVuZG9iagoxNiAwIG9iago8PCAvTGVuZ3RoIDE3 IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGlWVuTFTUQfs+viOeAzgI7O8lc MiOKclMBL1B1qnwQHqwtKLT2qLD6k/yfdi79dYbMOTsru1VsSDqdvnx9SeadfqHf6UY3dUM/trVd PxrtzFRP9KP7rtHvX+uf9R/67OGl0eeX2oTfy3Pa1LeJbI8dCnMXmEvM28ZN7djqCxwnM2/1m1v+ BOtPIGno9/JcvaOj/NDorq1NEKibptq5btLne/1gp7suENCftradNeOoT+k/u70+2+0sbdy90b/o yp6o06ZuddWeaBr0urpxQlJ1uvrU/zW62r6swhIN74QBEZ+GgdWVrNVxTVVnYUCMGiYyQoVF5t4F IjqOj+15YgiS0Ypjhkwi7CDQTd4la5/w1GZ740QFlUDFp3+WdPW7XundU/14F7xeGte42g5tS8ZV ZFwbHRH+nNK/0apttGr174ne/X59Vo6AZqa+1cKxTxxJlxUcVfS8CGc9S8JuxlE8Py44ccPmU9Wt YD5yOtvqmKc8dA54ysOLuEzsRPDlo3T1OXtq4AGo4XuPwsTqrncaYQ9EW4gmPKGJFk2w4SZD6wvP ivCMY0qIbb9MGNkAPVDhXpBEiSRYwQBnHoMq1m6zYLfZElhiMbYwEuTBGV+FXWTtqEbmxK+9pBST YiDsxgmyBj5RQc8vBpCQADzYzgJ6mqVYcoSDkKjaiTISxVIB12YRp8yXXbPokAQNlhcWgR8wwBIE hyUSjcqsBGjy6Yf1ZgqxEWDGS/fZPyGnrjJSyuZZTLemHhozeFupD7M5tASgoeWDcDZhne25YWOR dK9UmfsKfxWitM1U29GZudsUFZZgwSMZqx1oZ0ynvlaJdh4CXe0CTnZ7RaVqXVI9yDBLqolvMtq6 1HqQb5Za53wlwT4MFqeggw/Y9AKRAhnJK6pCBoArmbaM5eMZMcWGZElmJGKUqMapGCQtVFWchgDi dCqMAciFKhJTSlbvj1QRv0R5TXIwtvFZC3KJxvAAkmfW1QjT2A7k8Q/DbJA3YBA240yU40Hdmetk vsVMlyzBwTuFikEgg6UxgMTQHo4CDVsPIFUViGRNDMk6yxpwuhGqiNDcjlk5lg2MiUepwjLzzDfJ /gpZC7qwAUSSlyeJj0w9DiFIvcI3PKeqbwuqAtBwMQa8nUurru5zOwJ9WHyOctifF2BZVpwXiHsK UsGinLj5zktMmZvJ+YANxxsv+D3HU7m0sWXe5TZWMphjcPkWmmSgFq/QIW+hY5DCRQge1kVVTzwb 8sfT4Bji9yxNBNEXOnCpQjPRlZQMY7q6df28CKXbDXAOR0K4rB7GRDSrh+slIX2oxabr1HlWxsxk 62ZoglDzIk2V8fsfnj7z6pb18YCyGWO6htbdFDv6OWO6y63TNvpxpu3R6j+zeyZKayglu56uleQL NCK++pMo7HHklQw5siYZg+Ela4R68sta1EfkAXAcIfD2Pc9sdl9FdG5htuxwZsB/QR1jUVUbICrb heBYXxLsvBkmPcKFbYamhb64euKPPYKgD/hm4dLVQz8uXwlhCSgHAz4IqeBQ+3gsXFiSon2kGGm7 FLkFlsWqW8iQzbFfJF9CdnY1XLb9kauAZ7BUoPGGYkZ7ZV86F/WqTtf08bJTaJ91utfkaPu1Mq7r nc0hhh/ZOx/ku6J3Pvo4QW9SB/2vKm4M4H8gAwMsAVqIXMHYaUA85Qw+C8R8gtBe1Xqk6v6T7ECq WmgsIWfZ6V9xpfygAKM1wQA6RKVUdew5YVvWdlgOMrJKxArPMGU2BzkacNysscS7ngfDU28AWl6B l66+P0+DDxI7rnxkgBBLmc+33CHzXbNRYBmK2HeuHsa+X24PltI6EpSL+Ymem8Mjr6T1Mp2sC/6D DD8y+A/yXRH8s5fb67adixeYxeuH4JUxLI+dXFfyOwwQy3CUbZwREB5AKmaKsvSC2cyahRjB2IU0 IWfFy4PCbQCIxQBglk1gCMFkzRuH3wg41234ivIo9f1CDpGQS3BwGih58eCrlWwXq7P+sgbheGl7 N/VtOIsFzOVaKulopSl0fCLwn0UOv9zLlUe6jTJnQs873AzxBaxMlF6pJbkQyaf0taYdBreYoOQJ LPtaM2s1/Leptu/qbuwNNeVj3fWtUXs99KYeB9tjjj4qYc7YsW5cb2kOe7O5t+FrVlohkzC1nRzd sFynR8qDzk2D4g9fz1+/P3/919///Hqh3/9GEoHSfx9J1D2flXGk7HX2ZG/0oz/Vi/DBxbqppufE Vtuhr0fTWb3X3TDUzTRkcxfZXFKZVOG9dCeMZqC5qEpa6dgYJME41G50uieNBmPwBe8DRRTTeT2Y tuQW1bCkBinhPeL6urU9SQ9R9qqlVOgaAiDmyPo8BxvTN0Hem81FNcoV2Pl/eqTkOPfIf+/9bCoK ZW5kc3RyZWFtCmVuZG9iagoxNyAwIG9iagoxNzg3CmVuZG9iagoxNSAwIG9iago8PCAvVHlwZSAv UGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMTggMCBSIC9Db250ZW50cyAxNiAwIFIgL01l ZGlhQm94ClswIDAgNzIwIDU0MF0gPj4KZW5kb2JqCjE4IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BE RiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAw IFIKL0NzMiA4IDAgUiA+PiAvRm9udCA8PCAvVFQzIDE5IDAgUiAvVFQ1IDIxIDAgUiAvVFQyIDEw IDAgUiA+PiAvWE9iamVjdCA8PAovSW0yIDI0IDAgUiAvSW0xIDIyIDAgUiA+PiA+PgplbmRvYmoK MjQgMCBvYmoKPDwgL0xlbmd0aCAyNSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAzOTQgL0hlaWdodCAxMzcgL0ludGVycG9sYXRlCnRydWUgL0NvbG9yU3BhY2UgMjYg MCBSIC9JbnRlbnQgL1BlcmNlcHR1YWwgL1NNYXNrIDI3IDAgUiAvQml0c1BlckNvbXBvbmVudAo4 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ae1dh38bRdr+J0gIHBzwHRx8cDk4IORy cMBRwgU4Do77jp4QSEI/UoD0nhAS0iuQhBRaCukNEju9OVaxHNtx771blmzLktbfo4w83uyuVrPS yi2vf/r5N5qdnfLsvo/mfeedd9ra6I8QIAQIAUKAECAECAFCgBAgBAgBQoAQIAQIAUKAECAECAFC gBAgBAgBQoAQIASCCEiS1NLicTobq6trSkvL8vMKMjOysrNyCguLyssramvrXC63t9VLeBEChAAh 0GkI+Hw+8E9qStrF5JSwH1BWfX1Dp/WNGiIECIGrEwG/319ZUSnIS3LiysrMxiyrW4GGuZ/H42ls bKyprinD3C+/IDMzKyMjMz8vv7SktLqq2ul0trS0oFi36jZ1hhAgBNQIQJDTL2XIOcdoGgzQHXQ9 EA4Y6VJaukj/QcUVFZWYLqoBoRxCgBDoDghUlFeIyHLYMuAEt8vdhSOCQSwCjk1LvVRVVUXzqC58 cNQ0IaCJQGlJWVjaES+QcjEVBnPNhmKaCTUtOztHvJ/qktD7upZaY4oPVU4I9DgEampq1HIaZQ6m Ih5Pa2dC0VDfEIG5THOYVVXVndlzaosQIAQ0EWhqasJUR1NIo8yE70GnKUr1dfVR9lZxO5YGNOGi TEKAEOgcBMAe8AdQCKaJX+GW0AkDiRHBYjLWCZ2nJggBQkATAbMs4aEIDbOyluYWzabNysRaWwQ2 8FAdludDT/S0eMzqJ9VDCBAC4ghg6d8sQ41cqBVpOBeJdymCkkWFRYoWTfyak50TQZfoFkKAEIgS AWxOCSvICecvxMcdtSRa1SXPnD6LS46kZPUlRQ40ryi7Gup2OGgp2jL9K/ymQrVO+YQAIRALBOAT LjJxmjxp8jXXXLN69Rq11L/00su4dPjXw+pLipyiouJYDAF1wkFd0ZbpX7H4CKxi1H+qlhAgBNQI YGeciCCbwk6gwVgs3jU0CA2BDzPJ7vjl0K8idMpvYYnKyio1gJRDCBACMUKguKhEIYOaX01hJ9Ts anSZPpDc3DzNPofKXLliFSZ7+Nu/b3+oMpr5sLqb3nmqkBAgBEIhgP2wmpKoyDSLnUyffni9XkVX w3595pln77333n79+o0aOSpsYUUBTQfyRq/7UMmZbGdhKJApnxAgBCJAQNAD0yx2wlQtgk7q3FJX W6cgEP2vx48d79u37yfjPnn22WdvvvlmS6JFv7ziqqbj1qGS0387MuKlU58tvfRDQvVFnd7SJUKA EBBEAGZehfSF+moWOxXkFwj2TbBYSUlpqD5r5k+cOAk63Y6fdy5ZvASJBfMXaBYLlZmXq+EXMc2x GuzEPk/GvYOv4Kv61u4VRkYQTypGCHQTBHoBO+Xl5YdiEs38P/3pT3fffTcuJV6w3HDDDQ89+JBm sVCZGemZimfX7PP8XHBkjOVLTlAs8cGFz7/PO5DTGKtlSkU36Csh0LMQcLa6XF49FyNT2Onll1/B JERwCcz0uRM28YViEnX+lp+2oKuffvIpu/TKK4Ge79yxU10yVA78CjTfgSZfS3xZwpyL3zxz9EM5 Tb1yavzy9B8Tq1M176JMQuBqQACG2fSGvLiy8xtz9n6esu79C3OfO/7xZ7YlrX69cN/i7DRt2nQI 8vJlK9Riy9gpPi5efUmd07XsNGzYsD59+hz+9Qjr2IYNGzGoN4e9qe5nqJxQ7MTfMXtt+urMbW+c mSznqMHx7053rPml9ExDq/lLlrxpShACXY4ApkMgovjyC5tz932esh4axPPHR8tlgaVBTR5/+NAl glbxFctXQJBhtFGL7YMPPgg7s81qV19S55huFRefO8EA/tvf/nbAgAF7du9ln9279tx0003Q7xLO J6i7qpkDly2RF6DQXbY1/9fRlgWK5/JR4hc/5h3Mc5m8NCDSJSpDCJiOQElT5dHyC9/l7p+Xsv7D C/NeODFG8cJrfhWkJvRW0Ms67kg82GngwIGKzSz79x3AbGTQoEGasqzONN2jQJydFi1chCFo/s2Z PUfdVc2csHMn+QuA35EjZednJX895OgH8sf06ukJK9J/stQIEZ28QkoTAt0KgVOVNvmLLZIWpyaM VNAbE6I6ZMgQiDYW4n/84SerxQZXxrFjx/Xv3x+ZEHxNWVZnulwmqzbYXKxuRTPniSeeuP7669d+ s+7b9Rv4B56ZYNcHHnhA8xZ1ptoqLvK22GourcrY8vqZSfLH9/f492Ymf3W49By0cpFKqAwh0N0Q kNqkkednyt9q/bQhasJgEbxILYOaOdjt+/jjj7O5R98+ffkkhBuZNe+SZ8ZiJ4tgqGEY7cFCL774 orw/LD148GCMBQZz9SV1jjzSQklJiaEjEvJdpT/lH/pv4nzFE0QO8nG1u7171B9CICwC4tOnT8Vs TeXl5XCxZu3CMA5tRS2GmjnJjosHDxxavGjJO++8+/HHo7EpGNEJNEtqZppudMIQBINhjh0zFhS0 ZvVX6o5hOLj06iuvqi+pc3BoC8OttLR03rx569evP3fuHDb6hX2IvABmSpgvYdaEuZOcpjCzwvwK syxekhKEQPdHQHD6JEJNeXl5e/bsmTNnzoULF/jAccSbWgxjkdPc1MwbNSvh8/rCGvZBqnfeeRc8 w+02DdP9ZWv5TVD6zp45G3bUTe6gh4bD4Rg/fvxnl/+WL18eHx9fVlZmaFCwO8H69OrpiXKOgoUK dipYq/RdQQw1RIUJgdghAK/jRWmb5e+wOh2WmjgvMYHau3cv10owjxIJohJWcvUL4HzzGEEU1vSE JbkFC76E/0CoHm74dgMKwPIfqgDLx0Et8iGkpaVt37595syZDNIvvvgCqGZnZ8vLhE1j/Q6reFjL UzxTrPdh1Q9rf2FroAKEQJcgAF7aU3RM7YeseJP1qQm8BKnBfIkJ0cqVK0+ePFlXVycfERQWfcGM 8mogcm9LrCL34ujhKLsneHt1tcYRLfn5+QcPHly4cCGDd9q0aVu2bElOTubkL8c5VBp+s/CGgk8U PKPkDxd+U6sztsKHKtSNlE8IdD4CgryEN1mHmtS8dOLECQUvsaHF+tQDxC2PKYbZ0Z1eJ8JOODwU NrpQo6isrDx+/Pjq1asZR+E/M0k5nc5Qt2jmw6scvuXwMJdz1NNHP4QXOnzR4ZGueRdlEgKdg4Am L8FD5uusnxUeyHiBP7Eu1nS5FOclPqjm5uawBhwRKVaXAXXEIugc7zkSbrdb3a65OQiGIG9RM41u JCYmbtq0iXPUihUrIjBJ5TYWY48e/GzlHIU0ZtHbCg4Xucs1W6dMQiB2COjwUkZDYGv8qYorfJ80 qQmKhlyPg3SEmi+pB1JbU2uuRKM2TDlaW8O7rKs7YzSnpFgojF5kA8zLzTPUn9TUVIVJat++fTk5 xo5OwPuAWAeIeIC4B3KaGnZ2yleZ2x21YULheSXf+uxdfinkfM/QiKjwVYtAWF5iyGDxbkS775Oa mqLhJY58WWl5ZPKreReM7ZhO8MpjmoDaFaMj+eBxERnB4okcOHDgyy+/ZFMpbpLS0RA1IULMKESO QvwoOUc9e+yjuRfXYR8BgiRo3oW9Tig/KWlFS4gCmndRJiHAEWjnpYXyF4/pcWy+xEuyBJs+KajJ FF7iDeH0W02qMZqJWZO7ff2dVx7TBI7MM33xEdouDnyJpttqk9S33357/vx5oyYpxN7Ehibs75a/ KkiPsy5ECBfseFJ0kiuGuAWvmeIqfSUEdBAwykusKkyfsIjT0r6911xe4r3FfhNs2TBKR/LyBQWF 3OGTV9sJCazfmWs9M+ugKEAKH7ONGzcqTFLwjDUES53HeaDk1JSklY/HjZLT1Jtnp8IymVyXxWrD PnH51TfOTCptoiMbDCF9lRZmvDTWIjpf0oSJ8dLcuXPZ287sS7W1tZqFI8iEHbuqskrcjZxTU3ZW dpSTjQh6K7+lsdEVQbd5/3kCLCdiCZc3LZJmJqkZM2awBzd//vwITFJo6HxV8pJL3//n5KdyFvrH sf9it/jx8sTZF7+R5yP9rxNjM52xcjkTGTiV6eYI9AhekmMIpx24QgkKO8IdNDQYW0CXt2ViGmai sC6anIU0Ewh9gEVME7ukqAqLqgqT1NatWy9evGjUJJXlLNiUu+/dhDkKLnrsyEhFDr4+ffSDC9Up ip7QV0Kgx/GS/JFhHuXxeDAjgpqDbS8F+YUgopzs3KLCYnAXHKhg+u4SPU7eSXUahp0ssRNn5ASF Y6FqBZwH1M1FkAOT1LFjx1atWsXVvchMUjWe+v3FJycnrdAkJTlNPRE3Cm6fEXSVbumVCJjFS5j/ y/U4+P6ZqMf1SuTZoHCcqGAMK/BSTU1NrF2z1FCrTVLw5z969KhRkxRqPlflWJi6SWGSkrMTS3+f e0DdDcq5qhAgXuo+jxtTOywg1tXVY7JXXFScm5N7ee5XBCd2GJdcLndkPgMmDhCsmJKSsm3bNoVJ Kjc311Ar2EGspiN1DmxWnc/DhgZChWOEAPFSjIC9GqplJqkFCxYwdW/69OmGTFLvJShdDtTUxHKm Jq3ii79XA7A0Rh1eSr/s7y0CUUFBAelxIkD14jIVFRUKk9SGDRsSEhL010PT6nNDcZFmPmJBYwNy L4aRhsYQiAUvIXAQ2Zeu5hcMJikwEniJm831TVJzLq7VZCGdTOyLKW/WiL1gDHbJZ6w8lQ6JgMk7 j3R5KS9kL668oJgvES9dCc9V/U1tkoLet3//foVJCsXWZG6Hp9M466K3z01/8cQ4rNDp8BK/9O+T 47KchaIQSx6pKVOqO+wvW+vPm+RLf9Wb9Bdv4q1e+wO+Sy/58z7zl66Wag9J7kttfr2zFEWb68Xl vPWSK0mq3u0vXuLLGe1Lfd5ru8drud2X/DdfxnB/wUx/xSap/oTUUtAWEfmH5KXMn+GsK4gr8ZIg UFQMdARSUpikYEsPZd/GzgIobgWusuS6zBMV1r1Fxzfl7F2W/iPiBiPcwfCz03DEz2NxAc8oHBIa /owYn8tfuspr/UOAi0Q+ltv9hfPavKZ5CPeaF0BqzvVlfyCEIcM5aZBUvdMQR7X4PQgEzX+AkAjs jzPOS59//jmbt7P5Eha1e81ToIHEAgFmkoKKx9U9EZNUqJ6A2bA7Jt9VklKfDTbTLia1+ss3eO0D DAgUpy9rf3/J0jZft7ZuYa/0qoytqToIaONiPNdT5s8bjwlSBEj6Lj4p1f4i3uSuwqOMnV4hXhJH jUqagQDM4wqTFLw6YUgHd5lRfUcdkvMC5EIuTS2J9zitz1Tb3im1z8pLWp/h+CUl2ZbuiMtL2lhi n1tle7/B+s9my/3yW7z49a/9taPSbpbixx5hZ9DKjC0xoSnJ5y9f57X2l8FyW5NlUL3135W20cX2 L3OSfrzkOJGabMly7CtIWlNmn1JjHd5oGexJvGKy6kt/XWoJxFMK+4cfHcSop/lSWKCoQIwQwMwH +1/gcgDHAzaV0jRJRdq65C9Z7k28jQtUk+XPRfbFctd6nXR+0jq35VF+LxL+/CltUmcE+zI6Xs5O XBUymaa8Nb701+RQNFifz3Ls1kGPX0pJtpfbJnoS/9hxu7W/VCPkTwuCEoSC2Zfkehx+6UiPE0SP iukjoDBJwaUTjp06Jin92i5flfx5E7lE4Be81D4TksKlRixxEWzWYrmX1+PLfLsbEpSancykqdZK +eQTjJ2b9J0Yeim8WJrjbJXtQ2/i7zmS/sofBB5i+CLgJRgziZfCI0UlokMAm1+wBUZhkkLkFngm GK3YX7KMC4LT+o90xzEuKUYTaY5zddZXeW1Y1zPamViX12EnBU3pWec0e+lv9qW90D722ypsn6Tg ALPkDtoxlM5O2tFkubxCGjDr/V6qi9dsUzCTeEkQKCpmIgLMJIUNxdxsbtQkhdeeK3S11qHRCBSX vkrbmHYhvdVfsVk9XgQZHmtd2CUfnCvBWShsgil9gjTly/20fdS/L7Sv4GhEnMAkymV5Ilin7R6p OU+NZNgcBS8tW7aM9LiwoFEBExFAMBaFSQoxhBG2BTtlwrTSWuG138fe/wbrC6ZQExPGGtuIoFhZ /ldqUp567JN8YZmhWxUATa3L3qkTGFmq3tVOTbcW27+ImJEUN15ynIY5ndXsS/1nmxQ81zvMY718 ubCwUK7HES+JgEZlYocATFLYGIUwd2wqxU1SoVr0ZY1kb36zZSB+qRWiEc1XLO3x331f6nMKB54e xE44ZR6nUVwO6h76DK/WSq8taHADLUeDm/peWNRbE+9gj8lfsiLUo5TnEy/J0aB0t0JAbZJCGGG1 SeqyTsecLW/DGrdaLqLMgftBa+KdQbGq2CSHCN5WJyusXfKBR5DIrOyp+PemOlbhOAmRgwV9uZ+w YcJSBD+BKHFT315qn83q91rvamspliOpSBMvKQChr90TAUTkw4ELCpMU9nI2NbFdJ35fyt/ZO19l e1ctEabklNmnBcXKPqDN30lH9ug/Dn2reICUklYZOu0Ueis33OUmbTYFN1UlyfCGYkiCCTUHiBBw aj1O80hrzdspkxDofAS4SQqHWEHdQ1B6tqgHh0n2tsN/AMYNlThEuNKkqAf6HXRG1hBc0Dt/+OoW NdkJp8bjdIm4svNun+EYzr6c4BJAvfU/iuGb+DUn6acgz1tub/NoTJ+KiormzJmDR8zsS8RL6kdP Od0WARwACpPU2bNnWQ99GW+yt73CNlZfiEaNHPXAAwNXrFipKJZkd7zw/AsPPvhgfNxRxSX512L7 PNYQHIG6AzhydgIpIQYygvhFQErBsXhrvZagUQg+APKBK9LvvPMuYFy8aIkiH18tiZYnn3gSSB6N 1/PlgLNHkOeLF2siicN2sR5HvKQJDmV2fwSCMeG9NdzZL8NxWC0v8pz4uPibbrrp5ptvRkKe//F/ P77mmmumTJkqz1SnU5MvcOuT5E7tcojATiAl7LY7XHrO7Y02tIK/MjilabQ8qR67POfwr0duuOEG wHj82Al5PtLvvfsekJwwfoIiX/EVe16CPJ/8N00Yu2HAf81+UiYhoIOAVLOXveeNlqcUIqD5denS ZRCfxx57HN6FrMCGbzf06dNnyJAhPEfzRpZZa309+KNfuqajVzBDdcXHVm11eaojbFq1oO/Leo8N Dd71OgiwS3NmzwGMzz//vLzk1i3b+vbp+8jDjziSkuX56jTs7R08H5HvUwf4lCIEuisC/oJZTKYq bJ+qpUAz5+WXXwn8vk+YiKv49b/11tvwd/LEKc3Cikzse2XN+bLeCUIieVlOz/qPUFeKR4otz2wI WY5dilGrv4LJocEBxhXLg76aNqv9vvvuw5zql0O/qsurc7BljzWHUFGKntBXQqB3IICIZ+wlL0ha rRYBzZzz5xLuuuuufv2u271rz+DBgzFx+nb9Bs2S6szspJ9Zc76Lg4MA9g528rnYuLBmJ7gtEfrd jTfeCG4/d/Y8gBozegzIau7cz9WgaeZUtDvhI4pd73gVaRSEgAIBuEcyscpJ2qYpBZqZP/zwI3QQ 2KAgUB+8/4FmGc1MbNwLSrHtvmBPAuyEXa497CPVHZEjiVCWbFyIIaM5cM1Mpt+9/faI/fsOgO2f fvppzWKamYhaw1oMhICgP0KgNyLgSxnCXnLByB5cUt4a/hao6Y477rDbknhm2AS80IPsZO3P4EQ0 mE098A971uSvg9SczcYFJ8ywIPACTL8Dz99///233PI/aiM5L6lOFNkXBtmp+22vliNDaUIgYgR8 Kc+2s1N4awmXkVMnT99+++1gJ/wtX2Zgl2ua40yQnWz3sD7DC4tvW+5BCYSpkWOOqLzt7DSIoySS OHI4DvodYOQGKJG7UKbYvqCdnSbKe0JpQqDXICCbO4myE37xsUIHgZo8aTIkS+1goCNfmnOnX/Zt 6nGfstIrIlXK5k7G2AlYPfroowAz7DqdAlW+vtANQ9P0GumggXQtAr60f7Gf4NykHxTvf6ivkyZO gjQNHToMBRbMX4C03MEg1F0sP8NxJDh3sg8MDrx3WMU9JWxcLYl36yOgvhoZO5XaZwTnTgUzuvYV otYJgRgh4Mt+n73kgrF5t2zZeu211957773wamaCBi9xEFRYB0JWODfpe9ZcIFgB++sd7CS1cqfW tOTAGpz4JzJ2qrIF3av8cs+xGL0lVC0h0BUIYD2a0YXI/t+zZ87deedd11133a6dHcGxz5w+CxsU KGv7tu1hRbK0fS+wbAerz2u7r8d9pPpjisfF4/QajdAbGTvxoDRSXZyiJ/SVEOgdCEgNpxg7YYvu xeSg+3cokoFvM6ZJM2cofaHh7wSvp7vvvvtCQmKoe1m+0xo0wmPfR+8AkI8Ch5AyJBEOVB8ExdUI 2AnHuLQHQ7itzVvH+0AJQqB3IBAMnyJ5vLa7mVhh87tCcORfodM9++yz2Agsz+RpaHa4umiR3tEt OF6qQ6Y85b0DRj4KeEC18/wAQ5FFP/zgQ0Ansg+Io82jPPku/Yd3QJ5wu7tFjBp5lyhNCIRFAEHJ ENlp/fr1Bw8eZIX9eROYWOGQAv7+xyKBE9xYQ76MoWH72fMKwPTUfjJpgX1VLABkdYL6eAhff+WP mkDt2LFjy5YtVqvV6RQ9PUqzHsokBDoBAU5KkydPZm5FCP7j8XjQtORGzLRgYEyRPWKRyV2643jH xtXuYSqRGkw+Tt1fvJgh6bY8bGj6ZAhS7ocJY51mHD8EREWgZvaUlyxZgkh0mZmZnfCOUROEgCEE 1KSEl3bx4sV79uzB4Qg+n4/Vhj25TKycVmymCGN9MiRKvDAOeQlOnFL/AUY0NIoYFW6c8gY+Lfs2 +iuKzGnCW+e13cOGCeWLj93EBM7h4gcF+ktXaXa7ubkZwZm///57fhgrHvratWsR9Km0tFTzFsok BDoNAUZKCNXLZ0pyUlIbJQKuzu2R00rsc0yUJlZVftLXTGbxX3IGo951GhqhGmqc8nr9Gw+wT4Cm 9m70l0dLU/6y4EgxUUQ0ddORrLUOCyLp+GubP0xMKrwG8fHxX331FZtH4f/s2bOZxofzxULBQvmE QCwQCEVKu3fvxkxJTUryPnDXApz6oR/a0ajEpTvi4aPIZErmSCBvvGvScnYyjaYkry/lGTZYl+Xx 1GSrUbh0yhfZFwWpCSQvfOYmItGlpaXhHcDZYZymoPHhHDHS+LrmzbuaWuWkNGXKFP76QX0TIaUO nKRWnJLGXv5mywNYs9YRE/FLiIfpsjwWlCnHw22+ho4WuzqlyU7R01TAjmcJHkADfdYsTRlBJDqO i8qbEAF4dXV1CQkJCo1v3bp10PjKysoiqJBuIQRCIWAOKclqD4QBaT+LrcnyEHadiLOQZkns+W20 BE978eKoTZdd1lrXJ/XZKRqa4lF8Qcs11uEpyQbCOGgiiX1GnsT+jOQxNwur0+mDyzS+NWvW8N8y pvHZbDbS+PSho6v6CODEDbgEwKakniklJyfrq2/6NeNqwDnTcjuTAqhjhfblmsIikpmXtAlzsOCs KfFWf9V27dZ9vvqhf+6aT7vRiRORfsKQbcqfP5WPHVGRMx0HREBTl8HaX7ltUmti8KHAaUFqKeRI +msqWnat89pP8RzxBGl84lhRSX0EYkpK8qal2oPcQg75arD+Mztpp1pqdHJgDa6zvsZlEwm9I6LA TgZZoovLD/1z03eLJE+486Qkny/3Uw4C6KXS9jEmkzq4qS/lJ62FcwKvxGt/QHKnyR9Wy6EfgEbD 239t+npGZByF2nD+HdP42FFimFCNHz+eND45zpTWRKDTSEneutRo8Tr+2iEUibfigDaRM4IRwg6K DN8PG6jBdp8ijKS8oUC6p7DT0IGu2SM9h7f6a6uUQwj5XfKXfcPnokADJwbiWK50h965WuAozJcQ SJmfqskehC/tRcXhv1JjPbrEuTpKjsIgoPHFxcUpNL6tW7eSxhfyCV+VF0BKsFWGUt/YKZkcGMnt 9Jfm+fLSfZlJ3osJrdYTrecOe07s9Rze1nLgu5ada5u3rmzavLBp3Rz36qnupZ+65n/kmjOqcepQ 5/j/wPbiy7kikFqwWp/TXzBTLlmXhas/Np/WWl+DiBXb5+OXHZ6BOC4Btl8oLy2JQVcfJk3478sZ 3dZayfsZKiE1NnTJp3HiK1y0QyaGDmycNdLz6xYjpHTFQGEkx34TjsnlxG3NlgFO6zM11rehtRXa l8LjAo4clbaP8CvgtjzK3VaDd1n/6C9f1yYFndPktbdajuOZ1r85iPc/eo6CxpeamoollQULFnDD 1NKlS7HGl5WVJW+d0lcVApqktGjRIrwqsCkpSIkj43Wc4S+noQTYyV/WYcTgFfKE1JTly/6wfXMc 8ycX+o+9Kt3NBs4HxRN6VvEAKY1o+eUnf214duUVhk5IUu0vPNDflUyli6f1Ln/h7LbWMLO1Vssx 9+op5nIUxsI0vu+++06h8Z08eZLW+EI/6952JTJS6kDB72/46GlDvITC7sXjpCZXRyWhUwj86C+c yzeR6QmX7W5//mTJ5QhdWTe6osFOIKWZbwdIqaYiBh31S3VHA8feta876CDpS37MX7paZObJ+6nF UQ83fT3Taz/Ny0SWQBB1hcaHk9CZxhfqFzOyhsTvQjj61tZWV6Ortqa2vKy8sKAoOysnNyevuKik sqKyvq4em9z5VgjxaqkkR4CR0oYNG+Srb2FnSvx2eaJ5ywoD7DR0YPPPX7VJRreT+Ns85TBJSdV7 sIcCAUN8mSMQNtZfslyq3iE5E9o8xZrah7yf3SrdwU4BUnqr5dCP/ppOiZwgeeCcj+VROB74ixdC //VljfQXzPCXrZVqD0mu5DZv5BsAAxy1akr9MLmuZw5HgQ2g8e3atUuh8WE7eWdqfAhEX1VZdSkt Xb2IoM7Jzs5xOskr3oDYhSIlPHcd9U2/AX9xriA7NYx4pPVCvH5tV8nVwD67GcOx7OWv7m2+iK2J seIovBvQ+M6fP6/Q+BD1ItYaH+ZL1VXVaWmX1CyknwOO6qo5no4oBeZ+LndtbV15eUVhYWDul5WZ XVBQWFZWXlNT29jo8nhaMWSdGky8xElp6tSp3NiImVI0pMS7B8O485N/hSUo59jnfYVk2AzCJrm6 keM6f5QmJmLKUegn0/hWr17N32em8dntdtPZwO1yZ2Zk6rOQ/tWiwiKfV2NlwUTARaoC4dTV1mWk C40FU8SqqmpMF0VqjqBMTEkJ/fFesjVvX9M4/c2w1OSa9z7WoCMYAt3SoxHQ5qhvZnqTorVHMVg6 QeODKqfPPIJX0y9lBIMudtETra9vyDDOseComuoaE+dRxcXFcAmATUk9U3I4HNH/svhL8+F7A8t2 /VsPheUlFIADITyLuuiZULNdj0Br4lH3qsn1w/7M35aGEQ83mcdRGGFNTQ3T+Pg7P2HCBKbxIeRU xBDA6C1IPiLFUlPSmtxhYjtE3FWdGxFLDUZ7kR6GKgO9L0pqjTUpSe7G1oS4pvVznaOf468ZS0Cz c47TUu6GP+Q5uU8HN7p09SDQCRwFMKHxHTlyRKHxbdu2LQKND0pQKGmNOB9TEcz3OvOhwzIPVoy4 w/zGlIupMEkZ7XmsSQn98abbmn+GBjdcQUoNIx91Lxvvid/pryz2Jikdn5z/fcaXreVsaXSEVL4X IRCCo2bh/TFxlGAAnJgMs+r8+fO5YQoRWbHGl52dLdIQwuhBHrlsmpjIyc41UVHSH0tDg9PcUcAS pd8iuwpSwjpFKPXNlO3e/rICuHxranABd8Fda31ZyR1dvdLxCavkUl0YR76Oeyl1lSGgxVGPNH1j MkcBVKbxbd68WaHxnTp1SkfjA3tAlzGRkRRVVVSY4mcb5qUBwZoya1J0XidcvCYpLVy4ED8TsCmZ QkodGtyYfyomS9DgmjbOxxYGqUVjI2rzT8tZ+aa1s9q8gbDh9EcI6CAQ5CiEiWjfiw2fk1hwFPqQ n5+v0Pjmzp3LND51bA04VSpE0tyvmM+0tMRWQLDWJrg2Z3RoaamX4G+geKyAVzFTMpeU0Jw33Q5X Sfjh8LeFJS5rcJ954nf4K4oVvZJ/DTg+vTkI+8LkmZQmBPQRaL1w1L1yciCOTew5CvZhaHw7d+5U aHywqHNtK7DXzwxDjb7UF+QX6MMS5VU4rut3IJqruTm5iu5BX2YatOmkFNDgjjAN7q/8DWGJgAa3 80oNTtGtK7/6CugAjisRoW9iCETMUXC3kzwtYo10lILGd+7cOWh8bK8EQqDza/BI1Jdcm9WOk6kt iSEDI58/l4AC+pXgKjQv3qi5CazLh209ygLYxSPvM7gdhiaz1DfULDU1wnO7af3nTrUGN45pcMek li5YAJWPmtJXFQLtHDWQ/0qG1fWat61yffFBBATFgIVKcuzYsYqK4N5GSBk0F33J3bljF46lHjJk iGax48dO9O3b98knntS8Ks8sLi6J0cPNzoqh0YwNAYuPMXLUDK3BPeJeFl6DixGkVC0hwBDAj6Z7 5aT6oTKOGvkIjJkIiKGACC6+DSMfAZVFQ1DyOhsaGuQEEio9aNAgUNDJE6fUBaZMmQruWrpkqfqS Igc0yNVJeR+iTDsbnIqGNL+ePnXmxPGT/HP2zFlDR0KjTsH1O8HhXNbgtruXfII4PPy36QoNLrNn bPAXHC8V69EIaHHUo01rZ3sdHcd+NW9dxd9kUwgK8xlNWVZkzp41GxQ0ffoMRT6+Dhgw4JZbbrFa bOpL6pzoXaPVjzgvN1/dkDoH/cQQ5H833ngjjq0/Gn9MXVgzB1Z3detGcxCrJKDBfaupwb3QtOEL bC0nDc4oqlS+cxDQ4Sg+cTKRoAQdCc6dPX/99df/5S9/UYjtzh07Ie+jRo5S5If6im0y5sIIk36o thT5YKd+/fqNHTMWnzGjx4wYMfK5fzzXp0+f22+/Iz4uTABVXpU7Ctd3bwbW4L5unPEWf3wsAV3e vZQ0OHPfC6othghoclTjpFcVLza+ur74MGIbFAYgvlr30ksvg4gO7D/IRRWJUaPeQeae3XvkmTpp 001PdXX1Os3JL4GdbrjhBnkO0jNnzkL/p06ZqsgP9bWi3HAsMn95oedIKA3u7ead3/hIg4uhJFHV sUJAzVFqdoqGoGDmDSWG6vzNmzZDkEePHsMv2W1Jv/vd7x568CGeEzZhul9BaUlp2EZZAU12io+L x6Bee+11wUry8vIFH3a7BjcPsUoUT8057rIGl3hMaqY1OEE4qVg3RSDIUe3OUYpXnX2NbAZliJ1g Q+7fv/8f/vAHbkz+as3XEO15n88TFG0Uyzfb6wl0Idi6JjstWrQYQ1j45ULBSgRNT/7aCjwRxZO6 rMF96on72V9R1E1fNeoWIWAcAclZFzY+RgQEZYidIL843gqy/OMPPzFZfuH5F6ArJZy/ICjaKGb6 3Alx5ARbv2x3ug7mffaZMGHi0KHDrr322ldfeRWTQMFKsOwo+PTcKyZydkKE6uYdpMEJIkfFehgC OOiHv+o6CaMEZZSdsLzVt0/f4cPfgiyfOX22X7/r3nj9DUG5ZsW6lp1ArYo/sNOsWbPtNrvgKGCm E3x1PMd2O8dCg5uH7UtSs1vwLipGCPQsBDBxYj5OOrzELxklKKM7+p95+plbbvkfiDOEGpK+ZctW QblmxbDfxFzwDc2dfvOb3+zetYd9MANcsnjJU089hVHAr0BwFOLsBEbqfUGqzX12VFsvQEBw4tRB UPM/bGsV3XKbmZElKJis2KqVqyHO69atf+xvj9133/2G7kXhSrM9Cgyxk3rNDjY0WPUxIsFlR3HN rhe8eDQEQiAMAn6/68vRRg8pcwkTVHFRsSGGwawJ63SYbEDFmzZtuqF7UbixUejctDCYyC5HaRVH l95//wOwE1hXZCyCVnFZBylJCPR+BOA/jC3n2JfXsm8jHMhdc97RpyxBgqqvF/UX4sL73rvvQZxh dMLeEJ4pkoBaZPpOlig9CjB3wiQQw/nl0K8iQxD3KOj9bySNkBDQReAKylo3B5SFAK2GVDwYxsUd Mpn8xh2Jx966pUuXiYizvExRoV48It2BhrxYVycabRhrdrA77dm9l3127dy9YcPGf//7/0BNjzzy qLyfOukIvDFDdp0uEAJXHwIByirMujzL2tR6/khYAMSnHzpiK3IpFicgGNrJAiJS/z355GBsDRbp P8qoA/eFhZcKEAKEQMQIBGKSxyaiuFzksVc34h7q3yi4CxiTPexb4R84ka79Zp2gQscGQkYn/QdB VwmBWCCAE3LlTGJ6GuwXu9BzghFUoh+UuRFUYvEcqU5CoPchAOsTJgbRy2+oGhB+M6agCUZaCNU9 kfzYRZ+LKTJUOSHQCxCAUShG+h2ow/SlOgXgnRC5N4Kz7RSdpK+EACEQMQLV1TUiswhDZeC+iJMX Iu6S+I1GHbcMjSJHdeqBeMeoJCFACJiCQIlwQBIR6cZkzGW2+2WoYcZOOe00gg01NMonBAgBhkB5 uCNaRHgJZSDUsYjTq/OYmptic9pmg1OnUbpECBACnYkATr9Nv5QhyEKaxeBTDUeFzuwzawuHOJhr PTM91HDnY0ItEgK9DAEoSvCLNupGDqbCtuKGLp1swMEggm6rORYsV1Nd08seKw2HEOg1CMATu6y0 XHA2kpGegSjfsV6eE8EWdvjcnDw14YjnZGZmNTVRWF0RsKkMIdCVCIBwWlpaMCeBOyLM5vDNhnMU /AQKCgphpMIhubAvdYkepw8KNjhH4MQFvyZMmboDx+qPjq4SAoRAj0YAJFNbWydoQ4MZv6qqCipt jx4ydZ4QIAR6FgKY2mGCV1tbi8leYUERYtYF5n75hdBba2pqGhsboQzSfKlnPVPqLSFACBAChAAh QAgQAoQAIUAIEAKEACFACBAChAAhQAgQAoQAIUAIEAKEACFACBAChAAhQAgQAoQAIUAIEAKEACFA COgj8P9i72SjCmVuZHN0cmVhbQplbmRvYmoKMjUgMCBvYmoKMTExNDkKZW5kb2JqCjIyIDAgb2Jq Cjw8IC9MZW5ndGggMjMgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg NTEzIC9IZWlnaHQgMTU3IC9JbnRlcnBvbGF0ZQp0cnVlIC9Db2xvclNwYWNlIDI5IDAgUiAvSW50 ZW50IC9QZXJjZXB0dWFsIC9TTWFzayAzMCAwIFIgL0JpdHNQZXJDb21wb25lbnQKOCAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHtXYd7FFX3/ieyu8lu2qaQkARIJZSEhBJF8AMEAgkJ LQkdjHQIvYsNkCK9iZ80KVLEUFUUBaWp+AkqiIKAUgQFQfT3e5cL43Bndneycydmds888+xz59w7 59555+55557b/u//6CAECAFCgBAgBAgBQoAQIAQIAUKAECAECAFCgBAgBAgBQoAQIAQIAUKAECAE CAFCgBAgBAgBQoAQIAQIAUKAECAECAFCgBAgBAgBQoAQIAQIAUKAECAECAFCgBAgBAgBQoAQIAQI AUKAECAECAFCgBAgBAgBQoAQIAQIAX9A4ObNm6tXr9byJGfPnl2zZs0q8xzLly9/8cUXFy1aZJ4i r5ozZ87s2bNNVODFixcD5GXLlpmlzCtWrHjppZcWLFhglgKjnPPmzXv55ZdXrlxpljIvXboUtWLJ kiVmKTCwfeWVV+bOnWuWArNy7ty58/79+1qstzwNKr/8EuHi4mJOono5Y8aMEXQQAoQAIUAI1BgE Ll26pGquPQj79u37119/yRNMmjTpwoULcolq+Pnnn8dzjxkzZqtJDuktmaS8W/HtxMq8cOFCs5RZ Annz4g6mOMdWDGVlNgvCKCcr8LRp08xSZqlWrB9QZIpz5pCBrMwbNmwwF8hCKGDWrFlHjhxRNfty IaOAw4cPy4U1OQwXEF7r+PHja3Ih5WX7/vvvWT08c+aMXF6TwxMmTECZd65o8+eRGFOcGxflo8Aj R46syahyZWO1Yt++fZy8xl7CC4QyrxzU40bX+qY49/dpx0C+c+dOjUWVK9gLL7yAMuungN9++61j x4745fQrL4kClJiIlRAFVAOJEAWIrbSq2ogCVGERK/SBAioqKnr16pWSklJWVoYAO8rLy48ePaql bEQBWlDSk4YogChAtf5QK8DopkQgtwJUq5yqkChAFRaBQqIAogDV6kQUQBSgrBg+tAKYkuPHjyu1 aZEQBWhBSU8aogCiANX6QxRAFKCsGD5TgFKVRglRgEagfE5GFEAUoFp5iAKIApQVQycF3L17lw07 uXr1qsZOcKIA5VsQKzE7Bfz6QfRTTYIzk63/2xzFGfNvtkU1SrUVtAq587EhA4d+fDcqK92WnW67 tCeayxqXW2dHpNexDunuQJi6g8VWWlVt8u7g13LjU8NDhqZFq5rx7nUiEburVR3VWJ3Cy0UZjZ32 5tGOa8XqA5O6JkXUjwg5X5AeUH0BeGWY0Tlo0CAMBEL4xIkTEydOVH2PnJAogANE+KXZKQAGdteC iKCgoKYNbLcP/WPqEW7e0GYPCTq+zqm0z6Ikc0aGIevS9iGcwp/3RdeOtURHWM6/4yImogDh9Vap UE4BPz+ww3g125/i7fyyZrUhBwvoNPUebi+rF4ks3lGjmC86plqCgjonhOP2gKIAzH3AbGi8td69 e7N316NHD26ymPKdQkIUoAqLQKEfUABs7PCeDvzpJvRzfXKzc3SZS7JgTJgkMSJw93DMk1nByGjb qxFy/X062SFc90I4ExIFCKyx7lTJKQAG9sO29WwWS3JY8E9dMiRzfbpTWnSINcFhO1eQLgmFBypb 18Xb75vsVGqe0jAWUZueTEJUQFFA165dmcGXKGDmzJnffvutu7cpyYkCJCgMCvgHBdz6MLphis1q CXpvWSSsLgwy/mhwAcnNskFhOKAcdktiLevVAw/dQTvnuXLv+cw/uRMFGFR75Wo5CoCNnZDpsrdD ZO6ggkTXq9mmaBoobbVOSVp4SGSwFU4hTg8cUCCgqw98RAFFAaWlpexlSRSAxZE+++wz+RtUDRMF qMIiUOgfFADzfmytMyQ4KCXR+tUmZ4zTZZMv71Vx0RtBBK+OcrmDnutqh/Lr70fXibci9yuy3IkC BNZYd6qUFMDcQa4Pg//Ugylem5eI11SeGsWZZSMun29UC3n9t0WiXPmep12tg3GZMUwYUBSANYJu 3LiBdydRANoFWnqEiQLcVXhRcr+hAJjf2SNcpjg81IJ//f6lruaAzhP9CGfe5nuZlTrhDmqZHWyx BB1e42QOKHRPyJMRBYiqrh70KCkAlpa5g3KiHN8XpOPzOz0iRO4Xkttn7eGdreqgM9dzenicbJag Tg98/lLK/ilOdAR83iGFSQKKAj7//HPMC/79999BAX/++efUqVOxqLKHtylFEQVIUBgU8CcKgCnG ECCwQO981we5/vP7nVEZda2nt3pnAeYOQmKbNWhwNz53ogCDaq9crSoFwNgydxAG4cAmH3jQHJBs sm8B9PNiwM8PhV5YAPYfnwXnCtJYLpe6ZMA11CYuTMo0oCgAbwrDQbEofatWrbD+86FDh/7++2/5 63MXJgpwh4wouT9RQOVrEfgUxxHmsCjHiPrGCGhZJMRaD6323qZg7iAMBMU4VS4vogBR1dWDHncU II0OGv/IAyMZYZ8DJXUjs5126XteVc+GJ1x+p/k58Sx2dfMEXK5pkSAlDjQK8PDuPEQRBXgAR0iU 31DAD7ui4qIt0ZGWheNc7iBujChnk99fHjmq1KHlHFniCLVbwCwjSv4ZbsRpY5dfbHQi32eL+CYA YokChNRVz0rcUQBM7vD0aLwar02A11skYCqBlhOjfaDQYbXMbfLQwkuGXQpcLc6Id9jyYkKZpF18 WEyI9Yqsg5gowPMLZbFEAVpQ0pPGPygALqA2zVyDM7fMcjnhB3Vxjckc39et0f7yLefqaeFaThAK BvzERlnWznw4wlPV/kNIFKCnHuq/Vz8FoLt2SdPaWs6JDVxjjTDsB+M/JZuvDIzOiEEyNBa+zk9F /9Sw9MemqgUUBdy+fRtLTLNxoVgvqLKy8t69e1peOlGAFpT0pPEPCphRHor/muSEv/F+NBwy+HTX 3ykMNsHI/4uVvG9HSQREAXrqof579VOA0oarSjCks3mMo2edSLj3VRNIws/ap6BaYnTQrOw4BA63 S5aiEAgoCsAGMU2aNDl37tx7773Xr18/jAjFr5aXThSgBSU9afyAAjAXAJ9YjdNsmB0gWWZ479Ez mxRnxURdSVjVAJQ83TT45kFNGogC9NRD/fdWGwVg9Yl+yc7r2jameTI2NDfa0TI2FKwht/+BRgEl JSVYFwhvGVsGs7GggwcP1rL1DFGA/r+GZw1mpwCszwM7D1/N5xv4hSCmP+tqGnRr+88UrapSAJZ3 UPbtulNCFOC5phkdW20UcLx9irv1fzgjj0u4lVAJMUhhcW5tLjagWgGFhYWsAkjzApYsWfLRRx95 rRVEAV4h0pnA7BSwYkp4SfsQaSkGuX3G6nBYpQ2xJ9bz7CBPJioMvkBeyyepdBlQd7DOWqrldg8U sKJZ7W51ImC6OSNcDZeYhtCjTiSWJLrYhR9EGlAUAMuPZUKvXLmCXV/Z20SArRrq+eUSBXjGR3+s 2SlAlAE3VA9RgP6K6lWDBwqoBlPvQxYBRQFYJhTTweD8OXjwIF4ldg3u3r2713eKBEQBWlDSk4Yo wFDjz5QTBeipohrvJQrQCJSeZD7vF3D//v09e/Ywzw9GB+Xn52OlUC0lIQrQgpKeNEQBRAGq9Ye2 jPHhw75KtwRUK0C1jmkREgVoQUlPGqIAogDV+kMUUCV77kNiogDViscJiQI4QIRfEgUQBahWKqIA H6x6lW4JBArALIAffvhBtYJpFBIFaATK52REAUQBqpWHKKBK9tyHxIFAAeigOXv2LCrYlClTuHXh Fi1apFrxOCFRAAeI8EuiAKIA1UpFFOCDVa/SLYFAAaNGjbp27RoqGPYL4LaJ7NOnD0cKqvVw0qRJ rCrSLyGgRKBi9FBTnMqSk8Q4BCqGDzPFaRwCRmv+8ccfVc21Urh27dr9+/dD7jMFjB071ujHIf2E ACFACBAC2hH47rvvlNZeVXLz5k3sFINtgnNzc7FMEPYLkA5ItLQCsLkACjZ//vzdJjmkZotJyrt7 3bp17NX3fLW8aNEgU5yswJhdaBaQ2ZB1FHt7v05mORnI8+bNMwvIFRUVKPPIkSPNUmDMlmIg79y5 0yxlZgXWsraPnBEwC7igoODkyZNfyI7OnTtroQDqC5AjaURY6gtoubVP091lpjiHjBmOqrhgwQIj ADFC56ZNm1DgyUPLq+Qr/ncTjxrhAnnfvn1GAGKETsaz06dPN0K5ETo//vhjZlG1bKFrRAF80Onz 1DBQM2fwBwwYwElUy0MUoAqLQCFRgEAw3akiCnCHjEA5UYBAMN2p8pkClArZbvJKOSchCuAAEX5J FCAcUqVCogAlJsIlRAHCIVUqFEgBSuWqEqIAVVgECokCBILpThVRgDtkBMqJAgSC6U5VVSkAewT8 8ccf7rRpkRMFaEFJTxqiAD3oabyXKEAjUHqSEQXoQU/jvVWlAHTYnTp1CsrR8cFloXFYEVEAh5vw S44Csjd1a7ymsMnmbsp+4dydPRGVvaFYGSVEAs2urLd2V9WGIkkFM3t38Ff5qSc7pGAleWWH7/mC dER9X8CvLa9M6Zvki46urOWbmMv1nO6UJhWMuoOF/9c4hYHQHYxhe5cvX8aDK+cFQELdwVyV+Fcu OQposLijxWa11w7PebsHZ4qjn66H/Y/Snn+ak4u6TJveGvrDMmNz3y3ldObs6OlIirQEWxsuzUeU 2Slgfk48nrRzQrjc/CKMXUUyIkKcwVYYai5K1OXw9GhkPSTtsX3MmXJsdGu3WpLDgi8UugiIKMDo /2MgUABG9bMFIpQUoHF2MLUCjK6HHAXAwCYNbAIrEdMuRW6H641sDmFcUX25UHg4pk0yckl6NofT HN+9gUs+sAmTm50CYGDza4fjiRbkxMtte2ndSAjfaJEgF4oNY8fz9IgQbLW89+m6cs3YCTEvJhTy ytYP5UQBRv/1AoECvvzyy2HDht26dYvtGvan7MCUMWoFGF3HtOhXUkDTytKI7DjYopSJLZnJbbis kyXEFpoaBV8QZ5zFXsLbExztsNptjV4vkDRnvtYhyGIJb1RLah34AQV82zktzm4Ls1nw7c1MMdtk FvuSyy2zEWEYf5j6zIgQuTto1oM3PjLjn9YBUYCWv4+eNIFAAcDn0KFD2CwsNTW13+NHSkoKUYCe +iPqXhUK2F2W9WaRLTwEZ9baopztPR11I60OW6OVnSWzbFyAuYPAQU0rXfPUct8pcSQ7kTs6AqRM /YACYNs3PZkEns2Jclwtzvj0mWTQAcyyageBcCJg7qCxmTFM8+cdUpB7w0i7nBSIAkT9xdzpCRAK YI9PjiB31eBfl6tSAIwtmgAwUM5mCbEdUxGoN7qFZIGNDjB3UHJFHjJK7Jvlyn3UY7n7BwXA/Jan RuHpxmXGNHba4Yc/1DZZuLVXVQh3EDodbBbLkWdcObaLDwu2WD5qW0+emCjA6P9mQFHA4cOHOTw3 b97MSVQvqS9AFRaBQncUAPMb09blmccR3bquELMPe579Vlevqpg7KNhpz1zQ3hJidbZI5G7xGwqA KcaXPwN5TpM4uQX2LYzP+NEZMWhWeL193wN3UKtaoauaJ6AAMxrV4m4hChD4L1NVFVAUoIqAFiFR gBaU9KTxQAGwwMw6pb/0H84I+3aZNqM1vDpahpUydxDsvy3SrkzvNxQAq/tiVi2A7LBaznZO44yw b5fw5xcnRfxc5J0FRmS4Rgeh9YGO4KvF9bnsiAL0/K203EsUoAUlogAtKOlJ444CMA4zNCUK4zAt Vos9QWWMqG8sgIFGGHFaf3Y7r7dHPXCVJ499QpnSbyjgWPuUcJs11GaBKS5IjOCMsG+X6E1oEGnH 5/2JDg87mt3pQRskMTQYWaumJArQ87fScm/gUACWA5o6deqgQYMwEHTgwIGYLKBxXhhgJArQUpf0 pHFHAbXy02AcMD4zoY/LG8+NEeXMclTLOugy1nKGxLsGQ+Lg3PucQlyygaCZ89sro/yDAuC0yY6y w/zvbl23TVwYMHkt97ExonLTDcNePyJE41nLboM2tCw4975cIQs3j3YgpVIOCVGAnr+VlnsDhAJg 7WH8v/76awkT2JwePXocOXJEkngIEAV4AEdIlCoFpExy9QVHNk3AsJzcXaXhmbG4lMaIKm0yPPxZ 64q1nPHdMuHeSeyfnburRKlHLvF7CmB9wZMbxMLefp2fGh1ilY8R5czy9QdpkMzr+b/81JaxofEO 25t5iZwS5SVRgJA/kW9KAoQChgwZ8uuvv3IQYeEgLBbNCVUviQJUYREoVFJA49cLrWHBwVEOyQmP UfoYlglh4/92kVvpqoYx9RidvPXnPaPlRv+mgLV5iWDVp2L/ccL/t4VL0iTKocWNrzTmkmRek/hG TjuYQpJ4CBAFCPwrVVVVIFAAdg2bNm2aKjKvvvrqhQsXVKPkQqIAORpGhDkKwDj8sIyYIEtQ+ouP dQFjUCgMVHjjOGl+lhYzzqXBECOwACd0d+nHFID1H6JCrPjsx2JBcvvcq54TII+Szc+Sx2oJw1/U Ni7sXIHWnmWiACP+Uxp1BgIFXLlyBZvFqAKCzX2++uor1Si5kChAjoYRYY4CsAQErBDMr9Iys/5Z DOxURhkh8VcK+KU4o3mMywO/7gneUfNjYTqW6EHf8I5WdbQYfP1piAKM+E9p1BkIFAAoSkpKLl68 yGFy7dq1wsJCmh3MwfKvXMopAOs/JI95AoNw0BZQWnUsIpo8Ji953JNYQUIZK1ySubADslOdR2Dq 7uAvO6ZiLYgNCvvP7DnmaiF2S8sk/eZdiwbMUF7atLZqSuoONvr/GCAUcP78+ZYtW2K99Pv37wNS mP1t27bl5eVpaQIgPbUCjK6HcgoQbsYNUmhqClC1tzVQSBRg9F8vQCgAMGLjGMwFHjt2LLqAKyoq 1q9fr30DeqIAo+shUYDRCEM/bRlTDSDTljHVAHJVt4zRXySiAP0YetZAFOAZHyGxRAFCYPSshCjA Mz5CYokCvMK4aNGiESNGjB8/3mvKGpKAKKAaXgRRQDWATBRQDSALpADsJqOlwNQK0IKSnjREAXrQ 03gvUYBGoPQkIwrQg57GewVSAO0aphFzo5MRBRiNMPQTBVQDyEQB1QBy9VMAGgvwqyxduvRDkxxY DQkFxmGS8n64ZcsWVuBOKwe0Wd/XFCcr8OTJk80C8uzZs1mZT5Y+YZaTFXjx4sVmARkDTlBmDDgx S4FXrlzJQN6/f79ZyswKrH08z5gxYzAvAHtEKg+Nu4aNGzeOZUq/hAAhQAgQAjUBgXPnzmlscZSX l9++fVs1sUZH0KRJk2rCI1MZCAFCgBAgBBgCP/74o6pVVwpHjx599+5dpRwSjRTAuoM7rRjQ/N0y U5z9ZgwGSmi8/GmS4+zZs+y1YjVXkxT5T6w3jjLPnz/fLAXeuHEjCozFUsxSYJST1YrK1U/f+aSW Kc4XpvRDmbHyjFlAhvOHgdzinV6mMG4oZPmEYSizdkeQqvFnwtWrV3uIlaIeUsDKAQbNMxWutu/z Lgow46DQM2fOSLDX8ACjgAULFtTwckrFY93B7tbLkpLVqACzTnteb/3nkRhTnC8+ooAaBaOHwkiz g5u920u4ITJI4bMTh4qiAA/IyKOIAuRoGBGWRgQRBRgBL9NJFFANJEIUYJDZl6slCpCjoRqmVoBx hlTSTK0ACQrjAtQKMA5bpjnQWgG3bt169913WeP9s88+O3XqlBaEqRWgBSU9aagVoAc9jfdSK4Ba AcqqElAUgNWhmzZtumrVqtLSUkCB3YS7deumxEQpIQpQYiJWQhQgFk9VbUQBRAHKihFQFIDu0RMn TgCE3r17MyiwoeTvv/+uhIWTeKAAbGtVd0TzhkvzVR0ygoWVpdg2C9nlvN1DqRk77UpR5Aji3qAR l+QIMgJVTqfcEXTm7aglE8K2zo5QWvJLe6IR9fYclShlYh8kx9Y6oX/3wkjVe1nse8tcsabuC0h7 /mnYkEYrOivNCyRpM1ojtvGaQtVYIUIYMZg4FVWVZcg6bVorFuVzXwD2i2cVTKIAjOg7duwYV+uU l+4oIHdniS0iBFsvReTEqxR7d5lwYeKAJsgu5pkUTnPK+Cchr5WfxuREAcqXKFxCFCAcUqVCOQXc PhSTU99msQRxpvje4Zj8liFWS9CBpeomWtVuV0l4ZW90fIzFHhJ0apOTu/HG+9HJCdZQu+V/m6PM TgEZr7SBGQlNdip3a8p8rUOQxRKaFq2M4myRnsvQlCjsD66iobIUBQtvVItFCaSAKVOmnD59Wlnx OIk7Ckid/BQKFv10Pfw2WlWgUnLhLFBZGpEVh+xAl1J2yBq4Oeo6c7b3ZEKiAO4NGnFJFGAEqpxO OQXAwH75lhPGNiHWis9+yRTPGhGGf8SUgaGSxIgAWh/IpWV28N3Djw1PHdbDtf/mwnFhLFNTtwJg PWp1TsfjJPRuLJkXBPCt60h2WkKsDZd3ksuFh42mAKycc/z4cdQx1gpA13DXrl25Kqd66Y4CIpsl hMSFNX69EKDFd8sUDoiqwqw3u9jCQ3BmvVmEBNhmMTQ1yvV2ZM4oogDV9yhWSBQgFk9VbRwFwMwu Gucy+EVPhzCTe2h1ZLDNZZnvfPyYZTaCBco62JH1gjEPrT2y+GBFJFol7fOC0RJhOZqdAuBkDokP s9isDZf9Y+0TyhrhwZOezVG1SAKFRlMAbH7r1q0XLlxYXFyMSWHNmjXTMyIoa10RWkZxhRlAICwz Fh4hWGOBaHhQlTLB5faJzKndtLIMBUC47rBm8vREAar2RKyQKEAsnqralBQAS9uppcv7umpq+NUD 0fUSrFERlu+2u5wwRp/MHRTmsHy7zZXdrQ+jM+paoyMs59/5J3ezUwDMCHMHhdWPyX3XtT03vi0t NgucD9WwW7fRFIA6dufOnb179+Krfvv27RgRpFrrlELVVkBi/2zUw8z57YFS3aFNEXbtaS7c8+NG YUybZOTIfFBRTyRx+RIFKF+icAlRgHBIlQpVKeBiZXRctMUZbun4ZDD+BRtfNqoXWMkpzB1U2NrV BoHrCbmveyFcnswPKADGhLmDXB+WlaX4vrWGBjd+owtnZIy4rAYKUNYxLRJVCrAnReBkOGS/1RVE Gd7wYW+Fb+BACbqVVUf7KBU22dod7TXUwJDY0Cabu3EJiAK0vFadaYgCdAKo5XZVCoDJ3THP5ZnH 8WyRXW6BfQ7Dnq+d+Zgxd6eKuYNeHhYaEhzUo91Df5SU2D8ogLmD4G1O6NUYICdX5HEWxofLuC71 MeLI843VTwFYIltLPVRSQP1XnwEyiX2zpCdy5iVBInegSVHaAwl9ssC52Zt4k67UgH75sPRo5GhP iFCyBlGAlteqMw1RgE4AtdzujgI+/a8TXQA4Kno5JPOrJ3B5b3TtWAucS16VwB2ElMgavdIIc+n9 gwJgcDJeaevCNyhI6WRQmiMtEvRd2iLtqVOe8pC4GigANh+dwlj8mR2NGjX6+++/vVZFJQXEdkgF OPFdM+s8l8vOqKfqQMK6BrhnzN1Vgj5cLSfG3DrqOdHFjCG4nBLuElkjO3QE4ze2PT9GlCjA6zvV n4AoQD+GXjWoUsC196LTklzjMOvXs6I3ds8iT2NBYdvP7ojSci6d6GpWDyi04xbOsHOXc0e5UqJj mpPj0m8oAAYnsmkCHrPR617GOmZv7KrFuCFN0sAmrv7TLvXhxOAMGrt0TwFlQRYBg0JXrFiB3Xy+ +eYbLDTNjrKyMh8oIGdbDwzCBDjKwxoWjFju6TBkCI+m8QRRQm1wtCNrfTGnR7oEQSBNRHYcBmuF Z8YiLB8jimREAV5ti/4ERAH6MfSqQZUCej7j6g5eNjHs+DonvDH4GvdgtMf0dmSl27ScDVIe/qm9 ji9dPikcBVgzXaXJ4E8UENXS9VmbvcGtIWIWKTY/TaNxcyRFQiGOOuW5kjWTB1zWzGJh3dByOUba 4K7IprWZ0Od5ARgCikW85bXO3T4C8jQIc62A5DFPoDz1RrXAgBz5Wbtnw4dyN3248odSDWOUUbDT HtMupckWdZbEXaw9BaZAYlyCo8FH0hhRppYogHuDRlwSBRiBKqdTSQHM/HZt89AJP2ek64O8y4P+ WeU3eZUkk/qHYv4Xehm83kUUoGq+vArRywwXR8astu5SxrR1jXJRTk9mjnfczm70mQKwfSRXwTRe chSA8VGWYKvSSqPkKD9c9O4e0Kvc2SKRm5TB3ZK7qxRT5JCL3FMEMoJEPmqLKEDjm9WTjChAD3oa 7+Uo4MR6p8NuqVvb+sv+h74aTNRq08w1LghuHK+m20OCT9Y4U5OsWIPCQxopiiiAs0taLjNeboPp q1nrPLUpmCmDGeQaAmwAJAbDs4x8poDNmzdjH2p53dO434ecAthEMDSRVJ+auWUyF3ZQjfUsBDjo VvCcpnapa46Gssch6klXZzTGqbLbiQLkb9mgMFGAQcDK1cop4NcPouGrsVmDDq54zPl/bkcUpgag a0C5eoNktL0G4Nhno/29pkQCogDPZko1FjPLvPqUsL4BpiG7PmibxMNZlDq1FabcYlUKV0dAw1ro VGWafaYA9AXExsb27Nmz/6ND4/bxcgpgE+Xc9WtjLSOUP7ZjqioIOoWgUUABt5tyDhoGlKL7AANT sZQHciEKkJsRg8JEAQYBK1crp4B+nV3dZDPKVRaCwOB8RGEFIawjpMWG60xDFKDTlHm4HTQRmVsb b1N+YLCN3OviMwVgy7x79+7J9/Ts169fVbuDMWITn+tcO0V6Itfgn3XF6CKXJAIDGP8P5cruZpYF OtkRy7raiQLkZsSgMFGAQcDK1UoUgBUYftgVhZNbokcy5iy2eigA7RFkd/OgysAhf+oOZganGiYF K40kzCx8KXB3N1jUUTl8yGcKkFctFtY4QVjeClCWtgZKiAKU71q4hChAOKRKhRIFSKa+hgf8iQJq oGVjRRJIAb6NCKqxyEgFIwpQGhPhEqIA4ZAqFRIFKDERKwmoLWMYdD/99NOjaQE/+jYvQLK0NTZA FCD2b6KqjShAFRaxQqIAsXgqtQUUBZw5c+Y///nPqFGjHk0OnuTz7OAaa/xZwYgClFVduIQoQDik SoVEAUpMxEoCigLwzX/58mU5gAcOHJBfugtTX4A7ZETJae9gUUh60EN7B1dDPwL1BVTD57HPfQGi poZVwzPqzIJaAR4soagoagWIQtKDHmoFeABHSFRAtQJGjx597tw5OW4at4yZNm0aquLgscO6vjbI FCf74+AXmyOb4njhhRdYmWfOnGmKAqOQpgMZC2SxMpsFYQnkmZP771je1hSn6WrF5MmTWZm7z3/W FMYNhWQFvnTpktyYawmfPHkyLy/v4MGDnz068vPztcwLAHdIb5YChAAhQAgQAv86Al999ZUWsy9P 07dvX6wIgY0jpQN7R2qhAOwyz553okkO6e1MGDbYFGfF8GGszPhSNQnGEyWQqcDGIUAgG4ct04wJ swzk8ePHG52XKP2swBcuXJCbdy3hY8eOccm2bdvGSVQvWXfw4cOHVWNroHDRokVAae5zfW50rW+K 81Rpc/ZaMWqrBuKpWiTqC1CFRayQ1Yp9+/aJVWucthdffBFlnj59unFZiNUs9QVgU12xmo3TxvzG PjiCfC4SUYDRPEIU4HPl1H6jeUcEEQVof8tVTRngFLBx40YtiBEFEAUo6wm1ApSYCJdQK0A4pJzC QKOAK1eubJEdrVq10tIXQBRAFMD9cXBJFKDERLiEKEA4pJzCgKKAt99+u7y8fMeOHZgjjN+ioiLs I8wBonpJFEAUoKwYRAFKTIRLiAKEQ8opDCgK6NixIxaLvnnzJuoVcLh+/Tq2kuQAUb0kCiAKUFYM ogAlJsIlRAHCIeUUBhQFYFAoHh9rxOHPy3AYPnz42bNnWdjDr9kpYG1eYueEcOksSoyoqB+zolnt HwrTjbbtP3XJKKkb2SUx4ptOaVxe5wvSuyZF9Et2Xi3OoO5gD9VPVBR1B4tC0oMeGhHkARxRUT6P CBo8ePBff/31xx9/9OjRgxXmlVde0TLU0+wUMOPBdsPOYGuc3YYzKsRqs7j25MmMDPmiYypnmYVf LnqwB1D72uGcZjARyrDpySTIiQJE/Ts86CEK8ACOqCiiAFFIetDjMwWsXr36yy+/hObnnntu//79 t27dKigouH37toe8WJR/UAAztswOXyuuPys7Dha4OCmCs8xGXBY+sPavNomTlM9tEo/ch6ZFMwlR gNdKqD8BUYB+DL1qIArwCpH+BD5TgJQ1zD4mCA8ZMuTzzz+XhB4C/kcBzPA2iLRHBFtBB5JlNihw tnNagsPmsFqOPJOMLD5sW89utWQ77VeKMliORAEeqp+oKKIAUUh60EMU4AEcUVH6KaCqJfFXCkgL D4EvyCCzz6nd9lQdOJ9yohzoAkiPCAmzWT5rnyKlIQqoap30IT1RgA+gVfUWooCqIuZDeoEUgIXj tBTAPyhgwxOJ6HjFiS5adAGMyIiGTYajXrLDPgS+7Zx2WtHP604P3D5w/tQLC8bvkqaP5UsUoKUe 6kxDFKATQC23EwVoQUlnGj0UgM2C0f/70aOjQ4cOgTA1jHUHw/Byx/D0h654d0bbq/xcQVojp11j n/Llogx8/6MMnRL4rmGiAJ1/Ci23EwVoQUlnGqIAnQBqud1nCjhy5EibNm2wWOjyRwfWjg4cCuhQ O7w8NQpn/xQnxufAOQ9rPCglCu0Cr6beQ4LZ2XFJocEft3M5+T2fn7RLRncAMsWoJG6MKFGAlpqv Mw1RgE4AtdxOFKAFJZ1pfKaALl26YDqYPPddu3bJL92F/cMRJB8RBFsNdxC+xmGQlzV7zCfDzPhX +akLc+O1nK/lxtd22EKslnGZMVfd9ywju8yIECQDByFT8JGcL4gC3NU9gXKiAIFgulNFFOAOGYFy nylAmg5Q1cL4JQXAAr/Tqg6scfc6kXJrzMLoqx2ZEa3xrGV3NSh613P+4r5B0aeeE2leynKNC0Ub BOE5sjGiRAFVrZM+pCcK8AG0qt5CFFBVxHxI7zMFYMOC48ePy3PE5Gj5pbuwv1LA9qdcFDA4LUpJ Adolq5snYK7Z1pauGV7uzpXNEpDRM/Fh1x+kOdMpLdbuGiN6+JH7iCjAXd0TKCcKEAimO1VEAe6Q ESivKgVg8P/OBweWCG3UqNFbb73FLvGL9eICpy+AcwRhME/zGAcsM5aPcGe6vcoxwjMjIuTQI0uu mv5o+5RwmzXe8Zj/f/0TicgaXcnoI8ZdRAEC/yDuVBEFuENGoJwoQCCY7lRVlQKwOujatWtR/5VH gCwWzUYEwRWfFxOKs0WMI8tpt1lcPbOqXiBVS64qxFigTx/M9lKNhRAWHlPAkBPmBXBpsDoQCsAm CBMFuKvtAuWo/1h1DRsFCtRptCpaJs5ohANhmTjUfCwNpIrk+++/ryrnhGZ3BGHwf8NIu3Q2dtrb xIXBOb+5ZRLzzHDGWeAlxgsh30kNYpU6L3ZJb1UrFA2BQ22TiQK4KmfEJVGAEahyOqkVwAFixGVV WwH6y2B2ClCa35omIQrQX0u9aiAK8AqR/gREAfox9KrBZwo4ffp0ZWXlqVOnWBZbt27F3gFes0MC ogCjKYMoQEs91JmGKEAngFpuJwrQgpLOND5TAHYNS01NPXjwICvA0aNHsWSolsIQBRAFKOsJbRmj xES4hPoChEPKKQyEvgDpkbE06MWLF6VLBHr37o0lo+US1TBRAFGAsmIQBSgxES4hChAOKacwoCig pKSEe/xZs2Z9+umnnFB5SRRAFKCsFUQBSkyES4gChEPKKQwoCigrK+Mef+bMmWwTGU7OXRIFEAVw VQKXRAFKTIRLiAKEQ8opDCgKmDt37r59+yQEsHFMfn7+/fv3JYm7AFEAUYCybhAFKDERLiEKEA4p pzCgKODevXtYJqhPnz47duyAVc/JycHaoRwgqpeMAlAbZ5vkYH8c/L48uL8pzgnDhrAyjx071iQY z5ZApgIbhwCBbBy2TLOE8EsvvWR0XqL0szJfunRJ1Vx7FmI5iK+//vrNN988cODA77//7jmxFDtn zhwJKAoQAoQAIUAI/OsI/PLLL5KJNjpw48aNDz744D3zHCC49evX79mzxzxFfg9DdjFTw0QFBrzr 1q0D1CYq84YNG7BAuokKjIW8sKiXiQoMVzNqBX5NVGZMGIFjxEQFRlGx8puW5d2MpgbSTwgQAoQA IUAIEAKEACFACBAChAAhQAgQAoQAIUAIEAKEACFACBAChAAhQAgQAoQAIUAIEAKEACFACBAChAAh QAgQAoQAIUAIEAKEACFACBAChAAhQAgQAoSARgSwK02vXr2ys7OvX7+u8RaWDNNpf/vtN3e3XL16 dePGjZg8+OuvvyrTYFH9adOmYXWdvn37Dho06KeffpKn2b59+4ABAxCLX0zlk0f5Fv7+++99u5Hu IgQIAUIgEBAYOXLktWvXqvSkb7zxBubVqt6CGc0FBQWggG3btnXr1g2TsrlkWFd/9+7dnJBdgjuw 9pq7/dlVb/EqxE4uXtNQAkKAECAE/BgBfLFjQbO7d++qPqMHCoBNPnv2rPKuNWvWqFIAFswfM2aM PP3LL7988uRJuQRf+O4WZPjkk0+WLl0qTywPe3gKrNuJB8SKzfL0LIxmjlJIEkKAECAEAgEB9l0N p8r06dOLioqaNWumXNNSlQLOnz8/atSogQMHYiVzGO39+/dLcGHPxLy8vLZt28K64ujXr5/kR0J6 btVNtC+ggd0LC4/0KSkp2G/lwa29Dh8+zKJACuXl5e3bt2/evDmLwq6+Uo4engJL9C9cuLB79+54 wJ49e2LfFmn3RpZdcnIyU4hfD/wi5UUBQoAQIAT8BoElS5ZgyUTpcWB7tVAA2gvFxcXylBUVFceO HZP0uGsFwI0jpZECo0ePlsII+NAK4J4CxlzqiYBbSe5rQotj2LBh8uyQWH5JYUKAECAEAgcBuHEK CwuXL19+9OhRyWxyj69sBWCtXbj05cnwnY8vfEnijgKU2ynilqFDh0o3IuADBZw7d87dU2CvrjOP H7D5aDVIORIFSFBQgBAgBAIQgTt37mBDK3xI4xN98uTJys0NlRQwf/58UAaHVWlpqSRxRwFwyCg7 c7neAR8oAPnKn2LSpEnsKZBXVlYWnD/ccfnyZamoRAESFBQgBAiBQEPg0KFD8keG20S+4y2LUlIA toBEN678xlOnTo0fP16SuKOA1atXY3sRKRkCGBe0ePFiucQHCuCeAluGSU8B0rl586ZcPxcmCuAA oUtCgBAIHASaNm0qdbniqdEQgNeEe3wlBSBB//79sfkLS/ntt9927tz5559/lm5ET6vUyfvHH39s 2bKFeZnwcd6uXbu1a9eylNhBBjcigXQjAj5QgIenOHHiBFhA2vbrypUrEydOlDuCMCgUfiRWALjF 9u7dKy8MhQkBQoAQ8GMEli1bhiH68P/Akz916lT5SE4Mzod5xIGBNPhURuC5556ThmuiRxgf8OjJ hRBOJJhWDiUIQRO4ESOC0Hcg3YgBOdhOF3dhGNK8efOk8Tm4HVO9kJ5lx3KUjDP4BTPF0JVQUlKC KByrVq2SckRfhvwpsL+eFIXAd999B88VcgS54PeLL76QxyILPAWicMAlRTPF5OBQmBAgBAgBQoAQ IAQIAUKAECAECAFCgBAgBAgBQoAQIAQIAUKAECAECAFCgBAgBAiBQEPg/wG38gM8CmVuZHN0cmVh bQplbmRvYmoKMjMgMCBvYmoKMTE3MDkKZW5kb2JqCjI3IDAgb2JqCjw8IC9MZW5ndGggMjggMCBS IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzk0IC9IZWlnaHQgMTM3IC9D b2xvclNwYWNlCi9EZXZpY2VHcmF5IC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50 IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB7dAxAQAAAMKg/qlnB2+IQGHAgAED BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MPANDDE0E3UKZW5kc3RyZWFtCmVuZG9iagoyOCAwIG9iagoyNTkKZW5kb2JqCjMwIDAgb2JqCjw8 IC9MZW5ndGggMzEgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTEz IC9IZWlnaHQgMTU3IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9JbnRlcnBvbGF0ZSB0cnVlIC9C aXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB7dAxAQAA AMKg/qlnBn+IQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYOAYGhjR0uwplbmRzdHJlYW0KZW5kb2JqCjMxIDAgb2JqCjM3NQpl bmRvYmoKMzIgMCBvYmoKPDwgL0xlbmd0aCAzMyAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VS R0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBrZE9SwNBEIbfi9EoCRgkaAqRBUUs 7uSMRUy0yQeYiEWICmp3uZyJkI/jciH6A+xstBBtFPUviDYWlmKhhSAIwd8gBAIi4Zy9Q1IFGwd2 59l3Zz9mBnCZiq6X3ADKFdPILsfZ5tY28zThhQ8jiGJMUWt6LJNZpZAe1n6DwLdeJX7XTvrrfemg cXEzsHI2ETXFHod+ZW9eq6mAMEiCmq+pZeISsajqhkl8Siw1TJ3zI3HAoA8SNzkXHP7knLPZxVMJ GOvZBOAKEvtzDs9wLji8wFktKnmKSRGLzh+IgKFUkoXliBSzV/84lUt1ytM2Xi2fVtlYI++nMY4U kmAIQ0YEEmKmtkf5Aomqvm/sFoomi1FlNZaolvW6qRkiS1fUWZGF5DmZx/GecQ+0snYvhNGXrla9 BCKTQN9hV8udAHf3QPCpq02dA8OLwO2zrhiKcx/NQtv917q2Mx+y4wVfHOj/sKzWNOA5BjpHlvV9 ZVmda3qfevZQ+gEkd2ngCmVuZHN0cmVhbQplbmRvYmoKMzMgMCBvYmoKMzgwCmVuZG9iagoyOSAw IG9iagpbIC9JQ0NCYXNlZCAzMiAwIFIgXQplbmRvYmoKMzQgMCBvYmoKPDwgL0xlbmd0aCAzNSAw IFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3Ry ZWFtCngBrZE9SwNBEIbfi9EoCRgkaAqRBUUs7uSMRUy0yQeYiEWICmp3uZyJkI/jciH6A+xstBBt FPUviDYWlmKhhSAIwd8gBAIi4Zy9Q1IFGwd259l3Zz9mBnCZiq6X3ADKFdPILsfZ5tY28zThhQ8j iGJMUWt6LJNZpZAe1n6DwLdeJX7XTvrrfemgcXEzsHI2ETXFHod+ZW9eq6mAMEiCmq+pZeISsajq hkl8Siw1TJ3zI3HAoA8SNzkXHP7knLPZxVMJGOvZBOAKEvtzDs9wLji8wFktKnmKSRGLzh+IgKFU koXliBSzV/84lUt1ytM2Xi2fVtlYI++nMY4UkmAIQ0YEEmKmtkf5Aomqvm/sFoomi1FlNZaolvW6 qRkiS1fUWZGF5DmZx/GecQ+0snYvhNGXrla9BCKTQN9hV8udAHf3QPCpq02dA8OLwO2zrhiKcx/N Qtv917q2Mx+y4wVfHOj/sKzWNOA5BjpHlvV9ZVmda3qfevZQ+gEkd2ngCmVuZHN0cmVhbQplbmRv YmoKMzUgMCBvYmoKMzgwCmVuZG9iagoyNiAwIG9iagpbIC9JQ0NCYXNlZCAzNCAwIFIgXQplbmRv YmoKMzcgMCBvYmoKPDwgL0xlbmd0aCAzOCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3Ry ZWFtCngBzVtrk93EEf2uXzHcNaB1vFq9dUXCo/BSBS4qBfYCAdYJ1NZSmNqN40eSX5T/mZ7HOT3S SHe1Sz7EruIKSdM93X36OfIr87V5ZUpTFqX8qZu67faVGaqxGOWP6drSvL4y35m/m9PHbypz+cZU 7u+bS1nUNeG1G67IeO+a9wLxphzGZt+Ya7LTO7+aXx5aDrXlILuRv28us1fCyl5Wpm2Kym2oHdti HNrRXN6YT89N07sX5Kfti67qe3Mi1+c35vT8vJZ157+YH03+znF2UhatyXdHD45lN3L17rHxt96z NyqTvx8eXOTuidz5o71Tm3x0NzqTH7V+UZbrS093pNSB5CN30Zj8o0BBXy/w6NRddFleugthU+lb 4aHJsbnA2OTYPnn1brkINDgZZZd4xZJ7bs6fmM/OnY1TVVZDUfdNE1RZe7W7n5Oqz7wSG6/E/D/H 5vy3u5MaBFbV2DVGKXaB4jv3o1hbkoLUiKIa+uI4WPGhU4sYkRdUFIxCswYDZvmf7GIxmxriw0Bu i5EHb1GLpMxBTMmAMExDyOAG+RCfwcAx1ObYMYvYocAz7GQExhJ2rDPMsCN3RH8Lkotc1p3kIeUg 4lXmrwBMKh7C8kawQKZ0oCglw81iNdW8g8dS4k+s4kUKXQ0XxmL7ZMknBhHHhZdm3MMnMgkvM59I Agt0rFpS3pBlhGN+HuAVb8brkRJQjwDp/N1MoxGVz9VENFgzbBzxHd3fI7cvgTsJ6TNVMgHJtyAz ufk9ZupqSofvcLU+QzSdRiyrkAgQkP8IlqSG4DJnwUWVsBqjcyJKcIwezq0AOjsoDSztmggrGeKn YmUYgRWbim7Disr7YQgQlIUegT3QcH9IvOhobV9MkU0vaWslrtdlMTigL0T3bC1RrBLU6D6j24m2 JPVK4j2UNVbpaowH3ZCNNNIzbVKJhBixTvTNgkiWw+iKC6Ca5OCB+KWNyCeQz5ildx8j65AKX1ZO H8CkABqx/SDgAg8WFvNdclDCEGrH3EEFLLxN4uDGlxMQfgA3Ihmwoqo/sV44Cb1MxbpBOGaW0yD6 8JmlIDklpQTX5wbVk2R5pj7qPVQq04W6cYY1V+425vwycttu7Iuqripzsoy6/NG7oitUQShSNzDT yNALsqt6WOVg1QEGKoRGnKZf9WxWbOojwDQszKjOC1U/LeJfjkxEtYOcFtFcpHT4NvFlbeTTnNoN O9J1RBK4MATiXaKankgx8IqSO3FOJlV1All9R7YT2gKs5+aBb30Z2yI9xAX89iBGwUkNa7fFB/GS sK2JehXmdwFGu2+Kpi7j+lvxQZ1TkZTuU6c/KQ6giR3kFF09z9KuYg2jztEkGUwcra+khu/GtISX RP3oxCr9kBNsaVtUSMoGI9M+iHMKS8uZeo66TxVujXcnoWOsWokdFdrPgX1Odh9p+rboxrGPKYpQ mW9oFZdMOZF9XPdxwLioBrP8CXLRRPIopA1tKIxrLYxtsVMNvjG3PyeilN5WFestI2YHC0FzhUOm HLpi9J09+IQyfKGRnE8QDkmS+QmC8tGqY8ZIwXTu9BV3PrBExulAWs9KF/X5rPanWwGEQGfawzCM uMrPR9IkJRLlvJCNIezuzkKNDCZ3tbZz4jYTJ460VXXFvhtbNX8wS8C9HbvsjsUH8iP3X+G96Fq3 Aqxu66Lsekmai2bJhNE3Qb7f4wwm/zbp2w9nEYpzJ5Q1Uqf31YI4iBcSnxbixVxNCXqbrinarrHx Irhj0q0Cq2ISBnqFCQPG0Q7ojBB3hHso4qLRCkIPO93vkhgbsU4Suz5jt7N7z9pCsDNHbryjWAbF VmSMqqxkflcPfsyVaMxGrsYGWZlz+nYIJpCEnZrgFmrSC7ZDaVE6panBQ+WkSwc9xVMezUaxt3q3 RyFByWEU/KKDoC2pUS6haVhdzHdjwiAs3hU4Y08MM7xQ6b5E7RW5o1hTijGs1nfJOzZsEq8ojiwM QY2uCdEpINCoTBSy0T004VjPnSBU7xZEIxOyB8XD8Z9mEGD7NicBdtT3BBG5I2Zp6I83wN3kLIrJ Klzo3A+S2kVLsSsAXIqzaHqgAT9yl6Qbp6o4lMNWY6YexNShfxSjjFrFqrjqnM1UJyHMji9lbJS0 1qofkp6x1zE/ox6nRpCBnvJnIHuzCu0Q0WXP2pbAqsy6dgcaabhACHr/Ir84fig7YCDiAOoWO9Vd V5Rt1R2IROnoD6KqwiLnFQki56UzBqNn2mNFTswwA8r4pTKTG8J77tyJsXR/9KQjQn/isSh+CCXu iAIgUtDR+IQX4VEko5DZ7Dza/Kjlu24sOt/8hEQRvAmWfyCKodGlfpodgNVtG/unzhbEP2dzi21n N6sE0+le2OlC4a09KceQq3S1zp7tV1MlD8BomsRWGnJgYeIRBwNRSHUBQn2dZDXbrrl0Ik+oI1Tx lRw91t2wV/3PygmJxBsMmtKVptJVFFDTgYIOacU7VSangeFEhxeEtLrQuitSP6jDDs58pqF4yTtu V2JTysFLWcmx3kxauIX43X2U2MhJ9jA00qbM6CrYVCFaKDAHbIZFcoraiKO3Mk9UzjNHF5ttkCil K9OIekzJqkAp7hXmiLoqNIEhyXatTGNRwah7Nmspo9Dvm9PopIoY5IVyZ4RneF7TOIcwtVjSViiJ w9gKBdMX1caW3lvknpwSHSgkEG2gyKnn2a8FbOaRUTjqSLxIb1Phd5HWMP+Onv7F2kNmcKAA1t8H 3eurX9g7kqP1zg/2MnJFVg+JGhOA1ftKJi6uk4Q2gxNOPqWwLGVz3oDC22NEBD+Rg2q3Gx/Ffeng az9/aiN9XVXbd+TzB48+3bqsb1BltXwounM6FU14QmTWCzMr5vzwak1MP8qYziNb8dSybNw8UmJs pt+O5E+sGg95qW0xbzlrC26/MRuvEfy92XiN7oZsvGfxrPjCBArY1CdwiODZ0WEuIw3TC30CZADx GXoXyqAgTwgCggr3Uchkzly1XdFUpXwTtBr7P7LFo+DRRiZpID62wwn5X7t3+RGURS60vonUhSTr lHuZK5BzAIGGJVWYBlcN0/p0pk57XG8DjISrVJ28w+KdURVzRiVM+0ysez95m0FCRiPBdy4vsrfo 9z5e1OzbohnrlO6SHjlYCpIhJMWqilJjaBAAZGJyyQiAJ9MfeUGfUclFSlT+mQ1fkwTD9cxO0apg 39hk9zNLX9XFftxHxc+sBBHo3ccsvXSvTTvc+xyzCiO5xG9cBk9cBS4AK7CM4AWBH9k3zASwiMZg zPlMnNzlKa1feWthVbAKDO5jhstKWhyTCbaMVkRXBW+LOso45vnsttPXNTiAJMCELdoaYg3LVBAv lHJS43zvUOrnMUt440lN1fEjqdWzoJBHF5LelrOgVQ7JWVAAy0JLuuUsaMonOnPSrLg8Tc9/VM+5 i0BpuqqqorF/fJ+P/2kGGebb9CFxtdYBtYY9SVwZE5c5mLjuooiwPx1XuG+cBtvFLCtCSkKF1MWF Xn/pQCmF3Upt6pEuHwj5ZKYLn8Mt9RZp8aufH0CVIzle6LK/6qX7uDaAOrNfPGOuoqBuNoHaflis oObJ7iYMrHH4X4N6wucOoBZb/i1kKmajSTYMYYYxCSEojWDMb2kuhlGy/KfAjFl1KbSFgl/8zQdr 8GREW224sKs0Bj9d+BJDt8UtTwojj1dseZ5n9OPw6Hvxh4jLoG3SCTWiOpli0AU5Q2rbEpbFQ6Ne RH3YZlU9E4zbG7sxFACbIDxhEUGrLHo5orVf98esoq/wXZQAqyX3C5STACSfPFnS6TlziIUTwpNQ l02+BFNHn8gQzeRbm8yXt++1v2H7oaJR3cu0Vk58bQULE0zLmzsnksnurUOi71lOJF1b7Mu6FsEO pRLZnS9gpek51ANN9Cv/QmMxkK5ZUj6v66uyjVRxYKD5f5xKmKB+Sj4Y+CZENPZfK94cFY/B8eX8 kEXst4GK9U4txE6/unp9efWPt//8+dq8fiGat5/ktIN8TWhPCGTCKg5RjkXf9K0ZuqKWJ631ptMv bhpz9lL+DcjYCQ7+LanvN3P69Or657cv/nX1+OX1y9cvbq7evn5xacm6KPD4WciPzx4LHwexctgP bVm1jplHHW9VcuQ92E9Bqkom4XVXWbb2nVam4vtWsGdJDGPVt2NnbuQf7ez7sZZ5eXz7mrfbVvqW vfwzoYhExpu/mmciytf/BVqD8LMKZW5kc3RyZWFtCmVuZG9iagozOCAwIG9iagozMTUxCmVuZG9i agozNiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMzkgMCBS IC9Db250ZW50cyAzNyAwIFIgL01lZGlhQm94ClswIDAgNzIwIDU0MF0gPj4KZW5kb2JqCjM5IDAg b2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9D b2xvclNwYWNlIDw8IC9DczEgNyAwIFIKL0NzMiA4IDAgUiA+PiAvRm9udCA8PCAvVFQzIDE5IDAg UiAvVFQ1IDIxIDAgUiAvVFQyIDEwIDAgUiAvVFQ3IDQxIDAgUiA+PgovWE9iamVjdCA8PCAvSW0z IDQyIDAgUiA+PiA+PgplbmRvYmoKNDIgMCBvYmoKPDwgL0xlbmd0aCA0MyAwIFIgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA5MTIgL0hlaWdodCAxMzIgL0ludGVycG9sYXRl CnRydWUgL0NvbG9yU3BhY2UgNyAwIFIgL1NNYXNrIDQ0IDAgUiAvQml0c1BlckNvbXBvbmVudCA4 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4Ae3QAQ0AAADCoPdPbQ8HESgMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwICBt4EBgwsAAQplbmRzdHJlYW0KZW5kb2JqCjQzIDAg b2JqCjE1OTgKZW5kb2JqCjQ0IDAgb2JqCjw8IC9MZW5ndGggNDUgMCBSIC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggOTEyIC9IZWlnaHQgMTMyIC9Db2xvclNwYWNlCi9EZXZp Y2VHcmF5IC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngB7dtrb+JWFEbhBF/BxsbGl2Pj9P//zO6DkhnIBFVb6mu10jpf pjN071aPtMYYk7c3DgIIIIAAAggggAAC/xuBdw4CCOwo8PKvhh3/H/hPIYDAg8CfUcYXD3YSDgII 7CcQo7P2vhUZa0ySNM04CCCwo0CaJkks8inIeG1Ms7woSg4CCOwoUBR5libPQcaLY5oXx1NVcxBA YEeB6nQs829BWo9pXlbn5tJxEEBgR4FLe66O9yB/v2O1y2NWVk13Hcdp5CCAwD4C0zSNQ9/WFuTD O9Z4eSxOTT/Oy7osS+AggMAOAhbbuoTp2lZlZreQXxfI++Wx7sZw27bttsYmOQggoBZY78EtU39+ ukBaj/mxuc63j4+PzXIMYeYggIBWIIRl3Sy5WxjaU/HwhvX+drUdgr24rWG2W8iBgwACWgH7sCbE ILdlvFRFmvx6Bhl7rC7Dsn1stzBe+667cBBAQCvQ2eenswW5rVNX2w3ktx7HxW4ew9i3TV1XHAQQ 0ArU57YbZruHfNFjuN3s1rKpT2VZcBBAQCtQHu0R4xhWq+6n6+MQ1nUe7FlIkWUpBwEEtAKZfQWn vcZnjD/3ONsL1+ZUZPELrhwEEJAK2FdUj+feLpDL+OP1cV6+noTEHwDhIICAUiB+KS4+9V/Cqx6/ v/D1hQF+RQCBf1vg87HGTI//tiz7EPAL0KPfjAkEVAL0qJJlLwJ+AXr0mzGBgEqAHlWy7EXAL0CP fjMmEFAJ0KNKlr0I+AXo0W/GBAIqAXpUybIXAb8APfrNmEBAJUCPKln2IuAXoEe/GRMIqAToUSXL XgT8AvToN2MCAZUAPapk2YuAX4Ae/WZMIKASoEeVLHsR8AvQo9+MCQRUAvSokmUvAn4BevSbMYGA SoAeVbLsRcAvQI9+MyYQUAnQo0qWvQj4BejRb8YEAioBelTJshcBvwA9+s2YQEAlQI8qWfYi4Beg R78ZEwioBOhRJcteBPwC9Og3YwIBlQA9qmTZi4BfgB79ZkwgoBKgR5UsexHwC9Cj34wJBFQC9KiS ZS8CfgF69JsxgYBKgB5VsuxFwC9Aj34zJhBQCdCjSpa9CPgF6NFvxgQCKgF6VMmyFwG/AD36zZhA QCVAjypZ9iLgF6BHvxkTCKgE6FEly14E/AL06DdjAgGVAD2qZNmLgF+AHv1mTCCgEqBHlSx7EfAL 0KPfjAkEVAL0qJJlLwJ+AXr0mzGBgEqAHlWy7EXAL0CPfjMmEFAJ0KNKlr0I+AXo0W/GBAIqAXpU ybIXAb8APfrNmEBAJUCPKln2IuAXoEe/GRMIqAToUSXLXgT8AvToN2MCAZUAPapk2YuAX4Ae/WZM IKASoEeVLHsR8AvQo9+MCQRUAvSokmUvAn4BevSbMYGASoAeVbLsRcAvQI9+MyYQUAnQo0qWvQj4 BejRb8YEAioBelTJshcBvwA9+s2YQEAlQI8qWfYi4BegR78ZEwioBOhRJcteBPwC9Og3YwIBlQA9 qmTZi4BfgB79ZkwgoBKgR5UsexHwC9Cj34wJBFQC9KiSZS8CfgF69JsxgYBKgB5VsuxFwC9Aj34z JhBQCdCjSpa9CPgF6NFvxgQCKgF6VMmyFwG/wD/3uEz9+Zinh8M7BwEEtAKHJCvrbgxLGLu6zJL3 98+mv0Jdl+nanIosSQ4cBBDQCiRpfjz3Y1iXn3sM6zoPbX0ssizlIICAViDLy6q5TsuLHsdwuy1T 11Snsiw4CCCgFSiP1dnerq6xuh/er47LbVvD0LXnuq44CCCgFajPTXedV6vuRY/bx7bO47W7XFoO AghoBS5dP8xrjO7PHvNTO4TtL3stzOPAQQABucA4BcvRmhsvlX2K+vD5apKfmut8+4hBLiGEmYMA AlqBEJaY48cWhrYqUnvI+Ot5hz0JsVtLu4Hcttu6LhwEENAL2L2jBWdP/Zv41P93j/cHkE0/WbAx RrtAchBAQCxgqa3rGqZrGz9ePXxdHt/e3g9JXtZtP4zT/YwcBBAQC3y2NvSX+unyaD2+x+8KVOf2 0nV933EQQGAPgRhb28Sv4DxeHq3HgwVpzyfr+sxBAIHdBOxZ/6nMY46/367GC6QFmeVFWZZHDgII 7CRgwRV5ln7L8R6kFZlmHAQQ2FUgtRqfr47xsYf9aEn8NnvCQQCBPQWsOovv89Hjwy/aH/ZiOwII vBJ4yPDpH1/9+/w5AghoBJ4C5DcIIIAAAggggAACCPynBf4GlLwdEAplbmRzdHJlYW0KZW5kb2Jq CjQ1IDAgb2JqCjE2NzQKZW5kb2JqCjQ3IDAgb2JqCjw8IC9MZW5ndGggNDggMCBSIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AbVaaXPdthX9zl+BPNkx5VgUQRJcHC+t7c7UnU6nidUl id3WVZSJM1JcL21/Uf9nD5Z7Lii89xSpjfRBFADe9eAuAN+ZL8w705q2afHT9d3gZmsmuzQLfowb WvP+zPzJ/GiOn36w5vSDseH3wylecn1adsE3Ko6dcywR79tp6efenJOdjnxvvrvrOXSeA6TB74fT 6h1Y+Udrhr6xQaBhGZplGhZzemGenJh+DAvwx/ZzM7bzYI7wz8mFOT456fDiyXfmG1N/clgdtc1g 6s3BrUOIg6fbhyYOfeoHrKnvpImXdZjByIZrnCzGpKeEySYM9aYeZO5hInBPZkaZeeBn8qWfxZmq 5pIDz/aVOfmN+dVJcEmpuZ2abuz7pHk3BM3Dn6NuqKLKfVS5/s+hOfkhkhK/iVXh7itoV0p7bgaA YoBVMRZZuMTikxWLleP2saii45RFN0XoZSzUcV+WxsyckpyqHqNTxBdLMLQzdbK4qbcsTouq+pH3 U2dqwYiuPQp0MEV5hIOuOSASbh1WAWM6dze8D9hQIOFFwSYRlUteh5G+ojw5DD16QU/QuyGHUvjP k1qD7AJZQlOqoBuKwQed5NASKMGspPAsgZ9i6Fs0y+bXaR8If7/mVXUTzI8tAsI8uQw0k7EVdrv3 tED/SqQbheFoXTN145goVho/AmRKkhPsH0JSPy97NiZ2TUYLsYhOFCtwgI6nUxmt0poqg68sEjJ0 Dh/oi6+Sc4K9Y4ypfNiXODANosoI/GuMsXMMv/7PUdc1vVc4hQGNNJXYZk+kuZrD2PStndysjFJI u1682cGoUlWyeLPWCABK6WKOnkDE5gOsnKLzT7JcSKedOTk1tos27Iybm352k0fY2MzelElDZXz/ 8+4QUtQP7j+MD8p2lRQKLVNUVS1t2zau7zo1Z/KbMnsE4jGIHKQA8Xj7diy4pRSUcettM7qhX3Fb w/63gRki6PPETAPE1/qIpBKzsg69ii/m0CetVoh+LVR/JyN8UEp/kceqtomqqf+W7Y1ojT+kEVgj Dkiolp3GfTVJGGRWOODcHwmY/Z4r0nnvgA7sBbVlgknKijvCESukvh/yPawRzu/hpZmcAk/3MEPm nj28g8P2aiEx+t9qBlFlX82wZqSVw1+TF8Vp6ntJhwy3DJh8kMVZvv+zp4eIIPRuSzLVtUJY68ZQ 1aU9RozoC3lmRMWQUd+yhuIW1aSIlJUkqUhlemadKVi+H8CNOnjLywn2SeCqZvGjUl0j+ehLTkwm PK+R+WLhlhXIFZOX5OFuuSIPr3uCg9whyV4EAI1NCz5LeOIGV73EGOntSotELhaNMxdJ7M3FkLEE DK38lNk3EuBeHiaJ/u7/ImnoGuFC0veC5YGvnW0GY3w32Tx8aIzPSoAbNRs7OGSZuSwBbhQ+CkZF ctxZAmj4YCdBGx6gNPYwQdWrliaCxcFE0KbsJwmqBIs8pZ0Gt8JD3KnETh5EGDGEn4hS1VxPCrLX ZU0WzbZsaUrHyEblOCUFPAe4hEy1gRC2lbbINCa7Hlm0pS4uTXk3OCBBPYsFLGSZonCMkaP4Z0iC aw4/YxIURkUS7Ec2zruSIGOEOC7CpqolQmwkmVzGE0IFsSaL6T06+4FvdAFaLqVfuSRDb5FzDiRj ilgiBaOuwoNrKYXOiYAbwpEN6pbVJC7ciGYxBtVJEmcRXVhxt6kUJMO5r7bXgAVKiwDlXNdMy7ho xbau3n3Wlq5rSxvX2djGFXSzGJ4IXq8E1NC6i8ONY3iFE8U9qhQtx+4YjsrAnwMggouJ9hS1hUbC iG1bj3OByfqThnXXprmC/iYCCDFBFGOZYO7bhLEMWtg7GtMg8q4jtR0iV9ppzjP6y9ZlnWby9v4W oiBc4GexjcNxoDfGundWY7x8qTsC7dnepllwKjbncYO1OJFwbt1P+vItHfLgGOXxL1L5A4vGCnvj B2INHQew99Wge7BVqGmx/ZZlKJtnsV929nktujhecThoKsyXmvIaLadg9np0F/hl9Ke0W91So8G/ Ed3JNc65aSddNNk3ojvbprV9SVcPJ+jVXyY3P4l1b1WHLYVzhBib8WBxVBLKMgFA3I+YeXpTAHSu b3BUUxpUHLU1/jKu2zm24AlYW6uPG8XfqzlkB/brouCqY7R1/C0YlccUO6uPGH+xRWH+WC8zCUv2 1BCx8Y/bdmkhQTImKPqLKn+0pnZdsPGXOcSltdYalx75igSlo4/Etqof+/iLf71o+LOKvbr1CiEK M9hpbpYeV06Xz1aUsyrL6mijxVUIY6ueQucepnsE2o9VleQVViokzSVZ4ZXyUtYjqEzKTVKTzpEv 81m2JrXMXLOlpdhHm8Uge9MzuCIE8CJZFuyl436WgoOAqLp0eTYt6WDbutXBdsCQW2PI10ZyxwXn +bsEYHhaboNJ0XIsrnPm3xj/Id6LPn2RepAXT1HFxMvUaZ6G1sZruojaVoYGxJelawecDlvcYwy9 BzfeWpwbphFpEOFxQNExtebCdGPrpgn1iA6ec9B2bdt3i79U5euoBGTwe/Nidfw4jOAXGOM20YGx pF6WOzADCol41bdwK8dzWZgBMRa64OGATwETyLvRS3iAd+IatMDRo/CPhwvmYkeC2MzViNbh0i3B LibwsBYctkYG6oBLIK/DKjKg+MsP3VfqwEfRq59t7m2OmuOXh7dub+74Q2Sv2a3bzeaw+kkcC6vN LSouQGKb7Sx2RrgOpDlCwoINaKg+2QDbOWiO2jWTg0dd6r2keSGH7ebGAWa5INQa2kW/oE0KAh2L f+hLRo9MErzjs+wlLdLZFNxlr/IT7se8m1DPhjt7rVPFOf6mYKGYgicKpVC7UrzKX+NHpBVkEFYu Aa2wP+nfEbyWJtptvDl5zyLe5gC+HJXoRhTc3jDDTsP4klcNcz+lAxomxl44hyMUV3eTeFJ67Xiy 1VWKPr5N28V7Ff+9RLAmdocNGYffTcDtiY7PqDgEgBDKUqCSLYmmJzmhxhXyylHS0YMqgpVCUTdO ybbhgFCJPqpqvvIQS7IdlYI1viuRWOIrc7hiRzxMB57qChytxW1B1qUvRLp4jwQDlZaXJYyKtAfp kpOsFdM9bAJGQbdAOmoKSAdnkdzaMOieRP5SJhTcl1R7Iqyz7eHXAARXmRXHcGHrpxBdbv01wlEx huRC7XXr05WaS3YgO4urpEMQXUZ2pYmIayQjrQPb8e/P3p+e/ePjP1+fm/dvkOV7dIl2cDHB45QA fTEqUPTe/Yhfg0+p/J2o86ofP78YzLO3SMXHX56dv/745l9nT9+ev33/5uLs4/s3p5EeEjh+pETw n+vAxvnQAn74wKl3UzMP7ewJ+xUDSt9uRDMF09lxnvANwwU+mJrs4A+QdPCcg/0w9sOEmiF7veJg rBkKdbtpbKDOZXUXVCWzRV809c0047rgFN87PL9w/xd1F+g6mK4dmwXnGaIwvhLolxHdOZS3Q9f5 Tv3C9INFpYQjg2z0nKNBO5BJSicSUek4HNX+4r+Ovn5eCmVuZHN0cmVhbQplbmRvYmoKNDggMCBv YmoKMjYzMgplbmRvYmoKNDYgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVz b3VyY2VzIDQ5IDAgUiAvQ29udGVudHMgNDcgMCBSIC9NZWRpYUJveApbMCAwIDcyMCA1NDBdID4+ CmVuZG9iago0OSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VD IC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSCi9DczIgOCAwIFIgPj4gL0ZvbnQg PDwgL1RUOSA1MSAwIFIgL1RUMyAxOSAwIFIgL1RUNSAyMSAwIFIgL1RUMiAxMCAwIFIgL1RUNwo0 MSAwIFIgPj4gL1hPYmplY3QgPDwgL0ltNCA1MiAwIFIgL0ltNSA1NCAwIFIgPj4gPj4KZW5kb2Jq CjUyIDAgb2JqCjw8IC9MZW5ndGggNTMgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggMTA3NiAvSGVpZ2h0IDEwOCAvSW50ZXJwb2xhdGUKdHJ1ZSAvQ29sb3JTcGFjZSA3 IDAgUiAvU01hc2sgNTYgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNv ZGUKPj4Kc3RyZWFtCngB7dAxAQAAAMKg9U9tCF+IQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED BgwYMGDAgAEDBgy8AwNSGwABCmVuZHN0cmVhbQplbmRvYmoKNTMgMCBvYmoKMTU0NAplbmRvYmoK NTQgMCBvYmoKPDwgL0xlbmd0aCA1NSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCA4NDUgL0hlaWdodCAxMDggL0ludGVycG9sYXRlCnRydWUgL0NvbG9yU3BhY2UgNyAw IFIgL1NNYXNrIDU4IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl Cj4+CnN0cmVhbQp4Ae3QgQAAAADDoPlTX+EAhVBhwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwIABAwYMGDBgwIABA+/AAC2wAAEKZW5kc3RyZWFtCmVuZG9iago1NSAwIG9i agoxMjE4CmVuZG9iago1NiAwIG9iago8PCAvTGVuZ3RoIDU3IDAgUiAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEwNzYgL0hlaWdodCAxMDggL0NvbG9yU3BhY2UKL0Rldmlj ZUdyYXkgL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PgpzdHJlYW0KeAHt3MluG0sMhWFLPc+Deqjqwe//mGHJjiLdyMDlLgB/LgLDEhf8 GBx0tVr++KAQQAABBBBAAAEEEEAAgX9L4EIhgAACfwu8D6qv910pBBBA4FngKxr+ig35tbwrohBA AIH/Ckg2SEK8pkZIjCiOkyRJKQQQQOCPgKRCHEchNZ5DQyIjipM0ywsKAQQQeBXIszSR1HgJjRAZ aV5WdUMhgAACrwJ1Vebpa2hcLhIZRdX2w0ghgAACrwJD31bFPTQepxO5zEjzuhunZV3XhUIAAQR+ C4RMmMaultC4Pu5oyN2MOKvacXGblPfeUQgggIBzkgbbtm9+uXVVlkSPOxpyNEnyZpj9fp7Hfk8N eSuFAALmBSQxDokFPw/N84VGOJoU7W3dz8/z2LyTixEKAQQQWFfnt0NyYV9vbZn9OZzI0SQtu8mF PNncMk/TjUIAAQSmaZY7FhIah5vkcPKSGVnVT/6QyFinceg7CgEEEOg6+Sh1WiU05HDSV3nyuAl6 vwXaz26Xq4xpaJuqKikEEECgqpp2mORKY3c/ZIa8MMgHsXlGIYAAApk8GV61g1xOvM8MSRM5mXRV kYXHyykEEDAvkCRZUXVyOpETyJuzibzgl1FujiaRfB+FQgAB8wJRlGSlPLnl5XLibWZ4t4z3D2HD 914pBBCwLnCVj1SLRp729D9mxjzU+dPDXo+Hy/kBAQQMCtwf96zlhgaZYXD7jIyAXoDM0JvRgYBl ATLD8vaZHQG9AJmhN6MDAcsCZIbl7TM7AnoBMkNvRgcClgXIDMvbZ3YE9AJkht6MDgQsC5AZlrfP 7AjoBcgMvRkdCFgWIDMsb5/ZEdALkBl6MzoQsCxAZljePrMjoBcgM/RmdCBgWYDMsLx9ZkdAL0Bm 6M3oQMCyAJlhefvMjoBegMzQm9GBgGUBMsPy9pkdAb0AmaE3owMBywJkhuXtMzsCegEyQ29GBwKW BcgMy9tndgT0AmSG3owOBCwLkBmWt8/sCOgFyAy9GR0IWBYgMyxvn9kR0AuQGXozOhCwLEBmWN4+ syOgFyAz9GZ0IGBZgMywvH1mR0AvQGbozehAwLIAmWF5+8yOgF6AzNCb0YGAZQEyw/L2mR0BvQCZ oTejAwHLAmSG5e0zOwJ6ATJDb0YHApYFyAzL22d2BPQCZIbejA4ELAuQGZa3z+wI6AXIDL0ZHQhY FiAzLG+f2RHQC5AZejM6ELAsQGZY3j6zI6AXIDP0ZnQgYFmAzLC8fWZHQC9AZujN6EDAsgCZYXn7 zI6AXoDM0JvRgYBlATLD8vaZHQG9AJmhN6MDAcsCZIbl7TM7AnoBMkNvRgcClgXIDMvbZ3YE9AJk ht6MDgQsC5AZlrfP7AjoBcgMvRkdCFgWIDMsb5/ZEdALkBl6MzoQsCxAZljePrMjoBcgM/RmdCBg WYDMsLx9ZkdAL0Bm6M3oQMCywP/MjDS+Xi8UAgggcL3GaV4Ps/Pr1Fd5cr18J+jlGmdVP63eL2NT kBn8V0EAgbtAyIyiGRf/Q2a4zS+3tszSOI4oBBBAII7TrGxvi9/c2+sMt4UX6iJP04RCAAEE0jQv 6n76ioa/zyaz23c5nHR1VRQ5hQACCBRFVXdyNNl3N7+5nzH745BXxr5tmppCAAEEmqbtR7maOA7/ LjMmd5wSGst0GygEEEAgCNymxe3neXi5n5HFz5+bpGV3k8w4z92v60whgAACQWBd/X5+fh5u6sqX zIjSoh2XTTLj2DfvKAQQQCAI+G0/zs9zX8c2PIbxeD7jEiX5/e6o3NHYt81TCCCAQBDYtl3uZuzh E9U8iS6/M+NDHupKy2aYVhfeRb4igAAC3wIhEvw6D/LkllxmPGWGXGiUbX+bvs9wE4UAAgj8zoPb 0MrTGdHjaPLxcQkXGnlZt10vNYR/KAQQQOArDbq2LvNwN+NxmfEVGkmWl1XFR9IIIIDAi0BVlXmW xM+XGfJVNbnSiOIkzbKMZ98QQACBZ4EsS0NivFxmhMy4XCU1pHjGHgEEEHgSCLFwT4ynk8n9K/H3 1LhK8WU+BBBA4CEQQuH+J3Xe/PEh/mQAAggg8IPAm8R4/OqHFn6NAAIWBR7JwA8IIIAAAggggAAC CCCAwD8l8As7uRu4CmVuZHN0cmVhbQplbmRvYmoKNTcgMCBvYmoKMTU5MAplbmRvYmoKNTggMCBv YmoKPDwgL0xlbmd0aCA1OSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCA4NDUgL0hlaWdodCAxMDggL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0ludGVycG9sYXRlIHRy dWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHt 28tym0AQQFFLgHgIMEjAMAPK/39meizbiu0WpnqZur1K2pksTtUNApGXFwYBBBBAAAEEEEDgvxc4 MAggsF/g2b8I+/8G/iQCCHwK/AxKfnQ8HhMGAQT2C0gzUs63nCSlJEnTjEEAgf0CaZokktOXmmJL aXbKCwYBBPYL5Kcs/VaTtJRmeVmd67phEEBgn0Bdn6syz9J/r03xupQVVd12PYMAAvsFurauiuzf a1NsKa+a7jpOMuM0MgggsC0gncRYrl1T5bGm99um+CHvVDb94HwIwfuZQQCB3wT8Wy1u6Jvy9Pig dzgkaX5+vbqwrusSc2IQQOAXgRAW6SW46+s5T5OPJ3oSU1bU/eTX201ikiuTYxBAYEtgnr3EJMH4 qa/lrukzJrllKpuLC7fbbfFuGgcGAQS2BcbJ+UWKCe7SlI+bpnjLVLVXJ1etxU/Dpe8YBBDYFugv w+RjMu7aVvGm6f4E4iOmsEhL8nSiqc8MAghsCcgXst1ValrkpkmNKcSW6qoscgYBBLYEirKqY03h SUw+zGPfVvENCQYBBLYE5N27qu3HOXj1yjR52XfyZEJeNmIQQGBLQF5lLeTS5Lx8mlM+5k3ySPz+ zDy+Vc4ggMBzAXkx/O272Xl+FtN0kcger0Z8ebGc3yCAwKeAvIInj8AvcgUipk8UfoGARYCYLGqc QUARICYFhRUCFgFisqhxBgFFgJgUFFYIWASIyaLGGQQUAWJSUFghYBEgJosaZxBQBIhJQWGFgEWA mCxqnEFAESAmBYUVAhYBYrKocQYBRYCYFBRWCFgEiMmixhkEFAFiUlBYIWARICaLGmcQUASISUFh hYBFgJgsapxBQBEgJgWFFQIWAWKyqHEGAUWAmBQUVghYBIjJosYZBBQBYlJQWCFgESAmixpnEFAE iElBYYWARYCYLGqcQUARICYFhRUCFgFisqhxBgFFgJgUFFYIWASIyaLGGQQUAWJSUFghYBEgJosa ZxBQBIhJQWGFgEWAmCxqnEFAESAmBYUVAhYBYrKocQYBRYCYFBRWCFgEiMmixhkEFAFiUlBYIWAR ICaLGmcQUASISUFhhYBFgJgsapxBQBEgJgWFFQIWAWKyqHEGAUWAmBQUVghYBIjJosYZBBQBYlJQ WCFgESAmixpnEFAEiElBYYWARYCYLGqcQUARICYFhRUCFgFisqhxBgFFgJgUFFYIWASIyaLGGQQU AWJSUFghYBEgJosaZxBQBIhJQWGFgEWAmCxqnEFAESAmBYUVAhYBYrKocQYBRYCYFBRWCFgEiMmi xhkEFAFiUlBYIWARICaLGmcQUASISUFhhYBF4PeY3PX1nKfJ8cAggMCWwDFJ8/Pr1c3zdG2rU3o8 3JM8HNNT1V4n793Q1UUmNTEIILAlkKRZUXeD816Nyfkwj31b5acsZRBAYEsgO+VV249z8E67Mrmw SGVdU5VFziCAwJZAUVZNJ5/mlvAkpvWtprapzwwCCGwJ1E371tL6JKZlvUlNw6XvGAQQ2BboL4Nc l27r8v3KlGRlc3Hh9kdqctM4DgwCCGwJjOPkpKU/t+AuTZnJE/D3p3mHRJ5M9KNfb7fbEuZ5dgwC CGwJSCVhkV5WP/byBDw5PGK6PzMP67ouwTMIIPC7QFikF7llevtu9iOml/hFU9n08aF5CF6aYxBA 4DeBGIt8Nds35eM72xeJKcny+KRvGCe5Y2IQQGCHgMQyxO+S8sctk8R0r6luu65nEEBgr0DXtfW9 pfdbJnkKITWlWV5U55pBAIH9AueqyDN5Me/R0v3alMobEgWDAAL7BeK7d/HF8C8vnsdPekmaZgwC COwXSNPkR0vx2nSIL8kmDAII7BWIyUg5X65Lb7/Z+t8b/AwBBJ4I/Ezpvnnyx1kjgIAm8Cwk9ggg gAACCCCAAAL/kcBfAfiP2QplbmRzdHJlYW0KZW5kb2JqCjU5IDAgb2JqCjE0NDQKZW5kb2JqCjYx IDAgb2JqCjw8IC9MZW5ndGggNjIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4 AbVa224URxB9n6/o7AIZG7ye2+7sJJAgsBXCJRLSSnkwKCArBIiNRPxN/E8+KdWXc6pnune9TgiW mPFMd11Onaqu7vFn89J8NpWpFpX8a9qmW65r09fDYpB/ZtlV5q/fza/mkzl+fFWb8ytTu5+rc5m0 bMOwS84o+OyCz4LwtuqHdt2aC6rTJ+/Nu0OrobEaxBr5uTovPosqe1ubrl3UzqBuGBZ93w3m/NI8 2piucwPkUleL1dA3vTmSXzaX5nizaWTi5p05M+XxQXFULZamvHdg5KY15Q8HYlVjylv22pnyVene 1KZ87G5k7ICb+3aMzFm5B11RPgiTMPkQc1XK90E+hcw7PztWdebMiqxYYgyn3bFyxKrZHMo4RpVV blpT0JvePRAfeDMy8bXZPDWnGxf6FGFBsis8vM3awesuR/K/x7X1uJZfDszmo5cDciB0wqk9BQ+L ddX0bWdU/jLI/2Ykf0SN/eU3vWd2JF95ceaBM+XC3UiMRacQRAhByijMd/FuGv9TiCHKDPbMj9XQ ZMJ3MqHTt+F31fwcCt4cFME6a6YE+J0dK9dfMEInqQ23YTiVB0OLUgdNrVBBnA4K4hqJs/klNNVJ P1vDhNq42jc53vUyz2V22/eC+/llIWmd553GbZq9xJ03M5+0ijvfqIlzVgN9Btc4fD77zqNXaDIx OzmKMKqkmd5ymJdelHzAG4qkTUTdyskiNwA5qY7I2NpnrLscNc2iteBO8vbvUV65op7J2363eKkS VV31Nm/HWq7L3kKWDq0OYy2hqqsTIntp16VEi+dCIbU9FL+othO5FF0yFnFGKg9YITgZVV/DiJrO EGEy9cxPfRoWJes230FjKo/kwRDIBV10CkbMIJ9zdczNitreqZSulYUukfRSzSCjiai+S3NDE5VV NpTOeO1TCT+FGkln32jRLHLZUle1lKO29kXG9g7KssocyS/TpiFwpZC1N1QTw5V/BtgehvqrlulC TwQCOkVUHhG/WQadcfiNVovQgNhlPfQzc9VLbRmJqGFRklCWFRGqN2r1s1C7Vfgfrw4Cvkw3fXmE tccbLoABHdCV9EjhSjKS8b8V1jr6w6Gpq2myMknD9Bh8DREMtM5sZ00zrNzSlGFNMWXN+4AdGwka 8ltAkEwFpB/si2VsINjBuQCU4GzlCLlGkCiEQGroyAJGCIgQ7Ic2DNJh6CS69jH4qq8SMfAk6Z1p 3jxtd2jxE6tAujIYBa9D1dOiMYvM9Q2R2gQhrCdUrWnBhIImnc4Kk+sRQxemo3dYBtFwwk7awbm+ YzvkNmet2ZxfW7PeihJpw/rl4dNt4rniNsv/tW3Ii//abYPT8m/aBmQjyaBFQaOJgvgiEB1pSJrL 0FA7f3RFULDHGISbY7kXI73nfOfroi8BOU6Mg5b4W6/rxXKo1tomJXWJqlIzHjnTJc3AzLh+vy7S veI11jRLsabqI2uwthbYkCvEBIOriL6bwo/fFXWUF4BN53hDv9Olx4uL6y6rCOTxAWkCjfkNeSAD BkEMreGNOkm/iYQPQ2zXnJFhDadf4Bst5BvesLmlCoqxduQI59ulRnbPdk+2z8JH/SPZflsIHLJt a8AshRpOYzZQZapN3Ykh08aKghVzmkgJ+i7EQ7oYesSowZKMyO0hKlgSKJCR4Q1f0SLayDHpSqw1 i/M5Wj3CvoVjgj/RjlYHz2cnttjJCQic1Xe6XtJKruuuE1Um+dOf0VYvpZSQw23uRgtbJ+cAVV+1 tidPqtifr8rDW3esdqm0FiG52GDIRRxX9Zn9bKQ+nG7pBmDZDbJTXslmNrMPUP/HBwZWWzE5RQtK quW2tEEl9Edcsn0Fqe+5hUSKMPKZrV7CPh4FqmXhjAJBK8o5go4o4kpa6WSOZVT13YPQhGuDRRZl RlM4tHEwjmO4X6XFFIN0zzA4kXvfmiVgJdgATtYITk23CEFRUaIDBfS4wgvmNt2BGgXKP9GzYchk GFPyTI9gPXnqtbRlUnPtOZjLDznOvr7xuyvoSRLcEzPkIobbjDgcbovX9R5tRb1q8oydHO60fgUv b3iElBef9oIh3687QpJvA7kjpLyW9AgpqSo88k+4qPEljzgmLAK6CckQ91myQ2ICUA4ZcoheUrXO kMYz8CltY0jK6DDAVnF/UgwOZ4zbXs5NOS7nEnVbUa+HPVvR26pZrFeNVHSwKYnAxYsdhd3CsbO0 sx91DEiqe7teL9oq7o6TKswYAC5fjOKGgoHLdBYEVwedpKtodC61L57RElVJwevXwzYQ3f4cn2My y59i1G45zJgEB195bprqWfFfPdWzWvZI9Q82LHKawezLLKbaVc3ilOpcekpjxIRj2DVhd72jztuQ xOUL2a2C1AhQUt9h9QkCtcHEwsVjHVYt2oW5M66QqVlbNbkuy7f0ETIUwK2MCAhd/S43cBB27Paf 0ccs1R/ySZpxesLem+jvTDp7QiNrIaezz4oc0J6XMHF83DZoEdIPGGHRFoJnP8Fk+slUx7g1sAaL wwgUrkQ5DW7sCrooABZ9bAI7aAAR5A1fURuB0JjyXRzvgDOsBWlhDtn21gW7jb6QMANphY1/Fut6 KWf4tpq7L4ZhX+r/BKC2lyM53m9XYXVBAfuy1+euerfsbjFUdbuSPy+IVdysUblGRb3Gl+pYhX70 3KdLYfwYtgCq7AjACN1zIEhpT4G2g/I0j5UHH5PmRncJzFJKIANIn2CjcJ11UDOfAnZ9fRkxxucN CDjVIi2NbuiJDq3jkyjftxzmbKO04qpnQ0RfHXvuEkC+jO/adgF/tn2YL2Ax/zUmCCS9INiAY1e5 598OxDzI5l/bSv6t1rpVGOVel7R1sIvFjKUa/piSRQS48tM96hWk0DtWDJJExTHuTyw73bcD3whD vA69/BQIfIqQXCSMnlgn8E+tIgdj9Pyicwa5uU8Hll2jzyoIFdyFwYxlKJ0pz+I2dat5tJMfM6GI b9IDJq0ZGajZNJOR3NTzewoTDN4p/CcW7OicKe2B/Jz/tqd2lJUDaWyp3Tohf1Lml4v0T8XoFOAn oeCBhy1aV4kfnSVTUU1SbsTJ6wmqyDBLMvBTmQ4aAxmTASbTB7CDXrLyggxkGxslOqMGchDkYbYO gWq4EJuF0TM6Q+RoT8oGMpCW5XgXvshBhTVIS9nLfwDXYHCwCmVuZHN0cmVhbQplbmRvYmoKNjIg MCBvYmoKMjM3NAplbmRvYmoKNjAgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAv UmVzb3VyY2VzIDYzIDAgUiAvQ29udGVudHMgNjEgMCBSIC9NZWRpYUJveApbMCAwIDcyMCA1NDBd ID4+CmVuZG9iago2MyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFj ZSA8PCAvQ3MxIDcgMCBSIC9DczIgOCAwIFIgPj4gL0ZvbnQgPDwKL1RUMyAxOSAwIFIgL1RUNSAy MSAwIFIgL1RUMiAxMCAwIFIgPj4gPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9N ZWRpYUJveCBbMCAwIDcyMCA1NDBdIC9Db3VudCA1IC9LaWRzIFsgMiAwIFIgMTUgMCBSIDM2IDAg Ugo0NiAwIFIgNjAgMCBSIF0gPj4KZW5kb2JqCjY0IDAgb2JqCjw8IC9UeXBlIC9DYXRhbG9nIC9Q YWdlcyAzIDAgUiAvVmVyc2lvbiAvMS40ID4+CmVuZG9iago0MSAwIG9iago8PCAvVHlwZSAvRm9u dCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9LRkZOWUMrQ2FsaWJyaS1JdGFsaWMgL0Zv bnREZXNjcmlwdG9yCjY1IDAgUiAvVG9Vbmljb2RlIDY2IDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0 Q2hhciA2NyAvV2lkdGhzIFsgNDIwIDM4OCA1MDcKMjI2IDU3OSA1NDQgNTE0IDIyOSA1MTQgMzg5 IDUyMiAzMDMgNDk4IDUwNyAzMDMgNTU3IDc5MSA0NzggNTEzIDMzNSAyNTAgNDk4CjYyMyA1NDMg NDg3IDUxNCA0NDYgMzQzIDUxNCA0OTggNDk4IDUxNyAzMDcgMzA1IDMwNyBdID4+CmVuZG9iago2 NiAwIG9iago8PCAvTGVuZ3RoIDY3IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAFdk8uK2zAUhvd+Ci2ni8GK5DgTMIYyZSCLXmjaB7AlOTU0tlGcRd6+3zlJp9DFb/h0dC6/clK+ Hj4dpnE15bc8h2NazTBOMafLfM0hmT6dxqnYOBPHsD5Iz8K5W4qS5OPtsqbzYRpm0zSFMeV3Ui5r vpmnj3Hu0wc5+5pjyuN0Mk8/X496crwuy+90TtNqbNG2JqaBcp+75Ut3TqbU1OdDJD6ut2ey/t34 cVuSYSIyNveRwhzTZelCyt10SkVjbdu8vbVFmuJ/oUdCP4RfXS4aV7VctnvDJ/Jxlk9nNfNxx7t7 j354FHebthFZW4WWEg5EJA+CHkTWeie4BWu9vBHcgcjaHU0a9wIia2sttQcR0a1EOxCBXrAHEX0V A4jo+yLRCCKwF0wgYgztO4CI6J4oZyr6RkHGF4HS1zO+CBRHnjcSMUYliCMRpWRmjzmRc/dczHk1 WMlUHnMia7fyGh5zIlBLYc6rwVqG9JgT0agWxJwI1FzMeTVY7ySKOREG1QLmvBqMEq1YABGN5J0r /IpAeZwKryIMSiOeU0WUUuzM359a1kfW/H0twzVnNlL/C7qssoTjlN7/Lsu8SAHVHwfr40IKZW5k c3RyZWFtCmVuZG9iago2NyAwIG9iago0NTIKZW5kb2JqCjY1IDAgb2JqCjw8IC9UeXBlIC9Gb250 RGVzY3JpcHRvciAvRm9udE5hbWUgL0tGRk5ZQytDYWxpYnJpLUl0YWxpYyAvRmxhZ3MgNjggL0Zv bnRCQm94ClstNzI1IC0yNzYgMTI1OSAxMDE0XSAvSXRhbGljQW5nbGUgLTUgL0FzY2VudCA5NTIg L0Rlc2NlbnQgLTI2OSAvQ2FwSGVpZ2h0CjYzMyAvU3RlbVYgMCAvWEhlaWdodCA0NjcgL0F2Z1dp ZHRoIDUyMSAvTWF4V2lkdGggMTMyOCAvRm9udEZpbGUyIDY4IDAgUiA+PgplbmRvYmoKNjggMCBv YmoKPDwgL0xlbmd0aCA2OSAwIFIgL0xlbmd0aDEgMTc3NjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCngB1XwJeFvFtf/MXXSle3W162qztViWN9mW9yWx45t4SWzHsR1biZ3Vzp6QPXFC gEBKoVCHpSVAW1qWshRoaFEUFgcoBDC0pU1ZmtK+tgEKLX2v1G2h5b0QsP0/c0dy7LR9D16/7/99 T9bc38yZ5Z45M3PmzBkle3cPrUcSOoRYVLJ22+BOpH1CDoBVa/ftDdK0bQVCvGPDzo3baNoF5Qz2 jVsPbKDp0EmEwpdtWj+4jqbRJ4BVm4BA07gCMHvTtr0X03TwKsAvbd2xNpUf2gvptm2DF6fej34N 6eD2wW3rafnmOsC8nbvXp/JxH0JWhuYhtBHVcOn4eTQhhCGVjYPIgn6DBMQAxtAAcD6GFyEOckk+ f8fIscx9f1htrvsQefRAQOjJ9y77McHvX/PA4XMV4z8SHfoMqG2AQD9QT7hj/JcIiXedqzgnQT7C t6XyKGQfM7AjzCVJ/5zACHOAwsVJvwSp/RT2Jf2zIDVEYS8tsifpnw3E3Ul/HcAuCjsp7Ej664G4 ncI2WmErhYuSmXMhbwuFzcnMeZDalMxsBNhIYQOF9RTWUVhLK6yhFQYpDNC81RRWJTOaoZWVFFZQ WE5hGYV+Cn0UllJYQiFOoZfCYgrdFLoodFJYlMxoghd10NRCCu0U2ii0UlhAYT6FFgrNFJqSvlZo pTHpawOYR2EuBTXpawdiA4U5Sd9CSNVTqKMwm8IsCj0UammbNRSqaWNVFCopVNA2yymU0XqlFEoo xCgUUyiijRXS6lFar4Dm5VPIo5BLS+ZQiNAK2RTCtF4WLRmiEKQQoOCnkJn0LoLeZlDwJb2dkPJS 8FBw0zwXBYUSnRQcFOw0z0bBSokWmjJTMFGiTMFIQaIgUjAkPV3wdn3S0w0gUNBR4ClwtAhLUwwF TAFpgCcpTFAY1yrgT2jqYwrnKHxE4SyF/6Lwn0l3T2AEf0jhb0l3L6T+SuEDCu9T+Ast8mcKf6LE MQp/pPAehT/QIv9B4d8p/J7mvUvhdxR+S+EdWuRtCr+hxLcovEnhDQpnkq4lwOCvKfwq6VoKqV9S +DdK/AWFn1Pi6xR+RuE0hZ/SIq/R1Ks09QqFlynxJxROUfgxhR9ReImW/CGFH1Di9ym8SOEFCqNJ BTQffj6pNAA8R+HZpLIcUicpPEPhaQrfo/AUhScpPEHrnaAwQomPU3iMwqMUHqFwnEKSwjFaL0F5 eZimvkvhO7TIQxSOUvg2hQcpPEDr3U8rfIsS76NwL4V7KNxN4ZsU7qJwJ4U7ks410OnbKXwj6VwL qa8nnesAbks61wN8LencAPBVCl+hcCuFWyjcTOEIhZuSzkGo8GXa5pdomzfSNm+gcD1t+jpa4TCF YVryi7TItUlnHFq5hjb2BdrY1RSuoiU/T1u5klb/HIVDFK6gcDmFgxQuo3AphUuSTtg78AH6hotp 0/sp7KNvGKK87KWwh75vN62+i8JOCjsobKewjcJWChfRrmyh79tMYVPSWQVv30hhQ9JxJaTWJx1k Ha1LOq4AWJt0EBGsocTBpEOF1AAlrqbEVUnH5UBcmXR8HmBF0nE1wPKkHfZivCxp9wP0U+hL2kVI LaWwJGmH3R7Hk3bY5nEvhR4Ki5N22OZxd9IO2zzuotCZtBFhLUraWgA6KCykxHYKbZTYSmEBhflJ G+ybuIUWaabEJgqNSet8yJuXtBJ1MTdp7QNQk9Z+gIakdRnAHAr1SStZm3UUZlOYRaE2aY1CXk3S WghQnbTWAlRRqExaCbsV9EXlFMqSViLWUgolSSsReYxCMeWliEIhZSlKWSqgkE9ZyqOQS5nIoRCh kE0hTCtk0ZIhylKQMhGg7/NTyKQlMyj4aHUvBQ8FNy3poqBQBp0UHJRPO32RjYKV1rNQMFMwUZBp ESNNSUnLShCBmLSsAjAkLasB9BQECjoKPC3J0ZIsJTIUMAWkTkL9SWhxAnAcwicQPoZwDmgfwSvO Qvy/IPwnhA8h/M28JvBXCB+Y1wbeN68L/AXCnyH8CcIY0P8I4T3I+wOk/wPCv0P4PYR3gf47CL+F +DuAb0P4DZR7C9JvQngDwhkIv4bwKwi/NG0M/JtpU+AXEH4O4XUIPwPaacCfQngNwquQfgXwZQg/ gXAKwo8h/AjCSxB+COEH8kWB78tbAy/KBYEXAEflwsDzQHsO4s/K2wLq5El5S+AZeXPgaXlT4HuQ 85RcGngSwhMQThh3BUaMuwOPG/cEHjPuDTwK4REIxyGdBDwGZRIQHobwXQjfgfAQhKMQvg3hQeny wAPSJYH7pQOBbwHeJ10WuFc6GLgH6HdD+CaEuyDcCeEOCLdD+AaEr0O4TSoKfA3CV8X7A18R7wvc CngLhJshHIFwk7gp8GXxysCXxK8HbhRvD9wg3hm4HujXQbiajQSuYmsCn8c1gSvjh+KfO3oofkX8 YPzyowfj0kEsHfQdbD946cGjB391ULXpxMvil8QvPXpJ/EB8f/zio/vjTzBfRBuYa9W6+L6jQ3Fu yDG0d4j92xA+OoSbhnDJEGbQkGUoOMQa98Z3x/cc3R1Hu7t2H9qd2M3NTux+azeDdmNxZPLk8d0+ fwugetlu2dKyK74jvvPojvj2DdviW4DBzTUb45uOboxvqFkXX390XXxtzZr4YM1AfHXNyviqoyvj K2qWxZcfXRbvr+mLL4XyS2p64/GjvfGemu744qPd8c6aRfFFQO+oaY8vPNoeb6tZEG89uiA+v6Yl 3gydRxmWjGAGayEMLMoATpAPzyvxqb63fH/xcciX8J30sTazN+Bl8s0e3NjpwTs8V3hu9LBm98tu RnXnF7aYXS+73nT92cXZVVd+cQtSLEpQYZ2kb0pHL+nbcaWhiWJppdbXDiWc02J2YrMz4GSaA06M rG9Z/2Jlnc9YXrYwZjM2myfNjGqG4mZTwMSQx6SJVU2l1S1mOSAz5DEps4oqA4Uwn2vs6m0xSwGJ iTdInRKjSg2NLapUVNKCWBzEcPi0ALB6wg12BlpGMDquYB6P4C8d6+2JRttHhMnF7Ql91/IEvjYR 6SFPtXtZQndtAsWXLe87hvEN/ccw09ibcLR3L6Ppq6+/Hs3LbE9k9vQl7srsb08cgohKIpMQQZnH FDSvP7pqz9CeaHTvKnis2rM3qn0hhYdICj6QAd89eyFN/gAgjUjOP//QYlBu9R74aM3Q1v95lf/L Ofj/MvP/H3h3r15FHCHCHQhNHJnhGelCW9AedAj+voCuR0fQM+hXaA36PMS+hu5C30IPogR6Fv0Q /XxGrX8xMXGA34aM7ONIh+wITZ6bHJv4FoQR3jSNcgRSdi54njJpmfzTBbQ/TRyZtEyM6GxI1OrK zGvQ2l/x+OQ5pgFqypNVJM1cA3Gz9qb3hTsmHp64f0YH2tBC1IviaAlaivpRJ1oEoQt1ow60Eq1G g2gtWofWow3g2NqENoO8LkJb0Ta0HcIGtAPtRLvQbpDhXjSE9kF8b4pC0xejA+gSdBBRvBRdBvED 8LxEi12OrgDJfw6l8cpU+spplM+jq2E8roLnF9A16Fr0RUDynEmbmRpGh9F1MJ43oBtROn4+Np1K 4l9Ct0D4MroJRv1miH8Vxv429HX0DY16BN2KvqKl7kR3Q/6tM8qSvPPlb0d3oDth3nwTSt4Ds+f+ C8qSkneip9D3YE69iJ6G2fYMxJ5DJyD+HHoTvYV+i36P/h39B47iKjwffYD+hl4G6W8AqROZ79Se m+G5cUri+0G2lyAq2ctBltMlNQwjQvOohK/UpEalOIz2g0yvgdG4clqdYW28yCiRtohU01I/L1Eq KyKp8zQquSNTlPPyTI/DecotM2Q2U4K3gdRvnSbRtOynS3Z6/Jtoemp6/B50H4zBvfAk43BhKk1/ AFY4Cd9GR9FDEKPP8+l07Dvou+hh0AXH0HH0KHoMPY5GptKPQOp8fhJKPDJV5h/Tn0BParPgGXRS G//n0SgitGfQ8zAXaC6dGc9D6imgP4e+D1roR+jH6BR6AebO97XwI/QTmB+votdAa/0avZGaQa9r MyiMo+gV9CqXg37BmzDPnkTPMYvQxZD+OfM1mOuI/y0yqS2rV61csXxZf1+8t2dxd1fnoo6F7W2t C+a3NDc1zpurNsypr5s9q7amuqoyVlxUmJcTyQ5nBdwOq8UsS6JBL+h4jmUwKmwOtwwEEzkDCS4n vGBBEUmHB4EwOI0wkAgCqWVmmUSQ1BuErBklVSi54YKSKi2pTpXElmAdqisqDDaHg4lTTeEgnIG7 +yB+fVO4P5gY0+IdWpzL0RIyJEIhqBFsdm9qCibwQLA50bJv03DzQFNRIT4miY3hxvViUSE6JkoQ lSCWyAvvPIbz5mAtwuQ1zzrGIL1MXptgI82D6xJd3X3NTb5QqF+joUatrYSuMSFobQU3J4BndDh4 rPDk8HUjFrRmIGpcF143uKIvwQ5CpWG2eXj4moQ1msgPNyXyL/mtGwS4PlEYbmpORMPAWPviqRfg BB+xhIPDHyJgPjz2R+B6GmUwRdFFLB8ikkm6OCWmBB5MxxHwBhxC/0IhwsvhERWtgUTiUHcfTQfR Gl8SqbFof4IZIDkn0znOOMk5lM6Zqj4QBsk2h5sHUt99m9yJQ2uCRYUwsto3kuAikB9MsDkDa9Zu Iji4fjjcBD0EWaJeMA6bIKIOpoTZfKwkBuUHB6ATm4kYuvsSsfDOhCM8j0obCNBIpHlzT59WhVKb E47GBBpYm6qViDVDXZgizcNkYAiDpK1wd98JVD751rGKoO94OapA/YSPhNIIg5LTPNy3bkMiMOBb B/NzQ7DPF0qo/SC+/nDf+n4ySmFLIv8teB18YAC1WtC3C0qnC0O3E0JEH+xjfGw/GS0gBFvgEZ5X BxmWhI4myYjOqwv2YR9KF4O3pEqQ2Ix2IMFGGhdAZUCo2rjAF4LJrX3+G5Z8tAPARkI/xRMHTPDn eaLv+aes0dKEofxg8/qmaQzOaBQSGoOp1v4xnwyRRUoYwIKeDOcC0oeiQgbiQcjWJxjop0Yio+gO JlBXsC+8PtwfhjmkdvWRwSGy1sa3vSdMDiDaaKdmSe+MFM2voXkJFGrv7Usn4PjSl2iJauNKhlVL z9fSU8kFF2S3prODw/pwe88weXk41SAKwgqCwdHltA4errFVwGJtAUUZbhkMBy3BluHBkclDa4aP qerwzuaBTbNgGQyHW9cNh3v66mAstXV/0HcJebUNteP23nlFhaB75h0L42u7j6n42p5lfScscDV5 bW9fkoHD18C8/mPZkNd3IoiQqlEZQiVEUiRIEqSlxZDQa+V9J1SEDmm5nEbQ0mvh/KfRaCGgYbR2 hKE0S7ocAzSO0lSN1g8fWGHuTTAEoIebg+vI8FzWv2l4oJ8sLqTAUMIXJ3B4Dkow4TlwZNQZE2J4 /byEFJ5H6A2E3kDpOkIXwvMSWMEgnBHQScMDYdBTMOX64CjeD7PDQmY/EwmOTE729oVO+cb6Q7Ak VkBY1pcwRGEf4CNtUG4+CQNAnp84tHaQ8IHisNTJymxd2w9rId0gFGlNGKAFQ6oFKNGi1SHTESqt hbGBAdTqH4JE4lB/oj9KXtq3mXAUDFoSaEF4Fgw7bZPPIS+K9Q/bwmVkYkPRhBi5hoABeENwGNYo PkjCy0Dhkh4JRuB8bRiy1g4EYQQ4tLYHpjrVpSIZN6CsB5XI5azXguhLZSLSLTYiyWLCUAwNwpfE pWJoEL5CPwiFdF5LXZMqAO+2JCTgKGeaKFMVQDqQ1Up4ge81wDwp+ixppnsELQ5fDKqRMK29SoDs hBxpHQTlT+tLQAnXpCtDW/oIIZE2RilVID03gtzZSO/I5P3hA0QDpD9FhWGyOZCJiXwnYGKj/uEL CYnl0aJC/YVUWSMPD+vlf1yByksvTyG0gjhyVf8yQtw3J1/ilqFerhjt4T5Bi9mVqI/LQou5Poi/ i+7hMlE3+xrqYHZN1kN8Hn4dNeh6UQPnQ4u4zMmzzNOogc1EBua7aBc3BCET7WS/jC7Dk5O3sN7J Xcw2NMRsm/wVsxdFmb2TL8B7V0MIsp+gfgjlEFohsNBr+tsAhIxwjuuCdAiFIeZBAchhoIQVmZAC Z0kOeVEQ+ZEPOeG8J8EvDBzIDWV5pIffC4jIhWxIRllQX0AZ0FomtEU+D6AHcAs+w6xkGXY5+w53 hPszP6wL6X4p3CO8p3/aUGh4ReyWdNK3jfONv5AXylfLT5pMpkHTQ6b/Mn/eUma5yfKJtc36NLTE wwl7D/tLOI2y8I7Z2qmy89EipUjR180V8RhqRQJeB0wH8XXAFMbrVBvHRKp1bLdPtu7sxt1NAgNC PPPGmZVvnDkFeArHzoy9PmYZf33MVlsbi5WWYGvIqgWHiREEnS6cVcxUV1dVlZeXzWEqK4qZcJYJ Qk5lxRymeg5bXuZnMClKS2pUKEyo7C8/Wc52juuYSwPN2xdlMwGfyWHkcZAPuPT1ncV2c6gyL0+N BQRRx/B6nT5/VlNW06pZ3olHWUESxKCieE08Jxj1hqDH7jFxEy286dwHvOnjRm7rxzezpRUbF1fx XxX1DKfTPeVzRWa3hDzRoN1stxhNvF2x6QS7Tcqpbxs/rHd5XYIoCkaLaHC7Fb1B1Bkt4zWImXxp 8hyXyztg1HLQ955gDjKXo74o8bTF+9RZbosdd0SMcrYsKzmSGBbDWe7sbBEr2eGcyJgqQZLNFGWs cHnIiBXWaLRlLrbF+Xhe1N3Q0GCrjSE4AERdtTZXbbm3Y6zMWo5jo2W1nlh5ebnl4DWjo1ZcbgEA qUd9auh/32xpSX9EIcNSzOSyIdbEwgDlVFVjOj4uIYxDXDbL2vOylKBVj0vGf/cgL7siPn+2SScx dwsWb15mKN8jMjfiibvxyXrFZ+JYwWjAsyd+IMp6ljf5FC4pmfQsqzdL149fimAG9sIq9sFc9KMo qkKHZ0rvBCpkqo+LohONMDWqJVAaUZx8zpgS8DpLSqyREcwkvd2lI5g7rlp7ibxAPg0wB2O1MA/H anHsxbLy02PW2thYKXiEpc9QFWShTUg/63SYuHAoK6faDjMyBFNSINM3DHN2DsNW5KRinC9Uv7S6 oLUiM6M2vvv6lRMPhkKGd4UyH1bWfqG/8HGltL3+sZ7nOzfMDeTuu/TMsvcX71qYx9nqt61ocekL GpZUVF402DMnKxThrswNhNRVK0IVEefEyoruNeNv9yyfqIl1wA+nMNoz+RfuAO9HNWjzTEkdz8xE lhEm/lgR5+W8TsMILkhW9DhHcOFxNW/JlGisZHni2NhoLSxS36P/c1lNDnRVwpLlnA4/QzpeXqaA XPRkqsBi5chK5Q6YXLIpR12/sHd4R291Rt7C7S2LdnVXWSWR5Xi9wdk4eKBpw717GvIWDX39ub2t VyzL44adc7Ij0UjDRdd97RstXQeXFIajYYsFlp3XZXfkhj31+4/tWf3Dpx+4ojVUlkv6vxhW2gew 0mLoiZn9V5WwUc6CP7crWxIjKBYRXQWLs8MgBzVTldyRWBaX6RKR/ClW2ai3Y3y0AcdeebasnKwv 7La8WF6mLTUQ2vF/rVmyyMjKAn1op2uMxOgSE9jQVOwsIzlDXnfQrmN3jx/fzYhKltsbtOmYs9io hDzukI3HG5mFm7CkaMV4xiMYBZ6HB9Mw/mw6zv06HRv/CDRxqgRIEn4Px2KQZAZacoEkZbfHhGTZ bWL19sWeEZx/XNVPLS5QQjh2CsQBknj8n5chvaTrZkbvyhQWs8CiRRx/3ui06Pg/Q2ey3NAZHfMm fkWW9vCK16uYBKvPzj2c5vbju2wItiMy9nmgKQIw+lfO5BksDqZaNQbteXpDLvw57HkjmH3c4bIb 9HpTLiiIR1VXt4mqVNARREOAihiDrqQGFsb4NFESJ1Dep6lI1QMHiz89ltreprj8rFCRk5uTUgsc l+ep6tn3tU3JlYzoCnlcQbvA/ElfFpos68iuWloXfKxedc8K3b3hnvlr2sqDZvaNyr071i6MThSR vpNdizualyXojWWtAwvn9NsEbvyjYEVLe0daHjkgj1I0B31rpjwecyl6I58HWrNXlcvyajP9NfCX n8fXjmCsmvILjXl+xeDSC5mZ4RqQzuNqYXc4bk1tOVRAsOFoKnS6hMattachDXI69tmbojJjBEVx 2RWiPlI7TTE7U4wX6FguJ7dzf2flPFsly4tKboY3aBWYcn1mRfesPTvIsvC4QjaB+Yu+JBN7Vhxe FXvCXd5Te7zvq/0HOyPsZPNlm7o99kvWTbxtD8kGWc9xolnGJZVLGsLjv5iS8sO5gezm9SuyZhUo EwtLOtcRXXMPzLc9IN8stGimdFUD0uvdDoNd7xjBOY+qgfMza3wUx8pfP1VuOUVk9I/y0zPn/NqH vUXToaEyhduDeb3RKk7c/BtY/lkeD1nwb03cahJZoJtF9ipZ5N7TOd0+h/zxHXq6mvXcGptFcHrd ThmuKhjUPTnG/oZ9CWyR2ej6J5grmENT1shxQ6beP4IffgSm6Gz9CP7u48icg+1sTukI41dddmSY nZuZo2NDrQUfeduqzqqmDnahZodoG2uDtvrHToM9cmas3Fpuga21FjqqKp+iInQ8kjYE6aKhO4fi InYh2VcFWDbT9phqtpDLLnB4LcCP3LRy9+yuzXNczlj7luv6+68os3M5eQ6fhcM/jW1rqlraWBqA q9OqaPWOgTabx2riBMnw7eBCtaBmxd76mhtuvm5H44KG5RbQaUbhj83N5b0X7d5eGG6uDddvvQlU IYM6QGq3g9SKUR26ZqbUHisoq9ZxyDDCmFRD2Gr0sw5HODbCyKoThXVPV1cX+K1WY9mrBW3GN1V/ x7TNNmYFTQNa5jTROK5akJdLk5f9U9RKLZdwWKdzOpTzmy4jTJceMUeI1BhBs0duV689ffMWgV+7 Q93QXmIwGDi9rDfW964r6wcrxFO1ZP831vQOtWc92NU2d11HtXXD5uvjYeZ3YFkXhOb41m2xK3bZ KGZkeg1Gl92Y13NZ79xbbvrChjkF87qryxuKFq6v8RbVITxZP3GELeUvhrPDDTNlddzmtwaexL+D uWfFv1PDrXUL1NbZaquitKqzOVRgfGfRfH/dO7MD2bYFC6reUbM70+IaBZMNtl2Q1qgLjJQYkR1I bGqO2f/nqum1BZurJhKQCdEzaTVN9HLaWiHSqrbTEwhXXp46g7gUhS1lWJ1e1AnOjBxXtL7QL1l/ KMmcziCZhJeOWmf1bm8uqhU4juWglCDIZqeloD6aabz3kCjBAcQoi5d7LHXxHY1KSX5Ap9Px1ZzV 6XLA+UPvre6tXWa2Sm6X0yJ+8lDvpd25Jh1vFDk7KcCyLBSYzZbJNr3Lrdikg4sv7crlDUYdb4P5 OQ8kTlZ1Hdz6PTJT5qpcXlFXV9/dlZlRn1E/nyzlHCkfZVTUoQyOr24NdNeXc9nqRyVteYYPbTbX wrPZHa7fqPyU6MnsRGNRsJxdtXSNl8dGx0bB4jGNascLGAmyzLP+1y3CyPBk2v7dEFRVVU+fzv+N Msi0zN/+lYGeL+abJcwLksVgzK7rn1u1dG6+aM2SLC0rtte2b2rIUEratxzu+zsFsaSxLGCGs2KO piCKuy7uzAu5RLtZpyhuu+T0KkphU2z5xaFIe0Nu2dL9zbO+fOTwtnnTVUZZz9ZdO4qiC8r99VuP LIX9oWHyHH6f3wXn+PkXjIfFiSRVRKJT4nhLC081qKY7vXT3VKW/zwQRpUSRPnEJ7zKiI+T2BKw8 g0XG4ASzL2DlsEcvwTYGD75GDxYCBw+yXwE//O9hhixH91/AT21TUVFxrUvJCi3KWo6Ww8tB54s1 WVJPmzXvI7W1raYYhIGUIilr+aKmWlP5nNbyhRkLU4zDGRSmRcomjsVGQftby8tgdY4CgCVoLSdz I/RZ24L+ThnCVVWVKS02zZ76O1LKSBZS51EKTodO4Ddi0Rlyg3B0zA5eKK0vu2igzdrFUKJFh3cI fFld+RZKTIv0UWywZzqcPjOHs8zNK7bV1i2p9rKOlhVbaxqX1bj1wpScmcLMCq+6sP6iI0smtqeF zxT6Z3nqW2cS2avBZoPjrVF4KAs2n1BtZyy8sKEgZ15fRbgpm+wzi2CfeRVGyQVWbN/McSJWbACM C7fFzdhZdzZZyJIx80N7W/47qnB+X4HzG9mCtTOt+PfZ07RgWttpR9bzWyvHvppR27f/KysHvthX 4Ju1VIv1F3zXWdpZU7emozZiU0oX1dQPkhizp+22Gy9fVV3cd6i77bYbrlhVHes7tKysq9ofbV2z Y6imrKvGH21bs3Mv+EHOTtzMvgJ9K0AN6KaZfVPlUGWVUa6UK92yyw2GqV/NiLqMVZUhTij5KKfN JbuDnM3XauusPTutr9rUI2qJ7KExK7E5NKUELg8y6byfvoFpUsmdNsmo4ZGaWSm/lAAmKuwPHPsK VSZFbXMqlDhjcIABH4Bj1ziTXeD0gumRZWoEs2ThRjXjO6Bacqt2DrRbQ7GtTZVgjoTMzFWzvnzz 4a1zbcGod6IrvVK5P4ARApPkaKh9bkHF0v2d0QUVGXWgUe5raS7r3bJ7J13JzAcgx3K09QIpinlW a6YtA2VmGEewW7WoRW22DGteZq7OldXqmlI0xA+CYakSgWnL8wS4lv774tPko+2dUzK6YNUpwBlo HFmvt7v8jqz+JfOtnefV1HEsOlJrKuRqaOvOtYb9Lp2O/Qbn8gd9NkEUZm+6oWdiR3oRnV8v9+Yv rM3iBYNOR3SZYXKMeQ8k0IK+M1MCTyEzHgfjogJssagyG/5Q2Fyh+ppfzgvyJbzKwyHhZbUt+FEe KrAUMEa2IPaG6kutnfHTmittrAEiK6NjxMAAa4O4RIidQSZU9r/SFhWhdqohIgRfCfhLUqecmZYH eEA5WJvgRvEzLoV5TyeZDcZQSWNxYVOxu7JrZWdl9cablsV6GktkvcDoNK9jVvXi+urOCk9F54rO yorVV3fnzK8rlCR2qxgKKna3wxOt9udVFuTP7mloObC01KT4jHqrUa8QU8IX8PmK6kIFldGC2h51 3q6eYqNNkUQi6V2Tf2Ze4L6DmtHwTEmr+VWF0eroPL1hrmFutSEaLal2VbtQybwF1XPr9IXvGKKh qgXms2poSjGBOMfKTtXWgusEnrGYrTa1YEdHqX/Sp9o/Re30TAyz/9zynbLdmCnbTSDWHvMCoxMl k+Hd9ZwuWuLLy1T0egNYZYI+WBBz1Syu8TE8z64/KBl1Rrt8eRRLsBvAvsHj6LtwvDpicCoKHL9E Z4W1PGYQDRL8StPvFgSTpHOXd1QZM4NBEz4n202RoPI6uDY5zmAUXldAr4Mcuev4GGpDq1DVCbQM z1cdXbOMJe/IsUhL3txZC+xnIx2wo6aFHG1oGGtAp6LU7LX8Gqbf1HYY+qw9h6OjYKd2VMqSZa/S FqU7CFviHROxzySOINgbUabRb9X18taMfL8/YgWpWTPzIGZjpnZF1vlZ5eTz4jawqkXRlZOREfEY DJ4IzMCdsCO+zT4Flu1QWjgp33mW5EaldWWl4WyPG0nu7FJPuK7MABatv7XwrGoh4iQ+cnI2pWYr WFejo2CQWDVz1fUp6sBkS4t9yhCtOu+PIzOQejzP0wqxaMt0OnxmnglZmlfuqG1aWesxCOCLoDYI j7frdJIvGqjcMdBu68Tgx6NTzAPzkCNOnQez2tW8yNz+ylBzmKlIWwzjr3lrMv2l2Y76rbf04RvS ZJDQZZPn2HtAQqXEVzf9PH8CheBf49iUvCeZANzsBPHHqqQqRa1Zsq9VTu0GZDmChE6PWc5oKs5w Yba23nRwqkwdLHNZTVlR5WR3woRKz6l7dFxk5a5rugSbJ6gEcpwGfDXGelvACz4ZHd7Kz17T257L Ss6w1+23Cux9YABve/PMz9ZK4JPk9ODEiEtWQSb+f0E2jHuNuv77k6P7DLLAsrwBTpW3TLyBq+AX di6UdcwINsKipEmwfw93wwVZXqrfUcvfToH98yKsFjD8BOJQIHcU9hSLuKo8dlwuAANGzwpPuXiL J5LhCdn1D9XuqfmJWeb1Fgnb9/mC4HoEZwme3DXxe/Y1/mmw4bOeQk7GARdyiOGOixYeFiq9x4lq DvPXQXYu7QSTvhFRFIcQEqzugNOXZcZ69kHB6go6vVlm4X3ZrOcE2S7rLpXNBtjsHTLRtEMT9zMJ /jCKoKITyIG/kBT5jCfxKRg3Fz73CB8yXz1NORAnPdyovQGvxTqR7CWwUaT3EvC5e+m1GTDBPLjt q6sLBdlpYrHJ77F6rAYmUpQ/cMcQJzuDLleGmV9z38STEy9NnLmycmj/ULnRKvGMTs/vweytn4Nb +wLc8ABszKxOtIBEfgVcKn/H5U80Lj8GLq82n+cyBlMrzSVb5dUu9nJz0tuazekQqbMiJ6ciMMUk I/s94KHRM5Hi/MHbh3jKpGnilXtxM67BWYTJvRWS1QhbuV63e2L8K5+beG/i9YlnH9RpTMKPZDGK TpxkTvH74Sa1VHXofQYv8slen9epP+mfb3jGueg8j6Bl4XhLnNaxU9QYgnsd8AjgtG8gRFzxWHPf MqdYToCbqnsm/u0eUWR4Ep9ERodZx+PZ+ph70sEv19kcilU6V2eWBZvTaTUIFp9DF82F5YcnXwCu NgBXIVSuOh0hASFzyGJGIc5yMmO++RnuH7EVIzbtKeIv5GEyp32B5XjKNUE8YzhHiLkmkUGCowXw dDfOvVsSGcKrOGl0mnn2XJ7fbALWnFaRHzXJOrtTsUjEiw6yWg2e/h7eBZ4t8AZOv5s8gUrgnx24 zUwHKsFmtsARtQcddgfySgURvRN8m23HI4ujdvLvDKZuAMBDM34KDCewm2CPJwIl9iW5oPTBiVdr 5n+sC1MaKqQvCFLOTzt0n+qd6kjK5IQrNoXt0TyfhvHlRjMoCbg5wKbnJ35vccg8L9lMuJuXYTLB EZnFb//BJG3QOV2KXXJY4Q7JbZPZn9ys53UWoxQK+fXPsByHwS+o+/hG8JNimDuIfYkPocYLvecn UDPIxUDk0gxyUUeYksdttlyUi2TvCLMuWSMXP4lLUDYK4ELV4LU3sPryHpsKvuBpcnqW7Ejjp1PO P7CGwJeVEtSjWrOfoY2ZAtOu3GDKzuFnXqRzKR1IPF6CACYBu5jVGWS4a6mUbSLPGt1O3LFoV0ex V2+ONFXUbuqtlURwOwkGSZDmrthZN3B5a6Yx3LD+xrXnmDyrabNOcbltRrBNRTGYk2vD2U37Ny5d MNvlri4JZuWHHXY9+PEddkHKzvJULR6I5i9ZveXSG3tf9xDp9qOt7CucAqfcsmMoOoKfSIbccCv5 xHF7TrBwBPPH4fpwmo49NTo+ShT76OlxcpGt3R1NHUHSq+L87Rjp3StkPoCxNtKGRTtsyBlmHW6b GDGaGd4gWUXc2sqIdj8c8C0804pbZRMzqHO43XbjxM3Ed8LDA2+1OsGbDq5OvFUvG3geLggmbtZm Rzm6k/0b+wbcSteqPpQlKhx2wV/UiZ3gKcmKuvRSOGSQpnXhxdMvagdVavsSRy+2K7CvMjm5LCaT O7eYgdt02F3B6TWHgVsQ0DqKAj5Hgdn/vmQJWNywZbw/cavBpiiiJGG9Hm//gGf0DrOFjMNf8Ra9 w+kUFcbKzJr4qSnsNVngjgiXTPwU7v1Msuxx2HS4BBcJZrtTlq1wFzjxCi6GPLPRl28CG7UV17Bn 2Fb4FQpM5kccKCBlzzVgFu4A9fC0wCab3vLG3oCJO3pmaijoLzXg+luxa0NzPs3eCF5P2SqOm2SL TnZamL+a5EUaSRo3GadI+C6QPcjZ5gCxuR14r+AAx5tsc0pZIbcdeIPf0LBvc98E3kpQl2pwwO9e Mh2sARZc5WN5hqLiiNcH/2j0ETXbG/Q8iWtAm1kwl9T1nh+AhvE3xryeM+4zXlD4Vs1jAOMBjmRi K8DWOTWLypQI+dkJxprqcWF6GSVgXQ67QjA5TJ+clcywcoxmPSuajJ/8TLS4Tcz3xp/xcTrRaDYw PxT0vNEmf3Kfw7ZZzg657DYDuHStkuOwqzgvU4crcZnJI/v9PrvAT+xj7TZjdjhTN3GpwQi7KIbf 98D/BgIfHVgdqL2lZVF/Y7RxcOvmNbs3F7Xuhcha9P8AMxr94wplbmRzdHJlYW0KZW5kb2JqCjY5 IDAgb2JqCjEwNTcyCmVuZG9iagoxMCAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1 ZVR5cGUgL0Jhc2VGb250IC9XS1FHQVErQ2FsaWJyaSAvRm9udERlc2NyaXB0b3IKNzAgMCBSIC9U b1VuaWNvZGUgNzEgMCBSIC9GaXJzdENoYXIgMzMgL0xhc3RDaGFyIDExMCAvV2lkdGhzIFsgNDIw IDQ3OSAzMzUKNDk4IDUyNSA0MjMgNDUzIDIyNiA1NzkgMzkxIDUyNSA1MjcgMzA1IDQ4NyA0NTkg NTMzIDYyMyA0ODggNTgzIDUyNSA1MjUgNTI1CjIyOSAyNTIgMjI5IDUyNSA3MTUgNDcxIDM0OSA3 OTkgNTU3IDI1MCA0MzMgNjEyIDQ1OSA0NTUgMzA2IDQ5OCA2NDIgNDUyIDUwNwoyNTIgNTA3IDMw MyA1MDcgMzAzIDUxOSA1MjUgMzk1IDU0MyA1NDQgNjYyIDMwNyAzMDcgODU2IDYxNiAyNjggNDk4 IDYxNSA0OTgKMzg2IDQ5OCA4OTAgNTE3IDUyOSA2MzEgMjM5IDQ5OCA2MzQgNTIwIDg1NSA1MDcg NjQ2IDUwNyA1MDcgNTA3IDQ5OCA1MDcgXQo+PgplbmRvYmoKNzEgMCBvYmoKPDwgL0xlbmd0aCA3 MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBXZRLb5tAFIX3/IpZpovIYwZw LCGkKlUkL/pQ3f4AHkOCVGOEycL/vt+5uGmbxUE63Oe5d2Y2j4dPh3FY3ObbfG6PcXH9MHZzvJxf 5za6Jj4PY7JNXTe0y43Zv/ZUT8mG4OP1ssTTYezPriwT5zbfCbks89XdfezOTfygf1/nLs7D+Ozu fj4e7c/xdZp+xVMcF+eTqnJd7En3uZ6+1KfoNhZ6f+iwD8v1nqi/Hj+uU3R0RMR2bak9d/Ey1W2c 6/E5JqX3Vfn0VCVx7N6ZbgFN377Uc1KmDxXOfu/4dHxSz6f2FnnzeReR5YpI5Vx3LvXb/5xzvzbU 9LdO0m1VCt5nbUW9FAq8L7aiAQq832WiGRRgzUUpJUCjaAEF0CC6gwJi96J7KKCQZa6hAKs5N1AA pd8ybaGAVL1oBwXQQjRCgfe5ddVDAVSpArMVKGQUcWEV+CAr4gSskhAQJ/QNK4EiTqCQOSMurAJV KCBOoEmLRVwwgYVGF1iVQGbpDWgVSGUUrcH0FqmsaBVItRNFq4CzUbQG07szZ7QG01t0OGeIE9iy 6jJOA6nUM6INtKFZZagRyNyI0r7gPQmhtC8wOinKaF8glcXSPlrkrJVltC9Q12JpPzMJjAgr7QtY rQ3az0wCu8BK+wJWTSNjXQJ15ZyjRqCuCuUoEqC1KOsScNY0WLIBgUYRxzHASkKsrEvAWXpztApQ Rsd1+3Pw07drc7sIOUIFxFpRhOarWMuDUBKqik5CjlABZ22E3AbUWQ8IzVexlgqh+SpWyy0QKtCS JsM9M3ACpZ3TYaCQOSOW24RzoVQFQgViVYjbYMBZTXJ2DFB1xRE20KS2yTE0YNX6yGfAqjFyOgxQ bYQTbYBKL+fOwEYsFnFcecnniv0zVb1nenff3sn2dZ55Iu1xttdTr+Iwxrf3ezpPSmD4DafKet0K ZW5kc3RyZWFtCmVuZG9iago3MiAwIG9iago3MDMKZW5kb2JqCjcwIDAgb2JqCjw8IC9UeXBlIC9G b250RGVzY3JpcHRvciAvRm9udE5hbWUgL1dLUUdBUStDYWxpYnJpIC9GbGFncyA0IC9Gb250QkJv eCBbLTUwMyAtMzA3IDEyNDAgOTY0XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDk1MiAvRGVzY2Vu dCAtMjY5IC9DYXBIZWlnaHQgNjMyIC9TdGVtViAwIC9YSGVpZ2h0CjQ2NCAvQXZnV2lkdGggNTIx IC9NYXhXaWR0aCAxMzI4IC9Gb250RmlsZTIgNzMgMCBSID4+CmVuZG9iago3MyAwIG9iago8PCAv TGVuZ3RoIDc0IDAgUiAvTGVuZ3RoMSAzNTIyNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJl YW0KeAHUvXd8XMW5Pj5zzvbed7UrbdFKu5JWvUuWpbXVJcu2JMuWbMu9g7uNwTZgOpgQOgmEGhIg mIAsNxknwUmcEJKYkISSBoF7k1ASJ5AGGEv6PXNmR5IN3JvP5/fP/co8ep+ZOefozDvtnXdmDju2 7VxNjGQfkUnxyo3LtxDlp/x9iMMrL9kR5uHsdYSo09dsWbuRh/OuJUTvX3vxZWt4uHIuIb2xdauX r+Jhcg6ych0ieJiWQ2at27jjUh4ue5gQOvfizStT6RVfQ/yTG5dfmvr75HcIhzct37iaX38Tuy+8 ZdvqVDrtx+NsPI2QtaRaJfiktOBPIDSPhomNfJ9oiQRZRPBE+230aqJCKktXPzhyy4c/sS+11v2L pOmU20/8ee9PGXn+hidu/uTs6M36v2iPIqjHE/gP7tM+OPobQgwPf3L27MP6vyhPSiUqYt6wXg6P SNce1vtoB8g1glwtyFWC7BPkSkGuEORyQfYKskeQ3YJcJsilguwS5BJBdgqyQ5DtgmwVZIsgmwXZ JMhGQS4W5CJBNgiyXpB1gqwVZI0gqwVZJchKQVYIslyQZYIsFWSJIIOCLBZkkSALBRkQpF+QBYLM F6RPkHmC9ArSI0i3IHMFmSPIbEG6BJklSKcgHYK0C9ImSKsgLYI0C9IkSKMgMwWZIUhSkAZB6gWZ LkidINMEqRWkRpBqQaoEqRSkQpByQcoEKRWkRJBiQYoEKRSkQJB8QRKC5AmSK0iOIHFBYoJkC5Il SFSQTEEigoQFCQkSFCRDkHRBAoL4BUkTxCeIVxCPIG5BXII4BXEIYhfEJohVEIsgZkFMghgFMQii F0QniFYQjSBqQVSCyIJIglBBSIrQcUHGBBkV5JwgnwhyVpCPBflIkA8F+bcg/xLkn4L8Q5C/C/KB IO8L8jdB/irIGUH+IsifBXlPkHcFeUeQtwX5kyB/FOQPgvy3IP8lyFuCvCnI7wV5Q5DXBfmdIL8V 5DeC/FqQXwnymiCvCvKKIC8L8ktBfiHIzwV5SZCfCfKiIKcF+akgPxHkx4K8IMiPBHlekB8K8gNB TgnyfUG+J8h3BTkpyHOCfEeQbwvyLUFOCPKsIMcFGRHkmCBHBTkiyGFBDgkyLMhBQYYEeUaQpwX5 piBPCXJAkCcF+YYgTwjyuCCPCfJ1Qb4myKOCfFWQRwR5WJCHBHlQkAcEuV+QrwhynyD3CvJlQb4k yD2C3C3IXYLcKcgdgtwuyG2C3CrIFwW5RZAvCHKzIPsFuUmQGwW5QZDrBblOkGsFuUaQqwW5SpB9 glwpyBWCXC7IXkH2CLJbkMsEuVSQXYJcIshOQXYIsl2QbYJsFWSLIJsF2STIRkEuFuQiQTYIsl6Q dYKsFWSNIKsFWSXISkFWCLJckGWCLBVkiSCDgiwWZJEgCwUZEKRfkAWCzBekT5B5gvQK0iPIXEHm CDJbkFmCdArSIUi7IG2CtArSIkizIE2CNB5i1jKs5uFgfQg283DQDXE1D101HKxFaB8PXcnFFcNB EyIv56G9XOzhYjcXlw1nzMAllw5nNELs4uISLnbytB08tJ2LbTxy63DGTNywhYvNXGzil2zk4mIu LhpOb8aVG7hYz8U6LtZysWY4vQmXrOahVVys5GIFF8u5WMbFUi6W8PsGeWgxF4u4WMjFABf9XCzg Yj4XfVzM46KXix4uurmYy8UcLmZz0cXFLC46uegYDrQjD+1ctA0HOhBq5aJlONCJUPNwYBZEExeN XMzkaTP4fUkuGvh99VxM56KOXzmNi1p+ew0X1VxUcVHJRQV/WDkXZfwppVyUcFHMH1bERSG/r4CL fC4SXORxkctFDhdx/ugYF9n8mVlcRLnI5I+OcBHm94W4CHKRwUU6FwEu/MP+2VBWGhe+Yf8chLxc eHikmwsXj3Ry4eDCztNsXFh5pIULMxcmnmbkwsCFnqfpuNByoRlOm4u/rh5O64ZQcSHzSImHKBdE EXScizHlEjrKQ+e4+ISLszztYx76iIsPufg3F/8a9s0LjdB/Dvt6If7BQ3/n4gMu3udpf+Ohv3Jx hou/8LQ/c/Eej3yXi3e4eJuLP/FL/shDf+Ch/+ah/+LiLS7e5Gm/5+INHvk6F7/j4rdc/IZf8mse +hUXrw17FyArrw5750O8wsXLPPKXXPyCi59z8RK/5GdcvMgjT3PxUy5+wsWP+SUvcPEjHvk8Fz/k 4gdcnOLi+/zK7/HQd7k4ycVzPO07XHybR36LixNcPMvFcS5G+JXHeOgoF0e4OMzFoWFPAzI9POxZ BHGQiyEunuHiaS6+ycVTXBzg4slhD3p9+g3+lCe4eJynPcbF17n4GhePcvFVLh7h4mEuHuIPe5A/ 5QEu7udpX+HiPi7u5eLL/IYv8dA9XNzNxV087U7+lDu4uJ2n3cbFrVx8kYtbuPgCv/JmHtrPxU1c 3MjFDVxcP+xejrxfN+xeAXEtF9cMu9cgdDUXVw27+xDaN+zGYEOvHHZXQlzBxeX89r38vj1c7B52 r8Ill/HbL+ViFxeXcLGTix1cbOeP3sZv38rFlmH3SjxlM3/YJn7lRi4u5uIiLjZwsZ7ft46LtfzN 1vDbV3Oxil+5kosVXCznYhkXS7lYwjM9yN9sMReLeKYX8kcP8D/Uz8UC/rrz+R/q40+Zx0UvFz1c dA+7ksjY3GEXU+ucYRdrsLOHXddAdA27CiBm8Us6uegYdsGQoO081MZFK49sGXZdgbTmYdcNEE3D rishGodd+yBmDjtaIGZwkeSigYv6YQfsAjqdh+qG7QMITeOidtjO2lENF9XD9laEqobt/RCVw/aF EBU8rZyLsmF7PiJL+ZUlw3aWseJhO+uQirgo5LcX8L+Qz0WCPyyPi1z+sBwu4lzEuMgetjMtZXER 5c/M5M+M8IeF+VNCXAT5fRlcpHMR4MLPRdqwbRDP9A3blkB4h21LITxcuLlwceHkwsFvsPMbbDzS yoWFCzMXJn6lkV9p4JF6LnRcaLnQ8CvV/EoVj5S5kLigXJDkuHVFiGHMujI0al0VOgf+CXAW+Bhx HyHuQ+DfwL+AfyL+H8DfkfYBwu8DfwP+CpxB/F+APyPtPYTfBd4B3gb+ZFkb+qNlXegPwH8D/wW8 hbg3IX8PvAG8jvDvIH8L/Ab4NfAr80Wh18wloVchXzFfHHrZHAv9EvgF+M/NidBLwM+AF5F+GnE/ NW8M/QT8x+AvgP/IvCH0vHl96IfmdaEfmNeGTuHe7+N53wO+CyTHT+L3c8B3gG+btoa+ZdoWOmHa HnrWtCN0HBgBjiH+KHAEaYeRdghxw8BBYAh4xnhZ6Gnj7tA3jXtDTxkvDx0wXhF6EvgG8ATwOPAY 8HVjQehrkI8CX8U9j0A+bLwo9BD4g+APAPeDfwXPug/PuhfP+jLivgTcA9wN3AXcCdyB+27H824z zA7dapgT+qJhbegWw9dDXzA8HrpOzg5dK1eHrqHVoav79vVddWBf35V9l/ddceDyPuPl1Hh54PLO y/dcfuDy316edGgMe/t29+05sLvvsr5dfZce2NX3rHQ9WSNdl6zru+TAzj7VTtfOHTvlf+6kB3bS pp20eCeVyE7bzvBO2bSjb1vf9gPb+si2udv2bRvappo2tO3NbRLZRg0j4ycPbQsEWyCTe7eZbS1b +zb3bTmwuW/Tmo19G/CC66vX9q07sLZvTfWqvtUHVvWtrF7Rt7x6Wd/S6sG+JQcG+xZXL+xbdGBh 30B1f98CXD+/el5f34F5fb3V3X09B7r75lTP7puN+K7qzr5ZBzr7Oqrb+toPtPW1Vrf0NSPzJN2W Hk6XbewFZqfjTUiAziwOJANvBt4PqEhgKHAyIDus/pBfyrWm0cY5aXRz2pVpt6bJVt/PfFLSl5vf YvX+zPt779+8KmfSm1vYQjw2T9gju1nePF3zWN4OeRqauCypUPLa5YnGWqxuanWH3FJzyE2J/U37 +3bZ/ZztZzbJaqVW67hVSlpxudUSskjs17hFTlpKqlqs5pBZYr/GzbInaUYMe/m4ae68FqsxZJT6 GoxzjFLS2NDYkjQWFLcQmYYpVn5sELKOvQ11h1pGKDnkoWo6Qm87OK83kegc0ZGeziHd3EVD9Mah 7F72O9m9cEhz4xDpW7io/yClXxw4SKXGeUOuzu6FPHzdLbeQmRmdQxm9/UMPZwx0Du0DSTIyDkIy DnrIzIHEku07tycSO5bg15LtOxLKfwjRnSyEHyTgv+07EGb/IBAmLOXzf/hluG7pdvwoj+FP//xb /h9Iof8PvOP/8Vc8SFBF+2eMS9eSVdI1wNXAVcA+4ErgCuByYC+wB9gNXAZcCuwCLgF2AjuA7cBW YAuwGdgEbAQuBi4CNgDrgXXAWmANsBpYBawEVgDLgWXAUmAJMAgsBhYBC4EBoB9YAMwH+oB5QC/Q A3QDc4E5wGygC5gFdAIdQDvQBrQCLUAz0AQ0AjOBGUASaADqgelAHTANqAVqgGqgCqgEKoByoAwo BUqAYqAIKAQKgHwgAeQBuUAOEAdiQDaQBUSBTCAChIEQEAQygHQgAPiBNMAHeAEP4AZcgBNwAHbA BlgBC2AGTIARMAB6QAdoAQ2gBlQzxvFbBiSAAoSsooijY8AocA74BDgLfAx8BHwI/Bv4F/BP4B/A 34EPgPeBvwF/Bc4AfwH+DLwHvAu8A7wN/An4I/AH4L+B/wLeAt4Efg+8AbwO/A74LfAb4NfAr4DX gFeBV4CXgV8CvwB+DrwE/Ax4ETgN/BT4CfBj4AXgR8DzwA+BHwCngO8D3wO+C5wEngO+A3wb+BZw AngWOA6MAMeAo8AR4DBwCBgGDgJDwDPA08A3gaeAA8CTwDeAJ4DHgceArwNfAx4Fvgo8AjwMPAQ8 CDwA3A98BbgPuBf4MvAl4B7gbuAu4E7gDuB24DbgVuCLwC3AF4Cbgf3ATcCNwA3A9cB1ZNWMffRa sGuAq4GrgH3AlcAVwOXAXmAPsBu4DLgU2AVcAuwEdgDbgW3AVmALsBnYBGwELgYuAjYA64F1wFpg DbAaWAWsBFYAy4FlwFJgCTAILAYWAQuBAaAfWADMB/qAeUAv0APMBeYAs4FZQCfQAbQDbUAr0AI0 A01AI1n1f7yb/r/+egP/11/w//j7+ZYuYTuGCBm7c+omITKXbCDbyT78u57cQu4kz5HfkhXkGrB7 ycPkMfINMkS+S14gr5131//PwNhl6o3EJB8jGuIkZPzs+Jmxx4ARtWVKzJ0IOVXhyZhx2/hfL4j7 69id47axEY2DGJR7zdIv8LR/0NHxsxhfNcQ8XsnC0g3gVuUvfaB9cOyZscfPy8Bc0k0WkkVkMRkk y8hy5H8VWUfWQzMXkYvJRrJJCW1C2lrwNQgtxVXoSxQ+edVmsoVsJtvIDrKTXIJ/W8C3p0IsbasS 3kl24d+l5DKym+whe8nlqd+7lJi9SNmtxF6KlCvIlSiZq8jVChOSx1xDriXXodRuIDeSm1Binx+6 aeKq/eRm8gWU8xfJreTz+C3npdxGbiO3kztQH+4id5N7yJdRL75C7r8g9ktK/H3kQfIQ6gy7427E PKSwe8iXyLfID8kR8jR5hhxVdLkSuuUaEXpZo2h6C3SwF3m+Zsobc23umtDWFdAGy/f+VL4vhf6u nnLHJSk9Mu1dgyuZdvanyoE95fJUjNDEbcgZ55P5ZDpiebj1vHyKO/63WJZjpqf7oS+hGaazexB3 36dip14xld9DHkALfAS/mVYZ+yo4Zw8pfGr8gxPXPqykPUq+Rr6OsnicMCYkj3kMcY+TJ9C2nyQH yFP4N8mnMp76NPmmUnJD5CAZJofIYZTkUXKMjCjx/1PaM+g7LrznUOpZwxNPOU6eJSdQQ75DTqKn +R7+iZhvI+65VOwp5Soe/h72Up5SrmKp30Pdeh491I/JT8hPyc/IDxB6Ufn9I4ReIr8gvySvUTPY z8m7+D1KXlL/gVjIDGy8fBalcT9ZQpYkW1ctXTK4eNHCgf6+eb093XPnzO6a1dnR3tba0tzUOHNG sqF+et202prqqsqKosKC/JxYdlY0M+Rz2W1Ws9Gg12k1apUMyza/OdqyLDwUWzakikXb2gpYOLoc EcunRCwbCiOq5fxrhsLsvuVIOu/KJK5cc8GVSX5lcuJKagvXkbqC/HBzNDx0uikaHqELu/vBb2mK DoSHzii8S+GqmBIwIxCJ4I5ws29dU3iILgs3D7Vcsm5/87Kmgnx60GhojDauNhTkk4MGI6gRbCgn uuUgzamnCpFymmsPSkRnZn92SM5uXr5qaG53f3NTIBIZUOJIo/KsIU3jkFZ5Vnj9EN6Z3Bw+mH9y /xdGbGTFsoRpVXTV8sX9Q/Jy3LRfbt6//4Yhe2IoN9o0lLv7Dz4ocPVQfrSpeSgRxYt19kz8ATqk zrZFw/v/RfDy0TN/wVtPiVmeitFk2/5FWCLL4oSahuhywQneDW+I/EUi7F1uHkmSFQgM7evu5+Ew WREYJsmixMCQtIylnBQp7j6Wsk+kTNy+LArNNkebl6X+u2Sdb2jfinBBPkpW+S97SJWN9PCQHFu2 YuU6Jpev3h9tQg6hSzIPTpsmkOTylDKbDxYX4frly5CJ9UwN3f1DRdEtQ67oTK5tROAh2c3re/uV W3hs85CrcYgsW5m6a6ioGfeiijTvZwXDXpA9K9rdf5yUjb95sDwcOFRGyskAe48hTyMKJda8v3/V mqHQssAq1M814f5AZCg5APUNRPtXD7BSitqGct/En8MPClC5C3m74GpxMbI9pM3WhfulgDzASgsR 4Rb8is6sQ4JtSMODrERn1oX7aYCIy/BXUlcwdt5zEJCzG9twMyRubWwLRFC5lZ//4ZUCPAN4jSHd xDup8BLqyXfif+dzX41fzV4oN9y8umnKC573UASUF0w97bPfU2K6SCkDr6BjxdnG8lCQL4GHkawb kpBPJYqVoi88ROaG+6OrowNR1KHk3H5WOEzXSvl29kaZY1Ap7VQtmXdeiKdX87QhEumc1y8CzGcz 1JJQypUVqxJuVcITwbYLkttFcni/LtrZu5/98WjqgSSMFoTC0cTal99c7ShHY21BRxltWR4N28It +5ePjO9bsf9gMrl/S/OydbVoBvuj7av2R3v761CWSru/PLCb/WkH6aSd82YW5KPvmXkwSm/sPpik N/Yu7D+OzfjhG+f1D0twii6bOXAwC2n9x8OEJJVYicWySHZJmAXYk3oQ0CnXB44nCdmnpKqUCCW8 En5ZJY5fhDhKVo5IPM4mrpMQp+JxSSVuAD9oYb51KAL0w83hVax49g6s279sgDUu4kFR4j86RKP1 ZEiK1sOVqzENGaKrZw4ZozNZfAOLb+DxGhavjc4coh4K5YygT9q/LIp+ClWuHy7yAdQOG6v9UnZ4 ZHx8Xn/kdODMQARNYjGwsH9In8A4oM7uwHWtDMsQ3Tq0b+Vy9h6kD02dtcz2lQNoC+KBuKR9SI8n 6FNPwBUtyj2sOuKmlSgbFKBy/z4EhvYNDA0k2B/tX8/eKBy2DZG2aC2KnT9THWN/qGhgvyNayio2 Lh0yZN/AhB7vRuCkVmICCOKPocNlOdKa8OYro0hauSyMElCRlb2o6rwvNbByQ8xqdImq2GoFhkAq kbBsydlGs2FIX4gH4j/GjYV4IP7TDkApLPNK6IbUBfjbtiEj3ig2RZWpG6AdJLWzd8F/N+Dl2aXf ZY/pHiE90UvRNbKXVv6UFslD5uz25ej8+f1GxESrxc14li6bRbFnnOKxWpZzE/QuZ88bGX88ehnr AcRPQX6UDQ6sYpLAcVRsMrD/woihRYmCfN2FsWYlev9+nfmzb+D60pknJHtKuBljDSEqdozlZ5CP kKhqIXlK1USWq/5CnpLfAb5JnlKbyCLVOfKUpEJaDuIGyVOa1xCfB8wiK1WZiO9Xrm2V/0Ss6kzy pDZIpqvipFh+hSxWlZN75RVkIeQy+RMyKG0l2aoDQB1whmTLp0gFuwa+uOvoe+OvyI8q/F7NKnIv i1dVK/cyvkz6MZ4VId3S0ySi+hOwk0PtJBHNrzlw3V3yAyRTPUIq5F0kV36IZMq5ZADPJ/BJ5klZ 5AS8ll+SvYTC49wsnxv/GF7m64Dd8EI/ByyUz5EHgenQzUVAD9AGPA1sA9YCxcBqQEnHtS3AEmA1 Co+f+yHEhHnpYwhHyGxwLykgARInaaQaV0gkn+SSHJKOObIDNVyPazNwpR8jdDYxkEziI5UkTBIk hjNF00gVKcQJoyzSQHqJi1SQDjIdT51B2slM4iF5pIbYccLKShpJEyklIVKHWa+a9JB60kzcOJcU JDoSRZUqwVksM5kDC7kT3oEu0kJm4Q0J5h+P0CL6R2mF9DO5Uz6sWqT6RN2i/oHGqTmpXaT9pW6W 7kP9C4ZiwwnjLONh00rTOfONWCQ7aW20/tl2hT3fkeZ4wOlxPuCqcu12L3L/xbPba/c+6Yv63k1b 7Xf4g/67Ai2BnnR7+iMZ/cHi4MkQFkNDT4R+HY6EG8MXhb8Yfib8UaQtcmXkcKYtc3M0I6sx69/Z 34x1xWfkaHJO5Hw/5ye5/ty+XObdUMPLsV3+hdqC/GqR7y7oYdG3iBmuOw+ppUeOuJuadAXa78At J5EwHHs6Qmlj0qqSzMf8/obosQrNLbK9fYQWHG7Q3iJJpGH0jdEXi0bfOOOoKTpDi15/6423bB+8 aK8pKnvr5bdKiqk9YlfgskharUsTzSyUKuKxyrKy0nqpojwWzbRISlx5ZVW9XFYalGRcyWPqJRam 8i/OLZTnjGqkK6IN88vUQb/VZdaopXSfo6Au29a7KLuuMEMrazWyWqfNqZqZ2Xlxc+ZvtPYMtyfD odM5MjzuDLt29Ldqy9m/qy2fNKou/uQuWTNtcUOW/GWDTlJpNCNBX1retEj7fKvTpjI6bXaPTuuw m3KaFo9e705nz0h3u/mzRrugluj4WdUVahdqWYw8cJxkjb9z2GSjs6IjKRIbGX//sBExRkGwdvx+ 0s+ism3st1n5bVJ+J3NoNkvON9KurGgs+58mo8mXmRE1mKlHZSImm0l6Jvpc9GdROWqKmhwZPY4+ dR9paGhw1NQUFQ0O2r01dlB7me1Mqb0MGk8Mcn8bViWzPR6NovK4HJEtcjQzFqusolzPXm1URh+g o7bsUCjbqVdtHv3TBtngjKZnZFupjg6rzGnxYDjPb1Htob+n35vuCVhUstakp9PGXtCb9Sq1JeBR DRstOlnWWY23jO4hqFNPoS+kqF1BtL1q8qOkP+Sz0a6Qzcp+mfHLZ8KvMPKKnYyFyRy/O4l0dxLp brcxn12czy7OZxfns4vz2cX5z0ql8FGdPAJOYmXQ9CFcCfn+IVysSFwP+e9DuEVJx5VlI5ItaX7Y eNIoGf3xf5aUaLNGKHaYdJePUONB7TzScKZBqbc1tGjwLUVrpS8nOEF1TiRqOIdSXRZVNJIZq7CX V5ZFUCvdrD4HZVpeKEWjdlaZnZNURUPVc1ZubR972pub66WxHXetLPUkZuRVLG7OGRv1Vy/sGD7V 2FOZNju79aLuF89O62+M0e3T1/bU57lDcdXV8VD+vN1dhfNaqx2Gip5NEi2aVZE+NhidNmf09dr+ utBYdXpVD3rB5ePvq0zqIFrxikPpZFoipRVIRSuQfzkErUD+lWlFSYdWEt+RytCD+WgReswYzR92 9qpO0Dx0i8W08KB+Ppr0y2cYaBHPvu3VUyXF2S4Lb7zlSrPUMAWwZsoasNsVRFPlzVVlktQ6V3Lp nvYrfnJrV+89P7+yesPCloBOLat0Rp2ldM7WOfNvWVVVsfK2RV3bu8utWoNGPmbzOSyu3Hhg3tc+ eOCRc88sdofzAhan3+FKd+rjRfHm67+7d8+3r5wRK4pp7EG0QFbLbkUtc6Cv3pXMaIhQJ6s5TlZz nC7k2elAhp0+5NZ5gtUc4uc1xp/SjSJxHaRSYyDfOYSr/SckO0YTHzUNW7oDIzR2UM1ridDFy6JG DKJKSOdVCe2UCnDr/K+//9jYX5Xiz37inQe6j5RvfvL6Zw7ufXJbjXTfE598vYcX9IJH37l3/ZFr O87Z6/d9l419yJm8FznLJ5cc9MdTJQqplKgi8daQylsr6Xjr+IhkT+r1zrAzjJf3j1Bd0rwvRk/G 6EsxGotp0kaQH3N3HOKgZqLWD27dhiIuUroRG89WqVLO52dLKeiIXVT6KKfyXpXBrBu9k+VQWqMz 69Rq/BrT0GEdugaVHny2RHVmg6rVEXDoeG51joDLEbDrxjbobelOh9+mHSvR2QNKvsfPyvOQ7zhZ fFDrTOUbUsm3IlmppvKtpLOyRb6PmDNIMEOLrB1yOtM0IzTnUGZ3GusgUyNS0Sl7qhkjd7zQpmZG jDaiYcvzkDHtGLSnxcsrPKlzhf2+TJcOWW1RYk8505GLNq0t4HYG7PrRP2rNWrUav1RPx0MYcliO Fo3/VXWpOgyb46vJjPR0q4/VUB+roT7Wt/kMqKE+G3LhY6VnJs/FaTiejC+Ly3FrKv+QSv4hlZYM qbRkJR13Wkek0sNF5bTcN0INhzMza4rqT1ADxngDzR2u6XWN0PyDRWjPSmvGIMEG6FQ/9/Lg4Cle 5ohO6eW81lxZZWf9HWvtStHbWQ/IBm/e/lWqS1U6k9ZUveSahRc9eUlD8+5vrK7bUzH2st2u0mOM +IrR4zA4ahevWFVyz18enT/4jTO3dVy9utlvUC1xZjh1scLY7P3f2bz35LVNGRn0sswsqFGns6U7 xpz+WEamzzT41Pt33Xd2aLk/muvPZO0CY+5cjLlFZORwQwmNmlIqglRUpEioFVJpGko6VGRiyk33 ZhmZ9o1M+0amfSPTvpH1D0Y2RnhJ0o2BJelkv2x2OoskkU68bAMSEpg8ijRvXg8GkPyk9aSJvmSi pvNH46LBrWcaKEaNl9lIkmpQkw1rED0oN2xgEk1Qrk3JjThBVXN1rojPH3bpRg+BpbGap3Nl+tIi Lp3UpdRFMD+0jypn0kn1o98TXPUbwUbPShrBU+2L9kN/bjL3WIN3jvcZr0xSKoRUVKhI6AZSUaGS Dg2RZ9EnGsZPHoMmDLYexfhANic6wsl8iRzQfvHeenfEy9574m0n31C0+o/wVmVkRdJewhpDMSuT IsYiMJqUUZ4ZT2yUVyTeD1J5PyUdFxpYEZvc8Z6IwRbosU1aRyiMiW4NJcLfMxaL089Qf8oocrs0 Wko9HvkjrSszEM33aMeyRF5EGdAfa2zeiN8fdmrNjrFe+qJdm846QI3NIN0wetlEVzBZFt+VGvQm rUqNAjH7vaPjo/f5nam+vhO595O248TNM4udeEpmFYnMQiqZhVQGKDcye5jorT3uEZpIdea06LQo DCWP3E7hwzEqFrOpO9Ej60dPeXMnMvESM+E6XQGnHn3z06KqfPKI3p6eKhlNAv1xHXkqaVtWv6Ve MhcXe4uKDIU+nzJYojkpgygKRpF4V0jlXZV0FIyfFUwwq8RkMrDWZ2Ctz8Ban4G1PgMraQOrW7Dr kmkIkKzKbqPPay7ylRRqQjndoT5h6jY4YOSWoTyFdQZLV7Qse5m9ZnpRWRmzfae0sShl9m6hFKfR KcXN5h1ByUvLWHkz6tYkdK5Qmjfi1EljZbLRneFyB11GaayVoqWl+VDI+YF14eIsn57uUtPrjf5Q LG2jNeA0TVbptZ/cpTVoZRVMGUwu7hW6VD2Wl2Xy5wTOLZAfC+alGfXODHeqJ7tCbccM9LpDcavV larlioSCFAkdQb7PrDYlDOW4FGUGDYWFpUyZpT5cW+rDhaU2XFXKlFnKLsFktbrHUGiNq9LYOMiG e0wVvDVMeanWMKm7IuhMqTJcU2gbUY/H/Rn6CsreshizflO1SnWF2e03V/nj0ah7bF14RrokSTpn yOcLOXT5/p6MeCjDTmszKktLfBRmgDOU5gk7dK0uzKaMGaVx6c2ay6e13dNx7h8TreXJnEyDNzc0 +qPylcsGi+YcmCN9B3MNWBImLYHFt3L8jOoddQTz/TjZm/S7mA5crEK5mLnnYuaei+kAaipL6sOk GGvDMgmmlAuptCpIZSCFVAZSJR13BU/AJDaQNAyb1t4oa1lqZdicMIFfTg2bkyNlahyUFKtvig2s eqfjzjfuuuOVm5s67nrjrltfvqX5SHzRl7ds+fLS3NjCL23bet+SHOmeB84dXLrgsX8/fO/ZZ5bO //o/vrHp2zfPnveFE2u3nby5a96t32IWLuyh59H+0uHnuPRgliaVEUglI4pExiGVJqekIyMaVgW8 9gymngymngybyUxnZbA5VAashWFiz4atcEijMSGbxkPubtMUU4lXENGwUnk9v/mgN1FNMXTl55O7 vnnpnXpnJI1183l+6s7rWr9xVu6RaQsG8x/6yuy1LVnyncvv31Q3VjjRLlDUWm/D4ssWzNlQbhn9 OKd1JSthNsIbkeNK+GBuTwZthfYqHd66iuWiSslFFctVFSvlKpTysVw2c8xtsDOVgCkS1yoSqoFU VAOp9Jx2qGY4vdAG6/joliRNJr3ToYEjkW5vasRg9uLgGUwFU81E9DUwkFOthHUncqGMCd/k+M2m gx5vUE5NCL1Oj4eWx+KxWGpaqDJqXFlBf8RlVO1yF9TPm7ZdKAszQ2fJDH/n9tnx6MzFNeHyghzX DotubLRpblpD2e1PNK2cGUIno0MbQBMvKV/QEB399YQSYWiqZXP1/M2NM9bOqXVZEnWzS8b+OytD vm7Weq9WMzYrMm0uepvW8TPySrSbdvL2cTIDDgor3A8zmMqgIkVCdYpEC4JUVDVjRMpPJkqTThed VZq0wy9RmlVqCvjYvQHWgQdsuCvAOp4AK47As9h5iV78UECxHk4eSktJF5dHrcykMhWeoHG44gw0 ljTaw1W0Kmk00Vkon5NJA2NV9iq7pw6W/JEZAXVur2eE5qbaIYrgjJ25OxKJQdsZG5rlFBtLmcAI g2uigapEA+WOpkJNKnzhxFUjr2zc9cjgjM0LpnmNMGl1lrK5WzuqBxuzSnvWb1rXUzZt/e3zEgu6 6pwalSRrjFpjUdNgbeXccn9p74ZNG3rL6EWLvojpfTjTlx2Cx0mbmRMNVs0tq5o9raSsft7WOd1X zi+wpoWcRrvP6cB8Nj2akVE8M7tydl1p2fTerSgjK9r6a6j5mWT1MV8S6vXZYXudPAxGlIYNZSsN HrVbkUiAPL/hs4HUDgcJ0uwaB5sGZaTadimMtQ8U58YPErZTiZSGptigEWHWK6bCa8rk7S5h9Yzd JSZ38rXK1E6Z+3zy4ERFXKGzpzud3D3GLIcn0VNfBqsmQe5NZiwroGHWasOsFYdZ1QmzsT/Mag2+ u2RL2qda3qhpxJPq6SCVnk6RuA9SybCSjrs9z2KnLaxSZp/DEjyZ1MNAN8R6bD2Ytot6o5jjvDmz CsMZzARlGshyPTGg2VMujMkY1WXN+0Z2XjR0RROf/jl1+b072zt3dsNggFEecerpG5cc3zez/rKj u+SoUMe5vy+8Hqtb/VcvkL0ijmll+vhZzZvQSh1ZeyhWR0tHxj9KNrJKn43i0TGSU0ThHGQx2TTT x0huJvWFGSkooQXFtCCLFkRpVU9eT7TYKE91BGJ0b0Cu8MOcf6l/2RP2j+L5Y5YQvH+VU+yfSUuo FH5CrfoalS09NxhKpFtUYx9IZ2WLPzccyU+3ymNPaqg9Fg5lObUSjVLqkvWu7GB6xKWXaa5EM2SN M5oRjNqoOmaxszHbbpF/fq5IcNUBL5yIss5i/OSUqtZoRY8Gh+EnP1RNM4CrLX4v01AxWsG/oaEi UpzMyC2iuYU05qMxL417aA6huT1Roz2jxz7FvEdNZnkeHJx0c1LF6lO8nFNyqxj3LItU/oNZ7cjN DGe5jaqxN8deV5vcWcFIzKo20+Vjz5i0NjTemMegwVKiS21wZmaE4naVaWyo3uO3qmWdUS/Jo6Mw SWS11e+ReqUGT8AKpyi8Hen0Dzoz4uEUHf0BG88Wo+dtkH+MuU2SDCXD1pmhmUUzZaPeW25CCyhn baGcNYNyG+tW4ZH8MAn3R9xKqImw1kJqWQvApZDvsN5akbiBSaUbrx2RdEmX3fsDUm4rl6adLKcE voDywhl5IzSQtL6USTMzVRnvFXZM/52pS0WKUt7OwTPMFTC4dcmgMG9OJZYM1hTxcb8Ug90S2NHM bwyLr4L7j5XOs6yCebgmHPb1KsWA1nIPoKestLJKbrClB/why7Tbu1u3dxfU73hi/V5Pyeya6cvb S0w6mHPawMz5a8qX3zgv9rVbmlbNDA3MnbF5us9kgj1iWtjQkt2yZsasLR3ZLeVzKwIZ0QydLc2a luGPZjjz+66Yd8pb0JDb0juzCdq9F9p9Rb0Vazewo480NFBDpDLVQ0AqoxukMpqxsKKvyhH6UTLg TjBjMRGGRhNM/wnWPyWYxhMjkiGpJ25DZUVEpS4eoeqjsY5Ai21WDehBdRdzpDC3khc2QsqWntTZ RJ8SF57Rya7Ezj3uwlTU2j3QVr0kv1K28rbBRHtLSxyeMTeMY43WGfalwVLO6Wxry1lx84Kcp93l 85Ph+mRzvGlvY31/VRp9e+eJa1vssdrcTehfVCp4ANTVipWAX6N/zK2O2mZfM7Sz+epV0x15M0vH 7u1dULdyD9rXQmgsLL8AN+9NB9PZ+MKMJsg3Wd1ic/3DUAZRXIpIUFyN0AmkYilPuhrH32M3wOVo TJqLLNSS9nYoaTC3heAZkQ47O+Q/l7CxS29uK8kfoZqDeqht9OUEc0ElJt1Pp9Abc2fjBU5lJRjN xCgdnHApy2FJrU2r6+wvWn7P6ooZW+8dSHQ3Vfj0Gslhtsbr+mp3XRlJDtbVzG9ImNhE7Kv2NLs5 LTvDkdxzaOd1z+2eZvNn+ixOnyMeiuREjj294Jr+RFYiqnPCTyeRZdDL/dhzG4Mf/eZkqGEaNQZq WOusYSNVDbN0aljtqGGVpeYETmAQUsS1VsRqGNIhlbFKkbhJicfVRaxCGZyRFmNNPKCyoFmqh30d aOqqQ5YuLP+iMinVacJRIWZoaIOTU9mpTRCm5sSQJcPGnDLxqJLv19rTXWzBqvXeRSu/sCCndMXt S+dck9S6QqxO6R9rvLypATUINWpGZHqyJZ4mKtCurvld1xxcsePEta3NjZJRzMlGm1F3VuxNNl29 GnWpESaeRAahrXvRqyWw0vp0Mq+osqFyc6XsZK3JGYaWnM5IPrML85m2+CKO0r+hLnx8pCnxtYTE lieOsNZWrkpVPkiljilh3AbJOzgV018kkv/8PtVtKumkir6koipVetHvYh2+95ZZtlgki/69dKWC DfKVHO7TVsb50tcTfNKGzi4BqwcNVBONTKlWaKdTK5/kjlcqCtXK98bTRoeDLVu6k6vai0xao0aW ZK2xcv7W5ObHt9XWbX145Ya7lxU8Jl+2a/ri+kxMfeORzkvnF7r9bq0lzWF2Wk3GNJ+zfvfI7h3H r2pu2v6VfufVdxXOWl3Fxrls7L++Xn0pLIFVwx4ba4BKwwukei0mld4KRDF4IJVuDGbNx8PFeVgr fCnpYD7KbMOZylZ/7ExxW3iWrY1N88+UNqCJJU6VKebeqUQZ1m2EqaNUFbfSY0MPU2Yw6OZF765M 7lXS9fBUabTuYG4guzxseQGjntphfUGHrgnuEN2VNhszk6+Mtm3siM7MMukwFjq9FrXeqPeVddeu 0Nr9zqzwuT9jtQfjvFEnu8NZTr9dO7jkhvm5ZqvJqfj7oQXVSfVlZDnpOdzamtmL3uPj4UITbP6P k6F5mY5MB6kpK9SdWdja2zbnTENL1FN0pqYtd1b6LJOSVeQVmUWWadGpslNsalD2VqntrVIsPLM8 T3Qjn5XjKabvBZnnE7nJmyN80sCiVSex3uEO5fg7pr/ARjK7bUIjYxdfqJustota82e6DVAOuyuM u+roXdmITTS69cxMsIXTodc1W1Z+Wl2fVl3f4HXzc616FXTnDGdA0Wu2LFg+GcfaJfQpH4U+naSP NB5sxi6NTXBohKDUvm7seP046a4szu9u6zpT1xrOP1NpVVe2xWalsS6o4eXTWDmGLuFGhA5f/+Dl t16crDapWdPkqvxU5/UF2gui156iu1KPWz6q98SDGXGvweCNZwTjHr1DqOozlNa6vsmTnxWAF02C 5uz+7PTmWknrT1P9ND3GnhBLT89O0+vTsj8pmaxcn9aWohmVTm8w2nz2cLpWp4WaAz7e9v6megpt bzUZOJjsYOaAaXU0SspXrza19JcR6OmQx2aajQ466V7alWwra6ut9RScSW/tIKYznjaN0mWzioc+ hbU3rrKXTyFYBqD+QXOTzoEL9aMSpgFvjKnaBSfk1FqqmAa8naZWXOx0g9DaRONr3QgrKQhDVNbo sN7K2moZ+t97dA7mtHTo/sRmbQ7r25Vtnux0txYXwYsQzC3ytK5KZsiFn9aa0jytZlbFprbmV4UT 7lVeUccMg0v1Br3a4nNkZNosek02/BcS201SMXanfJP8I+yZmY0zIC8l3Y6CVjZutuowHLSGbU46 q7WsAfMeZtNCKiMm5JtHWVKDdg5o0mx10FlzAiprsVym1bLxAcMresCTSTNIQZk2ENCWFahYr5ks x1BB+tmf6A/bcFt/XnbSCJltLdbK1R2/MfW+43Yvq5bfrWvLC8/8dXXHol+H56SW/BsUG/jMq9yY S5SdTiROJbzoRZiLwQ4Lz3Y6gf8S4hfvU5hzVPH8xOIa1HWPN+X3EetiVTCYsY+F/WZdqccL1xCc QRMGMtskEIvHLXAWcQPwJqf1qmh66eC+2VUrAw7vjMo/N27pKSy/6LGtG+9dkW+LlIRLikqzQ1nl i6+aldsaoja7fWxs9WBxa5F39aKStiJv79Lud8O5Pv21l3Surg/IO6KhrAVFsy/tzc/wOAqD0ULJ IEWmD0yr39JXkp0cKI/UV5elpc3Kn74slj04s2v3vAK9LjL2weK14er2nIE1oaq20SW1DZIurSA3 xz2jMaO4nrWae9G3PAxbu5RcdrihnOZNLr+mhqop67KK5e1kLcsb5ItszJTiK22KIWBkaQa+vgav ONxxmmMFHVktabMUgwiNygHzOrW8xM3r86whuzIH0WgnW5nwSdv55NYtP4xGoFjRvsL24vq9TbxN OLXCuG69rX3hnlmRNNGJSNauJU1Z/X2jN4uYqRZ1Z/v0NTctZ33sdeNnabe6CGtoEfKFYw3ROdHN UdnDhmdkEXLSPwFXBMJK5YUUfgxlGPecwB6+dCz3KJr69PJOSqVY3vnoqCHE9sXggyv1h9Ns7Yp+ Xj2TSDkoU7Yis2w+vQLnZB0xq4yohbT+QgU486fVJhgmVCBfi3kEhmuTlhbX5uXWAMjx+Ctjd9JV yHEW/OnXH5pTynYqKeY/5N9ZO4bkphrI+2wDRTb7Jl/ChAaqXAepaAWSWzUgihpYX5s0pKWR0kKW x0Lk8VBOqB1L1qqDaqWVIqf2srJUZk/x3CKvau56Tbn3lGY0OdE6L9vdweSq1nCBT6+islav1US9 kaKgRfSkTAd5iWnT8qyr9sxL6Axmu8PMdiSoXQVt7fKBT6uDt4O9aAfl5O6kqaGS5pbQkqSDdmHC 85JisoEosynI95h2lDCUUnICJ84ziSmlg89fq0bT8HsKCghTCW8inkyjOqc9vcUumge8nTB5sDWp yKZYeaVvKq49aGaiGvxHC5x7dc5MfyDqs2rGrr2wftB5OkcaFpwzYatYx56lm8xGxRENR4ee/n3M /Olmcu4X9BKDWS/DTNabfLaxZ8ey7e5U30HroTM3SSrrzpuVdWel7k+pG6kqMVFH6EeHDbYWpcKn KsBn1vJP1+yJCj3ZglNvoX4Js5a55L1kwMFWl5W9QTHF3xZXnG1bemjLlH5MeSOElaUFRaJIIJVa rfRvwaAHzT4YLOWrmayb40uaSjdnQP0+Npf5zufWY+6sNIIpc2jlsQgrXYMicXv8BI72lxIb1Qx3 dsAg1iTNMzrqWwqq2wtgqqW6R5Q/mzWKVYqa1CoF7N6Ue5P1lsoHSab0Csxtc16X+amI1LqeO+Ug 5A4Lt/ol3pU6da78psKa7c2s9WCtVOvJbyys2THRs2oc6V5Phk0769b26oGmYltBd2dr1oJL2kMT 5SFFay7oYz8dAwezEVVIb9Tt6pvjL5qRU9KU50TnO0uMQSjBUnJX0spLkBVjaji6sJRSoxBXO0ot VZpoXoGg0QZLgm8CYbbD1J0g9KNjqYGJDUtJQ0FHXlpWu1C9A4qfGJkSqVWylLb/J12fr9rPH54m lPilrv9leDpPUVDQMjY6Mf/OG9AQWyF9IpnekEtzHDTXTmNmGjPRmI7GtDRP8dcqq55QAqRS/yCV bgvy/FVRNv0OFhmoYcpyK5vpT1lufVYysJWfY1bStQXFhJ1mdNjagbVFKeUwg8oGUzVT7D1ifVXq R8xOxTRDuMiE+0d+o3b7N7dt/vqmyprtT22HrHo6UL9hTvv6pkigYcOctg1NYfrHTcev75x5xeFt kB2Qe9uvXlFTvvTqro6rl9eUL7kaurl37C75FeiGeQv3MW9hpPIzdpPwEWpyWwkzYtzcUai4DJX1 L+4z/ExPYbttzud6Cj/LUfhpE8b9+Y7CO5bkNM1IZomuGpXF5Q44tLmzuroLVuxnjsIyxVHYEm/a 3Vg/UOWn717yrWtabZnl0bF64R9UvYvGhe26Rv1lefW57lnXPrOz+apVdc7cxpKx+3CeaNVeVpOW QVv3p7R1fTIAdYWMCda/JZhHjCtA6eQSzBuWh/NxSrUpS1UnSKWXhBS7dJX2h9248Ia5s9uN0xMh lQ1DvnrY31HNvGG2Ljbmf7Y3jDmkJ5yrFVhZENa2spIhKo77094wPbMCQy5tbkdbe5ypqHTl7Utz Wppb89iGble6Xfspj9jYYaEpejq3JmoVXjF79rTcjUJ1Y//ibjHuYoVbTLEMpMehsTKy8vCWChqz pnp8SCXrkLxyMcKsRSuzgh2pDWds2Ys1K+LHqJGd1Cc6YlZ3uN3NZptKd68M+LwRTVUGm1d8hh3M K5FGelzS6HU6b0aWO624ojY6peYofXX2jNqaDHMkK8Okkqm8whO06/V6natwVtXokBjgJzuaayqb 4lZZZzDoLYr/pnv8jPQictxOXkyaijobOud0Xtn5TKd6ytKyMuYpYXSzkCcPwSxWwuh7FIkOfMYI /V0yxNeXWRULsCqWWl5GcoB10YFn8akbtknIgAAxJREPE+pkMobnNZieMUmmwterDH+2z7Uvs2+x y3wZ+bdsDbnD8w5320ONfAE5tXyMLfJTlveLUkv+3EtoYbv0/uPlY+nFsiVXzy5e0FzsMajY8nCi YX51XlNpIJ6c29edjOf27OnJaqvNdWOqLmOHkD6zsr0oL5nrzkn29PUm49TSfDHK25vmygo5YX8G wgFHtDI7Vp4TykzUz6+rWN6eb3K4bSarx2ZPs2k9aR5ntDg9XpETzsyrm8esm8j436SNqm+SWrL4 cC6xRwtSDVGR0CmkUhaQSoNUJJRYwCqhyWsuOBNtyzCf8baVMOtbq6xznDnNBrsyvmJaevoUd9bz HaD2C/0an+PAkDbqbOHcQm8LXA5XWB1sg/DlYg72NvOhwT9R1erNSnfp1Hq1atFUhwL3GX6+9yGV b5yzwbdwyMCRnhkzSleVsQylzU6PlZLSTPwz989e1bZkiaYsNvtMf1sVc+sY2rryZ6W3ec5oWlPL OcyTyNw5yK3iR8TuqNMpTyJzJaY6mJTrJuVyn+qvUaoLVpLhVfwM181nqEquheu0PbORuU4V702i mDla4WFVXDY/Fg11LDFFOZ+vSfnYpGdVcd04jJ/jh53qu4nYJ3w3F6p6fJzVKPlv6iIphnkfPo1C aiV8HYXXNPl3qGkzyPThohkwkj46nAgGE+jNPk6a5IrEjDZb4sy0ijY2jTuU3aXnSxyn4V6kRaWv v8VdZEyr8A1Ojn7/ueaeCHpggXrT4IYeK/oPtRPwn/vSRH/m/g91wPOq+rnqV/AVLkNeLcjrcGJ2 P8tpyDzTnI5/pCIxj8xum9E2bVq4rbhNauu3JM5UtGHzhWo4u2vxlMbE6tgpLLFiKC06xVyF8DSx XXisnkEdsB5TLesCVSje1IrPam+T24Vx+IQdR1F8+hMVUPVznZ17+xqCYzOmaAoLGdZgzme3Sfqc mBz/SWmdlrcrWye8h4syIjaLIeXum6JFu8tuNpuFH/DCukSp2AQxNn6hA5HXM02vUs/KeD1TS6Ke aWZA9xvIhuFQ/Rylem0o3WDZMDi4wSIH4KD9eHhmCXwIHw1nB3pZu/au6mqbVd9W0pZIhKuLq6Xq OSRwJrtNxQrBzXs0UQSK35Z5ut+Cnw8OP6UgWKX8TxvwFN3Dwfe/VmS6eor+dfbQ5/SIk9qXGjO8 KIk0b9ilHSuaUgaTZSoXTimC/6nfnFoAn98SpnpyKbmLrYjK38Jc6w6sh5ZTY5yNzHE2MsfZlry4 YvzF2fwLR0o+PkrYNJeEUqYNpDLaQH6keEUYYa4hdoGIUHxFcGx9jG07Be1xozqtHRNe9eSyKLN7 xBx3Yqhmxs/ETEssi06sh/ItPDi3IByCWBB1ZLi9GXZN1z3KlErr4ktY3qK24vo9zVgYZb5y/cQk dVff7Lq1N62QMsU8dPSfc5Y2Zvf3STtFDOsFM+EP3QP95JP/Po7DgJglsE06IWUXT3aIBjkJUsX1 h4wre7khxVZeMSF1pKxDOxSTrMIFVZit2WncRnPUNDMHEdMzaVYmjTCKM05ZERpWYsM0K0zjVnpJ hEbYcqDe7m6LhGENIfROUg/zKhKGqcRCzA0F+X7ShGdEctojRn+7kRuW0K/iOiKJQWVGlhjEzqHB hLKnRklQdhIl2BRNO7GZeuIAiOR1equcfL4i76GSLI2dVpn9OcFgThr2D72oUrNtv96MKE4Wjqnk TySsgwe8QbtWfkilN5i0577BTg6qdBaDvMDk0MvoJyT80o/6TSbpT3qMjZLOyLRdMX5WfS203Uze OI7tjCeT05E17HjA3s9qWsVkNnYKRWgsTGMhGgvSWAaNp9McFc2Vae00Oq2WTiugdfnUFsZWMXw8 V3HLMoltC4gI4wk22OVKNJNJ7JjtsrJo64x25TqmzAbbHNtm25U2lS3p8LTZytqz22tvy6f5LC2f WaM2p6dtbf6ufKkZsd5Zytj3CvSZGDzV0HAauuT6VnReUkzYBDi1fQkMyVA0NiilNm3Jce2UXVti kjNF5VOo+lqVeuxD2ezNCYby0kzytyXpGdnsx06uOEJjH6tVbMxMz3To5F9L0vOS3oFqj33a0msS fVXCblS/Dwdk5Ye0LutkoUi36PWj2yeLyOrS6o0oIXgAR/16PUoIq5g4Daob9YmQpIMrgJJctI5O lFcRuf44KYFi7Kh52OIGJy/rMaYVUh/q41HQch/FyRqlb2BNRYnyUD2rrXlIJuyeOkKro7TSSI1h 5rZhpWI0lhTntrPdYO3CK8p6C7uD8oV+qJYytbP/8AuHYJXNTGzv7uQZ2MndYU6lEvPdYY06ZzwU jGJz2K9eUxndmTgKa6d66hv7UEed8XBG1GVQnX5JZbCHAhnZDkk/9nG+xWlSw+uppavHvgIhq01O Cz1GH7c4zSpZY9COHaRzIGSV0WUdW8J6D8yu90I/WaTnOAkgrxXIZlWA5gaoj22aYJveLJUWKa6n fjbVqfXTtGrIaWk01J5mcLYbOlVzcP4c64+YHbJ9f8glq0ms8UZkvl+rysnOucTKJ/b7OZUFKY9L K5Vdqikp9Yftkmav3iaPPaezZQWDmS69mlL5I409M5yeZdeMHbHZ1SaXhdaoHAZ5sdtnwe43q3m0 UHrVaVSz1T/kZADOgtfwpboEmXac2JATD9trHlP2ahchvVzfpJf02XY4gw6ltVkxVsAphBdnq83Y 9Th4Gv1O6lgOO7LCankVPe/QGVtt01K2LVV6TaOz6EZfdQdYl0FvGbvS5mRnWiSV0Y5tUIgb20kf wwZVTQuOkmnTI5kWjyfNJm2IZOPEoVZj8djDFp/Xbxu9B6f2mJeDyMeU1Rwjvi7gwgcjpK2HNXqZ 7S544zRGHtgDU9dQaLdYMxl7RnU6tUQydhC5zBt7g24nb+LrBIZhozed2F4+zbeLa7W8MVc5Rful 2zUWr/0mtdmZ5rR7DVR1ndGX5U/L8hpvDZUXFqS9qDVgSoBGRZ37AmGbRmMLszc9Mf4hvUW+W/Hs BQ4SHHHYc8wQjMIvacXbnm7A68KcYS+cmoukBsAJCzsVprfo03JC4Ry0WF9OOJTD1tLPD8vhcH7A aAzkhzMLmCwYzYnwCHyRBB2zH5+8oORLeJ9NyLGReA+yDconj6JVQncYVvAqie+y7E9ZftpUVF9X yLCxtaiwGWDPoGNvywb1d7AuoDtoU5Mi2F/elLpSR7G0T6jMrgx3WsSh0kiDKrMz6MYuJpX6AzM2 jWrNTrNmj9mqh7ZcZjyvmR6WCqXp+IaD5TDRGs9gu+MZrM7zUlTqFD+3LRU67GNLHPihX0VtUdOP 48FQLBbU2P34wMXHY3eqyLgP33iwHiFaw7toaGwafOFjPCpis5+bbnc47PL3bfaxV6PhYDQzM4z3 uG7scfoP9c34WkRm0i2zDk9mLgxZaRSyO2S8jjQUobzQL+HdNDDcHd6JQ/qFstIG+KBK/7Z0cOki NbVkpDn8TpNc2VOdHqrpKaM4O+vxptsk9YoXxgZefW1s4U9MdqMax/3Ua37+q9e3bv3dr3+xFl81 QOeDr/5Qshtv9DbeKELKjhMH3E94J1geiueXySOs0TqwGHOSdcDwQfE3TJTyV2QtkBUM21Nb6ago l+Ix7tD2ehz07fTq7krZhJPa/gwzVS9esmSJSrKle904Hiut3SmlbX39Vz9fg91EkhrN9Mf08dde pY+/oLfhzLdGozo9Ngfv99zYSSmg3oWT3JYjaT+y+p9nRVd0RpSc2KTNOgE+y2HzHSlgtYwTk8dh NDo8Jko02GxktTz6KJNj5yIBtHGXJsF6ApzVwyaQs3Uaq7LLeOHYSXo09ddsP0qzPq9J/TU1azwT s/XJKRf7s/So0eE1jVvgADNqH32Uy3GT12E86wrAZROxe60a9an0sN1rwzJLAB/upORB6X55gfpG jIO+pCWYE4oXebVWm8ZgjBpR3TH1QA6xJVmjicedHtZcqpxaDTs4UlWF72NUVVZ6vTK+k1Hq0cpV lR5UEq1WbrdIXm+G6ZV0OVxYGJbTXzYFvV5q+eADC8VeBNPLIv4VU4bXK1k+kB/XROM5Dv1Xxs5a baiHmq/oHTnxqOaiDdpoPO7Q30fVNvyMfXIf4mNR7Qa893TpE/n7qo04qJGHQRwNnRAn3ZQ0pZeW Rv5uyfun2uNBey0rsp15+UwpqjL/zIfSdpEL9jEAPmtNdXoafv4CGQlKWvl7UkHL4uLilsrc7Mys vEBmUdCcGXalWdWxpqXVRa2VeVmRrLx0tk4Le9Zv01CVuWlNc9QdzS/MCTmwHyHqMGLLqzbQvL41 y52ZYLH+oiQW8pjtiL7yIsxdvo1T1+Wkjdx7nHTA/vBapa5lHTSxs4GuaaCNDbS8gWY10IYRqTHp MqWnm3ZX0A0VtLOC1lbQRAWtQMJRLGaw5szMQjRftmp9DI8hxTj1OzJ+Fp5IqctUO15crI7hI1jD zoGmEeo+qF6a2l7C+p7EII4cDA6+xQy9QcXzoTD00xiueU/NnIxsE/V5Z1K0F6wBpHYsyt8uv/ix rd17F0/PtjkK5+x6bFP2rGS+RauSKNZcjbHKrrLB6/tyZf+Mrvkl628biD3trVw4M7ujucEfaVjS kFxSn0Ef7Xvosvacjov3f21J75MP3ry2Tm91GM1WpwUL3zqL3TJr3zcWW4M+a83qm5bVLp2ZZfaG HFc9vb6guBsf5pFJD3T7LM4SsUM8rfTq46SSTeiwE7ES3chh1o1UMMJiFMJiykWMQliMskyACaMi odt21vOwImqnxeI5CmHb4qfGvMl6rmL8L9mSaa4cpT/NUSaiKc6OuOWMSL6kP2iNBpELTLiUX0FX 0FCtXF/NJkvuDEwflBtTkezG6melRriYXz7ECnmy0E8eSp1gSu2VPsl896yrVLZszsTrJg0sTzOL 8VAWVOa3ClGi2ZPw9JmsqtkNzJozVExXF4ymDTSPTlQWrOenFsiUQ02JVEBxEiUSEHztiP9mtUdZ 3WUztKkDfhUfPLgzCH12UJb5Thm2lOatrGSfJxE7jyrlZ+u2PnbRqgc31eZ0bmquW5yMlKy8d82K Wwfz2Ubq1s2d8V9lVPdWXLw5ULOgbvXFeZnNa5salk4PXXftvmvorHnXLCzM67m0a/qa+Z2Zoebu xZVNu/rLiro3NZQtmdcejnb0LZWW5jUVp63oizfW1YTKrxj9amHnjOmRUP3M9vzlGy5CO21DXXpe Oc+ZwJp82gVLldliqRKu6pPJbFY7CuiURUi28u5i/ggXKzwX+0yM64QE44SEuYs7jLJgDRdSWYuC VJwSkO8wawXzZxw/KkjqDeyoaJLIbDkwqccdRYY5Bokos2qEcGZZqRBs7QHEQPDVT2zENeCYKDtH KY6JsrkHXEkoEljhtrfYrANbx7jznC0qoB/gP1NLTOkRywvh+WOdZpBtd1fJzxdtHLpq9+NrEsUX D+3bAzlkCSTquor7Nkz3BGesbqvumw77Tdp/978PLl/wjQ8fvutDRT61/L5L+qrS5n7hWxff/pN9 tVmNS7Zdh+7raTTbh9RefP3qj8msrCDNyqBZ6TQaoFl+mpWWOl+TqywTO9j8Cs0NO+2YuospYaol ucyHgBRIRaGKhPYhFYVCKhO4XHbw1BLEeSUcXzOy30a4NZTOE1JpV5An2aOmxJ9k7gmEoXrc8TC+ FOWE97ThULQnF85lLT/fXtowepotIis/p7FPj29vTvxA0SzhDguuXsU5NHmcDaO/hm/Gq8rmvapb 8ZbKD2nwjY/RxVqTUaPBp0qo5Szb84jTfXqapzI5fA64hTTv6Sx6dRNbk9Ha/PhaiV0v/+pug8oc 9Np9NpPmOVmF3ejYHP7JrXoYj9D2Nmj7ftTpeuxRMOdW0kSQ5mYwj0SSqVUZhpLUw46bYJMpeg0P U5MH1fBoWTb+kZqUrmuexf/8wwhlQTlGKDFpRE002qtrwuEaVL7Co2UeTWGvDWvNOUJD6CWwvsW+ 5cKcOm8lTrPqqFRApcNQPA3nKYe5bi44zoORmplY6Du0ykHA+9V6q360wuK2amWD1fTJgvU1jvSK ueXKYR5MdVX40I9v2sBF05bcMljoab1+82mpDOe61B3slKPWFvS4YJyYqWHxHZeuSCS6ajMzczJ1 jqAbC1kWd1bUV7F4d3P9nluf2faq3qGsKa5Fn3AH9NdP1cexneFkMp3VxIW0RAeVlTAzukTRWwnT W8mIVJE0zO6NzZ7tg+cLKn4nGcMlMeaQSSI2lpQtAXYnX0NU7gywO7GdVKmyAWj+iOJkQHPHLja0 b0uqykIqtR3yZNKJYrBMS+Kx05hraFbRNKpUZUQwyUeAafZpdg8OGBmThvbe/H+Ew+p2doDVOHGA FdvXbRNnWNF1s84C/T3vI7gjGjE4mTXZz6c6C42yjU/pH/D1lUJmpaa8cKmjrVPPZE0WohsjwB31 O568aMbW/lqrTiNbzPqK3s1NM1c1ZSZ6L+vag7LSaowW/daZ69vj/vLuitrls0oNzIeBuYSztm9z cuGNiwrC9QunNW6eW0C3Ddy6psqdEbJYMCvLSg9nhzPr+0qr+pOZaB5uZ5pVm5kcqMpprwxFc6Jq a8Bj9dotTpRz4bydrdPXd9cYJW3FXNb3s5N+v8RJvzz0S58ka5n7roDG82lWnGbFaHY6jQVoVOmg sn00G9/P8tCYm8ZcNGbD0jrNUtMsFU0EmLlwMungvVWBxwfiYZ0YfElKv8PkMZSdJ70Qp77HzyUz cIWNNT9mCuMXujEbG0RsbJpmY19+ihMV76twBOUl1vzYkZSkAckqVXFRPIA9CyhgVSJisxkiPQZ2 dB6WnaOmDOs7Kf9TIrVmmsAnKtgGYnbMCUP2FF+fGAuUAylTDmKIfkt8oI31VR4ct4zIv3Q57hBf oxh9z2QzY7Zn0NJfqJ3B/GCkJGi7w+4ee0QaW0Qfp1sisbH3xXoXtWlsQZ8zmOY1yw5sbcAn8sz6 cz+MSu+O1rIeazVa3D04eVxPvps0x6tovFLZKCQrPZZilCVpVapXgsRX7VD/q9hR4xyoPgeqzGHt Iscyp3Rz6ZWlculnf3jgWXxdgWAcYU0MZcZO/2DrA9gxZuM5nT40nPykKb/2n2F2ZlGd340PGk1p OoM48s02uFHbq6kWc2rwZd54uHKZdidbC5+fTjYOxRchvu/EpieR1FZh+Z6WfQcvrrt4XiWmb/A+ G7WGvNb1bY1bugvj3XvnT++PpftCGdJ0ndWgdjnGMqLtxZsf21xDH1731c219jSfxWT3O+z4chHO KIab1nbUL20ImfzZkjUS1qMTzMoZu1stVSzfj5Wu1LwE/9efVqhiXNjSCLfBaqH4kuTF8lGVB7NF 13BeVpB9sMuE/3VDUdnp0dPso35swoDFwZSDB59mSnUB561F4UMvRzUGfEJgBGey3a4MfKNqRG82 aDDa6Wi7zo5vm2BiDmaGvyDpxHe5cLrbyD7dZfz/xsGYA9yDKAw6qwvIAg6MsIKO8JoCFAONQMUx WjDPZfZk4AWOcsluYeBjF+Xew8gFPHhTEEhKAHvQ14AdHuOz4DEoYPBCVh4D58YEQYEN5zHPFef/ C1zHICLI9EVIBJnNzKwhL6+hoqT0Lxw0gaCqpAROncAzQXewKAJHBng2C8kIAHvqZ0Fja6CwYGeE 1+yMjKCWrxmwiww6t2cHCxsX25/33AKcLMBxC26m1r/1wPEiJuDmB25mES5eJjtBaRFu5n8loHEV 4Ji4KA8roy2jKRu3mLIscAiDie1fMas6MELAcQIa4wQBNgY+BoZw70B3x0Bt58SczKSiTABiWrM7 CmVuZHN0cmVhbQplbmRvYmoKNzQgMCBvYmoKMjAyMzIKZW5kb2JqCjUxIDAgb2JqCjw8IC9UeXBl IC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1BYREJVRytDYWxpYnJpLUJvbGRJ dGFsaWMgL0ZvbnREZXNjcmlwdG9yCjc1IDAgUiAvVG9Vbmljb2RlIDc2IDAgUiAvRmlyc3RDaGFy IDMzIC9MYXN0Q2hhciA2NyAvV2lkdGhzIFsgNDk1IDIyNiA0OTgKMzQ3IDUyNyAzNTIgNTI3IDUy NyA1MjggNTI4IDQyMyAzMDYgMjQ2IDQ5MSA1MjcgMzE2IDM5NCA2MzMgNTI4IDgwNCAyNDYgNTg1 CjUyOCAzMjUgMzI1IDUxOSA1MjggNDEyIDQ4MCA1MzIgNDY5IDYzMCA0NzAgNTYzIDYzMSBdID4+ CmVuZG9iago3NiAwIG9iago8PCAvTGVuZ3RoIDc3IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAFdk82OmzAUhfc8hZfTxQiDSTKREFI11UhZ9EdN+wBgmxSpAUTIIm/f73jSqTqL Y/Fx77XPNZf8+fDpMA6ryb8tkz/G1fTDGJZ4ma6Lj6aLp2HMitKEwa93Su/8uZ2znOLj7bLG82Hs J1PXmTH5d0ou63IzDx/D1MUPevd1CXEZxpN5+Pl8TG+O13n+Hc9xXI3NmsaE2LPd53b+0p6jyVPp 4yEQH9bbI1X/Mn7c5mhwREXxaslPIV7m1selHU8xq61t6peXJotjeBe6F3S9/9UuWV2WDcl2b1gC S2lZWpsq7znvK7wqSiW3wZS2+C/Z2VdDXX93UhZNLVm7qRrOc6BkCyeseETW7lJ0AyJrt0+KbkFE tBTuQES0Fz6BiOhGuAcR0Z2wBRFRDNZlByJrKy8MICI5YQQRmLbqQQRGkh2XKYFbId1I7KwWHN1I RAsh3UhgENKNBO6F2JdA9euwL3E5nRD7Ephqse9SC1U6CPsuXf5Wt+GwL7FVqsW+Sy1s1K/DvoRJ ea6wL9G+zq2wLxGVq4ohkDhXO3NaEsl8BUbo78fUNGnq36bUX5eFAU2/RppdzeQwxre/Z55mbZD0 B/uq6Q8KZW5kc3RyZWFtCmVuZG9iago3NyAwIG9iago0NTIKZW5kb2JqCjc1IDAgb2JqCjw8IC9U eXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL1BYREJVRytDYWxpYnJpLUJvbGRJdGFsaWMg L0ZsYWdzIDY4IC9Gb250QkJveApbLTY5MSAtMzA2IDEyNjUgOTY3XSAvSXRhbGljQW5nbGUgLTUg L0FzY2VudCA5NTIgL0Rlc2NlbnQgLTI2OSAvQ2FwSGVpZ2h0CjYzMiAvU3RlbVYgMCAvWEhlaWdo dCA0NjkgL0F2Z1dpZHRoIDUzNiAvTWF4V2lkdGggMTMyOCAvRm9udEZpbGUyIDc4IDAgUiA+Pgpl bmRvYmoKNzggMCBvYmoKPDwgL0xlbmd0aCA3OSAwIFIgL0xlbmd0aDEgMjA0NzYgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB5Zt5fFTV2fjPXWbfl8xMMnvuzGSSSTLZd5KbkJ0ACclA QlgSFg3KJhAFFEVti2IVFXGrVVutVbFlEhSD2opKtVapS1Grdat116i1Li3C5H3OfWYgQW31fX9/ 9PP5DXnme9Y75zzPc84959zLhnXDy4mGbCUcKVi6anAtkT7hA4BFS8/c4JOixAHp8rtOWXvqKox7 XYSoLKeu3HQKxrNXEhJaNrR8cBnGyVFg2RAkYJwpAQaGVm3YiPFwAfDylWuWJvOzfRBvXzW4Mfn7 5GWI+1YPrloOhM/sp+Erd+265cl8ppcQu13Kgq9TSQWfCp+gnhAGYgHGR4zkr0RBWGCUDBCiszJR wkMuzZfdOHYLM/f0xYaaz0m6EhIIuf+Dc56kfGzb7Zcc2XjsUrVH8QDoRwVXwA/UU9x47CVC1Dcf 2fivJ9UeJWGuT+YhAiMqboy9ZdRZ4h1jfzKaUQq4DLFuNL0cYmcg1iIWjDoqIbEfMR8hjNqrITET 4Uf4EF6EB+FGuBDpCCfCgbCP2pq9Y8xfEa8jXkO8ingF8TLiL4iXEC8i/ox4AfE84k+I5xCHEc8i nkE8jfgj4hDiScQTiD8gHkf8HvEY4lHEQcQjiIcRDyHuG02j/XtqNC0G2I8YQ9yL2Deatgzy7kHc jdiLGEX8TgJXMurN845xxYgiRCGiABGVbMvlY0w36olCBY0E9qtRdwEY7gjin4gvEV8gPkd8hvgH 4lPES6OuYqj+IuLPiBcQzyEOI/6E2I9t0aK73Yt4FvEMYh/ibsQYuuLPET9D3Iy4B3Ej4nnEDYib 0Ft/jLgUcTE62I8w9kPEGnThSxDbEKsQKxGnI07D6jFEH6IXMQ8xF7Ed0Y3oQvwUMQtxEaITMRsx E9EhgTNgrB0xA2GTnIhNQ6xGzEFYERaEGWFCGBEGhB6hQ2gRGoQa0YNQSWAOoNc9iF7nQV9yI1wI JyId4UDw6G4cuts76DZvI95CvIl4DD3kUcTvEAfRCx5B/ApxF2K3BC4DDV6G6ilFLJVazdmwEWkI K8KCMCNMCCOCweYSbO4E4hjiKOINbO5fEa8jXkO8ingF8TLiL4iHsUcPIQ4gHkT8FvEbxAOI+xH3 Ie7ATt+O+CXiNsQvELci/oYK2YW4CnEFYgdiJ7r+lYjNiE2IjYizEJcjzkQMIzYg1iOW4OhYjFiE WIgYRJSgVYoRRYhCRAFiABFF5CPyEBFEDiIbEUIEEQFEGJElgWPRhXPRhb9AfIb4B+JTxN8RnyA+ RnyEGEd8iPgA8T7iPcS7iHcQbyPeQnyOeBPxN8QbErg89LpcRASRg8hGhBFZiCBCQGQi/AgvQi25 KadCKBEKhFwC+3f0yE8QHyM+QowjPkS8j3gP8S7iKfTIPyI+QDyNOIR4El3xD4jHEb+XwIUwNoqu GEfsQfwacT3iOsS1iCcQd0rgZOh8VyMuRGxFnI84D3EuYjm64l7ECsQQ+sspiGWIEUQTohXRgKhH iIg6xA8QFyCuQdQgahHViCpEJaIN0YJoRlQgyhFKyVFYBWIaQo6QIXgEh0j6PIOxRsR0BEGcLYGZ QCQw8VSMHUMcRXyFOIL4F+KfiN/iHeE3iAcQ9yNGRq2XwPolLoHdggY4RwLjER8zNni/1Ld6vwD5 XNfufQPkryCva2d5fwdyEOQRkIdBHgI5APKgZq73tyB3g+wFGQUZAYmD7AH5NcivQO4C2Q1yJ8gd ILeD/BLkNpBfgNwKcgvIz9RD3ptBbgK5EeSnIDeA/ATkepDrQK4FuQbkapBdqrO8V4BcDrID5DKQ /Vw31ymq53ovhciPVcu99SpuDtdJhoiX60IyPx+1FIEmfoa4edQMK2rmJsQViMtHTSIk7kBchrgU 8WPEJYjtiIsRFyG2IWYhZo6CcseYDsQMRDuiDdGKaEE0I5oQjaOGJqg+HdGAcCNcCCciA5GOcIyC LccYO8KGSENYERaEeRQsPcaYxHnAz0D+AfIpyN9BPgH5GOQjsPhrIK+CvALyMshfQF4CeRGs92eQ 34A8AHIfyH6Qn4OVrgJDjDHXobKvRaxAxQwhTkWcgliOWIZYiliCGEQMIEoRJaimYkQRohBRgIgi 8hF5qJ9chAIhR8go9nOzuVmj1d6SB7lZpBGkB4SbOACJ2bnN+6WA2dY8xvxq1GKFzt01anECdiPu HLUIELsDcTvil9jx2xC/QNyKuAVxDeJqxC7EVeiPOxFXIhYjFmH/FyIWIPoR8xF9iF7EPMRcRAzR g+hGzEF0IToRsxERRA5qMRsRRmQhQoggIoAQEJkIPyrah/AieASHYBEMgogXgiNPgCRAjoEcBfkK 5Ai45b9A/gnyIcgHIO+DvAfyLsg7IG+De74F8ibI30CeAvkjyCGQJ0GeAPkDyOMgvwd5DORRkDGQ e8GF94HcAzLG7EGL/BpxI+KniBvQIj9BXI/4EeKHo6Z8qP4D1N6FiAsQ5yO2Is5DnIvYgjgHcTZi M2ITYiPiLMSZiGHEBsR6xDrEGYi1iDWI1YhViJWIeoSIRqtD1CKmIWoQ1YgqRCWiAlGOJixDGBEG hB6hQ2gRGpyR1AgVQilGwdrjYJEXQJ4HeQ7kMMifQJ4FeQbkabDSTphsrpQmnNNR+aeJq2Em/yEX 9P6Ay/deyOR7L2jdGjt/99bYea1bYufu3hLTbKneMmMLp9niBJy9ZfeWv2yRn9O6OXb27s0xfrN1 M6ve1HpWbOPus2Kasxjtma3DsZ7hN4c/G+aswz3Dy4Y3DF81fBgSFLcO3z18cJgbmzggmocrqpu3 Dl8+zFohnyXDjIEm+4Y1+uYNreti63evi/HrAut61nGVn6xjWHEdM7Bu7ToWCu1dFwg308LOdbaM Zt86cV3nOu6M1jWxtbvXxFa3rop9vIox1qu5GPGBPA3CEQPXQ3ZwPeIES1auXcmqToPersg/NTa0 +9TYKfnLYst3L4stzV8SG8wfiC3OXxhbtHthbEH+/Fj/7vmxvvze2DwoPze/Jxbb3RPrzu+Kzdnd FZudPys2C9Jn5s+IdeyeEWvPb4217W6NdbYyLfnNsSauzEu8DPHA31rPVs8nHl4z4F7rZte6X3d/ 4ubWuj5xsec5GUPGeRk7MjgDfLH4le5N35F+U/qedJlBCnDateatZnataauJLTCJpqdNr5t4YrrZ xBp2GG4y7DFwsw2LDR8bJgz8HgOzR/+g/ik9N1u/WL9Gzxn0NM4ZRX1+YbNBJ87w6qI6riaqq9PN 1nE7dIyoyy9qFnWBrOY67WztYi13k5YRtaHs5o/VE2pWVEOGqArlwZfd2Uw4xsfAsZ4RwCmpLZg0 L0zyZK+NkTFjzOUjPd2RyIwxxcScGXFlZ3+cuSge7KbfYtf8uPyiOInN7+8dYZjL+kYYdnpP3Dqj az7Gf3jppaTBPSPu7u6N3+zumxHfCgGRBiYgQNwjNtLQF1m0fnh9JBJZH1m/Ab43LFoPKRuG4U8C A98QHoYvGiK04Dd/aDZeKLJ+eDHUhmKL1kMSVIcAjdDrf3Pl/6LU/7YWMv9Fuvn/rymOxYvgdFxx IyGJnZNOy9eS88kNZDe5h9xHHiJ/IH8i/2DUcE7/Q/Ig+Rt5n3xKvoIxrWDSGBeTPane/zGYuFC2 iui4A0RO4EnCxJGJ9xJ3TLwHDwT0k1J2QszOh06kTJgnxk9OS+xMjCX+KNcQo1TXyD4BV/uEGZ84 wtZBTeNEGY2z22hY+qVPFDcm9iRumtKBxdDj1WQNWUvOIEvgkcYAWUc2ks3kbLKFnEvOgyc0F4JG fkS2kYvh+8fkUnIZ2UGuIFeSneQqsotcTa4h15LryPXkJ6DNn5IbIf1qiN8o5RIp52byc3IbuZ3c Se4ivyK/Jj+D+C3kVvIL8ktIvQPSd0OchmkIy9wIKbdBGs2lKXtInIwk8zA8SvaSu8F6e5J5qfi9 ZIzsJ/sI8j5yP3mA/Ib8Fqx6AOz8cPJ7P1j9/inp317jSfIIOUh+Rx4lj5Hfk8fBV54gT5JD5I/k qa+lf1Naquy3X+Vp8gx5FjzwMHmOPE/+TF4kL5G/kFfJa+QN8MU3yYeElsDcl8krkPM6pL5B3pXS T9R84XhdLPUalPtr8hpvk3eg/HtknHw06dfwt16GUu+SL8iX4PNKJoNxM3rGQj4n/4S4jrFBzhFG BSE/k8XkMflMlClhSplqpp5pYOZArICcRk4nl4NfXAXWR3+4HvzhLPCjiyGNegta/DYYdXcct/Ie sCm14k/AFvTfg5KtHv4GfR+Cnt4O9h+RbP51Wz2ctMTvIf8P4OHUM1KlqO0fmWK9p+Bqd0q+OEJG wRN+C15B7UutS/OoNZ6DqxxOWgK1+QZ5C3KolWj+nyUbPSFZ6TVJy29C/ttgvxekUmjNF8BLngdb 4hUOQh//CnWfBbs8K5Wi9n4RhJZ5HErdBfmvStd8HSzyAViL2ux9KP8OhB+QZqa3oMXUln9L5j0J OZ/AfPUZWPZj8ncI/QPC9N9DkPIpyEeQ+jH8wj9AaJkPoI2fgB99CDb+FKz+JeT8C8JfwBPUo1Dv RXKEfAUhmvMS5ID9If4VmSAJMgGzIsOwDAfpNEykOkfBy45BSxNQMgGLoWMMx/CMHOZPJXiOmtEw WvAfWlNKwauAV7FQiuYppRSpPPnn8fIGWFOZGDNjYawwD9vgqnrGAHEHfNMcVSqHsUMazUuVT4PH sDQtncmAkAdWZn7yR5jJPeQL8G8XeLiPyYRclnGDnZ9jBPDsMJPNFDDFTCnUCDBB+DXq6bVMHSNA SpAJMVnACPQPPJ6pgZx6ppFpgtwJJpcpg/FQyzRPmV2TEfY6GAHSB+b0P8v0jAzm/4fZWWQjxF8A n76ZdJJesoicJnuXfVJsXrxo4YL++X29sZ7uOV2ds2fN7JjR3tba0tzUOL2hXqyrnVZTXVVZUV5W Gs3Pyw2HggEh0+uwmowGnUatUirkMp5jGZLbJDQP+OKhgTgfElpb82hcGISEwUkJA3EfJDVPLRP3 0XqDkDWlpAglTzmppIglxeMlGaOvhtTk5fqaBF/8UKPgG2Pmd/VC+NJGoc8XH5fCM6UwH5IiOoj4 /VDD1+QYavTFmQFfU7z5zKHtTQONebnMiEY9XZi+XJ2XS0bUGghqIBQPC2tHmHAtIwXYcFPVCEuU OvqzcS7YNLgs3tnV29To9Pv7pDQyXbpWXD49rpCu5VsRhzaTS3wjuQe2/3jMSJYMRLTLhGWDC3rj 3CBU2s41bd++LW6KxLOFxnj25jcdoMDl8VyhsSkeEaBhM+Yc/wEmLgsaBd/2zwk0Xhj/EFo9KWUw mSIPGj8nNJN28bia4sxgKkygbdBC6J/fT9tyyZhIlkAkvrWrF+M+ssQ5SsRopC/ODtCcA6mctBjN 2ZrKOV59QADNNglNA8m/M4cc8a1LfHm5YFnpLxjng5Dvi3OhgSVLhygHl28XGqGHoEvSA9uNRgiI g0llNo0URKH84AB0YgVVQ1dvPCqsjVuFBtQ2JMBFgk0runulKpjaFLdOj5OBpcla8WgT1AUXadpO DUMbSK8ldPXuJ8UTr4+U+Jx7i0kJ6aPtiNumg1FCTdt7l50S9w44l4F/nuLrdfrjYh+or0/oXd5H rSQY49mvw8/BBwwo1YK+nVQ6VRi6HVcElb5e1sn1UWtBgq8ZvoSGGsgwxuUYpRZtqPH1Mk6SKga/ kixBQ1OuAxEuOL0VKgOh6vRWpx+cW/r8myY5sQPQjLjyeJt4aITsRJvwd761aViaNijb17S8cVID p1wUIlIDk1f75nayVBdJZUATlNScrbQPebkshH2QrYyz0E8piVrR4YuTTl+vsFzoE8CHxM5eahyq a8m+M7oFuqWVrJ30kp4pMcyvwLw48c/o6U1FYEPcG2+OSHalZpXiLVL8eLT1pOy2VLZvu1KY0b2d /riQvCDxwQgC48hDbYOXVJhLYLA2w0QpNA8KPqOvefvg2MTWJdtHRHH72qaBoSoYBtuFtmXbhe7e GrClNO63ODfTnzaTGcyMnoa8XJh7GkYE5qKuEZG5qHt+735Yb/su6ukdZWE7P9DQNxKAvN79PkJE KZWlqTSRFvHRCL3SHIgopfLO/SIhW6VcXkqQ4kvhREFKw0KQxpClYyymGVPlWEjjMU2U0vrgAyPM MQQmgHm4ybeMmuecvqHtA310cBEbmBL+mDgj1JI4K9TCIYRcG1cLyxviGqGBptfR9DpMl9N0hdAQ Z2wMKGcM5qTtAwLMU+ByvcTJ9IF3GKn3s0Hf2MRET6//kHO8zw9DYgHI/N64KgL3AVmwHcq1UBmA 5Jb41qWDtB0kBkOdjsy2pX0wFlIXhCJtcRVcQZW8ApRolupQd4RKS8E2YECp/laIxLf2xfsi9Ed7 V9AW+XzGOGkVqsDseE1ZiP5QtG+7WSiijg1F4+rgNgoVtI3A8YqU4oQo/BhMuLRHCi20fKkAWUsH fGABniztBlfHuVRN7QYpy2FK5EPLJVE7k5mEdosLanTquCofLgh/NKzJhwvCn6IPlEI7L8W2JQvA bxvjGmhRaJIqkxVAO5DVRtsCf9ug8bToQ/QyXWNkjrARpkbaaOmnFJAd1wXbBmHyx/oaSBEqUpXh WsogTaLXOIipCtpzLeidC/aMTfxS2ERngNQnL1egNwfqmMS5Hxyb9G0/OSHeH8nLVZ6cqpOSt29X 6r65AupLqTtOuArh6Wt1TxEC66UBmYZUy7SkhFtCavgGUsKfD+EvyC6+ktSCBLgZpJqGuY9INXvR RDuEy/gKEmK+JCHuBRKklK8mIZoGUsNXTrzGPgN5WYRlHyWLZEayiN8DUkHmcQ+R1dwjxMquJ9Xc UcLASk7JXjfxMPRaWvoCtbC/7gT6iUDghTxgBuy3HcRG3MQAe3wZ8REL0ZE0oifpxAnv81mJibig XibUYIka3oM0wzU8cCDrhfcFU+8U3k5uhxXp1Wwtew3n457mS/nnZBfLVfK7FPOVLuVR1Q1qk/pO 9aeag9p52t/p1uq+1F9jqDfajfeY2ky/MVebTzf/xPy2pQhaJoOTj/Xc63BKwMH1q0mMzCWz78mz 5dmUNfVqtoq0EQUTh6b44E1D6AIzIpp5Nlgu57qcOtPaLqarUcH2kLpXXn1l4auvHAIeYqKvjD8/ bjz2/Li5sjIaLSxgTH6TJFY9q1DI5UJmPlteXlZWXFxUy5aW5LNCph4kVFpSy5bXcsVFHpahRbGk lAqFaSr3+tHZXPOxAHumr3Go1cPlBW1es4JJlwkZmmhD2KxzR4VQVXaGXKng5WqFMqu8IbPp1MbM xBO8Uq/SR3wuwSLnVQaNLtufkWlRJEIy/ZFPZfqv5vGNXz3AmcqWzyqWb9JpWJlK+Uu/01NQ7bEG 3SadQafXK1xel0JhNqiFaV3HblS5fG61Tq8ypmk1bq9HrdcqDbZjfrDxwMQH/CaZQCrIivu4Zq6F 9EboyW2sd6/bTYxjnHJfHp/BZ6SpxphNoyXdaWPM2XvF8NxwxFGXMXO8btxElcZExw9Wguqc9/zn soUFfYwVdQWK5NOsHpYqtrjIlmbVK6myQYU81R+/yeI26wJV86e3bx5ojdqFhoGaluUtUYtOxcuV ap1NXLChYdWezQ2hmWf+7NCW5i0Lg/wVrkWV/pC/evDci7ZVNZ/WLHgCHotJ4RKyBbdN8KRVnTl6 1sLHD9x1foe7ALZALPgQ4b8Af3KQLLJsqgZgLmDHRVW6z2s0GA0qeH4ljlq6YBewcq+o6jmuAXAb JvpoUfHhcVDA3n9fUOq8Xi74qU9ZwE380E8Z9SkBHKmW578wCNW9m2589OLEvUa3RSF7Q1kWZCqu f+qSpsSHmR1nLbt4ZPuKHatmFtq4qpofXXLxlpWzc5UWn4Mfys2qOXPPlXUrZ+Uevby4b/iCi8C2 JRNHZF6ZFd7ZPTC1Z6Jd0OoydZkOu84e0KiD0SBR23PmBIQx5hzRK2ocwWgm77ariY4PG7ReLavl tFqze445JovRftfVmSujBPZ2EXul2V55MGPmsYN1TPTpogNFW7YdPGhiih3GR4uMNEx18n+9Mmgt qOekcWjxc6kQDj0F57ckQ3yYNfpKQqEip5obSriGWKO/OJRV6FJzn8O+hGa4VOxi5q1FyWIQE9RG tUwGX6z22GepMP/7VCgRYF5OhUGfNYRwVtCni8w9SZ86R7qe6HQOPae0zEkfY4b3isrjHgIaYqKH DhUXgS7u/fYytJdWPZ/0jeO9K7JxVk6hMVh1x/YYnSY5/yED/cqSOvM0c61eM6LwhnMEmyrNa+Ov TbX2q49s1LvBA/gB8G4v+MAFU9tMvfsjUeuzhJWqLPhntYTHmGn3Wu0WlVKpz4LwPaK9S4/2hqEO Fq+sNFeOg68Xo2kZh1Hy+f0k/F0qou/z4OkpC0r+b7N7OFlJKCsUSo2BgfSKvvPvXL+tmzVmloSC 1IDvqWpyGWfJnPC0wcZA4oP8grQS34a5Gyu7pkWcWu6Zis3DK7qiiSXYe4OGvzQaVSi1RTOWLypo 1itkiTZnbk3D9JRG1oBGCkktuW2qRvbZbUqtLEzGOLmoKwpXuj0V8C87LKscY8pFfXauNuyxqexK hdstVIwx1feKuV1CzJQcEagiGA+V43Q+mKSjY6bKw2j9ke9/KdQaq7DZ7BYbnSLh1pPPZnH53MmK nDyRsPwaoWPTvIL6tFJepsuszsspBm8vUjpzpuXMWQoDA0YD1euHyvIA09+/c6gi8bYlZ3p0V9uW GUOim/tMPHftfKfljCWJf9kErVqv4mUas5bxFnUUpyfMx9V8bW5WZvNpm1wFgiVxRaSxG8bILvC4 C0G/mWRgqnZFDVEqrSqLw2pRWseY9aJKVFn03pSHwSxKZxEm+vwhU7Gp2HgIBsvIvymY8qYT84Ff uiXzMKXa+AvpiEnTJu5/msPB4lSxTyd+a9BAutGq5S7X6vg3Fd5Qdqbtq3HojlwOX7zFZlF6s7Iz 06SxUzvxHp8Oq6wQ3CN23ce1cm0n7o0qt9IzxkbuBretVkJglIQKx9g7RK1FVZ3lhqUd52/LGWNi oxntZWNMzz2ifibXIc2c0k0Tps9KOimMH35lnHaW3kWhv6Lme9Sm00VqcYIDCu+bNjtdq8BtRcHA kJp0hy3nlvHl07xZDgXrMjTMX1XVeZrodBTNWnVpX/fWAiPkecJ2JZt4RohV5DSXZTt1KkfYm7ug c5ren2amy5AdvpaqUMXizdPrdl118Wl1TQ2z08wylUGd+Ky8PDy9d/FgtqcsJ720f1MTHWkB0B+R rSV5pIHcMVV/olljcnu8PqG8otJV6TJXmsyEqk+Vb1JXVmTyimLQnajLaneZTRpeb2/Wd9SAGveK ipmp224dzKp149LUeng8KrnMlm36g/gxM1Sd+773tVJOlRnKkpZzoXImNQ/rOYUU5KW7NawAFTAk pVs2AR2uvnRez/lRA+iwJsIzClbvKwwG851KtkWmNRgU5ulzlxZV9tSGHarEMYU97M/r76zVuUDR 4cbybJeevbDh6qsuGqptmN6RZrFaZXBb0sjlGqM6cb29uChq9tWX+NxFjTM669LLcl2lCzY3bSsv zRLnLl4CI6564n1uPvc8KSVnTNXyPS4XMYVL7mcEWDermfBotN13PxOApbuV6dwrBpO6PHZ4vA4E blG4hnuAlHy3Gsmpic5H6GdUH8mFHKya6QKZruN4br7G7DQaXNm1hSVzpoUzNC0dFZ2V2SY44NWZ nFUdfQW777SXdG+88dRwh1joUHBL7VUlgsOTnt+2cPE8X1ePWwA/MBWX5GX4M4y/umPalTu3nyZq 01x2M/UzOk5XwZPIXFJHdk7VgKj259VlQoYqs5z6lyEtN5PLaoZEFVHK9QV0hLraq75hhFLvkhZ2 dGFbDKsacC06QvXf8wJfG6V8anVrTy1bjg9TSX3l3PLUKHVKo7QyNi3sUDuKYZz2ZrVUF5gWs3ov eFc0A8bqFnCh7KbybKe+qOykkVodBI/p6Mqq37UTPMvkDtuYF1JudayzvCKrft7AQKRjZmkfDFdY B0+8xz0Os10+rHLumarFfTlF5XKeqMbYnaJKMGk9nNUqRMfYHWIWEUwmbdH7OeWPhoncKBflnfIB eVx+QK5wcnK5J6ddOyF6jo/Z1KJxnE54sGl4hS4q7JUQs0vTX/B/f7GULwpyeZp1kh+yislzI0yK JXROZBXUU7nH6y/+05ULeL5nYcOK2SVarVquMWm04vy1VQM7BgrSK3q33Lqi/8Ke7C/raopm10R0 PZ0rGzzsS63ru3PteZauORa7RW8w5UZCaq3DqgvPOW/e9Ot2XXRqbaSlf3q4NDCtO5oWKCTMRHti JyfKNsJu9aapmt1r9pi897Mb4Q5jAnWa2mpaxbZqsc1maxOreZKjHWNCe2e1eGDyC++r9gbMra1w OwntFQOzU/PgQfBSWHzD8D1oh51YNGqCBKOkYarT/UT7nS9xfPaTxjNMcLgnS63Y6BIt5bxUfeWW 1BgvTm6D7TYbJ3IypUavlFscXrMvmulQGn5u0HJKrd6iufWnpur5Z88qaVbDUx25SqNXySHZQEup rlmr1XEKtdGiW20x1vafPSujJMcnl8tkJXJnZsBrkSvk5qzaSIclTe0Lwpbu6Cfd58YiRhjEOrnL Dwksx1rCdXnsJyaH2hcIui1Le7bOjchUWrlMmiXKEjulu3kN6SKvT7WCmBYwZjjZjuKSaTVdnW7X NBdx1UxroROGWZPtKqkhLl5W3ubtmlbMB0Q6WRS0m832DgiJmsDMMGe32NkMzj7GcHtFWcoy0vYI 7lCVUek2Re9XTDR6cPxgEdzw8VZlgvtUJYnQecXw/+5XwIwy6vRfs1dZWfnkwfBvFgoLzB3njJwZ 25Zn1LIKtcGs1QpVc+uKu2qCSl2GRrqbzVzR4MZJ6euLBzoh6bTpWS5pSmL7t/XnO9OUVrPclQmG McHjvUBFdn2vy19f4i1ZcE5rPdz8VtSeWE58Li0nYHbKrMhKK+3f3AR3udDEEe5tWE3Ukx+cZD1j fnqgXkPUgsahqS/hZZYxplc0i5XtQrqaBPLlnuxmT4cMV1/SqoGu1NEYYApcmO/7XlXppI6apHv4 1JGQIrWv+dqagU2zyhXcCtbgLQwFohkq9nRerrL6bNl9s2t1XZBcFAhGYbGQWjjQqR0XDpaG2NKS xkU1TqUiU22gW1WDmrWnlabZgk5DyfyN0xOrU8mTFg1X24oK880+scQfalxUEWihZ3OgPzZXNgvO 77LJaVM1eHe21+qBXQ8jatRej8fqzeYD6YYxZtc+mRhoS0+uW1+dOW5CtR0ep8st8Np7/0NZOqEk 9YTLqFQsdeuDU2hHuCqSU+rklakQl/jyhEZGqM7gXgfK4f8QLPbqdN7iYKDIp9f7ir4qSXWd26w2 0PWSQU3PMoPgKV+Cp5SQy6b2U8wjHJ/DRTy8RWbOsViz4Z9XNHtkFkiU6QraPFZztleWHmhO79BN 8hep1wczwFNw3MLxhgkOOOhAltQg2r/DFaTJVa5gpmzivuYxSdfhvnR6E787pFbqvKXhcKFTx/1p EYduAt7DKHF9Sd3kBmaW2h4oDgWLXBru58aIP/FCYo4joNaatTJebdQyzyfCkppgmS4LpO7/R//O LNea1Dyvkv6PN/WNCGgsjbScpDFjGtGIaqJO0/AyY3NyEEn6oOqgExcMvJMzJw2P1FBgBNbgKQqE qPNP9vLjTn3Ce3Gsy92wFumnO/TJ+y7R3piXl19pt2X6Z2X298NvV2RquttNcHLRK7rEtvaKfD+c WtnyNJn9sxor9cW1bcUdruODPzn6pbMqmIqp/cyVB03FRdAXyZJ7/zfXmtRdaTbABUbKtN+UlNxT 4IaCtWOUzhGym1gD7BwCBRkqDuYIIS88d/Y0OkPQRKq70+SyQG4qMTVt7GV1zojHm2VTsO605r4V FVWxcjdvb+kbKm9eXJWhVB7XMmu359mjVSV9Z01PrEyNHkgstOdWTk3ktqgNKhnd3O0U2qqC3vL2 SKC1KpjVtLBMaAkm5+N3wEZVZPNJNtIWZmQ4Q5yB1wcNcFzcK1rFsnZe7wxmGApDSl+kzdehmjS6 YDam90WciiUr7Cdp36VWckR9d0Vz76gUa5ITCuhypUwWyjt5Cp6qy/7Tq5oXV2ewLwjNwWMvnlCY o8iSd5IWT1JYdvNCujepoXtg0JIdzt/mTdXTg5B/Hxw7B+BbS9xM5qilPXuMESZvckEz48kjtm8p ICkBDg0nHZsnN6ipk3WeJ86q/vNuPXX5ziUFJ0KJo6asablFnXX5Hv2JELuu9dorzhusiPb/cG7r tZefP0BDp+bU5zmyGuYNLM3LaYDQ9HmDSwg78Vpil9S3HNh3nbSuFXX+0jKtrlRX6tDZHbi1j9i1 ZaV+XgGbrh5RF2q36xw+3uxsM8+G47XvtLWHeRdmnH3f+zKTdJQ1yVukM5LkGPzGTT1suMLN1QXm 2fR+hNv5I3xZrTcLTklchvr+VVUzV9S7E8c0sNI5vqGXdmM69kJY01w8VGt0Z9kSq1LTLv8anpdc 4W+pDpUuOGchrG+s9LjkIlzwDCbHlRY8pphsmuovoiVsMrnNLuJ20SP5qJbTcbA/WCwaxbx2s8sU dmfJ7ZltdhxaMEfT5zN0EUpHF71TJceW9j9UmaQtaad0XGMnzVo2TssrtQaLRmW2ZZgyZzaXaztP 3LhHWX1qTnI56lo6ggavM00u5+5SBAqKc+HJlKIkdkZtYk1qTJ0YPpdFWks9sD6SyUEbLOxKFaCN ZnLhVG08QAzsJtg2lbC7RIutGv4RwVAiOpvekanfE9vhIQ3ZlxP9l+iceshBN0ewU6LPrOgeid7A tN+xGupFOn2leoHnVjDCkqexUzdGsCCku3w4CfGwdhunUOgtWp1QND1PKA9Yijt6O4qq1ty0rGBe U4FWqeAUKq1eqc8sm12dPS1sKWyf115YNnTVopzZdVG1hjtLG4XDVbvZ7M1xeHOC4Zq59R3nLyrV WzM0SrNe5crMdJkc7nRLZm66kBsKV82tb9ncX6wx2zTSWmjRxIfsW/wIaTr5BFN0l+VGyiMNSlW9 qr5cFYkUlNvL7aSgobW8vkaZC/vNe1QRf1krLAPn7BX9k7bwleNFhyor4WkPfEejcHQHjiU96THi 05593/kSKU8T4Kjg2zbtx3eZbHFqlyntS6FXCup8j/RwslC2IzPdrFRqlDqjShUorHDV9Nd6WZmM m7dSp1UYM8ynh6Vpn95X2fBDJi23S+0NBNyWxEJDti4cVKgUBpOlIC+oUhm1ivSynhqN2+fXMXtN DlN5aegxGL8yGZzGPQbnwgxZlNgpexx28xeQOXtXrx6ie3RRdXbLcOuG1irPItCcqKpe2F3hDQy1 1oP2Rrtnwmlm6O7AbHNrOOXEkbo6eHZKT5ik7ftBeKJGd4rw8Jk+AcIDtW/agKfcCvff/u+rOP+J jbrscU6u1Ohgo56e2qjfotfBRh2Uesv1pmn953RWzdGqFFqrTmlMcxr9+XSXnlj1/fXN7LTC5c6e nVEU8cphS/9tO/rE3Av7YMOpStOWlGbzcp7u99nPv6+JBmNb56W2/SwB/+ffgF1PO7yRWrGfzGd2 7e2s0sItKHyvLhpsFqtaYbc45+7gTFjaTrHNITxXMb4Mc8Txvd7313eRTWGZsgPiXkp6olPFXZ5Y 8/20CbugMFufk6GYq3BkVefQbZNCaccNFHdikffs99VZIJPpPGlzBX4+D9YuDu5ROA88O6UafDNA dGocpLCmqFAIpDuIxhEoLKoR0lVwROJpg5lj3j2ikeqTPiemTzvw5AOW2AelFbd00mf8btVghkgp //jRRVl5avcoeT++PXAibSkshnO8dDHMOa3N/adVNA9WO1WK1clbE11Dw7LW6oXNd2edsYMxplbR /tSC9wqhpTqQNX1ReWZLkM1OpR5711Zgc2S59KULz2tnLkglg55Ww37zLdBTIX0qPHm3sp/42ZxR sy18P3sHvLviY68UNaItry1T52xL7i/NdCIFJR0eN74i3Y1UJ2dLk6QcTjGTB5lZnHSzwZuLJQ0G dHJMc2/J4Z20lVva1K5wWaBczNQyKxhW5SyOhPPTlUyHrLi7pdZDH4eFgtF0FfcLjc+88sXDTy7W m1SsTJtm5DKNLq01TSfn1SbtsTPSVTNvuDW+RAfPxeA+D/20JnZxb0M/C8jQ1H7uFayW7PvZ26GP mextex0OelT8hqgXLfltgtLqbrPO0EunYvS1gWSHD1VGj59RitpvLHei59ISJBQCy0/pfHGy7zbu bbk8c/YpF/R8pnJmV4UipQ5W97edLK/zlgSzow4Vu4AtmtNY6WD1/rKIWMD9TOczLTj49KtnJW7T mTRyhdFhYiLcfJ1LbbZpZZzaaji2Y8b1N93STa0ML0DCMxZmB9vCLoQdcsYo0Zh/w+TA20XhpLUj UfrwJDl3T3oKybbAdGq06RMDZgOrgJCBudliYAsVnkDQZ01LV3qFoNcM/3UK3r9inuV97E0nrp/9 Ha7P++BppsmmPzrTbJRCBm6v0cQOKz3BoNdqsyk9QshrsdDrKxO/Zj+TbYP3twpFq9KpyiBOXYYz I035gadF9UHarEmTH9yXpEXSoaj0IDbZLYFJHQZLr64w0qN79jNOptYZNdcm3rtGq+Xkap1JnXjc mGGU80ytsszPlNpkyxQZPsFpPrLDYlZk+P1OkxoOvuRFuVlwLv4wtGoPtMpPisU0q19BiMFvNBA/ b/zA1WL4gP+mZkXpcuMQfTwsg6efKW0XM6mzaPpCjYJZpSrxJ56gbVLpzJqrGfvVeg1tKzzDLpPa l8jLslgVGV5okOwMaJrTl5lhUqX54D9bUH2ZQehHDg/LSGdvY0OsJTJ9cOWKJetW5DWsWbmsbQNE lpL/AdrozsMKZW5kc3RyZWFtCmVuZG9iago3OSAwIG9iagoxMTE1OAplbmRvYmoKMjEgMCBvYmoK PDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvTE1DR0hGK0hlbHZl dGljYSAvRm9udERlc2NyaXB0b3IKODAgMCBSIC9Ub1VuaWNvZGUgODEgMCBSIC9GaXJzdENoYXIg MzMgL0xhc3RDaGFyIDMzIC9XaWR0aHMgWyAxMzkgXSA+PgplbmRvYmoKODEgMCBvYmoKPDwgL0xl bmd0aCA4MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBXZDBbsMgEETvfMUe k0OE7TNCqlJF8qFtVCcfgGGxkGpAa3zw3xeIk0o97IGZeTAsP/fvvXcJ+JWCHjCBdd4QLmEljTDi 5DxrOzBOp/1UNT2ryHiGh21JOPfeBhCCAfDvjCyJNji8mTDisWhfZJCcn+BwPw9VGdYYf3BGn6Bh UoJBm6/7UPFTzQi8oqfeZN+l7ZSpv8Rtiwi5USbaRyUdDC5RaSTlJ2SiaaS4XCRDb/5ZOzDaPdm1 UtRpOlvzT6eg5YuvSnolym3qHmrRUsB5fK0qhlgerPMLftpwSgplbmRzdHJlYW0KZW5kb2JqCjgy IDAgb2JqCjIyMgplbmRvYmoKODAgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250 TmFtZSAvTE1DR0hGK0hlbHZldGljYSAvRmxhZ3MgNCAvRm9udEJCb3ggWy05NTEgLTQ4MSAxNDQ1 IDExMjJdCi9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgNzcwIC9EZXNjZW50IC0yMzAgL0NhcEhlaWdo dCA3MTcgL1N0ZW1WIDk4IC9YSGVpZ2h0CjUyMyAvU3RlbUggODUgL0F2Z1dpZHRoIDQ0MSAvTWF4 V2lkdGggMTUwMCAvRm9udEZpbGUyIDgzIDAgUiA+PgplbmRvYmoKODMgMCBvYmoKPDwgL0xlbmd0 aCA4NCAwIFIgL0xlbmd0aDEgNTA2OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAG9 WH9wFNUd/779cXchoSYB5JJw7F6XI7+FRMVAKByXu5CQgIEAvUOQuyQXk5hIBkMqWOiNBSsHUhWh Co5Kf1iBIsuFoRuoNDI66rQq6mjVOqPUX52O1NaWVkWz/by95EoYZfIH4755+/353vu8z3v3dvd6 1q6L0liKkUgNKyLdrWRd4x6FKGnuinQn7ezfQeY29/aoSVsuIBI7W7tv6krajvuJxrhu6lw/1D77 Xfg726KRlmScvoSc0QZH0mbXQE5p6+q5LWlnH4V0dK5pHopnvwHb1hW5bWh8ehu2ekukK5rMH/dD yCnda27tGbLrIad3r40O5bMg8L1EDF6B7qM0upns0DJRVhHZ/zrGRRKiPI7rOl/pF6uvmH2OshyW vXrhTy350qd//+9n0S/z0+91fA5H2nA+l7bCwUKiDIb42fR7UxGrHW6CQY3FBtWizkW9FrW4eJ6T Yuwxugf1UVSR2tk2Wo+6FfVBVCml7YfVz7YlJIf3OFtPuWyBN11Slo7PUZxj0pVXDGY7+rDypvO9 EywHq3eG5STGUtq8MexR9gi1kMJ+RR62gWqogO3pK+xUwgjtp27UGKpo3Rnbn5hcrpxkJeSRGNpM pckSO6Z8VFaqfFBmCCyhnMo3JIinJsPyXqEMuB5Wfu+6STmJejAZOlCIjGPKflensnOywfYklPtc BkObe5NinQtNjyldhbuVljIrXr/bEA4mlJmIL/emKzMq3Mq1rveVafmGg8EuddUrRWUvKFPQEGkq OvV4s5RJrp3KLIQmuwL5s1BPsANsLxWxvQnPAuU4VEy3r7awYrfBbu+rKSjzGGyDd0ZNwe7CmnxP Yb3iKazOz4e+/Dn7ZvsN9nn2cnuxvcA+1e6259nHO7IdmY7vODIcYxwOh91gv0nMVWwn2EGaC1oO 9jlsDtlgT8ApnWCHLOeh3zokh+Agx3jDfBebl9F4gx08msk1KMdslmYz2KG+pOuQV5G4JlmBTIHr uOFOAnMItIB0drdhoy1X9s51zs2ekzWz2v9Nt7AVGb4Xf/PlZC59d11jUD/gCunlXDFdoeF057Dy jbJnHUJRX3Fx3ZL1fb3dHa2BqBYIa4Eoaljf1tvm1GNNqnqko5sHVF2cGm5qbuMyEtW7tahf79D8 6pFeq91F4VYe7tX8R6g1sDR4pNUb9Sd6vb0BLeIP9TX51q4aMdbW1FhrfV8zlo93tpaP1WS1u2is VTzcxMdaxcdaxcdq8jZZY/HJB9obfbf2YHeqgfY6VS9o1GsXrwjqaiTkN9hjcPrXkTxAmfKTVCDH KFeaRgqR+SbqW1wOLjM/lJ+lzMEu859iJRa1n1dhcO5sGqC7aS8dJhs9Dr2AbqQH6HnWgd/2SjpK r7PJdBXOXokMqqc/MtN8mVrpl8jvoVO0i45QBtp00QREdzCPuQG2F3oTbTZ/TlOogu6kJ2kmet1B Z839Zh+iS2gZHaCDaP8HpglHpHHmE+b75KDF6HMzIi+b9eZhyqYS8lEDvJvpJPOIb5lt5KRKoHuI HqF99BR9zO5gR802s9c8bZ7BVnXSJGpE2ciOsjPiYelO8yHzb+YgmCigIowapp30C/R/GGUAR2uA 3cx62E62S/AKdwhHpS3yxMGvwEMhzUepoTV0Fxjop6fpU/qcfSI4xUyxR3zGvNb8F6VTHWbJZxKl XpSfoOzAnE4wG5vOqlgD28juZ7vYq0KRsEwICj8QbhM+FBeJK8X14qvSrVJC3i4/YEsfPGeeMJ81 X6OJ5KIbaC1twuxO0Wn6N33BRPQ1iXlYJfOxG1FibK/Qz/axfqGBDbDTwgH2DnuPfcLOC7KQIUwQ ioUeYadwUDglvCi2i7vEB8V3xHPSHFmQ98kf2Dz2Pw82DW4dfNGsNM+Yn+GIdZAbK+OjRbSaIpht N11DP8IsDqEcxqo9Tc/Q81Z5j02is/QZWCCWzXJZOVuIsohdz1pZO3uYHUc5aWH5j4CFENKELGGi MEloFJqELiEmvCbExDyxSFwgrhAPozwnvi6eF89LsjROmiDNl2ppu9Ql7UF5THpcSkgvyTPlOfIi ebkck7fK28Vm+WX5ddsm2w5bwvaJ7R84Fuvta+zbsTrPY88+hb38/0tiU4C+nG6hZuZnTbQbq7GP RSiO3dXC7gJf3VRgrhI3ifOF6dgNJ+l27NY9tJG2iitpn/mGeID+hJ3SiS5j9GvJRy75Z1idO2g6 dtFQ8RYWFRbkT/VM0b7rVnHkT8rLzXFOvHLC+HHZWZljM9LHpDnsNlkSBUYlAa06rOpTw7o0Vaup KeW2FoEjcoEjjJ+yqlePzNFV3i6C0IhMLzJbL8r0JjO9qUyWqc6m2aUlakBT9Rf8mmqwFYuD0O/2 ayFVP2vpCy39HksfC93tRgM14GzzqzoLqwG9urctHgj7S0tYvxd0jCkt4QeHl9J5xzpVRTbigKUq nhHQczV/QM/RoCMmegKRFr1hcTDgz3O7Q/DBtSSIMUpL2nXgpG0ZLVrLNsNLTWGuRVYGdTES0oUw 7yurWJ+o+fWJGz5w/t8c1gLbLwjqgqc6Eo1X697wNpDLzTC3Itth1TWq6FbYEgrqbMsQCI6xA0g5 3OQzwRPuUPU0zae1xTvCIJeWBBO53lzr8NWpIZjI8eZYRmlJv3NTpRuz7y+dVzqPy0q3c1NSfvTj pP+VAS6dm55+F7JuSYoAxhnQaoFTV5utQTSAreC3aAXFmyvAE64QwzTbgadKF7BnRI8ue2ojeqxx GEabPwku3OFPpOXkWg8hXwj54XjmLKwU8jM1NX4OT+uwdvbjkZ7IkMfmyTxHPMgXOrVXdBYZ1nv5 w9KDWbc5tTa+vr3WmsLWnIELHLA5NRyzPh4P8IagW1dDcOBtsqTOoLSG4BHGdoQMZm4xyO/qxzuq uPpGhEv4Vmv3Y3wYpSVwFLmhXVWiVmPkar5X1Lgar22Jq9VqGzaT5LEkAtF4aBoYbAyCJ1qKEb2h vJQaDYVmoZ9pvB80QXo8hB46hnqAtFzTvkLS9BI8TMWpDcHFQT3mz9O9/hBWAdt3oCGoD2DnhkLI KkshBeKN7c4hzOXAXFaE+NXJXvDuEkMXoXic99kY1Nz6QDyeF+e/t6RtMLrY4R1yGMRTOOUGizWg LYTmzrPWwK25ASvEOb0GW3p4R+Gd/dIMz0jhRsvrgHaGxXDFZWJ45mgYnjUqhitTSEcwPBuYKznD 3/v2GJ4zguG5l2bYm8INkPOA1msx7LtMDFeNhmH/qBgOpJCOYLgamAOc4fnfHsM1IxiuvTTDC1K4 AbIOaBdYDNdfJoYXjobhRaNi+PoU0hEMNwDz9Zzhxd8ew0tGMNx4aYaXpnAD5DKgXWoxvPwyMfz9 0TAcHBXDoRTSEQyvAOYQZ/iGFMPePJ0uPIdjFx27dNkP5pUXUI43JTmbfMwFhX8+4wMaVwa+LDIg 3SkP/m9C4f//+Iik0/h2E/EfUFXyfxnHNIMkVEemQXQaldvQxbehQ9ohRci0t+k4WhEtLz6OnmTI 6WVXZ7mz8lF90g7jy7/IT35RZUgLz+M7HxnWZUbx3fJ1F+JMsK+7pb18enm1lcDwJZacgQ3/TVH9 wqr5NdXFNdHO3mhPe3MEOckoT0acJplDF3ekdKZO4/b/AC4+ZiYKZW5kc3RyZWFtCmVuZG9iago4 NCAwIG9iagoyNzIwCmVuZG9iagoxOSAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1 ZVR5cGUgL0Jhc2VGb250IC9BVUxQRVUrQXJpYWxNVCAvRm9udERlc2NyaXB0b3IKODUgMCBSIC9F bmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZyAvRmlyc3RDaGFyIDE2NSAvTGFzdENoYXIgMjA4IC9X aWR0aHMgWwozNTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgNTU2IF0gPj4KZW5kb2JqCjg1 IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL0FVTFBFVStBcmlhbE1U IC9GbGFncyAzMiAvRm9udEJCb3ggWy02NjUgLTMyNSAyMDAwIDEwMDZdCi9JdGFsaWNBbmdsZSAw IC9Bc2NlbnQgOTA1IC9EZXNjZW50IC0yMTIgL0NhcEhlaWdodCA3MTYgL1N0ZW1WIDk1IC9MZWFk aW5nCjMzIC9YSGVpZ2h0IDUxOSAvU3RlbUggODQgL0F2Z1dpZHRoIDQ0MSAvTWF4V2lkdGggMjAw MCAvRm9udEZpbGUyIDg2IDAgUiA+PgplbmRvYmoKODYgMCBvYmoKPDwgL0xlbmd0aCA4NyAwIFIg L0xlbmd0aDEgNzAwMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtWXl4FFW2P/fe 6iUb6QTI2klX06SRdGIggAHCJJ2lA05EAgTtxiAdQiRBMNEA7tCMItAKKAOM4ILLqKijVDrIdECH KOqMKMtTRscVXGbQ+QZBv08dt9T73eoGieM3759XN79zzj3n3O3UqVu3OkuuWdpKyRQiQd6Wxc2d ZFzZn4J1tixbosbqKVlE5sYrOhcsjtUHL0L9qgWLrr8iVs8Jgj/d1to8P1anH8AvaIMiVmdjwYe3 LV5yXaye/R548qKOlrg9x4+6dXHzdfHxSdrVq5oXt8b8c8fLemdH15J43QZ+Xuc1rXF/hvZJfxpY H0TE4CXoS5pE95GFONmohC4hUv6g5JEJdWk3pTb9ds9j4+emTvrKmms1un/o4xGFUnjpnnmXfrfz xwU2siajmmD4SwPaWSr6L6YaG32387sbMBnZ07mX6KVGcV6PO8tx5Fkxko4DXIyMePIcvWKEyIuU O7xR4epJH1qaWlUsVLQvMagK2gHsBPYBCs0V+bDaQFcAIWAnsA84ApixwHzDqoJ3ANuB44BZ5Al7 RHXYqkaIbLTNxnpTRSadAnRAkAO0BJgGzAU2ANsBs+EnNR3ACmAfcBowk1dkRjaOwdwzI7cbrGfh olKj2hyrNs0xqj2XBmJ86vQYr70w5jYx5jZ6bEx9fnWMjyiK8fSC0hA670lMKe2ryhAZWGQGJt4J yviLlMoYOegBMZQ0gAtM1dB4RXrPcHfp9n1CISa4YDSfHHqfYJGUtNKqRK7zU5RODv45Pxmz8JM9 g9JKt1f9mn9EO4F9gOAfoXzIP6QV/LiMOWglsB3YBxwGTgFmfhzlGMoH/ANK5e9TCVAJzAW2A/uA U4CFvw9q4+/J/DColCsBzt8DtfF3sax3QVP5O5De4e/offyNSNmE0l5D8JTEBUdBXMjMjQvpGaVR /nrk25HIKDfuNDJqrxhGFTRGDIsUjHZERVZkUrsjyj/uUT2OB6pG8aOkARwzOYqRj5IKNABBoBMw Q3oT0psUAu4EHgA0AFkGagNUfgB4DXiTRgFeoAGw8iMRDBPlhyPuakdVBj/E/0yZiPhB/heDv8Zf Nvir/CWDvwKeD/sB/nIk30FVSbAT2tjAbeAlsJv48z3D0x16VRrfhwg6QEuASmAaMBfYAJj5Pj4s Mt+Rjk720gE8ww4eoc8M/ig9ZCXvQofXXYMEVCVxT/wVJJDt6nY397q3bEVVEvf6jZAkcd96ByRJ 3DeshCSJe9EySJK45y+EJIl79lxIkrinNUICifL7/zh8hKNs2pVMrUrl1yJK1yJK1yJK15LCr5WF vlXkHO+JFBYiYtu8npGFjtAeFnqWhWaw0EMs1MpCy1loJQtNYqHLWcjDQnYWymchLwvtZeMRihDz 7hpQneDNYqEDLPQUC3WxkJuFClhoOAuprMwb5c7IhXjqwHwG66mSDx139vyqArtPKnciok7kvBN7 wj7Qw4Bu1LxwUofFnLPzJR/WU1gZq58/sbSjagrfj4b7cRv20zFAwQ3ajzTaj072o7tU0EpgLtAH nAJ0wAzvYVjHBoOmgpYAlcBcYAVwCjAb0zmFqXDqAJVT3GlMrAS0Epgma3w/yjAUJ3d682x2m8c2 RWyws9R8Ni1fz+dllJGBvTk9zZoWZSm7v0n59zcplFCVwNfzDZSHG3FnnG+IfJvniLK7I+69jqqh 7HeUryDr2ARyswLw8dRl1MeR3Sr1Y8nOnwQvjdgvQbPUiLvIsYcNkq12O761f+L4zB7lED+173W8 pUYVFnH8FZondzuO2tc6XimJWqF51h1lYHtUw7XXPt7x1AHDdSUM2yKO5ZLtdtxsn+y40m4YWmOG y7tQ86Y6ZrhnO6agv1r7PIe3C33udlTaL3dMinmNk212O0ZhCp6YWIjJjrQbg7ryjQ5nlUVZm7fI ssXit0yzXGAptRRZnBaHJc+SaxliTbfarIOsydZEq9VqtipWbiXrkKh+3OuRb70hZuPlZ0ZCM1IM 2YYdhsltBpQ4s3L6NWmDRT2vn1nN6rW+Fqqfp2pfz3RFWeL02ZrJVc209Hqqb6zWxnvqoxZ9hlbm qdcsDZf5uxlbH4BW42uijBr9UaZL1apcLb3G30uMpa1alyv5eavWBQKUlbGsMqsyvSJtQl3tL5Cg oQzWen66sn4SPVmePG1L/Uy/9kReQCuVgp4XqNd+O1Nt8veyL9lpX20v+0KygL9XVLAvfTOkXlTU BgL1UXaJ4Ucq+wJ+yBgw+FnzSZV+pFrzY37bYn4FaA+/4ZLBLyGBCgy/goQEw09h0q+7a7ivtns4 CHwyVeoyfLoy1XN9DhTApwAEPhkhOmD4HMgISR+twujGbodLPghcWA7ZDRc7yzFcjJl3Gy4lcZe1 Z13WGiOJ2GwMH0nQTcrxMz4px+FzTiD/u9ha7fGwnvJAS5Ov1eULunytQFC7fVlblhaap6rdLQFp UDXhDs5raZO8uVULuFprtRZXrdpdbrT7mblJmstdtd3U5Gv0dzd5W2sj5d5yn6u5NtAzuWFs2YCx 1p4da2zDL4zVIDsbK8eabLT72Vhl0jxZjlUmxyqTY032TjbGIiPHG/zdVqoO1OD+Sd7DkxKRr8Fc Z6A6w9ZZYSRvuTNree4enFZ2UJInoCW7qrUUQOZ1cVVxlTThmZKmQVCnxk1Zy8uduXvYjrjJBnWa q5o8S5Z2LaUsX3tt7K8LF1RLlspbEaMeqfvFCy4+zdtcK8/W9VrhzHqtcvpsf7fFAm2wNgDdxDO6 pCRfVO+LKc+HcqJ0FOKso9RNkrqEhLjjf+aCMSeoEZ1eHDT29jBvPltCXQGh5dc3cmwFjbMRhqbZ /j04S8mXRFcAC+xiHtZ1pje5DkOmmIaw7K4zWLI0LsVjsSTODdcuD3m6zoTkTHceGSyDGLFa4sHW ZtpD2UCO6THKVtyURaSfAPBdpJ/ob9c/lXbJ+T+x0UXjINpBT7F2eor20QvsNFrtpF7aRfIIVEv3 0k20iVbjtTYbmrU0A8UE/SaWre/Cl8mDeGE+SAfheyktpz2UwbL0z2gFrRJvoNUqSqFhVEUN1EHr 2EX6UmqiY8otVEYX0VXUyUK6X1+vb9R/T49Qr/iL/iMlUQ61oBzUPzf9TX+PitFiM22lY2xjwjPk xSgheN5H19A2MUdh+gL9O8zASddiDgpNpYOsj3vQeyudYFnsJlGDXh7WNf1FeNlpDrXRNtrDxrHJ 3Glq0qfqBykDY1yHXrdShHajROk5eoclm07rv9dPUzYV0YVYzy46xPpE/48r+ysRNxOiNJImwNJB f6I/0xHmYs/zDlOyqdTkNd2gH6UhNJpmYbaPoeU/2Dd8OcoK8bJSp1fTIMTlLhlteok+ZDmshE1j l/CRvIPfL64hK0YcjTKf2hHvu9H7B0ij3TyZHxYPK08q35vz+o/rg3BH3HQP3UfPsxSsVGVd7Dfs TfYxr+Fz+T38I7FJeVx53dKMVV9Oi2kdPUnfsHQ2nk1nl7E2dhNbze5iW9lBdoR9yqt4I7+SnxJt 4mrxnFKNMlPpUm4x3Wa63fxpv7//xf7/6f9GL9Vvo+nIh5WY/Wa6HyvrpcP0Nsox+oiZWBIbhKIy J5vFbkRZztaxh9gO9jjbhVGOsI/YZ3glfcW+53jTcjPPxeFHHoFc/BqcMDfxe/lhlCP8X/xbkSmG CY8YJyaJgOjArFaLO1GeER8qOcphRUecS01bTNtNO0xPml4wnTYnW36Dd/xrPzz8Y+GPH/RT/5r+ Lf2R/l36hzQU9xBvD3yCTcLsm1EW4n5vQcbtpDdYMmKXwwpZBbsIkZnLFrKr2XWI5K1sG3vEmPvT 7FlE6S12CnNO4XZjzufzcbyaT0O5nLfyq3EY28h38Tf5d8IikkSqGCoKxWQxR7SKJeJ6sUVo4jXx vvhIfC1+QNGVRMWhDFPcikeZrMxVlir3KyeUE6Ym06umv5sTzYvNt5mj5i9wqqmwNFimW+ZYNlh2 W45ag8jO/fQM/REZePZix8VK4RPP0Ho+RsnGJ8wh5PNcmi+mcmQq38HW8JvZLj7cdJ25nJezi+m0 4kasX+bb+de8XExl9WwmLeSjYx2ahyhPQJqk7KeTyrNY2yH0fJ05mS3np8zJFMEZaQLOSC+JUYpH vErviGPMojxI7yqJLJOd5I+JBmTBc0qFyU9OcS89La5mN9Mz3EeU+L31DuTxxewJ7AuNrJT9W+g4 Bl+MLCoTH9MtdCX/G53Ec7yGfsfmKwtoPY1hN9EJehRPxUjTVeZC81D2Cm9Xwnww20VceRyrm8CG M2EaQreyOWKb+RR/m5bSYSWRPhB/wOwP86fFVOW0aQZrwxNwM91GV+sr6XqTX3mdLSDBLqEC5Th2 t5tEqeIEX4FdpQl72m483XuwD1SJqdBkIXMuQl7Mwg6xDeVu7BMKMqgdz/il2MUO0S5zI4/SAtMg hl0Hv9S82j+DZuuP0lZ9AV2lb6Ri7Aer9ZvQ4w76O22gHWxV/43UiU/Jt/FsX2Sq44dNdXoxD/O3 +Uy+ZeD9RbQLWBb9E+Vp3JkK014KK2/RTKrU79D/iuw+DzvsVpqHA+snWOXnGGGK6KMx/Rfzbr1O dGK9x2i6/pjuYInUpi+iafQsPWIxUbPFg3ussdex3huplc/Ql4jW/nbEYQOi4EW0lmL/WeutmdVY 5a2s+NWk8okTxpeNGzumdPSokvOLizyFI88b4S4Y7hrmVB35efbcnOyszIyhQwanp9lSB6UkJyUm WC1mkyI4oyKfqy6oau6gprhdU6YUy7qrGYrmcxRBTYWqbqCPpsp2zTAN8PTC84qfeXpjnt6znsym TqJJxUWqz6VqB2tdapTNnu6HvK7WFVC1k4Y81ZDvNOQUyE4nGqi+rLZaVWNB1afVLWsL+4K1xUWs OymxxlXTmlhcRN2JSRCTIGmZrs5ullnBDIFn+iZ2c7KmYIlajqvWp2W70BTdiAJf83ytYbrfV5vr dAaKizRW0+Kap5E8KXkMF6oxhtHMNZrFGEZtxxlHo9vV7qK+8B1RG80LepLnu+Y3N/k10Yw+fFqa B+PWapk3fJL1UxWd40y2+lxrrgj7stpV6RwOr1a1B6b7z2mb65Q9BALoA215QV0wXIeh78Cdqpdn cY2vCvg1tgpD4mBZYKwqtr7YqbcguFDVElzVrrbwwiBuTU5YoxnXOyM5Od5e/Tjl+NRwo9/l1Cpz XYHmWnv3EArPuL4n26tmD7QUF3Xb0mKB7R6UGheSU84VWhH0mM2QDHcp1c84G1km5+i6ECdBTW1R MRO/C2saL0nreAq3jMcNwBVgaKXNxx1p1xJqgmHbRKnHEplmKrC51PBXhAxwnfzXQE1zXGMusH1F 0ijz5Gyqaaz5jKx5PFphoUwRSw3uKeZYYdTHFRcti3KXq9OG72f50UANiG1zYGIJwu90yht8e9RL 81DRQtP9sbpK83Ij5C3B2ZoHpaXvjGXoLGkJnbGcbR50IZN3ye9ZGqpZ3Wf/Um0Zg31tEzWW8V/M rTF7/UxXPY7Gqi8cjGdtfeOAWswuA4q4wRaXtME1fpHLoZMSzxWGNXZCPuOC47I/WVMK8Gc2knp+ 1GJFVhoaptZptuCUGA0kOp3xZ+b/ahTVT8tWBvupWXwZ2kRPfKKxaWvlA+oDppccFvWN2HI4Tvbh cOIAG1ItNssL4wwZjw99p1qj0Sw8mQX4wyfHeIlAruZFyGBpxFNkqAO58eoAx9x4owAumZ3FRXXY M8PhOpdaFw6Gm6N6aJ5LtbnCvfwF/kK404fdLpY4UX3P7bla3R0BRKyNTcTjwam628XWTO/2sjUz Z/t78ROHuqbRH+GM1wSrA93DYfP3qkReQ8ulViqliyorVM+wyAi3Gv65vV6ikGFVDIVRb8GvG4Yu 5gQdo5Yoj+lsZ/w4dEpM5zV0cn1yj6lp9Mdvi5EQ8tFDDuE/NOiGH6TFSpcu/x/DUOSVDMM88Edw Oo5pDPX/I+FGX0OpHG91vLLkId8k/xNjIXKmOdMKQPBrEf2gir4fvCb6nlSlT85vMTvC23AWSiJH Lw4VM72DEsyvqTQKZ9ylyZc+luWxfT3nJJWcHD1q8NgLxpTiDWl2DXMv3tzWvnlze9tmfqh906Z2 yOhL/4EdUDr4ZRg135vKxhHPMakYIlvpuSHLc7Htkzm2f1DJVHQlxjmHKkoXO3DXXXLasbmTPgLn 2l+6BJSrcW6R802Px8+M7xCqmnVRg2+Wp+qa9uZFUxv/F0EjHbMKZW5kc3RyZWFtCmVuZG9iago4 NyAwIG9iago0NjY3CmVuZG9iago4OCAwIG9iagooTWFjIE9TIFggMTAuMTAuMiBRdWFydHogUERG Q29udGV4dCkKZW5kb2JqCjg5IDAgb2JqCihQb3dlclBvaW50KQplbmRvYmoKOTAgMCBvYmoKKEQ6 MjAxNTAyMTcwMTA1MjFaMDAnMDAnKQplbmRvYmoKOTEgMCBvYmoKKCkKZW5kb2JqCjkyIDAgb2Jq ClsgXQplbmRvYmoKMSAwIG9iago8PCAvUHJvZHVjZXIgODggMCBSIC9DcmVhdG9yIDg5IDAgUiAv Q3JlYXRpb25EYXRlIDkwIDAgUiAvTW9kRGF0ZSA5MCAwIFIgL0tleXdvcmRzCjkxIDAgUiAvQUFQ TDpLZXl3b3JkcyA5MiAwIFIgPj4KZW5kb2JqCnhyZWYKMCA5MwowMDAwMDAwMDAwIDY1NTM1IGYg CjAwMDAxMDcxMTUgMDAwMDAgbiAKMDAwMDAwMDM0NiAwMDAwMCBuIAowMDAwMDUxOTAxIDAwMDAw IG4gCjAwMDAwMDAwMjIgMDAwMDAgbiAKMDAwMDAwMDMyNyAwMDAwMCBuIAowMDAwMDAwNDUwIDAw MDAwIG4gCjAwMDAwMDE3MzAgMDAwMDAgbiAKMDAwMDAwNDUwMiAwMDAwMCBuIAowMDAwMDAwMDAw IDAwMDAwIG4gCjAwMDAwNjM4NjAgMDAwMDAgbiAKMDAwMDAwMDU1OSAwMDAwMCBuIAowMDAwMDAx NzA5IDAwMDAwIG4gCjAwMDAwMDE3NjYgMDAwMDAgbiAKMDAwMDAwNDQ4MSAwMDAwMCBuIAowMDAw MDA2NDIyIDAwMDAwIG4gCjAwMDAwMDQ1MzggMDAwMDAgbiAKMDAwMDAwNjQwMSAwMDAwMCBuIAow MDAwMDA2NTI5IDAwMDAwIG4gCjAwMDAxMDE2NTEgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBu IAowMDAwMDk4MDg4IDAwMDAwIG4gCjAwMDAwMTgxMTggMDAwMDAgbiAKMDAwMDAzMDA0OCAwMDAw MCBuIAowMDAwMDA2NzI2IDAwMDAwIG4gCjAwMDAwMTgwOTYgMDAwMDAgbiAKMDAwMDAzMjE3MSAw MDAwMCBuIAowMDAwMDMwMDcwIDAwMDAwIG4gCjAwMDAwMzA1MjEgMDAwMDAgbiAKMDAwMDAzMTYz MSAwMDAwMCBuIAowMDAwMDMwNTQxIDAwMDAwIG4gCjAwMDAwMzExMDggMDAwMDAgbiAKMDAwMDAz MTEyOCAwMDAwMCBuIAowMDAwMDMxNjExIDAwMDAwIG4gCjAwMDAwMzE2NjggMDAwMDAgbiAKMDAw MDAzMjE1MSAwMDAwMCBuIAowMDAwMDM1NDU2IDAwMDAwIG4gCjAwMDAwMzIyMDggMDAwMDAgbiAK MDAwMDAzNTQzNSAwMDAwMCBuIAowMDAwMDM1NTYzIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAg biAKMDAwMDA1MjA3NiAwMDAwMCBuIAowMDAwMDM1NzYwIDAwMDAwIG4gCjAwMDAwMzc1NTggMDAw MDAgbiAKMDAwMDAzNzU3OSAwMDAwMCBuIAowMDAwMDM5NDQ1IDAwMDAwIG4gCjAwMDAwNDIxOTUg MDAwMDAgbiAKMDAwMDAzOTQ2NiAwMDAwMCBuIAowMDAwMDQyMTc0IDAwMDAwIG4gCjAwMDAwNDIz MDIgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDg1NzExIDAwMDAwIG4gCjAwMDAw NDI1MjMgMDAwMDAgbiAKMDAwMDA0NDI2OCAwMDAwMCBuIAowMDAwMDQ0Mjg5IDAwMDAwIG4gCjAw MDAwNDU3MDcgMDAwMDAgbiAKMDAwMDA0NTcyOCAwMDAwMCBuIAowMDAwMDQ3NTExIDAwMDAwIG4g CjAwMDAwNDc1MzIgMDAwMDAgbiAKMDAwMDA0OTE2OCAwMDAwMCBuIAowMDAwMDUxNjYwIDAwMDAw IG4gCjAwMDAwNDkxODkgMDAwMDAgbiAKMDAwMDA1MTYzOSAwMDAwMCBuIAowMDAwMDUxNzY3IDAw MDAwIG4gCjAwMDAwNTIwMTIgMDAwMDAgbiAKMDAwMDA1MjkzMCAwMDAwMCBuIAowMDAwMDUyMzgy IDAwMDAwIG4gCjAwMDAwNTI5MTAgMDAwMDAgbiAKMDAwMDA1MzE3NSAwMDAwMCBuIAowMDAwMDYz ODM4IDAwMDAwIG4gCjAwMDAwNjUxMzEgMDAwMDAgbiAKMDAwMDA2NDMzMiAwMDAwMCBuIAowMDAw MDY1MTExIDAwMDAwIG4gCjAwMDAwNjUzNjYgMDAwMDAgbiAKMDAwMDA4NTY4OSAwMDAwMCBuIAow MDAwMDg2NTY5IDAwMDAwIG4gCjAwMDAwODYwMjEgMDAwMDAgbiAKMDAwMDA4NjU0OSAwMDAwMCBu IAowMDAwMDg2ODE3IDAwMDAwIG4gCjAwMDAwOTgwNjYgMDAwMDAgbiAKMDAwMDA5ODU3MSAwMDAw MCBuIAowMDAwMDk4MjUzIDAwMDAwIG4gCjAwMDAwOTg1NTEgMDAwMDAgbiAKMDAwMDA5ODgyMCAw MDAwMCBuIAowMDAwMTAxNjMwIDAwMDAwIG4gCjAwMDAxMDE5MTQgMDAwMDAgbiAKMDAwMDEwMjE3 NCAwMDAwMCBuIAowMDAwMTA2OTMxIDAwMDAwIG4gCjAwMDAxMDY5NTIgMDAwMDAgbiAKMDAwMDEw NzAwNSAwMDAwMCBuIAowMDAwMTA3MDM0IDAwMDAwIG4gCjAwMDAxMDcwNzYgMDAwMDAgbiAKMDAw MDEwNzA5NSAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDkzIC9Sb290IDY0IDAgUiAvSW5mbyAx IDAgUiAvSUQgWyA8MTAzN2ExY2VjMzJkZmQyOTFhZjlkMDEyYTgyYTMyMjE+CjwxMDM3YTFjZWMz MmRmZDI5MWFmOWQwMTJhODJhMzIyMT4gXSA+PgpzdGFydHhyZWYKMTA3MjQ1CiUlRU9GCg== --Apple-Mail=_25799639-0E67-401E-AFDE-C0E316E8C0B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 09 Feb 2015, at 20:50, Rene Struik <rstruik.ext@gmail.com> wrote:

Dear = colleagues:

Just a quick reminder that we have a 6TiSCH = security conf call tomorrow, Tue February 10, 2015, 4.30pm EST. 

I have not seen any = email traffic the last two weeks, nor any more feedback on the draft = document I posted on Fri January 9th.

I put as tentative = item on the agenda "time latency aspects" of the join protocol. I will = send out a more definitive agenda tomorrow around noon EST. Please send = agenda request to me prior to that time.

Suggested = agenda:
1) administrativia {agenda = bashing/minutes}
2) time latency aspects
3) = AOB

= --Apple-Mail=_25799639-0E67-401E-AFDE-C0E316E8C0B1-- --Apple-Mail=_4C17C210-6AE4-47C5-BEBB-21D310306111-- From nobody Tue Feb 17 05:26:06 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6C61A8956 for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 05:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 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, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, WEIRD_PORT=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 IMdzzHRNkanm for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 05:25:59 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 B54FD1A8876 for <6tisch-security@ietf.org>; Tue, 17 Feb 2015 05:25:58 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id hn18so29706208igb.2 for <6tisch-security@ietf.org>; Tue, 17 Feb 2015 05:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=3IeRRXNn56G3q0oLaLpFWPi4mjMloyYHyo1NTRsk4N0=; b=jI1dC4CL/bgEEgd0Zgha0uy1o/x3feBcMSzoU4jMtIyoTPP3NG1g8DLPHn6+0VS4S2 P0A/l3fvBzU0rNYRrkMbTTrj81KXqzbwV2kOVhXzOsAXupI9F12vm31N+pVgcct6WDGE 5L813Gl8pLGu6t6Ypj6+ofvKlcMYAzQypMa3QOvH/yYH4JK1nUNO0BoBQdRFm0UQ4muC JT/1ZXYy9ctqyRw/+C/V46u6kTLEuLsLLzqwL8yRzP53RXfCO53M/BnsU1t0Mkl2ZiEe aTJ8IbtGCLDTHhFpHe+8cPNgBqgm+H/oGRWhVDfo/uQYW73dUootcJ7GLTgsEck3tRbt dEAQ== X-Received: by 10.42.151.67 with SMTP id d3mr34826769icw.56.1424179557892; Tue, 17 Feb 2015 05:25:57 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id w31sm11239124ioi.32.2015.02.17.05.25.56 for <6tisch-security@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Feb 2015 05:25:57 -0800 (PST) Message-ID: <54E3414E.2070201@gmail.com> Date: Tue, 17 Feb 2015 08:25:34 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: tisch-security <6tisch-security@ietf.org> References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> <54D98E01.4090103@gmail.com> In-Reply-To: <54D98E01.4090103@gmail.com> Content-Type: multipart/alternative; boundary="------------090006060800040203060906" Archived-At: Subject: Re: [6tisch-security] Reminder -- 6tisch security call *today*, Tue Feb 17, 2015, 9am EST (includes dial-in info) X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 13:26:05 -0000 This is a multi-part message in MIME format. --------------090006060800040203060906 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear colleagues: Just a quick reminder that we have a 6TiSCH security conf call *today*, Tue February 17, 2015, 9am EST. As you may recall, I put as tentative item on the agenda of last week's call "time latency aspects" of the join protocol . Thomas Watteyne volunteered to take on this topic for this week's call. Suggested agenda: 1) administrativia {agenda bashing/minutes} 2) time latency aspects (Thomas Watteyne) 3) AOB == The schedule for the next few 6tisch security conference calls is as follows: Tue Jan 20th: 4.30pm EST Tue Jan 27th: 9am EST Tue Feb 3rd: 4.30pm EST Tue Feb 10th: 4.30pm EST Tue Feb 17th: 9am EST Tue Feb 24th: 9am EST Tue Mar 3rd: 4.30pm EST On 2/9/2015 11:50 PM, Rene Struik wrote: > Dear colleagues: > > Just a quick reminder that we have a 6TiSCH security conf call > tomorrow, Tue February 10, 2015, 4.30pm EST. > > I have not seen any email traffic the last two weeks, nor any more > feedback on the draft document I posted on Fri January 9th. > > I put as tentative item on the agenda "time latency aspects" of the > join protocol. I will send out a more definitive agenda tomorrow > around noon EST. Please send agenda request to me prior to that time. > > Suggested agenda: > 1) administrativia {agenda bashing/minutes} > 2) time latency aspects > 3) AOB > > On 1/28/2015 10:16 AM, Rene Struik wrote: >> Dear colleagues: >> >> Please find below the minutes of the 6TiSCH Security conf call as of >> January 27, 2015, 9-10am EST. >> >> Minutes 6TiSCH Security conf call, Wed January 27, 2015, 9-10am EST >> {note taker: Rene Struik} >> {recording: not available (Michael Richardson had control, but was >> not on the call} >> {discussion material (referenced in minutes): this time, no posted >> collatoral} >> >> 1. Attendance: >> Tero Kivinen, Yoshi Ohba, Rene Struik >> >> 2. Agenda >> The suggested updated agenda was approved. >> Suggested agenda: >> 1) administrativia {agenda bashing/minutes} >> 2) prep for IETF-92 in Dallas >> 3) AOB >> >> 3. Minutes >> The minutes of the previous 6TiSCH security conference call (Thu >> January 22, 2015) were approved. >> >> 4. Prep for IETF-92 in Dallas {more of a 6tisch security various >> "varia" discussion really} >> YO asked what happened with the output of the join process overview >> text discussed during last week's call. RS mentioned that Pascal >> Thubert included this in the 6tisch architecture draft (Section 13 - >> Security Considerations) and would issue >> draft-ietf-6tisch-architecture-05 for WGLC some time this week. >> >> RS mentioned that at the IETF-92 meeting in Dallas in March, the >> 6tisch group would presumably recharter and include more >> security-related milestones into the revised charter. He thought it >> would be useful to have a 6tisch security draft by that meeting that >> could serve as baseline. >> >> TK provided some more insight into the 802.15.4rev effort. He >> suggested that there would be 1-2 more letter ballots, followed by >> the start of sponsor ballot around end of March 2015, with >> anticipated conclusion of the work around July-August this year. RS >> commented that this schedule seemed quite aggressive, considering >> historical timelines of IEEE 802.15 efforts. TK mentioned that >> according to Bob Heile (Chair IEEE 802.15) the 802.15rev draft would >> only be available in the 802.15 private member area or to those >> people participating in person in an actual IEEE 802 meeting. >> Therefore, it does not seem possible to make a draft available to >> interested parties in the 6tisch community who did not meet those >> criteria (as previously suggested). >> >> 5. AOB >> RS suggested to cancel the 6tisch security call of next week and >> reconvene two weeks from now, which was agreed upon. _Next call will >> take place Tue Feb 10, 2015, 4.30pm EST._ >> >> RS mentioned he had received feedback from Kris Pister and Yoshi Ohba >> on draft-struik-6tisch-security-architectural-considerations-01 >> (posted January 9, 2015). Before updating the draft, he would like to >> see more people give this a look. He invited people to use the now >> cancelled slot of next week's call to review this draft... >> >> [call ended @9.23am EST] >> >> >> On 1/26/2015 12:15 PM, Rene Struik wrote: >>> Dear colleagues: >>> >>> Just a quick reminder that we have a 6TiSCH security conf call >>> tomorrow, Tue January 27, 2015, 9am EST. I expect this to be a short >>> call. >>> >>> Suggested agenda: >>> 1) administrativia {agenda bashing/minutes} >>> 2) prep for IETF-92 in Dallas >>> 3) AOB >>> >>> The dial-in info is below. >>> >>> Best regards, Rene >>> >>> _B) Dial-in information:_ >>> English : New York Time 6tisch security >>> Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00) >>> Meeting number: 641 709 118 >>> Meeting password: joinjoin >>> Audio connection: >>> 1-877-668-4493 Call-in toll free number (US/Canada) >>> 1-650-479-3208 Call-in toll number (US/Canada) >>> >>> Access code: 641 709 118 >>> Meeting link: >>> https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6 >>> >>> The etherpad we have used is at: >>> http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt >>> >>> >>> >>> >>> On 1/21/2015 10:30 AM, Rene Struik wrote: >>>> Dear colleagues: >>>> >>>> Giuseppe Piro offered to give a presentation on MAC security >>>> aspects, resulting in the updated agenda below. Dial-in info at >>>> bottom of email. >>>> >>>> Remember: 6tisch security call is now tomorrow, Thu Jan 21, 2015, >>>> 1pm EST, with duration not to exceed one hour. Please call-in on >>>> time and test your speaker/mike beforehand. >>>> >>>> Suggested updated agenda: >>>> 1) administrativia {agenda bashing/minutes} [4 min] >>>> 2) 6tisch security conf call schedule moving forward [1 min] >>>> 3) input 6tisch security to architecture draft [15 min] >>>> -- RS to present result homework assignment of last call >>>> 4) presentation Giuseppe Piro re MAC security [30 min] >>>> 5) prep for IETF-92 in Dallas [10 min] >>>> 5) AOB >>>> >>>> Link to suggested text (item #3 above): >>>> https://drive.google.com/file/d/0B2a6Ilxu1XfCbVhfd0ZONXoxc00/view?usp=sharing >>>> >>>> On 1/20/2015 4:54 PM, Rene Struik wrote: >>>>> Dear colleagues: >>>>> >>>>> Due to connectivity problems, those on the 6tisch security call >>>>> today concluded that it was best to reschedule the call. >>>>> >>>>> The rescheduled 6tisch security call will take place this >>>>> Thursday, January 22, 2015, 1-2pm EST. >>>>> (Please note that this is only once; schedule moving forward will >>>>> otherwise remain the same) >>>>> >>>>> Agenda and dial-in info remain the same (please scroll down). >>>>> >>>>> Best regards, Rene >>>>> >>>>> >>>>> On 1/20/2015 4:35 PM, Rene Struik wrote: >>>>>> I posted the document on Google drive, see weblink below. >>>>>> >>>>>> https://drive.google.com/file/d/0B2a6Ilxu1XfCa3RyZzlZb3RRREk/view?usp=sharing >>>>>> >>>>>> On 1/20/2015 1:13 AM, Rene Struik wrote: >>>>>>> Dear colleagues: >>>>>>> >>>>>>> Please find attached my analysis of the three text proposals. I >>>>>>> hope this helps in zooming in on consensus text. >>>>>>> >>>>>>> I will present this in more detail as item #3 on the agenda for >>>>>>> the 6tisch security call of tomorrow, Tue Jan 20, 2015, 4.30pm EST. >>>>>>> >>>>>>> We can discuss this in more detail during that call (I won't >>>>>>> have much time beforehand). >>>>>>> >>>>>>> Best regards, Rene >>>>>>> >>>>>>> [excerpt of minutes of 6tisch security conf call as of January >>>>>>> 14, 2015, 11am-12pm EST] >>>>>>> TW asked whether RS could review the three text proposals >>>>>>> currently on the table and suggest a way forward that takes into >>>>>>> account consensus and what was discussed during the call. RS >>>>>>> agreed to take this on as homework assignment, with target to >>>>>>> report back on this to the group by the end of Monday next week >>>>>>> (January 19, 2015). >>>>>>> >>>>>>> On 1/19/2015 2:20 PM, Rene Struik wrote: >>>>>>>> Dear colleagues: >>>>>>>> >>>>>>>> Just a quick reminder that we have a 6TiSCH security conf call >>>>>>>> tomorrow, Tue January 20, 2015, 4.30-5.30pm EST. >>>>>>>> >>>>>>>> Suggested agenda: >>>>>>>> 1) administrativia {agenda bashing/minutes} >>>>>>>> 2) 6tisch security conf call schedule moving forward >>>>>>>> 3) input 6tisch security to architecture draft >>>>>>>> -- RS to present result homework assignment of last call >>>>>>>> 4) prep for IETF-92 in Dallas >>>>>>>> 5) AOB >>>>>>>> >>>>>>>> For dial-in info, please see bottom of this email. >>>>>>>> >>>>>>>> As to item #2 above, if you wish to weigh-in, please do respond >>>>>>>> to the Doodle poll by end of *today*, see >>>>>>>> https://doodle.com/q63844gqd59urrae. >>>>>>>> >>>>>>>> Best regards, Rene >>>>>>>> >>>>>>>> -------- Forwarded Message -------- >>>>>>>> Subject: reminder -- 6tisch security call *tomorrow*, Wed Jan >>>>>>>> 14, 2015, 11am EST (dial-in info at bottom) >>>>>>>> Date: Tue, 13 Jan 2015 19:37:04 -0500 >>>>>>>> From: Rene Struik >>>>>>>> To: tisch-security <6tisch-security@ietf.org> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Dear colleagues: >>>>>>>> >>>>>>>> Just a quick reminder that we *do* have a conf call tomorrow, >>>>>>>> Wed Jan 14, 2015, 11am EST. >>>>>>>> >>>>>>>> Currently, the main agenda item is item #4b of last week: input >>>>>>>> to the 6tisch architecture draft. It would also be good to have >>>>>>>> some more comments on the draft I posted. >>>>>>>> >>>>>>>> Minutes of calls later tonight (sorry - extremely busy). For >>>>>>>> conf call dial-in info, see bottom of email. >>>>>>>> >>>>>>>> Best regards, Rene >>>>>>>> >>>>>>>> == >>>>>>>> Note: next week's call is on Wed Jan 14, 2015, 11am EST. >>>>>>>> >>>>>>>> On 1/6/2015 11:48 AM, Rene Struik wrote: >>>>>>>>> Dear colleagues: >>>>>>>>> >>>>>>>>> Happy New Year! >>>>>>>>> >>>>>>>>> According to the agreed-upon 6tisch security conf call >>>>>>>>> schedule, we will resume the conference call series today, Tue >>>>>>>>> Jan 6, 2015, 5pm EST. >>>>>>>>> >>>>>>>>> I propose we continue the discussion where we left off prior >>>>>>>>> to Christmas (essentially, item 3c below), except that we may >>>>>>>>> have a short presentation first (item #2). >>>>>>>>> >>>>>>>>> Agenda: >>>>>>>>> 1) administrativia {agenda bashing/minutes} >>>>>>>>> 2) {still to be confirmed} presentation Giuseppe Piro >>>>>>>>> 3) join protocol details >>>>>>>>> -- a) (done) status update MAC behavior >>>>>>>>> -- b) (brief!) recap of routing/communication flow aspects >>>>>>>>> -- c) incremental deployment aspects >>>>>>>>> 4) input 6tisch security to other 6tisch documents >>>>>>>>> -- a) terminology draft >>>>>>>>> -- b) architecture draft >>>>>>>>> >>>>>>>>> Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris >>>>>>>>> time. {The next call, on January 6, 2014) is also at 5pm EST >>>>>>>>> (see schedule till half of January 2015)}. >>>>>>>>> Note: next week's call is on Wed Jan 14, 2015, 11am EST. >>>>>>>>> >>>>>>>>> Dial-in info at end of this email. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Rene >>>>>>>>> >>>>>>>>> -------- Forwarded Message -------- >>>>>>>>> Subject: Suggested agenda for 6tisch security call of >>>>>>>>> *today*, Tue December 16, 2014, 5pm EST (dial-in info at bottom) >>>>>>>>> Date: Tue, 16 Dec 2014 09:21:20 -0500 >>>>>>>>> From: Rene Struik >>>>>>>>> To: tisch-security <6tisch-security@ietf.org> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Dear colleagues: >>>>>>>>> >>>>>>>>> I propose we continue the discussion where we left off last week. >>>>>>>>> >>>>>>>>> Agenda: >>>>>>>>> 1) administrativia {agenda bashing/minutes} >>>>>>>>> 2) join protocol details >>>>>>>>> -- a) (brief!) status update MAC behavior >>>>>>>>> -- b) continuation of routing/communication flow aspects {last >>>>>>>>> week, we did not finish the only two slides on this >>>>>>>>> 3) input 6tisch security to other 6tisch documents >>>>>>>>> >>>>>>>>> Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris >>>>>>>>> time. {The next call, on January 6, 2014) is also at 5pm EST >>>>>>>>> (see schedule till half of January 2015)}. >>>>>>>>> >>>>>>>>> Dial-in info at end of this email. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Rene >>>>>>>>> >>>>>>>>> -------- Forwarded Message -------- >>>>>>>>> Subject: suggested agenda for 6tisch security call of >>>>>>>>> tomorrow, Tue December 9, 2014, 9am EST (dial-in info at bottom) >>>>>>>>> Date: Mon, 08 Dec 2014 17:16:40 -0500 >>>>>>>>> From: Rene Struik >>>>>>>>> To: tisch-security <6tisch-security@ietf.org> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Dear colleagues: >>>>>>>>> >>>>>>>>> For last week's Tue Dec 2, 2014, 9am EST conf call I prepared >>>>>>>>> some material and posted prior to the call. During the call, >>>>>>>>> we discussed all MAC-related aspects relevant for the join >>>>>>>>> protocol and did not discuss higher-layer aspects I prepared >>>>>>>>> material for yet. I suggest we continue the systematic >>>>>>>>> discussion of last week and take that topic on now. >>>>>>>>> >>>>>>>>> This leads to the following suggested agenda for this week >>>>>>>>> (essentially a continuation of last week's one): >>>>>>>>> >>>>>>>>> Same as last week's, except with >>>>>>>>> #1a-b) focus on routing/communication flow related aspects >>>>>>>>> join protocol; >>>>>>>>> #2a): confirm concensus on MAC (as discussed last week) and >>>>>>>>> routing/communication flow aspects >>>>>>>>> #2c) {as consequence of two items above} what to squeeze into >>>>>>>>> architecture draft >>>>>>>>> >>>>>>>>> The detailed agenda and dial-in info is below (#A, resp. #B). >>>>>>>>> >>>>>>>>> Best regards, Rene >>>>>>>>> >>>>>>>>> _A) Suggested agenda Tue Dec 9, 2014, 9am EST call_ >>>>>>>>> >>>>>>>>> Proposed agenda: >>>>>>>>> >>>>>>>>> 0) Agenda bashing >>>>>>>>> >>>>>>>>> 1) Join protocol details >>>>>>>>> >>>>>>>>> a) desired properties >>>>>>>>> b) realizable properties >>>>>>>>> >>>>>>>>> #1a-b) focus on routing/communication flow related aspects >>>>>>>>> join protocol (we discussed MAC-related join-relevant >>>>>>>>> aspects during the conf call of Tue Dec 2, 2014, 9am EST). >>>>>>>>> For slides, see >>>>>>>>> https://drive.google.com/folderview?id=0B2a6Ilxu1XfCNF9JaXR1ZXlzZlU&usp=sharing >>>>>>>>> (same slides as sent out prior to Dec 2, 2014, 9am EST call) >>>>>>>>> Relevant slides: Slides 23-25 (contained in entire slide >>>>>>>>> deck (ppt), but also in excerpt (pdf)) >>>>>>>>> >>>>>>>>> 2) Next steps: >>>>>>>>> a) consensus on 1#a and 1#b >>>>>>>>> >>>>>>>>> #2a): confirm consensus on MAC (as discussed last week) >>>>>>>>> and routing/communication flow aspects >>>>>>>>> #2c) {as consequence of two items above} what to squeeze >>>>>>>>> into architecture draft >>>>>>>>> >>>>>>>>> b) form tiger team to work out details >>>>>>>>> - project phases >>>>>>>>> - communication of sub-results >>>>>>>>> c) what to squeeze into architecture draft, etc. >>>>>>>>> >>>>>>>>> I will prepare material to facilitate discussion on 1) and 2), >>>>>>>>> to be discussed during the call. >>>>>>>>> >>>>>>>>> _B) Dial-in information:_ >>>>>>>>> English : New York Time 6tisch security >>>>>>>>> Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00) >>>>>>>>> Meeting number: 641 709 118 >>>>>>>>> Meeting password: joinjoin >>>>>>>>> Audio connection: >>>>>>>>> 1-877-668-4493 Call-in toll free number (US/Canada) >>>>>>>>> 1-650-479-3208 Call-in toll number (US/Canada) >>>>>>>>> >>>>>>>>> Access code: 641 709 118 >>>>>>>>> Meeting link: >>>>>>>>> https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6 >>>>>>>>> >>>>>>>>> The etherpad we have used is at: >>>>>>>>> http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>>>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>>>> >>>>>> >>>>>> -- >>>>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>>> >>>>> >>>>> -- >>>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>> >>>> >>>> -- >>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>> >>> >>> -- >>> email:rstruik.ext@gmail.com | Skype: rstruik >>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >> >> >> -- >> email:rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > -- > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------090006060800040203060906 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call *today*, Tue February 17, 2015, 9am EST.

As you may recall, I put as tentative item on the agenda of last week's call "time latency aspects" of the join protocol . Thomas Watteyne volunteered to take on this topic for this week's call.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) time latency aspects (Thomas Watteyne)
3) AOB

==
The schedule for the next few 6tisch security conference calls is as follows:
Tue Jan 20th: 4.30pm EST
Tue Jan 27th: 9am EST
Tue Feb 3rd: 4.30pm EST
Tue Feb 10th: 4.30pm EST
Tue Feb 17th: 9am EST
Tue Feb 24th: 9am EST
Tue Mar 3rd: 4.30pm EST

On 2/9/2015 11:50 PM, Rene Struik wrote:
Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue February 10, 2015, 4.30pm EST.

I have not seen any email traffic the last two weeks, nor any more feedback on the draft document I posted on Fri January 9th.

I put as tentative item on the agenda "time latency aspects" of the join protocol. I will send out a more definitive agenda tomorrow around noon EST. Please send agenda request to me prior to that time.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) time latency aspects
3) AOB

On 1/28/2015 10:16 AM, Rene Struik wrote:
Dear colleagues:

Please find below the minutes of the 6TiSCH Security conf call as of January 27, 2015, 9-10am EST.

Minutes 6TiSCH Security conf call, Wed January 27, 2015, 9-10am EST
{note taker: Rene Struik}
{recording: not available (Michael Richardson had control, but was not on the call}
{discussion material (referenced in minutes): this time, no posted collatoral}

1. Attendance:
Tero Kivinen, Yoshi Ohba, Rene Struik

2. Agenda
The suggested updated agenda was approved.
Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) prep for IETF-92 in Dallas
3) AOB

3. Minutes
The minutes of the previous 6TiSCH security conference call (Thu January 22, 2015) were approved.

4. Prep for IETF-92 in Dallas {more of a 6tisch security various "varia" discussion really}
YO asked what happened with the output of the join process overview text discussed during last week's call. RS mentioned that Pascal Thubert included this in the 6tisch architecture draft (Section 13 - Security Considerations) and would issue draft-ietf-6tisch-architecture-05 for WGLC some time this week.

RS mentioned that at the IETF-92 meeting in Dallas in March, the  6tisch group would presumably recharter and include more security-related milestones into the revised charter. He thought it would be useful to have a 6tisch security draft by that meeting that could serve as baseline.

TK provided some more insight into the 802.15.4rev effort. He suggested that there would be 1-2 more letter ballots, followed by the start of sponsor ballot around end of March 2015, with anticipated conclusion of the work around July-August this year. RS commented that this schedule seemed quite aggressive, considering historical timelines of IEEE 802.15 efforts. TK mentioned that according to Bob Heile (Chair IEEE 802.15) the 802.15rev draft would only be available in the 802.15 private member area or to those people participating in person in an actual IEEE 802 meeting. Therefore, it does not seem possible to make a draft available to interested parties in the 6tisch community who did not meet those criteria (as previously suggested).

5. AOB
RS suggested to cancel the 6tisch security call of next week and reconvene two weeks from now, which was agreed upon. Next call will take place Tue Feb 10, 2015, 4.30pm EST.

RS mentioned he had received feedback from Kris Pister and Yoshi Ohba on draft-struik-6tisch-security-architectural-considerations-01 (posted January 9, 2015). Before updating the draft, he would like to see more people give this a look. He invited people to use the now cancelled slot of next week's call to review this draft...

[call ended @9.23am EST]


On 1/26/2015 12:15 PM, Rene Struik wrote:
Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue January 27, 2015, 9am EST. I expect this to be a short call.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) prep for IETF-92 in Dallas
3) AOB

The dial-in info is below.

Best regards, Rene

B) Dial-in information:
English : New York Time 6tisch security
Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00)
Meeting number:   641 709 118
Meeting password: joinjoin
Audio connection:
      1-877-668-4493 Call-in toll free number (US/Canada)
      1-650-479-3208 Call-in toll number (US/Canada)

Access code: 641 709 118
Meeting link:
        https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6

The etherpad we have used is at:
       http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt


On 1/21/2015 10:30 AM, Rene Struik wrote:
Dear colleagues:

Giuseppe Piro offered to give a presentation on MAC security aspects, resulting in the updated agenda below. Dial-in info at bottom of email.

Remember: 6tisch security call is now tomorrow, Thu Jan 21, 2015, 1pm EST, with duration not to exceed one hour. Please call-in on time and test your speaker/mike beforehand.

Suggested updated agenda:
1) administrativia {agenda bashing/minutes} [4 min]
2) 6tisch security conf call schedule moving forward [1 min]
3) input 6tisch security to architecture draft [15 min]
-- RS to present result homework assignment of last call
4) presentation Giuseppe Piro re MAC security [30 min]
5) prep for IETF-92 in Dallas [10 min]
5) AOB

Link to suggested text (item #3 above):
https://drive.google.com/file/d/0B2a6Ilxu1XfCbVhfd0ZONXoxc00/view?usp=sharing

On 1/20/2015 4:54 PM, Rene Struik wrote:
Dear colleagues:

Due to connectivity problems, those on the 6tisch security call today concluded that it was best to reschedule the call.

The rescheduled 6tisch security call will take place this Thursday, January 22, 2015, 1-2pm EST.
(Please note that this is only once; schedule moving forward will otherwise remain the same)

Agenda and dial-in info remain the same (please scroll down).

Best regards, Rene


On 1/20/2015 4:35 PM, Rene Struik wrote:
I posted the document on Google drive, see weblink below.

https://drive.google.com/file/d/0B2a6Ilxu1XfCa3RyZzlZb3RRREk/view?usp=sharing

On 1/20/2015 1:13 AM, Rene Struik wrote:
Dear colleagues:

Please find attached my analysis of the three text proposals. I hope this helps in zooming in on consensus text.

I will present this in more detail as item #3 on the agenda for the 6tisch security call of tomorrow, Tue Jan 20, 2015, 4.30pm EST.

We can discuss this in more detail during that call (I won't have much time beforehand).

Best regards, Rene

[excerpt of minutes of 6tisch security conf call as of January 14, 2015, 11am-12pm EST]
TW asked whether RS could review the three text proposals currently on the table and suggest a way forward that takes into account consensus and what was discussed during the call. RS agreed to take this on as homework assignment, with target to report back on this to the group by the end of Monday next week (January 19, 2015).

On 1/19/2015 2:20 PM, Rene Struik wrote:
Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue January 20, 2015, 4.30-5.30pm EST.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) 6tisch security conf call schedule moving forward
3) input 6tisch security to architecture draft
-- RS to present result homework assignment of last call
4) prep for IETF-92 in Dallas
5) AOB

For dial-in info, please see bottom of this email.

As to item #2 above, if you wish to weigh-in, please do respond to the Doodle poll by end of *today*, see https://doodle.com/q63844gqd59urrae.

Best regards, Rene

-------- Forwarded Message --------
Subject: reminder -- 6tisch security call *tomorrow*, Wed Jan 14, 2015, 11am EST (dial-in info at bottom)
Date: Tue, 13 Jan 2015 19:37:04 -0500
From: Rene Struik <rstruik.ext@gmail.com>
To: tisch-security <6tisch-security@ietf.org>


Dear colleagues:

Just a quick reminder that we *do* have a conf call tomorrow, Wed Jan 14, 2015, 11am EST.

Currently, the main agenda item is item #4b of last week: input to the 6tisch architecture draft. It would also be good to have some more comments on the draft I posted.

Minutes of calls later tonight (sorry - extremely busy). For conf call dial-in info, see bottom of email.

Best regards, Rene

==
Note: next week's call is on Wed Jan 14, 2015, 11am EST.

On 1/6/2015 11:48 AM, Rene Struik wrote:
Dear colleagues:

Happy New Year!

According to the agreed-upon 6tisch security conf call schedule, we will resume the conference call series today, Tue Jan 6, 2015, 5pm EST.

I propose we continue the discussion where we left off prior to Christmas (essentially, item 3c below), except that we may have a short presentation first (item #2).

Agenda:
1) administrativia {agenda bashing/minutes}
2) {still to be confirmed} presentation Giuseppe Piro
3) join protocol details
-- a) (done) status update MAC behavior
-- b) (brief!) recap of routing/communication flow aspects
-- c) incremental deployment aspects
4) input 6tisch security to other 6tisch documents
-- a) terminology draft
-- b) architecture draft

Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris time. {The next call, on January 6, 2014) is also at 5pm EST (see schedule till half of January 2015)}.
Note: next week's call is on Wed Jan 14, 2015, 11am EST.

Dial-in info at end of this email.

Best regards,

Rene

-------- Forwarded Message --------
Subject: Suggested agenda for 6tisch security call of *today*, Tue December 16, 2014, 5pm EST (dial-in info at bottom)
Date: Tue, 16 Dec 2014 09:21:20 -0500
From: Rene Struik <rstruik.ext@gmail.com>
To: tisch-security <6tisch-security@ietf.org>


Dear colleagues:

I propose we continue the discussion where we left off last week.

Agenda:
1) administrativia {agenda bashing/minutes}
2) join protocol details
-- a) (brief!) status update MAC behavior
-- b) continuation of routing/communication flow aspects {last week, we did not finish the only two slides on this
3) input 6tisch security to other 6tisch documents

Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris time. {The next call, on January 6, 2014) is also at 5pm EST (see schedule till half of January 2015)}.

Dial-in info at end of this email.

Best regards,

Rene

-------- Forwarded Message --------
Subject: suggested agenda for 6tisch security call of tomorrow, Tue December 9, 2014, 9am EST (dial-in info at bottom)
Date: Mon, 08 Dec 2014 17:16:40 -0500
From: Rene Struik <rstruik.ext@gmail.com>
To: tisch-security <6tisch-security@ietf.org>


Dear colleagues:

For last week's Tue Dec 2, 2014, 9am EST conf call I prepared some material and posted prior to the call. During the call, we discussed all MAC-related aspects relevant for the join protocol and did not discuss higher-layer aspects I prepared material for yet. I suggest we continue the systematic discussion of last week and take that topic on now.

This leads to the following suggested agenda for this week (essentially a continuation of last week's one):

Same as last week's, except with
#1a-b) focus on routing/communication flow related aspects join protocol;
#2a): confirm concensus on MAC (as discussed last week) and routing/communication flow aspects
#2c) {as consequence of two items above} what to squeeze into architecture draft

The detailed agenda and dial-in info is below (#A, resp. #B).

Best regards, Rene

A) Suggested agenda Tue Dec 9, 2014, 9am EST call

Proposed agenda:

0) Agenda bashing

1) Join protocol details
a) desired properties
b) realizable properties

#1a-b) focus on routing/communication flow related aspects join protocol (we discussed MAC-related join-relevant aspects during the conf call of Tue Dec 2, 2014, 9am EST).
For slides, see https://drive.google.com/folderview?id=0B2a6Ilxu1XfCNF9JaXR1ZXlzZlU&usp=sharing (same slides as sent out prior to Dec 2, 2014, 9am EST call)
Relevant slides: Slides 23-25 (contained in entire slide deck (ppt), but also in excerpt (pdf))
2) Next steps:
        a) consensus on 1#a and 1#b
#2a): confirm consensus on MAC (as discussed last week) and routing/communication flow aspects
#2c) {as consequence of two items above} what to squeeze into architecture draft
        b) form tiger team to work out details
            - project phases
            - communication of sub-results
        c) what to squeeze into architecture draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call.

B) Dial-in information:
English : New York Time 6tisch security
Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00)
Meeting number:   641 709 118
Meeting password: joinjoin
Audio connection:
      1-877-668-4493 Call-in toll free number (US/Canada)
      1-650-479-3208 Call-in toll number (US/Canada)

Access code: 641 709 118
Meeting link:
        https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6

The etherpad we have used is at:
       http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363






-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363




-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------090006060800040203060906-- From nobody Tue Feb 17 05:49:09 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B991A8853 for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 05:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 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, WEIRD_PORT=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 7UJM6noIoPL1 for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 05:49:06 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (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 8CEDA1A1B44 for <6tisch-security@ietf.org>; Tue, 17 Feb 2015 05:48:59 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id y19so35482995wgg.13 for <6tisch-security@ietf.org>; Tue, 17 Feb 2015 05:48:58 -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:content-type; bh=ud4Qdxo/M4B6xPeCO6jn2Ly3hlsRC/sYAiWQCBaaQIk=; b=hAD/6m2K9JBCdw8SDZmkkCyJBO+u2F9XNoEfPeUY3uCHrxwowhqEX1tFQB1pwmHPT2 jhW1rJ7jEd5Lq6O/sLAYjvrbZyxdLN87BAJms2lX9wNGM/e7AvSVO3TsKsLEjfSk29I8 IR6NKD+nUypDVWW18FM99eFuLgw65F+siTATlUsI8RAeaLdjXrMGILGIP5e5HnoKp42w IJBcPqdaR3KUqN1lvFhgGdrNr9hC3o9Nsr39dxoi0FkCZXoQgVgUj5ZuV/iOPHzjsTD+ mx7YmixIjstUCwkWbndEoNaf3lBmH55BJvs/TB4t1Drece21zKcAlQvDbpa6kGrOQflM ahGQ== X-Received: by 10.180.80.230 with SMTP id u6mr57383000wix.69.1424180936947; Tue, 17 Feb 2015 05:48:56 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.194.82.39 with HTTP; Tue, 17 Feb 2015 05:48:36 -0800 (PST) In-Reply-To: <54E3414E.2070201@gmail.com> References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> <54D98E01.4090103@gmail.com> <54E3414E.2070201@gmail.com> From: Thomas Watteyne Date: Tue, 17 Feb 2015 14:48:36 +0100 X-Google-Sender-Auth: 5xXfdm53JCECBd7o87cHL0UPzAc Message-ID: To: tisch-security <6tisch-security@ietf.org> Content-Type: multipart/alternative; boundary=f46d04428aced7bbe0050f48f6d0 Archived-At: Subject: Re: [6tisch-security] Reminder -- 6tisch security call *today*, Tue Feb 17, 2015, 9am EST (includes dial-in info) X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 13:49:07 -0000 --f46d04428aced7bbe0050f48f6d0 Content-Type: text/plain; charset=UTF-8 Rene, Thanks for the reminder. *Agenda* Today's discussion about latency will be illustrated by the excellent slides Malisa Vucinic put together (thanks!!), and which were sent to the mailing in: http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00427.html As such, the agenda should be updated to: Suggested agenda: 1) administrativia {agenda bashing/minutes} 2) time latency aspects (Malisa Vucinic, Thomas Watteyne) 3) AOB *Etherpad* During the meeting, I propose we use the following Etherpad: http://etherpad.tools.ietf.org:9000/p/6tisch-security?useMonospaceFont=true *Connection details* They remain unchanged: Meeting number: 641 709 118 Meeting password: joinjoin Audio connection: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 641 709 118 Meeting link: https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6 See you in 15min, Thomas --f46d04428aced7bbe0050f48f6d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rene,

Thanks for the reminder.

Agenda

Today's discuss= ion about latency will be illustrated by the excellent slides Malisa Vucini= c put together (thanks!!), and which were sent to the mailing in:
http://www.ietf.org/mail-archive/web/6tisch-= security/current/msg00427.html

As such, th= e agenda should be updated to:

Suggested agenda:
1) administr= ativia {agenda bashing/minutes}
2) time latency aspects = (Malisa Vucinic, Thomas Watteyne)
3) AOB

Etherpad

During the meeting, I propose we use the following Etherpad:
=

Connection details

They remain unchanged:

Meeting numbe= r: =C2=A0 641 709 118
Meeting password: joinjoin
Audio connection:
=C2=A0 =C2=A0 =C2=A0 1-877-66= 8-4493 Call-in toll free number (US/Canada)
=C2=A0 =C2=A0 =C2=A0 1-650-479-3208 Ca= ll-in toll number (US/Canada)
Access code: 641 709 118
Meeting link:


See you in 15min,

Thomas

--f46d04428aced7bbe0050f48f6d0-- From nobody Tue Feb 17 09:40:02 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418161A1BF4 for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 09:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, HTML_MESSAGE=0.001, J_CHICKENPOX_22=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 Ev0h0tJzXVhq for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 09:39:58 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::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 DD74B1A1B5C for <6tisch-security@ietf.org>; Tue, 17 Feb 2015 09:39:57 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id h15so31225180igd.4 for <6tisch-security@ietf.org>; Tue, 17 Feb 2015 09:39:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=pclR/lU0qVA/Ik+oEyHU1emsalFtBd1gIJ4hoWNc+rw=; b=yJ27kvx0esT+2/2cerFMRe+pOXmHpX/9+MQnsc5gK7TsPd/DQV6GyddrOoJGueaqmn 862p0rSM3qG36ZDZ5P3TUxvPKq3LwjizxxY4rq807fLwwvHWNor53mfo9tl+72/t0+ZF kvqUfJ1ro9cF8JAn5IM9lzUluE+l8C0kk2AqjkycD2+YOQSth1GOTqY5jjCfZ+2aIYW+ Ot71uyUaCB//XNlTb0OIhKORTTTswM39ibK1tvczlU4CsDoal6eueJ/Wcbsvev6+xlF7 uccQTFkY7RbjeFPekQXj2RRdOalYYZhkX/euERh/OHbOE/XYg048Rq/CXHSwVshCf5PZ FyJQ== X-Received: by 10.50.72.108 with SMTP id c12mr28535337igv.27.1424194797089; Tue, 17 Feb 2015 09:39:57 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id i2sm11572326ioi.41.2015.02.17.09.39.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Feb 2015 09:39:56 -0800 (PST) Message-ID: <54E37CD5.7090405@gmail.com> Date: Tue, 17 Feb 2015 12:39:33 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Malisa Vucinic , 6tisch-security@ietf.org References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> <54D98E01.4090103@gmail.com> <8E377EDE-074F-472E-B397-86F29AEDEB19@imag.fr> In-Reply-To: <8E377EDE-074F-472E-B397-86F29AEDEB19@imag.fr> Content-Type: multipart/alternative; boundary="------------000000080505020400050903" Archived-At: Subject: [6tisch-security] (simplified explanation of formulae) Re: Latency aspects of TSCH X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 17:40:00 -0000 This is a multi-part message in MIME format. --------------000000080505020400050903 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Malisa: I had a closer look at the slides you presented at the 6TiSCH security call this morning, Feb 17, 2015. Slide 3 presents time latency numbers in case of a random TSCH schedule with C cells per slotframe, where the slotframe length is L time slots. I was trying to come up with an easy explanation for your time latency figure of ~ 1/(C+1) the slotframe length between receiving a frame and sending a response in the next available dedicated "sending cell". It turns out one can do this without any nontrivial math. See below. Assumptions: -w.l.o.g., receipt by A of frame from B ("A <--B") is at time zero (since schedule repeats) -sending schedule of A: t cells, dividing up the unite line [0,1] in intervals of length L1, L2, ..., L{t+1}. - t>0 (o.w., A is mute). Observe that any schedule of t cells corresponds 1-1 with a partitioning of the unit line [0,1]. Moreover, if (L1,L2, ..., L{t+1}) is a schedule, then so is any permutation hereof. As a result, the average size of the first segment over all schedules is (L1+ .... + L{t+1})/(t+1)=1/(t+1): simply add up the first segment of the schedules (L1,L2, ..., L{t+1}), (L2,L3, ..., L{t+1}, L1), ..., (L{t+1},L1, ..., Lt). The result follows (take t:=C). Note: this assumes one has infinity many timeslots in a slotframe, so that one can approximate rational numbers by real numbers and one can ignore Li=Lj occurrences.( On 2/16/2015 8:14 PM, Malisa Vucinic wrote: > Hi all, > > I prepared a couple of slides on latency aspects with TSCH that can > hopefully be useful for evaluating different proposals for the join > process once there are more details on message sizes involved. > > Regards, > Malisa > > > > >> On 09 Feb 2015, at 20:50, Rene Struik > > wrote: >> >> Dear colleagues: >> >> Just a quick reminder that we have a 6TiSCH security conf call >> tomorrow, Tue February 10, 2015, 4.30pm EST. >> >> I have not seen any email traffic the last two weeks, nor any more >> feedback on the draft document I posted on Fri January 9th. >> >> I put as tentative item on the agenda "time latency aspects" of the >> join protocol. I will send out a more definitive agenda tomorrow >> around noon EST. Please send agenda request to me prior to that time. >> >> Suggested agenda: >> 1) administrativia {agenda bashing/minutes} >> 2) time latency aspects >> 3) AOB > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------000000080505020400050903 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Malisa:

I had a closer look at the slides you presented at the 6TiSCH security call this morning, Feb 17, 2015.

Slide 3 presents time latency numbers in case of a random TSCH schedule with C cells per slotframe, where the slotframe length is L time slots. I was trying to come up with an easy explanation for your time latency figure of ~ 1/(C+1)  the slotframe length between receiving a frame and sending a response in the next available dedicated "sending cell".

It turns out one can do this without any nontrivial math. See below.

Assumptions:
-w.l.o.g., receipt by A of frame from B ("A <--B") is at time zero (since schedule repeats)
-sending schedule of A: t cells, dividing up the unite line [0,1] in intervals of length L1, L2, ..., L{t+1}.
- t>0 (o.w., A is mute).

Observe that any schedule of t cells corresponds 1-1 with a partitioning of the unit line [0,1]. Moreover, if (L1,L2, ..., L{t+1}) is a schedule, then so is any permutation hereof. As a result, the average size of the first segment over all schedules is (L1+ .... + L{t+1})/(t+1)=1/(t+1): simply add up the first segment of the schedules (L1,L2, ..., L{t+1}), (L2,L3, ..., L{t+1}, L1), ..., (L{t+1},L1, ..., Lt).
The result follows (take t:=C).

Note: this assumes one has infinity many timeslots in a slotframe, so that one can approximate rational numbers by real numbers and one can ignore Li=Lj occurrences.(
 

On 2/16/2015 8:14 PM, Malisa Vucinic wrote:
Hi all,

I prepared a couple of slides on latency aspects with TSCH that can hopefully be useful for evaluating different proposals for the join process once there are more details on message sizes involved.

Regards,
Malisa




On 09 Feb 2015, at 20:50, Rene Struik <rstruik.ext@gmail.com> wrote:

Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue February 10, 2015, 4.30pm EST. 

I have not seen any email traffic the last two weeks, nor any more feedback on the draft document I posted on Fri January 9th.

I put as tentative item on the agenda "time latency aspects" of the join protocol. I will send out a more definitive agenda tomorrow around noon EST. Please send agenda request to me prior to that time.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) time latency aspects
3) AOB



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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------000000080505020400050903-- From nobody Tue Feb 17 12:17:25 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CD21A1B21 for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 12:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.18 X-Spam-Level: X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SPF_NEUTRAL=0.779, 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 0DA-TtFS_Qya for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 12:17:21 -0800 (PST) Received: from rominette.imag.fr (mx2.imag.fr [IPv6:2001:660:5301:59::17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83E91A044F for <6tisch-security@ietf.org>; Tue, 17 Feb 2015 12:17:20 -0800 (PST) Received: from globule.imag.fr (globule.imag.fr [129.88.34.238]) by rominette.imag.fr (8.13.8/8.13.8) with ESMTP id t1HKHDB8026216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2015 21:17:13 +0100 Received: from dhcp-33-61.eecs.berkeley.edu (dhcp-33-61.EECS.Berkeley.EDU [128.32.33.61]) (authenticated bits=0) by globule.imag.fr (8.13.8/8.13.8) with ESMTP id t1HKHDGA023893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2015 21:17:15 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_1B7EBC07-77C8-447E-934B-CAC37E8A9CDD" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Malisa Vucinic In-Reply-To: <54E37CD5.7090405@gmail.com> Date: Tue, 17 Feb 2015 12:17:13 -0800 Message-Id: <4EDC1B3D-8E75-4FA8-8B3E-E458B3A9CAA8@imag.fr> References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> <54D98E01.4090103@gmail.com> <8E377EDE-074F-472E-B397-86F29AEDEB19@imag.fr> <54E37CD5.7090405@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.2070.6) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (rominette.imag.fr [129.88.30.17]); Tue, 17 Feb 2015 21:17:13 +0100 (CET) X-IMAG-MailScanner-Information: Please contact MI2S MIM for more information X-MailScanner-ID: t1HKHDB8026216 X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-SpamCheck: X-IMAG-MailScanner-From: malisa.vucinic@imag.fr MailScanner-NULL-Check: 1424809035.36391@fBokQOMCr0MUdUr9m39WJw Archived-At: Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] (simplified explanation of formulae) Re: Latency aspects of TSCH X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 20:17:24 -0000 --Apple-Mail=_1B7EBC07-77C8-447E-934B-CAC37E8A9CDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Rene, Thanks for confirming my calculation. I agree that theoretically this assumes infinite number of timeslots in = a slotframe but I believe it should be accurate enough for C << L.=20 Regards, Malisa > On 17 Feb 2015, at 09:39, Rene Struik wrote: >=20 > Hi Malisa: >=20 > I had a closer look at the slides you presented at the 6TiSCH security = call this morning, Feb 17, 2015. >=20 > Slide 3 presents time latency numbers in case of a random TSCH = schedule with C cells per slotframe, where the slotframe length is L = time slots. I was trying to come up with an easy explanation for your = time latency figure of ~ 1/(C+1) the slotframe length between receiving = a frame and sending a response in the next available dedicated "sending = cell".=20 >=20 > It turns out one can do this without any nontrivial math. See below. >=20 > Assumptions: > -w.l.o.g., receipt by A of frame from B ("A <--B") is at time zero = (since schedule repeats) > -sending schedule of A: t cells, dividing up the unite line [0,1] in = intervals of length L1, L2, ..., L{t+1}. > - t>0 (o.w., A is mute). >=20 > Observe that any schedule of t cells corresponds 1-1 with a = partitioning of the unit line [0,1]. Moreover, if (L1,L2, ..., L{t+1}) = is a schedule, then so is any permutation hereof. As a result, the = average size of the first segment over all schedules is (L1+ .... + = L{t+1})/(t+1)=3D1/(t+1): simply add up the first segment of the = schedules (L1,L2, ..., L{t+1}), (L2,L3, ..., L{t+1}, L1), ..., = (L{t+1},L1, ..., Lt). > The result follows (take t:=3DC). >=20 > Note: this assumes one has infinity many timeslots in a slotframe, so = that one can approximate rational numbers by real numbers and one can = ignore Li=3DLj occurrences.( > =20 >=20 > On 2/16/2015 8:14 PM, Malisa Vucinic wrote: >> Hi all, >>=20 >> I prepared a couple of slides on latency aspects with TSCH that can = hopefully be useful for evaluating different proposals for the join = process once there are more details on message sizes involved. >>=20 >> Regards, >> Malisa >>=20 >>=20 >>=20 >>=20 >>> On 09 Feb 2015, at 20:50, Rene Struik > wrote: >>>=20 >>> Dear colleagues: >>>=20 >>> Just a quick reminder that we have a 6TiSCH security conf call = tomorrow, Tue February 10, 2015, 4.30pm EST.=20 >>>=20 >>> I have not seen any email traffic the last two weeks, nor any more = feedback on the draft document I posted on Fri January 9th. >>>=20 >>> I put as tentative item on the agenda "time latency aspects" of the = join protocol. I will send out a more definitive agenda tomorrow around = noon EST. Please send agenda request to me prior to that time. >>>=20 >>> Suggested agenda: >>> 1) administrativia {agenda bashing/minutes} >>> 2) time latency aspects >>> 3) AOB >>=20 >>=20 >>=20 >> _______________________________________________ >> 6tisch-security mailing list >> 6tisch-security@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch-security = >=20 >=20 > --=20 > email: rstruik.ext@gmail.com | Skype: = rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --Apple-Mail=_1B7EBC07-77C8-447E-934B-CAC37E8A9CDD Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=windows-1252 Hi Rene,

Thanks for confirming my calculation.

I agree that theoretically this assumes infinite number of timeslots in a slotframe but I believe it should be accurate enough for C << L. 

Regards,
Malisa

On 17 Feb 2015, at 09:39, Rene Struik <rstruik.ext@gmail.com> wrote:

Hi Malisa:

I had a closer look at the slides you presented at the 6TiSCH security call this morning, Feb 17, 2015.

Slide 3 presents time latency numbers in case of a random TSCH schedule with C cells per slotframe, where the slotframe length is L time slots. I was trying to come up with an easy explanation for your time latency figure of ~ 1/(C+1)  the slotframe length between receiving a frame and sending a response in the next available dedicated "sending cell".

It turns out one can do this without any nontrivial math. See below.

Assumptions:
-w.l.o.g., receipt by A of frame from B ("A <--B") is at time zero (since schedule repeats)
-sending schedule of A: t cells, dividing up the unite line [0,1] in intervals of length L1, L2, ..., L{t+1}.
- t>0 (o.w., A is mute).

Observe that any schedule of t cells corresponds 1-1 with a partitioning of the unit line [0,1]. Moreover, if (L1,L2, ..., L{t+1}) is a schedule, then so is any permutation hereof. As a result, the average size of the first segment over all schedules is (L1+ .... + L{t+1})/(t+1)=1/(t+1): simply add up the first segment of the schedules (L1,L2, ..., L{t+1}), (L2,L3, ..., L{t+1}, L1), ..., (L{t+1},L1, ..., Lt).
The result follows (take t:=C).

Note: this assumes one has infinity many timeslots in a slotframe, so that one can approximate rational numbers by real numbers and one can ignore Li=Lj occurrences.(
 

On 2/16/2015 8:14 PM, Malisa Vucinic wrote:
Hi all,

I prepared a couple of slides on latency aspects with TSCH that can hopefully be useful for evaluating different proposals for the join process once there are more details on message sizes involved.

Regards,
Malisa




On 09 Feb 2015, at 20:50, Rene Struik <rstruik.ext@gmail.com> wrote:

Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue February 10, 2015, 4.30pm EST. 

I have not seen any email traffic the last two weeks, nor any more feedback on the draft document I posted on Fri January 9th.

I put as tentative item on the agenda "time latency aspects" of the join protocol. I will send out a more definitive agenda tomorrow around noon EST. Please send agenda request to me prior to that time.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) time latency aspects
3) AOB



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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

--Apple-Mail=_1B7EBC07-77C8-447E-934B-CAC37E8A9CDD-- From nobody Tue Feb 17 12:30:38 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200C01A1BA5 for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 12:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, HTML_MESSAGE=0.001, J_CHICKENPOX_22=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 lHZ9JpDJS9kx for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 12:30:35 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 096BE1A044F for <6tisch-security@ietf.org>; Tue, 17 Feb 2015 12:30:35 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id hl2so32429867igb.5 for <6tisch-security@ietf.org>; Tue, 17 Feb 2015 12:30:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=jl3nEyqF51ZiXi/GRM7tax7ZAVYd1VLgqafEXUd9SiA=; b=SKv8fVZe/ekWKjRpc5kqC2N7znnWa5Uk11IOsf7Zlqv1OARN/KVJZLl5FL0sfhEpW1 TEGDxSpm7kTzDIyLu/VkdbJdjneNsmrAnJ7aslEWtKgHIPKASS60qePaRc5aLpVMmOYU LGgn3W7iRUuW4JIeWvK2lG1mVizwDCeFkrYdvlfMPcchb5Bdn8XBm34Tkv/GikrZAoYF /9CxTFfBiTohvbTaUd7LCyMORmExjBN92H7mI2zJiRGeShcpIveHRidDc/WlAu2GH4U1 VGWAMqpS+I+R0cRCGT/6FHo3akR3SSVDjZPu6GDGRqL+GZRhbH2AnExHPGCpHOWqlc7q /Hxw== X-Received: by 10.107.153.193 with SMTP id b184mr13523828ioe.85.1424205034243; Tue, 17 Feb 2015 12:30:34 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id f1sm10653193igt.14.2015.02.17.12.30.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Feb 2015 12:30:33 -0800 (PST) Message-ID: <54E3A4D2.8090907@gmail.com> Date: Tue, 17 Feb 2015 15:30:10 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Malisa Vucinic References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> <54D98E01.4090103@gmail.com> <8E377EDE-074F-472E-B397-86F29AEDEB19@imag.fr> <54E37CD5.7090405@gmail.com> <4EDC1B3D-8E75-4FA8-8B3E-E458B3A9CAA8@imag.fr> In-Reply-To: <4EDC1B3D-8E75-4FA8-8B3E-E458B3A9CAA8@imag.fr> Content-Type: multipart/alternative; boundary="------------080903000209070809070800" Archived-At: Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] (simplified explanation of formulae) Re: Latency aspects of TSCH X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 20:30:37 -0000 This is a multi-part message in MIME format. --------------080903000209070809070800 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Malisa: In fact, I think my note on approximation of reals by rational numbers was too pessimistic: my two-line argument for the 1/(C+1) density formula should hold in general. Two further notes: a) It seems one can easily extend the argument to cases where one inserts some "don't care" timeslot (Rx/Tx by any device) and include those in the C tally (if there are no clashes in access to that cell). b) I think random scheduling is not really optimum, since there are wide variations in latency from the average. For more deterministic time latencies, one might want to look into schemes that have a much smaller variance. Best regards, Rene On 2/17/2015 3:17 PM, Malisa Vucinic wrote: > Hi Rene, > > Thanks for confirming my calculation. > > I agree that theoretically this assumes infinite number of timeslots > in a slotframe but I believe it should be accurate enough for C << L. > > Regards, > Malisa > >> On 17 Feb 2015, at 09:39, Rene Struik > > wrote: >> >> Hi Malisa: >> >> I had a closer look at the slides you presented at the 6TiSCH >> security call this morning, Feb 17, 2015. >> >> Slide 3 presents time latency numbers in case of a random TSCH >> schedule with C cells per slotframe, where the slotframe length is L >> time slots. I was trying to come up with an easy explanation for your >> time latency figure of ~ 1/(C+1) the slotframe length between >> receiving a frame and sending a response in the next available >> dedicated "sending cell". >> >> It turns out one can do this without any nontrivial math. See below. >> >> Assumptions: >> -w.l.o.g., receipt by A of frame from B ("A <--B") is at time zero >> (since schedule repeats) >> -sending schedule of A: t cells, dividing up the unite line [0,1] in >> intervals of length L1, L2, ..., L{t+1}. >> - t>0 (o.w., A is mute). >> >> Observe that any schedule of t cells corresponds 1-1 with a >> partitioning of the unit line [0,1]. Moreover, if (L1,L2, ..., >> L{t+1}) is a schedule, then so is any permutation hereof. As a >> result, the average size of the first segment over all schedules is >> (L1+ .... + L{t+1})/(t+1)=1/(t+1): simply add up the first segment of >> the schedules (L1,L2, ..., L{t+1}), (L2,L3, ..., L{t+1}, L1), ..., >> (L{t+1},L1, ..., Lt). >> The result follows (take t:=C). >> >> Note: this assumes one has infinity many timeslots in a slotframe, so >> that one can approximate rational numbers by real numbers and one can >> ignore Li=Lj occurrences.( >> >> >> On 2/16/2015 8:14 PM, Malisa Vucinic wrote: >>> Hi all, >>> >>> I prepared a couple of slides on latency aspects with TSCH that can >>> hopefully be useful for evaluating different proposals for the join >>> process once there are more details on message sizes involved. >>> >>> Regards, >>> Malisa >>> >>> >>> >>> >>>> On 09 Feb 2015, at 20:50, Rene Struik >>> > wrote: >>>> >>>> Dear colleagues: >>>> >>>> Just a quick reminder that we have a 6TiSCH security conf call >>>> tomorrow, Tue February 10, 2015, 4.30pm EST. >>>> >>>> I have not seen any email traffic the last two weeks, nor any more >>>> feedback on the draft document I posted on Fri January 9th. >>>> >>>> I put as tentative item on the agenda "time latency aspects" of the >>>> join protocol. I will send out a more definitive agenda tomorrow >>>> around noon EST. Please send agenda request to me prior to that time. >>>> >>>> Suggested agenda: >>>> 1) administrativia {agenda bashing/minutes} >>>> 2) time latency aspects >>>> 3) AOB >>> >>> >>> >>> _______________________________________________ >>> 6tisch-security mailing list >>> 6tisch-security@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch-security >> >> >> -- >> email:rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------080903000209070809070800 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Malisa:

In fact, I think my note on approximation of reals by rational numbers was too pessimistic: my two-line argument for the 1/(C+1) density formula should hold in general.

Two further notes:
a) It seems one can easily extend the argument to cases where one inserts some "don't care" timeslot (Rx/Tx by any device) and include those in the C tally (if there are no clashes in access to that cell).
b) I think random scheduling is not really optimum, since there are wide variations in latency from the average. For more deterministic time latencies, one might want to look into schemes that have a much smaller variance.

Best regards, Rene

On 2/17/2015 3:17 PM, Malisa Vucinic wrote:
Hi Rene,

Thanks for confirming my calculation.

I agree that theoretically this assumes infinite number of timeslots in a slotframe but I believe it should be accurate enough for C << L. 

Regards,
Malisa

On 17 Feb 2015, at 09:39, Rene Struik <rstruik.ext@gmail.com> wrote:

Hi Malisa:

I had a closer look at the slides you presented at the 6TiSCH security call this morning, Feb 17, 2015.

Slide 3 presents time latency numbers in case of a random TSCH schedule with C cells per slotframe, where the slotframe length is L time slots. I was trying to come up with an easy explanation for your time latency figure of ~ 1/(C+1)  the slotframe length between receiving a frame and sending a response in the next available dedicated "sending cell".

It turns out one can do this without any nontrivial math. See below.

Assumptions:
-w.l.o.g., receipt by A of frame from B ("A <--B") is at time zero (since schedule repeats)
-sending schedule of A: t cells, dividing up the unite line [0,1] in intervals of length L1, L2, ..., L{t+1}.
- t>0 (o.w., A is mute).

Observe that any schedule of t cells corresponds 1-1 with a partitioning of the unit line [0,1]. Moreover, if (L1,L2, ..., L{t+1}) is a schedule, then so is any permutation hereof. As a result, the average size of the first segment over all schedules is (L1+ .... + L{t+1})/(t+1)=1/(t+1): simply add up the first segment of the schedules (L1,L2, ..., L{t+1}), (L2,L3, ..., L{t+1}, L1), ..., (L{t+1},L1, ..., Lt).
The result follows (take t:=C).

Note: this assumes one has infinity many timeslots in a slotframe, so that one can approximate rational numbers by real numbers and one can ignore Li=Lj occurrences.(
 

On 2/16/2015 8:14 PM, Malisa Vucinic wrote:
Hi all,

I prepared a couple of slides on latency aspects with TSCH that can hopefully be useful for evaluating different proposals for the join process once there are more details on message sizes involved.

Regards,
Malisa




On 09 Feb 2015, at 20:50, Rene Struik <rstruik.ext@gmail.com> wrote:

Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue February 10, 2015, 4.30pm EST. 

I have not seen any email traffic the last two weeks, nor any more feedback on the draft document I posted on Fri January 9th.

I put as tentative item on the agenda "time latency aspects" of the join protocol. I will send out a more definitive agenda tomorrow around noon EST. Please send agenda request to me prior to that time.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) time latency aspects
3) AOB



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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------080903000209070809070800-- From nobody Tue Feb 17 13:23:39 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BFA1A90B4 for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 13:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.655 X-Spam-Level: X-Spam-Status: No, score=0.655 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 B6m74-cfynFr for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 13:23:31 -0800 (PST) Received: from p02c11o149.mxlogic.net (p02c11o149.mxlogic.net [208.65.144.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EAC91A88AD for <6tisch-security@ietf.org>; Tue, 17 Feb 2015 13:23:31 -0800 (PST) Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c11o149.mxlogic.net(mxl_mta-8.2.0-3) with ESMTP id 351b3e45.2b2d60439940.121273.00-548.342220.p02c11o149.mxlogic.net (envelope-from ); Tue, 17 Feb 2015 14:23:31 -0700 (MST) X-MXL-Hash: 54e3b153016380c0-bfa047449f8b0d6fc988c18ab8d8f4d80f1325c3 Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c11o149.mxlogic.net(mxl_mta-8.2.0-3) with ESMTP id 051b3e45.0.121234.00-394.342066.p02c11o149.mxlogic.net (envelope-from ); Tue, 17 Feb 2015 14:23:30 -0700 (MST) X-MXL-Hash: 54e3b1526e02345a-5fc298a90c3dcae28a729c4aea161ba8c5cea66f Received: from jsimonmacmini.engineering.linear.com (unknown [10.70.48.25]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 299D4740AC; Tue, 17 Feb 2015 13:23:26 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C8B573FD-E16A-4D34-90C2-F7F7782817BC"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jonathan Simon In-Reply-To: <54E3A4D2.8090907@gmail.com> Date: Tue, 17 Feb 2015 13:23:10 -0800 Message-Id: <63410C6A-3545-4A24-B83C-F24E7D3A93A4@linear.com> References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> <54D98E01.4090103@gmail.com> <8E377EDE-074F-472E-B397-86F29AEDEB19@imag.fr> <54E37CD5.7090405@gmail.com> <4EDC1B3D-8E75-4FA8-8B3E-E458B3A9CAA8@imag.fr> <54E3A4D2.8090907@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.1878.6) X-AnalysisOut: [v=2.1 cv=QuhK3DCd c=1 sm=1 tr=0 a=glloKNylpeYNumXQcclYyA==] X-AnalysisOut: [:117 a=glloKNylpeYNumXQcclYyA==:17 a=BLceEmwcHowA:10 a=MqD] X-AnalysisOut: [INYqSAAAA:8 a=YlVTAMxIAAAA:8 a=0HtSIViG9nkA:10 a=pGLkceISA] X-AnalysisOut: [AAA:8 a=48vgC7mUAAAA:8 a=SyYMxH9GAAAA:8 a=Yrk9MYh4Wmo2tX_H] X-AnalysisOut: [kXUA:9 a=MbdPFG_gbaFntUb1:21 a=34fiiZHwzVW8idbF:21 a=pILNO] X-AnalysisOut: [xqGKmIA:10 a=wUAfXdCGL-oA:10 a=G1HyQLfxkfkA:10 a=yRLhjdVT-] X-AnalysisOut: [pYA:10 a=uztyEWA5df8A:10 a=AeFSex2-gKoA:10 a=Vr3WXsJME7xhy] X-AnalysisOut: [X0Uyr0A:9 a=rBkI91ZXHF6AwN_D:21 a=UH4AEIQ9UHvWpRbd:21 a=Io] X-AnalysisOut: [HcNLBCkxE_Ncbi:21 a=_W_S_7VecoQA:10 a=NPI4PQ6hFa3hbkAUJZsA] X-AnalysisOut: [:9 a=ZVk8-NSrHBgA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2015021712); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [12.218.215.72] Archived-At: Cc: Malisa Vucinic , 6tisch-security@ietf.org Subject: Re: [6tisch-security] (simplified explanation of formulae) Re: Latency aspects of TSCH X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 21:23:34 -0000 --Apple-Mail=_C8B573FD-E16A-4D34-90C2-F7F7782817BC Content-Type: multipart/alternative; boundary="Apple-Mail=_17502A44-4CF7-4805-BC05-DE132DB4AFC5" --Apple-Mail=_17502A44-4CF7-4805-BC05-DE132DB4AFC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It is also worth noting that it is implicit in the calculation that: * the the devices in question always have available buffers such that = there isn=92t a lot of backoff * that any security related processing can happen before any subsequent = steps that rely on said processing occur. This may not be true for ECC = operations or generation and testing of large primes. Jonathan On Feb 17, 2015, at 12:30 PM, Rene Struik wrote: > Hi Malisa: >=20 > In fact, I think my note on approximation of reals by rational numbers = was too pessimistic: my two-line argument for the 1/(C+1) density = formula should hold in general. >=20 > Two further notes: > a) It seems one can easily extend the argument to cases where one = inserts some "don't care" timeslot (Rx/Tx by any device) and include = those in the C tally (if there are no clashes in access to that cell). > b) I think random scheduling is not really optimum, since there are = wide variations in latency from the average. For more deterministic time = latencies, one might want to look into schemes that have a much smaller = variance. >=20 > Best regards, Rene >=20 > On 2/17/2015 3:17 PM, Malisa Vucinic wrote: >> Hi Rene, >>=20 >> Thanks for confirming my calculation. >>=20 >> I agree that theoretically this assumes infinite number of timeslots = in a slotframe but I believe it should be accurate enough for C << L.=20 >>=20 >> Regards, >> Malisa >>=20 >>> On 17 Feb 2015, at 09:39, Rene Struik wrote: >>>=20 >>> Hi Malisa: >>>=20 >>> I had a closer look at the slides you presented at the 6TiSCH = security call this morning, Feb 17, 2015. >>>=20 >>> Slide 3 presents time latency numbers in case of a random TSCH = schedule with C cells per slotframe, where the slotframe length is L = time slots. I was trying to come up with an easy explanation for your = time latency figure of ~ 1/(C+1) the slotframe length between receiving = a frame and sending a response in the next available dedicated "sending = cell".=20 >>>=20 >>> It turns out one can do this without any nontrivial math. See below. >>>=20 >>> Assumptions: >>> -w.l.o.g., receipt by A of frame from B ("A <--B") is at time zero = (since schedule repeats) >>> -sending schedule of A: t cells, dividing up the unite line [0,1] in = intervals of length L1, L2, ..., L{t+1}. >>> - t>0 (o.w., A is mute). >>>=20 >>> Observe that any schedule of t cells corresponds 1-1 with a = partitioning of the unit line [0,1]. Moreover, if (L1,L2, ..., L{t+1}) = is a schedule, then so is any permutation hereof. As a result, the = average size of the first segment over all schedules is (L1+ .... + = L{t+1})/(t+1)=3D1/(t+1): simply add up the first segment of the = schedules (L1,L2, ..., L{t+1}), (L2,L3, ..., L{t+1}, L1), ..., = (L{t+1},L1, ..., Lt). >>> The result follows (take t:=3DC). >>>=20 >>> Note: this assumes one has infinity many timeslots in a slotframe, = so that one can approximate rational numbers by real numbers and one can = ignore Li=3DLj occurrences.( >>> =20 >>>=20 >>> On 2/16/2015 8:14 PM, Malisa Vucinic wrote: >>>> Hi all, >>>>=20 >>>> I prepared a couple of slides on latency aspects with TSCH that can = hopefully be useful for evaluating different proposals for the join = process once there are more details on message sizes involved. >>>>=20 >>>> Regards, >>>> Malisa >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> On 09 Feb 2015, at 20:50, Rene Struik = wrote: >>>>>=20 >>>>> Dear colleagues: >>>>>=20 >>>>> Just a quick reminder that we have a 6TiSCH security conf call = tomorrow, Tue February 10, 2015, 4.30pm EST.=20 >>>>>=20 >>>>> I have not seen any email traffic the last two weeks, nor any more = feedback on the draft document I posted on Fri January 9th. >>>>>=20 >>>>> I put as tentative item on the agenda "time latency aspects" of = the join protocol. I will send out a more definitive agenda tomorrow = around noon EST. Please send agenda request to me prior to that time. >>>>>=20 >>>>> Suggested agenda: >>>>> 1) administrativia {agenda bashing/minutes} >>>>> 2) time latency aspects >>>>> 3) AOB >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 6tisch-security mailing list >>>> 6tisch-security@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6tisch-security >>>=20 >>>=20 >>> --=20 >>> email: rstruik.ext@gmail.com | Skype: rstruik >>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>=20 >=20 >=20 > --=20 > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > = http://cp.mcafee.com/d/avndygQ73gOrhojojK_tyVKVJ5MsOCrhs7cLCQn1NEVhjpd79JN= VVVNyZPoziiJo0E-kfSfbCPVg_oYKrtZzmvovW_9zzhO-qehPfnKnjh7fsMyCqenNNEVVqWdAk= RrzAul3PWApmU6CQjq9K_8K6zBdCUVMQsFCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjX= dNBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04SPtMQsTdwLQzh0qmT9OFoCnFZCUOCmdbFEwd559= aH7OtBW1EwYfmfS6PBm1EwGWq87qNlrfTPhiq80nWhEw2KP-5yNEw1_SDgQgltd409618bCTD3= vah6 --Apple-Mail=_17502A44-4CF7-4805-BC05-DE132DB4AFC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 It is = also worth noting that it is implicit in the calculation = that:

* the the devices in question always have = available buffers such that there isn=92t a lot of backoff
* = that any security related processing can happen before any subsequent = steps that rely on said processing occur.  This may not be true for = ECC operations or generation and testing of large = primes.

Jonathan

On Feb 17, 2015, at 12:30 PM, Rene Struik <rstruik.ext@gmail.com> = wrote:

=20 =20 =20
Hi Malisa:

In fact, I think my note on approximation of reals by rational numbers was too pessimistic: my two-line argument for the 1/(C+1) density formula should hold in general.

Two further notes:
a) It seems one can easily extend the argument to cases where one inserts some "don't care" timeslot (Rx/Tx by any device) and include those in the C tally (if there are no clashes in access to that cell).
b) I think random scheduling is not really optimum, since there are wide variations in latency from the average. For more deterministic time latencies, one might want to look into schemes that have a much smaller variance.

Best regards, Rene

On 2/17/2015 3:17 PM, Malisa Vucinic wrote:
=20 Hi Rene,

Thanks for confirming my calculation.

I agree that theoretically this assumes infinite number of timeslots in a slotframe but I believe it should be accurate enough for C << L. 

Regards,
Malisa

On 17 Feb 2015, at 09:39, Rene Struik <rstruik.ext@gmail.com> wrote:

=20
Hi Malisa:

I had a closer look at the slides you presented at the 6TiSCH security call this morning, Feb 17, 2015.

Slide 3 presents time latency numbers in case of a random TSCH schedule with C cells per slotframe, where the slotframe length is L time slots. I was trying to come up with an easy explanation for your time latency figure of ~ 1/(C+1)  the slotframe length between receiving a frame and sending a response in the next available dedicated "sending cell".

It turns out one can do this without any nontrivial math. See below.

Assumptions:
-w.l.o.g., receipt by A of frame from B ("A <--B") is at time zero (since schedule repeats)
-sending schedule of A: t cells, dividing up the unite line [0,1] in intervals of length L1, L2, ..., = L{t+1}.
- t>0 (o.w., A is mute).

Observe that any schedule of t cells corresponds 1-1 with a partitioning of the unit line [0,1]. Moreover, if (L1,L2, ..., L{t+1}) is a schedule, then so is any permutation hereof. As a result, the average size of the first segment over all schedules is (L1+ .... + L{t+1})/(t+1)=3D1/(t+1): simply add up the first = segment of the schedules (L1,L2, ..., L{t+1}), (L2,L3, ..., L{t+1}, L1), ..., (L{t+1},L1, ..., Lt).
The result follows (take t:=3DC).

Note: this assumes one has infinity many timeslots in a slotframe, so that one can approximate rational numbers by real numbers and one can ignore Li=3DLj occurrences.(
 

On 2/16/2015 8:14 PM, Malisa Vucinic wrote:
=20 Hi all,

I prepared a couple of slides on = latency aspects with TSCH that can hopefully be useful for evaluating different proposals for the join process once there are more details on message sizes involved.

Regards,
Malisa



=20

On 09 Feb 2015, at 20:50, Rene Struik <rstruik.ext@gmail.com> wrote:

Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue February 10, 2015, 4.30pm EST. 

I have not seen any email traffic the last two weeks, nor any more feedback on the draft document I posted on Fri January = 9th.

I put as tentative item on the agenda "time latency aspects" of the join protocol. I will send out a more definitive agenda tomorrow around noon EST. Please send agenda request to me prior to that time.

Suggested agenda:
1)= administrativia {agenda = bashing/minutes}
2)= time latency aspects
3)= AOB



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



--=20
email: rstruik.ext@gmail.com | Skype: =
rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363



--=20
email: rstruik.ext@gmail.com | Skype: =
rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
6tisch-security = mailing list
6tisch-security@ietf.org
h= ttp://cp.mcafee.com/d/avndygQ73gOrhojojK_tyVKVJ5MsOCrhs7cLCQn1NEVhjpd79JNV= VVNyZPoziiJo0E-kfSfbCPVg_oYKrtZzmvovW_9zzhO-qehPfnKnjh7fsMyCqenNNEVVqWdAkR= rzAul3PWApmU6CQjq9K_8K6zBdCUVMQsFCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjXd= NBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04SPtMQsTdwLQzh0qmT9OFoCnFZCUOCmdbFEwd559a= H7OtBW1EwYfmfS6PBm1EwGWq87qNlrfTPhiq80nWhEw2KP-5yNEw1_SDgQgltd409618bCTD3v= ah6

= --Apple-Mail=_17502A44-4CF7-4805-BC05-DE132DB4AFC5-- --Apple-Mail=_C8B573FD-E16A-4D34-90C2-F7F7782817BC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIBiDCCAYQw ggEpoAMCAQICAwHiQDAKBggqhkjOPQQDAjBKMRkwFwYDVQQDDBBKb25hdGhhbiBTaW1vbiAxMQsw CQYDVQQGEwJVUzEgMB4GCSqGSIb3DQEJARYRanNpbW9uQGxpbmVhci5jb20wHhcNMTUwMTA5MTgy NjI1WhcNMTYwMTA5MTgyNjI1WjBKMRkwFwYDVQQDDBBKb25hdGhhbiBTaW1vbiAxMQswCQYDVQQG EwJVUzEgMB4GCSqGSIb3DQEJARYRanNpbW9uQGxpbmVhci5jb20wWTATBgcqhkjOPQIBBggqhkjO PQMBBwNCAATk/cMZz8sYhwIeYQWKBOA1zFbrDsjl0a5uqUYpxynjUFbFHLOA0gcED6decefxLYey x5t84Quh52wqaBUr0CSBMAoGCCqGSM49BAMCA0kAMEYCIQCG7qwBSE/rQXufjLpOuqNilQUYUh1V 6XNYeffT+nJktgIhAI30apRItPgMa3uHhgbQ9Np10J7wgKERpgcXWruQguUDMYIB4TCCAd0CAQEw UTBKMRkwFwYDVQQDDBBKb25hdGhhbiBTaW1vbiAxMQswCQYDVQQGEwJVUzEgMB4GCSqGSIb3DQEJ ARYRanNpbW9uQGxpbmVhci5jb20CAwHiQDAJBgUrDgMCGgUAoIIBIzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAyMTcyMTIzMTFaMCMGCSqGSIb3DQEJBDEWBBQt exQG2oP9V7KYkU16f5CgF7VjeDBgBgkrBgEEAYI3EAQxUzBRMEoxGTAXBgNVBAMMEEpvbmF0aGFu IFNpbW9uIDExCzAJBgNVBAYTAlVTMSAwHgYJKoZIhvcNAQkBFhFqc2ltb25AbGluZWFyLmNvbQID AeJAMGIGCyqGSIb3DQEJEAILMVOgUTBKMRkwFwYDVQQDDBBKb25hdGhhbiBTaW1vbiAxMQswCQYD VQQGEwJVUzEgMB4GCSqGSIb3DQEJARYRanNpbW9uQGxpbmVhci5jb20CAwHiQDAJBgcqhkjOPQIB BEgwRgIhAIfeOVIBDHUsmaFcva04XRh/6ItzfuDuVMBqXHnxlJt+AiEAo9+59VSNBkgQZs/0uwMm MC+LGzS5sGiWhBTIRGVEOOoAAAAAAAA= --Apple-Mail=_C8B573FD-E16A-4D34-90C2-F7F7782817BC-- From nobody Tue Feb 17 13:44:01 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3DA1A8A6B for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 13:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.59 X-Spam-Level: X-Spam-Status: No, score=0.59 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, J_CHICKENPOX_22=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 kbeq0SftWzjc for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 13:43:57 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 190CC1A0102 for <6tisch-security@ietf.org>; Tue, 17 Feb 2015 13:43:57 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id hl2so32660039igb.3 for <6tisch-security@ietf.org>; Tue, 17 Feb 2015 13:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=N74JTXXSZMaSzPNMWa6YMHebjNgpJhqTIX1zml5ms3w=; b=oxRzunwLuShEsm+uChpnzBE2nVxOK9fMJGzWaFgzOJXlfvKp4u10r8m/V4nEqGGtvv vKYNuW+P3L8kfEibPs4TrAjEXcm7lhziu0q6C6/xzzZK9O/0uQBXPmgf/HXVV7NeZaZL D73JFHZR/YOWM0EXpJnYrQcVX0ibW3+sKeR/nagLCNsxlPkBCQHiC/7TsPPcliHXAMhU 1bAnCww+pT0Ki6v6xXvl3SoIGJfnmXKfEF6Dzv0Tv1NU7JutKgLLXk+UvpEa9dCaP5JQ u0yTyVWk8lRWluRW64DM6lqj5fI5jNi6cSGljlYUBmjBXVY7eIgVtlR4aQw3Xi0SQQrM 5G2w== X-Received: by 10.50.78.232 with SMTP id e8mr30505786igx.5.1424209436325; Tue, 17 Feb 2015 13:43:56 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id h19sm10759209igq.10.2015.02.17.13.43.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Feb 2015 13:43:55 -0800 (PST) Message-ID: <54E3B604.5010803@gmail.com> Date: Tue, 17 Feb 2015 16:43:32 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jonathan Simon References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> <54D98E01.4090103@gmail.com> <8E377EDE-074F-472E-B397-86F29AEDEB19@imag.fr> <54E37CD5.7090405@gmail.com> <4EDC1B3D-8E75-4FA8-8B3E-E458B3A9CAA8@imag.fr> <54E3A4D2.8090907@gmail.com> <63410C6A-3545-4A24-B83C-F24E7D3A93A4@linear.com> In-Reply-To: <63410C6A-3545-4A24-B83C-F24E7D3A93A4@linear.com> Content-Type: multipart/alternative; boundary="------------010605050302020100010205" Archived-At: Cc: Malisa Vucinic , 6tisch-security@ietf.org Subject: Re: [6tisch-security] (simplified explanation of formulae) Re: Latency aspects of TSCH X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 21:44:00 -0000 This is a multi-part message in MIME format. --------------010605050302020100010205 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Jonathan: Well, given the example on Slide 5 re DTLS with pre-shared keys, time latency is mainly driven by communication delays (due to TSCH scheduling) and computational delays are relatively marginal in comparison (the conclusion applies public-key based approaches as well). Please also see the eight month old (June 11, 2014) message with a similar conclusion: http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00153.html BTW - there is no need to generate or test prime numbers, since it would be suicidal to consider RSA. Best regards, Rene On 2/17/2015 4:23 PM, Jonathan Simon wrote: > It is also worth noting that it is implicit in the calculation that: > > * the the devices in question always have available buffers such that > there isn’t a lot of backoff > * that any security related processing can happen before any > subsequent steps that rely on said processing occur. This may not be > true for ECC operations or generation and testing of large primes. > > Jonathan > > On Feb 17, 2015, at 12:30 PM, Rene Struik > wrote: > >> Hi Malisa: >> >> In fact, I think my note on approximation of reals by rational >> numbers was too pessimistic: my two-line argument for the 1/(C+1) >> density formula should hold in general. >> >> Two further notes: >> a) It seems one can easily extend the argument to cases where one >> inserts some "don't care" timeslot (Rx/Tx by any device) and include >> those in the C tally (if there are no clashes in access to that cell). >> b) I think random scheduling is not really optimum, since there are >> wide variations in latency from the average. For more deterministic >> time latencies, one might want to look into schemes that have a much >> smaller variance. >> >> Best regards, Rene >> >> On 2/17/2015 3:17 PM, Malisa Vucinic wrote: >>> Hi Rene, >>> >>> Thanks for confirming my calculation. >>> >>> I agree that theoretically this assumes infinite number of timeslots >>> in a slotframe but I believe it should be accurate enough for C << L. >>> >>> Regards, >>> Malisa >>> >>>> On 17 Feb 2015, at 09:39, Rene Struik >>> > wrote: >>>> >>>> Hi Malisa: >>>> >>>> I had a closer look at the slides you presented at the 6TiSCH >>>> security call this morning, Feb 17, 2015. >>>> >>>> Slide 3 presents time latency numbers in case of a random TSCH >>>> schedule with C cells per slotframe, where the slotframe length is >>>> L time slots. I was trying to come up with an easy explanation for >>>> your time latency figure of ~ 1/(C+1) the slotframe length between >>>> receiving a frame and sending a response in the next available >>>> dedicated "sending cell". >>>> >>>> It turns out one can do this without any nontrivial math. See below. >>>> >>>> Assumptions: >>>> -w.l.o.g., receipt by A of frame from B ("A <--B") is at time zero >>>> (since schedule repeats) >>>> -sending schedule of A: t cells, dividing up the unite line [0,1] >>>> in intervals of length L1, L2, ..., L{t+1}. >>>> - t>0 (o.w., A is mute). >>>> >>>> Observe that any schedule of t cells corresponds 1-1 with a >>>> partitioning of the unit line [0,1]. Moreover, if (L1,L2, ..., >>>> L{t+1}) is a schedule, then so is any permutation hereof. As a >>>> result, the average size of the first segment over all schedules is >>>> (L1+ .... + L{t+1})/(t+1)=1/(t+1): simply add up the first segment >>>> of the schedules (L1,L2, ..., L{t+1}), (L2,L3, ..., L{t+1}, L1), >>>> ..., (L{t+1},L1, ..., Lt). >>>> The result follows (take t:=C). >>>> >>>> Note: this assumes one has infinity many timeslots in a slotframe, >>>> so that one can approximate rational numbers by real numbers and >>>> one can ignore Li=Lj occurrences.( >>>> >>>> >>>> On 2/16/2015 8:14 PM, Malisa Vucinic wrote: >>>>> Hi all, >>>>> >>>>> I prepared a couple of slides on latency aspects with TSCH that >>>>> can hopefully be useful for evaluating different proposals for the >>>>> join process once there are more details on message sizes involved. >>>>> >>>>> Regards, >>>>> Malisa >>>>> >>>>> >>>>> >>>>> >>>>>> On 09 Feb 2015, at 20:50, Rene Struik >>>>> > wrote: >>>>>> >>>>>> Dear colleagues: >>>>>> >>>>>> Just a quick reminder that we have a 6TiSCH security conf call >>>>>> tomorrow, Tue February 10, 2015, 4.30pm EST. >>>>>> >>>>>> I have not seen any email traffic the last two weeks, nor any >>>>>> more feedback on the draft document I posted on Fri January 9th. >>>>>> >>>>>> I put as tentative item on the agenda "time latency aspects" of >>>>>> the join protocol. I will send out a more definitive agenda >>>>>> tomorrow around noon EST. Please send agenda request to me prior >>>>>> to that time. >>>>>> >>>>>> Suggested agenda: >>>>>> 1) administrativia {agenda bashing/minutes} >>>>>> 2) time latency aspects >>>>>> 3) AOB >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 6tisch-security mailing list >>>>> 6tisch-security@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6tisch-security >>>> >>>> >>>> -- >>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>> >> >> >> -- >> email:rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >> _______________________________________________ >> 6tisch-security mailing list >> 6tisch-security@ietf.org >> http://cp.mcafee.com/d/avndygQ73gOrhojojK_tyVKVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKrtZzmvovW_9zzhO-qehPfnKnjh7fsMyCqenNNEVVqWdAkRrzAul3PWApmU6CQjq9K_8K6zBdCUVMQsFCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjXdNBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04SPtMQsTdwLQzh0qmT9OFoCnFZCUOCmdbFEwd559aH7OtBW1EwYfmfS6PBm1EwGWq87qNlrfTPhiq80nWhEw2KP-5yNEw1_SDgQgltd409618bCTD3vah6 > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------010605050302020100010205 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Jonathan:

Well, given the example on Slide 5 re DTLS with pre-shared keys, time latency is mainly driven by communication delays (due to TSCH scheduling) and computational delays are relatively marginal in comparison (the conclusion applies public-key based approaches as well). Please also see the eight month old (June 11, 2014) message with a similar conclusion: http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00153.html

BTW - there is no need to generate or test prime numbers, since it would be suicidal to consider RSA.

Best regards, Rene

On 2/17/2015 4:23 PM, Jonathan Simon wrote:
It is also worth noting that it is implicit in the calculation that:

* the the devices in question always have available buffers such that there isn’t a lot of backoff
* that any security related processing can happen before any subsequent steps that rely on said processing occur.  This may not be true for ECC operations or generation and testing of large primes.

Jonathan

On Feb 17, 2015, at 12:30 PM, Rene Struik <rstruik.ext@gmail.com> wrote:

Hi Malisa:

In fact, I think my note on approximation of reals by rational numbers was too pessimistic: my two-line argument for the 1/(C+1) density formula should hold in general.

Two further notes:
a) It seems one can easily extend the argument to cases where one inserts some "don't care" timeslot (Rx/Tx by any device) and include those in the C tally (if there are no clashes in access to that cell).
b) I think random scheduling is not really optimum, since there are wide variations in latency from the average. For more deterministic time latencies, one might want to look into schemes that have a much smaller variance.

Best regards, Rene

On 2/17/2015 3:17 PM, Malisa Vucinic wrote:
Hi Rene,

Thanks for confirming my calculation.

I agree that theoretically this assumes infinite number of timeslots in a slotframe but I believe it should be accurate enough for C << L. 

Regards,
Malisa

On 17 Feb 2015, at 09:39, Rene Struik <rstruik.ext@gmail.com> wrote:

Hi Malisa:

I had a closer look at the slides you presented at the 6TiSCH security call this morning, Feb 17, 2015.

Slide 3 presents time latency numbers in case of a random TSCH schedule with C cells per slotframe, where the slotframe length is L time slots. I was trying to come up with an easy explanation for your time latency figure of ~ 1/(C+1)  the slotframe length between receiving a frame and sending a response in the next available dedicated "sending cell".

It turns out one can do this without any nontrivial math. See below.

Assumptions:
-w.l.o.g., receipt by A of frame from B ("A <--B") is at time zero (since schedule repeats)
-sending schedule of A: t cells, dividing up the unite line [0,1] in intervals of length L1, L2, ..., L{t+1}.
- t>0 (o.w., A is mute).

Observe that any schedule of t cells corresponds 1-1 with a partitioning of the unit line [0,1]. Moreover, if (L1,L2, ..., L{t+1}) is a schedule, then so is any permutation hereof. As a result, the average size of the first segment over all schedules is (L1+ .... + L{t+1})/(t+1)=1/(t+1): simply add up the first segment of the schedules (L1,L2, ..., L{t+1}), (L2,L3, ..., L{t+1}, L1), ..., (L{t+1},L1, ..., Lt).
The result follows (take t:=C).

Note: this assumes one has infinity many timeslots in a slotframe, so that one can approximate rational numbers by real numbers and one can ignore Li=Lj occurrences.(
 

On 2/16/2015 8:14 PM, Malisa Vucinic wrote:
Hi all,

I prepared a couple of slides on latency aspects with TSCH that can hopefully be useful for evaluating different proposals for the join process once there are more details on message sizes involved.

Regards,
Malisa




On 09 Feb 2015, at 20:50, Rene Struik <rstruik.ext@gmail.com> wrote:

Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue February 10, 2015, 4.30pm EST. 

I have not seen any email traffic the last two weeks, nor any more feedback on the draft document I posted on Fri January 9th.

I put as tentative item on the agenda "time latency aspects" of the join protocol. I will send out a more definitive agenda tomorrow around noon EST. Please send agenda request to me prior to that time.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) time latency aspects
3) AOB



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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
6tisch-security mailing list
6tisch-security@ietf.org
http://cp.mcafee.com/d/avndygQ73gOrhojojK_tyVKVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKrtZzmvovW_9zzhO-qehPfnKnjh7fsMyCqenNNEVVqWdAkRrzAul3PWApmU6CQjq9K_8K6zBdCUVMQsFCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjXdNBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04SPtMQsTdwLQzh0qmT9OFoCnFZCUOCmdbFEwd559aH7OtBW1EwYfmfS6PBm1EwGWq87qNlrfTPhiq80nWhEw2KP-5yNEw1_SDgQgltd409618bCTD3vah6



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------010605050302020100010205-- From nobody Tue Feb 17 14:04:40 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444AC1A88F8 for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 14:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.945 X-Spam-Level: X-Spam-Status: No, score=-0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 OgnN-gLL8MJe for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 14:04:35 -0800 (PST) Received: from p01c11o145.mxlogic.net (p01c11o145.mxlogic.net [208.65.144.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF181A90E5 for <6tisch-security@ietf.org>; Tue, 17 Feb 2015 14:04:33 -0800 (PST) Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p01c11o145.mxlogic.net(mxl_mta-8.2.0-3) with ESMTP id 1fab3e45.2ac5dda28940.76525.00-505.214544.p01c11o145.mxlogic.net (envelope-from ); Tue, 17 Feb 2015 15:04:33 -0700 (MST) X-MXL-Hash: 54e3baf1353c9d2c-339b71d70fbd5699a0eb44a855d7311c0db5f917 Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p01c11o145.mxlogic.net(mxl_mta-8.2.0-3) with ESMTP id feab3e45.0.76493.00-390.214436.p01c11o145.mxlogic.net (envelope-from ); Tue, 17 Feb 2015 15:04:32 -0700 (MST) X-MXL-Hash: 54e3baf06fb5b865-1d55580aff345c32287f7771b5ba97474c09b10f Received: from jsimonmacmini.engineering.linear.com (unknown [10.70.48.25]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 156AA740AC; Tue, 17 Feb 2015 14:04:29 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_391B0BBF-8868-4FB2-A27C-2EE197FF3768"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jonathan Simon In-Reply-To: <54E3B604.5010803@gmail.com> Date: Tue, 17 Feb 2015 14:04:13 -0800 Message-Id: <127C0B65-7497-4802-B52F-2161C7C6DA2B@linear.com> References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> <54D98E01.4090103@gmail.com> <8E377EDE-074F-472E-B397-86F29AEDEB19@imag.fr> <54E37CD5.7090405@gmail.com> <4EDC1B3D-8E75-4FA8-8B3E-E458B3A9CAA8@imag.fr> <54E3A4D2.8090907@gmail.com> <63410C6A-3545-4A24-B83C-F24E7D3A93A4@linear.com> <54E3B604.5010803@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.1878.6) X-AnalysisOut: [v=2.1 cv=T5yYTp6Q c=1 sm=1 tr=0 a=glloKNylpeYNumXQcclYyA==] X-AnalysisOut: [:117 a=glloKNylpeYNumXQcclYyA==:17 a=BLceEmwcHowA:10 a=MqD] X-AnalysisOut: [INYqSAAAA:8 a=YlVTAMxIAAAA:8 a=0HtSIViG9nkA:10 a=pGLkceISA] X-AnalysisOut: [AAA:8 a=48vgC7mUAAAA:8 a=SyYMxH9GAAAA:8 a=uF9fR3SGv_xFYXfr] X-AnalysisOut: [mI0A:9 a=Y0NuU6_WTuYkG1ob:21 a=Wv0wpCwRJniM8z2w:21 a=pILNO] X-AnalysisOut: [xqGKmIA:10 a=wUAfXdCGL-oA:10 a=G1HyQLfxkfkA:10 a=yRLhjdVT-] X-AnalysisOut: [pYA:10 a=uztyEWA5df8A:10 a=AeFSex2-gKoA:10 a=Aud5CB0dVL4A:] X-AnalysisOut: [10 a=lYRxd9FOY42EsXdLsG8A:9 a=8aJlJX3vi2q9nWKW:21 a=i6kgck] X-AnalysisOut: [7wriWD6xz3:21 a=dM7p9f4g3JoGwmjt:21 a=_W_S_7VecoQA:10 a=NP] X-AnalysisOut: [I4PQ6hFa3hbkAUJZsA:9 a=ZVk8-NSrHBgA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2015021712); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [12.218.215.72] Archived-At: Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (simplified explanation of formulae) Re: Latency aspects of TSCH X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 22:04:38 -0000 --Apple-Mail=_391B0BBF-8868-4FB2-A27C-2EE197FF3768 Content-Type: multipart/alternative; boundary="Apple-Mail=_B20EB383-B62A-458A-A291-253F5DAD6EDD" --Apple-Mail=_B20EB383-B62A-458A-A291-253F5DAD6EDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Rene - Thanks.=20 I agree that RSA is absurd in this context, but as I mentioned in one of = the calls, some of the base standards use RSA signatures, e.g. RFC6550 = (RPL) calls out RSA with SHA-256, so=20 a) I=92m not sure what people are thinking in terms of shared key = establishment (hopefully not RSA), and b) we will need at some point to explicitly call out where we are using = other crytpo suites. =20 Jonathan On Feb 17, 2015, at 1:43 PM, Rene Struik wrote: > Hi Jonathan: >=20 > Well, given the example on Slide 5 re DTLS with pre-shared keys, time = latency is mainly driven by communication delays (due to TSCH = scheduling) and computational delays are relatively marginal in = comparison (the conclusion applies public-key based approaches as well). = Please also see the eight month old (June 11, 2014) message with a = similar conclusion: = http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00153.html= >=20 > BTW - there is no need to generate or test prime numbers, since it = would be suicidal to consider RSA. >=20 > Best regards, Rene >=20 > On 2/17/2015 4:23 PM, Jonathan Simon wrote: >> It is also worth noting that it is implicit in the calculation that: >>=20 >> * the the devices in question always have available buffers such that = there isn=92t a lot of backoff >> * that any security related processing can happen before any = subsequent steps that rely on said processing occur. This may not be = true for ECC operations or generation and testing of large primes. >>=20 >> Jonathan >>=20 >> On Feb 17, 2015, at 12:30 PM, Rene Struik = wrote: >>=20 >>> Hi Malisa: >>>=20 >>> In fact, I think my note on approximation of reals by rational = numbers was too pessimistic: my two-line argument for the 1/(C+1) = density formula should hold in general. >>>=20 >>> Two further notes: >>> a) It seems one can easily extend the argument to cases where one = inserts some "don't care" timeslot (Rx/Tx by any device) and include = those in the C tally (if there are no clashes in access to that cell). >>> b) I think random scheduling is not really optimum, since there are = wide variations in latency from the average. For more deterministic time = latencies, one might want to look into schemes that have a much smaller = variance. >>>=20 >>> Best regards, Rene >>>=20 >>> On 2/17/2015 3:17 PM, Malisa Vucinic wrote: >>>> Hi Rene, >>>>=20 >>>> Thanks for confirming my calculation. >>>>=20 >>>> I agree that theoretically this assumes infinite number of = timeslots in a slotframe but I believe it should be accurate enough for = C << L.=20 >>>>=20 >>>> Regards, >>>> Malisa >>>>=20 >>>>> On 17 Feb 2015, at 09:39, Rene Struik = wrote: >>>>>=20 >>>>> Hi Malisa: >>>>>=20 >>>>> I had a closer look at the slides you presented at the 6TiSCH = security call this morning, Feb 17, 2015. >>>>>=20 >>>>> Slide 3 presents time latency numbers in case of a random TSCH = schedule with C cells per slotframe, where the slotframe length is L = time slots. I was trying to come up with an easy explanation for your = time latency figure of ~ 1/(C+1) the slotframe length between receiving = a frame and sending a response in the next available dedicated "sending = cell".=20 >>>>>=20 >>>>> It turns out one can do this without any nontrivial math. See = below. >>>>>=20 >>>>> Assumptions: >>>>> -w.l.o.g., receipt by A of frame from B ("A <--B") is at time zero = (since schedule repeats) >>>>> -sending schedule of A: t cells, dividing up the unite line [0,1] = in intervals of length L1, L2, ..., L{t+1}. >>>>> - t>0 (o.w., A is mute). >>>>>=20 >>>>> Observe that any schedule of t cells corresponds 1-1 with a = partitioning of the unit line [0,1]. Moreover, if (L1,L2, ..., L{t+1}) = is a schedule, then so is any permutation hereof. As a result, the = average size of the first segment over all schedules is (L1+ .... + = L{t+1})/(t+1)=3D1/(t+1): simply add up the first segment of the = schedules (L1,L2, ..., L{t+1}), (L2,L3, ..., L{t+1}, L1), ..., = (L{t+1},L1, ..., Lt). >>>>> The result follows (take t:=3DC). >>>>>=20 >>>>> Note: this assumes one has infinity many timeslots in a slotframe, = so that one can approximate rational numbers by real numbers and one can = ignore Li=3DLj occurrences.( >>>>> =20 >>>>>=20 >>>>> On 2/16/2015 8:14 PM, Malisa Vucinic wrote: >>>>>> Hi all, >>>>>>=20 >>>>>> I prepared a couple of slides on latency aspects with TSCH that = can hopefully be useful for evaluating different proposals for the join = process once there are more details on message sizes involved. >>>>>>=20 >>>>>> Regards, >>>>>> Malisa >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On 09 Feb 2015, at 20:50, Rene Struik = wrote: >>>>>>>=20 >>>>>>> Dear colleagues: >>>>>>>=20 >>>>>>> Just a quick reminder that we have a 6TiSCH security conf call = tomorrow, Tue February 10, 2015, 4.30pm EST.=20 >>>>>>>=20 >>>>>>> I have not seen any email traffic the last two weeks, nor any = more feedback on the draft document I posted on Fri January 9th. >>>>>>>=20 >>>>>>> I put as tentative item on the agenda "time latency aspects" of = the join protocol. I will send out a more definitive agenda tomorrow = around noon EST. Please send agenda request to me prior to that time. >>>>>>>=20 >>>>>>> Suggested agenda: >>>>>>> 1) administrativia {agenda bashing/minutes} >>>>>>> 2) time latency aspects >>>>>>> 3) AOB >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> 6tisch-security mailing list >>>>>> 6tisch-security@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6tisch-security >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> email: rstruik.ext@gmail.com | Skype: rstruik >>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>>=20 >>>=20 >>>=20 >>> --=20 >>> email: rstruik.ext@gmail.com | Skype: rstruik >>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>> _______________________________________________ >>> 6tisch-security mailing list >>> 6tisch-security@ietf.org >>> = http://cp.mcafee.com/d/avndygQ73gOrhojojK_tyVKVJ5MsOCrhs7cLCQn1NEVhjpd79JN= VVVNyZPoziiJo0E-kfSfbCPVg_oYKrtZzmvovW_9zzhO-qehPfnKnjh7fsMyCqenNNEVVqWdAk= RrzAul3PWApmU6CQjq9K_8K6zBdCUVMQsFCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjX= dNBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04SPtMQsTdwLQzh0qmT9OFoCnFZCUOCmdbFEwd559= aH7OtBW1EwYfmfS6PBm1EwGWq87qNlrfTPhiq80nWhEw2KP-5yNEw1_SDgQgltd409618bCTD3= vah6 >>=20 >=20 >=20 > --=20 > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --Apple-Mail=_B20EB383-B62A-458A-A291-253F5DAD6EDD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Rene - = Thanks. 

I agree that RSA is absurd in this = context, but as I mentioned in one of the calls, some of the base = standards use RSA signatures, e.g. RFC6550 (RPL) calls out RSA with SHA-256, so 
a) I=92m = not sure what people are thinking in terms of shared key establishment = (hopefully not RSA), and
b) we will need at some point to explicitly = call out where we are using other crytpo suites. =  

Jonathan

On Feb 17, 2015, at 1:43 PM, Rene Struik <rstruik.ext@gmail.com> = wrote:

=20 =20 =20
Hi Jonathan:

Well, given the example on Slide 5 re DTLS with pre-shared keys, time latency is mainly driven by communication delays (due to TSCH scheduling) and computational delays are relatively marginal in comparison (the conclusion applies public-key based approaches as well). Please also see the eight month old (June 11, 2014) message with a similar conclusion: http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00153.= html

BTW - there is no need to generate or test prime numbers, since it would be suicidal to consider RSA.

Best regards, Rene

On 2/17/2015 4:23 PM, Jonathan Simon wrote:
=20 It is also worth noting that it is implicit in the calculation that:

* the the devices in question always have available buffers such that there isn=92t a lot of backoff
* that any security related processing can happen before any subsequent steps that rely on said processing occur.  This = may not be true for ECC operations or generation and testing of large primes.

Jonathan

On Feb 17, 2015, at 12:30 PM, Rene Struik <rstruik.ext@gmail.com> wrote:

Hi Malisa:

In fact, I think my note on approximation of reals by rational numbers was too pessimistic: my two-line argument for the 1/(C+1) density formula should hold in general.

Two further notes:
a) It seems one can easily extend the argument to cases where one inserts some "don't care" timeslot (Rx/Tx by any device) and include those in the C tally (if there are no clashes in access to that cell).
b) I think random scheduling is not really optimum, since there are wide variations in latency from the average. For more deterministic time latencies, one might want to look into schemes that have a much smaller variance.

Best regards, Rene

On 2/17/2015 3:17 PM, Malisa Vucinic wrote:
= Hi Rene,

Thanks for confirming my = calculation.

I agree that theoretically this assumes infinite number of timeslots in a slotframe but I believe it should be accurate enough for C << L. 

Regards,
Malisa

On 17 Feb 2015, at 09:39, Rene Struik <rstruik.ext@gmail.com> wrote:

Hi Malisa:

I had a closer look at the slides you presented at the 6TiSCH security call this morning, Feb 17, 2015.

Slide 3 presents time latency numbers in case of a random TSCH schedule with C cells per slotframe, where the slotframe length is L time slots. I was trying to come up with an easy explanation for your time latency figure of ~ 1/(C+1)  the slotframe = length between receiving a frame and sending a response in the next available dedicated "sending cell".

It turns out one can do this without any nontrivial math. See below.

Assumptions:
-w.l.o.g., receipt by A of frame from B ("A <--B") is at time zero (since schedule repeats)
-sending schedule of A: t cells, dividing up the unite line [0,1] in intervals of length L1, L2, ..., L{t+1}.
- t>0 (o.w., A is mute).

Observe that any schedule of t cells corresponds 1-1 with a partitioning of the unit line [0,1]. Moreover, if (L1,L2, ..., L{t+1}) is a schedule, then so is any permutation hereof. As a result, the average size of the first segment over all schedules is (L1+ .... + L{t+1})/(t+1)=3D1/(t+1): = simply add up the first segment of the schedules (L1,L2, ..., L{t+1}), (L2,L3, ..., L{t+1}, L1), ..., (L{t+1},L1, ..., Lt).
= The result follows (take t:=3DC).

Note: this assumes one has infinity many timeslots in a slotframe, so that one can approximate rational numbers by real numbers and one can ignore Li=3DLj occurrences.(
 

On 2/16/2015 8:14 PM, Malisa Vucinic = wrote:
Hi all,

I prepared a couple of = slides on latency aspects with TSCH that can hopefully be useful for evaluating different proposals for the join process once there are more details on message sizes involved.

Regards,
Malisa




On 09 Feb 2015, at = 20:50, Rene Struik <rstruik.ext@gmail.com> wrote:

Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue February 10, 2015, 4.30pm EST. 

I have not seen any email traffic the last two weeks, nor any more feedback on the draft document I posted on Fri January 9th.

I put as tentative item on the agenda "time latency aspects" of the join protocol. I will send out a more definitive agenda tomorrow around noon EST. Please send agenda request to me prior to that time.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) time latency aspects
3) = AOB



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



--=20
email: rstruik.ext@gmail.com | Skype: =
rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363



--=20
email: rstruik.ext@gmail.com | Skype: =
rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
6tisch-security mailing list
6tisch-security@ietf.org
http://cp.mcafee.com/d/avndygQ73gOrhojojK_tyVKVJ5MsOCrhs7cLC= Qn1NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKrtZzmvovW_9zzhO-qehPfnKnjh7fsMy= CqenNNEVVqWdAkRrzAul3PWApmU6CQjq9K_8K6zBdCUVMQsFCXCOsVHkiP2Di-rL00s4RtxxYG= jB1SKejBiNcLjXdNBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04SPtMQsTdwLQzh0qmT9OFoCnFZ= CUOCmdbFEwd559aH7OtBW1EwYfmfS6PBm1EwGWq87qNlrfTPhiq80nWhEw2KP-5yNEw1_SDgQg= ltd409618bCTD3vah6



--=20
email: rstruik.ext@gmail.com | Skype: =
rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

= --Apple-Mail=_B20EB383-B62A-458A-A291-253F5DAD6EDD-- --Apple-Mail=_391B0BBF-8868-4FB2-A27C-2EE197FF3768 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIBiDCCAYQw ggEpoAMCAQICAwHiQDAKBggqhkjOPQQDAjBKMRkwFwYDVQQDDBBKb25hdGhhbiBTaW1vbiAxMQsw CQYDVQQGEwJVUzEgMB4GCSqGSIb3DQEJARYRanNpbW9uQGxpbmVhci5jb20wHhcNMTUwMTA5MTgy NjI1WhcNMTYwMTA5MTgyNjI1WjBKMRkwFwYDVQQDDBBKb25hdGhhbiBTaW1vbiAxMQswCQYDVQQG EwJVUzEgMB4GCSqGSIb3DQEJARYRanNpbW9uQGxpbmVhci5jb20wWTATBgcqhkjOPQIBBggqhkjO PQMBBwNCAATk/cMZz8sYhwIeYQWKBOA1zFbrDsjl0a5uqUYpxynjUFbFHLOA0gcED6decefxLYey x5t84Quh52wqaBUr0CSBMAoGCCqGSM49BAMCA0kAMEYCIQCG7qwBSE/rQXufjLpOuqNilQUYUh1V 6XNYeffT+nJktgIhAI30apRItPgMa3uHhgbQ9Np10J7wgKERpgcXWruQguUDMYIB4TCCAd0CAQEw UTBKMRkwFwYDVQQDDBBKb25hdGhhbiBTaW1vbiAxMQswCQYDVQQGEwJVUzEgMB4GCSqGSIb3DQEJ ARYRanNpbW9uQGxpbmVhci5jb20CAwHiQDAJBgUrDgMCGgUAoIIBIzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAyMTcyMjA0MTRaMCMGCSqGSIb3DQEJBDEWBBTO 3fSaMHXoFkDgJRrRZmiKh9W+QjBgBgkrBgEEAYI3EAQxUzBRMEoxGTAXBgNVBAMMEEpvbmF0aGFu IFNpbW9uIDExCzAJBgNVBAYTAlVTMSAwHgYJKoZIhvcNAQkBFhFqc2ltb25AbGluZWFyLmNvbQID AeJAMGIGCyqGSIb3DQEJEAILMVOgUTBKMRkwFwYDVQQDDBBKb25hdGhhbiBTaW1vbiAxMQswCQYD VQQGEwJVUzEgMB4GCSqGSIb3DQEJARYRanNpbW9uQGxpbmVhci5jb20CAwHiQDAJBgcqhkjOPQIB BEgwRgIhAMRKpl0Vgt2ij0vAJbRm02RSWg2X4ajQGUdQRcn6gm+OAiEA56PKUdvNc/W1t4IOTLA4 eT+BA2Sv1kbxQgWNazI5UkIAAAAAAAA= --Apple-Mail=_391B0BBF-8868-4FB2-A27C-2EE197FF3768-- From nobody Wed Feb 18 12:05:32 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550D51A0390 for <6tisch-security@ietfa.amsl.com>; Wed, 18 Feb 2015 12:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.192 X-Spam-Level: *** X-Spam-Status: No, score=3.192 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, J_CHICKENPOX_22=0.6, 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 FgVLXwnKQsC9 for <6tisch-security@ietfa.amsl.com>; Wed, 18 Feb 2015 12:05:25 -0800 (PST) Received: from smtpdb7.aruba.it (smtpdb7.aruba.it [62.149.158.249]) by ietfa.amsl.com (Postfix) with ESMTP id 716EE1A0371 for <6tisch-security@ietf.org>; Wed, 18 Feb 2015 12:04:23 -0800 (PST) Received: from mail-pd0-f170.google.com ([209.85.192.170]) by smtpcmd03.ad.aruba.it with bizsmtp id tw4J1p00h3h2emh01w4Kxm; Wed, 18 Feb 2015 21:04:21 +0100 Received: by pdno5 with SMTP id o5so3434154pdn.8 for <6tisch-security@ietf.org>; Wed, 18 Feb 2015 12:04:19 -0800 (PST) X-Received: by 10.68.194.71 with SMTP id hu7mr1772275pbc.52.1424289859099; Wed, 18 Feb 2015 12:04:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.70.79.104 with HTTP; Wed, 18 Feb 2015 12:03:48 -0800 (PST) In-Reply-To: <127C0B65-7497-4802-B52F-2161C7C6DA2B@linear.com> References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> <54D98E01.4090103@gmail.com> <8E377EDE-074F-472E-B397-86F29AEDEB19@imag.fr> <54E37CD5.7090405@gmail.com> <4EDC1B3D-8E75-4FA8-8B3E-E458B3A9CAA8@imag.fr> <54E3A4D2.8090907@gmail.com> <63410C6A-3545-4A24-B83C-F24E7D3A93A4@linear.com> <54E3B604.5010803@gmail.com> <127C0B65-7497-4802-B52F-2161C7C6DA2B@linear.com> From: Giuseppe Piro Date: Wed, 18 Feb 2015 21:03:48 +0100 Message-ID: To: Malisa.Vucinic@imag.fr Content-Type: multipart/alternative; boundary=047d7b10ccc31be54f050f62538e Archived-At: Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (simplified explanation of formulae) Re: Latency aspects of TSCH X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 20:05:29 -0000 --047d7b10ccc31be54f050f62538e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Malisa, I've three little comments about the 5-th slide of your presentation http://www.ietf.org/mail-archive/web/6tisch-security/current/pdfWPK_6ZrxPI.= pdf 1. note that a timeslot of 10ms may not be enough for addressing all the L2 security procedures. Well, it depends from the selected security leve= l.. but in general they always require more computational capabilities 2. in a multi hop scenario, your estimation (i.e., 40 ms) should be valid if slots are properly allocated in the slotframe (maybe consecutiv= ely each other). Hence the assumption of "random scheduling" should not be m= ore valid 3. probably we need more than 3-4 frames for transmitting a certificate =E2=80=8BBasing from these comments, please, let me know if my understandin= g was wrong or not. Then, w.r.t certificates, could you please provide more details in order to justify the size fitting in 3-4 frames ? Best Regards and thanks a lot for your attention Giuseppe On Tue, Feb 17, 2015 at 11:04 PM, Jonathan Simon wrote: > Rene - Thanks. > > I agree that RSA is absurd in this context, but as I mentioned in one of > the calls, some of the base standards use RSA signatures, e.g. RFC6550 > (RPL) calls out RSA with SHA-256, so > a) I=E2=80=99m not sure what people are thinking in terms of shared key > establishment (hopefully not RSA), and > b) we will need at some point to explicitly call out where we are using > other crytpo suites. > > Jonathan > > On Feb 17, 2015, at 1:43 PM, Rene Struik wrote: > > Hi Jonathan: > > Well, given the example on Slide 5 re DTLS with pre-shared keys, time > latency is mainly driven by communication delays (due to TSCH scheduling) > and computational delays are relatively marginal in comparison (the > conclusion applies public-key based approaches as well). Please also see > the eight month old (June 11, 2014) message with a similar conclusion: > http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00153.htm= l > > > BTW - there is no need to generate or test prime numbers, since it would > be suicidal to consider RSA. > > Best regards, Rene > > On 2/17/2015 4:23 PM, Jonathan Simon wrote: > > It is also worth noting that it is implicit in the calculation that: > > * the the devices in question always have available buffers such that > there isn=E2=80=99t a lot of backoff > * that any security related processing can happen before any subsequent > steps that rely on said processing occur. This may not be true for ECC > operations or generation and testing of large primes. > > Jonathan > > On Feb 17, 2015, at 12:30 PM, Rene Struik wrote: > > Hi Malisa: > > In fact, I think my note on approximation of reals by rational numbers wa= s > too pessimistic: my two-line argument for the 1/(C+1) density formula > should hold in general. > > Two further notes: > a) It seems one can easily extend the argument to cases where one inserts > some "don't care" timeslot (Rx/Tx by any device) and include those in the= C > tally (if there are no clashes in access to that cell). > b) I think random scheduling is not really optimum, since there are wide > variations in latency from the average. For more deterministic time > latencies, one might want to look into schemes that have a much smaller > variance. > > Best regards, Rene > > On 2/17/2015 3:17 PM, Malisa Vucinic wrote: > > Hi Rene, > > Thanks for confirming my calculation. > > I agree that theoretically this assumes infinite number of timeslots in > a slotframe but I believe it should be accurate enough for C << L. > > Regards, > Malisa > > On 17 Feb 2015, at 09:39, Rene Struik wrote: > > Hi Malisa: > > I had a closer look at the slides you presented at the 6TiSCH security > call this morning, Feb 17, 2015. > > Slide 3 presents time latency numbers in case of a random TSCH schedule > with C cells per slotframe, where the slotframe length is L time slots. I > was trying to come up with an easy explanation for your time latency figu= re > of ~ 1/(C+1) the slotframe length between receiving a frame and sending = a > response in the next available dedicated "sending cell". > > It turns out one can do this without any nontrivial math. See below. > > Assumptions: > -w.l.o.g., receipt by A of frame from B ("A <--B") is at time zero (since > schedule repeats) > -sending schedule of A: t cells, dividing up the unite line [0,1] in > intervals of length L1, L2, ..., L{t+1}. > - t>0 (o.w., A is mute). > > Observe that any schedule of t cells corresponds 1-1 with a partitioning > of the unit line [0,1]. Moreover, if (L1,L2, ..., L{t+1}) is a schedule, > then so is any permutation hereof. As a result, the average size of the > first segment over all schedules is (L1+ .... + L{t+1})/(t+1)=3D1/(t+1): > simply add up the first segment of the schedules (L1,L2, ..., L{t+1}), > (L2,L3, ..., L{t+1}, L1), ..., (L{t+1},L1, ..., Lt). > The result follows (take t:=3DC). > > Note: this assumes one has infinity many timeslots in a slotframe, so tha= t > one can approximate rational numbers by real numbers and one can ignore > Li=3DLj occurrences.( > > > On 2/16/2015 8:14 PM, Malisa Vucinic wrote: > > Hi all, > > I prepared a couple of slides on latency aspects with TSCH that can > hopefully be useful for evaluating different proposals for the join proce= ss > once there are more details on message sizes involved. > > Regards, > Malisa > > > > > On 09 Feb 2015, at 20:50, Rene Struik wrote: > > Dear colleagues: > > Just a quick reminder that we have a 6TiSCH security conf call tomorrow, > Tue February 10, 2015, 4.30pm EST. > > I have not seen any email traffic the last two weeks, nor any more > feedback on the draft document I posted on Fri January 9th. > > I put as tentative item on the agenda "time latency aspects" of the join > protocol. I will send out a more definitive agenda tomorrow around noon > EST. Please send agenda request to me prior to that time. > > Suggested agenda: > 1) administrativia {agenda bashing/minutes} > 2) time latency aspects > 3) AOB > > > > > _______________________________________________ > 6tisch-security mailing list6tisch-security@ietf.orghttps://www.ietf.org/= mailman/listinfo/6tisch-security > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > > http://cp.mcafee.com/d/avndygQ73gOrhojojK_tyVKVJ5MsOCrhs7cLCQn1NEVhjpd79J= NVVVNyZPoziiJo0E-kfSfbCPVg_oYKrtZzmvovW_9zzhO-qehPfnKnjh7fsMyCqenNNEVVqWdAk= RrzAul3PWApmU6CQjq9K_8K6zBdCUVMQsFCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjXd= NBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04SPtMQsTdwLQzh0qmT9OFoCnFZCUOCmdbFEwd559aH= 7OtBW1EwYfmfS6PBm1EwGWq87qNlrfTPhiq80nWhEw2KP-5yNEw1_SDgQgltd409618bCTD3vah= 6 > > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --=20 *Giuseppe Piro, PhD* Post Doc Researcher DEI, Politecnico di Bari via Orabona 4 - 70125 (Bari), Italy. email: peppe@giuseppepiro.com phone: +39 080 5963301 web: g iuseppepiro.com --047d7b10ccc31be54f050f62538e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= Hi Malisa,
<= br>
I've= three little comments about the 5-th slide of your presentation=C2=A0
http://www.ietf.org/mail-archive/web/6tisch-security/current/pdfWPK_6ZrxPI= .pdf

  1. note that a timeslot of 10ms may not be enough= for addressing all the L2 security procedures. Well, it depends from the s= elected security level.. but in general they always require more computatio= nal capabilities
  2. in a mul= ti hop scenario, your estimation (i.e., 40 ms) should be valid if slots are= properly allocated in the slotframe (maybe consecutively each other). Henc= e the assumption of "random scheduling" should not be more valid<= /span>
  3. probably we need more tha= n 3-4 frames for transmitting a certificate=C2=A0
=E2=80=8BBasing from these= comments, please, let me know if my understanding was wrong or not.=C2=A0<= /div>

Then, w.r.t certifi= cates, could you please provide more details in order to justify the size f= itting in 3-4 frames ?=C2=A0

Best Regards and thanks a lot for your attention=C2=A0
Giuseppe

On Tue, Feb 17, 2015 at 11:04 PM, Jonathan Simon <j= simon@linear.com> wrote:
Rene - Thanks.=C2=A0

I= agree that RSA is absurd in this context, but as I mentioned in one of the= calls, some of the base standards use RSA signatures, e.g. RFC6550 (RPL) c= alls out=C2=A0RSA with SHA-256, so=C2= =A0
a) I=E2=80=99m not sure what people are thinking in terms of shared= key establishment (hopefully not RSA), and
b) we will need at some poi= nt to explicitly call out where we are using other crytpo suites. =C2=A0

Jonat= han

On Feb 17, 2015, at 1:43 PM, Rene Struik <rstruik.ext@gmail.com> wr= ote:

=20 =20 =20
Hi Jonathan:

Well, given the example on Slide 5 re DTLS with pre-shared keys, time latency is mainly driven by communication delays (due to TSCH scheduling) and computational delays are relatively marginal in comparison (the conclusion applies public-key based approaches as well). Please also see the eight month old (June 11, 2014) message with a similar conclusion: http://www.ietf.org/mail-archive/web/6tisch-security/cu= rrent/msg00153.html

BTW - there is no need to generate or test prime numbers, since it would be suicidal to consider RSA.

Best regards, Rene

On 2/17/2015 4:23 PM, Jonathan Simon wrote:
=20 It is also worth noting that it is implicit in the calculation that:

* the the devices in question always have available buffers such that there isn=E2=80=99t a lot of backoff
* that any security related processing can happen before any subsequent steps that rely on said processing occur.=C2=A0 This may not be true for ECC operations or generation and testing of large primes.

Jonathan

On Feb 17, 2015, at 12:30 PM, Rene Struik <rstruik.ext@gmail.com> wrote:

Hi Malisa:

In fact, I think my note on approximation of reals by rational numbers was too pessimistic: my two-line argument for the 1/(C+1) density formula should hold in general.

Two further notes:
a) It seems one can easily extend the argument to cases where one inserts some "don't care" timeslot = (Rx/Tx by any device) and include those in the C tally (if there are no clashes in access to that cell).
b) I think random scheduling is not really optimum, since there are wide variations in latency from the average. For more deterministic time latencies, one might want to look into schemes that have a much smaller variance.

Best regards, Rene

On 2/17/2015 3:17 PM, Malisa Vucinic wrote:
Hi Rene,

Thanks for confirming my calculation.

I agree that theoretically this assumes infinite number of timeslots in a slotframe but I believe it should be accurate enough for C << L.=C2=A0

Regards,
Malisa

On 17 Feb 2015, at 09:39, Rene Struik <rstruik.ext@gmail.com> wrote:

Hi Malisa:

I had a closer look at the slides you presented at the 6TiSCH security call this morning, Feb 17, 2015.

Slide 3 presents time latency numbers in case of a random TSCH schedule with C cells per slotframe, where the slotframe length is L time slots. I was trying to come up with an easy explanation for your time latency figure of ~ 1/(C+1)=C2=A0 the slotframe length between receiving a frame and sending a response in the next available dedicated "sending cell".

It turns out one can do this without any nontrivial math. See below.

Assumptions:
-w.l.o.g., receipt by A of frame from B ("= A <--B") is at time zero (since schedule repeats)
-sending schedule of A: t cells, dividing up the unite line [0,1] in intervals of length L1, L2, ..., L{t+1}.
- t>0 (o.w., A is mute).

Observe that any schedule of t cells corresponds 1-1 with a partitioning of the unit line [0,1]. Moreover, if (L1,L2, ..., L{t+1}) is a schedule, then so is any permutation hereof. As a result, the average size of the first segment over all schedules is (L1+ .... + L{t+1})/(t+1)=3D1/(t+1): simply add up the first segment of the schedules (L1,L2, ..., L{t+1}), (L2,L3, ..., L{t+1}, L1), ..., (L{t+1},L1, ..., Lt).
The result follows (take t:=3DC).

Note: this assumes one has infinity many timeslots in a slotframe, so that one can approximate rational numbers by real numbers and one can ignore Li=3DLj occurrences.(
=C2=A0

On 2/16/2015 8:14 PM, Malisa Vucinic wrote:
Hi all,

I prepared a couple of slides on latency aspects with TSCH that can hopefully be useful for evaluating different proposals for the join process once there are more details on message sizes involved.

Regards,
Malisa




On 09 Feb 2015, at 20:50, Rene Struik <rstruik.ext@gmail.com> wrote:

Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue February 10, 2015, 4.30pm EST.=C2= =A0

I have not seen any email traffic the last two weeks, nor any more feedback on the draft document I posted on Fri January 9th.

I put as tentative item on the agenda "time latency aspects" of the join protocol. I will send out a more definitive agenda tomorrow around noon EST. Please send agenda request to me prior to that time.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) time latency aspects
3) AOB



__________________________________________=
_____
6tisch-security mailing list
6tisch-securi=
ty@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch-secu=
rity



--=20
email: rstruik.e=
xt@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363=




--=20
email: rstruik.e=
xt@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363=
_______________________________________________
6tisch-security mailing list
6= tisch-security@ietf.org
http://cp.mcafee.com/d/avndygQ73gOrhojojK_tyV= KVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKrtZzmvovW_9zzhO-q= ehPfnKnjh7fsMyCqenNNEVVqWdAkRrzAul3PWApmU6CQjq9K_8K6zBdCUVMQsFCXCOsVHkiP2Di= -rL00s4RtxxYGjB1SKejBiNcLjXdNBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04SPtMQsTdwLQzh= 0qmT9OFoCnFZCUOCmdbFEwd559aH7OtBW1EwYfmfS6PBm1EwGWq87qNlrfTPhiq80nWhEw2KP-5= yNEw1_SDgQgltd409618bCTD3vah6



--=20
email: rstruik.e=
xt@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363=


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




--
Giuseppe Piro, PhD
Post Doc Rese= archer
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.<= br>email: peppe= @giuseppepiro.com
phone: +39 080 5963301
web: giuseppepiro.com
--047d7b10ccc31be54f050f62538e-- From nobody Wed Feb 18 16:09:14 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547851A0AC8 for <6tisch-security@ietfa.amsl.com>; Wed, 18 Feb 2015 16:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.809 X-Spam-Level: * X-Spam-Status: No, score=1.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, J_CHICKENPOX_22=0.6, SPF_NEUTRAL=0.779, 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 bdF8VW5tZ8xy for <6tisch-security@ietfa.amsl.com>; Wed, 18 Feb 2015 16:09:08 -0800 (PST) Received: from rominette.imag.fr (mx2.imag.fr [IPv6:2001:660:5301:59::17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A07D81A1B74 for <6tisch-security@ietf.org>; Wed, 18 Feb 2015 16:09:07 -0800 (PST) Received: from globule.imag.fr (globule.imag.fr [129.88.34.238]) by rominette.imag.fr (8.13.8/8.13.8) with ESMTP id t1J08x4q024871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2015 01:08:59 +0100 Received: from dhcp-33-61.eecs.berkeley.edu (dhcp-33-61.EECS.Berkeley.EDU [128.32.33.61]) (authenticated bits=0) by globule.imag.fr (8.13.8/8.13.8) with ESMTP id t1J08xxU004935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2015 01:09:01 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_099B44F5-7428-475C-AF8C-91C6D01EEEE4" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Malisa Vucinic In-Reply-To: Date: Wed, 18 Feb 2015 16:08:58 -0800 Message-Id: <7AD5AA5C-75B8-4A33-A061-5EAAB124A495@imag.fr> References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> <54D98E01.4090103@gmail.com> <8E377EDE-074F-472E-B397-86F29AEDEB19@imag.fr> <54E37CD5.7090405@gmail.com> <4EDC1B3D-8E75-4FA8-8B3E-E458B3A9CAA8@imag.fr> <54E3A4D2.8090907@gmail.com> <63410C6A-3545-4A24-B83C-F24E7D3A93A4@linear.com> <54E3B604.5010803@gmail.com> <127C0B65-7497-4802-B52F-2161C7C6DA2B@linear.com> To: Giuseppe Piro X-Mailer: Apple Mail (2.2070.6) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (rominette.imag.fr [129.88.30.17]); Thu, 19 Feb 2015 01:08:59 +0100 (CET) X-IMAG-MailScanner-Information: Please contact MI2S MIM for more information X-MailScanner-ID: t1J08x4q024871 X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-SpamCheck: X-IMAG-MailScanner-From: malisa.vucinic@imag.fr MailScanner-NULL-Check: 1424909341.26404@LyGJEDLjhoYCKaq+NdxjnQ Archived-At: Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (simplified explanation of formulae) Re: Latency aspects of TSCH X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 00:09:13 -0000 --Apple-Mail=_099B44F5-7428-475C-AF8C-91C6D01EEEE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Giuseppe, Thanks for your comments. See my answers inline. Best, Mali=C5=A1a > On 18 Feb 2015, at 12:03, Giuseppe Piro = wrote: >=20 > Hi Malisa, >=20 > I've three little comments about the 5-th slide of your presentation=20= > = http://www.ietf.org/mail-archive/web/6tisch-security/current/pdfWPK_6ZrxPI= .pdf = >=20 > note that a timeslot of 10ms may not be enough for addressing all the = L2 security procedures. Well, it depends from the selected security = level.. but in general they always require more computational = capabilities I agree that the lower end devices with a pure software implementation = of AES and CCM* could have difficulties fitting everything in 10ms = timeslot but since we have hardware acceleration available on a wide = range of platforms this should not be a problem.=20 > in a multi hop scenario, your estimation (i.e., 40 ms) should be valid = if slots are properly allocated in the slotframe (maybe consecutively = each other). Hence the assumption of "random scheduling" should not be = more valid This is 40 seconds over 5 hops, not milliseconds, however strange that = may sound. Consider two radio neighbors A and B performing the = handshake: A=E2=80=99s MAC layer receives the first DTLS packet to = transmit (Client Hello) at a random instant in the schedule. With the = random schedule and no queuing delay, it will take the infamous 1 + = L/(C+1) timeslots before this is received at B. It will be the same in = the other direction since B=E2=80=99s TX cell is also randomly scheduled = (we are effectively making the second assumption from Jonathan=E2=80=99s = email here). For 15 L2 frames carrying different DTLS datagrams in both = directions (C dedicated cells for each TX, both ends), this will be 15 = times the delay of a single frame. For multihop, since the randomly = generated schedule is common for all nodes in the mesh, the average = delay until a frame received at an intermediate hop will be forwarded to = the following one is the same. So effectively, we just need to add them = up and assuming the same number of dedicated cells between all pairs on = the path we get the multiplication by H. Does that make sense? =20 > probably we need more than 3-4 frames for transmitting a certificate=20= > =E2=80=8BBasing from these comments, please, let me know if my = understanding was wrong or not.=20 >=20 > Then, w.r.t certificates, could you please provide more details in = order to justify the size fitting in 3-4 frames ?=20 So 3-4 frames relates to an optimistic estimate of compressed ECC = certificates (see discussion = http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00222.html= = ). We may need more but, to me, transmitting 1.5K certificates in both = directions over multiple hops smells like a disaster which we ought to = avoid. =C3=8E >=20 > Best Regards and thanks a lot for your attention=20 > Giuseppe >=20 > On Tue, Feb 17, 2015 at 11:04 PM, Jonathan Simon > wrote: > Rene - Thanks.=20 >=20 > I agree that RSA is absurd in this context, but as I mentioned in one = of the calls, some of the base standards use RSA signatures, e.g. = RFC6550 (RPL) calls out RSA with SHA-256, so=20 > a) I=E2=80=99m not sure what people are thinking in terms of shared = key establishment (hopefully not RSA), and > b) we will need at some point to explicitly call out where we are = using other crytpo suites. =20 >=20 > Jonathan >=20 > On Feb 17, 2015, at 1:43 PM, Rene Struik > wrote: >=20 >> Hi Jonathan: >>=20 >> Well, given the example on Slide 5 re DTLS with pre-shared keys, time = latency is mainly driven by communication delays (due to TSCH = scheduling) and computational delays are relatively marginal in = comparison (the conclusion applies public-key based approaches as well). = Please also see the eight month old (June 11, 2014) message with a = similar conclusion: = http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00153.html= = >>=20 >> BTW - there is no need to generate or test prime numbers, since it = would be suicidal to consider RSA. >>=20 >> Best regards, Rene >>=20 >> On 2/17/2015 4:23 PM, Jonathan Simon wrote: >>> It is also worth noting that it is implicit in the calculation that: >>>=20 >>> * the the devices in question always have available buffers such = that there isn=E2=80=99t a lot of backoff >>> * that any security related processing can happen before any = subsequent steps that rely on said processing occur. This may not be = true for ECC operations or generation and testing of large primes. >>>=20 >>> Jonathan >>>=20 >>> On Feb 17, 2015, at 12:30 PM, Rene Struik > wrote: >>>=20 >>>> Hi Malisa: >>>>=20 >>>> In fact, I think my note on approximation of reals by rational = numbers was too pessimistic: my two-line argument for the 1/(C+1) = density formula should hold in general. >>>>=20 >>>> Two further notes: >>>> a) It seems one can easily extend the argument to cases where one = inserts some "don't care" timeslot (Rx/Tx by any device) and include = those in the C tally (if there are no clashes in access to that cell). >>>> b) I think random scheduling is not really optimum, since there are = wide variations in latency from the average. For more deterministic time = latencies, one might want to look into schemes that have a much smaller = variance. >>>>=20 >>>> Best regards, Rene >>>>=20 >>>> On 2/17/2015 3:17 PM, Malisa Vucinic wrote: >>>>> Hi Rene, >>>>>=20 >>>>> Thanks for confirming my calculation. >>>>>=20 >>>>> I agree that theoretically this assumes infinite number of = timeslots in a slotframe but I believe it should be accurate enough for = C << L.=20 >>>>>=20 >>>>> Regards, >>>>> Malisa >>>>>=20 >>>>>> On 17 Feb 2015, at 09:39, Rene Struik > wrote: >>>>>>=20 >>>>>> Hi Malisa: >>>>>>=20 >>>>>> I had a closer look at the slides you presented at the 6TiSCH = security call this morning, Feb 17, 2015. >>>>>>=20 >>>>>> Slide 3 presents time latency numbers in case of a random TSCH = schedule with C cells per slotframe, where the slotframe length is L = time slots. I was trying to come up with an easy explanation for your = time latency figure of ~ 1/(C+1) the slotframe length between receiving = a frame and sending a response in the next available dedicated "sending = cell".=20 >>>>>>=20 >>>>>> It turns out one can do this without any nontrivial math. See = below. >>>>>>=20 >>>>>> Assumptions: >>>>>> -w.l.o.g., receipt by A of frame from B ("A <--B") is at time = zero (since schedule repeats) >>>>>> -sending schedule of A: t cells, dividing up the unite line [0,1] = in intervals of length L1, L2, ..., L{t+1}. >>>>>> - t>0 (o.w., A is mute). >>>>>>=20 >>>>>> Observe that any schedule of t cells corresponds 1-1 with a = partitioning of the unit line [0,1]. Moreover, if (L1,L2, ..., L{t+1}) = is a schedule, then so is any permutation hereof. As a result, the = average size of the first segment over all schedules is (L1+ .... + = L{t+1})/(t+1)=3D1/(t+1): simply add up the first segment of the = schedules (L1,L2, ..., L{t+1}), (L2,L3, ..., L{t+1}, L1), ..., = (L{t+1},L1, ..., Lt). >>>>>> The result follows (take t:=3DC). >>>>>>=20 >>>>>> Note: this assumes one has infinity many timeslots in a = slotframe, so that one can approximate rational numbers by real numbers = and one can ignore Li=3DLj occurrences.( >>>>>> =20 >>>>>>=20 >>>>>> On 2/16/2015 8:14 PM, Malisa Vucinic wrote: >>>>>>> Hi all, >>>>>>>=20 >>>>>>> I prepared a couple of slides on latency aspects with TSCH that = can hopefully be useful for evaluating different proposals for the join = process once there are more details on message sizes involved. >>>>>>>=20 >>>>>>> Regards, >>>>>>> Malisa >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 09 Feb 2015, at 20:50, Rene Struik > wrote: >>>>>>>>=20 >>>>>>>> Dear colleagues: >>>>>>>>=20 >>>>>>>> Just a quick reminder that we have a 6TiSCH security conf call = tomorrow, Tue February 10, 2015, 4.30pm EST.=20 >>>>>>>>=20 >>>>>>>> I have not seen any email traffic the last two weeks, nor any = more feedback on the draft document I posted on Fri January 9th. >>>>>>>>=20 >>>>>>>> I put as tentative item on the agenda "time latency aspects" of = the join protocol. I will send out a more definitive agenda tomorrow = around noon EST. Please send agenda request to me prior to that time. >>>>>>>>=20 >>>>>>>> Suggested agenda: >>>>>>>> 1) administrativia {agenda bashing/minutes} >>>>>>>> 2) time latency aspects >>>>>>>> 3) AOB >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> 6tisch-security mailing list >>>>>>> 6tisch-security@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/6tisch-security = >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> email: rstruik.ext@gmail.com | = Skype: rstruik >>>>>> cell: +1 (647) 867-5658 | US: = +1 (415) 690-7363 >>>>=20 >>>>=20 >>>> --=20 >>>> email: rstruik.ext@gmail.com | = Skype: rstruik >>>> cell: +1 (647) 867-5658 | US: +1 = (415) 690-7363 = _________________________________________= ______ >>>> 6tisch-security mailing list >>>> 6tisch-security@ietf.org >>>> = http://cp.mcafee.com/d/avndygQ73gOrhojojK_tyVKVJ5MsOCrhs7cLCQn1NEVhjpd79JN= VVVNyZPoziiJo0E-kfSfbCPVg_oYKrtZzmvovW_9zzhO-qehPfnKnjh7fsMyCqenNNEVVqWdAk= RrzAul3PWApmU6CQjq9K_8K6zBdCUVMQsFCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjX= dNBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04SPtMQsTdwLQzh0qmT9OFoCnFZCUOCmdbFEwd559= aH7OtBW1EwYfmfS6PBm1EwGWq87qNlrfTPhiq80nWhEw2KP-5yNEw1_SDgQgltd409618bCTD3= vah6 = >>>=20 >>=20 >>=20 >> --=20 >> email: rstruik.ext@gmail.com | Skype: = rstruik >> cell: +1 (647) 867-5658 | US: +1 = (415) 690-7363 >=20 > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security = >=20 >=20 >=20 >=20 > --=20 > Giuseppe Piro, PhD > Post Doc Researcher > DEI, Politecnico di Bari > via Orabona 4 - 70125 (Bari), Italy. > email: peppe@giuseppepiro.com > phone: +39 080 5963301 > web: g iuseppepiro.com = --Apple-Mail=_099B44F5-7428-475C-AF8C-91C6D01EEEE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Giuseppe,

Thanks for your comments. See my answers inline.

Best,
Mali=C5=A1a

On = 18 Feb 2015, at 12:03, Giuseppe Piro <peppe@giuseppepiro.com> wrote:

Hi = Malisa,
I've three little comments about the 5-th = slide of your presentation 
http://www.ietf.org/mail-archive/web/6tisch-security/current/pd= fWPK_6ZrxPI.pdf

  1. note that a timeslot of 10ms may not be enough for addressing = all the L2 security procedures. Well, it depends from the selected = security level.. but in general they always require more computational = capabilities
I agree = that the lower end devices with a pure software implementation of AES = and CCM* could have difficulties fitting everything in 10ms timeslot but = since we have hardware acceleration available on a wide range of = platforms this should not be a problem. 

  1. in a multi hop scenario, your estimation (i.e., 40 ms) should = be valid if slots are properly allocated in the slotframe (maybe = consecutively each other). Hence the assumption of "random scheduling" = should not be more = valid
This is 40 = seconds over 5 hops, not milliseconds, however strange that may sound. = Consider two radio neighbors A and B performing the handshake: A=E2=80=99s= MAC layer receives the first DTLS packet to transmit (Client Hello) at = a random instant in the schedule. With the random schedule and no = queuing delay, it will take the infamous 1 + L/(C+1) timeslots before = this is received at B. It will be the same in the other direction since = B=E2=80=99s TX cell is also randomly scheduled (we are effectively = making the second assumption from Jonathan=E2=80=99s email here). For 15 = L2 frames carrying different DTLS datagrams in both directions (C = dedicated cells for each TX, both ends), this will be 15 times the delay = of a single frame. For multihop, since the randomly generated schedule = is common for all nodes in the mesh, the average delay until a frame = received at an intermediate hop will be forwarded to the following one = is the same. So effectively, we just need to add them up and assuming = the same number of dedicated cells between all pairs on the path we get = the multiplication by H. Does that make sense?  

  1. probably we need more than 3-4 frames for transmitting a = certificate 
=E2=80=8BBasing = from these comments, please, let me know if my understanding was wrong = or not. 

Then, w.r.t = certificates, could you please provide more details in order to justify = the size fitting in 3-4 frames = ? 

So 3-4 frames relates to an optimistic estimate of = compressed ECC certificates (see discussion  http://www.ietf.org/mail-archive/web/6tisch-security/current/ms= g00222.html). We may need more but, to me, transmitting 1.5K = certificates in both directions over multiple hops smells like a = disaster which we ought to avoid. =C3=8E


Best Regards and = thanks a lot for your attention 
Giuseppe

On Tue, Feb 17, 2015 at 11:04 PM, Jonathan Simon = <jsimon@linear.com> wrote:
Rene - Thanks. 

I agree that RSA is = absurd in this context, but as I mentioned in one of the calls, some of = the base standards use RSA signatures, e.g. RFC6550 (RPL) calls = out RSA with = SHA-256, so 
a) I=E2=80=99m not sure what = people are thinking in terms of shared key establishment (hopefully not = RSA), and
b) we will need at some point to explicitly = call out where we are using other crytpo suites.  

Jonathan

On Feb 17, 2015, at 1:43 = PM, Rene Struik <rstruik.ext@gmail.com> = wrote:

=20 =20 =20
Hi Jonathan:

Well, given the example on Slide 5 re DTLS with pre-shared keys, time latency is mainly driven by communication delays (due to TSCH scheduling) and computational delays are relatively marginal in comparison (the conclusion applies public-key based approaches as well). Please also see the eight month old (June 11, 2014) message with a similar conclusion: http://www.ietf.org/mail-archive/web/6tisch-security/current/ms= g00153.html

BTW - there is no need to generate or test prime numbers, since it would be suicidal to consider RSA.

Best regards, Rene

On 2/17/2015 4:23 PM, Jonathan Simon wrote:
=20 It is also worth noting that it is implicit in the calculation that:

* the the devices in question always have = available buffers such that there isn=E2=80=99t a lot of backoff
* that any security related processing can happen = before any subsequent steps that rely on said processing occur.  This = may not be true for ECC operations or generation and testing of large primes.

Jonathan

On Feb 17, 2015, at 12:30 PM, Rene Struik = <rstruik.ext@gmail.com> wrote:

Hi Malisa:

In fact, I think my note on approximation of reals by rational numbers was too pessimistic: my two-line argument for the 1/(C+1) density formula should hold in general.

Two further notes:
a) It seems one can easily extend the argument to cases where one inserts some "don't care" timeslot (Rx/Tx by any device) and include those in the C tally (if there are no clashes in access to that cell).
b) I think random scheduling is not really optimum, since there are wide variations in latency from the average. For more deterministic time latencies, one might want to look into schemes that have a much smaller variance.

Best regards, Rene

On 2/17/2015 3:17 PM, Malisa Vucinic wrote:
=
Hi Rene,

Thanks for confirming my = calculation.

I agree that theoretically this assumes infinite number of timeslots in a slotframe but I believe it should be accurate enough for C << L. 

Regards,
Malisa

On 17 Feb 2015, at 09:39, Rene Struik <rstruik.ext@gmail.com> wrote:

Hi Malisa:

I had a closer look at the slides you presented at the 6TiSCH security call this morning, Feb 17, 2015.

Slide 3 presents time latency numbers in case of a random TSCH schedule with C cells per slotframe, where the slotframe length is L time slots. I was trying to come up with an easy explanation for your time latency figure of ~ 1/(C+1)  the slotframe = length between receiving a frame and sending a response in the next available dedicated "sending cell".

It turns out one can do this without any nontrivial math. See below.

Assumptions:
-w.l.o.g., receipt by A of frame from B ("A <--B") is at time zero (since schedule repeats)
-sending schedule of A: t cells, dividing up the unite line [0,1] in intervals of length L1, L2, ..., L{t+1}.
- t>0 (o.w., A is mute).

Observe that any schedule of t cells corresponds 1-1 with a partitioning of the unit line [0,1]. Moreover, if (L1,L2, ..., L{t+1}) is a schedule, then so is any permutation hereof. As a result, the average size of the first segment over all schedules is (L1+ .... + L{t+1})/(t+1)=3D1/(t+1): = simply add up the first segment of the schedules (L1,L2, ..., L{t+1}), (L2,L3, ..., L{t+1}, L1), ..., (L{t+1},L1, ..., Lt).
= The result follows (take t:=3DC).

Note: this assumes one has infinity many timeslots in a slotframe, so that one can approximate rational numbers by real numbers and one can ignore Li=3DLj occurrences.(
 

On 2/16/2015 8:14 PM, Malisa Vucinic = wrote:
Hi all,

I prepared a couple of = slides on latency aspects with TSCH that can hopefully be useful for evaluating different proposals for the join process once there are more details on message sizes involved.

Regards,
Malisa




On 09 Feb 2015, at = 20:50, Rene Struik <rstruik.ext@gmail.com> wrote:

Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue February 10, 2015, 4.30pm EST. 

I have not seen any email traffic the last two weeks, nor any more feedback on the draft document I posted on Fri January 9th.

I put as tentative item on the agenda "time latency aspects" of the join protocol. I will send out a more definitive agenda tomorrow around noon EST. Please send agenda request to me prior to that time.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) time latency aspects
3) AOB



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



--=20
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363



--=20
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
= 6tisch-security mailing list
6tisch-security@ietf.org
http://cp.mcafee.com/d/avndygQ73gOrhojojK_tyVKVJ5MsOCrhs7cLCQn1= NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKrtZzmvovW_9zzhO-qehPfnKnjh7fsMyCqe= nNNEVVqWdAkRrzAul3PWApmU6CQjq9K_8K6zBdCUVMQsFCXCOsVHkiP2Di-rL00s4RtxxYGjB1= SKejBiNcLjXdNBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04SPtMQsTdwLQzh0qmT9OFoCnFZCUO= CmdbFEwd559aH7OtBW1EwYfmfS6PBm1EwGWq87qNlrfTPhiq80nWhEw2KP-5yNEw1_SDgQgltd= 409618bCTD3vah6



--=20
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


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




--
Giuseppe Piro, PhD
Post Doc = Researcher
DEI, Politecnico di Bari
via = Orabona 4 - 70125 (Bari), Italy.
email: peppe@giuseppepiro.com
phone: +39 080 5963301
web: giuseppepiro.com

= --Apple-Mail=_099B44F5-7428-475C-AF8C-91C6D01EEEE4-- From nobody Wed Feb 18 20:20:07 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6641A86EE for <6tisch-security@ietfa.amsl.com>; Wed, 18 Feb 2015 20:20:06 -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 PNancQ7-XPJv for <6tisch-security@ietfa.amsl.com>; Wed, 18 Feb 2015 20:20:00 -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 37B4D1A8764 for <6tisch-security@ietf.org>; Wed, 18 Feb 2015 20:19:58 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 32188200A3 for <6tisch-security@ietf.org>; Wed, 18 Feb 2015 23:27:50 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 25CC163A21; Wed, 18 Feb 2015 23:19:57 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0C4C6637F5 for <6tisch-security@ietf.org>; Wed, 18 Feb 2015 23:19:57 -0500 (EST) From: Michael Richardson To: 6tisch-security@ietf.org X-Attribution: mcr 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: Subject: [6tisch-security] WGLC comments on 6tisch-security X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 04:20:06 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable My appologies for the lateness of this review. One good point is that it's been 10 weeks since I read the document From=20beginning to end, and some things stick out that did not bother me before. My tl;dr> conclusion is that the document is not ready to proceed as is. If it is going to proceed in volumes (I suggest "editions" is the correct term), then I think that most things which are speculation should either be removed to a later edition, or something specific should be said, with the understanding that it might change later. Presciption rather than speculation should be the goal. 1) I find it odd that there is so much emphasis of the backbone router function... IN THE ABSTRACT. I suggest that the last sentence: Backbone Routers perform proxy Neighbor Discovery operations over the backbone on behalf of the wireless devices, so they can share a same subnet and appear to be connect= ed to the same backbone as classical devices. be removed from the abstract. Probably by the end of this review that I'll suggest a different thing that could be included. 2) end of section 1, what does it mean: "in the round of this document."? 3) I don't think that [I-D.ietf-roll-rpl-industrial-applicability] will ever get published. If there is terminology there that we still need, I think it should be extracted into the 6tisch-terminology document. While it is an informative reference, the fewer references to IDs the better in my opinion. 4) section 4, seems to ignore the possibility to simply run RPL across the subnet backbone. I understand why the ND mechanism are nice, because th= ey permit the backbone to just be ethernet, but the case where the backbone is really dedicated (and given VLANs, it's hard to know why you'd do anything else), one can just run RPL across it. I think that this ultimately matters to any of the later architecture, but I wouldn't want to later argue with someone who might claim that the newer ND mechanisms are REQUIRED. 5) the security words include: "will be studied in the next round of this d= ocument." and I'm not sure what a reader should make of this. Perhaps it should simply summarize section 13 in one sentence and say that PANA is a possibility, but that the choice of protocol is out of scope for this document. (well, 5.0 then explains about volumes. So perhaps the explanation about volumes should go much earlier, most probably into the abstract as well. Also, will the volumes build on the previous work, or will they replace it? if they will replace it, then I think correct word is "edit= ion") 6) I don't think that the Note: about DETNET really still belongs in a document that might be read in 5-10 years. Maybe a reference to the charter for DETNET would make more sense. 7) I don't understand why PANA lives above ACE in figure 3. I think that ACE lives above CoAP/DICE (DTLS is missing, but perhaps understood by DICE). I think that while technically PANA lives on top of UDP, there is of course a layer of EAP, and TLS above it, and perhaps a layer of ACE as well. So I'm not saying that this picture needs to be changed, just to observe this. 8) I think remove: "COMI and the dependent specifications are still work in progress, but getting stable enough at the time of this writing." 9) I am happy with the paragraph on join security in section 5. 10) I think that this is confused (bottom of page 9, section 6): > This architecture expects that a 6LoWPAN node can connect as a leaf > to a RPL network, where the leaf support is the minimal functionality > to connect as a host to a RPL network without the need to participate > to the full routing protocol. The support of leaf can be implemented > as a minor increment to 6LoWPAN ND, with the additional capability to > carry a sequence number that is used to track the movements of the > device, and optionally some information about the RPL topology that > this device will join. I think that either a minimal RPL permits leaf attachment *OR* the EARO 6lowPAN ND. I don't think that both are needed? I'm also think that some may confuse this with the join process requirements, which maybe this started out describing, but I don't think that does that. It might describe how nodes which have already joined (been imprinted upon the newtork) can form a network. Figure 4 seems to do it all without RPL, even though RPL is mentioned, and I don't understand that. 11) Reading section 6.1/6.2, I wonder if this just too much detail for an architecture. I also don't see how VLANID is involved (we are talking 802.1q here, right?). I am not saying that the TID and EARO aren't good things; I'm just finding that they just JUMP out here, and I'm not sure a read has any idea why they are here yet. I think that 6.3 should be far more specific: proxy-ND? LISP? or MIPv6? which is going to be used... I think that reviewers will push back here a lot. 12) I think that 6.4 needs be prescriptive, not speculative/suggestive. 6.5 needs to say, "the 6LBR and RPL root functionality are to be co-located in order that the address of the 6LBR be indicated by RPL DIO messages" 13) I think that 6.6 is saying that SEND can not be applied. I think it should be clearer in saying something like: "The threats against IPv6 ND as described in RFC3971 apply as well, but the solution can not work as the route over network does not permit direct peer to peer communication. As can be seen in Figure 4..." 14) I think that the relevant parts of [I-D.ietf-roll-rpl-industrial-applicability] need to imported into this document, since this sure looks like a normative reference to me. 15) section 8 seems to be really the key aspects of the architecture. I think that rather than say, "if the scheduling entity explicitely..." =3D> "hard". I think that it should instead say that there are hard cells and soft cells, and say that 6top can not move hard cells. (but, how would the PCE set them up, if 6top can't move them?) "6top contains a monitoring process which monitors the performance of cells, and can move a cell in the TSCH schedule when it performs bad." this seems pretty important an architectural thing, and I think it at least deserves it's own section number. 16) 8.2, insert something to the effect: Most RPL Objective Functions require metrics about reachability, such as the ETX. 6top creates and maintains an abstract neighbor table, and this may be leveraged. ... This information ... " 6top also enables the RPL OF to influence the MAC behaviour, for instance by configuring the periodicity of IEEE802.15.4e Extended Beacons (EB's). By augmenting the EB periodicity, it is possible to change the network dynamics so as to improve the support of devices that may change their point of attachment in the 6TiSCH network. " But, we aren't using the Enhanced Beacons (they are enhanced, not extended, aren't they? or did I get that backwards again?) for production network use... I would write: Consideration was given towards finding a way to embed the Route Advertisements and the RPL DIO messages (both of which are multicast) into the IEEE802.15.4e Enhanced Beacons. It was determined that this produced undue timer coupling among layers, that the resulting packet size was potentially too large, and required it is not yet clear that there is any need for Enhanced Beacons in a production network. [and then go on to explain how to configure the LinkType, however, I think that this is too much detail for the architecture, and it needs to say something like: The 6TISCH adaptation document will explain the details of confuring a broadcast channel that can accomodate EB, RPL DIOs and Router Advertisements ] but, maybe I mis-understand the entire section. 17) I think that 8.3 should actually say how the TSGI should be created, and also how the various layers can be synchronized such that the RPL management traffic can provide for the needed frame-based synchronization. I expect that this simply means that 6top needs to be able to trigger(override) the trickle timer if no other traffic has occured in "too long" a time. "After consultation with IEEE authors, it was asserted that 6TiSCH can make a full use of the octet to carry an integer value up to 0xFF." -> does this need some kind of clear liason statement? I think that the concepts introduced in section 6.4 and 6.5 should perhaps be more clearly. While not trying to duplicate the terminology document, I found the way that the CDU concept is introduced was awkward. Perhaps this isn't very important. Maybe moving figure 5 earlier? 18) I think that the 4 scheduling paradigms should be mentioned in the introduction as well! To first order, I think that is perhaps the most important thing in the document. " If the size of a bundle is configured to fit an average amount of bandwidth, peak emissions will be destroyed." (I don't think the word you want is "destroyed". I think that it means that packets will be dropped, but I don't think that describing the dropped packets as destroyed is the correct IETF idiom here, even though it might be grammatically correct) 19) 6TiSCH supports three different forwarding model, G-MPLS Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 Forwarding (6F). also should be mentioned in the introduction... 20) last comment on section 13. (the bullet (*) has become an ASCII "A", the high bit was likely removed) Device Authentication: The JN and the JA mutually authenticate each other and establish a shared key, so as to ensure on-going authenticated communications. This may involve a server as a third party. I again say that this is incorrect, the JA will never be able to authenticate *itself* to the JN. It may be able to present some *authorization* from the *network owner*, that the JA is authorized to act on behalf of the network owner. Unless you consider un-authenticated DH exchange "authentication", or you decide that it's okay for the JA to just not accept any public (some kind of leap of faith), the JA will not have an identity that a JN will accept. I have also repeatedly complained that figure 10 is inaccurate, because it fails to depict that authorization begins before authentication finishes. Perhaps the second two unidirectional arrows are part of the authentication phase, I don't know. I suggest that the sentence: "The join protocol consists of three phases:" be replaced with: "The join protocol has three major activities:" ("phases" implies some ordering such that one phase might finish before the next begins, while activities implies no such ordering) I suggest that figure 10 be omitted. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVOVkaYCLcPvd0N1lAQJ8Zwf/buLgfw8PDerwhMuNmXZjc8mFR+hCxhVZ bjHR9DvzrAyTCAl4LUEczj/gDHV29H/F9FFb23oMGdiRPe/ee2HEdpz98sowoITw jDpkz2U6k1jia8yDzKuOkf8wuo/EMFxWWQB91jK7m3f9lQ0JG63US9B/BCaz/bUR 5SlMui4E+vAgiiP20swHusTa01w5901jdOafGxE1JPlXRQ+QyNtB29IsJFC+Rxow ofqofxLznyiLEHxiOfLmENUMSPVosBGZz89ThZDbHkW3+IjVUGhQC+xaebQLc7iH V0dh3rd0KCa+d5gXECUdTNbLMmzgnxV7ExkeN4P3BlKfSNwCPKb8cw== =NO1H -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 19 01:10:31 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD571A895E for <6tisch-security@ietfa.amsl.com>; Thu, 19 Feb 2015 01:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 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, 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 lUf5sY5pTs64 for <6tisch-security@ietfa.amsl.com>; Thu, 19 Feb 2015 01:10:26 -0800 (PST) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (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 D97DC1A894C for <6tisch-security@ietf.org>; Thu, 19 Feb 2015 01:10:25 -0800 (PST) Received: by paceu11 with SMTP id eu11so8012464pac.10 for <6tisch-security@ietf.org>; Thu, 19 Feb 2015 01:10:25 -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=EH03A+mX+fUsIz4VSVJMGJN/ocW6aWnCpiWOiiQ/Xtk=; b=DlDkJdrIqLNZIHrqQ+FyFXvT9ldVzdtjSJgJkQewI+aFurq8X8KUc5xHdzCo8h24nH Qde2+Psl30v5SlzRZEro3iH8Cy4265fCfKD4DEsu/tYlhQtHrPQXdRUN5/dmHZQH74oW 6/YLSXwvIRkDAb4Dy1rlGFHPtHThKrKfV1cugr9FktQgRPET6daXDGCUMt+ihvyyaGxe AffJstblYqK82hOR+RuZ0E/F/41PTPJ2IXhTkz8aYvbS83tCaR4GaY7ofxVuUHfhAFlP NJN3BX41B+oR3Sck7GjT1n3EELAvqMyIpAZ94BBNJn407k0VvANFtrUDYOqNHOHeSvo/ +U1g== X-Received: by 10.67.21.144 with SMTP id hk16mr6132910pad.140.1424337025499; Thu, 19 Feb 2015 01:10:25 -0800 (PST) MIME-Version: 1.0 Sender: gpiro.poliba@gmail.com Received: by 10.70.79.104 with HTTP; Thu, 19 Feb 2015 01:09:55 -0800 (PST) In-Reply-To: <7AD5AA5C-75B8-4A33-A061-5EAAB124A495@imag.fr> References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> <54D98E01.4090103@gmail.com> <8E377EDE-074F-472E-B397-86F29AEDEB19@imag.fr> <54E37CD5.7090405@gmail.com> <4EDC1B3D-8E75-4FA8-8B3E-E458B3A9CAA8@imag.fr> <54E3A4D2.8090907@gmail.com> <63410C6A-3545-4A24-B83C-F24E7D3A93A4@linear.com> <54E3B604.5010803@gmail.com> <127C0B65-7497-4802-B52F-2161C7C6DA2B@linear.com> <7AD5AA5C-75B8-4A33-A061-5EAAB124A495@imag.fr> From: Giuseppe Piro Date: Thu, 19 Feb 2015 10:09:55 +0100 X-Google-Sender-Auth: apbdYrkTlN3odf1z1NWVriulb3M Message-ID: To: Malisa Vucinic Content-Type: multipart/alternative; boundary=001a113321c472084b050f6d4e42 Archived-At: Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (simplified explanation of formulae) Re: Latency aspects of TSCH X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 09:10:29 -0000 --001a113321c472084b050f6d4e42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Malisa, thanks for the clarifications. On Thu, Feb 19, 2015 at 1:08 AM, Malisa Vucinic wrote: > Hi Giuseppe, > > Thanks for your comments. See my answers inline. > > Best, > Mali=C5=A1a > > On 18 Feb 2015, at 12:03, Giuseppe Piro wrote: > > Hi Malisa, > > I've three little comments about the 5-th slide of your presentation > > http://www.ietf.org/mail-archive/web/6tisch-security/current/pdfWPK_6ZrxP= I.pdf > > > 1. note that a timeslot of 10ms may not be enough for addressing all > the L2 security procedures. Well, it depends from the selected securit= y > level.. but in general they always require more computational capabili= ties > > I agree that the lower end devices with a pure software implementation of > AES and CCM* could have difficulties fitting everything in 10ms timeslot > but since we have hardware acceleration available on a wide range of > platforms this should not be a problem. > > Ok. I know that hardware-based solutions could reduce the amount of time required complete l2 security tasks. We have to verify that "this should not be a problem" :-) . Anyway, I'm in line with your idea. > > 1. in a multi hop scenario, your estimation (i.e., 40 ms) should be > valid if slots are properly allocated in the slotframe (maybe consecut= ively > each other). Hence the assumption of "random scheduling" should not be= more > valid > > This is 40 seconds over 5 hops, not milliseconds, however strange that ma= y > sound. Consider two radio neighbors A and B performing the handshake: A= =E2=80=99s > MAC layer receives the first DTLS packet to transmit (Client Hello) at a > random instant in the schedule. With the random schedule and no queuing > delay, it will take the infamous 1 + L/(C+1) timeslots before this is > received at B. It will be the same in the other direction since B=E2=80= =99s TX cell > is also randomly scheduled (we are effectively making the second assumpti= on > from Jonathan=E2=80=99s email here). For 15 L2 frames carrying different = DTLS > datagrams in both directions (C dedicated cells for each TX, both ends), > this will be 15 times the delay of a single frame. > For multihop, since the randomly generated schedule is common for all nodes > in the mesh, the average delay until a frame received at an intermediate > hop will be forwarded to the following one is the same. So effectively, w= e > just need to add them up and assuming the same number of dedicated cells > between all pairs on the path we get the multiplication by H. Does that > make sense? > > =E2=80=8B Sure, it was been my misunderstanding, thanks. > > 1. probably we need more than 3-4 frames for transmitting a certificat= e > > > =E2=80=8BBasing from these comments, please, let me know if my understand= ing was > wrong or not. > > Then, w.r.t certificates, could you please provide more details in order > to justify the size fitting in 3-4 frames ? > > > So 3-4 frames relates to an optimistic estimate of compressed ECC > certificates (see discussion > http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00222.htm= l). > We may need more but, to me, transmitting 1.5K certificates in both > directions over multiple hops smells like a disaster which we ought to > avoid. =C3=8E > > =E2=80=8B Thanks for the pointer. I agree that compressed certs =E2=80=8Bare more suitable in this context. =E2=80=8B All the best, Giuseppe --=20 *Giuseppe Piro, PhD* Post Doc Researcher DEI, Politecnico di Bari via Orabona 4 - 70125 (Bari), Italy. email: giuseppe.piro@poliba.it phone: +39 080 5963301 web: telematics.poliba.it/piro --001a113321c472084b050f6d4e42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= Malisa, thanks for the clarifications.=C2=A0


On Thu, Feb 19, 2015 at 1:08 AM, Malisa Vucinic <Ma= lisa.Vucinic@imag.fr> wrote:
Hi Giuseppe,

Thanks for your c= omments. See my answers inline.

Best,
Ma= li=C5=A1a

On 18 Feb= 2015, at 12:03, Giuseppe Piro <peppe@giuseppepiro.com> wrote:

Hi Malisa,

I'v= e three little comments about the 5-th slide of your presentation=C2=A0

  1. note that a timeslot of 10ms may not be en= ough for addressing all the L2 security procedures. Well, it depends from t= he selected security level.. but in general they always require more comput= ational capabilities
=
I agree that the lower end devices with a pure software implementation= of AES and CCM* could have difficulties fitting everything in 10ms timeslo= t but since we have hardware acceleration available on a wide range of plat= forms this should not be a problem.=C2=A0


Ok. I know that hardware-based solutions could reduce the= amount of time required complete l2 security tasks. We have to verify that= "this should not be a problem" :-) . Anyway, I'm in line wit= h your idea.

=C2=A0
=
  1. in a multi hop scena= rio, your estimation (i.e., 40 ms) should be valid if slots are properly al= located in the slotframe (maybe consecutively each other). Hence the assump= tion of "random scheduling" should not be more valid
    2. <= /ol>
This is 40 seconds over 5 ho= ps, not milliseconds, however strange that may sound. Consider two radio ne= ighbors A and B performing the handshake: A=E2=80=99s MAC layer receives th= e first DTLS packet to transmit (Client Hello) at a random instant in the s= chedule. With the random schedule and no queuing delay, it will take the in= famous 1 + L/(C+1) timeslots before this is received at B. It will be the s= ame in the other direction since B=E2=80=99s TX cell is also randomly sched= uled (we are effectively making the second assumption from Jonathan=E2=80= =99s email here). For 15 L2 frames carrying different DTLS datagrams in bot= h directions (C dedicated cells for each TX, both ends), this will be 15 ti= mes the delay of a single frame.
For multihop= , since the randomly generated schedule is common for all nodes in the mesh= , the average delay until a frame received at an intermediate hop will be f= orwarded to the following one is the same. So effectively, we just need to = add them up and assuming the same number of dedicated cells between all pai= rs on the path we get the multiplication by H. Does that make sense? =C2=A0=


<= div class=3D"gmail_default" style=3D"color:rgb(0,0,153)">=E2=80=8B
Sure, it was been my= misunderstanding, thanks.
=C2=A0
=
  1. probably we need more than 3-4 frames for transmitting a certificate= =C2=A0
=E2=80=8BBasing fr= om these comments, please, let me know if my understanding was wrong or not= .=C2=A0

Then, w.r.t certificates, could you please provide more det= ails in order to justify the size fitting in 3-4 frames ?=C2=A0
=

So 3-4 frames relates t= o an optimistic estimate of compressed ECC certificates (see discussion =C2= =A0http://www.ietf.org/mail-archive/web/6tisc= h-security/current/msg00222.html). We may need more but, to me, transmi= tting 1.5K certificates in both directions over multiple hops smells like a= disaster which we ought to avoid. =C3=8E

=E2=80=8B

= Thanks for the pointer. I agree that compressed certs
=E2=80=8Bare more suita= ble in this context.

=E2=80=8B
=C2=A0

All the best,
Giuseppe

--
Giuseppe Piro,= PhD
Post Doc Researcher
DEI, Politecnico di Bari
via Orabona = 4 - 70125 (Bari), Italy.
email: giuseppe.piro@poliba.it
--001a113321c472084b050f6d4e42-- From nobody Thu Feb 19 01:11:47 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620361A894C for <6tisch-security@ietfa.amsl.com>; Thu, 19 Feb 2015 01:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.903 X-Spam-Level: ** X-Spam-Status: No, score=2.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MANGLED_BEST=2.3, 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 nC1jsvBVms-A for <6tisch-security@ietfa.amsl.com>; Thu, 19 Feb 2015 01:11:42 -0800 (PST) Received: from smtpcmd01240.aruba.it (smtpcmd01240.aruba.it [62.149.158.240]) by ietfa.amsl.com (Postfix) with ESMTP id 94F371A895E for <6tisch-security@ietf.org>; Thu, 19 Feb 2015 01:11:41 -0800 (PST) Received: from mail-pd0-f179.google.com ([209.85.192.179]) by smtpcmd01.ad.aruba.it with bizsmtp id u9Bd1p00B3shhp5019Beir; Thu, 19 Feb 2015 10:11:39 +0100 Received: by pdbfp1 with SMTP id fp1so7544004pdb.5 for <6tisch-security@ietf.org>; Thu, 19 Feb 2015 01:11:36 -0800 (PST) X-Received: by 10.66.138.46 with SMTP id qn14mr6230479pab.86.1424337096937; Thu, 19 Feb 2015 01:11:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.70.79.104 with HTTP; Thu, 19 Feb 2015 01:11:06 -0800 (PST) In-Reply-To: References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> <54D98E01.4090103@gmail.com> <8E377EDE-074F-472E-B397-86F29AEDEB19@imag.fr> <54E37CD5.7090405@gmail.com> <4EDC1B3D-8E75-4FA8-8B3E-E458B3A9CAA8@imag.fr> <54E3A4D2.8090907@gmail.com> <63410C6A-3545-4A24-B83C-F24E7D3A93A4@linear.com> <54E3B604.5010803@gmail.com> <127C0B65-7497-4802-B52F-2161C7C6DA2B@linear.com> <7AD5AA5C-75B8-4A33-A061-5EAAB124A495@imag.fr> From: Giuseppe Piro Date: Thu, 19 Feb 2015 10:11:06 +0100 Message-ID: To: Malisa Vucinic Content-Type: multipart/alternative; boundary=047d7b15a311b417e3050f6d525c Archived-At: Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (simplified explanation of formulae) Re: Latency aspects of TSCH X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 09:11:45 -0000 --047d7b15a311b417e3050f6d525c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Malisa, thanks for the clarifications. > On Thu, Feb 19, 2015 at 1:08 AM, Malisa Vucinic > wrote: > >> Hi Giuseppe, >> >> Thanks for your comments. See my answers inline. >> >> Best, >> Mali=C5=A1a >> >> On 18 Feb 2015, at 12:03, Giuseppe Piro wrote: >> >> Hi Malisa, >> >> I've three little comments about the 5-th slide of your presentation >> >> http://www.ietf.org/mail-archive/web/6tisch-security/current/pdfWPK_6Zrx= PI.pdf >> >> >> 1. note that a timeslot of 10ms may not be enough for addressing all >> the L2 security procedures. Well, it depends from the selected securi= ty >> level.. but in general they always require more computational capabil= ities >> >> I agree that the lower end devices with a pure software implementation o= f >> AES and CCM* could have difficulties fitting everything in 10ms timeslot >> but since we have hardware acceleration available on a wide range of >> platforms this should not be a problem. >> >> > Ok. I know that hardware-based solutions could reduce the amount of time required complete l2 security tasks. We have to verify that "this should not be a problem" :-) . Anyway, I'm in line with your idea. > > >> >> 1. in a multi hop scenario, your estimation (i.e., 40 ms) should be >> valid if slots are properly allocated in the slotframe (maybe consecu= tively >> each other). Hence the assumption of "random scheduling" should not b= e more >> valid >> >> This is 40 seconds over 5 hops, not milliseconds, however strange that >> may sound. Consider two radio neighbors A and B performing the handshake= : >> A=E2=80=99s MAC layer receives the first DTLS packet to transmit (Client= Hello) at >> a random instant in the schedule. With the random schedule and no queuin= g >> delay, it will take the infamous 1 + L/(C+1) timeslots before this is >> received at B. It will be the same in the other direction since B=E2=80= =99s TX cell >> is also randomly scheduled (we are effectively making the second assumpt= ion >> from Jonathan=E2=80=99s email here). For 15 L2 frames carrying different= DTLS >> datagrams in both directions (C dedicated cells for each TX, both ends), >> this will be 15 times the delay of a single frame. >> > For multihop, since the randomly generated schedule is common for all >> nodes in the mesh, the average delay until a frame received at an >> intermediate hop will be forwarded to the following one is the same. So >> effectively, we just need to add them up and assuming the same number of >> dedicated cells between all pairs on the path we get the multiplication = by >> H. Does that make sense? >> >> > =E2=80=8B > Sure, it was been my misunderstanding, thanks. > >> >> 1. probably we need more than 3-4 frames for transmitting a >> certificate >> >> =E2=80=8BBasing from these comments, please, let me know if my understan= ding was >> wrong or not. >> >> Then, w.r.t certificates, could you please provide more details in order >> to justify the size fitting in 3-4 frames ? >> >> >> So 3-4 frames relates to an optimistic estimate of compressed ECC >> certificates (see discussion >> http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00222.ht= ml). >> We may need more but, to me, transmitting 1.5K certificates in both >> directions over multiple hops smells like a disaster which we ought to >> avoid. =C3=8E >> >> =E2=80=8B > =E2=80=8B > =E2=80=8B Thanks for the pointer. I agree that compressed certs =E2=80=8Bare more suitable in this context. All the bes =E2=80=8Bt =E2=80=8B Giuseppe --=20 *Giuseppe Piro, PhD* Post Doc Researcher DEI, Politecnico di Bari via Orabona 4 - 70125 (Bari), Italy. email: peppe@giuseppepiro.com phone: +39 080 5963301 web: g iuseppepiro.com --047d7b15a311b417e3050f6d525c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0Malisa, thanks for the clarificat= ions.=C2=A0

=

On Thu, Feb 19, 2015 at 1:08 AM, Malisa Vucinic <M= alisa.Vucinic@imag.fr> wrote:
Hi Giuseppe,

Thanks for your c= omments. See my answers inline.

Best,
Ma= li=C5=A1a

On 18 Feb= 2015, at 12:03, Giuseppe Piro <peppe@giuseppepiro.com> wrote:

Hi Malisa,

I'v= e three little comments about the 5-th slide of your presentation=C2=A0

  1. note that a timeslot of 10ms may not be en= ough for addressing all the L2 security procedures. Well, it depends from t= he selected security level.. but in general they always require more comput= ational capabilities
=
I agree that the lower end devices with a pure software implementation= of AES and CCM* could have difficulties fitting everything in 10ms timeslo= t but since we have hardware acceleration available on a wide range of plat= forms this should not be a problem.=C2=A0


=C2=A0
Ok. I know that hardware-based solutions could reduce t= he amount of time required complete l2 security tasks. We have to verify th= at "this should not be a problem" :-) . Anyway, I'm in line w= ith your idea.


=C2=A0
  1. in a mult= i hop scenario, your estimation (i.e., 40 ms) should be valid if slots are = properly allocated in the slotframe (maybe consecutively each other). Hence= the assumption of "random scheduling" should not be more valid
This is 40 second= s over 5 hops, not milliseconds, however strange that may sound. Consider t= wo radio neighbors A and B performing the handshake: A=E2=80=99s MAC layer = receives the first DTLS packet to transmit (Client Hello) at a random insta= nt in the schedule. With the random schedule and no queuing delay, it will = take the infamous 1 + L/(C+1) timeslots before this is received at B. It wi= ll be the same in the other direction since B=E2=80=99s TX cell is also ran= domly scheduled (we are effectively making the second assumption from Jonat= han=E2=80=99s email here). For 15 L2 frames carrying different DTLS datagra= ms in both directions (C dedicated cells for each TX, both ends), this will= be 15 times the delay of a single frame.
For= multihop, since the randomly generated schedule is common for all nodes in= the mesh, the average delay until a frame received at an intermediate hop = will be forwarded to the following one is the same. So effectively, we just= need to add them up and assuming the same number of dedicated cells betwee= n all pairs on the path we get the multiplication by H. Does that make sens= e? =C2=A0


=E2=80=8B=C2=A0
=
=C2=A0
Sure, it was been = my misunderstanding, thanks.

=C2=A0
  1. probably we need more than 3-4 frames for transmitt= ing a certificate=C2=A0
= =E2=80=8BBasing from these comments, please, let me know if my understandin= g was wrong or not.=C2=A0

=
Then, w.r.t certificates, could you pleas= e provide more details in order to justify the size fitting in 3-4 frames ?= =C2=A0

So 3-= 4 frames relates to an optimistic estimate of compressed ECC certificates (= see discussion =C2=A0http://www.ietf.org/mail= -archive/web/6tisch-security/current/msg00222.html). We may need more b= ut, to me, transmitting 1.5K certificates in both directions over multiple = hops smells like a disaster which we ought to avoid. =C3=8E
=
=E2=80=8B
=E2=80=8B

=C2=A0
=E2=80=8B
Thanks for the poin= ter. I agree that compressed certs
=E2=80=8Bare more suitable in this context.


= All the bes
=E2=80=8Bt

=E2=80=8BGiuseppe

=

--
Giuseppe Piro, PhD
Post Doc Researcher
DEI, Politecnico di B= ari
via Orabona 4 - 70125 (Bari), Italy.
email: peppe@giuseppepiro.comphone= : +39 080 5963301
web: gius= eppepiro.com
--047d7b15a311b417e3050f6d525c-- From nobody Fri Feb 20 06:23:46 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF9E1A8A1A; Fri, 20 Feb 2015 04:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZQtkP3iS4Wv; Fri, 20 Feb 2015 04:12:19 -0800 (PST) Received: from mailscan1.extendcp.co.uk (mailscan34.extendcp.co.uk [79.170.42.6]) (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 7E69A1A6F3D; Fri, 20 Feb 2015 03:59:36 -0800 (PST) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.extendcp.co.uk) by mailscan-g75.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1YOmF4-0002ma-N3; Fri, 20 Feb 2015 11:59:34 +0000 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1YOmF2-0008EX-Ag; Fri, 20 Feb 2015 11:59:34 +0000 Received: from host86-171-66-135.range86-171.btcentralplus.com ([86.171.66.135] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1YOmEx-0005Ur-B4; Fri, 20 Feb 2015 11:59:28 +0000 Message-ID: <54E7219B.6040006@gridmerge.com> Date: Fri, 20 Feb 2015 11:59:23 +0000 From: Robert Cragie Organization: Gridmerge Ltd. 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)" , Michael Richardson References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050800090303060805030500" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: X-Mailman-Approved-At: Fri, 20 Feb 2015 06:23:45 -0800 Cc: "anima@ietf.org" , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [6tisch-security] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 12:12:24 -0000 This is a cryptographically signed message in MIME format. --------------ms050800090303060805030500 Content-Type: multipart/alternative; boundary="------------050601010308030707080601" This is a multi-part message in MIME format. --------------050601010308030707080601 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Danping, I have some general comments on the draft and some additional comments=20 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=20 authentication perspective b) There isn't much distinction between joining an existing network and=20 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.=20 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. * 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. 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. > > > I have added a number of CCs, I think that this fits into ANIMA best= =2E > > > > > 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 leve= l > > > 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 qu= ite 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. > > 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=20 extent, it is because up to now, there has been no "the one way to do=20 it". Therefore, something ZigBee IP is a profile which defines one=20 particular way of doing it. There are other ways as well, of course. I=20 guess the question is whether it can be generalised sufficiently to be=20 generally applicable and whether that is in fact worth doing > > > > > Given that: > > > > Because IEEE 802.15.4 maximum payload size is 128 Bytes, a standa= rd > > 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 tra= nsport: I realise that PANA/EAP/EAP-TLS gets roundly criticised for being=20 "heavyweight". Indeed, there are overheads in the use of these three=20 very well-established protocols which could be removed in certain cases. = However, this would result in the development of new protocols. Having=20 done a lot of work in looking at DTLS options, I can confidently say=20 that the difference at the end of the day is quite small > > > > If EAP is used, PANA can be used to relay the authentication mess= age > > from configured FFDs to 6LBR. If the validation is successful, t= he > > IP address and network key are generated and delivered to the FFD= =2E > > > > But, EAP-TLS with PANA is exactly what the Zigbee IP specification h= as specified. > > Do you envision any changes from that specification? > > Zigbee IP specification was developed to enable IP address for Zigbee a= pplication, thus the protocol stack are built on IETF's standards, includ= ing EAP-TLS. > As discussed in many working groups, TLS might result in a significant = amount of retransmissions due to unreliable communication capability of t= he 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=20 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=20 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 draf= t 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 ma= ke 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 occur= s 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 adv= antage of such IP address generation mechanism, so that PANA can be run w= ithout any problem. ZigBee IP solved this problem by using SLAAC IPv6 addresses based=20 on the EUI-64. These can be used in PANA straight away without the need=20 for any other configuration > =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? > > For unconstrained environment, I agree with you. But when it comes to c= onstrained device and constrained network communication, TLS might not be= a good choice as mentioned before. Certificate is not a good choice eith= er 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, Physical Unclonable Function (PUF). There certainly are overheads in certificates but in the 802.1AR=20 scenario (draft-pritikin-anima-bootstrapping-keyinfra-01) it has clear=20 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 sche= duling) > > would be provisioned. > > 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=20 session and describe what it is used for > > > Regards, > Ana > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > --------------050601010308030707080601 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Danping,

I have some general comments on the draft and some additional comments inline, bracketed by <RCC></RCC>

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.=A0 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.
  • 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.
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 bes=
t.
	>=20

	> Hedanping (Ana) <ana.hedanping@huawei.com> wrote:
	>     > A new draft is submitted, it's about the security bootstra=
pping
	>     > architecture and methods for IoT networks that implement I=
ETF
	> 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 q=
uite well,
	> and nobody has clearly articulated the process yet.  People have ju=
st assumed
	> that everyone knows this process, but really it needs to get writte=
n 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.
<RCC>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</RCC>

	>=20
	> Given that:
	>=20
	>    Because IEEE 802.15.4 maximum payload size is 128 Bytes, a stand=
ard
	>    security bootstrapping protocol should be light-weight with low
	>    complexity.  The protocol must allow for commissioning of device=
s
	>=20
	> I was surprised that the draft then suggested EAP with PANA as a tr=
ansport:
<RCC>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</RCC>
	>=20
	>    If EAP is used, PANA can be used to relay the authentication mes=
sage
	>    from configured FFDs to 6LBR.  If the validation is successful, =
the
	>    IP address and network key are generated and delivered to the FF=
D.
	>=20
	> 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 app=
lication, thus the protocol stack are built on IETF's standards, includin=
g EAP-TLS.=20
As discussed in many working groups, TLS might result in a significant am=
ount 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.
<RCC>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)</RCC>

	> A minority of people had prefered this mechanism for 6tisch-securit=
y, but
	> none stepped forward to write up that mechanism.   Perhaps this dra=
ft could
	> fulfill that need?

Yes, we should describe more clearly on this mechanism, and maybe this dr=
aft is a right place. It would be great if folks in the mailing list make=
 comments and contribution on this technical point.
<RCC>I am happy to write up that mechanism</RCC>

	> You write that the IP address would be generated; usually that occu=
rs via
	> distribution of PIOs via ND (router-adveristments) or RPL.  Were yo=
u going to
	> suggest something else here?

According to my knowledge, IP address can be generated once a device is a=
uthenticated to network access, afterwards, other further protocols can u=
se IP to communicate.=20
Besides, PANA needs IP as well. The incremental bootstrapping takes advan=
tage of such IP address generation mechanism, so that PANA can be run wit=
hout any problem.
<RCC>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</RCC>
 =20

	> From the ANIMA and 6tisch-security point of view, my view is that t=
his is all
	> about the choice of certificates for the TLS setup.  Do you have an=
y view on
	> how that might work?

For unconstrained environment, I agree with you. But when it comes to con=
strained 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.=20
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 ke=
y, Physical Unclonable Function (PUF).
<RCC>There certainly are overheads in certificates but in the 802.1AR scenario (draft-pritikin-anima-bootstrapping-keyinfra-01) it has clear value.</RCC>

	>=20
	> The 6tisch-security bootstrap process aims to create a
	> YANG/CBOR-over-CoAP-over-DTLS session between a Join Coordinator an=
d the
	> Joining Node: over that management link, security (and timeslot sch=
eduling)
	> would be provisioned.

CoAP-DTLS coincides with my idea.
Yang sounds like at a higher level, but I think EAP is actually the mecha=
nism running behind ^_^
<RCC>Again, in this document, it might be better to abstract this session and describe what it is used for</RCC>


Regards,
Ana

_______________________________________________
6lo mailing list
6lo@ie=
tf.org
https://www.ietf.org/mailman/listinfo/6lo

--------------050601010308030707080601-- --------------ms050800090303060805030500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRnzCC BXQwggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w MDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3 o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkU a+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwU q37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PK LrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwbKIpcInu0q5jZ7uBRg8MJ Rk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNaJLS6qVY9z2+q/0lYvvCo //S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx688O3T2plqFIvTz3r7UN IkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7199QalVGv6CjKGF/ cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BCiH+jMzouXB5B EYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4onZzMv7NR 2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Js LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEE KTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB DAUAA4IBAQBkv4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1 uouhbcRUCXXH4ycOXYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VX aX2S2FLKc4G/HPPmuG5mEQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeW ukhNkPKUyKlzousGeyOd3qLzTVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla 4EEkHbKPFWBYR9vvbkb9FfXZX5qz29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCC A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n 9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81 zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X 72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60 ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggY5 MIIFIaADAgECAhEAkJNVgmy0T3j/sFnejfTMyTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQwOTE2MDAwMDAwWhcN MTcwOTE1MjM1OTU5WjCCATcxCzAJBgNVBAYTAkdCMRAwDgYDVQQREwdXRjQgNFdBMRcwFQYD VQQIEw5XZXN0IFlvcmtzaGlyZTESMBAGA1UEBxMJV2FrZWZpZWxkMRQwEgYDVQQJEwtHcmFu Z2UgTW9vcjEfMB0GA1UECRMWODkgR3JlZW5maWVsZCBDcmVzY2VudDEXMBUGA1UEChMOR3Jp ZG1lcmdlIEx0ZC4xNDAyBgNVBAsTK0lzc3VlZCB0aHJvdWdoIEdyaWRtZXJnZSBMdGQuIEUt UEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT DVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTtrEYc/EYQZDn+/Byj786j qzQJukVnEZ0qu6G8Y/QZphmITLPJJCxlCvJhRGCt5zRDfwG1lM0k77mTVP166mrPMKfEbhAF mhW54app3f02j/E0T73Wkwqhc2xj+vs6ox+kXRZIiEa/VY1TXd8ALZZAJ2uPQm+3QByE0cO6 7Q7jr5dmZuXAuygh5Q7MvzxL0vKmxhJ1n0veVDwk+BifimRX+HHU3XTGrqySkiN4Amdm7ESD qdO7UAoezIGZoA/fTJE9CS4f4tVXcKhfGlp/Tw3K9q9cp6cjYD802hnFoiSQ9PgLviP20lcH CIGn91WkYhuYG9u8Fzgzmu0yVK5L0kkCAwEAAaOCAdswggHXMB8GA1UdIwQYMBaAFIKvbIz4 xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTSD2iG48824eEQkBLu4BgdWzh49TAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw RgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1 cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNv bS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0 LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAq8C9mIiSV9Nj9ZjHa 1kupbDGYy57v5fCk9lT++uiwGBP9yIFd9Gr8wISOl+96l9OLo8E+5CcPLyt96H4ez/ksXjC1 5EhzuhUB7HNi2b9GLDenjiHW4vBmSoIAbt9Pnz6zZsPH7eBPBcqkIWLFuqKBYUoXKLpzrVtr Kgv6PM3t2+4YakBnMWjpcqzinurEeGq4mh3gHTv03wcyT6eQVCu5k4yaJxoQReYtYIjv+W+m LmT/ZW61ZATZb2adV8xPejUlWSq4+2bpRbXZpD9FAmomNC8fSvGUUhMfYq5t5IUPHfP0kEH5 WQVWgVfpcf6Q8rnpWznsMiJrucUpJf8ZenHtMYIEKDCCBCQCAQEwga0wgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTAJ BgUrDgMCGgUAoIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTAyMjAxMTU5MjNaMCMGCSqGSIb3DQEJBDEWBBSkwnacLig9x1g2LdxfgFLiEn6PNjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0 T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQA3+lWPT8cwem8tujuK0tJ8hDdQvhohWR/b DG7ssVPkLyK8OETtkiKDzuBAL4Ux2Yxcujb7fPW90sxptw1sZnGSdon8DmufweaD1670SxVR nST0pRHSbMZ1COjdUF2xnYPFVyrtidfYPK7MwAmAJ2WC+OdBoLmIiBYOrZteOcq9MoRdIJl0 v21rDG/e+CMiLACwwOeNjOHCZ52RHI3k5O40Gm1tW9tOKdYiyhU2E55BmKtmUoCxcW1vuQLX kl9pmFEwMyNtoQmNKaXF36taabYQb/HByugM2Fqnq+7qtxTOU0EDlrCdaneZEJqy4BWvUSCX N57tj0QIJcZJQMpd10dxAAAAAAAA --------------ms050800090303060805030500-- From nobody Fri Feb 20 06:23:47 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: X-Mailman-Approved-At: Fri, 20 Feb 2015 06:23:45 -0800 Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "anima@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [6tisch-security] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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 10:51:50 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: [6tisch-security] [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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:39 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: [6tisch-security] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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 10:54:13 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: [6tisch-security] [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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:16 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: [6tisch-security] [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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 Sun Feb 22 09:49:41 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: X-Mailman-Approved-At: Sun, 22 Feb 2015 09:49:40 -0800 Cc: 6tisch-security@ietf.org, Michael Richardson , "Hedanping \(Ana\)" , robert.cragie@gridmerge.com, 6lo@ietf.org, Hannes Tschofenig , anima@ietf.org Subject: Re: [6tisch-security] [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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 Sun Feb 22 09:49:42 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: X-Mailman-Approved-At: Sun, 22 Feb 2015 09:49:40 -0800 Cc: 6tisch-security@ietf.org, Michael Richardson , "Hedanping \(Ana\)" , robert.cragie@gridmerge.com, 6lo@ietf.org, anima@ietf.org Subject: Re: [6tisch-security] [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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 Sun Feb 22 16:43:24 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CC91A00FB for <6tisch-security@ietfa.amsl.com>; Sun, 22 Feb 2015 16:43:23 -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 ANL18Ik-CWcD for <6tisch-security@ietfa.amsl.com>; Sun, 22 Feb 2015 16:43:21 -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 74B681A00E5 for <6tisch-security@ietf.org>; Sun, 22 Feb 2015 16:43:21 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 86F272009E; Sun, 22 Feb 2015 19:51:26 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id E2A7963A21; Sun, 22 Feb 2015 19:43:19 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C7D91637F4; Sun, 22 Feb 2015 19:43:19 -0500 (EST) From: Michael Richardson To: Malisa Vucinic In-Reply-To: <8E377EDE-074F-472E-B397-86F29AEDEB19@imag.fr> References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> <54D98E01.4090103@gmail.com> <8E377EDE-074F-472E-B397-86F29AEDEB19@imag.fr> 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: 6tisch-security@ietf.org Subject: Re: [6tisch-security] Latency aspects of TSCH X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 00:43:23 -0000 --=-=-= Content-Type: text/plain Malisa Vucinic wrote: > I prepared a couple of slides on latency aspects with TSCH that can > hopefully be useful for evaluating different proposals for the join > process once there are more details on message sizes involved. My understanding of your analysis is that it assumes a random schedule, and that it assumes that there is no bandwidth allocated between the 6LBR and the Join Assistant. -- 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) iQEVAwUBVOp3pICLcPvd0N1lAQIjVwf+OV4cDUH7UDsNSEYNr0nSsIMPbMR8ZSWo aOFc0NGC/qCmanSMbHebyHhlIaM3G71Ri4L2n8bFXE5ljvsyZFNswVX84DbWXUee nUNiAq/tg+n4msi4jFOZ93qO5U441ldNDd361oCm3F0LxpzgI2Q6CcXf9g3noX85 Hqs0Q17zwkBZlLKXumAeqBGdwVhxAYvizbUj4Gssqx84tgzHG9K8iwU8lcjzfEuD ZX0hhdnycdGaO0MtAPrk7d3Y83cHIzDexxaYjMi8tllAb2kzNOgtWgsxlkeJQ6dD zp1Hk3SJ15C8hDJoGAqCA96321h6I2E0LZVGgxCH7vfF4ZMCx6fFJQ== =pdxu -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Feb 22 16:45:33 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0A21A00EA for <6tisch-security@ietfa.amsl.com>; Sun, 22 Feb 2015 16:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nNpVw-SbZrx9 for <6tisch-security@ietfa.amsl.com>; Sun, 22 Feb 2015 16:45:31 -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 BE3E21A00E5 for <6tisch-security@ietf.org>; Sun, 22 Feb 2015 16:45:31 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 986382009E; Sun, 22 Feb 2015 19:53:37 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id E76FF63A21; Sun, 22 Feb 2015 19:45:30 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D33C6637F4; Sun, 22 Feb 2015 19:45:30 -0500 (EST) From: Michael Richardson To: Jonathan Simon In-Reply-To: <63410C6A-3545-4A24-B83C-F24E7D3A93A4@linear.com> References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> <54D98E01.4090103@gmail.com> <8E377EDE-074F-472E-B397-86F29AEDEB19@imag.fr> <54E37CD5.7090405@gmail.com> <4EDC1B3D-8E75-4FA8-8B3E-E458B3A9CAA8@imag.fr> <54E3A4D2.8090907@gmail.com> <63410C6A-3545-4A24-B83C-F24E7D3A93A4@linear.com> 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: Malisa Vucinic , Rene Struik , 6tisch-security@ietf.org Subject: Re: [6tisch-security] (simplified explanation of formulae) Re: Latency aspects of TSCH X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 00:45:32 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jonathan Simon wrote: > there isn=E2=80=99t a lot of backoff * that any security related proc= essing can > happen before any subsequent steps that rely on said processing occur. > This may not be true for ECC operations or generation and testing of > large primes. The only time I know that we need to test for primes is when looking at g^x values for a DH exchange that would be part of PFS. Is there another time? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVOp4JICLcPvd0N1lAQLSgQf/aOw1hDxopgGNZSVLOvN261YpcsqSITMV ou2VYbbW/gTxMJIEeO1yPzcKh6dnwMQtr0aIL4kIym9G2aCSTGy7EfYlwqXkshHj VKpy2tyH09sjTbg1L7Xj14UPhcdFa5JhvQt2ghDAaGmgOxPD3OHc5oQL8tH5UqpZ LoCOoN+HDc491CnjV7KLVXQ/wq53dtdH4J1s39+OOGltho4NoLLxS/NGQ2VfKCOU CvOo02BaxhfPXLYNg8jS21W/eN+rKcinpCuSL+xzInSZCpYglCLkZTGWW5xMz88C UOXF9+9H+gLw6gTZMvZohO2UwOXGcqvLl4FPJagm5Nn15kJA14Lkmw== =gmRw -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Feb 22 21:18:32 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893B11A01BA for <6tisch-security@ietfa.amsl.com>; Sun, 22 Feb 2015 21:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.781 X-Spam-Level: X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, SPF_NEUTRAL=0.779, 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 WoKAD9a0_6JN for <6tisch-security@ietfa.amsl.com>; Sun, 22 Feb 2015 21:18:28 -0800 (PST) Received: from shiva.imag.fr (mx1.imag.fr [IPv6:2001:660:5301:6::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D9D1A01A5 for <6tisch-security@ietf.org>; Sun, 22 Feb 2015 21:18:28 -0800 (PST) Received: from globule.imag.fr (globule.imag.fr [129.88.34.238]) by shiva.imag.fr (8.13.8/8.13.8) with ESMTP id t1N5IOrx025326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2015 06:18:24 +0100 Received: from [192.168.1.32] (c-67-170-237-101.hsd1.ca.comcast.net [67.170.237.101]) (authenticated bits=0) by globule.imag.fr (8.13.8/8.13.8) with ESMTP id t1N5IG3n012297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2015 06:18:23 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Malisa Vucinic In-Reply-To: Date: Sun, 22 Feb 2015 21:18:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> <54D98E01.4090103@gmail.com> <8E377EDE-074F-472E-B397-86F29AEDEB19@imag.fr> <29581.1424652199@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.2070.6) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (shiva.imag.fr [129.88.30.5]); Mon, 23 Feb 2015 06:18:24 +0100 (CET) X-IMAG-MailScanner-Information: Please contact MI2S MIM for more information X-MailScanner-ID: t1N5IOrx025326 X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-SpamCheck: X-IMAG-MailScanner-From: malisa.vucinic@imag.fr MailScanner-NULL-Check: 1425273505.05235@YDnDxQH0CKNPMY7CN08j+Q Archived-At: Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] Latency aspects of TSCH X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 05:18:30 -0000 > On 22 Feb 2015, at 16:43, Michael Richardson = wrote: >=20 >=20 > Malisa Vucinic wrote: >> I prepared a couple of slides on latency aspects with TSCH that can >> hopefully be useful for evaluating different proposals for the join >> process once there are more details on message sizes involved. >=20 > My understanding of your analysis is that it assumes a random = schedule, Yes, that is correct. > and > that it assumes that there is no bandwidth allocated between the 6LBR = and the > Join Assistant. Why would that be an assumption? It works for any pair of nodes in the = mesh including the 6LBR and the JA. For instance, for a given bandwidth = allocated between the 6LBR and the JA it estimates what can you expect = in terms of latency on that path with a random schedule.=20 From nobody Mon Feb 23 00:21:56 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: [6tisch-security] [6lo] [Anima] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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 07:02:02 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D191A1A1D for <6tisch-security@ietfa.amsl.com>; Mon, 23 Feb 2015 07:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.569 X-Spam-Level: * X-Spam-Status: No, score=1.569 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779, 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 qOmDzQVrZ1O1 for <6tisch-security@ietfa.amsl.com>; Mon, 23 Feb 2015 07:01:58 -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 EF6C51A0193 for <6tisch-security@ietf.org>; Mon, 23 Feb 2015 07:01:57 -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 t1NF1rqk015195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Feb 2015 17:01:53 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t1NF1rIj024662; Mon, 23 Feb 2015 17:01:53 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <21739.16609.214466.57257@fireball.kivinen.iki.fi> Date: Mon, 23 Feb 2015 17:01:53 +0200 From: Tero Kivinen To: Michael Richardson In-Reply-To: <18210.1424319597@sandelman.ca> References: <18210.1424319597@sandelman.ca> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 12 min X-Total-Time: 13 min Archived-At: Cc: 6tisch-security@ietf.org Subject: [6tisch-security] WGLC comments on 6tisch-security X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 15:02:00 -0000 Michael Richardson writes: > 16) 8.2, insert something to the effect: > Most RPL Objective Functions require metrics about reachability, > such as the ETX. 6top creates and maintains an abstract neighbor= > table, and this may be leveraged. ... This information ... >=20 > " > 6top also enables the RPL > OF to influence the MAC behaviour, for instance by configuring the= > periodicity of IEEE802.15.4e Extended Beacons (EB's). By augmenti= ng > the EB periodicity, it is possible to change the network dynamics = so > as to improve the support of devices that may change their point o= f > attachment in the 6TiSCH network. > " >=20 > But, we aren't using the Enhanced Beacons (they are enhanced, not > extended, aren't they=3F or did I get that backwards again=3F) for= > production network use... They are Enhanced Beacons, and yes you DO need them on the production network (unless your network is completely statically configured). The TSCH PAN formation requires that device (usually PAN coordinator) sends enhanced beacons which contain following information: =09- Time information so new devices can synchronize to the =09 network, as described in 7.4.3.2. =20 =09=E2=80=94 Channel hopping information, as described in 6.2.10 and =09 7.4.3.31. =09=E2=80=94 Timeslot information describing when to expect a frame to = be =09 transmitted and when to send an acknowledgment, as described =09 in 7.4.3.4. =09=E2=80=94 Initial link and slotframe information so new devices know= =09 when to listen for transmissions from the advertising device =09 and when they can transmit to the advertising device, as =09 described in 7.4.3.3. (this is from P802.15.4-REVc-DF3 draft, so section numbers do not match with old versions). If your network stays same, then there is no need to update any of that but if new devices join and you want to change for example the slotframe information, I think the enhanced beacons are the way to transmit that information from coordinator to the devices. If you check the IE table description: https://mentor.ieee.org/802.15/dcn/15/15-15-0090-01-0mag-ie-table.docx you will see that TSCH Slotframe and Link IE is supposed to be sent only in Enhanced beacons. Also note, as most of that information is in the Payload IEs that mean that enhanced beacons cannot really be encrypted, they can only be authenticated (i.e. security levels 1-3), so new devices can also read the information even without knowing the encryption keys.=20 =20 > I would write: > Consideration was given towards finding a way to embed the Route > Advertisements and the RPL DIO messages (both of which are > multicast) into the IEEE802.15.4e Enhanced Beacons. It was > determined that this produced undue timer coupling among layers, > that the resulting packet size was potentially too large, and > required it is not yet clear that there is any need for Enhanced > Beacons in a production network. So I think it is incorrect to claim that we do not need enhanced beacons in production network, as I do think it is still needed unless we manage the slotframes using some upper layer protocol. --=20 kivinen@iki.fi From nobody Mon Feb 23 10:53:09 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: [6tisch-security] [6lo] [Anima] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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 11:29:53 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EAB1A212D for <6tisch-security@ietfa.amsl.com>; Mon, 23 Feb 2015 11:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, WEIRD_PORT=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 6z6ffm4LqPKE for <6tisch-security@ietfa.amsl.com>; Mon, 23 Feb 2015 11:29:45 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::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 E5B9C1A1F70 for <6tisch-security@ietf.org>; Mon, 23 Feb 2015 11:29:44 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id z20so20916605igj.4 for <6tisch-security@ietf.org>; Mon, 23 Feb 2015 11:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=wtaWH1TSiKr8TgMRHrqV/3v7MTKWdMA1gessVh1fhi4=; b=p/oS0Koy3TNA52t1ggfcTfxH6z0ZRdRA+/g7prucmUPrqh/vLxnOJwg2aSdbs3cmp/ anlQBSs3Pn2YwT5YDLD0LYvIRhlrnrEbQbCFf/b7UM6mlkNgfqhH8glH/KLkV/e+ENUI YeOtPcDfg3g/cdhJu0/X9KTSSN4U4PP9hJErgPp5+5OWIWLtaUHgLfPHGAjKT/RBJehk bEm5w0W5K4rLTLZV9cW52Zz3M6ZdZBi03V9Dk1SyU2YxxCxa43iVCqgq9xhuob2hi4Ci 7h+Pojl/UuyERyo0M0j099xy+m9FuyWLixwbqJ2IinKdGkVNxcRofTdtZ91rPU/fT3+r Ld5g== X-Received: by 10.42.93.16 with SMTP id v16mr12179355icm.74.1424719784165; Mon, 23 Feb 2015 11:29:44 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id z29sm22588897ioi.36.2015.02.23.11.29.42 for <6tisch-security@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 11:29:43 -0800 (PST) Message-ID: <54EB7FA5.7010007@gmail.com> Date: Mon, 23 Feb 2015 14:29:41 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: tisch-security <6tisch-security@ietf.org> References: <54E3414E.2070201@gmail.com> In-Reply-To: <54E3414E.2070201@gmail.com> X-Forwarded-Message-Id: <54E3414E.2070201@gmail.com> Content-Type: multipart/alternative; boundary="------------000703000400030400000204" Archived-At: Subject: [6tisch-security] Reminder -- 6tisch security call *tomorrow*, Tue Feb 24, 2015, 9am EST (includes dial-in info) X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 19:29:51 -0000 This is a multi-part message in MIME format. --------------000703000400030400000204 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear colleagues: Just a quick reminder that we have a 6TiSCH security conf call *tomorrow*, Tue February 24, 2015, 9am EST. Suggested agenda: 1) administrativia {agenda bashing/minutes} 2) implementation aspects (w/. HW considerations) 3) time latency aspects (continuation) 4) AOB The dial-in information is the same as usual -- please scroll down. Rene == The schedule for the next few 6tisch security conference calls is as follows: Tue Jan 20th: 4.30pm EST Tue Jan 27th: 9am EST Tue Feb 3rd: 4.30pm EST Tue Feb 10th: 4.30pm EST Tue Feb 17th: 9am EST Tue Feb 24th: 9am EST Tue Mar 3rd: 4.30pm EST -------- Forwarded Message -------- Subject: Re: Reminder -- 6tisch security call *today*, Tue Feb 17, 2015, 9am EST (includes dial-in info) Date: Tue, 17 Feb 2015 08:25:34 -0500 From: Rene Struik To: tisch-security <6tisch-security@ietf.org> Dear colleagues: Just a quick reminder that we have a 6TiSCH security conf call *today*, Tue February 17, 2015, 9am EST. As you may recall, I put as tentative item on the agenda of last week's call "time latency aspects" of the join protocol . Thomas Watteyne volunteered to take on this topic for this week's call. Suggested agenda: 1) administrativia {agenda bashing/minutes} 2) time latency aspects (Thomas Watteyne) 3) AOB == The schedule for the next few 6tisch security conference calls is as follows: Tue Jan 20th: 4.30pm EST Tue Jan 27th: 9am EST Tue Feb 3rd: 4.30pm EST Tue Feb 10th: 4.30pm EST Tue Feb 17th: 9am EST Tue Feb 24th: 9am EST Tue Mar 3rd: 4.30pm EST On 2/9/2015 11:50 PM, Rene Struik wrote: > Dear colleagues: > > Just a quick reminder that we have a 6TiSCH security conf call > tomorrow, Tue February 10, 2015, 4.30pm EST. > > I have not seen any email traffic the last two weeks, nor any more > feedback on the draft document I posted on Fri January 9th. > > I put as tentative item on the agenda "time latency aspects" of the > join protocol. I will send out a more definitive agenda tomorrow > around noon EST. Please send agenda request to me prior to that time. > > Suggested agenda: > 1) administrativia {agenda bashing/minutes} > 2) time latency aspects > 3) AOB > > On 1/28/2015 10:16 AM, Rene Struik wrote: >> Dear colleagues: >> >> Please find below the minutes of the 6TiSCH Security conf call as of >> January 27, 2015, 9-10am EST. >> >> Minutes 6TiSCH Security conf call, Wed January 27, 2015, 9-10am EST >> {note taker: Rene Struik} >> {recording: not available (Michael Richardson had control, but was >> not on the call} >> {discussion material (referenced in minutes): this time, no posted >> collatoral} >> >> 1. Attendance: >> Tero Kivinen, Yoshi Ohba, Rene Struik >> >> 2. Agenda >> The suggested updated agenda was approved. >> Suggested agenda: >> 1) administrativia {agenda bashing/minutes} >> 2) prep for IETF-92 in Dallas >> 3) AOB >> >> 3. Minutes >> The minutes of the previous 6TiSCH security conference call (Thu >> January 22, 2015) were approved. >> >> 4. Prep for IETF-92 in Dallas {more of a 6tisch security various >> "varia" discussion really} >> YO asked what happened with the output of the join process overview >> text discussed during last week's call. RS mentioned that Pascal >> Thubert included this in the 6tisch architecture draft (Section 13 - >> Security Considerations) and would issue >> draft-ietf-6tisch-architecture-05 for WGLC some time this week. >> >> RS mentioned that at the IETF-92 meeting in Dallas in March, the >> 6tisch group would presumably recharter and include more >> security-related milestones into the revised charter. He thought it >> would be useful to have a 6tisch security draft by that meeting that >> could serve as baseline. >> >> TK provided some more insight into the 802.15.4rev effort. He >> suggested that there would be 1-2 more letter ballots, followed by >> the start of sponsor ballot around end of March 2015, with >> anticipated conclusion of the work around July-August this year. RS >> commented that this schedule seemed quite aggressive, considering >> historical timelines of IEEE 802.15 efforts. TK mentioned that >> according to Bob Heile (Chair IEEE 802.15) the 802.15rev draft would >> only be available in the 802.15 private member area or to those >> people participating in person in an actual IEEE 802 meeting. >> Therefore, it does not seem possible to make a draft available to >> interested parties in the 6tisch community who did not meet those >> criteria (as previously suggested). >> >> 5. AOB >> RS suggested to cancel the 6tisch security call of next week and >> reconvene two weeks from now, which was agreed upon. _Next call will >> take place Tue Feb 10, 2015, 4.30pm EST._ >> >> RS mentioned he had received feedback from Kris Pister and Yoshi Ohba >> on draft-struik-6tisch-security-architectural-considerations-01 >> (posted January 9, 2015). Before updating the draft, he would like to >> see more people give this a look. He invited people to use the now >> cancelled slot of next week's call to review this draft... >> >> [call ended @9.23am EST] >> >> >> On 1/26/2015 12:15 PM, Rene Struik wrote: >>> Dear colleagues: >>> >>> Just a quick reminder that we have a 6TiSCH security conf call >>> tomorrow, Tue January 27, 2015, 9am EST. I expect this to be a short >>> call. >>> >>> Suggested agenda: >>> 1) administrativia {agenda bashing/minutes} >>> 2) prep for IETF-92 in Dallas >>> 3) AOB >>> >>> The dial-in info is below. >>> >>> Best regards, Rene >>> >>> _B) Dial-in information:_ >>> English : New York Time 6tisch security >>> Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00) >>> Meeting number: 641 709 118 >>> Meeting password: joinjoin >>> Audio connection: >>> 1-877-668-4493 Call-in toll free number (US/Canada) >>> 1-650-479-3208 Call-in toll number (US/Canada) >>> >>> Access code: 641 709 118 >>> Meeting link: >>> https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6 >>> >>> The etherpad we have used is at: >>> http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt >>> >>> >>> >>> >>> On 1/21/2015 10:30 AM, Rene Struik wrote: >>>> Dear colleagues: >>>> >>>> Giuseppe Piro offered to give a presentation on MAC security >>>> aspects, resulting in the updated agenda below. Dial-in info at >>>> bottom of email. >>>> >>>> Remember: 6tisch security call is now tomorrow, Thu Jan 21, 2015, >>>> 1pm EST, with duration not to exceed one hour. Please call-in on >>>> time and test your speaker/mike beforehand. >>>> >>>> Suggested updated agenda: >>>> 1) administrativia {agenda bashing/minutes} [4 min] >>>> 2) 6tisch security conf call schedule moving forward [1 min] >>>> 3) input 6tisch security to architecture draft [15 min] >>>> -- RS to present result homework assignment of last call >>>> 4) presentation Giuseppe Piro re MAC security [30 min] >>>> 5) prep for IETF-92 in Dallas [10 min] >>>> 5) AOB >>>> >>>> Link to suggested text (item #3 above): >>>> https://drive.google.com/file/d/0B2a6Ilxu1XfCbVhfd0ZONXoxc00/view?usp=sharing >>>> >>>> On 1/20/2015 4:54 PM, Rene Struik wrote: >>>>> Dear colleagues: >>>>> >>>>> Due to connectivity problems, those on the 6tisch security call >>>>> today concluded that it was best to reschedule the call. >>>>> >>>>> The rescheduled 6tisch security call will take place this >>>>> Thursday, January 22, 2015, 1-2pm EST. >>>>> (Please note that this is only once; schedule moving forward will >>>>> otherwise remain the same) >>>>> >>>>> Agenda and dial-in info remain the same (please scroll down). >>>>> >>>>> Best regards, Rene >>>>> >>>>> >>>>> On 1/20/2015 4:35 PM, Rene Struik wrote: >>>>>> I posted the document on Google drive, see weblink below. >>>>>> >>>>>> https://drive.google.com/file/d/0B2a6Ilxu1XfCa3RyZzlZb3RRREk/view?usp=sharing >>>>>> >>>>>> On 1/20/2015 1:13 AM, Rene Struik wrote: >>>>>>> Dear colleagues: >>>>>>> >>>>>>> Please find attached my analysis of the three text proposals. I >>>>>>> hope this helps in zooming in on consensus text. >>>>>>> >>>>>>> I will present this in more detail as item #3 on the agenda for >>>>>>> the 6tisch security call of tomorrow, Tue Jan 20, 2015, 4.30pm EST. >>>>>>> >>>>>>> We can discuss this in more detail during that call (I won't >>>>>>> have much time beforehand). >>>>>>> >>>>>>> Best regards, Rene >>>>>>> >>>>>>> [excerpt of minutes of 6tisch security conf call as of January >>>>>>> 14, 2015, 11am-12pm EST] >>>>>>> TW asked whether RS could review the three text proposals >>>>>>> currently on the table and suggest a way forward that takes into >>>>>>> account consensus and what was discussed during the call. RS >>>>>>> agreed to take this on as homework assignment, with target to >>>>>>> report back on this to the group by the end of Monday next week >>>>>>> (January 19, 2015). >>>>>>> >>>>>>> On 1/19/2015 2:20 PM, Rene Struik wrote: >>>>>>>> Dear colleagues: >>>>>>>> >>>>>>>> Just a quick reminder that we have a 6TiSCH security conf call >>>>>>>> tomorrow, Tue January 20, 2015, 4.30-5.30pm EST. >>>>>>>> >>>>>>>> Suggested agenda: >>>>>>>> 1) administrativia {agenda bashing/minutes} >>>>>>>> 2) 6tisch security conf call schedule moving forward >>>>>>>> 3) input 6tisch security to architecture draft >>>>>>>> -- RS to present result homework assignment of last call >>>>>>>> 4) prep for IETF-92 in Dallas >>>>>>>> 5) AOB >>>>>>>> >>>>>>>> For dial-in info, please see bottom of this email. >>>>>>>> >>>>>>>> As to item #2 above, if you wish to weigh-in, please do respond >>>>>>>> to the Doodle poll by end of *today*, see >>>>>>>> https://doodle.com/q63844gqd59urrae. >>>>>>>> >>>>>>>> Best regards, Rene >>>>>>>> >>>>>>>> -------- Forwarded Message -------- >>>>>>>> Subject: reminder -- 6tisch security call *tomorrow*, Wed Jan >>>>>>>> 14, 2015, 11am EST (dial-in info at bottom) >>>>>>>> Date: Tue, 13 Jan 2015 19:37:04 -0500 >>>>>>>> From: Rene Struik >>>>>>>> To: tisch-security <6tisch-security@ietf.org> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Dear colleagues: >>>>>>>> >>>>>>>> Just a quick reminder that we *do* have a conf call tomorrow, >>>>>>>> Wed Jan 14, 2015, 11am EST. >>>>>>>> >>>>>>>> Currently, the main agenda item is item #4b of last week: input >>>>>>>> to the 6tisch architecture draft. It would also be good to have >>>>>>>> some more comments on the draft I posted. >>>>>>>> >>>>>>>> Minutes of calls later tonight (sorry - extremely busy). For >>>>>>>> conf call dial-in info, see bottom of email. >>>>>>>> >>>>>>>> Best regards, Rene >>>>>>>> >>>>>>>> == >>>>>>>> Note: next week's call is on Wed Jan 14, 2015, 11am EST. >>>>>>>> >>>>>>>> On 1/6/2015 11:48 AM, Rene Struik wrote: >>>>>>>>> Dear colleagues: >>>>>>>>> >>>>>>>>> Happy New Year! >>>>>>>>> >>>>>>>>> According to the agreed-upon 6tisch security conf call >>>>>>>>> schedule, we will resume the conference call series today, Tue >>>>>>>>> Jan 6, 2015, 5pm EST. >>>>>>>>> >>>>>>>>> I propose we continue the discussion where we left off prior >>>>>>>>> to Christmas (essentially, item 3c below), except that we may >>>>>>>>> have a short presentation first (item #2). >>>>>>>>> >>>>>>>>> Agenda: >>>>>>>>> 1) administrativia {agenda bashing/minutes} >>>>>>>>> 2) {still to be confirmed} presentation Giuseppe Piro >>>>>>>>> 3) join protocol details >>>>>>>>> -- a) (done) status update MAC behavior >>>>>>>>> -- b) (brief!) recap of routing/communication flow aspects >>>>>>>>> -- c) incremental deployment aspects >>>>>>>>> 4) input 6tisch security to other 6tisch documents >>>>>>>>> -- a) terminology draft >>>>>>>>> -- b) architecture draft >>>>>>>>> >>>>>>>>> Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris >>>>>>>>> time. {The next call, on January 6, 2014) is also at 5pm EST >>>>>>>>> (see schedule till half of January 2015)}. >>>>>>>>> Note: next week's call is on Wed Jan 14, 2015, 11am EST. >>>>>>>>> >>>>>>>>> Dial-in info at end of this email. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Rene >>>>>>>>> >>>>>>>>> -------- Forwarded Message -------- >>>>>>>>> Subject: Suggested agenda for 6tisch security call of >>>>>>>>> *today*, Tue December 16, 2014, 5pm EST (dial-in info at bottom) >>>>>>>>> Date: Tue, 16 Dec 2014 09:21:20 -0500 >>>>>>>>> From: Rene Struik >>>>>>>>> To: tisch-security <6tisch-security@ietf.org> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Dear colleagues: >>>>>>>>> >>>>>>>>> I propose we continue the discussion where we left off last week. >>>>>>>>> >>>>>>>>> Agenda: >>>>>>>>> 1) administrativia {agenda bashing/minutes} >>>>>>>>> 2) join protocol details >>>>>>>>> -- a) (brief!) status update MAC behavior >>>>>>>>> -- b) continuation of routing/communication flow aspects {last >>>>>>>>> week, we did not finish the only two slides on this >>>>>>>>> 3) input 6tisch security to other 6tisch documents >>>>>>>>> >>>>>>>>> Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris >>>>>>>>> time. {The next call, on January 6, 2014) is also at 5pm EST >>>>>>>>> (see schedule till half of January 2015)}. >>>>>>>>> >>>>>>>>> Dial-in info at end of this email. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Rene >>>>>>>>> >>>>>>>>> -------- Forwarded Message -------- >>>>>>>>> Subject: suggested agenda for 6tisch security call of >>>>>>>>> tomorrow, Tue December 9, 2014, 9am EST (dial-in info at bottom) >>>>>>>>> Date: Mon, 08 Dec 2014 17:16:40 -0500 >>>>>>>>> From: Rene Struik >>>>>>>>> To: tisch-security <6tisch-security@ietf.org> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Dear colleagues: >>>>>>>>> >>>>>>>>> For last week's Tue Dec 2, 2014, 9am EST conf call I prepared >>>>>>>>> some material and posted prior to the call. During the call, >>>>>>>>> we discussed all MAC-related aspects relevant for the join >>>>>>>>> protocol and did not discuss higher-layer aspects I prepared >>>>>>>>> material for yet. I suggest we continue the systematic >>>>>>>>> discussion of last week and take that topic on now. >>>>>>>>> >>>>>>>>> This leads to the following suggested agenda for this week >>>>>>>>> (essentially a continuation of last week's one): >>>>>>>>> >>>>>>>>> Same as last week's, except with >>>>>>>>> #1a-b) focus on routing/communication flow related aspects >>>>>>>>> join protocol; >>>>>>>>> #2a): confirm concensus on MAC (as discussed last week) and >>>>>>>>> routing/communication flow aspects >>>>>>>>> #2c) {as consequence of two items above} what to squeeze into >>>>>>>>> architecture draft >>>>>>>>> >>>>>>>>> The detailed agenda and dial-in info is below (#A, resp. #B). >>>>>>>>> >>>>>>>>> Best regards, Rene >>>>>>>>> >>>>>>>>> _A) Suggested agenda Tue Dec 9, 2014, 9am EST call_ >>>>>>>>> >>>>>>>>> Proposed agenda: >>>>>>>>> >>>>>>>>> 0) Agenda bashing >>>>>>>>> >>>>>>>>> 1) Join protocol details >>>>>>>>> >>>>>>>>> a) desired properties >>>>>>>>> b) realizable properties >>>>>>>>> >>>>>>>>> #1a-b) focus on routing/communication flow related aspects >>>>>>>>> join protocol (we discussed MAC-related join-relevant >>>>>>>>> aspects during the conf call of Tue Dec 2, 2014, 9am EST). >>>>>>>>> For slides, see >>>>>>>>> https://drive.google.com/folderview?id=0B2a6Ilxu1XfCNF9JaXR1ZXlzZlU&usp=sharing >>>>>>>>> (same slides as sent out prior to Dec 2, 2014, 9am EST call) >>>>>>>>> Relevant slides: Slides 23-25 (contained in entire slide >>>>>>>>> deck (ppt), but also in excerpt (pdf)) >>>>>>>>> >>>>>>>>> 2) Next steps: >>>>>>>>> a) consensus on 1#a and 1#b >>>>>>>>> >>>>>>>>> #2a): confirm consensus on MAC (as discussed last week) >>>>>>>>> and routing/communication flow aspects >>>>>>>>> #2c) {as consequence of two items above} what to squeeze >>>>>>>>> into architecture draft >>>>>>>>> >>>>>>>>> b) form tiger team to work out details >>>>>>>>> - project phases >>>>>>>>> - communication of sub-results >>>>>>>>> c) what to squeeze into architecture draft, etc. >>>>>>>>> >>>>>>>>> I will prepare material to facilitate discussion on 1) and 2), >>>>>>>>> to be discussed during the call. >>>>>>>>> >>>>>>>>> _B) Dial-in information:_ >>>>>>>>> English : New York Time 6tisch security >>>>>>>>> Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00) >>>>>>>>> Meeting number: 641 709 118 >>>>>>>>> Meeting password: joinjoin >>>>>>>>> Audio connection: >>>>>>>>> 1-877-668-4493 Call-in toll free number (US/Canada) >>>>>>>>> 1-650-479-3208 Call-in toll number (US/Canada) >>>>>>>>> >>>>>>>>> Access code: 641 709 118 >>>>>>>>> Meeting link: >>>>>>>>> https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6 >>>>>>>>> >>>>>>>>> The etherpad we have used is at: >>>>>>>>> http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>>>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>>>> >>>>>> >>>>>> -- >>>>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>>> >>>>> >>>>> -- >>>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>> >>>> >>>> -- >>>> email:rstruik.ext@gmail.com | Skype: rstruik >>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>> >>> >>> -- >>> email:rstruik.ext@gmail.com | Skype: rstruik >>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >> >> >> -- >> email:rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > -- > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email:rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------000703000400030400000204 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call *tomorrow*, Tue February 24, 2015, 9am EST.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) implementation aspects (w/. HW considerations)
3) time latency aspects (continuation)
4) AOB

The dial-in information is the same as usual -- please scroll down.

Rene

==
The schedule for the next few 6tisch security conference calls is as follows:
Tue Jan 20th: 4.30pm EST
Tue Jan 27th: 9am EST
Tue Feb 3rd: 4.30pm EST
Tue Feb 10th: 4.30pm EST
Tue Feb 17th: 9am EST
Tue Feb 24th: 9am EST
Tue Mar 3rd: 4.30pm EST


-------- Forwarded Message --------
Subject: Re: Reminder -- 6tisch security call *today*, Tue Feb 17, 2015, 9am EST (includes dial-in info)
Date: Tue, 17 Feb 2015 08:25:34 -0500
From: Rene Struik <rstruik.ext@gmail.com>
To: tisch-security <6tisch-security@ietf.org>


Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call *today*, Tue February 17, 2015, 9am EST.

As you may recall, I put as tentative item on the agenda of last week's call "time latency aspects" of the join protocol . Thomas Watteyne volunteered to take on this topic for this week's call.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) time latency aspects (Thomas Watteyne)
3) AOB

==
The schedule for the next few 6tisch security conference calls is as follows:
Tue Jan 20th: 4.30pm EST
Tue Jan 27th: 9am EST
Tue Feb 3rd: 4.30pm EST
Tue Feb 10th: 4.30pm EST
Tue Feb 17th: 9am EST
Tue Feb 24th: 9am EST
Tue Mar 3rd: 4.30pm EST

On 2/9/2015 11:50 PM, Rene Struik wrote:
Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue February 10, 2015, 4.30pm EST.

I have not seen any email traffic the last two weeks, nor any more feedback on the draft document I posted on Fri January 9th.

I put as tentative item on the agenda "time latency aspects" of the join protocol. I will send out a more definitive agenda tomorrow around noon EST. Please send agenda request to me prior to that time.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) time latency aspects
3) AOB

On 1/28/2015 10:16 AM, Rene Struik wrote:
Dear colleagues:

Please find below the minutes of the 6TiSCH Security conf call as of January 27, 2015, 9-10am EST.

Minutes 6TiSCH Security conf call, Wed January 27, 2015, 9-10am EST
{note taker: Rene Struik}
{recording: not available (Michael Richardson had control, but was not on the call}
{discussion material (referenced in minutes): this time, no posted collatoral}

1. Attendance:
Tero Kivinen, Yoshi Ohba, Rene Struik

2. Agenda
The suggested updated agenda was approved.
Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) prep for IETF-92 in Dallas
3) AOB

3. Minutes
The minutes of the previous 6TiSCH security conference call (Thu January 22, 2015) were approved.

4. Prep for IETF-92 in Dallas {more of a 6tisch security various "varia" discussion really}
YO asked what happened with the output of the join process overview text discussed during last week's call. RS mentioned that Pascal Thubert included this in the 6tisch architecture draft (Section 13 - Security Considerations) and would issue draft-ietf-6tisch-architecture-05 for WGLC some time this week.

RS mentioned that at the IETF-92 meeting in Dallas in March, the  6tisch group would presumably recharter and include more security-related milestones into the revised charter. He thought it would be useful to have a 6tisch security draft by that meeting that could serve as baseline.

TK provided some more insight into the 802.15.4rev effort. He suggested that there would be 1-2 more letter ballots, followed by the start of sponsor ballot around end of March 2015, with anticipated conclusion of the work around July-August this year. RS commented that this schedule seemed quite aggressive, considering historical timelines of IEEE 802.15 efforts. TK mentioned that according to Bob Heile (Chair IEEE 802.15) the 802.15rev draft would only be available in the 802.15 private member area or to those people participating in person in an actual IEEE 802 meeting. Therefore, it does not seem possible to make a draft available to interested parties in the 6tisch community who did not meet those criteria (as previously suggested).

5. AOB
RS suggested to cancel the 6tisch security call of next week and reconvene two weeks from now, which was agreed upon. Next call will take place Tue Feb 10, 2015, 4.30pm EST.

RS mentioned he had received feedback from Kris Pister and Yoshi Ohba on draft-struik-6tisch-security-architectural-considerations-01 (posted January 9, 2015). Before updating the draft, he would like to see more people give this a look. He invited people to use the now cancelled slot of next week's call to review this draft...

[call ended @9.23am EST]


On 1/26/2015 12:15 PM, Rene Struik wrote:
Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue January 27, 2015, 9am EST. I expect this to be a short call.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) prep for IETF-92 in Dallas
3) AOB

The dial-in info is below.

Best regards, Rene

B) Dial-in information:
English : New York Time 6tisch security
Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00)
Meeting number:   641 709 118
Meeting password: joinjoin
Audio connection:
      1-877-668-4493 Call-in toll free number (US/Canada)
      1-650-479-3208 Call-in toll number (US/Canada)

Access code: 641 709 118
Meeting link:
        https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6

The etherpad we have used is at:
       http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt


On 1/21/2015 10:30 AM, Rene Struik wrote:
Dear colleagues:

Giuseppe Piro offered to give a presentation on MAC security aspects, resulting in the updated agenda below. Dial-in info at bottom of email.

Remember: 6tisch security call is now tomorrow, Thu Jan 21, 2015, 1pm EST, with duration not to exceed one hour. Please call-in on time and test your speaker/mike beforehand.

Suggested updated agenda:
1) administrativia {agenda bashing/minutes} [4 min]
2) 6tisch security conf call schedule moving forward [1 min]
3) input 6tisch security to architecture draft [15 min]
-- RS to present result homework assignment of last call
4) presentation Giuseppe Piro re MAC security [30 min]
5) prep for IETF-92 in Dallas [10 min]
5) AOB

Link to suggested text (item #3 above):
https://drive.google.com/file/d/0B2a6Ilxu1XfCbVhfd0ZONXoxc00/view?usp=sharing

On 1/20/2015 4:54 PM, Rene Struik wrote:
Dear colleagues:

Due to connectivity problems, those on the 6tisch security call today concluded that it was best to reschedule the call.

The rescheduled 6tisch security call will take place this Thursday, January 22, 2015, 1-2pm EST.
(Please note that this is only once; schedule moving forward will otherwise remain the same)

Agenda and dial-in info remain the same (please scroll down).

Best regards, Rene


On 1/20/2015 4:35 PM, Rene Struik wrote:
I posted the document on Google drive, see weblink below.

https://drive.google.com/file/d/0B2a6Ilxu1XfCa3RyZzlZb3RRREk/view?usp=sharing

On 1/20/2015 1:13 AM, Rene Struik wrote:
Dear colleagues:

Please find attached my analysis of the three text proposals. I hope this helps in zooming in on consensus text.

I will present this in more detail as item #3 on the agenda for the 6tisch security call of tomorrow, Tue Jan 20, 2015, 4.30pm EST.

We can discuss this in more detail during that call (I won't have much time beforehand).

Best regards, Rene

[excerpt of minutes of 6tisch security conf call as of January 14, 2015, 11am-12pm EST]
TW asked whether RS could review the three text proposals currently on the table and suggest a way forward that takes into account consensus and what was discussed during the call. RS agreed to take this on as homework assignment, with target to report back on this to the group by the end of Monday next week (January 19, 2015).

On 1/19/2015 2:20 PM, Rene Struik wrote:
Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue January 20, 2015, 4.30-5.30pm EST.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) 6tisch security conf call schedule moving forward
3) input 6tisch security to architecture draft
-- RS to present result homework assignment of last call
4) prep for IETF-92 in Dallas
5) AOB

For dial-in info, please see bottom of this email.

As to item #2 above, if you wish to weigh-in, please do respond to the Doodle poll by end of *today*, see https://doodle.com/q63844gqd59urrae.

Best regards, Rene

-------- Forwarded Message --------
Subject: reminder -- 6tisch security call *tomorrow*, Wed Jan 14, 2015, 11am EST (dial-in info at bottom)
Date: Tue, 13 Jan 2015 19:37:04 -0500
From: Rene Struik <rstruik.ext@gmail.com>
To: tisch-security <6tisch-security@ietf.org>


Dear colleagues:

Just a quick reminder that we *do* have a conf call tomorrow, Wed Jan 14, 2015, 11am EST.

Currently, the main agenda item is item #4b of last week: input to the 6tisch architecture draft. It would also be good to have some more comments on the draft I posted.

Minutes of calls later tonight (sorry - extremely busy). For conf call dial-in info, see bottom of email.

Best regards, Rene

==
Note: next week's call is on Wed Jan 14, 2015, 11am EST.

On 1/6/2015 11:48 AM, Rene Struik wrote:
Dear colleagues:

Happy New Year!

According to the agreed-upon 6tisch security conf call schedule, we will resume the conference call series today, Tue Jan 6, 2015, 5pm EST.

I propose we continue the discussion where we left off prior to Christmas (essentially, item 3c below), except that we may have a short presentation first (item #2).

Agenda:
1) administrativia {agenda bashing/minutes}
2) {still to be confirmed} presentation Giuseppe Piro
3) join protocol details
-- a) (done) status update MAC behavior
-- b) (brief!) recap of routing/communication flow aspects
-- c) incremental deployment aspects
4) input 6tisch security to other 6tisch documents
-- a) terminology draft
-- b) architecture draft

Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris time. {The next call, on January 6, 2014) is also at 5pm EST (see schedule till half of January 2015)}.
Note: next week's call is on Wed Jan 14, 2015, 11am EST.

Dial-in info at end of this email.

Best regards,

Rene

-------- Forwarded Message --------
Subject: Suggested agenda for 6tisch security call of *today*, Tue December 16, 2014, 5pm EST (dial-in info at bottom)
Date: Tue, 16 Dec 2014 09:21:20 -0500
From: Rene Struik <rstruik.ext@gmail.com>
To: tisch-security <6tisch-security@ietf.org>


Dear colleagues:

I propose we continue the discussion where we left off last week.

Agenda:
1) administrativia {agenda bashing/minutes}
2) join protocol details
-- a) (brief!) status update MAC behavior
-- b) continuation of routing/communication flow aspects {last week, we did not finish the only two slides on this
3) input 6tisch security to other 6tisch documents

Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris time. {The next call, on January 6, 2014) is also at 5pm EST (see schedule till half of January 2015)}.

Dial-in info at end of this email.

Best regards,

Rene

-------- Forwarded Message --------
Subject: suggested agenda for 6tisch security call of tomorrow, Tue December 9, 2014, 9am EST (dial-in info at bottom)
Date: Mon, 08 Dec 2014 17:16:40 -0500
From: Rene Struik <rstruik.ext@gmail.com>
To: tisch-security <6tisch-security@ietf.org>


Dear colleagues:

For last week's Tue Dec 2, 2014, 9am EST conf call I prepared some material and posted prior to the call. During the call, we discussed all MAC-related aspects relevant for the join protocol and did not discuss higher-layer aspects I prepared material for yet. I suggest we continue the systematic discussion of last week and take that topic on now.

This leads to the following suggested agenda for this week (essentially a continuation of last week's one):

Same as last week's, except with
#1a-b) focus on routing/communication flow related aspects join protocol;
#2a): confirm concensus on MAC (as discussed last week) and routing/communication flow aspects
#2c) {as consequence of two items above} what to squeeze into architecture draft

The detailed agenda and dial-in info is below (#A, resp. #B).

Best regards, Rene

A) Suggested agenda Tue Dec 9, 2014, 9am EST call

Proposed agenda:

0) Agenda bashing

1) Join protocol details
a) desired properties
b) realizable properties

#1a-b) focus on routing/communication flow related aspects join protocol (we discussed MAC-related join-relevant aspects during the conf call of Tue Dec 2, 2014, 9am EST).
For slides, see https://drive.google.com/folderview?id=0B2a6Ilxu1XfCNF9JaXR1ZXlzZlU&usp=sharing (same slides as sent out prior to Dec 2, 2014, 9am EST call)
Relevant slides: Slides 23-25 (contained in entire slide deck (ppt), but also in excerpt (pdf))
2) Next steps:
        a) consensus on 1#a and 1#b
#2a): confirm consensus on MAC (as discussed last week) and routing/communication flow aspects
#2c) {as consequence of two items above} what to squeeze into architecture draft
        b) form tiger team to work out details
            - project phases
            - communication of sub-results
        c) what to squeeze into architecture draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call.

B) Dial-in information:
English : New York Time 6tisch security
Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00)
Meeting number:   641 709 118
Meeting password: joinjoin
Audio connection:
      1-877-668-4493 Call-in toll free number (US/Canada)
      1-650-479-3208 Call-in toll number (US/Canada)

Access code: 641 709 118
Meeting link:
        https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6

The etherpad we have used is at:
       http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363






-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363




-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


--------------000703000400030400000204-- From nobody Mon Feb 23 12:59:08 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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>, Brian E Carpenter , "anima@ietf.org" Subject: Re: [6tisch-security] [6lo] [Anima] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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 Tue Feb 24 08:09:09 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: X-Mailman-Approved-At: Tue, 24 Feb 2015 08:09:05 -0800 Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "anima@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [6tisch-security] [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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:15 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: [6tisch-security] [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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:32 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: [6tisch-security] [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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:29 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: [6tisch-security] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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:29 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: [6tisch-security] Device vs network bootstrapping [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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:44 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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>, Brian E Carpenter , "anima@ietf.org" Subject: Re: [6tisch-security] [6lo] [Anima] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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:06 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: [6tisch-security] Thread [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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 22:18:27 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: [6tisch-security] [6lo] Device vs network bootstrapping [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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:12 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: [6tisch-security] [6lo] [Anima] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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 09:47:26 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6901A1B0D; Thu, 26 Feb 2015 09:47:24 -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 dpmSOeoRrfm6; Thu, 26 Feb 2015 09:47:23 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298121A1E0B; Thu, 26 Feb 2015 09:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=402; q=dns/txt; s=iport; t=1424972843; x=1426182443; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/Eu8m4YI91vvqX+8PqyJZzQEt76vvV/isISZFtXlFjU=; b=Pk02cKVjD2Rxyy4xFRReyvn9aHhaCJietTA9ZIQjpX6wfgzbY0ocPKQC Bt/GGhwi2uiJFoy8d364L5/rdsn+YuEfrCjFiYQeuerVV+cdKVUic6hL+ XLnVJZ4e8W6iFlMwTeZS06/N1/eZjt4iUVOuGYeE4zgWJMd1nxfwdNUDc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BXBQA0W+9U/xbLJq1bg1RavBCFeYVuAoFxAQEBAQEBfIQQAQECAjhAARALGAkWBAsJAwIBAgFFBgEMAQcBAYgrDcQHkxMBAQEBAQEBAQEBAQEBAQEBAQEBARiLE4RuB4QrAQSKWI5chmmMYCOCAhwUgVogMQGCQgEBAQ X-IronPort-AV: E=Sophos;i="5.09,653,1418083200"; d="scan'208";a="357426570" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 26 Feb 2015 17:47:21 +0000 Received: from [10.131.65.104] (dhcp-10-131-65-104.cisco.com [10.131.65.104]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1QHlKVB017860; Thu, 26 Feb 2015 17:47:20 GMT Message-ID: <54EF5C27.1040400@cisco.com> Date: Thu, 26 Feb 2015 12:47:19 -0500 From: Paul Duffy Organization: Cisco Systems 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 , 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> <54EB4F24.7030609@gmx.net> In-Reply-To: <54EB4F24.7030609@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Michael Richardson , "Hedanping \(Ana\)" , anima@ietf.org, 6tisch-security@ietf.org, robert.cragie@gridmerge.com Subject: Re: [6tisch-security] [6lo] [Anima] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: paduffy@cisco.com List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 17:47:25 -0000 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 From nobody Thu Feb 26 11:23:45 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: [6tisch-security] [6lo] Device vs network bootstrapping [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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:40 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: [6tisch-security] [Anima] [6lo] Device vs network bootstrapping [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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:32:02 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8981E1A88D9 for <6tisch-security@ietfa.amsl.com>; Thu, 26 Feb 2015 14:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 ly4UOmCgaa4n for <6tisch-security@ietfa.amsl.com>; Thu, 26 Feb 2015 14:31:59 -0800 (PST) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (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 3DEED1A1A66 for <6tisch-security@ietf.org>; Thu, 26 Feb 2015 14:31:59 -0800 (PST) Received: by pdjy10 with SMTP id y10so16227623pdj.6 for <6tisch-security@ietf.org>; Thu, 26 Feb 2015 14:31:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HUzJsfaOYNjZOzkrJsLQ9nWA68bfmeASgy6Widc4vh8=; b=JlkbFZzJxmjKt0wYMkp6uM80btDC6hem3E5jcLrzCqHtrURzAMrUU7gb5HvHVCDmtP Et1mfLpdYWHkRaHEQPWBPr/mODa691a8oycIob2KTU0CdAh74oxg5DBdP9U7TrOXOYDn LGS7eziaR/qkHj6A/IfDDaM07tNX5EP02PE2kz3o616txDArkOoS1HtY42l88NVgy2yB R1R3NGfPVE27Hw+fdTawdJ3GzGXRba9+SvIJ2LaKWKbs7oq7yvX7LgSfL1i6LX0FcgP1 VsZMZ8cNEzTmk0tX3ptCYQ6dPHmMMxHq3c0ZjJV1sugaalVb30Kn+wYfcy7wwLIgf8ox aOqg== X-Gm-Message-State: ALoCoQmp08/y8RvaFgAfIT+gpA5isuN0b7SDv2XtY23f3DD00YX1D4FqPImJha+Zotr7dqP/S6vu X-Received: by 10.68.206.72 with SMTP id lm8mr18473518pbc.15.1424989918900; Thu, 26 Feb 2015 14:31:58 -0800 (PST) Received: from [10.70.48.35] ([207.140.31.138]) by mx.google.com with ESMTPSA id ny1sm1914368pbb.77.2015.02.26.14.31.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Feb 2015 14:31:58 -0800 (PST) Message-ID: <54EF9EDF.2090508@berkeley.edu> Date: Thu, 26 Feb 2015 14:31:59 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Brian E Carpenter , "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> In-Reply-To: <54EF72BF.3070603@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed 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: [6tisch-security] [6lo] Device vs network bootstrapping [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 22:32:01 -0000 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. 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 From nobody Thu Feb 26 14:32:52 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03921A8877 for <6tisch-security@ietfa.amsl.com>; Thu, 26 Feb 2015 14:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 7iABtOYG2cmN for <6tisch-security@ietfa.amsl.com>; Thu, 26 Feb 2015 14:32:49 -0800 (PST) Received: from p02c12o141.mxlogic.net (p02c12o141.mxlogic.net [208.65.145.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D070E1A1A66 for <6tisch-security@ietf.org>; Thu, 26 Feb 2015 14:32:48 -0800 (PST) Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c12o141.mxlogic.net(mxl_mta-8.2.0-3) with ESMTP id c0f9fe45.0.28268.00-304.78570.p02c12o141.mxlogic.net (envelope-from ); Thu, 26 Feb 2015 15:32:48 -0700 (MST) X-MXL-Hash: 54ef9f1026de2b90-249c34ef6afe50a189761d9c21959977fee9fa64 Received: from jsimonmacmini.engineering.linear.com (unknown [10.70.48.25]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 42F19740B1 for <6tisch-security@ietf.org>; Thu, 26 Feb 2015 14:32:42 -0800 (PST) From: Jonathan Simon Content-Type: multipart/signed; boundary="Apple-Mail=_65FB15EB-B52C-4643-AA51-95B99D617530"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 26 Feb 2015 14:32:43 -0800 References: <6F75DB38-6A96-41D5-9D78-AA2ADAF113A4@gmail.com> To: tisch-security <6tisch-security@ietf.org> Message-Id: <5DA4C214-97BF-4684-8E4C-13FEAFD60E05@linear.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AnalysisOut: [v=2.1 cv=K/02HkmI c=1 sm=1 tr=0 a=glloKNylpeYNumXQcclYyA==] X-AnalysisOut: [:117 a=glloKNylpeYNumXQcclYyA==:17 a=BLceEmwcHowA:10 a=MqD] X-AnalysisOut: [INYqSAAAA:8 a=YlVTAMxIAAAA:8 a=0HtSIViG9nkA:10 a=fOzni58Ne] X-AnalysisOut: [beTivbqhOUA:9 a=pILNOxqGKmIA:10 a=wnW1yHZy2Ee0waGq:21 a=_W] X-AnalysisOut: [_S_7VecoQA:10 a=NPI4PQ6hFa3hbkAUJZsA:9 a=ZVk8-NSrHBgA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2015022615); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [12.218.215.72] Archived-At: Subject: [6tisch-security] Security group goals X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 22:32:50 -0000 --Apple-Mail=_65FB15EB-B52C-4643-AA51-95B99D617530 Content-Type: multipart/alternative; boundary="Apple-Mail=_555F0683-1956-4BF4-A2DE-816D1CA6777C" --Apple-Mail=_555F0683-1956-4BF4-A2DE-816D1CA6777C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 So just to restate the problem I think we=92re trying to solve: Goal: We want to specify what is needed to get a new device=92s 6TOP = layer securely configured such that it can participate in a 6TiSCH = network. =20 The bulk of the discussion to date seems to focus on how to determine = whether the device should be allowed to be on the 6TiSCH network. What = is the minimal (i.e. smallest number of packets to do) set of things we = need in order to accomplish the goal? We can then build on that minimal = approach to solve more domain specific problems as needed. --=20 Jonathan Simon --Apple-Mail=_555F0683-1956-4BF4-A2DE-816D1CA6777C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 So = just to restate the problem I think we=92re trying to = solve:

Goal: We want to = specify what is needed to get a new device=92s 6TOP layer securely = configured such that it can participate in a 6TiSCH network. =  

The bulk of the discussion = to date seems to focus on how to determine whether the device should be = allowed to be on the 6TiSCH network.   What is the minimal = (i.e. smallest number of packets to do) set of things we need in order = to accomplish the goal?  We can then build on that minimal approach = to solve more domain specific problems as needed.

-- 
Jonathan = Simon

= --Apple-Mail=_555F0683-1956-4BF4-A2DE-816D1CA6777C-- --Apple-Mail=_65FB15EB-B52C-4643-AA51-95B99D617530 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIBiDCCAYQw ggEpoAMCAQICAwHiQDAKBggqhkjOPQQDAjBKMRkwFwYDVQQDDBBKb25hdGhhbiBTaW1vbiAxMQsw CQYDVQQGEwJVUzEgMB4GCSqGSIb3DQEJARYRanNpbW9uQGxpbmVhci5jb20wHhcNMTUwMTA5MTgy NjI1WhcNMTYwMTA5MTgyNjI1WjBKMRkwFwYDVQQDDBBKb25hdGhhbiBTaW1vbiAxMQswCQYDVQQG EwJVUzEgMB4GCSqGSIb3DQEJARYRanNpbW9uQGxpbmVhci5jb20wWTATBgcqhkjOPQIBBggqhkjO PQMBBwNCAATk/cMZz8sYhwIeYQWKBOA1zFbrDsjl0a5uqUYpxynjUFbFHLOA0gcED6decefxLYey x5t84Quh52wqaBUr0CSBMAoGCCqGSM49BAMCA0kAMEYCIQCG7qwBSE/rQXufjLpOuqNilQUYUh1V 6XNYeffT+nJktgIhAI30apRItPgMa3uHhgbQ9Np10J7wgKERpgcXWruQguUDMYIB4DCCAdwCAQEw UTBKMRkwFwYDVQQDDBBKb25hdGhhbiBTaW1vbiAxMQswCQYDVQQGEwJVUzEgMB4GCSqGSIb3DQEJ ARYRanNpbW9uQGxpbmVhci5jb20CAwHiQDAJBgUrDgMCGgUAoIIBIzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAyMjYyMjMyNDNaMCMGCSqGSIb3DQEJBDEWBBR3 7mXPJqTasLh3fEzF9lfsOHRk2zBgBgkrBgEEAYI3EAQxUzBRMEoxGTAXBgNVBAMMEEpvbmF0aGFu IFNpbW9uIDExCzAJBgNVBAYTAlVTMSAwHgYJKoZIhvcNAQkBFhFqc2ltb25AbGluZWFyLmNvbQID AeJAMGIGCyqGSIb3DQEJEAILMVOgUTBKMRkwFwYDVQQDDBBKb25hdGhhbiBTaW1vbiAxMQswCQYD VQQGEwJVUzEgMB4GCSqGSIb3DQEJARYRanNpbW9uQGxpbmVhci5jb20CAwHiQDAJBgcqhkjOPQIB BEcwRQIgNrP0C22w2cLMfvCDAyG64nUtHminReOYIvJ9HJmKzHQCIQD3S/25t7+LCxSAVYkgalVk 0OPsX5XPTSVHs4kFBfocHAAAAAAAAA== --Apple-Mail=_65FB15EB-B52C-4643-AA51-95B99D617530-- From nobody Thu Feb 26 14:34:56 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4741A88D8 for <6tisch-security@ietfa.amsl.com>; Thu, 26 Feb 2015 14:34: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 F2ceAphwRTgh for <6tisch-security@ietfa.amsl.com>; Thu, 26 Feb 2015 14:34:52 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::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 049601A88BD for <6tisch-security@ietf.org>; Thu, 26 Feb 2015 14:34:52 -0800 (PST) Received: by wevl61 with SMTP id l61so15439308wev.2 for <6tisch-security@ietf.org>; Thu, 26 Feb 2015 14:34:50 -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=29WHpN4RsjT1aB8Etz71abWbVJBn2tSaoSbsmclVy98=; b=keBnJepvtxowucq1O0ehFFzHNAk2ro/NZhVRWVEFXmX+SZLhQbEnuokk0QGSWKkNKb VjiCmpQKySPcgmnu6CGUvkTm2+wIT96ORD3Vwr/aAT+NKFqykYrgTxQsBPK6OuI1LVQu boiQFGD1aLC6m3vF7Z1K9RAc0ntl499Hf5BXOQf4kn7SVQYWLJ/AHBgytQY2pFG4/TRu TUwoMOYg8r4dx3r2r+3dMz79nimdkhrcKLoAQG7tSzroSVsa6Euf/TcwC48jQNw0g/Yk 4i+1AKP2Ad3CmOTNTLRu1h/GPa0eVrcmDYoc8I4IbaW6+yEvLgRuZ0HCeOpVUW7uajQd FsRw== X-Received: by 10.180.87.106 with SMTP id w10mr510884wiz.62.1424990090817; Thu, 26 Feb 2015 14:34:50 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.194.82.39 with HTTP; Thu, 26 Feb 2015 14:34:30 -0800 (PST) In-Reply-To: <5DA4C214-97BF-4684-8E4C-13FEAFD60E05@linear.com> References: <6F75DB38-6A96-41D5-9D78-AA2ADAF113A4@gmail.com> <5DA4C214-97BF-4684-8E4C-13FEAFD60E05@linear.com> From: Thomas Watteyne Date: Thu, 26 Feb 2015 23:34:30 +0100 X-Google-Sender-Auth: W6wtoHGp9xGOsz05YK9Po_Rn_Wg Message-ID: To: Jonathan Simon Content-Type: multipart/alternative; boundary=f46d044402f62bf40d0510055cd8 Archived-At: Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] Security group goals X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 22:34:54 -0000 --f46d044402f62bf40d0510055cd8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 That's my understanding. On Thu, Feb 26, 2015 at 11:32 PM, Jonathan Simon wrote: > So just to restate the problem I think we=E2=80=99re trying to solve: > > Goal: We want to specify what is needed to get a new device=E2=80=99s 6TO= P layer > securely configured such that it can participate in a 6TiSCH network. > > The bulk of the discussion to date seems to focus on how to determine > whether the device should be allowed to be on the 6TiSCH network. What = is > the minimal (i.e. smallest number of packets to do) set of things we need > in order to accomplish the goal? We can then build on that minimal > approach to solve more domain specific problems as needed. > > -- > Jonathan Simon > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --f46d044402f62bf40d0510055cd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

That's my understanding.

On Thu, Feb 2= 6, 2015 at 11:32 PM, Jonathan Simon <jsimon@linear.com> wrot= e:
So= just to restate the problem I think we=E2=80=99re trying to solve:

Goal: We want to specify what is needed= to get a new device=E2=80=99s 6TOP layer securely configured such that it = can participate in a 6TiSCH network. =C2=A0

= The bulk of the discussion to date seems to focus on how to determin= e whether the device should be allowed to be on the 6TiSCH network. =C2=A0= =C2=A0What is the minimal (i.e. smallest number of packets to do) set of th= ings we need in order to accomplish the goal?=C2=A0 We can then build on th= at minimal approach to solve more domain specific problems as needed.

--=C2=A0
Jonathan Simon

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


--f46d044402f62bf40d0510055cd8-- From nobody Thu Feb 26 14:40:10 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0501A8547 for <6tisch-security@ietfa.amsl.com>; Thu, 26 Feb 2015 14:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 hgbC_i45ZX-Y for <6tisch-security@ietfa.amsl.com>; Thu, 26 Feb 2015 14:40:05 -0800 (PST) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) (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 CCBFB1A1A66 for <6tisch-security@ietf.org>; Thu, 26 Feb 2015 14:40:05 -0800 (PST) Received: by pabli10 with SMTP id li10so1443814pab.0 for <6tisch-security@ietf.org>; Thu, 26 Feb 2015 14:40:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=dnhyYvlQJ2Xkda9aTjCI1OiKWrUV/eoXbhzCntqRj7g=; b=gCPgapv0VVwlwEkj0EOF16YG8TgUddgfccsdw0LiOgin3E19FLqc6J5/odJxcXeeas 95GkxX8/+MEzsBaHnJL+55yHr7k4aUIMRocso6x/iqRNIj3HX4tUoo1+Ch3w+l+WyeQa +0eo7giTlAklvrjSbjXLwYdC+I4WVmEO6M6Mdnbi9IGQ7S05OQrcisSLeFOs9ipYsIfX jGmV22wptu1W/oeMW8hsurKh5vYIBZi6FsxSZh7kMAsDLZ/+QNdlr6H6sxYQryz3pyan nVMb5hbB2emMeVOEmZ8IMPawNAfFGKRdBS1MRQJ5eOKRa75pmXEq5ZwGS9i6OioSqyPs j4TQ== X-Gm-Message-State: ALoCoQlJSn8K5HFJw8yXJTFYO2NqfionhqBrjwY7NGor0Vi23BnUVZA3U7trpxmt7NKyTePe/uWj X-Received: by 10.70.90.9 with SMTP id bs9mr7062558pdb.137.1424990405422; Thu, 26 Feb 2015 14:40:05 -0800 (PST) Received: from [10.70.48.35] ([207.140.31.138]) by mx.google.com with ESMTPSA id a14sm1966612pbu.51.2015.02.26.14.40.04 for <6tisch-security@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Feb 2015 14:40:04 -0800 (PST) Message-ID: <54EFA0C5.4090709@berkeley.edu> Date: Thu, 26 Feb 2015 14:40:05 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: 6tisch-security@ietf.org References: <6F75DB38-6A96-41D5-9D78-AA2ADAF113A4@gmail.com> <5DA4C214-97BF-4684-8E4C-13FEAFD60E05@linear.com> In-Reply-To: <5DA4C214-97BF-4684-8E4C-13FEAFD60E05@linear.com> Content-Type: multipart/alternative; boundary="------------070204000503000202030503" Archived-At: Subject: [6tisch-security] customer requirements (Re: Security group goals) X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 22:40:08 -0000 This is a multi-part message in MIME format. --------------070204000503000202030503 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Do we have a list of requirements that we're trying to satisfy? Some that I can think of: * I have a home system. I'm happy to let anyone give/get 6tsch links because of reason X. [bad - we need to make it look like this but not be that open?] * I install fire or security sensors in office buildings. No one without specific credentials gets squat. * I am a member of IndustryConsortiumX selling home/office/industrial automation products. Anyone with ICX certs gets some minimal connectivity. The amount of connectivity might vary. Lowest connected state might be access to the Minimal draft slotted aloha slot. Higher levels can come later. ksjp On 2/26/2015 2:32 PM, Jonathan Simon wrote: > So just to restate the problem I think we’re trying to solve: > > Goal: We want to specify what is needed to get a new device’s 6TOP > layer securely configured such that it can participate in a 6TiSCH > network. > > The bulk of the discussion to date seems to focus on how to determine > whether the device should be allowed to be on the 6TiSCH network. > What is the minimal (i.e. smallest number of packets to do) set of > things we need in order to accomplish the goal? We can then build on > that minimal approach to solve more domain specific problems as needed. > > -- > Jonathan Simon > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security --------------070204000503000202030503 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Do we have a list of requirements that we're trying to satisfy?  Some that I can
think of:
* I have a home system.  I'm happy to let anyone give/get 6tsch links because of
reason X. [bad - we need to make it look like this but not be that open?]
* I install fire or security sensors in office buildings.  No one without specific
credentials gets squat.
* I am a member of IndustryConsortiumX selling home/office/industrial automation
products.  Anyone with ICX certs gets some minimal connectivity.

The amount of connectivity might vary.  Lowest connected state might be access
to the Minimal draft slotted aloha slot.  Higher levels can come later.

ksjp

On 2/26/2015 2:32 PM, Jonathan Simon wrote:
So just to restate the problem I think we’re trying to solve:

Goal: We want to specify what is needed to get a new device’s 6TOP layer securely configured such that it can participate in a 6TiSCH network.  

The bulk of the discussion to date seems to focus on how to determine whether the device should be allowed to be on the 6TiSCH network.   What is the minimal (i.e. smallest number of packets to do) set of things we need in order to accomplish the goal?  We can then build on that minimal approach to solve more domain specific problems as needed.

-- 
Jonathan Simon



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

--------------070204000503000202030503-- From nobody Thu Feb 26 14:41:57 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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 , Brian E Carpenter , "anima@ietf.org" Subject: Re: [6tisch-security] [6lo] [Anima] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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 14:45:33 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367791A0AF8 for <6tisch-security@ietfa.amsl.com>; Thu, 26 Feb 2015 14:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 bGJDhhHRR0o6 for <6tisch-security@ietfa.amsl.com>; Thu, 26 Feb 2015 14:45:30 -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 053EC1A88FE for <6tisch-security@ietf.org>; Thu, 26 Feb 2015 14:45:30 -0800 (PST) Received: by pdjp10 with SMTP id p10so16329474pdj.3 for <6tisch-security@ietf.org>; Thu, 26 Feb 2015 14:45:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=YTwEMIHgnrukjCzrSoiYkcbzzG/MuXNsDLEEO/eoJtc=; b=CQLhFi++7NShwrW9MKVlmpBgi4un24IR2h9/ZkjUpaQhgKfh6CBgLsVJ3oJQ6z54ZC jFPXp7QnNCx4B+c+5mkg5Znxfwj/XCW5DyKYdjf2GwcKIv0NLwhfHE3ay3TKja7axT3I 8O5H4llVEPMXaA8AA3/jqJlvuo1N6ceUhslxiuYen2VxRymNwGYmLKic/1P2qtEdyET9 vWZtFy/vEhS+twrlDlQ5nSOKuTvR3hW3WJ5GrCqH9SkbDvdWcSqMfmSFrS/0+pTWmFv7 1z8Gg5JTYKOY+vQ6S3wV+3nZ8mVJP729ARzaWdPzV2FstbyGvtUW7A09OZtafWabDLtP uVXA== X-Gm-Message-State: ALoCoQnc3JvX9ZHdth28/1W1pODyGFySoBA1aDCVbOYzsCYWVgGJ84B9kldzQeSuhPWUiV0XiZPm X-Received: by 10.70.130.108 with SMTP id od12mr18632871pdb.18.1424990729678; Thu, 26 Feb 2015 14:45:29 -0800 (PST) Received: from [10.70.48.35] ([207.140.31.138]) by mx.google.com with ESMTPSA id hz8sm2051193pac.5.2015.02.26.14.45.28 for <6tisch-security@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Feb 2015 14:45:28 -0800 (PST) Message-ID: <54EFA209.3090800@berkeley.edu> Date: Thu, 26 Feb 2015 14:45:29 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: 6tisch-security@ietf.org References: <6F75DB38-6A96-41D5-9D78-AA2ADAF113A4@gmail.com> <5DA4C214-97BF-4684-8E4C-13FEAFD60E05@linear.com> <54EFA0C5.4090709@berkeley.edu> In-Reply-To: <54EFA0C5.4090709@berkeley.edu> Content-Type: multipart/alternative; boundary="------------010706040708010103050304" Archived-At: Subject: Re: [6tisch-security] customer requirements (Re: Security group goals) X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 22:45:32 -0000 This is a multi-part message in MIME format. --------------010706040708010103050304 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Note that there is also a customer requirement for speed. If I'm installing a network, I may only be able to put one mote up every few minutes, and security overhead is not likely to be a problem. But when the power fails, or someone reboots the gateway, or for whatever reason the network needs to reform, then even seconds per mote is going to be an unacceptable delay for some applications. If I have 500 motes talking to a single gateway doing lighting control or process automation, I'm not going to be very happy if my security overhead causes the network to take 2000 seconds to reform. ksjp On 2/26/2015 2:40 PM, Kris Pister wrote: > Do we have a list of requirements that we're trying to satisfy? Some > that I can > think of: > * I have a home system. I'm happy to let anyone give/get 6tsch links > because of > reason X. [bad - we need to make it look like this but not be that open?] > * I install fire or security sensors in office buildings. No one > without specific > credentials gets squat. > * I am a member of IndustryConsortiumX selling home/office/industrial > automation > products. Anyone with ICX certs gets some minimal connectivity. > > The amount of connectivity might vary. Lowest connected state might > be access > to the Minimal draft slotted aloha slot. Higher levels can come later. > > ksjp > > On 2/26/2015 2:32 PM, Jonathan Simon wrote: >> So just to restate the problem I think we’re trying to solve: >> >> Goal: We want to specify what is needed to get a new device’s 6TOP >> layer securely configured such that it can participate in a 6TiSCH >> network. >> >> The bulk of the discussion to date seems to focus on how to determine >> whether the device should be allowed to be on the 6TiSCH network. >> What is the minimal (i.e. smallest number of packets to do) set of >> things we need in order to accomplish the goal? We can then build on >> that minimal approach to solve more domain specific problems as needed. >> >> -- >> Jonathan Simon >> >> >> >> _______________________________________________ >> 6tisch-security mailing list >> 6tisch-security@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch-security > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security --------------010706040708010103050304 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Note that there is also a customer requirement for speed.  If I'm installing a network,
I may only be able to put one mote up every few minutes, and security overhead
is not likely to be a problem.  But when the power fails, or someone reboots the
gateway, or for whatever reason the network needs to reform, then even seconds
per mote is going to be an unacceptable delay for some applications.
If I have 500 motes talking to a single gateway doing lighting control or process
automation, I'm not going to be very happy if my security overhead causes the
network to take 2000 seconds to reform.

ksjp

On 2/26/2015 2:40 PM, Kris Pister wrote:
Do we have a list of requirements that we're trying to satisfy?  Some that I can
think of:
* I have a home system.  I'm happy to let anyone give/get 6tsch links because of
reason X. [bad - we need to make it look like this but not be that open?]
* I install fire or security sensors in office buildings.  No one without specific
credentials gets squat.
* I am a member of IndustryConsortiumX selling home/office/industrial automation
products.  Anyone with ICX certs gets some minimal connectivity.

The amount of connectivity might vary.  Lowest connected state might be access
to the Minimal draft slotted aloha slot.  Higher levels can come later.

ksjp

On 2/26/2015 2:32 PM, Jonathan Simon wrote:
So just to restate the problem I think we’re trying to solve:

Goal: We want to specify what is needed to get a new device’s 6TOP layer securely configured such that it can participate in a 6TiSCH network.  

The bulk of the discussion to date seems to focus on how to determine whether the device should be allowed to be on the 6TiSCH network.   What is the minimal (i.e. smallest number of packets to do) set of things we need in order to accomplish the goal?  We can then build on that minimal approach to solve more domain specific problems as needed.

-- 
Jonathan Simon



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




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

--------------010706040708010103050304-- From nobody Thu Feb 26 15:02:57 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: [6tisch-security] [6lo] Device vs network bootstrapping [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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 > > From nobody Thu Feb 26 18:17:56 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4431A7007 for <6tisch-security@ietfa.amsl.com>; Thu, 26 Feb 2015 18:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 ZaX0PRn8hZSt for <6tisch-security@ietfa.amsl.com>; Thu, 26 Feb 2015 18:17:48 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001: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 A50AF1A7113 for <6tisch-security@ietf.org>; Thu, 26 Feb 2015 18:17:47 -0800 (PST) Received: by iecvy18 with SMTP id vy18so24459373iec.6 for <6tisch-security@ietf.org>; Thu, 26 Feb 2015 18:17:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=WzTWDTuy4AO5ENU5lzXHIDlmHAxk9ppdlA5fOSnMJpI=; b=FONXs66xhlxIPiN/+MYysSI4WWfPwiYLeKOvNrylCWSnl5uvT7uuld+onMDETXwylK cUmelACL8A/j3E+inL91YByAdukVAJlBY94bz0Z7LTL9SZO4rQw+rn3hl4fGo9aA3Iea HXMZjzaVhkHP2y2/qdNpZiaNs+9JCkUaSjFdjQq3mKTN25BFowS6iWWhD/hP91smkE99 ZUhnVlTZtoO/ZcbfK6AD48jhTp7J7qC7knUyZyja+opLcPVUzWJvF9ohfdmNBKG0b7f9 nZIhreyR12iKzqSsCDhYutwyCkO4vbLE8XxMznrtpZdZNL8itoo6YT3h9xnnIJRKAKrX lSMw== X-Received: by 10.43.34.137 with SMTP id ss9mr13353465icb.11.1425003466848; Thu, 26 Feb 2015 18:17:46 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id d6sm1488997iod.11.2015.02.26.18.17.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Feb 2015 18:17:46 -0800 (PST) Message-ID: <54EFD3C2.9030504@gmail.com> Date: Thu, 26 Feb 2015 21:17:38 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kris Pister , 6tisch-security@ietf.org References: <6F75DB38-6A96-41D5-9D78-AA2ADAF113A4@gmail.com> <5DA4C214-97BF-4684-8E4C-13FEAFD60E05@linear.com> <54EFA0C5.4090709@berkeley.edu> <54EFA209.3090800@berkeley.edu> In-Reply-To: <54EFA209.3090800@berkeley.edu> Content-Type: multipart/alternative; boundary="------------040403040300040209080702" Archived-At: Subject: Re: [6tisch-security] customer requirements (Re: Security group goals) X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 02:17:54 -0000 This is a multi-part message in MIME format. --------------040403040300040209080702 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Kris: From Malisa Vucinic's information, time latencies can be expected to be primarily due to communication delays due to TSCH scheduling and not so much due to computational delays. In other words, I do expect that network (re)formation cost would not materially depend on whether security is switched on or off. I do see lots of merit in having more than one server/JCE/PCE component, so as to "cut the depth of network trees" and, thereby, reduce delays (where those server components would be inter-connected via a speedier channel). Best regards, Rene [excerpt of email to 6tisch security list as of Feb 17, 2015: http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00434.html] Well, given the example on Slide 5 re DTLS with pre-shared keys, time latency is mainly driven by communication delays (due to TSCH scheduling) and computational delays are relatively marginal in comparison (the conclusion applies public-key based approaches as well). Please also see the eight month old (June 11, 2014) message with a similar conclusion:http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00153.html Best regards, Rene On 2/26/2015 5:45 PM, Kris Pister wrote: > Note that there is also a customer requirement for speed. If I'm > installing a network, > I may only be able to put one mote up every few minutes, and security > overhead > is not likely to be a problem. But when the power fails, or someone > reboots the > gateway, or for whatever reason the network needs to reform, then even > seconds > per mote is going to be an unacceptable delay for some applications. > If I have 500 motes talking to a single gateway doing lighting control > or process > automation, I'm not going to be very happy if my security overhead > causes the > network to take 2000 seconds to reform. > > ksjp > > On 2/26/2015 2:40 PM, Kris Pister wrote: >> Do we have a list of requirements that we're trying to satisfy? Some >> that I can >> think of: >> * I have a home system. I'm happy to let anyone give/get 6tsch links >> because of >> reason X. [bad - we need to make it look like this but not be that open?] >> * I install fire or security sensors in office buildings. No one >> without specific >> credentials gets squat. >> * I am a member of IndustryConsortiumX selling home/office/industrial >> automation >> products. Anyone with ICX certs gets some minimal connectivity. >> >> The amount of connectivity might vary. Lowest connected state might >> be access >> to the Minimal draft slotted aloha slot. Higher levels can come later. >> >> ksjp >> >> On 2/26/2015 2:32 PM, Jonathan Simon wrote: >>> So just to restate the problem I think we’re trying to solve: >>> >>> Goal: We want to specify what is needed to get a new device’s 6TOP >>> layer securely configured such that it can participate in a 6TiSCH >>> network. >>> >>> The bulk of the discussion to date seems to focus on how to >>> determine whether the device should be allowed to be on the 6TiSCH >>> network. What is the minimal (i.e. smallest number of packets to >>> do) set of things we need in order to accomplish the goal? We can >>> then build on that minimal approach to solve more domain specific >>> problems as needed. >>> >>> -- >>> Jonathan Simon >>> >>> >>> >>> _______________________________________________ >>> 6tisch-security mailing list >>> 6tisch-security@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch-security >> >> >> >> _______________________________________________ >> 6tisch-security mailing list >> 6tisch-security@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch-security > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------040403040300040209080702 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Kris:

From Malisa Vucinic's information, time latencies can be expected to be primarily due to communication delays due to TSCH scheduling and not so much due to computational delays. In other words, I do expect that network (re)formation cost would not materially depend on whether security is switched on or off.

I do see lots of merit in having more than one server/JCE/PCE component, so as to "cut the depth of network trees" and, thereby, reduce delays (where those server components would be inter-connected via a speedier channel).

Best regards, Rene

[excerpt of email to 6tisch security list as of Feb 17, 2015: http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00434.html]

Well, given the example on Slide 5 re DTLS with pre-shared keys, time latency is mainly driven by communication delays (due to TSCH scheduling) and computational delays are relatively marginal in comparison (the conclusion applies public-key based approaches as well). Please also see the eight month old (June 11, 2014) message with a similar conclusion: http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00153.html

Best regards, Rene

On 2/26/2015 5:45 PM, Kris Pister wrote:
Note that there is also a customer requirement for speed.  If I'm installing a network,
I may only be able to put one mote up every few minutes, and security overhead
is not likely to be a problem.  But when the power fails, or someone reboots the
gateway, or for whatever reason the network needs to reform, then even seconds
per mote is going to be an unacceptable delay for some applications.
If I have 500 motes talking to a single gateway doing lighting control or process
automation, I'm not going to be very happy if my security overhead causes the
network to take 2000 seconds to reform.

ksjp

On 2/26/2015 2:40 PM, Kris Pister wrote:
Do we have a list of requirements that we're trying to satisfy?  Some that I can
think of:
* I have a home system.  I'm happy to let anyone give/get 6tsch links because of
reason X. [bad - we need to make it look like this but not be that open?]
* I install fire or security sensors in office buildings.  No one without specific
credentials gets squat.
* I am a member of IndustryConsortiumX selling home/office/industrial automation
products.  Anyone with ICX certs gets some minimal connectivity.

The amount of connectivity might vary.  Lowest connected state might be access
to the Minimal draft slotted aloha slot.  Higher levels can come later.

ksjp

On 2/26/2015 2:32 PM, Jonathan Simon wrote:
So just to restate the problem I think we’re trying to solve:

Goal: We want to specify what is needed to get a new device’s 6TOP layer securely configured such that it can participate in a 6TiSCH network.  

The bulk of the discussion to date seems to focus on how to determine whether the device should be allowed to be on the 6TiSCH network.   What is the minimal (i.e. smallest number of packets to do) set of things we need in order to accomplish the goal?  We can then build on that minimal approach to solve more domain specific problems as needed.

-- 
Jonathan Simon



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




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




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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------040403040300040209080702-- From nobody Fri Feb 27 05:00:15 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: X-Mailman-Approved-At: Fri, 27 Feb 2015 05:00:15 -0800 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: [6tisch-security] [6lo] Thread [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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 Fri Feb 27 05:00:16 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: X-Mailman-Approved-At: Fri, 27 Feb 2015 05:00:15 -0800 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: [6tisch-security] [6lo] Thread [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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 Fri Feb 27 05:00:18 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@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: X-Mailman-Approved-At: Fri, 27 Feb 2015 05:00:15 -0800 Cc: 6tisch-security <6tisch-security@ietf.org>, consultancy@vanderstok.org, Michael Richardson , robert.cragie@gridmerge.com, sarikaya@ieee.org, 6lo@ietf.org, Hannes Tschofenig , Brian E Carpenter , anima@ietf.org Subject: Re: [6tisch-security] [6lo] [Anima] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> 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 Fri Feb 27 07:48:15 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E6A1ACD63 for <6tisch-security@ietfa.amsl.com>; Fri, 27 Feb 2015 07:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hzdC20J2DOPb for <6tisch-security@ietfa.amsl.com>; Fri, 27 Feb 2015 07:48:11 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40821ACD61 for <6tisch-security@ietf.org>; Fri, 27 Feb 2015 07:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16469; q=dns/txt; s=iport; t=1425052091; x=1426261691; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=JvKiFKptcr9XXDAJ9MfcY6UCkoRpNY5RSdF5Ehq+X2Q=; b=EIXeRkkB5KXaU9IMdAueh/w49Tqmdlz5HNQIZ4bKOhQsFZLaHqUQLTI9 /z1uCVDGemDNhDOLnmV5GltKh5mWZY7yX9fR4I/IjwcngTyrTy7n5s9F/ 2rE1iu8p2ZUjxac0sY/egzfA/ZMXlSc3kj1GIH9hO6T5k0td4vCTDvewj 8=; X-Files: smime.p7s : 4831 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CKBQBQkfBU/4ENJK1bDoIxQ1JaBL9rgiYBCYUnSQKBJE0BAQEBAQF8hA8BAQEEAQEBKkEbAgEIDgMEAQELHQcCJQsUCQgCBAESCAaIIQ3XNwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEixKBPQGCfxYXCgGDF4EUBYoshUiBYYEugmeDUZNQI4MxPW+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,660,1418083200"; d="p7s'?scan'208,217";a="396562559" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-9.cisco.com with ESMTP; 27 Feb 2015 15:48:10 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t1RFmAsQ022549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Feb 2015 15:48:10 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.159]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Fri, 27 Feb 2015 09:48:10 -0600 From: "Pascal Thubert (pthubert)" To: Kris Pister , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Thread-Topic: [6tisch-security] customer requirements (Re: Security group goals) Thread-Index: AQHQUhUuxGGNZH4kREiHEs+1XPhFe50EpG9w Date: Fri, 27 Feb 2015 15:48:07 +0000 Deferred-Delivery: Fri, 27 Feb 2015 15:48:00 +0000 Message-ID: References: <6F75DB38-6A96-41D5-9D78-AA2ADAF113A4@gmail.com> <5DA4C214-97BF-4684-8E4C-13FEAFD60E05@linear.com> <54EFA0C5.4090709@berkeley.edu> In-Reply-To: <54EFA0C5.4090709@berkeley.edu> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.192.41] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0182_01D052AD.02928140" MIME-Version: 1.0 Archived-At: Subject: Re: [6tisch-security] customer requirements (Re: Security group goals) X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 15:48:14 -0000 ------=_NextPart_000_0182_01D052AD.02928140 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0183_01D052AD.02928140" ------=_NextPart_001_0183_01D052AD.02928140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This reminds me of the security profiles we discussed at ISA100. = Multiple network with different security levels may indeed co exist. =20 With 6TiSHC, RPL builds instances that lead to gateways, which are associated to some networks and operations. So it could be cool to be able to associated cells with instances, and authorize a device in an instance, which gives it access to the = associated cells. =20 Cheers, =20 Pascal =20 From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On = Behalf Of Kris Pister Sent: jeudi 26 f=E9vrier 2015 23:40 To: 6tisch-security@ietf.org Subject: [6tisch-security] customer requirements (Re: Security group = goals) =20 Do we have a list of requirements that we're trying to satisfy? Some = that I can think of: * I have a home system. I'm happy to let anyone give/get 6tsch links because of reason X. [bad - we need to make it look like this but not be that = open?] * I install fire or security sensors in office buildings. No one = without specific credentials gets squat. * I am a member of IndustryConsortiumX selling home/office/industrial automation products. Anyone with ICX certs gets some minimal connectivity. The amount of connectivity might vary. Lowest connected state might be access to the Minimal draft slotted aloha slot. Higher levels can come later. ksjp On 2/26/2015 2:32 PM, Jonathan Simon wrote: So just to restate the problem I think we=92re trying to solve: Goal: We want to specify what is needed to get a new device=92s 6TOP = layer securely configured such that it can participate in a 6TiSCH network. =20 The bulk of the discussion to date seems to focus on how to determine whether the device should be allowed to be on the 6TiSCH network. What = is the minimal (i.e. smallest number of packets to do) set of things we = need in order to accomplish the goal? We can then build on that minimal = approach to solve more domain specific problems as needed. --=20 Jonathan Simon _______________________________________________ 6tisch-security mailing list 6tisch-security@ietf.org https://www.ietf.org/mailman/listinfo/6tisch-security =20 ------=_NextPart_001_0183_01D052AD.02928140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This reminds me of the security profiles we discussed at ISA100. = Multiple network with different security levels may indeed co = exist.

 

With 6TiSHC, RPL builds instances that lead to gateways, which are = associated to some networks and operations.

So it could be cool to be able to associated cells with instances, = and authorize a device in an instance, which gives it access to the = associated cells.

 

Cheers,

 

Pascal

 

From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On = Behalf Of Kris Pister
Sent: jeudi 26 f=E9vrier 2015 = 23:40
To: 6tisch-security@ietf.org
Subject: = [6tisch-security] customer requirements (Re: Security group = goals)

 

Do we have a list of requirements that = we're trying to satisfy?  Some that I can
think of:
* I have = a home system.  I'm happy to let anyone give/get 6tsch links = because of
reason X. [bad - we need to make it look like this but not = be that open?]
* I install fire or security sensors in office = buildings.  No one without specific
credentials gets squat.
* = I am a member of IndustryConsortiumX selling home/office/industrial = automation
products.  Anyone with ICX certs gets some minimal = connectivity.

The amount of connectivity might vary.  Lowest = connected state might be access
to the Minimal draft slotted aloha = slot.  Higher levels can come = later.

ksjp

On 2/26/2015 = 2:32 PM, Jonathan Simon wrote:

So = just to restate the problem I think we’re trying to = solve:


Goal: We want to specify what is = needed to get a new device’s 6TOP layer securely configured such = that it can participate in a 6TiSCH network.  

The bulk of the discussion to date = seems to focus on how to determine whether the device should be allowed = to be on the 6TiSCH network.   What is the minimal (i.e. = smallest number of packets to do) set of things we need in order to = accomplish the goal?  We can then build on that minimal approach to = solve more domain specific problems as needed.

-- 

Jonathan Simon





___________________=
____________________________
6tisch-security =
mailing list
6tisch-security@ietf.org
https://ww=
w.ietf.org/mailman/listinfo/6tisch-security

 

------=_NextPart_001_0183_01D052AD.02928140-- ------=_NextPart_000_0182_01D052AD.02928140 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOLTCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIErzCC A5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEyMjIwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxWpgYmt7hJ4Jbn Uavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW/qGHqS5DUkMW fK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8GsLGsk0C5tQiT OpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAtMX9ZvVI3sDNp LUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5GOld0YVC+xkA/ y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNV HQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBE BgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5h bENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2Vy dHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2ErwAkQI5kPxWZq b7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9YG+MiY5xS+LsF Nqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENumNzToe+ABEKWc yjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqGNAe5LMrmHErY mQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2ShAaJvp8ivub MIIFPDCCBCSgAwIBAgIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDMwMDAwMDBaFw0xNjAy MDMyMzU5NTlaMCMxITAfBgkqhkiG9w0BCQEWEnB0aHViZXJ0QGNpc2NvLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALTqoFHH36vHzOLhXp5Wv28HBpYWouQolX/OzHVrZbIEblHp NAxFdrnNSWULDP5gT8hp/t4P0XO3YEnaQxpPUu0wWFlLrDC690s0y3T0hATowmfycNcLX+hddBDL 8ChyZdJAVhxl0vnxORmcciJmXmWOJ+4lzEqaDbm5lZUHgi3kc0t9/IFOOJ6yq1kjttHu1MFPZZUc lUnlpXmD+2/GzxeCHlQgLvw232No6lrAS34PQxbu7rnfw25Spd3CFP7RymWZnNL26rIvt3J4rpv8 xy0EedfU3AUo5scNpr7Mb1npOgVU7N+K07atmjh71wpvfnpvwIxPA+OOHcXwOS5JsosCAwEAAaOC AfAwggHsMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBS2xFsxMSdl ViqpYN1OZcdW6Bg4OTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0G A1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgG CCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHQYDVR0RBBYwFIEScHRodWJlcnRAY2lzY28uY29tMA0GCSqGSIb3DQEBCwUA A4IBAQABMkoJZJ5HHnG3Sl0jOpl8Emhb5fjpyW2eK26Zy8e62uqUL7ExSBChD97N1lCYUFY4TqIR zCmaObFC+fDgG3IDQ7ZOJDVu6ZK8TAGiBF6sSYcg5rSfIKPxJUQvTciSrTE+XHEVONmU6xQrMIYY 4/T4iho50oQmNpTSNmGc19ZZ9mQtbRGsjdwILm5NvIyI3X088GidfVJqifQ9dRmSikzELdvlmdBs TFdAM1zx3CscylrUPQyy3lrLuvWf9arpPHV7sex+cwkLKOGHl26mXMoOPwvEYcpJJ3phmR/aqxbC mZwz4LugVrqvC0sFERLSjfarSBQxKL7XSxxS6JYEL3LpMYIEdDCCBHACAQEwgbEwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwCQYF Kw4DAhoFAKCCApcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUw MjI3MTU0NzAxWjAjBgkqhkiG9w0BCQQxFgQUcsiuqC2whKqgyMefoo5EtVXpAVUwgasGCSqGSIb3 DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwIC ASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwgcIGCSsG AQQBgjcQBDGBtDCBsTCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAiZ2uutKsTVMx1cjK8TSpgTCBxAYLKoZIhvcNAQkQAgsxgbSggbEwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcN AQEBBQAEggEArvKCK6q7971Ir623hICmF6SLOghmH8j5TU+bYKAOfsuMNylWfC8bv4802bI3yqHd 3El0slj1WiyNFO62CBL0vCkYE2+XuUrwvbN1yi0CVGidR6tsuxVOm8IuWRNNXIjDOy1LP2f8R7p6 7EjCzIgyDCvgl31N9disP5ZtYe417XF/g32Qk8Rd57jGeKncXQT/ZKWphUxxGpByCTufSTkzPsOl a4y9CaPPBKXRAomoIIuiUDz1N1DhLsiAruE7jyR68y32/qrottRLcjKWT/leKE+EsSKU4C4NIZbL HS4DjfsqVjG8r7eWe2jTQ/gUI0wcNci4N/UwzYd3KXxSFS0ARwAAAAAAAA== ------=_NextPart_000_0182_01D052AD.02928140-- From nobody Fri Feb 27 09:50:56 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8761ACEE8 for <6tisch-security@ietfa.amsl.com>; Fri, 27 Feb 2015 09:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 AzG_6Cbv5oos for <6tisch-security@ietfa.amsl.com>; Fri, 27 Feb 2015 09:50:46 -0800 (PST) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (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 CEB6C1ACEDA for <6tisch-security@ietf.org>; Fri, 27 Feb 2015 09:50:45 -0800 (PST) Received: by paceu11 with SMTP id eu11so24332049pac.7 for <6tisch-security@ietf.org>; Fri, 27 Feb 2015 09:50:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=EELzv9rSpnnt9v0zPNm5hC6h+vdak6sHBfdsoKaIYAk=; b=dWjgr1FoUGEvKQSX+/BvJd8XyYcKPmS4h1kpntH2rrle7dUzuKeDbxwwbeTtN61ovv i3Bpp2OJWL2wztIiW2bUphkmh4flaARRN+12a8KAOG0kixRuNS0RO19PoGN1KSPCCJ1z jbpLnPKAkNVjPSpTnVH3WudpovhvTYtWHFJsj1bVN6QZopzZqUJR6dSH1GiNuZqFJpAn FFHkyL50QAuxINYSOA9Q/Pi9e16mB3Bq+md9Ew6+6h7Tnwr4q9pJR1pQlIXIn2JyqfdR 7KU39TbMeCdbQKX/Wy0WHGuXxOFEenOGTARSYWMVRmfSKMhoIFtPVySxTwRognq0NFJ2 WfIQ== X-Gm-Message-State: ALoCoQnGe+s369vj7GTV9O0VxrIYUPXqX4leGjDha0rApbY5EZa+GQDSyYnfVI4Dqoz/cgXGqD/m X-Received: by 10.68.189.105 with SMTP id gh9mr25530315pbc.142.1425059445518; Fri, 27 Feb 2015 09:50:45 -0800 (PST) Received: from [128.32.32.89] (dhcp-32-89.EECS.Berkeley.EDU. [128.32.32.89]) by mx.google.com with ESMTPSA id nu10sm4608361pdb.24.2015.02.27.09.50.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Feb 2015 09:50:44 -0800 (PST) Message-ID: <54F0AE74.1080806@berkeley.edu> Date: Fri, 27 Feb 2015 09:50:44 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , "6tisch-security@ietf.org" <6tisch-security@ietf.org> References: <6F75DB38-6A96-41D5-9D78-AA2ADAF113A4@gmail.com> <5DA4C214-97BF-4684-8E4C-13FEAFD60E05@linear.com> <54EFA0C5.4090709@berkeley.edu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080809040800090109040301" Archived-At: Subject: Re: [6tisch-security] customer requirements (Re: Security group goals) X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 17:50:48 -0000 This is a multi-part message in MIME format. --------------080809040800090109040301 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Pascal - I agree that it would be nice to have a very flexible way of binding L2 resources to different instances with different security properties, sort of like unix file permissions. Can we agree that this is a harder problem and we don't need to solve it right now? Certainly it is not a requirement to address the three scenarios below. ksjp On 2/27/2015 7:48 AM, Pascal Thubert (pthubert) wrote: > > This reminds me of the security profiles we discussed at ISA100. > Multiple network with different security levels may indeed co exist. > > With 6TiSHC, RPL builds instances that lead to gateways, which are > associated to some networks and operations. > > So it could be cool to be able to associated cells with instances, and > authorize a device in an instance, which gives it access to the > associated cells. > > Cheers, > > Pascal > > *From:*6tisch-security [mailto:6tisch-security-bounces@ietf.org] *On > Behalf Of *Kris Pister > *Sent:* jeudi 26 février 2015 23:40 > *To:* 6tisch-security@ietf.org > *Subject:* [6tisch-security] customer requirements (Re: Security group > goals) > > Do we have a list of requirements that we're trying to satisfy? Some > that I can > think of: > * I have a home system. I'm happy to let anyone give/get 6tsch links > because of > reason X. [bad - we need to make it look like this but not be that open?] > * I install fire or security sensors in office buildings. No one > without specific > credentials gets squat. > * I am a member of IndustryConsortiumX selling home/office/industrial > automation > products. Anyone with ICX certs gets some minimal connectivity. > > The amount of connectivity might vary. Lowest connected state might > be access > to the Minimal draft slotted aloha slot. Higher levels can come later. > > ksjp > > On 2/26/2015 2:32 PM, Jonathan Simon wrote: > > So just to restate the problem I think we’re trying to solve: > > > Goal: We want to specify what is needed to get a new device’s 6TOP > layer securely configured such that it can participate in a 6TiSCH > network. > > The bulk of the discussion to date seems to focus on how to > determine whether the device should be allowed to be on the 6TiSCH > network. What is the minimal (i.e. smallest number of packets to > do) set of things we need in order to accomplish the goal? We can > then build on that minimal approach to solve more domain specific > problems as needed. > > -- > > Jonathan Simon > > > > > > _______________________________________________ > > 6tisch-security mailing list > > 6tisch-security@ietf.org > > https://www.ietf.org/mailman/listinfo/6tisch-security > --------------080809040800090109040301 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Pascal - I agree that it would be nice to have a very flexible way of binding L2 resources
to different instances with different security properties, sort of like unix file permissions.

Can we agree that this is a harder problem and we don't need to solve it right now?
Certainly it is not a requirement to address the three scenarios below.

ksjp

On 2/27/2015 7:48 AM, Pascal Thubert (pthubert) wrote:

This reminds me of the security profiles we discussed at ISA100. Multiple network with different security levels may indeed co exist.

 

With 6TiSHC, RPL builds instances that lead to gateways, which are associated to some networks and operations.

So it could be cool to be able to associated cells with instances, and authorize a device in an instance, which gives it access to the associated cells.

 

Cheers,

 

Pascal

 

From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf Of Kris Pister
Sent: jeudi 26 février 2015 23:40
To: 6tisch-security@ietf.org
Subject: [6tisch-security] customer requirements (Re: Security group goals)

 

Do we have a list of requirements that we're trying to satisfy?  Some that I can
think of:
* I have a home system.  I'm happy to let anyone give/get 6tsch links because of
reason X. [bad - we need to make it look like this but not be that open?]
* I install fire or security sensors in office buildings.  No one without specific
credentials gets squat.
* I am a member of IndustryConsortiumX selling home/office/industrial automation
products.  Anyone with ICX certs gets some minimal connectivity.

The amount of connectivity might vary.  Lowest connected state might be access
to the Minimal draft slotted aloha slot.  Higher levels can come later.

ksjp

On 2/26/2015 2:32 PM, Jonathan Simon wrote:

So just to restate the problem I think we’re trying to solve:


Goal: We want to specify what is needed to get a new device’s 6TOP layer securely configured such that it can participate in a 6TiSCH network.  

The bulk of the discussion to date seems to focus on how to determine whether the device should be allowed to be on the 6TiSCH network.   What is the minimal (i.e. smallest number of packets to do) set of things we need in order to accomplish the goal?  We can then build on that minimal approach to solve more domain specific problems as needed.

-- 

Jonathan Simon





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

 


--------------080809040800090109040301-- From nobody Fri Feb 27 09:58:42 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7C71ACF04 for <6tisch-security@ietfa.amsl.com>; Fri, 27 Feb 2015 09:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9bNmmFWEs2UA for <6tisch-security@ietfa.amsl.com>; Fri, 27 Feb 2015 09:58:40 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (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 E43A51ACEEF for <6tisch-security@ietf.org>; Fri, 27 Feb 2015 09:58:39 -0800 (PST) Received: by pablj1 with SMTP id lj1so21985209pab.9 for <6tisch-security@ietf.org>; Fri, 27 Feb 2015 09:58:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3QNTj6IDuNGjxNPM2iVWfun4ljXKCpTR3zSkc38KKcc=; b=G+6WeCJAlbfn6lrObwSGvzPi/i1G9ZATMHBjWpC+b916kchnJtj8zdqDRe9sdzi26H GEdkWCbnYKmTCLJ6lOAOWelsPESkWgYu6U01zGsS3/Mi+ZSPiU1QqLgjbtHP8Iwm15p9 sWhNy6rr7EGCqtXl2g7p2WU6aMyLV5aqp+eIwV3bhWTx+wH+Q7Ko2QK3YIdzoIqf1FJ2 8LmnE+kOhElNKsSIa4i/e150Do/BPEO9nQ2hSzXe+1EXUKNUK00Nd932OVXEeb0thyTI r/nZsSTYD17uWcbWy8e9D6sT9KjI9awlmHmQB57GT5vHVkCIu7kkjEg4irKN2MJGmFBJ hrEg== X-Gm-Message-State: ALoCoQmmSVsuWVNHouNLMfbTBVKa1uBuUzuIA3pA7AQO+aAtijwTDR1xZ3Ec3t6DPjO6NUpsgWNz X-Received: by 10.66.228.132 with SMTP id si4mr15844222pac.134.1425059919603; Fri, 27 Feb 2015 09:58:39 -0800 (PST) Received: from [128.32.32.89] (dhcp-32-89.EECS.Berkeley.EDU. [128.32.32.89]) by mx.google.com with ESMTPSA id je2sm4579934pbd.44.2015.02.27.09.58.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Feb 2015 09:58:38 -0800 (PST) Message-ID: <54F0B050.3020702@berkeley.edu> Date: Fri, 27 Feb 2015 09:58:40 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Rene Struik , 6tisch-security@ietf.org References: <6F75DB38-6A96-41D5-9D78-AA2ADAF113A4@gmail.com> <5DA4C214-97BF-4684-8E4C-13FEAFD60E05@linear.com> <54EFA0C5.4090709@berkeley.edu> <54EFA209.3090800@berkeley.edu> <54EFD3C2.9030504@gmail.com> In-Reply-To: <54EFD3C2.9030504@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [6tisch-security] customer requirements (Re: Security group goals) X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 17:58:41 -0000 Rene - I'm assuming that security computational delays are zero. You are correct that latencies are primarily due to TSCH scheduling. If you can do security processing without needing any TSCH communication, then your statement below may be correct. Unfortunately, most of what I've seen proposed recently in this group will in fact require a crippling amount of TSCH traffic, and lead to literally hours of delay in network formation for large networks. If that is the only option that we give to end users, then they will in fact just switch off security. We will have failed. ksjp On 2/26/2015 6:17 PM, Rene Struik wrote: > I do expect that network (re)formation cost would not materially > depend on whether security is switched on or off. From nobody Fri Feb 27 10:40:29 2015 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0F01A1B47 for <6tisch-security@ietfa.amsl.com>; Fri, 27 Feb 2015 10: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 zRrAzFTs2RiS for <6tisch-security@ietfa.amsl.com>; Fri, 27 Feb 2015 10:40:27 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::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 E60A01A040B for <6tisch-security@ietf.org>; Fri, 27 Feb 2015 10:40:26 -0800 (PST) Received: by iecat20 with SMTP id at20so33140794iec.12 for <6tisch-security@ietf.org>; Fri, 27 Feb 2015 10:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=zQffo10BfeMViT498owGLQcaRZ6psJEU9wf0W8uacyU=; b=eulA3W3mDYBMDZeqKy0XZfHHSufd8WZBZJ/PKIj4O4WP9fGg7MGwB82tWKX/1N/NCW AOVrqqRAWH1ZXjy3zwo5rPMz24ux6OLD6mDkbb60xDsLhyl1Rwycc3K5EJfX4g43j2/l f6Ve35QlbJQQkBoX6hnd6b1FDdlet0V+elnaOGSZ5GrT4OQuK5ZCt/tHBCfBfNw3kcjf beGdAko6FglXSaSn0CO0/eZ/5n1+WXkbOP445Z08k07IMzRWXoDqy5wENRgW6afRSwwk x8zeEhmRifED/tLHOKCZjz/rV/IEp2/ghKa5kqSXNZrZmhXurVKouZWMb01h1c1BDNAs LiAA== X-Received: by 10.42.170.200 with SMTP id g8mr17063806icz.5.1425062426186; Fri, 27 Feb 2015 10:40:26 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id j128sm2726990ioe.26.2015.02.27.10.40.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Feb 2015 10:40:25 -0800 (PST) Message-ID: <54F0BA10.6090402@gmail.com> Date: Fri, 27 Feb 2015 13:40:16 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kris Pister , tisch-security <6tisch-security@ietf.org> References: <6F75DB38-6A96-41D5-9D78-AA2ADAF113A4@gmail.com> <5DA4C214-97BF-4684-8E4C-13FEAFD60E05@linear.com> <54EFA0C5.4090709@berkeley.edu> <54EFA209.3090800@berkeley.edu> <54EFD3C2.9030504@gmail.com> <54F0B050.3020702@berkeley.edu> In-Reply-To: <54F0B050.3020702@berkeley.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [6tisch-security] customer requirements (Re: Security group goals) X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 18:40:28 -0000 Hi Kris: Do you have a pointer to what triggers your concern? "Unfortunately, most of what I've seen proposed recently in this group will in fact require a crippling amount of TSCH traffic, and lead to literally hours of delay in network formation for large networks." Best regards, Rene On 2/27/2015 12:58 PM, Kris Pister wrote: > Rene - I'm assuming that security computational delays are zero. You > are correct that > latencies are primarily due to TSCH scheduling. If you can do > security processing without > needing any TSCH communication, then your statement below may be correct. > > > If that is the only option that we give to end users, then they will > in fact just switch > off security. We will have failed. > > ksjp > > On 2/26/2015 6:17 PM, Rene Struik wrote: >> I do expect that network (re)formation cost would not materially >> depend on whether security is switched on or off. > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363