Re: [6tisch] WGLC for https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt

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

Hello Mališa

Many thanks for the in depth review. Let’s see below:


Here are my comments on draft-ietf-6tisch-architecture. I used the latest version of the draft hosted on bitbucket. In general, an editorial pass on the whole document would be useful, there are some typos here and there. The main issue I see is that Section 6.1 is completely outdated as it still refers to the preliminary discussions in the WG on JP authenticating the pledge, which is not really the case. Other comments are organized per sections, as I went through the document.

Mališa

=====================================================
Section 1: Introduction

- I think it would be quite useful to add here a high-level description of TSCH operation, in order to give reader some idea on what TSCH is before delving into the terminology section
[PT>] Agreed : I suggest to rewrite the section as follows:
   The Timeslotted Channel Hopping (TSCH) [RFC7554] mode of the IEEE Std
   802.15.4 [IEEE802154] Medium Access Control (MAC) was introduced with
   the IEEE Std 802.15.4e [IEEE802154e] amendment and is now retrofitted
   in the main standard.  For all practical purpose, this document is
   expected to be insensitive to the revisions of that standard, which
   is thus referenced undated.  TSCH is both a Time-Division
   Multiplexing and a Frequency-Division Multiplexing technique whereby
   a different channel can be used for each transmission, and that
   allows to schedule transmissions for deterministic operations.




=====================================================
Section 2: Terminology
- 6P transaction: It would be useful to describe this term in a generic manner to cover 3-step transactions. I don't think it's really needed to talk about individual messages in the protocol.
[PT>] I agree; what about the following:

   6P (6top Protocol):  The protocol defined in [RFC8480]. 6P enables

               Layer-2 peers to allocate, move or deallocate cells in

               their respective schedules in order to communicate.



   6P Transaction:  A 2-way or 3-way sequence of 6P messages used by

               Layer-2 peers to modify their communication schedule.

-Bundle:
-“Bundles are associated for either Layer-2 (switching) or Layer-3 (routing) forwarding operations. a Layer-3 bundle pair maps to an IP Link with a neighbor, whereas a Layer-2 bundle set corresponds to the relation of one or more incoming bundle(s) from the previous-hop neighbor(s) with one or more outgoing bundle(s) to the next-hop neighbor(s) along a Track. “
- I suggest removing the text above from the terminology section.
[PT>] We need the term further down in the specification. I suggest we make ist a separate definition like this:


  bundle:     A group of equivalent scheduled cells, i.e. cells

               identified by different [slotOffset, channelOffset],

               which are scheduled for a same purpose, with the same

               neighbor, with the same flags, and the same slotframe.

               The size of the bundle refers to the number of cells it

               contains.  For a given slotframe length, the size of the

               bundle translates directly into bandwidth.  A bundle is a

               local abstraction that represents a half-duplex link for

               either sending or receiving, with bandwidth that amounts

               to the sum of the cells in the bundle.



   Layer-2 vs. Layer-3 bundle:  Bundles are associated for either

               Layer-2 (switching) or Layer-3 (routing) forwarding

               operations.  a Layer-3 bundle pair maps to an IP Link

               with a neighbor, whereas a Layer-2 bundle set corresponds

               to the relation of one or more incoming bundle(s) from

               the previous-hop neighbor(s) with one or more outgoing

               bundle(s) to the next-hop neighbor(s) along a Track.


- CCA: definition is a bit upside down
[PT>] Agreed ; what about


   CCA (Clear Channel Assessment):  A mechanism defined in [IEEE802154]

               whereby nodes listen to the channel before sending, in

               order to detect ongoing transmissions from other parties.

               Because the network is synchronized, CCA cannot be used

               to detect colliding transmissions within the same

               network, but it can be used to detect other radio

               networks in vicinity.

[PT>]
- centralized cell reservation, centralized track reservation: are these really needed?
[PT>] no, I agree, removing.
- Enhanced Beacon: add defined in IEEE802.15.4 ?
[PT>] Yes. What about:


     EB (Enhanced Beacon):  A special frame defined in [IEEE802154] used

               by a node, including the JP, to announce the presence of

               the network.  It contains enough information for a pledge

               to synchronize to the network.


- link: describe what "link" means in terms of 6tisch
[PT>] yep


   link:       A communication facility or medium over which nodes can

               communicate at the Link-Layer, the layer immediately

               below IP.  In 6TiSCH, the concept is implemented as a

               collection of Layer-3 bundles.  Note: the IETF parlance

               for the term "Link" is adopted, as opposed to the IEEE

               Std 802.15.4 terminology.


- Constrained Join Protocol (CoJP) is currently not defined. Should we have a dedicated entry or piggyback within generic “join protocol” term stressing that 6TiSCH defines CoJP as its implementation.
[PT>] I think we need to define an entry for CoJP, similar to 6P. What about;

   CoJP (Constrained Join Protocol):  CoJP is a one-touch join protocol

               defined in the Minimal Security Framework for 6TiSCH

               [I-D.ietf-6tisch-minimal-security].  CoJP requires the

               distribution of preshared keys (PSK), and enables a node

               to join with a single round trip to the JRC via the JP.


