RE: [6tisch] Opsdir last call review of draft-ietf-6tisch-minimal-security-12

[Linda Dunbar <[e-mail]>]

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ć <[e-mail]> 
Sent: Monday, October 07, 2019 10:39 AM
To: Linda Dunbar <[e-mail]>
Cc: [e-mail]; 6tisch <[e-mail]>; [e-mail]; [e-mail]
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ša

> On 5 Oct 2019, at 01:54, Linda Dunbar via Datatracker <[e-mail]> 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
> [e-mail]
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2F6tisch&amp;data=02%7C01%7Clinda.dunbar
> %40futurewei.com%7C4b48bea8289a448fc54308d74b3c7064%7C0fee8ff2a3b24018
> 9c753a1d5591fedc%7C1%7C1%7C637060595293959400&amp;sdata=eD9OiaPzigRIqt
> 66tBC1fANtpgzVzIX2SxldjSYwsq4%3D&amp;reserved=0