From nobody Tue Aug 9 13:26:34 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEA112D54C for <6tisch-security@ietfa.amsl.com>; Tue, 9 Aug 2016 13:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9N3l7kh50RZz for <6tisch-security@ietfa.amsl.com>; Tue, 9 Aug 2016 13:26:30 -0700 (PDT) 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 8ACB012D87A for <6tisch-security@ietf.org>; Tue, 9 Aug 2016 13:26:30 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7785D2009E for <6tisch-security@ietf.org>; Tue, 9 Aug 2016 16:37:08 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2665A638BE for <6tisch-security@ietf.org>; Tue, 9 Aug 2016 16:26:29 -0400 (EDT) From: Michael Richardson To: 6tisch-security <6tisch-security@ietf.org> X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 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 Archived-At: Subject: [6tisch-security] upcoming design team meetings X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 09 Aug 2016 20:26:32 -0000 --=-=-= Content-Type: text/plain While I didn't plan to cancel the Wednesday morning design team meetings after IETF, I also didn't explicitely schedule them knowing vacations and post-IETF downtime... Nancy has asked if we could move the time, as she can never make the time involved due to regular physio. Same time, different day was proposed (Tuesday or Thursday). I propose to cancel the meeting on August 10 (tomorrow), but to go ahead with a meeting on August 17 (next week). (and: no meeting on August 24 either) I have been working on the document, and I will get it onto the datatracker this week. Hope you have been having a good summer. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV6o8coCLcPvd0N1lAQJZsQf5AcoLBXa6M1lvYGmSo68u32JFb58cHib2 MLdwC21/NZ6D49TcVimeuxrwqlYoslde3IATw6hOKaZ1XwY9emZ47lED7owG0NAg 7pHdhvyKAjMEHU6HXEclSPsY+0gxCic5+Q8HwwQNAAI6nz6exyvAIpGtilrSM+Yz uyIDEf58eRmvSeqd9MKVzp/plwS4mbwYibi+8DuLGPI2or3xARiPWrZNXRt5cNNM EUmWOzC4EHZQR4bcqd8QWN4+tL8cPrgfWDoG6hd2qprfWB82uTNL8cvqLWGTMEA4 hRp7kZBljIWiEodtrzF1YIehdGRkoJSI+rIQk4J3eIA8kTHwp89Rcw== =NTXF -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 10 01:09:15 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0844912D0CB for <6tisch-security@ietfa.amsl.com>; Wed, 10 Aug 2016 01:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.769 X-Spam-Level: X-Spam-Status: No, score=-15.769 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 nJ-kcuVoA9X7 for <6tisch-security@ietfa.amsl.com>; Wed, 10 Aug 2016 01:09:12 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F283112D0AC for <6tisch-security@ietf.org>; Wed, 10 Aug 2016 01:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1437; q=dns/txt; s=iport; t=1470816551; x=1472026151; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=dpo4gfOqIsy6sWk0wGFX8+L9VbAg2p8nWPfuwZbJm9I=; b=M3gOFe9EclmwMnenyfMKHvbah5rAI8sBc2lm494oRLbucsVk6IvMBUpV zi4dBOrt/5QSjqrvglFgSqUhBAhvNeKNvs7oxOeovL2XY0EgWxbmnD8RN gV3wlSHVCgENz9AZ0cgHfQDF2S9Gq5RZs3bkffqDNm9FP0JLr7kCm91mk k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAgB74KpX/4sNJK1dg0WBUge5IYF9g?= =?us-ascii?q?maDNwKBVjgUAQEBAQEBAV0nhF4BAQWBBQQCAQgRBAEBKAcyFAkIAgQBEgiIKcE?= =?us-ascii?q?/AQEBAQEBAQEBAQEBAQEBAQEBAQEdhiqETYE5AYJpAQGFdgWOUYpqAY8Ej0qMN?= =?us-ascii?q?IN3AR42ghIcgUxuhXY3fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,498,1464652800"; d="scan'208";a="139708902" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Aug 2016 08:09:11 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u7A89BkA001630 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Aug 2016 08:09:11 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 10 Aug 2016 03:09:10 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Wed, 10 Aug 2016 03:09:10 -0500 From: "Pascal Thubert (pthubert)" To: Michael Richardson , 6tisch-security <6tisch-security@ietf.org> Thread-Topic: [6tisch-security] upcoming design team meetings Thread-Index: AQHR8nxbu4oL7ItOekOOYGu+5zYijKBB1jqg Date: Wed, 10 Aug 2016 08:08:43 +0000 Deferred-Delivery: Wed, 10 Aug 2016 08:08:07 +0000 Message-ID: References: <31943.1470774389@obiwan.sandelman.ca> In-Reply-To: <31943.1470774389@obiwan.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.12] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [6tisch-security] upcoming design team meetings X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 10 Aug 2016 08:09:13 -0000 Hello Michael and all: As you point out, there's a slowdown period right now. I did not see answers to this mail and yes, it would be good to have Nancy = in. So why don't we Doodle on some new regular time, one that Nancy can join, s= tarting September? I can organize the webex, no problem there.=20 Cheers, Pascal > -----Original Message----- > From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf= Of > Michael Richardson > Sent: mardi 9 ao=FBt 2016 22:26 > To: 6tisch-security <6tisch-security@ietf.org> > Subject: [6tisch-security] upcoming design team meetings >=20 >=20 > While I didn't plan to cancel the Wednesday morning design team meetings = after > IETF, I also didn't explicitely schedule them knowing vacations and post-= IETF > downtime... Nancy has asked if we could move the time, as she can never m= ake > the time involved due to regular physio. Same time, different day was pr= oposed > (Tuesday or Thursday). >=20 > I propose to cancel the meeting on August 10 (tomorrow), but to go ahead = with > a meeting on August 17 (next week). > (and: no meeting on August 24 either) >=20 > I have been working on the document, and I will get it onto the datatrack= er this > week. Hope you have been having a good summer. >=20 > -- > Michael Richardson , Sandelman Software Works -= =3D > IPv6 IoT consulting =3D- >=20 >=20 From nobody Thu Aug 11 09:18:38 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B12112D0B4 for <6tisch-security@ietfa.amsl.com>; Thu, 11 Aug 2016 09:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.146 X-Spam-Level: X-Spam-Status: No, score=-8.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAJvxUfR3GKK for <6tisch-security@ietfa.amsl.com>; Thu, 11 Aug 2016 09:18:35 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 63A99126D74 for <6tisch-security@ietf.org>; Thu, 11 Aug 2016 09:18:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,505,1464645600"; d="scan'208,217";a="229639440" Received: from mail-yw0-f170.google.com ([209.85.161.170]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 11 Aug 2016 18:18:32 +0200 Received: by mail-yw0-f170.google.com with SMTP id r9so326939ywg.0 for <6tisch-security@ietf.org>; Thu, 11 Aug 2016 09:18:32 -0700 (PDT) X-Gm-Message-State: AEkoouuEvXQMS4DmhKNbc/muHpROZDBY1mBsCnNR+RI6efBCBlXsGE4WAv70sNBMyRpNfLRqUyyA5WfGeqCD2g== X-Received: by 10.129.105.136 with SMTP id e130mr6873346ywc.176.1470932311294; Thu, 11 Aug 2016 09:18:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.110.193 with HTTP; Thu, 11 Aug 2016 09:18:10 -0700 (PDT) In-Reply-To: References: <31943.1470774389@obiwan.sandelman.ca> From: Thomas Watteyne Date: Thu, 11 Aug 2016 09:18:10 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=001a114715eee74b660539ce1db2 Archived-At: Cc: Michael Richardson , 6tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] upcoming design team meetings X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 16:18:37 -0000 --001a114715eee74b660539ce1db2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael, Looking forward to future 6TiSCH-sec meetings. I'm just about to send out the list of 6TiSCH interim meetings. Thomas On Wed, Aug 10, 2016 at 1:08 AM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hello Michael and all: > > As you point out, there's a slowdown period right now. > I did not see answers to this mail and yes, it would be good to have Nanc= y > in. > So why don't we Doodle on some new regular time, one that Nancy can join, > starting September? > I can organize the webex, no problem there. > > Cheers, > > Pascal > > > -----Original Message----- > > From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On > Behalf Of > > Michael Richardson > > Sent: mardi 9 ao=C3=BBt 2016 22:26 > > To: 6tisch-security <6tisch-security@ietf.org> > > Subject: [6tisch-security] upcoming design team meetings > > > > > > While I didn't plan to cancel the Wednesday morning design team meeting= s > after > > IETF, I also didn't explicitely schedule them knowing vacations and > post-IETF > > downtime... Nancy has asked if we could move the time, as she can never > make > > the time involved due to regular physio. Same time, different day was > proposed > > (Tuesday or Thursday). > > > > I propose to cancel the meeting on August 10 (tomorrow), but to go ahea= d > with > > a meeting on August 17 (next week). > > (and: no meeting on August 24 either) > > > > I have been working on the document, and I will get it onto the > datatracker this > > week. Hope you have been having a good summer. > > > > -- > > Michael Richardson , Sandelman Software Works -= =3D > > IPv6 IoT consulting =3D- > > > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > --=20 _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --001a114715eee74b660539ce1db2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Michael,
Looking forward to future 6TiSCH-sec meetings= . I'm just about to send out the list of 6TiSCH interim meetings.
=
Thomas

