Skip to main content

Telechat Review of draft-ietf-roll-security-threats-10
review-ietf-roll-security-threats-10-genart-telechat-yee-2014-10-02-00

Request Review of draft-ietf-roll-security-threats
Requested revision No specific revision (document currently at 11)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-09-30
Requested 2014-09-25
Authors Tzeta Tsao , Roger Alexander , Mischa Dohler , Vanesa Daza , Angel Lozano , Michael Richardson
I-D last updated 2014-10-02
Completed reviews Genart Last Call review of -00 by Peter E. Yee (diff)
Genart Last Call review of -09 by Peter E. Yee (diff)
Genart Telechat review of -10 by Peter E. Yee (diff)
Secdir Last Call review of -00 by Stephen Kent (diff)
Secdir Telechat review of -01 by Stephen Kent (diff)
Rtgdir Last Call review of -09 by Manav Bhatia (diff)
Assignment Reviewer Peter E. Yee
State Completed
Request Telechat review on draft-ietf-roll-security-threats by General Area Review Team (Gen-ART) Assigned
Reviewed revision 10 (document currently at 11)
Result Ready w/issues
Completed 2014-10-02
review-ietf-roll-security-threats-10-genart-telechat-yee-2014-10-02-00
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Please wait for direction from your document shepherd or AD before posting a
new version of the draft.

Document: draft-ietf-roll-security-threats-10
Reviewer: Peter Yee
Review Date: Oct-2-2014
IETF LC End Date: Aug-28-2014
IESG Telechat date: Oct-2-2014

Summary: This draft is on the right track but has open issues, described in 
the review. [Ready with issues.]

I'm disappointed to see that none of my suggestions from the -09 review were
incorporated into the document.  While the language nits could probably be
passed along to the RFC Editor for laborious incorporation, I don't see why
they should have to deal with a set of corrections that were known prior to the
IESG telechat.  And I do list issues below that go beyond nits and what they
RFC Editor can be expected to correct, so I'm really conflicted about seeing
this document move forward without correction. Oh, yeah.  Two new nits were
added because of some revisions in -10 that actually undid correct language! 
Really???  They are:

Page 4, 3rd full paragraph, 3rd sentence: change "it's" to "its".

Page 4, 3rd full paragraph, last sentence: change "similiar" to "similar".

This document analyzes security threats for routing in a low-power and lossy
networks.  It discusses countermeasures and operational considerations for
dealing with the threats in the design of RPL.  The document generally conveys
the desired information to a certain degree, but it needs some polishing before
it should proceed.

Major issues:

Minor issues:

In general, there are language issues throughout the document:

        1) Overuse of commas, particularly before the conjunction “and”.  While
        these aren’t generally harmful to understanding, they can make parsing
        more tedious.  In situations where they are truly ill-advised, I’ve
        offered specific nits below.  Consider conserving commas.  I have added
        a few where they added readability. 2) Dense noun strings are found in
        many places.  These are strings of nouns that are concatenated into
        difficult to understand strings.  I wish I had marked one in my review
        copy of the document, but they are pretty obvious when read aloud. 
        Think of ways to reduce their use to improve readability. 3) Bombastic
        adjectives without justification.  “Serious” and “significant” appear
        many times in the document without necessarily being justified.  I
        think these could be toned down, thereby obviating the need to explain
        why they were used.  In some cases, the situation described isn’t at
        all dire in all cases, but this is not obvious from the adjectives
        used. 4) Parsing errors.  Some sentences I just could not parse.  I’ve
        provided nits for those, including some where I tried to suggest ways
        to make the sentences parseable. 5) Run-on sentences.  Break down
        overly long sentences on clause boundaries in order to make
        understanding easier.

I do realize that some of the authors may not be native speakers of English, so
please do not take insult at my criticism of the language in the document. 
Heck, sometimes I inadvertently introduce errors during the review process.

Page 5, Section 4, 1st paragraph, 1st sentence: I know what you’re trying to
get at, but it takes more than routing security to ensure correctness of
routing operation.  Correctness of implementation counts for a lot as does
proper design of the routing protocol.  Perhaps change “ensures” to “helps to
ensure”.

Page 14, Section 6.1.2, 2nd sentence: what are “inappropriate authorizations”
and has does a dummy node provide them?

Page 16, 1st partial paragraph: isn’t exclusion too late?  If the device has
already exposed the routing information, exclusion may prevent it from doing so
going forward, but does nothing to remedy the original exposure.

