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