Jonathan - funny, that's just what I was saying a few months ago :)
As long as everyone agrees with Jonathan, all is well.
ksjp
Jonathan Hui wrote:
Kris, I think you're a bit confused on the purpose of the 6lowpan
header type. The header type is completely orthogonal to whether
people choose to utilize strong integrity checks. The dispatch type is
analogous to the Next Header field in IP packets. It gives flexibility
in constructing different header stacks, yet is easy to parse. Its
what enables IPv6 to support extension headers.
Robust networks always need strong integrity checks, but integrity
checks don't replace dispatch types.
--
Jonathan Hui
Kris Pister wrote:
Here's a thread from ISA that may be of interest. 6lowpan had some
email a few months ago on the topic of coexistence, and the level of
safety afforded by the dispatch byte. If you read Gerry's email
below, you'll see that once again this approach has proven hazardous
in a public forum. I'd say at least half of the WSN companies that
I've talked to have fallen victim to this (Dust included - back in
2003!).
ksjp
Kris Pister wrote:
This is an example of a very common problem seen in the early stages
of software development in sensor networks. Wireless HART does not,
and SP100.11a should not, suffer from it.
The general problem is that those unfamiliar with working in a
regulated but unlicensed band are not used to the idea that there is
a lot of traffic flying around at 2.4GHz, employing a wide range of
MAC protocols. More subtly, even well-formed packets in your own
network can be corrupted in flight in such a way that the frame
check sequence (FCS) does not catch the errors. In both cases, the
naive system will try to execute the instructions in a packet that
is essentially random, with disastrous results.
In TSMP (the basis of Wireless HART and SP100.11a data link layers),
the solution to this problem is to use a message integrity code
(MIC) on every packet. This 32 bit number is a cryptographic hash
of the entire packet, and prevents corrupted or foreign packets from
being accepted at the lowest layer of the communication stack, with
a probability of 99.99999998% (fewer than one in 4 billion get
through on average). For a reliable network, even this is not
enough, since undetected errors might occur on the order of once per
year per network.
Another 32 bit MIC is used at the application layer to verify the
authenticity of the sender of the message. Combined with the DLL
MIC, this reduces the probability of executing random packets to
something like once per age-of-the-universe per network. Even with
energy scavenging, that's a long time! :)
The lesson here is simple: never *ever* turn off crypto in your
networks. Use well-known published keys if you want to, but keep
the integrity codes in place.
ksjp
--
Prof. EECS, UC Berkeley
Founder & CTO, Dust Networks
________________________________
From: Gerry Nadler [mailto:[EMAIL PROTECTED]
Sent: Mon 10/29/2007 10:31 AM
To: ISA100
Subject: [sp100] interoperability problems at ISA Houston
Everyone:
On the evening before the ISA exhibition (Monday night) I visited
the show floor to see the ISA-100 booth. Most all the booths were
unmanned and all was quiet except for a small group in one booth
that was having problems. They were using Zigbee. Their Zigbee
system was not functioning due to some type of interference. (The
name of the company is not mentioned here because for the purpose of
this note it is not necessary). I walked by the booth and the
people were very frustrated as to the cause of their problem. I
tried to help. We set up a 15.4 packet sniffer to look at the
packets to see what was the cause of the problem. The vendor was
using Ember chips and software stack. We got the sniffer running
and looked at the packets and we saw the problem. There was nothing
we could do because the 15.4 stack was being corrupted by an illegal
packet(or so I thought at the time). The packets were sent to the
Ember software team for analysis and they made modification to their
stack and the vendor was up and running by the time the show opened
on Tuesday.
I walked around the show floor at about 11 PM at night and looked to
see who might be transmitting 15.4 packets. I checked the ISA-100
booth and the surrounding area and everything seemed to be shut
down. I walked up and down every aisle looking for a possible
transmission site. I didn't see anything except for the wireless
HART booth where there was "flashing LEDs", a possible sign of RF
transmissions. It could have been another Zigbee/SP-100
transmission site as well.
On Tuesday I stopped by the booth and Bob LeFort the president of
Ember was at the booth. We had a nice chat and when I got back home
I asked him if he could have his software people write up what they
found. Below is a short analysis of the problem written by the VP
of engineering at Ember. They did a great job and had the problem
diagnosed and fixed before Houston show opened the next day.
I have included this because depending on your point of view this
may be harbinger of things to come or it can be dismissed.. I
thought the group should know what we may or may not expect in the
future.
Gerry
Ember report by Skip Ashton, Ember VP Engineering.
The cause of the problem was an Ember device receiving a coordinator
realignment packet. Under the 15.4 specification, this packet is
intended to be unicast to an orphan device, or broadcast to a
network that is changing its parameters. Receipt of this packet was
causing the Ember device to change channels and PAN ID. The 15.4
specification requires this packet be sent with a 64 bit extended
address for the source. However, in this case the 16 bit
coordinator address for the source was being used making this an
illegal packet. This illegal packet to change PAN ID was being
generated by another network device at a regular interval.
Reception and processing of the coordinator realignment command is
mandatory within 802.15.4. However, it should be ignored by devices
that are using higher levels of control over items such as channel
change. A ZigBee network device is not expecting a coordinator
realignment. This command is not used to change channels within
ZigBee, because a higher layer network command is used instead. As
such, these type of MAC commands should be ignored.
A change was made to our stack to ignore such MAC command frames
once the ZigBee stack is operational.
--- You are currently subscribed to sp100 as:
[EMAIL PROTECTED] To unsubscribe send a blank email to
[EMAIL PROTECTED]
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
