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: A0BfAQDWMHdY/xbLJq1UCRkBAQEBAQEBAQEBAQcBAQEBAYM7AQEBAQF+A4EKg1CKCHKRIZUogg0fC4JCgzYCgk0UAQIBAQEBAQEBYyiEagEBBAEBIQ8BBTYLEAkCDgoCAiYCAicwBg0GAgEBiHwOkmWdToIlihUBAQEBAQEBAQIBAQEBAQEBARsFgQuFOoICgVmBBoQYBwQGAYMkgl4BBIh1kjWGW4p7gXeFDIMqhjiKaYd7HzhxJBIIFRU6hGiBSD01AYYoAQYIF4IXAQEB
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 > > . >
- [manet] Benoit Claise's No Objection on draft-iet… Benoit Claise
- Re: [manet] Benoit Claise's No Objection on draft… Jiazi Yi
- Re: [manet] Benoit Claise's No Objection on draft… Benoit Claise