Re: [Roll] AddRE: AD Review of draft-ietf-roll-unaware-leaves-18 (cont)

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 09 November 2020 08:58 UTC

Return-Path: <pthubert@cisco.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 BE8393A0D29; Mon, 9 Nov 2020 00:58:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=fZ+juFPd; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iPgaqnFF
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 hOVqdEB2ohDN; Mon, 9 Nov 2020 00:58:45 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8433A0D20; Mon, 9 Nov 2020 00:58:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9348; q=dns/txt; s=iport; t=1604912325; x=1606121925; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QQpzLPpEe57eQYViX6jzKnAnVy65G4ngqvlZLMG9O6s=; b=fZ+juFPdThYCejvuI1lxXlMVN9bm6/bNa9ViLuquQkOhCOtqy6685N7K gmdobTbppRTfRuJzUbVSxq2F4oK1nb13tl3wK0XDvWLmvHgXmKvp3WIIt lVgfTIMSBnAXX2kwAemXRH/SYwBL4v8KQfKdWS2RC/W7RRN6/kxKRb/SF E=;
X-IPAS-Result: =?us-ascii?q?A0DpCAC4A6lffYsNJK1aCB4BPAwCCxWDIVF7WS8uhD2DS?= =?us-ascii?q?QONVYEFl3yBQoERA1QLAQEBDQEBJQgCBAEBhEoCF4F7AiU4EwIDAQEBAwIDA?= =?us-ascii?q?QEBAQUBAQECAQYEFAEBhjwMhXIBAQEBAgESEREMAQE3AQQLAgEIDgwCJgICA?= =?us-ascii?q?jAVEAEBBAENDRqDBYJVAw4gAQ6iIQKBO4hodoEygwQBAQWBMwGDWxiCEAMGg?= =?us-ascii?q?Q4qgnODdYZXG4FBP4ERQ4IaNT6CRhcCAQGBNg4KEYMVM4Iskyc+kymRHAqCb?= =?us-ascii?q?YkNhg6MFIMYihKURpNOgX6Ie5VNAgQCBAUCDgEBBYFrIYFZcBWDJFAXAg2SE?= =?us-ascii?q?IUUhUR0AgktAgYBCQEBAwl8iwYCBSEHghcBAQ?=
IronPort-PHdr: =?us-ascii?q?9a23=3An4QXIxd0WFNpMHpuHTE43HvslGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQAdfU7vtFj6zdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutaFjbo3n05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.77,463,1596499200"; d="scan'208";a="621075327"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Nov 2020 08:58:43 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A98whnl001629 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2020 08:58:43 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Nov 2020 02:58:43 -0600
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Nov 2020 03:58:42 -0500
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 9 Nov 2020 02:58:42 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eJGF8Y7xl5S+ooQCvM7RnR1kwOB5UkXRUETilq9BpSUhW3zMl+cMEqXm+xMHg7EMHzgh99NxF7PIwD6ZorYWmP/QRsmRDrQxEA2m6plRjC46LsHg8nVEzfB5ewQzvXH8bJ4BryJqRtnC9LKdoUzWOn/9T+tXJOJK13ifI0eBzzvT9D78o7dkg7aDF41cjzT8/Tl59D7JuaoSHs+iSSij2a4AHN3B8VUUdsFU4JdxHwTwR5GTj7aRJh37Gvd7fpxQrA2MRTTCjS3uCMRxWr8+DVHDC5ousCxobAVsj3LWUDIk+Prl5+YxJu/BiWsy0NjcVqBWwX5ZxsVttkKCvnbFig==
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=QQpzLPpEe57eQYViX6jzKnAnVy65G4ngqvlZLMG9O6s=; b=iQ0hnJvGqdjhoSOgd2vfA2qNSa3RtYQswYUIL7Q71vNvXnG9CNpwmLBU1WVKD9HY1UjOmL4MtLogScqz+/fuw1aLq+cf4G0IN62YZ0kF+DWYiSCcHRCahNOebNgZyt1CgAQbYKmcVIEB4qDd5fW8nsWr+Tlya6rIOMCzht28eLyAT1x1Vm/z+ym55N3PisRUvi5xN7qb4WPVlw0XBhY3EwoVa96StjR6XAQt6gpSKOwaVvY1Z62O1UH/BlCNRUNCRVXYzOfiU+ICRYWAumeUpio3YvhNOpT1vjvdA9pkhr+Temj7wVWxsLJcBgqyXVGglCbBocUOzHXmou18qv6vIg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QQpzLPpEe57eQYViX6jzKnAnVy65G4ngqvlZLMG9O6s=; b=iPgaqnFFqW+nf2g/ctpzL1WHhMGYe1x79gQCEgdvbI7j7mfIdasXTB4WcmHtWVtdCp8p6lsnDphbPwgcMFQw5JqPHPY8xvKcP9ijyRS8GS4jEq+3Vb5KcJX63QvVjngPwxZEKHG42ITPjhwfzGkNXLYjwzgFkRUv5KTbBhD6F4s=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MW3PR11MB4747.namprd11.prod.outlook.com (2603:10b6:303:2f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.23; Mon, 9 Nov 2020 08:58:40 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ad88:1b7e:c9f2:b30d]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ad88:1b7e:c9f2:b30d%6]) with mapi id 15.20.3541.024; Mon, 9 Nov 2020 08:58:40 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-roll-unaware-leaves@ietf.org" <draft-ietf-roll-unaware-leaves@ietf.org>
CC: "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "Routing Over Low power and Lossy networks" <roll@ietf.org>, Rahul Jadhav <rahul.ietf@gmail.com>
Thread-Topic: AddRE: AD Review of draft-ietf-roll-unaware-leaves-18 (cont)
Thread-Index: AdatWy2mXTdzAsDFTqmHK9bpaMWnsgHLm6oAACjXjZA=
Date: Mon, 9 Nov 2020 08:58:26 +0000
Deferred-Delivery: Mon, 9 Nov 2020 08:58:14 +0000
Message-ID: <CO1PR11MB4881F316BA26841631DEA3ACD8EA0@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <CY4PR11MB135293C625696CFC5997520ED8170@CY4PR11MB1352.namprd11.prod.outlook.com> <CAMMESsx6mF9W1+O0fpCy-Q-0jbmvc4UBo_HG7TCKcennv-Dr+w@mail.gmail.com>
In-Reply-To: <CAMMESsx6mF9W1+O0fpCy-Q-0jbmvc4UBo_HG7TCKcennv-Dr+w@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:8cd9:8d24:c5d2:c846]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 45791ab8-56a8-4ed0-f346-08d8848da784
x-ms-traffictypediagnostic: MW3PR11MB4747:
x-microsoft-antispam-prvs: <MW3PR11MB4747BE16B8F65036B6C3EA24D8EA0@MW3PR11MB4747.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Yvr+VP8sYOH/rg6nyDlcizmhxFbzeGdGWoimCAkcPW9ssEdT+CNB98Ew2vyOaVgmypTuLsYR8JFgpfk2xreqUvRK03H5wnKLr5O9wi8pf92pHEctGMDt2DwP8DS8Zc5LsW6kRaKOZx/7n1+CqZBW6ofOsHyDyIgBl7Iz2UwO3kaAWKyqsuQTBrIyCDNzsCHqPCWl29pOvdYlCEhxmx9H23C5fJhGPhcTA58VlC4lpd2BKz+L0IB43lSPZ44EaIV6DFgxw3xefwczPEcIOO5FB0O9/vdUP5/NPFJ+77aQLlwNQ4tBaNck9LPZnUxp+SmPqgFD25RL+IYGW81OLsmuIYBksUOmBSRKlXPAwHMhSRGrcA9o640JjJDFzTH3oSGec6O5eHpvN0cWTRtqJd/ddg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(396003)(366004)(39860400002)(136003)(7696005)(33656002)(86362001)(83380400001)(186003)(2906002)(55016002)(66476007)(9686003)(64756008)(66556008)(4326008)(52536014)(6666004)(71200400001)(6506007)(8936002)(66946007)(110136005)(54906003)(316002)(66446008)(8676002)(76116006)(5660300002)(478600001)(966005)(66574015); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: H4XGaeqWL6Rj+55ivCAxskjTqcT2sDLvpW6lxEg9TqcrPM7zoo0dI8Ye5LSv8fiKQB8cqmHdfRK4boO155fqqIiA/zGoTa/TC6lz0Dlg8svIaHBTznJtj4x7TMJwqftIPDLNQ3+NbXk2+FTF46k/+EqVoV+2obfSq8kNDxxhlRxoYrtClyDYaiyHhcCoGVh+J5ERicwkssAV4EasxdtJs5Wh3Dm4lR2G68W2wxmnnVBJJiu8n9gh4pXiVGt/h/e/gu3rXIUJGZX544EzYD/frOQRHxVz9ZftqlpgqenzaqAqrjTJIxESxGLC3az0N69BTzmOTJdmD0vfccgC40XQHsj9/JGOZ8nSp6suSLQi+LwdngVMyFodR5xwQYMKCwbJvKQcmmnRASm51TFpxvxLGgq5UPWJdw+vS/+aHCw8Ci1xhU4l7/qG81GJ8d5TM/9WUrvFyL6R+c/cZIJe5NnmUpVtaaAyh2XpTD7K+7jctlBddKU+LaOGcc0hGVyaaqqeGQC9gBjm0QaXGCDx3A1POE5hnLgQPLBwMMtQcEqoMU0b0ysfszSyTWaCZAJe2Zxm61Avz+4NEvLRdDaPaFsygft6m5gFxzp62SlG8K5B9wDYKI150MJIHUtQxrW/qNEy7j+/DeeyWawYW2SrMD9vonv1jSJjZA0UbDti8cndGd6dmQY3NKSKiEuHRdCqn1wF/O5kplvgIEhpM0S6tdHGNA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 45791ab8-56a8-4ed0-f346-08d8848da784
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2020 08:58:40.7643 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: XojKFh5z3UownY0gCG+loTVVbd6cN9KaGN4kIeTkLWxWhgYTGDiu8GfcmLl8EoUg9azlvxfxLXjv7eT11m+Saw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4747
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/kQSkZDJ8HRZCmlNKG9CQ-7_XyDA>
Subject: Re: [Roll] AddRE: AD Review of draft-ietf-roll-unaware-leaves-18 (cont)
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: Mon, 09 Nov 2020 08:58:48 -0000

