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

Benoit Claise <bclaise@cisco.com> Thu, 12 January 2017 07:35 UTC

Return-Path: <bclaise@cisco.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 EDA36129489; Wed, 11 Jan 2017 23:35:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.721
X-Spam-Level:
X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 8TlPqwBx8Ew7; Wed, 11 Jan 2017 23:35:03 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD801293E4; Wed, 11 Jan 2017 23:35:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7264; q=dns/txt; s=iport; t=1484206502; x=1485416102; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=1lV/NyjJ06lrYMTnmIswL6ynY80k5REkUPBN9cvchHg=; b=Nercd1UMEw+NkPPbpIuE33fwErO/cWso1oNgvSkzgtBe0AU+fuugY+nB m/rSaClZUDD9xJ+queFCSFecUmZy+g6QyJmvPdflTX8LDqCi3gfkVHpHg 0MLHM/GoOC5aUg45lXd6GziwrZw39hhy6W93W8EDdtxcwvnVFkeX++lu1 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BfAQDWMHdY/xbLJq1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM7AQEBAQF+A4EKg1CKCHKRIZUogg0fC4JCgzYCgk0UAQIBAQE?= =?us-ascii?q?BAQEBYyiEagEBBAEBIQ8BBTYLEAkCDgoCAiYCAicwBg0GAgEBiHwOkmWdToIli?= =?us-ascii?q?hUBAQEBAQEBAQIBAQEBAQEBARsFgQuFOoICgVmBBoQYBwQGAYMkgl4BBIh1kjW?= =?us-ascii?q?GW4p7gXeFDIMqhjiKaYd7HzhxJBIIFRU6hGiBSD01AYYoAQYIF4IXAQEB?=
X-IronPort-AV: E=Sophos;i="5.33,349,1477958400"; d="scan'208";a="648710009"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2017 07:34:57 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0C7Yuns006135; Thu, 12 Jan 2017 07:34:56 GMT
To: Jiazi Yi <ietf@jiaziyi.com>
References: <148360528696.20579.6013305676126157111.idtracker@ietfa.amsl.com> <DD1B5587-BDB5-4042-8387-8E5AA802791B@jiaziyi.com>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <ec7438e0-e968-cdec-182b-34a20390f1fa@cisco.com>
Date: Thu, 12 Jan 2017 08:34:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <DD1B5587-BDB5-4042-8387-8E5AA802791B@jiaziyi.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/-YtJz293lY6ZXQzxUQ4wFmdpBrU>
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: Thu, 12 Jan 2017 07:35:05 -0000

Thanks Jiazi,

Regards, B.
> 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
>
> .
>