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

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

Hello Roman

About:

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

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.

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

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

> -----Original Message-----
> From: Roman Danyliw <[e-mail]>
> Sent: jeudi 22 août 2019 22:57
> To: Pascal Thubert (pthubert) <[e-mail]>; The IESG
> <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: RE: Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-
> 24: (with COMMENT)
> 
> 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:[e-mail]]
> > Sent: Thursday, August 22, 2019 11:19 AM
> > To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: RE: Roman Danyliw's No Objection on
> > draft-ietf-6tisch-architecture-
> > 24: (with COMMENT)
> >
> > 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.
> 
> 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
> > "
> > 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
> >
> 
> 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.
> >
> > 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
> 
> 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.
> > 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.
> >
> > ...
> > "
> 
> 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.
> > 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
> > PT> 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*”
> >
> > PT > Added
> 
> Thanks.
> 
> > > ** 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!
> 
> Thanks for these changes.
> 
> 
> > 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