Many thanks Alvaro!

I committed to git but the IETF datatracker is locked till next week.
Please find the delta here:

https://github.com/roll-wg/roll-unaware-leaves/commit/6068e40d6450b33e664460d606e860401cc9a5c3

more below : )

> 
> Hi Pascal!
> 
> 
> There are just a couple of remaining comments...nothing major.  I will start
> the IETF LC when you upload an update. :-)
> 
> Thanks!!
> 
> Alvaro.
> 
> 
> 
> ...
> > > > But we're also merging the statis with the DCO-ACK Status In that
> > > > we deprecate
> > > > https://www.iana.org/assignments/rpl/rpl.xhtml#rpl-dco-ack-status
> > >
> > > That is new!! I don't even see DCO-ACK mentioned in the document at all.
> > >
> > > Does this mean that §12.5 should also be changed to include the
> > > DCO-ACK message in it?
> >
> > Not sure I understand. §12.5 Has the only DCO status, status 1.
> 
> §12.5 says this:
> 
>    This specification creates a new Subregistry for the RPL Non-
>    Rejection Status values for use in the RPL DAO-ACK and DCO messages
>    with the 'A' flag reset, under the RPL registry.
> 
> s/DAO-ACK and DCO/DAO-ACK, DCO, and DCO-ACK
> 
> 

