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

From: Mališa Vučinić <[email-masked]>
Date: Wed, 5 Dec 2018 16:06:39 +0100

Hello Pascal,

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

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

- CCA: definition is a bit upside down

- centralized cell reservation, centralized track reservation: are these
really needed?

- Enhanced Beacon: add defined in IEEE802.15.4 ?

- link: describe what "link" means in terms of 6tisch

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

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

- Maybe add block “Applications” alongside with CoJP?

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

- Static Scheduling: mention earlier that this is needed for
interoperability during network formation
---------------------------------------------------------------------------------------------
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.

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

- “via a Join Proxy” to me gives an impression that JP participates in the
authentication process, not that it only 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.

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.

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

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 6 Dec 2018 14:48:22 +0100

Hi Pascal,

I'm reviewing the architecture draft, although the deadline has already passed... I have one comment.

I see some ideas which don't have concrete protocol specifications discussed as WG drafts, for instance, centralized reservation and tracks. They look like kind of "concepts" at this moment. 

Can we keep them in the architecture draft whose intended status is now Standards Track? I read RFC7127, "Characterization of Proposed Standards", but, I'm not sure...

This should have been raised when you asked by https://mailarchive.ietf.org/arch/msg/6tisch/qxeFuhVNGV5wXjgz1yHY8Mp8e1I

Sorry for the late comment.

Best,
Yatch

> On Nov 11, 2018, at 3:22, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Dear WG :
> 
>  
> 
> We are now starting the working group last call for the 6TiSCH Architecture based on https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt. This document is the merge of the previous architecture and terminology documents.
> 
>  
> 
> Authors of our WIP WG docs draft-ietf-6tisch-dtsecurity-zerotouch-join-03, draft-ietf-6tisch-enrollment-enhanced-beacon-00, draft-ietf-6tisch-minimal-security-08 and draft-ietf-6tisch-msf-01 are requested to pay particular attention on how their work is reflected in the Architecture, and are strongly encouraged to propose new text to improve the correctness of that representation.
> 
>  
> 
> The architecture is a foundational product of the WG, providing the view on the whole stack that we designed, implemented and interop tested over the 5 years of activity of the group; it is in some form a testimony of the WG.
> 
> With this in mind, please pay a very special attention when reviewing it.
> 
>  
> 
> The WGLC ends on Friday November 30th, 2018.
> 
>  
> 
> Many thanks in advance;
> 
>  
> 
> The chairs.
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Dec 2018 14:46:23 +0000

Hello Yatch:

I'm still fixing the text from the WGLC comments so I'm happy to still pick some. Please let me know if you intend to provide a review soon.
To your point: this is an architecture document. I'm not too anxious that all the components are not fully implemented yet.
Maybe we'll work on them in PAW ML. Did you register?

Take care,

Pascal

> -----Original Message-----
> From: 6tisch <[email-masked]> On Behalf Of Yasuyuki Tanaka
> Sent: jeudi 6 décembre 2018 14:48
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]; Yasuyuki Tanaka <[email-masked]>
> Subject: Re: [6tisch] WGLC for https://www.ietf.org/id/draft-ietf-6tisch-
> architecture-17.txt
> 
> Hi Pascal,
> 
> I see some ideas which don't have concrete protocol specifications discussed as
> WG drafts, for instance, centralized reservation and tracks. They look like kind
> of "concepts" at this moment.
> 
> Can we keep them in the architecture draft whose intended status is now
> Standards Track? I read RFC7127, "Characterization of Proposed Standards",
> but, I'm not sure...
> 
> This should have been raised when you asked by
> https://mailarchive.ietf.org/arch/msg/6tisch/qxeFuhVNGV5wXjgz1yHY8Mp8e1I
> 
> > We are now starting the working group last call for the 6TiSCH Architecture
> based on https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt. This
> document is the merge of the previous architecture and terminology
> documents.
> >
> >
> >
> > Authors of our WIP WG docs draft-ietf-6tisch-dtsecurity-zerotouch-join-03,
> draft-ietf-6tisch-enrollment-enhanced-beacon-00, draft-ietf-6tisch-minimal-
> security-08 and draft-ietf-6tisch-msf-01 are requested to pay particular
> attention on how their work is reflected in the Architecture, and are strongly
> encouraged to propose new text to improve the correctness of that
> representation.
> >
> >
> >
> > The architecture is a foundational product of the WG, providing the view on
> the whole stack that we designed, implemented and interop tested over the 5
> years of activity of the group; it is in some form a testimony of the WG.
> >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Dec 2018 14:46:23 +0000

