Subject: [6tisch] draft-ietf-6tisch-msf-02.txt is published

From: Tengfei Chang <[email-masked]>
Date: Mon, 11 Mar 2019 18:52:45 +0100

Dear all,

draft-ietf-6tisch-msf-02.txt  is just published.

The main changes made in this version are

   - Resolve the issues in Pending Elements section.
   - Using autonomous SHARED and non-SHARED cells.
   - Overall revised the specification.

Additional information about how the issues in the pending elecments
section are resolved is written below.  (issues are separated by "=")

Any reviews or comments are welcome!

Tengfei

Security issue on autonomous cell installation
====================

The autonomous cell to the pledge is installed on the join proxy before the
pledge is authorized, which is a security issue. Related discussion: ttps://
mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao

[Resolved. During join process, only pledge required to install autonomous
SHARED cell to JP, no action required from JP side.]

Handling the case when bandwidth allocation exceeds available capacity
====================

When node A initializes a 6top ADD transaction to node B, but node B does
NOT have enough bandwidth to allocate.
What can node B do to indicate this case in its 6top response, and how
should node A handle the packet after receiving the response?
Related discussion:
https://www.ietf.org/mail-archive/web/6tisch/current/msg06095.html

[ToDo. According to 6top RFC8480, SUCCESS return code will be in the 6top
response with an empty cellList possibly. For this case, I don't have a
prefect solution. One solution I am using is marking the node B as
'no_resource', then updating it's routing table and filtering out the
neighbor marked as 'no_resource'. However, this is a layer-violation
design.]

joining traffic MUST be sent in minimal cell
====================

Joining traffic MUST be sent in minimal cell.
Issues link: https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/11

 [Resolved. Joining traffic will be sent on autonomous cell.]

NumCellsElapsed  shouldn't update on shared dedicated cell
====================
    NumCellsElapsed  is used to track under/overuse of cells.
    If we are backing off, i.e. skipping cells, should those skipped cells
count towards NumCellsElapsed ?
    Issues link:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/13

    [Resolved. The counters are only applied on managed unicast cell.]

non-trusted packet shouldn't be accounted for for adapting traffic
====================
    Mention that the untrusted packet (e.g. join request/response)
shouldn't be counted for adapting the traffic.
    Issues link:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/15

    [Resolved. clarified in adapting traffic section.]

Customize the backoff exponent on dedicated shared cell.
====================
    Use small backoff exponent on dedicated cell since it's only shared by
two nodes.
    Discussion: do we still have this case with the merger of ASF?
    Issues link:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/17
    [NotApplied. After ASF is merged, the dedicated shared cell is not used
anymore. The autonomous SHARED cell is shared among a set of neighbors
hence no need to customize the backoff exponent.]

Adapting 6P Timeout
====================
    After 6P TIMEOUT, the next 6P transaction should be configured using a
larger TIMEOUT.
    Issues link:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/19

    [ToDo. I am not sure this is an issue or not with current version. Need
to discuss with Malisa and Simon.]

Timeout calculation is wrong
====================
    The 6P Timeout is calculated as :
    list style: symbols

    (1/(C+1))*(1/PDR)*SIXP_TIMEOUT_SEC_FACTOR

    It should be
    list style: symbols

    (1/(C+1))*(1/PDR)*SIXP_TIMEOUT_SEC_FACTOR

    according to the paper: https://arxiv.org/pdf/1507.05810.pdf
    Related link is at:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/22

    [Resolved. The comments are taken and applied in the text.]

Separate Cell Counters for TX and RX
====================
    NumCellsUsed and NumCellsElapsed counter should be separated between TX
and RX.
    Question: still applies?
    Related Link is at:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/20

    [Resolved. The comments are taken and applied in the text.]

Two slotframes
====================
    Why are they two slotframes in same length?
    Issues link:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/25

    [Resolved. The length of two slotframes are SHOULD be the same, instead
of MUST.]

Parameters for SAX is missing
====================
    It'd be nice to have an example or a test vector in the draft in order
to validate a SAX implementation used for MSF.
    This is critical for interoperability.
    Related discussion:
https://mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao

    [Resolved. An appredix of how to implement the sax is added.]

Wrong end state statement
====================
    In Section 1, one of the end states of the join process is having "one
default unicast cell to/from each of its neighbors".
    It should be an autonomous TX cells to its Join Proxy.
    Related discussion: hhttps://
mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao

    [Resolved.Comments are taken and applied in v2.]

Dependency on RFC8180 shouldn't be a MUST
====================
    Section 2 states
    "A node implementing MSF MUST implement the Minimal 6TiSCH