On Wed, Aug 10, 2016 at 1:08 AM, Pascal Thubert (pthubert) <pthube= rt@cisco.com> wrote:
Hello = Michael and all:

As you point out, there's a slowdown period right now.
I did not see answers to this mail and yes, it would be good to have Nancy = in.
So why don't we Doodle on some new regular time, one that Nancy can joi= n, starting September?
I can organize the webex, no problem there.

Cheers,

Pascal

> -----Original Message-----
> From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf Of
> Michael Richardson
> Sent: mardi 9 ao=C3=BBt 2016 22:26
> To: 6tisch-security <6t= isch-security@ietf.org>
> Subject: [6tisch-security] upcoming design team meetings
>
>
> While I didn't plan to cancel the Wednesday morning design team me= etings after
> IETF, I also didn't explicitely schedule them knowing vacations an= d post-IETF
> downtime... Nancy has asked if we could move the time, as she can neve= r make
> the time involved due to regular physio.=C2=A0 Same time, different da= y was proposed
> (Tuesday or Thursday).
>
> I propose to cancel the meeting on August 10 (tomorrow), but to go ahe= ad with
> a meeting on August 17 (next week).
> (and: no meeting on August 24 either)
>
> I have been working on the document, and I will get it onto the datatr= acker this
> week.=C2=A0 Hope you have been having a good summer.
>
> --
> Michael Richardson <mcr+= IETF@sandelman.ca>, Sandelman Software Works=C2=A0 -=3D
> IPv6 IoT consulting =3D-
>
>

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