Hello Yatch:

Take care,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Dec 2018 14:46:23 +0000

Hello Yatch:

Take care,

Pascal

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 6 Dec 2018 16:58:26 +0100

Thank you, Pascal.

> Please let me know if you intend to provide a review soon.

Yes. Here are my additional but minor comments:

---

[Definition of 6P / Section 2.2 and Figure 1]

In the terminology section, 6top is explained as follows:

   6top (6TiSCH Operation Sublayer):  The next highest layer of the IEEE
               Std 802.15.4 TSCH medium access control layer.  It
               implements and terminates 6P, and contains at least one
               SF.

However, 6top doesn't contain SFs in Figure 1. My understanding on 6top is the same as Figure 1. In addition, the original text says that 6top "contains at least one SF". However, 6TiSCH could work without SF. Then, the explanations of 6top and 6P in Section 2.2 would be:

   6top (6TiSCH Operation Sublayer):  The next higher layer of the IEEE
               Std 802.15.4 TSCH medium access control layer.  It
               provides the abstraction of an IP link over a TSCH
               MAC, schedules packets over TSCH cells, and expose a management
               interface to schedule TSCH cells.

   6P (6top Protocol):  Allows neighbor nodes to communicate to add/
               delete cells to one another in their TSCH schedule. 6P is terminated at
               the 6top layer.

[Terminology / Section 2.2]

Are these terms common? It seems so, but they are not used in the draft nor in RFC7554/RFC8180/RFC8480, are they?: 

   blacklist of frequencies:  A set of frequencies which should not be
               used for communication.

   broadcast cell:  A scheduled cell used for broadcast transmission.

Does "broadcast cell" means a cell having the broadcast MAC address in its neighbor MAC address field? I'd like to have more text on them or to remove them.

["6P protocol"]
"6P protocol" is used three times in the draft, which should be replaced with "6P" (or "6top Protocol").

---

That's all :-) 

> Maybe we'll work on them in PAW ML. Did you register?

Yes, I did.

Thanks!
Yatch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Dec 2018 16:02:15 +0000

On the side, Mališa

With RFC 8505, we are now claiming that the scope of uniqueness for a Link Local address is the pair of peers.
So the flow that you represent as

        |                          |                          |
        |<-Neighbor Discovery (2)->|                          |

In minimal security is more precisely as illustrated in my proposed flow for section 3.7 of the architecture:

    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

Now, I do not think you need to change minimal, though, the level of abstraction is fine.

All the best

Pascal

From: Mališa Vučinić <[email-masked]>
Sent: mercredi 5 décembre 2018 16:07
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: Re: [6tisch] WGLC for https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt

Hello Pascal,

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

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

- centralized cell reservation, centralized track reservation: are these really needed?
- Enhanced Beacon: add defined in IEEE802.15.4 ?

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

- Static Scheduling: mention earlier that this is needed for interoperability during network formation
---------------------------------------------------------------------------------------------
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.

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:

with

- “via a Join Proxy” to me gives an impression that JP participates in the authentication process, not that it only 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.

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.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 Dec 2018 15:43:44 +0000

Hello Mališa

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

Mališa

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

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

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

[PT>] Why not?

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

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

         |               |               |               |

         |               |               |               |

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

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

         |               |               |               |

with

[PT>] OK, will swap

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

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

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

[PT>] What about

   [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

- 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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 Dec 2018 16:00:44 +0000

Hello Yatch

Many thanks for your review! Let's see below

> However, 6top doesn't contain SFs in Figure 1. My understanding on 6top is the
> same as Figure 1. In addition, the original text says that 6top "contains at least
> one SF". However, 6TiSCH could work without SF. Then, the explanations of
> 6top and 6P in Section 2.2 would be:
> 
[PT>] Great!

>                delete cells to one another in their TSCH schedule. 6P is terminated at
[PT>] great also : ) Maybe I should use: "6P operates at the 6top layer"?

> Does "broadcast cell" means a cell having the broadcast MAC address in its
> neighbor MAC address field? I'd like to have more text on them or to remove
> them.
[PT>] 
[PT>] Agreed to remove them

> "6P" (or "6top Protocol").
[PT>] I fixed : ) either use 6P or 'the 6top protocol'.

