Re: [Roll] RtgDir review: draft-ietf-roll-security-threats-09.txt

manav bhatia <manav@ionosnetworks.com> Tue, 09 September 2014 11:46 UTC

Return-Path: <manav@ionosnetworks.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FD31A0052 for <roll@ietfa.amsl.com>; Tue, 9 Sep 2014 04:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.579
X-Spam-Level:
X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 po4JPRjC8GV0 for <roll@ietfa.amsl.com>; Tue, 9 Sep 2014 04:46:47 -0700 (PDT)
Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0D1C1A004C for <roll@ietf.org>; Tue, 9 Sep 2014 04:46:46 -0700 (PDT)
Received: by mail-la0-f42.google.com with SMTP id hz20so4284966lab.1 for <roll@ietf.org>; Tue, 09 Sep 2014 04:46:45 -0700 (PDT)
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:date :message-id:subject:from:to:cc:content-type; bh=xvPoEK5TIaKcj7nVqgrZjEbnfQC3dPVv9oBco+a+000=; b=cCa1bovMzayvKXMNai7keww7/IkSMiQyeyneEHwHEBWlZNXA/6eAGM5MRwd39q8ooP 7iM2AfPayM0NyKxCdsK/NLOIBhiyG454Or+u1k8hbjmd4iTfsTGrxuEmy3RE/wiSPRTL L5Y8FjNycczW22QHZplJ6U8lkT4CDMBZ303rDz1rob0CSc73RMjEmDoxpdoIXraKJ/tH uhLucxBApfweW8AIE3OVZO3YnL6+kofBwZTyMxYApdLRBMTIqzMgY8ewATr0aDvujssc 7DP5hV7s1LWzryt6EP3b0OLfQbytp2+TLaBy91mE933q9XkA155nlkRjkRsr7+nQ6hT0 Tw8A==
X-Gm-Message-State: ALoCoQn4jfoB+aqD3/V/XxIkWlJ8mVPPKYMScyspF1MloP+0fAslsRHd/+43I7q7hO4XgwPib0OM
MIME-Version: 1.0
X-Received: by 10.112.150.106 with SMTP id uh10mr33215109lbb.11.1410263204942; Tue, 09 Sep 2014 04:46:44 -0700 (PDT)
Received: by 10.112.126.132 with HTTP; Tue, 9 Sep 2014 04:46:44 -0700 (PDT)
In-Reply-To: <9079.1409603902@sandelman.ca>
References: <087f01cfc036$26032120$72096360$@ionosnetworks.com> <CAGS6MpDXeJpmc=fiA8MLiRSgRNtnbTwfsZxtqC63HDJtvttFAA@mail.gmail.com> <9079.1409603902@sandelman.ca>
Date: Tue, 9 Sep 2014 17:16:44 +0530
Message-ID: <CAGS6MpAYzjxUEuVLErjdKCCo7gBnZFS-Jd1xxmJCCqYGGvB0+w@mail.gmail.com>
From: manav bhatia <manav@ionosnetworks.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/3QLUAxhS3-fHs_JmDiC4IQJyTag
X-Mailman-Approved-At: Tue, 09 Sep 2014 04:56:43 -0700
Cc: draft-ietf-roll-security-threats.all@tools.ietf.org, draft-ietf-roll-security-threats@tools.ietf.org, roll@ietf.org, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>, roll-chairs@tools.ietf.org
Subject: Re: [Roll] RtgDir review: draft-ietf-roll-security-threats-09.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 11:46:49 -0000

Hi Michael,

> ***
> This document is as much about naming the threat, and much less about
> providing a definitive solution to the threat...
> ***

Then what precisely is Sec 7 - "Countermeasures" for? All my comments
are on the text within those sub sections.

[clipped]

>>
>> I also don't think it's a good idea to suggest that we "restrict
>> realizable network topologies" to counter overclaim/misclaim attacks.
>
> I guess I will say two things about this.
> 1) we have no specific mechanisms in RPL to either recognize this situation
>    or deal with it.  It's an attack that (any) node with the L2-keys
>    can do, and therefore falls in the category of threats by insiders.

I dont think you get my point. What i am describing is not an attack.

The counter provided in the text to avoid misclaiming imo doesnt look
proper to me. However if i am the only one who thinks that the
guidance provided is not the best, then we could ignore this and move
on.

>> (6) Sec 7.3.3 "Countering Selective Forwarding Attacks". Are you really
>> suggesting that RPL should redundantly flood protocol messages over
>> multiple paths in the hope that at least one will make it to the
>> destination. Given the delicate energy and network utilization constraints
>> this just doesn't look right. Shouldn't we focus more on ensuring that we
>> don't get an insider malicious node than on what we can do once we have
>> one inside our routing domain?
>
> Flooding is an option if you want to deal with selective forwarding attacks.
> Yes, that's right, it's a really bad answer, energy-wise.  Some deployments
> might be willing to make that tradeoff.  In fact, MPL does *exactly* this,
> using trickle to control the flood.
>
> Or, there is option two: "dynamically selecting the next hop from a set of
>     candidates", as you note.  They are mostly mutually exclusive choices.
>
> Or, option three: applicability statement says that they aren't going to
> solve it.

Flooding just doesnt seem right, especially in energy constrained
networks and devices.

>
>
> So you are suggesting that the title:
> 6.2.  Threats and Attacks on Confidentiality
>
> should say something more like:
> 6.2.  Threats due to failures to keep routing information confidential

Yup, this is better.

Manav