Last Call Review of draft-ietf-manet-olsrv2-sec-threats-03
review-ietf-manet-olsrv2-sec-threats-03-opsdir-lc-kuarsingh-2017-01-10-00

Request Review of draft-ietf-manet-olsrv2-sec-threats
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-12-20
Requested 2016-12-06
Draft last updated 2017-01-10
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 Victor Kuarsingh
State Completed
Review review-ietf-manet-olsrv2-sec-threats-03-opsdir-lc-kuarsingh-2017-01-10
Reviewed rev. 03 (document currently at 04)
Review result Has Issues
Review completed: 2017-01-10

Review
review-ietf-manet-olsrv2-sec-threats-03-opsdir-lc-kuarsingh-2017-01-10

Dear Authors,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Document Reviewed - Security Threats for the Optimized Link State Routing Protocol version 2
Link to Document - https://tools.ietf.org/html/draft-ietf-manet-olsrv2-sec-threats-03


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