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

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

Hi Richard,

thanks for the answers.
Some additional clarifications below in the text.

Richard Kelsey schreef op 2015-09-21 17:55:
> Peter, thank you for the comments.  As a general response, the
> draft is informational and describes MLE as it is used in ZigBee IP.
> Some of the choices made depended on the particular needs of
> ZigBee IP and on the RFCs and drafts that were available at the
> time (2009-2012).
<pvds>
Ok, I understand that. I thought there was a special reason beyond 
ZigBee/IP that motivated a possibly re-edited version of the draft.
</pvds>
> 
>> The way the draft removes unreliable links looks really great and
>> must be very useful.
> 
> Determining link reliability is not a primary goal of MLE.  That
> really requires collecting ongoing statistics about transmission
> attempts and successes, which MLE does not do.
<pvds>
That is clear, but MLE can be used to exploit the statistics?
</pvds>
> 
>> Abstract
>> 
>> Three capabilities: Put 3) as first. Difference between 2) and 1)
>> is not very clear.
> 
> 1) is concerned with configuring an individual radio link between
> two neighboring devices in a mesh.  It deals with the specific
> values for communication between those two devices. This is the
> primary purpose for MLE, which is why it is listed first.
> 
> 2) is for setting mesh-wide shared values, such as the channel
> or PAN ID.  This could be done in lots of ways.  ZigBee IP
> happened to use MLE.  Removing this functionality would not
> affect the rest of the protocol.
> 
> 3) is an optimization to make 1) more efficient.  It isn't
> strictly necessary.
> 
> I suspect the confusion between 1) and 2) is partly due to the
> multiple meanings of the word "link".  Would this be better?
> 
>    MLE extends IEEE 802.15.4 for use in multihop mesh networks by
>    adding three capabilities: 1) dynamically configuring and
>    securing radio connections between neighboring devices, 2)
>    enabling network-wide changes to shared radio parameters, and
>    3) allowing the determination of radio link quality prior to
>    configuration.

<pvds>
For me this is much clearer.
</pvds>
> 
>> 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.
> 
> RFC 7388 defines statistics for 6LoWPAN packet reception and
> transmission.  I don't see how this is relevent to management
> of 802.15.4 radio links.
<pvds>
The remark was made because the scope of MLE was nor clear to me.
And 7388 acquires statistics about link quality (derivable from lowpan 
packet statistics)
> 
>> 3rd al
>> 
>>  MLE can also be used……across a network identified by its channel
>> and PAN ID.  Forwarding with simple flooding (you mean TRICKLE ?)
> 
> The point here is that there is no dependency on the multicast
> forwarding protocol or on its being efficient.
> 
>> If ZigBee IP standard reference is needed, should “thread” not be
>> mentioned as well?
> 
> The draft describes MLE as used in ZigBee IP, not as it is used
> in Thread.
> 
>> Section 4.1:
>> 
>> 1st al: Again what is relation with RFC7388. Is an extension to 7388
>> sufficient?
> 
> Again, I don't see any connection to RFC7388's 6LoWPAN message
> statistics.
> 
>> 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)
> 
> How about the following:
> 
>    IEEE 802.15.4 security uses frame counters to detect replayed
>    messages.  Each sender maintains an outgoing frame counter
>    that is included in outgoing secured messages and is
>    incremented for each message sent.  Receivers store the
>    highest frame counter yet seen from each neighbor.  Messages
>    that arrive with a frame counter less than or equal to the
>    highest previously-seen frame counter are discarded.
> 
>    In a mesh network neighbors come and go as the mesh topology
>    changes.  When a message arrives from a previously unheard
>    neighbor, the receiver has no stored frame counter that can be
>    used to determine if the message has been replayed by an
>    attacker.  MLE solves this by providing a simple handshake
>    mechanism that allows the receiver to securely obtain the
>    sender's current outgoing frame counter.

