Alvaro Retana has entered the following ballot position for draft-ietf-6tisch-minimal-security-13: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a couple of important issues I want to bring up. I don't think they raise to the level of a DISCUSS, but would like to talk about them before the document is published. (1) What is the relationship between this document and rfc8180? Both documents define "minimal" operation in a 6TiSCH network. This document seems to build on rfc8180. Should it formally Update it? Should it also be a BCP? One aspect that jumps at me is the fact that both documents declare key distribution/provisioning out of scope. rfc8180 describes the behavior of a Joining Node (which I interpret to be the same as a pledge) "depending on which key(s) are pre-configured" (§4.6), but this document seems to assume only the case where the "pledge...initially...does not possess the link-layer key(s)" so that "during the join process, the pledge sends unencrypted and unauthenticated frames." (§5) Leaving key distribution/provisioning out of scope is fine, but the assumptions of the operation are not congruent. Given that rfc8180 is a BCP, then it seems that this document doesn't follow the Best Practices or maybe tries to update (?) them with this new minimal security framework. (2) Normative References §1: "This document presumes a 6TiSCH network as described by [RFC7554] and [RFC8180]." Why are these references not Normative? If the content of this document is based on the descriptions in those RFCs, I believe they should be. Also, IEEE802.15.4 seems to be important to understand in a 6TiSCH document. (3) §5: The Normative keywords in this paragraph are out of place because the specification is already made in rfc8180. IOW, there's no need to specify here what is already specified elsewhere. In an operational 6TiSCH network, all frames MUST use link-layer frame security [RFC8180]. The IEEE Std 802.15.4 security attributes MUST include frame authenticity, and MAY include frame confidentiality (i.e. encryption). _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
