Jonathan - until we start to get into stateful header compression, all
of the information that is covered in the L4 checksum is covered by the
L2 MIC. It may be in a different form, but it's all there.
I'm far more concerned about corruption due to RF communication problems
than I am about corruption due to incorrect algorithm implementation.
No matter what we do, bad implementations will always be a problem -
what if my mote calculates the checksum properly, but swapped some bytes
in the message formation before calculating the checksum, or just
generated the wrong command packet in the first place? Those are errors
of comparable simplicity to not being able to compress or decompress the
6LoWPAN header properly. There's a long list of simple mistakes that
can be made by a node that aren't going to get caught by either an L4
checksum or an L2 MIC. Intermediate routers will always have an
opportunity to incorrectly accept a corrupted packet or transmit a
mutated one. Those aren't the errors that I'm worried about, because we
have some control over them. The ones that we can't control are the
ones that happen in the ether.
So I'll go back to my earlier question: given your concern about people
improperly compressing and decompressing, and the realities of low power
wireless in a shared ISM band, which do you think will have more end to
end errors?
A) n hops with L4 checksum
B) n hops with L2 MIC
Or maybe a better question is: does option B scare you so much that we
don't want to allow people to do it because it may corrupt our otherwise
flawless networks?
ksjp
Jonathan Hui wrote:
Hi Kris,
I'm still not seeing how L2 MICs negate the need for L4 MICs. L2 MICs
are verified and recomputed hop by hop, where as L4 MICs are not.
There are a couple reasons why L2 MICs do not cover all of the
functionality of L4 MICs. First, an intermediate router could
incorrectly accept a corrupted packet or incorrectly mutate the L2
payload yet compute a MIC that will indicate the packet is still
valid to the next hop. Second, the L2 MIC as currently defined by
802.15.4 only covers the bits contained within the frame. It does not
take in any knowledge of the upper layers. An L4 MIC necessarily
covers the IPv6 pseudo-header and does so in 6LoWPAN even if some of
those bits are elided.
The only case I see where the L2 MIC covers every bit of
functionality an L4 MIC might provide is if the IPv6 datagram is
carried uncompressed within the L2 frame and communication occurs
within link-local scope.
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
