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

From: peter van der Stok <[email-masked]>
Date: Mon, 14 Sep 2015 12:40:41 +0200

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: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 21 Sep 2015 15:55:18 +0000

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).

> 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.

> 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.

> 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.

> 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

The draft describes MLE as used in ZigBee IP, not as it is used
in Thread.  

> 1st al: Again what is relation with RFC7388. Is an extension to 7388

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.

> 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.

> secured link? In fact the MLE message is secured twice once at UDP 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.

> Why still use TLV at this stage. In other wgs the use of CBOR is

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.

> Is it wise to start with type = 0,  not better to start with type=1, to

I don't see how that helps.

> 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.

> 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

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.

> 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.

> 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

Realm-local.  This nees to be fixed in the draft.

> 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.

> 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

________________________________________
From: peter van der Stok [[email-masked]]
Sent: Monday, September 14, 2015 6:40 AM
To: robert cragie; [email-masked]
Subject: [6lo] Review of draft-kelsey-6lo-mesh-link-establishment

Hi Robert,

Greetings,

peter

Abstract

3rd al

---

From: peter van der Stok <[email-masked]>
Date: Tue, 22 Sep 2015 10:17:37 +0200

Hi Richard,

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

> ZigBee IP and on the RFCs and drafts that were available at the
<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>
> attempts and successes, which MLE does not do.
<pvds>
That is clear, but MLE can be used to exploit the statistics?
</pvds>
>    3) allowing the determination of radio link quality prior to

<pvds>
For me this is much clearer.
</pvds>
> transmission.  I don't see how this is relevent to management
<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)
>    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>
> sure what needs to be clarified.
<pvds>
Motivated by my earlier assumption that this version is a re-edit.
</pvds>
> You mean something like this?
<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>