Dear Tero, all,
here answers of your comments after reviewing the minimal draft and
publishing v18.
-----------------
1)
SERIOUS ISSUE 1: no security section
First of all there is no security considerations section at all. There is
section 4.6 which contains certain security related issues, but it mostly
just lists the required security features (or misfeatures) but does not do
any kind of security analysis.
[…]
The missing security section should include at least following information:
If attacker knows the K1 key, what kind of damage can it do. This is
especially important even if unique keys are used per network, as those
keys might be shared using weak methods and might be short to make the
setup easy. Even if we say in this document that static K1 MUST NOT be
used, people are going to use it, so we need to tell implementors what the
attackers can then do.
Most likely also explain that running networks might not want to accept
completely new set of parameters through the EBs even if they are
authenticated, and perhaps suggest that the whole networks is first shut
down before new set parameters are taken in to use.
Explain that using static key is never safe if there is possibility that
the network might be restarted, as the security of the AES CCM relies on
that the ASN never goes back (which might happen if the network is
restarted).
Explain that 802.15.4 link security do provide authentication and
encryption, but it DOES NOT provide replay protection for the TSCH mode.
This means that all protocols run over 802.15.4 TSCH network must provide
replay protection themselves.
There might be others, but this came to my mind in few minutes of thinking
this issue.
RESOLUTION
A security considerations section has been added describing different
threats and considerations.
2)SERIOUS ISSUE 2: K1
Secondly this document includes text suggesting fixed cryptographic key
("6TiSCH minimal15") which can be used to protect some parts of the 6TiSCH
network. As there is no security considerations there is no analysis what
attacker can do when it knows this key K1.
We have seen several attacks lately against IoT devices where attackers
have found out the default admin key and used it to attack the network. By
proposing static fixed key in the RFC it gives indication that such setup
might be secure, thus vendors implementing this might do similar thing, and
use fixed key. As this key would be known by everybody joining the network,
it will not stay secret, and that will mean it will leak out and it does
not protect anything anymore.
This document should require that both K1 and K2 keys MUST be unique to the
network and the bootstrapping procedures specified later (there
is already work ongoing in the 6TiSCH WG to do them) will be used to
distribute them to new joining nodes.
[…]
Another major issue is that the section 4.6 also forbids using any clear
text frames, even for the joining process. This will make it impossible to
actually to run the bootstrap procedure over the same network that will be
used later for normal traffic. The IEEE Std 802.15.4 do allow exemptions so
that nodes which have configured security to be on for all frames, can
temporarely receive clear text frames from the certain nodes just for this
kind of joining procedures.
This document does not explain how they can be used, and actually forbids
using them.
Section 4.6 has text saying that:
All link-layer frames MUST be secured by the link-layer security
mechanisms defined in IEEE802.15.4 [IEEE802154-2015]: link-layer
authentication and link-layer encryption.
Enhanced Beacons cannot have link-encryption as the joining node needs to
be able to see the ASN contained in the payload IE. Thus Enhanced Beacons
MUST be authenticated, but MUST NOT be encrypted. All other frames MUST be
both encrypted and authenticated.
Also the initial joining node does not know the K1 nor K2, thus it cannot
use link-layer security mechanisms at all, thus this paragraph is
completely wrong.
Remove this whole paragraph.
[…]
Section 4.6 has text saying:
For early interoperability testing, value 36 54 69 53 43 48 20 6D 69
6E 69 6D 61 6C 31 35 ("6TiSCH minimal15") MAY be used for K1.
This text does not belong to this document at all. We do have policy saying
we do not do clear text passwords in the IETF, and having fixed
password in clear in the RFC do count as clear text password at least for
me.
Also if we provide any key in the RFC, the changes are that most
implementations will simply use that key, meaning the K1 does not provide
any protection at all after that.
Remove the whole section, or if you want to keep it, then replace the title
of the section to "Link-Layer Insecurity", and add note in the abstract
telling that this document proposes insecure way of doing things.
Note, that K1 is used to authenticate the EB, thus anybody who knows the
K1, can start sending fake EB messages, and mess up the network by changing
the channel offsets or similars, i.e., knowning K1 will provide very easy
way of doing DoS attack against the whole network, and the network will
most likely need to be completely reformed before the single packet DoS
attack is recovered.
Also early interoperability testing keys should be agreed with the people
doing interoperability testings, or in the interoperability events, not in
the drafts or RFCs.
RESOLUTION:
The section has been rewritten addressing the issues.
4.6. Link-Layer Security
When securing link-layer frames, link-layer frames MUST be secured by
the link-layer security mechanisms defined in IEEE Std 802.15.4
[IEEE802154-2015]. Link-layer authentication MUST be applied to the
entire frame, including the 802.15.4 header. Link-layer encryption
MAY be applied to 802.15.4 payload IEs and the 802.15.4 payload.
During normal network operation a cryptographic key KL is used to
authenticate and optionally encrypt DATA and ACKNOWLEDGMENT frames.
KL may be pre-provisioned. Key distribution is out of scope of this
document. Provisioning mechanisms are defined for example in
[I-D.ietf-6tisch-minimal-security] and
[I-D.ietf-6tisch-dtsecurity-secure-join]. Some provisioning
mechanisms will require some level of network access during the
joining process.
During the join process, if KL has not been provisioned yet, a
protocol identifier PI SHOULD be used in place of KL until both
transmitter and receiver have KL. In particular, PI is used to
authenticate EBs. In this case, PI MUST be pre-configured, and
provides no security. PI does indicate that the authenticated frame
was intended as a 6TiSCH EB. In a crowded 802.15.4 RF environment,
this facilitates logical segregation of distinct networks. The value
36 54 69 53 43 48 20 6D 69 6E 69 6D 61 6C 31 38 ("6TiSCH minimal18")
is RECOMMENDED for PI, but a network operator MAY change it for
administrative and segregation reasons.
In the event of a network reset, the new network MUST either use a
new cryptographic key or keys KL, or ensure that the ASN remains
monotonically increasing.
In addition a security considerations sections has been added. See Section
8. Security Considerations
3) EDITORIAL ISSUE 1
I think IEEE wants that their standards are referenced as "IEEE Std
802.15.4", not IEEE802.15.4. Might be good idea to replace use that, and if
shorter version is needed just add "802.15.4" to terminology and define it
to mean IEEE Std 802.15.4, and then use the shorter version in rest o fthe
document. We would not want people to write "RFC.6550", as that would just
look funny...
ACTION
Thomas has contacted Pat Kinney, as chairman of the Interest Group 6TISCH
at IEEE, CC’ing the 6TiSCH ML
RESPONSE FROM PAT
Tero’s correct, we always get lectured from the IEEE editors that the
standard is referred to as IEEE Std 802.15.4 (note that Std has no period
after it). Tero’s also correct that once you define 802.15.4 as a short
version of IEEE Std 802.15.4, you can use it. BTW: used as a descriptor,
you drop the Std, i.e. an IEEE 802.15.4 device.
RESOLUTION
added the "alias" in the terminology section and used the short name
elsewhere.
4)EDITORIAL ISSUE 2
In this document the term "Slotframe length" is used to specify the
number of timeslots in slotframe. All other documents (802.15.4-2015,
802.15.4e-2012 and draft-ietf-6tisch-terminology-07) use term
"Slotframe size" for that. See IEEE Std 802.15.4-2015 section 7.4.4.3
TSCH Slotframe and Link IE.
Why not use same term for the same thing?
DISCUSSION
Makes sense
RESOLUTION
Replaced all occurences of “slotframe length” to “slotframe size”.
5)EDITORIAL ISSUE 3
IEEE Std 802.15.4-2015 also section 7.4.4.3 TSCH Slotframe and Link IE also
has field called "Number of Links", which match Number of
scheduled cells (active) in Figure 1. Terminology document has both Cell
and Link, and Link uses the IETF meaning of it, not the IEEE meaning of it.
Should we provide both names for the field, especially as the Appendix A
uses the IEEE naming.
DISCUSSION
There has been WG consensus on using “Cell” rather than “Link” as the
latter conflicts with the IEEE terms
No problem for providing both in Appedix A
RESOLUTION
OLD
Number of Links = 0x01
NEW
Number of Links (Cells) = 0x01
6)EDITORIAL ISSUE 4
Same for other names (slotOffset == Timeslot, chOffset == Channel Offset).
Also the IEEE Std 802.15.4-2015 moved away from using link
Options as hex number (0x0f), and instead lists the separate bit-fields in
it (tx, rx, shared, timekeeping), as does the Appendix A.
DISCUSSION
Don’t see what change is requested here
7)EDITORIAL ISSUE 5
Also as slotOffset/Timeslot and chOffset/Channel Offset are 16-bit numbers,
it might be better to express them as 0x0000 instead of 0x00.
DISCUSSION
Good point
RESOLUTION
OLD
slotOffset 0x00
chOffset 0x00
NEW
slotOffset 0x0000
chOffset 0x0000
8)EDITORIAL ISSUE 6
The macLinkType is bit funny as it is one TSCH MAC PIB attribute in per
link structure in macLinkTable. It might be better to refer it as LinkType
given to the MLME-SET-LINK.request primitive, which will then create the
new entry for the macLinkTable and fill in the values given to the
primitive. Note, that this value is not transmitted in the EB, it specifies
that this link is used to send EBs.
RESOLUTION
Replaced all occurrences of macLinkType by LinkType.
9) EDITORIAL ISSUE 7
In Figure 2 the legend specifies TX and RX, but the actual figure uses
Tx and Rx. Change the legend to use Tx and Rx too.
RESOLUTION
OLD
TX: Transmit
RX: Receive
NEW
Tx: Transmit
Rx: Receive
10) EDITORIAL ISSUE 8
In the section 4.5.1 the reference to the IEEE Std 802.15.4-2015 is wrong.
The value of the PAN ID compression bit is not in the Table 7-6, but is
Table 7-2. I.e. change
The value of
the PAN ID Compression bit is specified in Table 7-6 of the
IEEE802.15.4 2015 specification, and depends on the type of the
destination and source link-layer addresses (short, extended, not
present).
to:
The value of
the PAN ID Compression bit is specified in Table 7-2 of the
IEEE Std 802.15.4-2015 specification, and depends on the type of
the destination and source link-layer addresses (short, extended,
not present).
(also change the 802.15.4 2015 to 802.15.4-2015).
RESOLUTION
OLD
The value of the PAN ID Compression bit is specified in Table 7-6 of the
IEEE802.15.4 2015 specification, and depends on the type of the destination
and source link-layer addresses (short, extended, not present).
NEW
The value of the PAN ID Compression bit is specified in Table 7-2 of the
IEEE Std 802.15.4-2015 specification, and depends on the type of the
destination and source link-layer addresses (short, extended, not present).
11) EDITORIAL ISSUE 9
The text
While listening for EBs, a joining node set its own PAN ID to 0xffff
in order to meet the filtering rules in the IEEE802.15.4
specification [IEEE802154-2015].
is wrong and should be removed. The IEEE Std 802.15.4-2011 required setting
PAN ID to 0xffff when doing active or passive scan, but that kludge was
removed in the IEEE Std 802.15.4-2015, and now the filtering rules
specifically checks whether we are doing scanning and if so, we do not do
normal filtering rules, but do special filtering rules needed for scanning.
RESOLUTION
Remove that text.
12) EDITORIAL ISSUE 10
Typo in 4.5.2 the TSCH Slotframe and Link IE is misspelled with
SlotFrame. Replace SlotFrame with Slotframe.
RESOLUTION
OLD
TSCH SlotFrame and Link IE
NEW
TSCH Slotframe and Link IE
13)EDITORIAL ISSUE 11
In section 7.2 there is text saying:
Frame types BEACON and COMMAND are queued with higher priority
than frame types DATA and ACK.
This is wrong. The ACK is sent inside the same timeslot than the frame
it is acking to. It is never sent through queue. Remove the "and ACK"
from the sentence.
RESOLUTION
OLD
Frame types BEACON and COMMAND are queued with higher priority than frame
types DATA and ACK.
NEW
Frame types BEACON and COMMAND are queued with higher priority than frame
types DATA.
14)EDITORIAL ISSUE 12
In the appendix the examples have mostly the same field names than in the
IEEE Std 802.15.4-2015, but some of the fields have bit different
spelliongs. Is there reason for this?
Spelling changes:
"GroupID" vs "Group ID"
"SubID" vs "Sub-ID" (all MLME IEs)
"TimeSlot" vs "Timeslot"
"TimeSlot template ID" vs "Timeslot ID"
"Ch. Hopping" vs "Channel Hopping"
"Channel Hopping Sequence ID" vs "Hopping Sequence ID"
"SlotFrame Handle" vs "Slotframe handle"
"SlotFrame Size" vs "Slotframe size"
"Link Option" vs "Link Options"
"tx,rx,shared,timekeeping" vs "TX Link, RX Link, Shared Link, Timekeeping"
DISCUSSION
No idea why, agree to keep consistent
RESOLUTION
Followed spelling suggested in the review.
15) EDITORIAL ISSUE 13
In the A.4 example the example uses old name for the bit 6, i.e. the
"Frame Counter Size" was renamed to "ASN in Nonce" in 802.15.4-2015 to
better reflect what it really means.
RESOLUTION
OLD
Frame Counter Size
NEW
ASN in Nonce
--
Dr. Xavier Vilajosana
Wireless Networks Lab
*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email protected] <[email protected]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain
[image: Universitat Oberta de Catalunya]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