=====================================================
Section 3.1: 6TiSCH Stack

- add Constrained Join Protocol in the Figure above CoAP. Use “Constrained Join Protocol” instead of “Minimal Security Framework for 6TiSCH”.
- Description of DTLS seems as a remnant. I would stress OSCORE here as the primacy choice with DTLS also being an option for applications.
[PT>]
[PT>] This gives :



      +--------+--------+

      |  CoJP  | Applis |

      +--------+--------+--------------+-----+

      | CoAP / OSCORE   |  6LoWPAN ND  | RPL |

      +-----------------+--------------+-----+

      |       UDP       |      ICMPv6        |

      +-----------------+--------------------+

      |                 IPv6                 |

      +--------------------------------------+----------------------+

      |     6LoWPAN HC   /   6LoRH HC        | Scheduling Functions |

      +--------------------------------------+----------------------+

      |     6top (to be IEEE Std 802.15.12) inc. 6top protocol      |

      +-------------------------------------------------------------+

      |                 IEEE Std 802.15.4 TSCH                      |

      +-------------------------------------------------------------+

And later:




   The Datagram Transport Layer Security (DTLS) [RFC6347] sitting either

   under CoAP or over CoAP so as to traverse proxies, as well as Object

   Security for Constrained RESTful Environments (OSCORE)

   [I-D.ietf-core-object-security], are examples of protocols that could

   be used to protect application payload.  OSCORE is used in particular

   by the Constrained Join Protocol (CoJP) defined in the "Minimal

   Security Framework for 6TiSCH" [I-D.ietf-6tisch-minimal-security].


- Maybe add block “Applications” alongside with CoJP?
[PT>] Why not?

---------------------------------------------------------------------------------------------
Section 3.3: Scheduling TSCH

- Static Scheduling: mention earlier that this is needed for interoperability during network formation
[PT>] OK, OK. Let’s see ;




   Static Scheduling:  This refers to the minimal 6TiSCH operation

      whereby a static schedule is configured for the whole network for

      use in a slotted-Aloha fashion.  The static schedule is

      distributed through the native methods in the TSCH MAC layer and

      does not preclude other scheduling operations to co-exist on a

      same 6TiSCH network.  A static schedule is necessary for basic

      operations such as the join process and for interoperability

      during the network formation, which is specified as part of the

      Minimal 6TiSCH Configuration [RFC8180].

---------------------------------------------------------------------------------------------
Section 3.7: Join Process and Registration

- at this point, wording “with a preshared key” is not necessary. We expect zero-touch work to provide a shared key for CoJP execution. Omit “6TiSCH” in “6TiSCH Constrained Join Protocol” to be consistent with minimal-security. Replace 6JP with CoJP, applies for text and Figure 5.

[PT>] yep ; we end up with






3.7.  Join Process and Registration



   As detailed in Section 6, a pledge that wishes to join the 6TiSCH

   network must participate to a join process to obtain its security

   keys.



   The join process can be zero-touch and leverage ANIMA procedures, as

   detailed in the 6tisch Zero-Touch Secure Join protocol

   [I-D.ietf-6tisch-dtsecurity-zerotouch-join].



   Alternatively, the join process can be one-touch, in which case the

   pledge is provisioned with a preshared key (PSK), and uses CoJP as

   specified in [I-D.ietf-6tisch-minimal-security].



   In order to join, the pledge is helped by a Join Proxy (JP) that

   relays the link-scope Join Request over the IP network to the Join

   Registrar/Coordinator (JRC) that can authenticate the pledge and

   validate that it is attached to the appropriate network.  As a result

   of this exchange the pledge is in possession of a Link-Layer material

   including a key and a short address, and all traffic is secured at

   the Link-Layer.



   The following flows illustrate the steps that are needed to provide

   reachability for a device in a secure fashion.



   Figure 5 illustrates that very initial joining phase.



    6LoWPAN Node       6LR              6LBR         Join Registrar

     (pledge)       (Join Proxy)       (root)      /Coordinator (JRC)

         |               |               |               |

         |  6LoWPAN ND   |6LoWPAN ND+RPL |  IPv6 network |

         |   LLN link    |Route-Over mesh| (the Internet)|

         |               |               |               |

         |   Layer-2     |               |               |

         |enhanced beacon|               |               |

         |<--------------|               |               |

       <-----------------|               |               |

         |  <------------|               |               |

         |               |               |               |

         | NS(EARO)      |               |               |

         |(for the LL @) |               |               |

         |-------------->|               |               |

         | NA(EARO)      |               |               |

         |<--------------|               |               |

         |               |               |               |

         | CoJP Join Req |               |               |

         | Link Local @  |               |               |

         |-------------->|               |               |

         |               |       CoJP Join Request       |

         |               |       Global Unicast @        |

         |               |------------------------------>|

         |               |               |               |

         |               |       CoJP Join Response      |

         |               |       Global Unicast @        |

         |               |<------------------------------|

         |CoJP Join Resp |               |               |

         | Link Local @  |               |               |

         |<--------------|               |               |

         |               |               |               |



            Figure 5: CoJP join process in a Multi-Link Subnet



