Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2571120043; Fri, 11 Oct 2019 02:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 Pl_cffRbG3x5; Fri, 11 Oct 2019 02:18:06 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 3C548120020; Fri, 11 Oct 2019 02:18:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.67,283,1566856800"; d="scan'208,217";a="322384677" Received: from wifi-pro-82-179.paris.inria.fr ([128.93.82.179]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2019 11:18:03 +0200 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Message-Id: <0EEA127F-FA8F-4BA2-8ED5-1614ECAC6566@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_8B5A299D-355C-4C54-B4E9-59F20B2AAE76" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 11 Oct 2019 11:18:02 +0200 In-Reply-To: Cc: "ops-dir@ietf.org" , 6tisch <6tisch@ietf.org>, "ietf@ietf.org" , "draft-ietf-6tisch-minimal-security.all@ietf.org" To: Linda Dunbar References: <157023324915.1400.10416689027865506912@ietfa.amsl.com> <91540EE6-E74D-4ECA-9E54-9B5E35FA5937@inria.fr> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [6tisch] Opsdir last call review of draft-ietf-6tisch-minimal-security-12 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 09:18:09 -0000 --Apple-Mail=_8B5A299D-355C-4C54-B4E9-59F20B2AAE76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Linda, After a second look, I noticed that the ASN acronym only had a couple of = occurrences in the text. To address your comment, I replaced the = occurrences of =E2=80=9CASN" with the expanded version =E2=80=9Cabsolute = slot number=E2=80=9D without defining the acronym in our document. The = changes following your review can be found at: = https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/83= e751fd8c97441e0362df983dec2801b6177300 = =20 Please let me know whether I should go ahead and upload the new version = to the datatracker. Mali=C5=A1a > On 10 Oct 2019, at 18:42, Linda Dunbar = wrote: >=20 > Malisa,=20 >=20 > Thanks for the changes.=20 >=20 > I didn't realize that IEEE802.15 uses ASN for completely different = purpose than the IETF's ASN. Maybe add a note stating "this ASN is = completely different from the BGP's ASN".=20 >=20 > Linda >=20 > -----Original Message----- > From: Mali=C5=A1a Vu=C4=8Dini=C4=87 >=20 > Sent: Monday, October 07, 2019 10:39 AM > To: Linda Dunbar > > Cc: ops-dir@ietf.org ; 6tisch = <6tisch@ietf.org >; ietf@ietf.org = ; draft-ietf-6tisch-minimal-security.all@ietf.org = > Subject: Re: [6tisch] Opsdir last call review of = draft-ietf-6tisch-minimal-security-12 >=20 > Dear Linda, >=20 > Many thanks for your review. Please find the responses inline. >=20 > Kind regards, > Mali=C5=A1a >=20 >> On 5 Oct 2019, at 01:54, Linda Dunbar via Datatracker = wrote: >>=20 >> Reviewer: Linda Dunbar >> Review result: Has Nits >>=20 >> Reviewer: Linda Dunbar >> Review result: Has Nits & with comment >>=20 >> I am the assigned Ops area reviewer for this draft. The Ops=20 >> directorate reviews all IETF documents being processed by the IESG = for=20 >> the IETF Chair. Please treat these comments just like any other last = call comments. >>=20 >> This document is written very clear, specifying a framework for a new=20= >> device to securely join a 6TiSCH network. >=20 >>=20 >> One question: the document assumes that there is pre-shared key (PSK)=20= >> between the device and the controller. The Security Consideration = does=20 >> describe the common pitfall of a single PSK shared among a group of=20= >> devices. Is there any way to prevent it? Is it necessary to require=20= >> the Key to be periodically changed? >=20 > Please note that the document mandates unique PSKs between each device = and the JRC (Section 3, PSK), thus a compromise of a single device does = not leak the PSK of other devices in the network. The discussion you = refer to in the Security Consideration section makes an attempt to draw = attention to the unsafe practices, but beyond mandating the PSK to be = unique for each pledge, which is already a strong requirement, I am not = sure we can do much more about it. Requiring the PSK to be periodically = changed would require periodic in-situ manipulation of devices (by the = 100s or even 1000s), something that is not realistically going to = happen=E2=80=A6What we could do, however, is to mandate the PSK to be = changed upon device re-commissioning to a new owner, when it is likely = that a device needs to be manipulated, so I would propose the following = sentence be added at the end of Section 3, PSK: >=20 > NEW: > In case of device re-commissioning to a new owner, it is REQUIRED to = change the PSK. >=20 > Would that work? >=20 >> Another suggestion: >> Section 5.1 introduces an acronym ASN to represent "Absolute slot = number". >>=20 >> Can you use a different acronym because ASN has been widely used in=20= >> networking as the Autonomous System Number. >=20 > ASN for "Absolute slot number=E2=80=9D was defined in the IEEE = 802.15.4 specification and the acronym is widely used in our community. = I would refrain from re-defining it as it would cause confusion, given = that is already used in other documents produced by the 6TiSCH working = group (RFC8180, RFC7554). >=20 >> --- >> An autonomous system number (ASN) is a unique number that's available=20= >> globally to identify an autonomous system and which enables that=20 >> system to exchange exterior routing information with other = neighboring autonomous systems. >>=20 >> Thank you. >>=20 >> Linda Dunbar >>=20 >>=20 >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://nam03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= = .= >> ietf.org = %2Fmailman%2Flistinfo%2F6tisch&data=3D02%7C01%7Clind= a.dunbar >> %40futurewei.com = %7C4b48bea8289a448fc54308d74b3c7064%7C0fee8ff2a3b= 24018 >> = 9c753a1d5591fedc%7C1%7C1%7C637060595293959400&sdata=3DeD9OiaPzigRIqt >> 66tBC1fANtpgzVzIX2SxldjSYwsq4%3D&reserved=3D0 --Apple-Mail=_8B5A299D-355C-4C54-B4E9-59F20B2AAE76 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = Linda,

