Last Call Review of draft-ietf-manet-olsrv2-sec-threats-03
review-ietf-manet-olsrv2-sec-threats-03-genart-lc-davies-2016-12-18-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>;.

Document: draft-ietf-manet-olsrv2-sec-threats-03.txt
Reviewer: Elwyn Davies
Review Date: 2016/12/18
IETF LC End Date: 2016/12/20
IESG Telechat date: 2017/01/05

Summary: Ready with nits

Major issues:

None.

Minor issues:

s3.2:  I do not know enough about the details of NHDP and OLSRv2 to know if
this is a silly question:  Would it be possible for a compromised node to
perform hop-limit or hop-count modification attacks even with RFC 6183 security
in place just by modifying these fields and reforwarding the packet even if it
wasn't actually in the network topology?   If so, it would be desirable to
mention this if it can do any harm.

s6:  I am unclear whether the RFC 6183 security mitigates all the threats
mentioned  here and in RFC 7186.  It would be useful to list any that remain
unmitigated at the end of s9 as items for further study (or say that all of
these are covered).

Nits/editorial comments:

idnits indicates that RFC 6779 has been obsoleted by RFC 7939.  I think this
ref ought to be updated.

I noticed that Ian Chakeres' affiliation is out of date.

Abstract: s/threats of/threats that might apply to/

s1, para 2: s/requirements presented/requirements that need to be addressed /

s1, para 2: s/utopia/utopian/

s1, para 2:
OLD:
   For the
   Internet, with an increase in users, an increase in attacks and
   abuses followed necessitating a change in recommended practices.
NEW:
   With deployent in the wider
   Internet, with a resultant increase in user numbers, an increase in attacks
   and abuses has followed necessitating a change in recommended practices.
ENDS

s1, para 3: s/often is/is often/

s1, para 3: s/particular/greater/

 s1, para 3:
OLD:
there is commonly no physical
   protection as otherwise known for wired networks.
NEW:
there are commonly no physical constraints on the conformation of nodes and
   communication links that make up the network as could be expected for
   wired networks.
ENDS

s1, para 4: s/secured/well-secured/

s1, para 2: s/to OLSRv2/of OLSRv2

s1,next to last para: It would be good to reference RFC 6130 for NHDP here.

s1.1, para 1:
OLD:
Link State Advertisements, They are described in the
   below with sufficient details for elaborating the analyses in this
   document.
NEW:
Link State Advertisements. They are described in the sections
   below with sufficient details to allow elaboration of the analyses in this
   document.
ENDS

s1.3: s/correctly looking/apparently correct/

s1.4; s/henceforth/henceforth identified as/

s1.3: s/disrupt the the LSA process,/disrupt the LSA process,/

s3, para 1: s/TCs to not being delivered to/TCs not being delivered to/

s3.1, para 1: s/a jittering/a jittering mechanism/

s3.2.1, para 1: s/forwarding the message/forwarding for the message/

s3.2.1, para 2: s/transmissions arrives/transmissions arrive/

s4.3.1, s4.3.2 and s5.1:  The statements that 'this threat can be mitigated...'
are premature and belong to s6.  Suggest removing the sentences.

s4.4, para 6:
OLD:
The compromised OLSRv2 router will indicate its willingness to be zero (thus,
avoid being selected as MPR) NEW: The compromised OLSRv2 router will indicate
its willingness to be selected as an MPR as zero (thus, avoid being selected as
MPR) ENDS

s5.1, para 1:
OLD:
The inconsistent topology maps due to neighborhood discovery has been
NEW:
The creation of inconsistent topology maps due to neighborhood discovery has
been ENDS

s6.2.1, "Modifying the hop limit/count": I think you mean "mutable" rather than
"mutual" (2 places)!

s6.2.3, "Identity Spoofing": s/may further allow to revoke/may give the
possibility of revoking/

s9: There is some discussion as to whether an Informational RFC can have
Normative References.  I think it shouldn't, but if it does then I would argue
that RFC 6130 and RFC 7183 are also normative.