Page 21, 4th paragraph: I’d like to point out that none of these
countermeasures appear to do anything for a node which simply sends out the
routing data to the 3rd party directly.  This transmission need not be
performed over the routing protocol.  And it would be essentially undetectable
if the transmissions were both directed and encrypted.

Page 27, 4th bullet item: how does introducing quotas prevent overload attacks?
 Sure, no node would pass on received traffic from a node that exceeded its
quota, but that node could still be spewing traffic towards its neighbors and
overloading them nonetheless.

Page 27, last paragraph, 2nd sentence: so how does this scheme help?  It can’t
prevent an overloading node from transmitting.

Page 28, 1st full paragraph, 2nd sentence: I remain mystified how this helps. 
A receiving node can still be bogged down with processing incoming messages
from the overload transmitter.  Sure, certificate verification will prevent the
node from using keys that aren’t authorized or “real”, but the node will still
have to devote resources to performing some minimal level of message processing
before it can decide to throw away a message.  So it is still vulnerable to
being overloaded.

Nits:

General: Ensure a comma follows each use of “i.e.” and “e.g.”.

General: write RFCXXXX as RFC XXXX except when used in a reference.

General: write network layers as “Layer X” not “layer-x”.

Page 1, Abstract, last sentence: consider dropping “Applicable” as unnecessary.

Page 4, third full paragraph, 1st sentence: delete “All of”.  Append “solely”
after “itself”.

Page 4, third full paragraph, last sentence: define, expand, or add a reference
for “MPL”.

Page 4, Section 2, 3rd paragraph, last sentence: change “This” to “These”.
 Delete the space between “light” and “weight”.

Page 5, Section 4, 1st paragraph, 2nd sentence: change “clock” to “time”.
Time is the parameter.  Clock is the device that maintains that parameter.

Page 5, Section 4, 1st paragraph, 3rd sentence: change “thereby” to
“therefore”.  Insert “the” before “confidentiality”.  Consider explaining the
term “injector” which isn’t really used in as such in (at least some of) the
RPL documents.

Page 5, 1st paragraph, 1st sentence: delete the comma after “particularly”.

Page 6, Section 4.1, 2nd paragraph, last sentence: change “process” to
“processes”.

Page 7, move the “Figure 11” caption so it’s next to the figure itself.

Page 8, 1st paragraph after the bullet points, last sentence: insert “are”
before “nonetheless”.

Page 8, Authentication definition: is “joiner” a usual term in this context? 
RPL doesn’t use it nor does it use the term “injector” found previously in this
document.  While both make some amount of sense in terms of what RPL describes,
it would be best to use terms that are the same as RPL or are well understood
within the context.

Page 9, Integrity definition: I prefer “undetected” in place of “unauthorized”.
 Integrity protection doesn’t always prevent the data from being changed, but
it should at a minimum make it apparent that the data has indeed been changed
and in an apparently unauthorized manner.  This definition also ends in a
sentence fragment that needs to be deleted or completed.

Page 9, Non-repudiation definition, last sentence: replace “considered”
with “consideration”.  Replace the “an” before “RPL” with “a” on the assumption
that the acronym is read as “ripple” and not “R-P-L”.

Page 9, paragraph after non-repudiation definition: delete the comma after
“availability”.

Page 9, Availability definition, 1st sentence: change “need to be” to “are”. 
Put a period at the end of the overall definition. Page 10, 1st paragraph, put
a “)” after “[RFC5826]”.

Page 10, “Limited” definition: add a comma after non-rechargeable.  Change the
space between “battery” and “powered” to a hyphen.  Change “it’s” to “its”. 
Change “exchausted” to “exhausted”.

Page 10, “Large scale” definition: In the last sentence, the topic of key
management is introduced.  Not having had any discussion about the topic
before, it seems to be a bit of out place.  Yeah, that’s not super actionable
but I found it jarring.

Page 11, 1st paragraph, last sentence: change “suggests” to “suggest”.

Page 11, 2nd paragraph: replace “absense” with “absence”.

Page 11, last paragraph, 2nd sentence: multicast and anycast are hardly just
mechanisms for routing.  They may be used by routing, but they aren’t limited
to that use.  Perhaps change the beginning of the sentence to “Since
application of these  mechanisms to routing”.

