Robert Cragie writes: > I am fine with the text in principle but I have a couple of final > suggested changes on the text just for clarity purposes. > > 1) It is not entirely clear to the casual reader whether an EB only > ever needs authentication or whether we are saying that is the only > security treatment it will get. It is important to distinguish as > the IEs are payload IEs which could indeed be encrypted but we > choose not to.
EBs CANNOT be encrypted in TSCH. To be able to decrypt the EBs the receiving node would need to know the ASN, but it cannot know it as the ASN would be in the encrypted part of the EB. Because of this EBs cannot be encrypted when using TSCH. This is fundamental property of the TSCH, it is not something we choose not to do. We should most likely explain this in the security considerations section (i.e. provide reason why data confidentiality service is not possible for EBs, and why only data integrity service can be provided). We should most likely also explain that even when data integrity service is provided for the EBs, the receiving devices are able to use EBs while joining the network even when they do not know the key used to protect the EBs. I.e. that 802.15.4 do have special rules that this is allowed even when normally frames which you do not have key for are dropped. When the IETF last call is issued and people not familiar with 6tisch, and for example the secdir reviewers read this document, they most likely do not have very good understanding what 802.15.4 does, thus explaining why we doing certain things as we do, and why certain issues are not a problem will help solving their comments, even before they have time to make them... I.e. if I would be doing the security considerations section and then started to look what is in the EBs, and what can attacker do by messing those things up, I would not find anything in the security considerations section that would give me answer. Btw, the attackers can do quite efficient denial-of-service attack, especially when using the full format of the TSCH Timeslot IE is used. I.e. it can send TSCH Timeslot IE saying that macTsTimeslotLength is for example 16 seconds (if 24-bit format of macTsTimeslotLength is supported), or otherwise se the time slot length for 65 ms. Then it can say in Frame and Link IE that size of slotframe is 255, thus meaning that the device can send one frame every 16.5 seconds. When it then tries to send association or any other messages to other end it will take 16.5 seconds for each frame, thus making the joining process REALLY SLOW, and most likely it will take minutes before the joining node gets so far that it notices that this is wrong network, and I should try to find the better one. Only using proper K1 would protect against that kind of DoS attacks. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
