[6tisch] Alvaro Retana's No Objection on draft-ietf-6tisch-minimal-security-13: (with COMMENT)

[Alvaro Retana via Datatracker <[e-mail]>]

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).