=====================================================
Section 6: Security Considerations

The Minimal Security Framework for 6TiSCH [I-D.ietf-6tisch-minimal-security] describes the minimal mechanisms required to support secure enrollment of a pledge to a 6TiSCH network based on PSK. The specification allows to establish of Link-Layer keys, typically used in combination with a variation of Counter with CBC-MAC (CCM) [RFC3610], and set up a secure end-to-end session between the joining node (called the pledge) and the join registrar/coordinator (JRC) in charge of authenticating the node via a Join Proxy (JP). It can also be used to obtain a Link-Layer short address as a side effect. CoJP uses shared slots which are a constrained resource, so it is optimized to limit the number of messages to the strict minimum. As an example, Neighbor Discovery between the pledge and the JP can be skipped when the IPv6 Link Local addresses that are used derive from the node's EUI-64 address.

- I think “enrollment” is not the best term here since the pledge is considered to be already enrolled into the domain from the security viewpoint during the one-touch provisioning. I would suggest replacing the text:

support secure enrollment of a pledge to a 6TiSCH network based on PSK

with

enable a pledge to securely join a 6TiSCH network based on a PSK.

[PT>] OK, will swap

- “via a Join Proxy” to me gives an impression that JP participates in the authentication process, not that it only acts as a relay.

[PT>] OK, what about: “via a Join Proxy (JP) that acts as a relay”?

- CoJP appears here out of the blue, maybe mention it in the first sentence that it is defined as part of the Minimal Security Framework?

CoJP uses shared slots which are a constrained resource, so it is optimized to limit the number of messages to the strict minimum. As an example, Neighbor Discovery between the pledge and the JP can be skipped when the IPv6 Link Local addresses that are used derive from the node's EUI-64 address.



- I am not super happy about the phrasing of the paragraph above. CoJP does not use any particular slots: CoJP messages on the first hop are transmitted on shared slots, a consequence of CoJP being executed when a pledge is not yet part of the network. The example on ND is misleading since ND is only mentioned in minimal-security as part of the secure stack configuration, not really as part of the CoJP protocol itself.

[PT>]
[PT>] Yes, As I reread this text I drew the same conclusion. And the ND text has nothing to do there, I’ll remove it. The result is as wfollows:




   The Minimal Security Framework for 6TiSCH

   [I-D.ietf-6tisch-minimal-security] specifies the CoJP protocol that

   provides the minimal-security mechanisms required to enable a pledge

   to securely join a 6TiSCH network based on a PSK.  CoJP allows to

   establish Link-Layer keys, typically used in combination with a

   variation of Counter with CBC-MAC (CCM) [RFC3610], and set up a

   secure end-to-end session between the joining node (called the

   pledge) and the join registrar/coordinator (JRC) in charge of

   authenticating the node via a Join Proxy (JP) that acts as a relay.

   It can also be used to obtain a Link-Layer short address as a side

   effect.  It is optimized to limit the number of messages to the

   strict minimum.  CoJP messages on the first hop are transmitted on

   shared slots, a consequence of CoJP being executed when a pledge is

   not yet part of the network.


The "6tisch Zero-Touch Secure Join protocol" [I-D.ietf-6tisch-dtsecurity-zerotouch-join] wraps the minimal security draft with a flow inspired from ANIMA "Bootstrapping Remote Secure Key Infrastructures (BRSKI)" [I-D.ietf-anima-bootstrapping-keyinfra].

- I would rephrase the sentence above to make it apparent that zero-touch work precedes minimal-security flow by defining the establishment of a shared secret based on (manufacturer-installed) certificate. The shared secret obtained by zero touch is then used to provide a secure OSCORE session to CoJP.

[PT>] What about

   The "6tisch Zero-Touch Secure Join protocol"

   [I-D.ietf-6tisch-dtsecurity-zerotouch-join] wraps the minimal

   security draft with a flow inspired from ANIMA "Bootstrapping Remote

   Secure Key Infrastructures (BRSKI)"

   [I-D.ietf-anima-bootstrapping-keyinfra].  The zero-touch operation

   precedes minimal-security flow by defining the establishment of a

   shared secret based on (manufacturer-installed) certificate.  The

   shared secret obtained by zero touch is then used to provide a secure

   OSCORE [I-D.ietf-core-object-security] session to CoJP.

[PT>] Note: I ‘m swapping that text with lighter one text in 3.7 so the main text is at the right place

---------------------------------------------------------------------------------------------
Section 6.1: Join Process Highlights

- This section, including Figure 17, is completely outdated. There is no authentication happening between JP and the pledge.
- Is it appropriate to have a generic description of the join process within "Security Considerations"?
[PT>]
[PT>] Need to talk with Michael. I’ll publish a rev with 6.1 in appendix, and we’ll decide what to do.

Many thanks Malisa, this was really useful

Pascal