Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Malisa

> >> 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.

My own Q&A

How is the bad ASN identified? -> I guess it can be picked from the frame counter in the Auxillary Security Header.
But then does the spec require that the receiver checks the frame counter that the sender used ? Is that implemented?
What is the reaction of the receiver in case of a bad ASN?  -> It could send a beacon with a correct ASN I guess.
But then how can we determine who of the 2 has the correct ASN? -> I guess a node should not have the right to act as coordinator until it confirmed his sense of ASN.

Otherwise, a bad ASN with the good modulo gets the frame in the right channel offset...

> 
> >> 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?

It is not mandatory but we could use it. A more generic method would be for the pledge to solicit a beacon with a nonce that does not depend on ASN and see check the MIC/MAC of the beacon.
 
All the best,

Pascal