Re: [manet] RTG-Dir Review of draft-ietf-manet-smf-sec-threats-05

[Jiazi YI <[e-mail]>]

Dear Eric, all:

Thanks very much for your review and comments. We just submitted a new
revision based on the comments received.

The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-manet-smf-sec-threats/
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-manet-smf-sec-threats-06
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-smf-sec-threats-06



Please find the reply inline:

On Tue, Aug 9, 2016 at 9:26 PM, Eric Gray <[e-mail]> wrote:

<snip>


>
>
> 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.
>

More explicit references to the security consideration section of RFC6621
are added both in the introduction and related sections.


> 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?
>

SMF requires 1-hop and 2-hop neighbourhood information to reduce the relay
set. SMF allows alternative low-layer information to provide necessary
neighbourhood information -- but that's only for 1-hop neighbourhood. But
for 2-hop neighbour information, only NHDP is used in SMF.
We clarified the difference in the section.


>
>
> 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.
>

We changed the name of the section to Attack to Hop Limit to avoid
ambiguity.


>
>
> 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.
>

We added references to related sections in RFC6621 and explained why those
are expanded in this document at the begin of section 4.


>
>
> 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.
>

The RSS is based on the neighbourhood information obtained from the control
plane. For SMF, as far as I can see, only NHDP is used in practice to
obtain neighbourhood information. So the common threats listed in section
5.1 such as DoS, eavesdropping, etc. can be applied to SMF directly --
that's also one of the purpose of having RFC7186 as an independent
document: related content can be reused by protocols such as SMF and
OLSRv2.



>
> 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.”
>
>
In RFC6621, RFC5614 is cited when the E-CDS is introduced:

   The "Essential Connected Dominating Set" (E-CDS) algorithm [RFC5614]
   forms a single CDS mesh for the SMF operating region.

Although “Essential Connected Dominating Set” is not explicitly used in
RFC5614, as a derivative, I think it's still appropriate (and even
necessary) to cite the original source?


>
> 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.
>
>
By taking consideration of the comments from AD, we summarised the content
of the document and merged the "future work" section in this Security
Considerations section.


>
>
> 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.”
>
>
>

RFC editor is the best teacher to tell us how to write English correctly --
especially for non-native English speakers like me :)

Thanks again for your comments!!

regards

Jiazi


> J
>
>
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>
>