Oh I see, done.

> 
> ...
> > > [major] What should the receiver do if a different value is used?
> > >
> > Added
> > "
> > ROVRsz (ROVR Size): Indicates the Size of the ROVR. It SHOULD be 1, 2,
> > 3, or 4, indicating a ROVR size of 64, 128, 192, or 256 bits,
> > respectively. If a legacy Target Option is used, then the value must
> > remain 0, as specified in [RFC6550]; In case of a value above 4, the
> > size of the ROVR is undetermined and this node cannot validate the
> > ROVR; an implementation SHOULD propagate the whole Target Option
> > upwards as received to enable the verification by an ancestor that
> > would support the upgraded ROVR.
> > "
> 
> [nit] s/[RFC6550]; In/[RFC6550]. In

Done

> 
> 
> [major] "value above 4, the size of the ROVR is undetermined and this node
> cannot validate the ROVR; an implementation SHOULD propagate the whole
> Target Option upwards as received to enable the verification by an ancestor
> that would support the upgraded ROVR."
> 
> Several points:
> 
> 1- Maybe I missed it, but I didn't see anywhere that a RPL node would validate
> the ROVR.  Is that implicit somehow?  Note that I'm referring to RPL
> functionality since we're talking about the Target Option (not from rfc8505's
> point of view).
 
