(YFNP) and a over-the-air programming protocol (OTAP). One could argue that OTAP should not depend on YFNP in the case where you want to upgrade YFNP to YFNPng. Such incompatibility already exists with ZigBee 2006 and Pro. So for them to coexist in my network, I'll need to have two different keys, one for each protocol. When decoding a packet, I'll either need to try both keys and pick the one that works or rely on some common understanding of 802.15.4's key-identifier. The former is fairly inefficient. Maybe the argument is with appropriate hardware, we can efficiently apply a set of keys and have it return the one that worked, or none at all. Are there protocols operating on 802.15.4 that have scoped out more efficient ways of selecting the key to use? Or are you satisfied with the trial-and-error approach?
The problem is that you're trying to cross layer boundaries and IEEE 802.15.4 was never intended to allow such usage. IEEE 802.15.4 specifies a link key--a key that can be used to validate traffic between two hosts at the data link level. What you are describing is network keying, which is beyond the scope of IEEE 802.15.4. YFNP, YFNPng, and OTAP can all specify their desired security scheme and keying approach (for example, OTAP may implement a network-wide keying scheme while YFNP is a multicast protocol that uses group keying). Either way, these are concerns above the data link layer, and we should not confuse security at the network layer with security at the data link layer. -Joe _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
