Hi Tero: The thing we (seem to) disagree upon is whether this is minimal's problem.
I think it's everybody's problem and minimal inherits from it like everyone else and should not be the place where the security behavior is specified. I do agree, though, that it's good that we propose a minimal and simple set up for the purpose of interop tests. Like I said, I think that minimal should say that it depends on MAC layer packets to be secured appropriately to protect MAC operations and to guarantee authenticity of L3 content, but does not need specify how that happens. And because MAC layer packets are secured, RPL does not need to be so section 10 of RPL can be omitted by implementations. But because we do not seem to reach consensus on new text, I think along René's recommendation to fall back on the original text that reached consensus, suggesting a key "6tisch-minimal15" (string format + Hexa) to serve as K1 for the interop test. Do we have consensus on this? Pascal > -----Original Message----- > From: Tero Kivinen [mailto:[email protected]] > Sent: lundi 18 mai 2015 17:38 > To: Pascal Thubert (pthubert) > Cc: Michael Richardson; [email protected] > Subject: Re: [6tisch] Shipping minimal > > Pascal Thubert (pthubert) writes: > > We disagree on this pass but you have my arguments and I have yours. > > What's new is that we also disagree that this problem that minimal > > should deal with. > > What is this problem you are talking about here? > > > The problem has to do with a deployment decision that is made or not > > made elsewhere, and that may or may not be allowed by the security > > design. > > This does not yet tell me the problem you are now talking about. > > > If K1 is known to the joining node, even well-known, then the > > deployment can adjust the MIC size to make undetected transmission > > errors really-really rare. > > Yes, I agree that. On the other hand I do not think this is important for > minimal. I > would much rather use K1 to properly authenticate EBs AFTER the initial join > process, which requires it not to be well-known. > > > Thus the conclusion of our discussion so far is: > > - The poor frame error protection (FCS-only) is a generic problem that > > is only present if the security design allows for K1 to be unknown by > > the joining node. > > We are talking about few dozen frames DURING the initial bootstrap phase. You > need really crappy network to get that many errors which pass the FCS, to > cause > the bootstrap to fail, and even then you need bad implementation of the parser > who is parsing the frames to get messed up with those. If there is that crappy > network, then most likely the network will not work at all, as most of the > frames > will be dropped by bad FCS. > > I.e. if you get 1 wrong bit every 1000 bits, that means that you have an have > one > error in most of your full length frames. To get another error to the same > frame > in such way that the FCS still matches will still not be very probable. > Someone > can probably calculate that. > > Your case of there being billions devices out there all time, is not really > valid, as > there will be only few hundred of those billion devices doing "the once in the > lifetime joining process" at the same time (assuming 10 year lifetime of > devices > and joining process taking hundred seconds). > > We are not talking FCS protecting normal data traffic, we are talking about > the > FCS protecting the about 10-20 frames used during the bootstrapping phase. > Actually the joining process running KMP or similar will of course validate > all > data sent inside KMP when doing authentication, so the the frames where errors > can cause problem is the EBs. You need to get one EB received properly to be > able to start joining the network. Even in EBs, most of the errors will cause > the > frame to be ignored (i.e. if there is anything wrong with the IE lengths or > IE IDs > etc then frame most likely will be ignored). > > Even if EBs had errors, and because of that joining process failed, that > simply > means we start the process from beginning, and try again. > > > - The case of an attacker that is willingly settings bits wrong in > > EBs is present if the security design allows for K1 to be unknown > > OR well-known by the joining node. > > Yes, for joining. But for rejoining after you have already been part of > network, > or cases where network is reconfigured etc, having a proper K1 will prevent > attackers from doing nasty attacks, but using well-known K1 will not. > > > About your new points: > > > > > No, but it is much more likely to have the attacker flipping those > > > bits intentionally to get worst possible effect, than them getting > > > flipped randomly so that the FCS still matches. > > > > Why would he need to match the FCS? If the MIC is unknown then it can > > send whatever it likes and then compute a CRC over it. > > For attacker yes, but for random bit errors the case is different. > I.e. to get two random bit errors to same frame, so that FCS still matches, > does > not happen that often. > > The story about Zigbee and WireHART is completely different to that, as both > devices of course did calculate proper FCS, thus Zigbee devices did properly > receive the WireHART packets, and then got messed up when their > implementation didn't know what to do with them. > > > > I.e. the implementations MUST be able to cope with EBs having worst > > > possible values regardless wheter the EBs are protected by the > > > well-known key or no key at all. > > > > Is that written in 802.15.4? > > No, that is general wisdom of writing code. I know this is new to some people > writing code (especially in IoT space), but you really should validate stuff > that > you receive before you act on it... :-) > > > That is not an upper layer problem. > > Actually it is upper layers problem. I.e. when the device does scanning the > MAC > will simply pass beacons to the next higher layer and the next higher layer > will > then parse IE lists etc to check if the beacon is acceptable. I.e. this > filtering is > something we need to specify in 6tisch, as 802.15.4 does not provide that. > > > All that minimal should really have to say is that its security is > > only as good as the L2 security will be because there is no additional > > L3 security to protect, say, RPL. > > I.e if there is no L2 security because well-known key is used there is no > security > at all in minimal? > > > > And, yes the security considerations section of the minimal should > > > explain what kind of attacks can be done by sending "bad" EBs, and > > > how those issues can be solved. > > > > If we allow for well-known or unknown K1, yes, I agree that we need > > that analysis for anything 6TiSCH, not minimal specifically. > > So writing that now is something we should get ongoing. > -- > [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
