Re: [6tisch] WGLC for

"Pascal Thubert (pthubert)" <> Thu, 06 December 2018 16:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 429B6130E17 for <>; Thu, 6 Dec 2018 08:06:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.959
X-Spam-Status: No, score=-15.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ehLqmUpJ11Wy for <>; Thu, 6 Dec 2018 08:06:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7C87124BAA for <>; Thu, 6 Dec 2018 08:06:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=49094; q=dns/txt; s=iport; t=1544112401; x=1545322001; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oDUMm8Ueqb06JgHo1lP9oxYJn/llELP/Q8Qu/ylNqT4=; b=IVhdlsgqyOkIqMhbIEYISoRKvrGKxN19vqHGX621sOukh73b2ToQYvMk V7qxaum71n3+B/7MBGNXYK3XJB/HMddbPa2qpi7pYUPm/f+x8Xoafauyn hH/i0c+5EjJYnIi0YnzfpMHCmwLFB873DxT3fMardp3gtE0jg7TVuWFME A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.56,322,1539648000"; d="scan'208,217";a="489182150"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2018 16:06:39 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id wB6G6d3c024938 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Dec 2018 16:06:39 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 6 Dec 2018 10:06:38 -0600
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Thu, 6 Dec 2018 10:06:38 -0600
From: "Pascal Thubert (pthubert)" <>
To: Mališa Vučinić <>
CC: "" <>
Thread-Topic: [6tisch] WGLC for
Thread-Index: AQHUjKwsiAVlTLmO0E2OlfMzIBcoFaVx1Ewg
Date: Thu, 06 Dec 2018 16:02:15 +0000
Deferred-Delivery: Thu, 6 Dec 2018 16:01:42 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_d740438ec044474098445e4041350124XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [6tisch] WGLC for
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Dec 2018 16:06:51 -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


From: Mališa Vučinić <>
Sent: mercredi 5 décembre 2018 16:07
To: Pascal Thubert (pthubert) <>
Subject: Re: [6tisch] WGLC for

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.


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


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