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

Elwyn Davies <> Sun, 18 December 2016 19:56 UTC

Return-Path: <>
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 013B0129675; Sun, 18 Dec 2016 11:56:04 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Elwyn Davies <>
Subject: Review of draft-ietf-manet-olsrv2-sec-threats-03
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Sun, 18 Dec 2016 11:56:03 -0800
Archived-At: <>
X-Mailman-Version: 2.1.17
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Dec 2016 19:56:04 -0000

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

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

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

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

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

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.