--
_______________________________________

<= div style=3D"font-size:small">Thomas Wa= tteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking= Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

_______________________= ________________
--001a114715eee74b660539ce1db2-- From nobody Thu Aug 11 09:25:21 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7846C12D605 for <6tisch-security@ietfa.amsl.com>; Thu, 11 Aug 2016 09:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.767 X-Spam-Level: X-Spam-Status: No, score=-15.767 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 LxeoukARPQOx for <6tisch-security@ietfa.amsl.com>; Thu, 11 Aug 2016 09:25:17 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3827912D155 for <6tisch-security@ietf.org>; Thu, 11 Aug 2016 09:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9534; q=dns/txt; s=iport; t=1470932717; x=1472142317; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AvMn+0chcdpV70fybZ/NjJR0wpyp06AitRNwrVLNZWA=; b=hHADyZc1sod1NYY9jtwiP9IvUaxJBMGULKnDR+vCCm5o/EdGAX46WgYn StAF+wCj//mrRs/PQUzObzIxOOh9zPrRnSfw0Fg53G96g9FORqeIwKLcp yykve+qcQbIZdCbA2AyctFU3IOSEhvyncSd/wgbJtjj5UqowO33hYIn/g Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AgCwpqxX/4MNJK1egndOVnwHtB+FB?= =?us-ascii?q?4F9JIJCgm1KAoFiOBQBAQEBAQEBXSeEXgEBBQEBbAsMBAIBCBEDAQEBKAcnCxQ?= =?us-ascii?q?JCAIEAQ0FiDEOwBQBAQEBAQEBAQEBAQEBAQEBAQEBAQEcineBOQGCaQEBOx6FH?= =?us-ascii?q?QWOUopqAY8Tj0OMNYN3AR42ghIND4FMboVBN38BAQE?= X-IronPort-AV: E=Sophos;i="5.28,505,1464652800"; d="scan'208,217";a="309642815" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Aug 2016 16:25:15 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u7BGPFaJ030986 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Aug 2016 16:25:16 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 11 Aug 2016 12:25:14 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 11 Aug 2016 12:25:14 -0400 From: "Nancy Cam-Winget (ncamwing)" To: Thomas Watteyne , "Pascal Thubert (pthubert)" Thread-Topic: [6tisch-security] upcoming design team meetings Thread-Index: AQHR8nxcDE/h38c+d0iyCtrmoTXcs6BCGueAgAIbFQD//4yggA== Date: Thu, 11 Aug 2016 16:25:13 +0000 Message-ID: References: <31943.1470774389@obiwan.sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.85.82] Content-Type: multipart/alternative; boundary="_000_D3D1F4C4184A69ncamwingciscocom_" MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , 6tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] upcoming design team meetings X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 16:25:19 -0000 --_000_D3D1F4C4184A69ncamwingciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes,, I would like to participate and didn;t have the current meetings on m= y schedule as it conflicts w/other meetings. I am out next week but should be back after Aug 23rd and can start particip= ating thereafter.... Thanks, Nancy From: 6tisch-security <6tisch-security-bounces@ietf.org> on behalf of Thomas Watteyne > Date: Thursday, August 11, 2016 at 9:18 AM To: "Pascal Thubert (pthubert)" > Cc: Michael Richardson = >, 6tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] upcoming design team meetings Michael, Looking forward to future 6TiSCH-sec meetings. I'm just about to send out t= he list of 6TiSCH interim meetings. Thomas On Wed, Aug 10, 2016 at 1:08 AM, Pascal Thubert (pthubert) > wrote: Hello Michael and all: As you point out, there's a slowdown period right now. I did not see answers to this mail and yes, it would be good to have Nancy = in. So why don't we Doodle on some new regular time, one that Nancy can join, s= tarting September? I can organize the webex, no problem there. Cheers, Pascal > -----Original Message----- > From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf Of > Michael Richardson > Sent: mardi 9 ao=FBt 2016 22:26 > To: 6tisch-security <6tisch-security@ietf.org> > Subject: [6tisch-security] upcoming design team meetings > > > While I didn't plan to cancel the Wednesday morning design team meetings = after > IETF, I also didn't explicitely schedule them knowing vacations and post-= IETF > downtime... Nancy has asked if we could move the time, as she can never m= ake > the time involved due to regular physio. Same time, different day was pr= oposed > (Tuesday or Thursday). > > I propose to cancel the meeting on August 10 (tomorrow), but to go ahead = with > a meeting on August 17 (next week). > (and: no meeting on August 24 either) > > I have been working on the document, and I will get it onto the datatrack= er this > week. Hope you have been having a good summer. > > -- > Michael Richardson = >, Sandelman Software Works -=3D > IPv6 IoT consulting =3D- > > _______________________________________________ 6tisch-security mailing list 6tisch-security@ietf.org https://www.ietf.org/mailman/listinfo/6tisch-security -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --_000_D3D1F4C4184A69ncamwingciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Yes,, I would like to participate and didn;t have the current meetings= on my schedule as it conflicts w/other meetings.
I am out next week but should be back after Aug 23rd and can start par= ticipating thereafter….

