Last Call Review of draft-kelsey-intarea-mesh-link-establishment-05
review-kelsey-intarea-mesh-link-establishment-05-secdir-lc-kelly-2013-09-19-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

From the abstract: "This document defines the mesh link establishment (MLE)
protocol for establishing and configuring secure radio links in IEEE 802.15.4
radio mesh networks." It defines a UDP-based protocol to configure radio links,
facilitate network-wide changes to radio parameters, and detect neighboring
devices.

The protocol is intended for IEEE 802.15.4 mesh networks, and it re-uses
features from this link-layer protocol. I haven't been keeping up with this
IEEE effort, so when I opened the draft I was a complete noob.

I have comments/questions about 3 things in the document:

1) The protocol mostly relies on the security mechanisms of 802.15.4, except
that it adds an anti-replay mechanism. This mechanism requires a a message
recipient to send a challenge to a newly-heard neighbor, and for that neighbor
to return the same challenge. The challenge is defined as a TLV. Although
RFC4086 is referenced for challenge generation, no minimum challenge length is
specified. Does that mean a one-byte random challenge is okay? Since the text
also says "A new value MUST be chosen for each Challenge TLV transmitted", you
probably want to specify a reasonable minimum length.

2) Section 5 says "MLE security MUST NOT use any key that is being used by the
link (or any other) layer." I think the point you're trying to make is that
because of CCM, key re-use is potentially toxic. It might be good to explicitly
state this.

3) Prior to the text just referenced, it says, "If MLE security is in use each
device MUST maintain an outgoing MLE frame counter for use in securing outgoing
packets in compliance with [CCM].  This MAY be the same frame counter used for
securing 802.15.4 frames; in this case the same counter value MUST NOT be used
for securing both an 802.15.4 message and an MLE message."

Maybe I'm just missing it, but I don't understand the need for MUST NOT here.
Since they must have different keys, what harm results from using the same
counter value in distinct protocols?

--Scott