Configuration [RFC8180], which defines the "minimal cell", a single shared
cell  providing minimal connectivity between the nodes in the network".
    MUST here is too strong.
    Some may want to use MSF with a base schedule other than the one
defined in RFC8180, with full understanding on the implications by not
following RFC8180.
    Proposal is to replace MUST by SHOULD.
    Related discussion:
https://mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao

    [Resolved. Comments are taken and applied in v2.]

DIO can be unicast packet as indicated in RFC6550
====================
    Section 2 states
    "DODAG Information Objects (DIOs), defined by [RFC6550].  These are
broadcast frames."
    However, the DIO as a response to a DIS is a unicast frame.
    Related discussion: hhttps://
mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao

    [Resolved. Comments are taken and applied in v2.]

Rules for broadcast frames is out of scope of MSF
====================
    In Section 2, the rules for broadcast frames on the minimal cell seem
to be an implementation-specific optimization.
    And it is beyond of the scope of this draft.
    This idea is about how to use the minimal cell efficiently; it's not
directly related to how to use cells scheduled by MSF.
    Related discussion:
https://mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao

    [ToDo. I agree with this comment. Should we remove those text or keep
them in the draft but mentioned those rules are not a MUST but a
RECOMMENDED?]

Wrong statement in Step 4
====================
    In Section 4.4 Step 3, the statement "After joining" in the explanation
of step 3 should be "After having chosen a JP"?
    At this step 3, "joining" is not done.
    Related discussion:
https://mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao

    [Resolved. Comments are taken and applied in v2.]

Rephrase NumCellsElapsed  to NumCellsElapsed
====================
    Rephrase NumCellsElapsed  to NumCellsElapsed
    Issues link:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/14

    [Resolved. Comments are taken and applied in v2.]

Create a list of packets that be able to be sent on minimal cell
====================
    The current text enumerates explicitly EBs and DIOs.
    The other broadcast packets are not mentioned.
    For example: RPL DIS or application-layer broadcast?
    It should mention EBs and DIOs but also say "any other broadcast
packet".
    Issues link:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/24

    [Resolved. Comments are taken and applied in v2.]

Clarify term 'dedicated cell'
====================
    Terminology: "dedicated" needs to be clarified in MSF.
    Issues link:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/26

    [Resolved. dedicated cells are not used in v2. The type of cell used in
the specification are autonomous non-SHARED cell, autonomous SHARED cell
and managed unicast cell.]

text is missing
====================
    The text that describes the 6P command with cell options etc. was
accidentally removed.
    Needs adding back somewhere.
    The text was:
    Step 5 - 6P ADD to Preferred Parent
    After having selected a preferred parent, the joined node MUST issue
    a 6P ADD command to that parent, with the following fields:
    list style: symbols
     CellOptions: set to TX=1,RX=1,SHARED=1
     CellOptions: set to TX=1,RX=1,SHARED=1
     NumCells: set to 1
     CellList: at least 5 cells, chosen according to Section 7
    /list>
    After the 6P Transaction is finished, the node MUST synchronize only
    to its preferred parent.  At this point, the node has a dedicated
    cell which allows for bidirectional communication with its preferred
    parent.
    Issues link:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/29

    [NotApplied. This comments is referring to the version before ASF is
merged.]

-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Mon, 18 Mar 2019 15:49:29 +0100

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:

