Re: [manet] OLSRv2 sec threats review

Abdussalam Baryun <abdussalambaryun@gmail.com> Mon, 29 August 2016 06:25 UTC

Return-Path: <abdussalambaryun@gmail.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 272DA12D13A for <manet@ietfa.amsl.com>; Sun, 28 Aug 2016 23:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ZZifac8g0xvR for <manet@ietfa.amsl.com>; Sun, 28 Aug 2016 23:25:04 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E3A12D0E8 for <manet@ietf.org>; Sun, 28 Aug 2016 23:25:04 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id w38so63916324qtb.0 for <manet@ietf.org>; Sun, 28 Aug 2016 23:25:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q1xlCDVX9IccH9iX+sVe4jl6ijnZA52GDMqd6Qu0ZFQ=; b=pxzU/jx1+1vetSEgzOKENavEYpfhL8thJXfNyDgXpiV6TyO0FMGj2iqJqGTzPPImwA kOg28Uyi7u5pV1+QZMOe8Ekgo0SnZ8FrvlFhorvrJDsEo4YsdNsDjXponMc/WQDfnWcR 55ZmTs73qdSW0IpfoXKT8ubCtVxIwgLT5LaBbis2Xvxk37lUXn4eW9vxJLhwKVklruQJ Z452c93iU/fgpGc2tHS2pbD93Kx5G8vR36Ha1teoyQsBgzYt+e0qL5iK4yZndNMBjzQL pDJ/QazYrL/gXnek6avj5qh20pTt0T80jLTRGxoVK9wyCCAdI4TSYPMqlCGZLAn2wDcs 5IXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q1xlCDVX9IccH9iX+sVe4jl6ijnZA52GDMqd6Qu0ZFQ=; b=j/pLiBXsTdwm9lPfGRmkcdZmLzPpDroDavVhN1brYcIXnljE5Pmwp7R6ydas7JNJqV RyXIQTDrU7CDjXUmvs3a7Bi9UDhgqz0K4I3MYH1e3yKA18yF0/qc7BKfiaGTNT8Y87G1 /rARwD+kInGvk0gaNZdawpwN5oxt+h1glhw6SOtZwhCu7bRbH/h87v1aDgElt1O5qOiI mh7EH/3Q4my4AaEKo0GNPLBtut9TELRlXfRjkj9qDEiveEGRCiPgx4QzdJdAh6rruqz+ /OcHZFDmlumi3Ll2n9zUURdW3+CiobVJZ+Tdhjo01ilOXzHnkhMfs9gDfFcbEXe028ge FbuA==
X-Gm-Message-State: AE9vXwNLFJGeMgeTfY9c9rInV24GKmMvAjDr6ZPSQQ5F0Rzaa6UKwAd0MYmxS9We49XJNjVz8sXL9u6ORZoO0w==
X-Received: by 10.237.59.212 with SMTP id s20mr16503190qte.126.1472451903009; Sun, 28 Aug 2016 23:25:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.81.137 with HTTP; Sun, 28 Aug 2016 23:25:02 -0700 (PDT)
In-Reply-To: <CA+-pDCf_nL1un3YR8LvAMa7qHyeppnwArW3VCjC8EiGeT7kmjg@mail.gmail.com>
References: <CA+-pDCf_nL1un3YR8LvAMa7qHyeppnwArW3VCjC8EiGeT7kmjg@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
Date: Mon, 29 Aug 2016 08:25:02 +0200
Message-ID: <CADnDZ881Zvpb_3=KJWSModkaruEK5sdB6twRvtzZVz1QeP6fLw@mail.gmail.com>
To: Justin Dean <bebemaster@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c190c30a0baca053b2fecd1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/rlgIshaOjttLCKhpARwy9XO2i80>
Cc: "manet-chairs@tools.ietf.org" <manet-chairs@tools.ietf.org>, "manet@ietf.org" <manet@ietf.org>
Subject: Re: [manet] OLSRv2 sec threats review
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: Mon, 29 Aug 2016 06:25:07 -0000

Thanks Justin,

I would add my quick comments,

On Mon, Aug 29, 2016 at 6:33 AM, Justin Dean <bebemaster@gmail.com> wrote:

