Kristofer PISTER writes:
> Can you say more about the reasoning behind "Disallow short
> addresses in Nonce generation" ?

Short addresses are not defined to be unique. The 802.15.4 says that
how short addresses are chosen is outside the scope of this standard.

I.e. it is completely valid for PAN coordinator to allocate duplicate
short addresses for different devices, if it feels things will still
work. I.e. if they are for example in such schedule that their
neighbors will know which one is which. Also PAN coordinator can
allocate duplicate short addresses to devices which are so far away
from each other that they cannot hear each other (or their neighbors).

In practice the PAN coordinator will not allocate duplicate short
addresses for the same PAN, but for example some other networks might
do that, for example when they derive short addresses from somewhere
else like from IP-address...

Also even if short addresses are unique within the PAN, they most
likely will not be unique across different PANs.

If you have cluster tree network like in figure figure 2 in
802.15.4-2011 you notice that there is multiple devices having same
short address in different PANs. The whole cluster tree network might
still use same TSCH schedule system and coordinated ASN and the same
keys, so different PAN coordinators for different clusters can talk to
neighbor clusters.

As the 7.3.2 of the 802.15.4e-2012 did not use PAN id along with short
address in the Source Address field, this could cause duplicate nonces
(i.e. two devices from different PANs using same short address sends
message using same ASN (on same channel on shared slot, or on
different channels). This means nonce is no longer unique, and that
will break the security.

There are much bigger problems if ASN is not used, i.e. when using
non-TSCH mode, and where normal frame counter is used. In that case
every single device starting with frame counter 0, and getting some
short address that has already ben used in the network will cause
nonce collision.

Also the 7.3.2 does not specify how the 16-bit short address is put in
to the Source Address field. One could assume source address is string
and put the short address as first 2 bytes of the source address, but
what values to put to rest of the source address field. They must be
same in both sender and receiver. Most likely it should be filled with
zeroes. On the other hand the macShortAddress is integer, so it cannot
be stored in the string directly wihtout endness problems (extended
address is string and it can be stored there without problems).

Section 7.3.1 defines integer representation format for the section
7.3, and it says that format of B.2 is used, and B.2.2 says integers
shall be represented as octect strings in most-significat-octet-first.
This means that if we encode short address 0x1234 as 16-bit integer,
and pad with zeros we get nonce value of

	12 34 00 00 00 00 00 00

On the other if we assume that source address field is 64-bit integer,
and we just store the 16-bit integer there then value will be:

	00 00 00 00 00 00 12 34

On the other hand if implementation uses the same format that was used
when sending the Source Address in MAC, then the value would be:

	34 12 00 00 00 00 00 00

So the text in 7.3.2 is unclear which format should be used, thus
causing interoperability issues.

Note, that all complient 802.15.4 devices must know the mapping from
the short address to extended address, so there is no reason why the
device cannot use the extended address in nonce. The security section
table 64 (of 802.15.4-2011) describing elements of the
DeviceDescriptor contains the mapping from short address to extended
address. Short address is optional in the DeviceDescriptor, but
extebded address is not optional, it must be there, and it is used in
incoming frame security procedure in 7.2.3.

So there is no reason to use short addresses in the nonce generation,
as it just causes security issues, and complient 802.15.4 devices must
already know the extended addresses of their neighbors so there is no
point of not using it. Frame addressing fields can of course use short
addresses, and extended address is only used internally in the nonce
generation regardless what was in the addressing fields, so there is
no expansion of the frame size when using extended addresses in the
nonce generation.

If you have network where the receiver do not know the mapping from
the short address to extended address for the sender when receiving
secured frame, then that is not complient with 802.15.4, and 6tisch do
not need to care about it...
-- 
kivinen@iki.fi