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

[Tero Kivinen <[e-mail]>]

Mališa Vučinić writes:
> Thanks, Tero, for this summary email. Before adding the lease time
> to the join response, I would like to make sure that the problem you
> describe cannot be solved by simply avoiding to reuse the address.
> 65K should give more than enough space for the coordinator not to
> have to reuse the address it had once assigned.

If you have network which is static and where there is no mobile nodes
joining, then perhaps. On the other hand you still need to implement
some mechanism to cope the situation someone manages to use all
addresses.

I.e., what will the coordinator do when it do run out of address (lets
say because someone managed to make attack that consumed addresses).
Only thing it can really do is to tear down the whole network and
rebuild it from the scratch using different keys, i.e., start the
bootstrap from the beginning again. On the other hand lots of devices
might be such that they do not allow running the bootstrap procedure
second time unless some manual intervention is needed (press reset
button, power down the device etc).

Rekeying the K2 would also work, but that means that every single node
still needs to talk to the JCE separately, and reallocate the short
address again.

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

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.

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. 

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

On the other hand having lease time for address is standard thing we
have used to solve this issue, and I think it works fine here too.

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. 

> Mališa
> 
> > On 01 Dec 2016, at 13:48, 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.
> > 
> > In all of this discussions I assume we are using IEEE Std.
> > 802.15.4-2015 security.
> > 
> > When not using TSCH the nonce is generated using Source address +
> > Frame counter and security level. As Frame counter is separate for
> > each device, that means that only thing that makes sure the nonces are
> > different is the Source address. Because of this the Source address
> > must be extended address, as short addresses are only unique during
> > certain time, not globally.
> > 
> > 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
> > assigining the short address must make sure that same short address is
> > not given to multiple nodes at the same time, but it can give short
> > address to node A, and when it is sure that node A does not use the
> > short address anymore, it can give the same short address to node B.
> > This means it can reuse the short addresses and it will not run out of
> > short addresses unless it has more than 65k nodes in network.
> > 
> > Now, if the short address assinged to the node A does not have any
> > timeframe how long it is valid, the coordinator does not know when the
> > node A stops using the short address, thus it cannot reuse the
> > address. It cannot assume that all nodes will contact it before going
> > away and send release for the address lease, so it must use some other
> > mechanism to guarantee that.
> > 
> > Easiest way would be to send the lifetime along the short address. As
> > we do have global time in the network (ASN), we can use that as a
> > global time frame, so the coordinator can send node A a short address
> > of 0x1234, and say that node A is allowed to use it until ASN
> > 0x12345678a0. After that ASN is reached the node A would need to
> > contact coordinator again to renew the short address lease (or most
> > likely it would contact bit earlier and renew the lease so it gets the
> > same address again).
> > 
> > This is explained in the IEEE Std. 802.15.4-2015 section 9.3.2.2:
> > ----------------------------------------------------------------------
> >    9.3.2.2 CCM* nonce for TSCH mode
> > 
> > 	When TSCH mode is enabled, the nonce shall be formatted as
> > 	shown in Figure 9-2.
> > 
> > 	      +----------------+--------+
> > 	      | Octets: 8      |   5    |
> > 	      +----------------+--------+
> > 	      | Source Address |  ASN   |
> > 	      +----------------+--------+
> > 	   Figure 9-2—CCM* nonce in TSCH mode
> > 
> > 	The Source Address shall either be set to the extended address
> > 	of the device originating the frame or shall be formatted as
> > 	illustrated in Figure 9-3.
> > 
> > 	    +-----------------+------+--------+---------------+
> > 	    | Octets: 3       |   1  |   2    |      2        |
> > 	    +-----------------+------+--------+---------------+
> > 	    | IEEE 802.15 CID | 0x00 | PAN ID | Short address |
> > 	    +-----------------+------+--------+---------------+
> >     Figure 9-3—Source Address field for TSCH mode with short addressing
> > 
> > 	The IEEE 802.15 CID field contains the CID for IEEE 802.15.
> > 	
> > 	The PAN ID field contains the PAN ID.
> > 	
> > 	The Short Address field contains the short address of the
> > 	device originating the frame.
> > 	
> > 	NOTE—When using short addresses in the nonce, it is important
> > 	that the coordinator assign unique short addresses.
> > 	
> > 	The ASN shall be set to the ASN of the timeslot during which
> > 	the frame is sent.
> > ----------------------------------------------------------------------
> > 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).
> > -- 
> > [e-mail]
> > 
> > _______________________________________________
> > 6tisch-security mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/6tisch-security
> 

-- 
[e-mail]