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

[Jiazi Yi <[e-mail]>]

Dear Benoit, 

Thanks very much for your detailed review. 
A new revision (-04) has been updated considering the comments provided. 

Other than the editorial issues, we added a short subsection 6.3 to call out the importance of correct deployment for mitigating some of the vulnerabilities. 

regards

Jiazi

> On 5 Jan 2017, at 09:34, Benoit Claise <[e-mail]> wrote:
> 
> 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
> 
> 
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet