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

Request Review of draft-ietf-manet-olsrv2-sec-threats
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-12-20
Requested 2016-12-06
Draft last updated 2016-12-18
Completed reviews Secdir Last Call review of -03 by Joseph Salowey (diff)
Genart Last Call review of -03 by Elwyn Davies (diff)
Opsdir Last Call review of -03 by Victor Kuarsingh (diff)
Assignment Reviewer Elwyn Davies
State Completed
Review review-ietf-manet-olsrv2-sec-threats-03-genart-lc-davies-2016-12-18
Reviewed rev. 03 (document currently at 04)
Review result Ready with Nits
Review completed: 2016-12-18


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

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: 


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:
   For the
   Internet, with an increase in users, an increase in attacks and
   abuses followed necessitating a change in recommended practices.
   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.

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

s1, para 3: s/particular/greater/

 s1, para 3:
there is commonly no physical
   protection as otherwise known for wired networks.
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.

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:
Link State Advertisements, They are described in the
   below with sufficient details for elaborating the analyses in this
Link State Advertisements. They are described in the sections
   below with sufficient details to allow elaboration of the analyses in this

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: 
The compromised OLSRv2 router will indicate its willingness to be zero (thus, avoid being selected as MPR)
The compromised OLSRv2 router will indicate its willingness to be selected as an MPR as zero (thus, avoid being selected as MPR)

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

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.