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

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

MIME-Version: 1.0
In-Reply-To: <9079.1409603902@sandelman.ca>
References: <087f01cfc036$26032120$72096360$@ionosnetworks.com> <CAGS6MpDXeJpmc=fiA8MLiRSgRNtnbTwfsZxtqC63HDJtvttFAA@mail.gmail.com> <9079.1409603902@sandelman.ca>
Date: Tue, 09 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
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
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>

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

Re: [Roll] RtgDir review: draft-ietf-roll-securit… Michael Richardson
Re: [Roll] RtgDir review: draft-ietf-roll-securit… manav bhatia