> As there weren't many on list comments during or after last call here is my detailed review.
> Summary is that I'm doing the writeup right now and passing it on up.  Most of my comments
> are of the editorial type with exceptions which are minor and mostly clarification based.
>
> Apologies to the author team for not getting this done sooner; I wanted to make sure I did it right.
>
>
> Comments noted as JWD
>
>
>
>
> Network Working Group                                         T. Clausen
> Internet-Draft                                                U. Herberg
> Intended status: Informational
> Expires: November 10, 2016                                         J. Yi
>                                                      Ecole Polytechnique
>                                                              May 9, 2016
>
> Security Threats for the Optimized Link State Routing Protocol version 2
>                                 (OLSRv2)
>                  draft-ietf-manet-olsrv2-sec-threats-02
> Abstract
>
>    This document analyzes common security threats of the Optimized Link
>    State Routing Protocol version 2 (OLSRv2) and describes their
>    potential impacts on Mobile Ad Hoc Network (MANET) operations.  It
>    then analyzes which of these security vulnerabilities can be
>    mitigated when using the mandatory-to-implement security mechanisms
>    for OLSRv2, and how the vulnerabilities are mitigated.
> Status of this Memo
>
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    This Internet-Draft will expire on November 10, 2016.
> Copyright Notice
>
>    Copyright (c) 2016 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
> Clausen, et al.         Expires November 10, 2016               [Page 1]Internet-Draft               OLSRv2 Threats                     May 2016
>
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
> Table of Contents
>
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
>      1.1.  OLSRv2 Overview  . . . . . . . . . . . . . . . . . . . . .  4
>        1.1.1.  Neighborhood Discovery . . . . . . . . . . . . . . . .  4
>        1.1.2.  MPR Flooding . . . . . . . . . . . . . . . . . . . . .  5
>        1.1.3.  Link State Advertisement . . . . . . . . . . . . . . .  5
>      1.2.  Link State Vulnerability Taxonomy  . . . . . . . . . . . .  5
>      1.3.  OLSRv2 Attack Vectors  . . . . . . . . . . . . . . . . . .  6
>    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
>    3.  Topology Map Acquisition . . . . . . . . . . . . . . . . . . .  6
>      3.1.  Attack on Jittering  . . . . . . . . . . . . . . . . . . .  7
>      3.2.  Hop-count and Hop-limit Attacks  . . . . . . . . . . . . .  7
>        3.2.1.  Modifying the Hop Limit  . . . . . . . . . . . . . . .  7
>        3.2.2.  Modifying the Hop Count  . . . . . . . . . . . . . . .  8
>    4.  Effective Topology . . . . . . . . . . . . . . . . . . . . . .  9
>      4.1.  Incorrect Forwarding . . . . . . . . . . . . . . . . . . .  9
>      4.2.  Wormholes  . . . . . . . . . . . . . . . . . . . . . . . . 10
>      4.3.  Sequence Number Attacks  . . . . . . . . . . . . . . . . . 11
>        4.3.1.  Message Sequence Number  . . . . . . . . . . . . . . . 11
>        4.3.2.  Advertised Neighbor Sequence Number (ANSN) . . . . . . 11
>      4.4.  Indirect Jamming . . . . . . . . . . . . . . . . . . . . . 12
>    5.  Inconsistent Topology  . . . . . . . . . . . . . . . . . . . . 14
>      5.1.  Identity Spoofing  . . . . . . . . . . . . . . . . . . . . 14
>      5.2.  Link Spoofing  . . . . . . . . . . . . . . . . . . . . . . 16
>        5.2.1.  Inconsistent Topology Maps due to Link State
>                Advertisements . . . . . . . . . . . . . . . . . . . . 16
>    6.  Mitigation of Security Vulnerabilities for OLSRv2  . . . . . . 18
>      6.1.  Inherent OLSRv2 Resilience . . . . . . . . . . . . . . . . 18
>      6.2.  Resilience by using RFC7183 with OLSRv2  . . . . . . . . . 19
>        6.2.1.  Topology Map Acquisition . . . . . . . . . . . . . . . 19
>        6.2.2.  Effective Topology . . . . . . . . . . . . . . . . . . 20
>        6.2.3.  Inconsistent Topology  . . . . . . . . . . . . . . . . 20
>    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
>    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
>    9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
>      9.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
>      9.2.  Informative References . . . . . . . . . . . . . . . . . . 21
>    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
> Clausen, et al.         Expires November 10, 2016               [Page 2]Internet-Draft               OLSRv2 Threats                     May 2016
> 1.  Introduction
>
>    The Optimized Link State Routing Protocol version 2 (OLSRv2)
>    [RFC5148], [RFC5444], [RFC5497], [RFC6130], [RFC7181], [RFC7182],
>    [RFC7183], [RFC7187], [RFC7188] is a successor to OLSR [RFC3626] as a
>    routing protocol for MANETs (Mobile Ad hoc NETworks).  OLSRv2 retains
>    the same basic algorithms as its predecessor, however offers various
>    improvements, e.g., a modular and flexible architecture allowing
>    extensions, such as for security, to be developed as add-ons to the
>    basic protocol.
>
> [JWD] NIT: listing RFC7181 first would be helpful.
>
> [AB] why the introduction says basic algorithms as OLSRv1, it is
confusing, I think they are not having similar procedures. The plural of
algorithms even makes it confused. It is better to say 'basic algorithm'.

