Hi Jonathan:
It is always great to recount anecdotal evidence. However, I fail to see
why this should necessarily apply to 6tisch.
The question is what constitutes a proper mechanism for network
segregation. This technical topic was discussed in Section 1.2, item #8
of the draft
draft-struik-6tisch-security-architectural-considerations-01, where it
was suggested that this relates to filtering based on checking the
"language of well-formed frames" (see 2nd starred item in 1.2, #8). In
fact, some of the language in that section re IE header fields were from
Kris Pister (see acknowledgement in Section 3, p. 16).
Once again, may I suggest, as I did in my email of April 24, 2014,
9.47am EDT, to first read that draft and only bring up topics not
already dealt with there?
[excerpt email RS as of April 24, 2015, 9.47am EDT]
I did notice lots of emails surrounding 802.15.4 security (or
perceptions thereof), but I do not entirely understand the background of
these emails.
Since some emails seem to repeat similar discussions in December 2014
(including confusions and misconceptions of 802.15.4 security), I would
like to encourage everyone to read the draft
draft-struik-6tisch-security-architectural-considerations-01 (posted
January 9, 2015). I wrote this draft partially in the hope that we would
not have the very repeat of arguments we now seem to witness. So, I
highly recommended reading that 3 1/2 months old draft and only bring up
topics not already dealt with there.
Best regards,
Rene
On 5/7/2015 6:01 PM, Jonathan Simon wrote:
Once again I will repeat an old story…
We went to a Zigbee demo with our pre-WirelessHART product, which uses MICs to
authenticate both the equivalent of Beacons (called advertisements in WH) and
data traffic.
The Zigbee networks fell apart in our presence, while we operated fine. The
reason why was that the Zigbee networks did not use MICs, and were interpreting
some of our data traffic as coordinator realignment frames, causing their nodes
to change channel.
No protocol owns the airwaves - any protocol that does not anticipate random
frames arriving that look like valid instructions, and taking at least minimal
steps to avoid this problem (i.e. authenticating frames with SOME key), is
poorly designed.
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
--
email: [email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
