When reading the draft once again, I noticed some more issues:
- The document goes to quite deeply in the explaining the format of
IEs, including the length and Sub-IDs etc, but it completely omits
the fact that most IEs we are talking about are MLME Nested IEs.
I.e. the format of the data that will be included in the packet will
be:
<Header IEs> <Header Termination 1 IE> <MLME Payload IE>
The <MLME Payload IE> will then contain the IEs described in the
section 4. The <Header IEs> part will include the IE described in
section 5.
I.e in normal case the format will be:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length1 = 0 |Element ID=0x7f|0| Length2 = xxx |GrpId=1|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length3 = 6 |Sub ID = 0x1a |0| ASN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASN |Join Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length4 = 1 |Sub ID = 0x1c |0| TT ID = 0x00 | Length5 = ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
Where the Length1 is the length of Header Termination 1 IE, which is
the first 16-bits of the data, then next 16-bits is the MLME Payload
IE (Group ID = 1) and its length is in Length2, which then includes
all nested IEs inside it. The first nested IE would then be the Sync
IE with length of 6 and Sub ID of 0x1a etc...
I.e. if we copy that much of the 802.15.4 it would be better to copy
so much that people could actually implement it. Or better would be
just leave out stuff that is already in the 802.15.4 and only include
things that we need to say here.
For example we could say that for TSCH Timeslot IE we always use the
Timeslot Template ID of 0x00 and there is no other data in the IE.
Especially as the format for rest of the IE is not accurate, as the
format specified there cannot be used in 915 MHz band, as default
values for macTsMaxTx and macTsTimeslotLength do not fit in the
16-bits allocated for them in IE. In latest revision the last fields
are either 2 or 3 octets and their length can be seen from the length
of the IE.
This parts of the document is bad because it includes too much
information to cause confusion, but too little information so you
cannot still implement anything based on this text.
--
The section 8 says:
One of the
keys (K1) is used to authenticate EBs (all frame). As defined in
Section 4 EBs MUST be authenticated but payload not encrypted. This
prevents two independent networks to interfere or enable non-allowed
nodes to join a particular network.
Which would indicate that well-known keys cannot be used as K1, as
they do not authenticate the EBs.
Also I do not understand what the
This
prevents two independent networks to interfere or enable non-allowed
nodes to join a particular network.
is really trying to say in the "enable non-allowed nodes ..." part. If
it is trying to say that using real key as K1 will prevent nodes which
do not know the key for joining the network, then that is true, but it
is not true for for the well-known keys case. Well-known keys do NOT
provide that feature.
--
[email protected]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
