Skip to main content

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 revision No specific revision (document currently at 04)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-12-20
Requested 2016-12-06
Authors Thomas H. Clausen , Ulrich Herberg , Jiazi Yi
Draft last updated 2017-01-10
Completed reviews Secdir Last Call review of -03 by Joseph A. Salowey (diff)
Genart Last Call review of -03 by Elwyn B. 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 revision 03 (document currently at 04)
Result Has Issues
Completed 2017-01-10
review-ietf-manet-olsrv2-sec-threats-03-opsdir-lc-kuarsingh-2017-01-10-00
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