[6lo] Review of draft-kelsey-6lo-mesh-link-establishment

[peter van der Stok <[e-mail]>]

Hi Robert,

Below my review of the mle draft.
The way the draft removes unreliable links looks really great and must 
be very useful.
However, I got muddled about the security aspects. I hope my questions 
help solve the issues I had.

Greetings,

peter
____________________________________________________________________________________________________

Abstract
Three capabilities: Put 3) as first. Difference between 2) and 1) is not 
very clear.
A full stop (.) is needed between …. configuration. MLE….
Section 1 Introduction.
1st al.
A reference to existing 802.15.4 MIB RFC7388 would help, and also an 
explanation why this is not sufficient.

3rd al
MLE can also be used……across a network identified by its channel and PAN 
ID.
Forwarding with simple flooding (you mean TRICKLE ?)
If ZigBee IP standard reference is needed, should “thread” not be 
mentioned as well?
Section 4:
Last line page 4, remove: before…….them.
Section 4.1:
1st al: Again what is relation with RFC7388. Is an extension to 7388 
sufficient?
2nd al. This is very terse, and completely incomprehensible to anyone 
not familiar with 802.15.4 security standards section. And even then I 
wonder what is meant. More motivation would be welcome (probably 
including an example)
Section 4.2
Relation with draft-ietf-roll-mpl-parameter-configuration-07 needs to be 
clarified.
Section 5.
It will be helpful when the draft explains how neighbours use link 
security and how MLE uses 802.15.4 security for the MLE messages. Do I 
understand correctly that a link can be secured with 802.15.4 mechanisms 
and MLE uses 802,15.4 mechanism on the MLE message sent over this 
secured link? In fact the MLE message is secured twice once at UDP level 
and once at link level?
The figure is encouraged to include the MAC layer as well.
Section 6.
Why still use TLV at this stage. In other wgs the use of CBOR is 
considered advantageous.
Section 7
Is it wise to start with type = 0,  not better to start with type=1, to 
reduce error scenarios
Section 7.6
Because the MLE message containing this TLV is sent within a 802.15.4 
frame, the frame counter in the TLV must be identical to the frame 
counter in 802.15.4 header? Is that not superfluous?
Does this mean that MLE uses key1 + frame counter and link uses key2 + 
frame counter with key1 NEQ key2?
Section 7.7: Add a reference to section 12.
Section 7.8: is link parameter, or interface parameter not a bitter 
title?
The consequences of modifying the PAN ID or channel number are not clear 
to me. Can there be some explanatory text on this aspect?
To what 802.15.4 parameter does Permit Joining correspond?
Section 7.9: I thought MLE frame counter is equal to link frame counter, 
so why two separate ones?
Section 8, 1st al: do you mean realm-local or admin-local ? see also 
section 11
Section 8. This description really needs more text and probably some 
examples and should be better related to section 5.  A scenario 
describing the process in full would be really helpful.
Section 9 2nd al. What are “reserved command type values”?
Section 9 3rd al. As in section 8, What does joining the network mean? 
If I understand correctly that means that a network with a PAN ID has 
been formed, and a secured network segment exists with neighbours 
communicating over 802.15.4 secured links and another unsecured segment 
with neighbours which communicate over unsecured links. Joining means 
that a node from unsecured segment leaves the unsecured segment and 
joins the secured one. Under what conditions can a node in a secured 
segment communicate with a node in the unsecured segment?
In addition, does joining also mean that secured MLE messages MUST be 
exchanged? Can there be MLE secured messages which are transported over 
unsecured links? As pointed out earlier, I miss the overview.

________________________________________________________________________________________________________________

-- 
Peter van der Stok
vanderstok consultancy
mailto: [e-mail]
www: www.vanderstok.org
tel NL: [phone]     F: [phone]