Add text on reuse and uniqueness of short addresses

Tag: WGLC

Tero Kivinen wrote (https://mailarchive.ietf.org/arch/msg/6tisch/jTAFrLJfp6qfJ3t5UuKBJW3P2RI):

In section 9.3.2 there is text about link-layer short address, but there is no requirement for the JRC, that mandates it to ensure that it will be unique at any given time. I.e., the security of the network will depend that there is never two sort address using same keys at the same time. I.e., if JRC is restarted and its loosing the state of which short addresses are allocated it MUST rekey the whole network with newly generated key (and as it cannot do that by sending updates, as it does not know who is part of network, it must force everybody to rejoin).

If JRC gives out the short address without giving lease_time, it MUST not ever reuse those short addresses. If it does give lease time it should wait for some guard time before reusing short address that has already been expired. This guard time should include cases where node has sent out message and the message is waiting in transmit queue, but has not been sent out yet, while the address expires, and node might not have code to purge the tranmission from the queue. So adding guard time that is in order of maximum wait time for sending frame or so, would be good.

Sounds good. Are you ok to add an explanation encompassing your two paragraphs from above in Security Considerations section and point to it in the CBOR parameter definition paragraph?

Sure.

In section 9.3.2.2 there is text saying that "short address is unique LOCALLY in the network". This is incorrect. It needs to be unique in the whole network using the same key, i.e., globally in the network using the same key and part of the same TSCH network. I know that some vendors have been using duplicate short addresses for different parts of the network, when there is no risk of them overhearing each other for other 802.15.4 networks, but that is not safe to do in TSCH when short addresses are used in the nonce.

Good point. I will add this to security considerations.

This of course also means that short addresses cannot be generated by hashing of the extended address or similar means locallly and then sending out neighbor discovery to see if someone is using that address, and if so regenerate new one. The node using the same short address might not be in radio range, or might be sleepign etc.

So it is really important that short addresses are always assigned by JRC and JRC takes care of them being unique.

I do understand that the text is trying to say it does not need to be unique in the global internet, but in the local network it needs to be unique globally inside the whole network.

Note, that short address of 0xfffe (associated, but not given short address) and 0xffff (broadcast) are reserved in 802.15.4-2015 and cannot be used. Also some other 802.15.4 extensions like L2R (layer 2 routing) 802.15.10 do reserve additional set of short addresses for example for multicast (0xff00-0xfffd).

Most likely this text should be reflected to that, saying that if address is 0xfffe, then pledge has joined the network, but JRC decided not to give him short address (for example it is running out of them), and the device should use extended address to talk to others.

If JRC gives out short address of 0xffff, then it should be considered invalid.

All good points, thanks! In CoJP section, I tried to make the text a bit generic in order to enable the use of CoJP with different link-layer technologies, i.e. other than 6TisCH, but I will definitely add these in the context of 802.15.4.

Comments (4)