[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

---

From: Tengfei Chang <[email-masked]>
Date: Mon, 18 Mar 2019 19:22:43 +0100

Thanks a lot Yatch, for the comments!

I will answer your comments inline.

> autonomous SHARED cell to a pledge during its secure joining process.

For Step 4, the node already securely joined the network.
The neighbor referred to the neighbor who has already joined the network.
There is no action for pledge at this step.

> in order to send back a join response, doesn't it? I may miss

For security issue, the address of pledge will not be recorded in neighbor
table.
The JP will get the nexthop address from the layer 3 source address, hence
send back the join response.
I don't know whether there is a specification for how the neighbor table
should be managed.
If no, I think PERSONALLY it's better not keeping the address from pledge
in neighbor table.

> and may suggest a mitigation technique such as "on-demand allocation".

There is no risks on cell allocation, right?
I assume the allocation here you are saying is about the neighbor table
entry allocation?

> expect text describing how to handle packets having code point AF42 or

Yes, I was just thinking the join request/response between JP and pledge
since they are only sent on autonomous cell which won't effect the traffic
adaptation.
But it does between JP and JRC. I will state that. But I have a question
maybe something I haven't followed before, how the node who already joined
the network knowing the packet it forwarded is a join request/response?

> I'd like to hear what others think :-)

I am with Xavi for this comment. would like to hear more comments as
well!

>     https://tools.ietf.org/html/rfc6206#section-6.7
So just using a regular trickle timer algorithm? I agree with that.

> we assume they are configured offline? Or they can be advertised in

This is a pre-configured (offline) for interoperability purpose only.

> with the set of parameters (h0=0, l_bit=0, r_bit=1) for

Yep, I could add it in next version. Thanks for the comments!

>    the MAC address of the neighbor is set for the autonomous SHARED

I agree with what you said above. I will fix it in next version.

> actually shared with its neighbors.

What I think of is the SHARED bit feature is a technique we could perform
back-off algorithm among multiple devices.
But not the other way around that if there are multiple devices accessing
the same  medium , then all nodes must use SHARED bit to 1.
With the 6P context, if all nodes are set as SHARED, the 6P response will
be conflicted with other 6P requests. This could easily cause 6P timeout
with a large number of 6P requests. (This is what I experienced during
experiments).

However, I didn't find in 802.15.4-2015 standard specification which saying
I can do that, (by searching shared/shared link) but as well didn't find in
the specification saying I can not. (let me know if you or anyone find it
in case I missed).
For 4th paragraph below Figure 7-54 at page 189 in the specification:

"The shared link is one that uses contention to access the medium."

I understand the sentence as SHARED or NOT is depending on the way how we
use it.

> s/Joining Request/Join Request/

Thanks so much for the review and comments!

>
> Thanks!
> Yatch
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 21 Mar 2019 16:25:06 +0100

Thank you, Tengfei.

Additional and following-up comments:

[Section 5.1, what to do after timeout of a 6P transaction]
https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-5

The draft does not say anything about how to handle timeout of a 6P
transaction. I know, the initiator of the timed out transaction will
resend a 6P request to the same peer ;-) But, it's better to mention
that as well as the maximum number of retries if we have.

[Section 9, 6P Timeout Value]
https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-9

A couple of questions:

- "C" includes the autonomous cell to the neighbor or it is the number
   of the managed cells?
- How can the timeout value be calculated while PDR is not available?

[Section 4.5, Step 4 of the bootstrap process]
https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-4.5

tengfei> I don't know whether there is a specification for how the
tengfei> neighbor table should be managed. If no, I think PERSONALLY
tengfei> it's better not keeping the address from pledge in neighbor
tengfei> table.

Although the actual way to manage neighbor information is
implementation-dependent, the minimal security framework draft
suggests to have separate memory for joined nodes and for pledges
respectively:

https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-6

Again, my comment on Section 4.5 is just that, I think we need some
text in "Security Considerations" section for this operation described
in Step 4. And, it seems the term of "the neighbor table" in the Step
4 is ambiguous. Some may think it's IPv6 neighbor cache, some may
think L2 neighbor table.

[Appendix-B, SAX configuration]

tengfei> This is a pre-configured (offline) for interoperability
tengfei> purpose only.

It's better to mention how a pledge gets the SAX parameters used in
the network where it is trying to join. There are always two options:

- pre-configured
- advertised in EBs

Best,
Yatch

---

From: Tengfei Chang <[email-masked]>
Date: Thu, 21 Mar 2019 17:23:24 +0100

Hi Yatch,

Thanks for the following-up comments! I replied inline below.

> that as well as the maximum number of retries if we have.
Comment accepted!

> - How can the timeout value be calculated while PDR is not available?
I agree that those questions are not clear for the current version.
As the current version allows 6P to send on the autonomous SHARED cell
mentioned in the draft (MAY send on the Managed Cell as well, as mentioned
in the draft.), the PDR value is not realistic.
The calculation of TIMEOUT in the draft MAY not apply anymore.

Instead of a complex calculation, I propose to use a fixed value.
The value is the worst case to have a 6P response received on the
autonomous SAHRED cell after maxmium re-tries.
The worse case means each time when 6P response is failed to send out, it
back-off with the largest number of cells (autonomous SHARED cell).
Since there is only one autonomous SHARED cell each node, the node will
wait for the same number of slotframes.

The calculation is like:

for maxmium 3 retries:

backoff exponent start from 2 and increase each re-transmission

6P Timeout = slotframeDuration * (1 +  (2^2-1)+(2^3-1)+(2^4-1)  )

> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-6

I see. I am not sure using a neighbor cache is able to avoid the DoS attack.
My intuitive thinking is the neighbor cache still has a fixed size.
If an attacker sends multiple join requests with fake eui64 address in the
packet, it can still fill up the neighbor cache, which blocks other pledges
to join.

This maybe need to discuss with minimal security scope as well.

> 4 is ambiguous. Some may think it's IPv6 neighbor cache, some may

I agree!

> the network where it is trying to join. There are always two options:

Agreed.