Early Review of draft-ietf-manet-smf-sec-threats-05
review-ietf-manet-smf-sec-threats-05-rtgdir-early-gray-2016-08-24-00

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