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

[Richard Kelsey <[e-mail]>]

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.

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

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

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

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

> 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

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

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]