Review of draft-ietf-manet-olsrv2-sec-threats-03

[Elwyn Davies <[e-mail]>]

Reviewer: Elwyn Davies
Review result: Ready with Nits

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.