ietf
[Top] [All Lists]

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

2014-09-01 01:44:23
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 resolve these comments along with any other Last Call comments you
may receive.  (My apologies for submitting these a few days late - I’m on
the road less able to communicate.)


Document: draft-ietf-roll-security-threats-09
Reviewer: Peter Yee
Review Date: Aug-31-2014
IETF LC End Date: Aug-28-2014
IESG Telechat date: TBD


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

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 fine, 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-09, Peter Yee <=