Hi Pascal,
I'm confusing about what kinds of EB errors you want to detect. I think you
mentioned two kinds of errors:(1) Transmission error(2) Wrong EB from some
attacker.
Maybe there is third type of error?
I think everybody agree that CRC (or FCS) is used to detect (1), but can not
detect (2).I'm not sure what is the contribution from well-known key based MIC
to detect (1). But I do think the well-known key based MIC can not detect (2),
because the attacker can also make a legal MIC over a wrong EB with the
well-known key.
Do I miss something?
ThanksQin
On Tuesday, May 12, 2015 5:25 PM, Pascal Thubert (pthubert)
<pthub...@cisco.com> wrote:
Hello Tero:
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.
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.
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.
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.
- 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.
About your new points:
> > Do we have an analysis of what any combination of bits that are wrong
> > in a beacon may cause when undetected?
>
> 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.
> 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? That is not an upper layer problem. 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.
> 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.
Cheers,
Pascal
> -----Original Message-----
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: mardi 12 mai 2015 06:44
> To: Pascal Thubert (pthubert)
> Cc: Qin Wang (qinwang6...@yahoo.com); Michael Richardson; 6tisch@ietf.org
> Subject: Re: [6tisch] Shipping minimal
>
> Pascal Thubert (pthubert) writes:
> > 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.
>
> If you think it is too short, then you can select PHY that supports better
> error
> correction properties.
>
> Yes, MIC do provide better protection, but I doubt you really claim that
> 802.15.4
> cannot be used at all without security as it only uses 2-octet CRC?
>
> If that is really true, then perhaps the 802.15.4 should make security
> mandatory...
>
>
> > 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.
>
> Yes, and the issue will be what? When EBs are only used during the bootstrap
> process, then we are only interested in the few tens of seconds time window
> for
> the lifetime of the device. I.e. the joining node needs to receive ONE (1) EB
> properly before it can start joining the network.
>
> If this really is that big issue then implementations might keep on doing
> passive
> scan for longer and wait until they get for example 2-3 identical EBs from the
> same coordinator, and only after that try to join that network. This is
> something
> they can already do without any changes in any of the other nodes in the
> network. This will lengthen the initial passive scan from 10 seconds to 30
> seconds.
>
> And if the EBs are used after that then proper K1 key will be needed, and that
> will protect them.
>
> > Do we have an analysis of what any combination of bits that are wrong
> > in a beacon may cause when undetected?
>
> 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.
>
> 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.
>
> 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.
> --
> kivi...@iki.fi
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
