Last Call Review of draft-ietf-6tisch-minimal-security-12
review-ietf-6tisch-minimal-security-12-secdir-lc-orman-2019-10-18-00

Request Review of draft-ietf-6tisch-minimal-security
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-10-04
Requested 2019-09-20
Authors Mališa Vučinić, Jonathan Simon, Kris Pister, Michael Richardson
Draft last updated 2019-10-18
Completed reviews Secdir Last Call review of -12 by Hilarie Orman (diff)
Genart Last Call review of -12 by Vijay Gurbani (diff)
Opsdir Last Call review of -12 by Linda Dunbar (diff)
Assignment Reviewer Hilarie Orman
State Completed
Review review-ietf-6tisch-minimal-security-12-secdir-lc-orman-2019-10-18
Posted at https://mailarchive.ietf.org/arch/msg/secdir/9_GJuOAENV4KUqgnJiTAib85Rfk
Reviewed rev. 12 (document currently at 13)
Review result Has Nits
Review completed: 2019-10-14

Review
review-ietf-6tisch-minimal-security-12-secdir-lc-orman-2019-10-18

       Security review of Minimal Security Framework for 6TiSCH
		draft-ietf-6tisch-minimal-security-12

Do not be alarmed.  I generated this review of this document as part
of the security directorate's ongoing effort to review all IETF
documents being processed by the IESG.  These comments were written
with the intent of improving security requirements and considerations
in IETF drafts.  Comments not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

Nodes can join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e)
network) by issuing a request that is validated using pre-shared
keys.  The document defines the Constrained Join Protocol and its
data structures.

The security considerations section has been done well.

The "short identifier" space consideration on page 34 might be
problematic under extreme conditions.  If almost all values have
been used, a set of nodes might cause trouble by constantly
sending join requests.  The JRC(s) would have to time out their
previous information, and there might be long delays before a
short identifier could be freed up.  Perhaps there should be a rate
limit on join requests from any single node.  (If there is such
a limit I didn't see it).

Page 20 and page 23 mention "the user", but it is unclear what "user"
means in this framework.

Page 34 says that "the loss of security properties is eminent".  That
intended word was probably "imminent".  I suggest rephrasing.

Page 37 asks the reader to recall a "well-known" Bluetooth problem, but
there is no citation for it.  Either document it or remove it.

Hilarie Orman