| 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 “ASN" with the expanded version “absolute slot number” without defining the acronym in our document. The changes following your review can be found at:
Please let me know whether I should go ahead and upload the new version to the datatracker.
Mališa
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ša Vučinić <malisa.vucinic@xxxxxxxx> Sent: Monday, October 07, 2019 10:39 AMTo: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>Cc: ops-dir@xxxxxxxx; 6tisch <6tisch@xxxxxxxx>; ietf@xxxxxxxx; draft-ietf-6tisch-minimal-security.all@xxxxxxxxSubject: Re: [6tisch] Opsdir last call review of draft-ietf-6tisch-minimal-security-12Dear Linda,Many thanks for your review. Please find the responses inline.Kind regards,MališaOn 5 Oct 2019, at 01:54, Linda Dunbar via Datatracker <noreply@xxxxxxxx> 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…What 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” 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@xxxxxxxx
https://nam03.safelinks.protection.outlook.com/?url="">.
ietf.org%2Fmailman%2Flistinfo%2F6tisch&data="" class="">%40futurewei.com%7C4b48bea8289a448fc54308d74b3c7064%7C0fee8ff2a3b24018
9c753a1d5591fedc%7C1%7C1%7C637060595293959400&sdata=eD9OiaPzigRIqt
66tBC1fANtpgzVzIX2SxldjSYwsq4%3D&reserved=0
|