Thanks, Nancy

From: 6tisch-security <6tisch-security-bounces@ietf.o= rg> on behalf of Thomas Watteyne <thomas.watteyne@inria.fr>
Date: Thursday, August 11, 2016 at = 9:18 AM
To: "Pascal Thubert (pthubert)= " <pthubert@cisco.com>=
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, 6t= isch-security <6tisch-securi= ty@ietf.org>
Subject: Re: [6tisch-security] upco= ming design team meetings

Michael,
Looking forward to future 6TiSCH-sec meetings. I'm just about to send = out the list of 6TiSCH interim meetings.
Thomas

On Wed, Aug 10, 2016 at 1:08 AM, Pascal Thubert = (pthubert) <pthubert@cisco.com> wrote:
Hello Michael and all:

As you point out, there's a slowdown period right now.
I did not see answers to this mail and yes, it would be good to have Nancy = in.
So why don't we Doodle on some new regular time, one that Nancy can join, s= tarting September?
I can organize the webex, no problem there.

Cheers,

Pascal

> -----Original Message-----
> From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf Of
> Michael Richardson
> Sent: mardi 9 ao=FBt 2016 22:26
> To: 6tisch-security <6t= isch-security@ietf.org>
> Subject: [6tisch-security] upcoming design team meetings
>
>
> While I didn't plan to cancel the Wednesday morning design team meetin= gs after
> IETF, I also didn't explicitely schedule them knowing vacations and po= st-IETF
> downtime... Nancy has asked if we could move the time, as she can neve= r make
> the time involved due to regular physio.  Same time, different da= y was proposed
> (Tuesday or Thursday).
>
> I propose to cancel the meeting on August 10 (tomorrow), but to go ahe= ad with
> a meeting on August 17 (next week).
> (and: no meeting on August 24 either)
>
> I have been working on the document, and I will get it onto the datatr= acker this
> week.  Hope you have been having a good summer.
>
> --
> Michael Richardson <mcr&= #43;IETF@sandelman.ca>, Sandelman Software Works  -=3D
> IPv6 IoT consulting =3D-
>
>

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



--
_________= ______________________________

Thomas Wa= tteyne, PhD
Research = Scientist & Innovator, Inria
Sr Networ= king Design Eng, Linear Tech
Founder &= amp; co-lead, UC Berkeley OpenWSN
Co-chair,= IETF 6TiSCH