As of now, the only verification is by the 6LBR, when the Root proxies the EDAR. It is important that the intermediate routers transport the ROVR even if they do not understand it, so the Root can do appropriate proxying. The 6LBR verifies that the ROVR is the same, else it triggers a validation by the 6LR.

This may happen in the case where the 6LN does not claim the ROVR is cryptographic and thus the 6LR does not do the validation, but the ROVR already existed at the 6LBR and was seen as cryptographic, so the 6LBR triggers the check.

See https://www.rfc-editor.org/authors/rfc8928.html
"
The 6LR MUST indicate to the 6LBR that it performed a successful validation by setting a status code of 5 ("Validation Requested") in the EDAR. Upon a subsequent EDAR from a new 6LR with a status code that is not 5 for a validated Binding, the 6LBR MUST indicate to the new 6LR that it needs to challenge the 6LN using a status code of 5 in the EDAC.
"

Now, it is my hope that in the future we add an ROV (route ownership validation) method to RPL, based on the ROVR.

> 2- It seems to me that both the 6LR and then the Root simply copy the ROVR
> from/to the EDAR.  IOW, there doesn't seem to be another RPL ancestor who
> would do anything with it.
 
True, this spec does not have a backward compatibility issue. 
But we are still changing the DAO for all modes. So I thought we need to indicate what the behavior is in other modes as well.


> 3- Assuming that the 6LR somehow originated a bad Target Option (with a
> ROVRsz > 4), then it looks like the Root wouldn't be able to send an
> EDAR.  What should it do?  I'm guessing it should send a failure signal back to
> the 6LR.

True. I guess that could be a bad RPL status on the DAO-ACK; if there is no ACK requested it could be a DCO. 
I'm wondering if we should start defining RPL statuses. Note that the case is either a bug or a backlevel Root, IOW a deployment issue. 
We should not complexify the code overtly for any if those case.

> 
> 4- We're making assumptions about an "upgraded ROVR".
> 
> 
> To solve all this maybe just delete starting with "In case of a value above
> 4..."   If RPL is just carrying the information then that seems more an rfc8505
> issue...
> 

Well, the 6LR is capable of placing a larger ROVR and the Root does not understand it. This needs to be reported to the network admin. 
I'm not too happy removing the sentence for the reasons above. I'll do this git commit with it but keep the point open.


> > Nothing prevents a packet coming in a RPL domain to carry an RPI.
> > E.g., that packet escaped another RPL domain, which is now valid. The
> > border router (typically the root) must rewrite it. the question is
> > whether we assume that the RUL placed a meaningful one. I'd say that
> > cannot be assumed in all cases, e.g., if instead of a leaf we have
> > another RPKL network.
> > But when it is useful, the 6LR should have a policy to know so it
> > knows how to use it.
> ...
> > I added
> > "
> > If the packet from the RUL has an RPI, the 6LR as a RPL border router
> > MUST rewrite the RPI to indicate the selected Instance and set the
> > flags, but it does not need to encapsulate the packet.
> > "
> >
> > Also added
> >
> > "
> > It is up to the 6LR (e.g., by policy) to use the RPLInstanceID
> > information provided by the RUL or rewrite it to the selected
> > RPLInstanceID for forwarding inside the RPL domain.
> > "
> 
> Good...except that I think there's a Normative conflict: "the 6LR...MUST
> rewrite the RPI" vs "up to the 6LR...to use...or rewrite".
>  s/MUST/SHOULD

Done, though unconvinced. "up to the 6LR..." has no normative text on the 6LR behavior, just on the 6LN. 

> 
> Should any of this be also in UseofRPLInfo?  Or maybe it should be explained
> there and referenced form here.  UseofRPLInfo talks about always inserting
> the RPI at the 6LR, no exceptions.
> 

I'll open a thread; your point on the security section could be reflected there, that if the external destination passes a packet with a RPI then the RPI should be revisited or encapsulated.


> 
> 
> ...
> > I'm wondering if there again the end of your message was lost?
> 

Great, ready to publish when you (and the datatracker) are!

Take care,

Pascal