Skip to main content

Last Call Review of draft-ietf-6tisch-architecture-21
review-ietf-6tisch-architecture-21-secdir-lc-mandelberg-2019-06-28-00

Request Review of draft-ietf-6tisch-architecture
Requested revision No specific revision (document currently at 30)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-06-26
Requested 2019-06-12
Authors Pascal Thubert
I-D last updated 2019-06-28
Completed reviews Intdir Early review of -19 by Carlos Pignataro (diff)
Iotdir Early review of -19 by Eliot Lear (diff)
Rtgdir Last Call review of -21 by Andrew G. Malis (diff)
Tsvart Last Call review of -20 by Gorry Fairhurst (diff)
Genart Last Call review of -20 by Francis Dupont (diff)
Secdir Last Call review of -21 by David Mandelberg (diff)
Opsdir Last Call review of -22 by Qin Wu (diff)
Secdir Telechat review of -24 by David Mandelberg (diff)
Assignment Reviewer David Mandelberg
State Completed
Request Last Call review on draft-ietf-6tisch-architecture by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/tw1aZMDZaUw-32qqI3f8XjcKLaQ
Reviewed revision 21 (document currently at 30)
Result Has nits
Completed 2019-06-28
review-ietf-6tisch-architecture-21-secdir-lc-mandelberg-2019-06-28-00
I have reviewed 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 primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Ready with nits.

The review deadline for this was really short, so I didn't have a chance 
to read this as closely as I would have liked. That said, from skimming 
the document and reading the sections that looked most interesting, it 
looks pretty good. The security considerations section covers what I 
expected it to. I have only one question/concern:

Sections 4.2.1 and 4.3.4 talk about the security of joining a network, 
and time synchronization, respectively. Do any of the security 
mechanisms in 4.2.1 rely on having an accurate clock? (E.g., to distrust 
old/expired keys.) Is time synchronization done before the join process, 
and is there any way to exploit time synchronization in order to cause a 
node to join a malicious network?