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

Jiazi Yi <ietf@jiaziyi.com> Wed, 11 January 2017 23:23 UTC

Return-Path: <ietf@jiaziyi.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13861129DC3; Wed, 11 Jan 2017 15:23:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UV7IaPEsRHj3; Wed, 11 Jan 2017 15:23:21 -0800 (PST)
Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38414129DA4; Wed, 11 Jan 2017 15:23:21 -0800 (PST)
Received: from [192.168.1.101] (95.248.86.88.rdns.comcable.net [88.86.248.95]) by mx.zohomail.com with SMTPS id 14841769979751022.9174540370219; Wed, 11 Jan 2017 15:23:17 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Jiazi Yi <ietf@jiaziyi.com>
In-Reply-To: <148360528696.20579.6013305676126157111.idtracker@ietfa.amsl.com>
Date: Thu, 12 Jan 2017 00:23:14 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <DD1B5587-BDB5-4042-8387-8E5AA802791B@jiaziyi.com>
References: <148360528696.20579.6013305676126157111.idtracker@ietfa.amsl.com>
To: Benoit Claise <bclaise@cisco.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/cECYs5kg48N2f7ECKABYH804oow>
Cc: victor@jvknet.com, manet <manet@ietf.org>, draft-ietf-manet-olsrv2-sec-threats@ietf.org, The IESG <iesg@ietf.org>, Mobile Ad-hoc Networks Working Group <manet-chairs@ietf.org>
Subject: Re: [manet] Benoit Claise's No Objection on draft-ietf-manet-olsrv2-sec-threats-03: (with COMMENT)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jan 2017 23:23:23 -0000

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 <bclaise@cisco.com> 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
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet