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 12:42 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 F1BA43A0B77; Thu, 10 Sep 2020 05:42:31 -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 Yzo9Aov8aNVz; Thu, 10 Sep 2020 05:42:30 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 7532A3A0AE4; Thu, 10 Sep 2020 05:42:24 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 08ACgF3K001247; Thu, 10 Sep 2020 08:42:16 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 08ACgF3K001247
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1599741736; bh=SfuRK6MDsYnSUlBdhfI/3aynXUZKgEXpm23vUKTbC9o=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=bLD6l3N5FriJXEokykKxeGwHmdbpsRe0HT7FkKgmuQkbuzht7Fhb2qMDacFrtTjH8 id0B/Xkw/WWqHB+fUSrPFpDlzGWbuj4kKlJie1eDR4bxfzbOmPQet6k+axSRDhpRs4 b7BfvPLbnE8lfUj7UeieM/2bFBtjfoz8WByimZcA=
Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 08ACgEfb018587; Thu, 10 Sep 2020 08:42:14 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) 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 08:42:14 -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 08:42:14 -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///AtACAAaEHAP//v+AQ
Date: Thu, 10 Sep 2020 12:42:12 +0000
Message-ID: <b95cf6db0add4136989f62615d01d8fd@cert.org>
References: <159966310991.32249.4584030650116177263@ietfa.amsl.com> <MN2PR11MB356548E58C054951B6519D7BD8260@MN2PR11MB3565.namprd11.prod.outlook.com> <63f9e20b35ec4cd7afdcd0cd08eccfcc@cert.org> <MN2PR11MB3565A6E073151141E9FC3620D8270@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB3565A6E073151141E9FC3620D8270@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/yYlNYk7xzVUgGmMnwWwebDVWGDM>
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 12:42:38 -0000

Hi Pascal!

> -----Original Message-----
> From: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Sent: Thursday, September 10, 2020 8:31 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 😊
> 
> > > 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,
> 
> I love it, Roman!
> 
> I'll be holding the publication till Alvaro and Benjamin reach an agreement on
> whether this updates RFC 6550 or not.
> 
> Till then I committed the diffs as  https://github.com/roll-wg/roll-turnon-
> rfc8138/commit/80fa3425e8c0c60a8482ddb2583f75f405fe490a
> 
> Please let me know if we are good now.

Looks good to me!  Thanks for the quick turnaround.

Regards,
Roman