Pascal, Before the pledge selects a JP, the text from RFC8180 that is relevant seems to be (Section 6.2):
When a node joins a network, it may hear EBs sent by different nodes already in the network. The decision of which neighbor to synchronize to (e.g., which neighbor becomes the node's initial time- source neighbor) is implementation specific. For example, after having received the first EB, a node MAY listen for at most MAX_EB_DELAY seconds until it has received EBs from NUM_NEIGHBOURS_TO_WAIT distinct neighbors. Recommended values for MAX_EB_DELAY and NUM_NEIGHBOURS_TO_WAIT are defined in Figure 5. When receiving EBs from distinct neighbors, the node MAY use the Join Metric field in each EB to select the initial time-source neighbor, as described in Section 6.3.6 <https://tools.ietf.org/html/rfc8180#section-6.3.6> of IEEE Std 802.15.4 [IEEE.802.15.4 <https://tools.ietf.org/html/rfc8180#ref-IEEE.802.15.4>]. To me, this text is ambiguous on whether the pledge should duty cycle its radio according to the schedule found in the first received EB. In case the pledge does not duty cycle its radio upon receiving the first EB that happens to be a replay, the attacker cannot really desync the pledge due to its radio being on 100% of the time waiting for additional beacons. Eventually, as Michael noted, one fresh EB will arrive from a legitimate node with a higher ASN, at which point it becomes critical for the pledge to select the JP with the largest available ASN for a given advertised PAN ID. I believe this text deserves expanded discussion in the Security Considerations of minimal-security but I am not convinced on the need for a special mechanism to exchange/sign the ASN. Mališa > On 27 Jun 2019, at 11:53, Pascal Thubert (pthubert) <pthub...@cisco.com> > wrote: > > Hello Michael > > Both ASN and sync create event horizons. > * A wrong ASN will cause MIC processing to fail and the packet will be > ignored. > * If an attacker syncs a pledge outside of the network sync's beyond guard > time, the pledge will not even see that legitimate nodes are sending. > > In both cases, a node that believes an attacker has no way to validate ASN > right there. It needs an additional one-hop authenticated exchange with a > legitimate node with a, e.g., random nonce in payload. Some people will want > that step even if the window is narrow. I think we should describe it in > archie and in minimal sec. > > 6P or MSF could be used for that purpose when present but cannot be the only > way since they are optional. > > All the best, > > Pascal > >> -----Original Message----- >> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Michael Richardson >> Sent: mercredi 26 juin 2019 17:49 >> To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malis...@gmail.com> >> Cc: Pascal Thubert (pthubert) <pthub...@cisco.com>; 6tisch@ietf.org; Tero >> Kivinen <kivi...@iki.fi> >> Subject: Re: [6tisch] [secdir] secdir review of >> draft-ietf-6tisch-architecture-21 >> >> >> Mališa Vučinić <malis...@gmail.com> wrote: >>>> Mališa Vučinić <malis...@gmail.com> wrote: >>>>> Instead, as with traditional TSCH, the joined node can obtain its time >>>>> information from its time source neighbor, i.e. RPL preferred parent, >>>>> by triggering an exchange of link-layer frames with L2 security >>>>> features enabled. The MSF draft already mandates that the first >>>>> outgoing message from the joined node after joining is the 6P ADD >>>>> message to its preferred parent, which consequently gets protected >> with >>>>> L2 security. >>>> >>>> But, how can the L2-security work if the newly-joined node has an >> ancient >>>> ASN? Won't the parent just drop the packet as being a replay, and then >> what? >> >>> Yes, so the node will desynchronize eventually, fall out of network and >>> restart the join process, hopefully with a different network. >> >> hmm. Or, it sees a new beacon, which it can integrity check, and then sees >> the ASN jump forward. This would be the same as if it had slept for awhile. >> >> Unless the attacker can continuously *block* the node from seeing the latest >> beacons, and continuously feeds it old beacons, the problem should go away. >> >> So maybe this is really not as a big a deal as I thought. >> >>>>> What needs to be specified clearly is that this first 6P >>>>> exchange should not be encrypted but only authenticated at L2. >>>>> Upon successful completion of the first 6P exchange with its time >> (routing) >>>>> parent, the joined node obtains a negotiated cell and as a side effect >>>>> proves freshness of the ASN used. >>>> >>>> I'd rather that we added a new exchange, rather than special casing some >> 6P >>>> interaction here. An RPL DIS would be a better choice here, I think, with >>>> an RPL DAO unicast reply. Still, I hate to special case this as being >>>> authenticated only. >>>> Doesn't that have to happen first? >> >>> Whatever packet we send here, be it DIS or 6P, they need to have >>> special handling in terms of L2 security… Is DIS mandatory to send upon >>> preferred parent selection? >> >> I think that we can do nothing. >> >> Maybe the replayed beacon attack (and solution: wait for another beacon) >> belongs in the Security Considerations of the Architecture. >> >> -- >> ] Never tell me the odds! | ipv6 mesh networks >> [ >> ] Michael Richardson, Sandelman Software Works | IoT architect >> [ >> ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails >> [ >> >> >> -- >> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works - >> = IPv6 IoT consulting =- >> >> > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
