I respectfully disagree Tero: The fact that the MIC provides a protection against transmission errors cannot be ignored. 2 octets CRC is really weak. Consequences of undetected errors can be anything. CRC errors have blocked transcontinental lines in the past, and there is no bug fix for them. You have to change the protocol when you do things wrong. I have seen that happen.
When we have billions of devices, that will be millions of networks, that's thousands of undetected EB transmission errors every whatever period makes sense. Do we have an analysis of what any combination of bits that are wrong in a beacon may cause when undetected? We want a better CRC but we have short frames. We do want to benefit from side effects even if that means imperfections on architecture. An example of that is at a different layer that the UDP checksum can be elided in 6LoWPAN if there is a MIC in the packet that provides better protection (RFC 6282). Cheers, Pascal > -----Original Message----- > From: Tero Kivinen [mailto:[email protected]] > Sent: jeudi 7 mai 2015 15:24 > To: Pascal Thubert (pthubert) > Cc: Michael Richardson; [email protected] > Subject: Re: [6tisch] Shipping minimal > > Pascal Thubert (pthubert) writes: > > But then, if the JN does not know K1, how can it validate the MIC? > > It does not need to validate it. MIC is security feature, it is not meant to > be used > to protect against transmission erros, even when it will also detect those. > > Your comment would be about the same as saying: The IPsec/AH provides the > 96-bit ICV, and if the other end does know the key (or we do not use the AH at > all), how it can know that it received the TCP packet properly. > > > Do we have another way to protect against transmission errors on EBs? > > Yes. Same as we normally use for non-secured frames. The level of protection > provided depends on the PHY used. It might either be 2-octet FCS, or it might > be > 4-octet FCS, or it might be some kind of forward error correction code (FEC) > etc. > > None of these feaures are disabled when we enable the security. I.e when we > receive the the secured frames we first check the FCS, if that is right, then > we go > through the filterin rules to see if is for us, and if it is meant for us, > only then we > do security processing. For the beacons received during active/passive > scanning > there is special case that even if the security processing fails, we still > use the > contents of the beacon, for other cases if the security processing fails, we > drop > the frame (of course the 802.15.4e does not say whether you still process the > IEs included in the frame). > -- > [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
