Hi,
Thank you, Tengfei and the other authors, for updating the draft!
I'm sharing my comments on the latest version.
https://tools.ietf.org/html/draft-ietf-6tisch-msf-02
[Security Consideration on autonomous SHARED cell allocation]
4.5. Step 4 - Installing Autonomous Cells for each neighbor in neighbor
table
Because it has learnt the link-layer keying material used in the
network, the joined node can now decrypt any packets sent by its
neighbors. Once a new neighbor is added to the neighbor table, a new
autonomous SHARED cell MUST be added to that neighbor.
As per the second sentence in this section, a JP MUST allocate an
autonomous SHARED cell to a pledge during its secure joining process.
Tengfei's email says no action required on the JP side, but the JP
need to have a neighbor table entry (neighbor cache entry) for the JP
in order to send back a join response, doesn't it? I may miss
something.
tengfei> [Resolved. During join process, only pledge required to
tengfei> install autonomous SHARED cell to JP, no action required from
tengfei> JP side.]
If this is the case, I would propose to add some note in Security
Considerations section where we mention risks of this kind allocation,
and may suggest a mitigation technique such as "on-demand allocation".
Basically this is the same comment as the first one in the following
email:
https://mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao
[Join request packets can still increment NumCellUsed?]
tengfei> non-trusted packet shouldn't be accounted for for adapting
tengfei> traffic
tengfei> ====================
tengfei> Mention that the untrusted packet (e.g. join
tengfei> request/response) shouldn't be counted for adapting the
tengfei> traffic. Issues link:
tengfei> https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/15
tengfei>
tengfei> [Resolved. clarified in adapting traffic section.]
I think this issue hasn't been resolved yet by the latest draft. I
expect text describing how to handle packets having code point AF42 or
AF43.
https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-6.1
[EB / DIO transmission rules]
I would propose to remove the third and fourth paragraphs mainly for
these two reasons:
- This is an implementation-specific optimization
- This is irrevalnt to the scheduling function itself
2. Interface to the Minimal 6TiSCH Configuration
(snip)
Because the minimal cell is SHARED, the back-off algorithm defined in
[IEEE802154-2015] is used to resolve collisions. To ensure there is
enough bandwidth available on the minimal cell, a node implementing
MSF SHOULD enforce the following rules for broadcast frames:
1. send EBs on a portion of the minimal cells not exceeding
1/(3(N+1)), where N is the number of neighbors of the node.
2. send any other broadcast packets on a portion of the minimal
cells not exceeding 1/(3(N+1)), where N is the number of
neighbors of the node. For example, the broadcast DIO and DIS,
IPv6 Neighbor Discovery (ND)[RFC4861] and any other application
layer broadcast packets.
The RECOMMENDED behavior for sending EBs is to have a node send EBs
with a probability of 1/(3(N+1)). The RECOMMENDED behavior for
sending DIOs is to use a Trickle timer with rate-limiting. There is
no recommendation behavior for sending any other broadcast. However,
the traffic portion of all broadcast packets on minimal cell, except
EBs, MUST not exceed 1/(3(N+1)).
Here is Xavi's comment on this:
xavi> here we place a SHOULD and not a MUST. We want to make sure the
xavi> network works as if there is over-use of the minimal cell
xavi> collapses. We think this should be said here so an adopter is
xavi> aware of the limitations and implements a working measure.
https://mailarchive.ietf.org/arch/msg/6tisch/3SrQj7LXzfFZUSEYasWcwGSrFRM
I'd like to hear what others think :-)
Aside from that, it's unclear how to implement "Trickle timer with
rate-limiting", and having such a modification to Trickle is
discouraged by RFC6206:
https://tools.ietf.org/html/rfc6206#section-6.7
[SAX Configuration]
How can a mote know what values should be used for l_bit and r_bit? Do
we assume they are configured offline? Or they can be advertised in
EBs?
Appendix B. Example of Implementation of SAX hash function
(snip)
For interoperability purpose, the values of h0, l_bit and r_bit in
Step 1 and 2 are configured as:
o h0 = 0
o l_bit = 0
o r_bit = 1
The appropriate values of l_bit and r_bit could vary depending on the
the set of motes' EUI64 address. How to find those values is out of
the scope of this specification.
Additionally, it'd be nice to have test vectors of the SAX computation
with the set of parameters (h0=0, l_bit=0, r_bit=1) for
interoperability.
[Autonomous Cell]
We need a clearer description on the two types of the autonomous cell:
3. Autonomous Cells
MSF nodes MUST initialize Slotframe 1 with a set of default cells for
unicast communication with their neighbors. These cells are referred
to as 'autonomous cells', because they are maintained autonomously by
each node. To distinguish from the autonomous cells, the cell
scheduled by 6P transaction is defined as 'managed cells'. How to
schedule managed cells is detailed in Section 5. For autonomous
cells, each node has:
o One cell at a [slotOffset,channelOffset] computed as a hash of the
node's EUI64 (detailed next). The cell options for this cell are
TX=1, RX=1, SHARED=0.
o One cell at a [slotOffset,channelOffset] computed as a hash of the
EUI64 of the Join Proxy or each neighbor in the IPv6 neighbor
table (detailed in Section 4.4 and Section 4.5). The cell options
for this cell are TX=1, RX=1, SHARED=1.
- put the labels of "autonomous non-SHARED cell" and "autonomous
SHARED cell" to the itemization: the first one is "autonomous
non-SHARED cell", the second one is "autonomous SHARED cell"
- tell what to set to NodeAddr (neighbor addresses) of these cells; I
presume NodeAddr is not set for the autonomous non-SHARED cell, and
the MAC address of the neighbor is set for the autonomous SHARED
cell
I'd like to have some explanation why we can set SHARED=0 for the
autonomous non-SHARED cell whose slot offset and channel offset are
actually shared with its neighbors.
[Editorial]
s/time offset/slot offset/
s/Joining Request/Join Request/
---
That's all.
Thanks!
Yatch
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
