[6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-24: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-6tisch-architecture-24: 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-architecture/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Why are both Section 3.4 and Section 4.4 needed?  Both appear to explain the
four scheduling mechanisms.  Section 4.4. appears to have more details.

** Section 3.6. Per the summary table in this section, what is the routing
technique “reactive P2P”.  It doesn’t appear to be explained in the text above.

** Section 3.6.  Per the “Hop-by-Hop  (TBD)” in the scheduling column in the
summary table, to what does the “TBD”?

** Section 6.  In reviewing the Security Considerations section, there is a
substantial amount of technical detail (thank you!).  However, despite this
detail, understanding the overall security properties of the architecture and
associate implementations mechanisms used by the architecture was challenging
for me.  Specifically, if 6TiSCH “is subject to the observations in section 5
of [I-D.ietf-detnet-architecture]”, then per [I-D.ietf-detnet-architecture] it
should provide “confidentiality of data traversing the DetNet”, “authentication
and authorization … for each connected device”, availability, and precision
timing. The text needs to be clearer on how those properties are realized, and
if there are residual threat.  My recommended way to realize this clarity is
restructure the text into blocks around the relevant security properties and
explicitly state the property as an introduction.  A few additional points:

-- Per precision timing, the text in this section says “measures must be taken
to protect the time synchronization, and for 6TiSCH this includes ensuring that
the Absolute Slot Number (ASN), which is used as ever incrementing counter for
the computation of the Link-Layer security nonce, is not compromised, more
below on this.”  In the subsequent text there is “[t]he standard [IEEE802154]
assumes that the ASN is distributed securely by other means.  The ASN is not
passed explicitly in the data frames”.  To confirm, is this the intended
guidance on avoiding “compromising” the ASN – distribute it out of band and
don’t pass it in the data frame?

-- Per confidentiality (but it is really more than that), a series of security
mechanisms/assumptions are inherited from [IEEE Std. 802.15.4] around
link-layer security. They need to be explicitly stated (i.e., confidentiality,
authenticity, with what crypto, relative to whom, etc.).  The operational
details of key management has no treatment.

-- Per availability, the text notes “communication with the PCE must be secured
and protected against DoS”.  Secured how?

** Section 6.  Per “Section 9 of [RFC8453] applies equally to 6TiSCH”, this
reference organizes threats and mitigations around the CMI and MPI interfaces. 
What is the analog to those in this architecture?

** Section 6.  Please provide a citation for “CCM*”

** Editorial
-- Section 3.1. Typo. s/an homogenous/a homogenous/

-- Section 3.5. Typo. s/[RFC6550]is/[RFC6550] is/

-- Section 3.6. Typo. s/A central/a central/

-- Section 3.6. Typo.  s/an hybrid/a hybrid/

-- Section 3.7.  The paragraph starting with “The reference stack that the
6TiSCH architecture presents …” doesn’t seem to add any clarity.

-- Section 4.2.1. Typo.  s/(JP):/(JP),/

-- Section 4.2.2.  Typo. /ND ot the/ND to the/

-- Section 4.3.1.1. Typo. s/are are/are/

-- Section 4.3.1.1. Duplicate phrase.  “added/moved/deleted, in which case 6top
can only act as instructed,” appears twice.

-- Section 4.3.5.  Typo.  s/an height/a height/