I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at 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.