_________= ______________________________
 --_000_D3D1F4C4184A69ncamwingciscocom_-- From nobody Tue Aug 16 15:46:48 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835D712B05E; Tue, 16 Aug 2016 15:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-0cUgdXLXFu; Tue, 16 Aug 2016 15:46:44 -0700 (PDT) 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 F07A512D08F; Tue, 16 Aug 2016 15:46:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 083CB200A5; Tue, 16 Aug 2016 18:57:45 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EB422639DC; Tue, 16 Aug 2016 18:46:41 -0400 (EDT) From: Michael Richardson To: tisch-security <6tisch-security@ietf.org> X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 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 Archived-At: Cc: anima-bootstrap@ietf.org Subject: [6tisch-security] developments on 6tisch join scheduling X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 16 Aug 2016 22:46:46 -0000 --=-=-= Content-Type: text/plain During discussions at IETF96, it became clear that the join ordering/time sequence envisioned for 6tisch would be less possible than I thought. The bad news is that a new mechanism might be hard to actually design. The good news is that I think a new mechanism would put 6tisch join and ANIMA bootstrap almost identical. To go back, the proposal was: 1) a new pledge would send a NA with an EARO, which would turn into a DAC/DAR process up to the 6LBR. The 6LBR would let the JCE know about the new node through mechanism TBD. The new pledge would receive a NA in reply, which, for the pledge would acknowledge that they might be knocking on the right door. (A network which didn't like that node would reply in some negative fashion, which naturally could also be forged) 2) the JCE would reach out (via the proxy) to the pledge, on a schedule determined by the JCE. The JCE would control the order of joining, and since CoAP would be used with using something like: draft-wang-6tisch-6top-protocol-00 all joining nodes would remain quiet except when responding to queries from the JCE. The goal of having the pledge be passive was one of bandwidth conservation, the JCE would enroll only as many pledges as it felt it had available bandwidth in the upper parts of the MESH DODAG tree. A 6tisch network might allocate a rather small amount of bandwidth for join messages, and utilizing the bandwidth responsabily is important. That means never wasting any energy among the lower parts of the DODAG when the packets would just get dropped further upwards. In discussions, it appears that the EARO as described in draft-thubert-6lo-rfc6775-update-00 might be replaced by the Crypto-ID of draft-sarikaya-6lo-ap-nd-02, and the process is slightly different. One additional reason why the passive pledge turns out to be a problem is that the JCE does not actually know the wake/sleep schedule for the pledge. In the 6tisch case, it ought to be possible for the pledge to sync up to the schedule and so the proxy will know when it can transmit to it, but in order to keep the proxy from having to store a lot of data coming from the JCE, the JCE also needs to know the schedule out at the edge. This does not seem unsolveable, but it was an additional concern raised. Meanwhile, in ANIMA bootstrap, the initial contact is through a GRASP discovery (or DNSSD) to find a proxy. The new pledge uses the proxy to initiate an EST session using the proxy. The enrollment process in the ANIMA case is driven by the pledge, on the assumption that the ANIMA ACP has sufficient bandwidth for normal congestion control present in TCP and CoAP to deal with a limits. What is needed is a way to adjust things so that the pledges will attempt to join in a way that does not overwhelm the network, and more so, that the proxy nodes can easily police that they are doing so. So the idea is to use the ANIMA GRASP discovery mechanism to find a proxy, but in addition, in the reply, to get some kind of number to seed a backoff algorithm that causes the pledge to attempt to initiate the join process at times deterministic to the network. I'm not talking about an exponential backoff. This is where the hard part is, how to come up with a simple to describe, and simple to code algorithm which would fill up the available bandwidth, and be easily subdividable. By subdividable, I mean, if we pass 5% of the join bandwidth to proxy A, at rank 3, that it would be able to easily pass some percent of that bandwidth to a new proxy at rank 4 in a way that does not mean reconfiguring the entire mesh to delegate bandwidth. Removing the subdivable property, some simple pseudo-random number generator, with the right seed would be the right idea. A good PRNG ought to span the available time space evenly. I don't have a solution, but I'm trying to write up the requirements more clearly. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEUAwUBV7OXzoCLcPvd0N1lAQJkIwf4rXSVcoj1tFnLgqLvE17N3AbFPBlb/8iF owaPqV0zl0YfKoeYRWFc/MEjUv+yzSfR5wjJ1OzHKOFJvu9cUO7re+pwxp+ZdpbL 8supqAoU1k9TwYAHMNJy11ZSR+ztGxJhkH9vboOAQZ2sl+1ehMQfKJgBesE8dbUN FqklFmq08/SFb3D0vhMk7BFS7cNVFXmLixMNAacx5iv1jcN9UBO7dq3dThY5+JmK Kj31jt2ouRCA2IJ17wuiz0UqxXiH8DrjoFn6isId9kR/P7yQwD3kvZJTSVJgYYzi xFTP6hmxe/64akGspstNuD8j3xZ7HhoLjfnRzUwgIKoEmJgUwlLC =NZ6u -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 16 18:46:00 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAB112B064; Tue, 16 Aug 2016 18:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6U_3wyyj_vKv; Tue, 16 Aug 2016 18:45:54 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 C934212B042; Tue, 16 Aug 2016 18:45:54 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id y134so6434837pfg.3; Tue, 16 Aug 2016 18:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=9/dtC8VGTVbAt/2+E5LRjS0UjNRkTo6BDM+om1lRYnA=; b=vavtsA+09OY35tf5OGfptfAV+5JPn2VCAqQJ0w4DV5fUirc+Jz/DrKaVzEs4hSNVwD oO8pnwWmGw0LjtQqWWu/dCtcoqOdRNjzhBlHyE6p5ZpxhyZV5ELxZ1qi59T41K4+CBRn CREyuU2SxKzUvJZzZFQcxBk7ajAF8CLMoPcZo6GFYCg/WsHrDdBvX59t3+j/TvOiizLf ZZWDFDbhoHgojW2d8dbdQpE27cCiV20fH+ke+XkM9nMMJpwozjmn/xyBincGlCcoGdED Er7tNHMelzFFmPsWCQuwotfzJ/GOzpUxGS/6pTtUOXwrXDcfNIGX8YS7ySFK9EsmpeJL 9bQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=9/dtC8VGTVbAt/2+E5LRjS0UjNRkTo6BDM+om1lRYnA=; b=RSmAmdWOOPd17Ki22BERexSmf3uGfST3AiBWoPX5+IwoFfUMphspO5Zux6K27nStoq SoNPUrbPMlV+yH1Ju5CbRupY2whOtw8Rvpb2fZzAwe9HzYPMpRMfEdj6zysEokkaW/uK ELlTo2vF3lBKKd8b2I8/jd9VgCr9jqynZ/kRnQ/brgD/u5K/WtEDaODrE9/UoScfrAqY dv4TaWvKNW9gSTf45/dKwIoKrvhe4VjIn99tmiBWn+ZA4X9w4lXQ5lUJ1fpafqFWyfAe JoYn/1TmydHsn+yYAPSZvWc/dWkSAi/RgN9Qdutc2/4c3i/RJSxdcDiReesSuz69Zw7Q xhiQ== X-Gm-Message-State: AEkoouuCt4C/bZ5DBLTekS8eyvCkkvwaP6s2uj16ZbLwgIvLfyHYZoJdZsfTVOT61KsIeA== X-Received: by 10.98.222.70 with SMTP id h67mr69573320pfg.128.1471398354174; Tue, 16 Aug 2016 18:45:54 -0700 (PDT) Received: from ?IPv6:2406:e007:63aa:1:28cc:dc4c:9703:6781? ([2406:e007:63aa:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 6sm42370026pab.11.2016.08.16.18.45.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Aug 2016 18:45:53 -0700 (PDT) To: Michael Richardson , tisch-security <6tisch-security@ietf.org> References: <24944.1471387601@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <36a58fbd-22a5-7dbe-6287-5bfca0d284fd@gmail.com> Date: Wed, 17 Aug 2016 13:45:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <24944.1471387601@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: anima-bootstrap@ietf.org Subject: Re: [6tisch-security] [Anima-bootstrap] developments on 6tisch join scheduling X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 17 Aug 2016 01:45:56 -0000 > So the idea is to use the ANIMA GRASP discovery mechanism to find a proxy, > but in addition, in the reply, to get some kind of number If you are asking for *content* in a Discovery Response, you are actually asking for GRASP rapid mode (an objective included in the response message). I'm not suggesting that this is a problem. Regards Brian On 17/08/2016 10:46, Michael Richardson wrote: > > During discussions at IETF96, it became clear that the join ordering/time > sequence envisioned for 6tisch would be less possible than I thought. > The bad news is that a new mechanism might be hard to actually design. > The good news is that I think a new mechanism would put 6tisch join > and ANIMA bootstrap almost identical. > > To go back, the proposal was: > 1) a new pledge would send a NA with an EARO, which would turn into a > DAC/DAR process up to the 6LBR. The 6LBR would let the JCE know > about the new node through mechanism TBD. > The new pledge would receive a NA in reply, which, for the pledge > would acknowledge that they might be knocking on the right door. > (A network which didn't like that node would reply in some negative > fashion, which naturally could also be forged) > > 2) the JCE would reach out (via the proxy) to the pledge, on a schedule > determined by the JCE. The JCE would control the order of joining, > and since CoAP would be used with using something like: > draft-wang-6tisch-6top-protocol-00 > all joining nodes would remain quiet except when responding to > queries from the JCE. > > The goal of having the pledge be passive was one of bandwidth conservation, > the JCE would enroll only as many pledges as it felt it had available > bandwidth in the upper parts of the MESH DODAG tree. A 6tisch network might > allocate a rather small amount of bandwidth for join messages, and utilizing > the bandwidth responsabily is important. That means never wasting any energy > among the lower parts of the DODAG when the packets would just get dropped > further upwards. > > In discussions, it appears that the EARO as described in > draft-thubert-6lo-rfc6775-update-00 might be replaced by the Crypto-ID > of draft-sarikaya-6lo-ap-nd-02, and the process is slightly different. > > One additional reason why the passive pledge turns out to be a problem is > that the JCE does not actually know the wake/sleep schedule for the pledge. > In the 6tisch case, it ought to be possible for the pledge to sync up to > the schedule and so the proxy will know when it can transmit to it, but > in order to keep the proxy from having to store a lot of data coming from the > JCE, the JCE also needs to know the schedule out at the edge. This does not > seem unsolveable, but it was an additional concern raised. > > Meanwhile, in ANIMA bootstrap, the initial contact is through a GRASP > discovery (or DNSSD) to find a proxy. The new pledge uses the proxy to > initiate an EST session using the proxy. The enrollment process in the ANIMA > case is driven by the pledge, on the assumption that the ANIMA ACP has > sufficient bandwidth for normal congestion control present in TCP and CoAP to > deal with a limits. > > What is needed is a way to adjust things so that the pledges will attempt to > join in a way that does not overwhelm the network, and more so, that the proxy > nodes can easily police that they are doing so. > > So the idea is to use the ANIMA GRASP discovery mechanism to find a proxy, > but in addition, in the reply, to get some kind of number to seed a backoff > algorithm that causes the pledge to attempt to initiate the join process > at times deterministic to the network. I'm not talking about an exponential > backoff. > > This is where the hard part is, how to come up with a simple to describe, and > simple to code algorithm which would fill up the available bandwidth, and be > easily subdividable. > > By subdividable, I mean, if we pass 5% of the join bandwidth to proxy A, at > rank 3, that it would be able to easily pass some percent of that bandwidth > to a new proxy at rank 4 in a way that does not mean reconfiguring the entire > mesh to delegate bandwidth. > > Removing the subdivable property, some simple pseudo-random number generator, > with the right seed would be the right idea. A good PRNG ought to span > the available time space evenly. I don't have a solution, but I'm trying to > write up the requirements more clearly. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima-bootstrap mailing list > Anima-bootstrap@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap > From nobody Thu Aug 18 06:04:48 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3539412DDBA; Thu, 18 Aug 2016 06:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 2Hq-JE_YcIvh; Thu, 18 Aug 2016 06:04:39 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2D6212DDC8; Thu, 18 Aug 2016 06:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5694; q=dns/txt; s=iport; t=1471525473; x=1472735073; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=h+hzAOMORCB852K2G3sXMXR06UsSkCJbc2rW0KXTSDo=; b=MA6wNjPE2bfCNWsV03PWDREC9WHJhk9dEXXdC9FdYV1pf7KyPjysFvU6 FpPbAUQyKUtEjxWFbIFyijE1jGCMSXj6ER09BzibYKhpIueMd8PI45or+ 3FDxydSW4rebhYYzawqrOlxdwMHUGQuP7sAHln3LBD9y0ckDqs8qH4Pdo Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AgDdsbVX/4gNJK1dg0OBUge3V4F9g?= =?us-ascii?q?maDNwKBbTgUAgEBAQEBAQFeJ4ReAQEFeQwEAgEIEQQBASgHMhQJCAIEAQ0FCBI?= =?us-ascii?q?BiBa8BwEBAQEBAQEBAQEBAQEBAQEBAQEBARyGKoRNgTkBgmOFfgWOVopuAYkeh?= =?us-ascii?q?XiBco1ehmeFVIN3AR42g3puhWlFfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,539,1464652800"; d="scan'208";a="139223293" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Aug 2016 13:04:32 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u7ID4Wgu015660 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Aug 2016 13:04:32 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 18 Aug 2016 08:04:31 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Thu, 18 Aug 2016 08:04:31 -0500 From: "Pascal Thubert (pthubert)" To: Michael Richardson , tisch-security <6tisch-security@ietf.org> Thread-Topic: [6tisch-security] developments on 6tisch join scheduling Thread-Index: AQHR+BAV/+KBXOtlnU+yNvEKrwkQAKBOrVlw Date: Thu, 18 Aug 2016 13:04:17 +0000 Deferred-Delivery: Thu, 18 Aug 2016 13:03:59 +0000 Message-ID: <1ed0a6c6bbbe481fab1bc1c6e36c53d2@XCH-RCD-001.cisco.com> References: <24944.1471387601@obiwan.sandelman.ca> In-Reply-To: <24944.1471387601@obiwan.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.28] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "anima-bootstrap@ietf.org" Subject: Re: [6tisch-security] developments on 6tisch join scheduling X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 18 Aug 2016 13:04:43 -0000 Hello Michael About your subdivision: One may note that to root sees it all, and it the ultimate limit of the ban= dwidth that may be given to join process.=20 The bigger the network the slower a given JA can accept new joins. And the = deeper the JA, the more overall resources will be consumed by a join. Since this is dynamic and dependent on the network, it may be that we need = the root to provide JAs with a MTBJ (mean time between joins) that depends = on the rank or something. We can wonder if the root itself could be the proxy, being triggered by a D= AR message as you described. The root can afford to maintain an EST session= . The root would arbitrate when that request is being served. And that the ro= ot may instruct in the DAC when the device is entitled to continue its join= process. For this purpose, the DIO may contain new information about root capabiliti= es in the DODAG Configuration option.=20 Cheers, Pascal > -----Original Message----- > From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf= Of > Michael Richardson > Sent: mercredi 17 ao=FBt 2016 00:47 > To: tisch-security <6tisch-security@ietf.org> > Cc: anima-bootstrap@ietf.org > Subject: [6tisch-security] developments on 6tisch join scheduling >=20 >=20 > During discussions at IETF96, it became clear that the join ordering/time > sequence envisioned for 6tisch would be less possible than I thought. > The bad news is that a new mechanism might be hard to actually design. > The good news is that I think a new mechanism would put 6tisch join and A= NIMA > bootstrap almost identical. >=20 > To go back, the proposal was: > 1) a new pledge would send a NA with an EARO, which would turn into a > DAC/DAR process up to the 6LBR. The 6LBR would let the JCE know > about the new node through mechanism TBD. > The new pledge would receive a NA in reply, which, for the pledge > would acknowledge that they might be knocking on the right door. > (A network which didn't like that node would reply in some negative > fashion, which naturally could also be forged) >=20 > 2) the JCE would reach out (via the proxy) to the pledge, on a schedule > determined by the JCE. The JCE would control the order of joining, > and since CoAP would be used with using something like: > draft-wang-6tisch-6top-protocol-00 > all joining nodes would remain quiet except when responding to > queries from the JCE. >=20 > The goal of having the pledge be passive was one of bandwidth conservatio= n, > the JCE would enroll only as many pledges as it felt it had available ban= dwidth in > the upper parts of the MESH DODAG tree. A 6tisch network might allocate = a > rather small amount of bandwidth for join messages, and utilizing the ban= dwidth > responsabily is important. That means never wasting any energy among the > lower parts of the DODAG when the packets would just get dropped further > upwards. >=20 > In discussions, it appears that the EARO as described in > draft-thubert-6lo-rfc6775-update-00 might be replaced by the Crypto-ID of > draft-sarikaya-6lo-ap-nd-02, and the process is slightly different. >=20 > One additional reason why the passive pledge turns out to be a problem is= that > the JCE does not actually know the wake/sleep schedule for the pledge. > In the 6tisch case, it ought to be possible for the pledge to sync up to = the > schedule and so the proxy will know when it can transmit to it, but in or= der to > keep the proxy from having to store a lot of data coming from the JCE, th= e JCE > also needs to know the schedule out at the edge. This does not seem > unsolveable, but it was an additional concern raised. >=20 > Meanwhile, in ANIMA bootstrap, the initial contact is through a GRASP dis= covery > (or DNSSD) to find a proxy. The new pledge uses the proxy to initiate an= EST > session using the proxy. The enrollment process in the ANIMA case is dri= ven by > the pledge, on the assumption that the ANIMA ACP has sufficient bandwidth= for > normal congestion control present in TCP and CoAP to deal with a limits. >=20 > What is needed is a way to adjust things so that the pledges will attempt= to join > in a way that does not overwhelm the network, and more so, that the proxy > nodes can easily police that they are doing so. >=20 > So the idea is to use the ANIMA GRASP discovery mechanism to find a proxy= , but > in addition, in the reply, to get some kind of number to seed a backoff a= lgorithm > that causes the pledge to attempt to initiate the join process at times > deterministic to the network. I'm not talking about an exponential backo= ff. >=20 > This is where the hard part is, how to come up with a simple to describe,= and > simple to code algorithm which would fill up the available bandwidth, and= be > easily subdividable. >=20 > By subdividable, I mean, if we pass 5% of the join bandwidth to proxy A, = at rank > 3, that it would be able to easily pass some percent of that bandwidth to= a new > proxy at rank 4 in a way that does not mean reconfiguring the entire mesh= to > delegate bandwidth. >=20 > Removing the subdivable property, some simple pseudo-random number > generator, > with the right seed would be the right idea. A good PRNG ought to span > the available time space evenly. I don't have a solution, but I'm trying= to write > up the requirements more clearly. >=20 > -- > Michael Richardson , Sandelman Software Works -= =3D > IPv6 IoT consulting =3D- >=20 >=20