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ć <malisa.vuci...@inria.fr>
Sent: mercredi 5 décembre 2018 16:07
To: Pascal Thubert (pthubert) <pthub...@cisco.com>
Cc: 6tisch@ietf.org
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"?
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
