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

[Tero Kivinen <[e-mail]>]

Pascal Thubert (pthubert) writes:
> 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.

No, the auxillary security header does not contain ASN ever. The Frame
counter field is for frame counters, not for ASNs, and it is only 4
octets long, and you cannot fit ASN in there. ASN will be delivered in
the beacon frame inside the TSCH Syncronization IE. 

> But then does the spec require that the receiver checks the frame
> counter that the sender used ?

For frame counters yes, but frame counters are not used in TSCH mode.
In TSCH each device keeps track of ASN by its own clock, and as
everybody knows what ASN is, there is no need to transmit it between
nodes already in the network. ASN is only sent inside the IE for new
nodes.

And ASN will get implictly verified as if you do get out of sync with
ASN, then you will be using wrong ASN for nonce generation and all
your inbound security processing will fail. 

> Is that implemented? What is the reaction of the receiver in case of
> a bad ASN?

If it is secured frame, it will get SECURITY_ERROR for each frame
having wrong ASN, and it will drop the frames. For non secured frames,
it will not even notice the issue if it actually managed to be on
correct channel to hear the transmission. 

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

When PAN coordinator forms a TSCH network it will decide what ASN will
be used, and everybody else must sync with him when joining the
network, and must keep themselves in sync. If they loose track of ASN,
they must rejoin the network and regain the syncronization. 
-- 
[e-mail]