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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