>
>    The developments reflected in OLSRv2 have been motivated by increased
>    real-world deployment experiences, e.g., from networks such as
>    FunkFeuer [FUNKFEUER], and the requirements presented for continued
>    successful operation of these networks.  With participation in such
>    networks increasing (the FunkFeuer community network has, e.g.,
>    roughly 400 individual participants at the time of publication of
>    this document), operating with the assumption, that participants can
>    be "trusted" to behave in a non-destructive way, is utopia.  Taking
>    the Internet as an example, as participation in the network increases
>    and becomes more diverse, more efforts are required to preserve the
>    integrity and operation of the network.  Most SMTP-servers were,
>    e.g., initially available for use by everyone on the Internet - with
>    an increased populace on the Internet, attacks and abuses caused the
>    recommended practice is today to require authentication and
>    accounting for users of such SMTP servers [RFC5068].
>
> [JWD] NIT language improvement....with an increase in users on the Internet,
> an increase in attacks and abuses followed necessitating a change in recommended
> practices; today authentication and accounting for users is required for use of SMTP servers [RFC5068].
>
>
>    As OLSRv2 often is used in wireless environments, it is potentially
>    exposed to different kinds of security threats, some of which are of
>    particular significance as compared to wired networks.  As radio
>    signals can be received as well as transmitted by any compatible
>    wireless device within radio range, there is commonly no physical
>    protection as otherwise known for wired networks.
>
> [AB] it should not only say about wireless and wired, but what about
Mobile environment, OLSRv2 is for MANET, so it is not only for wireless.
Threats are more in Mobile environment than Wireless environment. So please
add some words about the different threats for OLSRv2 in Mobile, in
addition to the threats in wireless. Otherwise the draft needs to state
what states that are mobile environment threats, or what states are covered
in the draft.

We need for threats, to define the environment under study/analysis, or the
scenarios. I don't know if IETF they do this or not for threat document,
but IMHO it is very important to have some basic mobile scenarios.

>
>    A first step towards hardening against attacks disrupting the
>    connectivity of a network, is to understand the vulnerabilities of
>    routing protocol, managing the connectivity.  This document therefore
>    analyzes OLSRv2, to understand its inherent vulnerabilities and
>    resiliences.  The authors do not claim completeness of the analysis,
>    but hope that the identified attacks, as presented, form a meaningful
>    starting-point for developing and deploying increasingly secured
>    OLSRv2 networks.
>
>
So the analysis is not complete, we need to say why? if we say why it will
be good for future work to solve the issue. However, we can describe the
analysis as simple-analysis or any other word ( basic, general, ,,,,), that
will help the reader understand that there may be future analysis that will
use this draft as its start for more deep/specific/complete analysis.

>
>    This document first describes security vulnerabilities to OLSRv2 when
>    it is used without the mandatory-to-implement security mechanisms, as
>    specified in Section 23.5 of [RFC7181].  It then analyzes which of
>    these security vulnerabilities can be mitigated when using the
>    mandatory-to-implement security mechanisms for OLSRv2, and how the
> Clausen, et al.         Expires November 10, 2016               [Page 3]Internet-Draft               OLSRv2 Threats                     May 2016
>
>    vulnerabilities are mitigated.  This separation is important since
>    other security mechanisms ([JWD] other) than the mandatory-to-implement ones may be
>    used in a deployment, as explicitly stated in [RFC7181]:
>
>       "Any deployment of OLSRv2 SHOULD use the security mechanism
>       specified in [RFC7183] but MAY use another mechanism if more
>       appropriate in an OLSRv2 deployment.  For example, for longer-term
>       OLSRv2 deployments, alternative security mechanisms (e.g.,
>       rekeying) SHOULD be considered."
>
>    Moreover, this document is also based on the assumption that no
>    additional security mechanism such as IPsec is used in the IP layer
>    or other mechanisms on lower layers, as not all MANET deployments may
>    be able to accommodate such common protection mechanisms (e.g.,
>    because of limited resources of MANET routers).
>
>    The threats related to NHDP (Neighborhood Discovery Protocol) have
>    been discussed in [RFC7186].  As NHDP is a fundamental block of
>    OLSRv2, the vulnerabilities of NHDP apply also to OLSRv2.
>
>    It should be noted that many OLSRv2 implementations are configurable,
>    and so an attack on the configuration system (such as [RFC6779] and
>    [RFC7184]) can be used to adversely affect the operation of an OLSRv2
>    implementation.
>
> [AB] I cannot understand the paragraph, I think there is edit error in
lines of-------  system and can be used ....

will continue review,

Regards
AB