Skip to main content

Telechat Review of draft-ietf-lwig-crypto-sensors-05

Request Review of draft-ietf-lwig-crypto-sensors
Requested revision No specific revision (document currently at 06)
Type Telechat Review
Team Routing Area Directorate (rtgdir)
Deadline 2018-02-20
Requested 2018-02-08
Requested by Alvaro Retana
Authors Mohit Sethi , Jari Arkko , Ari Keränen , Heidi-Maria Back
I-D last updated 2018-02-21
Completed reviews Secdir Early review of -04 by Christian Huitema (diff)
Intdir Early review of -04 by Tim Chown (diff)
Iotdir Early review of -04 by Samita Chakrabarti (diff)
Opsdir Telechat review of -05 by Éric Vyncke (diff)
Rtgdir Telechat review of -05 by Emmanuel Baccelli (diff)
Genart Last Call review of -05 by Dan Romascanu (diff)
Secdir Last Call review of -05 by Christian Huitema (diff)
Assignment Reviewer Emmanuel Baccelli
State Completed
Request Telechat review on draft-ietf-lwig-crypto-sensors by Routing Area Directorate Assigned
Reviewed revision 05 (document currently at 06)
Result Has nits
Completed 2018-02-21

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and sometimes
on special request. The purpose of the review is to provide assistance to
the Routing ADs. For more information about the Routing Directorate, please
see ​

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-lwig-crypto-sensors-05.txt
Reviewer: Emmanuel Baccelli
Review Date: 20/02/2018
Intended Status: Informational


This document is basically ready for publication, but has nits that should
be considered prior to publication.


The draft's content are solid and relevant, the readability is good.
I have a few suggestions on how to further improve readability.

Major Issues:

No major issues found.

Minor Issues:

In section 8.3, concerning network layer security, it would be more
complete to also mention specific routing security aspects, e.g. cases
where multi-hop is needed in a LoWPAN, and mechanisms (such as topology
authentication) should be used to mitigate sinkhole attacks etc.

In the end summary, maybe it would also make sense to add something like:
"If push comes to shove, strong security is also possible on 8-bit and
I think it is important to send the message that even some "legacy" IoT
hardware could be made secure.


# Section 3: the "network configuration" bullet point is somewhat unclear,
hinting at different issues. Would it not make sense to split it in 2
different bullet points?

# Section 4.1: it would be clearer if the main principles used for
provisionning are gathered and stated upfront in this section. I mean a
short list like
"only identities are provisionned",
"identities are self-securing".

# Section 4.1 in the part on group identity: at first sight it is not
straightforward what is n and what is m, and why they might be differ. Some
explicit mention would be useful.

# Section 4.1 in the part on group identity: does the model require each
device to be provided with the identities of all the other devices in the
group at commissionning time?
It is unclear in the text, an explicit mention would be useful here too.

# Section 5: it is somewhat awkward to find an OS within a list of crypto
However, I agree it is important to point to available operating systems in
this space.
I suggest a separate paragraph on operating systems and citing a survey
such as:
O. Hahm et al. "Operating Systems for Low-end Devices in the Internet of
Things: a Survey." IEEE Internet of Things Journal 3.5 (2016): 720-734.

As a side note, it would be great to have an equivalent survey to point to
available light-weight crypto libraries...

# Section 6: in the beginning of the section, it is not clear that the
measurements are on Arduino Uno (right?).
I suggest stating this explicitly.

# Section 6: "The Arduino board only provides ... the random() function
I think this sentence is somewhat misleading.
The main point here is what there is (or what there isn't) behind this
function call.
I suggest rephrasing the bullet point with something like:
"some boards (e.g. Arduino Uno) do not provide a hardware random number
On such boards, obtaining crypto-quality randomness is an issue."

# Spotted typos:

in Section 6 "results for for all the 128"
in Section 7 "enough power to be stay on"