After a = second look, I noticed that the ASN acronym only had a couple of = occurrences in the text. To address your comment, I replaced the = occurrences of =E2=80=9CASN" with the expanded version =E2=80=9Cabsolute = slot number=E2=80=9D without defining the acronym in our document. The = changes following your review can be found at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security= /commits/83e751fd8c97441e0362df983dec2801b6177300 

Please let me know = whether I should go ahead and upload the new version to the = datatracker.

Mali=C5=A1a

On 10 Oct 2019, at 18:42, Linda = Dunbar <linda.dunbar@futurewei.com> wrote:

Malisa, 

Thanks for the changes. 

I didn't realize that IEEE802.15 = uses ASN for completely different purpose than the IETF's ASN. Maybe add = a note stating "this ASN is completely different from the BGP's = ASN". 

Linda

-----Original = Message-----
From: Mali=C5=A1= a Vu=C4=8Dini=C4=87 <malisa.vucinic@inria.fr> 
Sent: Monday, October 07, 2019 = 10:39 AM
To: Linda = Dunbar <linda.dunbar@futurewei.com>
Cc: ops-dir@ietf.org; 6tisch <6tisch@ietf.org>; ietf@ietf.org; draft-ietf-6tisch-minimal-security.all@ietf.org
Subject: Re: [6tisch] Opsdir = last call review of draft-ietf-6tisch-minimal-security-12

Dear Linda,

Many thanks for your review. = Please find the responses inline.

Kind regards,
Mali=C5=A1a

On 5 Oct 2019, at 01:54, Linda Dunbar = via Datatracker <noreply@ietf.org> wrote:

Reviewer: Linda Dunbar
Review result: Has = Nits

Reviewer: Linda Dunbar
Review result: Has Nits  & with comment

I am the assigned Ops area reviewer for this = draft. The Ops 
directorate reviews all IETF documents being processed by the = IESG for 
the IETF Chair.  Please treat these comments just like = any other last call comments.

This document = is written very clear, specifying a framework for a new 
device to = securely join a 6TiSCH network.


One question: the document assumes that there is pre-shared = key (PSK) 
between the device and the controller. The Security = Consideration does 
describe the common pitfall of  a single PSK shared = among a group of 
devices. Is there any way to prevent it? Is it necessary to = require 
the Key to be periodically changed?

Please note that the document mandates unique PSKs between = each device and the JRC (Section 3, PSK), thus a compromise of a single = device does not leak the PSK of other devices in the network. The = discussion you refer to in the Security Consideration section makes an = attempt to draw attention to the unsafe practices, but beyond mandating = the PSK to be unique for each pledge, which is already a strong = requirement, I am not sure we can do much more about it. Requiring the = PSK to be periodically changed would require periodic in-situ = manipulation of devices (by the 100s or even 1000s), something that is = not realistically going to happen=E2=80=A6What we could do, however, is = to mandate the PSK to be changed upon device re-commissioning to a new = owner, when it is likely that a device needs to be manipulated, so I = would propose the following sentence be added at the end of Section 3, = PSK:

NEW:
In case of device = re-commissioning to a new owner, it is REQUIRED to change the = PSK.

Would that = work?

Another=  suggestion:
Section 5.1 introduces an acronym ASN = to represent "Absolute slot number".

Can = you use a different acronym because ASN has been widely used in 
networking = as the Autonomous System Number.

ASN for "Absolute slot number=E2=80= =9D was defined in the IEEE 802.15.4 specification and the acronym is = widely used in our community. I would refrain from re-defining it as it = would cause confusion, given that is already used in other documents = produced by the 6TiSCH working group (RFC8180, RFC7554).

---
An autonomous system number (ASN) is a unique number that's = available 
globally to identify an autonomous system and which enables = that 
system to exchange exterior routing information with other = neighboring autonomous systems.

Thank = you.

Linda Dunbar


_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://nam03.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Fwww.
ietf.org%2Fmailman%2Flistinfo%2F6tisch&amp;data=3D02%7C= 01%7Clinda.dunbar
%40futurewei.com%7C4b48bea8289a448fc54308d74b3c7064%7C0fee8f= f2a3b24018
9c753a1d5591fedc%7C1%7C1%7C637060595293959400&amp;sdata=3De= D9OiaPzigRIqt
66tBC1fANtpgzVzIX2SxldjSYwsq4%3D&amp;reserved=3D0

= --Apple-Mail=_8B5A299D-355C-4C54-B4E9-59F20B2AAE76--