Re: [Roll] Roman Danyliw's No Objection on draft-ietf-roll-turnon-rfc8138-14: (with COMMENT)

Roman Danyliw <rdd@cert.org> Thu, 10 September 2020 11:57 UTC

Return-Path: <rdd@cert.org>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3FD3A094C; Thu, 10 Sep 2020 04:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 Ki-pQJF4f8De; Thu, 10 Sep 2020 04:57:44 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A10D3A094B; Thu, 10 Sep 2020 04:57:44 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 08ABvblR042161; Thu, 10 Sep 2020 07:57:37 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 08ABvblR042161
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1599739058; bh=FpOHy5680cZOlOPLXe/oXlv79O5fVvPopX9JTv2czfk=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ZG3CrXluSfcTirzzkRSUnHJt83PE6zb4PQW1KzMdKAYlX/qwYoFGly5sHb1Iv3ngC 1mRD7A8HgBFDncu/aYtsF5ITCVwcMdNTxWcOwdo8SXZiKMsxA6xtDyENuiBFf18e2F CTL+VgXxoRLlk8gbghbCZSvR7yfYnqtZiizXVtfo=
Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 08ABvXmI021640; Thu, 10 Sep 2020 07:57:33 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 10 Sep 2020 07:57:33 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Thu, 10 Sep 2020 07:57:33 -0400
From: Roman Danyliw <rdd@cert.org>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-roll-turnon-rfc8138@ietf.org" <draft-ietf-roll-turnon-rfc8138@ietf.org>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "roll@ietf.org" <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-roll-turnon-rfc8138-14: (with COMMENT)
Thread-Index: AQHWhrjGMfxr+M3irEunf+Ap7+JkrKlgsE6A///AtAA=
Date: Thu, 10 Sep 2020 11:57:31 +0000
Message-ID: <63f9e20b35ec4cd7afdcd0cd08eccfcc@cert.org>
References: <159966310991.32249.4584030650116177263@ietfa.amsl.com> <MN2PR11MB356548E58C054951B6519D7BD8260@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB356548E58C054951B6519D7BD8260@MN2PR11MB3565.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.202.159]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/rn5pG9TSOH-Oa93IuCKnk6NX6aA>
Subject: Re: [Roll] Roman Danyliw's No Objection on draft-ietf-roll-turnon-rfc8138-14: (with COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 10 Sep 2020 11:57:46 -0000

Hi Pascal!

> -----Original Message-----
> From: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Sent: Wednesday, September 9, 2020 11:25 AM
> To: Roman Danyliw <rdd@cert.org>rg>; The IESG <iesg@ietf.org>
> Cc: draft-ietf-roll-turnon-rfc8138@ietf.org; roll-chairs@ietf.org; roll@ietf.org;
> Ines Robles <mariainesrobles@googlemail.com>om>; aretana.ietf@gmail.com
> Subject: RE: Roman Danyliw's No Objection on draft-ietf-roll-turnon-rfc8138-
> 14: (with COMMENT)
> 
> Hello Roman
> 
> Many thanks for your time on this review, and for your comments below : )
> 
> Let's see:
> 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 5.  Typo. s/an homogenous/a homogeneous/
> 
> Fixed
> 
> >
> > Section 7.  Editorial. To be clearer on where the attacker is in the
> > topology and on who is incurring the cost:
> >
> > OLD
> > An attacker in the middle of the network may reset the "T" flag to
> > cause extra energy spending in its subDAG.
> >
> > NEW
> > An on-path attacker may reset the “T” flag to force additional energy
> > consumption by the nodes in the subDAG.
> >
> 
> Hum, I believe we're not there yet, because worded as this it looks like the
> attacker is along a unicast path. This is not the case.
> 
> The "T" flag is in a message (the DIO) that is propagated in a fashion that is
> akin to multicast though it's not. The RPL node receives DIO messages from
> neighbors that are willing to be parents. If this node decides to also be a
> parent, it will regenerate a DIO that contains some fields unchanged, including
> the DODAG configuration option.
> 
> In that process, the bad guy may change some fields it shouldn't, including the
> "T" flag, but it's just one of many fields in that same situation. His children and
> their descendant will repeat that wrong setting. Note that this is not a tree but
> a DODAG. So you get DIOs from not one (candidate) parent but multiple ones.
> A descendant may discover an inconsistency between its parents (if some
> descend from the attacker and others do not) and could raise an alert, but the
> case can be normal, e.g., during a transition. RPL does not really specify that, it
> is left to implementations, e.g., constrained nodes will not spend code looking
> for anomalies.
> 
> Bottom line, there is no path to be on. There's a wave coming, the attacker
> relays that wave, and modifies it. If it is in the middle of the network this has
> an effect - on its descendants. If the attacker is at the leaf edge, the attack as
> no effect since this node has no descendant.
> 
> What do you think?

Understood.  I now appreciate the vagueness of the original words.  I'm trying to find an alternative to using "middle of the network" since this doesn't convey for me the hierarchy you are describing.  See below:

> > OLD
> > An attacker in the middle of the network may reset the "T" flag to
> > cause extra energy spending in its subDAG.

NEW
An attacker may reset the "T" flag to force additional energy consumption of child or descendant nodes in its subDAG.

Regards,
Roman

> Take care,
> 
> Pascal