[6tisch] Comments on draft-ietf-6tisch-msf-02 - Re: draft-ietf-6tisch-msf-02.txt is published

[Yasuyuki Tanaka <[e-mail]>]

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