Many thanks again,  Yatch.

Take care,

Pascal

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 12 Dec 2018 12:00:37 +0100

Hello Pascal,

Most of the resolutions to my comments look good. Couple of nits inline.

Mališa

*[PT>] *I think we need to define an entry for CoJP, similar to 6P. What
> about;
How about:
CoJP (Constrained Join Protocol): CoJP enables a pledge to securely join a
6TiSCH network by distributing network parameters over a secure channel.
CoJP is defined in the Minimal Security Framework for 6TiSCH
[I-D.ietf-6tisch-minimal-security]. In the minimal setup with pre-shared
keys defined in [I-D.ietf-6tisch-minimal-security], CoJP allows the pledge
to join the network in a single round trip exchange.

> - 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 |
>
Nit: Swap Applis and CoJP to have control plane "kind of" on the left side
:-).

>    network must participate to a join process to obtain its security
Nits: Replace "must participate to a join process" with "must trigger the
join protocol".

>    specified in [I-D.ietf-6tisch-minimal-security].
Proposal to replace the paragraph above with:

The join protocol used in 6TiSCH is Constrained Join Protocol (CoJP). In
the minimal setting defined in [I-D.ietf-6tisch-minimal-security], the
authentication is based on a pre-shared key, based on which a secure
session is derived. CoJP exchange may also be preceded with a zero-touch
handshake [I-D.ietf-6tisch-dtsecurity-zerotouch-join] in order to enable
pledge joining based on certificates and/or inter-domain communication.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 12 Dec 2018 12:51:08 +0000

Hello Mališa

Please see below ( I pushed the result in the repo, please let me know if we are OK now )

From: 6tisch <[email-masked]> On Behalf Of Mališa Vucinic
Sent: mercredi 12 décembre 2018 15:01
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [6tisch] WGLC for https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt

Hello Pascal,

Mališa

How about:
CoJP (Constrained Join Protocol): CoJP enables a pledge to securely join a 6TiSCH network by distributing network parameters over a secure channel. CoJP is defined in the Minimal Security Framework for 6TiSCH [I-D.ietf-6tisch-minimal-security]. In the minimal setup with pre-shared keys defined in [I-D.ietf-6tisch-minimal-security], CoJP allows the pledge to join the network in a single round trip exchange.
[PT>]
The second sentence is extraneous, correct?
[PT>] what about

   CoJP (Constrained Join Protocol):  The Constrained Join Protocol
               (CoJP) enables a pledge to securely join a 6TiSCH network
               and obtain network parameters over a secure channel.  In
               the minimal setup with pre-shared keys defined in
               [I-D.ietf-6tisch-minimal-security], CoJP can operate with
               a single round trip exchange.

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

      |  CoJP  | Applis |

      |       UDP       |      ICMPv6        |

      |                 IPv6                 |

Nit: Swap Applis and CoJP to have control plane "kind of" on the left side :-).

[PT>] OK

   keys.

Nits: Replace "must participate to a join process" with "must trigger the join protocol".
[PT>]
OK, but  “must use” then. You do not trigger a protocol, you trigger its operation.

The join protocol used in 6TiSCH is Constrained Join Protocol (CoJP). In the minimal setting defined in [I-D.ietf-6tisch-minimal-security], the authentication is based on a pre-shared key, based on which a secure session is derived. CoJP exchange may also be preceded with a zero-touch handshake [I-D.ietf-6tisch-dtsecurity-zerotouch-join] in order to enable pledge joining based on certificates and/or inter-domain communication.

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 12 Dec 2018 13:57:03 +0100

Thanks Pascal, looks good!

Mališa

On Wed, Dec 12, 2018 at 1:51 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> *From:* 6tisch <[email-masked]> *On Behalf Of *Mališa Vucinic
> *Sent:* mercredi 12 décembre 2018 15:01
>
>
> *To:* Pascal Thubert (pthubert) <[email-masked]>
>
> *Cc:* Michael Richardson <[email-masked]>; [email-masked]
>
>
> *Subject:* Re: [6tisch] WGLC for
> https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt
>
>
>
> Hello Pascal,
>
>
>
> *The second sentence is extraneous, correct?*
>
> *[PT>] what about*
>
>
>
> *[PT>] OK*
> *OK, but  “must use” then. You do not trigger a protocol, you trigger its
> operation.*
>
>
>