Page 12, Section 4.4, 1st paragraph: change “access points” to “points of
access”.  This is more consistent with other use in this document and prevents
confusion with a term of art in IEEE 802.11.

Page 12, last bullet item: this one would seem to fall more into the camp of
“correctness of implementation” and not so much security.  Maybe just drop it?

Page 12, last paragraph, 1st sentence: change “in” to “with” after
“difficulties”.

Page 13, 1st paragraph: insert “a” before “flexible”.  Change “of” to “for”
after “scheme”.

Page 13, 1st paragraph after bullet items, 1st sentence: change “which” to
“that”.  Change “affecting” to “affect”.

Page 13, 1st paragraph after bullet items, 2nd sentence: change “barrier of” to
“barriers to”.

Page 13, 2nd paragraph after bullet items, 1st sentence: change “applied”
to “met”.

Page 14, 1st partial paragraph, 4th full sentence: insert “be” before “limited
in memory”.  Add a comma after “consumption”.  Replace the space between “long”
and “term” with a hyphen.

Page 14, Section 6.1 title: capitalize the title like the other
section/subsection titles: “Threats Due to Failure to Authenticate”.  I’ve also
made failures singular.

Page 14, Section 6.1.1, 2nd paragraph, 1st sentence: insert “is” before
“application”.

Page 14, Section 6.1.1, 2nd paragraph, 2nd sentence: replace “which” with
“that”.

Page 14, Section 6.1.3, 1st sentence: change “continously” to “continuously”.

Page 14, Section 6.1.3, 2nd sentence: delete “down”.  Explain how a new node
joining repeatedly with new identities drains resources.

Page 14, Section 6.1.3, 3rd sentence: replace “of” with “on”.

Page 15, Section 6.2.2, 2nd paragraph, 2nd sentence: change “is” to “are”.

Page 15, Section 6.2.2, 1st paragraph after the bullet items: replace the space
between “device” and “specific” with a hyphen.

Page 16, paragraph before the bullet items: end the phrase with a colon.

Page 16, 1st bullet item: elaborate on the differences between overclaiming and
misclaiming.  Or justify why both terms need to be present.

Page 17, Section 6.3.2, 1st paragraph: end the paragraph with a colon.

Page 17, Section 6.4.1, 1st sentence: insert “the” before “threat”.

Page 18, 2nd paragraph: append a colon after the reference.

Page 18, Figure 3 caption: append “example” to the caption.

Page 18, bullet items: eliminate the superfluous semicolons and period found
after the bullet item titles.

Page 19, Figure 4: eliminate one of the duplicate labels reading “Falsify as
Good Link To Node_5”.  Replace “To” with “to” in the remaining label.

Page 19, Figure 4: capitalize “sinkhole”.

Page 20, 1st full paragraph, 1st sentence: replace “generating” with
“generation”.

Page 20, 1st full paragraph, last sentence: change “resources” to “resource”.

Page 20, 1st bullet item: eliminate the reference.  It’s already been given
previously.

Page 20, Section 7.1, 1st sentence: change “to disclosure” to “that disclose”.

Page 21, 1st paragraph: eliminate the hyphen in “mis-configuration”.

Page 21, 3rd paragraph, last sentence: insert “a” before “3rd”.

Page 21, Section 7.1.2, 2nd paragraph, 2nd sentence: make “exchange”
plural.

Page 21, Section 7.1.2, 2nd paragraph, 3rd sentence: delete the commas.

Page 21, Section 7.1.2, 4th paragraph: append a comma after the reference.
 Change “similiar” to “similar”.

Page 22, 2nd full paragraph: change “Zigbee” to “ZigBee”.

Page 22, Section 7.1.3, 1st paragraph, 2nd sentence: insert “a” before “shared”.

Page 23, Section 7.2, 3rd sentence: delete “the” before “unauthorized” and
“overclaiming”.  I’m not sure what is meant by “content” in this sentence.

Page 23, Section 7.2.1, 2nd paragraph, 1st sentence: change “change” to
“exchange”.

Page 23, Section 7.2.1, 2nd paragraph, 2nd sentence: change the second
“exchange” to “messages”.

Page 24, 1st carried over bullet item: insert “the” before “sequence”.

Page 24, Section 7.2.2, 1st paragraph: I couldn’t parse this sentence to my
satisfaction.

Page 24, Section 7.2.2, last paragraph: change “overclaims” to “overclaiming”
and “misclaims” to “misclaiming” for consistency with prior usage.

