Pascal Thubert (pthubert) writes:
> I’m interested specifically of the value of a well-known key MIC
> that will perform a Message Integrity Check on top of what FCS does.
>
> A 2-octet CRC has a chance out of 64K to miss an error that involves
> more than one bit transmission error. That is low. Very low in fact.
But that errornous frame needs to hit to EB, and it also needs to be
something that still parses properly by the upper layer, and the error
needs to be something that actually affects something. As we have not
analyzed what wrong values in different fields in EB can cause, we
cannot really say what it could cause.
> It is really a residue from a past that ended up being no worries as long as
> there is an additional digital hash like a UDP checksum or a security
> signature in the frame/packet.
UDP 16-bit one's complement checksum is much weaker than 16-bit FCS we
use in here. Also most bit errors in the EB will cause the frame to be
dropped also.
> The EB does not carry a layer 3 or 4 checksum. The MIC is the only
> coverage beyond FCS. I’m not happy to drop that unless a careful
> study has been done on the impact of random bit errors in an EB…
For each field in EBs:
MHR.Frame Control field:
Most bit errors here will cause frame to be ignored (wrong
version, wrong frame type, wrong bits on or off (frame
pending, ar, ie present), wrong security enabled field, wrong
addressing modes).
MHR.Sequence number:
No problem. Not used during joining.
MHR.Addressing fields:
Wrong coordinator address / PAN ID => join will fail
immediately when device cannot connect coordinator. Will move
to next EB.
MHR.Auxiliary security header.Security Control:
If Key Identifier Mode or Frame Counter Suppression fields
have wrong vales the length of the Auxiliary security header
do not match, which will cause either some IEs to be ignored
(because they were consumed as part of Auxiliary security
header) or having extra junk in IE list. Both of those will
cause the frame parsing to fail.
MHR.Frame Counter:
Not present in TSCH, but if Frame Counter suppression is not
on, this will consume 4 bytes from the IE list, thus causing
IE list parsing to fail.
MHR.Auxiliary security header.Key Identifier
Not used during the joining process, as we do not have key. If
KeyIdMode in Security Control Field is wrong this will either
consume extra bytes or add junk to IE list, which will cause
IE parsing to fail.
MHR.Header IEs:
If the Header IE Termination 1 IE is not there the rest of IEs
are parsed as Header IEs which will cause the IE frame parsing
to fail.
MHR.Payload IEs:
If the first IE is not MLME nested payload IE the rest of the
IEs will be parsed incorrectly thus IE frame parsing will
fail.
MHR.Payload IE.TSCH Syncronization IE:
If ASN is wrong frames sent after this will most likely have
wrong channel hopping number, meaning wrong channel. Also all
frames sent with security will be silently ignored by
recipient. Most likely the coordinator will not hear the
frames sent by the joining node, thus joining node will give
up and try next EB. This might get fixed up automatically when
the device is joining the network and hears next EB.
If Joining priority is wrong the device might join some other
device which is not optimal. This should still work.
MHR.Payload IE.TSCH TimeSlot IE:
If the Timeslot ID is not 0, then the joining node most likely
will not know the proper parameters for the network as it has
only Timeslot ID 0 configured. If full parameters are given
then the timing of the network settings are wrong. Some of
those do cause so that no communications is possible (sender
sending at wrong time, wrong timeslot duration), and some of
those can cause the network to get messed up (i.e. sender
thinking the ack wait time is differnet or something like
that). Some invalid values do not affect anything. If no
communications is possible then joining node will move to next
EB. If communications is possible, values here might get fixed
when it receives new EB with correct values.
MHR.Payload IE.Hopping timing IE:
Ups, I do not think this should be here at all, Instead of
this there should be Channel Hopping IE. I got confused as the
bitbucket example had short MLME nested IE with id of 0x1d which is
Hopping Timing IE instead of long MLME nested IE with ID of
0x9.
MHR.Payload IE.Channel Hopping IE:
If the Hopping Sequence ID is wrong then the hopping sequence
is wrong, thus no communications is possible, thus joining
node will give up and move to next EB.
MHR.Payload IE.Slotframe and Link IE:
If Number of Slotframe is wrong then the IE length do not
match, and parsing will fail.
If the Slotframe handle is wrong it does not cause problems as
it is not really used. This might get fixed when next EB is
received.
If the Slotframe size is wrong then the device is sending on
the wrong time, and coordinator might not listen to him, but
he will cause collisions with other traffic. In the end
communications will fail and as he cannot hear EBs as he is
waiting them on wrong time, he will timeout and give up
joining and move to next EB.
If the Number of Links is wrong, the IE length do not match,
and parsing will fail.
If the Timeslot or Channel Offset are wrong the communications
will fail as device is sending/receiving on wrong channel or
at wrong time. He cannot hear EBs, thus will timeout and give
up joining process and move to next EB.
If link bits are wrong joining node does not have any suitable
link to send data to coordinator, thus cannot communicate and
needs to ignore this EB and move to next.
MHR.Payload IE.Payload IE Termination:
If this is wrong it will parsed as wrong IE, and most likely
IE parsing will fail.
So in most cases there is no real security problems, provided that the
next higher layer parses the IEs properly and verifies the lengths
etc. Also if any of the IEs are missing the EB will not have enough
information to be usable, thus it will get ignored.
Next the question is, which of these parameters can be changed while
the TSCH network is up. I think anything in the TSCH TimeSlot IE or
Channel Hopping IE cannot be changed while the network is running so
they might be ignored on EBs (on the other hand nothing in the 15.4
says that this is required). TSCH Syncronization IE should most likely
be ignored after the device has successfully syncronized with the
network.
But the Slotframe and Link IE is something that can be updated
dynamically and coordinator can add/remove or modify links. I.e every
node in the network is supposed to keep track of those and if attacker
sends Slotframe and Link IE changing the Slotframe size from 101 to
102 this will cause the whole network to be messed up...
In section 6.3.6 TSCH PAN formation of 802.15.4-D00 (5.1.2.6 in
802.15.4e) there is text which says:
After joining, the device may receive additional slotframes
and links from a higher layer management entity or peer as
required by the application, or the device may be instructed
to remove slotframes and links obtained from the Enhanced
Beacon.
Or just changing the share dslot timeslot or channel offset to wrong
will also cause devices to loose EBs, or removing all the shared
slotframes.
So this is at least something that is needed also during the
production use of the network, and which would really require that EBs
are properly protected. Or we need to explictly forbid changing those
in 6tisch unless K1 is proper key.
On the other hand this does not affect joining process, as if those
are wrong joining will simply fail, and joining node moves to next EB.
--
[email protected]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
