Hello,





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


​

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir







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: Security Threats for Simplified Multicast Forwarding (SMF) - draft-ietf-manet-smf-sec-threats-05 (

https://tools.ietf.org/html/

draft-ietf-manet-smf-sec-threats-05

)







Reviewer: Eric Gray




Review Date: 9 August, 2016




 




Summary:




I have some minor concerns about this document that I think should be resolved before publication.





 




Comments: 




The draft is mostly readable.  There are a fair number of language irregularities – which we are asked not to spend time on in these reviews – including a few that might make reading of some parts of the draft
 difficult for people not already familiar with the intentions and content of the document.




 




Major Issues: 




No major issues found.




 




Minor Issues: 




RFC 6621 discusses a few security issues which do not look to have been referenced in this draft, even indirectly.  There are good reasons why this is unusual.




Similarly, while the draft does make at least an oblique reference to the security issues that apply to RFC 6130, it is not clear without extensive reading what this draft addresses that is not (at least sufficiently)
 addressed there (or in RFC 7186).




 




Toward the end of the first paragraph in section 3 (SMF Threats Overview), the draft makes an assertion that is not consistent with other text in the same paragraph; it claims that “SMF relies on NHDP” while other
 text, including text in the same paragraph, seems strongly to indicate that NHDP is


one alternative approach that might be used

.




 




Note that I was unable to parse part of this same sentence: what does “(not matter if other … for 1-hop neighbor discovery)” mean?





 




Section 4.1.1 (Replay Attack) appears to address an issue that a) is not necessarily a control plane attack (as implied in the first paragraph), and b) is clearly a variation of a threat described in the Security
 Considerations section of RFC 6621 as a DoS attack.  Because the specific threat in both cases (the case described in this section and that described in RFC 6621) involves using some means of delivering bogus packets earlier than subsequent legitimate packets,
 this does not (at least intuitively) seem like a replay attack.




 




Section 4.2.1 – Pre-activation Attacks (Pre-Play) – similarly appears to address one specific example of a second general class of threat described in the Security Considerations section of RFC 6621 (issues with
 use of predictable sequencing techniques).  




 




The same applies to section 4.2.2 – De-activation attacks. 





 




It would be useful if the leading text in section 4.2 talked generally about the related attack vector described in the Security Considerations section of RFC 6621 and why this draft needs to expand on this class
 of threat (associated with I-DPD) described there.




 




Section 4.3 also similarly provides an expansion on a class of threats (associated with H-DPD) already described in RFC 6621.




 




In general, I feel that the expansions provided in section 4 of this draft provide useful information – as examples, at least.  However, this section should explicitly refer to applicable text in RFC 6621, which
 includes suggestions on ways to mitigate these threats.  If the authors and/or the working group feel that the suggestions made in RFC 6621 are insufficient, it would be useful to say why this is the case in this document.




 




The sentence comprising section 5.1 (Relay Set Selection Common Threats) does not appear to be correct as written; RFC 7186 does not include anything about RSS algorithms.  To the extent that RSS MAY depend on
 NHDP, RFC 7186 does describe threats to NHDP that would impact RSS for these cases.  Arguably the same threats may apply independent of how SMF routers become aware of the neighborhood topology, but this is not (and possibly cannot be) known without exhaustive
 analysis of all methods by which this information might be determined.




 




In Section 5.2 (Threats to E-CDS Algorithm), RFC 5614 is given as a reference for “Essential Connected Dominating Set” (or the E-CDS algorithm), when RFC 5614 actually does not mention either one (it defines CDS
 and talks about a small number of algorithms – none of which are directly related to E-CDS; the word “essential” does not appear to be included in the RFC anywhere).  I was not able to find a reference for this term in a few minutes of poking around, though
 it is easy enough to find references for “minimum connected dominating set.”




 




The Security Considerations section (section 7) of this draft should provide a summary of security issues included or addressed in this document (directly or indirectly by reference) as well as any related security
 issues yet to be addressed. Minimally, if the authors feel that this information is provided in section 3 (SMF Threats Overview), the Security Considerations section should say this.  One approach would be to use the Security Considerations section to summarize
 the main content of the document.




 




Nits: 




I had a number of issues with “esoteric questions of English usage.” However, according to our instructions, “the RFC Editor will spot these, and it is not a wise use of time to discuss these things.”




 




J