Thanks a lot Yatch, for the comments! I will answer your comments inline.
On Mon, Mar 18, 2019 at 3:50 PM Yasuyuki Tanaka <yasuyuki.tan...@inria.fr> wrote: > 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. > 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. > > 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. > 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. > > 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". > There is no risks on cell allocation, right? I assume the allocation here you are saying is about the neighbor table entry 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. > 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? > > > 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 :-) > I am with Xavi for this comment. would like to hear more comments as well! > > 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 > > So just using a regular trickle timer algorithm? I agree with that. > > [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? > This is a pre-configured (offline) for interoperability purpose only. > > > 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. > Yep, I could add it in next version. Thanks for the comments! > > [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 agree with what you said above. I will fix it in next version. > > 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. > 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. > > > [Editorial] > > s/time offset/slot offset/ > s/Joining Request/Join Request/ > > --- > > That's all. > Thanks so much for the review and comments! > > Thanks! > Yatch > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > -- Chang Tengfei, Pre-Postdoctoral Research Engineer, Inria
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
