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

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

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ć <[e-mail]>
Sent: mercredi 5 décembre 2018 16:07
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: [e-mail]
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

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