ietf
[Top] [All Lists]

Gen-ART LC review for draft-ietf-roll-security-threats-10

2014-10-02 02:25:28
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.


<Prev in Thread] Current Thread [Next in Thread>
  • Gen-ART LC review for draft-ietf-roll-security-threats-10, Peter Yee <=