[manet] Benoit Claise's No Objection on draft-ietf-manet-olsrv2-sec-threats-03: (with COMMENT)

["Benoit Claise" <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-manet-olsrv2-sec-threats-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Below is cut/pasted Victor Kuarsingh's OPS DIR review.

Summary:

The document analyzes currently assessed (known) security threats for the
OLSRv2 protocol and how these threats may impact a Mobile Ad Hoc Network
(MANET).  The document points to reference documents such as RFC7186,
RFC7183, RFC7188 and RFC7181 and expands on the explanation of security
vulnerabilities and how such vulnerabilities can be mitigated by
currently documented security mechanisms.

Text updates (suggestions / recommendations) are provided below the
general feedback.

General Comments and Feedback:

Overall the document does cover the intention described per the abstract
(summarized above).   Descriptions of the vulnerabilities seem consistent
with documents such as RFC7186 and RFC8183 which already cover detailed
explanation of similar material.  

A few comments are noted in the in-line text overview below (some NITs /
suggestions on wording), and a preference for avoiding such conventions
which use taxonomy like "fresh", "lie" with preference for other options
like "recent", "incorrect/ erroneous " may be better suited for such a
document.

Given this document is attempting to provide a incremental analysis of
the security threats vs. how such threats fair with known security
mechanisms in place, I would recommend that the a slight incremental bit
of text (in-line or separate table) to show which mechanisms are purely
related to implementation level protection (i.e. software written to
enable protocol function) vs. deployment level options.  It appears most
of the protections are implementation level, but there seems to (at
least) two examples of mitigations which may be deployment level (e.g. it
was noted about IP forwarding on Linux boxes as well as wormholes which
create [potentially undesirable] direct comm paths between participating
nodes.). I think noting surveillance related activity for compromised
hosts may also be useful to discuss in section 6 (hard to detect, but a
potential threat).

Other then that, I find the document useful as an analysis which
discusses how the known threats are potentially mitigated by known
mitigations.   There are a few more editing items that can be found, but
that can be addressed by the RFC editor.

Section Review of -  Security Threats for the Optimized Link State
Routing Protocol version 2 (OLSRv2)


Abstract - ok


Introduction 


1. P2 

<old> operating with the assumption, that participants can

   be "trusted" to behave in a non-destructive way, is utopia.

<suggested>

operating with the assumption, that participants can

   be "trusted" to behave in a non-destructive way, is utopian.


P4

<old>  A first step towards hardening against attacks disrupting the

   connectivity of a network, is to understand the vulnerabilities of

   routing protocol,

<suggested>  A first step towards hardening against attacks disrupting
the

   connectivity of a network, is to understand the vulnerabilities of
the

   routing protocol,


1.1. OSLRv2 Overview


P1

<old> They are described in the below with sufficient..

<suggested> They are described in the sections below with sufficient..


1.1.1. Neighbour Discovery


Good


1.1.2 MPR Selection


Good


1.2 Link State Advertisement 


OK


1.3 OLSRv2 Attack Vectors


** use of honestly, lie, etc **.


2. Terminology


** for compromised router, it’s possible that only surveillance is the
goal (may not actually send erroneous or incorrect information) ** . This
may not be detectable, but dangerous none-the-less.


3. Topology Map Acquisition


OK


3.1 Attack on Jittering


OK


3.2 Hop-Count and Hop-limit Attacks


OK


3.2.1 Modifying the Hop Limit


OK


3.2.2 Modifying the Hop Count


OK


4. Effective Topology


OK


4.1 Incorrect Forwarding


** IP forwarding can also be turned of on commercial routers as well via
config - quite easily **  Likely ops level mitigation needed.


4.2 Wormholes


** comment on section above.  **


4.3 Sequence Number Attacks


P1

<comment> Not sure the word “fresher” in the sentence “long paths or
other delays, is not allowed to

   overwrite fresher information” is the best choice.  Technically, the
latter arriving message due to delay/etc is fresher from the receivers
point of view, but less desirable given the delay or path.


4.3.1 Message Sequence Number


<comment> similar to above comment, perhaps “recent” is a better word to
use vs. “Fresh” in the sentence “”Routers will retain this larger ANSN as
"the most fresh information" and …””


4.4 Indirect Jamming 


OK


5. Inconsistent Topologies


OK


5.1 Identity Spoofing


OK


5.2 Link Spoofing


OK


5.2.1 Inconsistent Topology Maps due to Link State Advertisements 


6. Mitigation of Security Vulnerabilities for OLSRv2


OK


6.1 Inherent OLSRv2 Resilience


OK


6.2 Resilience by using RFC7183 with OLSRv2


OK


6.2.1 Topology Map Acquisition


OK


6.2.2 Effective Topology


OK


6.2.3 Inconsistent Topology