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

manav bhatia <> Tue, 09 September 2014 11:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 06FD31A0052 for <>; Tue, 9 Sep 2014 04:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.579
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id po4JPRjC8GV0 for <>; Tue, 9 Sep 2014 04:46:47 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E0D1C1A004C for <>; Tue, 9 Sep 2014 04:46:46 -0700 (PDT)
Received: by with SMTP id hz20so4284966lab.1 for <>; Tue, 09 Sep 2014 04:46:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id uh10mr33215109lbb.11.1410263204942; Tue, 09 Sep 2014 04:46:44 -0700 (PDT)
Received: by with HTTP; Tue, 9 Sep 2014 04:46:44 -0700 (PDT)
In-Reply-To: <>
References: <087f01cfc036$26032120$72096360$> <> <>
Date: Tue, 9 Sep 2014 17:16:44 +0530
Message-ID: <>
From: manav bhatia <>
To: Michael Richardson <>
Content-Type: text/plain; charset=UTF-8
X-Mailman-Approved-At: Tue, 09 Sep 2014 04:56:43 -0700
Cc:,,, "" <>,
Subject: Re: [Roll] RtgDir review: draft-ietf-roll-security-threats-09.txt
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


>> 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

>> (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.