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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Roman:

Many thanks for your review, your time is much appreciated.

Please see below:

> 
> ----------------------------------------------------------------------
> 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 is a high level architecture, section 4 a low level. Having both in 1 document was  a conscious decision since the early review by Ralph. We split in a high and a low level architecture and kept them combined to avoid the explosion of documents. For the same reason, we later incorporated the terminology that was initially a separate spec.

As a result this draft has 2/3 documents in one, with commonalities in section 3.4 and 4.4 for instance. That's where we are and as you say, there is no fundamental new reason to undo that.
 
There was a desire to make section 4 self-sufficient, with the idea of possibly splitting section 3 and 4 which we never did. Still it might be useful to the reader who just reads that section.
And there was a desire to have a discussion at the high level architecture on this topic so removing 3.4 is not good either.

I'm quite afraid to destabilize the document by doing a major change now.


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

PT> I removed the P2P which is not explained. The relevant text otherwise is
"
or by in a distributed fashion using a reactive routing protocol and
   a Hop-by-Hop scheduling protocol.
"


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

PT> good catch. It is now AODV RPL, updated the picture


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

PT >  I made an attempt at it, please see -25 once published.
The outlook would be

   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  51
     6.1.  Availability of Remote Services . . . . . . . . . . . . .  51
     6.2.  MAC-Layer Security  . . . . . . . . . . . . . . . . . . .  52
     6.3.  Time Synchronization  . . . . . . . . . . . . . . . . . .  53
     6.4.  Selective Jamming . . . . . . . . . . . . . . . . . . . .  53
     6.5.  Validating ASN  . . . . . . . . . . . . . . . . . . . . .  53
     6.6.  Rekeying  . . . . . . . . . . . . . . . . . . . . . . . .  54
     6.7.  Deeper Considerations . . . . . . . . . . . . . . . . . .  54

More below


> 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?

PT > ASN is not passed in the frame because it would was 5 octets. A network is non-functional if nodes do not have the right sense of ASN so if the network works, it means the 5 bytes can be saved.
PT > With 6TiSCH, ASN is learned from unsecured beacons, and needs t be proven before used. We hint how that is done in this spec, and detail in minimal security.
PT > once installed and as long as the node is synchronized to the network ASN is implicit and cannot be compromised.
PT > One of the new sections deals with ASN protection and the details are in the 6tisch minimal security draft

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

PT>
PT > For the most part, I pointed at the minimal security draft for more details, made it a normative reference: this comes from a chat with Ben Kaduk and the authors of minimal security. We wish to place the gory details in the security section of minimal security, and that includes key management. Still I added some of the text below, a section on rekeying, and MAC security, which is basically CCM* with a network-wide key, using ASN and MAC addresses in the nonce:
"

6.4.  Rekeying

   Though it is possible to use peer-wise keys, a 6TiSCH network
   typically uses a network-wide key that is common for all
   transmissions in the LLN.  [I-D.ietf-6tisch-minimal-security] enables
   to obtain that key and to rekey the network when needed.  Since the
   ASN is expressed in 5 octets, it should never wrap during a network
   lifetime, and it is possible that a network never needs to rekey.

   Still, there are occasions where rekeying is necessary, for instance:

   o  An unwelcome node has joined and needs to be expelled

   o  The JRC needs to reassign a short address that was already
      assigned while the current network key was in use.

   o  Resetting Epoch time when rebooting the network.
"

" 6.2.  Relative to MAC-Layer Security

   This architecture operates on IEEE Std. 802.15.4 and expects the
   Link-Layer security to be enabled at all times between connected
   devices, except for the very first step of the device join process,
   where a joining device may need some initial, unsecured exchanges so
   as to obtain its initial key material.  In a typical deployment, all
   joined nodes use the same keys and rekeying needs to be global.

   The 6TISCH Architecture relies on the join process to deny
   authorization of invalid nodes and preserve the integrity of the
   network keys.  A rogue that managed to access the network can perform
   a large variety of attacks from DoS to injecting forged packets and
   routing information.  "Zero-trust" properties would be highly
   desirable but are mostly not available at the time of this writing.
   [I-D.ietf-6lo-ap-nd] is a notable exception that protects the
   ownership of IPv6 addresses and prevents a rogue node with L2 access
   from stealing and injecting traffic on behalf of a legitimate node.

...
"

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

PT > This is what section 9 of RFC 8453 discusses. Note that it mostly insists on PKI / AAA as opposed to delay attacks and black holes.
How can take us in network architecture, isolation, firewalls. That seems to take us quite off topic , doesn't it? 
 



> ** 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?

PT> This is the same parallel as done in the DetNet architecture from which this is inherited, using the same reference.
The security issues that arise when a centralized control is separate from the forwarding plane are similar: rogue access to one of the components, and attacks on the connectivity on the control path, including interception, blackholing or latency injection.
I can remove the reference and replace by text like the above, please advise. In parammme please condsider the security section of the detnet architecture, it is in AUTH 48 but still changeable.


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

PT > Added

> ** 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/

PT> all nits processed, many thanks!

I will publish 25 to provide a abase on which we can refine in the next minutes.
Please consider it before replying to this mail.

Many thanks again!

Pascal