Page 24, Section 7.2.3, 3rd paragraph, 1st sentence: replace the space between
“key” and “based” with a hyphen.  I’m not sure how authentication provides for
authorization as stated in the sentence.  I recognize authentication as
necessary for many authorization schemes, but authorization doesn’t typically
come out of pure authentication.

Page 24, Section 7.2.4, 2nd sentence: change “counted” to “countered”.
Change “counter” to “value (e.g., a sequence number or timestamp)”.

Page 24, Section 7.2.4, 3rd sentence: change “are” to “is,” (note the
comma) and add a comma after “general”.

Page 24, Section 7.2.4, 4th sentence: change “as” to “since” and delete “then”.

Page 25, 1st full paragraph: the parenthetical doesn’t make sense.  Is IEEE
802.15.4 supposed to be an example?  A counterexample?  Add some words here to
make it clear what is meant.  Replace “echos” with “echoes”.

Page 25, 2nd paragraph, 1st sentence: replace “affect” with “effect”.

Page 25, 2nd paragraph, 2nd sentence: replace “never changed” with “unchanged”.

Page 25, 2nd paragraph, 3rd sentence: replace “which” with “that”.  Add a comma
after “Sinkhole Attack”.

Page 25, Section 7.2.5, 3rd paragraph, 2nd sentence: append a comma after
“sources”.  Why is there a discussion of flooding attacks in a subsection on
Byzantine attacks?

Page 25, Section 7.2.5, 4th paragraph, 1st sentence: append a comma after
“node”.

Page 26, Section 7.3, 2nd sentence: delete “e.g.,”.

Page 26, Section 7.3.1, 1st paragraph, 1st sentence: I’m not sure what you’re
trying to do here with the references.  If the both refer to the HELLO Flood
than combine them inside of parentheses.

Page 26, Section 7.3.1, 3rd paragraph, 1st sentence: replace “method” with
“protection against this attack”.  Change “is the verify” to “is to verify”.

Page 26, Section 7.3.1, 3rd paragraph, 2nd sentence: delete the comma.
Move “are” before “continuously”.

Page 26, Section 7.3.1, 4th paragraph: define, expand, or reference ETX.

Page 27, 1st paragraph: should the comma be replaced by “of”?  As in the
section is part of the referenced document?  Consider changing the first use of
“receiver” to “receiving node” for clarity.

Page 27, Section 7.3.2, 1st paragraph, 1st sentence: change “nodes’” to
“node’s”.  Delete the comma after “quickly”.

Page 28, Section 7.3.3, 2nd paragraph, 2nd sentence: change “which” to “that”
and delete the comma.

Page 28, Section 7.3.3, 3rd paragraph, 3rd sentence: move inherently after
“traffic is”.

Page 28, Section 7.3.3, 3rd paragraph, 4th sentence: should “outside” be
“outsider” to match the usage of “insider” at the beginning of the paragraph?

Page 29, Section 7.3.4, 1st paragraph, 2nd sentence: change “hence” to
“therefore”.

Page 29, Section 7.3.4, 2nd paragraph, 2nd sentence: delete “hence”.

Page 29, Section 7.3.4, 1st paragraph after the bullet items, change the comma
after “calculations” to a semicolon.  Change “node to node” to “node-to-node”.

Page 29, last paragraph: should “might be match” be “might not match”?

Page 30, 3rd paragraph: add a comma after “protocols”.  What is a “security
suit”?

Page 31, Section 8.1., 1st paragraph, 2nd sentence: change “does” to “do”
and “itself” to “themselves”.

Page 31, Section 8.1, 1st paragraph after the bullet items, 2nd sentence:
change “AES128” to “AES-128”.

Page 32, Section 8.2, 2nd paragraph, 1st sentence: insert “a” before
“significant”.

Page 32, Section 8.,2, 5th paragraph, 1st sentence: change “which” to “that”. 
Delete the comma after “(DIO)”.

Page 32, Section 8.3, 1st sentence: append a comma after “availability”
and after “LLNs”.  Change “require” to “requires”.

Page 33, 4th bullet item: append “among possible paths” after “randomly”.

Page 33, Section 8.4, 1st sentence: delete “but”.  Explain what about public
key is too “expensive”.  Who are the “many” that are being bandied about here?

Page 37, reference for “Sybil2002”: this should be changed to “Douceur2002” and
similar changes made wherever else that document is referenced.