<pvds>
Thanks, this helps a lot. I still think a scenario would help the reader 
focus quickly and better grasp the meaning of the later sections.
IMO the problem of the MLE message security is rather subtle and not 
immediately recognized.
</pvds>
> 
>> Section 4.2
>> 
>> Relation with draft-ietf-roll-mpl-parameter-configuration-07
>> needs to be clarified.
> 
> ZigBee IP, and thus the version of MLE described in the draft,
> predates draft-ietf-roll-mpl-parameter-configuration.  I'm not
> sure what needs to be clarified.
<pvds>
Motivated by my earlier assumption that this version is a re-edit.
</pvds>
> 
>> 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?
> 
> MLE messages secured at the UDP level are not secured at the
> link level.  I see that the draft does not state this explicitly;
> I'll fix this.
> 
>> The figure is encouraged to include the MAC layer as well.
> 
> You mean something like this?
> 
>  
> +------------+-----------+------------+-----+------------+---------+-----+
>  | MAC Header | IP Header | UDP Header |  0  | Aux Header | Command | 
> MIC |
>  
> +------------+-----------+------------+-----+------------+---------+-----+
> 
> I'm not sure I see the point.
<pvds>
I don't any more, because I was under the wrong impression that there 
was a relation between frame counter in MLE message and 802.15.4 header
and that the figure might illustrate this.
The phrase in 4.1: "..... The MLE message containing a neighbor's frame 
counter is not....." made me wonder what relation there was.
The phrase in 5 " CCM requires that each key and nonce pair be used 
exactly one, which is most easily achieved by using different keys"
suggested to me that the frame numbers would usually be equal.
</pvds>
> 
>> Section 6.
>> 
>> Why still use TLV at this stage. In other wgs the use of CBOR is
>> considered advantageous.
> 
> One reason is that ZigBee IP development predated the appearance
> of CBOR.
> 
> That aside, switching to CBOR would add considerable complexity
> to both the draft and to implementations.  I don't see what
> advantages CBOR would bring that would be worth the extra
> complexity.
> 
>> Section 7
>> Is it wise to start with type = 0,  not better to start with type=1, 
>> to
>> reduce error scenarios
> 
> I don't see how that helps.
> 
>> 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?
> 
> The 802.15.4 frame is not secured and does not have a frame counter.
> 
>> Does this mean that MLE uses key1 + frame counter and link uses key2 +
>> frame counter with key1 NEQ key2?
> 
> They use different keys.  From section 5:
> 
>    MLE security MUST NOT use any key that is being used by the link (or
>    any other) layer.
> 
> The two key counters may or may not be the same.  It may be, for
> example, that MLE may be running on a host processor while 802.15.4
> is running on an attached coprocessor.  This would make coordinating
> a single frame counter difficult.  On the other hand, if the two
> are running on a single processor, nothing is gained by requiring
> the the two counters be different.
> 
>> Section 7.8: is link parameter, or interface parameter not a bitter
>> title?
> 
> I don't think so, although "network" might not be the best term
> either.  These parameters apply to the entire mesh, not just a
> single link or interface.
> 
>> The consequences of modifying the PAN ID or channel number are not 
>> clear
>> to me. Can there be some explanatory text on this aspect?
> 
> Yes, I can see that more needs to be said here.
> 
>> To what 802.15.4 parameter does Permit Joining correspond?
> 
> The permit joining flag in the beacon header.
> 
>> Section 7.9: I thought MLE frame counter is equal to link frame 
>> counter,
>> so why two separate ones?
> 
> Practical considerations.  See the note on section 7.6 above.
> 
>> Section 8, 1st al: do you mean realm-local or admin-local ? see also
>> section 11
> 
> Realm-local.  This nees to be fixed in the draft.
> 
>> 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.
> 
> I agree that the description is too sparse.
> 
>> Section 9 2nd al. What are “reserved command type values”?
> 
> The currently unassigned values.  This needs to be made
> consistent with section 14.
> 
>> 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.
> 
> Starting to talk about joining opens a Pandora's box of issues,
> given how many different ways there are of handling joining.
> Better would be to leave it out of scope and remove this
> sentence:
> 
>    The one exception to this is messages sent to or from a
>    device that is joining the network and does not yet have
>    the necessary keys.
> 
> -Richard Kelsey
>