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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 07 Aug 2019 21:26:19 -0700

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/

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Aug 2019 15:19:21 +0000

Hello Roman:

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

Please see below:

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

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

> summary table, to what does the “TBD”?

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

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

> mechanisms/assumptions are inherited from [IEEE Std. 802.15.4] around link-
> layer security. They need to be explicitly stated (i.e., confidentiality,

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? 

> 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

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

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

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 22 Aug 2019 20:57:14 +0000

Hi Pascal!

Thank you for publishing -25.  It addresses my concern.  I have one detailed response below about a possible edit based on your question.

Roman

> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: Thursday, August 22, 2019 11:19 AM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-
> 24: (with COMMENT)
> 
> Hello Roman:
> 
> > ** 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.
> 

Understood.  I can appreciate the intent here.

> 
> > ** 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
> PT> otherwise is
> "
> > ** Section 3.6.  Per the “Hop-by-Hop  (TBD)” in the scheduling column
> > in the summary table, to what does the “TBD”?
> 

Thanks.

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

This new text if very helpful and addresses my concern.  Thank you.

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

Works for me.

> > -- 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.
> > ** Section 6.  Per “Section 9 of [RFC8453] applies equally to 6TiSCH”,
> > this reference organizes threats and mitigations around the CMI and
> > MPI interfaces.
> 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.

I would recommend taking a hybrid approach.  I think it's worth making the more specific statement you propose but also citing that the more general version of this consideration comes from [RFC8453].

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

Thanks.

> > -- Section 3.7.  The paragraph starting with “The reference stack that
> > the 6TiSCH architecture presents …” doesn’t seem to add any clarity.
> >
> > -- Section 4.3.1.1. Duplicate phrase.  “added/moved/deleted, in which
> > case 6top can only act as instructed,” appears twice.
> >

Thanks for these changes.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 23 Aug 2019 07:37:12 +0000

Hello Roman:

I elided the pieces where we are in sync

> > > ** Section 6.  Per “Section 9 of [RFC8453] applies equally to
> > > 6TiSCH”, this reference organizes threats and mitigations around the
> > > CMI and MPI interfaces.
> > PT> This is the same parallel as done in the DetNet architecture from
> > PT> which
> > 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 would recommend taking a hybrid approach.  I think it's worth making the
> more specific statement you propose but also citing that the more general
> version of this consideration comes from [RFC8453].
> 

PT> I caught that hint and gave it a try in 25, which is already a change in that direction:

   As with DetNet in general, the communication with the PCE must be
   secured and should be protected against DoS attacks, including delay
   injection and blackholing attacks, and secured as discussed in the
   security considerations defined for Abstraction and Control of
   Traffic Engineered Networks (ACTN) in Section 9 of [RFC8453], which
   applies equally to DetNet and 6TiSCH.  In a similar manner, the
   communication with the JRC must be secured and should be protected
   against DoS attacks when possible. 

PT> I'm happy to modify it deeper in 26, and would appreciate a suggestion : )

Many thanks again!

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 26 Aug 2019 09:44:05 +0000

Hello Roman

> version of this consideration comes from [RFC8453].

I propose in -26 to change the first subsection to be as follows:
"
6.1.  Availability of Remote Services

   The operation of 6TiSCH Tracks inherits its high level operation from
   DetNet and is subject to the observations in section 5 of
   [I-D.ietf-detnet-architecture].  The installation and the maintenance
   of the 6TiSCH Tracks depends on the availability of a controller with
   a PCE to compute and push them in the network.  When that
   connectivity is lost, existing Tracks may continue to operate until
   the end of their lifetime, but cannot be removed or updated, and new
   Tracks cannot be installed.

   In a LLN, the communication with a remote PCE may be slow and
   unreactive to rapid changes in the condition of the wireless
   communication.  An attacker may introduce extra delay by selectively
   jamming some packets or some flows.  The expectation is that the
   6TiSCH Tracks enable enough redundancy to maintain the critical
   traffic in operation while new routes are calculated and programmed
   into the network.

Also Michael suggested improvements for the rekeying piece
It would now look as follows:

"
6.6.  Network Keying and Rekeying

   Section 4.2.1 provides an overview of the CoJP process described in
   [I-D.ietf-6tisch-minimal-security] by which an LLN can be assembled
   in the field, having been provisioned in a lab.
   [I-D.ietf-6tisch-dtsecurity-zerotouch-join] is future work that
   preceeds and then leverages the CoJP protocol using the
   [I-D.ietf-anima-constrained-voucher] constrained profile of
   [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI).  This later work
   requires a yet-to-be standardized Lighweight Authenticated Key
   Exchange protocol. 

   The CoJP protocol results in distribution of a network-wide key that
   is to be used with [IEEE802154] security.  The details of use are
   described in [I-D.ietf-6tisch-minimal-security] sections 9.2 and
   9.3.2.

   The BRSKI mechanism may lead to use of the CoJP protocol, in which
   case it also results in distribution of a network-wide key.
   Alternatively the BRSKI mechanism may be followed by use of
   [I-D.ietf-ace-coap-est] to enroll certificates for each device.  In
   that case, the certificates may be used with an [IEEE802154] key
   agreement protocol.  The description of this mechanism, while
   conceptually straight forward still has significant standardization
   hurdles to pass.

   [I-D.ietf-6tisch-minimal-security] section 9.2 describes a mechanism
   to change (rekey) the network.  There are a number of reasons to
   initiate a network rekey: to remove unwanted (corrupt/malicious)
   nodes, to recover unused 2-byte short addresses, due to limits in
   encryption algorithms.  For all of the mechanisms that distribute a
   network-wide key, rekeying is also needed on a periodic basis.  In
   more details:

   o  The mechanism described in [I-D.ietf-6tisch-minimal-security]
      section 9.2 requires advance communication between the JRC and
      every one of the nodes before the key change.  Given that many
      nodes may be sleepy, this operation may take a significant amount
      of time, and may consume a significant portion of the available
      bandwidth.  As such, network-wide rekeys in order to exclude nodes
      that have become malicious will not be particularly quick.  If a
      rekey is already in progress, but the unwanted node has not yet
      been updated, then it is possible to to just continue the
      operation.  If the unwanted node has already received the update,
      then the rekey operation will need to be restarted.

   o  The cryptographic mechanisms used by [IEEE802154] include the
      2-byte short address in the calculation of the context.  If the
      2-byte short address is reassigned to another node while the same
      network-wide keys are in operation, it is possible that this could
      result in disclosure of the network-wide key due to reused of the
      nonce.  A network that gains and loses nodes on a regular basis is
      likely to reach the 65536 limit of the 2-byte (16-bit) short
      addresses, even if the network has only a few thousand nodes.
      Network planners should consider the need to rekey the network on
      a periodic basis in order to recover 2-byte addresses.  The rekey
      can update the short addresses for active nodes if desired, but
      there is actually no need to do this as long as the key has been
      changed.

   o  Many cipher algorithms have some suggested limits on how many
      bytes should be encrypted with that algorithm before a new key is
      used.  These numbers are typically in the many to hundreds of
      gigabytes of data.  On very fast backbone networks this becomes an
      important concern.  On LLNs with typical data rates in the
      kilobits/second, this concern is significantly less.  However, the
      LLN may be expected to operate for decades at a time, and
      operators are advised to plan for the need to rekey.

   Except for urgent rekeys caused by malicious nodes, the rekey
   operation described in [I-D.ietf-6tisch-minimal-security] can be done
   as a background task and can be done incrementally.  It is a make-
   before-break mechanism.  The switch over to the new key is not
   signaled by time, but rather by observation that the new key is in
   use.  As such, the update can take as long as needed, or occur in as
   short a time as practical.

"

This is candidate to -26 to be published soon. Please come back to us if this needs additional work  : )

