Re: [Roll] Following up on seq Counter to protect the config option and others

Rahul Jadhav <nyrahul@outlook.com> Tue, 15 October 2019 09:31 UTC

Return-Path: <nyrahul@outlook.com>
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 AE5CD120071 for <roll@ietfa.amsl.com>; Tue, 15 Oct 2019 02:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com
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 TWWTc-68UzfK for <roll@ietfa.amsl.com>; Tue, 15 Oct 2019 02:31:43 -0700 (PDT)
Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253062.outbound.protection.outlook.com [40.92.253.62]) (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 D2B41120025 for <roll@ietf.org>; Tue, 15 Oct 2019 02:31:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cxQL+WApwAQGOHk4NldZRG7kwwTYrQFpJ8FzTtPodz8q8i1zhBO+DNYrXEUonrhcnSYgGu4iw3ZuzEW2bOPZ7scdBjRrFYHyprx7EqJAuzPE3EmYN/NRgAYnGTFhJ3WeysUQAQC8O5vq0Nx7aPzN9A/5MDywsgdqOCva77ueXBR8zpz9pG/JFOrkW7HN0nKBgDbNPuRQS0H9oQC2U89Vab/oqzXVMTC/qomYED92qUwP5rABUScJhLfegXPPXCDNVFrNOeqN03YcumX3gCb8xCHeTJ8phA8MSSptSbfPzJFQtOuqKKrEs1jD8YpUZwrZBaPxw0kQOpAPbKqFfIv/Ig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h2pIBHH3Q8A4EaP1GORgOopQ50xHerXgjKMgnB1hsJg=; b=c4N9Ief9iYdEjcpJHWr4uRDBLmL7eLRZp896c3IMacMnr5IqEh+cBt60VsoYA15KLkbGdx+m5HZDr+qim9xw5AKjpy1vDgfjT6KIJ5ytYn6Gs0xKTPxqI8zvPkJXzirl+pSFyX9GzJPUwuMg4IGXBKpR0N/3NRSRNZDkRK56JAdcfm0HZyN92auflpDd9UBsUZzSM40DBYne2eJ8/R1JSzHIukHL/9EHomYwOIW9hgY8I5/J5z55SaUahPfe9Wj/a80zyEPRGNBPSy3HU3IZoM/ar0Ag3y0lo9GCj5rXeVyZcmsTZkwkrhrEew0J6oU8HXcklSJD48AMrInjI612oA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h2pIBHH3Q8A4EaP1GORgOopQ50xHerXgjKMgnB1hsJg=; b=GPLjLuaPjamMYWQ+7OEysUcQNDZmvsD1rKZvj0J1/ZOtBrXo+o5qJ9LlUWl8rn5BVmRjLh1udGT61Rk+1Rn2fKKDiE7ASSi18mhI5L/3CHWZhPnqpdgYUBhbnniawcYXDEb1Fpbjx2F9vZArwYOsJp2D8Vvj2jtWZqUNsVWKS6icHRLoPuOxIZ0eBnjiXOGU5LZoxDQ6uEJP9BbS/YmsfyD/K9N4Xai0kLtuLbJC7F8EphaMrVWWTkYD6R8kTQ0XmyuTZT9FrLgUquEo8IgFNQpVQayRTez1X3g4pihIz6/MY9UCQ6hXThU9++Wm6XQz+8P5/CYGFq7F9gGEip1/mg==
Received: from PU1APC01FT049.eop-APC01.prod.protection.outlook.com (10.152.252.56) by PU1APC01HT190.eop-APC01.prod.protection.outlook.com (10.152.253.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2347.16; Tue, 15 Oct 2019 09:31:40 +0000
Received: from BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM (10.152.252.57) by PU1APC01FT049.mail.protection.outlook.com (10.152.253.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16 via Frontend Transport; Tue, 15 Oct 2019 09:31:40 +0000
Received: from BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM ([fe80::8a1:677d:4fb6:b932]) by BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM ([fe80::8a1:677d:4fb6:b932%6]) with mapi id 15.20.2347.021; Tue, 15 Oct 2019 09:31:40 +0000
From: Rahul Jadhav <nyrahul@outlook.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: Following up on seq Counter to protect the config option and others
Thread-Index: AdWCrxPZcTH2VHjHRxWHUI79NH4rSgAWqh1aAAqHJKAAAYAa0Q==
Date: Tue, 15 Oct 2019 09:31:39 +0000
Message-ID: <BM1PR01MB2612A801ED80473E07AFEE01A9930@BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM>
References: <MN2PR11MB3565FFC5F9C48EC4E7CAD65DD8900@MN2PR11MB3565.namprd11.prod.outlook.com> <BM1PR01MB261263B41F4E94D9329CB698A9930@BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM>, <MN2PR11MB3565BAEE863811C93696213CD8930@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB3565BAEE863811C93696213CD8930@MN2PR11MB3565.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:1F3F7C4C2CC4ABC59D2EA88A393E07335A314662AF0132DDC1248704D721CA5B; UpperCasedChecksum:78EEF9A3742ADF3D3B5DEB8C385D4900FB07BAD247B954F9E185B925ADB0D04F; SizeAsReceived:7108; Count:44
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [5TK1Kc/OrGsZwhFO7u+qP4cJKAkNkPvt]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-traffictypediagnostic: PU1APC01HT190:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: D6cr/h2At0m7Mb00N3CeHnWUAa4M+RltXKd8nmN6FeEmEe2xAITSt2by6U/HCp7wG2PaFrBBtYvyWgyT8eNmf+29wGMBN3kS4zP5olO5AK/x+vS22cm13+2iQPGc52NIDJAlsh0U7IDPA3wpD0YQYujQyNkMVToyKs1agxNCXrug2k9GAGaglOmr2tbYl85H
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BM1PR01MB2612A801ED80473E07AFEE01A9930BM1PR01MB2612INDP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 2e61a4b5-b91d-4db7-0030-08d751527bbb
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2019 09:31:39.8856 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT190
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/NkFfR8eiWEy-4OX6QFYGbkjroE0>
Subject: Re: [Roll] Following up on seq Counter to protect the config option and others
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: Tue, 15 Oct 2019 09:31:46 -0000



We want to protect a global configuration with a sequence set by the root because the root is authoritative in them.

Why? A node may receive different levels of config from different parents and one of them may be back level. The node needs a freshness indication. It may want a signature in the future.

=> We need to split the capabilities that go in the DIO and that are protected by the RCSS from the rest and think about how we protect that rest.



Makes sense?



[RJ] Yes, the problem with RCSS been controlled by individual parents is that it is not possible to know if the root caps are changed. And we certainly need that. So we need to split the caps and use two counters?




From: Roll <roll-bounces@ietf.org> On Behalf Of Rahul Jadhav
Sent: mardi 15 octobre 2019 05:47
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] Following up on seq Counter to protect the config option and others



Note that this also means that the capabilities have to be split between the parent capabilities (not protected) and the network-wide that are (item 5 above)..

The alternate is that the RCSS covers everything a parent advertises in which case it is not set by the root but by individual parents.



[RJ] I think RCSS can be handled by individual parents (similar to DTSN in storing MOP). The only problem would be that additional memory i.e., one byte per parent would be required in this case. May not be a big problem since the parent set is limited in size.



Or do we need 2 counters?



[RJ] IMO, This won't be a good option, memory-wise or handling-wise.