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

[Mališa Vučinić <[e-mail]>]

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