All the best,

Pascal

> From: Roman Danyliw <[email-masked]>
> Sent: jeudi 22 août 2019 22:57
> To: Pascal Thubert (pthubert) <[email-masked]>; The IESG
> <[email-masked]>
> Thank you for publishing -25.  It addresses my concern.  I have one detailed
> response below about a possible edit based on your question.
> 
> Roman
> 
> > 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.
> >
> > 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.
> >
> > > ** 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-
> > the text into blocks around the relevant security properties and
> > explicitly state the property as an introduction.
> >
> > > -- 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
> > > The ASN is not passed explicitly in the data frames”.  To confirm,
> > > is this the intended guidance on avoiding “compromising” the ASN –
> > 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.
> > > -- Per confidentiality (but it is really more than that), a series
> > > of security mechanisms/assumptions are inherited from [IEEE Std.
> > 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
> >
> > 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 3.7.  The paragraph starting with “The reference stack
> > > that the 6TiSCH architecture presents …” doesn’t seem to add any clarity.
> > >
> > > -- Section 4.3.1.1. Duplicate phrase.  “added/moved/deleted, in
> > > which case 6top can only act as instructed,” appears twice.
> > >

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 27 Aug 2019 16:00:34 +0300

>       result in disclosure of the network-wide key due to reused of the

Even when the nonce reuse happens, I do not think there is any leak of
the network-wide keys in that case. What is lost is the
confidentiality of the those messages sharing nonce, i.e., only those
messages are broken, not the whole network key.

>       operators are advised to plan for the need to rekey.

Note, that TSCH in general allows maximally of 2^40 frames to be sent
before ASN rolls over. In normal case the maximum packet size is 2^7
octets, meaning the total amount of bytes that can be transferred over
TSCH network is 2^47 octects, meaning 2^43 blocks of AES. Currently
only cipher supported by the TSCH is AES-CCM-128 (altough 802.15.4y
will be adding support for other algorithms too), but I think the
maximum number of blocks recommened for one key for AES is more than
2^43, so this should not be a problem at all. I.e., the ASN frame
counter will be problem before this will be problem. Even if using the
PHY with 2^11 max frame length that gives only 2^47 blocks at maximum. 
-- 
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 27 Aug 2019 14:47:52 +0000

All the best,

Pascal

> From: Tero Kivinen <[email-masked]>
> Sent: mardi 27 août 2019 15:01
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>; Benjamin
> Kaduk <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-
> architecture-24: (with COMMENT)
> 
> Even when the nonce reuse happens, I do not think there is any leak of the
> network-wide keys in that case. What is lost is the confidentiality of the those
> messages sharing nonce, i.e., only those messages are broken, not the whole
> network key.

I'd really like to understand that. This is too deep for Archie anyway. I'll change the text to indicate that a nonce-reuse attack would be possible.
Does the below work?

" 
      The cryptographic mechanisms used by IEEE Std. 802.15.4 include the 2-byte
      short address in the calculation of the context.
      A nonce-reuse attack may become feasible if a short address is reassigned
      to another node while the  same network-wide keys are in operation.
"

> Note, that TSCH in general allows maximally of 2^40 frames to be sent before
> ASN rolls over. In normal case the maximum packet size is 2^7 octets,
> meaning the total amount of bytes that can be transferred over TSCH
> network is 2^47 octects, meaning 2^43 blocks of AES. Currently only cipher
> supported by the TSCH is AES-CCM-128 (altough 802.15.4y will be adding
> support for other algorithms too), but I think the maximum number of blocks
> recommened for one key for AES is more than 2^43, so this should not be a
> problem at all. I.e., the ASN frame counter will be problem before this will be
> problem. Even if using the PHY with 2^11 max frame length that gives only
> 2^47 blocks at maximum.

Many thanks, Tero, all this is really useful. What about:

" 
      With TSCH as it stands at the time of this writing, the ASN will wrap
      after 2^40 timeslot durations, which means with the default values around
      350 years. Wrapping ASN is not expected to happen within the lifetime of
      most LLNs. Yet, should the ASN wrap, the network must be rekeyed to avoid
      a nonce-reuse attack.

      Many cipher algorithms have some suggested limits on how many bytes
      should be encrypted with that algorithm before a new key is used.
      These numbers are typically in the many to hundreds of gigabytes of
      data.  On very fast backbone networks this becomes an important
      concern. On LLNs with typical data rates in the kilobits/second,
      this concern is significantly less. With IEEE Std. 802.15.4 as it stands
      at the time of this writing, the ASN will wrap before the limits of the
      current L2 crypto (AES-CCM-128) are reached, so the problem should never
      occur.

      In any fashion, if the LLN is expected to operate continuously for decades
      then the operators are advised to plan for the need to rekey.
"

All the best;

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Aug 2019 13:43:34 -0400

Tero Kivinen <[email-masked]> wrote:
    >> o The cryptographic mechanisms used by [IEEE802154] include the 2-byte
    >> short address in the calculation of the context.  If the 2-byte short
    >> address is reassigned to another node while the same network-wide keys
    >> are in operation, it is possible that this could result in disclosure
    >> of the network-wide key due to reused of the

    > the network-wide keys in that case. What is lost is the confidentiality
    > of the those messages sharing nonce, i.e., only those messages are
    > broken, not the whole network key.

I had understood that it was worse.
The text has slightly changed since, but can you suggest better text?
So I've overstated the risk.

    >> o Many cipher algorithms have some suggested limits on how many bytes
    >> concern.  On LLNs with typical data rates in the kilobits/second, this
    >> concern is significantly less.  However, the LLN may be expected to
    >> operate for decades at a time, and operators are advised to plan for
    >> the need to rekey.

    > PHY with 2^11 max frame length that gives only 2^47 blocks at maximum.

This analysis should be included, and I'll try to do that.

I think that we MUST rekey before the ASN rolls over too?
Is that a major concern?

I understood the ASN advances every 10ms in many networks, sometimes as slow
as 50ms.  So let's call it 2^6/s?  So the ASN rolls over after 544 years?
2^(40-6) / (86400 * 365) = 544.

I guess the point is that we don't have to rekey for cryptographic of ASN
roll-over reasons.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 28 Aug 2019 09:15:42 +0000

With the default of 10 ms it takes 350 years to wrap ASN. That's  long memory to keep for an attacker. Modern storage technology does not last that long.

But hey, 6TiSCH is designed to be easily portable to other deterministic MAC technologies (think RAW) which would be much faster. A reasonable time slot in 802.11 ax would be below 1ms, which would take is down to 35 years. But there are alternatives:

- At some point we do not slot anymore, just provide precise time for transmission (think time-based shapers).

- If we keep resource blocks of 10ms in 5G, there will be multiple packets, so ASN will need an extension (at least an additional octet that would be signaled in band) to count the packet with a finer granularity than ASN, within the time slot.

I modified Archie based on Tero's comment to make it more abstract - just say nonce-reuse attack deferring to others on what the result of the attack can be - and indicate the 350 years. Please ssee if that's enough.

All the best,

Pascal

> From: Michael Richardson <[email-masked]>
> Sent: mardi 27 août 2019 19:44
> To: Tero Kivinen <[email-masked]>
> Cc: Pascal Thubert (pthubert) <[email-masked]>; Roman Danyliw
> <[email-masked]>; [email-masked]; [email-masked]; The
> IESG <[email-masked]>; [email-masked]; [email-masked];
> Benjamin Kaduk <[email-masked]>
> bytes
> I understood the ASN advances every 10ms in many networks, sometimes as
> slow as 50ms.  So let's call it 2^6/s?  So the ASN rolls over after 544 years?
> I guess the point is that we don't have to rekey for cryptographic of ASN roll-
> over reasons.
> 
> --

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 30 Aug 2019 01:05:33 +0300

Pascal Thubert (pthubert) writes:
> > Even when the nonce reuse happens, I do not think there is any
> > leak of the network-wide keys in that case. What is lost is the
> > confidentiality of the those messages sharing nonce, i.e., only
> > those messages are broken, not the whole network key.
> 
> I'd really like to understand that. This is too deep for Archie
> anyway. I'll change the text to indicate that a nonce-reuse attack
> would be possible. Does the below work?
> 
> " The cryptographic mechanisms used by IEEE Std. 802.15.4 include
>       the 2-byte short address in the calculation of the context. A
>       nonce-reuse attack may become feasible if a short address is
>       reassigned to another node while the same network-wide keys
>       are in operation. "

Looks good.

> > Note, that TSCH in general allows maximally of 2^40 frames to be
> > sent before ASN rolls over. In normal case the maximum packet size
> > is 2^7 octets, meaning the total amount of bytes that can be
> > transferred over TSCH network is 2^47 octects, meaning 2^43 blocks
> > of AES. Currently only cipher supported by the TSCH is AES-CCM-128
> > (altough 802.15.4y will be adding support for other algorithms
> > too), but I think the maximum number of blocks recommened for one
> > key for AES is more than 2^43, so this should not be a problem at
> > all. I.e., the ASN frame counter will be problem before this will
> > be problem. Even if using the PHY with 2^11 max frame length that
> > gives only 2^47 blocks at maximum.
> 
> " With TSCH as it stands at the time of this writing, the ASN will
>       wrap after 2^40 timeslot durations, which means with the
>       default values around 350 years. Wrapping ASN is not expected
>       to happen within the lifetime of most LLNs. Yet, should the
>       ASN wrap, the network must be rekeyed to avoid a nonce-reuse
>       attack.
> 
>       Many cipher algorithms have some suggested limits on how many
>       bytes should be encrypted with that algorithm before a new key
>       is used. These numbers are typically in the many to hundreds
>       of gigabytes of data. On very fast backbone networks this
>       becomes an important concern. On LLNs with typical data rates
>       in the kilobits/second, this concern is significantly less.
>       With IEEE Std. 802.15.4 as it stands at the time of this
>       writing, the ASN will wrap before the limits of the current L2
>       crypto (AES-CCM-128) are reached, so the problem should never
>       occur.
> 
>       In any fashion, if the LLN is expected to operate continuously
>       for decades then the operators are advised to plan for the
>       need to rekey. "

That looks good also.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 30 Aug 2019 02:15:20 +0300

Pascal Thubert (pthubert) writes:
> - If we keep resource blocks of 10ms in 5G, there will be multiple
> packets, so ASN will need an extension (at least an additional octet
> that would be signaled in band) to count the packet with a finer
> granularity than ASN, within the time slot.

There is no space in the nonce to extend ASN, so changing ASN size to
bigger number, or transmitting multiple packets from the same source
address inside the same ASN is not a problem that can be solved
easily. ASN already stole one byte from the nonce so it was able to be
expanded to 5 octets (frame counter is 4 octets and the 5th octet in
normal nonce is used for security level to protect against MIC
truncation problems when using same key with different length MICs).

The current TSCH security do assume that every node sends at most one
frame during one timeslot. Multiple nodes might send other frames
at the same timeslot using different channels etc, as the nonce
contains source address, and different nodes have different source
addresses. In normal case there is two frames sent inside the same
timeslot, one from sender to recipient using extended address of
sender in nonce, and one Ack from the recipient to sender using
extended address of the recipient in the nonce. Both of them use same
ASN and extended address + ASN makes the 13 octets we have available
in nonce.
-- 
[email-masked]