Re: [6tisch-security] Short address assignment

[Tero Kivinen <[e-mail]>]

Michael Richardson writes:
> 
> Tero Kivinen <[e-mail]> wrote:
>     > During the teleconf I pointed out about the issues with the short
>     > address assignments and security. This email provides background
>     > information and explains the situation bit more.
> 
> thank you!
> 
>     > When using TSCH the situation is bit different as Frame counter is
>     > replaced with network global ASN. This means that Source address part
>     > needs to be unique for that timeslot. This means that coordinator
> 
> Attached below is a yang module to describe the short-address assignment.
> 
>     > PAN ID is added, as large networks might use multiple PANs, but still
>     > use same secret key (it does not matter whether the ASNs are in sync or
>     > not).
> 
> Do you think we should slip the PANID in with the short-address
> assignment?

What do you mean by that?

> We have not explained how the pledge knows about PANIDs: clearly it
> could just use whatever PANID the beacons it hears contain. Do you
> think we need to be more explicit?

When device searches for network it will listen beacons, and when it
hears beacons it will pick one and set its macPanId to match for that
and join that network. Device can only be part of one PAN at the same
time, i.e. it can only receive frames which are directed to its
macPanId value (or broadcast PAN ID). It can send frames to other PANs
by providing both source and destination PAN.

Each short address is associated with exactly one PAN, i.e., the PAN
of the coordinator who gave it out. 

> Perhaps we should at least put it in the yang model such that it
> read back?

Could be useful if we at one point want to have networks crossing
multiple PANs. 

> I have included an inception date for the short-address for this
> reason as well. I called it "effectiveat", but maybe there is a
> better name.

Looks ok to me.
-- 
[e-mail]