Re: [6tisch-security] Short address assignment, nonces, and TSCH

[Michael Richardson <[e-mail]>]

Tero Kivinen <[e-mail]> wrote:
    >> Then, the question becomes whether we need a mechanism to detect nodes
    >> that are no longer present in the network. In case we use the lease
    >> time as you propose, to have such a mechanism useful, we would need to
    >> set it to a fairly small value (24h or less),

    > Why? The only reason for the lease time is to allow JCE to clean up
    > unused short addresses, and as there is 65k of them, it could be also
    > much longer time, lets say a year or so. If the JCE ever starts running
    > out of addresses (i.e., more than half of the address space is in use),
    > it can shorten the lifetime to a day or so for new devices.

Yes, but that just makes the new devices fight each other for new addresses.
Probably, it should be allocating addresses with some kind of time-based
horizon against which it allocates.  If it knows it will rekey everything by
time X, then it always allocates lifetimes such that they expire by X.

    > As far as I have understood the networks are supposed to be up and
    > running for years, thus having life time of one year etc is not an
    > issue.

Rekeying once a year seems reasonable to me.
Once you rekey, you have to reach out to every node, and the ones that you
fail to reach after some time, are gone, and get cleaned up.

    > On the other hand TSCH nodes, are required to keep constant
    > communication with their timekeeping neighbors (i.e., send packet every
    > few minutes), thus the extra power consumption used for renewal of the
    > address every day or so is negligible.

That might be reasonable, but I think the scale can be extended a lot.

    >> but then we require the whole network to ‘rejoin’ in the same time
    >> frame, which is quite an overhead. I am thinking whether we could
    >> achieve the same functionality by having neighboring nodes report to
    >> JCE that a node left the network upon the removal from the neighbor
    >> table. What do you think?

    > JCE could of course also use the routing table to find out which nodes
    > are still in the network, but that requires whole routing table to be
    > known to the JCE (I am not familiar with the routing protocol used, so
    > I do not know whether it is true or not).

6tisch networks are generally non-storing, which means that the DODAG root(s)
know how to get to every single node.  The JRC (new name for JCE) might have
access to that routing table, but access could be arranged using something
like i2rs perhaps.  In any case, presence of a route does not mean that the
node is alive, or that it's a current route.  RPL is reactive rather than
proactive: if links go in active and nobody is in the forest to notice, then
nobody hears it (to paraphrase a philosophical question).

The JRC contacting the node to attempt to rekey it would be traffic, and said
traffic would cause either a reactive attempt to find the node (if it was
reachable from the same next-hop router), or would fail until the node woke
up and reconnected.  Upon failure, the node's address could be cleaned up at
next rekey, I think.

    > Anyways we are going to need some kind of renewal method, i.e., where
    > node comes back to JCE and says he wants to use same address he had
    > before. This is needed if the node is temperarely disconnect from the
    > network, and when he rejoins the network he needs to go back to the JCE
    > and verify his address is not given out to anybody else while he was
    > away.

    > So as this mechanism is needed regardless whether we have lease time or
    > not if want to cope with JCE reusing addresses, then requiring nodes to
    > do it periodically based on the lease time is not really big overhead.

If the lease time hasn't expired, I think that the address should not be
garbage collected, until a rekey.  Upon rekey, the node is off the network
anyway, and has to do something.

I think that most networks will have enough fewer than 64K nodes that they
can tolerate some leak/loss of 2-byte addresses and mostly never have to
change addresses, even through rekeys.  But the leak will be reclaimed upon
rekey.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-